测试用例篇

测试用例的等级是用来表示测试用例的重要性或优先级的。不同的测试用例可能针对不同的功能、模块或场景，根据它们的重要性和业务影响，可以给它们分配不同的等级。常见的测试用例等级包括：

1. P0(Critical)：

一般针对核心功能或关键路径的测试。
如果存在 P0 级别的问题，通常会阻止软件发布。

2. P1(High)：

重要但不是核心功能的测试。
如果存在 P1 级别的问题，可能会推迟软件的发布或需要快速发布修复补丁。

3. P2(Medium)：

普通功能的测试，不会对业务产生重大的影响。
P2 级别的问题通常会在下一个正常的发布周期中得到修复。

4. P3(Low)：

低优先级的功能或很少遇到的场景的测试。
这些问题可能会被列入待办列表，根据资源情况在未来的某个时间点修复。

5. P4(Trivial or Cosmetic)：

针对非功能性或仅仅是外观、样式问题的测试。
这些问题可能不会立即得到修复，但会在后续版本中考虑。

测试用例等级的设定有助于测试团队，开发团队和管理团队确定哪些问题需要首先解决，以及如何分配资源。这也有助于确保关键功能得到适当的关注，而低优先级的问题不会消耗过多资源。

以上就是测试用例等级的概述，你了解了嘛？了解了那可太棒啦！还迷糊的，罚你多看几遍哈哈。

四、测试用例设计八大条件

在我们测试人员进行测试用例设计时通常需要满足的八大条件包括以下几点，但根据实际情况和需求，这些条件可能有所变化或差异：

明确性：测试用例的描述应该简洁、清晰，不给予任何歧义的机会。
可靠性：每次执行测试用例时，都应该获得相同的结果。
有效性：测试用例应该是有效的，即能够验证被测系统的某个特定功能或特性。
独立性：各个测试用例应该是相互独立的，一个测试用例的执行不应依赖于另一个测试用例的结果。
可追溯性：测试用例应能追溯到相关的需求或规格说明书，以确保所有的需求都被测试到。
完整性：测试用例集合应该全面，覆盖所有可能的应用场景、边界条件等。
可重复性：测试用例应该在不同的环境和条件下都能被重复执行。
维护性：随着软件需求和设计的变化，测试用例应该容易被修改或更新。

以上就是常见的八大测试用例设计条件。在实际工作当中，可能还需要根据项目和团队的具体需求来调整或添加其他条件哦~

五、测试用例设计万能公式

诶~上面都是概念呀，还是不知道设计测试用例该从何下手哇，哎呀，莫慌莫慌，记住以下万能公式，不怕关键时刻设计不出傻傻紧张~

万能公式：

功能测试 + 性能测试 + 界面测试 + 兼容性测试 + 易用性测试 + 安全测试

万能公式简解：

功能测试：在日后的工作当中功能测试用例来自于需求文档，而我们面试的时候嘞，功能测试用例来源于生活经验；
性能测试：考虑一些极端情况，如高并发量，响应时间等；
界面测试：工作中的话参考设计图，面试的时候，我们可以对颜色、形状、文字、材质、大小、输入框、图片、下拉框...所有我们可以看到的元素都可进行分析；
兼容性测试：考虑不同的浏览器、不同的版本、不同的系统、不同数据的兼容性；
易用性测试：软件是否具备简单上手的属性；
安全测试：隐私数据是否加密，例如：接口参数是否为明文、数据库对隐私数据是否加密、SQL 注入、用户密码在界面是否隐藏展示、越权（水平越权：你访问到了你同事的隐私信息；垂直越权：你访问到了你上级的隐私信息）。

栗子：

诶嘿，说这么多给大家举个示例：下面是针对好游快爆 APP 里的贴子发布 + 草稿箱交互功能的测试用例（个人初学时做的哈，欢迎提出问题~）：

到这里啊，又有问题来咯，有时候测试范围还是蛮大的，那我们该如何下手呢？这时候，就得我们设计测试用例的具体方法“隆重登场”了，一起来看！

六、测试用例设计的具体方法

1. 等价类划分法

该方法简单来说就是分块 / 分区检测，从每一个区块选择一个进行测试，以代表这个区块的结果，这个所说的区块就是等价类，该方法可以用较少的测试用例达到尽可能多的功能覆盖，解决不能穷举测试的问题。等价类分为两种：有效等价类和无效等价类。

有效等价类：对于需求文档有意义的集合

