研发质量保障体系搭建

质量保障体系的搭建，并非测试人员一方的责任，需要产品、研发、项目经理、运维工程师一起参与来搭建这个体系。

一、研发流程阶段

1. 需求阶段

需求阶段主要确保「产品经理」输出的原始需求能被项目经理、研发人员、测试人员所认可。

1.1 流程概述

1. 「项目经理」进行项目立项，「产品经理」收集、整理各方需求，并输出产品需求规格书，即PRD
2. 「项目经理」、「研发负责人」、「测试负责人」对PRD进行评审，并提出意见或建议
3. 「产品经理」根据需求评审的结果进行评估分析，并对PRD进行修订
4. 「项目经理」、「研发负责人」、「测试负责人」针对修订后的需求进行二次确认，评审通过后，需求定稿存入项目空间。定稿后的需求在核心要点上不允许进行随意变更，如需变更则需走需求变更流程
   （这里产品要输出的东西需要补充：需求说明书、UI设计等）

1.2 需求评审

评审要点：

• 正确性：
  • 是否清晰准确的陈述了要开发的功能
• 完整性：
  • 正常场景、异常场景是否均有考虑到
  • UI、交互设计是否完整
  • 流程类需求是否有清晰的流程图
  • 是否存在隐藏的需求
• 合理性：
  • 是否与现有功能冲突，存在冲突时是否有兼容方案
  • 用户体验是否合理
• 可行性：
  • 需求中的功能是否具有可操作性，能否通过现有技术实现
• 可测试性：
  • 是否每项需求均有验证的标准及方法，可通过设计测试用例或者其他验证方法来进行测试
• 可交付性：
  • 评估是否能在规定时间内进行交付
  • 交付成本是否过高，例如部署、迁移
• 无二义性：
  • 需求是否存在模糊描述，例如：同已有逻辑
• 分配优先级：
  • 是否对所有需求都进行了优先级分配；若所有需求都一样重要，那么在项目管理过程中便无法灵活管控资源及进度

评审人员：
项目经理、产品经理、测试负责人、研发负责人

1.3 规范

1、统一的需求文档模板、交互设计规范说明、UI设计规范说明
2、评审必须登记评审记录和会议纪要。记录包括时间、评审项目、评审内容、参与人员、主持产品经理（项目负责）、内容纪要、记录人
3、产品需求评审通过，即锁定需求内容。如无十分必要不能随意变更
4、需求变更需走变更流程，并征得研发、测试、项目经理一致认可

2. 研发阶段

2.1 流程概述

1. 「研发负责人」针对需求进行研发方案设计，并组织「产品经理」「测试负责人」进行评审
2. 「研发负责人」对开发任务进行拆解、排期，并指派到个人
3. 「研发人员」进行开发实现并联调
4. 「研发负责人」组织完成代码review、研发自测，自测通过后进入版本提测
5. 「运维人员」就研发提测的版本，部署到测试环境，交付给「测试人员」

2.2 研发设计方案

1. 研发方案设计
   研发的技术方案里至少需要包含：

   • 需求说明：
     • 需求背景
     • 需求拆解
   • 概要设计，包含系统现状、总体设计思路、系统架构图、系统流程图
   • 详细设计：
     • 接口设计：提供接口设计文档，包括入参出参字段定义，接口参数校验逻辑，异常情况的处理和返回的错误码。
     • 系统间交互流程：结合系统间流程图说明整笔业务请求涉及哪些系统组成部分，业务的发起来源，系统间交互调用了具体哪个接口，请求处理基本步骤和数据落地存储逻辑。
     • 系统内处理流程：结合业务处理流程图说明请求如何加工计算数据，处理的具体步骤，最终处理完成之后结果如何保存，或者传输到什么地方。
     • 存储设计：包括存储结构（包括MySQL、ES、Redis、OSS等）设计，包括表和字段的概念定义，各个表之间的关联，业务系统如何使用这些库表。
     • 安全问题：数据安全、接口安全

2. 研发设计评审
   评审要点：

   • 正确性
     • 技术设计是否可以满足业务需求中的全部功能要求？
     • 对异常场景考虑是否充分？
   • 可测性
     • 是否可测？
     • 预期结果是否稳定？
   • 非功能性
     • 是否考虑了安全性、性能、稳定性、扩展性、可靠性等非功能质量属性？
   • 兼容性
     • 对不同形态和版本的终端是否兼容？
     • 对上下游的服务和数据是否兼容
   • 部署方案
     • 部署逻辑是否合理？
     • 是否需要对数据结构、缓存、各类配置进行操作？

   评审人员：
   项目经理、研发工程师、测试工程师、产品经理

