软件测试—测试用例的设计

测试用例是什么？

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

好的测试用例的特征

一个好的测试用例应该具备以下五个特征：

1. 用例表达清除，通俗易懂。
2. 用例可操作性强，易操作性。
3. 用例的输入输出明确，一个用例一个结果。
4. 用例的可维护性强。
5. 用例对需求的覆盖率高。

基于需求对测试用例的设计

第一步是验证需求的可靠性，正确性，逻辑合理性，在正确的基础上细化测试需求。

分析测试需求，一般分为功能测试需求和非功能测试需求。

功能测试需求：

1. 用户功能需求：验证系统是否满足用户的基本需求。

2. 业务功能需求：验证系统是否满足业务功能需求。

3. 数据管理需求：验证系统对数据的管理是否符合要求，包括数据录入，编辑，保存，删除，共享等其他操作的正确性和完整性。

4. 系统性能需求：验证系统在正常情况下的性能表现。

5. 安全性需求：验证系统的安全性是否符合需求。

6. 用户体验需求：验证系统的页面友好型，操作便捷性，交互流畅性，往往与功能测试同时验证。

7. 兼容性需求：验证系统在不同的场景，设备，浏览器等环境下的兼容性，以保证系统可以正常运行和展示。

例如现在对一个奶茶点单小程序做一个简单的功能测试：

当然，读者可以进行扩展，比如用户功能需求可以再加一个留言功能，这样更容易可以看见用户的意见或者建议，有助于发展，在兼容性中也可以加一个不同网络环境的兼容性。

非功能需求测试

1. 性能测试：测试软件在不同压力条件下的性能表现，包括对响应时间，吞吐量、并发用户数等指标。
2. 可靠性测试：测试软件在高负载环境下的稳定性和可靠性，包括系统的容错能力、重启和恢复能力等。
3. 安全性测试：测试系统安全性和防护能力，包括对系统的攻击和用户信息安全。
4. 可用性测试：测试软件的易用性，包括界面的友好性，工作流程的简单性、错误提示的准确性。
5. 兼容性测试：测试系统在不同操作系统、浏览器、设备、网络中的兼容性，确保系统在各种环境中都可以正常运行。
6. 易维护测试：测试软件中的易维护性和可扩展性，包括代码的结构、注释完整、模块的解耦和程度。
7. 可伸缩性测试：测试系统在负载状态和大量并发用户时的性能表现和系统资源利用率。
8. 可靠性测试：测试系统在各种异常情况下的可靠性和稳定性、包括一些系统错误、日志记录等。
9. 容量测试：测试系统在大规模数据和用户量下的性能表现，包括数据库中的数据扩展。

依旧针对奶茶点单小程序写一个非功能测试用例。

这兼容性测试和功能测试是相同的，不过功能测试更加针对于功能展开，而非功能是针对整个程序。

如何设计一个测试用例

一、等价类

等价类设计方法指的是将输入数据可以划分为若干等价类，每个部分的等价类的数据具有相同的特征，对这些等价类进行测试可以覆盖整个输入空间的有效部分。

优点：提高测试效率和覆盖性

对一个登录功能设计一个等价类测试用例设计：

1. 根据登录的输入要求，确定输入的等价类。
   • 比如输入的用户名和密码不能是空字符串，那么可以将输入划分为 空字符串和非空字符串。
2. 对于每个输入的等价类，选择典型的测试用例。
   • 对于用户名的输入、在空字符串等价类中，选择一个空字符串作为测试用例，而非空中选择一个合法的测试用例。
3. 对于每个输入的等价类，执行测试并记录结果。
   • 在登录功能中，当输入空字符串用户名和空字符串密码时是否可以登陆成功。使用非空字符串用户名和密码时是否可以登录成功，并测试登录提示是否正确。
4. 对于异常情况，也应该设置对应的测试用例。
   • 比如，当用户名或者密码长度超过限制，系统应该如何处理这些异常并提示错误信息。

二、边界值法

在测试中，边界值指的是输入数据的最大值和最小值以及临近最大值和最小值的临界值。边界值测试指的是在检测系统在这些临界值附近中可能出现的异常或者错误。

例1：对于输入框中数据长度为1-12设置一个边界值测试。

1. 计算边界值附近数据，1的边界值数据为0、1，12的边界值数据为12、13。得到这组数据的边界值为0、1、12、13.
2. 针对每个测试用例和临界值，执行测试并记录结果。验证字节长度在这4种长度中是否可以正常得到预期结果。主要是针对系统是否可以正常处理这种输入，然后得到正确的结果。比如输入 长度为12 字节的字符串，系统不会出现超出字符串限制长度异常或者字符串为空的异常。

例2：当查询页面数据一共有999条数据时，每50条数据作为一页，在做分页数据后，查询每条数据，设计边界值法。

1. 已知数据存在999条，每50条数据作为一页，向上取整得到页面数为 20。
2. 选择临界值，在这场景下，临界值为 50、51、950、951。50和51对应的是第一页和第二页，950和951对应的是第19页和第20页。
3. 针对每个测试用例和边界值，执行测试并记录结果。验证系统是否可以正常处理边界测试用例和临界值，以及边界情况下的分页逻辑是否正确。例如输入 51 页，系统应该显示的是第二页，而不是其他页数。

三、错误猜测法

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

这个方法看重的是测试工程师对软件的理解和个人经验，是比较看重“第六感”的一种方法。所以很难系统化和过度依赖个人能力。

