基于Charles录制会话的HTTP接口自动化测试框架设计与实现

刘国庆 汪兴轩

(复旦大学信息科学与工程学院 上海 200433)

0 引 言

接口测试是指Web系统组件间的测试，它主要用于检测组件与组件之间的交互点[1]。在移动软件开发领域，大多采用分层软件体系结构，服务提供者和消费者基于接口契约传递数据和上下文信息。应用软件的数据大多来源于服务端的接口返回，持续保障接口有效返回、及时发现异常接口是移动软件测试中的一个重要课题[2]。

在Web应用开发领域，客户端服务器模型是一种被广泛应用的网络架构，它把整套软件系统划分为客户端和服务端[3]，即客户端请求数据，服务端响应内容。超文本传输协议是一个基于请求与响应的无状态Web传输协议，因其具有传输效率高、占用较低的网络带宽等特点而被广泛使用[4]。

Charles是一款被广大Web开发者广泛使用的HTTP/HTTPS代理服务器、监视器、反向代理服务器软件，当Web应用程序通过Charles的代理访问互联网时，Charles可以监控HTTP/HTTPS应用程序发送和接收的所有数据。Charles允许开发者查看所有连接互联网的HTTP/HTTPS通信，包括Request、Response以及Headers等，在Web开发中扮演着重要的角色。

1 概 述

传统的HTTP接口测试需要测试人员手工设计用例与构建参数，利用接口测试工具，如postman、jmeter、fiddler等[5]，模拟客户端向服务端发送请求，服务端处理后返回请求结果，测试人员手工检查返回的结果是否符合预期。传统的测试工具虽然使用方便，易于上手，但是它们也有很多不足之处：

(1) 测试数据需手工输入 接口测试本质上是对接口输入和输出数据对应关系的测试。测试人员手动调用接口，输入测试数据，然后验证接口返回数据的正确性。每次接口测试之前，测试人员必须手动向工具输入测试数据，耗时耗力。

(2) 无法测试加密接口 接口测试工具无法自动执行加解密操作，例如md5、base64、AES等加密方式。对于加密接口，测试人员需使用加解密工具对参数处理之后才能进行测试，导致测试效率低下。

(3) 扩展能力不足 接口测试工具虽然有它的便利性，但与此同时也伴随着局限性。例如，测试人员需要将测试结果生成HTML形式的测试报告后发到指定的邮箱、需要对接口做持续集成测试等，这些都是工具难以做到的。

对应客户端服务端模型，在移动软件测试领域中，基本上采用“端分离测试”的工作模式，即各端保障各端质量[6]。实际上，客户端工作时往往频繁地调用服务端接口，获得了大量的测试数据，生成了丰富的测试用例。而“端分离测试”这种工作模式忽略了客户端测试人员在测试过程产生的大量的服务端测试用例，从而导致了冗余的测试工作。

传统的接口测试需要测试人员了解接口定义、设计测试用例、配置请求参数、观察接口响应等[7]。由于软件开发中接口设计场景化、请求参数复杂化、服务端数据动态化等趋势愈发明显，人工观察接口响应容易出错，上述步骤必然会导致测试效率不高。特别对于新开发的移动应用软件，必伴随着大量的服务端接口，测试人员逐个测试接口，造成了大量的重复工作。

为此，本文提出了一种应用于新开发移动应用场景下，伴随客户端功能测试，基于Charles录制会话的HTTP接口自动化测试框架。它依托于业界内已有的开源持续集成平台[8]和单元测试框架，从客户端功能测试出发，实现了自动生成测试用例、对测试数据自动处理、持续集成测试、生成测试报告等功能，测试人员在进行客户端功能测试的同时收集服务端测试数据与用例，添加接口响应校验规则后，便可持续检验接口是否正常工作。

相较于传统的接口测试工具与测试流程，本文提出的方案省去手工构建请求参数环节，实现自动构建请求与校验响应，增加集成测试与扩展功能，实现接口测试由人工到自动化的转变，提高了测试效率。

2 方案设计

2.1 架构设计

如图1所示，本文提出的接口自动化测试框架主要包含测试用例录制单元、中间件服务单元以及持续集成测试单元三部分，每个单元又由不同的子单元构成。

图1 接口自动化测试框架系统架构

(1) 测试用例录制单元：客户端监听工具(Charles)：记录HTTP会话，监听被调用接口传递的参数，录制接口测试用例，导出“.har”文件；

