提到写用例，老司机们可都会投来不屑的一瞥，
写用例嘛？
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、涉及到增加、删除或修改等操作的用例时，应该增加一条验证步骤。
验证步骤：即要通过结果查询操作，确认操作成功，而不仅仅通过界面结果。
如：进行短信发送测试，不仅仅查看发送页面提示“消息发送成功”，还应该查询用户手机是否真正的收到了短信。
根据小酋上面提到的11点，你说写出的用例能不闪耀动人吗？请持续关注小酋的文章，更多精彩在后面，比如下文该讲讲用例的书写模板了。Are you ready？
关注小酋微信公众号 ceshibuluo （51ste软件测试部落），更多精彩内容等着你~