一种容器服务的测试方法及装置与流程

1.本技术涉及计算机软件测试技术及云技术，尤其涉及一种容器服务的测试方法、装置、电子设备及计算机可读存储介质。


背景技术：

2.云计算(cloud computing)指it基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是it和软件、互联网相关，也可是其他服务。
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.图1是本技术实施例提供的容器服务的测试系统100的架构示意图；
34.图2是本技术实施例提供的服务器200-1的结构示意图；
35.图3a是本技术实施例提供的容器服务的测试方法的一个流程示意图；
36.图3b是本技术实施例提供的容器服务的测试方法的一个流程示意图；
37.图3c是本技术实施例提供的容器服务的测试方法的一个流程示意图；
38.图4是本技术实施例提供的执行测试用例的流程示意图；
39.图5是本技术实施例提供的容器服务的测试方法的流程示意图。
具体实施方式
40.为了使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术作进一步地详细描述，所描述的实施例不应视为对本技术的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本技术保护的范围。
41.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
42.在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
43.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
44.对本技术实施例进行进一步详细说明之前，对本技术实施例中涉及的名词和术语进行说明，本技术实施例中涉及的名词和术语适用于如下的解释。
45.1)docker：一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个容器中，然后发布到任何流行的linux机器上。
46.2)soa：面向服务的体系结构，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口联系起来。
47.3)mock：就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法(即用来在测试过程中，模拟外部环境和对象)。一般地，需要在mock函数(相当于代理函数)里面提供模拟的数据返回来保证被测试函数(被测试函数中包括原函数(即被代理函数))可以准确获取到依赖的数据。
48.4)中转机：记录了基于soa面向服务的体系结构中，各个服务的ip地址/端口(port)、以及接口。
49.5)集成测试：针对soa体系结构中的服务或接口进行的测试。
50.6)测试用例：集成测试的材料，是一种可执行的代码文件，记录某次测试的具体输入参数，以及期待的输出结果。
51.7)标记：指的是记录某个测试用例，与哪些服务/接口有关。标记可以表示集成测试用例对哪些服务/接口进行了覆盖。
52.8)kubernetes，简称k8s，是用8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用。
53.相关技术中，通常所有开发人员共享一套测试环境，测试环境不稳定，将导致所有开发人员进度受阻，测试效率极低；当不同的开发人员对同一接口设置不同的mock数据时，将产生冲突。通过人工的方式记录接口和测试用例的映射关系，这种方式维护成本较高、查找效率较低；当任一接口发生契约更新时，重新回归执行测试用例的处理效率较低。
54.针对上述问题，本技术实施例提供一种容器服务的测试方法、装置、电子设备和计算机可读存储介质，能够提升测试的处理效率，下面说明本技术实施例提供的容器服务的测试方法的示例性应用，本技术实施例提供的容器服务的测试方法可以由服务器实施，例如可以由一个服务器单独实施，也可以由多个服务器(即服务器集群)协同实施。
55.下面，以由多个服务器协同实施为例说明本本技术实施例。参见图1，图1是本技术实施例提供的容器服务的测试系统100的架构示意图。其中，容器服务的测试系统100包括有：服务器集群200、网络300、容器集群500(示例性的示出了容器500-1、容器500-2和容器500-3)以及终端400，将分别进行说明。
56.容器集群500中的容器(示例性的示出了容器500-1、容器500-2和容器500-3)分别安装在服务器集群中对应的服务器中。各个容器用于在任一服务单元被更新后，对包括被更新的服务单元的标签的测试用例进行回归测试；当测试完成后，容器中部署的容器服务(例如，即时通信客户端中的支付代扣支付服务)用于实现客户端410中相应的功能需求。
57.服务器集群200用于接收终端400的业务请求，将业务请求分发给容器集群500中对应的容器，将接收到的容器发送的响应结果，返回给终端400。
58.终端400用于运行客户端410，接收用户发起的业务请求(例如电子支付请求)，客户端410用于根据容器集群500提供的相应的容器服务，向用户输出相应的人机交互界面。
59.网络300用于作为服务器集群200和终端400之间通信的媒介，可以是广域网或者局域网，又或者是二者的组合。
60.在一些实施例中，容器中部署的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本技术实施例中不做限制。
61.接下来，说明本技术实施例提供的用于实施容器服务的测试方法的电子设备的结构，如前所述，本技术实施例提供的电子设备可以是图1中的服务器200-1。参见图2，图2是本技术实施例提供的服务器200-1的结构示意图，图2所示的服务器200-1包括：至少一个处理器210、存储器230、至少一个网络接口220。服务器200-1中的各个组件通过总线系统240耦合在一起。可理解，总线系统240用于实现这些组件之间的连接通信。总线系统240除包括
数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统240。
62.处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(dsp，digital signal processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
63.存储器230可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器230可选地包括在物理位置上远离处理器210的一个或多个存储设备。
64.存储器230包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(rom，read only me mory)，易失性存储器可以是随机存取存储器(ram，random access memor y)。本技术实施例描述的存储器230旨在包括任意适合类型的存储器。
65.在一些实施例中，存储器230能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
66.操作系统231，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。
67.网络通信模块232，用于经由一个或多个(有线或无线)网络接口220到达其他计算设备，示例性的网络接口220包括：蓝牙、无线相容性认证(wifi)、和通用串行总线(usb，universal serial bus)等。
68.在一些实施例中，本技术实施例提供的容器服务的测试装置可以采用软件方式实现，图2示出了存储在存储器230中的容器服务的测试装置233，其可以是程序和插件等形式的软件，包括以下软件模块：运行模块2331、获取模块2332、查找模块2333和测试模块2334，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
69.可以理解的是，本技术实施例提供的容器服务的测试方法可以由一个服务器单独实施，也可以由多个服务器(即服务器集群)协同实施。下面，将以由一个服务器单独实施为例说明本技术实施例提供的容器服务的测试方法。
70.参见图3a，图3a是本技术实施例提供的容器服务的测试方法的一个流程示意图，将结合图3a示出的步骤进行说明。
71.在步骤101中，运行容器服务。其中，容器服务包括多个服务单元；容器服务与开发对象是一一对应的。
72.在一些实施例中，通过在容器集群的每个容器中安装容器服务镜像的方式，在每个容器中运行容器服务；其中，每个容器提供有服务测试接口，以接收用于待执行的测试用例。需要说明的是，由于容器服务与开发对象是一一对应的，即能够在容器集群的每个容器中，针对不同开发人员部署不同的虚拟容器服务，以支持开发人员在各自的容器中进行开发/测试。
73.举例来说，在容器集群的每个容器中安装容器服务镜像的方式，可以通过将每个容器服务都打包为docker容器映像，并将每个容器服务实例部署为容器。docker是一种打
包和部署服务的方式。例如，docker集群框架，可以为kuber netes。其中，每个容器都封装了用于构建容器服务的技术的细节。例如，在容器集群的每个容器中安装相同的容器服务镜像的方式所有容器服务可以以完全相同的方式启动和停止；由于每个服务实例都是隔离的容器，也可以在容器集群的每个容器中安装不同的容器服务镜像的方式为不同开发人员设置不同的虚拟容器，以支持开发人员在各自的容器中开发/测试。
74.本技术实施例，能够通过更改容器服务实例的数量直接扩展和缩小容器服务。在容器集群的每个容器中安装不同的容器服务镜像的方式为不同开发人员设置不同的虚拟容器，解除了对统一测试环境的依赖，提升了开发效率。且支持开发人员在各自容器中随意设置mock数据，避免产生数据冲突。
75.在一些实施例中，多个服务单元可以通过将服务按照多种维度拆分来得到，例如以下至少之一：将容器服务按照业务关联程度拆分成多个服务单元，其中，每个服务单元的业务相互关联；将容器服务按照资源关联程度拆分成多个服务单元，其中，每个服务单元的资源相互依赖。
76.需要说明的是，每个服务单元通过数据序列化机制、应用承载协议和传输控制协议/网际协议(tcp/ip，transmission control protocol/internet protocol)通信实现服务调用，其中，容器服务的应用层承载协议负责界定哪些代码数据时用于服务之间的调用、区分调用的是哪个接口以及各类序列化的数据结构如何放在一起，从而组成一个整体的通信数据块，然后，通过数据序列化机制将返回的响应数据和调用请求关联起来。tcp/ip通信负责将调用请求传送到提供相应服务的服务单元中，并将响应数据返回给发起调用的服务单元。这里，tcp/ip只是常见选择，如果考虑到调用效率和时延，或者广播场景，也可以选用udp或别的通信协议。
77.本技术实施例，将复杂臃肿的单体服务进行细粒度的服务化拆分，每个拆分出来的容器服务各自独立打包部署，从而极大地提高了服务交付的效率。
78.在步骤102中，获取多个测试用例，测试用例中包括与测试用例有关的服务单元的标签。
79.在一些实施例中，容器服务运行在容器中，容器中还运行有中转服务；获取多个包括与测试用例有关的服务单元的标签的测试用例，可以通过以下方式实现：针对多个待执行的测试用例，分别执行以下处理：通过容器服务执行测试用例，并通过中转服务接管容器服务中的多个服务单元在执行测试用例的过程中的调用请求，以确定多个服务单元中与测试用例有关的服务单元；在测试用例中写入与测试用例有关的服务单元的标签。
80.在一些示例中，通过中转服务接管容器服务中的多个服务单元在执行测试用例的过程中的调用请求，可以通过以下方式实现：通过容器服务中的第一服务单元执行测试用例，当测试用例需要调用的目标功能未位于第一服务单元时，向中转服务发送调用请求；通过中转服务解析调用请求，以确定容器服务中包括目标功能的第二服务单元，并向第二服务单元发送调用请求；通过中转服务接收第二服务单元响应调用请求的响应结果，并发送给第一服务单元。
81.举例来说，由于容器服务被拆分为多个服务单元，这些服务单元通过相互调用提供完整的业务服务功能(即目标功能)。但是在执行测试用例时，通过人工来记录服务单元和测试用例的映射关系，会导致测试效率较低。本技术实施例在执行测试用例的过程中，将
服务单元间的调用请求交给中转服务接管，即，在执行测试用例的过程中，当服务单元a需要调用服务单元b，发起调用请求时，通过中转服务解析调用请求，其中，调用请求中包括调用信息和调用对象，基于调用请求向服务单元b发送该调用信息，通过中转服务接收服务单元b响应调用请求的响应结果，将其发送给服务单元a；并记录服务单元a，b之间的调用情况，调用情况包括测试用例覆盖的服务单元。需要说明的是，中转服务用于在测试过程中接管调用请求，在提供业务服务的场景下，可以不使用中转服务进行接管，服务单元a可以直接调用服务单元b。
82.由于互联网的更新换代速度极快，业务服务功能需要即时更新，本技术实施例通过中转服务在测试过程中记录下服务单元和测试用例的映射关系，能够精准查找到需要回归执行的测试用例，提升了回归测试的覆盖精准度。
83.作为示例，通过中转服务解析调用请求，以确定容器服务中包括目标功能的第二服务单元，可以通过以下方式实现：将每个服务单元注册到中转服务中，以使中转服务记录每个服务单元的地址和端口，并基于服务单元的地址和端口响应调用请求。
84.举例来说，每个服务单元预先会注册到中转服务，中转服务的建立可以通过以下方式实现：新建中转服务的连接，即指定通过中转服务接管调用请求；进行中转服务授权，即通过验证中转服务的账号、密码授权进行中转服务；添加进行中转服务的中转通道。需要说明的是，还可以通过验证私钥文件的密码进行授权以加强安全性。
85.在步骤103中，在多个测试用例中查找包括目标测试单元的标签的测试用例，目标测试单元是容器服务的多个服务单元中被更新的服务单元。
86.在一些实施例中，包括与测试用例有关的服务单元的标签的测试用例可以存储在数据库中，数据库用于接收、存储和管理中转服务中生成的带有服务单元的标签的测试用例，以供测试人员通过数据库查询包括目标测试单元的标签的测试用例。即，当容器服务的多个服务单元中的任一服务单元被更新时，通过容器服务根据被更新的服务单元的标签在数据库中查找对应的测试用例。
87.在一些示例中，在多个测试用例中查找包括目标测试单元的标签的测试用例，可以通过测试用例管理平台来实现。测试用例管理平台用于通过客户端页面或web页面向测试人员提供人机交互接口，测试人员可以通过手机或电脑等终端设备连接到该测试用例管理平台上。该测试用例管理平台用于管理数据库中存储的测试用例，同时也供测试人员对测试用例进行查询。具体地，测试用例管理平台显示一测试用例查找界面，测试用例查找界面中显示有查找框，用于供测试人员输入目标测试单元，以查找包括目标测试单元的标签的测试用例，测试用例管理平台通过读取查找框中输入的目标测试单元，查找包括目标测试单元的标签的测试用例，进而完成后续对查找到的测试用例进行回归测试。
88.在本技术实施例中，由于数据库中存储了服务单元与测试用例的对应关系，当任一服务单元被更新时，能够精准查找到与覆盖了该服务单元的测试用例，从而，在后续的回归处理中能够精准执行包括被更新的服务单元的标签的测试用例，提升了测试用例对服务单元的覆盖精准度。
89.在步骤104中，通过容器服务执行查找到的测试用例，以获得对应的测试结果。
90.在一些实施例中，查找到的测试用例包括输入数据、运行条件和脚本文件。参见图3b，图3b是本技术实施例提供的容器服务的测试方法的一个流程示意图，示出了图3a中的
步骤104可以通过步骤1041和步骤1042实现，将结合各步骤进行说明。
91.在步骤1041中，通过容器服务基于输入数据在运行条件中执行脚本文件，得到实际执行结果。
92.在步骤1042中，将实际执行结果和测试用例的组合作为对应的测试结果。
93.在一些实施例中，查找到的测试用例包括：预期执行结果。当实际执行结果与预期执行结果匹配一致时，将测试通过的结果也写入测试结果中；当执行结果与预期执行试结果匹配不一致时，将测试失败的结果也写入测试结果中。
94.在一些实施例中，通过容器服务执行查找到的多个测试用例时，基于测试用例中的输入数据、脚本文件和远程条件生成测试组件，在生成多个测试组件的同时，支持开发人员设置的多个测试组件之间的执行顺序。对于容器服务来说，当接收到测试组件配置完成的指示时，确定多个测试组件之间的执行顺序，并按照执行顺序将多个测试组件组装为测试用例。
95.在一些实施例中，参见图3c，图3c是本技术实施例提供的容器服务的测试方法的一个流程示意图，基于图3a，在步骤104之后，还可以执行步骤105和步骤106，将结合各步骤进行说明。
96.在步骤105中，在容器服务的所有服务单元的历史测试结果中，查找目标测试单元被更新前的历史测试结果。
97.在步骤106中，通过目标测试单元被更新后的测试结果，替换目标测试单元被更新前的历史测试结果。
98.举例来说，历史测试结果中包括测试结果a、b、c、d、e，当某一服务单元更新时，该服务单元覆盖的测试用例，测试结果b、c中包括该测试用例，即可以在容器服务的所有服务单元的历史测试结果a、b、c、d、e中，查找目标测试单元被更新前的历史测试结果b和c。通过目标测试单元被更新后的测试结果b’和c’替换目标测试单元被更新前的历史测试结果b、c。
99.本技术实施例能够精准更新历史测试结果，以快速得到更新后的历史测试结果。
100.在一些实施例中，当目标测试单元的数量为多个时，还可以执行以下步骤：按照调用频率对多个目标测试单元进行降序排序；将降序排序作为对多个目标测试单元进行测试的顺序。
101.在一些示例中，确定需要测试的至少一个目标测试单元；确定目标测试单元对应的测试用例的执行周期；确定执行周期内测试用例的可执行时间段；获取至少一个历史执行周期中每个历史执行周期内的至少一个目标测试单元的历史调用频率；确定每个历史执行周期中可执行时间段内测试用例的标准执行时间；利用历史调用频率和标准执行时间对神经网络模型进行训练，生成训练后的神经网络模型；获取当前的执行周期内的目标时间段中至少一个目标测试单元的当前调用频率；将当前调用频率输入到训练后的神经网络模型中；获取训练后的神经网络模型输出的当前的执行周期中测试用例的执行时间。
102.在本技术实施例中，根据目标测试单元的调用频率确定对目标测试单元进行测试的顺序，以优先测试调用频率高的服务单元，使得测试的顺序更合理化，调用频率通常反映服务单元的需求程度，因此能够更贴近用户需求；本技术实施例可以根据当前的执行周期内服务单元的运行情况，动态预测决定当前的执行周期内测试用例的执行时间，确定合适
的测试用例的执行时间，减轻了开发人员的工作量。
103.在一些实施例中，在执行测试用例过程中，中转服务在记录所调用的服务单元时会将这个服务单元所在的进程号以及该服务单元所在线程的调用栈一同记录下来，一起存储在数据库中。在测试完毕后，中转服务会对数据库中的每条记录按照其服务单元调用的类名称和进程编号进行分类汇总，按照记录的时间戳进行排序，最终形成一个测试用例过程中每个进程各自的服务单元调用序列。检测执行测试用例时服务单元的调用情况，即检测被调用服务单元的进程号是否等于所对应的容器服务的进程号，如果相等才会将其记录到数据库中；如果不相等，确定其为恶意调用表明其恶意性，并不对其进行记录。
104.本技术实施例中，排除对恶意的调用情况的记录，节省容器服务额外的记录操作，以提升测试的效率。
105.下面，将说明本技术实施例在一个实际的应用场景中的示例性应用。以将本技术实施例提供的容器服务的测试方法应用于即时通信客户端中的支付代扣支付的集成测试中为例，本技术实施例的具体实现方案为：基于docker技术，在容器集群的每个容器中安装不同的容器服务镜像的方式为不同开发人员设置不同的虚拟容器，支持开发人员在各自的容器中开发/测试，解除了对统一测试环境的依赖，提升了开发效率。支持开发人员在各自容器中随意设置mock数据，避免导致数据冲突。基于soa技术，当测试用例在执行完毕后，即可获取到该测试用例的调用栈，以及调用栈上的服务/接口(即，服务单元)名称，将服务单元名称标记在测试用例上，这样，通过自动化的方式实现了测试用例和服务单元的映射；当任一接口发生契约变更时，只需通过标记，搜索哪些测试用例覆盖了该服务单元，并重新回归执行这些测试用例，即可迅速对服务单元进行测试，提高了测试效率，提升了测试用例对接口的覆盖精准度。以在容器3中执行测试用例1为例，具体流程如下：
106.首先，中转机接管服务单元在执行测试用例的过程中的调用请求。
107.在一些实施例中，图4示出了三个服务单元(即服务/接口)，即服务单元a、服务单元b及服务单元c，三者之间存在调用关系。中转机(即提供中转服务的服务器)接管服务单元a发起的调用请求1(调用请求1用于尝试调用服务单元b)，即，服务单元a向中转机发起调用请求1.1，中转机获取服务单元b的ip地址和端口，并发起调用请求1.2，以调用服务单元b。需要说明的是，服务单元a、服务单元b和服务单元c会预先注册登录中转机，以使中转机能够记录服务单元a、服务单元b和服务单元c的地址和端口，以便后续中转机基于服务单元的地址和端口响应调用请求。即通过调用1.1和1.2，服务单元a便调用到了服务单元b。同理，当服务单元b，尝试通过发起调用请求2调用服务单元c的时候，也是通过中转机的调用请求2.1和调用请求2.2，发生真实调用行为。
108.需要说明的是，多个服务单元是基于soa技术将单体服务拆分得到的。其中，服务拆分方式有两种方式，一种是纵向拆分，是从业务维度进行拆分，即按照业务的关联程度将关联比较密切的业务作为一个服务单元；还有一种是横向拆分，是从公共且独立功能维度拆分，即按照资源关联程度，将资源相互依赖的业务作分为一个服务单元。
109.其次，当测试用例执行完毕后，中转机将服务单元的标签标记到测试用例中，并存入数据库中。
110.需要说明的是，由于服务单元a、服务单元b和服务单元c会预先注册登录中转机，中转机在测试用例1执行的过程中，中转机基于记录的服务单元a、服务单元b和服务单元c
的地址和端口响应服务单元a、服务单元b和服务单元c发起的调用请求。并将服务单元a、服务单元b、服务单元c作为三个标签，标记到测试用例1上面。
111.再者，当服务单元a被修改时，容器中的服务测试接口根据服务单元a的标签在数据库中查找对应的测试用例，将查找到的测试用例发送给容器中的服务；容器中的服务执行查找到的测试用例以获取对应的测试结果。
112.在一些实施例中，当服务单元a(或者b/c)被开发人员4进行了修改时，容器中的服务测试接口只需要根据服务单元a这个标记去筛选测试用例，可以精确的获取涉及到服务单元a的测试用例(例如测试用例1)，容器中的服务测试接口将查找到的测试用例发送给容器中的服务；容器中的服务只需将测试用例1重新执行一次，就可以对服务单元a进行覆盖回归测试，通过这种方式，提升了测试用例对服务单元的覆盖精准度。
113.下面继续说明本技术实施例提供的容器服务的测试方法的流程示意图进行说明。本技术实施例提供的容器服务的测试方法可以由一个服务器单独实施，参见图5，图5是本技术实施例提供的容器服务的测试方法的流程示意图，本技术实施例提供的容器服务的测试方法包括以下步骤，下面分别进行说明。
114.步骤501：中转服务接收服务单元的注册，记录每个服务单元的地址和端口。
115.步骤502：容器中的服务测试接口接收测试用例，发送给容器中的容器服务。
116.需要说明的是，通过在容器集群的每个容器中安装容器服务镜像的方式，在每个容器中运行容器中的服务。容器中的服务(即容器服务)按照业务关联程度或资源关联程度被拆分成多个服务单元。
117.步骤503：容器中的服务执行测试用例。
118.步骤504：容器中的中转服务接管容器服务中的多个服务单元在执行测试用例的过程中的调用请求，以确定多个服务单元中与测试用例有关的服务单元，在测试用例中写入与测试用例有关的服务单元的标签。
119.以多个服务单元为第一服务单元和第二服务单元为例说明，容器中的服务的第一服务单元执行测试用例1，当测试用例1需要调用的电子支付功能未位于第一服务单元时，第一服务单元向中转服务发送调用请求；中转服务解析调用请求，以确定容器服务中包括电子支付功能为第二服务单元，并向第二服务单元发送调用请求；第二服务单元响应调用请求并返回响应结果给中转服务，中转服务接收第二服务单元的响应结果，并发送给第一服务单元。然后，中转服务将第一服务单元和第二服务单元的标签写入测试用例1中。
120.需要说明的是，步骤501-步骤504是首次执行测试用例的处理方案，步骤505-步骤509是针对服务单元发生更新时的处理方案。
121.步骤505：容器的服务测试接口接收与容器服务有关的多个测试用例，测试用例中包括与所述测试用例有关的服务单元的标签。
122.步骤506：容器的服务测试接口在多个测试用例中查找包括目标测试单元的标签的测试用例。其中，目标测试单元是容器服务的多个服务单元中被更新的服务单元。
123.步骤507：容器的服务测试接口按照调用频率对多个目标测试单元进行降序排序，并按照降序排序发送给容器中的容器服务。
124.步骤508：容器服务按照降序排序顺序执行查找到的测试用例，以获得对应的测试结果，并发送给服务测试接口。
125.步骤509：容器的服务测试接口在所有服务单元的历史测试结果中，查找目标测试单元被更新前的历史测试结果；通过目标测试单元被更新后的测试结果，替换目标测试单元被更新前的历史测试结果。
126.本技术上述实施例，通过中转服务将与测试用例有关的服务单元的标签标记在测试用例中，实现了测试用例和服务单元的自动化映射，能够节约维护成本，提高查找效率；在多个测试用例中查找包括被更新的服务单元的标签的测试用例，通过容器服务执行查找到的测试用例，能够精准执行包括被更新的服务单元的标签的测试用例，提升测试用例对服务单元的覆盖精准度。
127.下面继续说明本技术实施例提供的容器服务的测试装置233的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器230的容器服务的测试装置233中的软件模块可以包括：
128.运行模块2331，用于运行容器服务；其中，所述容器服务包括多个服务单元；所述容器服务与开发对象是一一对应的；获取模块2332，用于获取多个测试用例，所述测试用例中包括与所述测试用例有关的服务单元的标签；查找模块2333，用于在所述多个测试用例中查找包括目标测试单元的标签的测试用例，所述目标测试单元是所述容器服务的多个服务单元中被更新的服务单元；测试模块2334，用于通过所述容器服务执行查找到的测试用例，以获得对应的测试结果。
129.在一些实施例中，所述容器服务运行在容器中，所述容器中还运行有中转服务；所述获取模块2332，还用于针对多个待执行的测试用例，分别执行以下处理：通过所述容器服务执行所述测试用例，并通过所述中转服务接管所述容器服务中的多个服务单元在执行所述测试用例的过程中的调用请求，以确定所述多个服务单元中与所述测试用例有关的服务单元；在所述测试用例中写入与所述测试用例有关的服务单元的标签。
130.在一些实施例中，所述获取模块2332，还用于通过所述容器服务中的第一服务单元执行所述测试用例，当所述测试用例需要调用的目标功能未位于第一服务单元时，向所述中转服务发送调用请求；通过所述中转服务解析所述调用请求，以确定所述容器服务中包括所述目标功能的第二服务单元，并向所述第二服务单元发送所述调用请求；通过所述中转服务接收所述第二服务单元响应所述调用请求的响应结果，并发送给所述第一服务单元。
131.在一些实施例中，所述获取模块2332，还用于将每个所述服务单元注册到所述中转服务中，以使所述中转服务记录每个所述服务单元的地址和端口，并基于所述服务单元的地址和端口响应所述调用请求。
132.在一些实施例中，所述多个服务单元是通过执行以下操作中的至少之一得到的：将所述容器服务按照业务关联程度拆分成所述多个服务单元，其中，每个所述服务单元的业务相互关联；将所述容器服务按照资源关联程度拆分成所述多个服务单元，其中，每个所述服务单元的资源相互依赖。
133.在一些实施例中，所述测试模块2334，还用于在所述容器服务的所有服务单元的历史测试结果中，查找所述目标测试单元被更新前的历史测试结果；通过所述目标测试单元被更新后的测试结果，替换所述目标测试单元被更新前的历史测试结果。
134.在一些实施例中，当所述目标测试单元的数量为多个时，所述测试模块2334，还用
于按照调用频率对所述多个目标测试单元进行降序排序；将所述降序排序作为对所述多个目标测试单元进行测试的顺序。
135.在一些实施例中，所述容器服务被部署在容器集群中；所述运行模块2331，还用于通过在所述容器集群的每个容器中安装容器服务镜像的方式，在所述每个容器中运行所述容器服务；其中，每个所述容器提供有服务测试接口，以接收用于待执行的测试用例。
136.在一些实施例中，所述查找到的测试用例包括输入数据、运行条件和脚本文件；所述测试模块2334，还用于通过所述容器服务基于所述输入数据在所述运行条件中执行所述脚本文件，得到实际执行结果；将所述实际执行结果和所述测试用例的组合作为所述对应的测试结果。
137.本技术实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本技术实施例上述的容器服务的测试方法。
138.本技术实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本技术实施例提供的容器服务的测试方法，例如，如图3a、3b、3c示出的容器服务的测试方法。
139.在一些实施例中，计算机可读存储介质可以是fram、rom、prom、eprom、eeprom、闪存、磁表面存储器、光盘、或cd-rom等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
140.在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
141.作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(html，hyper text markup language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
142.作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
143.综上所述，通过本技术实施例将与测试用例有关的服务单元的标签标记在测试用例中，以实现测试用例和服务单元的自动化映射，能够节约维护成本，提高查找效率；在多个测试用例中查找包括被更新的服务单元的标签的测试用例，通过容器服务执行查找到的测试用例，能够精准执行包括被更新的服务单元的标签的测试用例，提升测试用例对服务单元的覆盖精准度；根据目标测试单元的调用频率确定对目标测试单元进行测试的顺序，以优先测试调用频率高的服务单元，使得测试的顺序更合理化，调用频率通常反映服务单元的需求程度，因此能够更贴近用户需求；本技术实施例可以根据当前的执行周期内服务单元的运行情况，动态预测决定当前的执行周期内测试用例的执行时间，确定合适的测试用例的执行时间，减轻了开发人员的工作量。
144.以上所述，仅为本技术的实施例而已，并非用于限定本技术的保护范围。凡在本技术的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本技术的保护范围之内。