论文部分内容阅读
摘要：接口测试是软件系统测试非常重要的一个方面。某广告接口入参及出参众多，针对该接口进行日常测试时，需要执行的测试用例数量达到指数膨胀状态，且测试用例无法全面覆盖线上流量场景。在软件研发日益敏捷的时代，为了达到快速测试、场景覆盖度高这两大要求，基于unittest、DDT数据驱动测试框架等自动化测试用例组织技术，设计并实现了一套非常实用的接口Diff自动化测试框架。框架支持自动从线上服务器拉取所需的测试请求日志数据，通过在测试、线上两套环境中同时回放请求并收集返回结果，并以优美的Web页面展示测试结果报告。基于该框架的接口Diff自动化测试，能够在非常短的时间内高效完成日常测试，有效缓解了该广告产品因迭代频繁带来的巨大测试压力。
关键词：接口测试;unittest;数据驱动测试;Diff;请求日志
Abstract： Interface testing is a very important aspect of software system testing. Take an advertising interface as an example， there are many input params and output data， when test the interface daily， the number of test cases to be executed reaches an exponential expansion state， and the test cases can not fully cover the online traffic scenarios. In the era of increasingly agile software development， in order to meet the two requirements of rapid testing and high scene coverage， a very practical interface Diff automatic testing framework is designed and implemented based on the automation test case organizing technologies such as unittest and DDT data-driven testing framework. The framework supports automatically pulling the required test request log data from the online server， playing back the request and collecting the returned results in the test and online environments at the same time， and displaying the test result report in a beautiful web page. The interface Diff automatic test based on this framework can efficiently complete the daily test in a short time， and effectively solve the test pressure caused by frequent iterations of the advertising product.
Key words： interface test; unittest; data driven test; Diff; request log
1 背景
隨着现代互联网公司之间的竞争越来越激烈，用户需求也越来越多样化，对软件及服务更新速度和质量的要求也越来越高，如何通过加速产品研发流程，快速满足用户需求，使得在竞争加剧的时代赢得用户的青睐，成为企业关心的重要问题之一。举例来说，某广告业务为提升用户体验，间接提升收入，某后台服务已经达到了一天上线数次的频率，而在这种情况下，测试周期被不断压缩，于是对质量保障的速度以及质量提出了更高的要求。原有的手工回归测试至少也需要半天甚至更多的时间，并且回归测试能够覆盖的线上场景也非常有限，经常发生由于某个场景没有测试覆盖，导致出现线上问题，影响用户体验甚至收入。手工测试已不能满足业务迭代需求，测试同学面临两个问题：一是如何使得接口测试变得更快，二是如何使得测试场景覆盖度变得更高。在这种情况下，自动化测试[1]作为提升测试效率的一种手段，就变得迫在眉睫。在这个后端服务中，接口比较多，为了提升不同接口自动化测试的复用性，方便扩展，以及未来迁移到其他业务服务，如何设计一个好的测试框架就成为关键。为此，本文基于Shell技术、Python技术、unittest[2]单元测试技术、DDT数据驱动测试[3]技术、HTML超文本传输协议与CSS、JS编程语言，设计了一套方便、实用的基于请求日志的接口自动化Diff测试框架。该框架具有结构清晰、易扩展[4]、易维护等特点，能够将线上请求流量经过处理后保存到文件，作为测试数据输入，并通过数据驱动的测试方式，分别在测试、线上两套环境中执行测试并对比测试结果，并且将所有测试数据的测试结果通过Web页面形式的测试报告供开发人员浏览。通过在实际项目中使用该自动化测试工具，可以在五分钟内完成2000条请求日志的快速执行和对比，极大提升了测试的效率和覆盖度，有效解决了版本频繁迭代带来的测试人员压力过大问题，并且对于出现异常结果的测试数据，提供了详尽的错误原因，方便研发人员快速定位问题并修改bug。
2 整体设计
本文设计的接口自动化测试框架主要分为三部分，采用分层设计思想，且测试数据与测试脚本分离[5]。第一部分是测试数据获取模块，主要是通过Shell等技术，实现线上请求日志的抓取、处理，并将数据文件放入指定路径。第二部分是自动化测试执行模块，通过Python等技术，主要实现测试参数的输入及接收解析、Diff任务的执行及结果获取等内容。第三部分是测试结果展示模块，通过HTML、CSS及JS技术，主要实现对以上测试数据执行后的Diff结果报告的生成。 3 具体实现
3.1 测试数据获取模块
测试数据获取模块使用Shell脚本实现。在某广告业务中，接口入参多达30个以上，且一些关键参数的枚举值众多，会陷入组合爆炸情况，靠手工设计接口测试用例，远远无法覆盖线上多样化的请求场景。另外，除这些关键参数外，其他参数的不同值往往也会对业务内部的代码运行方式产生影响，需要对这些参数做比较全面的覆盖，来检查是否会导致程序崩溃等异常。于是，本文借助业务的线上请求日志来生成测试数据集，经过评估，数据的多样性得到了保证。
在某广告业务中，日志文件使用nginx的access.log文件，获取到日志后，通过awk等技术对日志请求参数进行提取后，拷贝到执行模块所在机器，以待自动化测试执行模块调用。
3.2 自动化测试执行模块
自动化测试执行模块采用Python编程语言开发实现。具体流程如图1所示。
依据图1所示流程框架，下面对该模块关键技术展开阐述。
3.2.1 参数解析
首先阐述该自动化Diff框架的参数设计。对Diff形式的接口自动化而言，必须使用两套环境，每个环境都要指定一个接口前缀;我们在做Diff时，有时根据业务需求，可能还需要在两套环境中分别指定需要追加的参数;作为针对返回结果的Diff，有几种不同的方式，可能是针对返回结果的全部内容进行Diff，也可能是针对指定字段进行Diff。如果针对全部内容进行Diff，也可能有部分字段无法对比，需要从对比项中过滤排除;如果针对指定字段进行Diff，那就需要通过参数显示指定需要对比的字段。
以上分析了框架需要接收的参数。作为一个自动化框架而言，参数可以通过配置文件或者命令行形式输入，而本文同时支持者两种形式，兼顾了执行的便捷性和灵活性。
1）对配置文件形式的参数输入方式而言，该自动化框架采用ini文件定义配置项，代码示例如下：
其中，Diff中的type字段表示过滤型Diff或者提取型Diff，env指定线上/线下环境，extend指定请求参数追加字段，filter指定Diff时需过滤的字段，extract指定Diff时需要提取的字段，log指定测试数据文件路径。在具体测试类中，通过Python的configparser模块加载ini文件中的配置项。
2）对命令行形式的参数输入方式而言，使用了Python的argparse模块来定义，部分代码示例：
通过以上两种参数输入方式，在运行时提供了充分的灵活性，比如可以结合两种参数输入方式的优点，部分固定参数通过配置文件加载，非固定参数通过命令行传入，减少了程序调用的接口复杂性。
3.2.2 用例组装
在用例组装阶段，本文采用了Python流行的单元测试框架unittest，以及数据驱动框架ddt模块，配合unittest完成测试类以及测试数据的组装。在测试用例目录，我们可以编写任意多的以test开头的Python文件，在每個Python文件中定义的测试类，都要加载ddt装饰器，至此就可以实现测试数据文件中的每一行请求参数均可以充当一个单独的测试用例来执行。
3.2.3 请求环境并获得响应
在测试类中，根据请求参数和测试数据，分别拼接线下和线上URL，然后使用Python的requests模块分别发送请求到两套环境，并获取响应状态码以及响应json数据。在请求过程中，可能会遇到偶尔的失败，所以需要增加重试机制，本文使用了requests模块中自带的Session、HTTPAdapter来实现重试3次的功能。
3.2.4 根据Diff类型进行结果递归对比
本文实现了两种Diff类型，分别为过滤型和提取型，过滤型适合响应内容的大部分字段都需要对比，只有少部分无需对比或者由于随机导致无法对比的情况;而提取型适合响应内容只需要对比其中一小部分字段的情况。根据不同的对比类型，调用不同的对比函数。
对比函数通过递归调用实现。首先本框架定义了四种错误类型，分别为value值不一致、test版本字段多余、test版本字段缺失、列表长度不一致。对于返回的json数据结构，均由key-value组成，而value可以分为字典类型、列表类型，以及普通的字符串。以过滤型Diff为例，对比程序可以描述如下：
1）获取整个online返回json，如果该value为字典类型，则进行如下处理：
①遍历test中的所有key，如果当前key在过滤字段中，则直接跳过;否则，如果该key在online中不存在，则记录错误;
②遍历online中的所有key，如果当前key在过滤字段中，则直接跳过;否则，如果该key在test中不存在，则记录错误;否则，递归调用该函数，继续判断该key对应的value值。
2）如果该value为列表类型，则进行如下处理：
①如果test列表长度与online列表长度不一致，则记录错误;
②如果test列表长度与online列表长度一致，则逐个列表项再次递归调用。
3）如果该value为普通字符串类型，则判断test与online是否一致，不一致则记录错误。
4）递归结束之后，将收集到的错误返回给主程序。
5）在主程序判断是否有错误，并进行断言。
3.3 测试结果展示模块
测试结果展示模块采用Python第三方模块BeautifulReport来实现。在BeautifulReport库中，主要由BeautifulReport.py模块以及template.html构成，template.html负责测试报告的页面结构及样式，而CSS样式则通过内联形式定义在html中，使得测试报告无需依赖其他任何文件，并通过JS代码将所有测试用例的结果数据加载到页面中。而测试用例结果数据通过BeautifulReport.py模块完成收集。 整个测试报告由报告汇总区以及详细数据区两大部分组成[6]。报告汇总区展示本次测试的整体统计数据，如用例总数、用例通过数、用例失败数、用例跳过数、测试开始时间、运行时间等，并通过饼图展示用例成功数、失败数以及跳过数各自的占比，视觉效果一目了然。在详细数据区域，展示了每条测试数据的编号、所在测试类、测试方法、运行时长、测试结果等。其中，每条用例的执行结果的细节数据默认为隐藏状态，在每条执行结果的操作栏点击“展开”按钮，可以看到当前这条测试用例运行过程中收集到的数据，对于失败的用例，提供了非常清晰的断言结果，显示具体错误原因，给后续的问题排查提供足够的数据支持。并且在详细数据区域，也提供了筛选条件，可以筛选属于不同测试类，以及不同测试结果的数据。具体测试报告主界面效果如图2。
4 持续集成测试
前文我们提到，该自动化测试框架采用unittest结合DDT组织测试用例，为了方便调用，我们需要将该程序提供为服务，供研发人员在日常开发测试过程中使用，以此尽可能提高产品迭代效率。Jenkins作为持续集成[7]测试常用的工具，只需要进行Job配置，将线上请求日志抓取过程、触发unittest启动脚本等流程组装起来，并通过参数化构建，就可以运行并得到测试结果，通过设定邮件通知，当执行结束后能够及时发送邮件给相关人员，并且可以自定义邮件，展示构建ID、构建人、构建状态、测试报告地址等信息，使得执行结果一目了然。
5 实际产品应用
某广告业务核心接口有两个，分别是使用protobuf作为序列化协议的前端处理接口以及使用json作为序列化协议的后端算法处理接口。以json协议的接口为例，该接口使用GET请求方式，参数多达三十多个，其中有一些必须要关注的重要参数，比如广告类型字段共有三十多种组合情形，协议字段有两种类型，渠道号有三种组合类型，仅考虑此三个字段，就有二百多种场景，并且该json接口响应内容字段也有几十个，校验点多，执行手工回归测试就需要将近一天的时间。再以protobuf协议的接口为例，该接口使用POST请求方式，构造protobuf请求参数也需要考虑几十种场景，且构造相对麻烦，返回的protobuf数据也需要校验几十个字段的正确性，一次手工回归测试工作量也在一天左右。而现阶段产品往往迭代非常快速，在该业务最高峰时，一天的时间需要上线数次，所以手工测试完全无法满足当前业务需求。自动化测试能够以更高效的方式代替或者补充烦琐的手工测试，因此，自动化测试已经成为当前业务测试的必然手段。
采用本文的自动化Diff测试框架，应用到某广告业务上，以json协议的接口为例，通过从线上服务器获取请求日志并做预处理，处理成测试框架需要的参数文件，然后通过Python命令调用测试框架主程序入口文件，触发unittest，框架通过ddt将测试用例文件中的每一行测试数据映射到测试用例方法中，然后分别请求测试环境与线上环境，并递归对比返回结果，生成测试报告，通过对整个流程的执行耗时进行了分析，统计到平均2000条测试用例数据执行耗时在3分钟左右，且通过详细的断言输出，能够立即定位错误场景，与手工测试相比，自动化耗时极少，测试效率提升显著。
再应用到该广告业务的protobuf协议的接口测试，通过从线上固定采集一批protobuf二进制流数据，采用base64形式编码为文本并存储到文件中，然后调用测试框架主程序入口文件，在测试类中对测试数据进行base64解码后发送到接口，获得protobuf响应后，将响应内容转化为Python字典，然后调用同样的递归对比函数，也可以迅速得到测试结果。
6 未来发展方向
前文提到该广告业务场景众多，如果抓取的线上请求日志量不够，则可能无法覆盖比较完整的测试场景;如果抓取的线上请求日志量太多，则测试执行时间又会变长。所以，如何用较少的测试用例覆盖更加全面的测试场景，消除相似或者重复的测试数据，也就是如何对流量进行精选以提升效率，是一个值得探索的方向。比如，可以通过每日定时获取大量请求日志，并基于特定规则消除等价类，这样在某种程度上能够减少较多的等价case。或者，通过训练特定AI模型，通过构建相似度分值的方式，也值得探索。另外，业界也在尝试用例自动生成技术[8]，可以基于已有用例来生成新的用例，丰富测试数据，也是一个值得探索的方向。
部分接口返回内容中，可能存在多层嵌套，不同级别也存在字段名称重复的情况，故本文中涉及的过滤以及提取字段的指定方式可能存在不够精准的情况，后期也可以通过使用Jsonpath等技术，精确指定需要过滤或者提取的字段。
另外，也可以探索基于统计的形式，通过汇总相同的错误，给出更进一步的错误分析，通过错误分析信息能够进一步提升问题排查速度。
7 结束语
传统的HTTP接口手工测试效率低下，测试工作量大，且工作本身重复度高，现阶段业务迭代速度越来越快，手工测试已不能满足需求，自动化测试是唯一的出路。不同于针对单环境的接口自动化测试断言的方式，本文通过在测试环境与基准环境中分别请求接口，通过Diff技术实现自动化测试，使得自动化测试更精准，问题发现效率更高，尤其适合本文提到的查询类型的接口。该测试框架通过良好的执行接口传参设计、用例的组织、数据驱动测试的模式、高效的递归对比、清晰明了的测试报告，并通过无缝与持续集成平台对接，实现了测试服务化，极大提升了测试效率，释放了大量的测试资源，使得测试同学可以做更多有价值的事情。通过实际运行数据，发现使用该测试框架进行日常测试回归，对整体软件质量的提高有突出的贡献，线上bug明显减少。
参考文献：
[1] 邢翠芳，杜晶，赵海冰.软件自动化测试技术研究[J].电脑知识与技术，2013，9（12）：2923-2925.
[2] 王娜.基于python的接口自动化测试框架设计[J].电脑知识与技术，2020，16（12）：246-248.
[3] 劉智.一种数据驱动的软件接口自动化测试框架的设计与实现[J].信息化研究，2015，41（1）：75-78.
[4] 朱菊，王志坚，杨雪.基于数据驱动的软件自动化测试框架[J].计算机技术与发展，2006，16（5）：68-70.
[5] 周娟，蒋外文.基于Web的自动化测试框架[J].计算机工程，2009，35（18）：65-66.
[6] 孙立哲.轻量级接口自动化测试框架设计与实践[J].计算机应用与软件，2020，37（1）：27-30，36.
[7] 国建胜，张亚楠，刘晶.基于持续集成的自动化测试框架[J].电脑知识与技术，2019，15（6）：259-260.
[8] 尤枫，赵瑞莲，吕珊珊.基于输出域的测试用例自动生成方法研究[J].计算机研究与发展，2016，53（3）：541-549.
【通联编辑：谢媛媛】
关键词：接口测试;unittest;数据驱动测试;Diff;请求日志
Abstract： Interface testing is a very important aspect of software system testing. Take an advertising interface as an example， there are many input params and output data， when test the interface daily， the number of test cases to be executed reaches an exponential expansion state， and the test cases can not fully cover the online traffic scenarios. In the era of increasingly agile software development， in order to meet the two requirements of rapid testing and high scene coverage， a very practical interface Diff automatic testing framework is designed and implemented based on the automation test case organizing technologies such as unittest and DDT data-driven testing framework. The framework supports automatically pulling the required test request log data from the online server， playing back the request and collecting the returned results in the test and online environments at the same time， and displaying the test result report in a beautiful web page. The interface Diff automatic test based on this framework can efficiently complete the daily test in a short time， and effectively solve the test pressure caused by frequent iterations of the advertising product.
Key words： interface test; unittest; data driven test; Diff; request log
1 背景
隨着现代互联网公司之间的竞争越来越激烈，用户需求也越来越多样化，对软件及服务更新速度和质量的要求也越来越高，如何通过加速产品研发流程，快速满足用户需求，使得在竞争加剧的时代赢得用户的青睐，成为企业关心的重要问题之一。举例来说，某广告业务为提升用户体验，间接提升收入，某后台服务已经达到了一天上线数次的频率，而在这种情况下，测试周期被不断压缩，于是对质量保障的速度以及质量提出了更高的要求。原有的手工回归测试至少也需要半天甚至更多的时间，并且回归测试能够覆盖的线上场景也非常有限，经常发生由于某个场景没有测试覆盖，导致出现线上问题，影响用户体验甚至收入。手工测试已不能满足业务迭代需求，测试同学面临两个问题：一是如何使得接口测试变得更快，二是如何使得测试场景覆盖度变得更高。在这种情况下，自动化测试[1]作为提升测试效率的一种手段，就变得迫在眉睫。在这个后端服务中，接口比较多，为了提升不同接口自动化测试的复用性，方便扩展，以及未来迁移到其他业务服务，如何设计一个好的测试框架就成为关键。为此，本文基于Shell技术、Python技术、unittest[2]单元测试技术、DDT数据驱动测试[3]技术、HTML超文本传输协议与CSS、JS编程语言，设计了一套方便、实用的基于请求日志的接口自动化Diff测试框架。该框架具有结构清晰、易扩展[4]、易维护等特点，能够将线上请求流量经过处理后保存到文件，作为测试数据输入，并通过数据驱动的测试方式，分别在测试、线上两套环境中执行测试并对比测试结果，并且将所有测试数据的测试结果通过Web页面形式的测试报告供开发人员浏览。通过在实际项目中使用该自动化测试工具，可以在五分钟内完成2000条请求日志的快速执行和对比，极大提升了测试的效率和覆盖度，有效解决了版本频繁迭代带来的测试人员压力过大问题，并且对于出现异常结果的测试数据，提供了详尽的错误原因，方便研发人员快速定位问题并修改bug。
2 整体设计
本文设计的接口自动化测试框架主要分为三部分，采用分层设计思想，且测试数据与测试脚本分离[5]。第一部分是测试数据获取模块，主要是通过Shell等技术，实现线上请求日志的抓取、处理，并将数据文件放入指定路径。第二部分是自动化测试执行模块，通过Python等技术，主要实现测试参数的输入及接收解析、Diff任务的执行及结果获取等内容。第三部分是测试结果展示模块，通过HTML、CSS及JS技术，主要实现对以上测试数据执行后的Diff结果报告的生成。 3 具体实现
3.1 测试数据获取模块
测试数据获取模块使用Shell脚本实现。在某广告业务中，接口入参多达30个以上，且一些关键参数的枚举值众多，会陷入组合爆炸情况，靠手工设计接口测试用例，远远无法覆盖线上多样化的请求场景。另外，除这些关键参数外，其他参数的不同值往往也会对业务内部的代码运行方式产生影响，需要对这些参数做比较全面的覆盖，来检查是否会导致程序崩溃等异常。于是，本文借助业务的线上请求日志来生成测试数据集，经过评估，数据的多样性得到了保证。
在某广告业务中，日志文件使用nginx的access.log文件，获取到日志后，通过awk等技术对日志请求参数进行提取后，拷贝到执行模块所在机器，以待自动化测试执行模块调用。
3.2 自动化测试执行模块
自动化测试执行模块采用Python编程语言开发实现。具体流程如图1所示。
依据图1所示流程框架，下面对该模块关键技术展开阐述。
3.2.1 参数解析
首先阐述该自动化Diff框架的参数设计。对Diff形式的接口自动化而言，必须使用两套环境，每个环境都要指定一个接口前缀;我们在做Diff时，有时根据业务需求，可能还需要在两套环境中分别指定需要追加的参数;作为针对返回结果的Diff，有几种不同的方式，可能是针对返回结果的全部内容进行Diff，也可能是针对指定字段进行Diff。如果针对全部内容进行Diff，也可能有部分字段无法对比，需要从对比项中过滤排除;如果针对指定字段进行Diff，那就需要通过参数显示指定需要对比的字段。
以上分析了框架需要接收的参数。作为一个自动化框架而言，参数可以通过配置文件或者命令行形式输入，而本文同时支持者两种形式，兼顾了执行的便捷性和灵活性。
1）对配置文件形式的参数输入方式而言，该自动化框架采用ini文件定义配置项，代码示例如下：
其中，Diff中的type字段表示过滤型Diff或者提取型Diff，env指定线上/线下环境，extend指定请求参数追加字段，filter指定Diff时需过滤的字段，extract指定Diff时需要提取的字段，log指定测试数据文件路径。在具体测试类中，通过Python的configparser模块加载ini文件中的配置项。
2）对命令行形式的参数输入方式而言，使用了Python的argparse模块来定义，部分代码示例：
通过以上两种参数输入方式，在运行时提供了充分的灵活性，比如可以结合两种参数输入方式的优点，部分固定参数通过配置文件加载，非固定参数通过命令行传入，减少了程序调用的接口复杂性。
3.2.2 用例组装
在用例组装阶段，本文采用了Python流行的单元测试框架unittest，以及数据驱动框架ddt模块，配合unittest完成测试类以及测试数据的组装。在测试用例目录，我们可以编写任意多的以test开头的Python文件，在每個Python文件中定义的测试类，都要加载ddt装饰器，至此就可以实现测试数据文件中的每一行请求参数均可以充当一个单独的测试用例来执行。
3.2.3 请求环境并获得响应
在测试类中，根据请求参数和测试数据，分别拼接线下和线上URL，然后使用Python的requests模块分别发送请求到两套环境，并获取响应状态码以及响应json数据。在请求过程中，可能会遇到偶尔的失败，所以需要增加重试机制，本文使用了requests模块中自带的Session、HTTPAdapter来实现重试3次的功能。
3.2.4 根据Diff类型进行结果递归对比
本文实现了两种Diff类型，分别为过滤型和提取型，过滤型适合响应内容的大部分字段都需要对比，只有少部分无需对比或者由于随机导致无法对比的情况;而提取型适合响应内容只需要对比其中一小部分字段的情况。根据不同的对比类型，调用不同的对比函数。
对比函数通过递归调用实现。首先本框架定义了四种错误类型，分别为value值不一致、test版本字段多余、test版本字段缺失、列表长度不一致。对于返回的json数据结构，均由key-value组成，而value可以分为字典类型、列表类型，以及普通的字符串。以过滤型Diff为例，对比程序可以描述如下：
1）获取整个online返回json，如果该value为字典类型，则进行如下处理：
①遍历test中的所有key，如果当前key在过滤字段中，则直接跳过;否则，如果该key在online中不存在，则记录错误;
②遍历online中的所有key，如果当前key在过滤字段中，则直接跳过;否则，如果该key在test中不存在，则记录错误;否则，递归调用该函数，继续判断该key对应的value值。
2）如果该value为列表类型，则进行如下处理：
①如果test列表长度与online列表长度不一致，则记录错误;
②如果test列表长度与online列表长度一致，则逐个列表项再次递归调用。
3）如果该value为普通字符串类型，则判断test与online是否一致，不一致则记录错误。
4）递归结束之后，将收集到的错误返回给主程序。
5）在主程序判断是否有错误，并进行断言。
3.3 测试结果展示模块
测试结果展示模块采用Python第三方模块BeautifulReport来实现。在BeautifulReport库中，主要由BeautifulReport.py模块以及template.html构成，template.html负责测试报告的页面结构及样式，而CSS样式则通过内联形式定义在html中，使得测试报告无需依赖其他任何文件，并通过JS代码将所有测试用例的结果数据加载到页面中。而测试用例结果数据通过BeautifulReport.py模块完成收集。 整个测试报告由报告汇总区以及详细数据区两大部分组成[6]。报告汇总区展示本次测试的整体统计数据，如用例总数、用例通过数、用例失败数、用例跳过数、测试开始时间、运行时间等，并通过饼图展示用例成功数、失败数以及跳过数各自的占比，视觉效果一目了然。在详细数据区域，展示了每条测试数据的编号、所在测试类、测试方法、运行时长、测试结果等。其中，每条用例的执行结果的细节数据默认为隐藏状态，在每条执行结果的操作栏点击“展开”按钮，可以看到当前这条测试用例运行过程中收集到的数据，对于失败的用例，提供了非常清晰的断言结果，显示具体错误原因，给后续的问题排查提供足够的数据支持。并且在详细数据区域，也提供了筛选条件，可以筛选属于不同测试类，以及不同测试结果的数据。具体测试报告主界面效果如图2。
4 持续集成测试
前文我们提到，该自动化测试框架采用unittest结合DDT组织测试用例，为了方便调用，我们需要将该程序提供为服务，供研发人员在日常开发测试过程中使用，以此尽可能提高产品迭代效率。Jenkins作为持续集成[7]测试常用的工具，只需要进行Job配置，将线上请求日志抓取过程、触发unittest启动脚本等流程组装起来，并通过参数化构建，就可以运行并得到测试结果，通过设定邮件通知，当执行结束后能够及时发送邮件给相关人员，并且可以自定义邮件，展示构建ID、构建人、构建状态、测试报告地址等信息，使得执行结果一目了然。
5 实际产品应用
某广告业务核心接口有两个，分别是使用protobuf作为序列化协议的前端处理接口以及使用json作为序列化协议的后端算法处理接口。以json协议的接口为例，该接口使用GET请求方式，参数多达三十多个，其中有一些必须要关注的重要参数，比如广告类型字段共有三十多种组合情形，协议字段有两种类型，渠道号有三种组合类型，仅考虑此三个字段，就有二百多种场景，并且该json接口响应内容字段也有几十个，校验点多，执行手工回归测试就需要将近一天的时间。再以protobuf协议的接口为例，该接口使用POST请求方式，构造protobuf请求参数也需要考虑几十种场景，且构造相对麻烦，返回的protobuf数据也需要校验几十个字段的正确性，一次手工回归测试工作量也在一天左右。而现阶段产品往往迭代非常快速，在该业务最高峰时，一天的时间需要上线数次，所以手工测试完全无法满足当前业务需求。自动化测试能够以更高效的方式代替或者补充烦琐的手工测试，因此，自动化测试已经成为当前业务测试的必然手段。
采用本文的自动化Diff测试框架，应用到某广告业务上，以json协议的接口为例，通过从线上服务器获取请求日志并做预处理，处理成测试框架需要的参数文件，然后通过Python命令调用测试框架主程序入口文件，触发unittest，框架通过ddt将测试用例文件中的每一行测试数据映射到测试用例方法中，然后分别请求测试环境与线上环境，并递归对比返回结果，生成测试报告，通过对整个流程的执行耗时进行了分析，统计到平均2000条测试用例数据执行耗时在3分钟左右，且通过详细的断言输出，能够立即定位错误场景，与手工测试相比，自动化耗时极少，测试效率提升显著。
再应用到该广告业务的protobuf协议的接口测试，通过从线上固定采集一批protobuf二进制流数据，采用base64形式编码为文本并存储到文件中，然后调用测试框架主程序入口文件，在测试类中对测试数据进行base64解码后发送到接口，获得protobuf响应后，将响应内容转化为Python字典，然后调用同样的递归对比函数，也可以迅速得到测试结果。
6 未来发展方向
前文提到该广告业务场景众多，如果抓取的线上请求日志量不够，则可能无法覆盖比较完整的测试场景;如果抓取的线上请求日志量太多，则测试执行时间又会变长。所以，如何用较少的测试用例覆盖更加全面的测试场景，消除相似或者重复的测试数据，也就是如何对流量进行精选以提升效率，是一个值得探索的方向。比如，可以通过每日定时获取大量请求日志，并基于特定规则消除等价类，这样在某种程度上能够减少较多的等价case。或者，通过训练特定AI模型，通过构建相似度分值的方式，也值得探索。另外，业界也在尝试用例自动生成技术[8]，可以基于已有用例来生成新的用例，丰富测试数据，也是一个值得探索的方向。
部分接口返回内容中，可能存在多层嵌套，不同级别也存在字段名称重复的情况，故本文中涉及的过滤以及提取字段的指定方式可能存在不够精准的情况，后期也可以通过使用Jsonpath等技术，精确指定需要过滤或者提取的字段。
另外，也可以探索基于统计的形式，通过汇总相同的错误，给出更进一步的错误分析，通过错误分析信息能够进一步提升问题排查速度。
7 结束语
传统的HTTP接口手工测试效率低下，测试工作量大，且工作本身重复度高，现阶段业务迭代速度越来越快，手工测试已不能满足需求，自动化测试是唯一的出路。不同于针对单环境的接口自动化测试断言的方式，本文通过在测试环境与基准环境中分别请求接口，通过Diff技术实现自动化测试，使得自动化测试更精准，问题发现效率更高，尤其适合本文提到的查询类型的接口。该测试框架通过良好的执行接口传参设计、用例的组织、数据驱动测试的模式、高效的递归对比、清晰明了的测试报告，并通过无缝与持续集成平台对接，实现了测试服务化，极大提升了测试效率，释放了大量的测试资源，使得测试同学可以做更多有价值的事情。通过实际运行数据，发现使用该测试框架进行日常测试回归，对整体软件质量的提高有突出的贡献，线上bug明显减少。
参考文献：
[1] 邢翠芳，杜晶，赵海冰.软件自动化测试技术研究[J].电脑知识与技术，2013，9（12）：2923-2925.
[2] 王娜.基于python的接口自动化测试框架设计[J].电脑知识与技术，2020，16（12）：246-248.
[3] 劉智.一种数据驱动的软件接口自动化测试框架的设计与实现[J].信息化研究，2015，41（1）：75-78.
[4] 朱菊，王志坚，杨雪.基于数据驱动的软件自动化测试框架[J].计算机技术与发展，2006，16（5）：68-70.
[5] 周娟，蒋外文.基于Web的自动化测试框架[J].计算机工程，2009，35（18）：65-66.
[6] 孙立哲.轻量级接口自动化测试框架设计与实践[J].计算机应用与软件，2020，37（1）：27-30，36.
[7] 国建胜，张亚楠，刘晶.基于持续集成的自动化测试框架[J].电脑知识与技术，2019，15（6）：259-260.
[8] 尤枫，赵瑞莲，吕珊珊.基于输出域的测试用例自动生成方法研究[J].计算机研究与发展，2016，53（3）：541-549.
【通联编辑：谢媛媛】