如何搭建测试质量体系

大家好，我是温大大。

最近群友刚跳槽新公司，公司上面让他建立一套属于自己公司的「质量体系」，所以今天温大大结合自己待过的团队与公司，
跟大家一起唠唠「如何搭建质量体系」，

质量体系的建立这里并非测试人员一方的责任，需要产品、研发、项目经理、运维工程师一起参与来搭建这个体系，QA这边作为「承上启下」的「连接」作用，来全链路确保质量体系的设计与落地。

该篇文章更像是一篇「内功心法」，它没有固定的「招式」，更多的是给同学们一些「搭建质量体系」的「思路」。

目录

1. 质量体系5个流程阶段

• 1.1 需求阶段
• 1.2 研发阶段
• 1.3 测试阶段
• 1.4 交付阶段
• 1.5 运营阶段

2. 质量体系内部各角色作用

• 2.1 产品/项目经理
• 2.2 研发/测试工程师
• 2.3 交付/运维工程师

1. 质量体系5个流程阶段

根据QA业务活动，我们将软件开发分为5个阶段：需求阶段、研发阶段、测试阶段、交付阶段、运营阶段，每个阶段参与人员与对应的业务活动均不同。

所谓的建立「质量体系」就是要梳理这5个阶段：定义参与人员、定义每类人员从事的活动 / 职责、定义每个阶段落地方案。

温大大待过 传统通讯领域、互联网电商领域、兴新大数据领域 的公司，不同领域公司活动不同，所以下面的「质量体系」是综合型的体系说明，可能并不适用你目前公司的体系，只做参考。

1.1 需求阶段

定位：

• 需求阶段主要确保「产品经理」收集整理的「原始需求」能被 研发人员、测试人员、项目经理所认可，

• 各方人员从自个角度认可该需求，例：研发从需求「可实现性」来评判，测试从需求的「可扩展性」来评判、项目经理从需求「可交付行」来评判

人员：

• 项目经理
• 产品经理
• 测试负责人
• 研发负责人

活动：

• 需求评审

流程：

• 1、「项目经理」进行项目立项，然后「产品经理」整合从「客户」那边收集到的「需求」输出 「产品需求规格书，简称：PRD」
• 2、「测试/研发」负责人会跟「项目/产品」经理一起评审「PRD」，几方提出自己对需求的认知与理解。
• 3、「研发」负责人主要从「需求」可实现性角度给出「需求」最终实现大致「技术方案」以及「预计开发完成周期」。
• 4、「测试」负责人主要从「需求」的「扩展性/隐藏性」（指：除了需求A是否还有需求B）提出异议以及大致「测试完成周期」。
• 5、「项目经理」关注2点：第1点是可交付性（例：安装、部署、迁移成本是否太高），第2点是在给客户承诺时间内进行交付。

产出：

• 1、「产品需求规格书」以及 「评审意见」

1.2 研发阶段

定位：

• 研发阶段主要确保产品的「研发设计」与「测试设计」都各方人员所认可：「研发技术方案」与 「测试技术方案」有充分的时间去设计与评审。

• 例：测试工程师主要从方案的「可测试性」、「可恢复性」、「可追溯性」、「可娄底性」方面去考虑，评审通过后研发通过一些工具来完成「编码+自测」（例：单元测试、静态代码扫描、CodeReview），提测后的版本能通过「测试工程师」设计的「准入用例」。

人员：

• 研发工程师
• 测试工程师
• 产品经理

活动：

• 研发技术方案设计 / 评审
• 研发编码 / 自测
• 测试方案设计 / 评审

流程：

• 1、「研发工程师」根据「需求」进行「研发技术方案」设计，这里可能会有一些「难以实现的需求A」会替换成「可实现的需求B」，本质上 需求A 约等于 需求B。
• 2、「测试工程师 / 产品」对「研发技术方案」进行评审，测试主要从「研发技术方案」的 「可测试性，注1」、「可恢复性，注2」、「可追溯性，注3」、「可娄底性，注4」、「是否满足需求，注5」来评估方案「好坏」
• 3、「技术方案」审核通过后，研发进行「编码 + 自测」，会引入一些：单元测试、静态代码扫描、codeReview 一些质量活动。
• 4、「测试工程师」根据「需求」+ 「研发设计方案」进行「测试技术方案」设计，然后让「研发 / 产品」进行「评审」
• 5、「研发工程师」编码完成，「测试工程师」会设计一些「准入测试」用例来确保「版本质量」，若「准入测试」通过后，研发会「正式」提测。

注1:「可测试性」指系统模块设计出来都要求能被测试，若研发无法提供测试方法 或 工具，那么此点就不能满足，可以驳回。

注2:「可恢复性」指系统某些核心模块设计出来能扛住一些「高并发」压测场景、「未知的」异常场景、例：中间件模块不能被压挂，允许缓慢的接受请求，即使遭受「未知场景」挂掉后也要求有「重试机制」能恢复。

注3:「可追溯性」指系统某些服务的状态、日志都是可以被「监控」的，能通过观察该服务的「状态+日志」来判断当前服务的好坏。

