质量可视化 - 让数据为质量说话演讲稿

美柚测试总监 - 孔令云

建议对照 ppt 阅读（链接: https://pan.baidu.com/s/1NSip2sH5v1i6BALS8bYdsg 密码: h08h）

p1-2 开场

各位测试的小伙伴们，大家上午好，刚才云层老师讲了很多段子，大家有没有感觉进来的是脱口秀专场啊？讲段子的过程中让大家 get 到一些测试的点，我觉得非常好，那接下来我们切换到质量保障专场，由我来跟大家分享下美柚质量可视化管理的相关经验，希望对大家有一定的帮助或者启发。

p3 大纲

今天我将从 4 个方面对我们在质量可视化方面所做的工作进行分享

1 为什么要做质量可视化？

2 质量可视化的数据有哪些？分别具有什么意义？

3 质量数据如何采集，以及应用效果展示

4 最后会谈一谈质量可视化平台未来的展望

p4 个人简介

在正式开始分享前，我先做下自我介绍，我现在在美柚负责测试及质量管理工作。

P5 为什么要做质量可视化

接下来我就给大家分享一下我们做质量可视化平台的初衷。

p6 美柚 App，工具->平台

随着业务的不断发展，美柚 App 已经从一个生理期记录的工具型 App 成长为涵盖女性经期、备孕、怀孕、辣妈 4 个身份，包含资讯、社区、电商、直播等业务在内的一个平台型 App。

p7 美柚系 App

同时，除了美柚 App 以外，我们还形成了主打育儿的柚宝宝、宝宝记 App，主打电商的柚子街 App，还有返利相关的返还、羊毛省钱等一系列 App 产品的产品矩阵。

p8 挑战

在这样的产品研发背景下，对我们产品质量的保障提出了更多的挑战，
外部挑战是：活跃用户多，设备碎片化严重，尤其是 Android 设备，近年来碎片化更加严重，top10 机型总占比只有 15%， top100 也只有 67%，iOS 相对会好一些， top10 占比达到 75%
另外产品根据用户标签、推荐算法、用户设置等呈现了千人千面的样式，同时线上存在多个并行的的 AB 实验，也增加了测试验证的成本以及难度，还有一点就是多个 App 版本并存，需要考虑版本前后兼容性的问题

内部挑战是：美柚 App 涉及经期、备孕、孕期、育儿不同身份以及社区、资讯、算法、广告、电商等不同的业务团队，研发人员几百人，各个业务开发节奏、发版周期不尽一致，而且业务耦合性较高，比如广告会嵌入不同的业务当中，身份与业务也是互相交叉，同时研发数据比较分散，而且 App 通常以 2-3 周为一个迭代。

这些都对 App 质量的保证提出了巨大的挑战。

p9 测试问题

对于测试内部来讲，之前也有很多抱怨，比如：需求经常变更；临时需求很多；马上发版了，老板要加需求；开发提测质量很差；开发提测也比较晚，测试时间被压缩；对上线没有信息，提心吊胆；线上出了问题不知不觉或后知后觉；不知道现场的朋友们是否遇到过类似的问题，有的话，我们可以一起先来看看，是不是可以将问进一步归类，并且通过数据量化的方式来评估问题，比如：

1）跟产品相关的问题：

• 迭代周期内，需求变更了多少次？变更率是多少？
• 哪些是临时需求？临时需求增加了多少次？
• 老板需求是否有经过评审确认？是否经常性出现？等等 ### 2）跟开发相关的问题：
• 是否在提测前有进行自测？
• 开发的 task 是否规定了提测时间？是否按时提测了？
• 是否确定集成测试时间？集成测试时间占研发周期比例多少？
  ### 3）跟测试相关的问题：
• 上线的标准是什么？
• 线上都监控哪些质量相关的指标？
• 线上问题数量，是否符合质量标准？

p10 质量可视化数据及意义

正是为了解决上述研发过程中跟质量相关或影响质量的问题，我们决定做质量可视化。

p11 3 阶段指标

大家可以看到这张图里面，我们将整个研发过程分成 3 个阶段，分别是研发 - 即质量预防阶段，测试 - 即质量保证阶段，线上 - 即质量监控阶段，3 个阶段中间会有两个卡口，来控制质量，一个是提测节点的卡口，一个是上线节点的卡口，每个卡口都会定义卡口通过放行的质量标准，比如在提测卡口，会重点关注开发提测的及时性以及提测质量，上线卡口呢，则会关注各类 bug 关闭率情况以及 DI 收敛趋势状况，来评估质量风险。

3 个阶段中也会制定相应的质量指标，比如在研发阶段：

1）针对产品

