质量运营在智能支付业务测试中的初步实践

约定不等于承诺〃 2023-10-17 21:32 44阅读 0赞

### 背景 ###

毋庸置疑，质量是决定产品能否成功、企业能否持续发展的关键因素之一。对于“质量时代”下的互联网企业，如何在快速迭代的节奏中兼顾质量，真正落地“人人重视质量、人人创造质量、人人享受质量”，这是对QA的要求，也是整个产品技术团队面临的重要挑战。

质量运营，是将运营的思路注入到质量评估与改进工作中，它着眼于产品的全生命周期，以质量为中心，以数据为驱动，通过建设持续迭代的质量保障体系，最终提升交付质量。本文将聚焦研发过程中的提测阶段，以改进提测质量为例，从方案制定、策略应用、效果评估等几个方面，介绍质量运营在智能支付业务中的初步应用。

### 挑战 ###

美团点评智能支付承担了整个公司所有线下交易，当前日交易量已经突破1000万单，是公司继外卖和摩拜之后，又一个千万级日订单的业务。业务高速增长、团队快速扩张的情况下，质量问题极易被放大化，如果不能及时得到处理，后续解决成本会越来越高。

#### 存在的痛点 ####

刚参与智能支付业务测试时遇到的几个问题，如下：

1.  缺陷严重级别高，提测打回时常发生  
    如：核心功能未实现或实现与需求不符。
2.  缺陷数量多，定位、修复、回归耗时长  
    如：越在上游引入的缺陷，修复的成本就越高，潜在的风险也越大。
3.  各类低级缺陷，团队彼此间的信任度降低  
    如：文案错误、变量引用错误等编码大意导致的低级缺陷。

#### 解决的难点 ####

在尝试去改善时发现难以推动的几个问题，如下：

1.  对暴露出的质量问题，如何更直观的在认知上达成一致？  
    如：收到过很多类似的问题反馈：“xx的缺陷太多了，质量意识差”、“xx项目存在很大问题，需要尽快改进”，即使是基于事实得出的判断，这种偏主观的表达方式，对问题达成一致的认知带来很大的困难。
2.  对已公认的质量问题，如何更快速的进行分析和定位？  
    如：缺陷发生在测试阶段，但缺陷的引入可能是在需求阶段、设计阶段、开发阶段；某个时间段内的异常质量数据，可能是A项目或B项目，可能是C团队或D团队。问题类型细分、数据钻取能力等等，在问题的快速分析和定位中至关重要。
3.  对已定位的质量问题，如何找到可以落地的改进措施？  
    如：项目总结中常常会见到类似这样的描述：“加强自测”、“严格遵守项目流程”、“文档需要写的更详细些”，这种偏“形容词”的改进措施，很难实际操作，这也是整个质量改进过程中最大的一个难点。

### 思路 ###

质量改进是一个持续迭代的过程，不可急于求成。按照质量运营的方法，基本思路为：分析痛点，找到抓手，持续运营，形成闭环。  
基于提测阶段的质量问题特征，从痛点和难点中寻找突破点。大致思路为：

1.  目标应达成一致：质量改进的目标是QA的KPI，并应该与关键干系人在愿景、目标上达成一致。
2.  问题的客观呈现：提取核心度量指标，通过有效数据和典型案例说话。
3.  数据的灵活钻取：尽可能全的提供各种维度的数据，并分层级展示。
4.  改进措施可落地：对措施的多方Review、流程标准化到工具化的演进。

### 解决方案 ###

解决方案的重中之重，是务必遵循PDCA来实现运转方式的闭环。具体如下：

![E8_A7_A3_E5_86_B3_E6_96_B9_E6_A1_88-PDCA.png][]

#### 确定问题与方向 ####

通过痛点描述可知，缺陷是反映智能支付业务当前提测质量的最显著特征。提测质量的进一步分析，可通过**缺陷的数量、缺陷的严重程度、缺陷的生成原因**三个方向来展开。

