如何优雅编写测试用例 | LuckyHunter's notes

在编写测试用例之前，首先应该根据所在公司、项目组的特点，提前制定好对应的测试用例模板以及用例维护方式，比如：Excel、XMind、TestLink、禅道等。

测试用例的组成通常包含以下内容（具体字段根据业务需要取舍）：

作为测试用例的唯一标识。编号取值规则可以根据项目名称各中文首字母大写 + 六位数字构成，例如：“蔡坨坨电商项目” 在登录功能子模块的第一条用例编号可取值为 CTTDS_000001。

又称之为测试点，用一句话来描述测试用例的关注点，每一条用例对应一个测试目的。

一个好的测试用例应该关注标题的规范性，一般来说如果设计用例标题不规范，别人在使用你的测试用例时，就无法做到清晰明了，就会浪费很多时间在沟通上。

并且需要控制用例的粒度，从测试执行者的角度来说，过细的测试用例会让执行者感到疲惫繁琐，过粗的测试用例又容易导致检查点遗漏。所以测试用例标题一般控制在 30 个字以内。

根据项目模块层级关系填写，例如：组织权限。

简要的测试目的，例如：账号密码功能校验。

用例在执行之前需要满足的一些条件，否则用例无法执行，如测试环境，需要提前执行的操作等，例如：进入到某一页面。

测试用例其实就是在某种场景下，执行一定的动作，达到什么样的结果。而前置条件决定了 “在某种场景下”，所以是不可或缺的。

根据需求的优先级来定义，高优先级要覆盖核心业务，重要特性以及使用频率比较高的部分。

级别的枚举值也有多种形式，比如：P0\P1\P2\P3，1\2\3\4，高 \ 较高 \ 中 \ 低。

冒烟测试（高）、基础用例（较高）、特殊场景用例（中）、错误场景用例（低）。

测试用例的步骤描述，执行人员可以根据测试步骤完成测试的执行，一般只需要写和测试目的密切相关的步骤，一些基础的步骤可以放在前置条件中，例如：1. 输入正确的账号 2. 输入错误的密码 3. 点击登录按钮 4. 查看结果。

用例步骤一般不多于 7 步，不少于 2 步。

操作步骤也是不可或缺的一部分，因为它关系到如何执行。

在执行测试时，需要输入一些外部数据来完成测试。这些数据根据测试用例的统计情况来确定，有参数、文件或数据库记录等，例如：账号：admin，密码：123456。

测试用例中最重要的部分，主要用来判断被测对象是否正常，例如：提示用户名或密码错误。

预期结果关系到用例需要达到什么样的结果，所以也是不可或缺。

每条用例的实际执行结果，只有三个枚举值：PASS（通过）、FAIL（不通过）、N/A（未执行）。

预期结果一般不超过 5 个，不少于 1 个。

每条测试用例执行不通过后再记录对应一条 Bug，例如：BUG-1219。

用例对应的编写人员，填写编写人员姓名，例如：测试蔡坨坨。

用例对应的执行人员，填写执行人员姓名，例如：测试蔡坨坨。

每条测试用例的备注，备注内容可以按实际情况填写，一般有备注的测试用例都比较重要，需要格外关注。

测试用例的编写并没有好坏和对错之分，每个人编写用例的思路也是各不相同，适合当前团队就是最好的，不要盲目把所有的字段都加上，应根据实际场景进行取舍。

除此之外，还有一些注意事项值得关注。

例如：

标题要清晰，推荐采用场景 + 预期结果进行描述，比如：输入正确的用户名和密码，成功登录系统；
控制用例的粒度，比如：标题字数不超过 30 个字、步骤数控制在 2-7 步、预期结果数在 1-5 个；
用例之间要解耦，日常工作中经常遇到几个用例有先后顺序的情况，比如：在测试编辑之前肯定要先新建一条数据，最好把新建放在编辑用例的前置条件中，每条用例都能实现闭环；
预期要明确，不要出现一些模糊字眼，对于不明确的点应该跟产品沟通；
拒绝冗余，用例可以多，但不要冗余，尽可能以最小场景覆盖最全的范围，同一个等价类只需测一条数据，当然，因为测试不可穷尽性，测试场景肯定不会最全面，往往会受限于时间和资源等成本，这时需要在有限的资源下，寻求质量和效率之间的平衡点，优先级这个字段就起到了作用，再引申就是测试策略的问题了，整体上采取基于风险驱动的模式，有侧重点地去验证一些场景，优先核心功能，或者增加资源和延长周期，同时寻求自动化相关技术去提升整体效率。