声明：
个人觉得写的挺好，所以转载过来，如有侵权，请联系QQ:396667207删除
转自：https://new.ztestin.com/new/subject-two-study-design
PS：其实每个公司都有一个规范，工作中多还是以公司规范为主
3.用例设计书写的标准规范
用例标题：
描述清楚该用例所要达到的测试目的，不是单纯的描述所在模块
正确示例：
未登录状态下发布动态能否成功
登录状态下只发布文字动态内容能否成功
错误示例：
碎乐App-碎乐-推荐-重磅推存
前置条件：
用例必须清晰地描述此用例所需的前提条件
正确示例：
1、用户已登录碎乐APP
2、用户已进入动态页面
错误示例：
网络正常
用例步骤：
测试用例编写要步骤明确，输入输出要素（输入数据值）清晰，并且无疑义
正确示例：
1、点击动态下的（发动态）按钮
2、输入文字：我很享受音乐
3、点击（发送）按钮
输入数据值：
当前用例输入值的具体范围及明确值
预期结果：
预期结果的可判定性，即测试步骤执行后，结果是可判定的，每一个测试用例步骤都应有相应的唯一的预期结果且预期结果可以验证
正确示例：
发布动态成功，页面跳转至动态页面
发布动态失败，提示请输入内容
错误示例：
1.碎乐APP成功打开
2.显示我的页面
3.打开编辑页面
4.弹出性别选择窗口
测试用例集：
一条用例内多个用例步骤对应多个预期结果时，禁止使用编号内附加子级编号形式编写测试用例，需要单独表述。
测试用例可以使用单条用例或测试用例集的方式编写，单条用例需要把同一情况下的测试用例整合在一条内编写，预期结果与操作步骤相互对应。测试用例集需要操作步骤与预期结果编号相对应，完整的表达操作与结果之间的关系。
真实示例：
下面是某软件的直播模块标准用例的书写规范(如图3-1)
-
图3-1
4.用例设计书写的颗粒度描述
验证一个功能点一条用例，没有重复、冗余的测试用例。
测试用例需要从用户层面来设计用户使用场景和使用流程。
- 冒烟测试：
验证系统正向功能流程通畅及验证系统正向必填项（系统要求验证项）输入值、单选项、下拉框、按钮等符合系统要求；
- 功能测试：
用例中需要合理的使用测试用例编写方法设计反向用例、容错性用例、三方交互用例等场景，以确保覆盖业务操作的基本路径和异常路径，以及对其他模块/功能的影响对必填项（系统要求验证项），保证达到系统规定；
- UI测试:
对系统UI页面进行检查，确保UI布局合理、文字统一、易用性、友好型等达到系统要求（同一页面没有操作整体页面检查算一个功能点）；
5.用例执行规范
- 测试结果中：
出现非Pass的用例必须添加详细备注信息,Fail的用例必须提交缺陷；
由于某个Bug或者缺少测试条件导致用例不能执行，标为Block添加备注信息；
功能模块没有设计好，或者不适用于本轮测试的用例，标为N/A加备注信息；
- Bug详情
标题要求简明扼要的阐述问题本质，使查看人员能快速了解Bug内容；
必须有完整的测试环境信息（测试设备型号、操作系统版本、网络）、前提条件、要简明清晰分步骤描述如何复现bug问题、清晰准确的预期结果和实际结果、复现概率;
- 有现象的Bug需要必要的截图证明
崩溃的Bug必须提供Log日志附件帮助定位问题，截图无法反应的问题需要上传操作视频文件，提供的视频、图片、log文件必须满足公司要求的统一格式。
原则上同一Bug只能Fail一条测试用例，在其他测试用例中，如果存在此Bug，但又不影响继续测试，不能跳过不执行。
6.用例测试突发状况处理
用例无法满足执行的前提条件，或者测试过程中无测试数据，导致用例无法执行，必须及时与客户确认，客户是否可提供测试数据，不能直接跳过此用例不执行；
按照用例描述步骤，无法达到用例预期结果，或者无法实现某个功能，必须及时与客户确认，如是Bug，应该Fail并提Bug；
如果是客户APP功能没有设计完成，应该标N/A添加备注信息；
如是用例设计错误，应该根据正确需求修改用例执行；
测试过程中发现测试用例设计错误，必须及时与客户沟通，更新用例，不能直接跳过此用例不执行；
用例执行过程中，出现无法判断结果是否正确的情况时，必须及时与客户确认，不能直接标记结果（Pass、Block或N/A）加备注信息；
产品需求有变化时，必须及时同步修改测试用例；