**缺陷数量**

table th:first-of-type \{  
width: 110px;  
\}

<table> 
 <thead> 
  <tr> 
   <th align="left">缺陷数量</th> 
   <th align="left">具体说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">缺陷总数</td> 
   <td align="left">指定统计规则下缺陷的数量，仅包含项目过程中提交的缺陷</td> 
  </tr> 
 </tbody> 
</table>

*缺陷的严重程度*

<table> 
 <thead> 
  <tr> 
   <th align="left">严重级别</th> 
   <th align="left">具体说明</th> 
   <th align="left">使用范围</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">致命-Blocker</td> 
   <td align="left">影响核心功能的缺陷</td> 
   <td align="left">缺陷导致核心业务流程不可用，或产生较大影响</td> 
  </tr> 
  <tr> 
   <td align="left">严重-Critical</td> 
   <td align="left">造成较大影响的功能性缺陷</td> 
   <td align="left">缺陷导致核心业务流程受影响，或导致非核心业务流程不可用</td> 
  </tr> 
  <tr> 
   <td align="left">一般-Major</td> 
   <td align="left">影响较小的功能性缺陷</td> 
   <td align="left">缺陷导致非核心业务流程受影响，或导致用户体验类的问题</td> 
  </tr> 
  <tr> 
   <td align="left">提示-Minor</td> 
   <td align="left">非功能性缺陷</td> 
   <td align="left">如：不影响正常功能的UI错误、无重大歧义的提示错误等</td> 
  </tr> 
  <tr> 
   <td align="left">建议-Trivial</td> 
   <td align="left">优化建议</td> 
   <td align="left">非严格意义上的缺陷，一些可优化的点</td> 
  </tr> 
 </tbody> 
</table>

*缺陷的生成原因*

<table> 
 <thead> 
  <tr> 
   <th align="left">生成原因</th> 
   <th align="left">具体说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">实现与文档不符</td> 
   <td align="left">RD实现与需求文档描述不一致</td> 
  </tr> 
  <tr> 
   <td align="left">需求缺陷</td> 
   <td align="left">需求文档中缺少相应描述；需求变更</td> 
  </tr> 
  <tr> 
   <td align="left">技术方案考虑不足</td> 
   <td align="left">前后端接口定义不一致；对边界、异常场景考虑不全等</td> 
  </tr> 
  <tr> 
   <td align="left">环境问题</td> 
   <td align="left">被测服务不稳定；服务器或测试设备配置等引起的问题</td> 
  </tr> 
  <tr> 
   <td align="left">第三方依赖</td> 
   <td align="left">依赖的外部系统引入的问题，如用户中心等</td> 
  </tr> 
  <tr> 
   <td align="left">兼容性</td> 
   <td align="left">不同设备上出现的功能或展示异常类的问题</td> 
  </tr> 
  <tr> 
   <td align="left">性能问题</td> 
   <td align="left">服务端性能：响应时间过长、CPU过高、GC频繁、没有分页、没有缓存等；<br>客户端功耗：包大小、冷启动时间、流量、内存泄漏OOM、加载时间、耗电量</td> 
  </tr> 
  <tr> 
   <td align="left">安全问题</td> 
   <td align="left">XSS注入，SQL注入等</td> 
  </tr> 
  <tr> 
   <td align="left">Bugfix引入</td> 
   <td align="left">由于修改Bug引入的缺陷</td> 
  </tr> 
  <tr> 
   <td align="left">不是缺陷</td> 
   <td align="left">无效Bug；不能复现</td> 
  </tr> 
 </tbody> 
</table>

#### 度量指标及标准 ####

针对缺陷的三个分析方向，提取出可度量的指标、定义合理的标准值，并与整个团队达成一致。

##### 指标提取策略 #####