注4:「可娄底性」指系统核心功能必须有「娄底方案」，即便该核心功能死掉了、也能有「备选方案」来继续提供「核心功能」的服务。

注5:「是否满足需求」容易理解，指开发的功能与需求匹配，没有存在「遗漏」需求的情况。

产出：

• 1、「研发技术方案」以及 「评审意见」
• 2、「测试技术方案」以及 「评审意见」
• 3、通过GitLab管理代码、通过 禅道管理 测试用例

1.3 测试阶段

定位：

测试阶段主要依靠测试人员来保证「质量」，首先得根据「研发技术方案」+ 项目「承诺交付时间」来制定合理的「测试策略」

测试范围有哪些、

通过什么手段方案来保证：工具？流程？、

每一轮的测试重点都有哪些：冒烟？验收？性能？、

项目中最大的风险是什么：技术？人力？

再根据「测试策略」+ 「测试技术方案」来进行各类测试活动（例：冒烟测试、白盒测试、黑盒测试、压力测试、稳定性测试等）。

人员：

• 研发工程师
• 测试工程师
• 产品经理

活动：

• 测试策略制定
• 冒烟测试
• 白盒测试、黑盒测试、压力测试、稳定性测试、接口测试、验收测试
• 其他类型测试

流程：

• 1、制定合理的「测试策略」，来确保在要求交付时间内能「合格」交付产品
• 2、等待提测后，「测试工程师」会运用各种测试手段来确保「版本」质量
• 3、若遇到有争议的问题，「测试工程师」会让「产品经理」介入来「评判」该实现是否合理

产出：

• 1、测试环境/数据 管理
• 2、测试工具：sonar、jenkins、jmeter、postman、
• 3、测试bug管理：jira
• 4、测试平台：压测平台、自动化测试平台、故障注入平台、部署平台

1.4 交付阶段

定位：

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

• 所以更多的是利用：灰度环境，注1来提前部署发现问题 或 AB切流，注2来小范围验证版本线上运行状况、全链路压测 或 通过定期项目回顾会来回顾之前发现的线上问题，来及时对测试场景查漏补缺。

注1: 灰度环境，模拟一套与线上真实1:1的环境，除了客户不能访问外，其余：网络配置、版本配置、环境配置均已线上一致。

注2: AB切流，对线上客户群划1小部分出来，然后让最新版本部署后推送给这一小部分客户，然后验证该版本是否稳定。

人员：

• 研发工程师
• 测试工程师
• 项目经理
• 交付工程师

活动：

• 灰度环境
• 全链路压测
• 项目回顾会
• 其他业务活动

流程：

• 1、搭建1套「灰度环境」来预先验证最新版本，或通过「AB切流」方式来在线上真实验证版本质量。
• 2、条件允许情况下通过「全链路压测」来验证整个系统的稳定性。
• 3、周期性对上线版本进行复盘，然后「典型问题」专项分析，然后对「测试场景」进行查漏补缺。

产出：

• 灰度环境 1套
• 全链路压测报告 1份
• 「测试查漏补缺方案」1份

1.5 运营阶段

定位：

运营阶段主要确保产品上线后能被「实时观测」，及时的发现「异常」并且能快速的定位「问题」。

人员：

• 运维工程师
• 客服

活动：

• 监控报警
• 排查定位
• 扩容测试

流程：

• 1、「运维工程师」通过建立需「监控指标」集合，对线上的产品进行「全方位」监控，例：系统层面（CPU/IO/内存/磁盘）、业务层面（支付金额猛增、页面访问QPS陡降），具体需要根据实际情况制定合理的「线上监控指标」。
• 2、出现问题后，「运维工程师」如何进行故障排查、问题如何传递给「研发」修复、修复后如何进行线上发布/ 部署，这些需要根据公司情况制定一份合理的「线上bug应急方案」流程。

产出：

• 「线上监控指标」1 份
• 「线上bug应急方案」1份

2. 质量体系内部各角色作用

2.1 产品/项目经理

定位：

参考 1.1章节 「定位」

关键点：

• 产品经理：明确客户「需求清单」、客户前端UI模型
• 项目经理：明确项目启动时间、交付时间、交付清单

2.2 研发/测试 工程师

定位：

参考 1.2/1.3 章节 「定位」

关键点：

• 研发工程师：认可「需求清单」、项目技术难点「识别与攻克」
• 测试工程师：认可「需求清单」、项目测试风险「识别与解决」、提升测试「效率与质量」

2.4 交付/运维工程师

定位：

参考 1.4/1.5 章节 「定位」

关键点：

• 交付工程师：客户现场「环境预发布/全链路压测」、问题定期「复盘与回顾」
• 运维工程师：客户现场「系统监控/问题定位」、拥有「紧急线上问题处理」能力

日常还有很多关于「测试」技术、薪资、面试套路方面的交流，如果你也有一个「加薪」梦，欢迎加入我们，大家一起升职加薪。

关注微信公众号：测试猿温大大，加入我们。