【软件测试从0到1】第三篇：用例篇

目录

一、测试用例的基本要素

二、测试用例的设计方法

三、具体的设计方法

3.1 等价类

3.2 边界值

3.3 判定表法

3.4 正交法

3.5 场景设计法

3.6 错误猜测法 

---

一、测试用例的基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
评价测试用例的标准：对比好坏用例的评价标准

• 用例表达清楚，无二义性。
• 用例可操作性强。
• 用例的输入与输出明确。一条用例只有一个预期结果。
• 用例的可维护性好。
• 用例对需求的覆盖率高。

测试用例的给我们带来的好处
测试执行者的依据
使得工作可重复，自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴

• 使用中带来困扰

测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多

不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率
 

二、测试用例的设计方法
 

基于需求进行测试用例的设计

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；
 

重要：

万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试

万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试

问：测试用例是越多越好吗？

不是的！测试用例能够提高系统测试覆盖率就是好的测试用例！

但是在面试中能够说出来越多的测试用例肯定是好的！

下面对一个水杯进行测试：

 对注册界面进行测试：

三、具体的设计方法
 

3.1 等价类
 

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合。

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

1.1.1.1.5 处理
1.1.1.1.5.1 基本事件流
1、 用户选择注册；
2、 系统展现用户协议界面，并请用户确认是否同意用户协议
1) 若用户不同意协议，系统禁止用户注册。
2) 若用户同意协议，用户进行注册信息填写。
3、 用户填写注册信息。
注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。
4、 用户提交注册信息；
5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、 用户可执行激活操作，直接跳转至注册邮箱门户页面。
7、 用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。

1.1.1.1.5.2 扩展事件流
1. 用户注册并激活成功后，第一次登录平台时，提示用户完善信息；

1.1.1.1.5.3 异常事件流
1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。

1.1.1.1.6 输出
用户注册成功

1.1.1.1.7 后置条件
该模块为用户登陆等的前置模块

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
 

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合。

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

3.2 边界值
 

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

3.3 判定表法

判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来；其缺点是判定表的建立过程较烦杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用

判定表设计测试用例：

1. 确认输入条件和输出条件。
2. 找出输入条件和输出条件直接的关系
3. 画判定表
4. 根据判定表编写测试用例

需求：订单已提交，订单合计金额大于300元或则订单中有红包，则认为该订单是属于有优惠的订单，否则是没有优惠的订单。

适用场景：针对不同的输入条件之间的组合对应不同的输出结果。

你的设计测试用例的方法为什么是判定表法而不是因果图法：

我人为根据因果图画判定表是有点多余，因果图实际上在设计测试用例的时候没有多大意义。

因果图法是根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。

设计因果图的步骤 

1. 分析程序的规格说明书中哪些是原因，哪些是结果。所谓原因，是指输入条件或输入条件的等价类，而结果是指输出条件。给每一个原因和结果赋一个标识符。
2. 分析程序规格说明书中的语义，确定原因与原因，原因与结果之间的关系，画出因果图。
3. 由于语法环境的限制，一些原因与原因之间，原因与结果之间的组合不能出现。对于这些特殊情况，在因果图中用一些记号标明约束或限制条件。
4. 将因果图转化为判定表。
5. 根据判定表的每一列设计测试用例。

当然，若能直接得到判定表，可以直接根据判定表设计测试用例。

3.4 正交法

正交实验法是研究多因素多水平的一种设计方法，它依据 Galois理论从全面实验中挑选出部分具有代表性的水平组合进行实验，并对结果进行分析从而找出最优的水平组合。

当析因设计要求的实验次数太多时，一个非常自然的想法就是从析因设计的水平组合中，选择一部分有代表性水平组合进行实验。因此就出现了分式析因设计(fractional factorial designs)，但是对于实验设计知识较少的实际工作者来说，选择适当的分式析因设计还是比较困难的。 例如作一个三因素三水平的实验，按全面实验要求，须进行3^3=27种组合的实验，且尚未考虑每一组合的重复数。若按L9(3^4)正交表安排实验，只需作9次，按L15(3^7)正交表进行15次实验，显然大大减少了工作量。因而正交实验设计在很多领域的研究中已经得到广泛应用。

因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成：
行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。
因素数(Factors)：输入的条件，用C表示
水平数(Levels)：输入条件对应的结果。不是输出条件。用T表示
正交表的表示形式： L=行数(水平数*因素数) L=N(TC)
正交表的两条性质：
每一列中各数字出现的次数都一样多。
任何两列中的各有序数对出现的次数都一样多

正交分解步骤：

1. 找到因素数和水平数
2. 用allParis工具来生成正交表
3. 根据正交表来设计测试用例
4. 补充测试用例

需求：用户注册信息填写，姓名，电子邮箱，密码，确认密码，验证码

1. 找到因素数和水平数

2. 用allParis工具来生成正交表 

3.  根据正交表来设计测试用例

4. 补充测试用例

3.5 场景设计法
 

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

案例：
以注册为例


 

 想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：

1、用户激活后再次点击邮件激活链接？
2、已注册用户再次注册？

 主要分为基本事件流和多个备用事件流

3.6 错误猜测法

 

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。

这个方法的缺点是难以系统化，并且过度依赖个人能力