目录
写在前言的一些东西
大家好呀 ! 今天抽空我们来聊一下智能测试，其实说起智能测试，大家想到的大多都是类似于人工智能那样高级的东西，或者甚至是电影里面出现的那样机器人的场景。其实我们从现有阶段我们从智能测试的角度，落实到测试实际项目上好像完全又不是那个我们想要的样子，那么我们换个角度上来说，智能测试的是不是可以等于精准测试了，更加精准的去测试我们想要测试的范围或者说程序改动了，那么这样的人工智能测试更根本算不上人工智能的范畴，这里我们就叫做智能化测试方案吧。
举个例子
从上面的描述，大家可能不太理解我描述的精准测试是什么概念了，那么我们首先来看一下上面这一幅图，这幅图也就是找茬，找出不同点，找出两幅图的差异点，越快越好，越快越精准，那相对应的人员就赢了。那么我们换算一下了，我们在做测试的时候，越快找出bug点那么我们的测试效率以及质量是不是很好了，所以说到这里我们就出现了一个精准的概念了。
自动化测试真的是万能的吗
那么我们在测试的过程中快速精准找到bug了？拿上面的图来说，我们分为ab两个图 a图是dev分支b是master分支，一个是主分支代码，一个是开发修改过后的分支代码。每次是不是开发会给测试说我修改了一些代码，需要测试全量回归或者说部分代码回归部分功能点了，那么这个时候测试就很懵逼，说我如何全量回归了，我咋知道你开发修改了什么了？说到这里估计很多兄弟们就会说，写个自动化测试代码或者采用一些自动化测试手短就可以实现测试全面回归了。但是问题来了，在时间有限，money有限，资源有限的情况下，我们既要考虑测试是否充分覆盖率全面，又要顾及到时间，人员，配置，环境等更重条件限制。
那么说到这里我们就有些小伙伴或说到全量自动化测试覆盖，直接run起来不就ok了吗？但是自动化测试真的是万能的吗？
其实看到这篇文章的小伙伴估计也明白，其实自动化测试是有成本的那么也就是说你想使用它不是那么简单的，既然自动化测试有成本，那么它就有一定的局限性。
- 而这种局限性也就是一定的开发成本，同时在测试点变动以后测试代码是有维护成本的，外加自动化测试入门简单但是达到了一定的覆盖程度后，那么测试代码的使用并不简单，在很多时候是有学习成本的，还有自动化测试用例的设计是否足够的合理，这个也取决我们写自动化测试脚本的人员，对于被测业务，以及自身测试能力的考量。
- 再者新功能出现后，我们每次自动化测试在对新功能测试的时候具有一定的滞后性，一般情况下我们都是在新功能测试完成后再去补全我们的自动化测试覆盖率也称之为自动化测试全案例，所以由于这些局限性，在某些情况下我们采用自动化测试做一些全量覆盖是很难实现的。
外加目前现在大多数公司采用的是敏捷开发模式，那么迭代更新肯定是十分频繁的，所以我们在做回归测试的时候，如果测试人员不住掉变更的点在哪里，或者测试人员知道变更修改的地方在哪里，但是不知道影响的范围是多大，那么这个时候我们在把测试范围定小的情况下，就很容易出现漏测，从而导致上线后出现风险甚至是出现不可挽回的损失，要不就是刚才说的全功能回归，测试的范围过大，付出的代价也是十分巨大的，所以说到这里精准测试就显得尤其重要了，这个我们后面来说。
定位变动后之测试范围
在it行业中，在每次代码做了大的修改，或者架构方便做了调整，或者一些关键库或者jar包等等一些升级，很大情况下测试心里是没有底的，生怕漏册了，那么这里就说到上面说到的点了，作为测试我们如何才能精准定位到变更的范围了，测试真能确认覆盖到了所有改动后的被测代码了嘛，也就是相当于我们能确定全部观察到怪兽吃雪糕的所有的细节了吗。
- 这种情况在于黑盒测试的过程中，很大程度决定因素在于测试人员的经验如何，主观性如何，所以很有可能发生遗漏，一旦出现了遗漏的情况，不出意外肯定就是各种甩锅，没错吧各位看官！看锅是在测试这里还是在开发哪里了，可能这个时候会出现这样一个疑问，测试每次叫开发告知我们本次改了哪些代码，哪些方法，可能会影响哪些点不就完事了吗，测试有能力自己去分析代码这不不就完美了吗？
- 但是开发说的一定是对的吗，一定是全面的吗，即使是说开发能准确的说明改动的代码，那么改动影响所带来的影响范围开发能够评估起初嘛，如果开发都能将这些问题评估起初，其实就不需要测试了，同样的还有一些情况就是开发偷偷的改动了一些代码没告诉测试或者忘记了，这个时候我们不可能不管这些，就让它去发布吧。
所以综上所述，作为测试人员就应该考虑到更加精细化的一些测试了，也就是说我们测试人员想要做什么，一眼望去就能看出来，差异点就是本次改动什么，然后脑海中bi一下就出现了差异点所影响到的范围，这样我们就可以缩小测试范围，然后我们就可以进行测试了，测试完成之后我们在脑子bi一下一扫就知道哪些测试覆盖到了，确认一下我们的覆盖率是不是完整的，这就是我们想要达到的目的。那么这个目的的本质是什么，这个本质也就是我们所谓的精准测试，精细测试。那么接下来就开始说一下啥是精准测试了。
精准测试的定义
精准测试就是一种可以追溯的软件测试技术。大家说好像听起来很高端的样子，是吧？又叫量化数据，我们都听过量化投资，那在投资领域很高端，量化数据好像也很高端的样子，到底精准测试它是干什么的？它其实的核心思想就是什么？就是使用非常精确和智能的软件来解决我们软件测试里面遇到的一些问题，从根本上引领从我们原来以经验为主的方法转向用技术为主的这样的一个转型，质量的评估不再仅仅靠经验，而是通过精准的数据来判定。
所以精准测试其实没有改变传统的软件测试方法，它不算是一个新的概念，它只能算作辅助，它的区别只在于它由软件去采集测试过程执行的代码逻辑和测试数据的过程自动建立起来。测试用例和程序代码之间的逻辑关系在测试的过程中加入到软件的采集过程，可以形成一些正向或者逆向的回溯。来看看我们代码影响了哪些用例，我就执行哪些用例，对吧？所以正向逆向我们分开来看，通过正向追溯，我们可以看到测试人员执行用力所对应的代码细节，这样哪个用例挂掉了，我们知道了哪些代码会有问题，我们方便进行缺陷的修复。测试数据可以直接作为开发调试提供一些依据，快速定位并且修复缺陷，这是我们正向追溯的意义，而逆向追溯就是我们精准的内核所在，我们通过修改的源代码可以快速确定到测试用例的范围，这样可以极大地减少回归测试的盲目性和工作量，也方便我们快速的去修订测试用例，达到测试覆盖率的最大化。
look，这是我们精准测试的目的，也是我们精准测试的目标，以及是我们精准测试的核心。那怎么做到？刚刚我们提了几点，其实我们最主要的是什么？是从代码变化开始到要执行哪些用例，这是我们的开头和最终结果，那中间我们要做什么呢？就像我们前面说过的，我们想要一眼看过去，看到差异点，一下有了影响范围的评估，再一下我们就知道测试之后哪些用力覆盖到了。ok，那么我们需要做到以下4个步骤。
做好精准测试的步骤
差异化分析
第一步我们要做差异化的分析，我们代码之间到底有什么差异？这个差异化分析要明细到一些更细节的地方，明细到一些上游的方法，甚至是类，底哪些类，哪些服务收到了影响，这是我们分析的目的。
调用链分析
差异化分析做完，我就可以做调用链分析，从某些修改后方法要向上推到我们整个的业务链路、场景链路上去，找到到底影响了哪些业务场景，分析出这些业务场景。
用例推荐执行
有了业务场景的差异化我们就可以做关联了，基于我们自己建设好的一些用例库，我们这个用例库是要关联到我们那些方法，我们那些调用连。然后来推荐我们执行哪些测试用例，哪些要跑，哪些不要跑，是由我们系统使用我们软件来决定的，
覆盖率
最后一步就是我们开始做覆盖率的分析。
小总结
这四个步骤结合起来就是我们一个精准测试的流程，经过我们的差异化的分析测试，也就是调用链的分析，然后再到我们的推荐到的自动化测试用例的执行，最后才到我们的质量评估，包含我们的覆盖率评估分析，这里面会有一些，比如差异覆盖率分析，看看我们是不是每一轮我们测试修改的代码是否进完整覆盖。
以上四个步骤结合起来就是我们一个精准测试的流程了，第一做好差异化分析测试后我们在进行调用链分析，接下来我们在到自动化测试去执行测试用例，最后就到了我们质量评估，也就是测试覆盖率的分析。这就是精准测试的四个流程，下面我们一一聊一下这四个步骤具体是什么？
差异化分析
- 版本之间的差异化
- 无效变更查询
- 是否有变更 【去除无效变更】
- 变更详细记录
- 首先我们就是要对版本变化进行差异化分析，也就是从master去对比dev，看一下dev发了什么变化，这是版本之间的差异化分析的最简单的一步，其实在提交代码的时候，git本身就糊告诉我们代码的差异在哪里，那么这样的差异化分析到底够不够了？我觉得不太够。虽然git能告诉我们哪行发生了变化，但是我们从变化的哪一行不能知道了更多的信息，我门也没办法追溯代码之间到底方法发生了变化 。
- 那么这里说个差异化分析的方法 ---- 抽象语法树
- 抽象语法数是什么？就是源代码的抽象语法结构和树状的表现形式，通过这个来分析，它分析能分析出来什么？它分析能够通过语法结构来分析出来具体修改了哪一行代码，哪一个方法方便我们进行后续的测试和链路的分析。大家可以看这样一个流程，就是我们前端传入了我们的 Git 地址，我们的基础分支和部署分支，那我们就可以进行一个对比，对吧，然后对比来一下到底发生了哪些代码变更，然后我们通过 Java Parser，通过这样的方式来生成，并且分析语法树，获取到相应的方法信息。也就是说通过我们代码变更的行数找到对应修改了哪些方法，这是我们的方法维度，这是最底层的维度，通过这个我们当然后面有一些降噪处理。
- 那么什么是降噪了，其实从字面意思来理解就是处理掉一些无关紧要的一些东西，例如我们在提交我们写的代码的时候，会调整一些格式，比如说加一个标点符号或者换行等，这就是我们噪音了，让代码看起来更加整洁，但是这种代码变了吗，方法变了吗，对于我们整体的代码逻辑是没有变的。这里就需要我们降噪了，降噪完毕后，这样可以相对精准的获取到我们精准分析结果。
- 这个结果就是我们当前部署分支到底修改了什么？修改点是什么？增加了什么方法，删除了什么方法，改变了什么方法？这是我们差异化分析要得到的结果，这是最底层的那个方法，当然方法也不能叫最底层，对吧？方法是在我们底层那个代码的行数，那个编码上面的一个可视化的东西，因为这个方法才是我们真正被外围，被我们的服务，被我们的一些接口所调用的内容。我们差异化分析得到了这一些，接下来就到了我们的链路分析。
链路分析【测试分析】
- 变更代码 【差异化分析中得到差异化的代码】
- 用例库关系
- 方法调用关系库 【用例代码关系库中找到对应变更的代码 方法，对应的测试用例】
- 输出对应测试用例
- 测试分析就是我们的调用链路分析，其实它是个在干什么？它是通过我们的差异化分析得到了变更代码之后来找出变更代码对应的我们的整体的涉及到了哪些服务，哪些接口的变更。通过这些服务接口再去跟我们的用例相关联，找到我们的用例方法、调用关系的库，通过这件事儿来找出我们的真正的需要测试的，也就是推荐的测试能力。
- 初步结果是什么？我们知道了我们的方法，我们的修改的代码的变更所影响到的方法，最终影响到了我们哪些接口，哪些服务？因为我们推到了最后层的一些调用，比如说我们是 HTTP 接口，我们就能够找到什么，找到那个Controller，找到什么？找到那个 Controller 层，到底影响了哪些 Controller 层？它的一个接口数据。如果我们是一些 RPC 的服务， service 服务，那我们就能达到我们的 service 层，看看到底是哪个 service 的，哪个服务受到了影响，这才是我们最终的调用面的分析。
用例库
- 采集用例 【执行用例，用例采集至用了详细列表】
- 采用用例执行的方法调用关系 【可用插撞的方式进行方法调用链动态获取】
- 关联用了与方法 【采集用了关联方法原始信息表】
- 数据存储 【用例与函数的关系表】
- 有了方法的调用链路，接下来我们关联我们的自动化测试用例库，这个用例库是需要我们提前建设出来，提前维护一个用例的知识库，把用例和方法、关联关系和我们的服务梳理出来。
- 我们做一些精准测试的时候，精准测试的探索，它是手工维护的，我写一条用例，我写到我到底影响了 a 服务、 b 服务、 c 服务、 d 服务，这样就比较 low 了，对吧？其实我们也可以用插桩的办法，用一些插桩的技术来进行自动化的把对应关系的采集维护下来。
- 这是一个过程，就是我们根据我们的方法变更，根据我们的服务修改调用链路分析，最终拿到要推荐的我们的用例，那这种例里面可能会包含一些自动化的能力，我们就自动的执行调度，可能有一些需要人为的，不是说未来，也不是说所有的人工的测试操作都可以转化成为我们的自动化测试用例，这可能也是不现实的，一定还有在未来即便是完整自动化了，一定要是 80% 自动化， 20% 的人还需要人的一些探索，所以这些需要探索的功能用力，我们推给指定的人员去手动进行，然后有一些性能的用力，我们执行一些性能的用力调度，得到性能的报告，最终结束我们这一次的精准测试，这是我们精准测试的执行过程。再到最后一步执行之后，我们还要有一个覆盖率的分析。
覆盖率分析
- 用例执行
- 覆盖率统计
- 差异化分析
- 自动化测试报告 功能测试报告 性能测试报告
- 我们覆盖到哪一行代码的时候，插桩就会记录下信息，最终也知道了哪一行代码被覆盖到。结合着这些我们就可以统计出来每次执行精准测试的变更覆盖率是否达到了100%。当然有些代码逻辑好比一些异常的捕获，这个异常的触发场景很难，日常测试几乎走不到，那么我们也很难去覆盖掉，覆盖率也很难达到100%。所以我们最终一方面可以设定一个最低的阈值，哪怕代码有些逻辑走不到，也不会大面积并且占比很高的走不到，还是需要一个最低的覆盖率保障。
- 再则测试的同学根据自己测试的业务进行情况划分，具备一些 code review 的能力和习惯，因为我们的精准测试其实还是作为一个辅助测试的工具。最后我们可以记录一下以往测试的覆盖率，根据不同业务通过测试后的覆盖率情况，统计我们的覆盖率趋势，以历史的覆盖率数据为依据来设定我们的阈值或者是监控告警的值，如果覆盖率低于往期正常的值，那就进行报警，或者说进行一个卡点，那我们覆盖率分析的整体流程就是这个样子的，这样方便我们后续去更好地去完善我们的精准测试的一个思路。
最后在聊一下
- 有得小伙伴会说这算智能化吗？可以算也可以不算，但是不太智能，其实还是通过一些算法，通过大家可以想象的空间，它不是拥有自主意识的机器人来帮助我们做精准测试，只是人为的通过代码分析，通过代码结构调整的方式来进行我们相对精准的测试分析，其实它是个辅助软件，对吧？那所以我们说精准测试的核心是自动化软件，对软件过程数据进行记录，从而进行实现我们精准测试。
- 用例推荐这样的一个过程，通过这样的精准测试，我们可以实现软件质量的实时监控、回归用例的智能筛选、测试覆盖率的精准分析以及软件缺陷的快速定位。精准测试也并不是适合于所有的软件项目类型，但是对于我们的互联网的一些应用，包括我们的相机应用、产品级的应用，对于软件质量的需求比较高，对于迭代要求比较高的时候，对于精准测试的要求是会逐渐递增的，那精准测试的诞生，其实核心原因还是对于软件质量的要求，无论是用来做项目验收的公信力手段，还是用来做测试效率的管控，以及测试与开发人员的工作协同，包括我们的复杂式、分布式架构所带来的挑战，都是围绕着软件质量的需求满足而建立的，而软件质量的最终价值是我们用户体验的提升，所以对精准测试的实现，实际上也是我们的软件测试过程未来走向数字化、走向技术化的一些实践，或者说一些探索。那精准测试通过提升软件质量，改善用户体验，从而给了一些企业数字化转型更可靠的一些软件能力。
当然，我们要说精准测试还在什么阶段了？还是在探索的初级阶段，虽然有了一定的思路，但是技术上、实现上、流程上没有非常的完善，没有尽善尽美，没有实现一套落地化的、体系化的套路，所以说目前还没有说什么样的精准测试架构，是 100% 合理的一套架构。未来精准测试也是互联网里一个智能化测试的重点方向。 加油 各位🦸
4501
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
