导语
随着产品在线上的继续经营，产品在线上的规模越来越大，性能也越来越简单。产品体量的增长对品质要求越来越高。为了达到更高的品质要求，必然须要想方法减少测试的强度，但用传统的手工写用例自动化回归的形式老本过高。近年来，AI 技术在越来越多的畛域施展了越来越重要的作用。在腾讯外部，咱们也始终放弃着对新技术的好奇心，踊跃学习并利用于日常工作中。本文作者是腾讯安全部零碎测试高级工程师林军克，他领有 16 年的软件测试教训，对 AI 技术在测试畛域的落地颇有钻研。
本文以平安防护产品举例子，但此方法论实用于波及多因素组合导致的 BUG 的深度开掘。上面所示的图为典型的流量攻打的防护流程：黑客在互联网上对业务服务器发动攻打，咱们有检测流量的设施检测攻打，检测到攻打后主动启动防护，将被攻打 IP 的流量导流到进攻设施，在进攻设施上对流量进行荡涤后将失常流量从新转发到业务服务器。
01 平安产品测试的痛点剖析
平安防护产品特点：
1，黑产攻打手法多样且疾速翻新，须要产品能疾速响应现网的新攻打手法，但绝不能误杀失常用户，所以产品防护策略十分多。上面的表格显示次要策略文件中配置项的数量，加起来达到两三百个，且数量还在快速增长中。每迭代一个版本又会减少大量新配置项，解决逻辑非常复杂。
次要的策略配置文件 策略项置项数量
anti_*.conf 50
anti_*.conf 147
.conf 11
.conf 11
.conf 10
即使开发十分小心，实际上仍无奈确保每个性能都是高内聚低耦合的，有时候仍难免会呈现本来不相干的配置项间相互影响的状况。如果本不相互影响的开关间存在不应有的影响，可能导致切换策略后防护不可控。咱们外部已经呈现过一个非预期的影响导致故障的例子，过后的故障是：一个防护 UDP 流量的配置项影响了 HTTPS 流量的防护性能，然而这两个配置本来没有任何关系。因而咱们须要测试在各种组合的策略下，产品性能都可能稳固牢靠。
2，对于特定的流量，最终绝大部份流量会被某个特定的防护模块防爱护。利用这个特点能够简化模型，咱们能够抓住次要特色进行建模，其它的防护细节能够临时不关注。
业界解决这种参数组合导致的问题次要利用全对偶算法来对参数进行两两组合。生成的测试集能够用起码的组合数笼罩任意两个变量的所有取值组合。在实践上，该用例集可能裸露所有由两个变量独特作用而引发的缺点。尽管这种算法生成的组合数起码，但如果新增了新的参数从新生成组合，新的组合跟之前的组合齐全没有关联。所以当参数较少时，咱们常常用它来缩减用例数，同时放弃较好的测试笼罩。然而一旦参数量较多时，每次都生成全新的组合，每次都要依据组合从新计算预期后果，整个过程就将变得十分复杂。难以解决“数百个开关在不同的配置下对于特定流量的防护手法”的问题。
咱们项目组内目前都是用手工减少用例，自动化执行用例。在这种形式下，每次新增配置项都要放弃全对偶其实很难。例如，假如目前己有的用例都是全对偶的，当初新增一个配置项，这个配置项只能取 0 和 1 两个值。为了保征所有参数都组合一遍，那么必须在原来所有用例的根底上新增配置项取 0 时测一遍，取 1 时再测一遍。每减少一个配置项用例数翻一翻，用例数十分宏大。如果每次都全新生成组合的话，150 个配置开关在全新生成全对偶组合的状况下只有约 130 种组合。而增量形式可达 2^150 种组合。
02 业界是如何自动化生成用例的
那业界有没有既可能全新生成组合数少又不须要从新人工计算预期后果的计划呢？答案是有的。UML 建模技术就是随被测版本更新保护模型，每次测试均从新整体兼顾生成全新用例进行测试。这项技术最外围价值在于：自动化生成用例，用起码的用例数达到最大化性能笼罩，最终更快更全地测试版本。这项技术的劣势是：模型保护简单，对于设计缺点难以发现（用例只是机械地遍历），没有从用户的角度设计用例。
03AI 在前端页面测试畛域的利用
近年来，AI 技术的倒退十分地快，AI 技术也有跟 UML 同样的特点：喜爱建模型。所以是否通过 AI 技术绕过简单的建模？整体兼顾用例，用起码的用例数达到最大的笼罩。同时防止人工计算预期后果。
为了摸索新技术利用于测试畛域，我疾速扫了一下 AI 的盲，再进行更深刻的学习时发现，其实 AI 利用于测试畛域的将来已至。业界己经有不少工具在利用 AI 做自动化测试了，连用例都是自动化设计的。对于前端的页面，甚至有工具号称只有给定 URL 链接，测试人员只需坐等测试后果。相似的软件有：eggplant、appvance IQ、Sauce Labs 等等。
通过剖析发现这些技术次要利用 AI 的计算机视觉技术在页面上辨认所有的按纽，依据每一页上的按纽生成遍历树，再依据遍历树主动遍历可能经验的门路（user journey）。从而达到自动化设计用例，自动化测试的目标。
腾讯的共事之前出版过一本《AI 自动化测试》的书，外面具体介绍了 AI 在图像类游戏和数据类游戏上的测试。
业界已有的这些技术都很优良，但次要利用于前端页面的测试，后盾的测试还没有相应的技术。所以咱们开始钻研如何将 AI 技术利用于后盾测试，通过多种尝试，并联合 AI 的特点，咱们产生了一个大胆的想法：没有人工的参加，机器不可能了解人工设计的业务逻辑，而像 UML 那样构建模型又太过于重型，但 AI 是十分善于解决做数据分类的，既然算不进去预期后果是否不计算？测试套只记录流量如何解决的，记录后由 AI 依据流量及防护后果分类。分完类后再按各类剖析出此类的典型配置？而后人工审查典型配置下的流量处理形式是否正当。
04 摸索 AI 在后盾测试中的利用
依据这些想法，咱们很快就制订了实施方案。咱们的指标：用最小的代价晋升多种因素组合的笼罩，深度开掘深层次的 BUG。计划施行胜利的实践根底是：基于测试实践，用起码的用例数来笼罩最多的场景。利用 AI 对各种场景下的响应进行归类、洞察。这两块串起来是可行的。
打算施行步骤如下：
Step1：每次新增了新配置项都从新基于全对偶算法生成配置。
Step2：对每种配置用典型的攻打手法并记录被测端的防护形式。
Setp3：通过 AI 剖析各种防护跟配置间的关联。找出各种防护形式最次要的配置项。
Step4：查看各种防护形式最相干的 N 种配置是否合乎预期设计？
第一部份基于测试实践生成全对偶的组合非常简单。我花了半天工夫就施行了。为了对多个配置文件中的配置项做组合，我设计了用配置项名 @文件名的形式对配置项命名。应用 pairwise 工具生成。组合之后再用脚本转成配置文件。
基于全对偶算法一共生成了 250 种组合。选取 27 种典型特色的流量别离发动 ’GET’,’POST’,’PUT’,’DELETE’,’HEAD’,’OPTIONS’,’TRACE’,’CONNECT’ 申请。流量种数有 278=216 种，在 250 种配置下别离过这 216 种流量并记录下防护手法，失去 250216=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 是由腾讯官网推出的一站式品质开放平台。十余年品质治理教训，致力于质量标准建设、产品质量晋升。腾讯 WeTest 为挪动开发者提供兼容性测试、云真机、性能测试、平安防护等优良研发工具，为百余行业提供解决方案，笼罩产品在研发、经营各阶段的测试需要，历经千款产品磨砺。金牌专家团队，通过 5 大维度，41 项指标，360 度保障您的产品质量。
关注腾讯 WeTest，理解更多测试干货常识
WeTest 腾讯品质开放平台 - 专一游戏 晋升品质