“.har”文件解析：提取会话数据，生成测试用例；

测试用例池：存放测试用例、接口请求参数与校验规则。

(2) 中间件服务单元：接口请求构建：调用测试用例池中的接口Url、Method等参数，构建并向服务端发送接口请求；

接口响应校验：校验接口响应信息，检查接口返回的数据结构与值是否符合预期。

(3) 持续集成测试单元：单元测试框架：调用中间件服务单元，执行测试用例，生成测试报告；

持续集成平台：定时调用单元测试框架，自动化执行接口测试，发送测试报告，如有异常则发送报警信息。

2.2 流程设计

如图2所示，当客户端开发人员完成应用开发并且转交给测试人员后，测试人员在客户端安装待测应用进行功能测试的同时，监听工具自动采集接口测试用例，具体流程如下：启动Charles，客户端连接代理服务器；测试人员进行客户端功能测试，Charles录制客户端与服务端交互过程中所调用的接口以及传递的参数信息；通过调用Python脚本，提取Charles录制的接口请求数据，生成测试用例；测试人员完善测试用例并且添加接口响应校验规则后装入单元测试框架；持续集成平台以任务的形式定时运行单元测试框架，其分别完成向服务端发送接口请求数据、接收服务端响应并与预先填写的检验规则作对比、发送测试结果三项任务。

图2 接口自动化测试框架工作流程

2.3 工程设计

如图3所示，在工程上，本文提出的接口自动化测试框架由Charles+Python+Unittest+Git+Jenkins构成，主要分为两部分：录制接口测试用例与接口自动化测试。

图3 接口自动化测试框架工程设计

3 录制接口测试用例

如图4所示，录制接口测试用例部分以Charles为核心，Python脚本将HTTP会话过程转换成可用的测试用例。测试人员在进行功能测试的同时，Charles录制客户端与服务端会话，测试结束后，导出“.har”格式文件。经过白名单与黑名单过滤后，接口测试用例存入测试用例池。

图4 接口测试用例录制结构

3.1 录制接口测试用例

当客户端连接Charles后，客户端的请求参数通过Charles转发至服务端，服务端的响应又通过Charles下发至客户端。如图5所示，对于某款特定的移动应用，其接口一般归于一个或多个域名，而Charles将客户端与服务端会话过程中所有的数据按照域名进行归类，导出HTTP Archive(Har) format格式(“.har”)后，可查看会话详情。

图5 Charles代理服务器软件

“.har”格式文件在本质上是“utf-8”格式的json字符串文件，其中的“entries”字段为列表对象，保存了HTTP会话的详情，一个元素则记录了一条HTTP会话，“entries”的数据结构如表1所示。

表1 “entries”数据结构

3.2 构建接口测试用例池

从上一节得知，“entries”中的一个元素即可视为一条测试用例，而其中的“request”和“response”对象则保存了完整的请求与响应信息。本文构建了Python脚本将请求参数与响应数据映射至测试用例池。测试用例根据接口的url字段归档，采用“一对多”的模式组织数据结构，即一个url对应多组参数，从而实现同一个接口对应多个测试用例的组织模式。构建测试用例池流程如图6所示。

图6 构建测试用例流程图

除了完整的请求与响应信息以外，赋予测试用例名称与编号，方便后期的维护与扩展。测试用例池的每条用例结构如表2所示，其中headers、queryString、cookies、postData均为json对象。

表2 测试用例组织结构

Python的xlrd和xlwt库可以很方便地实现对Excel文件的写入与读取，而Excel表格可以直观地显示接口的信息以及请求的详细数据。本文使用Excel文件作为测试用例池的存储容器，一行为一条测试用例，而测试用例之间可能存在相同的请求对象，后期维护时可以较快扩展用例。

4 中间件服务

中间件服务用于连接用例池与服务端。它分为两个部分，一部分是构建单元，另一部分是接收单元。构建单元负责将测试用例池中的用例参数组装成HTTP请求并向服务端发送，待服务端解析请求后，接收单元接收接口响应并将响应报文转换成预期的格式，与预先配置的校验规则做对比。

4.1 构建单元

构建单元以Python的requests库为基础，将测试用例中参数组装成一个完整的HTTP请求。requests库支持HTTP协议中的所有请求方法，并且其能携带所有的HTTP请求信息。

