基于故障注入的测试方法、装置、计算机设备和存储介质与流程

本申请涉及云测试领域，特别是涉及一种基于故障注入的测试方法、装置、计算机设备和存储介质。

背景技术：

随着计算机技术的迅速发展，出现了越来越多的应用、业务系统以及分布式服务体系等。随着服务化、微服务和持续集成的逐渐普及，从开发到线上的便捷性大幅提高。但在复杂的分布式服务体系中，故障发生的随机性和不可预测性也随之增加，对复杂系统稳定性的考验更大。为保证系统功能能够正常运行，通常需要对系统的相关功能等进行测试。因此出现了一些故障注入的测试方式。

现有的故障注入测试方式中，故障注入的测试数据来源较为单一，且需要根据测试需求进行人工配置。现有的这种方式存在测试效率较低以及测试精准度较低的问题。

技术实现要素：

基于此，有必要针对上述技术问题，提供一种能够有效提高测试效率和测试精准度的基于故障注入的测试方法、装置、计算机设备和存储介质。

一种基于故障注入的测试方法，所述方法包括：

获取基于待测业务的测试指令，所述待测业务包括业务信息和业务标识；

获取多个故障类型对应的预设参数文件，根据所述业务信息和所述预设参数文件配置多个故障实例；

对所述多个故障实例进行组合，得到所述待测业务的故障实例数据；

根据所述业务标识获取对应的业务接口数据，利用所述业务接口数据和所述故障实例数据生成所述待测业务的故障注入数据；

根据所述业务标识将所述故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据。

在其中一个实施例中，所述获取基于待测业务的测试指令之前，还包括：获取历史故障数据；对所述历史故障数据进行分类，得到多种故障类型；利用所述历史故障数据构建每种故障类型的故障场景数据；利用所述故障场景数据生成各个故障类型对应的预设参数文件。

在其中一个实施例中，所述根据所述业务信息和所述预设参数文件配置多个故障实例包括：根据所述业务信息确定所述待测业务的待测故障类型；获取所述待测故障类型对应的预设参数文件；获取所述业务信息的参数列表，所述参数列表包括业务指标参数；利用所述业务指标参数对所述预设参数文件进行配置，生成各个故障类型对应的故障实例。

在其中一个实施例中，所述对所述多个故障实例进行组合，得到所述待测业务的故障实例数据包括：调用测试编排引擎根据所述业务信息确定故障编排策略；根据所述故障编排策略对所述多个故障实例进行串联和组合，得到所述待测业务对应的故障案例数据。

在其中一个实施例中，所述根据所述业务标识将所述故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据包括：对所述故障注入数据分配相应的注入线程；通过所述注入线程根据所述业务标识将所述故障注入数据注入至相应的业务系统；利用所述故障注入数据在所述业务系统执行相应的测试任务，并生成测试结果数据。

在其中一个实施例中，所述方法还包括：获取预设监控指标数据；利用所述预设监控指标数据对所述测试结果数据进行分析，生成故障排查数据；所述故障排查数据用于对所述业务系统中相应的故障进行修复。

一种基于故障注入的测试装置，所述装置包括：

指令获取模块，用于获取基于待测业务的测试指令，所述待测业务包括业务信息和业务标识；

实例配置模块，用于获取多个故障类型对应的预设参数文件，根据所述业务信息和所述预设参数文件配置多个故障实例；对所述多个故障实例进行组合，得到所述待测业务的故障实例数据；

故障注入模块，用于根据所述业务标识获取对应的业务接口数据，利用所述业务接口数据和所述故障实例数据生成所述待测业务的故障注入数据；

故障测试模块，用于根据所述业务标识将所述故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据。

在其中一个实施例中，所述实例配置模块还用于根据所述业务信息确定所述待测业务的待测故障类型；获取所述待测故障类型对应的预设参数文件；获取所述业务信息的参数列表，所述参数列表包括业务指标参数；利用所述业务指标参数对所述预设参数文件进行配置，生成各个故障类型对应的故障实例。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现本申请任意一个实施例中提供的基于故障注入的测试方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现本申请任意一个实施例中提供的基于故障注入的测试方法的步骤。

