CN111881014B - 一种***测试方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请涉及软件测试技术领域，提供一种***测试方法、装置、存储介质及电子设备。其中，***测试方法包括：向运行有待测***的服务器注入服务器异常；监测待测***包含的待测服务的运行指标，并测试待测服务的接口功能。该方法通过主动向运行有待测***的服务器注入服务器异常，模拟服务器真实的异常状况，然后对待测服务的运行指标进行监测以及对待测服务的接口功能进行测试，进而后续基于得到的运行指标和测试结果进行统计分析，就可以确定在服务器出现异常的情况下待测服务、待测***的工作情况，从而拓展了业务***的常规测试范围，还有利于尽早暴露并解决在测试过程中出现的问题。

Description

一种***测试方法、装置、存储介质及电子设备

技术领域

本发明涉及软件测试技术领域，具体而言，涉及一种***测试方法、装置、存储介质及电子设备。

背景技术

在业务***正式上线前都会对其进行测试，但在现有技术中，对业务***进行测试基本上都是建立在服务器环境比较稳定的情况下，测试的范围比较局限，导致业务***上线后故障较多。

发明内容

本申请实施例的目的在于提供一种***测试方法、装置、存储介质及电子设备，以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种***测试方法，包括：向运行有待测***的服务器注入服务器异常；监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能。

在上述方法中，首先通过主动向运行有待测***的服务器注入服务器异常，模拟服务器真实的异常状况，然后对待测服务的运行指标进行监测以及对待测服务的接口功能进行测试，进而后续基于得到的运行指标和测试结果进行统计分析，就可以确定在服务器出现异常的情况下待测***的工作情况(例如，是否能够正常工作、工作过程中存在的问题等)。或者说上述方法提供了一种测试业务***在服务器出现异常的情况下的工作情况的新方案，拓展了业务***的常规测试范围，填补了现有技术中的空白。

进一步的，上述方法还有利于尽早暴露并解决在测试过程中出现的问题，降低待测***在实际上线后出现故障的概率。

在第一方面的一种实现方式中，所述方法还包括：向所述待测服务注入服务异常；监测所述待测服务的运行指标，并测试所述待测服务的接口功能。

在上述实现方式中，通过主动向待测服务注入服务异常，模拟待测服务真实的异常状况，从而可以测试待测服务在异常状况下的工作情况。

在第一方面的一种实现方式中，在所述向所述待测服务注入服务异常之后，所述方法还包括：确定所述待测服务的相关服务，所述相关服务包括所述待测服务的上游服务和/或下游服务；监测所述相关服务的运行指标，并测试所述相关服务的接口功能。

待测***中的服务之间可能具有依赖关系，被当前服务依赖的服务称为当前服务的上游服务，依赖于当前服务的服务称为当前服务的下游服务，若当前服务发生异常，可能导致它的下游服务发生异常，也有可能是它的上游服务异常所导致。因此，在向待测服务注入异常后，除了测试待测服务本身，还可以对待测服务的上游和/或下游服务的工作情况进行测试，全面评估异常在服务调用链中产生的影响。

在第一方面的一种实现方式中，所述待测***部署在DevOps平台上，所述DevOps平台上还部署有运维监控***以及自动化测试***；所述向运行有待测***的服务器注入服务器异常，包括：调用所述DevOps平台提供的第一异常获取接口获取服务器异常列表，并调用所述DevOps平台提供的第一异常注入接口向所述服务器注入所述服务器异常列表中的服务器异常；所述监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能，包括：调用所述DevOps平台提供的服务实例获取接口获取部署在所述DevOps平台上的服务形成的服务列表，并确定所述服务列表中所述待测***包含的所述待测服务；利用所述运维监控***监测所述待测服务的运行指标，并利用所述自动化测试***测试所述待测服务的接口功能。

