Go最全支付宝用例自生成技术实践(1)，食堂大妈看完都学会了-CSDN博客

本文链接：https://blog.csdn.net/2401_84904639/article/details/138763278

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

https://developer.aliyun.com/article/767770

讲师简介：
**乾雨，**蚂蚁集团高级开发工程师。2018年加入蚂蚁金服，现一直从事工程效能，智能化测试相关的工作。2018之前一直从事电商相关工作，参与过日均过亿的网关开发工作。

热爱技术，做过开源监控工具Onyxia，为公司产品打下稳定性的基础，面对公司db中间件针对java语言的漏洞，重写过对应的事务管理器，推动部门内java编写的产品线能稳定上线。

本次分享分以下四个部分：
一、背景介绍
二、当前业内方案
三、支付宝的用例自生成实践
四、总结和价值
戳我观看视频

一、背景介绍

如图所示，假如已经有一个作品在线上，当月提出一个需求，按照正常流程进行，开发完测试，验收产品，产品如期上线。

但是在这个测试中大部分同学都比较侧重于验收新功能，对于之前已有的功能很少验证或者不去验证，下意识认为两个功能点之间没有关联，不会出事情，但开发人员为了本次新功能开发需求，可能会改变业务代码当中某些公共的方法，这些公共方法可能会服务已有的功能点，缺少测试验证，上线后可能会导致已有的功能异常，引发线上故障。

如图所示，即将有一个很复杂的功能要上线，要实现这个功能，代码中有很多if…else或者switch…case的语句，并且排序计划需要这个功能上线，那么在时间有限的情况下，大家都会优先去保证核心链路的测试，其他链路的测试可能会简单或者不去测试，甚至在测试过程中不会去考虑异常场景，比如说PPT中展示的例子，当type为空时，会有什么影响，这些基本不会做验证，上线之后未做详细验证的分支，很有可能有bug，引发线上故障。

测试流程，在该流程中，查bug会占比较长的时间，无论自测，还是交给测试人员做，都会耗费长时间。回顾上述场景一、场景二，出现的问题都需要长时间测试才能避免。

测试包括四种测试方法：单元测试、集成测试、系统测试、全链路测试。

测试用例：指覆盖更多分支的测试用例。比如说我有10个接口，每个接口有10个分支逻辑，那么我需要用100个用例来覆盖所有的业务范围，如果能有100个用例，上线之前全部跑一遍，无论结果如何，起码业务分支都已经运行过，一些常见异常都能暴露出来，剩下要做的就是开发测试同学去查看跑这100个用例的过程当中，是不是符合预期，有没有业务逻辑的错误，如果我们能有这种大量的用例集合，那么就会大大的减少测试成本，毕竟运行用例的时间是有限的，比查找bug的时间减少很多，这样就会将之前业务上遇到的问题转化为用例生成的问题。

一般来看，用例的来源主要有两个方面：

①开发测试同学自己构造。这种方式依赖于编写用例人员的多少，以及人员水平的高低，比如之前举的例子，由于之前各种原因：项目周期短，人员少，只会覆盖有限的人员逻辑，很难去覆盖所有的人员分支，甚至不会去管异常的用例；

②线上录制。通过一些技术手段将线上发的技术参数录制下来，当做测试用例，这种方式无法解决测新的问题。

比如我新写了一个接口，或者将原来接口的参数做了改变，线上没办法录制到最新接口的参数的请求，所以没有办法使用。

并且线上一般都是正常请求，很难去录制到异常的参数，有些异常参数只会在特定情景下复现，不能录制到异常用例，并且这种方式录制量很大，有可能录制到100万条用例，由于不知道这些用例对应哪些分支逻辑，所以会全部跑一遍，测试的时间很长，如果测试过程中异常较多，则还会做数据分析工作，比如100万条用例，其中5万条是失败的，那么就需要用户去查看失败的用例是什么原因导致的，如果逐条去查看，是不太可行的，中间就会需要聚类的方式，有一定排查和解决问题的成本。还有一些其他问题，比如说我们现在已经有一些用例集合，这时候还需要用户去维护这些用例，当接口迭代更新的时候，需要把对应的用例更新，让他跑用例的时候不至于随着时间的推移测试质量下降，这个也需要一定的成本。

