大数据算法应用的测试发展之路（二）

在上一篇文章中，我们介绍了大数据应用在测试领域的六大问题，分别是功能性测试与验证、数据更新的实时性、数据请求响应的及时性、算法的效果、AI 算法系统的线上稳定性和工程效率。本文，我们就来讲讲这六大问题应该如何解决?

一、AI 应用的功能性测试验证

功能测试主要分为三部分：端到端的用户交互测试、在线工程的功能测试、离线算法系统的功能测试。

1）端到端的用户交互测试

搜索推荐广告系统中的用户交互测试，既包括了买家端（手机淘宝、天猫 app 和优酷 app 等）的用户体验和逻辑功能的验证，也包括了针对广告主和商家的客户管理平台（Business Platform）上业务流程逻辑的校验，其中会涉及广告主在广告创意创作、投放计划设定、计费结算等方面的测试。

端到端的测试保证了最终交付给用户和客户使用的产品质量。端上的测试技术和工具，主要涉及端到端（native/h5）app/web 上的 UI 自动化、安全、性能稳定性（monkey test/crash 率）、流量（弱网络）、耗电量、兼容性和适配。我们在集团其他团队的测试技术和开源技术体系的基础上做了一些改进和创新，例如将富媒体智能化验证引入客户端自动化测试，完成图像对比、文字 OCR、局部特征匹配、边缘检测、基于关键帧的视频验证（组件动画、贴片视频）等，解决了广告推荐在客户端上所有展现形式的验证问题。另外，针对 Java 接口和客户端 SDK 的测试，除了常规的 API Service 级别测试之外，在数据流量回放的基础上使用对比测试的方法，在接口对比、DB 对比、文件对比、流量对比的上有一些不错的质量效果。

由于 UI 的改版速度非常快，所以在端到端的测试策略方面，我们把自动化的重点放在接口层面，UI 的 automation 只是简单的逻辑验证，全量的 UI 验证回归（功能逻辑和样式体验）还是通过手动测试。这里我们使用了不少的外包测试服务作为补充。

2）在线工程系统的测试

在线工程系统测试是整个系统功能测试的重点。

以搜索推荐广告系统为例，其本质上是数据管理的系统，数据包括商品维度、用户维度、商家和广告主维度的数据。把大量的数据按照一定的数据结构存储在机器内存之中，提供召回、预估、融合等服务，这些都是在线工程要去解决的问题。

在线工程系统测试的基本原理是通过发送 Request/Query 请求串、验证 Response 结果的模式，并在此基础上使用多种提升测试用例生成效率和执行效率的技术。基于可视化、智能化等技术（智能用例生成、智能回归、失败智能归因、精准测试覆盖、功能 A/B 测试），把测试方法论融入其中，解决大规模异构的在线工程功能测试 case 编写成本高、debug 难、回归效率低的问题。

搜索推荐广告的在线服务工程基本上由 20—30 个不同的在线模块组成，测试这些在线服务模块极其消耗时间，用例的编写效率和回归运行效率是优化的主要目标。我们在用例生成阶段，通过用例膨胀和推荐技术、基于遗传算法动态生成有效测试用例，在用例执行阶段，使用动态编排的回归技术，来提升在线模块功能测试的覆盖率。此外，我们比较多地使用线上的 Query 做对比测试的方法，用以验证功能变更的差异，分析即将发布的系统与实际线上系统之间的结果一致率和数据分布，来很好地找到系统的功能性问题。

在线上测试领域，除了对比测试，我们把近期 Top-N 的 Query 在线上定时做巡检监察，一方面起到功能监控的作用，另一方面 Query 量级到一定程度（例如最近一周 80%的长尾 Query），可以很轻松地验证引擎数据的完整性和多样性。

最后，这一部分的测试策略也需要强调一下，由于算法的逻辑（例如召回和排序的业务逻辑）非常复杂，涉及不同的业务和分层模型，这些逻辑是算法工程师直接设计实现的，所以算法逻辑的测试用例的设计和执行也是由算法工程师来做，只有他们最清楚模型的功能逻辑和如何变化。结合着线上 debug 系统的使用，算法工程师可以很清楚目前线上运行的算法和线下即将上线的算法之间的逻辑差异，测试用例也就比较容易编写。测试工程师在其中主要负责整个测试框架和工具环境的搭建，以及基本测试用例的编写与运行。这个测试策略的调整，在本文最后关于测试未来的预判部分也有介绍。