在第一方面的一种实现方式中，所述待测***部署在DevOps平台上，所述DevOps平台上还部署有运维监控***以及自动化测试***；所述向所述待测服务注入服务异常，包括：调用所述DevOps平台提供的服务实例获取接口获取部署在所述DevOps平台上的服务形成的服务列表，并确定所述服务列表中所述待测***包含的所述待测服务；调用所述DevOps平台提供的第二异常获取接口获取服务异常列表，并调用所述DevOps平台提供的第二异常注入接口向所述待测服务注入所述服务异常列表中的服务异常；所述监测所述待测服务的运行指标，并测试所述待测服务的接口功能，包括：利用所述运维监控***监测所述待测服务的运行指标，并利用所述自动化测试***测试所述待测服务的接口功能。

DevOps平台可以理解为用来安装、部署应用程序的工具，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。在以上两种实现方式中，本申请方案中涉及的待测***、运维监控***以及自动化测试***均部署在DevOps平台上进行统一管理，同时DevOps平台还封装服务实例获取、异常获取、异常注入等接口供外部调用，使得对于异常的注入以及对服务的测试等操作变得简单，用户无需自行编写复杂的指令。

在第一方面的一种实现方式中，所述服务器异常包括以下至少一种：磁盘异常、IO异常、内存异常、CPU异常、断电以及断网。

在第一方面的一种实现方式中，所述服务异常包括以下至少一种：数据库访问超时、数组越界、请求异常以及响应异常。

第二方面，本申请实施例提供一种***测试装置，包括：注入模块，用于向运行有待测***的服务器注入服务器异常；测试模块，用于监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能。

第三方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第四方面，本申请实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种待测***的示意图；

图2示出了本申请实施例提供的一种***测试方法的流程图；

图3示出了本申请实施例提供的一种测试平台的示意图；

图4示出了本申请实施例提供的一种***测试装置的功能模块图；

图5示出了本申请实施例提供的一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

本申请实施例提供的***测试方法测试的对象为某个业务***中的部分或全部的服务，被测试的业务***检测待测***，待测***中被测试的服务简称待测服务。其中，待测服务既可以是传统服务也可以是微服务，本申请对此不限定。

图1示出了本申请实施例提供的一种待测***的示意图。参照图1该待测***100包括前端服务110、业务侧微服务120、核心侧微服务130以及中间件140几个组成部分，该待测***100可以部署在服务器或服务器集群上。待测***10可能被用于不同的业务场景，下面以其被用于视频结构化场景为例进行介绍，即在该场景下待测***100为一个视频结构化***。所谓视频结构化，可以指通过原始的视频流、视频文件进行智能分析，提取出其中关键信息，并进行文本的语义描述。视频结构化***的一种可能的工作流程如下：

在用户希望进行视屏结构化时，可以从前端服务110提供的Web页面上勾选摄像头进行视频流采集或者上传视频文件，Web页面上控件的操作逻辑可以由业务侧微服务120提供支持，业务侧微服务120在获取到视频数据后，将其传递给核心侧微服务130，核心侧微服务会调用相应的算法对视频数据进行结构化分析，并将分析结果返回给业务侧微服务120进行存储。中间件140具有工具性质，可以实现为具有特定功能的服务，例如，Redis(一种高性能数据库)、RabbitMQ(一种消息队列)、Nginx(一种Web服务器)等。中间件140可以分为业务侧中间件和核心侧中间件，分别供业务侧微服务120和核心侧微服务130使用。视频结构化***中各组件的部署顺序为：核心侧中间件、核心侧微服务130、业务侧中间件、业务侧微服务120、前端服务110。

视频结构化***中的待测服务可以包括业务侧微服务120、核心侧微服务130以及中间件。发明人在研究视频结构化***的测试工作时发现其中存在如下缺陷：

缺陷一：对于待测服务的测试都是建立在服务器的CPU、IO、网络环境等指标比较稳定的前提下，对服务器出现异常的情况，视频结构化***以及***包含的待测服务能否正常工作则缺少相应的测试方案。