上述基于故障注入的测试方法、装置、计算机设备和存储介质，获取基于待测业务的测试指令后，获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例，并对多个故障实例进行组合，得到待测业务的故障实例数据。由此能够有效根据待测业务信息的维度获取到与待测业务信息相匹配且全面的故障实例数据。进而根据业务标识获取对应的业务接口数据，利用业务接口数据和故障实例数据生成待测业务的故障注入数据。根据业务标识将故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据。通过自动化配置与业务信息匹配的故障案例数据，由此能够快速有效地生成与业务信息相匹配且全面的故障案例数据，并智能地生成测试用例，从而有效提高了故障注入测试的测试效率和测试精准度。

附图说明

图1为一个实施例中基于故障注入的测试方法的应用场景图；

图2为一个实施例中基于故障注入的测试方法的流程示意图；

图3为一个实施例中基于分布式服务的测试系统的结构框图；

图4为一个实施例中构建预设参数文件步骤的流程示意图；

图5为另一个实施例中基于故障注入的测试方法的流程示意图；

图6为一个实施例中基于故障注入的测试装置的结构框图；

图7为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

云测试(cloudtesting)，是基于云计算的一种新型测试方案。服务商可以提供多种平台，一般用户在本地把自动化测试脚本编写好，然后上传到相应的平台，就可以在平台上运行自动化测试脚本。云测试提供一整套测试环境，测试人员利用虚拟桌面等手段登录到该测试环境，就可以立即展开测试。这将软硬件安装、环境配置、环境维护的代价转移给云测试提供者(公共云的经营者或私有云的维护团队)。在测试人员指定硬件配置、软件栈(操作系统、中间件、工具软件)、网络拓扑后，可以通过虚拟化技术创建一套新的测试环境。利用云测试方式，极大地减少了测试环境搭建时间，节省了成本。如机器和网络准备、操作系统安装、各种测试工具软件安装等都将节省，只需提前将需要的配置环境告之云测试服务商，到时间直接使用即可。由于是基于网络上的应用，当测试中遇到软件使用上等问题时，亦可获得云测试服务商远程快速支持，能够有效提高测试效率。

本申请提供的基于故障注入的测试方法，可以应用于如图1所示的应用环境中。其中，测试终端102通过网络与测试服务器104进行通信。测试服务器104获取测试终端102基于待测业务发送的测试指令，测试服务器104获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例，并对多个故障实例进行组合，得到待测业务的故障实例数据。测试服务器104根据业务标识获取对应的业务接口数据，利用业务接口数据和故障实例数据生成待测业务的故障注入数据。根据业务标识将故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据。其中，测试终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机和平板电脑，测试服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种基于故障注入的测试方法，以该方法应用于图1中的测试服务器为例进行说明，包括以下步骤：

步骤202，获取基于待测业务的测试指令，待测业务包括业务信息和业务标识。

其中，故障注入是指针对特定的故障模型，有意识的在目标系统中催出故障,加速其错误和失效的发生，通过分析系统对所注故障的回应信息，可以验证其容错和故障安全等信息。例如，可以通过混沌工程平台实现故障注入配置。混沌工程是指通过在生产环境中通过故障注入的方式注入测试问题，从而发现生产环境系统性弱点，并进行系统性改进的方法或手段。其目标是不断提升生产环境面对任何变更的可靠性，建立对系统抵御生产环境中失控条件的能力。例如chaosblade(一种开源混沌工程工具)混沌工程实验工具，支持的混沌实验场景不仅覆盖基础资源，如cpu满载、磁盘io高、网络延迟等。还包括运行在jvm(javavirtualmachine，java虚拟机)上的应用实验场景，如dubbo(一种开源服务框架)调用超时和调用异常、指定延迟或抛异常以及返回特定值等，还涉及容器相关的实验，如杀容器、杀pod(pod是创建或部署的最小单位)。

服务器在对业务系统进行测试的过程中，可以基于混沌工程的实验场景进行测试。测试人员可以通过对应的测试终端基于待测业务向测试服务器发送测试指令，测试指令中包括一个或多个业务标识，例如业务标识可以包括多个业务维度属性对应的业务标识信息。

步骤204，获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例。

