缺陷分析的正逆向

网上流传一句话：世界上最难的事有两件，一是把自己的思想装进别人的脑袋，二是把别人的钱装进自己的口袋。当然...

网上流传一句话：世界上最难的事有两件，一是把自己的思想装进别人的脑袋，二是把别人的钱装进自己的口袋。当然后来又有神续：前者成功的是老师，后者成功的是老板，两者都成功的是寺庙。当然这是开玩笑，说这个是为了引入我们今天的话题：缺陷分析。

作为测试工程师，最常接触的就是各种缺陷，如何将缺陷变废为宝，对今后的测试工作产生指导价值，这是我们做缺陷分析的终极价值，也相当于把别人口袋的钱（代码bug）装进自己的口袋（指导价值）。至于另外的一件把自己的思想放进别人脑子里的事，也是比较高难度的，今天笔者就尝试给大家分享一种缺陷分析的思路，如果读者读过本文如能产生共鸣或者火花，那这也算是完成传播思想这个难事了。

言归正传，缺陷分析如果按照现实工作的模式，大致应该分为两个过程：缺陷定位和缺陷报告。这两个过程可以具体化表示，缺陷定位是一种从表现到内在原因的查找过程，类似几何证明题里的分析过程，由最后的结果逆向求证需要的条件；而缺陷报告就是根据那些分析再从正向梳理整个问题发生的过程并总结收益，类似几何证明题里最后的证明步骤，呈现出来的是从触发条件一路到最后的结果的正向演进。针对两个过程，笔者以手机QQ浏览器（iPhone）项目案例和大家分享下思路。

一、缺陷定位（逆向求证）

几何证明题中，要求证一个结果，例如A=B，就要根据A=B的这个结果去寻找成立的条件，一步步的条件往上推演，直到找到已知的对应条件。这个过程就是一个逆向的求证过程。在缺陷分析中也要借鉴这种思路，根据缺陷现象（来自测试发现或者用户反馈），分析产生缺陷的可能原因，从直接原因到间接原因，再到根因，逐步推演到实际的代码层面上。

在这个逆向求证过程中，笔者推荐使用中医的望闻问切的四诊法。《难经》有曰："望而知之者，望见其五色，以知其病。闻而知之者，闻其五音，以别其病。问而知之者，问其所欲五味，以知其病所起所在也。切脉而知之者，诊其寸口，视其虚实，以知其病，病在何脏腑也。"换成测试语言来说就是要通过"望"这种观察方式查看现象，确定是否是bug；通过"闻"这种体验观察缺陷的特征，为后面的判断做辅助依据；通过"问"这种验证方式判断缺陷可能产生的原因和时间；通过"切"这种方式定位缺陷产生的根本原因。整体思路如图1-1所示，说的比较抽象，接下来结合实际案例来解释下。
图1-1

案例：掉粉30万事件

1.1 望

手机QQ浏览器6.5版本appstore发布后，发现日活突然少了30万左右，持续多日。这就可以判断是"有问题"了，因为观察到日活的减少时与新版本发布有关，且是突然下跌几十万，这与以往的某天突然下跌日活不同，可以排除线上运营活动或者其它的非版本问题的原因，产生的异常与新发布的版本质量有关系，是个可以进行分析的版本质量缺陷。

在望这个环节上，我们得到抽象的信息。6.5版本用户日活减少了三十万。

　1.2 闻

知道了病症的表现，还得通过闻的方式来观察这个症状。医学上是听五音，闻味道。在IT行业里就是要逐个可能的维度里去观察异常，如果各个维度都正常，那还得扩展维度。如果某个维度（例如某种机型、系统、版本等等）存在问题，就可以获得有价值的线索。

这个"闻"的成本跟被观察的缺陷类型有关系。在掉粉30万这个案例中，由于现象比较抽象，原因可能很多，逐一检测，耗时较长，到最后找到异常的特征，前后花了将近三天的排查时间。发现iOS7系统的用户在发布了新版本后，日活从之前的三十多万将至百人以内，如图1-2所示。
图1-2

在闻这个环节上，我们获取了进一步的信息，iOS7系统的用户在6.5版本发布后出现了问题。

1.3 问

"望"和"闻"都是测试或者开发人员没有经过与缺陷的亲密接触而获取到的信息。要想定位具体问题还是要"问"。如果说"望"是直观得到的信息，"闻"可能还需要开发帮忙梳理可能的维度，那么"问"这个维度更多的考验测试人员自身的功力。"问"的主要目的是确认缺陷所在区域、缺陷产生的历史时期、缺陷的影响范围。通过测试人员与缺陷的亲自交互，为项目组提供专业的缺陷定位分析。

在案例1中，iOS7系统用户日活上报陡降，可能有两个原因：一是iOS7系统的用户装不上新版本或者无法正常启动；二是iOS7系统用户能够正常使用，只是上报信息出现问题。这是需要测试人员来验证的，首先在上线前测试时验证过iOS7系统的安装与启动，其次从appstore渠道下载最新版，在iOS7各个子系统和机型上尝试，都不会出现无法启动的问题，原因一排除。通过连接灯塔系统，发现iOS7系统在所有的上报信息都无法查找到。判断原因二有很大的嫌疑。进一步确认是终端版本没有上报，还是灯塔系统出现故障。通过抓包确认，终端确实没有上报信息到后台，因此判断为版本质量问题。这便确定了缺陷所在的区域是终端版本。

接下来判断缺陷产生的历史时期，6.5版本存在这个问题，那么自然的要确认6.4版本和即将发布的6.6版本有没有同样的问题，经过同样的验证方法发现6.4和6.6版本都没有此问题，缺陷就发生在6.5版本。

最后还需要判断下缺陷的影响范围。按理在6.5引入缺陷后，没有被发现之前，开发是不会修复的，6.6版本也应该存在此问题。可是这里却要存疑，何故6.6版本"自动"修复了缺陷？

在经过"问"这个环节后，我们获取到了更进一步的信息。缺陷只存在于iOS7系统上6.5版本，终端不能够上报数据，灯塔系统正常。提出可疑点，6.6何时自动修复了缺陷。

　1.4 切

当测试人员把问这个环节的获取的信息提交给项目组后，就需要项目组进行CodeReview，来查找所有涉及iOS7网络上报的修改代码。开发根据提供的信息找到可疑代码如下图1-3所示。
图1-3
......
（点击阅读原文，即可查看全文）

推荐阅读

点击阅读☞5个简单的BUG追踪技巧

点击阅读☞B/S系统常见缺陷整理和解决方案

点击阅读☞如何写一个好的缺陷（Defect）报告？

点击阅读☞软件测试过程中的三种不常见缺陷

点击阅读☞一个令人纠结的性能测试缺陷