2.3 研发自测

【参与人员】开发
○ 【用例占比】所有核心主链路用例（P0、P1）用例；
○ 【通过标准】完成冒烟用例的验证，测试会验证开发同学的冒烟结果，通过后，需求进入提测阶段，否则打回重新冒烟

3. 测试阶段

测试阶段主要是通过测试策略、测试用例以及一系列的测试手段等确保版本质量。

3.1 流程概述

1. 根据需求功能、研发设计方案，结合现有测试资源、测试能力，制定合理的测试计划，来确保能够在规定时间内交付产品
2. 「测试工程师」根据分配的任务进行测试用例设计，并组织「产品经理」、「研发工程师」进行评审定稿
3. 版本提测后，「测试工程师」对系统进行冒烟测试，检验版本是否达到测试准入标准，若准入验证通过则进行大规模测试，若不通过则版本打回研发
4. 版本正式提测后，「测试工程师」根据制定的测试计划，运用各种测试方法对系统进行测试，以确保版本质量
5. 版本测试通过后，由「测试负责人」输出测试报告，并就遗留缺陷组织「项目经理」「产品经理」进行评审确认是否可遗留

3.2 测试计划

1. 测试计划制定：
   由测试负责人根据需求、研发设计方案、交付时间、资源情况评估，制定测试计划，确保版本可如期交付。

   测试计划核心要素：

   测试范围：新功能、旧功能，分别需要覆盖哪些
   测试时间：什么时间测试开始，什么时间结束
   测试策略：需要安排几轮测试？每一轮的测试重点有哪些？需要运用哪些测试方法（性能、安全、稳定性测试等）、测试工具？
   测试环境：在什么环境测？环境配置要求如何？
   测试资源：需要哪些人力资源投入，资源如何安排
   风险控制：识别的风险有哪些？对应的解决方案？

   测试计划制定规范：后续补充文档

2. 测试计划评审：
   评审要点：

   • 测试环境：测试环境要求是否清晰，是否可提供
   • 测试范围：
     • 是否覆盖了业务和技术需求？对于已有功能是否安排了必要的回归？
     • 是否存在测试过度？
   • 测试优先级：对待测模块是否进行了优先级分配
   • 测试策略：
     • 安排的测试轮次是否合理？是否包含包含基础的冒烟、验收等测试
   • 风险控制：项目风险是哪些？（资源、技术）是否有对应的解决方案？

   参与人员：项目经理、产品经理、研发负责人、测试工程师

3.3 测试用例

1. 测试用例设计
   可参考文章：测试用例规范

2. 测试用例评审
   评审的时间不宜过早或过晚，一般提测前2天左右完成；单次评审时间不宜超过1个小时。

   评审要点：

   • 测试范围：测试用例是否覆盖了业务和技术需求？对于已有功能是否进行了必要的回归？
   • 异常情况：用例是否考虑了非常规操作或其他异常情况？
   • 易读性：测试用例是否包含前置条件、操作步骤、期望结果等必要信息？
   • 非功能性设计：针对非功能性的需求和技术设计，测试用例是否设计充分？

   通过标准：
   确定用例覆盖所有设计的功能点，且明确每个用例的验证点

   评审人员：
   产品经理、研发工程师、测试工程师

3.4 环境准备

1. 测试环境部署，确保基础环境搭建到位
2. 应用服务架构，架构尽量与生产环境一致
3. 测试数据构造
4. 客户端设备，例如测试移动端产品，则需兼容的设备机型、版本需提前准备就绪

3.5 测试准入

制定测试准入标准，若满足标准则进入SIT测试阶段，若不满足则进行整改，直至满足后方可进入下一阶段。

测试准入条件：

1. 需求规定的功能均已实现
2. 研发自测通过率95%以上
3. 测试用例已设计完毕，并评审通过，更新至用例管理平台
4. 测试环境、工具、数据已准备就绪
5. 测试用例在管理平台已完成分配指派
6. 冒烟测试用例执行通过率95%以上

3.6 测试执行

根据测试计划、测试策略要求，对待测系统服务进行功能测试、性能测试、安全测试等。测试执行过程中核心保障测试进度管理、缺陷管理。

1. 缺陷管理
   缺陷标准规范，参考：
   BUG描述规范
   BUG处理流程规范

