第二，就给大家介绍一下精准化测试思想，简单介绍一下，这有一句话我念一遍，因为我看过很多精准化相关的资料，我认为这句话总结的非常到位，精准化测试就是“用非常精准和智能的软件来解决软件测试的问题，并从根本上引领软件测试，从经验型方法向技术性方法的转型”。它强调两点，首先当然是需要解决问题的，精准和智能是精准化测试里要聚焦的两个点，如果做精准化测试一定要聚焦在这两个点上，它要达到的目标是什么？从经验型方法向技术性方法转移，黑盒测试大多依赖于经验型方法，如何在经验型方法中提升技术性的手段就是我们精准化测试的目的。

分别介绍一下，首先介绍一下精准要做哪些事，我们这边的精准：

1、测试用例到代码逻辑精准记录的双向追溯。什么叫双向追溯，执行黑盒测试用例直接就能映射到你的代码逻辑上，看代码逻辑也能反向用到测试用例上，一定是双向的，如果是单向的，这个效率是提高不了多少的。怎么实现？代码逻辑到测试用例是通过函数调用关系计算来的，我们提出一种方法叫代码染色，这两个都会在后面详细给大家介绍。

2、精准的代码级的缺陷定位和崩溃分析。在做黑盒测试的过程中，我们一定要给黑盒测试同学提供什么样的方法？测着测着发现一个bug，他自己就知道哪块代码出问题了，要达到这种效果，崩溃也是要能落到崩溃分析上。

3、精准的测试充分度分析，主要是解决测试不可度量的问题。

智能有哪些？主要列了3点：

1、回归用例的自动筛选。

2、自动化用例筛选与执行。

3、持续集成。

第二部分就简单介绍到这，主要介绍第三部分，告诉大家如何去做，上面那些事，如果我想做的话一步步怎么做？我给大家分享我们在搜狗社区具体应用的案例，我们现在正在做的事，大概是做成什么样子。

首先再给大家提一下影响效率的因素，因为我们这里主要要解决效率的问题，列了很多，刚才也有人说过了：

1、团队新人没有经验。

2、团队新人能力不足。

3、测试范围圈定凭经验。这里我们经常遇到那种情况，开发改了一段代码，需求上写的很清晰，我们都测到了，但是却有另外一个场景出现问题，是有关联的，我们很难把那部分测试用例圈出来。

4、测试用例筛选难，让你从曾经的测试用例筛选出这次的测试用例，这个很难。

5、测试经验沉淀效果差，我们这个测试经验沉淀基本是口口相传，沉淀的东西是静态的，无法动起来，看代码、整理接口、就编成一篇篇测试文档，或者在某个软件、某个平台里落在那儿了，它动不起来，不实际，用到不会查，查还可能查不全，怎么让这些资料主动为你提供帮助，这是我们做的事情。

6、测试人员状态不稳定，主要是指大家的心理和生理状态。

最初我们给自己提了4个目标，我们要解决的问题：

1、要精准圈定我的测试范围。

2、对影响的范围必须给出建议；如果测这个版本要有个东西，暂且叫它软件，要告诉我还有哪些东西要考虑。

3、自动筛选测试用例，要测这个版本了，至少给我一份测试用例让我做参考。

4、为黑盒测试提供实时覆盖率结果。

为什么强调实时覆盖率改革呢？有时候我们经常做覆盖率，一堆功能做完了，让我们出一份覆盖率软件去分析，发现有几行没有覆盖到，再往回推，效率也是比较低的，我们要达到什么情况？比如，我执行了非常短的业务流程可能就是一个登陆，三步操作，输入用户名、输入密码、提交，这三步操作希望知道我的覆盖率是什么，及时调整覆盖用例，这个对我们价值是比较大的，所以我们必须为黑盒测试的同学提供实时的覆盖率分析。

刚才说了那么多我们一步步介绍，下面是具体每一步是怎么做的：

筛选测试用例，一共做了三步：版本提测的时候做哪些事情，首先会提供提测版本的信息和线上版本的信息，我们对这两个版本进行diff，计算出diff结果，结合变更函数计算，通过调用函数关系的计算，现在想想diff软件里面是有很多代码段的，告诉你在哪一行发生了变化，这一部分是他提供给我们的信息，我们要从这个信息里得到什么结论呢？首先要把变更函数计算出来，这些代码段映射到函数上是哪些函数发生变动这我要知道，那么和这些函数相关联的还有哪些函数？它的调用关系我们要知道，要做到这两点，要从diff结构解析后面两部分。第三是测试用例生成，解析出来的函数映射到测试用例上，这些函数发生变化或者这些函数关联的功能发生变化就可以把这部分测试用例筛选出来。

