CN113722201A - 一种API一致性检测方法及PaaS平台 - Google Patents

Abstract

本发明实施例提供了一种应用程序接口(API)一致性检测方法、应用即服务(PaaS)平台以及计算机可读存储介质，其中方法包括：基于应用程序的待检测版本，从至少一个基准版本中选择与应用程序的待检测版本的API相同的参考基准版本；复用所述参考基准版本的测试环境以及测试工具镜像，对所述应用程序的待检测版本进行测试，得到所述应用程序的待检测版本的每一个API的测试结果；基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过。

Description

一种API一致性检测方法及PaaS平台

技术领域

本发明涉及应用测试领域，尤其涉及一种应用程序接口(API，ApplicationProgramming Interface)一致性检测方法、应用即服务(PaaS，Platform as a Service)平台以及计算机可读存储介质。

背景技术

应用程序从无到有，经过开发、发布、测试、上线等阶段。从一个版本逐步发展为多个版本。版本间的差异主要包括新增功能点、代码优化、bug修复等。随着应用程序自身的发展，会不断地更新API。而当更改API时接口如何最大限度地减少业务的中断是一个大的挑战。对外提供API的应用程序，由于新功能开发或修复错误，这就需要不断的发布新版本。应用程序的新版本在发布时，会有相应的API变化说明。因此测试人员需要测试验证，以保证API的变化和说明的一致。如果新版本没有引入API变化，那么针对新版本和上一个版本，测试人员使用同样的测试工具和测试方法测试出的API行为应该是一致的。如果测试出来的结果不一致，则有如下可能性：1)应用程序存在bug。2)开发人员说明的API变化存在疏漏。3)测试环境有问题或者存在其它影响API行为的问题。发现API不一致的问题说明了测试的价值，而应对频繁且重复的测试需要好的方法。

新旧版本之间，除了废弃或变动的API外，所有的API都需要保证兼容。为了测试API的兼容性，常见的做法是测试人员使用新版本部署一套测试环境，但是，这样的做法使得针对新版本的检测效率较低、并且不灵活，同时也并无法保证测试结果的准确性。

发明内容

为解决上述技术问题，本发明实施例提供了一种应用程序接口(API，ApplicationProgramming Interface)一致性检测方法、应用即服务(PaaS)平台以及计算机可读存储介质。

第一方面，提供了一种应用程序接口(API，Application ProgrammingInterface)一致性检测方法，应用于应用即服务(PaaS)平台，所述方法包括：

基于应用程序的待检测版本，从至少一个基准版本中选择与应用程序的待检测版本的API相同的参考基准版本；

复用所述参考基准版本的测试环境以及测试工具镜像，对所述应用程序的待检测版本进行测试，得到所述应用程序的待检测版本的每一个API的测试结果；

基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过。

第二方面，提供了一种PaaS平台，包括：

选取单元，用于基于应用程序的待检测版本，从至少一个基准版本中选择与应用程序的待检测版本的API相同的参考基准版本；

测试单元，用于复用所述参考基准版本的测试环境以及测试工具镜像，对所述应用程序的待检测版本进行测试，得到所述应用程序的待检测版本的每一个API的测试结果；

判断单元，用于基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过。

第三方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序使得计算机执行上述第一方面或其各实现方式中的方法。

本发明实施例的技术方案，能够在进行应用程序的新版本的检测的时候，复用原来的测试环境以及测试工具镜像进行测试，从而避免运行环境不一致所带来的问题，并且能够实现高效的进行测试环境的部署，提升了测试效率；另外，本申请实施例提供的方案，通过维护至少一个基准版本，使得进行待检测版本的检测是，灵活的匹配的对应的基准版本，从而排除干扰因素，也提升了测试结果的准确性。

附图说明

图1是本发明实施例提供的一种API一致性检测方法程示意性图一；

图2是本发明实施例提供的一种API测试的处理示意图；

图3是本发明实施例提供的一种API一致性检测方法流程示意性图二；

图4、图5是本发明实施例提供的一种基准版本选取的两种示意图；

图6为本发明实施例提供的一种PaaS平台组成结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本发明实施例提供了一种API一致性检测方法，应用于PaaS平台，如图1所示，所述方法包括：