2. 进度管理

   • 严格按照测试计划确定的优先级进行测试任务的执行
   • 测试进度日报；测试执行人员每天按统一的模板汇报各自的测试进度及关键问题，测试负责人汇总后，再按统一的模板整合汇报到项目组，汇总的进度日报里关键信息需包含整体测试进度、活跃BUG统计、关键问题、主要风险等
   • 测试范围变更管理；包括对需求变更、人员请假、环境异常、优先级调整等导致的测试策略、测试计划变更，需严格控制变更情况，若有风险，需及时沟通解决

3.7 测试报告

测试报告规范后续补充

3.8 测试准出

测试准出条件：

1. 被测项目满足产品需求
2. SIT测试覆盖率100%
3. 已输出测试报告
4. P0、P1、P2级BUG修复率100%
5. P3、P4级BUG修复率95%以上
6. 遗留问题均已评审通过，并有解决方案（延期处理/暂不处理/转需求/挂起等）
7. 性能指标符合要求

4. 交付阶段

交付阶段主要确保产品发布后，能完整、稳定在客户线上环境运行。

4.1 流程概述

1. 「项目经理」「产品经理」对产品进行UAT验证，必要时还需要业务方参与，确认需求实现满足业务方要求
2. 发布材料准备：
   • changelog说明，由「产品经理」准备
   • 用户培训手册，由「产品经理」准备
   • 服务版本号，由「测试经理」最终确认，并同「研发人员」「运维人员」达成一致
   • 遗留问题列表，由「测试经理」准备；需注意这里的遗留问题必须是项目组评审通过的
   • 测试报告，由「测试经理」准备
3. 上线发布方案，由「测试经理」组织「研发人员」、「运维人员」制定，方案包括：数据库脚本执行、各服务发布版本号、部署顺序、部署时间点、部署回滚方案（包括数据库回滚和应用程序回滚）等
4. 线上功能checklist，由「测试经理」准备，用于发布后对线上环境的功能回归，时间需控制在1个小时内
5. 执行发布流程，由「DBA」、「运维人员」按计划执行发布流程，由「研发人员」核对部署与配置的正确性，最后由「测试人员」进行功能checklist执行，验证结果及问题反馈到开发处，严重问题若无法在计划时间内解决则执行回滚方案，不影响功能的问题则进行记录，遗留后续迭代计划处理

4.2 预演方案

如发布流程复杂，不可控因素较多，可视情况组织发布预演练。即在指定环境模拟一遍正式发布的流程。方案上基本同正式发布一致，区别仅在于操作的环境。
演练过程需记录每个流程的耗时及问题点，演练结束后组织复盘，并针对问题点进行流程的调整优化。

4.3 上线方案

上线方案主要明确发布流程的每一个步骤、预计执行时间、负责人及问题解决预案，确保版本能正常部署到生产环境。

发布前

• 服务升级配置表，确定服务器CPU/内存规格、环境变量配置、业务配置等；配置需提前梳理并由研发、运维确认无误
• 发布平台、数据库权限临时开放给对应人员
• 各模块上线checklist定稿
• 数据执行脚本核对

发布中

• 数据备份
• 数据脚本执行流程
• 各服务部署先后顺序及预计执行时间
• 服务间依赖关联，启动顺序约定

发布后

• checklist执行验证

风险及解决方案

• 关键环节的风险预判及应急预案
• 服务回滚策略及流程
• 数据回滚策略及流程

4.4 线上checklist

1. 开发部分
   主要负责确保服务部署的正确性。checklist内容至少需包含如下：

   • 服务版本号是否正确
   • 服务配置检查，例如服务器CPU/内存规格等、环境变量、业务配置
   • 服务启动是否正常，健康状态是否正常等
   • 服务日志接口是否有异常报错
   • 数据迁移校验，数据正确性

2. 测试部分
   主要负责验证线上环境核心功能流程可正常运行。

   功能checklist
   checklist设计完后需组织产品经理、研发经理、项目经理进行评审。
   checklist的设计部分需遵循：

   • checklist的目的主要是保障核心功能流程正常，而非SIT阶段的BUG挖掘，所以在用例设计上，要区别于功能用例设计
   • 需区分哪些可自动化覆盖，哪些需要人工验证
   • 需分配指派到人，并且整体验证时长需控制在1个小时内

   全链路压测
   核心验证系统稳定性。需提前确认压测场景、压测时长，并组织评审通过

5. 运维阶段

