测试方法、装置、电子设备及计算机可读存储介质与流程

1.本技术涉及微服务技术领域，具体而言，本技术涉及一种测试方法、装置、电子设备及计算机可读存储介质。


背景技术：

2.微服务架构是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成；服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。
3.随着微服务架构的流行与广泛应用，应用程序被拆分的服务数量及服务调用的复杂度也逐渐增加。现有技术中通常采用接口文档或表格，管理微服务中的服务接口信息，并编写服务接口测试用例以对应用程序进行集成测试；当出现接口文档与实际服务接口不一致的错误，测试用例无法对该错误进行及时暴露，存在测试效率低下的问题。


技术实现要素：

4.本技术实施例提供了一种测试方法、装置、电子设备及计算机可读存储介质，可以解决现有技术中针对微服务架构的应用程序，存在测试效率低下的问题。所述技术方案如下：
5.根据本技术实施例的一个方面，提供了一种测试方法，该方法包括：
6.接收第一客户端的交互请求，获取交互请求中携带的交互信息以及服务接口；服务接口包括第一客户端与第二客户端之间的交互接口；
7.根据预设的服务契约，对交互信息进行校验；其中，服务契约为预先配置的；
8.在交互信息校验通过的情况下，通过服务接口调用第二客户端处理交互请求。
9.可选的，上述接收第一客户端的交互请求之前，方法包括：
10.根据服务接口，配置服务契约；其中，服务契约中包括服务接口的服务属性信息和测试属性信息。
11.可选的，上述根据预设的服务契约，对交互信息进行校验，包括：
12.基于服务属性信息，对交互信息的请求格式进行校验；
13.当请求格式与服务属性信息中的标准请求格式一致，则交互信息校验通过。
14.可选的，上述通过服务接口调用第二客户端处理交互请求，包括：
15.基于第二客户端的功能逻辑处理交互请求，并生成响应信息；
16.基于服务契约对响应信息进行校验；
17.在响应信息校验通过的情况下，向第一客户端发送服务接口响应成功的通知。
18.可选的，上述方法还包括：
19.在第一客户端完成开发，且第二客户端未完成开发的情况下，基于服务契约对第一客户端的接口调用功能进行测试。
20.可选的，上述基于服务契约对第一客户端的接口调用功能进行测试，包括：
21.获取第一客户端发送的调用请求，以及调用请求中的请求信息和服务接口；
22.根据服务契约，对请求信息进行校验；
23.在请求信息校验通过的情况下，基于服务契约生成请求信息的虚拟响应信息；
24.将虚拟响应信息发送给第一客户端。
25.可选的，上述基于服务契约生成请求信息的虚拟响应信息，包括：
26.基于测试属性信息确定与服务接口对应的虚拟接口；
27.基于虚拟接口进行数据处理，并生成针对请求信息的虚拟响应信息。
28.可选的，上述方法还包括：
29.基于服务契约生成接口定义代码；其中，接口定义代码包括前端服务接口代码和后端服务接口代码；
30.根据前端接口代码开发服务前端，以及根据后端接口代码开发服务后端；其中，服务后端的数量为至少两个；
31.将服务后端作为第二客户端；
32.将与第二客户端有依赖关系的服务前端或服务后端作为第一客户端。
33.可选的，上述方法还包括：
34.采集各服务后端的接口定义信息，并基于接口定义信息注册服务后端对应的服务接口；
35.基于服务契约确定各服务接口对应的服务属性信息；
36.针对每一服务接口，当接口定义信息与服务属性信息不一致，则基于服务属性信息更新服务契约。
37.根据本技术实施例的另一个方面，提供了一种测试装置，该装置包括：
38.接收模块，用于接收第一客户端的交互请求，获取交互请求中携带的交互信息以及服务接口；服务接口包括第一客户端与第二客户端之间的交互接口；
39.校验模块，用于根据预设的服务契约，对交互信息进行校验；其中，服务契约为预先配置的；
40.调用模块，用于在交互信息校验通过的情况下，通过服务接口调用第二客户端处理交互请求。
41.可选的，上述装置还包括，配置模块，用于：
42.根据服务接口，配置服务契约；其中，服务契约中包括服务接口的服务属性信息和测试属性信息。
43.可选的，上述校验模块，用于：
44.基于服务属性信息，对交互信息的请求格式进行校验；
45.当请求格式与服务属性信息中的标准请求格式一致，则交互信息校验通过。
46.可选的，上述调用模块，用于：
47.基于第二客户端的功能逻辑处理交互请求，并生成响应信息；
48.基于服务契约对响应信息进行校验；
49.在响应信息校验通过的情况下，向第一客户端发送服务接口响应成功的通知。
50.可选的，上述装置还包括，测试模块，用于：
51.在第一客户端完成开发，且第二客户端未完成开发的情况下，基于服务契约对第一客户端的接口调用功能进行测试。
52.可选的，上述测试模块，还用于：
53.获取第一客户端发送的调用请求，以及调用请求中的请求信息和服务接口；
54.根据服务契约，对请求信息进行校验；
55.在请求信息校验通过的情况下，基于服务契约生成请求信息的虚拟响应信息；
56.将虚拟响应信息发送给第一客户端。
57.可选的，上述测试模块，还用于：
58.基于测试属性信息确定与服务接口对应的虚拟接口；
59.基于虚拟接口进行数据处理，并生成针对请求信息的虚拟响应信息。
60.可选的，上述装置还包括，客户端开发模块，用于：
61.基于服务契约生成接口定义代码；其中，接口定义代码包括前端服务接口代码和后端服务接口代码；
62.根据前端接口代码开发服务前端，以及根据后端接口代码开发服务后端；其中，服务后端的数量为至少两个；
63.将服务后端作为第二客户端；
64.将与第二客户端有依赖关系的服务前端或服务后端作为第一客户端。
65.可选的，上述装置还包括，契约更新模块，用于：
66.采集各服务后端的接口定义信息，并基于接口定义信息注册服务后端对应的服务接口；
67.基于服务契约确定各服务接口对应的服务属性信息；
68.针对每一服务接口，当接口定义信息与服务属性信息不一致，则基于服务属性信息更新服务契约。
69.根据本技术实施例的另一个方面，提供了一种电子设备，该电子设备包括：存储器、处理器及存储在存储器上的计算机程序，上述处理器执行计算机程序以实现本技术实施例第一方面所示方法的步骤。
70.根据本技术实施例的再一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本技术实施例第一方面所示方法的步骤。
71.根据本技术实施例的一个方面，提供了一种计算机程序产品，其包括计算机程序，该计算机程序被处理器执行时实现本技术实施例第一方面所示方法的步骤。
72.本技术实施例提供的技术方案带来的有益效果是：
73.本技术实施例通过接收第一客户端的交互请求，以获取交互请求中携带的交互信息和服务接口；并根据预设的服务契约对交互信息进行校验，并在校验通过的情况下基于服务接口调用第二客户端，以实现对第一客户端交互请求的响应；本技术实施例通过服务契约实现服务接口和接口测试的统一管理，在实际服务接口与服务契约中的信息不一致时，接口测试时会对该问题进行及时暴露，保证了接口测试的准确性；同时，基于服务契约，测试第一客户端和第二客户端的信息交互功能，保障了客户端即微服务之间服务接口的通信，提高了测试效率。
附图说明
74.为了更清楚地说明本技术实施例中的技术方案，下面将对本技术实施例描述中所需要使用的附图作简单地介绍。
75.图1为本技术实施例提供的一种测试方法的应用场景示意图；
76.图2为本技术实施例提供的一种测试方法的流程示意图；
77.图3为本技术实施例提供的一种测试方法中的服务契约开发的流程示意图；
78.图4为本技术实施例提供的一种测试方法中的自测联调的流程示意图；
79.图5为本技术实施例提供的一种测试方法中的集成测试的流程示意图；
80.图6为本技术实施例提供的一种测试方法中的契约更新的流程示意图；
81.图7为本技术实施例提供的一个示例的测试方法的流程示意图；
82.图8为本技术实施例提供的一种测试装置的结构示意图；
83.图9为本技术实施例提供的一种测试电子设备的结构示意图。
具体实施方式
84.下面结合本技术中的附图描述本技术的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本技术实施例的技术方案的示例性描述，对本技术实施例的技术方案不构成限制。
85.本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本技术实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“a和/或b”可以实现为“a”，或者实现为“b”，或者实现为“a和b”。
86.为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术实施方式作进一步地详细描述。
87.微服务架构提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。这些服务通常具备如下特点：
88.1、具备自己的堆栈，包括数据库和数据模型；
89.2、微服务之间通过rest api(representational state transfer application programming interface，表述性状态转移化应用程序接口)、事件流和消息代理的组合相互通信；
90.3、它们是按业务能力组织的，分隔服务的线通常称为有界上下文。
91.微服务在管理人员和项目负责人中与在开发人员中一样受欢迎，原因在于，微服务更好地反映了许多业务主管想要组建和运行其团队以及开发流程的方式。换句话说，微服务是一种架构模型，可以更好地促进所需的运营模型。
92.随着微服务架构的流行和广泛应用，改变了团队的组织方式和协作方式；相比单
体架构，微服务有其优势：服务个体更小、更内聚、业务职责更清晰、可复用性更强、可独立部署等；系统的灵活性和开发效率都有了较大的提升；但同时又引入了一些新的问题，微服务架构本质上是分布式系统架构，各个服务需要配合协同来完成产品的需求；随着拆分服务数量及服务调用复杂度的增加，会面临研发成本呈指数级增长的挑战；发明人发现，现有技术中的问题主要集中在以下几点：
93.1、微服务通常通过api(application programming interface，应用程序接口)接口进行通信。微服务交互双方、多方频繁沟通对接交互调用的接口信息，通过文档或表格来管理，上述文档或表格的内容过多，无法与实际服务接口一起协同管理，影响开发效率。
94.2、由于微服务之间的依赖关系，导致必须等待底层服务先开发完成才能联调对接和集成测试，测试效率低下；
95.3、如果发现被调用服务接口不满足要求、接口缺失、接口无法联调等问题时，需要重新等待版本联调，造成资源和时间上的浪费；
96.4、调用服务与被调用服务随着需求的增加或变更、bug(程序错误)修改、代码重构等因素导致接口发生变更。调用方无法及时获取接口变化而导致整体业务在测试或运行中出现问题。
97.同时，发明人还发现，可以基于一些有效的规范和工具解决上述问题，主要可以采用如下手段：
98.1、基于openapi(一种服务开发的规范，用来描述api的基本信息)和swagger(一种api表达工具，用于实现api规范)制定接口规范、实现sdk(software development kit，软件开发工具包)生成、文档生成，提升开发效率。
99.2、通过接口mock(模拟)工具解决服务之间的开发依赖问题，实现接口数据mock保证联调测试；
100.3、编写契约单元测试用例，实现服务集成契约测试。
101.但是，上述手段还是存在如下问题：
102.1、接口契约、测试契约、接口mock规则各自独立管理；在其中任何一方发生变更时，难以保证各处的同步调整，导致较高的沟通成本；
103.2、接口契约生成代码后，难以保证代码与实际契约定义的一致性；
104.3、接口契约与实际开发接口的一致性，必须通过契约测试用例来保证；对契约测试编写有较高的要求；
105.4、接口与契约的不一致性导致的bug，不能及时暴露；往往要延后的集成测试才能暴露出来，加大了项目实施风险。
106.本技术提供的测试方法、装置、电子设备以及计算机可读存储介质，旨在解决现有技术的如上技术问题。
107.本技术实施例提供了一种测试方法，该方法可以由终端或服务器实现。本技术实施例涉及的终端或服务器通过接收第一客户端的交互请求；并根据预设的服务契约对交互请求中的交互信息进行校验，并在校验通过的情况下基于服务接口调用第二客户端；本技术实施例涉及的终端或服务器通过服务契约实现了服务接口和接口测试的统一管理，提高了服务接口的测试效率。
108.下面通过对几个示例性实施方式的描述，对本技术实施例的技术方案以及本技术
的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。
109.如图1所示，本技术的测试方法，可以应用于图1所示的场景中，具体的，服务器101可以接收第一客户端102的交互请求，以获取交互信息和服务接口，并根据预设的服务契约对交互信息进行校验；在校验通过的情况下基于服务接口调用第二客户端103，已完成对交互请求的响应。
110.图1所示的场景中，上述测试方法可以在服务器中进行，在其他的场景中，也可以在终端中进行。
111.本技术领域技术人员可以理解，这里所使用的“终端”可以是手机、平板电脑、pda(personal digital assistant，个人数字助理)、mid(mobile internet device，移动互联网设备)等；“服务器”可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
112.本技术实施例中提供了一种测试方法，如图2所示，该方法包括：
113.s201，接收第一客户端的交互请求，获取交互请求中携带的交互信息以及服务接口；服务接口包括第一客户端与第二客户端之间的交互接口。
114.其中，第一客户端与第二客户端可以是微服务架构中的服务，第一客户端和第二客户端存在依赖关系，服务之间通过服务接口进行信息交互。
115.具体的，在第一客户端和第二客户端开发完成进行集成测试时，用于进行测试的终端或服务器，可以接收第一客户端发送的交互请求，并根据该交互请求确定第一客户端的交互信息，以及第一客户端和第二客户端的服务接口。
116.s202，根据预设的服务契约，对交互信息进行校验；其中，服务契约为预先配置的。
117.其中，上述服务契约可以是基于oas(openapi specification，openapi接口定义规范)的接口文档，是技术人员预先编写配置的；接口文档就是定义和描述服务接口的文档；接口定义规范(如oas)则是接口的元模型，它详细规定了接口的元素和格式。
118.具体的，用于进行测试的终端或服务器，可以获取技术人员编写的oas服务契约，基于该oas服务契约配置代理服务，并基于该代理服务对交互信息的规格定义进行解析；当规格定义与服务契约中的接口属性相匹配，则该交互信息校验通过；当规格定义与服务契约中的接口属性不匹配，则该交互信息校验不通过。
119.在本技术实施例中，基于oas规范的服务契约的优势在于：服务接口的使用者(front-end developer)、调用者(client)、提供者(server)、维护者(back-end developer)、测试者(tester)可以通过oas规范统一思想，提高信息传达的效率；前端开发人员不需要关心后端开发的语言和平台，也不需要去查看后端的代码或开发文档，真正的做到面向接口文档开发；接口定义文档可以通过代码生成工具生成各种语言形式的框架代码，避免需求变更时导致的数据不一致问题，提高开发效率。
120.s203，在交互信息校验通过的情况下，通过服务接口调用第二客户端处理交互请求。
121.具体的，当交互信息校验通过，用于进行测试的终端或服务器，可以基于代理服务中接口注册的路由信息，向服务接口发出调用请求，服务接口根据该调用请求对第二客户端进行调用，以便第二客户端处理该交互请求；
122.当交互信息校验未通过，用于进行测试的终端或服务器，可以直接向第一客户端返回交互请求与接口规范不匹配的消息。
123.在本技术实施例中，以交互请求为新用户创建请求、第二客户端为新用户创建服务为例进行具体说明。在对第一客户端与第二客户端的服务接口进行测试之前，可以基于oas服务契约配置代理服务；然后用于进行测试的终端或服务器，可以接收第一客户端发送的新用户创建请求，并根据该新用户创建请求确定第一客户端的交互信息。其中，交互信息包括新用户的姓名、性别、手机号、证件信息等属性。接着，根据代理服务对上述交互信息的格式进行解析，验证交互信息中各属性结构是否一致、必选属性是否缺失、属性类型是否一致；其中，例如在对属性类型进行验证时，可以验证手机号是否为11位数字格式等。当上述交互信息校验通过，可以基于代理服务向服务接口发出调用请求，服务接口根据该调用请求调用新用户创建服务，以实现新用户创建服务根据该交互请求进行创建操作，并返回响应数据即新用户id号。
124.本技术实施例通过接收第一客户端的交互请求，以获取交互请求中携带的交互信息和服务接口；并根据预设的服务契约对交互信息进行校验，并在校验通过的情况下基于服务接口调用第二客户端，以实现对第一客户端交互请求的响应；本技术实施例通过服务契约实现服务接口和接口测试的统一管理，在实际服务接口与服务契约中的信息不一致时，接口测试时会对该问题进行及时暴露，保证了接口测试的准确性；同时，基于服务契约，测试第一客户端和第二客户端的信息交互功能，保障了客户端即微服务之间服务接口的通信，提高了测试效率。
125.本技术实施例中提供了一种可能的实现方式，上述步骤s201中的接收第一客户端的交互请求之前，方法包括：
126.根据服务接口，配置服务契约；其中，服务契约中包括服务接口的服务属性信息和测试属性信息。
127.其中，服务契约可以是oas服务契约，是技术人员基于oas3.0的规格扩展机制预先配置的。服务属性信息可以包括针对服务接口的请求格式、响应格式定义信息；测试属性信息可以包括服务接口的测试定义信息。
128.其中，上述规格扩展机制所包括的规格定义属性有：审计日志(x-api-auditlog)、权限(x-api-authority)、接口范围(x-api-scope)、接口mock规则(x-api-faker)、单元测试契约定义(x-api-contracts)等。
129.具体的，用于进行测试的终端或服务器，可以接收技术人员的服务接口配置信息，接着根据oas规范和配置信息生成oas服务契约，然后将oas服务契约推送至git(一个分布式版本控制系统)仓库。
130.本技术实施例中提供了一种可能的实现方式，如图3所示，上述方法还包括：
131.(1)基于服务契约生成接口定义代码；其中，接口定义代码包括前端服务接口代码和后端服务接口代码。
132.具体的，用于进行测试的终端或服务器，可以从git仓库获取服务契约，接着可以采用代码生成工具基于服务契约，生成前端服务接口代码和后端服务接口代码；同时，可以采用测试契约生成工具，基于服务契约生成契约测试代码；然后可以将上述前端服务接口代码、后端服务接口代码以及契约测试代码推送至私服仓库。
133.(2)根据前端接口代码开发服务前端，以及根据后端接口代码开发服务后端；其中，服务后端的数量为至少两个。
134.具体的，用于进行测试的终端或服务器，可以接收技术人员的开发指令，基于开发指令，通过前端接口代码开发服务前端，以及根据后端接口代码开发服务后端。
135.(3)将服务后端作为第二客户端；将与第二客户端有依赖关系的服务前端或服务后端作为第一客户端。
136.在本技术实施例中，该测试方法基于微服务架构的应用场景可以是服务前端对服务后端的服务调用，还可以是服务后端之间的服务调用。
137.本技术实施例中提供了一种可能的实现方式，上述方法还包括：
138.在第一客户端完成开发，且第二客户端未完成开发的情况下，基于服务契约对第一客户端的接口调用功能进行测试。
139.在本技术实施例，在第一客户端所依赖的第二客户端未完成开发的情况下，可以针对开发完成的第一客户端进行自测联调。其中，自测联调的测试步骤将在下文详细介绍。
140.本技术实施例中提供了一种可能的实现方式，如图4所示，上述基于服务契约对第一客户端的接口调用功能进行测试，包括：
141.(1)获取第一客户端发送的调用请求，以及调用请求中的请求信息和服务接口。
142.具体的，用于进行测试的终端或服务器，可以将调用请求推送至代理服务，代理服务根据该调用请求从预设缓存中加载服务契约。
143.(2)根据服务契约，对请求信息进行校验。
144.具体的，用于进行测试的终端或服务器，通过服务契约中所包含的服务接口的服务属性信息，对请求信息的规格定义进行解析；当规格定义与服务契约中的接口属性相匹配，则该请求信息校验通过；当规格定义与服务契约中的接口属性不匹配，则该请求信息校验不通过。
145.(3)在请求信息校验通过的情况下，基于服务契约生成请求信息的虚拟响应信息。
146.具体的，当请求信息校验通过，用于进行测试的终端或服务器，可以基于代理服务调用mock接口，并基于mock接口生成针对请求信息的虚拟响应信息；
147.当交互信息校验未通过，用于进行测试的终端或服务器，可以直接向第一客户端返回调用请求与接口规范不匹配的消息。
148.本技术实施例中提供了一种可能的实现方式，上述基于服务契约生成请求信息的虚拟响应信息，包括：
149.a、基于测试属性信息确定与服务接口对应的虚拟接口。
150.其中，测试属性信息包括mock规则信息，上述mock规则信息用于确定mock接口。
151.具体的，用于进行测试的终端或服务器，可以基于测试属性信息所包括的mock规则信息，确定与服务接口对应的虚拟接口。当该虚拟接口被调用时，可以模拟真实的服务接口进行数据处理。
152.b、基于虚拟接口进行数据处理，并生成针对请求信息的虚拟响应信息。
153.具体的，用于进行测试的终端或服务器可以调用虚拟接口，虚拟接口用于模拟真实的服务接口对调用请求进行处理，并生成虚拟响应信息。
154.(4)将虚拟响应信息发送给第一客户端。
155.其中，虚拟响应信息可以是基于mock规则信息随机生成的。
156.在本技术实施例中，以第一客户端为开发完成的前端服务，调用请求为新用户创建请求为例进行具体说明，在新用户创建服务未开发完成的情况下，可以基于如下方式进行对第一客户端进行自测联调：用于进行测试的终端或服务器，可以将新用户创建请求推送至代理服务，代理服务根据该调用请求从预设缓存中加载服务契约。其中，新用户创建请求包括新用户的姓名、性别、手机号、证件信息等属性信息；接着，通过服务契约中所包含的服务接口的服务属性信息，对请求信息的规格定义进行解析；验证交互信息中各属性信息结构是否一致、必选属性是否缺失、属性类型是否一致；其中，例如在对属性类型进行验证时，验证手机号是否为11位数字格式等。当上述请求信息校验通过，可以基于代理服务调用mock虚拟接口，并基于mock虚拟接口生成针对请求信息的虚拟响应信息；例如，mock虚拟接口可以模拟真实的新用户创建的服务接口，对请求信息进行处理，并随机生成一个新用户的id号作为虚拟响应信息。最后将该id号发送给第一客户端。
157.本技术实施例中提供了一种可能的实现方式，如图5所示，上述步骤s202中的根据预设的服务契约，对交互信息进行校验，包括：
158.(1)基于服务属性信息，对交互信息的请求格式进行校验。
159.在本技术实施例中，当交互信息为包括新用户的姓名、性别、手机号、证件信息等属性，服务属性信息可以包括新用户创建的标准请求格式：交互信息中的属性结构、必选属性设定、属性类型等，例如在限定属性类型时，上述属性类型可以包括姓名的长度限定，手机号的数字位数限定等；可以基于标准请求格式对上述交互信息进行规格检查，验证交互信息中各属性结构是否一致、必选属性是否缺失、属性类型是否一致；其中，例如在对属性类型进行验证时，可以验证手机号是否为11位数字格式等。
160.(2)当请求格式与服务属性信息中的标准请求格式一致，则交互信息校验通过。
161.在本技术实施例中，当交互信息为包括新用户的姓名、性别、手机号、证件信息等属性，服务属性信息可以包括新用户创建的标准请求格式：包括交互信息中的属性结构、必选属性设定、属性类型等，例如在限定属性类型时，上述属性类型可以包括姓名的长度限定，手机号的数字位数限定等；可以基于标准请求格式对上述交互信息进行规格检查，验证交互信息中各属性结构是否一致、必选属性是否缺失、属性类型是否一致；其中，例如在对属性类型进行验证时，可以验证手机号是否为11位数字格式等。当交互信息所包含的信息内容满足上述标准请求格式的要求，则交互信息校验通过；当交互信息中的至少一项不满足上述标准请求格式的要求，则交互信息校验不通过。
162.在本技术实施例中，在第二客户端未开发完成的情况下，基于服务契约，对第一客户端的调用请求进行校验，并基于mock接口对调用请求进行虚拟响应，可以单独对第一客户端进行服务接口的调用测试，提高了微服务架构项目的研发效率，解决了微服务拆分带来的沟通成本大、开发依赖问题导致的研发效率低下的问题。
163.本技术实施例中提供了一种可能的实现方式，上述步骤s203中的通过服务接口调用第二客户端处理交互请求，包括：
164.(1)基于第二客户端的功能逻辑处理交互请求，并生成响应信息。
165.在本技术实施例中，当交互请求为新用户创建请求、第二客户端为新用户创建服务，则基于新用户创建服务的功能逻辑，基于交互请求，生成新用户的id号作为响应信息。
166.(2)基于服务契约对响应信息进行校验。
167.其中，服务契约中的服务属性信息还包括响应信息的标准响应格式，用于进行测试的终端或服务器，可以基于标准响应格式对响应信息进行校验。
168.在本技术实施例中，当交互请求为新用户创建请求、第二客户端为新用户创建服务，则基于新用户创建服务的功能逻辑，基于交互请求，生成新用户的id号作为响应信息。接着，可以从服务契约中获取响应信息的标准响应格式，即新用户id号的格式如限定为三位数字，可以基于标准响应格式对响应信息进行校验。
169.(3)在响应信息校验通过的情况下，向第一客户端发送服务接口响应成功的通知。
170.具体的，当响应信息的格式与标准相应格式一致，则响应信息校验通过；当响应信息的格式与标准相应格式不一致，则响应信息校验不通过。
171.在本技术实施例中，当交互请求为新用户创建请求、第二客户端为新用户创建服务，则基于新用户创建服务的功能逻辑，基于交互请求，生成新用户的id号作为响应信息。接着，可以从服务契约中获取响应信息的标准响应格式，即新用户id号的格式如限定为三位数字，可以基于标准响应格式对响应信息进行校验。新用户的id号的格式与标准响应格式一致，即新用户id号为三位数字，则该响应信息校验通过；则用于进行测试的终端或服务器向第一客户端发动服务接口响应成功的通知。
172.在本技术实施例中，可以基于服务契约对第一客户端的交互请求与第一客户端的响应信息进行校验，可以及时对测试过程中的故障进行定位；同时，在交互请求未通过验证的情况下，不对第二客户端进行调用，有效提升了测试效率和准确。
173.本技术实施例中提供了一种可能的实现方式，如图6所示，上述方法还包括：
174.(1)采集各服务后端的接口定义信息，并基于接口定义信息注册服务后端对应的服务接口。
175.具体的，用于进行测试的终端或服务器，可以基于服务管控模块采集各服务后端的接口定义信息，并对服务接口进行注册，实现了服务接口的统一管理。
176.(2)基于服务契约确定各服务接口对应的服务属性信息。
177.具体的，在采集接口定义信息的同时，用于进行测试的终端或服务器可以从该服务契约中解析出服务接口对应的服务属性信息。
178.(3)针对每一服务接口，当接口定义信息与服务属性信息不一致，则基于服务属性信息更新服务契约。
179.具体的，可以将上述接口定义信息和服务属性信息进行对比，当二者信息不一致，则将上述接口定义信息作为服务契约中，新的服务属性信息。
180.在本技术实施例中，可以每隔预设时间段，采集一次服务后端的接口定义信息，并基于该接口定义信息对服务契约中的服务属性信息进行对比更新，实现了实际服务接口与服务契约的实时匹配。当后端服务随着业务有需求增加或变更、bug修改、代码重构等因素导致服务接口的变更，服务契约能够实时获取该变更并随之更新；实现了服务接口与服务契约的集中化管理，提升了微服务架构项目开发和测试的效率。
181.为了更好的理解上述测试方法，下面结合图7详细阐述一个本技术的测试方法的示例，包括如下步骤：
182.s701，根据服务接口，配置服务契约；其中，服务契约中包括服务接口的服务属性
信息和测试属性信息。
183.其中，服务契约可以是oas服务契约，是技术人员基于oas3.0的规格扩展机制预先配置的。服务属性信息可以包括针对服务接口的请求格式、响应格式定义信息；测试属性信息可以包括服务接口的测试定义信息。
184.具体的，用于进行测试的终端或服务器，可以接收技术人员的服务接口配置信息，接着根据oas规范和配置信息生成oas服务契约，然后将oas服务契约推送至git仓库。
185.s702，基于服务契约生成接口定义代码；其中，接口定义代码包括前端服务接口代码和后端服务接口代码。
186.具体的，用于进行测试的终端或服务器，可以从git仓库获取服务契约，接着可以采用代码生成工具基于服务契约，生成前端服务接口代码和后端服务接口代码；同时，可以采用测试契约生成工具，基于服务契约生成契约测试代码；然后可以将上述前端服务接口代码、后端服务接口代码以及契约测试代码推送至私服仓库。
187.s703，根据前端接口代码开发服务前端，以及根据后端接口代码开发服务后端；其中，服务后端的数量为至少两个。
188.具体的，用于进行测试的终端或服务器，可以接收技术人员的开发指令，基于开发指令，通过前端接口代码开发服务前端，以及根据后端接口代码开发服务后端。
189.s704，将服务后端作为第二客户端；将与第二客户端有依赖关系的服务前端或服务后端作为第一客户端。
190.在本技术实施例中，该测试方法基于微服务架构的应用场景可以是服务前端对服务后端的服务调用，还可以是服务后端之间的服务调用。
191.s705，在第一客户端完成开发，且第二客户端未完成开发的情况下，基于服务契约对第一客户端的接口调用功能进行测试。
192.在本技术实施例中，以第一客户端为开发完成的前端服务，调用请求为新用户创建请求为例进行具体说明，在新用户创建服务未开发完成的情况下，可以基于如下方式进行对第一客户端进行自测联调：用于进行测试的终端或服务器，可以将新用户创建请求推送至代理服务，代理服务根据该调用请求从预设缓存中加载服务契约。其中，新用户创建请求包括新用户的姓名、性别、手机号、证件信息等属性信息；接着，通过服务契约中所包含的服务接口的服务属性信息，对请求信息的规格定义进行解析；验证交互信息中各属性信息结构是否一致、必选属性是否缺失、属性类型是否一致；其中，例如在对属性类型进行验证时，验证手机号是否为11位数字格式等。当上述请求信息校验通过，可以基于代理服务调用mock虚拟接口，并基于mock虚拟接口生成针对请求信息的虚拟响应信息；例如，mock虚拟接口可以模拟真实的新用户创建的服务接口，对请求信息进行处理，并随机生成一个新用户的id号作为虚拟响应信息。最后将该id号发送给第一客户端。
193.s706，在第一客户端和第二客户端都完成开发时，基于服务契约针对上述第一客户端和第二客户端的服务接口进行集成测试。
194.在本技术实施例中，以交互请求为新用户创建请求、第二客户端为新用户创建服务为例进行具体说明。在对第一客户端与第二客户端的服务接口进行测试之前，可以基于oas服务契约配置代理服务；然后用于进行测试的终端或服务器，可以接收第一客户端发送的新用户创建请求，并根据该新用户创建请求确定第一客户端的交互信息。其中，交互信息
包括新用户的姓名、性别、手机号、证件信息等属性。接着，根据代理服务对上述交互信息的格式进行解析，验证交互信息中各属性结构是否一致、必选属性是否缺失、属性类型是否一致；其中，例如在对属性类型进行验证时，验证手机号是否为11位数字格式等。当上述交互信息校验通过，可以基于代理服务向服务接口发出调用请求，服务接口根据该调用请求调用新用户创建服务，以实现新用户创建服务根据该交互请求进行创建操作，并返回响应数据即新用户id号。
195.s707，采集各服务后端的接口定义信息，并基于接口定义信息注册服务后端对应的服务接口。
196.具体的，用于进行测试的终端或服务器，可以基于服务管控模块采集各服务后端的接口定义信息，并对服务接口进行注册，实现了服务接口的统一管理。
197.s708，基于服务契约确定各服务接口对应的服务属性信息。
198.具体的，在采集接口定义信息的同时，用于进行测试的终端或服务器可以从该服务契约中解析出服务接口对应的服务属性信息。
199.s709，针对每一服务接口，当接口定义信息与服务属性信息不一致，则基于服务属性信息更新服务契约。
200.具体的，可以将上述接口定义信息和服务属性信息进行对比，当二者信息不一致，则将上述接口定义信息作为服务契约中，新的服务属性信息。
201.在本技术实施例中，可以每隔预设时间段，采集一次服务后端的接口定义信息，并基于该接口定义信息对服务契约中的服务属性信息进行对比更新，实现了实际服务接口与服务契约的实时匹配。当后端服务随着业务有需求增加或变更、bug修改、代码重构等因素导致服务接口的变更，服务契约能够实时获取该变更并随之更新；实现了服务接口与服务契约的集中化管理，提升了微服务架构项目开发和测试的效率。
202.本技术实施例通过接收第一客户端的交互请求，以获取交互请求中携带的交互信息和服务接口；并根据预设的服务契约对交互信息进行校验，并在校验通过的情况下基于服务接口调用第二客户端，以实现对第一客户端交互请求的响应；本技术实施例通过服务契约实现服务接口和接口测试的统一管理，在实际服务接口与服务契约中的信息不一致时，接口测试时会对该问题进行及时暴露，保证了接口测试的准确性；同时，基于服务契约，测试第一客户端和第二客户端的信息交互功能，保障了客户端即微服务之间服务接口的通信，提高了测试效率。
203.本技术实施例提供了一种测试装置，如图8所示，该测试装置80可以包括：接收模块801、校验模块802和调用模块803；
204.其中，接收模块801，用于接收第一客户端的交互请求，获取交互请求中携带的交互信息以及服务接口；服务接口包括第一客户端与第二客户端之间的交互接口；
205.校验模块802，用于根据预设的服务契约，对交互信息进行校验；其中，服务契约为预先配置的；
206.调用模块803，用于在交互信息校验通过的情况下，通过服务接口调用第二客户端处理交互请求。
207.本技术实施例中提供了一种可能的实现方式，上述装置还包括，配置模块，用于：
208.根据服务接口，配置服务契约；其中，服务契约中包括服务接口的服务属性信息和
测试属性信息。
209.本技术实施例中提供了一种可能的实现方式，上述校验模块802，用于：
210.基于服务属性信息，对交互信息的请求格式进行校验；
211.当请求格式与服务属性信息中的标准请求格式一致，则交互信息校验通过。
212.本技术实施例中提供了一种可能的实现方式，上述调用模块803，用于：
213.基于第二客户端的功能逻辑处理交互请求，并生成响应信息；
214.基于服务契约对响应信息进行校验；
215.在响应信息校验通过的情况下，向第一客户端发送服务接口响应成功的通知。
216.本技术实施例中提供了一种可能的实现方式，上述装置还包括，测试模块，用于：
217.在第一客户端完成开发，且第二客户端未完成开发的情况下，基于服务契约对第一客户端的接口调用功能进行测试。
218.本技术实施例中提供了一种可能的实现方式，上述测试模块，还用于：
219.获取第一客户端发送的调用请求，以及调用请求中的请求信息和服务接口；
220.根据服务契约，对请求信息进行校验；
221.在请求信息校验通过的情况下，基于服务契约生成请求信息的虚拟响应信息；
222.将虚拟响应信息发送给第一客户端。
223.本技术实施例中提供了一种可能的实现方式，上述测试模块，还用于：
224.基于测试属性信息确定与服务接口对应的虚拟接口；
225.基于虚拟接口进行数据处理，并生成针对请求信息的虚拟响应信息。
226.本技术实施例中提供了一种可能的实现方式，上述装置还包括，客户端开发模块，用于：
227.基于服务契约生成接口定义代码；其中，接口定义代码包括前端服务接口代码和后端服务接口代码；
228.根据前端接口代码开发服务前端，以及根据后端接口代码开发服务后端；其中，服务后端的数量为至少两个；
229.将服务后端作为第二客户端；
230.将与第二客户端有依赖关系的服务前端或服务后端作为第一客户端。
231.本技术实施例中提供了一种可能的实现方式，上述装置还包括，契约更新模块，用于：
232.采集各服务后端的接口定义信息，并基于接口定义信息注册服务后端对应的服务接口；
233.基于服务契约确定各服务接口对应的服务属性信息；
234.针对每一服务接口，当接口定义信息与服务属性信息不一致，则基于服务属性信息更新服务契约。
235.本技术实施例的装置可执行本技术实施例所提供的方法，其实现原理相类似，本技术各实施例的装置中的各模块所执行的动作是与本技术各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。
236.本技术实施例通过接收第一客户端的交互请求，以获取交互请求中携带的交互信
息和服务接口；并根据预设的服务契约对交互信息进行校验，并在校验通过的情况下基于服务接口调用第二客户端，以实现对第一客户端交互请求的响应；本技术实施例通过服务契约实现服务接口和接口测试的统一管理，在实际服务接口与服务契约中的信息不一致时，接口测试时会对该问题进行及时暴露，保证了接口测试的准确性；同时，基于服务契约，测试第一客户端和第二客户端的信息交互功能，保障了客户端即微服务之间服务接口的通信，提高了测试效率。
237.本技术实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现测试方法的步骤，与相关技术相比可实现：本技术实施例通过接收第一客户端的交互请求，以获取交互请求中携带的交互信息和服务接口；并根据预设的服务契约对交互信息进行校验，并在校验通过的情况下基于服务接口调用第二客户端，以实现对第一客户端交互请求的响应；本技术实施例通过服务契约实现服务接口和接口测试的统一管理，在实际服务接口与服务契约中的信息不一致时，接口测试时会对该问题进行及时暴露，保证了接口测试的准确性；同时，基于服务契约，测试第一客户端和第二客户端的信息交互功能，保障了客户端即微服务之间服务接口的通信，提高了测试效率。
238.在一个可选实施例中提供了一种电子设备，如图9所示，图9所示的电子设备900包括：处理器901和存储器903。其中，处理器901和存储器903相连，如通过总线902相连。可选地，电子设备900还可以包括收发器904，收发器904可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器904不限于一个，该电子设备900的结构并不构成对本技术实施例的限定。
239.处理器901可以是cpu(central processing unit，中央处理器)，通用处理器，dsp(digital signal processor，数据信号处理器)，asic(application specific integrated circuit，专用集成电路)，fpga(field programmable gate array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本技术公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器901也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。
240.总线902可包括一通路，在上述组件之间传送信息。总线902可以是pci(peripheral component interconnect，外设部件互连标准)总线或eisa(extended industry standard architecture，扩展工业标准结构)总线等。总线902可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
241.存储器903可以是rom(read only memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，ram(random access memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是eeprom(electrically erasable programmable read only memory，电可擦可编程只读存储器)、cd-rom(compact disc read only memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。
242.存储器903用于存储执行本技术实施例的计算机程序，并由处理器901来控制执行。处理器901用于执行存储器903中存储的计算机程序，以实现前述方法实施例所示的步骤。
243.其中，电子设备包括但不限于：诸如移动电话、笔记本电脑、pad等等移动终端以及诸如数字tv、台式计算机等等固定终端。
244.本技术实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。
245.本技术实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行时实现如下情况：
246.本技术实施例通过接收第一客户端的交互请求，以获取交互请求中携带的交互信息和服务接口；并根据预设的服务契约对交互信息进行校验，并在校验通过的情况下基于服务接口调用第二客户端，以实现对第一客户端交互请求的响应；本技术实施例通过服务契约实现服务接口和接口测试的统一管理，在实际服务接口与服务契约中的信息不一致时，接口测试时会对该问题进行及时暴露，保证了接口测试的准确性；同时，基于服务契约，测试第一客户端和第二客户端的信息交互功能，保障了客户端即微服务之间服务接口的通信，提高了测试效率。
247.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除图示或文字描述以外的顺序实施。
248.应该理解的是，虽然本技术实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本技术实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本技术实施例对此不限制。
249.以上所述仅是本技术部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术的方案技术构思的前提下，采用基于本技术技术思想的其他类似实施手段，同样属于本技术实施例的保护范畴。