广告召回自动化测试之路

作者|姚晓明

广告召回测试之手动测试
广告业务，包括广告投放、广告检索、广告扣费等系统的开发和维护，本篇主要介绍测试在整个召回流程中的工作。

首先，我们来了解一下从页面发起请求直至广告展示扣费的整个过程

其中，商业召回服务的主要作用是承接APP服务和底层搜索服务，在测试的过程中，既要关注上层传入的参数，也要关注底层返回的数据，通常我们要测广告召回时，要进行以下一系列的操作：

从整个测试过程来看，手动测试有几个缺点：

依赖APP服务的稳定性，如果APP页面挂了或者服务挂了，很难开展测试

整个手动测试流程比较长，需要时刻切换页面以及切换各个服务日志

召回结果的准确性无法保证，在遇到召回策略及排序规则比较复杂的情况，就难以判断召回广告的正确性

召回日志和扣费日志需要检验的内容特别多，基本日志中的每一个参数都要进行校验，都需要特别关注

广告召回测试提效第一版
接着，为方便测试，减少各方面依赖，从日常测试进行提炼，商业测试组开发了几个工具，召回对比、召回日志、召回结果、召回case工具。

召回对比工具，适用于对比两套环境，比如：动态测试环境和稳定测试环境，动态沙箱环境和稳定沙箱环境，沙箱环境和线上环境，适用于测试广告策略新增修改，有一套基准的环境可以对比，可以看到本次需求改动所带来的广告召回的影响。

召回日志工具，直观的可以看到单次广告召回日志的信息，展示各种广告信息，比起看日志密密麻麻的更简洁、更清晰，不想登录服务器查看的时候，可用此工具解决，但是还是需要到服务器上去拿id信息。

召回结果工具，适用于某个环境召回看结果，不依赖于APP页面，选择环境，输入广告入参，即可进行召回，也可进行扣费。

召回case工具，用于平时维护广告召回的用例，一些常用的测试场景case，定期维护至平台，每次进行召回，都可以从这边寻找到广告入参，不必自己再拼装参数，大大简化了测试的前期准备工作。

基于这几个工具，由手动测试向半自动化测试进行了转变，不仅摆脱了对上游环境的依赖，由原来的通过APP页面进行召回转变成简单的通过工具页面就可以进行召回，而且召回的结果更加直观，原来APP页面只能展示基本的商品信息，而且广告藏在普通商品中间，非常的不方便也不直观，现在工具页面除了展示推广的商品信息，更多的展示了广告的推广信息，还有就是召回对比方便我们日常测试，更好的保证了召回广告的准确性。

单个工具虽好用，但是我们有更高的要求
以上四个好用的工具，单个用起来很顺手，但是却没有将广告的整个测试流程串起来，是属于半手动半自动化，召回结果和召回日志，是我们在测试广告任何需求中所必需要进行的，是两部分结合测试，所以要想整个流程更顺畅，要把两部分的测试工作串联起来，所谓众人拾柴火焰高，在经过与开发的几次探讨，最终产生了新的测试方案，开发协助测试，通过接口将日志结果返回，测试更好的利用召回结果和召回日志两部分，开始进行一系列回归测试方案设计开发。

广告召回自动化回归测试方案应运而生
1、了解广告的核心
首先，我们要梳理出广告的核心，才能有针对性有计划的实施广告自动化回归测试方案。整个广告的生命周期，由召回源->召回策略->打分->排序->扣费构成，其中核心部分为召回、扣费、策略，这也是我们日常测试过程中特别关注的几个重点环节，经过广告系统的不断迭代开发测试上线，集思广益梳理并总结出如下的核心测试场景：

2、核心case选取及回归流程
目前商业根据广告召回源分为7类 回归工具

首先，针对不同的召回源进行区分，将核心case进行归类，每一个召回源都要有一个代表的广告位；

其次，对于每个广告位都需要进行校验的点进行抽离，抽取出常规的校验点，也就是召回广告是否满足召回条件（例如推广时段）；

再次，对于一些特殊的广告位，有特殊的校验，把这部分抽离出来进行特殊校验；

最后是点击扣费过程中的校验点抽离出来进行扣费校验。

每一条case都要经过入参校验、常规校验、特殊校验、点击扣费校验4个模块，每一个模块校验完毕之后有一个结果，所有的校验完毕之后有一个最终的结果，标识整个case执行成功或是失败，并且失败的case会打印出具体失败的信息，是哪一步校验失败，方便排查问题。如下为回归工具的校验流程图：

3、自动化回归测试过程中遇到的问题及解决方案
整个回归测试计划，包含27条核心case，覆盖了线上流量较大、正在开启中的广告位。在开始执行回归测试的过程中也是遇到了各种各样的问题，一些case由于断言失败而导致执行结果失败。为了提升case的稳定性，使回归测试能够真正发挥作用，我们一直在对整个工具进行优化，挑选了几个比较典型的问题以及解决方案，跟大家进行分享：

（1）命中反作弊策略导致无法完成扣费校验

