【测试开发】用例篇（1）

文章目录

• 【测试开发】用例篇（1）
• • 1. 测试用例的基本要素
  • 2. 测试用例的设计方法
  • • 2.1 基于需求的设计方法（设计测试点）
    • 2.2 等价类划分法（测试点=>测试用例）
    • • 2.2.1 测试中的等价类思想
      • 2.2.2 有效等价类与无效等价类
      • 2.2.3 等价类思想设计测试用例步骤
    • 2.3 边界值法
    • • 2.3.1 边界点
      • 2.3.2 边界值思想设计测试用例步骤
    • 2.4 判定表法
    • • 2.4.1 判定表表达逻辑判定
      • 2.4.2 判定表思想设计测试用例步骤

【测试开发】用例篇（1）

1. 测试用例的基本要素

四个重要的要素：

1. 测试环境
2. 操作步骤
   • 不需要给出执行结果，因为用例在写的时候，咋知道结果？应该是与预期结果进行比较~
3. 测试数据
4. 预期结果

测试用例：

1. 高效，避免重复测试，节约测试时间
2. 测试用例是自动化测试的前提！

博文链接：【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_s:103的博客-CSDN博客

---

2. 测试用例的设计方法

本文所讲都是基于黑盒测试的！

网络说明：

黑盒测试是一种软件测试方法，它着重于测试软件的功能而不考虑其内部实现细节。在黑盒测试中，测试人员将软件视为一个黑盒子，只观察输入和输出，而不了解内部的代码逻辑和结构。

黑盒测试的目的是验证软件是否按照规格说明书或用户需求正常工作，以及检测是否存在功能上的错误或缺陷。测试人员根据输入的有效和无效数据，测试软件的各种功能，包括界面、用户交互、数据处理等。通过观察输出结果和与预期结果比对，可以确定软件是否符合预期行为。

与白盒测试相比，黑盒测试更注重从用户的角度出发，关注软件的功能和用户体验。它可以帮助发现潜在的问题和改进空间，提高软件质量和可靠性。

2.1 基于需求的设计方法（设计测试点）

测试人员：

• 要看懂需求文档，QA要梳理需求、掌握需求，针对这个文档设计测试用例
  • 这就是基于需求的设计方法

如何基于需求进行测试用例设计：

以一个功能需求为例：微信发红包，金额限制200，时间限制24h

• 那我们就以此功能为测试点：
  1. 金额为200块能否发送成功
  2. 超过200块能不能发送成功
  3. 24h后能否领取
  4. …

在以注册功能为例，这次画图分析：

1. 对测试点进行多级分类
   • 一定要先分类，先搭框架！否则你写的测试用例再全面也是乱的，不堪入目的~

万能公式：

2. 头脑风暴式的列举测试点：

3. 按照要求设计测试用例（补充测试要素）
   • 通过测试点设计出来即可

补充说明测试点和测试用例的区别：

1. 定义：测试点是测试过程中需要覆盖的功能、需求或情况，它是一个较宽泛的概念；而测试用例是对于一个具体的测试点的具体测试场景或操作序列的描述，是测试点的具体实现。

2. 抽象性：测试点更加抽象和高层次，它可能代表一个功能模块、一个需求、一种交互场景等；测试用例更具体和详细，它描述了具体的测试输入、预期输出和执行步骤。

3. 覆盖范围：测试点通常是一个大的分类或集合，它可以包含多个测试用例；而测试用例是具体的测试实例，每个测试用例都是独立的，用于覆盖测试点的不同方面或情况。

4. 可执行性：测试点本身不一定可执行，而测试用例是可执行的，可以直接用于执行测试，验证软件功能或需求的正确性。

测试点和测试用例在软件测试过程中是相互关联的，测试用例是为了覆盖和测试测试点而存在的。

在测试计划和设计阶段，首先确定要测试的测试点，然后为每个测试点设计相应的测试用例来验证软件的正确性和可靠性。

基于需求的设计方法，可以设计出大概的测试点，但通过测试点怎么设计测试用例，还需要其他方法

• 我们这一顿瞎列举，需求之外的用例不一定测得到，比如说发送0.00001可不可以发送成功…

• 而当看需求，我们要测的用例很多，例如测200，300，400，500…我们要测那么多，用例是无穷无尽的，测试用例太多，成本花销也大

我们应该用更有科学依据的方法，筛选和设计出科学全面的测试用例，且避免缺漏

2.2 等价类划分法（测试点=>测试用例）

例如图书馆的书籍分类：

1. 历史
2. 数学
3. 人文
4. 政治
5. 经济
6. …

而等价类的核心就是“分类”，一类东西就有共同的特性

2.2.1 测试中的等价类思想

概念：

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类

从等价类中选出一个测试用例

如果这个测试用例测试通过，则认为所代表的等价类测试通过

这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

举个例子：你和你的对象去逛街，TA渴了，想要和奶茶

---

你要帮TA试一口：搅拌搅拌在5分位处吸一口（测试其中一口），这一口好吃=>代表这一杯好吃=>给对象吃，不需要整杯都喝完（测试完）才推出好喝与否的结论！

2.2.2 有效等价类与无效等价类

有效等价类：

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

• 也就是一些常规正常的输入集合（例如红包0-200内的正常金额，再例如发送的请求数据合理）

无效等价类：

• 根据需求说明书，不满足输入需求的集合。
• 也就是一些非法不正常的输入集合（例如红包的0.0001和300的非正常金额，再例如发送的请求数据非法极端）

练习：

需求案例：用户名输入

1. 必填
2. 长度6-15
3. 字符类型A-Z，不区分大小写

