一种KVM架构下API测试的方法及系统与流程

本发明涉及软件测试技术领域，具体涉及一种kvm架构下api测试方法及系统。

背景技术：

api是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

api测试在目前流行的互联网产品测试理念中比重最为重要，由于要快速响应用户诉求应对需求变化，api测试更优于单元测试、gui测试。单元测试更主流的由研发自己担任，在以往的研发理念里占比较重，适用于产品生命周期久、需求改动不频繁的传统模式，无法适用现在流行快速迭代及越来越高的客户需求体验。另外，gui测试层通常采用的方法是模拟各种用户使用场景，并验证这些操作的结果是否正确，最贴近用户体验，但也有很大的缺点：执行效率较低花费大量的人力成本，即便是使用gui自动化测试技术，用例的维护和执行代价依然很大。所以无法满足持续的客户变化，稳定性和复用性是其重大缺陷。

以上原因导致了api测试比重加大，成为最需要优化的测试部分。以往的研发模型更多的采用单体结构，所谓单体结构是指所有的业务场景的表示层、业务逻辑层和数据访问层都在一个工程里，请统一编译、打包后部署在环境里。所以单体结构具有发布简单、方便调试、架构简单等特点，所以一直被大量使用特别是企业级的产品中。

但是随着互联网产品的普及，互联网产品的测试理念也得到大家的认可和推广。这样也暴露了单体架构的很多缺点，主要体现在灵活性、可扩展性、稳定性及可维护性。

微服务架构应运而生，这是种新型的架构风格，一种大型复杂软件系统不再由一个单体组成，而是由一系列相互独立的微服务组成。各个微服务运行在自己的进程中，开发和部署都没有依赖。

kvm是一个开源的系统虚拟化模块，自linux2.6.20之后集成在linux的各个主要发行版本中。它使用linux自身的调度器进行管理，所以相对于xen，其核心源码很少。kvm目前已成为学术界的主流vmm之一。

针对单体架构的api的测试方案是很长一段时间api测试的主流，主要测试方式是针对提供的对外api设计测试数据，并覆盖多种逻辑组合。由于单体架构下代码的底层、路逻层、表示层等对外表现的api比较单一，所以对外暴露可传入的测试数据对代码逻辑来说覆盖有限，另外还有以下主要缺陷：

稳定性差：当单体应用中的任何一个模块有问题时，都可能造成应用整体不可用，缺乏容错机制。无论多小的改动，也需要重新打包整个应用，而且每次打包时间都比较久。

可扩展性差：在模拟多并发场景时，无法便利的以模块为单位灵活扩展容量，不利于模块的横向扩展。

可维护性差：当单体应用中的任何一个模块有问题时，都可能会造成应用的复杂性直线上升，当业务规模比较庞大时，整体项目的维护性成本会增大。

基于kvm实现的虚拟化系统符合以上特点，多个服务都会对外暴露接口，同时这些微服务之间也有逻辑关联，就会导致两个问题：api测试的数据量增大；各个服务之间有耦合关系。

基于kvm架构的虚拟化系统是目前主流的虚拟化系统实现方式，且基于该框架实现的虚拟化系统大都采用微服务架构，针对这类虚拟化系统的api测试，提出更优的解决方案，解决目前基于kvm实现的虚拟化系统的api测试的短板。

技术实现要素：

基于kvm实现的虚拟化系统多个服务都会对外暴露接口，针对api测试的数据量增大；各个服务之间有耦合关系的问题，本发明提供一种kvm架构下api测试方法及系统。

本发明的技术方案是：

一种kvm架构下api测试的方法，包括如下步骤：

分析各服务间的耦合关系；

将各服务间的耦合关系进行解耦；

进行各服务api接口的测试。

为了既能保证api质量又能减少用例数量的测试策略，需要将各服务间的耦合关系进行解耦；

进一步的，分析各服务间的耦合关系，包括：

获取各服务的请求和响应数据；