缺陷二：视频结构化***所涉及的服务之间具有一定的依赖关系，若一个服务出现异常，则依赖它的服务也可能会出现异常。例如，根据前文的阐述，视频结构化***部署时业务侧中间件应该在业务侧微服务启动之前部署，若在某次部署中，业务侧中间件Redis在业务侧微服务启动之后才执行(可视为Redis在部署上的异常)，就会造成依赖于Redis的业务侧微服务无法正常工作。目前还缺乏对某个异常服务的上游服务和/或下游服务进行有效测试、确定其能否正常工作的方案。

以上缺陷，是发明人长期研究现有测试方案后发现的，因此，其发现过程以及下文中本申请实施例针对上述缺陷所提出的解决方案，都应该是发明人在对本申请做出的贡献。

可以理解的，图1仅为示例，本申请方案中涉及的待测***未必采用图1所示的架构，因此图1不应视为对本申请保护范围的限制，但上面提出的两个缺陷具有普遍性。

图2示出了本申请实施例提供的一种***测试方法的流程图。该方法可由一电子设备执行，图5示出了该电子设备可能的结构，可以参照后文关于图5的阐述。参照图2，该方法包括：

步骤S200：向运行有待测***的服务器注入服务器异常。

步骤S210：监测待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能。

服务器异常可以包括，但不限于服务器的磁盘异常(如磁盘出现坏道，磁盘剩余空间过低等)、IO异常(如IO设备错误等)、内存异常(如内存占用过高等)、CPU异常(如CPU占用过高等)、断电以及断网等，可以事先梳理好服务器可能存在的异常，对这些异常进行封装保存，并对外提供接口以便在需要进行异常注入时可以获取到这些异常。步骤S200中的注入服务器异常，是指主动制造服务器异常场景用于模拟服务器真实的异常状况，比如，通过某个接口向服务器注入CPU异常，该接口的内部代码会设法提高CPU的占用率，制造服务器CPU出现异常的状况，从而可以在这样的异常状况下测试待测***的运行状况。

步骤S210中的待测服务的运行指标，既可以包括单个待测服务的指标，也可以包括所有待测服务(或者说待测***)总体的指标。这些指标包括但不限于CPU占用情况、IO速率、内存占用情况、虚拟内存(如Linux下的SWAP)占用情况、磁盘占用情况等。这些指标主要用于从外部环境的层面描述待测服务的运行状况，例如，若某个待测服务长时间占用CPU接近100％，可以合理推断其运行出现了异常。对待测服务的运行指标可以通过运维监控***进行监测，例如，Prometheus***、InfluxDB***等。

仅仅基于上述运行指标并不能获知待测服务的功能是否正常，例如，某个待测服务虽然运行指标正常，但内部数据已经出现错误，调用该待测服务提供的接口总是向客户端返回错误的数据，则仍然属于一种异常状况。因此，还需要对待测服务的接口进行功能测试。接口测试可以采用自动化测试***，如Postman、RESTClient等接口测试工具。

执行完步骤S210后，结合通过监测得到的运行指标和/或通过接口测试得到的测试结果进行统计分析，就可以确定待测服务的工作情况，包括待测服务能否正常工作，若不能正常工作存在怎样的异常等，进而可以确定对应于该异常的解决方案，即如何使得待测服务在服务器出现异常的状况下也可以维持正常运行的方案。上述统计分析过程以及解决异常的过程，既可以采用人工排查的方式，也可以由根据异常现象自动分析、自动确定解决方案，本申请对此不作限定。由于待测***是由若干服务构成的，所以确定了待测服务的工作情况，也就是确定了整个待测***的工作情况。

由于服务器可能存在多种异常状况，因此可能需要多次向服务器注入不同种类的异常，分别进行测试。在一种实现方式中，为避免干扰，每次只注入一种类型的服务器异常，注入完成立即着手确定对应于该异常的解决方案，成功确定解决方案后再注入下一种类型的服务器异常。

