测试用例编写规范及管理办法

目录

1.文章目的

2.测试用例的编写规范

2.1用例编写原则

2.1.1覆盖所有需求和业务场景

2.1.2 可维护性

2.2测试用例的必要元素

2.2.1 用例编号

2.2.2用例优先级

2.2.3 前提条件

2.2.4测试数据

2.2.5操作步骤

2.2.6预期结果

2.3测试用例的编写方法

2.3.1基于需求列测试大纲

2.3.2使用模板用例编写

2.3.3用例评审

3.选择有效的测试用例

3.1冒烟测试用例

3.2有效的回归用例

---

1.文章目的

    本文目的是分享软件测试用例的设计原则、方法，提高软件测试用例的可读性、可执行、可维护性、覆盖程度、以及测试的灵活性，使软件测试用例真正能够指导测试的实施和执行。同时针对软件测试过程中，测试时间受限无法全量回归的情况，如何制定有效的测试方案，给出合理的建议。

2.测试用例的编写规范

2.1用例编写原则

2.1.1覆盖所有需求和业务场景

1. 需覆盖软件需求规格说明、核心业务流程

2. 需覆盖正向场景、异常场景

3. 需覆盖核心数据和业务规则的有效&无效等价类、边界条件的校验

2.1.2 可维护性

1. 须使测试用例的分解符合高内聚和低耦合的特征，如按模块划分、按功能和业务流程划分

2. 须使测试用例每个步骤的结构和描述合理，简洁、清晰。​

2.2测试用例的必要元素

2.2.1 用例编号

        可以根据软件名称、模块名称和数字组合定义，如CMS系统的登录模块用例，编号可以设置成cms_login_001；

2.2.2用例优先级

        每个测试用例须根据测试设计和执行的进度和质量要求的重要和紧急程度进行设置，在项目执行过程中用例优先级不是一成不变的。

1. P1（占比：10%~20%）：冒烟用例、主流程用例、用户最常用功能或者影响用户体验的性能、质量特性等
2. P2（占比：60%~70%）：正常场景用例，从测试效率角度，边界区域更容易发现缺陷，测试边界区域的用例优先级相对较高；从修改成本考虑，逻辑方面的缺陷修复比简单功能缺陷修复成本高，逻辑方面的测试用例优先级要相对较高
3. P3（5%~10%）：异常场景用例，发布前如果时间限制，不需要回归，不会产生重大不良影响的用例
4. P4（占比：<5%)：极度异常场景用例，生僻场景，使用频率比较低

2.2.3 前提条件

用例执行的前置条件，如测试角色权限，修改代码或程序配置等要求。

2.2.4测试数据

        执行用例前需要准备的测试数据

2.2.5操作步骤

1. 每一个测试用例步骤的输入描述必须是一个，或一组明确的、无需进一步说明的测试操作行为；
2. 每一个测试用例步骤的期望结果是由此步骤的一个，或一组输入操作产生的，并且必须具有唯一性。
3. 每一个测试用例步骤的输入数据必须在执行测试前完成设计，并且必须满足真实的业务数据要求。

2.2.6预期结果

         每一个测试用例步骤都有明确的期望结果，用例编写时预期结果不应出现详见需求、页面展示正确之类的笼统描述。

2.3测试用例的编写方法

2.3.1基于需求列测试大纲

    熟悉需求是编写测试用例的前提条件，测试人员可以通过参与需求宣讲、阅读需求文档熟悉软件需求。在熟悉需求的过程中，使用思维导图梳理测试大纲，比较清晰、直观地罗列清楚要测试的需求点。

2.3.2使用模板用例编写

    可以根据用例模板进行用例编写，也可以用xmind按照用例模板格式定义好层级，进行用例编写，比较直观，且完成后导出excel。

2.3.3用例评审

1. 组织方式：用例编写完成后测试人员可以发起用例评审，如组织会议评审、邮件评审；测试用例评审的参与人员是：开发、产品、测试人员；

2. 评审目的：

• 1）完善测试的覆盖率，产品参与核对用例是否覆盖软件需求；

• 2)开发人员从代码角度给出建议，保证测试的全面性，防止漏测、过渡测试、无效测试等；

• 3）确保各角色对需求理解的一致性

3.选择有效的测试用例

3.1冒烟测试用例

        用例评审通过后，可以抽取P1级别的功能用例做为冒烟测试用例，冒烟用例是版本转测前由研发同学冒烟自测的执行依据。

3.2有效的回归用例

1.用例按需求模块或业务流程或组件划分清楚，划分方式和研发对齐

• 根据研发修改的范围，评估影响范围，抽取要回归的用例，做到测试执行的有效性
• 没有修改的模块或流程，执行优先级降低，时间来不及可以不覆盖（前提是和研发沟通好上线范围和影响）

2.根据测试情况、需求变更情况，及时更新、调整测试用例

•     已知需求变更，用例对应修改
•     测试过长中拨测场景发现严重问题，要丰富对应场景的测试用例
•     用例的优先级，根据不同版本的修改范围和影响，应灵活调整