按是否要运行程序进行划分测试方法

1.静态测试:不运行测试程序,通过检查文档或源程序语法,结构,过程(测试对象:1.需求文档,各类设计文档 2.源程序)

2.动态测试:通过跑程序进行测试(测试对象1.源程序 2.软件)

是否自动化划分

1.手工测试:手动一个一个测试程序

2.自动化程序:需要工具或者写脚本测试

其他测试方法

1.冒烟测试:针对最基本的功能和流程测试(从开始一个接一个测试,想烟囱一样冒烟)

2.回归测试:前bug修改完后,进行重新测试(1.bug回归测试:测上次bug的地方 2.旧功能回归: bug改了看看之前全部旧功能受不受影响)建议使用自动化脚本

3.随机测试:需要一定工作经验(测测一些重要功能,其他人没测的功能)

4.探索性测试:测试设计时与测试执行同时执行(为了完善测试用例,进行完整系统测试)

测试计划和测试方案

测试计划:描述要进行的测试活动范围,资源和进度文档(管理型文件)

包含内容: 1.测试目标与范围 2.角色分工与职责 3.任务安排/进度与资源分配 4.风险评估与应急计划5.测试各项标准(重点在于资源分配与风险评估)

测试方案:从测试技术角度分析,重点在于测试策略与技术实现(技术型文件)

测试方案包含:

1.测试策略:

a.UI,功能,易用性(用户体验),兼容,性能

b.安全:授权/隐私/数据传输/数据存储

c.可靠性:稳定性/健壮性/可恢复性/错误处理

d.可维护性:可拓展

e.可移植性:重用

2.测试方法:1.手工/自动化 2.黑盒/白盒

测试用例:指导软件进行操作,帮助证明软件功能或发现软件缺陷的一种说明,最终形成文档

测试用例8大要素:1.编号(唯一性) 2.模块 3.用例标题(见名知意) 4.前置条件(外在环境网络,系统服务,本模块前置模块) 5.测试数据 6.测试步骤 7.预期结果 8.优先级(在资源受限时,测试用例执行的先后顺序)

作用:1.便于降低测试人员交接成本

2.便于评估测试工作量(量化),提前准备数据,分配任务,把控进度

3.便于回归测试

4.便于理清思路,确保测试

测试用例设计方法

1.等价类 2.边界值 3.判定表 4.场景法 5.流程图 6.错误推测法 7.因果法 8.正交法

一.等价类划分法

应用于有数据输入的地方

1.从大量数据中划分范围(等价类)然后从每个范围中挑选代表数据

2.这些代表数据要能反映这个范围数据共性的测试结果

步骤:1.需求分析 2.用例设计 划分有效等价类/无效等价类 3.编写测试用例

举例 需求:QQ账号输入,6-10位自然数

二.边界值法

使用场景与等价类划分法组合使用(1.对等价值法的补充 2.大量程序错误往往发生在边界上)

步骤: 1.需求分析 2.用例设计,划分等价法找出上/内/离点 3.编写测试用例

上点边界上的点(10-99 10和99)

内点:边界内的点(10~99)

离点:离边界最近的左右点(9和11 98和100)

举例 QQ号输入,6-10位自然数

1.需求分析 2.用例设计,等价值法,确定边界法(上:6 10 内 8 离 5 7 9 11)

3.编写测试用例

三.判定表法

用于处理较复杂业务逻辑,如:不同选择/条件,能带来不同结果,使用判定表能避免遗漏测试点

步骤:1.需求分析 2.用例设计,使用判定表法 3.编写测试用例,梅列数据对应一条结果

例: 需求:若用户欠费或关机,则不允许被呼叫

1.需求分析 分析输入/输出,查看是否符合判定表法

输入->选择/条件->条件有欠费或关机

输出->结果->结果有允许被叫和不允许主被叫

2.用例设计,通过判定表法,列表分析

3.编写测试用例,每列数据对应一条测试用例

四.因果图: 输入条件或输入条件组合较多,组合使用判定表与因果图

五.正交法:基于数学概率学,设计最经济的实验路径

