软件测试方法（满满干货吐血整理）

软件测试方法

 

 

软件测试系列文章目录

天行健：软件测试基础理论知识(一)

天行健：软件测试基础理论(二)

天行健：软件测试之软件测试分类

天行健：测试用例书写分类

本篇开始

1. 正交排列法

正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率。当可能的输入数据或者输出数据的组合数量很大时，由于不可能为每个输入组合都创建测试用例，可以采用这种方法。

1.1 正交排列表的重要概念

正交实验设计是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。

1.2 正交表

一种特制的表，一般的正交表记为：

• 其中, l表示行数「line」
• n是表的行数，也就是需要测试组合的次数 -> 这个n值需要查表啦.
• K是表的列数，表示控件的个数（因素的个数，或因子个数）
• m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）

示例:

1. 有4个控件
2. 每个控制有3个取值
3. 9为需要测试组合个数 -> 查表查出来的.

称为4因素3水平

1.3 查找正交表

查找正交表

1.4 正交排列表的使用步骤

• 根据所测程序中控件的个数（因素）以及每个控件的取值个数（水平），选取一个合适的正交排列表
• 把控件及其取值列举出来，并对其进行编号
• 把控件及其取值映射到正交排列表中
• 把正交排列表中的ABCD（因子）分别替换成4个控件
• 把每列中的1,2,3（状态）分别换成这个控件的3个取值（水平），排列顺序要按照表中给出的顺序
• 根据映射好的正交排列表编写测试用例

1.5 使用正交排列法的局限性

• 目前常见的正交排列表只有前面附录文件中给出的几种
• 即使是已有的正交排列表，基本都要求每个控件中取值的个数要相等，这在实际软件中很少遇到。

2. 混合正交表

• 水平数不同
  • 因素（变量）的水平数（变量的取值）不相同
• 找不到现成的正交表，就只能使用工具来生成！

2. 1 正交表生成工具「allpairs」

• 很多情况下无法找到合适的正交表，就要使用正交表生成工具
• 使用步骤
  • 制作取值表（只列出数据即可，不用编号）
  • 复制取值表的数据，放到文本文档中保存（注意不要更改任何格式，例如文件叫Test2.txt）
  • 把文本文档放在allpairs文件夹中
  • win+r后输入cmd进入控制台
  • 使用控制台代码进入allpairs文件夹（cd 目录名字）
  • 在控制台中输入allpairs.exe Test2.txt > chenggong.txt （ chenggong是自己起的名字，用来存放生成的组合用例，可以自动生成，不必提前建好

3. 正交表总结

• 如何确定m和k值.
  • 因子/因素, 水平.
  • 因子/因素 -> 控件数量
  • 水平: 每一个控制所选的值
  • ln (m k)
    • n通过正交表可以查出来
    • m -> 控制取值 -> 水平
    • k -> 控制个数 -> 因素/因子
    • k因素m水平.
• 如果说我们查询正交表的时候没有匹配的项,则要找到行数最少的那一个.因子/因素多的那一个.
• 正交排列表生成测试用例步骤
• 混合正交表
  • 通过工具自动生成.
  • 操作步骤
    • 注意点
      • 数值表,一定不要有序号.
      • txt里信息不要修改格式,否则不能正确的生成混合正交表.

4. 测试方法的选择

• 等价类划分
• 边界值
• 因果图
• 判定表
• 场景
• 流程分析法
• 错误推断
• 正交表
  • 混合正交表

5. 遵守原则

• 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点
• 认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误。因为一次完整的软件测试过后，如果程序中遗留的错误过多并且严重，则表明该次测试是不足的，而测试不足则意味着让用户承担隐藏错误带来的危险，但测试过度又会带来资源的浪费。因此测试需要找到一个平衡点。
• 参考原则
  • 拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法。
  • 需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试。
  • 在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。
  • 如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图和判定表法。
  • 对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试用例获得最大的的测试覆盖率）。
  • 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例
  • 采用错误推断法再追加测试用例——依靠测试工程师的经验和智慧

6. 测试用例的力度

• 测试用例可以写的很简单，也可以写的很复杂。
  • 最简单的测试用例是测试的纲要，仅仅指出要测试的内容。
• 测试用例写的过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是需要把测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已
• 最复杂的测试用例则会指定输入的每项数据，期待的结果即检验方法，具体到界面元素的操作步骤，指定测试的方法和工具等。
  • 测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

7. 测试用例的本质

测试用例的设计本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

• 基于需求的测试用例设计
  • 基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
  • 要把测试用例当成活的文档，因为需求是活的，善变的。因此在设计测试用例方面应该要把敏捷方法的“及时响应变更比遵循计划更有价值”这一原则体现出来。
  • 不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例。

8. 总结

书写测试用例的方法及原则的介绍.