3）算法工程测试与离线系统测试

从数据流程的角度看，算法工程包括算法模型的建模流程和模型训练上线两部分，我们可从特征提取、样本生成、模型训练、在线预测，整个 pipeline 离线流程到在线的过程，来验证特征样本的质量和模型的质量。

算法测试的关键在于三个部分：

• 样本特征质量的评估

• 模型质量的评估

• 模型在线预估服务的质量保障

样本特征质量的评估和模型质量的评估，涉及数据质量与特征功效放在一起在第四部分效果评估部分介绍，主要使用数据质量的各种指标的设计与实现来评估它们的质量。这里重点说一下第三个：模型在线预估服务的质量保障，即算法在线预估服务上线前的测试，因为其涉及到模型最终服务的质量，比较重要。我们采用了一种小样本离线在线打分对比的方法，较为简单地解决了模型上线质量的问题。

具体的验证过程是这样的：在模型上线正式服务之前，需要对模型做测试验证，除了准备常规的 test 数据集，我们单独分离出一部分样本集，称为小样本数据集，对比小样本数据集在线系统的得分与离线分数异，验证模型的在线服务质量，这种小样本打分实际上也提供了类似于灰度验证的能力。见下图 2。

图 2 小样本测试流程示意图

关于离线系统的测试，我们在深度学习训练平台的质量保障上也做了一些探索。

目前深度学习平台质量主要面临三大难点：

• 由于种种复杂状况，集群上训练的模型存在训练失败的风险，如何提前预警深度学习平台当前存在的潜在风险；

• 由于神经网络天然局部最优解基因和 Tensorflow Batch 的设计思路，每次训练的模型，如何保障其满足上线的质量要求；

• 如何验证在大规模数据集和分布式系统下，深度学习平台提供的各种深度学习功能的准确性；

针对以上三个问题，我们也尝试了三个解决方法：

• 实验预跑法，设计特别的模型和训练数据，15 分钟内训练完毕。可以快速发现和定位训练平台的问题，在大规模的生产模型正式训练之前就发现问题；

• Model on Model 的模型验证法，把模型生产的中间数据指标（除 auc 之外，还包括神经元激活率、梯度在各层传到均方差等）透传加工建模，监控生产模型的质量；

• Model Based 功能校验法，针对性地设计样本格式和测试模型网络，精确计算出模型 variable 的理论值，根据训练模型的结果验证平台的质量。

二、数据更新的实时性测试

测试数据更新的实时性，其中主要是解决两个子问题，即引擎数据实时更新链路的测试和模型实时更新（Online Deep Learning）链路的测试。

1）引擎实时更新链路的测试

一个实时更新链路，从上游的数据源/数据表（TT/MetaQ/ODPS，阿里的消息中间件与离线数据表）读取数据，经过 Streaming 计算平台（Bayes 引擎、BLINK 等，阿里的实时计算平台）的实时计算任务处理产出引擎可以接受的更新消息，引擎在收到此类消息之后再做数据的更新操作。

这个链路主要验证的点在于：

• 数据的正确性验证

• 数据的一致性验证

• 数据的时效性验证

• 数据的并发性能测试

如何解决这几个问题？我们使用了流式数据实时对比、全量对比来解决数据的正确性和一致性验证的问题；数据的时效性更多地依赖计算平台底层的资源来保证毫秒级别的更新速度，通过记录更新时间戳来验证更新的时效性；性能测试通过伪造上游数据和流量复制来验证整个链路的响应时间和并发处理能力。

2）模型实时更新链路的测试

最近两年，Online Deep Learning（ODL）逐渐兴起，用户实时行为特征数据也需要实时地训练到模型之中，在 10-15 分钟的时间间隔里，在线服务的模型会被更新替代，留给模型验证的时间最多只有 10 分钟的时间，而这成为了 ODL 带来的质量挑战。

为了解决这个问题，我们使用了两种方法。