其中，预设参数文件可以为预先配置的故障类型对应的案例模板，案例模板中包括多个故障参数信息等。故障实例表示针对业务信息进行配置得到的故障实验数据，用于对相应故障类型的故障进行测试。

例如，在分析复杂系统如何应对异常时，对系统中的服务注入通信故障，如超时、错误等，是一个故障注入的典型场景。随着系统测试需求增加，需要分析更多其他的非故障类的场景，如流量激增、资源竞争条件、拜占庭故障(例如性能差或有异常的节点发出有错误的响应、异常的行为、对调用者随机性的返回不同的响应，等等)、非计划中的或非正常组合的消息处理等等。因为如果一个面向公众用户的网站突然收到激增的流量，从而产生更多的收入，很难称之为故障，但仍需要分析系统在这种情况下如何实现针对性的测试。因此，故障测试可以通过对预先配置的故障案例实现破坏系统的故障点进行测试。

测试服务器获取到测试指令后，根据待测业务的业务信息获取多个故障类型对应的预设参数文件，并根据业务信息和预设参数文件配置多个故障类型对应的故障实例。其中，测试服务器中预先对多个故障点和对应的案例进行模板化配置，结合业务信息挖掘故障的广度和深度，从而得到多个故障类型对应的预设参数文件，以用于后续直接根据故障类型自动化获取配置好的案例模板进行配置，以利于故障案例收敛和注入配置。

步骤206，对多个故障实例进行组合，得到待测业务的故障实例数据。

其中，测试服务器在进行故障实例配置的过程中，还需要将多个类型的故障实例生成待测业务对应的完整的故障实例数据。测试实例数据也指针对待测业务的测试用例。测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

测试服务器进一步根据业务信息对多个故障实例进行组合，具体地，测试服务器可以对多个故障实例进行串联和组合，使得后续在测试过程中可以实现多个故障实例的串行和并行运行，以提高故障注入测试的效率和真实性。由此能够有效根据待测业务信息的维度获取到与待测业务信息相匹配且全面的故障实例数据，从而得到组合后的故障实例数据。

步骤208，根据业务标识获取对应的业务接口数据，利用业务接口数据和故障实例数据生成待测业务的故障注入数据。

步骤210，根据业务标识将故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据。

其中，业务接口数据是表示在各个业务系统间建立的数据接口库，用于保证系统间的数据交互。业务标识中还包括业务节点标识，业务节点标识可以为业务系统对应的业务系统标识，以用于将故障注入数据发送至对应的业务应用中。

测试服务器生成待测业务的故障实例数据后，进而根据业务标识获取对应的业务节点标识和业务接口数据，根据业务接口数据利用故障实例数据生成待测业务系统对应的故障注入数据。测试服务器则根据业务节点标识将故障注入数据注入至对应的业务系统中进行测试，以进行持续的自动化运行试验，并生成测试结果数据。通过自动化配置与业务信息匹配的故障案例数据，并根据业务属性标识结合业务数据，形成基于业务维度的故障注入数据，由此能够快速有效地生成与业务信息相匹配且全面的故障案例数据，从而有效提高了故障注入测试的测试效率和测试精准度。

在一个具体的实施例中，基于故障注入的测试方法可以应用于基于分布式服务的测试系统，如图3所示，为基于分布式服务的测试系统的结构框图。其中，分布式服务系统可以包括ares平台、服务治理平台、saltstackservice(架构集中化管理平台)、业务系统以及监控/警报系统。其中，分布式服务系统可以包括测试终端、测试服务器以及多个业务服务器等。测试终端用于测试人员配置案例模板和发起测试指令等操作。测试服务器用于根据测试指令和业务属性配置故障案例，并对故障案例进行串联和合并处理，并生成故障注入数据，进而将故障数据注入至相应的业务系统中。

