如何搭建测试质量体系

大家好,我是温大大。

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

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

如何搭建测试质量体系_第1张图片

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

目录

  1. 质量体系5个流程阶段
  • 1.1 需求阶段
  • 1.2 研发阶段
  • 1.3 测试阶段
  • 1.4 交付阶段
  • 1.5 运营阶段
  1. 质量体系内部各角色作用
  • 2.1 产品/项目经理
  • 2.2 研发/测试工程师
  • 2.3 交付/运维工程师

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

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

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

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

如何搭建测试质量体系_第2张图片

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

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

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

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

你可能感兴趣的:(温大大面试群,功能测试)