如何保证项目质量？层层卡点，一次把事情做对！

绝地灬酷狼 2024-03-16 13:22 21阅读 0赞

### 0 前言 ###

工期太紧，能按期提测不错了，Bug多一点正常。质量好不好？不好说。如何提升？不知道，QA会保证呀。

我的粉丝里大部分程序员对自己代码质量要求还是很高的。可当遇到赶工压力，尤其Deadline前，就很可能把完成度很低的代码交出去，心想“反正有人CR，到时再说”。但此时，这些代码好比“行走的Bug制造机”，后患无穷。

我曾在一个技术债严重部门，面向各级程序员做过一轮抽样访谈调研。结果程序员只有27.2%时间在做真正产生价值的编码工作。但他们花20.7%的时间，进行需求质量和代码质量问题所引发的Bug修复、返工和紧急上线工作。

质量成本分两类：

*  事前防止失败的一致性成本
 *  事后处理失败的非一致性成本，包括内部Bug引发的返工成本，以及外部Bug导致的用户侧成本

近年，越来越多公司严格控制测试人员比例，鼓励开发通过各类技术手段从上游保障质量，因为越发认识到：事后检查处理代价最高。

质量是规划、设计、建造出的，而非检查出的。 **预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多**。

我们都懂一次性把事做对的成本最低。而一次把事做对意味着，我们要有意识提升预防类工作的占比，从根本降低内部Bug率、外部Bug率。在这质量改进过程中，开发是绝对关键力量，而非测试。

作为项目管理，如何更好规划质量管理活动？

### 1 质量规划，明确标准 ###

**规划质量，是识别项目及产品的质量要求和标准，并确定用哪些质量保障方法、过程改进措施来达到这些标准的过程**。

**在业务生命周期的不同阶段，质量标准应动态变化**。如业务初创期追求最小化MVP模型快速迭代，质量不是最关键因素。但规模扩张一定程度后，质量要求就很高了。不同项目对质量要求也相差甚远，不能一概而论。 **只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义**。

#### 稳定业务对客户端质量标准的定义 ####

![426986ed5372a265dd4f26f2aaa2e053.png][]

定义好质量标准，之后要思考整个项目进程中，需规划好哪些质量保障活动，以很好达标。

#### 各阶段的质量保障手段 ####

特别关注研发过程中的质量保障手段，制定适当编码规范、提交规范和分支规范，同时设计代码准入标准，CR、UT、接口验证和UI验证，确保这些手段与你的项目质量要求匹配：

![5c7effc4c9960a90af20a0dd5c828cff.png][]

项目经理的视角始终聚焦项目整体目标。在项目经理看来，质量作为目标的一部分，达到要求最重要，无需追求质量的无止境提升。因为，质量也要代价，是否够用取决于项目目标和要求。

### 2 质量分析，追根溯源 ###

质量分析，是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并制定相应的预防措施和解决方案。

曾给一个底层核心模块的技术团队做项目管理，上层模块经常抱怨它的质量，有时甚至在关键流程都有问题，团队内外都对其质量失去信心。

数据上看，该模块线上Bug量占项目总Bug量17%，给上层其他模块和运维都带来大量麻烦。随越来越多外部应用接入，若这问题得不到解决，内部矛盾可能升级为外部矛盾！

#### 2.1 定位问题 ####

*  团队扩张很快，长时间内，测试人员配比都很低，8开发对0.5测试。测试基本只给开发打工，只保证最基本功能，其他更深度测试类型无法涉猎
 *  没从用户视角检验产品，上层模块的应用场景、运维的应用场景与测试视角相差大，测试效果难保障
 *  五分之一线上Bug来自社区，用户侧问题后才去社区找，再把补丁合进来，无主动应对

根据用户调研结论，用户对底层核心模块的期望更多是稳定，对新需求，用户普遍表示暂无需要。因此，盲目增加复杂功能不明智，保持产品简单可靠是王道。

#### 2.2 改进或预防措施 ####

*  新功能适当放慢：基本功能成型情况下，进一步控制新功能开发在迭代中的占比与优先级。当时定义不超过70%，在一定时期内，核心功能不再做大变动
 *  回顾总结：将线上Bug分析作为周会固定内容，集体讨论整体层面的改进措施，并跟进实施到位
 *  查漏补缺：对已有测试用例进行全面梳理，与相关开发、测试、运维集体Review完善，花大力气补充测试代码（增加异常、并发、稳定性测试等）。考虑这是长期工作，要确保将其分解到各迭代，分批实施
 *  走到前面：紧密跟进社区Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对措施，主动引入必要补丁
 *  以终为始：新功能需求确定后，测试用例同步设计并Review通过，然后开放冒烟测试标准，让开发人员在明确“什么是完成”的前提下，进行开发

坚持2m后，整体质量状况好多了。总体来说，质量分析最重要是追根溯源，找到问题症结。

#### 2.3 追根溯源的方法 ####

*  **每月坚持线上Bug分析会**。可召集产品、研发、测试对过去1m线上问题，进行根因分析，制定策略并推进落实
 *  **持续进行内部Bug分类**。从不同维度分析Bug原因，你可以按照具体引入阶段给Bug分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发、覆盖升级、历史遗留等，也可以按照Bug类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效
 *  **建立质量大盘，拉通不同业务线或模块的每月Bug趋势**，对齐千行代码Bug率、Bug数/需求数的比率、Reopen Bug率等，对低于平均线下的业务线或模块进行有针对性的原因分析

### 3 质量控制，层层设卡 ###

质量分析要点在追根溯源，质量控制是将一些明确的质量规范和做法，落地在各环节的过程。

从需求到发布的整个过程中的质量活动：

![d2249e457eb5d9d3fa10b670da1fbb7f.png][]

要推动质量改进措施落地，相匹的工具配套不可少。大厂都自主设计开发企业效能平台，来完成持续集成和持续交付，并在需求到发布的整个链条，设置质量卡点。可根据需要，逐步为自己的应用定制持续集成方案，指定代码准入阈值，如静态扫描、单元测试、覆盖率测试、冲突检测、Jar包版本检测的通过条件等。

![8a5af7227689e653e29722b6b6917539.png][]

质量控制及卡点行为，是结合项目的质量要求、团队的质量成熟度，层层加强质量把关和收口。即便同项目的不同应用，也因线上要求不同，而对质量卡点有不同侧重。通过质量卡点的在线工具化，才能做到真正有效质量保障。如某些团队在特定阶段，会按静态代码扫描问题级别分级计算缺陷值（如上图），提交测试申请时，如果系统检测到缺陷值有升高，就无法成功提交。

### 4 总结 ###

项目经理在质量管理过程中的工作，可从如下方面入手：

*  质量规划，明确项目的质量标准
 *  质量分析，追根溯源，找到质量差距的根本症结
 *  质量控制，在需求到发布过程中，设置层层卡点来控制质量

要想一次把事情做对，你首先得明确什么是对，然后要分析差距，找到相应的质量保障方法，并不断迭代。这三个方面是个螺旋式循环上升的过程，你需要不断地根据质量分析的结果，设置合适的质量卡点，直到达到规划中的质量标准。

[426986ed5372a265dd4f26f2aaa2e053.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/007a17d4947b4225802feca1aa45248b.png
[5c7effc4c9960a90af20a0dd5c828cff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/66a05d41965c46a78c7d95244d5b0f23.png
[d2249e457eb5d9d3fa10b670da1fbb7f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/b10036087903491f907e5384d1d8aabd.png
[8a5af7227689e653e29722b6b6917539.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/f4bf6a6b9990499585b9e83be9ada181.png