如何设计出一个比较全面的测试用例
目录
1. 测试用例的基本要素(不需要执行结果)
测试环境 -> 操作步骤 -> 测试数据 -> 预期结果
2. 测试用例的给我们带来的好处
1) 提高测试效率，节省测试时间
2) 测试用例是自动化测试的前提
3) 积累测试的方法思路以供后续借鉴
3. 用例编写步骤
拿到测试需求 -> 分析需求（画思维导图） -> 确定测试范围，划分用例优先级 -> 编写用例
4. 设计测试用例的方法
4.1 基于需求进行测试用例的设计
在基于需求进行测试用例设计时，我们需要从功能需求和非功能需求两个方面进行分析。以下是详细的步骤：
1. 功能需求测试分析--参考标准：需求文档
-
明确测试目标：首先，需要明确测试的目标，即确保软件的功能实现与需求文档中的描述一致。
-
识别关键功能点：从需求文档中提取出关键的功能点，这些功能点是用户最关心的，也是最容易出错的地方。
-
设计测试场景：针对每个关键功能点，设计相应的测试场景。测试场景应尽可能覆盖所有可能的使用情况，包括正常情况、异常情况和边界条件。
-
编写测试用例：根据测试场景，编写详细的测试用例。测试用例应包含明确的前置条件、操作步骤、预期结果和实际结果等信息。
2. 非功能需求测试分析--参考标准：需求文档
-
性能测试：评估系统的性能指标，如响应时间、吞吐量和资源利用率等。设计测试用例来模拟不同的负载情况，以验证系统在高负载下的稳定性和性能表现。
-
安全性测试：检查系统的安全性措施是否有效，如身份验证、访问控制和数据加密等。设计测试用例来尝试攻击系统，以发现潜在的安全漏洞。
-
兼容性测试：验证系统在不同平台、浏览器或设备上的兼容性。设计测试用例来测试系统在各种环境下的表现，以确保其能够在不同环境中正常运行。
-
可用性测试：评估系统的易用性和用户体验。通过用户调查、问卷调查或用户测试等方式，收集用户反馈，以改进系统的设计和交互方式。
3. 总结
在基于需求进行测试用例设计时，我们需要从功能需求和非功能需求两个方面进行全面的分析。通过明确测试目标、识别关键功能点、设计测试场景和编写测试用例等步骤，可以确保软件的质量满足需求文档中的要求。同时，我们还需要关注系统的性能、安全性、兼容性和可用性等方面，以提供更好的用户体验和保障系统的稳定性。
4.2 具体的设计方法
1.等价类
概念：
将所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入）,测试的时候，然后从每一个类别中选取少数具有代表性的数据作为测试用例，如果测试通过，即代表这一类测试通过。
有效等价类：满足用户需求的一个数据集合
无效等价类：不满足用户需求的数据集合
设计测试用例的流程:
充分理解需求 -> 将需求分类（有效等价类，无效等价类）-> 针对有效等价类和无效等价类设计测试用例
举例:
比如说，如果你要测试一个输入年龄的字段，你可以分成几组：小于0的年龄、0到100之间的年龄、大于100的年龄。然后，从每组中选一个典型的数字来测试，比如-1、50、101。这样就可以覆盖大部分情况了。
2.边界值
概念：
边界值分析法就是测试输入或输出的边界值的一种黑盒测试方法。因为程序在边界值的地方最容易出问题，所以我们专门测试这些边界值。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
这里还涉及到三个概念:
上点：边界上的点就是上点（不管范围是开区间还是闭区间）
内点：边界内的点（不管范围是开区间还是闭区间）
离点：如果区间是开区间，区间内最靠近上点的点
如果是闭区间，区间外最靠近上点的点
举例:
上点：50，55
内点：51，52，53，54，55
离点：51 56
3.判定表（因果图）
概念:
是一种用于描述复杂逻辑决策规则的技术，常用于需求分析阶段来定义业务规则，并在测试阶段用来设计测试用例。
简单而言，判定表其实就是一个表格，它帮助我们清晰地列出所有可能的情况和对应的处理结果。
设计测试用例的流程:
(1）分析所有可能的输入和可能的输出
(2) 找出输入与输出之间的对应关系
(3) 设计判定表
(4) 把判定表对应到每一个测试用例
举例:
1. 分析所有可能的输入和可能的输出--条件可能是来自用户界面的输入数据，或者是系统内部的状态变化等
假设我们有一个简单的登录系统，其输入条件为用户名和密码，输出结果为登录成功或失败。
输入条件：
用户名（Username）
密码（Password）
输出结果：
登录成功（Login Success）
登录失败（Login Failed）
2. 找出输入与输出之间的对应关系
接下来，确定输入条件与输出结果之间的关系。这些关系通常由逻辑运算符（如与、或、非等）来表达。
对于登录系统，我们可以有以下几种情况：
用户名正确且密码正确 -> 登录成功
用户名正确且密码错误 -> 登录失败
用户名不存在 -> 登录失败
密码为空 -> 登录失败
3. 设计判定表
根据上述关系，构建一个判定表。判定表包含一系列的条件组合以及对应的动作。
| 动作\条件 | C1:用户名正确 | C2:密码正确 | C3:用户名存在 | C4:密码非空 |
| A1 | 是 | 是 | 是 | 是 |
| A2 | 是 | 否 | 是 | 是 |
| A3 | 否 | - | 否 | - |
| A4 | - | - | 是 | 否 |
4. 把判定表对应到每一个测试用例
测试用例1（对应A1）:
输入：正确的用户名和密码。
预期结果：登录成功。
测试用例2（对应A2）:
输入：正确的用户名，错误的密码。
预期结果：登录失败。
测试用例3（对应A3）:
输入：不存在的用户名。
预期结果：登录失败。
测试用例4（对应A4）:
输入：密码为空。
预期结果：登录失败。
通过这样的方法，我们可以确保所有的输入组合都被考虑到，并且每个可能的结果都有对应的测试用例来验证。这样可以帮助我们发现潜在的问题并提高软件的质量。
4.正交表法
概念:
是一种系统化的测试用例设计方法，主要用于减少测试用例的数量，同时保证较高的覆盖率。这种方法特别适用于那些具有多个输入参数和多种可能的参数组合的情况。
设计测试用例的流程:
充分理解需求 -> 确定因素水平 -> 画正交表 -> 补充正交表 -> 将正交表转换成测试用例
举例:
1. 充分理解需求
首先，你需要彻底理解软件的功能需求和非功能需求。这一步是为了确保你知道要测试哪些方面。
2. 确定因素和水平
接下来，识别出所有影响系统行为的因素（即变量），并确定每个因素可能的水平（即变量取值）。
例如，在一个在线购物系统中，因素可能包括支付方式、商品种类、用户类型等，而水平则包括具体的支付选项（信用卡、支付宝）、商品种类（电子产品、书籍）、用户类型（新用户、老用户）等。
因素：
支付方式（Payment Method）
商品种类（Product Category）
用户类型（User Type）
水平：
支付方式：信用卡（Credit Card）、支付宝（Alipay）
商品种类：电子产品（Electronics）、书籍（Books）
用户类型：新用户（New User）、老用户（Existing User）
3. 画正交表
根据所识别的因素和水平，选择一个合适的正交表。正交表的特点是：
每一列中各个数字（水平）出现的次数一样多。
任何两列中的各有序数对出现的次数一样多。
正交表通常表示为 Lₙ(mᵏ)，其中 n 是行数（测试用例数量），m 是水平数，k 是因素数。
对于上述因素，可以选择 L₄(2³) 的正交表：
| 序号 | 支付方式 | 商品种类 | 用户类型 |
| 1 | CC | Elec | New |
| 2 | CC | Books | Existing |
| 3 | Alipay | Elec | Existing |
| 4 | Alipay | Books | New |
这里的 CC 表示 Credit Card，Alipay 表示支付宝；Elec 表示 Electronics，Books 表示 Books；New 表示 New User，Existing 表示 Existing User。
4. 补充正交表
有时，标的正交表可能不足以涵盖所有重要的测试场景。这时，可以根据实际情况对正交表进行补充或调整，以确保关键路径得到充分测试。
5. 将正交表转换成测试用例
最后，根据正交表中的每一行设计具体的测试用例。每一行代表一组输入参数的组合，以及对应的预期输出或行为。
测试用例1（对应第1行）:
输入：支付方式为信用卡，商品种类为电子产品，用户类型为新用户。
预期结果：支付成功，订单创建。
测试用例2（对应第2行）:
输入：支付方式为信用卡，商品种类为书籍，用户类型为老用户。
预期结果：支付成功，订单创建。
测试用例3（对应第3行）:
输入：支付方式为支付宝，商品种类为电子产品，用户类型为老用户。
预期结果：支付成功，订单创建。
测试用例4（对应第4行）:
输入：支付方式为支付宝，商品种类为书籍，用户类型为新用户。
预期结果：支付成功，订单创建。
通过这种方式，你可以有效地设计出覆盖广泛输入组合的测试用例，同时减少测试的工作量。
5.场景设计法
概念：
通过模拟特定的使用场景来测试系统功能或业务流程的一种方法。具体来说，就是设定一个具体的场景，模拟在这个场景下会发生什么，然后观察最终的结果，以此来发现需求中存在的问题。
设计测试用例的流程:
充分理解需求 -> 确定主事件流 -> 确定次事件流 -> 每个事件流就是一个测试用例
举例:
比如说，你要测试一个在线购物网站的结账流程：
你可以设定一个场景：用户添加商品到购物车，然后去结账。
在这个场景中，你会模拟用户点击“添加到购物车”和“去结账”的动作。
观察最终的结果，比如是否能顺利结账、订单信息是否正确等。
6.错误猜测法
概念：
一种依靠测试人员的经验和直觉来找出程序中可能出现的错误，并据此设计测试用例的方法。
简单来说，就是测试人员根据自己以前遇到过的bug或者是对系统的理解，猜测哪里可能会出错，然后专门去测试这些地方。
举例:
比如，如果你曾经在一个项目中遇到过某个特定类型的错误，那么在测试新的项目时，你可能会特别留意类似的情况，看看同样的错误会不会再次出现。这就是错误猜测法的实际应用。
原文地址：https://blog.csdn.net/m0_62055442/article/details/142393172
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！