1.  典型性  
    
    
     *  找最想要解决的问题。不追求全面，只针对Top问题提取指标，如：生成原因里最应该避免的是哪些。
     *  找最能反映问题的指标。如：缺陷数量有众多度量指标（新增数量、人均数量等等），为排除工作量影响，我们选择用千行代码缺陷率这个指标。
2.  有效性  
    
    
     *  除非对绝对数量有明确要求，否则尽量使用百分比作为度量指标。
     *  指标数据的计算方式，要求简单易懂，并务必得到相关人的认可。

##### 标准制定策略 #####

1.  基于公司统一要求  
    如：Sonar千行代码严重问题数，统一标准为低于0.1。
2.  基于公司各业务现状  
    如：缺陷相关指标按照公司各业务部门排行，取Top5的值作为标准线。
3.  基于自身业务阶段持续调整  
    如：随着智能支付业务质量的持续改进，定义更严格的质量标准。

##### 最终定义的指标与标准 #####

<table> 
 <thead> 
  <tr> 
   <th align="left">度量指标</th> 
   <th align="left">指标说明</th> 
   <th align="left">标准值</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">千行代码缺陷率</td> 
   <td align="left">（缺陷总数/代码行数）* 1000</td> 
   <td align="left">移动端：&lt; 0.45<br>前端：&lt; 0.2<br>后端：&lt; 0.15</td> 
  </tr> 
  <tr> 
   <td align="left">Sonar千行代码严重问题数</td> 
   <td align="left">（Sonar严重问题数/代码行数）* 1000</td> 
   <td align="left">Blocker：0<br>总数：&lt; 0.1</td> 
  </tr> 
  <tr> 
   <td align="left">严重缺陷占比</td> 
   <td align="left">严重缺陷总数/缺陷总数</td> 
   <td align="left">&lt; 3.5%</td> 
  </tr> 
  <tr> 
   <td align="left">需求缺陷占比</td> 
   <td align="left">需求缺陷总数/缺陷总数</td> 
   <td align="left">&lt; 10%</td> 
  </tr> 
  <tr> 
   <td align="left">实现与文档不符缺陷占比</td> 
   <td align="left">实现与文档不符缺陷总数/缺陷总数</td> 
   <td align="left">&lt; 10%</td> 
  </tr> 
 </tbody> 
</table>

#### 获取数据并展示 ####

基于Metrics（美团点评工程质量中心提供的度量平台），能够快速的获取数据并展示。但要注意，部分指标的计算需要对Metrics提供的数据进行二次处理，以保证数据的精准性。如：在计算千行代码缺陷率时，需要排除掉开发自测缺陷等。

对于数据的展示形式，除了利用Metrics提供的各种图表外，最为关键的是要实现数据与问题（相关缺陷）的可关联，以便进行下一步分析。如下图所示（通过超链接方式进行关联）：

![数据与问题可关联][E6_95_B0_E6_8D_AE_E4_B8_8E_E9_97_AE_E9_A2_98_E5_8F_AF_E5_85_B3_E8_81_94.png]

#### 制定计划并改进 ####

改进措施的制定和实施是整个质量改进过程中的重中之重。基于经验，给出三个策略。

##### 自上而下与自下而上相结合 #####

*  自上而下：通过有效数据、典型案例，建设可信任的结果评估体系；以此为基础，利用每一个问题数据，在Leader层强化质量意识，借鉴向上管理的思路，实现质量改进的向下驱动。
 *  自下而上：通过案例复盘、数据钻取，对问题进行明确定位，让问题方基于工具即可将问题下沉到具体项目或具体角色，进而推进可落地的过程改进，并持续利用结果评估体系衡量改进效果，实现质量改进的向上闭环。

![E8_87_AA_E4_B8_8A_E8_80_8C_E4_B8_8B_E4_B8_8E_E8_87_AA_E4_B8_8B_E8_80_8C_E4_B8_8A_E7_9B_B8_E7_BB_93_E5_90_88.png][]