通过分析获取各服务的请求和响应数据，确定各服务之间的调用关系；找到针对某一服务的调用方式，就能很大程度的保证了该服务的质量。

根据服务间的调用关系确定存在耦合关系的服务。

进一步的，获取各服务的请求和响应数据，包括：

在服务之前放置的代理组件，获取每个服务的发送请求数据和返回响应数据；

收集到的发送请求数据和返回响应数据关系生成对应的json文件。

进一步的，将各服务间的耦合关系进行解耦，包括：

设置mockservice模拟各个真实的服务解决各服务api之间相互依赖的耦合关系。解耦的方式常用的是实现mockservice来代替被依赖的真正的服务。

进一步的，设置mockservice模拟各个真实的服务解决各服务api之间相互依赖的耦合关系，包括：

通过调用关系mockservice模拟各个真实的服务进行api测试。

进一步的，通过调用关系mockservice模拟各个真实的服务进行api测试，包括：

mockservice根据生成的json文件模拟真实服务的发送请求数据和返回响应数据进行api测试。只有真正被使用的api调用才被收集到，如果没有使用到的就不去测试，使用mockservice去模拟各个真实的service解决了api之间的相互依赖耦合关系。既解决了传统api测试思路通过排列组合导致的测试数据庞大，也解决了api之间耦合的问题。

另一方面，本发明技术方案还提供一种kvm架构下api测试的系统，包括分析处理模组、解耦处理模块和测试模块；

分析处理模组，用于分析各服务间的耦合关系；

解耦处理模块，用于将各服务间的耦合关系进行解耦；

测试模块，用于进行各服务api接口的测试。

进一步的，分析处理模组包括获取模块、分析处理模块；

获取模块，用于获取各服务的请求和响应数据

分析处理模块，用于分析获取各服务的请求和响应数据，确定各服务之间的调用关系并根据服务间的调用关系确定存在耦合关系的服务。

进一步的，获取模块为设置在服务之前的代理组件；

代理组件，用于获取每个服务的发送请求数据和返回响应数据；

代理组件，还用于收集到的发送请求数据和返回响应数据关系生成对应的json文件。

进一步的，解耦处理模块为mockservice模块；

mockservice模块，用于模拟各个真实的服务解决各服务api之间相互依赖的耦合关系；

mockservice模块，根据生成的json文件模拟真实服务的发送请求数据和返回响应数据进行api测试。

从以上技术方案可以看出，本发明具有以下优点：mockservice根据生成的json文件模拟真实服务的发送请求数据和返回响应数据进行api测试。只有真正被使用的api调用才被收集到，如果没有使用到的就不去测试，使用mockservice去模拟各个真实的service解决了api之间的相互依赖耦合关系。既解决了传统api测试思路通过排列组合导致的测试数据庞大，也解决了api之间耦合的问题。

此外，本发明设计原理可靠，结构简单，具有非常广泛的应用前景。

由此可见，本发明与现有技术相比，具有突出的实质性特点和显著地进步，其实施的有益效果也是显而易见的。

附图说明

图1为微服务架构中各个服务间有耦合关系示意图；

图2为有耦合关系的各服务间的请求和响应示意图；

图3为一种kvm架构下api测试的方法流程关系示意图；

图4为一种kvm架构下api测试的方法流程示意图。

具体实施方式

下面结合附图并通过具体实施例对本发明进行详细阐述，以下实施例是对本发明的解释，而本发明并不局限于以下实施方式。

实施例一

在传统的单体架构的api测试中，常用的测试策略是：根据被测的api参数进行数列的有效的排列组合，并验证相关结果的正确性；查看测试结果的代码覆概率，根据遗漏的覆盖率分析找出遗漏的测试用例；以代码覆盖率不断提升为api测试完成的标志。但是在微服务的架构里，整体的功能会拆分成很多单个的服务也就是多个独立的service，所以原本整体的应用会拆分为多个api共同协作完成。每个service对应独立的driver，各driver都是独立的提供单独独立的服务。在互联网模式下，产品发布的周期流行以“天”甚至是“小时”为单位，所以测试执行的时间被压缩的很少。这是就需要找到一种既能保证api质量又能减少用例数量的测试策略，如图4所示，本发明提供一种kvm架构下api测试的方法，包括如下步骤：

