文章目录

前言
质量保障的内容
- 效率工程
- 工程规范
- 内建质量
质量保障实践
- 质量保障第初级阶段
- 质量保障第二阶段
- - 迭代流程管理
  - 需求管理
  - 用例管理
  - 缺陷管理
  - 文档管理
  - 线上问题统一管理
  - - 统一的问题上报入口
    - 线上问题管理
    - 定期的复盘活动
  - 建立初级流水线，提高部署效率
- 质量保障第三阶段
- - 回归体系确立
  - 性能测试
  - 线上监控
  - 代码提交规范的确定
  - git message 提交监控与规范制定
后记

前言

做了也快1年测试了，这边总结一下对业务质量保障体系的建设的一些感悟总结。
首先测试与QA的区别。
测试只是质量保障的手段，交付符合质量的软件才是最终目的，针对不同业务建设不同的质量保障体系才是QA的价值。所以我们不能只满足于做一个tester，而是要以QA的定位对团队做出贡献。
质量保障并不是只是QA的事情，是要靠整个团队的共同努力。

质量保障的内容

质量保障的内容离不开以下三点：

效率工程
工程规范
内建质量

效率工程

测试工具，流水线，devops的建设。所谓质效一体，没有效率，质量就难以获得保障。这边的效率不仅指的是测试效率，也指的是研发效率。如何让每一个程序员专注于业务开发，而不必做那些杂事，比如写了一行代码1分钟，测试部署环境花了10分钟。这是浪费时间的事情，在当前敏捷横行的年代这么做增大了研发的压力，甚至出现延期的风险，质量更得不到保障。这也是各大公司大力推行devops的原因。
测试也是如此，每一迭代有时需要花大量时间做回归，项目周期就会延长，影响交付。这时候自动化测试的价值就出来了。

作为QA需要有一个锐利的眼睛，即发现整个软件研发周期中效率低下的部分，包括需求->研发->测试->发布上线的全流程，并使用技术手段加以提效。

工程规范

俗话说：不成规矩，不成方圆。混乱的项目管理必然增加软件交付后缺陷的数量，让项目有序推进也是质量保障工作的一部分。比如需求管理规范，用例管理编写规范，代码编写规范，每一迭代周期控制等等。这边推荐腾讯tapd，做的特别棒，工程规范一站式管理。其他的禅道什么的也凑合。

内建质量

这边才是真正意义上的测试，包括功能测试，性能测试，高可用测试，混沌测试，变异测试等。

质量保障实践

下面通过效率工程、工作规范、内建质量这3个方面，阐述质量保障在业务中的实际落地情况。

质量保障第初级阶段

当前阶段为项目初创时期，以活下去为目的。这时就需要使用开发主导，实验为先的模式。此时要的不是UI点美观，优秀的性能，快速的做出满足客户需求的功能才是这一阶段的重点。此时项目的重点在于快，重点在于保障版本按期发布，接纳有损发布。代码规范限制研发速度，流程规范只会束缚产品无法快速见用户，只需要轻量的流程保障发布不会出现大纰漏，出现问题能够及时止血，因此对于强制升级功能是核心即可。
这一阶段的基本情况为：

需求管理未规范，word满天飞，管理混乱。
缺陷管理缺失，有问题直接聊天工具沟通，研发人员经常修了那个忘了这个，没有统一的bug反馈渠道。
用例管理全无，测试人员xmind或者excel编写用例。
没有流水线，研发手动部署研发产物。
用户反馈没有统一入口，线上问题不能及时发现

还有一些其他情况，在这一阶段，基本都是纯收工测试，保障新功能以及核心功能的可用性即可，这一阶段就一个字：快！

引用其他文章的话：

基础设施这里更依赖既有的平台和工具来支撑，无暇定制。
流程规范只会束缚产品无法快速见用户，只需要轻量的流程保障发布不会出现大纰漏，出现问题能够及时止血，因此对于强制升级功能是核心即可；
人员管理基本不涉及。整个项目人员12个，人员比较少，沟通问题不凸显，因此未设定各个角色的owner，以及owner对应的职责内容也未形成规范。

质量保障第二阶段

创业成功，项目稳定了，就进入了质量保障第二阶段了，建立工程规范，以自动化手段提高效率。这一阶段要建立需求管理，迭代流程管理，用例管理，缺陷管理等规范，建立统一的用户反馈上报入口机制。在这一阶段，为了让项目平稳运行，靠的是人为规范的约束。

迭代流程管理

定义一个固定的上线时间一周一迭代或者两周一迭代的机制，约束研发，防止乱上线的情况发生。对于目前的项目，其迭代周期如下：

在此期间固定需求评审或者用例评审时间，复盘时间等，根据不同业务形态灵活调整。

需求管理

此时需要一个统一的平台来管理需求，不能再存在各自线下的主机中了，不利于需求的统一管理以及透明化的建设。主要要做到以下几点：

