聊聊自动化测试想法

Posted 2022-08-23 大鸡腿同学

前言

---

当开发改动相关业务逻辑之后，测试同学需要重新回归测试，有些还得走完整流程，比如说下单，开单，然后财务审核，各种流程去回归测试。无疑加大了测试同学的工作量，有些新接手别人工作的更是一脸闷逼，不知道之前的需求长啥样。

那么自动化测试的作用就发挥出来了。

背景

---

现在我们的做法是让测试同学去手动录入接口，以及相应返回参数的判断逻辑，这就很蛋疼了，可能一个系统就有上百个接口，想想都让我头大（虽然不是开发来搞），所以我想谈谈我的想法💡，减少测试同学的工作量，降本提效我觉得是大部分it在做的事情，这时就需要体现出来。

多少模块

---

作为工程师，模块化是一个很重要的思想。

那么在自动化这一块，我觉得有几个部分：接口模块、构建数据模块、自动化测试模块。

接口模块：首先你得知道有多少接口吧，分别用了什么参数，然后返回结果是什么

构建数据模块：测试总得有数据才能测试，那怎样构建测试数据

自动化测试模块：在前面两个基础上，对输入输出的内容进行校验，然后记录接口是否正常

实现方案

---

接口模块

在controller层，mvc是能拿到所有的接口以及对应的参数，这个找张表收集起来，然后每次项目启动的时候更新下项目所有的接口数据，洒洒水～

保存对应api，参数还有响应参数，我们也可以将它们分类，通过应用来区分整在一张表里头。

构建数据模块

这个环节会比较细一点，一般情况下是测试人员通过随机参数来达到自动化测试的目的。我想另辟蹊径，通过收集测试的流量，来构建测试数据。比如说，我在测试环节新建商品，可以是导入excel，可以是页面直接输入数据，这些在网关层都能拦截得到，比如说api路径，请求参数。

如果为了防止数据跟test环境冲突，可以拿uat环境请求数据，这个过程叫录制流程，当我们需要的回归的时候，将这些录制流量，重放出来，构造数据，相当方便实用。

这个想法的由来，其实是来自我之前的一次面试，那是一次阿里的面试，面试官所在的组做的是工具类🔧，其中就有流量录制，针对复杂的业务流程导致线上问题排查困难的情况，通过流量录制手段，然后重放的形式来排除问题所在。这个工具叫做JVM SandBox

有一个跟我老大聊天的时候，也发现其中的难点，就是数据构建的问题，线上流量有了，但是基础数据咋办，我觉得可以再搞个方案把线上数据dump到测试环境配合调试。

自动化测试模块

这个就比较简单了，就是把我们刚刚录制的流量，可以是test环境的，也可以说uat环境的，重放到我们系统api里面，然后需要一个判断逻辑，对响应的参数进行匹配，是否跟我们预期是一致的。比如说返回参数是否为200，或者说另外一个接口查询商品详情是否正常等等手段来验证自动化测试的结果，然后将这个结果保存到表头。

那么那些异常的响应，就是我们需要拎出来解决的问题了。

对比效果

---

如果是人工录入的话，首先有多少接口，这个跟系统的业务量有关系的，其次每个接口的参数，还有返回的参数的校验都需要单独写一套逻辑。再说到改动，由于信息不一定是对称的，所以漏掉接口也是正常情况，另外一个如果接口改了参数，还有返回参数，测试同学也是浑然不知的。

对比我这套方案，基本是由开发同学来完成，你多少个接口，心里没有点数？哈哈哈

收集api阶段，主要是我们通过mvc那层收集所有api数据，基本上不会漏接口，参数跟返回结果也是实时同步（项目启动的时候，就更新一次）构建数据的环节，人工方案是通过postman上随机数来实现，但是要知道有些参数不适合用随机数，比如说手机号，这些有特定规则的，那这时录制流量的好处就显现出来了。自动化测试阶段，人工的方案是写了一个逻辑来判断响应参数是否符合预期，我这个方案其实也一样。但是呢，就是如果我们有一套系统来搞，一旦发现响应结果变了，就需要有通知我们是否需要变动自动化测试脚本，流量重放编排等等。说白了，就是对变动是有感知的，包括api接口路径、参数、响应结果。

这样一对比，很明显降低了测试同学的工作量，美滋滋～