测试基础第三天
正交排列法
正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率。
当可能的输入数据或者输入数据的组合数量很大时，由于不可能为每个输入组合都创建测试用例，可以采用这种方法。
案例：字符属性设置程序
窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值
- 字体：仿宋、楷体、华文彩云
- 字符样式：粗体、斜体、下划线
- 颜色：红色、绿色、蓝色
- 字号：20号、30号、40号
正交试验设计
是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交排列表的、高效率、快速、经济的试验设计方法。
正交排列表是经过严格的数学推理得来的。
正交排列法的使用步骤
1、根据所测程序中控件的个数（因素）以及每个控件的取值个数（水平），选取一个合适的正交排列表
2、把控件及其取值列举出来，并对其进行编号
3、把控件及其取值映射到正交排列表中
把正交排列表中的ABCD（因子）分别替换成4个控件
把每列中的1,2,3（状态）分别换成这个控件的3个取值（水平），排列顺序要按照表中给出的顺序
4、根据映射好的正交排列表编写测试用例
练习：字符属性设置程序
步骤一：根据所测程序中控件的个数以及每个控件的取值个数，选取一个合适的正交排列表
4个控件（因素）：字体、字符样式、颜色、字号
每个控件有3个取值（水平）
选择L9（3^4）正交排列表
|
编号 |
字体 |
字符样式 |
颜色 |
字号 |
|
1 |
仿宋 |
粗体 |
红色 |
20号 |
|
2 |
楷体 |
斜体 |
绿色 |
30号 |
|
3 |
华文彩云 |
下划线 |
蓝色 |
40号 |
步骤二：把控件及其取值列举出来，并对取值进行编号
步骤三：把控件及其取值映射到正交排列表中
1、把正交排列表中的A、B、C、D（因子）分别替换成4个控件
2、把每列中的1,2,3（状态）分别换成这个控件的3个取值，排列顺序要按照表中给出的顺序
步骤四：根据映射好的正交排列表编写测试用例
正交表的每一行表示一种组合，对应编写一条测试用例
案例：114系统查询企业单位
使用正交排列法的局限性
目前常见的正交排列表只有前面附录文件中给出的几种
即使是已有的正交排列表，基本都要求每个控件中取值的个数要相等，这在实际软件中很少遇到。
没有现成的正交排列表怎么办？
通过正交排列法的学习，我们更多的应该学习到一种测试思想，也就是在从所有组合集合中选取测试数据时，应该均匀的选取其中的组合作为测试用例，而不要只在某个局部选取数据。
混合正交表
找不到现成的正交表，就只能使用工具来生成！
正交表生成工具allpairs
使用步骤：
1、制作取值表（只列出数据即可，不用编号）
2、复制取值表的数据，放到文本文档中保存（注意不要更改任何格式，例如文件叫Test2.txt ）
3、把文本文档放在allpairs文件夹中
4、win+r后输入cmd进入控制台
5、使用控制台代码进入allpairs文件夹（cd 目录的绝对地址）
6、在控制台中输入allpairs.exe Test2.txt>chenggong.txt （ chenggong是自己起的名字，用来存放生成的组合用例，可以自动生成，不必提前建好）
allpairs.exe Test2.txt> chenggong.txt
测试方法的选择
在确定测试方法时，应遵循以下原则：
- 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。
- 认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误。测试需要找到一个平衡点。
通常在确定测试方法时，有以下几条参考原则:
（1）拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法。
（2）需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试。
（3）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。
（4）如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图和判定表法。
（5）对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法，用较少的测试用例获得最大的的测试覆盖率。
（6）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。
（7）采用错误推断法再追加测试用例——依靠测试工程师的经验和智慧。
测试用例的力度
最简单的测试用例是测试的纲要，仅仅指出要测试的内容。是需要把测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划。
最复杂的测试用例则会指定输入的每项数据，期待的结果及检验方法，具体到界面元素的操作步骤，指定测试的方法和工具等。
测试用例的本质
测试用例的设计本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
基于需求的测试用例设计是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
要把测试用例当成活的文档，因为需求是活的，善变的。因此在设计测试用例方面应该要把敏捷方法的“及时响应变更比遵循计划更有价值”这一原则体现出来。
测试用例评审
1、同行评审
测试用例的检查方式有很多，同行评审是其中最敏捷的一种。
“个体和交互比过程和工具更有价值”，这强调了测试用例设计者之间的思想碰撞，通过探讨、协作来完成测试用例的设计。
2、用户评审
“顾客的协作比合同谈判更有价值”。
软件缺陷的定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。
软件缺陷的表现形式
- 软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题
-
- 软件未达到需求规格说明书表明的功能
- 软件出现了需求规格说明书指明不会出现的错误
- 软件的功能超出了需求规格说明书指明的范围
- 软件未达到需求规格说明书虽未指明而应该达到的目标
- 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好
- 功能、特性没有实现或部分实现。
- 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
- 产品实际结果和所期望的结果不一致。
- 没有达到需求规格说明书所规定的性能指标等。
- 运行出错，包括运行中断、系统崩溃、界面混乱等。
- 数据不正确、精度不够、不完整或格式不统一。
- 用户不能接受的其他问题，如存取时间过长、界面不美观。
- 硬件或系统软件上存在的其他问题
软件缺陷的根源
交流不充分
- 客户与开发人员、开发人员与测试人员等
软件的复杂性
- 功能复杂、开发复杂、测试复杂
开发人员的错误
- 对需求的理解、开发压力、能力与经验
需求的变化
- 需求说明书、设计文档、程序的变更
进度压力
- 项目周期比较紧
软件缺陷的产生的原因
软件缺陷修复的费用
软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长。
大部分研究都发现，检查比测试的成本更小。
软件缺陷的信息
为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。
软件缺陷分类——缺陷状态
|
编号 |
缺陷状态 |
描述 |
|
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.由于程序所引起的死机，异常退出 2.程序死循环 3.程序错误，不能执行正常工作或重 要功能，使系统崩溃或资源不足 |
不能执行正常工作或重要功能，使系统崩溃或资源不足 |
|
数据缺陷 |
1.数据计算错误 2.数据约束错误 3.数据输入、输出错误 |
严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启不属更正方法） |
|
数据库缺陷 |
1.数据库发生死锁 2.数据库的表、缺省值未加约束条件 3.数据库连接错误 4.数据库中的表有过多的空字段 |
|
|
接口缺陷 |
1.数据通信错误 2.程序接口错误 |
|
|
功能缺陷 |
1.功能无法实现 2.功能实现错误 |
严重地影响系统要求或基本功能的实现，但有合理的办法更正（重新安装或重新启动不属更正方法） |
|
缺陷类型 |
内容说明 |
备注 |
|
安全性缺陷 |
1.用户权限无法实现 2.超时限制错误 3.访问控制错误 4.加密错误 |
|
|
兼容性缺陷 |
与需求规定配置兼容性不符合 |
|
|
性能缺陷 |
1.未达到预期的性能目标 2.性能测试中出错，导致无法继续进行测试 |
|
|
界面缺陷 |
1.操作界面错误 2.打印内容、格式错误 3.删除操作未给出提示 4.长时间操作未给出提示 5.界面不规范 |
操作者不方便或遇到麻烦，但不影响执行工作功能的实现 |
|
建议 |
1.功能建议 2.操作建议 |
建议性的改进要求 |
软件缺陷分类——严重程度
|
严重等级 |
描述 |
|
5-Critical |
系统瘫痪、异常退出、死循环、严重的计算错误等 |
|
4-VeryHigh |
频繁的死机，系统大部分功能不可用 |
|
3-High |
a.功能点没有实现，或不符合用户需求 b.数据丢失 |
|
2-Medium |
a.影响一个相对独立的功能 b.仅仅在特定条件上发生 c.与产品需求定义不一致 d.断断续续的出现问题 |
|
1-Low |
表面性错误（如错别字） |
软件缺陷分类——优先级
|
优先级别 |
描述 |
|
5-Urgent |
最高优先级。在这个错误影响下，系统几乎不可用。 |
|
4-VeryHigh |
高优先级。错误对这套系统的能力产生严重的影响。 |
|
3-High |
中优先级。如果这个错误存在与系统中，会制约开发和测试的活动的进行，如果先前没有修复它，那么需要在发布前修复它。 |
|
2-Medium |
低优先级。不会延迟发布，但是会在以后修正这个错误。 |
|
1-Low |
最低优先级。时间和资源允许时修正。 |
开发人员拒绝修改的缺陷
- 程序员无法重现或者没有明确的重现缺陷的步骤的报告
- 程序员无法读懂的缺陷报告
- 用户很少使用或者不符合用户使用习惯的操作出错
- 由不受信任的测试人员提出
缺陷修改说明
不是所有缺陷都会修改
- 市场的压力使得产品最终发行有时间限制
- 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
- 缺陷报告中提出的问题很难重现
- 错误的修改影响的模块较多，带来的风险较大(遗留)
- 修改的性价比太低