产品建立需求编写规范，让需求的可读性增加，可以让新同学快速理解需求内容。
将编写的需求按照迭代归档，清晰明了的展现当前迭代的需求。
需求分模块归类，便于回顾查询往期需求。
需求状态的确定，比如需求已录入->需求评审通过->编码完成->测试完成->部署完成等。
状态的流转规范，需要研发测试生产同学自觉流转状态。
需求评审阶段确立，需要相关研发测试同学对需求进行评审，并进行工期评估。
对每个需求本身的价值做一个评估，计算出一个估值并确立优先级。

用例管理

用例不是用完就扔，这是软件测试原则的10个原则之一，对于历史用例需要专门的平台进行统一管理。主要做到以下几点。

用例状态，包括正常、废弃。
用例等级，标记什么是核心模块用例等级就为高。
用例类型，包括功能、接口、性能。
分模块管理，将用例分模块，便于回归。
确立用例编写规范，比如前置、步骤、结果。
用例关联需求。

缺陷管理

缺陷管理也是质量保障重要的一环，对缺陷进行全过程的跟踪也是十分有必要的。

缺陷状态的确立，由测试新建缺陷，研发接受缺陷处理分析给予反馈，定位缺陷类型，流转到测试，测试进行回归后关闭bug
缺陷类型的分类规范确定，利于定位问题原因，复盘，下面是分类的一个参考：

需求优化（体验问题、功能缺失或不满足用户侧需求类的，需要通过需求变更/转需求方式解决问题的）
程序bug（程序编码问题导致的，需要修改代码重新部署来解决问题的）
性能问题（程序基本功能正常使用，但在高并发场景下存在卡顿、异常的情况，需要通过性能优化来解决问题的）
基础设施（使用的公司内部基础服务导致问题的，如网络异常、中间件问题、云服务问题、taf平台问题、sumeru平台问题、stke问题、其它）
线上维护（程序运行使用相关的维护工作导致问题的，如配置、数据库操作、数据更新、部署平台操作等）
运营问题（产品运营过程中计划、人为不当操作、脏数据等原因导致的）
合作方问题（与外部合作方交互且因合作方产品存在问题导致的）
无效问题（无需解决、人为无效操作问题、无法复现归为此类）

缺陷编写规范的确定，经常会存在bug提太多，bug单太潦草导致测试回归的时候不知道自己当时写了什么，有时候研发也看不懂bug单的内容，沟通效率低下，就需要一个bug单编写规范约束测试人员提单，下面是一个参考：
【问题描述】：填写出问题的任务id，情报id，url等信息，简要描述问题现象
【详细步骤】：作业员如何操作出现相关问题
【预期结果】：正常情况下的结果
【实际结果】：当前出现的结果
【附件】：附带截图，视频，方便定位问题
缺陷原因的填写，每个bug都存在其原因，在研发解决问题后督促其填写原因方便复盘。
缺陷关联需求，做到每个缺陷都能到找引起这个缺陷的需求是什么，这样可以不断学习，更利于精准回归工作的开展。

文档管理

对于一些设计文档，会议纪要，重要文件，也应当统一管理，方便存取，提高效率。尤其是研发的接口文档，这个是做接口回归测试的重要参考，不维护的话对于新同学快速接入业务是存在很大的困难的，也不利于研发查询过往接口信息。

线上问题统一管理

线上问题是需要高度重视的，更需要做到细致的管理，形成从入口到出口再到复盘的闭环。

统一的问题上报入口

确定自己业务对应的是什么用户，需要给用户提供统一的上报入口，这样既能够方便线上问题的管理，也让用户有地方可以吐槽产品的不足，方便项目成员快速发现线上问题并及时修复。根据不同业务需求可以自定义上报入口，当前业务使用自研供应商反馈平台issue进行上报。

这边需要制定反馈上报规范，拒绝乱报的情况发生。某些业务必要的时候可以加AI识别拦截等功能。

线上问题管理

一旦用户上报了线上问题，就会流入统一的问题管理平台，这个平台的功能与缺陷管理类似，包括缺陷状态，缺陷类型，缺陷原因，上报时间等属性，必要时还可以加入其他属性，比如问题影响，问题损耗等等。

定期的复盘活动

复盘目标：总结归纳线上问题出现的根因，指导改善测试/开发/线上活动，提升产品质量

复盘内容：

问题根因分析中的线上有效问题，主要为程序bug、性能问题
复盘参与人员：复盘涉及问题的所有相关负责人员，相关测试人员为必要参与人员
复盘时间：每周组织一次进行总体复盘
复盘结果：结果输出为线上问题分析单
根因-测试：测试人员未发现问题的原因
根因-研发：研发人员写bug的原因
改进措施：将来怎么改进

定义线上事故的标准，一旦出现线上事故，立马进行复盘。

建立初级流水线，提高部署效率