步骤11：基于应用程序的待检测版本，从至少一个基准版本中选择与应用程序的待检测版本的API相同的参考基准版本；

步骤12：复用所述参考基准版本的测试环境以及测试工具，对所述应用程序的待检测版本进行测试，得到所述应用程序的待检测版本的每一个API的测试结果；

步骤13：基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过。

本申请实施例的一种API一致性测试方法，通过PaaS平台构建应用程序镜像和测试工具镜像，自动部署测试环境。选择特定版本测试API行为，并维护基准版本信息。测试新版本的API，对比基准版本的测试结果，判定API是否保持一致。

API主要包含：API名称、用途、url、方法、请求体(request body)、返回码、返回体(response body)、版本等。

图2中，简单描述了API测试方法，一端是测试工具，也称为客户端。它通过构造API请求并发送请求给应用程序。然后根据API响应的返回码以及返回体来判断测试结果。另一端是应用程序，提供API服务，是被测对象。

举例说明，应用程序提供查询当前用户详情的API：GET/users/{user_id}。

测试工具构造一条API请求GET/users/Jack HTTP/1.1,查询名为Jack的用户详情，然后发送请求到应用程序。如果当前应用程序中存在用户Jack，则应用程序返回码200-OK，返回体如下：

反之如果Jack这个用户不存在，则应用程序返回404-Not Found。

如果新版本中，查询用户详情的API被移除后，上述测试接收到的返回码为400-Bad Request。

前述API既是作为消费者(用户和开发人员)使用应用程序的重要方式也是应用程序提供的功能和服务与他人共享的重要方式。如第三方开发者基于API开发的客户端软件。因此，保证API的稳定性至关重要，随意更改API很容易中断服务。

本实施例提供的方案中，所述基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过，包括：

判断所述应用程序的待检测版本的每一个API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果是否一致；

若一致，则确定所述应用程序的待检测版本的API一致性测试通过。

确定API一致性测试失败的方式，可以为：

第一种方式、

判断所述应用程序的待检测版本的每一个API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果是否一致；

若不一致，则确定所述应用程序的待检测版本的API一致性测试失败。

也就是，一旦存在任意一个API对应的测试结果不同，那么就认为测试失败。

第二种方式、

当所述应用程序的待检测版本存在部分API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果不一致时，

判断所述部分API对应的测试用例是否为第一类测试用例；其中，所述第一类测试用例为对应的测试结果可以忽略的测试用例；

若所述部分API对应的测试用例为第一类测试用例，则确定所述应用程序的待检测版本的API一致性测试通过；否则，确定所述应用程序的待检测版本的API一致性测试失败。

也就是说，如果应用程序的待检测版本与选中的基准版本的测试结果相比，存在N个API的测试结果是不同的，那么就进一步N个API对应的测试用例，是否为第一类测试用例，也就是是否为可以忽略的一部分测试用例；其中，第一类测试用例可以预先设置。

如果确定为第一类测试用例，那么就可以认为一致性测试通过，否则，失败。

进一步地，在进行参考基准版本的选择的时候，如果从至少一个基准版本中未找到与待检测版本的API一样的，那么可以将待检测版本作为待测试基准版本进行处理，也就是说：当应用程序的待检测版本的API与至少一个基准版本相比，均存在API的变化时，将所述应用程序的待检测版本作为待测试基准版本进行处理。

其中，所述将所述应用程序的待检测版本作为待测试基准版本进行处理，包括：

获取所述待测试基准版本的API列表；

构建所述待测试基准版本的应用程序镜像以及测试工具镜像；其中，所述测试工具镜像中包含有与所述API列表中包含的API对应的测试用例；

部署测试环境，运行所述应用程序镜像以及所述测试工具镜像对所述基准版本的API进行测试，得到测试结果；

将所述待测试基准版本的API测试结果与预设的测试结果进行比对，若一致，则确定所述待测试基准版本的API一致性测试通过，并将所述待测试基准版本记录为新的基准版本。

图3示意了API一致性测试方法对应的流程图，下面结合图3，对本实施例提供的上述方案进行详细的说明和描述：

步骤1、获取API列表；可以为针对待测试基准版本，获取API列表。

对于测试工具来说，针对每一个API都有对应的测试用例。测试人员添加或者维护这些测试用例，需要获取被测应用程序的API列表。

