软件测试流程规范（质量度量）

1 软件测试流程

1.1 软件测试流程图

1.2 软件测试流程说明

需求分析：产品经理需要提前将需求文档提供给项目所有参与成员，分析阶段，需要仔细阅读和检查评审对象，以及评审相关的输入资料。根据职责要求和评审的目的，尽量发现评审对象中的缺陷，并根据缺陷分类和记录，以方便后续的缺陷分析和过程改进，是提高评审效率和覆盖率的有效手段之一。

需求评审：讨论评审员提交的问题列表，并形成会议纪要。参与者可以标识缺陷、提出处理缺陷的建议或对缺陷做出决定。检查缺陷是否已解决，收集度量数据，并评估出口准则（何时可以结束评审活动）。测试计划：制定测试计划、测试策略，有效控制项目进度，预估项目存在的风险。

编写用例：根据产品需求、产品原型和测试点，编写全量测试用例。

用例评审：项目所有参与人员，包括：产品、开发、测试人员。评审用例，保证用例的覆盖度达到最大。

开发自测：测试提供冒烟用例（主流程测试用例），由开发自测。自测通过后交由测试验收，验收通过后，测试进行提测。

用例执行：选择合适的测试策略，进行全量用例执行。

Bug生命周期：bug提交、bug回验、bug重新打开、bug关闭。

产品、UI验收：测试完成后，交由产品进行功能验收，UI验收界面样式。

测试通过：产品、UI验收通过后。

测试报告：测试通过后，编写测试报告，进行提交。

线上验证：上线后，需要验证主流程功能是否正常。

项目复盘：项目结束后，组织项目成员对现本阶段总结。

2 需求评审

2.1. 个人准备阶段

在个人准备阶段，需要仔细阅读和检查评审对象，以及评审相关的输入资料。根据职责要求和评审的目的，尽量发现评审对象中的缺陷，并根据缺陷分类和记录，以方便后续的缺陷分析和过程改进，是提高评审效率和覆盖率的有效手段之一。

2.2 需求评审阶段

讨论评审员提交的问题列表，并形成会议纪要。参与者可以标识缺陷、提出处理缺陷的建议或对缺陷做出决定。

需求评审过程，由专门人员做会议纪要，记录评审过程中产生新的的疑问、业务缺失和其他问题。

2.3 需求返工阶段（产品经理）

修复评审过程中发现的缺陷。

2.4 跟踪结果阶段

检查缺陷是否已解决，收集度量数据，并评估出口准则（何时可以结束评审活动）。

2.5 测试点整理

根据需求评审以及定稿的需求，提取罗列测试点。

采用思维脑图罗列测试点，梳理测试思路，如下图：

3 测试划分

根据迭代执行阶段，测试分类策略如下：

冒烟测试（提供冒烟用例，由开发进行测试）

业务功能测试

交叉测试（时间允许的情况）

功能验收测试

产品验收测试

内部验收测试

外部质检测试

发布封装版本

4 测试用例规范

4.1 静态测试方法（开发自测，提高代码本身质量）

代码审查

代码走查

静态分析

4.2 编写测试方法

主干流程、分支流程，如需求未作变动，可复用上一迭代测试用例

标准数据

异常数据

边界值

4.3 测试用例分级

4.4 用例评审和修订

测试组内成员评审用例，检查用例的有效性和遗漏点

测试用例评审人员：产品、UI、开发、测试

修订测试用例：用例修订后，根据实际情况，判断是否需要进行二次评审

4.5 测试执行

4.5.1 测试执行优先级

测试优先级的确定可以来源于测试用例的风险级别，测试执行的先后顺序可以采用基于风险的深度优先策略或广度优先策略进行实施

测试资源是否及时到位也会影响测试优先级的设置

开发团队相关的因素也会影响测试优先级的设置

4.5.2 测试执行入口准则

系统测试设计规格说明、系统全量测试用例，经过评审并且通过

测试所需资源，如测试人员、测试环境、测试数据等已经到位

开发人员提交了版本说明，其中阐述了从开发角度建议的测试重点、测试建议、存在的缺陷和问题列表等

开发提交了在测试环境中通过了冒烟测试

4.5.3 评估出口准则

测试结果满足所有的出口准则

5 软件缺陷管理

5.1 bug定义

5.2 流程说明

提交bug：提交bug后，及时和开发沟通，确保开发已知。

Bug回验：开发修复后，进行回归测试。

Bug已解决：开发修复bug后，指给测试人员。

Bug重新打开：关闭的bug，测试过程中已关闭的bug又出现了，可以重新打开关闭的bug。

Bug打回：回验已解决的bug，问题依然存在，重新指派给对应开发人员，备注复现步骤和相关信息。

Bug关闭：已修复的bug，验证通过后，进行关闭（进行备注）。

暂不修复bug：与开发、产品达成一致后，进行bug备注，且申请转出

暂不修复bug，与产品不能达成一致，需报备给刘总，评估项目工期与现阶段迭代延误风险

5.3 提交软件缺陷准则：