有效等价类：非NULL，并且非空字符串，并且长度大于等于6，并且小于等于15，并且只含字母的字符串

无效等价类：为NULL，或者为空字符串，或者长度小于等于6，或者长度大于等于15，或者字符串中存在字母外的其他字符串…

2.2.3 等价类思想设计测试用例步骤

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

就以刚才的练习为例，针对长度这个测试点进行设计测试用例（补充测试要素）：

2.3 边界值法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充

说到底就是有效输入和无效输入的边界（等价类的边界），临界值作为测试用例！

• 在我们的程序开发的学习过程中，我们应该不少发生边界异常的情况，比如说用户长度限制6-15，
  • 其中1-5、7-14、16~∞，都没问题，但是代码在边界处理的时候出现了问题，导致6和15出现了问题…

2.3.1 边界点

1. 上点：边界上的点
2. 内点：边界内的点
3. 离点：边界值附近的一个点（闭区间区间外距离上点最近的点；开区间区间内距离上点最近的点）
   • 不需要了解为什么这样，有点科学的规矩罢了

例如以下例子：

1. 闭区间[6，15]

上点：6，15

内点：10（取其一）

离点：5，16

2. 半开半闭区间(6，15]

上点：6，15

内点：10（取其一）

离点：7，16

2.3.2 边界值思想设计测试用例步骤

1. 充分理解需求
2. 找边界点
3. 针对边界点设计测试用例

就以刚才的练习为例，针对长度这个测试点进行设计测试用例（补充测试要素）：

等价类划分出来的测试用例，和边界值设计出来的测试用例结合在一起，就更加全面了！

2.4 判定表法

判定表是由因果图转化而来的，因果图没啥用，直接判定表就好了~

概念：

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

2.4.1 判定表表达逻辑判定

也就是表达条件与条件，条件与结果之间的“关系”：

1. 与，条件都为真，结果才为真
2. 或，条件都为假，结果才为假
3. 恒等，条件为真，结果为真
4. 非，条件为假，结果为真

通过这个判定表，描述多个测试变量的变化与结果的关系，也就是黑盒测试输入输出之间的关系！

2.4.2 判定表思想设计测试用例步骤

1. 充分理解需求
2. 分析所有可能的输入和可能的输出
3. 找出输入与输出之间的关系
4. 设计判定表
5. 把判定表对应到每一个测试用例

以淘宝618活动为例：

分析输入输出集合

• 测试变量：
  1. 订单是否提交
  2. 订单合计金额是否大于300
  3. 有没有红包
• 规则：
  • 订单提交的情况下，订单合计金额大于300或者有红包，就有优惠
• 输入：
  • 订单是否提交，订单金额释放大于300，是否有红包
• 输出：
  • 优惠/不优惠

找出输入输出之间的关系

1. 订单已提交，(金额大于300，有红包) => 优惠
2. 订单已提交，(金额大于300，无红包) => 优惠
3. 订单已提交，(金额小于300，有红包) => 优惠
4. 订单已提交，(金额小于300，无红包) => 不优惠
5. 订单未提交，(金额大于300，有红包) => 不优惠
6. 订单未提交，(金额大于300，无红包) => 不优惠
7. 订单未提交，(金额小于300，有红包) => 不优惠
8. 订单未提交，(金额小于300，无红包) => 不优惠

设计判定表

把判定表对应到每一个测试用例

或者这样：

面试时，对测试开发岗位的应聘者，可能会问点高中排列组合的问题，因为有时候会用到吧，但是我们按常规的方式去设计就行了，不要可以它是什么“排列组合”、等等巴拉巴拉的…

为什么我们在一开始写的这个输入输出关系和最终的测试用例不是一样的吗？

网络资料：

在软件测试中，

1. 输入输出关系是指测试用例中输入数据与预期输出之间的关系。
2. 测试用例通过提供不同的输入数据，验证软件在不同情况下的输出是否符合预期。

尽管测试用例已经描述了输入和输出关系，但在某些情况下，测试用例可能会变得非常多和复杂，特别是当有多个输入变量和多个预期输出的组合时。这时，为了更好地管理和组织测试用例，可以使用判定表来辅助测试用例的编写和管理。

判定表是一种表格，用于描述输入条件和对应的输出结果之间的关系。它可以帮助测试人员系统性地识别和列举不同的输入组合，以及预期输出的结果。

• 通过使用判定表，可以减少测试用例的数量，同时保证覆盖了所有可能情况，从而提高测试效率。

• 并且方便后期继续添加/补充/修改测试点、测试要素、测试变量、条件…，能生成的测试用例也因此变化~

  • 甚至可以用AI将判定表转化为测试用例，不过生成的测试用例还要检测一遍哦

• 更严谨，提高效率，减少错误率（让表格按照公式计算复杂逻辑）

所以，判定表的编写和使用可以带来以下好处：

1. 优化测试用例设计：判定表可以帮助发现输入条件的组合情况，使得测试用例设计更全面和高效。

2. 提高测试覆盖率：通过判定表，测试人员可以确保测试用例覆盖了所有输入条件的组合情况，从而提高测试覆盖率。

3. 简化测试维护：使用判定表可以降低测试用例数量，减少了测试维护的复杂性和工作量。

总之

• 判定表在软件测试中的作用是辅助测试用例的编写和管理，帮助测试人员全面而高效地覆盖输入输出关系。它是一种组织测试用例的有效工具，提高了测试效率和质量。

---

文章到此结束！谢谢观看
可以叫我 小马，我可能写的不好或者有错误，但是一起加油鸭🦆！

我们应该根据具体情况打出组合拳，才能设计出好的测试用例！

---