综上所述，在图2示出的方法中，首先主动向服务器注入服务器异常以便模拟服务器真实的异常状况，然后对待测服务的运行指标进行监测以及对待测服务的接口功能进行测试，进而后续基于得到的运行指标和测试结果进行统计分析，就可以确定在服务器出现异常的情况下待测***的工作情况。换句话说，该方法提供了一种测试业务***在服务器出现异常的情况下的工作情况的新方案，显著地拓展了常规方法中对业务***进行测试的测试范围，填补了现有技术中的空白。另一方面，通过上述方法中的异常注入还有利于尽早暴露并解决在面临服务器异常时待测***可能出现的问题，降低待测***在实际上线后出现故障的概率。

服务器异常主要是待测服务所处的外部环境中的异常，偏向于设备层面。除了服务器异常外，还有一类异常是服务异常，服务异常主要是待测服务的内部产生的异常，偏向于待测服务的代码逻辑或数据层面。

在一些实现方式中，除了向服务器注入异常外，还可以向待测服务注入服务异常以便模拟待测服务真实的异常状况，并在异常注入后，对待测服务的运行指标进行监测，以及对待测服务的接口功能进行测试。进而基于通过监测得到的运行指标和/或通过接口测试得到的测试结果进行统计分析，就可以确定待测服务的工作情况，并且还可以进一步确定对应于服务异常的解决方案，即如何消除服务异常，或者如何在服务出现异常的状况下使得待测服务仍然能够维持正常工作的方案。由于待测***是由若干服务构成的，所以确定了待测服务的工作情况，也就是确定了整个待测***的工作情况。对待测服务进行服务异常注入还有利于尽早暴露并解决在面临服务异常时待测***可能出现的问题，降低待测***在实际上线后出现故障的概率。

需要指出，对服务异常的测试和对服务器异常的测试是相互独立进行的，即允许二者分别选择服务进行测试，也允许二者分别选择独立的时间段进行测试。例如，可以选择相同的待测服务，先测试服务器异常，再测试服务异常，在测试服务异常时，服务器可以恢复成正常状态。

服务异常可以包括，但不限于数据库访问超时、数组越界、请求异常以(如请求参数不合法等)及响应异常(如响应数据错误等)等，可以事先梳理好服务可能存在的异常，对这些异常进行封装保存，并对外提供接口以便在需要进行异常注入时可以获取到这些异常。所谓的向待测服务注入服务异常，是指主动制造服务异常场景用于模拟服务真实的异常状况，比如，通过某个接口向待测服务注入错误的请求参数，就可以模拟实际中客户端发送非法请求所导致的异常状况，从而可以在这样的异常状况下测试待测服务的运行状况。

至于在异常注入后，监测待测服务的运行指标以及测试待测服务的接口功能，其方法和步骤S210类似，不再重复阐述。

由于服务异常可能有很多类型，同时待测服务也可能有多个，因此可能需要多次向不同的待测服务注入不同种类的异常，分别进行测试。在一种实现方式中，为避免干扰，每次只向一个待测服务注入一种类型的服务异常，注入完成立即着手确定对应于该异常的解决方案，成功确定解决方案后再向该待测服务注入下一种类型的服务异常，若某个待测服务已经注入并解决了所有类型的服务异常，则可以开始下一个待测服务的异常注入过程，直至所有的待测服务都完成异常注入并测试完毕。或者，对于一些相互之间没有依赖关系的待测服务，也可以进行并行测试。

进一步的，之前已经提到，待测***中的服务之间可能具有依赖关系，被当前服务依赖的服务称为当前服务的上游服务，依赖于当前服务的服务称为当前服务的下游服务，上游服务和/或下游服务可以简称当前服务的相关服务。若当前服务发生异常，可能导致它的下游服务发生异常，也有可能是它的上游服务异常所导致。因此，在向待测服务注入异常后，除了测试待测服务本身，还可以对待测服务的相关服务的工作情况进行测试，全面评估异常在服务调用链中产生的影响。具体做法如下：

