接口测试 讲讲一些接口自动化测试的经验

0x88 · July 30, 2018 · Last by 0x88 replied at September 02, 2019 · 7288 hits

本来想吐槽一波的,听取前辈们的建议,还是算了。
现在先讲讲我在接口自动化测试的落地方案,如下图

看到这个图,可能大神们都会来质疑,首先一定会质疑数据备份还原这种方法,比如说数据库数据有几个、几十个G甚至几T时,这种方法还是否适合……

说起来惭愧,方案还是有点low,有些还是需要手动去做。

首先,我们会从git上面去拉代码,打包并上传部署,这部分是由CI/CD来完成,当然我们这边的的CI/CD并没有做得特别的好,而且连产品都没有成型的状态,于是我先用jenkins的PipeLine来完成前面这一套的工作流,再增加数据准备与执行测试两个节点(如果有个像样的CI/CD平台后再做迁移)。
数据准备是用数据库备份还原的方法来做,而接口测试这个是由我们自研的seiya接口平台承担这部分的工作。
特别强调jacoco做统计的做法很low,是用手动去修改catalina.sh。
正常来说这个Jacoco统计的应该由CI/CD来统一操作的。

对于前面CI/CD这一块我就不多说,每个公司都有一样或者不一样的做法。
这里就只讲一下怎么做接口自动化测试。
从数据库备份还原这种方法说起吧。为什么要使用这种方法?
举个实际的测试例子来说就一目了然了。
例子:一个注册用户的接口测试用例
如果是我来写这个case,我会这样来设计
一般注册帐号需要输入用户名、中文名、手机号码、性别、邮箱等等,当然也会分有效注册和无效注册
---有效注册
必须是一个数据库不存在的新用户,比如输入的数据是:zhangsan,张三,139xxxxxxxx,male,zhangsan@163.com
---无效注册
无效也分各种场景:
1、 注册已经存在的用户
2、 手机号码校验
3、 邮箱校验
4、 验证码校验
……..
根据以上场景我们就可以开始做接口测试了。
其它的CASE就不说了,我们用jmeter写第一条有效测试的case(post 一段Form表单),一开始我们会这样写(就用比较通用的jmeter来作为例子讲吧),如下图:

这样写有没有问题呢?
第一次执行时,当然是没问题,但下一次呢?
下一次执行就不可以用相同的数据了,又得去造一堆数据。为了让数据可以复用,所以我这里选择了数据备份还原的方法。
还有没有更好的方法?
答案是有的。
我列一下我想到的几种方法:
1、 调用删除的注册接口
2、 调用sql语句去删除数据
3、 写一套自动生成数据的方法
4、 数据库备份还原的方法
5、 …….
前面几种方法一开始我也是做过的,但都遇到各种问题。
1、 调用删除注册的接口。当然得找开发要接口。
开发大大:我们不提供这种接口,因为这种接口不能合到主干,如果强行加上,难以管理代码。
2、 调用sql语句去删除数据。我想这种可以了吧,于是提出这种方案。
开发大大:“我们不允许使用sql语句去删除数据,我们不信任你们测试写的sql脚本,sql脚本需要DBA去评审。再说你们这种sql语法会导致我们有脏数据。”

此时此刻的心里:一群草泥马在奔腾着。
3、 写一套自动化生成数据的方法。我发现这种方法我不会写,于是放弃了。
4、 最终只能选择数据库备份还原的方法。这种方法是不是最好的呢?我觉得并不是最好的,但是是目前情况下最适合项目的。
以下几个项目特点决定了我使用这种方法:
a.项目测试环境数据其实真的不大
b.操作简单,就一条sql命令解决的事情(source xxx.sql)
c.生产/线上环境不允许操作数据库,只能在测试环境做这个事情
d.基础建设没达到一定的高度,提供不了更好的方法。

可能数据库还原不是最好的,但在目前状态下是最合适项目的方法。在不同场景下采用不同的测试方法不也是我们作为测试应该去做的事情吗?

数据这一块还只是一个需要注意的地方,另外在实际做接口测试还需要注意一些细节。

1、 CASE依赖。CASE依赖分前置依赖与后置依赖,依赖方式这也分并行依赖与串行依赖。
如下图:

2、 数据对应关系。数据对应关系可以是一条数据对应一个接口,或者是一条数据对应多个接口,也可以是多个数据对于一个接口,这样就会形成多个不同的Case。我这里就只拿多个数据对应一个接口来举个例子:

如果是一个注册接口,我们得考虑是注册能不能有特殊字符,电话号码是不是11位(国内),邮件格式等等。这样一个接口其实我们可以写N条测试case,而不是仅仅一条接口case就完事。
当然数据有各式各样,需要我们去造,比如空格,特殊字符等等。
3、 case排序
为什么要讲case排序呢?还是举个例子来说会比较实在一点。
就用网站登录功能来说吧。
设计一个登录case,一般来说要测试有效登录和无效登录,如果没有帐号就行得先注册,这样我们又得依赖注册接口去注册一个帐号。多麻烦呀。如果我们先执行注册接口,这样我们就可以使用同一套数据,不用再造一个登录数据,这样整个case集就可以这样排列。
1、 注册(帐号名:张三;密码:123456)
2、 无效登录(帐号名:李四;密码:123456)
3、 有效登录(帐号名:张三;密码:123456)
4、 其它功能

另外一个比较经典的例子就是功能启用和禁用接口测试,启用接口需要依赖此功能已经禁用的状态,禁用接口依赖此功能启用,如果我们写接口依赖的的就是启动依赖于禁用,禁用依赖与启用,这样就会导致死循环。如果采用case排序,那么我们就不需要依赖,禁用后调启用,两条CASE解决问题,也不需要做前后置依赖。

在接口自动化测试的过程中涉及状态的尽量采用case排序,不要使用case依赖。

讲完接口自动化测试的经验,讲一讲怎么去衡量接口测试的有效率。
在我们这边是这样来衡量的:
1、 接口数覆盖率:指的是接口文档中接口数与Case数的百分比
2、 Case通过率
3、 接口测试代码覆盖率:就是使用jacoco统计的行为覆盖和分支覆盖率。Jacoco统计tomcat的覆盖率百度一下一般都能查到。
把这些事情都做了,那么下一步就是不断的提升这三个指标。

对于自动化测试,我现在更加倾向于落地,而不是做一些高大上的东西结果什么价值都产生不了的项目。有一些自动化哪怕方法很low,但是能落地能产生价值,并且需要在这种low的方法上不断的去提升。一味追求自动化测试的团队最终都会放弃自动化测试, 真正的自动化测试还是要从基本的业务测试做起,只有贴近业务测试需求的自动化测试才能产生价值!!!

共收到 16 条回复 时间 点赞

同意楼主观点,能落地的自动化才有价值

首先,我们们从git上面去拉代码,打包并上传部署,这部分是由CI/CD来完成
这句话,怪怪的

0x88 #3 · July 30, 2018 作者
槽神 回复

被发现bug了😂😂

4Floor has been deleted
5Floor has been deleted
6Floor has been deleted

赞一个,很多东西都是原理简单,落地难,大规模落地应用更难

Author only
0x88 · #9 · July 30, 2018 作者
Author only

请教下楼主有通过代码diff找到目标模块做特定的接口测试 方面的经验吗?

回复

你指增量覆盖率吗?

0x88 回复

一个是增量覆盖率,一个是分支更新合入之后只执行分支的用例。。。类似这样,我自己也缺乏实践

0x88 #13 · July 31, 2018 作者
回复

我没想好增量覆盖能带来什么价值,所以没把增量作为一个个评估质量的标准。另外分支测试这个我们这边还没有一套完整体系的cicd支持,现在做只会事倍功半。

0x88 回复

好的,学习了

楼主能再讲讲你们的数据库备份还原具体怎么做的吗

自动生成数据的话,调用了增删改的接口之后,数据库不是也需要还原吗?

0x88 #17 · August 31, 2019 作者
穷疯了 回复

反正我是无论如何都还原数据库。不然各种数据不稳定,案例跑不下去。

0x88 回复

现在我也是还原数据库,感觉还原数据库花费了主要的时间,请问有什么优化的方法吗

0x88 #19 · September 02, 2019 作者
穷疯了 回复

不清楚你们是什么样的测试数据,居然能有这么大。出一个馊主意,多搞几台相同的数据库。
其实一般来说做自动化测试前需要有环境自动部署能力,这个能力是自动化测试重要环节。
使用docker+k8s可以快速部署环境(包括数据库),但我这边做不了,所以多搞几台服务器。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up