本主动托换体系设计的特点是受力明确、承载力可靠、变形易于控制、能够适应现有结构布置和桩基布置条件、托换施工期间和托换完成以后的建筑物安全控制设计采取静态应变测试系统、电子位移计、倾角仪、裂缝观测仪对新托换梁的挠度、沉降、倾斜度、裂缝进行高精度动态监测，得出同步顶升时托换梁的即时变化结果，以便更准确地指导托换梁顶升工作。

服务端解析构建单元的请求之后，会将响应以Response对象的形式返回。而在移动应用软件开发中，大多数移动应用基本采用json格式耦合客户端与服务端。借助于Python中的json库，将HTTP响应报文转换成json格式，方便校验其响应内容。

本文将request库和json库进一步封装，构成基础http请求包，以类方法的形式对外开放，用于传递HTTP数据。

类方法介绍如表3所示，Get_main和Post_main分别对应HTTP协议中的Get和Post方法，Headers和Data若为空，则调用默认值，返回对象为统一的json格式的字符串。

表3 封装HTTP请求方法

4.2 接收单元

对于接口响应内容的校验，本文选取了两种校验方式。对于无代码能力的测试人员，使用Json Schema；另一种方式是使用断言(Assert)，而这也对测试人员提出了更高的要求。Json Schema指的是数据交换中的一种虚拟“合同”，用于Json数据的一致性检验。它可以验证值的数据类型是否正确，是否包含所需的数据，数据的组成结构是否正确，值的范围是否符合预期等。Python的jsonschema库提供了丰富的json数据验证功能，用户仅仅需要将数据导入库即可进行可靠的json验证。在unittest框架中，TestCase类提供了较多的方法用于对接口响应结果的校验，表4列出了几个常用的断言方法。

表4 TestCase类常用断言方法

5 持续测试

持续测试单元由unittest单元测试框架、HTMLTest Runnner、Sendmail以及Jenkins构成。其中unittest完成测试用例池中的用例组织与管理，HTMLTestRunner用于生成测试报告，Sendmail发送测试报告，而Jenkins则是整个持续测试的核心，它定期执行测试任务，实现接口测试框架的持续运行。

使用unittest单元测试框架组织管理测试用例池中的测试用例，执行所有用例结束后利用HTMLTest Runner库生成html格式的测试报告，同时构建了SendMail模块发送测试信息，便于远程测试人员查看测试详情。

5.1 unittest与HTMLTestRunnner

unittest是一个Python单元测试框架，支持自动化测试，全局配置测试的开启与关闭，测试用例以集合的形式聚合到框架中。unittest以类的形式组织测试用例，每一个测试类起始由“setup()”构成，结束由“teardown()”构成，中间包括各个测试用例“test_case()”。HTMLTestRunner配合unittest用于将测试结果保存至html文件中，提高可读性。

在调用unittest单元测试框架时，测试用例必须以“test_”开头。通过中间件服务单元将测试用例池中的用例以方法的形式实例化并嵌入至unittest单元测试框架。另外，unittest提供了完整的断言方法，如果某个测试用例断言失败，框架则抛出“AssertionError”，并标识该用例测试失败；否则，则标识该用例为测试成功状态。例如assertEqual方法用于验证两个参数值是否相等，下述嵌入示例中的assertEqual验证响应结果的状态码是否为200，若不是则输出“测试失败”，并标记该用例为失败状态；否则，测试用例通过。一个类中可定义多个测试用例函数，按类分组批量执行测试用例。嵌入示例及代码结构如下所示：

嵌入示例:利用assertEqual检查接口的响应状态码类名←继承unittest中的TestCase类起始方法setUp测试用例函数func←传入用例参数(来源于测试用例池) url←用例池中的Request.url header←用例池中的Request.headers data←用例池中的Request.data res←Get_main/Post_main(url, header, data) assertEqual(res[′status′], ′200′, ′测试失败′)结束方法teardown

测试用例嵌入至unittest后，给定html文件的保存路径以及测试报告名称，完整的接口测试框架遍搭建完毕。unitest使用TestSuite管理测试用例，一个TestSuite是多个测试用例的集合，该集合内的所有测试用例将被一起执行。利用TestSuite可以将不同的测试用例组成测试逻辑组，即接口测试用例可根本被测软件的逻辑功能进行模块化组织，然后设置为统一的测试套件，对外仅暴露一个命令即可实现批量执行测试用例。