##### 多维度的数据聚合与分析相结合 #####

*  周维度数据聚合：对周数据中的异常进行分析，并排除掉因周期偏短导致的数据噪点，重在对问题进行风险预警。
 *  月维度数据聚合：对月数据中的异常进行分析，并结合数据的变化趋势，重在对问题进行确认和改进。周维度和月维度相结合，构成了质量管理中的问题发现与改进周期。
 *  季度维度数据聚合：对季度数据的分析，重在得出对质量目标的完成度并给出质量评分，并对过程中的问题进行回顾和总结，构成了质量管理中的考核周期。

![E5_A4_9A_E7_BB_B4_E5_BA_A6_E7_9A_84_E6_95_B0_E6_8D_AE_E8_81_9A_E5_90_88_E4_B8_8E_E5_88_86_E6_9E_90_E7_9B_B8_E7_BB_93_E5_90_88.png][]

##### 流程的标准化与工具化相结合 #####

*  在改进提测质量的初期阶段，对于流程的优化经常出现在各个项目总结的改进措施中，但大多是通过意识、模板或者口头提醒来实现，这无疑增加了流程的接入成本、执行难度，进而降低了流程的约束力。
 *  借鉴在制造业中常见的一种解决思路——“防呆措施”，在流程标准化之后，应尽可能将其工具化，提升流程的生命力。

![E6_B5_81_E7_A8_8B_E7_9A_84_E6_A0_87_E5_87_86_E5_8C_96_E4_B8_8E_E5_B7_A5_E5_85_B7_E5_8C_96_E7_9B_B8_E7_BB_93_E5_90_88.png][]

*  防呆措施的目的之一是防止不符合流程的产出物交付到下游。
 *  将防呆措施应用到提测流程，即应实现各项准入标准的自动化检查，类似如下提测时校验：

![这里写图片描述][70]

#### 回顾与反馈 ####

主要从时间维度、项目维度两方面开展。

1.  时间维度  
    各类周会、双周会、季度总结，对质量数据进行Review。
2.  项目维度  
    重在项目复盘。复盘可以看成PDCA环和环之间的连接，有了它，PDCA才能环环相扣、周而复始。

#### 迭代与推广 ####

若改善有效，则进行推广。若改善无效，则分析原因，修改计划，重新启动另一轮PDCA。

1.  指标与标准的持续迭代  
    如：过程中对Sonar千行严重问题数的标准由0.1提升到0。
2.  度量模型与方法工具的推广  
    如：质量报表、Sonar在PR时触发检查不通过不允许Merge、提测准入自动化等等在其他业务的推广。

### 效果 ###

对于效果的评估，主要从三方面进行说明。

1.  质量数据的关注度
2.  质量指标的达成度
3.  过程质量改进对迭代效率的提升效果

#### 质量数据关注度 ####

主要体现在团队各方对质量报表的使用率。以下三张图分别为：智能支付QA、智能支付RD、智能支付RD Leader对质量报表的使用率走势。

![这里写图片描述][70 1]

#### 质量指标达成度 ####

对质量指标的达成情况进行说明，其中：初始值为16年Q4的情况。

