2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在北京召开。以“未来”为主题，汇聚国内外测试领域知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术帮助测试从业者了解最前沿的行业动态和最新的行业实践。搜狗科技高级测试开发工程师王鹏在《如何通过精准测试来解决效率黑洞》进行了主题演讲。王鹏指出，“准确和智能是精密检测的两个着力点，如何从实证方法上改进技术手段才是精密检测的目的。”以下为王鹏演讲实录：大家好，今天我要跟大家分享的主题是《如何通过精准测试来解决效率黑洞》。希望大家听完后，思考一下是否适合进行精密测试。如果现阶段不合适，我的目的就达到了。第二点，如果确实可以做精准测试的话，希望大家听完之后能学到一些方法，知道在什么阶段介绍什么方法可以解决什么问题，可以达到什么效果。想做的话，回去之后就可以一步步开始了。执行。分享分为三个部分：1.影响我们测试效率的因素有哪些，既然这样做肯定是有原因的。2.简单介绍一下精密检测的思路。最近又开始精密测试了，有些同学还不是很了解。3.介绍一下我们用来提高效率的具体方法。每个阶段都会详细介绍。首先说一下影响效率的因素。这是在向大家诉苦。这个话题我选择了“黑洞”这个词。大家可以看到这张照片是美国宇航局前段时间发现的第一张黑洞照片。当我选择这个主题时，这张照片还不存在。我为什么选择黑洞？为什么是效率黑洞？因为它们有相似之处，什么是黑洞？质量很大但体积很小。我们通常从事什么样的工作？测试的工作很辛苦，付出很多，但可能收效甚微。是什么导致了这样的情况？分析：1、投入产出比。不知道大家平时做事的时候有没有考虑过这个问题。这件事其实对自己的影响很大。你可以仔细考虑一下。人们常说我们的工作效率低下。对我们的直接影响是你的。创新工作特别难启动。作为一个测试工程师，如果我整天被工作束缚，做着重复性的工作，可能很多人都是这样，而我一开始也是这样，那么很难进行一些创新的工作，或者你而老板提出如果你有一些想法去做这些创新的工作，你可能没有时间。老板会和你讨论，这些创新工作的投入产出比是多少，效果如何，花了那么多时间会有什么结果？这是我们面临的困境。2.我们的结果无法衡量。正如很多分享嘉宾所提到的，如果没有意外的话就没事了。一旦网上发现问题，经常追溯的时候，开发就可以检查代码了。如何回放我们整个测试过程是不可测的。这个有问题，你觉得我哪里错了？如果我们的工作是不可衡量的，当我们真正关心这件事情的时候，我们就处于非常非常被动的位置。因为这两部分，如果这一次出了问题，下次你要投入更多的精力，从另一个角度影响你的效率。说完自己的亲身经历，再回顾一下平时的工作。我列出了两个项目：黑盒测试和白盒测试。你可能认为这是陈词滥调，但事实并非如此。今天，我们听到并分享了许多先进的黑盒测试方法。据我们了解，在很多大厂，包括很多公司，黑盒测试仍然占学生的80%以上。这是一个无法回避的问题，大量的同事还在搞黑盒测试，所以我们如何帮助他们其实是一个很重要的问题。说到黑盒测试，我会从流程、效果、管理三个方面来谈。黑盒测试的流程是怎样的？因为黑盒测试看不到代码，整个测试过程伴随着大量的猜测。在测试这个功能的时候，你可以根据自己的经验来猜测是否会出现一些问题。在设计测试用例时，您还依赖于Guess。二是不稳定，体现在很多方面。举个极端的例子，今天的测试可能和昨天的测试不一样，今天你身体不舒服的时候测试的版本可能和你身体好的时候有不同的结果。三是难以控制。正是因为太多的因素，导致整个黑盒测试过程不可控。我说要考个90分的版本，这个怎么定？效果与个人素质有很大关系。新人和老手的业务测试质量差别很大。在座的很多管理者，如果你管理一个黑盒测试团队，你面临的困难是什么？管理测试开发团队，评估你的代码开发能力和代码设计能力，其实并不是一件难事。我们跟你打过几次交道，你帮我实现几个功能，你基本就知道你的背景了，你就知道是什么情况了。工作可以交给你开发，那业务呢？您可能有自己熟悉的业务。例如，您有测试需求。在测试需求的众多业务中，30%是你熟悉的，70%是陌生的。可以给你吗？如何选择合适的同事来测试这个版本？这是一个非常大的问题，对黑盒测试团队的管理者提出了很大的挑战。当出现问题时，我们反思这个问题，那个问题在测试过程中需要注意。经理们问过自己为什么选择他吗？为此，如果你选择另一个同学，你能避免他犯的错误吗？这是一件困难的事情。另外，再说说白盒测试。这里有人做过白盒测试吗？那里有两个。不知道你是不是互联网行业的。其实我不推荐做互联网行业的白盒测试，因为白盒测试是因为MicrosoftOffice开发周期极长而产生的。上线三个版本，完成后门槛高。团队中一两个人可以做白盒测试吗？单兵作战，你能把一半的考验交给另一个同学吗？没有办法交出来，只能自己动手。第三个目标相对简单。在做白盒测试的时候，我们一般会评估我们的测试是否到位。基本上只能靠覆盖率。在白盒测试过程中，覆盖率达到一定的目标，就代表OK。目标非常单一。还是没有办法大家一起来做。一个版本来的时候，大家一起做白盒测试，最后一起汇总结果。这也很难做到；四是分析的投入产出比比较低，可以完成。以后只能说“你看，这些逻辑确实覆盖了，没问题”，但是你找到bug了吗？没有找到。这种情况很常见，所以白盒测试不适合互联网行业，所以现在大家一直在做灰盒测试。我们基本上通过黑盒测试来测试，在黑盒测试的基础上更高效的解决问题。这就是我们面临的现状。第二，给大家介绍一下精密检测的思路。我简单介绍一下这句话。我会再看一遍，因为我看了很多与精度相关的资料。我觉得这句话总结的很好。精密测试是“用非常精确和智能的软件来解决软件测试的问题，从根本上引领软件测试从经验方法向技术方法的转变”。它强调两点。首先，要解决问题。准确度和智能化是精度测试中需要重点关注的两点。如果做精度测试，一定要重点关注这两点。它要达到的目标是什么？？从经验方法到技术方法，黑盒测试大多依赖于经验方法。如何在实证方法上改进技术手段，是我们精准测试的目的。我分别介绍一下。先介绍一下precision需要做什么。我们的精准度1.从测试用例到代码逻辑记录的双向溯源。什么是双向可追溯性？执行黑盒测试用例可以直接映射到你的代码逻辑，代码逻辑也可以反向用于测试用例。它必须是双向的。如果是单向的，这个效率是提高不了的。多少。如何实现？代码逻辑与测试用例的关系是通过函数调用关系来计算的。我们提出了一种叫做代码着色的方法，后面会详细介绍。2.准确的代码级缺陷定位和崩溃分析。在做黑盒测试的过程中，我们要给黑盒测试的同学们提供哪些方法呢？测试发现bug后，他就知道是哪一段代码有问题了。要达到这个效果，crash也必须能够落入crash分析。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文件来分析计算函数之间的调用关系。具体就是如图所示的结果。当你分析类的健壮性时，你会输出这样一个文件。上面有很多调用关系，但它只是一层调用关系。我们需要通过这一层调用关系将它们串起来。,左右关联就可以了，所以我们需要关联函数调用链。当然你也可以看到第三方库中有很多函数调用关系。其实可以通过过滤器过滤掉不相关的。如何分析diff结果，改变代码段，解析diff结果文件，计算改变的文件名和改变代码段的位置信息。它会在第三行和第五行写一堆操作。对于这段代码段，我们需要通过整个diff结果文件，计算出JAVA文件中的代码信息，解析，保存。如何改函数，我们通过扫描源文件和代码段的信息来判断一个包含关系。比如函数A包含这段代码，我们就认为函数A发生了变化，这样计算变化的函数分类。影响范围如何计算？结合函数刚才说的调用关系，划定受影响函数的范围就是这样一个过程。比如diff结果，A.java，code有起始位置和结束位置，A.java的原文件也有这个信息。你可能会问，一个函数的结束位置怎么判断，开始位置就可以判断，因为你知道可编译函数本身就有编译器，不需要到那个层次，比它简单多了。只要提取出函数位置，就一定有类特征。函数的起始位置没有问题，结束位置也大致理解了。就是下一个函数起始位置上面的那一行，但是可能会有一些细节，比如嵌套类，其他函数的应用等。我们会处理这个细节，但总体思路是这样的。所以如果第一个代码段落在函数1的区间内，我们就认为这个代码段属于那个区间，大概就是这个过程。如图，具体分析SVNdiff的结果，代码段，大家拿到PPT的时候可以详细参考，我就不赘述了，很简单。三种定义方式中我们如何判断函数，只要确定了函数信息，获取了位置信息即可，无需深入分析。我们实际达到了什么效果？我们要达到什么效果？以我们的项目为例，给出了两个版本号。这两个版本分别是待测版本和待比较版本，下面会计算其变化函数。这个更改函数包括依赖函数，因为这两个选择比较接近，更改这些内容后，我们这次需要关注的所有范围的函数信息都在这里了。以上主要从代码层面介绍影响范围，最后落在测试用例上。这是最关键的，那怎么办呢？其实我们也是从一些笨办法入手的。这个东西有时候不可能达到最优的方式。给大家介绍一下整个过程，大家可以好好想想。首先，手动输入是一种非常低效的方式，但为什么要开始呢？因为我们之前做过这个，虽然我们不做白盒测试，但是我们也做灰盒测试。测试人员还需要阅读代码。看完代码，他就更容易进入了。这是不可持续的。本来就是很低效的。手动阅读源码，梳理出与业务相关的功能，并与测试用例建立关联。理解了这个功能之后，如果觉得它和哪个用例相关，可以手动关联。这种占20%，他们会抱怨我们怎么能给他们提供辅助信息。工具也很认同开发，因为他们也想提高自己的代码质量，要求他们写好注释。我们推动开发写注释，使用工具提取功能和注释信息。有测试用例对应的场景，仍然需要手动建立测试用例的关联。这部分约占30%。我把它定义为中等效率。其实它的效率不高，开发写注释是可以的。你的理解有偏差，但是辅助信息比第一个多，其实最好的是效率更高，是代码着色的工作。根据测试人员的行为，自动录入测试用例与功能的对应关系。我们特别希望在做黑盒测试的时候能够记录黑盒测试行为。这是最好的办法。可以看到最笨的方法就是用excel。并不是每个人都必须从头开始做这件事。其实他们之前也开始做这个了，但是要求对应测试用例级别。后来我们提供了一个平台，但是并没有从根本上解决这个问题。如图，这是在做代码覆盖的时候。在做覆盖率分析时，可以直接输入函数相关的内容。效率提高了，但最根本的问题没有解决。下面我给大家介绍一下代码染色的思路。码染分为5步，离不开覆盖率。首先我们在执行黑盒测试用例的时候，我们会收集覆盖率，因为我们已经实现了黑盒测试覆盖率的实时收集，比如我开始记录我的行为，黑盒测试执行了某个行为，收集覆盖率，分析覆盖率结果。覆盖率发生变化的函数肯定是和这次执行相关的，我们会对这些代码进行着色，着色会反向对应测试用例层级，结合之前函数调用关系的计算，相当于放大范围有点大。如果这些功能发生变化，就会映射到黑盒测试用例，从而形成双向可追溯性，用例也可以在功能级别执行，功能级别的变化可以映射到用例，大大提高了这种方法的效率。筛选测试用例的流程如图所示。一是基线版本代码与测试版本代码diff，以及diff结果分析计算的软件和方法。计算方法会将依赖项放入库中进行比较。如果库中有，会直接从用例库中筛选。一些新添加的需求必须手动编写。没有办法做到这一点。你需要手动填写用例，最后合并成一个完整的测试用例。如图所示，这是我们最终得到的结果。当你过滤出结果时，它包括所有功能的信息，对这些功能的理解，以及最终要执行的测试用例级别。您可以通过单击它直接执行测试用例。让我简要介绍一下覆盖率。我们主要做两种，JAVA覆盖率和JS覆盖率。JAVA我就不多说了。每个人都使用jacoco，但我建议使用on-the-fly模式。我们为JS选择了一个工具。大多数工具都支持单元测试，对我们的黑盒测试不是很友好。我们基于JScover做了二次开发，实现了插报加代理的方法，同时支持ES6编译文件的源文件和Instrumentation。JS多了一个东西，覆盖无非就是四个东西，代码插入，数据上报，文件映射，报表生成。代码检测主要是针对源文件和编译后的文件，JScover可以做到这一点。数据上报可能需要修改一些代码，文件映射需要代理，将所有在线请求映射到本地都需要代理。报告生成本身其实更好支持。数据上报可以通过一些事件上报。这里有两个，比如页面切换。测试PC时，如果出现页面切换，就让它报一次。如果它是无线的，它可能涉及滚动。这种情况一般是鼠标移动，所以不要每次都报，因为会给业务测试带来很大的压力。例如鼠标向下滚动一次，则鼠标操作时会报一次。这种前端测试导致的性能问题不会被发现，工具导致的性能问题也不会有。效果还不错。如果你对此感兴趣，可以回去看看。再来说说ES6，为什么要兼容ES6标准呢？前段时间大家用JS框架开发，都采用了ES6的方式，已经不是原生JS了。以前可以通过JS发帖举报。如果需要编译，像右图应该怎么办？选择什么节点进行检测？源代码易于阅读但不可执行。这种仪器是没有意义的。编译后更容易执行。压缩和混淆后不易阅读和执行。我们为编译的检测选择了这种方法，这样就可以选择ES6。发展模式。你可以参考一下。这是我们的覆盖率分析。有JS项目和JAVA项目。他们都支持立即收集报道。前端可以做一些工作来实时检查覆盖率。这是报道。基本信息，如图，相当于左边是JAVA结果页面，右边是JS页面。JAVA部分有bug提示，相当于diff结果。查看哪个部分未涵盖。如果这一段功能有告警，有bug，也可以查看一下，可以打通。这就是我们的整个测试过程，这里列出来。如果我们做精确测试，我们可以在哪个部分做。首先，测试前，跟大家差不多，requirementsreview，usecasewriting，usecasereview，preparationbeforetesting，testingwalk-through，这个主要是在testingtopre-release和onlinesupport这部分支持。它用于测试人员，也用于开发前的默认测试和产品发布前的演练。我们现在所做的工作如图所示。可能每个公司都有不同的东西。我们这边不是运维发布代码。其实开发有很大的权限。它可以直接发布代码。我们发布所有的开发系统都被监控了，他们有代码发布。无论是线上还是测试环境，我们都会从这里开始所有的操作。只要有释放，这部分就会自动执行。如果有测试，在测试行为发生后，我们的测试人员会收到一封包含上述所有计算结果的邮件，所有信息都可以在测试前获取，最大限度的帮助功能测试人员提高他的测试效率.持续集成还将与许多自动化平台连接。这些自动化都是精准的自动化，都是筛选出来的自动化用例。以上就是我的全部分享内容。