本实施例中，获取API列表的方式有两种，一种是开发人员提供，一种是测试人员通过软件生成。

分别来说，常见的做法是开发人员提供API文档，该文档包括当前版本的应用程序所支持的完整的API列表，每一个API的用途、用法、参数以及返回值等。测试人员根据API文档编写测试用例。而新版本的发布，需要开发人员及时更新API文档，通知测试人员及时更新测试用例。

此外，测试人员可以通过工具分析应用程序的代码自动生成API列表，这种做法依赖于开发人员使用规范的语法定义API。

然后通过后续步骤2、3构建所述待测试基准版本的应用程序镜像以及测试工具镜像；具体的：

步骤2、构建应用程序镜像；也就是针对待测试基准版本构建应用程序镜像。

基于PaaS平台运行应用程序，镜像是基础。镜像中包括了应用程序运行所必备的基础配置和依赖库。

对于API测试来说，可以使用mock方法。

其中，Mock方法进行测试就是在测试过程中，对于某些不容易构造(如HttpServletRequest必须在Servlet容器中才能构造出来)或者不容易获取的比较复杂的对象(如JDBC中的ResultSet对象)，用一个虚拟的对象(Mock对象)来创建以便测试的测试方法。

通过代码编写应用程序的mock接口，屏蔽无法测试的部分。被测试的API使用mock接口来应答，使得测试工具可以完成API测试。适用于开发与测试并行场景，需要提前测试应用程序的API。

开发人员负责应用程序镜像的版本管理，版本信息中包括当前版本支持的功能列表、API列表、修复记录等。

步骤3、构建测试工具镜像；也就是针对待测试基准版本构建测试工具镜像。其中，所述测试工具镜像中包含有与所述API列表中包含的API对应的测试用例。

测试工具通常使用主流的自动化测试框架(如Robot Framework),测试用例由测试人员编写。测试工具镜像包含了完整的测试用例，测试人员无须经过任何修改即可进行测试。

测试人员负责测试工具镜像的版本管理，版本信息中包括当前版本支持的测试用例(所有API的测试用例)、修复记录等。

例如，测试工具镜像v1.0版本包括了1000个测试用例，能够覆盖应用程序v1.0版本所有的API。如果新版本的应用程序增加了部分API，那么测试工具需要增加相应的测试用例。使用老版本的测试工具镜像测试新版本的应用程序，则无法覆盖完整的API。如果新版本的应用程序废弃了部分API，则使用老版本的测试工具镜像测试，会有部分用例测试不通过。

步骤4、构建部署脚本；也就是针对待测试基准版本构建部署脚本。具体的：

PaaS平台提供API和客户端用于部署应用程序。对于使用PaaS平台的开发人员或者测试人员来说，根据应用程序的特点构建部署脚本。脚本包含使用的镜像名称以及版本、副本个数、开发的端口、标签等。对于提供API服务的应用程序还需要创建相应的负载均衡器；其中，所述负载均衡器用于对外提供服务。

步骤5、选择基准测试版本；

为了衡量新版本的应用程序API兼容程度，识别出API变动。需要有一个基准的版本(第一次做的为基准版本，更新之后，有新的基准版本)供对比。一旦新版本的应用程序进行了API的修改，需要增加一个基准版本用于关联应用程序版本，并且需要同步更新测试工具镜像版本。

应用程序版本与API之间的对应关系，可以参见图4。API较小的改动使用微版本记录并提供，如获取用户详情的API在返回体中增加了国籍信息，可以在应用程序侧提升一个微版本，低于这个微版本的API请求得到的返回体中不包含国籍信息。

举例来说，如图4所示，应用程序版本v1.0.0支持的API版本是v1，v2.0.0支持的API版本是v2。基准版本测试包含三个版本，第一个版本是应用程序版本v1.0.0，第二个版本是应用程序版本v1.2.0,第三个版本是应用程序版本v2.0.0.

然后部署测试环境，运行所述应用程序镜像以及所述测试工具镜像对所述基准版本的API进行测试，得到测试结果。具体如步骤6、7：

步骤6、测试API接口；

具体可以为：通过PaaS平台部署测试环境，运行应用程序和测试工具。在测试工具上配置应用程序的API访问方式。测试人员使用测试工具进行测试。

步骤7、记录测试结果；