针对上述提到的相关问题，我们要考虑如何将生成用例做到智能化和自动化，若用例覆盖度不够，则自动生成需要的用例集合；若用例数目太多，则根据需要去缩减用例数量；若迭代有更新，那么能动态感知生成新的用例集合。

上述就是目前我们需要解决的问题。

智能化测试

现如今智能化测试是一种大趋势，现阶段开发过程中，bug的查找、定位占用了大量时间、人力成本，很多人意识到这个问题，慢慢的向自动化发展，能自动查找问题，并且在自动化基础上，加一些大数据和算法的支持，做到智能化的成产用例。

如今业内也有很多的方式方法去推进智能化的落地，比如学术界有一些论文，像《基于符号执行的方式》、《基于模糊测试的方式》、《基于模型的方式》等去生成用例，每种论文的方式或多或少都会有一些开源的项目去支撑这些论文的思想；工业界也有一些很有价值的工业产品，比如Randoop、Evosuite、AFl等，通过这些各式各样的方法和工具，走出了多少人工才能查找定位走出bug死胡同。智能化的用例生成，将会减少很多查bug的时间，研发效率将会有很大的提升。

二、目前业内方案

Randoop、Evosuite

Randoop和Evosuite都是比较好的开源工具，都能够自动生成单元测试。

比如说有一个link list对象，现在想测试里面用到的方法，通过运行各自支撑、支持的命令，可自动生成类似于PPT展示的单侧用例，达到用例自生成的目的。生成的单侧new了一个link list的对象，里面设置了一个字符串，之后调用-isEmpty的方法去做测试。

观察源代码，发现有些数据是这样实现的：通过随机值生成一些随机的数据放到里面，或者说根据类型去设置。Evosuite里面包含了GA的思想，它会根据覆盖率去进化生成的参数。

Randoop和Evosuite主要面向单侧，而我们的业务方向可能面向接口测试，比如说我是一个接口测试平台，调用各个业务方的接口，那么就不会去生成单侧，因为没办法去了解业务的实现类是什么，所以暂时不采用此方式。
AFL

AFL是谷歌的一个工程师开发师，以代码运行的路径为指导，构造大量输入参数，对软件进行大量测试，进而发现问题的一种模糊测试方法。

与之前Randoop和Evosuite不同的是，它不会生成单侧，比如像PPT中展示的那样，用户首先要准备参数的种子文件，第一次可能不需要编译，只需要将种子文件放在接口当中去做测试，测试过程当中对业务代码进行插装，计入本次代码的执行路径，如果跑到了新的路径，那么编译的这个种子文件将编译后的种子文件再输入到应用程序当中，针对同一个接口继续做测试。

AFL经过一些开源项目验证，这种方法是可行的，但也有一些问题，这个相对来说，是比较适合C和C++的应用。如果要做AFL测试，必须要做一些种子文件，种子文件的质量和大小都有一定的限制。

接下来我们来看一些目前比较常用的用例生成方式。

第一种：组合测试

**组合测试：**之前已经有一些用例集合，这些用例按照字段属性单独来看，id的范围只有三种，name的范围只有三种，age的范围只有两种，那么可以做两两组合来基于已有的参数编译生成新的参数，如上图所示。

第二种：交叉测试

交叉测试与组合测试有很多相似地方，有如图所示的一些集合，它针对某个参数有多个请求，那么我们把这个参数拆开来看，我们将第一个用例的用户对象和第二个用例的性别对象组合作交叉，再将第二个用例的用户对象和第一个用例的性别对象再组合做交叉，这样就会得到变异的一些参数，将这些参数再拿去进行测试，用来找到业务当中更多的问题。