本申请涉及系统测试领域，尤其涉及一种健壮性测试过程的实现方法和装置。
背景技术：
：：健壮性测试(RobustnessTesting)又称为容错性测试(FaultToleranceTesting)，用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。为了使系统具有良好的健壮性，要求设计人员在做系统设计时必须周密细致，尤其要注意妥善地进行系统异常的处理。在当前的例如健壮性测试等类型的功能测试过程中，虽然有很多的异常用例，但是大部分都是通过构造无效或者非法请求，用单线程验证是否该异常用例是否被代码的异常逻辑捕获。部分测试用例会采用字节码注入的方式来动态地模拟故障，来观察系统或业务在某一故障条件下的表现。在当前的性能测试过程中，关注在不同的高并发下评估系统或业务的性能表现。线上集群演练通常是用系统命令(e.g.tc,iptables等)来模拟网络拥塞的情况，来观察该故障对线上生产系统的容错性、恢复性和性能的影响度。在实现本申请的过程中，本申请的申请人发现现有技术存在以下缺陷：在当前的功能测试过程中，很少会考虑在大并发的情况下，某类特定故障对业务的影响度，也基本没有把该系统维度的故障与链路业务维度的场景进行关联，更没有考虑对响应延迟故障的趋势进行建模分析。并且，线上集群演练通常是用系统命令(e.g.tc,iptables等)来模拟网络拥塞的情况，很难做到精确的、细粒度的延迟模拟(比如精确模拟某系统的某接口的响应延迟)，而且也基本没有考虑对响应延迟的趋势进行建模分析。基于上述的缺陷，如何更精确、全面的实现健壮性测试过程，成为了现有技术方案亟待解决的重要问题。技术实现要素：本申请提供了一种健壮性测试过程的实现方法和装置，能够解决现有技术中，无法更精确、全面的实现健壮性测试过程的问题。为达到上述目的，本申请实施例一方面提供了一种健壮性测试过程的实现方法，所述方法包括：启动业务压测进程，开始对当前业务在被测试系统中的执行过程施加测试压力；根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景；监控所述业务在所述被测试系统被注入所述延迟故障信息后的执行情况的数据信息，并进行量化处理；根据所述量化处理后的数据信息，生成所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果。优选的，所述预先配置的故障注入策略，至少包括：故障注入周期、故障注入的目标接口以及待注入的延迟故障信息。优选的，所述根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景，具体包括：根据所述故障注入周期，向所述被测试系统中与所述目标接口相对应的接口注入所述待注入的延迟故障信息，以模拟相应的故障场景。优选的，所述监控所述业务在所述被测试系统被注入所述延迟故障信息后的执行情况的数据信息，并进行量化处理，具体包括：将业务维度的监控数据与系统维度的响应延迟进行关联，按照如下公式，对故障i所对应的故障场景下，当前业务在所述被测试系统中的响应延迟情况TPS故障i进行量化统计：其中：TPS正常表示正常状态下的业务TPS；RPT正常表示正常状态下的业务平均响应时间；DELAY故障i表示在故障i所对应的故障场景下模拟的响应延迟；c表示被注入故障i的系统接口在该业务场景中的被调用的次数。优选的，所述根据所述量化处理后的数据信息，生成所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果，具体包括：将所述量化处理后的数据信息与预设的健壮性测试阈值相比较，根据比较结果，确定所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果。另一方面，本申请实施例还提出了一种健壮性测试装置，具体包括：测试模块，用于启动业务压测进程，开始对当前业务在被测试系统中的执行过程施加测试压力；故障注入模块，用于根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景；监控模块，用于监控所述业务在所述被测试系统被所述故障注入模块注入所述延迟故障信息后的执行情况的数据信息，并进行量化处理；处理模块，用于根据所述监控模块量化处理后的数据信息，生成所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果。优选的，所述预先配置的故障注入策略，至少包括：故障注入周期、故障注入的目标接口以及待注入的延迟故障信息。优选的，所述故障注入模块，具体用于：根据所述故障注入周期，向所述被测试系统中与所述目标接口相对应的接口注入所述待注入的延迟故障信息，以模拟相应的故障场景。优选的，所述监控模块，具体用于：将业务维度的监控数据与系统维度的响应延迟进行关联，按照如下公式，对故障i所对应的故障场景下，当前业务在所述被测试系统中的响应延迟情况TPS故障i进行量化统计：其中：TPS正常表示正常状态下的业务TPS；RPT正常表示正常状态下的业务平均响应时间；DELAY故障i表示在故障i所对应的故障场景下模拟的响应延迟；c表示被注入故障i的系统接口在该业务场景中的被调用的次数。优选的，所述处理模块，具体用于：将所述量化处理后的数据信息与预设的健壮性测试阈值相比较，根据比较结果，确定所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果。与现有技术相比，本申请所提出的技术方案至少具有以下优点：通过应用本申请实施例的技术方案，在健壮性测试过程中，根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景，并把业务维度监控数据与系统维度的响应延迟的趋势进行关联，通过建模来量化每种响应延迟类故障对业务链路健壮性的影响，通过这种基于响应延迟趋势的健壮性建模方法，既可以量化响应延迟(精细到接口粒度)对业务TPS的影响度，又可以在给定业务预期TPS的条件下，量化所能忍受的最差响应延迟(精细到接口粒度)。而且通过此模型，可以量化强弱依赖的系统接口对业务场景的影响度，并且建立健壮性基线用于健壮性回归。附图说明图1为本申请实施例提供的一种健壮性测试过程的实现方法的流程示意图；图2为本申请实施例提供的一种应用场景下的健壮性测试过程的实现方法的流程示意图；图3为本申请实施例提供的一种应用场景下的健壮性测试过程所生成的曲线示意图；图4为本申请实施例提供的一种应用场景下的健壮性测试过程两轮发布的健壮性回归结果的示意图；图5为本申请实施例提供的一种健壮性测试装置的结构示意图。具体实施方式如
背景技术：
：所述，在当前的功能测试过程中虽然有很多的异常用例，但是大部分都是通过构造无效或者非法请求，用单线程验证是否该异常用例是否被代码的异常逻辑捕获；很少会考虑在大并发的情况下，某类特定故障对业务的影响度。部分测试用例虽然采用了故障注入的方式来模拟异常情况，但基本没有把该系统维度的故障与链路业务维度的场景进行关联，更没有考虑对响应延迟故障的趋势进行建模分析。在性能测试过程中，大多数时候只是观察在不同的高并发下，系统或业务的性能表现，但是很少关注在高并发下的系统或者业务链路的容错性和恢复性表现。线上集群演练通常是用系统命令(e.g.tc,iptables等)来模拟网络拥塞的情况，很难做到精确的、细粒度的延迟模拟(比如精确模拟某系统的某接口的响应延迟)，而且也基本没有考虑对响应延迟的趋势进行建模分析。为了解决现有技术中存在的问题，本申请提出了一种健壮性测试过程的实现方法，在健壮性测试过程中对依赖系统的接口注入不同程度的响应延迟，并把业务维度监控数据与系统维度的响应延迟的趋势进行关联，通过建模来量化每种响应延迟类故障对业务链路健壮性的影响。。如图1所示，为本申请实施例提供的一种健壮性测试过程的实现方法的流程示意图，本方法包括：步骤S101、启动业务压测进程，开始对当前业务在被测试系统中的执行过程施加测试压力。步骤S102、根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景。在具体的应用场景中，所述预先配置的故障注入策略，至少包括以下配置信息：(1)故障注入周期，用于设置故障注入的间隔时间，为了测试的准确性，可以设置多次的故障注入，较小的间隔时间可以提高测试效率，获得更多的测试样本，提高测试的准确性，而较大的间隔时间则可以减少注入次数，简化测试过程，而且可以避免相邻注入过程之间出现过多的干扰。(2)故障注入的目标接口，用于确定进行故障的端口，通过本参数的配置，可以将故障影响的检测粒度精确到具体的端口，提高检测结果的准确性。(3)待注入的延迟故障信息，通过设置本参数，可以对系统进行多样化测试，检测不同故障场景下的故障影响，提高检测过程的测试范围，在本申请的实施例中，本参数的配置具体为不同的网络延迟时间。基于上述的配置，本步骤的具体实现方式为：根据所述故障注入周期，向所述被测试系统中与所述目标接口相对应的接口注入所述待注入的延迟故障信息，以模拟相应的故障场景。步骤S103、监控所述业务在所述被测试系统被注入所述延迟故障信息后的执行情况的数据信息，并进行量化处理。在现有技术中，没有把该系统维度的故障与链路业务维度的场景进行关联，因此，本步骤的处理过程就是为了克服这样的问题。具体的，本步骤将业务维度的监控数据与系统维度的响应延迟进行关联，按照如下公式，对故障i所对应的故障场景下，当前业务在所述被测试系统中的响应延迟情况TPS故障i进行量化统计：其中：TPS正常表示正常状态下的业务TPS；RPT正常表示正常状态下的业务平均响应时间；DELAY故障i表示在故障i所对应的故障场景下模拟的响应延迟；c表示被注入故障i的系统接口在该业务场景中的被调用的次数。步骤S104、根据所述量化处理后的数据信息，生成所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果。具体的，本步骤将所述量化处理后的数据信息与预设的健壮性测试阈值相比较，根据比较结果，确定所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果，从而对响应延迟故障的趋势进行建模分析。与现有技术相比，本申请实施例所提出的技术方案具有以下优点：通过应用本申请实施例的技术方案，在健壮性测试过程中，根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景，并把业务维度监控数据与系统维度的响应延迟的趋势进行关联，通过建模来量化每种响应延迟类故障对业务链路健壮性的影响，通过这种基于响应延迟趋势的健壮性建模方法，既可以量化响应延迟(精细到接口粒度)对业务TPS的影响度，又可以在给定业务预期TPS的条件下，量化所能忍受的最差响应延迟(精细到接口粒度)。而且通过此模型，可以量化强弱依赖的系统接口对业务场景的影响度，并且建立健壮性基线用于健壮性回归。下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。如图2所示，为本申请实施例提供的一种具体应用场景中的健壮性测试过程的实现方法的流程示意图，本方法包括：步骤S201、控制器向健壮性测试平台配置故障注入的定时任务。具体的控制器可以是自动运行的服务器，也可以是通过指令触发的处理终端，这样的变化并不会影响本申请的保护范围。在具体的应用场景中，故障注入操作是健壮性测试的基本单位。一个故障注入操作通常包括以下信息：故障名称、注入手段(字节码、脚本或其他)、被注入故障的系统域名、注入的响应延迟大小、抛出的异常类型等。在健壮性测试的过程中，测试人员可以从系统接口的粒度进行故障注入操作，来监控和评估该故障操作对业务场景的影响度。步骤S202、控制器指示健壮性测试平台启动业务压测进程。步骤S203、健壮性测试平台对线下业务集群中相应业务的执行过程施加测试压力。步骤S204、健壮性测试平台根据步骤S201中配置的定时任务，向线下业务集群中相应的端口注入故障。步骤S205、健壮性测试平台对线下业务集群进行监控，获取业务维度的监控数据与系统维度的响应延迟信息。步骤S206、健壮性测试平台对监控到的信息进行量化处理，生成线下业务集群相应的健壮性测试模型，并反馈给控制器。具体的量化方式参考了利特尔法则(Little'sLaw)，该法则在性能测试中的应用非常广泛，主要用于性能结果的验证，法则的公式如下所示：TPS＝U_concurrent/(T_response+T_think)其中：a)TPS是系统或业务的吞吐量；b)U_concurrent是压测的并发数；c)T_response是系统或业务的平均响应时间；d)T_think是平均思考时间。根据利特尔法则，只要保持压测并发数U_concurrent恒定，可以利用故障注入技术来动态地控制T_response+T_think，从而量化系统或者业务在某个故障延迟状态下的TPS表现。基于利特尔法则，只要保持健壮性测试中的并发数恒定，我们可以利用故障注入技术来动态的控制响应延迟，从而量化系统或者业务在某个响应延迟故障下的TPS表现。简化后(不考虑thinktime、不考虑应用的依赖超时限制)的响应延迟趋势建模的公式，如下所示：其中：TPS正常和RPT正常分别表示正常状态下的业务TPS和业务平均响应时间。在恒定并发数下，给定业务场景，这两个值就是常量。脚标“故障i”表示某种特定的故障操作。例如，某故障i可以被描述为“向系统S的接口A注入xxx毫秒的响应延迟”。DELAY故障i表示在某个特定故障i下模拟的响应延迟。在健壮性测试过程中该值是动态变化的变量。变量c表示被注入故障i的系统接口在该业务场景中的被调用的次数。TPS故障i表示在故障i条件下，该业务场景的TPS。基于此建模公式，测试人员可以在健壮性测试过程中从接口粒度注入不同程度的响应延迟故障，然后把业务维度的各项数据与响应延迟故障的趋势进行关联和建模，用于后续的健壮性分析。通过基于响应延迟趋势的建模，测试人员可以在高并发的健壮性测试过程中对关键系统的接口注入不同程度的响应延迟，并把业务维度监控数据与响应延迟的趋势进行建模，从而量化每种响应延迟类故障对业务链路健壮性的影响。为了进一步说明本申请实施例的处理效果，本实施例给出了在某业务链路高并发下健壮性测试过程中，通过对响应延迟趋势的建模，所生成的曲线示意图，具体如图3所示。从模型曲线可以得到以下结论：a)业务场景A，在系统S的接口A注入200ms时，达到最低TPS：7.4，属于不能忍受的范围内，需要业务owner改进。在该接口注入400ms时，业务场景TPS降为0，因此该接口对于业务场景A属于强依赖。b)业务场景B，在系统S的接口A注入200ms时，达到最低TPS：11.9，属于弱依赖。但最低TPS不在可以忍受的范围内，需要业务owner改进。c)业务场景C，在系统S的接口A注入200ms时，达到最低TPS：15.3，属于弱依赖。最低TPS在可以忍受的范围内。d)业务场景D不受系统S的接口A的故障延迟影响。根据该建模曲线，可以在某系统的某接口出现某延迟的情况下，预估某业务场景的TPS值；同理可以反推，如果不希望某业务TPS低于某值，该接口预期的响应延迟则不能高于某值。不仅能够区分强弱依赖关系，而且能够量化该系统维度的依赖对业务维度的影响度。进一步的，上述的每轮所获取到的健壮性测试的建模数据，还可以用于之后每轮发布的健壮性回归，比较同一种类型的故障操作，在不同版本间带来的健壮性差异。具体的，图4给出了本申请实施例中两轮发布的健壮性回归结果。比如在0713发布的时候，收银台渲染只调用1次系统S的A接口；但是在0813日常发布的时候，系统S的接口A在该场景中被调用了100次。尽管两次发布都是注入了同样的延迟，但是对业务场景的影响显然是不一样的。相比依赖测试，健壮性建模不仅能发现不同版本间依赖调用的变化，更能关联具体的业务场景，量化本轮依赖变化一旦出现故障对特定业务场景的影响度。与现有技术相比，本申请实施例所提出的技术方案具有以下优点：(1)基于响应延迟趋势的健壮性建模方法。通过精确模拟接口粒度的响应延迟，并与特定的业务场景建立关联进行趋势建模，从而能量化某系统某接口的某延迟对具体的业务的影响度。(2)量化响应延迟(精细到接口粒度)对业务TPS的影响度。该建模方法可以粗略的估计在某系统的某接口延迟达到多少毫秒的情况下，某具体业务场景的会达到的TPS值，以及该值是否在容忍范围内。从而为大促和其他重大项目提供参考建议和预警。(3)给定业务预期TPS，量化所能忍受的最差响应延迟(精细到接口粒度)。该建模方法在给定业务场景的预期TPS目标的情况下，可以反推某系统某接口的响应延迟的最高容忍度，否则会达不到既定业务目标，为业务线和架构提供参考建议。(4)量化强弱依赖对业务场景的影响度。该建模方法不仅能区分业务场景中的强弱依赖，并能量化各种系统维度的依赖对业务维度的影响度。(5)建立健壮性基线，用于健壮性回归。每轮发布中健壮性测试的建模数据可以建立基线，用于之后每轮发布的健壮性回归。相比依赖测试，健壮性基线的建立不仅能发现不同版本间依赖调用的变化，更能把某类特定故障类型关联到具体的业务场景，量化同一种类型的故障操作在不同版本间带来的健壮性差异。为了实现上述的技术方案，本申请实施例提供了一种健壮性测试装置，其结构示意图如图5所示，具体包括：测试模块51，用于启动业务压测进程，开始对当前业务在被测试系统中的执行过程施加测试压力；故障注入模块52，用于根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景；监控模块53，用于监控所述业务在所述被测试系统被所述故障注入模块52注入所述延迟故障信息后的执行情况的数据信息，并进行量化处理；处理模块54，用于根据所述监控模块53量化处理后的数据信息，生成所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果。优选的，所述预先配置的故障注入策略，至少包括：故障注入周期、故障注入的目标接口以及待注入的延迟故障信息。优选的，所述故障注入模块52，具体用于：根据所述故障注入周期，向所述被测试系统中与所述目标接口相对应的接口注入所述待注入的延迟故障信息，以模拟相应的故障场景。优选的，所述监控模块53，具体用于：将业务维度的监控数据与系统维度的响应延迟进行关联，按照如下公式，对故障i所对应的故障场景下，当前业务在所述被测试系统中的响应延迟情况TPS故障i进行量化统计：其中：TPS正常表示正常状态下的业务TPS；RPT正常表示正常状态下的业务平均响应时间；DELAY故障i表示在故障i所对应的故障场景下模拟的响应延迟；c表示被注入故障i的系统接口在该业务场景中的被调用的次数。优选的，所述处理模块54，具体用于：将所述量化处理后的数据信息与预设的健壮性测试阈值相比较，根据比较结果，确定所述被测试系统中的所述业务在所述故障场景下的健壮性测试结果。与现有技术相比，本申请实施例所提出的技术方案具有以下优点：通过应用本申请实施例的技术方案，在健壮性测试过程中，根据预先配置的故障注入策略，向所述被测试系统注入相应的延迟故障信息，以模拟相应的故障场景，并把业务维度监控数据与系统维度的响应延迟的趋势进行关联，通过建模来量化每种响应延迟类故障对业务链路健壮性的影响，通过这种基于响应延迟趋势的健壮性建模方法，既可以量化响应延迟(精细到接口粒度)对业务TPS的影响度，又可以在给定业务预期TPS的条件下，量化所能忍受的最差响应延迟(精细到接口粒度)。而且通过此模型，可以量化强弱依赖的系统接口对业务场景的影响度，并且建立健壮性基线用于健壮性回归。本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备(可以是手机，个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。以上所述仅是本申请的优选实施方式，应当指出，对于本
技术领域：
：的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本申请的保护范围。当前第1页1 2 3 当前第1页1 2 3