测试完成后，记录测试结果。整理并输出每一个API的测试情况。

步骤8、分析测试结果；将所述待测试基准版本的API测试结果与预设的测试结果进行比对。

测试人员在编写测试用例时，会定义预期结果(也就是预设的每一个测试用例所对应的预设的测试结果)。基于这个结果去判断测试通过与否。

对于基准版本测试来说，为了避免测试用例的预期结果编写错误或者测试步骤不当等干扰。测试人员分析测试的详细日志，检查核对每一个用例的实际执行情况。

步骤9、判断测试是否通过；如果不通过则执行步骤10；否则，执行步骤11。

经过检查核对后，如果存在部分测试用例测试失败(也就是两者不一致)，则判定测试不通过。

步骤10、打回给开发重新修改；

对于测试不通过的情况，需要通知开发人员修复问题并重新发布版本。基准版本也不会修改。

步骤11、确定基准版本信息；也就是将所述待测试基准版本作为新的基准版本。具体可以为将新的基准版本添加到基准版本列表中，或与原来的至少一个基站版本均保存在数据库中。

具体的，如果测试通过，则记录基准版本信息。以图5为例进行说明，一共记录了三个基准版本。第一个基准版本对应：应用程序v1.0.0、测试工具版本v1.0、API版本v1、微版本v1.0。第二个基准版本对应：应用程序v1.2.0、测试工具版本v1.1、API版本v1、微版本v1.1。第三个基准版本对应：应用程序v2.0.0、测试工具版本v1.2、API版本v2、微版本v2.0。

至此完成基准版本的确定。后续步骤，结合基准版本对新版本的应用程序，也就是应用程序的待检测版本进行API一致性检测的处理，具体可以包括：

步骤12、获取新版本的应用程序；

应用版本发布新版本时，测试人员需要重新测试验证一遍。测试人员获取新版本的应用程序镜像，根据应用程序的版本号从基准版本信息列表中选择版本最接近的测试工具镜像。如测试应用程序版本v1.3.0，选择最接近的第二个基准版本。

如果新版本的应用程序存在API的变化，这类版本需要作为基准版本进行测试。这里，如果作为基准版本进行测试，可以执行前述步骤1～步骤11的处理，不再进行赘述。

步骤13、部署新版本

上传新的应用程序镜像到PaaS平台，更新部署脚本，重新部署一套测试环境。

步骤14～步骤16、测试API接口，记录测试结果以及分析测试结果。

具体的处理，可以与前述同第6步～步骤8相同，这里不再赘述。

步骤17、与基准版本作对比；

对比每一个测试用例的测试结果，找出新版本测试结果与基准版本测试结果不一致的测试用例。通常情况下，所有测试用例的测试结果都得一致。但是，测试人员可以选择忽略部分测试用例的测试结果。

步骤18、判断API接口是否一致；

除了测试结果可忽略的测试用例外，其它测试用例的测试结果必须都得一致。如果有不一致的情况，则判定API一致性测试不通过，执行步骤20。否则，通过，执行步骤19。

步骤19、测试通过；

API一致性测试通过，应用程序的新版本按照约定没有改变API的行为。调用该应用程序API的第三方软件可以正常工作，使用该应用程序API的用户不用感知应用程序的版本变化。

步骤20、测试失败；

API一致性测试失败，应用程序的新版本改变了API行为但没有通知测试人员。或者修改的代码破坏了API的行为。

步骤21、分析失败原因；

针对测试不通过的API，测试人员需要与开发人员沟通确定此类API的实现是否存在bug。

开发人员修复完bug后，发布新的应用程序版本，需要从第12步开始重新验证直至测试全部通过。

综上所述，本申请提供的方案，能够在进行应用程序的新版本的检测的时候，复用原来的测试环境以及测试工具镜像进行测试，从而避免运行环境不一致所带来的问题，并且能够实现高效的进行测试环境的部署，提升了测试效率；另外，本申请实施例提供的方案，通过维护至少一个基准版本，使得进行待检测版本的检测时，灵活的匹配的对应的基准版本，从而排除干扰因素，也提升了测试结果的准确性。