在向待测服务注入服务异常之后，首先根据服务之间的依赖关系确定待测服务的相关服务(当然如果事先已经记录每个服务的相关服务，直接获取就可以了)，然后监测相关服务的运行指标，并测试相关服务的接口功能，其做法和监测待测服务的运行指标以及测试待测服务的接口功能类似，不再重复。

下面再结合DevOps平台介绍本申请方案的一种实施方式。DevOps(部署Development和运维Operations的组合词)平台可以理解为用来安装、部署应用程序的工具，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

在一些实现方式中，本申请方案中涉及的待测***、运维监控***(用于监测服务的运行指标，具体见前文)以及自动化测试***(用于测试服务的接口功能，具体见前文)均部署在DevOps平台上进行统一管理，同时DevOps平台还封装服务实例获取、异常获取、异常注入等接口供外部调用，使得对于异常的注入以及对待测服务的测试等操作变得简单，用户无需自行编写复杂的指令，有利于提高测试效率。

具体而言，在采用DevOps平台时，步骤S200可以实现为：调用DevOps平台提供的第一异常获取接口获取服务器异常列表，并调用DevOps平台提供的第一异常注入接口向服务器注入服务器异常列表中的服务器异常。其中，服务器异常列表中包含事先梳理并封装好的全部服务器异常，至于要注入的服务器异常可以是该列表中的部分或全部的异常，取决于测试需求。如果有多个服务器异常需要注入，可以采取依次注入的方式，解决一个异常再注入下一个异常，前文已述。

第一异常注入接口可以是一个统一的接口，不同的服务器异常在进行注入时都通过调用该接口完成：例如，在服务器异常列表中，每个服务器异常用一个异常代码表示，第一异常注入接口在设计时提供一个参数用于指定异常代码，从而在第一异常注入接口被调用后，接口的内部逻辑根据该参数传入的值就可以确定当前服务器异常的类型，并执行相应的异常注入行为。当然，也不排除在一些实现方式中，针对不同类型的服务器异常，提供不同的第一异常注入接口用于异常注入。

步骤S210则可以实现为：首先，调用DevOps平台提供的服务实例获取接口获取部署在DevOps平台上的服务形成的服务列表，该服务列表中包含了部署在DevOps平台上的全部服务，由于待测***的服务也都部署在DevOps平台上，从而可以从该服务列表中确定出属于待测***的待测服务；然后，可以利用运维监控***监测待测服务的运行指标，并利用自动化测试***测试待测服务的接口功能。

进一步的，在采用DevOps平台时，对于测试服务异常的情况，其具体实现如下：

首先，调用DevOps平台提供的服务实例获取接口获取部署在DevOps平台上的服务形成的服务列表，并确定服务列表中待测***包含的待测服务。

然后，调用DevOps平台提供的第二异常获取接口获取服务异常列表，服务异常列表中包含事先梳理并封装好的全部服务异常，至于要注入的服务异常可以是该列表中的部分或全部的异常，取决于测试需求，第二异常获取接口和第一异常获取接口可以实现为同一接口也可以实现为不同的接口。之后，调用DevOps平台提供的第二异常注入接口向待测服务注入服务异常列表中的服务异常，第二异常注入接口和第一异常注入接口可以实现为同一接口也可以实现为不同的接口。如果有多个服务异常需要注入，可以采取依次注入的方式，解决一个异常再注入下一个异常，前文已述。第二异常注入接口可以是一个统一的接口，不同的服务异常在进行注入时都通过调用该接口完成，也可以针对不同类型的服务异常，提供不同的第二异常注入接口用于异常注入，其实现可以参考上文对第一异常注入接口的实现，不再重复阐述。

最后，利用运维监控***监测待测服务的运行指标，并利用自动化测试***测试待测服务的接口功能，如有需要，还可以利用运维监控***监测待测服务的相关服务的运行指标，并利用自动化测试***测试待测服务的相关服务的接口功能。

