不期速成 日拱一卒 不期速成 日拱一卒
首页
技术
测试
分类
标签
归档
关于
首页
技术
测试
分类
标签
归档
关于
  • Hello Docker
  • 二进制文件安装Docker指南
  • Docker网桥导致网络故障分析
  • 使用Docker部署Python开发调试运行环境
  • Habor-轻量化容器服务自动部署工具
  • 当开发团队开始用Docker,测试团队应该做什么?
  • 如何把应用服务手动注册到Systemd
  • 探究inode耗尽导致的no space left on device报错原因
  • PyCharm远程开发配置攻略
  • 视频推流方案
  • Prometheus&Grafana打造性能测试监控服务
  • Pythoner的vim
  • RobotFramework字符转译之坑
  • JSONSchema常用关键字语法手册
  • 根据JSON Schema生成JSON样例数据
  • 一图看懂正则表达式
  • SQL中LIMIT和IFNULL的使用
  • 基于Druid的接口测试自动化方案
    • 一、背景
    • 二、穷则思变
    • 三、可行性分析
      • (一)校验其接口的HTTP状态码是否正确
      • (二)校验接口是否触发执行了期望的SQL,不多不少
      • (三)SQL的变量参数是否和HTTP接口传入的一样
      • (四)执行的SQL是否报错
    • 四、自动化工具设计和应用
      • 接口请求批量发送
      • Druid API信息处理
    • 五、风险和局限性
    • 六、总结
  • 技术
2020-05-12

基于Druid的接口测试自动化方案

作者 更新内容 日期
郭群 创建文档 2020年5月12日
郭群 补充工具使用效果 2020年5月14日

# 一、背景

大数据事业群-昆山HG项目有以下几个主要特点:

  • 数据复杂性高,多表之间数据关联性强,且数据由第三方公司提供;
  • 接口较多(130+);
  • 业务流程单一,主要为统计大屏报表;
  • 使用的数据库为FP + PG,FP存储了绝大多数的数据;

测试工程师遇到的问题:

  • 测试数据由现场系统定期导出后,导入公司测试环境用于测试,存在数据过期问题(功能测试用例,近一周查询,在数据刚导入被测系统时可用,但一周后,其测试结果将会改变,测试用例期望结果会失效);
  • 受疫情等诸多因素影响,不便于频繁从现场导出数据用于测试;
  • 测试数据为研发导入被测系统,且FP数据库不支持update SQL,若想更新测试数据的时间,需要将FP数据库导出为txt,批量修改txt的所有时间字段后重新入库,操作繁琐,且不利于维护;
  • 构造测试数据,需要梳理各表之间的逻辑关系,投入成本巨大,且维护困难,
  • 且后续HG项目远期计划会使用公司的主题库,将会带来一些数据库表的变更。

上述测试数据问题是接口回归测试遇到的最大阻碍。 这种阻碍使得接口自动化测试的期望结果很难编写,以往的期望结果断言策略为:

  1. 编写用例,声明期望结果,构造确定的测试数据,入库用于测试;
  2. 编写SQL动态查询数据库,根据SQL结果与接口的请求进行比对断言(这种方式在一定情况下,需要编写多条SQL进行交叉验证,否则有漏洞)

这两种接口自动化断言的方式,对于HG项目来说,都不够适用,我们需要新的方案。

# 二、穷则思变

接口测试,主要是接口功能测试,我们抽丝剥茧看看有哪些需要注意的测试要点:

  1. 接口的参数处理是否正确

    a. 正常的参数:通常优先级高
    b. 异常的参数:通常优先级低

  2. 参数处理正确的前提下,接口的数据处理是否正确:
    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'
    }
}
1
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的步骤,需要另外测试关注其变动逻辑释放合理正确。

# 六、总结

开发团队注重软件的可维护性和可测试性,会对整体研发效率提升和产品质量提升起到事半功倍的作用,测试也会享受红利。 测试工程师也应当对开发团队提出可维护性和可测试性的要求,共同进步,共同推进研发效能的提升。

#接口测试#自动化测试
上次更新: 7/26/2026, 4:44:44 PM
SQL中LIMIT和IFNULL的使用

← SQL中LIMIT和IFNULL的使用

最近更新
01
测试覆盖度量全景图
11-30
02
Prism测试覆盖度量
11-30
03
AITDBClient使用文档
11-15
更多文章>
Theme by Vdoing | Copyright © 2021-2026 toddlerya | MIT License
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式