作为测试工程师，最常接触的就是各种缺陷，如何将缺陷变废为宝，对今后的测试工作产生指导价值，这是我们做缺陷分析的终极价值，也相当于把别人口袋的钱（代码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网络上报的修改代码。开发根据提供的信息找到可疑代码，进一步展开分析，发现在修改小说网络层缓存时影响到了iOS7的网络上报。

别忘了，还有一个疑问点，为何6.6自动修复了缺陷？再“切脉”发现有一位开发当时进行CR时觉得那部分代码写的不够好，可能存在隐患，就给重构了，也就避免了iOS7上报出现问题，但是这位开发自身也是不清楚之前还存在这个问题，所以缺陷就在悄无声息中解决了。

到了切这个环节，我们已经基本定位出了缺陷产生的根本原因。新手开发在修改小说的问题时，影响到了iOS7系统的网络上报，导致了iOS7系统用户在安装6.5版本后无法上报信息到灯塔，从而导致日活陡降30万。解决方法只能靠快速发布patch版本来进行修复。

纵观整个望闻问切的过程，就是从现象逆向追踪到本质的一个定位，也是一般bug分析的必经过程。很多时候我们写出来的报告像是事后诸葛亮的感觉，就是仿佛已经知道了原因，再来分析影响。还原缺陷分析的真实过程对我们再进行分析能够起到很好的梳理作用，明白自己所处的阶段。

二 缺陷报告（正向演进）

对项目组开发来说，一般从缺陷能够逆向追踪到产生的代码原因，解决了基本上工作就结束了。但是我们测试人员在这个过程中还可以挖掘更多的有价值的点。这也是要写缺陷报告的原因，通过上一章的逆向追踪，我们已经可以知道缺陷相关的情况，如何变废为宝，将缺陷的价值挖掘到最大，并指导今后的测试就看这个正向演进的过程。

如何呈现一份好的缺陷分析报告，也是一个考验功力的时候。本文笔者建立一个缺陷分析模型如下图2-1所示。既要聚焦于当前的问题，又要有宏观分析的视角。从现象到思考逐层深入分析，每一层又对应着宏观的分析。通过该模型的方式演进缺陷分析，能够将问题剖析的相对清晰，指导今后测试也有借鉴意义。

图2-1

图2-1所示的模型主要是说明缺陷报告要分为四层，分别是缺陷现象、复现路径、缺陷原理、缺陷思考，这四层是我们做一份完整的缺陷报告不可缺少的，也是层层递进的一个逻辑关系。右侧的是宏观方面的对应，就是除了要就事论事分析bug，还要跳出当前bug，看的更加宏观一些，思考广角要大，宏观的四层也是一次递进的关系。具体可见下文讲解。本节内容搞的案例承接上文，仍然采用手机浏览器掉粉事件。

2.1 缺陷现象——缺陷影响

首先要描述缺陷发生时的现象，这个容易做。站在宏观的角度来看，还要列出缺陷产生的影响，如表2-1所示。

表2-1

对应本文案例记录如下。

缺陷现象：6.5版本的iOS7系统用户无法上报使用数据。

缺陷影响：如表2-2所示。

表2-2

总结一下这一层面的描述要求：

缺陷原理的描述要求：有图有真相，闪退附日志。（如果可以现象图，最好附上，便于读者能够清晰认识到缺陷的现象，如果是闪退了，还需要附上日志）

缺陷影响的描述要求：机型必现度，修复影响度。（主要是指表格中的项都要有完整说明，对于了解缺陷在宏观层面上的影响有所帮助）

2.2 复现路径——测试思想

接下来要描述复现bug的路径，每个复现路径都蕴含着一定的测试思想。这里为了抽象，可以引用探索式测试全局测试策略中的一些方法，例如下图２-2所示的几个举例。实际情况是可能是几种测试思路的组合。

图2-2

对应本案例记录如下：

复现路径：在iOS7手机上，安装6.5版本（全新或者升级安装），启动浏览器，无上报信息。

测试思想：指南针测试法（按照需求进行验收，iOS7系统用户上报是必备的）。

总结一下这一层面的描述要求：

