测试|测试用例方法篇

测试|测试用例方法篇

1.测试用例的基本要素：测试环境，操作步骤，测试数据，预期结果…

注：这里是预期结果而非执行结果

2.测试用例带来的好处

一方面可以提高测试的效率，节省测试时间
另一方面测试用例是自动化测试用例的前提

3.测试用例的设计思路，设计方法，具体设计方法之间的关系

设计测试用例工作展开流程/设计思路（基于需求的测试用例设计）

​ 1.查看需求文档 2.梳理需求 3.根据文档针对需求设计用例
​ 然而，需求又可以分为两大类：功能性需求，非功能性需求
​ 其中功能性需求分为

1. 各功能单独测试（有业务限制）
2. 功能的交互（根据业务连）
3. 功能一致性
4. 功能的错误操作
5. 用户体验，操作的易用性

具体工作时可以根据功能模块划分和业务模块划分用户操作区域将功能模块划分，进行测试

非功能性需求分为：性能，安全性，可靠性，兼容性，易维护性，可移植性。每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，
就越有可能给易用性，性能带来更大的挑战

注：对于每个应用软件系统，非功能特性的质量需求都是存在的，但不同项目对各个非功能要求不同。
1.纯客户端（不能发）如word电脑自带播放器等，功能测试要求低，但兼容性稳定性可移植性要求高
2.客户端/服务端如qq等要求功能正确，稳定性能好，对性能安全兼容要求不高
3.大型复杂网络应用系如银行对功能性能安全兼容容错可靠性都有很高要求

4.具体设计方法

具体设计而言，头脑风暴法==》具体的设计方法

1.等价类法

依据需求，将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决不能穷举的问题。
在等价类思想中，我们一般将我们一般将输入域划分为有效等价类和无效等价类两个集合，其中有效等价类是满足用户需求的输入，集合无效等价类，是不满足用户需求的输入集合。
设计步骤：

1. 充分理解需求
2. 划分有效等价类和无效等价类
3. 从有效等价类抽取其中一个数据进行设计测试用例，从无效等价类中抽取其中一个进行测试用例设计

2.边界值法（补充）

通常边界值分析法是对等价类划分法的补充，这种情况下，测试用例来自等价类的边界。
这种情况下设计步骤就是

1. 充分理解需求
2. 找出边界点
3. 针对边界点设计测试用例
   其中上点是边界上的点，内点是边界内的点，离点是边界值附近的一个点，闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点

3.判定表法

（一种表示逻辑判断的工具，和因果图起到的作用是一致的，因为因果图最后还是要转换成判定表所以这里我就直接理解成判定表法了）
设计步骤：

1. 分析所有可能的输入和可能的输出
2. 找出输入与输出之间的对应关系
3. 设计判定表（用表格表示出来）
4. 将判定表对应到每一个测试用例（对应表格用思维导图表示出来）

注：我们这里列的是测试点，但要求高的，需要写针对测试点补充测试要素

4.正交表法

（我的理解就是一般情况下的判定表法，因为输入输出比较多的时候，我们使用判定表法可能会耗费很多时间，这个时候使用正交表法就比较合适）
两个非常重要的概念：因素和水平

因素：输入变量。

水平：每个输入变量的取值。

两条性质：

1.每一列中每个数字出现的次数一样多

2.任何两列中有序数对出现的次数都一样多。
设计步骤

1. 充分理解需求
2. 确定因素和水平
3. 画正交表
4. 补充正交表
5. 将正交表转化成测试用例
   这里在画正交表时一般借助allpairs工具，使用方法：
   1. 将因素和水平放到表格中，
   2. 将这个表格直接复制到txt文本中
   3. cmd进入allpairs安装路径下，输入文件名就会生成对应的正交
   4. 将对应的case转化成测试用例

5.场景设计法

其实就是在具体的业务场景下，根据事件流进行设计用例，其中事件流是同一事件不同触发顺序和处理结果形成的。
设计步骤：

1. 充分理解需求
2. 确定主事件流
3. 确定次事件流
4. 每一个事件流就是一个测试用例

6.错误猜测法

依靠测试人员经验的设计方法

设计实例

等价类法

边界值法

判定表法

正交表

这就是最后生成的正交表，其中~代表可以填写可以不填写。

因此最终可以生成8个测试点

场景设计法

错误猜测法

只能依靠测试人员的经验。