本节书摘来自华章计算机《腾讯iOS测试实践》一书中的第1章，第1.6节,作者：丁如敏　王琳　等著
　 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.6　数据反推

1.6.1　测试过程中的数据
测试数据反推—充分利用各类测试数据的优化流程，进一步保障产品的质量。在各阶段的测试过程中会产生大量数据，例如Bug数据、测试通过率、回归通过率等。那么如何充分利用这些数据呢？前面已对已知Bug以及未知Bug进行了讨论。现在换个角度，从Bu***生的阶段来分析，图1-12是不同阶段Bug修复成本曲线。

图1-12　不同阶段Bug的修复成本[3]
针对Bug各阶段的分析，根据图1-12中Bug越早发现解决成本越低的结论，需要尽可能在最早引入的阶段发现Bug。针对某些阶段漏过的Bug分析，要尽可能完善测试设计覆盖，避免Bug都留到集成阶段发现，降低版本延期发布风险，从而开发出更高效的发布版本。
例如某个项目，集成测试发现的Bug占比只有整个版本（所有各分支版本）发现Bug的3%～6%，这些Bug大多是分支合流跟主干耦合的问题，还有一些是机型覆盖或者运营配置问题。大多数Bug都已经在各FT（Feature Team，特性模块）分支上发现了，这样集成后的发布风险就会大大降低，加快了发布速度。图1-13是FT分支的合流模型，各个分支FT都能充分保证质量，这样合流后集成测试问题就很少了。

图1-13　分支合流研发模式
也许有人会说3%～6%并不算少，确实，不同项目有不同要求。这里介绍的思路就是充分利用这些数据去思考与分析，推动团队采取动作，逐步降低该比例，逐步降低发布风险，提升发布效率。 分支合流模型的测试如何开展是另外一个话题，不过大体思路都差不多，除了基本持续集成外，还需要自动化测试（BVT、接口测试、终端性能测试等）的支持，才能快速支持分支合流的快速研发模型。
再举一个例子，Bug各模块分布，有些模块Bug问题比较多，可能需要特别关注测试，因为根据测试的二八法则—80%的缺陷出现在20%的代码中，所以对这些模块需要多分析多做测试，这样可以更大可能发现潜在问题。一般来说，不同模块会对应不同的开发团队或者FT，也可以通过Bug来评估开发团队（或者FT）的成熟度，根据不同的开发团队（FT）制定相应的改善措施，用数据说话，这样更好地推动团队的正向优化。
表1-1所示的是另外一个项目团队某个版本的各个FT存在的缺陷占比，从表中可以看出模块A是缺陷高发区，出现这种情况需要和对应模块的负责人进行沟通，细查原因，以利于改进。
以上仅仅是从Bug模块分布来分析Bug数据，其实还可以从很多维度（从开发人员的维度、用户行为的维度等）去挖掘Bug数据，充分利用Bug数据来优化测试设计，提升测试效率。
1.6.2　线上数据
以上介绍的大多是与研发过程品质相关的，其实还有一个很重要的方向就是线上品质，通过线上海量用户上报的数据来度量产品品质。大多数情况下，研发过程品质始终无法保证线上品质。比如用户反馈的重现问题，就是线上用户反馈的问题我们怎么也重现不了，即使严格按照用户的步骤、机型、网络等场景也重现不了。研发过程中测试的数据跟线上用户的数据对应不上，例如某个产品的启动速度，研发过程中测试的启动时间是2.3秒（测试20次取平均值），而线上用户上报的数据是3.2秒（20万个用户上报的平均值）。
业界也有相关测试方法，例如微软公司提出的TiP（Testing in Production），就是通过版本上线后海量用户上报各类数据来发现潜在的问题。测试人员需要关注各类性能数据，例如启动速度、内存、流畅度、响应时间、Crash率等。因为用户的机型、网络、地域、数据环境不同，所以不同用户上报的数据差异很大，这里需要做一些数据统计的分析处理，才能更好地展现出来。由于线上环境的复杂性，线上数据反映的结果会比测试数据差一些。
那么如何通过线上数据来分析定位问题呢？主要的方法就是对某些指标进行详细埋点上报，这样才能获得更详细数据并进行分析，最后找到问题所在。还是以某个产品的启动速度为例来说明（启动速度是指用户点击应用图标开始到拉取完数据展示给用户的这个时间段）。
App启动后就会到后台服务器拉取数据，从大的方向来看，需要区分后台服务器耗时以及App处理的耗时，这样可以方便前端或者后台解决问题。
如图1-14所展示的，“等待响应”就是后台服务器耗时（其中也包含网络传输的耗时）。一般可以通过抓取网络包分析得出相关耗时。
图1-14中的RTT（Round-Trip Time）是客户端到服务器往返所花的时间。
当然，只区分客户端跟后台服务器各自的耗时是远远不够的，还需要细分到每个主要函数的耗时，这样才能更好地定位具体是哪部分耗时。图1-15所示的是某个App对关键函数（节点）的日志统计。

图1-15　关键函数（节点）的日志统计
图1-15只是启动速度这个指标需要记录的数据，可能发现需要记录的数据非常多，对这些记录的日志也会进行分级，线上发布版本的日志会尽量少一些，不过关键的地方还是需要记录的。当然，版本加了日志会对性能有所损耗，不过在可接受的范围内，还是有必要的；通过线上版本的数据上报，可以得到用户真实的数据，发现潜在问题并逐步优化，给用户更好的体验，提升产品口碑。
如果品质体系的各个指标都有数据上报，那么数据量将非常大，对数据分析挖掘要求就会更高，当然可能产生的价值也会更大，这样更要重视数据的测试。这也是我们强调线上数据测试的原因。
测试数据还可以预测即将发布版本的质量，不管是研发过程还是灰度阶段，都将会产生很多测试数据。那么是否可以充分利用这些数据来预测上线版本的质量趋势呢？这确实是一个方向，但是需要大量的测试数据才可能有机会预测靠谱。因为线上用户的各种机型系统、网络状况、用户环境数据，这些都很难在上线前的环境覆盖到，所以就很难预测线上版本的质量。如果灰度群体足够，那么还是有机会的。腾讯内部的很多项目，产品稳定性问题（Crash率）都是通过灰度来发现问题的，Crash率达到一定程度，就可以进一步扩大灰度规模，逐步迭代放大灰度数量，直至上线。