本申请实施例还提供一种测试平台，该平台用于利用本申请实施例提供的***测试方法测试待测***，图3示出了该平台的示意图。参照图3，从下往上看，该平台最下层为封装好的异常，左侧为服务器异常，右侧为服务异常。第二层为集成的DevOps平台接口，包括上面提到的第一异常获取接口、第二异常获取接口、第一异常注入接口、第二异常注入接口、服务实例获取接口等。第三层为平台具体的功能实现，左侧为用于接口测试的自动化测试***，右侧为用于运行指标监测的运维监控***，中间为本申请的方法中三个主要的步骤，通过调用第二层中DevOps平台提供的接口实现。最上层左侧为Web页面，用于用户直接执行测试操作，右侧为API，用于对接第三方应用程序，以便将测试功能集成到第三方应用程序中。

图4示出了本申请实施例提供的***测试装置300的功能模块图。参照图4，***测试装置300包括：

注入模块310，用于向运行有待测***的服务器注入服务器异常；

测试模块320，用于监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能。

在***测试装置300的一种实现方式中，注入模块310还用于：向所述待测服务注入服务异常；测试模块320还用于：监测所述待测服务的运行指标，并测试所述待测服务的接口功能。

在***测试装置300的一种实现方式中，测试模块320还用于：在向所述待测服务注入服务异常之后，确定所述待测服务的相关服务，所述相关服务包括所述待测服务的上游服务和/或下游服务；监测所述相关服务的运行指标，并测试所述相关服务的接口功能。

在***测试装置300的一种实现方式中，所述待测***部署在DevOps平台上，所述DevOps平台上还部署有运维监控***以及自动化测试***；注入模块310向运行有待测***的服务器注入服务器异常，包括：调用所述DevOps平台提供的第一异常获取接口获取服务器异常列表，并调用所述DevOps平台提供的第一异常注入接口向所述服务器注入所述服务器异常列表中的服务器异常；测试模块320监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能，包括：调用所述DevOps平台提供的服务实例获取接口获取部署在所述DevOps平台上的服务形成的服务列表，并确定所述服务列表中所述待测***包含的所述待测服务；利用所述运维监控***监测所述待测服务的运行指标，并利用所述自动化测试***测试所述待测服务的接口功能。

在***测试装置300的一种实现方式中，所述服务器异常包括以下至少一种：磁盘异常、IO异常、内存异常、CPU异常、断电以及断网。

在***测试装置300的一种实现方式中，所述待测***部署在DevOps平台上，所述DevOps平台上还部署有运维监控***以及自动化测试***；注入模块310向所述待测服务注入服务异常，包括：调用所述DevOps平台提供的服务实例获取接口获取部署在所述DevOps平台上的服务形成的服务列表，并确定所述服务列表中所述待测***包含的所述待测服务；调用所述DevOps平台提供的第二异常获取接口获取服务异常列表，并调用所述DevOps平台提供的第二异常注入接口向所述待测服务注入所述服务异常列表中的服务异常；测试模块320监测所述待测服务的运行指标，并测试所述待测服务的接口功能，包括：利用所述运维监控***监测所述待测服务的运行指标，并利用所述自动化测试***测试所述待测服务的接口功能。

在***测试装置300的一种实现方式中，所述服务异常包括以下至少一种：数据库访问超时、数组越界、请求异常以及响应异常。

图5示出了本申请实施例提供的电子设备400的一种可能的结构。参照图5，电子设备400包括：处理器410、存储器420以及通信接口430，这些组件通过通信总线440和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，存储器420包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器410以及其他可能的组件可对存储器420进行访问，读和/或写其中的数据。

处理器410包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器410可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(NetworkProcessor，简称NP)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通信接口430包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口430可以包括进行有线和/或无线通信的接口。

在存储器420中可以存储一个或多个计算机程序指令，处理器410可以读取并运行这些计算机程序指令，以实现本申请实施例提供的***测试方法以及其他期望的功能。

