测试用例规范约定
一、用例设计书写的标准规范
1.用例标题
描述清楚该用例所要达到的测试目的，不是单纯的描述所在模块或；
正确示例：
未登录状态下发布动态能否成功
或
登录状态下只发布文字动态内容能否成功
2.前置条件
用例必须清晰地描述此用例所需的前提条件；
正确示例：
1、用户已登录云转诊APP；
2、用户已进入动态页面；
3.用例步骤
测试用例编写要步骤明确，输入输出要素（输入数据值）清晰，并且无疑义；
输入数据值：指当前用例输入值的具体范围及明确值；
正确示例：
1、点击动态下的（发动态）按钮
2、输入文字：我很享受音乐
3、点击（发送）按钮
4.预期结果
预期结果必须具有可判定性，即测试步骤执行后，结果是可判定的，每一个测试用例的步骤都应有相应的唯一的预期结果，预期结果中不能包含步骤；
正确示例：
发布动态成功，页面跳转至动态页面
错误示例：
1.云转诊APP成功打开
2.显示我的页面
3.打开编辑页面
4.弹出性别选择窗口
5.测试用例集
一条用例内多个用例步骤对应多个预期结果时，禁止使用编号内附加子级编号形式编写测试用例，需要单独表述。

测试用例可以使用单条用例或测试用例集的方式编写，单条用例需要把同一情况下的测试用例整合在一条内编写，预期结果与操作步骤相互对应。

测试用例集需要操作步骤与预期结果编号相对应，完整的表达操作与结果之间的关系
真实示例如下图所示：
二、用例设计书写的颗粒度描述
要求：验证一个功能点一条用例，没有重复、冗余的测试用例。

功能测试用例需要从用户层面来设计用户使用场景和使用流程。

1.冒烟测试
验证系统正向功能流程通畅及验证系统正向必填项（系统要求验证项）输入值、单选项、下拉框、按钮等符合系统要求；
2.功能测试
用例中需要合理的使用测试用例编写方法设计反向用例、容错性用例、三方交互用例等场景，以确保覆盖业务操作的基本路径和异常路径，以及对其他模块/功能的影响和必填项（系统要求验证项），保证达到系统规定；
3.UI测试
对系统UI页面进行检查，确保UI布局合理、文字统一、易用性（易操作、易理解和易学习）、友好性等达到系统要求（同一页面没有操作整体时，页面检查算一个功能点）；
三、用例执行规范
1.出现非Pass的用例必须标记对应的状态,Fail的用例必须提交缺陷；
2.由于某个Bug缺少测试条件导致用例不能执行，标为Block添加备注信息；
3.功能模块没有设计好，或者不适用于本轮测试的用例，标为N/A加备注信息；
四、用例测试执行突发状况处理
1.用例无法满足执行的前提条件，或者测试过程中无测试数据，导致用例无法执行，必须及时与相关人员沟通，相关人员（测试负责人、用例设计人、产品、开发）是否可提供测试数据，不能直接跳过此用例不执行；
2.按照用例描述步骤，无法达到用例预期结果，或者无法实现某个功能，必须及时与产品经理沟通，如是Bug，应该标记为Fail并提Bug；
3.测试执行过程中，如果是APP功能没有设计或开发完成，对应的用例应该标N/A并且添加备注信息；

4.测试执行过程中，如果是用例设计错误，应该根据正确需求修改用例与产品经理确认后继续执行；
5.测试过程中发现测试用例设计错误，必须及时与用例设计者和产品经理沟通，更新用例，不能直接跳过此用例不执行；
6.用例执行过程中，出现无法判断结果是否正确的情况时，必须及时与产品经理确认，不能直接标记结果（Pass、Block或N/A）加备注信息；
7.产品需求有变化时，必须及时同步修改测试用例；。