也就是说，本实施例基于PaaS平台的镜像功能，将应用程序与测试工具打包成镜像，并进行版本管理。降低了部署应用的复杂度，避免了运行环境不一致引起的问题，让测试人员专注于测试本身。具体的，基于PaaS的编排功能，自动部署应用并开通访问策略，实现了高效重复部署测试环境。根据应用程序版本间的API变化情况，选择并维护相应的基准版本信息。测试人员复用与基准版本一样的测试工具、测试方法以及测试环境来测试新版本的应用程序API行为。对比基准版本的测试结果，判断新版本的应用程序API行是否为与基准版本一致。如果存在不兼容的情况，需要进行问题的分析与解决。

基于上述，本发明实施例提供了一种PaaS平台，如图6所示，所述方法包括：

选取单元61，用于基于应用程序的待检测版本，从至少一个基准版本中选择与应用程序的待检测版本的API相同的参考基准版本；

测试单元62，用于复用所述参考基准版本的测试环境以及测试工具镜像，对所述应用程序的待检测版本进行测试，得到所述应用程序的待检测版本的每一个API的测试结果；

判断单元63，用于基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过。

本申请实施例的一种API一致性测试方法，通过PaaS平台构建应用程序镜像和测试工具镜像，自动部署测试环境。选择特定版本测试API行为，并维护基准版本信息。测试新版本的API，对比基准版本的测试结果，判定API是否保持一致。

API主要包含：API名称、用途、url、方法、请求体(request body)、返回码、返回体(response body)、版本等。

本实施例提供的方案中，所述判断单元63，用于判断所述应用程序的待检测版本的每一个API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果是否一致；

若一致，则确定所述应用程序的待检测版本的API一致性测试通过。

确定API一致性测试失败的方式，可以为：

第一种方式、

判断单元63，用于判断所述应用程序的待检测版本的每一个API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果是否一致；

若不一致，则确定所述应用程序的待检测版本的API一致性测试失败。

也就是，一旦存在任意一个API对应的测试结果不同，那么就认为测试失败。

第二种方式、

判断单元63，用于当所述应用程序的待检测版本存在部分API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果不一致时，

判断所述部分API对应的测试用例是否为第一类测试用例；其中，所述第一类测试用例为对应的测试结果可以忽略的测试用例；

若所述部分API对应的测试用例为第一类测试用例，则确定所述应用程序的待检测版本的API一致性测试通过；否则，确定所述应用程序的待检测版本的API一致性测试失败。

也就是说，如果应用程序的待检测版本与选中的基准版本的测试结果相比，存在N个API的测试结果是不同的，那么就进一步N个API对应的测试用例，是否为第一类测试用例，也就是是否为可以忽略的一部分测试用例；其中，第一类测试用例可以预先设置。

如果确定为第一类测试用例，那么就可以认为一致性测试通过，否则，失败。

进一步地，在进行参考基准版本的选择的时候，如果从至少一个基准版本中未找到与待检测版本的API一样的，那么可以将待检测版本作为待测试基准版本进行处理，也就是说：当应用程序的待检测版本的API与至少一个基准版本相比，均存在API的变化时，将所述应用程序的待检测版本作为待测试基准版本进行处理。

其中，

所述测试单元，用于获取所述待测试基准版本的API列表；构建所述待测试基准版本的应用程序镜像以及测试工具镜像；其中，所述测试工具镜像中包含有与所述API列表中包含的API对应的测试用例；部署测试环境，运行所述应用程序镜像以及所述测试工具镜像对所述基准版本的API进行测试，得到测试结果；

所述判断单元，用于将所述待测试基准版本的API测试结果与预设的测试结果进行比对，若一致，则确定所述待测试基准版本的API一致性测试通过，并将所述待测试基准版本记录为新的基准版本。

综上所述，本申请提供的方案，能够在进行应用程序的新版本的检测的时候，复用原来的测试环境以及测试工具镜像进行测试，从而避免运行环境不一致所带来的问题，并且能够实现高效的进行测试环境的部署，提升了测试效率；另外，本申请实施例提供的方案，通过维护至少一个基准版本，使得进行待检测版本的检测时，灵活的匹配的对应的基准版本，从而排除干扰因素，也提升了测试结果的准确性。

本申请实施例还提供了一种计算机可读存储介质，用于存储计算机程序。

可选的，该计算机可读存储介质可应用于本申请实施例中的任意一种设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由网络设备、终端设备实现的相应流程，为了简洁，在此不再赘述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理器中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，)ROM、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (11)

