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

前言

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

首先,来看看我们业务的特点:

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

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

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

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

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

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

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

平台的主要功能如下:

接口管理:

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

类似postman的页面管理

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

数据构造/清理:

能支持多方式数据构造(mysql/接口/redis/kafka),灵活构造准备数据。

支持多层级(测试套件/测试用例)构造/清理;

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

用例的执行:

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

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

数据校验:

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

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

支持巡查机制

支持转储结果校验

结果查看:

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

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

学习成本:

编码能力零要求

方便上手,方便操作

实现

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

即时的自动同步接口

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

解决方案:

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平台部测试技术平台化、效率化的先锋力量!

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180531B1QVIS00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券