<table> 
 <thead> 
  <tr> 
   <th align="left">度量指标</th> 
   <th align="left">初始值</th> 
   <th align="left">标准值</th> 
   <th align="left">目标完成度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">千行代码缺陷率</td> 
   <td align="left">移动端：0.7<br>前端：0.25<br>后端：0.3<br></td> 
   <td align="left">移动端：&lt; 0.45<br>前端：&lt; 0.2<br>后端：&lt; 0.15<br></td> 
   <td align="left"><strong>整体达标，但存在个别方向缺陷率较高</strong></td> 
  </tr> 
  <tr> 
   <td align="left">Sonar千行代码严重问题数</td> 
   <td align="left">Blocker &gt; 0<br>总数：0.2</td> 
   <td align="left">Blocker：0<br>总数：&lt; 0.1</td> 
   <td align="left"><strong>达标</strong></td> 
  </tr> 
  <tr> 
   <td align="left">严重缺陷占比</td> 
   <td align="left">14%左右</td> 
   <td align="left">&lt; 3.5%</td> 
   <td align="left"><strong>达标</strong></td> 
  </tr> 
  <tr> 
   <td align="left">需求缺陷占比</td> 
   <td align="left">18%左右</td> 
   <td align="left">&lt; 10%</td> 
   <td align="left"><strong>达标</strong></td> 
  </tr> 
  <tr> 
   <td align="left">实现与文档不符缺陷占比</td> 
   <td align="left">&lt; 10%</td> 
   <td align="left">&lt; 10%</td> 
   <td align="left"><strong>达标，但有升高趋势，接近标准值</strong></td> 
  </tr> 
 </tbody> 
</table>

近几个Q的变化趋势，如下：

![这里写图片描述][70 2]

#### 迭代效率提升效果 ####

以客户端方向为例（之前过程质量存在较严重的问题），说明过程质量改进对迭代效率的提升效果。

![E5_AE_A2_E6_88_B7_E7_AB_AF_E8_BF_AD_E4_BB_A3_E6_95_88_E7_8E_87_E6_8F_90_E5_8D_87.png][]

### 总结 ###

经过一段时间的摸索和实践，我们在提测质量上有了较明显的提升，过程中积累的方法、流程和工具也在推广使用。但提测质量只是全生命周期质量运营的一小部分，对于高速发展的智能支付业务，不仅要求整个质量保证体系的迭代优化，更要求全体成员不断提升质量思维、持续追求极致质量，进而形成一种质量文化，真正实现“人人重视质量、人人创造质量、人人享受质量”。

### 作者介绍 ###

勋伟，美团点评高级测试开发工程师，金融服务平台智能支付业务测试负责人，2015年加入美团点评。

### 招聘 ###

如果你想学习互联网金融的技术体系，亲历互联网金融业务的爆发式增长，如果你想和我们一起，保证业务产品的高质量，欢迎加入美团金融工程质量组。有兴趣的同学可以发送简历到：fanxunwei\#meituan.com。

![这里写图片描述][70 3]

