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

总第244篇

2018年 第36篇

背景

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

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

挑战

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

存在的痛点

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

1. 缺陷严重级别高，提测打回时常发生  
   如：核心功能未实现或实现与需求不符。

2. 缺陷数量多，定位、修复、回归耗时长  
   如：越在上游引入的缺陷，修复的成本就越高，潜在的风险也越大。

3. 各类低级缺陷，团队彼此间的信任度降低  
   如：文案错误、变量引用错误等编码大意导致的低级缺陷。

解决的难点

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

1. 对暴露出的质量问题，如何更直观的在认知上达成一致？  
   如：收到过很多类似的问题反馈：“xx的缺陷太多了，质量意识差”、“xx项目存在很大问题，需要尽快改进”，即使是基于事实得出的判断，这种偏主观的表达方式，对问题达成一致的认知带来很大的困难。

2. 对已公认的质量问题，如何更快速的进行分析和定位？  
   如：缺陷发生在测试阶段，但缺陷的引入可能是在需求阶段、设计阶段、开发阶段；某个时间段内的异常质量数据，可能是A项目或B项目，可能是C团队或D团队。问题类型细分、数据钻取能力等等，在问题的快速分析和定位中至关重要。

3. 对已定位的质量问题，如何找到可以落地的改进措施？  
   如：项目总结中常常会见到类似这样的描述：“加强自测”、“严格遵守项目流程”、“文档需要写的更详细些”，这种偏“形容词”的改进措施，很难实际操作，这也是整个质量改进过程中最大的一个难点。

思路

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

1. 目标应达成一致：质量改进的目标是QA的KPI，并应该与关键干系人在愿景、目标上达成一致。

2. 问题的客观呈现：提取核心度量指标，通过有效数据和典型案例说话。

3. 数据的灵活钻取：尽可能全的提供各种维度的数据，并分层级展示。

4. 改进措施可落地：对措施的多方Review、流程标准化到工具化的演进。

解决方案

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

确定问题与方向

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

缺陷数量

缺陷数量	具体说明
缺陷总数	指定统计规则下缺陷的数量，仅包含项目过程中提交的缺陷

缺陷的严重程度

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

缺陷的生成原因

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

度量指标及标准

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

指标提取策略

1. 典型性

• 找最想要解决的问题。不追求全面，只针对Top问题提取指标，如：生成原因里最应该避免的是哪些。    

• 找最能反映问题的指标。如：缺陷数量有众多度量指标（新增数量、人均数量等等），为排除工作量影响，我们选择用千行代码缺陷率这个指标。

有效性

• 除非对绝对数量有明确要求，否则尽量使用百分比作为度量指标。

• 指标数据的计算方式，要求简单易懂，并务必得到相关人的认可。

标准制定策略

1. 基于公司统一要求  
   如：Sonar千行代码严重问题数，统一标准为低于0.1。

2. 基于公司各业务现状  
   如：缺陷相关指标按照公司各业务部门排行，取Top5的值作为标准线。

3. 基于自身业务阶段持续调整  
   如：随着智能支付业务质量的持续改进，定义更严格的质量标准。

最终定义的指标与标准

度量指标	指标说明	标准值
千行代码缺陷率	（缺陷总数/代码行数）* 1000	移动端：< 0.45 前端：< 0.2 后端：<  0.15
Sonar千行代码严重问题数	（Sonar严重问题数/代码行数）* 1000	Blocker：0 总数：< 0.1
严重缺陷占比	严重缺陷总数/缺陷总数	< 3.5%
需求缺陷占比	需求缺陷总数/缺陷总数	< 10%
实现与文档不符缺陷占比	实现与文档不符缺陷总数/缺陷总数	< 10%

获取数据并展示

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

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

制定计划并改进

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

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

• 自上而下：通过有效数据、典型案例，建设可信任的结果评估体系；以此为基础，利用每一个问题数据，在Leader层强化质量意识，借鉴向上管理的思路，实现质量改进的向下驱动。

• 自下而上：通过案例复盘、数据钻取，对问题进行明确定位，让问题方基于工具即可将问题下沉到具体项目或具体角色，进而推进可落地的过程改进，并持续利用结果评估体系衡量改进效果，实现质量改进的向上闭环。

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

• 周维度数据聚合：对周数据中的异常进行分析，并排除掉因周期偏短导致的数据噪点，重在对问题进行风险预警。

• 月维度数据聚合：对月数据中的异常进行分析，并结合数据的变化趋势，重在对问题进行确认和改进。周维度和月维度相结合，构成了质量管理中的问题发现与改进周期。

• 季度维度数据聚合：对季度数据的分析，重在得出对质量目标的完成度并给出质量评分，并对过程中的问题进行回顾和总结，构成了质量管理中的考核周期。

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

• 在改进提测质量的初期阶段，对于流程的优化经常出现在各个项目总结的改进措施中，但大多是通过意识、模板或者口头提醒来实现，这无疑增加了流程的接入成本、执行难度，进而降低了流程的约束力。

• 借鉴在制造业中常见的一种解决思路——“防呆措施”，在流程标准化之后，应尽可能将其工具化，提升流程的生命力。

• 防呆措施的目的之一是防止不符合流程的产出物交付到下游。

• 将防呆措施应用到提测流程，即应实现各项准入标准的自动化检查，类似如下提测时校验：

回顾与反馈

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

1. 各类周会、双周会、季度总结，对质量数据进行Review。

2. 项目维度  
   重在项目复盘。复盘可以看成PDCA环和环之间的连接，有了它，PDCA才能环环相扣、周而复始。

迭代与推广

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

1. 指标与标准的持续迭代  
   如：过程中对Sonar千行严重问题数的标准由0.1提升到0。

2. 度量模型与方法工具的推广  
   如：质量报表、Sonar在PR时触发检查不通过不允许Merge、提测准入自动化等等在其他业务的推广。

效果

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

1. 质量数据的关注度

2. 质量指标的达成度

3. 过程质量改进对迭代效率的提升效果

质量数据关注度

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

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

质量指标达成度

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

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

迭代效率提升效果

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

总结

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

作者简介

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

----------  END  ----------

招聘信息

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

也许你还想看：