5.2 SendMail

接口自动化测试框架托管于远程服务器中，为了方便查看测试报告，本文利用smtplib库构建了SendMail模块集成至框架中，以邮件的形式发送测试报告。基本流程为：

1) 读取测试报告；

2) 添加邮件内容及附件；

3) 连接邮件服务器；

4) 发送邮件；

5) 退出。

框架定义list对象存储邮件接收者信息，每个元素为接收者的邮箱地址，用于接收测试报告。测试报告以“MIMEText”格式集成至框架中，用户设置本地邮箱和密码后，建立 SMTP邮件服务器，启动邮件发送流程，如发送异常，框架打印异常信息。

5.3 Jenkins持续集成测试

Jenkins平台安装Git插件后，将托管在Git服务器的代码更新至测试环境后做持续集成测试。在配置Jenkins任务时选择Git源码管理，通过“Poll SCM”设定测试时间间隔，便可持续进行接口测试。值得注意的是，设定测试时间间隔忌太短，以免对服务端造成额外的压力。每次测试结束后，Jenkins控制台输出测试信息，同时，测试报告以html形式存放于测试环境中的指定路径。

6 实施验证

在已部署接口自动化测试框架的测试机系统上，本文对一个Android开发应用实施接口自动化测试。具体环境、测试过程、结果如下所述。

6.1 测试环境

搭建基于CentOS 6.7 操作系统的的Linux测试环境， 部署本文提出的接口自动化测试框架。框架使用Python 3.6.12版本编写，依托于Jenkins 2.150.2版本持续集成运行。测试环境安装Git命令行工具，Jenkins配置Git服务器地址并生成密钥后与Git服务器建立连接。

6.2 测试过程

如表5所示，本文对国内某主流动漫社区安卓应用进行冒烟测试，收集其一级按钮下后端接口数据。首先使装有待测应用的客户端连接Charles代理服务器，然后对移动应用进行指定测试范围内的冒烟测试。测试结束后，Charles导出接口“.har”文件，经过Python解析后，共获取124个接口测试用例，部分测试用例数据如图7、图8所示。

表5 测试对象、方法、范围

图7 测试用例池记录(1)

图8 测试用例池记录(2)

6.3 添加校验规则与配置Jenkins

根据接口响应数据格式以及接口数据结构的不同，本文选取jsonschema与断言两种校验方式交叉验证接口数据是否正常返回。为上一小节测试用例池中的测试用例逐条添加校验规则装入unittest后，提交至Git服务器。

如表6的配置说明所述，在Jenkins平台，配置Git服务器地址，以Python脚本的方式每5分钟循环遍历用例池中的用例，每条测试用例通过unittest向服务端发出请求，检查响应是否符合预期设定的校验规则。单次遍历接口用例结束后，生成一份html格式的测试报告，包括执行用例时间、用例状态、成功或失败详情等，如图9所示。如图10所示，在Jenkins中配置发送者与接收者邮箱后，测试结束后便可向指定邮箱发送测试报告。

表6 Jenkins配置说明

图9 测试报告

图10 发送测试报告

6.4 框架运行分析

本文将提出的接口自动化测试框架在测试环境中运行24小时。邮箱以5分钟为间隔收集测试报告，每份报告提供测试详情。因接口返回数据动态变化，框架运行前期会出现因校验规则设计不完整与接口响应数据不匹配的现象，需及时修改校验规则以兼容所有可能的接口并正确返回；运行后期，框架便可实现无人值守的接口自动化测试。

另外，本文对于某些接口设计了相应的负向情况以检验框架的稳定性，当框架运行异常时，如脚本错误、服务端响应超时、测试任务异常等，Jenkins平台可按照向预先设置的管理员邮箱发送报警邮件，并提供出错的堆栈输出。

7 结 语

本文提出了一种基于Charles录制测试用例的HTTP接口自动化测试框架，它融合了现有接口测试工具的便利性，与此同时提高了测试效率。以功能测试为出发点，收集功能测试过程中的数据，以此为基础快速完善与补充测试用例，配合unittest框架和Jenkins平台实现完整的接口自动化测试。通过实践证明，工具在执行自动化接口测试的同时，起到了一定程度的监控作用，持续保证接口下发数据正常。

下一步的研究方向是增加参数列表，实现工具的自动构建测试用例，进而提高接口测试效率以及保证接口测试的全面性。