混沌测试方法、电子设备及介质与流程

1.本发明涉及测试技术领域，具体提供一种混沌测试方法、电子设备及介质。


背景技术：

2.随着云开发的重点转移到容器，容器相关技术已经变得大受欢迎，例如自从k8s(即kubernetes)开源后，许多厂商已经开始基于k8s发展业务或者二次开发k8s封装自身的平台从而来部署自身的业务，同时k8s+容器化技术已经逐渐普及，许多类似生产或者测试等环境已经开始上云。
3.在k8s的使用过程中，该分布式系统很容易产生不可预知的问题，从而阻碍业务产品的运行。而现有的很多业务产品都是要求服务能够持续运行的，即使出现问题也需要在规定的时间内自行恢复。k8s如果在使用中产生较多运行问题则无法维持服务的高可用性，进而增加用户的时间成本，也影响用户的使用体验。
4.相应地，本领域需要一种新的混沌测试方法来解决上述问题。


技术实现要素：

5.本发明旨在解决上述技术问题，即解决现有容器技术在使用中无法维持服务的高可用性、增加了用户时间成本进而影响用户体验的问题。
6.为了实现上述目的，在第一方面，本发明提供一种混沌测试方法，所述方法包含以下步骤：
7.s1、基于混沌测试平台，开启待测试服务的混沌测试；
8.s2、获取所述混沌测试中的测试问题；
9.s3、判断所述测试问题是否被修复并且当所述测试问题未被修复时判断是否修改测试指标；
10.s4、基于是否修改所述测试指标的判断结果，控制所述待测试服务执行相应的测试操作，直至所述测试问题被修复。
11.在上述混沌测试方法的可选技术方案中，“基于混沌测试平台，开启待测试服务的混沌测试”的步骤包括：
12.基于所述混沌测试平台以及监控工具开启所述待测试服务的混沌测试，其中所述监控工具至少包括dashboard。
13.在上述混沌测试方法的可选技术方案中，“判断所述测试问题是否被修复”的步骤包括：
14.控制所述待测试服务基于所述测试问题执行相应优化操作；
15.当完成所述相应优化操作之后，判断所述测试问题是否被修复。
16.在上述混沌测试方法的可选技术方案中，“基于是否修改所述测试指标的判断结果，控制所述待测试服务执行相应的测试操作”的步骤包括：
17.当判定为修改所述测试指标时，在完成所述测试指标的修改后控制所述待测试服
务基于修改后的测试指标返回步骤s1；
18.当判定为不修改所述测试指标时，控制所述待测试服务基于所述测试指标返回步骤s3。
19.在上述混沌测试方法的可选技术方案中，所述判断所述测试问题是否被修复之后，所述方法还包括：
20.当判定所述测试问题被修复时，结束所述待测试服务的混沌测试。
21.在上述混沌测试方法的可选技术方案中，所述基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：
22.获取测试实施方案，其中所述测试实施方案至少包括所述测试指标。
23.在上述混沌测试方法的可选技术方案中，所述基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：
24.基于所述待测试服务选择所述混沌测试平台并基于yaml部署所述混沌测试平台，其中所述混沌测试平台至少包括chaosmesh。
25.在上述混沌测试方法的可选技术方案中，所述基于所述待测试服务选择所述混沌测试平台之前，所述方法还包括：
26.获取混沌测试方案，其中所述混沌测试方案至少包括测试范围以及所述待测试服务。
27.在第二方面，本发明还提供了一种电子设备，所述设备包括存储器和处理器，所述存储器中存储有机器可执行指令，当所述机器可执行指令被所述处理器执行时，使得所述设备能实现如上述中任一项所述的混沌测试方法。
28.在第三方面，本发明还提供了一种可读存储介质，所述可读存储介质中存储有多条程序代码，所述程序代码适于由处理器加载并运行以执行上述中任一项所述的混沌测试方法。
29.本领域技术人员能够理解的是，在本发明的技术方案中通过s1、基于混沌测试平台，开启待测试服务的混沌测试；s2、获取混沌测试中的测试问题；s3、判断测试问题是否被修复并且当测试问题未被修复时判断是否修改测试指标；s4、基于是否修改测试指标的判断结果，控制待测试服务执行相应的测试操作，直至测试问题被修复。这样的设置能够验证待测试服务在各类异常状态下的处理策略，便于针对性地对待测试服务进行加固以及防范，从而维持待测试服务的高可用性，降低用户的时间成本，提升用户的使用体验。
30.进一步地，基于混沌测试平台，开启待测试服务的混沌测试的步骤包括：基于混沌测试平台以及监控工具开启待测试服务的混沌测试，其中监控工具至少包括dashboard。这样的设置能够让待测试服务的测试更加直观，从而便于了解待测试服务在不同的异常状况下的运行情况，进一步增强待测试服务的健壮性。
附图说明
31.参照附图，本发明的公开内容将变得更易理解。本领域技术人员容易理解的是：这些附图仅仅用于说明的目的，而并非意在对本发明的保护范围组成限制。此外，图中类似的数字用以表示类似的部件，其中：
32.图1是根据本发明的一个实施例的混沌测试方法的主要步骤流程示意图；
33.图2是根据本发明的一个实施例的判断测试问题是否被修复的主要步骤流程示意图；
34.图3是根据本发明的一个实施例的控制待测试服务执行相应的测试操作的主要步骤流程示意图；
35.图4是根据本发明的另一个实施例的混沌测试方法的详细步骤流程示意图；
36.图5是用于执行本发明的混沌测试方法的电子设备的主要结构框图示意图。
具体实施方式
37.下面参照附图来描述本发明的一些实施方式。本领域技术人员应当理解的是，这些实施方式仅仅用于解释本发明的技术原理，并非旨在限制本发明的保护范围。
38.在本发明的描述中，“模块”、“处理器”可以包括硬件、软件或者两者的组合。一个模块可以包括硬件电路，各种合适的感应器，通信端口，存储器，也可以包括软件部分，比如程序代码，也可以是软件和硬件的组合。处理器可以是中央处理器、微处理器、图像处理器、数字信号处理器或者其他任何合适的处理器。处理器具有数据和/或信号处理功能。处理器可以以软件方式实现、硬件方式实现或者二者结合方式实现。非暂时性的计算机可读存储介质包括任何合适的可存储程序代码的介质，比如磁碟、硬盘、光碟、闪存、只读存储器、随机存取存储器等等。术语“a和/或b”表示所有可能的a与b的组合，比如只是a、只是b或者a和b。术语“至少一个a或b”或者“a和b中的至少一个”含义与“a和/或b”类似，可以包括只是a、只是b或者a和b。单数形式的术语“一个”、“这个”也可以包含复数形式。
39.混沌测试是一种可实验的、基于系统的方法来处理大规模分布式系统中的混乱问题的方式。通过不断试验，了解系统实际能承受的韧性边界并建立信心，同时通过不同的试验方法和目的，观察分布式系统的行为和反应，从而尽早揭露系统的弱点。因此针对背景技术中的现有容器技术在使用中无法维持服务的高可用性、增加了用户时间成本进而影响用户体验的问题，本发明提供了一种混沌测试方法。
40.参阅附图1，图1是根据本发明的一个实施例的混沌测试方法的主要步骤流程示意图。如图1所示，本发明的混沌测试方法包含以下步骤：
41.步骤s101：基于混沌测试平台，开启待测试服务的混沌测试。
42.在一些实施例中，基于混沌测试平台，开启待测试服务的混沌测试包括：基于混沌测试平台以及监控工具开启待测试服务的混沌测试，其中监控工具至少包括dashboard。具体来说，dashboard是商业智能仪表盘(businessintelligencedashboard，bidashboard)的简称，它是一般商业智能都拥有的实现数据可视化的模块，是向企业展示度量信息和关键业务指标(kpi)现状的数据虚拟化工具。通过基于混沌测试平台以及监控工具开启待测试服务的混沌测试，能够让待测试服务的测试更加直观，从而便于了解待测试服务在不同的异常状况下的运行情况，进一步增强待测试服务的健壮性。
43.步骤s102：获取混沌测试中的测试问题。
44.具体来说，在混沌测试中控制待测试服务提交测试问题并对该测试问题进行跟踪。
45.步骤s103：判断测试问题是否被修复并且当测试问题未被修复时判断是否修改测试指标。
46.参阅附图2，图2是根据本发明的一个实施例的判断测试问题是否被修复的主要步骤流程示意图。如图2所示，在一些实施例中，判断测试问题是否被修复包括以下步骤：
47.步骤1031：控制待测试服务基于测试问题执行相应优化操作。
48.步骤1032：当完成相应优化操作之后，判断测试问题是否被修复。
49.具体来说，相应优化操作可以为从技术角度进行开发优化，也可以为从环境角度来进行修复。
50.步骤s104：基于是否修改测试指标的判断结果，控制待测试服务执行相应的测试操作，直至测试问题被修复。
51.基于上述步骤s101至s104，本发明通过步骤s101：基于混沌测试平台，开启待测试服务的混沌测试；步骤s102：获取混沌测试中的测试问题；步骤s103：判断测试问题是否被修复并且当测试问题未被修复时判断是否修改测试指标；步骤s104：基于是否修改测试指标的判断结果，控制待测试服务执行相应的测试操作，直至测试问题被修复。这样的设置能够验证待测试服务在各类异常状态下的处理策略，便于针对性地对待测试服务进行加固以及防范，从而维持待测试服务的高可用性，降低用户的时间成本，提升用户的使用体验。
52.参阅附图3，图3是根据本发明的一个实施例的控制待测试服务执行相应的测试操作的主要步骤流程示意图。如图3所示，在一些实施例中，基于是否修改测试指标的判断结果，控制待测试服务执行相应的测试操作包括以下步骤：
53.步骤s1041：当判定为修改测试指标时，在完成测试指标的修改后控制待测试服务基于修改后的测试指标返回步骤s101。
54.步骤s1042：当判定为不修改测试指标时，控制待测试服务基于测试指标返回步骤s103。
55.具体来说，测试指标在一定程度上表征了测试问题的难度，当待测试服务在现有测试指标的基础上未完成测试问题的修复时，需要判断一下是否对测试指标进行调整，即是否需要在现有测试难度的基础上降低测试难度。是否修改测试指标以及修改后的测试指标的设置可以由开发运维测试及产品\项目经理共同探讨决定；也可以在实施混沌测试之前做好预设，从而在混沌测试中控制待测试服务按照预设的方式进行测试即可。
56.示例性地，测试指标可以为修复某一测试问题的时长设置，例如设置为3分钟内完成测试问题a的修复。若测试问题a未能在3分钟完成修复，则表示测试问题a未被修复，从而需要判断是否对现有的测试指标进行修改。若测试问题a只有在3分钟内完成修复才能将对运行所造成的影响控制在预设的范围内，则不允许修改测试指标；若设置测试问题a在5分钟内完成修复也能够将对运行所造成的影响控制在预设的范围内，则允许将测试指标由在3分钟内完成测试问题a的修复修改为在5分钟内完成测试问题a的修复。或者，尽管测试问题a只有在3分钟内完成修复才能将对运行所造成的影响控制在预设的范围内，但是也可以允许修改测试指标，这样可以更准确的了解待测试服务在修复测试问题a时所需要的时长，进而便于更好地对待测试服务进行改进。以上所述的测试指标的设置方式以及是否修改测试指标的设置方式等都只是作为示例性说明，在实际应用中可以根据实际需要来进行选择。
57.在一些实施例中，判断测试问题是否被修复之后，所述方法还包括：当判定测试问题被修复时，结束待测试服务的混沌测试。即若测试问题未被修复才需要考虑是否进一步
的对测试指标进行修改；若测试问题已被修复，则无需考虑是否对修改指标进行修改，而是直接结束待测试服务的混沌测试。
58.在一些实施例中，基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：获取混沌测试方案，其中混沌测试方案至少包括测试范围以及待测试服务。
59.具体来说，在分布式系统中部署有多个服务，但并不是每一个服务都需要进行混沌测试，因此需要在实施混沌测试之前确定需要进行混沌测试的服务并将需要进行混沌测试的服务称为待测试服务。混沌测试可以对服务故障、pod类故障、进程故障、网络故障、压力注入、文件系统注入、中间件故障、核心业务链故障以及物理机故障等等多种故障进行测试，但并不是每一个待测试服务都需要进行所有故障种类的混沌测试，因此需要在实施混沌测试之前确定一下每一个待测试服务需要测试的故障种类，即待测试服务的测试范围。
60.在一些实施例中，获取混沌测试方案之后，以及基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：基于待测试服务选择混沌测试平台并基于yaml部署混沌测试平台，其中混沌测试平台至少包括chaosmesh。
61.具体来说，在选择混沌测试平台时需要选择适合待测试服务的混沌测试平台，从而更好地进行混沌测试。yaml是一个可读性高，并且用来表达数据序列化的格式。yaml参考了其他多种语言，包括：c语言、python、perl，并从xml、电子邮件的数据格式(rfc2822)中获得灵感。当前已经有数种编程语言或脚本语言支持(或者说解析)这种语言。chaosmesh是一个开源的云原生混沌工程平台，能够提供丰富的故障模拟类型，具有强大的故障场景编排能力，方便用户在开发测试中以及生产环境中模拟现实世界中可能出现的各类异常，帮助用户发现系统潜在的问题。chaosmesh提供完善的可视化操作，旨在降低用户进行混沌工程的门槛。用户可以方便地在webui界面上设计自己的混沌场景，以及监控混沌实验的运行状态。
62.在一些实施例中，基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：获取测试实施方案，其中测试实施方案至少包括测试指标。
63.在一些实施例中，基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：申请沙箱以及申请待测试服务的部署；获取待测试服务的测试版本，并在通过沙箱的申请以及待测试服务的部署申请后在沙箱中部署测试版本的待测试服务。具体来说，沙箱就是相当于在要运行的服务与系统之间建立一个隔离层，当运行服务的时候，就会将服务直接调入该隔层中，此后，服务对系统所做的修改，都会被映射到这个隔离层中，而不会真正地去触及系统。
64.需要说明的是，尽管这里描述的都是基于混沌测试平台以及自动化脚本来实现对待测试服务的混沌测试，但这并不是限制性的，本领域技术人员也可以基于混沌测试平台以及机器学习来实现对待测试服务的混沌测试，即建立待测试服务模拟模型，将大量规范的接口文档和接口测试用例作为训练样本来对待测试服务模拟模型进行训练，同时当有新增校验项或者优化校验项时再进一步地对待测试服务模拟模型进行训练，从而基于混沌测试平台以及待测试服务模拟模型来实现混沌测试。
65.参阅附图4，图4是根据本发明的另一个实施例的混沌测试方法的详细步骤流程示意图。如图4所示，本发明的混沌测试方法包含以下步骤：
66.步骤s201：获取混沌测试方案，其中混沌测试方案至少包括测试范围以及待测试
服务。
67.具体来说，测试范围可以包括服务故障测试、pod类故障测试、进程故障测试、网络故障测试、压力注入测试、文件系统注入测试、中间件故障测试、核心业务链故障测试以及物理机故障测试中的一种或多种，其可以根据待测试服务来进行确认。
68.步骤s202：申请沙箱以及申请待测试服务的部署。
69.步骤s203：获取待测试服务的测试版本，并在通过沙箱的申请以及待测试服务的部署申请后在沙箱中部署测试版本的待测试服务。
70.步骤s204：基于待测试服务选择混沌测试平台并基于yaml部署混沌测试平台，其中混沌测试平台至少包括chaosmesh。
71.步骤s205：获取测试实施方案，其中测试实施方案至少包括测试指标。
72.步骤s206：基于混沌测试平台以及监控工具开启待测试服务的混沌测试，其中监控工具至少包括dashboard。
73.具体来说，chaosmesh对待测试服务实施混沌测试的测试问题类型包括pod故障、网络攻击、文件系统注入、压力测试、内核故障、时钟偏移、dns故障、aws故障、gcp故障jvm应用故障、azure故障以及http故障中的一种或多种。
74.步骤s207：控制待测试服务获取混沌测试中的测试问题。
75.步骤s208：控制待测试服务基于测试问题执行相应优化操作。
76.步骤s209：当完成相应优化操作之后，判断测试问题是否被修复。
77.步骤s210：若测试问题未被修复则判断是否修改测试指标。
78.步骤s211：若测试问题已被修复则结束待测试服务的混沌测试。
79.步骤s212：当判定为修改测试指标时，在完成测试指标的修改后控制待测试服务基于修改后的测试指标返回步骤s206。
80.步骤s213：当判定为不修改测试指标时，控制待测试服务基于测试指标返回步骤s208。
81.需要指出的是，尽管上述实施例中将各个步骤按照特定的先后顺序进行了描述，但是本领域技术人员可以理解，为了实现本发明的效果，不同的步骤之间并非必须按照这样的顺序执行，其可以同时(并行)执行或以其他顺序执行，这些变化都在本发明的保护范围之内。
82.进一步，本发明还提供了一种电子设备。
83.参阅附图5，图5是用于执行本发明的混沌测试方法的电子设备的主要结构框图示意图。如图5所示，本发明还提供了一种用于执行本发明的混沌测试方法的电子设备，所述电子设备包括：处理器11、存储器12以及存储在该存储器12中并且可以在处理器11上运行的计算机程序13。处理器11执行计算机程序13时实现上述部分方法实施例中的步骤。
84.示例性地，处理器11可以是中央处理单元(central processingunit，cpu)，也可以是其它通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecific integratedcircuit，asic)、现场可编程门阵列(field-programmablegate array，fpga)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
85.示例性地，存储器12可以是电子设备的内部存储单元，例如，是电子设备的硬盘或内存；存储器12也可以是电子设备的外部存储设备，例如，在电子设备上配备的插接式硬盘，智能存储卡(smartmedia card，smc)，安全数字(securedigital，sd)卡，闪存卡(flashcard)等。进一步地，存储器12还可以既包括电子设备的内部存储单元也包括外部存储设备。存储器12用于存储计算机程序以及电子设备所需的其它程序和数据，存储器12还可以用于暂时地存储已经输出或者将要输出的数据。
86.在一些可能的实施方式中，电子设备可以包括多个处理器11和存储器12。而执行上述部分方法实施例的混沌测试方法的程序可以被分割成多段子程序，每段子程序分别可以由处理器11加载并运行以执行上述方法实施例的混沌测试方法的不同步骤。具体地，每段子程序可以分别存储在不同的存储器12中，每个处理器11可以被配置成用于执行一个或多个存储器12中的程序，以共同实现上述部分方法实施例的混沌测试方法，即每个处理器11分别执行上述部分方法实施例的混沌测试方法的不同步骤，来共同实现上述部分方法实施例的混沌测试方法。
87.上述多个处理器11可以是部署于同一个设备上的处理器，例如上述电子设备可以是由多个处理器组成的高性能设备，上述多个处理器11可以是该高性能设备上配置的处理器。此外，上述多个处理器11也可以是部署于不同设备上的处理器，例如上述电子设备可以是服务器集群，上述多个处理器11可以是服务器集群中不同服务器上的处理器。
88.电子设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备可以包括但不仅限于处理器11和存储器12。本领域技术人员可以理解，图5仅仅是电子设备的示例，并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如，电子设备还可以包括输入输出设备、网络接入设备、总线等。
89.进一步，本发明还提供了一种计算机可读存储介质。在根据本发明的一个计算机可读存储介质实施例中，计算机可读存储介质可以被配置成存储执行上述部分方法实施例的混沌测试方法的程序，该程序可以由处理器加载并运行以实现上述混沌测试方法。为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该计算机可读存储介质可以是包括各种电子设备形成的存储装置设备，可选的，本发明实施例中计算机可读存储介质是非暂时性的计算机可读存储介质。
90.进一步，应该理解的是，由于各个模块的设定仅仅是为了说明本发明的装置的功能单元，这些模块对应的物理器件可以是处理器本身，或者处理器中软件的一部分，硬件的一部分，或者软件和硬件结合的一部分。因此，图中的各个模块的数量仅仅是示意性的。
91.本领域技术人员能够理解的是，可以对装置中的各个模块进行适应性地拆分或合并。对具体模块的这种拆分或合并并不会导致技术方案偏离本发明的原理，因此，拆分或合并之后的技术方案都将落入本发明的保护范围内。
92.至此，已经结合附图所示的优选实施方式描述了本发明的技术方案，但是，本领域技术人员容易理解的是，本发明的保护范围显然不局限于这些具体实施方式。在不偏离本发明的原理的前提下，本领域技术人员可以对相关技术特征作出等同的更改或替换，这些更改或替换之后的技术方案都将落入本发明的保护范围之内。