例如，如图3所示的故障测试平台，pumba工具通过调用dockerapi(容器调用接口)的方式来实现container(容器)级别的相关攻击，包含随机kill(杀死一个或多个正在运行的容器)、stop(停止一个或多个正在运行的容器)、remove(移除一个或多个正在运行的容器)、pause(暂停一个或多个正在运行的容器)、网络状况模拟等，是在docker(容器)部署方式下攻击方式比较丰富的一种方案。例如具体还可以采用chaosblade(一种混沌实验工具)工具，除了基础的cpu、disk、i/o、network外，还支持docker、dubbo、jvm的攻击，同时支持攻击后迅速回滚，是在k8s部署方式下最优方案。在架构层面上，能够支持springcloud体系；在业务层面上，通过服务治理平台提供限流、熔断、mock(创建模拟对象)等功能实现业务接口层面的故障注入。为了提升故障注入工具的易用性，同时实现权限管控、大规模攻击、指令下发、历史记录、方案预演等必需功能，设计自动化混沌工程平台，借助于saltstack实现攻击指令下发，以应用为维度实现权限管控，并将最小攻击目标限定在单个应用上。

上述基于故障注入的测试方法中，测试服务器获取基于待测业务的测试指令后，获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例，并对多个故障实例进行组合，得到待测业务的故障实例数据。由此能够有效根据待测业务信息的维度获取到与待测业务信息相匹配且全面的故障实例数据。测试服务器进而根据业务标识获取对应的业务接口数据，利用业务接口数据和故障实例数据生成待测业务的故障注入数据。根据业务标识将故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据。通过自动化配置与业务信息匹配的故障案例数据，由此能够快速有效地生成与业务信息相匹配且全面的故障案例数据，并智能地生成测试用例，从而有效提高了故障注入测试的测试效率和测试精准度。

在一个实施例中，如图4所示，获取基于待测业务的测试指令之前，还包括构建多个故障类型对应的预设参数文件，具体包括以下步骤：

步骤402，获取历史故障数据。

步骤404，对历史故障数据进行分类，得到多种故障类型。

步骤406，利用历史故障数据构建每种故障类型的故障场景数据。

步骤408，利用故障场景数据生成各个故障类型对应的预设参数文件。

在进行故障注入测试之前，测试服务器可以获取大量真实的历史故障数据进行分析。具体地，测试服务器根据故障数据的属性对每个历史故障数据进行分类，得到多个故障类型。测试服务器进而构建多种故障类型对应的故障场景数据，以用于配置和生成多种故障类型对应的案例模板，进而构建得到包括各种故障类型的案例模板库，并生成每种故障类型对应的预设参数文件。通过预先构建案例模板后，在测试过程中就可以直接根据测试需求利用案例模板自动化配置相应的故障实例数据。

例如，将相关故障场景抽象为五大类：应用类、中间件类、存储类、基础设施类、业务特性。抽象的故障场景即为需要实现的故障注入能力。其中，应用类可以包括rpc服务、扩容缩容、服务迁移、api网关、mac、接口限流、内存占满等故障场景。中间件类可以包括nginx路由异常、请求异常、haproxy宕机、redis宕机、节点异常等故障场景。存储类包括数据库层的故障场景，可以包括数据库宕机、数据同步延迟、数据库阻塞、统计信息异常、索引失效、内存耗尽等故障场景。基础设施类可以包括虚拟机宕机、虚拟机资源耗尽、磁盘异常、网络异常、dns故障、防火墙禁止等故障场景。业务特性则包括具体的业务场景异常，例如业务流程错误、业务数据异常等故障场景。

在一个实施例中，根据业务信息和预设参数文件配置多个故障实例包括：根据业务信息确定待测业务的待测故障类型；获取待测故障类型对应的预设参数文件；获取业务信息的参数列表，参数列表包括业务指标参数；利用业务指标参数对预设参数文件进行配置，生成各个故障类型对应的故障实例。

其中，业务信息中包括了参数列表和业务属性，参数列表中包括了多个业务指标参数，例如可以包括多个业务维度属性对应的业务指标参数。

测试服务器获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例。具体地，测试服务器解析业务信息，得到业务信息对应的参数列表，参数列表包括了一些业务指标参数。测服务器进而根据业务信息确定待测业务的待测故障类型；获取待测故障类型对应的预设参数文件，并利用业务指标参数对预设参数文件进行配置，生成各个故障类型对应的故障实例。通过利用业务指标参数信息对多个案例模板进行配置，可以直接对多个故障类型的故障点和案例进行模板化配置，由此能够快速有效地根据业务参数进行自动化配置，从而有效生成多个业务维度的故障案例。