无效等价类：对于需求文档无意义的集合

具体我们可以通过一个栗子来理解：测试用户密码为 6 ~ 18 位

有效等价类：6 ~ 18 位

无效等价类：小于 6 位，大于 18 位

测试用例：

输入长度为 6 ~ 18 位的密码，假设是 9 位
输入长度小于 6 位的密码，假设是 5 位
输入长度大于 18 位的密码，假设是 21 位

2. 边界值法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

边界值指的是有效边界 + 无效边界

还是上面的栗子：测试用户密码为 6 ~ 18 位

有效边界：6、18

无效边界：5、19

如果还是不太理解，可以看下图：

3. 判定表法

判定表是因果图的另一种形式，判定表法和因果图画法的步骤差不多（后者就是多了个“画因果图”，这个一般人画不出来< 二班人除外哈 > ，也没有什么明确的画法），这里我们学习判定表法，它一般用于输入条件的组合对应不同的结果。

判定表法设计测试用例的步骤：

明确输入条件和输出条件
找出输入条件和输出条件之间的关系
画判定表
根据判定表编写测试用例

栗子：

双十一或其他购物节（悄悄问一句：大家抢到优惠了嘛哈哈），当订单使用红包或者订单金额大于 300 ，则该订单就是优惠订单，否则就为不优惠订单。

a. 明确输入条件和输出条件：

输入条件：红包（A）、金额大于 300 （B）、订单已提交（C）；

输出条件：有优惠（1）、无优惠（2）.

（括号里为它们各自编号，便于进行后续步骤）

b. 找出输入条件和输出条件之间的关系：

确定输入输出之间所有可能的组合关系，最后根据组合（编号）给出对应的结果，如下：

c. 画判定表：

d. 根据判定表编写测试用例：

有红包，订单金额小于 300 元，不提交订单，则该订单为无优惠订单；
无红包，订单金额大于 300 元，不提交订单，则该订单为无优惠订单；
无红包，订单金额小于 300 元，提交订单，则该订单为无优惠订单；
有红包，订单金额小于 300 元，提交订单，则该订单为有优惠订单；
无红包，订单金额大于 300 元，提交订单，则该订单为有优惠订单；
有红包，订单金额大于 300 元，提交订单，则该订单为有优惠订单；
有红包，订单金额大于 300 元，不提交订单，则该订单为无优惠订单；
无红包，订单金额小于 300 元，不提交订单，则该订单为无优惠订单。

4. 场景设计法

场景设计法可以比较生动地描绘出事件触发时的情景，有利于测试设计者进行测试用例的设计，使得测试用例更容易被理解和引导。该方法将事件分为基本事件流和备选事件流。

基本事件流：原本按计划要进行的事情

备选事件流：一些意外情况

栗子：银行 ATM 机取钱

编写测试用例：

基本事件流：插卡，输入正确的密码，选择取款功能，输入金额，取钞，退卡；

备选事件流：

插卡，卡被卡住插不进去；
插卡，输入密码，密码错误，...，退卡；
插卡，输入密码，密码正确，选择的不是取款，...，退卡；
......

5. 错误猜测法

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

该方法主要依赖测试人员的工作经验和积累，它的缺点就是难以系统化，并且过度依赖测试人员的个人能力。

比如对登录功能进行测试，一般就是：密码是否隐藏加密、密码是否以明文进行传输、考虑 SQL 注入的问题......

6. 正交法（很少用）

正交法就是指从大量的实验中挑选出适量的、有代表性的点，依据“正交表”进行合理的测试用例设计。

正交表的特性：

每一列中，不同的数字出现次数相等；
任意两列中数字的排列方式齐全而且均衡。

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

找出因素和水平；
生成正交表；
根据正交表来编写测试用例；
补充可能存在遗漏但是非常重要的测试用例。

栗子：测试下面的这个注册页面：

第一步，找出因素和水平

因素：用户名、密码、确认密码、验证码；

水平：填写、不填写。

第二步，使用 allparis 生成正交表

生成步骤：

1. 将因素和水平写入 Excel

2. 在 allparis 同级目录下创建一个新的 txt 文件，复制刚刚 Excel 表中所写的信息，粘贴到你创建的 .txt 文件中，保存

3. 在 cmd 中使用 allparis 工具生成正交表

其中 kaiyuanxi.txt 为咱们自己创建的 txt 文件；kaiyuanxitf.txt 为要生成的正交表文件

4. 在目录中可以看到刚刚生成的正交表