软件过程质量管理

从软件表现反推软件质量，目前业内较成熟的评价标准有：千行代码bug率，产线bug占比率，提审打回率等等。而针对软件过程进行质量门禁建设和质量动作，目前业内暂无较通用方案，这也是本文今天讨论的重点。

本文基于现有项目实施过程中的各个阶段，作为“质量”角色需要思考的角度，质量动作，以及质量门禁的建设进行讲解。如果更好的方案，欢迎大家互相交流，给予指导。

业务/需求评审阶段

需要针对业务方提出的业务诉求和产品拆解出的产品需求进行质量评估。思考角度如下：

1）针对业务提出的诉求，现有产品功能是否可以满足？是否有必要新开发功能来实现业务玩法？

2）该玩法后续是否可以移植？

3）为一次性方案还是通用方法？

4）该营销手段预期获客多少？能带来的多少新增的GMV？

5）是否有其他类似的玩法可以替代？

技术设计阶段

需求评审后， 技术团队开始拆解任务并出技术设计文档。

一个需求拆解成多少个人时来做？涉及到多少个技术域？订单快照中的商品信息，是由商品团队来提供版本号还是订单团队自己落交易时刻的商品信息？

由于技术方案会影响到整个项目的质量，故此阶段质量需要参与细节把控。

软件开发阶段

背景知识：ISO9126 软件质量模型是评价软件质量的国际标准，由6个特性和27个子特性组成。包括：功能性，可靠性，易用性，效率，维护性，可移植性。

那么基于以上6个特性，质量的思考角度可以是：

1）在开发过程中使用TDD模式，还是DDD模式？

2）单元测试边开发边写， 还是开发完全后集中交叉撰写？

3）框架选择用go-zero还是gin?使用HTTP协议还是WebSocket协议？

4）技术选型是否在满足当下需求功能的基础上考虑到后续拓展维护成本以及重构的概率？

5）本次实现方式对历史功能的影响范围是否可控并合理？

联调阶段

选择一名技术owner，承担起联调工作的主导人角色。技术负责人需要跳出自己所在的技术域，为项目整体的技术负责，最终为项目整体的交付质量负责。

注意：进入联调阶段前，项目组内需要完成用例评审，并通晒p0p1级别case【部分技术域根据历史项目完成情况来判断，质量较差的话则需要包含到p2级别】，在联调阶段需要执行完全部p0p1级别case通过后，方可提审。

demo版本演示阶段

参与角色：产品，研发，质量，UI/交互设计师。业务方/运营【可选参加】

本阶段由技术owner组织产品演示，需要演示p0p1级别的业务场景。

此阶段发现的问题通常会有：接口契约变更/未对齐，未考虑到的业务场景，部分异常场景未做处理，未兼容历史数据，未兼容复杂业务场景等。

此阶段呈现出的问题通常可以在【联调阶段】/【软件开发阶段】前置发现解决。

质量验收阶段

qa角色正式进入项目验收，所做的动作包括：抽查p0p1级别用例，执行p2以下级别用例，并进行探索性测试。

需要分析并统计在此阶段发现的bug背后的根因，以及，对应用例的业务角度。为后续项目的过程优化沉淀数据。

此阶段发现的问题通常会有：环境问题，配置问题，接口契约问题，未考虑到的场景未做处理，未兼容历史数据等。

此阶段呈现出的问题通常可以在demo版本演示阶段/联调阶段/软件开发阶段前置解决。

业务验收阶段

产品/运营/业务 角色正式进入项目验收阶段：从业务角度使用产品，进行使用性测试。

此阶段发现的问题通常会有：环境问题，配置问题，使用习惯问题，多方理解不一致问题等。

此阶段呈现出的问题通常可以在【demo版本演示阶段】前置发现解决

通过以上几个阶段质量的全程跟进与细节把控，相信后续的项目质量提升会非常明显。