测试理论基础4

测试理论基础第四天

一、流程分析法
定义
流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径在黑盒测试中，若将软件系统的某个流程看成路径的话， 则可以针对该路径使用路径分析的方法设计测试用例
优点
1.降低了测试用例设计难度，只要搞清楚各种流程,就可以设计出高质量的测试用例来，而不需要太多测试方面的经验
2.在测试时间较紧迫的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍
步骤
1.详细了解需求
2.根据需求说明或界面原型，找出业务的各个页面以及各页面之间的流转关系
3.画出业务流程
4.写用例，覆盖所有的路径分支
总结
流程分析法适用于有先后顺序的测试。常用于业务流程测试、安装流程测试等
注意
流程测试没有问题并不能说明系统功能没有问题，还需要针对每步功能进行测试。对于包含复杂流程的系统,只有功能点和处理流程都进行测试覆盖,才算是比较充分的测试

二、错误推断法
定义
错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况,它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法
基本思想
列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例;这种方法很大程度上是凭经验进行的， 即凭人们对过去所作测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷采用错误推测法，最重要的是要思考和分析测试对象的各个方面,多参考以前发现的Bug的相关数据、总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序,才能够设计出比较完善的测试用例
三、正交排列法
定义
正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率。当可能的输入数据或者输入数据的组合数量很大时， 由于不可能为每个输入组合都创建测试用例，可以采用这种方法
实验设计
是研究多因素多水平的一种设计方法,它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散 齐整可比” 的特点，正交试 验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。
步骤
1.根据所测程序中控件的个数(因素)以及每个控件的取值个数(水平)，选取一个合适的正交排列表
2.把控件及其取值列举出来，并对其进行编号
3.把控件及其取值映射到正交排列表中
4.根据映射好的正交排列表编写测试用例
公式
Ln（m^k）
n是表的行数，也就是需要测试的组合次数,k是表的列数，表示控件的个数（因素的个数或因子个数）,m是每个控件包含的取值个数（各因素的水平数即各因素的状态数）
总结
1.根据控件和取值数选择一个合 适的正交表
2.列举取值并编号，生成取值表
3.把取值表与选择的正交表进行映射
四、测试用例方法总结
原则
1.根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。
2.认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误
使用测试方法选择依据
1.拿到一个测试任务时,先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
2.需要输入数据的地方,考虑采用等价类划分法,包括输入条件和输出条件的等价划分，将无限测试变成有限测试
3.在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例现程序错误的能力最强
4.如果程序的功能说明中含有输入条件的组合情况,则开始就应考虑选用因果图和判定表法
5.对于参数配置类的软件，需要考虑参数之间的组合情况,考虑使用正交排列法选择较少的组合方式(最少的测试用例获得最大的的测试覆盖率
6.对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例
7.采用错误推断法再追加测试用例一依靠测试工程师的经验和智慧
测试用例的力度
编写测试用例的力度要介于简单和复杂之间
测试用例的本质
测试用例的设计本质应该是在设计的过程中理解需求,检验需求， 并把对软件系统的测试方法的思路记录下来，以便指导将来的测试
测试用例评审
1.同行评审
2.用户评审
五、软件缺陷
定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要现实的某种功能的实效或违背，因此软件缺陷就是软件产品中所存在的问题， 最终表现为用户所需要的功能没有完全实现，没有满足用户的需求
软件缺陷的表现形式
1.功能特性没有实现或部分实现
2.产品不合理，功能特性不明确，逻辑不清楚或存在矛盾
3.产品实际结果和所期望的结果不一致
4.没有达到需求规格说明书所规定的性能指标
5.运行出错，包括运行中断、系统崩溃、界面混乱等
6.数据不正确、精度不够、不完整或格式不统一
7.用户不能接受的其他问题，如存取时间过长、界面不美观
8.硬件或系统软件上存在的其他问题
软件缺陷的产生原因
1.需要解释或者记录错误
2.用户需求定义错误
3.设计说明存在错误
4.编码说明、程序代码有误
5.硬件或者软件系统上存在错误
6.其他，如文档错误、内容不正确或拼写错误
软件缺陷分类
缺陷状态
1.提交submited
已提交的缺陷
2.打开open
确认“提交的缺陷”等待出来
3.拒绝rejected
拒绝“提交的缺陷”不需要修复或不是缺陷、重复缺陷、无法重视
4.修复resolved
缺陷被修复
5.关闭closed
确认修复的缺陷，将其关闭
6.推迟later
可在以后解决，但是确定修复日期或版本
缺陷信息
1.缺陷ID
唯一的缺陷ID，可以根据该ID追踪缺陷
2.缺陷状态
缺陷状态值缺陷通过一个跟踪修复过程的进展情况
3.缺陷标题
描述缺陷的标题
4.缺陷的严重程度
对软件产品的影响程度，分致命、较严重、严重、一般、低
5.缺陷的优先级
缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正
6.缺陷所属模块
缺陷所属的项目和模块，要能较精确的定位至模块
7.缺陷记录着
提交缺陷的人员姓名
8.缺陷提交时间
缺陷提交的时间
9.缺陷处理人
处理缺陷的处理人
10.处理结果描述
对处理结果的描述，描述处理情况和代码修改说明
11.缺陷处理时间
缺陷处理的时间
12.缺陷验证人
对被处理缺陷验证的验证人（回测者）
13.验证结果描述
对验证结果的描述（通过、不通过）
14.缺陷详细描述
缺陷的重现步骤
15.缺陷环境说明
对测试环境的描述
16.必要的附件
如涉及到附件的或错误现象的图片等
缺陷所属模块（bug类型）
1.系统缺陷
1.由于程序所引起的死机，异常退出
2.程序死循环
3.程序错误，不能执行正常工作或重要功能，使系统崩溃或资源不足
2.数据缺陷
1.数据计算错误
2.数据约束错误
3.数据输入、输出错误
3.数据库缺陷
1.数据库发生死锁
2.数据库的表、缺省值未加约束条件
3.数据库连接错误
4.数据库中的表有过多的空字段
4.接口缺陷
1.数据通信错误
2.程序接口错误
5.功能缺陷
1.功能无法实现
2.功能实现错误
6.安全性缺陷
1.用户权限无法实现
2.超时限制错误
3.访问控制错误
4.加密错误
7.兼容性缺陷
与需求规定配置兼容性不符合
8.性能缺陷
1.未达到预期的性能目标
2.性能测试中出错导致无法继续进行测试
9.界面缺陷
1.操作界面错误
2.打印内容格式错误
3.删除操作未给提示
4.长时间操作未给出提示
5.界面不规范
10.建议
1.功能建议
2.操作建议
严重程度
1.low
表面性错误(如错别字)
2.medium
a.影响一个相对独立的功能
b.仅仅在特定条件上发生
c.与产品需求定义不一致
d.断断续续的出现问题
3.high
a.功能点没有实现或不符合用户需求
b.数据丢失
4.veryhigh
频繁的死机，系统大部分功能不可用
5.critical
系统瘫痪、异常退出、死循环、严重的计算错误等
优先级
1.low
最低优先级.时间和资源允许时修正
2.medium
低优先级.不会延迟发布,但是会在以后修正这个错误
3.high
中优先级.如果这个错误存在与系统中,会制约开发和测试的活动的进行,如果先前没有修复它,那么需要在发布前修复它
4.veryhigh
高优先级.错误对这套系统的能力产生严重的影响
5.urgent
最高优先级.在这个错误影响下系统机会不可用