版本发布上线后，还需要确保能够实时监控，及时发现异常并告警，在规定时间内进行定位解决，保障生产稳定性。

5.1 监控告警

明确监控方法、监控指标、告警机制。
具体后续补充

5.2 故障处理

故障处理流程规范，后续补充

二、持续集成持续交付 CI/CD

明确各种“类生产环境”的作用及差异点，保障环境稳定可用；常见环境划分包括：

• 开发环境
• 测试环境
• 预发布环境
• 生产环境

基于以上环境，将各种测试技术和自动化技术集成起来，使代码提交后能 自动构建、部署、测试，生成工具链。

三、测试体系建设

1. 效率

1、测试左移：

• 做好过程质量把控，包括需求评审、研发设计评审，减少无效返工
• 研发自测推进，由测试提供研发自测用例，或研发提供测试评审，推进研发自测，提升版本提测质量 并通过测试准入验证，把控研发提测质量
• 制定测试准入标准，设计冒烟测试用例，如果冒烟测试通过率<90%，则提测版本打回开发

2、测试策略：
旨在减少不必要的测试，尽早暴露重点问题并推进解决。有效的测试策略，能最大限度提升测试效率。

常见测试策略制定：

• 冒烟测试：只验证核心功能链路，不需要细测，暴露出影响流程的BUG；冒烟测试的用例通常选择BVT用例执行
• 第一轮：新功能全面细测，旧功能只测试BVT+高等级用例，尽可能挖掘所有能发现的BUG
• 第二轮——第x轮：验证上一轮BUG，并根据上一轮测试情况，调整本轮测试策略
• 回归测试：验证全部BUG，所有功能进行BVT+高等级用例测试，保障核心功能流程

以上仅供参考，实际需根据项目具体情况进行调整

3、自动化测试：

• 根据业务特点，构建核心功能链路自动化能力，用于冒烟验证、发布集成回归，来提升交付效率，常见有接口自动化、UI自动化，需根据项目及团队情况选择合适的自动化手段；

  自动化测试效益分析：
  ROI = 自动化提升的效率/自动化产生的成本 = （手工用例执行的时间 - 自动化用例执行时间）* 自动化用例的有效执行次数 / 自动化用例编写和维护的总成本

• 持续集成与持续交付

4、专项解决痛点：

• 分析实际影响效率的痛点问题，制定对应的解决方案；不限于工具支撑、人员补充、人员培养等
• 缺陷辅助定位工具；在研发测试阶段，我们有大量的开发工作量实际是耗费在缺陷的确认、重现、定位、修改、验证上，对于疑难或概率性缺陷若有工具能辅助定位分析，则效率能大大提升

2. 质量

1、测试模型
基于深入了解行业产品特性，产出测试模型，包括但不限于： 业务流程、业务特性树、业务场景等。测试模型构建的合理性和完整性是后续质量保障的基础

2、测试规范
遵循制定好的规范，减少过程无效沟通及返工。包括但不限于：用例编写规范、测试过程规范、BUG编写规范、BUG处理规范、压测规范等

3、测试技术

• 接口测试
  接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等

  为什么要进行接口测试
  1.越底层发现bug，它的修复成本是越低的。
  2.前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。
  3.检查系统的安全性、稳定性，前端传参不可信。
  4.如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。
  5. 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
  6. 现在很多系统前后端架构是分离的，从安全层面来说做接口测试很有必要。

  接口测试工具：Postman、Jmeter、Apipost

• 安全测试
  渗透测试，以成功入侵系统，证明系统存在安全问题为出发点，以攻击者的角度来看待 和思考问题

  安全测试工具：Burp Suite 、AppScan、Nmap、kail Linux等

• 性能测试
  性能测试是通过增加用户请求访问量来测试软件或应用程序的稳定性及响应时间。
  目的是验证软件系统是否能够达到需求提出的性能指标，同时发现软件系统中存在的性能瓶颈。

  性能测试工具：LoadRunner、Jmeter等

• 全链路压测
  微服务架构下，单服务接口性能测试很难模拟出接近生产环境的场景和数据规模，单接口压测通过并不能代表整个系统链路的性能。尤其是QPS 比较高的场景，如果不进行全链路压测，只要链路中一个环节挂掉，就会引起整个链路的崩溃。

  全链路压测是基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据，对整个业务链路进行各种场景的测试验证，持续发现并进行瓶颈调优，保障系统稳定性。

  全链路压测的目标

  • 实现生产环境的压测服务，模拟真实的生产峰值场景，以发现真实的线上瓶颈并实现监控分析
  • 实现精准的容量规划，确保线上系统的正常运行
  • 实现压测流量和生产流量的隔离，避免对生产流量产生影响