1.一种应用程序接口API一致性检测方法，应用于应用即服务PaaS平台，所述方法包括：

基于应用程序的待检测版本，从至少一个基准版本中选择与应用程序的待检测版本的API相同的参考基准版本；

复用所述参考基准版本的测试环境以及测试工具镜像，对所述应用程序的待检测版本进行测试，得到所述应用程序的待检测版本的每一个API的测试结果；

基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过。

2.根据权利要求1所述的方法，其特征在于，所述基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过，包括：

判断所述应用程序的待检测版本的每一个API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果是否一致；

若一致，则确定所述应用程序的待检测版本的API一致性测试通过。

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

当所述应用程序的待检测版本存在部分API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果不一致时，

判断所述部分API对应的测试用例是否为第一类测试用例；其中，所述第一类测试用例为对应的测试结果可以忽略的测试用例；

若所述部分API对应的测试用例为第一类测试用例，则确定所述应用程序的待检测版本的API一致性测试通过；否则，确定所述应用程序的待检测版本的API一致性测试失败。

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

当应用程序的待检测版本的API与至少一个基准版本相比，均存在API的变化时，将所述应用程序的待检测版本作为待测试基准版本进行处理。

5.根据权利要求4所述的方法，其特征在于，将所述应用程序的待检测版本作为待测试基准版本进行处理，包括：

获取所述待测试基准版本的API列表；

构建所述待测试基准版本的应用程序镜像以及测试工具镜像；其中，所述测试工具镜像中包含有与所述API列表中包含的API对应的测试用例；

部署测试环境，运行所述应用程序镜像以及所述测试工具镜像对所述基准版本的API进行测试，得到测试结果；

将所述待测试基准版本的API测试结果与预设的测试结果进行比对，若一致，则确定所述待测试基准版本的API一致性测试通过，并将所述待测试基准版本记录为新的基准版本。

6.一种PaaS平台，其特征在于，包括：

选取单元，用于基于应用程序的待检测版本，从至少一个基准版本中选择与应用程序的待检测版本的API相同的参考基准版本；

测试单元，用于复用所述参考基准版本的测试环境以及测试工具镜像，对所述应用程序的待检测版本进行测试，得到所述应用程序的待检测版本的每一个API的测试结果；

判断单元，用于基于所述应用程序的待检测版本的每一个API的测试结果，与参考基准版本的API的测试结果进行比对，确定所述应用程序的待检测版本的API一致性测试是否通过。

7.根据权利要求6所述的PaaS平台，其特征在于，所述判断单元，用于判断所述应用程序的待检测版本的每一个API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果是否一致；

若一致，则确定所述应用程序的待检测版本的API一致性测试通过。

8.根据权利要求7所述的PaaS平台，其特征在于，所述判断单元，用于当所述应用程序的待检测版本存在部分API对应的测试用例的测试结果，与参考基准版本的API对应的测试用例的测试结果不一致时，判断所述部分API对应的测试用例是否为第一类测试用例；其中，所述第一类测试用例为对应的测试结果可以忽略的测试用例；若所述部分API对应的测试用例为第一类测试用例，则确定所述应用程序的待检测版本的API一致性测试通过；否则，确定所述应用程序的待检测版本的API一致性测试失败。

9.根据权利要求6所述的PaaS平台，其特征在于，所述判断单元，用于当应用程序的待检测版本的API与至少一个基准版本相比，均存在API的变化时，将所述应用程序的待检测版本作为待测试基准版本进行处理。

10.根据权利要求9所述的PaaS平台，其特征在于，所述测试单元，用于获取所述待测试基准版本的API列表；构建所述待测试基准版本的应用程序镜像以及测试工具镜像；其中，所述测试工具镜像中包含有与所述API列表中包含的API对应的测试用例；部署测试环境，运行所述应用程序镜像以及所述测试工具镜像对所述基准版本的API进行测试，得到测试结果；

所述判断单元，用于将所述待测试基准版本的API测试结果与预设的测试结果进行比对，若一致，则确定所述待测试基准版本的API一致性测试通过，并将所述待测试基准版本记录为新的基准版本。

11.一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现权利要求1-5任一项所述方法的步骤。

Images