针对产品，我们会关注产品的需求变更率指标，针对需求的微小调整是允许的，但我们不希望出现频繁的需求大改以及一些本身不明确的需求就进入开发测试阶段，我们遵循的质量原则是 “第一次就将正确的事情做正确”，另外，在上线时间确定的情况下，需求的频繁变更势必会压缩开发和测试时间，从而增加质量风险，所以，我们通过统计需求变更率的指标，一方面减少不必要的变更，另一方面和产品一起持续提升需求本身的质量，让需求逻辑、交互、边界更加明确，从而减少返工造成的内耗；

2）针对开发

针对开发，我们会关注静态代码扫描通过率的指标，比如我们将 sql 语句规范中的禁止出现 “select *” 作为强制的规则，扫描出此类 bug，就直接提 bug，并与开发同学达成一致，此类问题必须修改；

针对开发，我们还会关注 bug 日清率的指标，bug 不能做到日清，通常有两种可能，一个是 bug 多，改不完，一个是 bug 难，不好改，这又反映出代码复杂度高、耦合性高、可读性差、可维护性差、历史遗留问题多等一系列更深层次的技术及管理问题；

3）针对测试

我们会关注自动化测试覆盖率、bug 一次修复成功率、App 打包的成功率，还有 App 包大小、启动时间、闪退、内存泄漏、卡顿、cpu 内存等占用率、耗电量等专项指标；

4）对于线上

针对线上，我们会关注 bug 漏测率，也就是线上 bug 与线下 bug 的比值，还有 App 补丁包的更新率、后台及 api 上线回滚率、App 闪退、卡顿率以及 api 性能等线上指标。

p12 采集及应用

有了这些质量数据的指标定义以后，接下来我介绍下我们是如何采集这些质量指标数据并进行应用的。

p13 数据来源及应用

我们的数据来源包括研发管理平台、性能检测 sdk、第三方监控平台（如通过 bugly、oppo 运营后台等获取闪退、卡顿、ANR 等指标数据）、elk 日志（获取线上 api 响应时间等指标数据）、持续集成系统（获取 App 打包、上线回滚等指标数据）、自动化测试系统（获取自动化测试覆盖率，case 测试通过率等指标数据）。

p14 指标数据具体来源

这张图展示了质量数据的具体来源，不同颜色代表数据来源于不同的数据源。

比如测试阶段的 App 专项性能指标，有部分就来自于性能测试 sdk，我们通过运行 App 端的 UI 遍历测试程序，自动去检测 App 运行过程中的闪退、卡顿问题，如果发现问题，就通过数据服务接口上报 bug 到研发管理平台，并将数据存储在数据库中，同时 ETL 服务会定时同步研发管理平台的 bug 数据进行存储，并在可视化平台中做汇总、统计及展示应用。

p15 需求管理

接下来我以部分指标为例，分享下我们为了采集这些指标，需要具体做哪些工作：
首先是需求管理，所有需求，不管是业务需求还是技术需求，都需要记录在需求管理系统中，同时比较重要的业务、技术需求会有需求审核的过程，确保需求的质量。

p16 需求拆分 task

有了需求之后，开发同学分解需求并拆分成 task，预估开发时间，这里面的结束时间将作为提测的时间节点。

p17 需求变更

如果需求有变更，会记录在系统里面，我们需求变更率的统计就是以此为依据进行统计。

p18 测试确认

刚才在结束 task 的时候有提到，测试人员将会以 task 结束的时间点作为提测的时间点，如果到时间点没有提测，那么测试人员就会将此任务标记为 “未及时提测”，对于已提测的 task，测试人员会通过冒烟测试验证该 task 是否测试通过，同样标记测试结果，这样，每一个 task 就得到了两个维度的结果，一个是是否及时提测，另一个是测试是否通过

p19 迭代报表

再来看报表，每一天的任务结果我们通过累加，就可以得到当天的提测及时率和通过率数据，这个就可以作为衡量开发质量、进度的很重要的依据；另外，还有一个衡量产品质量变化趋势的值就是 DI（defect index，即缺陷指数），每一个严重级的缺陷会定义一个权重，各个严重级 bug 权重和数量之和即为 DI，如图，这是一个迭代周期内，DI 的变化趋势，先增加后减少，从图中能看出，质量是逐步趋于稳定的。

p20 阅读报表

那么每个月，我们会出一个业务报表，包含产品需求变更率的情况、开发提测及时率、通过率情况，还有 bug 日清率以及 DI 指数等信息，各个业务可以横向对比。

p21 线上 bug

针对测试，很重要的一个衡量测试成效的指标就是漏测率，漏测率跟线上 bug 直接相关，所以就需要先登记线上 bug。

p22 线上 bug 列表

登记的所有线上 bug，都会汇总在线上 bug 列表栏中。

p23 报表

最后，我们会以月、年等维度统计出各个业务的漏测率数据，作为该业务测试团队测试质量评价的重要参考。

p24