s1：分析各服务间的耦合关系；

这里所说的耦合关系是指，比如我们需要测试servicea提供的api接口，但是servicea又调用了servicex和servicey组成，如果x或者y由于其他原因不可用，那么a也就无法进行完整的测试，servicea与servicex和servicey之前存在耦合关系如图1所示。

本步骤中，分析各服务间的耦合关系，包括：

获取各服务的请求和响应数据；

进一步需要说明的是，获取各服务的请求和响应数据，包括：

在服务之前放置的代理组件，获取每个服务的发送请求数据和返回响应数据；

收集到的发送请求数据和返回响应数据关系生成对应的json文件。

在这里需要说明的是，json文件数据格式如下所示：

json数据格式一

error是调用api是否成功，errortype是错误类型(如果成功则为0)errormessag是错误信息(如果成功则为空)result是返回的结果，(如果失败则返回为空)。

通过分析获取各服务的请求和响应数据，确定各服务之间的调用关系；找到针对某一服务的调用方式，就能很大程度的保证了该服务的质量。

根据服务间的调用关系确定存在耦合关系的服务。

s2：将各服务间的耦合关系进行解耦；

比如我们需要测试servicea提供的api接口，但是servicea又调用了servicex和servicey组成，如果x或者y由于其他原因不可用，那么a也就无法进行完整的测试，所以我们需要一种方法将servicea的测试与servicex和servicey解耦，然后进行测试。

解耦的方式常用的是实现mockservice来代替被依赖的真正的service。所以关键点变成了模拟真实的service的request和response。如图2所示，a由x和y组成，那么x和y与a就有发送request返回response的关系。所以servicea的使用者其实只有servicex和servicey，找到对a的调用的方式，就能很大程度的保证了servicea的质量。所以问题转化成如何找到servicex和servicey对servicea的调用，将这些测试用例测试通过，servicea的质量基本就得到了保证。

设置mockservice模拟各个真实的服务解决各服务api之间相互依赖的耦合关系。解耦的方式常用的是实现mockservice来代替被依赖的真正的服务。

如图3所示，mockservice根据生成的json文件模拟真实服务的发送请求数据和返回响应数据进行api测试。只有真正被使用的api调用才被收集到，如果没有使用到的就不去测试，使用mockservice去模拟各个真实的service解决了api之间的相互依赖耦合关系。既解决了传统api测试思路通过排列组合导致的测试数据庞大，也解决了api之间耦合的问题。

s3：进行各服务api接口的测试，调用对应的测试用例进行api的测试。

实施例二

本发明技术方案还提供一种kvm架构下api测试的系统，包括分析处理模组、解耦处理模块和测试模块；

分析处理模组，用于分析各服务间的耦合关系；分析处理模组包括获取模块、分析处理模块；

获取模块，用于获取各服务的请求和响应数据；获取模块为设置在服务之前的代理组件；

代理组件，用于获取每个服务的发送请求数据和返回响应数据；

代理组件，还用于收集到的发送请求数据和返回响应数据关系生成对应的json文件。

分析处理模块，用于分析获取各服务的请求和响应数据，确定各服务之间的调用关系并根据服务间的调用关系确定存在耦合关系的服务。

解耦处理模块，用于将各服务间的耦合关系进行解耦；解耦处理模块为mockservice模块；

mockservice模块，用于模拟各个真实的服务解决各服务api之间相互依赖的耦合关系；

mockservice模块，根据生成的json文件模拟真实服务的发送请求数据和返回响应数据进行api测试。

测试模块，用于进行各服务api接口的测试。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。