如何搭建测试质量体系

大家好，我是温大大。

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

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

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

质量体系5个流程阶段

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

质量体系内部各角色作用

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 章节「定位」

关键点：

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

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

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