六.场景法:一般的功能都是由多个步骤来实现,多个操作组合 结果只有成功或失败 需要遍历所有用户场景

注:判定表法遍历是所有输入可能性 场景法遍历是所有输出的可能性

举例:测试微信红包功能,用场景法设计测试用例

1.分析用户操作发红包遇到情况

2.分析场景情况

场景一:成功发送红包–基本流

场景二:余额不足–备选流1

场景三:被删除好友/被拉黑–备选流2

场景四:网络异常–备选流3

3.编写测试用例

学习心得总结: 1.功能->场景->步骤->条件->测试点

重点:先对场景分类,再对每个步骤/条件中使用等价类/边界值/判定表法设计方法

2.融合测试点->推导完整用例(成功场景,一条用例尽量覆盖多个测试点

失败场景,一个测试点就刷一条用例)

微信发红包设计用例

七.流程图法

当功能的业务逻辑和实现步骤较多较复杂时,可以借助画流程的方式去辅助分析用户场景

1.需求分析

2.用例设计画流程图(开始/结束:椭圆 方向/路径:箭头 处理操作:长方形 判断:菱形 输出:平行四边形)

3.编写测试用例(一条流程图就是一条用例)

八.错误判断法

测试人员使用经验或直觉发现错误

举例:开发人员在开发新功能时:关联业务容易出问题

异常场景考虑不全:输入项空值/空格/特殊字符处理

异常场景,如网络超时

软件缺陷与缺陷管理

软件缺陷:软件毛病,可能存在于功能/UI/兼容性/易用性/性能等方面

缺陷产生原因:1.需求文档错误/疏忽 2.编码错误:设计错误/编码错误 3.其他原因:时间紧,沟通理解错误

缺陷描述:测试人员发现bug后,应确认无误描述bug,描述应该具有规范性

要素:1.编号(唯一性) 2.模块 3.缺陷模块:见名知意/让开发人员理解/唯一性

4.严重程度(严重:主功能不可用 一般:次要功能不可用,边界/异常未进行

一般:次要功能不可用,边界/异常未进行处理

微小:UI问题,易用性问题,建议等)

5.优先级: 高:阻断性问题,影响继续测试,需要立刻修复 中:正常流程,本次迭代上线前修复即可

低:可以延期到下个版本解决

6.复现步骤

7.预计结果

8.实际结果

9.缺陷类型:代码错误/界面错误/兼容性错误/易用性问题/性能问题/安全问题

10.缺陷状态:1.新建 2.已指派 3.打开 4.修复/拒绝/延期 5.完成/再次打开

缺陷报告

一个记录缺陷文档

组成:包括缺陷描述的全部内容,附加测试日期,解决人员,解决日期,解决方案

注意:1.一个缺陷一个报告 2.尽量确保缺陷可以重现 3.简洁,准确,完整

BugList

缺陷统计

场景:1.统计数据可以整理到测试报告中,方便项目相关负责人知悉当前测试版本的整体质量

为了了解隐患和方便后续绩效考核

禅道使用

一种帮助测试开发人员进行bug管理的国产项目管理工具

由禅道管理并导出的bug文档

禅道工作流

测试人员使用流程

一.测试用例管理

1.编写测试用例 测试->用例->“+建用列”

2.用例评审(a.用例评审功能,禅道里默认关闭,可以由管理员到后台->自定义->用例->评审流程开启

b.开启后,新建用例状态(待评审)

c.用例评审线下活动,线下开会,由有权人员显示修改用例状态)

3.用例执行

二.Bug管理

1.提交bug 测试->bug->“+提bug”

2.回归性测试 回归测试通过,则关闭bug 不通过激活bug 已关闭bug再现,可重新激活

3.导出/报表 测试->bug->可以看见"+提bug"旁有导出/报表 功能

测试报告

测试活动的总结性文档,标志测试活动的结束

内容包括:1.测试工作经过的结果 2.风险评估 3.缺陷汇总和分析 4.测试工作的总结和改进

打算从事软件测试的小伙伴注意啦!!领取软件测试零基础全套入门学习资料，扫码加微领取
添加wx好友时备注: 111 !!!