可以理解，图5所示的结构仅为示意，电子设备400还可以包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。图5中所示的各组件可以采用硬件、软件或其组合实现。电子设备400可能是实体设备，例如PC机、笔记本电脑、平板电脑、服务器、嵌入式设备等，也可能是虚拟设备，例如虚拟机、虚拟化容器等。并且，电子设备400也不限于单台设备，也可以是多台设备的组合或者大量设备构成的一个或多个集群。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的***测试方法。例如，计算机可读存储介质可以实现为图5中电子设备400中的存储器420。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (9)

1.一种***测试方法，其特征在于，包括：

向运行有待测***的服务器注入服务器异常；

监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能；

其中，所述待测***部署在DevOps平台上，所述DevOps平台上还部署有运维监控***以及自动化测试***；

所述向运行有待测***的服务器注入服务器异常，包括：

调用所述DevOps平台提供的第一异常获取接口获取服务器异常列表，并调用所述DevOps平台提供的第一异常注入接口向所述服务器注入所述服务器异常列表中的服务器异常；

所述监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能，包括：

调用所述DevOps平台提供的服务实例获取接口获取部署在所述DevOps平台上的服务形成的服务列表，并确定所述服务列表中所述待测***包含的所述待测服务；

利用所述运维监控***监测所述待测服务的运行指标，并利用所述自动化测试***测试所述待测服务的接口功能。

2.根据权利要求1所述的***测试方法，其特征在于，所述方法还包括：

向所述待测服务注入服务异常；

监测所述待测服务的运行指标，并测试所述待测服务的接口功能。

3.根据权利要求2所述的***测试方法，其特征在于，在所述向所述待测服务注入服务异常之后，所述方法还包括：

确定所述待测服务的相关服务，所述相关服务包括所述待测服务的上游服务和/或下游服务；

监测所述相关服务的运行指标，并测试所述相关服务的接口功能。

4.根据权利要求1-3中任一项所述的***测试方法，其特征在于，所述服务器异常包括以下至少一种：磁盘异常、IO异常、内存异常、CPU异常、断电以及断网。

5.根据权利要求2所述的***测试方法，其特征在于，所述向所述待测服务注入服务异常，包括：

调用所述DevOps平台提供的服务实例获取接口获取部署在所述DevOps平台上的服务形成的服务列表，并确定所述服务列表中所述待测***包含的所述待测服务；

调用所述DevOps平台提供的第二异常获取接口获取服务异常列表，并调用所述DevOps平台提供的第二异常注入接口向所述待测服务注入所述服务异常列表中的服务异常；

所述监测所述待测服务的运行指标，并测试所述待测服务的接口功能，包括：

利用所述运维监控***监测所述待测服务的运行指标，并利用所述自动化测试***测试所述待测服务的接口功能。

6.根据权利要求2、3、5中任一项所述的***测试方法，其特征在于，所述服务异常包括以下至少一种：数据库访问超时、数组越界、请求异常以及响应异常。

7.一种***测试装置，其特征在于，包括：

注入模块，用于向运行有待测***的服务器注入服务器异常；

测试模块，用于监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能；

所述待测***部署在DevOps平台上，所述DevOps平台上还部署有运维监控***以及自动化测试***；

所述注入模块向运行有待测***的服务器注入服务器异常，包括：调用所述DevOps平台提供的第一异常获取接口获取服务器异常列表，并调用所述DevOps平台提供的第一异常注入接口向所述服务器注入所述服务器异常列表中的服务器异常；

所述测试模块监测所述待测***包含的待测服务的运行指标，并测试所述待测服务的接口功能，包括：调用所述DevOps平台提供的服务实例获取接口获取部署在所述DevOps平台上的服务形成的服务列表，并确定所述服务列表中所述待测***包含的所述待测服务；利用所述运维监控***监测所述待测服务的运行指标，并利用所述自动化测试***测试所述待测服务的接口功能。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1-6中任一项所述的方法。

9.一种电子设备，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求1-6中任一项所述的方法。

Images