• 其他专项测试
  同样在微服务背景下，很多企业项目开始进行容器化部署。为应对Kubernetes+Docker+微服务部署模式的特性，提高测试质量，在测试技术上也衍生出各种专项测试技术，例如：
  1、系统容灾测试：
  通过模拟断电、断网、服务崩溃等异常情况，验证系统的健康状态监视和异常情况下的功能切换、系统恢复能力
  2、pod弹性扩缩容测试：
  通过模拟用户请求，增大/降低系统服务负载，验证服务是否能在负载大的时候，自动进行扩容，确保所有请求能正常响应，当负载小的时候自动进行缩容，以避免资源浪费。弹性扩缩容的测试验证除了关注功能本身外，还需要关注扩容、缩容的速度；缩容策略，例如当有请求还在被指定缩容的pod上时，如何能确保不影响用户正常使用
  3、服务负载均衡测试：
  单台服务的负载是有限的，当负载较大时，就需要有多台相同的服务器，此时为避免流量全部打到同一台服务上导致负载过大而异常，就需要有负载均衡策略调配，控制流量的走向。而测试则通过工具模拟请求，验证负载均衡策略是否合理，是否能正常生效
  …等等

3. 组织过程资产

通过制定标准组织过程资产沉淀模板和节奏，保障过程资产有效沉淀，可以复用。

组织过程资产包括：
1、空间目录
例如下图，实际可根据内部情况调整
2、流程规范
包括但不限于测试流程定义、测试计划模板、测试用例模板、报告模板、缺陷规范、发布规范等

• 流程定义
  规定项目流程中所需的活动、活动阶段、负责人等，包括：项目立项、里程碑确定、需求评审、用例设计、测试计划、测试执行、测试总结、UAT试用、版本发布、过程质量管理
• 标准定义
  质量标准定义：测试覆盖率、有效BUG率、整体漏测率、BUG收敛情况等
• 文档模板
  包括测试计划模板、测试用例模板、测试报告模板、缺陷登记模板等
• 测试用例库
  功能用例库、自动化用例库

3、测试方法沉淀
各类测试方法、测试技术沉淀（接口测试、自动化测试、性能测试、安全测试、专项测试等）

4、固资管理
例如：测试环境信息、测试设备信息维护

5、业务知识库

6、培训材料
内部分享课程材料

四、度量与运营

“你如果无法度量它，就无法管理它”

1. 质量度量指标

过程质量：

• 需求质量
  • 需求评审打回次数
  • 需求变更次数
  • 需求增加次数
  • 需求质量BUG数
• 开发质量
  • 提测质量
  • 测试准入打回次数
  • 代码质量
  • P0/P1 BUG占比
  • BUG工时比
• 测试质量
  • 测试覆盖率
  • 有效BUG率
  • 整体漏测率
  • BUG收敛情况
• 发布质量
  • 发布回滚率

交付质量：

• 线上故障：线上故障数、故障级别、线上故障恢复时长、线上缺陷数
• 服务稳定性：服务可用性、错误类型分布、错误数量、错误率、报警数
• 服务可用性：度量线上服务的性能，接口响应时间、慢响应率、慢查询、最大QPS
• 服务安全性：安全漏洞严重问题数

2. 效率度量指标

• 交付周期比、工时比

3. SMART原则

• 具体的 specific
• 可度量 measurable
• 可达到 attainable
• 与其他目标有相关性 relevant
• 有明确的截止期限 time-bound

4. PDCA闭环

• Plan 制定改进计划
  • 质量痛点驱动
  • 质量目标驱动
• Do 实施落地计划
  • 数据收集和聚合
• Check 复盘和反馈
  • 书面总结报告
  • 复盘总结会
• Action 改进和推广

五、质量文化建设

想把质量做好，流程和方法是"术"的层面，文化是“道”的层面。文化是组织成员表现出来的共同的信念、价值观、态度、制度和行为模式。

在大多数质量保障体系推行过程中更多关注的是可见的质量标准、要求、操作程序等，换句话说，也就是被要求应该如何做，而不是主动、自发的质量意识和行为。

质量文化的建设应该自上而下，由高层主导构建文化，并推行以获得质量认知统一，让所有人参与到持续改进中，辅以一系列奖惩制度。