测试环境每条用例在召回广告的时候，召回的广告数量不确定，然而我们对每个召回的广告都进行了扣费校验，频繁的操作会导致命中扣费反作弊策略，所以在扣费的过程中，不能使用同一用户的唯一凭证进行扣费，而且不同的用例，使用的用户唯一凭证应该也不一样。

问题解决方案：用户信息替换

为解决此方案，我们进行了两步操作，首先寻找生成用户唯一凭证的工具，在入参的时候，对关键信息进行替换，保证每次用于召回的参数这些信息都是不一样的，其次在进行扣费校验的时候，我们没必要对所有的数据都进行扣费，只需要选取其中的几条来进行扣费规则的校验就能达到目的，实现自动化用户信息替换，也是更真实的符合广告召回扣费场景，使得我们的用例更贴近真实场景。

（2）商品状态、推广状态校验失败
测试环境，很多推广数据状态有问题，由于脏数据问题造成用例校验失败。脏数据产生的原因主要有两个：一部分是因为不同测试人员在线下环境操作数据时，数据的状态不一致，导致对召回结果进行校验失败；另一部分的脏数据来源于case执行过程中造的数据进行操作时，数据的状态出现问题，导致后续的召回失败。

问题解决方案：数据治理

数据治理工具，可以提供批量处理问题数据的能力，可以按账号进行问题数据批量处理，也可以进行单个问题数据处理，其作用主要体现在两个部分，一部分是在回归执行前先批量处理一部分数据；另外一部分是在特殊的case中，每次召回之前，先对处理的数据进行一次状态的校验，如果数据状态异常，先对数据进行一次预处理，保证广告能够正常的召回，用这样的方式来避免脏数据对回归测试结果的影响，有利于回归用例的稳定性。

（3）特殊场景用例无法进行校验
回归测试计划中的用例，有些用例需要在特定的场景下才可以进行校验，比如扣费金额相关的用例，依赖于特定的条件，否则强行校验毫无意义。

问题解决方案：数据构造

通过配置，哪个用例需要调用哪个数据构造方法，便于日后扩展使用，在之前，组内也提供了很多数据构造的工具，除了用于提效日常的测试过程，也可以发挥它更大的价值作用。数据构造作为基础的工具，是日常必不可少的，这个需要平时组内的共同积累，有了工具，就该把工具的作用尽可能的发挥，更好的协助平时的测试工作，此次我们将数据构造与回归测试结合，有助于日后回归测试的扩展，我们能做到的回归范围会越来越广。

（4）用例之间相互影响导致校验失败
整个回归测试计划，执行时间在5分钟左右，为了解决耗时问题，采用了异步和多线程对代码进行优化，目前耗时在80s左右，本来想着工具又提升一步，但是新的问题又产生了。在之前的实现方式中，用例每次顺序执行，执行结果没有问题，现在用例随机执行，发现有的用例之间在执行的过程中产生了影响，会造成本应该执行成功的用例却失败了。

问题解决方案：用例间解耦

保持用例间相互独立，执行起来互不影响，所以在选取用例参数的时候，也是至关重要的，在之前我们习惯用一些常用的分类，比如手机、交通工具等，所以在参数选取上刚开始也是选取的这些，正是出现了新的问题，让我们开始意识到，不同的用例，在参数选取上尽量多样性，尽量避开选取相同的几个类目，对用例执行结果之间可能产生相互影响，用例参数的选取丰富了，也增强了我们回归工具的健壮性。

通过对工具的不断优化，回归工具的稳定性越来越高，目前工具的成功率可以达到90%。

4、效果展示
回归工具主要用于每次涉及广告核心服务上线前的回归，在保证本次需求测试通过的前提下，通过回归工具保证广告的核心流程不受影响，上线之后，为广告的核心服务提供了自测的手段，为每一次上线做兜底。

截止目前，发现的主要问题有，上线某个策略导致其他不相关的广告位召回失败，问题原因是：代码层没有针对没有配置策略的广告位进行判空处理。

由于我们的广告位越来越多，手动回归所有的广告位不现实，有必要进行每一次广告服务上线前的自动化回归。除此之外，回归工具在线下环境也发挥了作用：例如线下环境的广告位配置因为人为改动原因，经常与线上不一致，导致线下广告召回结果不符合预期，以为是需求bug；线下数据清理的错误，导致召回结果不符合预期；线下环境配置问题导致召回结果不符合预期……这些问题虽然不是线上bug，但是由于这些问题的存在，会影响到我们线下测试的效率以及测试和开发的判断，增加排查问题的难度，因此，召回工具常规在线下进行执行，也可以帮我们排除一些召回的干扰因素。

我们的故事才刚刚开始
正是出现的这些问题，激励着我们不断完善工具的可用性和可推广性，顺势发展，在广告流程不断的迭代开发中，测试工具也需要时刻保持与时俱进，坚持不断的丰富和完善工具，在实现全面广告自动化流程的道路上不断进步，解放人力，把人力投入到更有价值的地方。