基于Druid的接口测试自动化方案
| 作者 | 更新内容 | 日期 |
|---|---|---|
| 郭群 | 创建文档 | 2020年5月12日 |
| 郭群 | 补充工具使用效果 | 2020年5月14日 |
# 一、背景
大数据事业群-昆山HG项目有以下几个主要特点:
- 数据复杂性高,多表之间数据关联性强,且数据由第三方公司提供;
- 接口较多(130+);
- 业务流程单一,主要为统计大屏报表;
- 使用的数据库为FP + PG,FP存储了绝大多数的数据;
测试工程师遇到的问题:
- 测试数据由现场系统定期导出后,导入公司测试环境用于测试,存在数据过期问题(功能测试用例,近一周查询,在数据刚导入被测系统时可用,但一周后,其测试结果将会改变,测试用例期望结果会失效);
- 受疫情等诸多因素影响,不便于频繁从现场导出数据用于测试;
- 测试数据为研发导入被测系统,且FP数据库不支持update SQL,若想更新测试数据的时间,需要将FP数据库导出为txt,批量修改txt的所有时间字段后重新入库,操作繁琐,且不利于维护;
- 构造测试数据,需要梳理各表之间的逻辑关系,投入成本巨大,且维护困难,
- 且后续HG项目远期计划会使用公司的主题库,将会带来一些数据库表的变更。
上述测试数据问题是接口回归测试遇到的最大阻碍。 这种阻碍使得接口自动化测试的期望结果很难编写,以往的期望结果断言策略为:
- 编写用例,声明期望结果,构造确定的测试数据,入库用于测试;
- 编写SQL动态查询数据库,根据SQL结果与接口的请求进行比对断言(这种方式在一定情况下,需要编写多条SQL进行交叉验证,否则有漏洞)
这两种接口自动化断言的方式,对于HG项目来说,都不够适用,我们需要新的方案。
# 二、穷则思变
接口测试,主要是接口功能测试,我们抽丝剥茧看看有哪些需要注意的测试要点:
接口的参数处理是否正确
a. 正常的参数:通常优先级高
b. 异常的参数:通常优先级低参数处理正确的前提下,接口的数据处理是否正确:
a. 接口对应的数据库操作是否正确(SQL执行是否失败?);
b.接口对应的数据处理逻辑是否正确(SQL执行成功,业务逻辑是否正确?);
既然接口功能测试的本质如此,我们接口测试核心校验的是业务数据获取的逻辑,且HG项目主要为查询类SQL,那校验接口和SQL的映射是否正确就好了,至于数据库是否有数据,这不影响业务查询逻辑的校验。 通过手工测试建立一个基线版本:梳理出每个接口对应的SQL有哪些,测试通过的接口记录其映射关系对,作为接口功能回归测试的期望比对结果。
回归测试时,批量执行接口的正向用例:
- 校验接口的HTTP状态码是否正确;
- 校验接口是否触发执行了期望的SQL,不多不少;
- SQL的变量参数是否和HTTP接口传入的一样;
- 执行的SQL是否报错;
这四板斧下来基本覆盖了接口核心功能的回归校验。
# 三、可行性分析
# (一)校验其接口的HTTP状态码是否正确
这一步操作,技术太成熟了,方案有很多种:
- HTTPTestLibrary可以胜任,只需编写3行用例即可完成,还可以使用数据驱动的用例编写方式,进一步提高用例编写效率,
- 使用Postman进行手工测试时,保存相关请求,接口功能测试时,回放执行即可。
# (二)校验接口是否触发执行了期望的SQL,不多不少
HG项目,开发团队使用了阿里巴巴开源的Druid数据库连接池,并且配置相关的监控配置项,这为我们这套方案提供了极大的便利:
URI监控,可以直观的获取URL和SQL的映射关系:
并且有接口API可用,可以批量获取映射关系:

# (三)SQL的变量参数是否和HTTP接口传入的一样
Druid监控API中,没有体现具体的传入参数(这体现在PG库中,形参都用“?”代替),但是HG项目开发团队的日志规范较好,记录了传参:

# (四)执行的SQL是否报错
Druid也记录了这些SQL的执行信息,并且提供了API便于使用:
# SQL执行正确示例:

# SQL执行错误报错示例:

# 四、自动化工具设计和应用
# 接口请求批量发送
接口请求中,有些需要参数化的时间信息,可以使用AwesomeFormat (opens new window) 被测系统使用BDP进行认证授权,接口自动化关键字使用BDPHTTPTestLibrary (opens new window)
接口请求发送,仅校验HTTP响应码是否正确即可。
优先完成每个接口的正向功能用例。
# Druid API信息处理
GitLab项目地址:http://172.16.111.6:10080/X2590/DruidAPIAnalyzeTool
# (一)设计思路
所需处理的数据主要是Druid SQL API返回的sql.json和WEBURI API返回的weburi.json
# 1、定义数据映射关系
将保存好的json文件放入data目录下,在config.py文件中,声明数据映射关系,
json_data_pair = {
'sql': {
'current': './data/v1.1-round2-sql.json',
'last': './data/v1.1-round1-sql.json'
},
'weburi': {
'current': './data/v1.1-round2-weburi.json',
'last': './data/v1.1-round1-weburi.json'
}
}
2
3
4
5
6
7
8
9
10
# 2、分别提取sql和weburi文件的数据,并格式化输出
执行python analyze.py,生成提取结果
weburl对sql的映射关系分组,weburl排序,weburl对应的sql列表排序
提取后的格式化输出效果:

sql执行结果排序
提取后的格式化输出效果:

# (二)、比对分析
使用Beyond Compare工具进行文件分析,无需多余的开发工作,最大限度利用已有工具。
# 右键快捷操作,比对文件:

# WEBURI比对效果:

# SQL结果比对效果

# 五、风险和局限性
通常一个业务的查询分为以下几个步骤:
A: 浏览器发起HTTP请求【必选】
B:服务端接收请求,并执行相关SQL获取数据【必选】
C:对SQL返回结果进行处理【可选】
D:服务端返回HTTP响应【必选】
E:前端JavaScript对数据进行处理【可选】
A-->B-->C-->D-->E
请注意,若没有C和E两个步骤,则此方案可用,若存在C或者E的步骤,需要另外测试关注其变动逻辑释放合理正确。
# 六、总结
开发团队注重软件的可维护性和可测试性,会对整体研发效率提升和产品质量提升起到事半功倍的作用,测试也会享受红利。 测试工程师也应当对开发团队提出可维护性和可测试性的要求,共同进步,共同推进研发效能的提升。