在一个实施例中，对多个故障实例进行组合，得到待测业务的故障实例数据包括：调用测试编排引擎根据业务信息确定故障编排策略；根据故障编排策略对多个故障实例进行串联和组合，得到待测业务对应的故障案例数据。

其中，测试编排引擎可以为一种工作流引擎，工作流引擎可以提供业务流程编辑器，是一种可视化的构件工具，可以用于快速构建业务流程。测试编排引擎还可以为微服务编排引擎，用于在分布式服务系统中对相应的业务工作流进行编排构建。

测试服务器根据业务信息和预设参数文件配置对应的多个故障实例后，调用预设的测试编排引擎，测试编排引擎根据业务指标参数确定故障编排策略。测试服务器进而通过流程编排引擎基于预设参数文件结合待测业务的业务信息将多个故障实例进行串联和组合，由此能够有效根据业务信息的业务维度获取到与待测业务信息相匹配且全面的故障实例数据，从而得到组合后的故障实例数据。通过流程编排引擎，将多个故障实例进行串联和组合，同时根据需求实现串行和并行的效果，提升自动化程度和故障注入的效率及真实性。

测试服务器组合得到多个故障实例数据后，根据每个故障实例数据对应的故障场景，合理设置线程数，对多个故障实例数据串行和并行运行，以提高故障实例数据处理效率。

其中，串行是指多个任务执行时，一个执行完再执行另一个。并行是指每个线程分配给独立的核心，线程同时运行。例如，在单cpu系统中，系统调度在某一时刻只能让一个线程运行，虽然这种调试机制有多种形式，要通过不断切换需要运行的线程让其运行。而在多cpu系统中，可以让两个以上的线程同时运行。使用多个线程可以在单个处理系统中实现更高的吞吐量，如果一个程序是单线程的，这个处理器在等待一个同步i/o操作完成的时候，他仍然是空闲的。在多线程系统中，当一个线程等待i/o的同时，其他的线程也可以执行。

在一个实施例中，如图5所示，提供了一种基于故障注入的测试方法，包括以下步骤：

步骤502，获取基于待测业务的测试指令，待测业务包括业务信息和业务标识。

步骤504，获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例。

步骤506，对多个故障实例进行组合，得到待测业务的故障实例数据。

步骤508，根据业务标识获取对应的业务接口数据，利用业务接口数据和故障实例数据生成待测业务的故障注入数据。

步骤510，对故障注入数据分配相应的注入线程。

步骤512，通过注入线程根据业务标识将故障注入数据注入至相应的业务系统。

步骤514，利用故障注入数据在业务系统执行相应的测试任务，并生成测试结果数据。

测试服务器获取基于待测业务的测试指令后，获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例，并对多个故障实例进行组合，得到待测业务的故障实例数据。由此能够有效根据待测业务信息的维度获取到与待测业务信息相匹配且全面的故障实例数据。测试服务器进而根据业务标识获取对应的业务接口数据，利用业务接口数据和故障实例数据生成待测业务的故障注入数据，并根据业务标识将故障注入数据注入至对应的业务系统中进行测试。

具体地，测试服务器价格呢故障注入数据注入至业务系统时，首先对故障注入数据分配相应的注入线程，通过注入线程根据业务标识将故障注入数据注入至相应的业务系统。测试服务器进而利用故障注入数据在业务系统执行相应的测试任务，其中，测试服务器可以直接执行业务系统中的测试任务，并生成测试结果数据，由此能够有效提高故障注入测试的处理效率。在另一种实施方式中，业务系统可以部署有相应的业务服务器，测试服务器将故障注入数据注入至相应的业务系统后，通过业务服务器执行业务系统中的测试任务，并生成测试结果数据，将测试结果数据返回给测试服务器。从而有效提高了故障注入测试的测试效率。

在一个实施例中，测试服务器将故障注入数据注入至业务系统中进行测试时，还可以利用故障注入数据生成故障注入插件，并以插件的形式在业务系统中进行故障测试。通过组合和自动化串联多个故障案例模板，实现统一配置下发，对单独的故障点和案例进行模板化设置，挖掘故障的广度和深度，以利于故障案例收敛和自动化效率提升。在生成故障注入数据时，结合业务数据，从而形成基于业务维度故障注入，规划化覆盖核心业务问题。通过以插件的形式注入故障数据，能够增强故障测试平台的可扩展性和通用性，从而能够有效提高故障测试的效率。

