破解测试难题，两步助你打造完美无缺的测试用例

转载自"360质量效能"微信公众号

引言

测试用例设计是每个测试人员最基础也是必备的一项核心技能，目前chatgpt都可以写测试用例了，网上各种测试方法的总结更是数不胜数，即使这样我们在测试过程中，仍然会存在以下问题：

● 测试用例照抄需求文档

● 测试用例设计不全面、场景覆盖不全，导致漏测

● 测试用例冗余、大篇幅重复

● 测试用例重点不突出

● 测试用例可读性不高、他人执行难度大

如何规避解决以上问题，下面简单介绍一下笔者在测试用例设计中的思路吧 ~

?5W2H需求分析及用例设计要点?

首先，拿到需求先进行需求分析，使用5W2H分析法，了解需求的背景及目的、深入理解功能在业务中的具体应用，为什么做、什么时候做由谁做等，有疑问的地方及时与产品确认。然后思考如何去测试这个需求、测试范围是什么、需要测试到什么程度、怎么提升测试效率。分析清楚以上问题后，为后续测试用例设计奠定基础。

其次，测试用例设计时有以下几个需要注意的点：

1. 先规划一个具体的xmind用例结构，确定一二级内容，每个层级的内容是平级、独立、且有内在逻辑的。清晰的结构可以避免用例冗余或用例覆盖不全、以及他人可读性差等问题。

比如，系统级的测试，建议xmind一级菜单按照功能模块拆分，再针对每个功能模块分别展开用例编写：

若是单个页面可以按照页面功能结构划分：

若是流程相关的需求可以按照业务流程展开设计：

2. 用例中可以标记说明一些测试周边信息，比如：

①. 需求地址：以便后续回顾时直接定位需求位置；

②. 开发人员：多人合作项目bug指派明确；

③. 核心功能点作为备注提醒；

④. 用例标记说明；

3. 通用的功能比如权限验证、通用组件等可以作为单独模块验证，避免各个功能模块用例重复。

4. 核心功能位置靠前、突出展示，测试用例评审时大家可以重点关注、测试执行时也需要重点验证。

5. 场景用例可以作为单独模块验证，将各个功能串联起来，便于梳理思路以及后续执行。

6. 大型项目可以设置一个冒烟测试用例的独立模块，便于提供给开发进行自测；也可以在用例中记录上线步骤、配置信息、表结构等，避免上线遗漏、顺序错误等情况。

在以上内容都考虑到位之后，测试用例的结构大致如下，也可以作为团队内部的用例模板供后续测试用例设计参考。

?使用用例设计方法编写用例?

用例结构确定之后，开始使用测试用例设计方法进行用例编写，用例设计方法有：等价类、边界值、场景流程分析法、错误推断法、判定法、因果图、正交测试法。下面介绍一下最常用的前四种方法。

1. 等价类划分

等价类划分法大家都很熟悉了，将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。通过选择适当的数据子集来代表整个数据集，降低测试数目但又可以合理的覆盖。一般可以分为有效等价类和无效等价类，即输入合理的数据集合正向案例和输入不合理的数据集合反向案例。

设计用例时，一条用例尽可能多的去覆盖尚未覆盖的有效等价类。可以避免用例冗余、提升效率；但一条用例只能覆盖一条无效等价类，才能直观清晰验证是否符合预期，避免漏测。

举例：

2. 边界值

边界值是对等价类划分的补充，针对输入或者输出的边界值进行测试，测试用例来源于等价类的边界，选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。长期工作经验告诉我们，大量错误均是发生再输入或者输出范围的边界上，此处用例的设计必不可少。

举例：（上方是针对输入边界设计、下方是针对输出边界设计）

3. 场景流程分析法

场景法是通过场景描述用例执行的路径，从用例开始到结束遍历这条路径上所有基本流、备选流、以及异常流。我们可以在需求分析时，就动手画出业务流程图，再根据流程图进行场景设计。这样可以避免场景缺失导致的漏测，尤其是复杂业务逻辑，更容易有场景遗漏。通过流程图每个分支的路径设计用例，可以保障测试的完整性。

举例：下单功能

基本流：用户登录->添加产品->进入购物车->结算支付

备选流：添加产品->进入购物车->点击结算跳转到登录页面->登录后继续结算支付

异常流：用户登录异常、下单异常等

4. 错误推断法

主要通过以往经验或直觉推测出系统可能存在的缺陷，并针对性的编写测试用例。但有时我们会遇到想不出可能存在问题的点，那就需要自身加强对需求的理解、了解系统架构的实现、掌握代码设计的细节、提高个人测试能力。

总结

以上，通过各种方法已将基本的功能测试用例设计完毕了。但是一份好的测试用例，不仅需要考虑功能性，还需要结合软件质量的六大特性进行测试用例设计，继续对测试用例进行添砖加瓦，提高测试质量。最后附上一份完整的测试用例结构模板，希望对大家后续测试有帮助~