浅谈业务质量保障体系的建设_业务质量包括哪些内容呢

前言

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

质量保障的内容

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

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

效率工程

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

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

工程规范

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

内建质量

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

质量保障实践

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

质量保障第初级阶段

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

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

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

引用其他文章的话：

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

质量保障第二阶段

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

迭代流程管理

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

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

需求管理

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

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

用例管理

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

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

缺陷管理

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

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

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

3. 缺陷编写规范的确定，经常会存在bug提太多，bug单太潦草导致测试回归的时候不知道自己当时写了什么，有时候研发也看不懂bug单的内容，沟通效率低下，就需要一个bug单编写规范约束测试人员提单，下面是一个参考：
   【问题描述】：填写出问题的任务id，情报id，url等信息，简要描述问题现象
   【详细步骤】：作业员如何操作出现相关问题
   【预期结果】：正常情况下的结果
   【实际结果】：当前出现的结果
   【附件】：附带截图，视频，方便定位问题

4. 缺陷原因的填写，每个bug都存在其原因，在研发解决问题后督促其填写原因方便复盘。

5. 缺陷关联需求，做到每个缺陷都能到找引起这个缺陷的需求是什么，这样可以不断学习，更利于精准回归工作的开展。

文档管理

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

线上问题统一管理

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

统一的问题上报入口

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

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

线上问题管理

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

定期的复盘活动

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

复盘内容：

1. 问题根因分析中的线上有效问题，主要为程序bug、性能问题

2. 复盘参与人员：复盘涉及问题的所有相关负责人员，相关测试人员为必要参与人员

3. 复盘时间：每周组织一次进行总体复盘

4. 复盘结果：结果输出为线上问题分析单

5. 根因-测试：测试人员未发现问题的原因

6. 根因-研发：研发人员写bug的原因

7. 改进措施：将来怎么改进

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

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

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

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

质量保障第三阶段

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

回归体系确立

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

性能测试

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

线上监控

包括

1. 线上错误日志监控，帮助研发快速定位问题，找出问题堆栈.

2. 线上慢接口监控分析体系的搭建.

代码提交规范的确定

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

必要时加入拦截功能。

git message 提交监控与规范制定

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

参考规范：

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

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

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

必要时加入拦截功能

后记

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