自动化测试之功能自动化尝试

前言

作为测试人员，自动化测试一直是不可避免的话题，比较常见的有UI自动化测试、接口自动化测试、功能自动化测试、性能自动化测试等。选择哪种自动化类型和业务的特点关系还是比较大的。

首先，来看看我们业务的特点：

前端变动多，布局不稳定。

业务逻辑复杂，联表关系多，数据构造难。

业务流长，一个功能前后需要验证几个模块到十几个模块。

与开发共用一套环境，要搭建完全独立的自动化环境代价比较高。

测试平台多，上线前需要在多个平台重复检查。

测试人员较少，难以实现单模块单人负责。

综上所述，测试人员人少，数据构造繁琐，逻辑复杂，全量回归场景多，导致我们急需通过自动化来提升测试效率。但是前端改动频繁，单纯的接口测试又意义不大，故决定做全流程功能自动化平台，即从接口入手，书写对应的测试用例，并针对接口返回和涉及到中间流数据（比如数据库，kakfa，redis等）功能检查，来保证功能的正确性。

平台的主要功能如下：

接口管理：

接口从开发的接口doc文档自动同步

类似postman的页面管理

多套参数管理方案，方便多人共同使用和场景切换

数据构造/清理：

能支持多方式数据构造（mysql/接口/redis/kafka），灵活构造准备数据。

支持多层级（测试套件/测试用例）构造/清理；

支持变量传递，前一个接口的返回可以作为后一个接口的参数，共同实现数据构造的功能

用例的执行：

可选择任意层级、指定接口，指定测试套件的指定用例执行

多个测试环境免修改自由切换执行

数据校验：

丰富的校验方式支持整个业务流的中间环节验证；

支持文本对比校验，和正则表达式校验

支持巡查机制

支持转储结果校验

结果查看：

支持可视化，表格式页面结果查看

用例失败后，详细错误理由查看

学习成本：

编码能力零要求

方便上手，方便操作

实现

说了这么多，下面来系统的实现吧。由于python开发的速度很快，且容易上手，丰富的第三方库，大大加快了开发速度和难度，所以后台我们选择的是python+flask进行开发，前台使用jquery和bootstrap进行页面和交互开发。

即时的自动同步接口

问题：接口的参数一般都比较多，如果手动输入一个个参数，估计很少有人愿意这样做。

解决方案：

1）为了方便的录入全部的接口，我们和开发的phpdoc文件进行了对接。

2）当开发更新接口文件后，会自动生成phpdoc，然后触发我们的同步脚本。

3）同步脚本会解析phpdoc中的内容，自动同步到我们的数据库中，生成我们后续用于测试的接口。

当然，这些接口除了用于后续的测试外，也用于了开发的自测，免除了参数录入的过程，开发们很乐意进入平台和我们共同维护接口信息和参数格式。

多样的数据构造

接口运行过程中，经常需要提前准备一些测试数据。为了方便构造数据，我们抽取了以下几种的数据构造方式。

Mysql数据库类型数据构造：

选择构造数据的库，输入构造的sql，即可构造成功。

一些简单的字段，会随着用户或者场景变化的值，最好通过查询sql的方式获取。如果以后其他人把数据改了，你的用例仍然可以稳定执行，不受任何干扰。

也可以insert很多准备数据，但是这样的数据，和业务真实性差异会比较大，不太建议这种做法。如果真的要准备数据，建议以接口API的方式来构造。

接口API类型数据构造：

选择需要的接口名称，输入必要的参数来构造数据。

我们也支持接口间变量的传递，前一个接口的返回字段，可以作为下一个接口的参数，这样就可以把多个接口串起来实现一个完整的功能，模拟真实的用户操作调用接口的过程，达到构造数据的完整性，和测试的仿真性。

Redis类型数据构造：

选择构造数据的redis地址，输入构造的key和value值来构造数据。

