简介更复杂。产品量的增长对质量的要求越来越高。为了达到更高的质量要求，必须想方设法加大测试的强度，但采用传统的手动编写测试用例来自动化回归的方法成本太高。近年来，人工智能技术在越来越多的领域发挥着越来越重要的作用。在腾讯内部，我们一直保持着对新技术的好奇心，积极学习并将其应用到日常工作中。本文作者为腾讯安全部高级系统测试工程师林俊科。拥有16年软件测试经验，对AI技术在测试领域的落地有大量研究。本文以安全防护产品为例，但该方法论适用于深度挖掘多种因素组合导致的BUG。下图是一个典型的流量攻击的防护流程：黑客对互联网上的业务服务器发起攻击，我们有流量检测设备来检测攻击。检测到攻击后，自动启动防护，将被攻击IP的流量导流到防御设备，清洗防御设备上的流量后，将正常流量重新转发到业务服务器。01安全产品测试痛点分析安全防护产品特点：1.黑客手段多样，更新速度快。产品既要对现网新的攻击方式做出快速反应，又不能误杀正常用户，所以产品防护策略有很多。下表显示了主策略文件中的配置项数量，加起来有二三百个，而且这个数量还在快速增长。一个版本的每一次迭代都会增加大量新的配置项，处理逻辑非常复杂。主策略配置文件中的策略项个数anti_*.conf50anti_*.conf147.conf11.conf11.conf10即使开发很用心，仍然无法保证各个功能高度内聚和低耦合。有时候还是难免原本不相关的配置项会相互影响。如果互不影响的开关之间存在不当影响，则可能导致切换策略后保护不可控。我们曾经有一个意外影响导致失败的例子。当时的故障是：一个保护UDP流量的配置项影响了HTTPS流量的保护功能，但是两个配置没有任何关系。因此，我们需要测试产品功能在各种策略组合下的稳定??性和可靠性。2、对于特定的流量，大部分流量都会受到特定的保护模块的保护。利用这个特性可以简化模型，我们可以掌握建模的主要特征，其他的保护细节可以暂时忽略。业界解决这种参数组合带来的问题主要是采用全对偶算法，将参数成对组合。生成的测试集可以覆盖任意两个变量的所有值组合，且组合数最少。从理论上讲，这组用例可以暴露出两个变量相互作用造成的所有缺陷。虽然这个算法生成的组合数量最少，但是如果加入一个新的参数重新生成组合，新的组合与之前的组合完全无关。所以当参数较少的时候，我们经常使用它来减少测试用例的数量，同时保持更好的测试覆盖率。但是一旦参数数量多了，每次都会产生新的组合，每次都要根据组合重新计算预期结果，整个过程会变得非常复杂。很难解决“不同配置下数百台交换机对特定流量的保护方式”的问题。在我们的项目组中，用例是手动添加的，用例是自动执行的。这样一来，每增加一个新的配置项，其实都很难保持完全的对偶性。比如假设现有的用例都是对偶的，现在增加一个新的配置项，而这个配置项只能取0和1两个值。为了保证所有的参数再次组合，需要在所有原有用例的基础上增加新的配置项，设置为0时测试一次，设置为1时再测试一次。每增加一个配置项，用例数就会增加一倍，用例的数量非常大。如果每次都产生新的组合，那么在新一代全双组合的情况下，150个配置开关只有130个左右的组合。增量法可以达到2^150种组合。02行业如何自动生成用例？业界是否有解决方案，可以用少量的组合生成新的组合，而无需手动重新计算预期结果？答案是肯定的。UML建模技术是用被测版本更新和维护模型，每一次测试都重新组织生成一个新的用例进行测试。该技术的核心价值在于：自动生成用例，用最少的用例最大化功能覆盖，最终更快更完整地测试版本。这种技术的缺点是：模型的维护复杂，很难发现设计缺陷（只是机械地遍历用例），没有从用户的角度来设计用例。03AI在前端页面测试领域的应用近年来，AI技术发展非常迅速，AI技术也和UML有相同的特点：喜欢建立模型。那么复杂的建模能否通过AI技术绕过呢？将用例作为一个整体进行协调，以用最少的用例实现最大的覆盖范围。还要避免手动计算预期结果。为了探索新技术在测试领域的应用，我快速扫描了AI的盲区，然后在进行更深入的研究时发现AI在测试领域的未来已经到来。业界已经有很多工具使用AI进行自动化测试，甚至用例都是自动设计的。对于前端页面，甚至有工具声称只要给出URL链接，测试人员只需要等待测试结果即可。类似的软件还有：茄子、appvanceIQ、SauceLabs等。通过分析发现，这些技术主要是利用AI计算机视觉技术识别页面上的所有按钮，根据每个页面上的按钮生成遍历树，然后根据遍历树自动遍历可能的路径（用户旅程）.以达到自动化设计用例和自动化测试的目的。腾讯的同事之前出过一本书《AI自动化测试》，里面详细介绍了AI在图像游戏和数据游戏上的测试。业界已有的这些技术很优秀，但主要用于前端页面的测试，后台测试还没有相应的技术。于是我们开始研究如何将AI技术应用到背景测试中。经过各种尝试，结合AI的特点，我们提出了一个大胆的想法：没有人的参与，机器是不可能理解人设计的业务逻辑的，而且像UML那样建立模型太重了，但人工智能非常擅长处理和分类数据。既然无法计算出预期的结果，那能不计算吗？测试套件只记录流量是如何处理的，记录后AI会根据流量和防护结果进行分类。归类后，按每个类型分析一下该类型的典型配置？然后手动检查典型配置下的流量处理方式是否合理。04探索AI在后台测试中的应用基于这些思路，我们很快制定了实施方案。我们的目标：以最小的成本提高多因素组合的覆盖率，深挖深层次的bug。该方案成功实施的理论基础是：基于测试理论，用最少的用例覆盖最多的场景。使用AI对各种场景下的响应进行分类和洞察。把这两块串起来是可行的。该方案的实现步骤如下：Step1：每增加一个新的配置项，基于全对偶算法重新生成配置。Step2：对每个配置使用典型的攻击方式，记录被测端的防御方式。Setp3：通过AI分析各种保护和配置之间的关系。找出各种保护方式最重要的配置项。Step4：检查各种保护方式最相关的N个配置是否符合预期设计？第一部分非常简单，可以根据测试理论生成完整的对偶组合。我花了半天时间才实现。为了合并多个配置文件中的配置项，我设计了配置项命名方式为配置项名@文件名。使用成对工具生成。合并后，使用脚本将其转换成配置文件。基于全对偶算法共生成了250个组合。选择具有27个典型特征的流量分别发起'GET'、'POST'、'PUT'、'DELETE'、'HEAD'、'OPTIONS'、'TRACE'、'CONNECT'请求。共有278=216种流量，这216种流量在250种配置下通过并记录保护方式，得到250216=54000个场景的保护记录。记录结果如下：分为3部分，第一部分是配置项的组合数据，第二部分是发送的流量名称，最后一栏是被测端使用的保护方式。一旦数据可用，就可以将其交给人工智能。但团队只有测试专家，没有AI专家。我们向腾讯内部的AI专家请教。AI专家在了解了我们的需求后认为是可行的，但是具体实现还是让我们很是头疼。因为AI领域的知识和测试领域的知识相差太大，从头学起这些知识就像读天书一样。但只要你肯动脑筋，多学点，方法总是多于困难的。我找到了一个适合AI初学者使用的数据挖掘工具。经过反复的学习和实践，我觉得这些组件都可以应用在我们的解决方案中。我建立的模型如下：PCA的全称是principalcauseanalysiscomponent，可以帮助我们找出N个对结果影响较大的配置项。配置项对结果的影响进行排序，输出为一维列表。开发设计中配置开关的处理顺序必须是网状的，参考这个结果即可。定量分析分类树对配置项的影响。我个人认为这个组件输出的信息更有价值。PCA分析结果如下。在我们的例子中，这条曲线还是比较平滑的，说明没有影响特别大的配置项。AI使用RANK组件分析的配置项影响结果，顺序与开发的设计流程图对齐，大致吻合。初步确认方案还是有些靠谱的。下图是通过分类树对运行结果进行分类的展示：下面用一个典型的例子来说明如何根据AI的介绍发现问题：AI对数据进行处理后得到了一个很大的分类树图，并且数据每条结果都会用颜色标注，如图，黄色、紫色、白色和绿色分别是四个结果相关的数据展示。其中，黄色区域的根节点一共代表了74条数据，表示保护方式为dropos_*。这个结果最相关的配置项：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识别不准确的问题。我们先记下这一点。框底部的配置项是与结果相关的子相关配置项。继续观察它的叶节点。我们特别注意每个叶节点的比例。本例中，当该配置项配置不同的值时，比例接近。结果的趋势也很明显，这是低耦合的信号。根据分类树显示的信息打开原始表，隐藏不相关的列，将相关的配置项放在一起。这个时候就可以看出问题了。根据问题场景对应的行号，找出对应的配置，在环境中重现问题，如图。问题重现后，配置如下：Expected：Linux下发的流量应该不符合上述策略，应该按预期转发。实测发现掉流量是因为os_**：这个例子说明在AI的引导下，可以成功发现特定场景下OS指纹功能误识别的可能性，也证明了使用AI分析数据的方法是可靠的。我认为人工智能对测试的核心价值在于将复杂的数据以可视化的方式呈现出来，让分析变得更简单。综上所述，该方法可以解决“目前存在但不多的多参数相互耦合导致的深层次bug”的痛点，但要解决这些问题，需要进行参数组合测试，解决成本为很高”。以较小的成本验证多个因素之间的耦合。为54,000个场景自动生成测试用例，运行时间为3.5天。分析结果后，AI确认了2个开发错误。如果这54000个场景的用例是手工写的，按照现在每人每天30个用例计算，没有节假日需要4.9年才能完成。使用该方法后，生成组合只需几分钟，跑完需要3.5天。目前预计在探索阶段10天即可完成分析，大大提高了测试效率。关于腾讯WeTest腾讯WeTest是腾讯官方推出的一站式质量开放平台。十余年质量管理经验，致力于质量标准建设和产品质量提升。腾讯WeTest为移动开发者提供兼容性测试、云真机、性能测试、安全防护等优秀的研发工具，为100多个行业提供解决方案，覆盖产品研发各个阶段的测试需求开发运营，经历上千款产品。.金牌专家团队通过5大维度41项指标，高度保障您的产品质量。关注腾讯WeTest，了解更多WeTest测试干货腾讯品质开放平台-专注游戏提升品质