第一种方法是建立 ODL 全链路质量指标监控体系，这里的链路是指从样本构建到在线预测的全链路，包括样本域的指标校验和训练域指标校验。指标选取上主要看是否跟效果相关联，例如对于 ctr 预估方向，可以计算测试集上的 auc、gauc（Group auc，分组后的 auc）、score_avg（模型打分均值）等指标，甚至计算 train_auc&test_auc，pctr&actual_ctr 之间的差值（前者看是否过拟合，后者看打分准度）是不是在一个合理的范围内。

这里的关键点是测试集的选取。我们建议测试集除了取下一个时间窗口的数据（用未见的数据测试模型的泛化性能），还可以包含从过去一段时间（比如一周）的数据里面随机抽样的一部分数据（用已见但全面的数据测试模型是否跑偏）。这样可以降低局部的异常测试样本对评估指标带来的扰动影响。

第二种方法是设计一个离线仿真的系统，模型正式上线之前，先在仿真环境模拟打分校验。简单来说就是把需要上线的模型，在线下测试环境利用线上流量，通过在线服务的组件打分模块进行一个提前的预打分，在这个打分过程中出现任何错误都算校验不通过，打分正常的模型再对分数进行均值和分布的校验，打分校验不通过会直接拒绝上线。

通过以上两种方案，结合样本与模型的监控与拦截，可以极大概率降低 ODL 的质量风险。

三、性能压测

对于由离线、在线两部分构成的 AI 系统，在线响应的是用户实时访问请求，对响应时间要求更高，因此，性能是在线系统的重点。离线的性能很大程度上取决于训练平台在计算资源方面的调度使用，我们一般通过简单的源头数据复制来做验证。

在线系统可分为读场景和写场景的性能测试，写场景的性能在第二部分实时更新链路的时效性部分已有介绍，这里主要讲一下在线系统读场景的性能容量测试。在线系统一般由二三十个不同的引擎模块组成，引擎里的数据 Data 与测试 Query 的不同都会极大的影响性能测试结果，同时由于维护线下的性能测试环境与线上环境的数据同步工作需要极大的代价，我们目前的策略都是选择在线上的某个生产集群里做性能容量测试。

对于可以处理几十万 QPS（Query Per Second）的在线系统，难点在于如何精准控制产生如此量级的并发 Query，使用简单的多线程或多进程的控制已经无法解决，我们在这里使用了一个爬山算法（梯度多伦迭代爬山法）来做流量的精准控制，背后是上百台的压力测试机器递增式地探测系统性能水位。

另外一个建设方向是整个压测流程的自动化以及执行上的无人值守，从基于场景的线上 Query 的自动选取、到压力生成、再到均值飘逸算法的系统自动化校验工作，整个压测流程会按照预设自动完成。并且，配合着集群之间的切流，可以做到白+黑（白天夜间）的日常压测，为线上水位和性能瓶颈的分析带来了极大的便利。

四、效果的测试与评估

效果的测试与评估是大数据应用算法的重头戏，由于算法效果涉及到搜索广告业务的直接受益（Revenue & GMV），我们在这个方向上也有比较大的投入，主要分为以下几个子方向。

1）特征与样本的质量与功效评估

从特征质量与特征效用两个角度出发，我们可以在特征指标计算中发现一些重要指标：缺失率占比、高频取值、分布变化、取值相关性等。在训练和评估过程中，大量中间指标与模型效果能产生因果关系，通过系统的分析建模张量、梯度、权重和更新量，能够对算法调优、问题定位起到辅助决策作用。并且，通过改进 AUC 算法，分析 ROC、PR、预估分布等更多评估指标，能够更全面的评估模型效果。

随着数据量级的增加，最近两年我们在建模和训练过程中使用了千亿参数、万亿样本，Graph Deep Learning 也进入百亿点千亿边的阶段，在如此浩瀚的数据海洋里，如何可视化特征样本以及各种指标就成为一个难点。

我们在 google 开源的 Tensorboard 的基础上做了大量的优化与改进，帮助算法工程师可视化数据指标、调试训练过程，同时在深度模型的可解释性上给予了较好的支持。