技术特征：
1.一种混沌测试方法，其特征在于，所述方法包含以下步骤：s1、基于混沌测试平台，开启待测试服务的混沌测试；s2、获取所述混沌测试中的测试问题；s3、判断所述测试问题是否被修复并且当所述测试问题未被修复时判断是否修改测试指标；s4、基于是否修改所述测试指标的判断结果，控制所述待测试服务执行相应的测试操作，直至所述测试问题被修复。2.根据权利要求1所述的混沌测试方法，其特征在于，“基于混沌测试平台，开启待测试服务的混沌测试”的步骤包括：基于所述混沌测试平台以及监控工具开启所述待测试服务的混沌测试，其中所述监控工具至少包括dashboard。3.根据权利要求1所述的混沌测试方法，其特征在于，“判断所述测试问题是否被修复”的步骤包括：控制所述待测试服务基于所述测试问题执行相应优化操作；当完成所述相应优化操作之后，判断所述测试问题是否被修复。4.根据权利要求3所述的混沌测试方法，其特征在于，“基于是否修改所述测试指标的判断结果，控制所述待测试服务执行相应的测试操作”的步骤包括：当判定为修改所述测试指标时，在完成所述测试指标的修改后控制所述待测试服务基于修改后的测试指标返回步骤s1；当判定为不修改所述测试指标时，控制所述待测试服务基于所述测试指标返回步骤s3。5.根据权利要求1所述的混沌测试方法，其特征在于，所述判断所述测试问题是否被修复之后，所述方法还包括：当判定所述测试问题被修复时，结束所述待测试服务的混沌测试。6.根据权利要求1所述的混沌测试方法，其特征在于，所述基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：获取测试实施方案，其中所述测试实施方案至少包括所述测试指标。7.根据权利要求1所述的混沌测试方法，其特征在于，所述基于混沌测试平台，开启待测试服务的混沌测试之前，所述方法还包括：基于所述待测试服务选择所述混沌测试平台并基于yaml部署所述混沌测试平台，其中所述混沌测试平台至少包括chaosmesh。8.根据权利要求7所述的混沌测试方法，其特征在于，所述基于所述待测试服务选择所述混沌测试平台之前，所述方法还包括：获取混沌测试方案，其中所述混沌测试方案至少包括测试范围以及所述待测试服务。9.一种电子设备，其特征在于，所述设备包括存储器和处理器，所述存储器中存储有机器可执行指令，当所述机器可执行指令被所述处理器执行时，使得所述设备能实现如权利要求1至5中任一项所述的混沌测试方法。10.一种可读存储介质，其中存储有多条程序代码，其特征在于，所述程序代码适于由处理器加载并运行以执行权利要求1至5中任一项所述的混沌测试方法。

技术总结
本发明涉及测试技术领域，具体提供一种混沌测试方法、电子设备及介质，旨在解决现有容器技术在使用中无法维持服务的高可用性、增加了用户时间成本进而影响用户体验的问题。为此目的，本发明通过S1、基于混沌测试平台，开启待测试服务的混沌测试；S2、获取混沌测试中的测试问题；S3、判断测试问题是否被修复并且当测试问题未被修复时判断是否修改测试指标；S4、基于是否修改测试指标的判断结果，控制待测试服务执行相应的测试操作，直至测试问题被修复。这样的设置能够验证待测试服务在各类异常状态下的处理策略，便于针对性地对待测试服务进行加固以及防范，从而维持待测试服务的高可用性，降低用户的时间成本，提升用户的使用体验。验。验。


技术研发人员：贾广辽
受保护的技术使用者：江苏云从曦和人工智能有限公司
技术研发日：2023.07.17
技术公布日：2023/10/15