软件测试工程师撰写优质测试用例的秘籍

一、前期准备要充分

（一）深入理解需求

        在拿到软件项目后，全面掌握软件各方面需求是编写测试用例的首要环节。首先，要认真研读相关文档，包括需求规格说明书、设计文档等，通过这些文档去细致了解软件预期实现的功能，比如软件具备哪些具体操作模块、各模块之间如何交互协作等；明确软件需要达到的性能指标，像响应时间、吞吐量等要求；梳理清楚其业务逻辑，例如业务流程是怎样的走向、不同业务场景下的先后顺序等。

        然而，仅依靠文档有时是不够的，还需要积极与开发团队及产品经理进行沟通。和开发团队沟通，能知晓技术实现层面的细节，例如采用了何种架构、使用了哪些关键技术等，这有助于我们从实现角度去思考测试点。与产品经理交流，则可以进一步明确产品的定位、目标用户群体以及一些隐藏在业务背后的深层次需求，避免对需求产生误解。只有通过这样多途径、全方位地去掌握软件的各项需求，才能为后续科学合理地编写测试用例打下坚实的基础。

（二）掌握相关理论

        软件测试中有诸多基本理论知识以及常用的用例设计方法，熟悉并掌握它们对实际编写测试用例有着重要意义。

1、等价类划分：

        其主要思路在于分类。先是根据需求，大体上划分为有效和无效两种等价类，然后再进一步细化相应的等价类，接着建立等价类表，最终生成测试用例。例如，对于一个限制输入 3 位数整数的用户 ID 输入框，可以划分出 100 - 999 这个有效等价类，以及少于 100、大于 999 这两个无效等价类。若在有效等价类 100 - 999 中，输入数据 202 通过测试，那就代表该等价类里的其他数据也能通过测试。等价类划分法适用于有数据输入（编辑框）的地方，像用户登录、注册、新建、查询等场景，它能够让我们用较少的测试用例尽可能多地覆盖功能，避免不必要的重复测试，有效减少测试用例数量的同时提高测试效率。

2、边界值分析：

        边界值分析法可看作是对等价类划分法的补充。它不是从某等价类中随意挑一个作为代表，而是要使这个等价类的每个边界都作为测试条件。边界值数据本质上属于某个等价类的范围，虽然测试时有时看似冗余（比如正好等于、刚刚大于或刚刚小于边界的值），但为了保障更好的测试质量，边界值必须单独进行测试。当有数据输入且存在取值边界或长度边界时，边界值法往往会和等价类划分法一起搭配使用，从而形成一套较为完善的测试方案。比如对于输入 1 到 100 之间整数的输入框，除了用等价类划分出小于 1 的整数、1 到 100 之间的整数、大于 100 的整数这三个等价类外，还需要针对边界值 1、100 以及略超出边界的值 0、101 等进行专门测试。

3、因果图法：

        当等价类法和边界值分析法只考虑了单个的输入条件，未顾及输入条件的各种组合、输入条件之间相互制约关系的场景时，因果图法就能发挥作用了。它的方法步骤包括找出所有的原因（即输入条件或输入条件的等价类）、找出所有的结果（即输出条件）、明确所有输入条件之间以及输出条件之间的制约与组合关系，确定什么样的输入条件组合会产生哪种输出结果，画出因果图后再转换为判定表 / 决策表，最后为判定表中的每一列表示的情况设计测试用例。

4、判定表法：

        主要包含五部分，即条件桩（问题的所有条件）、条件项（所有条件的取值组合）、动作桩（所有可能的操作）、动作项（在每一种条件取值组合的情况下，执行动作桩中的哪些动作）以及规则（一种条件取值组合与其对应的动作组合）。其方法步骤为列出所有的条件桩和动作桩（输入和输出），填入条件项（输入项），再填入动作项得到初始判定表，最后简化判定表（合并相似规则，也就是相同动作的情况）。

5、正交试验法：

        在因果图和判定表法面对变量值很多、排列组合数量极大的场景时，会生成极为庞大且冗余的测试用例，很难实现对所有组合场景进行全量测试用例覆盖，这时正交试验法就应运而生了，它可以借助相关工具（如 PICT）来生成正交试验测试用例，帮助优化测试用例的组合情况。

6、功能图法：

        针对需要对被测对象的状态流转进行验证的情况，像因果图、判定表、正交试验等主要针对不同条件输入输出组合进行测试的方法就不太适用了，功能图法则可大显身手。其核心思想是抽象出待测系统的若干状态以及状态之间的转换条件和转换路径，然后从状态迁移路径覆盖的角度设计测试用例，具体会涉及分析需求明确状态节点、梳理不同状态的转换输出状态 - 条件表、画出状态迁移图、转换为状态迁移树以及从状态迁移树导出测试路径等一系列步骤。

7、场景法：

        这是一种通过使用事件触发流程，对系统的功能点或业务流程进行描述的方法。从业务层面来讲，需要熟悉需求业务逻辑，并针对当前需求进行发散性思考；从技术层面看，要分析出基本流（模拟用户正确的业务操作流程）和备选流（模拟用户错误的业务操作流程），通过遍历所有基本流和备选流来覆盖完整的业务场景。不过它也有缺点，那就是只能验证业务流程，不能验证单点功能，所以一般会先采用等价类划分、边界值分析、错误推断法、判定表法等对单点功能进行验证，通过后再采用场景法进行业务流程的验证。

8、错误推测法：

        在实际需求测试过程中，受到外部环境及业务逻辑的影响，比如涉及多需求耦合、浏览器缓存堆积等情况，仅针对当前需求设计出的测试用例可能会有覆盖不全的问题，此时就需要借助以往的经验进行反向错误推测，辅助其他方法对测试用例进行完善。

        了解这些常见的用例设计方法的原理和适用场景后，我们就能根据具体的软件项目特点，灵活选用合适的方法运用到实际的测试用例编写工作中去了。

二、测试用例要素全解析

（一）用例编号

        测试用例编号是用于唯一标识每个测试用例的，它需要具备易识别性与可追踪性，方便后续查找和管理用例。其规则设定通常会结合项目名称、测试阶段以及具体序号等来定义。

        例如，常见的系统测试用例编号规则可以是 “产品编号 - ST - 系统测试项名 - 系统测试子项名 - XXX”，其中产品编号也叫项目标识，每个公司都有自己一套定义产品编号的规则，并且已有的产品编号都是既定的，可直接拿来使用。“ST” 代表系统测试阶段，后面紧跟的系统测试项名对应的是较大较系统的测试点，再后面的系统测试子项名则是对测试点更细化的划分，比如要测试用户能否成功登录这个功能，可细分为 qq 登录、邮箱登录等子项，最后的 “XXX” 可以是具体的数字序号，像 01、001、002 等等。

        集