2）在线流量实验

算法项目在正式上线之前，模型需要在实验环境中引入真实的线上流量进行效果测试和调优。

在第一代基于 Google 分层实验架构的在线分层实验（原理 Google 论文“Overlapping Experiment Infrastructure More, Better, Faster Experimentation”）的基础上，我们在并发实验、参数管理、参数间相互覆盖、实验质量缺乏保障、实验调试能力缺失、实验扩展能力不足等方面做了很多的改进，极大地提升了流量的并发复用与安全机制，达到了真正的生产实验的目的。从效果看，通过在线实验平台引入的真实流量的验证，使得模型的效果质量得到极大的保障。

3）数据效果评测

数据效果评测主要分为两部分：相关性评测与效果评测。

相关性是相关性模型的重要评估指标，我们主要通过数据评测来解决，通过对搜索展示结果的指标评测，可以得到每次搜索结果的相关性分数。细分指标包括：经典衡量指标 CSAT(Customer Satisfaction，包括非常满意、满意、一般、不满意、非常不满意)、净推荐值 NPS(Net Promoter Score，由贝恩咨询企业客户忠诚度业务的创始人 Fred Reichheld 在 2003 提出，它通过测量用户的推荐意愿，从而了解用户的忠诚度)、CES(Customer Effort Score，“客户费力度”是让用户评价使用某产品/服务来解决问题的困难程度。)、HEART 框架（来源于 Google，从愉悦度 Happiness、Engagement 参与度、Adoption 接受度、Retention 留存率、Task success 任务完成度）。

效果评估方面，我们采用了数据统计与分析的方法。在一个算法模型真正全量投入服务之前，我们需要准确地验证这个模型的服务效果。除了前面介绍的离在线对比之外，我们需要更加客观的数据指标来加以佐证。这里我们采用了真实流量的 AB 实验测试方法，给即将发布的模型导入线上 5%的流量，评估这 5%流量和基准桶的效果对比，从用户体验（相关性）、平台收益、客户价值三个维度做各自实际指标的分析，根据用户的相关性评测结果、平台的收入或者 GMV、客户的 ROI 等几个方面来观测一个新模型对于买家、平台、卖家的潜在影响到底是什么，并给最终的业务决策提供必要的数据支撑。当流量从 5%增加到 10%、20%，甚至 50%后，无论是功能问题、还是性能的问题，甚至是效果的问题都会被探测到。这种方法进一步降低了重大风险的发生，这是一个数据统计分析与技术的融合的方案，与本文所介绍的其他技术方法不同，比较独特，但效果甚佳。

五、线上稳定性

与其他业务的稳定性建设类似，线上稳定性也是通过发布三板斧（灰度、监控、回滚）来解决发布过程的质量，通过线上的容灾演练、故障注入与演练、安全红蓝对抗攻防来提升系统线上的稳定性和可用性。

在 AIOps 和 Service Mesh 为基础的运维管控方向上，我们正在向着智能运维、数据透视分析、自动切流、自动扩缩容等方向努力。我们预测结合 Service Mesh 技术理念在 C++在线服务的演进，系统会具备对业务应用无侵入的流量标定及变更标定的能力，也就能够实现流量调度能力和隔离的能力。

另外，红蓝攻防也将进一步发展，自动化、流程化将逐步成为混沌工程实施的标准形式。由于这一部分尚处于起步阶段，这里不再过多介绍还没有实现的内容，但我们判定这个方向大有可为，与传统运维工作不同，更接近 Google 的 SRE（Site Reliability Engineering）理念。

六、AI 应用的工程效能

AI 应用的工程效能主要是解决在测试阶段和研发阶段提升效率的问题，这个方向上我们以 DevOps 工具链建设为主，包括开发、测试、工程发布、模型发布（模型 debug 定位）、客户反馈（体感评估、众测、客户问题 debug）整个研发闭环所使用到的工具方面的建设。

在我们设想的 DevOps 的场景下，开发同学通过使用这些工具可以独立完成需求的开发测试发布及客户反馈的处理。鉴于这个方向与测试本身关系不大，篇幅原因，这里也略过。

相关阅读：

大数据应用的测试发展之路（一）