你真的会写用例嘛？

提到写用例，老司机们可都会投来不屑的一瞥，

写用例嘛？

123 ABC so easy！

然而，当真写出来的用例，可能闪瞎大家的眼。

哈哈，这是怎么练就的呢？请看上方大屏幕……

哦，哦，请看下面~

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。

测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类缺陷的测试数据。

关于用例的编写规范，应遵循以下11点：

1、界面测试和功能测试用例分开编写。界面测试可以根据需求和行业规范列出checklist，不单独针对每个页面进行用例编写。

2、如果需求是增量的，应该对用例进行版本规划。起始编号为V1.0.0，具体版本编号可以根据需求制定。

3、根据需求文档结构视图，采用树形结构进行对用例的编写。（如果需求模块结构不合理，可以适当做修改）

如：
|1一级功能
|–1.1二级功能
|----1.1.1功能点
|------测试用例1
|------测试用例2

4、注意用例命名前面加上编号，方便后面检索。

编号应该根据一定的命名规则生成，且保持全局唯一性（如使用bug管理系统，保证编号在系统中是唯一的）。
如，XX1901-F01-C01 XX为项目名，1901为需求版本编号，F表明为功能需求，01为需求功能编号，C01表明为该功能的第一个测试用例。

5、每条测试用例对应一条测试需求的测试点，用例名称应该简洁易懂。（用例名称最好包含测试点）

6、标明每条测试用例的目的、测试等级和预置条件。（测试等级与相应需求的优先级对应）

PS：

①当需求没用标明优先级，可以找需求设计人员确认；也可以根据经验进行判断后再与需求设计人员进行确认。
②优先级与下面因素有关：

• 用户操作频度
• 功能的重要程度（虽然使用频度虽然低，但非常重要，如财务中系统月扎帐、结算）
• 对核心业务的影响程度
• 负面（异常）情况对系统的破坏性

7、用例尽量根据实际情况，按照最高执行效率进行排版；测试用例中的每个步骤：不能出现二义性，仅是一个可执行的步骤，每个步骤对应一条预期结果。

PS：为了提高用例执行效率，小酋摒弃了以前的用例写法（严格的前置步骤、输入、输出），一直在所负责的项目中推行使用“思维导图+测试点”来进行用例的设计。此条对于经验丰富的老手较为实用，新人建议还是老老实实的写用例，但形式可以根据实际情况做一些简化。

8、如果用例间存在关联的（如，前一个用例执行成功是后一个用例执行的前置条件），把影响后面执行的用例放在前面。

9、针对每个测试点，建议常规用例（以边界值分析、等价类划分、正交实验法、场景分析等编写的用例）放在前面，非常规用例（仅指错误猜测法编写的用例）放在后面。

10、用例编写应采用书面语，文字语言简练易懂，避免出现错别字，病句或逻辑错误。

11、涉及到增加、删除或修改等操作的用例时，应该增加一条验证步骤。

验证步骤：即要通过结果查询操作，确认操作成功，而不仅仅通过界面结果。
如：进行短信发送测试，不仅仅查看发送页面提示“消息发送成功”，还应该查询用户手机是否真正的收到了短信。

另外，欢迎加入软件测试技术交流群 313782132 ~进群可领取免费软件测试资料以及群内测试大牛解惑！

测试工程师职业发展路线图

功能测试 — 接口测试 — 自动化测试 — 测试开发 — 测试架构师

加油吧，测试人！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。事必有法，然后有成。

资源不错就给个推荐吧~