针对依赖关系举个例子，开发为了实现功能1，同时修改了函数A和函数C，其中函数之间调用关系功能1是C调用A，功能2是B调用A，开发是改了A了，提了C这个场景，B调用A就可能出现问题，函数调用关系计算就是为了解决这样的场景。

我们这边服务端的语言都是JAVA，所以我们是使用了JAVACG工具，通过对class文件解析计算函数之间的调用关系。具体就是如图这样的结果，当你解析对于class稳健的时候会输出这样的文件，一大堆调用关系在上面，但是只是一层调用关系，我们需要通过这种一层调用关系把他们串起来，左右关联一下就可以了，所以我们要把函数调用链关联起来，当然你也可以看到，其中有很多第三方库的函数调用关系，其实可以通过过滤器把不相关的过滤掉。

diff结果解析怎么做的，变更代码段，解析diff结果文件，计算变更文件名和变更代码段的位置信息。它会写第三行第五行发生了一堆操作，这个代码段我们要通过整个diff结果文件算出JAVA文件里的代码信息解析出来要保存。变更函数怎么办，我们通过扫描源文件和代码段的信息判断一个包含关系，比如函数A包含了这个代码段我们认为函数A发生了一种变化，通过这种方式计算变更的函数分类。影响范围怎么计算？结合函数刚才说的调用关系，圈定受影响的函数范围，是这样的流程。

举个例子，比如diff结果，A.java，code有个开始位置、结束位置，A.java原文件里也有这些信息，你会问，如何判断一个函数结束的位置，开始位置可以判断，因为你知道可编译的函数自己本身是有编译器的，不用达到那个级别，比它简化很多，只要把函数位置提取出来，肯定是有一个class特征的，函数开始位置是没有问题的，结束位置大概理解成下一个函数开始位置的上一行，但是可能有细节，有嵌套类、其他函数的套用，这一块细节的地方处理一下但是整体思路是这样的。所以如果第一个代码段落到函数1的区间范围内的话，我们认为这个代码段属于那个区间，大概就是这样的过程。

如图就是具体解析SVN diff的结果，代码段，大家拿到PPT可以详细参考一下，我不详细讲了，非常简单。三种定义方式我们如何判断函数，只要把函数信息确定，位置信息拿到就可以了，不用做更深的分析了。

我们实际达到的效果是什么？我们要达到什么样的效果？以我们工程为例，给出两个版本号，这两个版本是这次提测的版本和要比对的版本，底下就会把它的变动函数计算出来，这个变动函数就包括依赖的函数，因为这两个选的比较近，改了这些内容，我们这次需要关注的所有范围的函数信息就在这里。

前面主要介绍从代码层面影响范围，最终还是要落在测试用例上的，这是最关键的事情，那么怎么做的？其实我们也是从一些笨方法开始的，这个东西有时候不可能一下达到最优的方式，给大家介绍一下整个的历程，大家可以思考一下。

现场视频（下）

首先，人工录入是一种非常低效的方式，但是为什么从它开始呢？因为我们以前就做这件事，我们其实虽然不做白盒测试，但是我们也是做灰盒，测试人员也是需要看代码的，看代码了就让他录入时比较顺手，这件事情不可持续只是它原本效率就很低，人工阅读源码梳理与业务相关的函数，并与测试用例建立相关性，看懂了这个函数，觉得和哪个用例相关的就人工手动关联上。这种占20%，他们会提一些抱怨，我们怎么给他们提供辅助信息，工具也跟开发达成一致，因为他们也希望提高自己的代码质量，要求他们写良好的注释，我们推动开发撰写注释，使用工具把函数和注释信息抽出来，那里面有和测试用例对应的场景，还是需要人工建立测试用例的相关性。这一块大概占30%，我定义叫中效，其实它的效率也不高，而且还有可能开发写的注释，你理解上有偏差的地方，但是比第一种又多了一些辅助信息在，其实最好的是比较高效是代码染色的工作，根据测试人员行为自动录入测试用例和函数的对应关系，我们特别希望做黑盒测试的时候可以录制黑盒测试行为，这样是最好的方法。

可以看一下最笨的方法是用excel的方式，并不是强制要求大家从零开始做这件事的，其实之前也开始做这件事了，只不过要求它和测试用例级对应上，后来我们提供了一个平台，但是没有从根本上解决这个问题。如图这是做代码覆盖率的时候，做覆盖率分析的时候可以直接把函数相关的内容录入进来，效率是有提升，但是还是没有解决最根本的问题。