单一准确：每个报告只针对一个软件缺陷，一个报告中若存在多个软件缺陷，避免导致只有其中一个软件缺陷得到注意和修复，其他缺陷没有得到修复。

可以再现：缺陷操作步骤的准确描述是开发人员可以再现缺陷的重要保证。如果按照所描述的步骤不能再现缺陷，开发人员就会抱怨，浪费大家的时间。

完整统一：提供完整的缺陷描述信息，以及所需的图片信息、视频文件等。

短小简练：通过使用关键词，可以使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。

特定条件：许多软件功能在通常情况下正常，而是在某种特定条件下会存在缺陷，例如网络繁忙时。所以，缺陷描述不要忽视看似细节的但又必要的特定条件，指引帮助开发人员找到原因的线索。

不做评价：在软件缺陷描述不要带有个人观点，不要对开发人员进行评价。软件缺陷是针对产品、针对问题本身，将事实或现象客观的描述处理，不需要评价或议论。

5.4 临后（线上）bug解决方案：

归纳收集临后bug列表（专门人员），且划分版本、优先级别，进行分类，制定修复计划。不能因为是线上问题，就必须立刻解决和当天解决，可根据优先级的高低，确定具体的解决时间，避免大量临后bug堆积。

按照修复计划，优先处理紧急程度高的

临后bug应制定测试回验方案，在某个时间段进行回验。

回验成功后，开发人员应提供修改方案，且可能受关联的其他功能模块，避免生成其他bug风险。

回验临后bug，且需回归可能受关联的其他功能模块（开发提供）。

回验通过（临后bug和受关联的其他功能），关闭临后bug，临后bug列表状态进行变更。

6 软件测试文档

6.1 测试计划

6.1.1 计划说明

测试的范围和目标

对测试的各阶段所需要的时间、人力及其他资源进行评估，针对每个测试任务仔细分析到位，尽量做到客观、准确、留有余地（总时间的10%~15%）。

制定测试项目的输入、输出和质量标准，并三方达成一致

建立变化处理的流程规则，预估潜在风险控制

6.2 测试用例

6.2.1 用例要素

用例编号：每个用例唯一的编号标识

功能点：对应模块-子模块

优先级：用例执行优先级别

用例名称：每个用例应具有的唯一名称

前置条件：包括前提条件和约束条件，若存在特别限制、参数偏差或异常处理，应标识处理，并说明它们对测试用例的影响

用例步骤：指引执行测试的步骤，提高执行效率

期望结果：用例执行期望的正确结果

实际结果：与预期输出比较是否一致，若一致则测试通过，反正测试不通过

测试结果：通过、不通过

备注：用例的补充描述

6.2.2 测试用例质量要求

单个测试用例的质量要求

具有可操作性

具备所需的各项信息

各项信息描述准确、清楚

测试目标针对性强

验证点完备，而且没有太多的验证点（不超过3项）

有太多的操作步骤，例如不超过7步

符合正常业务惯例

整体测试用例的质量要求

覆盖率：尽可能覆盖所有的测试范围、功能特性和代码。

易用性：设计思路清晰、组织结构层次合理，操作连贯性好，使单个模块的测试用例集执行顺畅。

易维护性：以很少的时间来完成测试用例的维护工作，包括添加、修改和删除测试用例。

颗粒度适中：既能覆盖各个特定的场景，保证测试效率；又能处理不同数据输入的测试要求，提高测试用例的可维护性。

6.2.3 测试用例维护

客户需求发生变更，应增加新的测试用例或修改已有的测试用例，删除不再适用的测试用例。

测试过程中，发现一些隐藏相对较深的缺陷，而这些缺陷没有相关联的测试用例，应及时补充相应的测试用例。

随着产品版本的不断升级，测试用例也需要及时维护，必要时进行重构（对测试用例的结构进行调整，包括用例模块的合并和分解），确保每个用例都是有效的，无效用例被置为无效或不可用状态。

对于功能性测试用例，可以从产品特性的分类——功能模块来划分

功能模块来划分，如图：

6.2.4 测试用例与迭代任务关联

每次新增需求，需要增加相应的迭代任务，新增迭代测试用例

本次迭代测试用例，仅用于本次迭代测试任务，与全量测试用例分开

本次迭代任务结束后，用例需要维护到全量测试用例中

本次迭代任务，若用例可复用，可将复用的测试用例和新增的迭代测试用例，统一放入到本次迭代测试用例集

6.2.5 测试报告要素

产品标识

测试系统的系统配置

使用的文档及标识

产品描述、用户文档、程序和数据的测试结论

与需求不符的清单

针对建议的要求不符的清单，产品未作符合性测试的说明

测试结束日期

7 测试流程质量管控

项目风险检查表

8 产品质量度量表

缺陷引入阶段矩阵表

缺陷移除率A、本阶段发现的缺陷数B、本阶段引入的缺陷数C、缺陷遗漏率D

公式：A=B/C*100%、D=1-A

例：需求阶段

1） A=5/92=5.43%

2） D=1-5.43%=94.57%

度量指标

9 项目时间节点

来源：祈盼蔚蓝的天