[E8_A7_A3_E5_86_B3_E6_96_B9_E6_A1_88-PDCA.png]: https://tech.meituan.com/img/%E8%B4%A8%E9%87%8F%E8%BF%90%E8%90%A5%E5%9C%A8%E6%99%BA%E8%83%BD%E6%94%AF%E4%BB%98%E4%B8%9A%E5%8A%A1%E6%B5%8B%E8%AF%95%E4%B8%AD%E7%9A%84%E5%88%9D%E6%AD%A5%E5%AE%9E%E8%B7%B5/%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88-PDCA.png
[E6_95_B0_E6_8D_AE_E4_B8_8E_E9_97_AE_E9_A2_98_E5_8F_AF_E5_85_B3_E8_81_94.png]: https://tech.meituan.com/img/%E8%B4%A8%E9%87%8F%E8%BF%90%E8%90%A5%E5%9C%A8%E6%99%BA%E8%83%BD%E6%94%AF%E4%BB%98%E4%B8%9A%E5%8A%A1%E6%B5%8B%E8%AF%95%E4%B8%AD%E7%9A%84%E5%88%9D%E6%AD%A5%E5%AE%9E%E8%B7%B5/%E6%95%B0%E6%8D%AE%E4%B8%8E%E9%97%AE%E9%A2%98%E5%8F%AF%E5%85%B3%E8%81%94.png
[E8_87_AA_E4_B8_8A_E8_80_8C_E4_B8_8B_E4_B8_8E_E8_87_AA_E4_B8_8B_E8_80_8C_E4_B8_8A_E7_9B_B8_E7_BB_93_E5_90_88.png]: https://tech.meituan.com/img/%E8%B4%A8%E9%87%8F%E8%BF%90%E8%90%A5%E5%9C%A8%E6%99%BA%E8%83%BD%E6%94%AF%E4%BB%98%E4%B8%9A%E5%8A%A1%E6%B5%8B%E8%AF%95%E4%B8%AD%E7%9A%84%E5%88%9D%E6%AD%A5%E5%AE%9E%E8%B7%B5/%E8%87%AA%E4%B8%8A%E8%80%8C%E4%B8%8B%E4%B8%8E%E8%87%AA%E4%B8%8B%E8%80%8C%E4%B8%8A%E7%9B%B8%E7%BB%93%E5%90%88.png
[E5_A4_9A_E7_BB_B4_E5_BA_A6_E7_9A_84_E6_95_B0_E6_8D_AE_E8_81_9A_E5_90_88_E4_B8_8E_E5_88_86_E6_9E_90_E7_9B_B8_E7_BB_93_E5_90_88.png]: https://tech.meituan.com/img/%E8%B4%A8%E9%87%8F%E8%BF%90%E8%90%A5%E5%9C%A8%E6%99%BA%E8%83%BD%E6%94%AF%E4%BB%98%E4%B8%9A%E5%8A%A1%E6%B5%8B%E8%AF%95%E4%B8%AD%E7%9A%84%E5%88%9D%E6%AD%A5%E5%AE%9E%E8%B7%B5/%E5%A4%9A%E7%BB%B4%E5%BA%A6%E7%9A%84%E6%95%B0%E6%8D%AE%E8%81%9A%E5%90%88%E4%B8%8E%E5%88%86%E6%9E%90%E7%9B%B8%E7%BB%93%E5%90%88.png
[E6_B5_81_E7_A8_8B_E7_9A_84_E6_A0_87_E5_87_86_E5_8C_96_E4_B8_8E_E5_B7_A5_E5_85_B7_E5_8C_96_E7_9B_B8_E7_BB_93_E5_90_88.png]: https://tech.meituan.com/img/%E8%B4%A8%E9%87%8F%E8%BF%90%E8%90%A5%E5%9C%A8%E6%99%BA%E8%83%BD%E6%94%AF%E4%BB%98%E4%B8%9A%E5%8A%A1%E6%B5%8B%E8%AF%95%E4%B8%AD%E7%9A%84%E5%88%9D%E6%AD%A5%E5%AE%9E%E8%B7%B5/%E6%B5%81%E7%A8%8B%E7%9A%84%E6%A0%87%E5%87%86%E5%8C%96%E4%B8%8E%E5%B7%A5%E5%85%B7%E5%8C%96%E7%9B%B8%E7%BB%93%E5%90%88.png
[70]: https://img-blog.csdn.net/20180523095741651?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01laXR1YW5UZWNo/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 1]: https://img-blog.csdn.net/20180523095858322?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01laXR1YW5UZWNo/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 2]: https://img-blog.csdn.net/20180523095951852?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01laXR1YW5UZWNo/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[E5_AE_A2_E6_88_B7_E7_AB_AF_E8_BF_AD_E4_BB_A3_E6_95_88_E7_8E_87_E6_8F_90_E5_8D_87.png]: https://tech.meituan.com/img/%E8%B4%A8%E9%87%8F%E8%BF%90%E8%90%A5%E5%9C%A8%E6%99%BA%E8%83%BD%E6%94%AF%E4%BB%98%E4%B8%9A%E5%8A%A1%E6%B5%8B%E8%AF%95%E4%B8%AD%E7%9A%84%E5%88%9D%E6%AD%A5%E5%AE%9E%E8%B7%B5/%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%BF%AD%E4%BB%A3%E6%95%88%E7%8E%87%E6%8F%90%E5%8D%87.png
[70 3]: https://img-blog.csdn.net/20180523100018630?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01laXR1YW5UZWNo/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70