一些数据开发喜欢存储在redis中，比如访问的次数，是否访问过之类的值，如果真实模拟这些的话，需要前期跑N多，或者重复构造多次数据才行，我们采用直接设置redis值的方式来实现，简化了测试的流程。

丰富的校验器

既然是功能自动化测试，接口运行完后，简单的接口返回体检查肯定是不能满足需求的，我们根据业务，抽取出业务处理过程中的每一步产出，分解为以下三类。

l 接口返回检查：

即接口的返回字段检查，通过检查接口的返回初步判断功能的正确性，一般是errno，code等的校验。

支持文本检查和正则表达式校验两种方式。

数据库字段检查：

提前需要在配置管理中配置好要校验的数据库的连接方式，这里仅需要选择数据库名称，输入预先写好的sql，来检查某功能对数据库的处理是不是正确。

通常，一些数据库的字段页面是check不到正确性的，它又对其他模块，或者整体业务完整性有很大的影响，如果人工检查，就需要频繁的页面操作，然后再去写sql语句查询，涉及到申请数据库权限，连数据库，写sql等一系列的操作。如果用这个平台，只需要输入一次检查的sql语句，就能自动帮你检查正确性，并返回结果。测试也变得简单，方便。

文件输出检查：

提前需要在配置管理中配置好要校验的文件的机器，路径，和访问方式。然后在校验器中需要选择对应的文件名称，输入要校验的字段即可。支持多字段校验。

在我们的业务中，经常有两个模块之间交互的文件，如果手动去校验文件，就特别繁琐，文件的格式，内容等都需要一一检查，很容易发生测试遗漏的问题。在这里就可以输入要关注的重要字段，或者全部行的内容，执行用例，就自动检查完了全部的内容，简单，方便。

另外，我们还从文件的格式中抽取出关键参数，作为文件内容唯一性的标准，防止以前的用例间的相互影响。

无代价的多环境执行

问题：上线前，我们需要在多套环境中重复的进行测试，来保证上线功能的正确性。如果仅靠手工，重复工作量太大了，而且很容易发生遗漏等问题。

解决方案：我们在开发平台的时候，实现了一套用例无修改即可在多套环境执行的功能。

通过配置管理进行多套环境相同变量名变量的存储，例如一些环境变量，比如域名，数据库地址，log文件机器，redis配置，以及每个人单独使用的用户名以及相关信息，都在多个环境中配置，以达到选择环境即可执行的效果。

同样，一些用接口执行过程中的变量，也需要维护起来，方便后面接口的使用。这个主要是用于数据构造，通过变量传递方式构造的数据，即使切换了环境，只要重新构造一套即可，无需任何额外代价。

这样，基本上第一遍测试的时候，把要测试的场景构造好，校验的数据准备一下，然后回归检查，切换环境检查，就能一键式的运行。

从接口层级以下的功能都自动化起来之后，是不是我们的关注点也变得简单了，只要看一些页面上面的交互效果即可，不需要频繁的切换linux窗口，数据库窗口的进行各种字段检查了。

方便的结果查看

报告文件为了方便可用，我们生成了类似python unittest结果文件的报告。可以直接查看用例成功失败情况，点击fail，能看到失败的详情。

其他

平台还支持一些业务定制，比如接口保存多套参数，字段加解密，自动生成唯一后缀等，还有操作上复制，拖动，批量修改，导入导出等功能，方便用例维护。

总

结

通过这个平台，我们将自动化用例书写变得简单化，只通过一些简单地操作，就能完成一个接口的功能校验，并能根据自己的需要执行一部分的用例。

目前已经在接口的自测，冒烟，和整体功能的回归等方面都起到了很大的作用。

但是自动化还和测试流程，环境等密切相关，后续我们还会逐渐和流程改进、数据构造、环境监测和缺陷报告系统等关联起来，真正使自动化测试变得一体化，更加有效。

Qtest是360旗下的专业测试团队！

是WEB平台部测试技术平台化、效率化的先锋力量！