以注册为例来执行错误猜测法

1. 密码中校验字符的大小写？
2. 姓名中的特殊字符
3. 密码发送到服务器是否明文？

四、场景设计法

以用户场景为基础的测试方法，主要是验证系统在各种现实场景中的功能、性能和可用性。

如何实现一次场景测试法

1. 理解用户需求和使用场景
2. 定义典型的使用场景
3. 设计场景测试用例
4. 执行场景测试用例
5. 观察系统行为和输出结果
6. 记录和分析结果
7. 修复和重复测试

以注册做一次场景分析测试：

可以根据这种场景再次设计场景，比如用户再次注册、用户填写信息相同情况。

五、因果图

是一种通过分析问题的原因和结果之间的关系的方法，通过将问题放在一个地方，尽可能地将原因列出，试图找到真正影响的原因。

它分为四种状态

1. 恒等
   • 如果原因为真，那么结果一定为真
   • 例如：家里前几天请了一个空调安装师傅安装了一个空调，那么家里肯定有一台空调。
2. 与
   • 只有两个或两个以上原因都为真，结果才为真。
   • 例如：她买了一辆车，她买了一栋房，她有车有房。
3. 或
   • 原因中有一个为真，这个结果就为真。
   • 例如：她有一个好闺蜜，她有一个男朋友，她最少有一个人是真心对她的。
4. 非
   • 只有原因为假，结果才为真。
   • 例如：你天天刷剧，也能收到大厂的offer。

四种因果图画法

一般设计因果图步骤分为五步：

1. 分析可能的输入和输出
2. 找出输入输出之间的对应关系
3. 画出因果图
4. 把因果图转换成判定表
5. 把判定表对应到每一个测试用例。

以登录的需求为例，设计一个因果图。要求是将姓名、密码、验证码必须全部输入验证好才可以登录成功。

1. 首先通过分析所有可能的输入输出，可以得到以下结果

   • 输入：用户名、密码、验证码
   • 输出：登录成功、登录失败

2. 第二步，找出输入与输出之间的对应关系

   (1) 用户名输入正确，密码输入正确，验证码输入正确 登陆成功

   (2)用户名输入错误，密码输入正确，验证码输入正确 登陆失败

   (3)用户名输入错误，密码输入错误，验证码输入正确 登陆失败

   (4)用户名输入错误，密码输入正确，验证码输入错误 登陆失败

   (5)用户名输入错误，密码输入错误，验证码输入错误 登陆失败

   (6)用户名输入正确，密码输入错误，验证码输入正确 登陆失败

   (7)用户名输入错误，密码输入错误，验证码输入错误 登陆失败

   (8)用户名输入正确，密码输入正确，验证码输入错误 登陆失败

3. 为了更加方便画出因果图和判定表，需要对所有的输入输出编号。

   1：用户名

   2：密码

   3：验证码

   21：登录成功

   22：登陆失败

4. 画因果图

   

5. 画判定表

   	1	2	3	4	5	6	7	8
   条件1	Y	N	N	N	N	Y	Y	Y
   条件2	Y	Y	N	Y	N	N	N	Y
   条件3	Y	Y	Y	N	N	Y	N	N
   中间结果	Y	N	N	N	N	N	N	N
   失败	N	Y	Y	Y	Y	Y	Y	Y
   成功	Y	N	N	N	N	N	N	N

六、正交排列法

基于正交实验设计理论，通过将测试参数组合成一组正交表，以最小化测试用例数量，实现对系统的全面覆盖。

一般使用正交排列需要考虑以下几点：

因素：在实验中需要考察的变量。

水平：在实验范围内，因素被考察时的取值称为水平。

正交表的构成

行数：正交表的行的个数，意思就是实验的次数

因素数：正交表中列的个数，用C表示

水平数：任何单个数可以取得的单个值的最大个数

正交表设计测试用例的步骤：

1. 计算有那些因素？
2. 每个因素有那些水平？
3. 选择一个合适的正交表。
4. 将变量映射到正交表中。
5. 把每一行的各因素水平组合作为一个测试用例。
6. 加上你认为可疑且没有在表中出现的测试用例组合。

再深入—好的测试用例

更加全面地测试一个系统的所有功能，完善系统的不足之处，利用发散性思维去针对系统的每个功能进行测试，发现缺陷等……

以下是总结后得到的：

1. 完整性：可以覆盖待测系统的所有功能和场景，包括正常情况、边界情况和异常情况。
2. 独立性：每个测试用例应该是独立与其他测试用例的。
3. 可重复性：测试用例应该是可以重复执行的，而且针对每次执行结果是一样的。
4. 易于理解和维护：测试用例应该具有清晰的描述，方便测试人员理解和执行，以应对需求变更和系统更新。
5. 高效性：测试用例的设计尽量简洁明了，能够覆盖重要的功能和风险点，并且能够快速检测可能存在的问题。
6. 特殊情况覆盖：测试用例应该包含一些特殊情况的验证，比如输入边界值，异常处理等，以确保系统的可靠性和稳定性。
7. 回归测试覆盖：测试用例应该覆盖对已经修复的测试功能进行验证的回归测试，以确保修改不会增加新的问题。

设计测试用例的意义

设计一个测试用例可以更高效的发现软件中存在的缺陷，及早修复软件缺陷。通过设计测试用例可以覆盖不同场景和功能，进一步提升软件的质量。测试设计可以帮助测试团队高效地利用有限的资源在有限的时间内获得更加广泛的测试覆盖。