给大家介绍一下代码染色的思想，代码染色分5步，离不开覆盖率，首先我们在执行黑盒测试用例的时候，会收集覆盖率，因为我们已经做到了黑盒测试覆盖率的实时收集，比如开始录制我的行为的话，黑盒测试执行一段行为，收集覆盖率，解析覆盖率的结果，覆盖率当中发生变化的函数和这一次执行肯定是有关系的，我们会把这些代码进行染色，染色就会和测试用例级反向对应上，再结合之前的函数调用关系的计算，相当于把范围稍微放大一点，这些函数如果发生变化的话都会映射到黑盒测试用例上，这样就形成了双向追溯，执行用例也可以到函数级别，函数级别变化可以映射到用例上，这种方法效率就得到了很大的提升。

筛选测试用例的流程如图，首先是基线版本代码和测试版本代码diff，对diff结果进行解析计算变更的软件和方法，计算方法会把依赖关系入库做比对，如果发现库中有的话，直接会从用例库里筛选出来，有一部分新增的需求肯定是要手动撰写用例的，这部分没有办法，需要手动把用例补上，最后合并成一份完整的测试用例。

如图这就是我们最终达到的结果，当你筛选出来结果的话，包含所有函数的信息以及对这种函数的理解和最后要执行的测试用例级，点进去可以直接执行测试用例。

简单给大家说一下覆盖率，我们主要做两种，JAVA覆盖率和JS覆盖率，JAVA不多说，大家都用jacoco，但是我建议用on-the-fly模式。JS我们选择了一种工具，大部分工具都是支持单元测试的，对我们黑盒测试不是很友好，我们基于JScover做了二次开发，实现插桩上报加代理的方式，同时支持源文件和ES6编译文件的插桩。

JS多说一句，覆盖率无非要做四件事，代码插桩、数据上报、文件映射、生成报告。代码插桩主要针对源文件和编译文件，JScover就可以做这件事情。数据上报可能需要改动一些代码，文件映射需要一个代理，把所有线上的请求映射到本地这一块需要有个代理。生成报告这块，实际上自己支持的也比较好。

数据上报，可以通过一些事件进行数据上报，这里列了两个，比如页面切换，像测PC的时候，如果页面发生切换就让它报上来一次就可以，无线的话可能涉及到滚动，这样的话一般是鼠标移动，不要行行都报一次，那样对业务测试压力比较大，比如鼠标往下滚动一次，鼠标有操作了就报上来一次，这种不会发现前端测试有性能问题，工具引起的性能问题不会有，这个效果还不错，这个大家感兴趣可以回去看一下。

说一下ES6，为什么要兼容ES6标准呢？前段时间大家都用JS框架开发，他们都是采用ES6方式了，已经不是原生JS了，之前是在JS插桩就可以上报了，需要编译的话像右图这种怎么办？选择一个什么节点进行插桩呢？源码是易读不可执行的，这种插桩没有意义，编译后较易度可执行，压缩混淆后不易读，可执行，我们选择了这种方式对编译后的插桩，这样可以选择ES6的开发模式。

大家参考一下就可以了，这是我们一个覆盖率分析的，有JS的工程也有JAVA的工程，都是支持立即收集覆盖率的，前端做一些工作就可以覆盖率实时察看，这是覆盖率的基本信息，如图相当于左边是JAVA的结果页面，右面是JS的，JAVA这一块有一个bug的提示，相当于这是一个diff结果，看哪块没有覆盖，如果对这一块函数有告警说它有bug的话也可以察看，都可以打通。这是我们整个的测试流程，把它列在这儿，如果做精准化测试的话，可以在哪个部分把这个事情做了。首先提测前，跟大家差不多，需求评审、用例编写、用例评审、提测前准备、提测走查，这个主要支持在提测到预发布、上线支持的部分，我们筛选出来的测试用例不仅用于测试人员而且还用于开发的提测前的默验测试以及产品提测前的走查。

我们现在做的工作如图，可能每个公司都有不一样的东西，我们这边不是运维发布代码的，实际上开发有很大的权限，它可以直接把代码发布，我们对开发所有发布系统做了监控，他们有代码发布，无论是线上还是测试环境，我们这边会启动所有的操作，只要有一次发布这一块都会自动执行，如果有测试的话在他提测行为发生以后，我们测试人员就会收到一封邮件，邮件里包含上述所有的计算结果，测试之前就可以拿到所有的信息，最大化帮助功能测试人员提高他的测试效率。持续集成这一块也会跟很多自动化平台打通这些自动化都是精准自动化，都是通过筛选出来的自动化用例。

关于Testin