复现路径的描述要求：言简意要明，完整路径全。（语言简洁明了，不能大篇叙述，必要时可以考虑用流程图等不同形式来展示，其次路径需要描述完整，如果存在多个复现路径或者对应多种现象都需要注明，不要遗漏。）

测试思想的描述要求：路径含思想，关联知识库。（这个是指复现bug的操作应该蕴含一定的测试思想，用可理解简要词汇表示，可以记录到bug的知识库里，也可以从bug知识库里寻找历史相关的bug，重新整合思考。）

2.3 缺陷原理——代码关注

在微观上了解了缺陷现象和复现路径，还需要深入说明缺陷原理，缺陷原理一般落实到代码层，有时候考虑到成本问题可以只到逻辑层。可以采用5W法（http://baike.baidu.com/view/4238021.htm），提问逐层分析问题产生的原因。这个5W涉及的问题可以是在逆向求证的时候思考过的，也可以是就测试人员为何漏测或者开发人员为何写出缺陷代码进行提问。

定位缺陷发生的原理后，开发和测试人员都要提炼出关于今后写代码需要格外关注的点，将相关逻辑进行完整排查，确保没有类似的问题。

对应本案例的描述如下：

缺陷原理：

1.为什么手机浏览器日活近期掉粉30万？

因为发布6.5版本，安装了6.5版本后，iOS7系统上的日活陡降30万。

2.是什么原因导致的日活陡降？

因为iOS7系统用户使用6.5版本浏览器后无法上报日志到灯塔系统。

3.所有iOS7系统有这个问题吗？会不会跟机型有关系？

所有iOS7系统都存在此问题，iOS8、iOS9都是没问题的。与机型无关。

4.在6.4版本和即将发出的6.6版本没这个问题吗？

旧版本和即将发出的新版本都没问题，问题只存在于6.5版本上。说明是6.5引入的，在6.6上被无意中修复了。影响范围就限于6.5版本，需要发布patch。

5.是6.5版本什么时候引入的，什么情况下引入的？

在6.5的灰度阶段引入的，为了修改小说页面刷新后空白的bug，修改了网络层缓存机制，导致iOS7系统的网络上报存在问题。

6.开发的CR为何没有发现问题？

当时是过了CR，但是没有发现可能存在隐患，只是觉得代码的逻辑实现不是很优雅，就暂时没动。后来在6.6的时候另外一个开发看着觉得逻辑比较乱，就重构了一下，自动修复了这个问题。

7.测试为何没有暴露问题？

这个问题反映了测试上报时候对系统的不关注问题。在问题发生之前，测试统计上报的测试都是不分系统，只要在一个系统上做了验证即可。理论上对上报类的只跟网络层有关系，与系统没有关系，但是从修改的代码中可以看出是针对iOS7系统做了单独处理，应该进行多关注。今后测试统计上报，会适当兼顾各个系统的情况。

代码关注：

开发需要关注网络层修改的问题，尤其是灰度后需要多找几个人进行CR，新人开发更是要多注意。测试人员在发生这个bug后，需要关注开发提交的影响点中涉及系统的网络层修改，在不同系统上对统计上报做个排查测试。

总结一下这一层面的描述要求：

缺陷原理的描述要求：５Ｗ深究到底，深入代码层。

代码关注的描述要求：开发关注点，逻辑完整查。

2.4 缺陷思考——扩展总结

在经过前面三个步骤后基本上就能够对缺陷有个全维度的审视和认知。但是要做文章开头说的把别人口袋里的钱放到自己口袋里，还缺最后一个很关键的环节，就是微观上关于缺陷的思考和宏观上的扩展总结，这些也是要呈现在正向演进的报告里，提高测试报告的“含金量”。缺陷思考主要是反问自己是否真的解决了问题，这个看似简单，其实最容易出问题。开发修复了代码后 ，要做个全方位的验证，对相关模块也要做关联测试。宏观上的扩展总结是可选项，可以对历史上类似的bug做个梳理，有能力和时间的话还可以对相关的架构做个完整梳理。

对应本案例的描述如下：

