随着产品在线上的持续运营，产品在线上的规模越来越大，功能也越来越复杂。产品体量的增长对质量要求越来越高。为了达到更高的质量要求，必然需要想办法增加测试的强度，但用传统的手工写用例自动化回归的方式成本过高。近年来，AI 技术在越来越多的领域发挥了越来越重要的作用。在腾讯内部，我们也一直保持着对新技术的好奇心，积极学习并应用于日常工作中。本文作者是腾讯安全部系统测试高级工程师林军克，他拥有 16 年的软件测试经验，对 AI 技术在测试领域的落地颇有研究。
本文以安全防护产品举例子，但此方法论适用于涉及多因素组合导致的 BUG 的深度挖掘。下面所示的图为典型的流量攻击的防护流程：黑客在互联网上对业务服务器发起攻击，我们有检测流量的设备检测攻击，检测到攻击后自动启动防护，将被攻击 IP 的流量导流到防御设备，在防御设备上对流量进行清洗后将正常流量重新转发到业务服务器。
安全防护产品特点：
1，黑产攻击手法多样且快速翻新，需要产品能快速响应现网的新攻击手法，但绝不能误杀正常用户，所以产品防护策略非常多。下面的表格显示主要策略文件中配置项的数量，加起来达到两三百个，且数量还在快速增长中。每迭代一个版本又会增加大量新配置项，处理逻辑非常复杂。
主要的策略配置文件 策略项置项数量
即便开发非常小心，实际上仍无法确保每个功能都是高内聚低耦合的，有时候仍难免会出现原本不相关的配置项间相互影响的情况。如果本不相互影响的开关间存在不应有的影响，可能导致切换策略后防护不可控。我们内部曾经出现过一个非预期的影响导致故障的例子，当时的故障是：一个防护 UDP 流量的配置项影响了 HTTPS 流量的防护功能，然而这两个配置原本没有任何关系。因此我们需要测试在各种组合的策略下，产品功能都能够稳定可靠。
2，对于特定的流量，最终绝大部份流量会被某个特定的防护模块防保护。利用这个特点可以简化模型，我们可以抓住主要特征进行建模，其它的防护细节可以暂时不关注。
业界解决这种参数组合导致的问题主要利用全对偶算法来对参数进行两两组合。生成的测试集可以用最少的组合数覆盖任意两个变量的所有取值组合。在理论上，该用例集能够暴露所有由两个变量共同作用而引发的缺陷。虽然这种算法生成的组合数最少，但如果新增了新的参数重新生成组合，新的组合跟之前的组合完全没有关联。所以当参数较少时，我们经常用它来缩减用例数，同时保持较好的测试覆盖。但是一旦参数量较多时，每次都生成全新的组合，每次都要根据组合重新计算预期结果，整个过程就将变得十分复杂。难以解决 “数百个开关在不同的配置下对于特定流量的防护手法” 的问题。
我们项目组内目前都是用手工增加用例，自动化执行用例。在这种方式下，每次新增配置项都要保持全对偶其实很难。例如，假设目前己有的用例都是全对偶的，现在新增一个配置项，这个配置项只能取 0 和 1 两个值。为了保征所有参数都组合一遍，那么必须在原来所有用例的基础上新增配置项取 0 时测一遍，取 1 时再测一遍。每增加一个配置项用例数翻一翻，用例数非常庞大。如果每次都全新生成组合的话，150 个配置开关在全新生成全对偶组合的情况下只有约 130 种组合。而增量方式可达 2150 种组合。
那业界有没有既能够全新生成组合数少又不需要重新人工计算预期结果的方案呢？答案是有的。UML 建模技术就是随被测版本更新维护模型，每次测试均重新整体统筹生成全新用例进行测试。这项技术最核心价值在于：自动化生成用例，用最少的用例数达到最大化功能覆盖，最终更快更全地测试版本。这项技术的劣势是：模型维护复杂，对于设计缺陷难以发现（用例只是机械地遍历），没有从用户的角度设计用例。
近年来，AI 技术的发展非常地快，AI 技术也有跟 UML 同样的特点：喜欢建模型。所以能否通过 AI 技术绕过复杂的建模？整体统筹用例，用最少的用例数达到最大的覆盖。同时避免人工计算预期结果。
为了探索新技术应用于测试领域，我快速扫了一下 AI 的盲，再进行更深入的学习时发现，其实 AI 应用于测试领域的未来已至。业界己经有不少工具在利用 AI 做自动化测试了，连用例都是自动化设计的。对于前端的页面，甚至有工具号称只要给定 URL 链接，测试人员只需坐等测试结果。类似的软件有：eggplant、appvance IQ、Sauce Labs 等等。
通过分析发现这些技术主要利用 AI 的计算机视觉技术在页面上识别所有的按纽，根据每一页上的按纽生成遍历树，再根据遍历树自动遍历可能经历的路径（user journey）。从而达到自动化设计用例，自动化测试的目的。
腾讯的同事之前出版过一本《AI 自动化测试》的书，里面详细介绍了 AI 在图像类游戏和数据类游戏上的测试。
业界已有的这些技术都很优秀，但主要应用于前端页面的测试，后台的测试还没有相应的技术。所以我们开始研究如何将 AI 技术应用于后台测试，经过多种尝试，并结合 AI 的特点，我们产生了一个大胆的想法：没有人工的参与，机器不可能理解人工设计的业务逻辑，而像 UML 那样构建模型又太过于重型，但 AI 是非常擅长处理做数据分类的，既然算不出来预期结果能否不计算？测试套只记录流量如何处理的，记录后由 AI 根据流量及防护结果分类。分完类后再按各类分析出此类的典型配置？然后人工审查典型配置下的流量处置方式是否合理。
根据这些想法，我们很快就制定了实施方案。我们的目标：用最小的代价提升多种因素组合的覆盖，深度挖掘深层次的 BUG。方案实施成功的理论基础是：基于测试理论，用最少的用例数来覆盖最多的场景。利用 AI 对各种场景下的响应进行归类、洞察。这两块串起来是可行的。
计划实施步骤如下：
Step1：每次新增了新配置项都重新基于全对偶算法生成配置。
Step2：对每种配置用典型的攻击手法并记录被测端的防护方式。
Setp3：通过 AI 分析各种防护跟配置间的关联。找出各种防护方式最主要的配置项。
Step4：检查各种防护方式最相关的 N 种配置是否符合预期设计？
第一部份基于测试理论生成全对偶的组合非常简单。我花了半天时间就实施了。为了对多个配置文件中的配置项做组合，我设计了用配置项名 @ 文件名的方式对配置项命名。使用 pairwise 工具生成。组合之后再用脚本转成配置文件。
基于全对偶算法一共生成了 250 种组合。选取 27 种典型特征的流量分别发起'GET','POST','PUT','DELETE','HEAD','OPTIONS','TRACE','CONNECT'请求。流量种数有 27*8=216 种，在 250 种配置下分别过这 216 种流量并记录下防护手法，得到 250*216=54000 种场景的防护记录。记录下来的结果是这样的：一共分 3 部份，第一部份为配置项组合数据，第二部份是所发流量的名字，最后一列是被测端所用的防护手法。
数据有了，可以交给 AI 了。但是团队只有测试专家，没有 AI 专家。我们就在腾讯内部找 AI 专家请教，AI 专家了解我们的需求后认为可行，但具体的落地仍然让我们十分困扰。因为 AI 领域的知识跟测试领域的知识差异太大了，从头开始学习这些知识仿佛阅读天书一般。
不过只要肯动脑多学习，方法总比困难多。我找到了一个 AI 小白也很容易上手的 data mining 工具，经过反复学习和实践，我认为这几个构件在我们的方案中可以应用。我建立的模型如下：
PCA 全称叫主成因分析构件，可以帮我们找出对结果影响很大的 N 个配置项，配置项对结果影响大小排序，输出是一个一维的列表。开发设计的配置开关处理顺序肯定是个网状的，这个结果参考一下就好。分类树对配置项影响定量分析。个人认为这个构件输出的信息比较有价值。
PCA 的分析结果是这样的。在我们的案例中，这条曲线挺平滑的，说明没有影响特别大的配置项。
AI 使用 RANK 构件分析出来的配置项对结果影响大小，跟开发的设计流程图对了下顺序，大致是可以对得上。初步印证了方案还是有点靠谱的。
下图是通过分类树对运行结果分类后的展示：
我们以一个典型的例子说明一下，如何根据 AI 的提引找到问题：AI 对数据处理后得到了一张很大的分类树图，对数据中每一种结果都会用一种颜色标记，如图中所示黄、紫、白绿分别是 4 种结果相关的数据展示。其中黄色区域的根节点上表示防护手法为 dropos_********的数据共 74 条。
该结果最相关配置项：
drop_*****@anti_***.conf。
左边叶子节点表示：
当 drop_*****@anti_***.conf 配置为 android、ios、linux 时。
防护手法为：dropos_*****。
右边叶子节点表示：
当 drop_*****@anti_***.con+f 配置为 0 时。
防护手法为：*********************_trans。
经合被测系统的防护逻辑，我看到这个地方是确实存在问题。这个功能是一个对特定 OS 指纹作丢弃的功能，因为我跑用例时只用 linux 系统发了流量，功能正常的情况下应只有 linux 下会丢弃。AI 却分析到当 drop_********@anti_******.conf 配置为 android、ios、win、linux 会丢弃，也就是说在配置为 android、ios、win 时有 OS 识别不准确的问题。我们先下记下这个点。
方框最下方的配置项是跟结果相关的次相关的配置项，继续观察其叶子结点，我们特别关注各叶子结点的比例，这个例子中这个配置项配置为不同值时，比例接近，结果倾向性也很明显，这是耦合性低的信号。
按照分类树展示的信息打开原始表格，隐藏掉不相关的列并把相关联的配置项放在一起，这个时候就可以看出问题所在。
按有问题场景对应的行号找出相应配置在环境上重现问题，重现问题如图。重现问题后配置如下：
预期：流量在 linux 下发的，不应匹配上策略，预期应被转发。实测发现流量因为 os_********** 被 drop 了：
这个例子说明在 AI 的指引下成功发现特定场景下 OS 指纹功能确实存在误识别的可能，也证明了用 AI 分析数据的方法是可靠的。我认为 AI 对于测试的核心价值在于把复杂的数据以可视化的方式呈现，使分析变得更加容易。
综上所述，本方法可以解决 “目前多个参数相互耦合导致的深层次 BUG 有但不多，但要解决这些问题需要做参数组合测试，解决的代价很大” 的痛点。用较小的代价验证多个因素间的耦合性。自动化生成了 54000 个场景的测试用例，耗时 3.5 天跑完，AI 分析跑出的结果后，己跟开发确认了其中 2 个 BUG。这 54000 个场景如果人工写用例，按目前每人天 30 个用例算，节假日无休也需要 4.9 年才能完成。使用此方法后，生成组合只需几分钟，3.5 天跑完，目前摸索阶段预计 10 天也可以分析完，大大提高了测试效率。
腾讯 WeTest 是由腾讯官方推出的一站式品质开放平台。十余年品质管理经验，致力于质量标准建设、产品质量提升。腾讯 WeTest 为移动开发者提供兼容性测试、云真机、性能测试、安全防护等优秀研发工具，为百余行业提供解决方案，覆盖产品在研发、运营各阶段的测试需求，历经千款产品磨砺。金牌专家团队，通过 5 大维度，41 项指标，360 度保障您的产品质量。