在一个实施例中，该方法还包括：获取预设监控指标数据；利用预设监控指标数据对测试结果数据进行分析，生成故障排查数据；故障排查数据用于对业务系统中相应的故障进行修复。

其中，预设监控指标数据是预先根据业务系统的业务信息的性能等指标配置的监控指标数据。用于对测试结果数据进行监控和比对分析。

测试服务器将故障注入数据发送至业务系统中进行测试运行，得到相应的测试结果数据后，测试服务器获取相应的测试结果数据，并进一步根据预设的监控指标对测试结果数据进行评估分析，生成故障排查数据。其中，故障排查数据中包括故障位置和故障信息，用于对业务系统中相应的故障进行修复，后续做持续性的验证。

测试服务器可以预先定义业务服务的监控指标，监控指标可以为能直接衡量系统服务质量的业务监控，可以反映故障触发时对系统行为作出假设以及监控指标的预期变化。例如，调用延迟故障会导致请求的rt会变长，对上层交易量造成下跌的影响，这个交易量则可以作为一个监控指标。

例如，当执行完混沌实验后，可以收到相应的报警信息，并利用报警信息生成测试结果数据。通过对比下之前定义的监控指标，判断测试运行是否符合预期，并利用不符合监控指标的反馈信息或报警信息生成故障排查数据。例如当出现数据库语句执行较慢时，可通过arms的链路根据来排查定位，可以排查出哪条语句执行慢。因此，得到测试结果数据后，还需要通过混沌工程进行持续性的验证，以不断完善业务系统。测试服务器通过模拟生产环境中真实的或有理论依据的故障案例数据，并在业务系统对应的生产环境中运行实验，能够有效保证测试实验环境的真实性，从而能够有效提高测试的准确性。

应该理解的是，虽然图2、4、5的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2、4、5中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图6所示，提供了一种基于故障注入的测试装置，包括：指令获取模块602、实例配置模块604、故障注入模块606和故障测试模块608，其中：

指令获取模块602，用于获取基于待测业务的测试指令，待测业务包括业务信息和业务标识；

实例配置模块604，用于获取多个故障类型对应的预设参数文件，根据业务信息和预设参数文件配置多个故障实例；对多个故障实例进行组合，得到待测业务的故障实例数据；

故障注入模块606，用于根据业务标识获取对应的业务接口数据，利用业务接口数据和故障实例数据生成待测业务的故障注入数据；

故障测试模块608，用于根据业务标识将故障注入数据注入至对应的业务系统中进行测试，生成测试结果数据。

在一个实施例中，实例配置模块604还用于获取历史故障数据；对历史故障数据进行分类，得到多种故障类型；利用历史故障数据构建每种故障类型的故障场景数据；利用故障场景数据生成各个故障类型对应的预设参数文件。

在一个实施例中，实例配置模块604还用于根据业务信息确定待测业务的待测故障类型；获取待测故障类型对应的预设参数文件；获取业务信息的参数列表，参数列表包括业务指标参数；利用业务指标参数对预设参数文件进行配置，生成各个故障类型对应的故障实例。

在一个实施例中，实例配置模块604还用于调用测试编排引擎根据业务信息确定故障编排策略；根据故障编排策略对多个故障实例进行串联和组合，得到待测业务对应的故障案例数据。

在一个实施例中，故障注入模块606还用于对故障注入数据分配相应的注入线程；通过注入线程根据业务标识将故障注入数据注入至相应的业务系统；故障测试模块608还用于利用故障注入数据在业务系统执行相应的测试任务，并生成测试结果数据。

在一个实施例中，故障测试模块608还用于获取预设监控指标数据；利用预设监控指标数据对测试结果数据进行分析，生成故障排查数据；故障排查数据用于对业务系统中相应的故障进行修复。

关于基于故障注入的测试装置的具体限定可以参见上文中对于基于故障注入的测试方法的限定，在此不再赘述。上述基于故障注入的测试装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储业务信息、预设参数文件等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现本申请任意一个实施例中提供的基于故障注入的测试方法的步骤。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请任意一个实施例中提供的基于故障注入的测试方法的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。