缺陷思考：经过修改后，在6.6上测试发现iOS7上上报ok，日活在灰度时也会到正常水平。继续做关联性测试，既然日活上报没问题，那么深入看看各个业务在不同系统上的具体上报，发现6.6灰度后引入了一个新问题，就是只有初始化状态的上报，没有后续的功能使用上报，于是再次修复。通过关联测试增强了测试人员挖掘缺陷的能力，对类似问题进行了围堵式打击。

扩展总结：

梳理历史上关于统计上报的知识库。过往只有某些业务上报存在不准确或者漏报的问题，现在可以增加对系统的覆盖检查，上线前的checklist里也可以增加一列。

总结一下这一层面的描述要求：

缺陷思考的描述要求：确认不复现，关联性测试。

扩展总结的描述要求：历史相关联，架构梳理清。

由此正向演进的过程梳理完毕。

三 写在最后（讨论分析）

如下图3-1所示，概括了是本文的总体思路。缺陷分析的正逆向分析，逆向求证重点在于从缺陷现象通过望闻问切四诊法寻找到问题的本因，也即缺陷定位，而正向演进侧重报告输出和逻辑理顺，从得知根因开始，从根因开始理顺影响和整理测试思路，完善知识库，指导今后更好的工作。

图3-1

在日常的测试工作中，我们与开发之间的互动主要体现在逆向求证的相互帮助和讨论中，逆向求证是能够体现团队协作和提高测试影响力的过程。最终的输出是缺陷报告的形式，可以参考本文提供的模型来进行梳理总结和反思。

在文章的最后，还是要讨论三个老生常谈的问题，任何一个理论或者模型的使用必然伴随着一个挑战，就是投入产出比如何？适用人群是怎样的？适用阶段是什么时候？本文就这三个问题和大家再进行一次讨论。

3.1 投入产出比

投入产出比我们分两个方面来分析，首先是线上反馈或者研发过程中的严重问题（例如闪退、功能障碍），不存在投入产出比的顾虑，因为这些问题都是必须验证和解决的。这里涉及投入产出比主要针对的是对日常的研发bug或者线上反馈的普通问题。笔者推荐如下思路。

缺陷定位（逆向求证）如何降低投入：

1）通过望的方式决定是否要进行下一步，如果问题判断影响不大或者没必要做进一步的分析，就可以在这一步终止。如果问题比较严重，就继续下一步。

2）在闻的这一环节，确认异常发生的位置，如果能找到，可以安排新人或者外包去进行“问”这一环节，例如验证发生版本、影响机型范围等。在这里可以减少一部分人力成本。

3）在切的这一环节，如果情况比较复杂，就需要联系开发进行处理，测试人员要视情况判断是否要深入参与，一般性的问题，经过前三个环节后基本可以交给开发来处理了。要紧的问题可以由测试人员继续跟进，直到结束。

缺陷报告（正向演进）如何提高产出：

1）练习本文的四层模型或者自己认为合理的模式进行缺陷报告总结，形成固有套路，提高报告撰写效率。

2）学习探索式测试思想，对测试过程中的操作能够快速找到指导思想，方便后续知识库的维护。

3）日常多思考，一个报告的缺陷思考和扩展总结方面可以邀请他人一起参与讨论，碰撞出思想火花，集思广益，提高思考的产出。

结合测试人员实际的经验进行判断，通过这种一升一降的方式，提高自己在缺陷分析方面的投入产出比。

3.2 适用人群

这个很多会问，这种缺陷分析是否适用于外包测试同学，新加入的正式员工合适可以开始做缺陷分析？我们一一来讨论下。表3-1所示，“√“代表适用，”*“代表不适用。这也只是个参考，具体还得因人而异，总体来说，各个角色都是可以通过学习和练习的方式逐步提高缺陷分析能力。手机QQ浏览器（iPhone）项目上从正式到外包同学启动了全员缺陷分析模式，效果还是不错的。

表3-1

3.3 适用阶段

适用阶段这个因项目而异，在iPhone浏览器项目组中，和项目组达成的共识是在集成测试后发现的闪退问题都要做缺陷分析，不管是因为集成引入的还是之前测试遗漏，都要做分析并同步出来。另外在每个版本结束到下个版本开始，每个外包测试同学会对自己负责的模块的典型的bug做根因分析，以此作总结回顾，并思考接下来的测试侧重点。