技术

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

作者	更新内容	日期
toddlerya	创建文档	2020 年 5 月 12 日
toddlerya	补充工具使用效果	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/X3927/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'
    }
}