刚才介绍了一个业务项目从需求到开发到测试最后上线整个过程中质量相关指标的采集及应用，在这个过程当中还涉及到一些自动化测试的工作以及自动化相关的指标数据的采集及应用。

针对 App 的性能自动化，我们通过 Monkey 以及 UI 遍历程序（已开源在 GitHub，大家有兴趣可以下载，地址：https://github.com/MeetYouDevs/UIWalker），在 UI 遍历自动化测试过程中，我们会自动切换用户身份、AB 实验等，目前 UI 遍历的页面覆盖率能达到 80% 左右，测试过程中我们会利用性能检测 sdk 自动检测 crash、内存泄漏、ANR、卡顿以及主线程非法调用的问题，并通过接口将问题日志上报性能数据处理服务，这个服务对问题日志进行分析、过滤去重、聚合等操作后，将确认是 bug 的通过调用 bug 管理系统的接口创建 bug，同时，对开发标记为已修复，并 3 次未再复现的 bug 自动进行关闭。

p25-27

这几个分别是自动提单上报的 crash、ANR、主线程非法调用的 bug。

p28

这一张是自动关闭 bug 的示例，可以看到创建 bug 的 “变更人” 是我们的自动化测试程序 “exserver”，bug 被开发同学将状态修改为 “已解决” 以后，经程序自动验证 bug 已被解决，凌晨 1:05，该 bug 给关闭，可以看到变更人是 “exserver_auto_close"

p29

上面这张图是自动化测试 bug 每日的关闭率情况，下面这张图是版本维度的 bug 关闭率，通常在一个版本迭代中，App 的性能问题 bug 关闭率需要达到 90% 以上，我们才允许发版，可以看到从 779 版本到 782 版本，每个版本的关闭率均在 90% 以上，783 是正在开发中的版本，目前关闭率还比较低，通过在测试环境的这些测试以及卡口约束，我们线上的 App crash 率维持在一个相对较低的水准。

p30 卡顿

这张图是自动化测试检测出来的卡顿信息列表，按卡顿次数做了排序，打开详情可以看到卡顿的具体信息。

p31

前面我分享了 App 性能自动化测试以及数据采集的过程，接下来分享几个线上数据监控的具体例子，这张图是线上 95 分位 api 性能，每天我们都会从 elk 中将前一日的访问日志捞出来做分析，对于 95 分位超过 300ms 的接口，针对性分析原因，并配合开发一同优化。

p32

这两张图是美柚 App Android 版线上卡顿率、ANR 从2019年1月1号截止到现在的趋势图，可以看到卡顿率下降非常明显，目前稳定在一个非常低的水平上，ANR 中间虽有波动，但总体还是下降的一个趋势。

p33

这张图是我们可视化平台的看板页面，用户也可以定制显示自己关注的指标到看板。

p34 绩效

这张图是开发人员的绩效统计图表，包括开发人员的提测及时率、通过率，bug 日清率，线上线下 bug 数等等，实际上，这些指标一开始是我们测试对开发的一些要求，我们认为只有开发自身重视质量，提测质量有一定保证，整个产品的质量才能得到更好的保障，后来呢，这些指标逐渐被各各个开发小组接纳，作为开发同学绩效考核指标，写入了 okr 里面。

p35-p36 质量可视化平台未来展望

最后，我介绍一下我们质量可视化平台未来的展望，目前，我们正处于由 1.0 向 2.0 升级的阶段，1.0 阶段是我们测试自己建设，包括质量指标的定义、质量数据的采集以及应用推广等均由测试自己建设，随着质量可视化对于质量提升效果的显现以及对于研发绩效考核的帮助，产品和开发同学也逐渐会提出一些需求给我们，来共同完善质量可视化平台，比如产品同学提出的需求有：业务需求评审通过率；开发同学提出的需求有：开发工时统计、人均 bug 数统计等等。除此之外，2.0 版本中还将增加基于线上监控数据的智能预警功能，更有效的对潜在的质量风险进行识别并采取相应的风险防范措施。

p37 slogon

我们质量可视化平台的 slogon 是：让数据为质量说话，捍卫产品的质量以及用户体验，提升研发质量以及研发效率。

p38 个人微信及专栏

最最后面，打个广告，我个人的微信号，大家可以扫码关注交流，同时我的技术专栏《接口测试之代码实例 21 讲》（https://www.nowcoder.com/tutorial/10032/index）11 月初在牛客网正式上线，随专栏开源了 5 个 GitHub 项目，包含接口示例的代码、接口自动化测试框架代码以及一个简易电商网站的代码，我也列出了有专栏的地址，大家有兴趣可以阅览，也欢迎大家转发。

大家的印象里，可能觉得测试总监是不是就不做具体的技术了，实际上，我的主要工作可以用 3 个词 6 个字概括，就是 “技术”、“流程”、“团队”，技术在我的工作里面永远是排在第一位的。

我的分享完毕，感谢聆听！