【测试】测试用例编写规范

目的

        统一测试人员测试用例编写流程及规范，包括对测试用例要素和用例等级定义的统一

角色

        测试人员依据此规范编写测试用例

测试用例编写要求

开始时间

        ● 用例设计编写在需求评审，迭代启动会结束，测试计划，测试方案评审通过后

文档准备

        ● 需求/故事/原型，《需求分析》，《测试计划》，《测试方案》，《设计图》等

用例编写平台

        ● 企业微信在线文档，模板参考《能源测试用例手册2024》

用例修改

        ● 用例评审后，根据评审意见修改用例

        ● 测试执行过程中发现遗漏或错误时，修改用例

        ● 需求变更后修改用例

完成时间

        ● 开发提测前至少1天

测试用例编写注意点

1.  全面覆盖本次需求，“测试方案-功能测试”中涵盖的功能点必须有用例与之对应

2.  有与其他系统相关的需求（如上游或者下游的相关需求）时，需要编写相关用例

3.  历史缺陷的复现步骤没有包含在用例中时，需要及时补充；

        ● 在缺陷中根据字段筛选“是否测试用例发现=否”的缺陷

        ● 补充用例

        ● 用例补充后，在备注中添加用例ID

测试用例要素

1.  用例标题，必填标题：填写系统名称

2.  用例编号：项目名缩写——001 

3.  用例名称，必填用概括的语言描述该测试用例的测试点，每个测试用例的标题不能重复

4.  前置条件执行当前测试用例需要的前置条件

        a.  测试数据

5.  用例步骤，必填其他人依据该操作步骤执行无异议

        a.  建议用例步骤不能超过7条

6.  预期结果，必填有多个预期结果时，按（1.1，1.2，2.1）描述

        a.  建议一个步骤的预期结果不超过3个

7.  关联需求用例可以关联需求；所有的需求都必须有对应用例，但不是所有的用例都必须关联需求

8.  用例类型，必填（值不够时，可在测试用例模板中自定义）UI测试、功能测试、合规性测试、易用性测试

        a.  UI测试：对应用例三级目录中“UI检查”

        b.  功能测试：对应用例三级目录中“业务流/控件检查”

        c.  易用性测试：对应用例三级目录中“易用性检查”

        d.  合规性测试：对应用例三级目录中“合规性检查”

9.  用例等级，必填用例等级制度，参考“测试用例等级”

10.  功能模块（可在TAPD测试用例模板中自定义）测试用例所测试的功能模块

测试用例等级

等级定义	描述	划分依据	对应的bug等级	建议占比
P0	核心功能测试用例（冒烟测试）	确定此版本是否可测的测试用例，该用例执行失败会导致多个重要功能无法运行。	致命	5%-10%
P1	高优先级测试用例	核心功能的正向业务流，覆盖平台功能的所有重要业务流，基本功能测试，和重要的错误、边界测试	严重	20%-30%
P2	中优先级测试用例	使用频率不高、非常用的重要功能，更全面地验证功能的各个方面，异常测试，边界、中断、断网、容错、UI等测试用例	一般	30%-40%
P3	低优先级测试用例	非主要功能，不影响使用的功能，生僻的预置条件和数据设置的功能，不常被执行，性能、压力、兼容性、稳定性、安全、可用性	一般/提示	10%-20%

P0：即冒烟测试不通过，无法进行测试。用例设计常用思想&方法：场景法。

P1：P1和P2用例要覆盖所有功能的正向业务流，能够保证软件功能稳定使用。包含功能交互、使用场景、使用频率较高的正常功能用例。

P2：常见输入框、字符等正向用例，常见异常场景的业务流，常见的失败类场景。

P3：用例设计常用思想&方法：边界值、无效等价类等。常见的输入框异常用例，包括一些异常的触发条件。 

等级划分

初步划分

1.把所有功能性验证（或基本路径）的测试标注为P1；

2.把所有错误、边界值、UI测试标注为P2；

3.把所有非功能性的测试（例如性能、可用性、稳定性、安全、兼容等）标注为P3。

提升和降级

并非所有的功能性测试都一样的重要，并且有些边界和非功能性测试也很重要。思考一下测试的重要性及相对于其他同等优先级别的测试，你想要检查这个功能的频率，考虑质量目标和项目的需求，可以对case重新调整，规则如下：

1.把功能性验证测试分为两组：重要和不是十分重要，将“不是十分重要”的功能性验证测试降级为P2；

2.把错误和边界测试分成两组：重要和不是十分重要，将“重要”的错误和边界测试升级为P1；

3.把非功能性测试分成两组：重要和不是十分重要，把“重要”的非功能性测试升级为P2；

4.针对每组高，中和低优先级别的测试用例，重复划分和升级/降级流程直到你达到一个点，可以在不同优先级之间移动的测试用例的数量到最小。

注：所谓“重要”，可以理解为：bug多的、用户使用频率高的、最基本的这些概念。

挑出冒烟测试用例

为了确保小版本是可以测试的并准备好给小组其他成员执行准入测试，需从高优先级别的case中挑选出P0 case，规则如下：

1.将高优先级别的测试用例分成两组：严重的和重要的，将“严重”的高优先级的测试用例升级为P0级