设计测试用例的步骤：1、确定测试范围；2、明确用例设计原则；3、做好前期准备工作；4、确定测试用例设计的要素；5、明确测试用例的颗粒度；6、确定用例设计维度。确定测试范围的条件是完整的需求文档、需求已经组织评审和澄清、完整的功能列表。
1、确定测试范围
- 必须有完整的需求文档
- 需求已经组织评审和澄清
- 必须有完整的功能列表
2、明确用例设计原则
- 遵循“边界值”全覆盖原则：确定相关等价类的边界，然后定义下面3种条件的值：边界上的值；刚好在边界值上方的值；刚好在边界值下方的值。
- 遵循”等价类划分场景“全覆盖原则：依据需求将输入划分成若干个等价类，从等价类中选定一个测试用例，如果该用例通过，则表明整个等价类通过。
- 遵循”测试用例路径少数“原则：当出现多个路径时，需要新建用例去覆盖。一条用例仅覆盖一个测试点。降低漏测风险。
- 遵循“单条用例覆盖最小化”原则：假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，下面两种方法来设计测试用例：方法一是用一个测试用例覆盖三个子功能 – TestA1A2A3；方法二是用三个单独的用例分别来覆盖三个子功能 – TestA1，TestA2，TestA3。方法二遵循了“单条用例覆盖最小化”原则，好处是当用例执行失败时，降低复现/定位复杂度。
- 遵循“测试用例与测试用例之间最低耦合度”原则：严谨使用上一条测试用例的结果，做为下一条测试用例的输入；每一条测试用例，应该都是完整独立的。这样做的好处便于测试用例拉取、复用、可维护、减少后续投入成本。
3、做好前期准备工作
- 拿到相关文档，熟悉业务、了解系统；
- 梳理功能点，画好思维导图；
- 有条件的，就和同小组测试人员交换思维导图，互补测试点；
- 与产品、开发等相关同事沟通，加深对系统的理解。
4、确定测试用例设计的要素
- 用例编号：项目简称 + 模块简称 + 顺序编号。
- 用例名称：操作 + 预期结果。
- 级别：根据两方面：用户使用该场景的频率；该功能对系统的影响程度。
- 预置条件：操作的前提。
- 测试步骤：操作步骤。
- 期望结果：根据功能点和需求点，所产生的结果。
5、明确测试用例的颗粒度
颗粒度，就是指一个用例所涵盖的关注内容：
- 颗粒度大，则总的用例数就少，一个用例所涵盖的关注内容比较多，用例看起来也简洁。
- 颗粒度小，则总的用例数就多，一个用例所涵盖的关注内容少，甚至只有一个，单条用例关注的测试点很集中，不容易遗漏，执行时间比较好估计。
6、确定用例设计维度
- 熟悉业务，了解系统；
- 测试用例的颗粒度大小要灵活、适当；
- 充分考虑用户的各种使用场景；设计方法：等价类、边界值、错误推测、判定表、场景法。
- 测试用例的要素要齐全，操作步骤尽量详细、易懂；
- 做好用例评审，及时更新测试用例。
延伸阅读
测试用例的重要性
- 测试用例构成了设计和制定测试过程的基础。
- 测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，测试人员对产品质量和测试流程也就越有信心。
- 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95%的关键测试用例已得以执行和验证”，远比“我们已完成95%的测试”更有意义。
- 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
- 测试设计和开发的类型以及所需的资源主要都受控于测试用例。
- 测试用例通常根据它们所关联的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。优异方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
文章标题：怎么设计测试用例，发布者：Z, ZLW，转载请注明出处：https://worktile.com/kb/p/36237
微信扫一扫 
支付宝扫一扫 