建立持续集成，一键部署机制，提高发布效率，节约时间.

至此，质量保障第二阶段告一段落，这一阶段是项目进入平稳期创业成功后需要制定的事情。

质量保障第三阶段

进入第三阶段，项目已经做大做强了，此时对质量的要求肯定更高了。功能点也多了起来。此时重点就转移到了效率上。就要往回归体系的建设，性能测试，稳定性测试，工程效能方向迁移。当前项目还处于第二阶段，等阶段到了再具体说。

回归体系确立

包括回归用例的确立
回归用例的研发
流量回放机制的制定

性能测试

用户量一大，难免对性能这一方面有了较高的要求，就需要性能测试了。

线上监控

包括

线上错误日志监控，帮助研发快速定位问题，找出问题堆栈.
线上慢接口监控分析体系的搭建.

代码提交规范的确定

写出符合规范的代码可以增加易读性，减少bug的发生几率。对每次提交的代码做静态代码扫描，扫描出问题，让研发及时修复问题。

必要时加入拦截功能。

git message 提交监控与规范制定

目的在于打破测试研发产品沟通壁垒，让每次代码提交透明化

参考规范：

commit message格式
type: subject
注意：冒号后面有空格

type 用于说明 commit 的类别，只允许使用下面7个标识

feat ：新功能（feature）
fix ：修补bug
docs ：文档（documentation）
style ：格式（不影响代码运行的变动）
refactor ：重构（即不是新增功能，也不是修改bug的代码变动）
test ：增加测试
chore ：构建过程或辅助工具的变动
subject 是commit代码的简短描述，末尾不加标点符号
例子
feat: 地图导航功能增加

必要时加入拦截功能

后记

最重要的是怎么让规范落地，如何说服他们执行这套规范，有人不执行怎么办，所以靠人为的约束并不是最好的解决方法，如果说靠技术来约束，会起到不错的效果，目前在探索中。

浅谈业务质量保障体系的建设相关推荐

浅谈语音质量保障：如何测试 RTC 中的音频质量？
简介:日常音视频开会中我们或多或少会遭遇这些场景:"喂喂喂,可以听到我说话吗?我听你的声音断断续续的","咦,我怎么可以听到回声?","太吵啦,我听不 ...
国信证券OA系统及质量保障体系信创建设：泰山服务器、麒麟操作系统、东方通中间件、达梦数据库、蓝凌软件、毕昇JDK
信息技术应用创新(简称"信创")是国家重点战略,其目标是建立我国自主可控的IT底层架构和标准.国信证券作为证券行业第一批试点单位于2020年6月启动办公系统(以下简称OA系统)信创 ...
ToB质量保障体系建设思考
互联网企业向ToB转型要实现"高质量.低成本.高效率"交付的目标,需要构建一套完整的质量保障体系.通过总结行业质量保障的最佳实践,结合对ToB业务和互联网的业务的理解,个人认为质量 ...
全球化安全生产质量保障体系建设探索
作者:肖刚毅.张俊.李晶磊(全球化业务平台团队) 全球化电商中的业务.技术及架构和国内技术都有一定差异,从安全生产保障和质量保障角度,这些差异带来了更多的挑战,本文将为大家分享安全生产和质量保障相关的 ...
得物交易域数据仓库数据质量保障体系建设 |大数据测试
一.背景介绍目前得物数仓测试,划分成交易.增长.社区等多个模块,不同的数仓测试域,都会有一名测试人员负责跟进,根据每个版本每个域资源实际投入情况,组内会适当的调整资源,以满足日常迭代需要:单交易域这 ...
质量保障体系建设演进案例
在业务早期发展阶段,主要是产品驱动.研发和测试互相配合.不同的测试方法是验证和保障交付质量的手段,而不是构建质量体系的基石.测试的努力带来的更多是一些"安全感",而非安全保障.因此 ...
SLA 4 个 9 ，贝壳高可用架构的质量保障体系
导语 | 贝壳用户需求和用户量的不断增长,对系统的高可用性提出了更高的要求,服务端的质量保证工作该如何开展?本文是对贝壳找房-基础平台中心-质量平台赋能部总监--项旭老师在云+社区沙龙online的分 ...
研发质量保障体系搭建
质量保障体系的搭建,并非测试人员一方的责任,需要产品.研发.项目经理.运维工程师一起参与来搭建这个体系. 一.研发流程阶段 1. 需求阶段需求阶段主要确保「产品经理」输出的原始需求能被项目经理.研发 ...
测试用例优先级划分_全面的质量保障体系之测试用例分级
在<全面的质量保障体系之发现缺陷>中提到测试用例分级的应用,以最少的测试用例实现覆盖更多的测试场景,以提高测试的精准度.测试用例分级是每个公司都在做的事情,但如何精细化的做好测试用例分级, ...

浅谈业务质量保障体系的建设