广告业务自动化测试探索

前言

对于测试来说，在熟悉了现有业务之后，挖掘业务测试中的痛点进行有针对性的自动化以提升测试效率和质量保障效果，是我们不断追求的目标。

比如一个需要经常回归的主流程、人工测试需要耗费大量时间甚至根本不可能实现的测试点、测试数据的频繁构造、辅助业务方的小工具，都可以是我们探索实现自动化可能的效率点。

笔者所服务的是广告业务，作为DSP对每天近百亿流量请求作出响应，返回广告。

那么，在广告业务中，为什么需要实现自动化，以及我们是采用何种方式实现自动化的，将是本文叙述的重点。

业务背景

首先，为了大家对整体业务流程有一个感知，先介绍下数据流转过程：

上图是一个极其简化的流程，主要的流程会涉及三方：媒体方（SSP）、ADX（广告交易平台）、DSP。

媒体方有一些变现的需求，所以会在自身页面或者APP中放置一些广告位，广告请求会经由广告交易平台，再广播给各个DSP（需求方平台）。

DSP根据接口请求，经过内部一系列处理，进而返回广告内容进行竞价。如果最终获得展现、点击机会，则会发出相关打点。

在整个流程中，笔者主要测试的就是DSP业务对接口请求的处理过程。那么这个测试过程中的要点有哪些呢？

01

收入层面

作为广告变现业务，收入肯定是第一要务，也是终极目标。

任何一个小的业务逻辑可能都会对收入产生影响，所以需要对业务逻辑进行全面覆盖，同时还需要实时监控线上运行情况，包括接口的业务逻辑、收入、以及一些关键数据的监控。

02

接口层面

DSP与ADX是通过googleprotobuf协议来进行数据交互的，这是一个非常高效的数据传输格式，尤其适合如广告业务这样的需要大量数据传输的场景，感兴趣的同学可以google相关资料。

在协议所定义的proto文件中，关注请求参数与响应字段分别有近50个，对于其中的很多重要参数都需要覆盖不同的请求情况。

以移动DSP为例：http/https、app/wap、单图/多图、图片宽高组合等都需要做一个全面覆盖的验证工作。

这样就存在参数的组合爆炸问题，工作量可想而知。

03

日志层面

大家都知道，广告业务的数据分析、收入结算都依赖服务器日志，所以日志正确性验证也是很重要的一点。

但日志字段相当多，手工验证效率并不高。

基于这三点，我们发现只能通过自动化+线上监控的方式，才能更好保障业务质量。

线上监控的话题在

《测试右移：线上监控实践》

中已经阐述，所以本文只着重介绍自动化的实现方式。

自动化测试方案

首先给大家呈现整体的测试方案架构图：

下面逐个介绍下架构中用到的一些关键技术、框架。

注：部分敏感数据已进行遮挡，请见谅。

01

发请求的Client模块

因为该测试隶属于接口测试范畴，所以需要一个接口请求模块。

主要包括protobuf请求参数的构造、发送、接口返回数据的解析、以及下文将会提到的使用ElasticSearch API对于日志数据的获取、解析过程。

02

测试用例以及测试数据组织：Pytest

本方法使用Pytest这个Python测试框架来组织测试用例。

笔者之前做过一些调研，Python测试框架有unittest、Nose、Pytest等，最终选定了Pytest，因为它具有以下几个优点：

感兴趣的同学可以研究下。

在本方案中，其实是采用了Pytest+requests来做的接口自动化。

测试用例的编写可能是如下形式：

03

日志收集：Logstash+ElasticSearch

对于日志验证，有同学可能试过直接通过类似paramiko的库连接服务器，执行一系列shell来获取想要的日志。

这里笔者感觉获取日志的过程还可以优化，于是调研了业界常用的Logstash+ElasticSearch方案，发现正好能满足需求。

可以这么介绍Logstash：

Logstash 是一个开源的日志收集引擎，能够实时检测文件变动并传输数据，为日志分析、数据存储、报表查询、监控预警提供强大的管道链。

如果你所在的业务有日志收集分析需求，那么可能听说过这个工具，生产服务器上一般都会安装。

Logstash的配置文件很简单，主要是三部分：

input部分会定义需要监控的文件路径；

中间的filter部分可以设置一些处理过程，比如提取想要的特定字段；

output部分会定义收集到的日志输出到哪里，可以输出到文件、控制台、消息队列、抑或是ElasticSearch这样的搜索引擎供后续查询。

在本方案中，Logstash会配置输出到ElasticSearch。

可以这么介绍：

Elasticsearch是一个基于Restful API的分布式存储及全文检索引擎，它提供了非常灵活好用的API，能够让我们查询存储到其中的日志数据。

比如，可以以下面的两种形式进行数据查询：

好了，Logstash和ElasticSearch都介绍完了。

我们会将Logstash安装到测试服务器上，配置好对应输入输出，设置后台运行。

ElasticSearch会安装到另一台服务器中运行，整体的数据流就会是这样：

具体而言，在本方案中，Logstash的配置如下：

使用ElasticSearch查询出的日志数据如下：

我们可以使用API查询出对应的日志进行详细的断言，这样可以验证日志的正确性。

04

数据可视化展示：Kibana

其实在本方案中并没有用到数据可视化，因为所有的日志数据都是自动化验证，不需要展示具体数据。

但因为业界ELK的名声已经打出来了，“K”就是所谓的Kibana，所以这里附带介绍下这个工具，搭建好后，界面如下：

05

持续集成及报告展示：Jenkins+Allure

持续集成的整个过程通过Jenkins调起，测试报告用的是Allure。

总结

上述就是笔者在DSP业务中探索的一些自动化方案。

注：由于部分数据比较敏感，所以没有给出全部截图，还请见谅。

该自动化使得参数全量组合情况下的所有字段的验证成为可能，结合Jenkins可以实现日构建、夜构建，保障功能的稳定性。

感兴趣的同学欢迎留言探讨，也希望方案中的一些技术细节对于你所在的业务有一些借鉴意义。

Qtest是360旗下的专业测试团队！

是WEB平台部测试技术平台化、效率化的先锋力量！