SDK测试方法、介质及装置与流程

sdk测试方法、介质及装置
技术领域
1.本公开的实施方式涉及软件开发测试技术领域，更具体地，本公开的实施方式涉及sdk测试方法、介质及装置。


背景技术：

2.本部分旨在为本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.软件开发工具包(software development kit，sdk)一般是指软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合，开发人员一般利用该sdk进行应用程序开发，用于快速建立应用软件。为了检测sdk是否满足开发人员所建立的应用程序的要求，需要进行sdk测试，来分析sdk的质量，从而保证应用程序开发的质量和效率。
4.相关技术中，在进行sdk测试过程中，需要用户手动操作，测试效率较低。


技术实现要素：

5.本公开提供一种sdk测试方法、介质及装置，以实现对sdk多版本的自动化测试，提高测试效率。
6.在本公开实施方式的第一方面中，提供了一种sdk测试方法，包括：确定sdk的待测试版本，并获取待测试版本中每一个测试版本的列表信息；基于每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据；根据每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得每一个测试版本对应的待测试代码；对每一个测试版本对应的待测试代码进行测试，获得测试结果。
7.在本公开的一个实施例中，所述根据每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得每一个测试版本对应的待测试代码，包括：获取sdk的预设测试版本对应的待测试代码；根据所述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，对所述预设测试版本对应的待测试代码进行调整，获得所述每一个测试版本对应的待测试代码。
8.在本公开的另一实施例中，所述根据所述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，对所述预设测试版本对应的待测试代码进行调整，获得所述每一个测试版本对应的待测试代码，包括：根据所述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，调整所述预设测试版本对应的待测试代码中相应依赖包的版本数据，获得所述每一个测试版本对应的待测试代码。
9.在本公开的再一个实施例中，所述对每一个测试版本对应的待测试代码进行测试，获得测试结果，包括：确定sdk每一api对应的处理数据流；根据所述每一api对应的处理数据流，获得sdk全链路测试用例集；基于所述sdk全链路测试用例集，对所述每一个测试版
本对应的待测试代码进行测试，获得测试结果。
10.在本公开的又一个实施例中，所述根据所述每一api对应的处理数据流，获得sdk全链路测试用例集，包括：确定所述每一api对应的处理数据流中的目标事件，所述目标事件为处理数据流中能够引起数据状态发生变化的事件；根据所述目标事件，构建所述sdk全链路测试用例集。
11.在本公开的又一个实施例中，所述根据所述目标事件，构建所述sdk全链路测试用例集，包括：根据所述目标事件中每一事件引起数据状态发生变化的数据，确定每一事件对应的待查看数据；基于所述目标事件中每一事件，以及所述每一事件对应的待查看数据，构建所述sdk全链路测试用例集。
12.在本公开的又一个实施例中，所述确定sdk的待测试版本，包括：确定sdk正在被使用的版本；将所述正在被使用的版本作为sdk的待测试版本。
13.在本公开的又一个实施例中，在所述对所述每一个测试版本对应的待测试代码进行测试，获得测试结果之前，还包括：部署测试环境；所述对所述每一个测试版本对应的待测试代码进行测试，获得测试结果，包括：在所述测试环境，对所述每一个测试版本对应的待测试代码进行测试，获得测试结果。
14.在本公开实施方式的第二方面中，提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如第一方面提供的sdk测试方法。
15.在本公开实施方式的第三方面中，提供了一种sdk测试装置，包括：第一确定模块，用于确定sdk的待测试版本，并获取所述待测试版本中每一个测试版本的列表信息；第二确定模块，用于基于所述每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据；获得模块，用于根据所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得所述每一个测试版本对应的待测试代码；测试模块，用于对所述每一个测试版本对应的待测试代码进行测试，获得测试结果。
16.在本公开的一个实施例中，所述获得模块，具体用于：获取sdk的预设测试版本对应的待测试代码；根据所述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，对所述预设测试版本对应的待测试代码进行调整，获得所述每一个测试版本对应的待测试代码。
17.在本公开的另一个实施例中，所述获得模块，具体用于：根据所述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，调整所述预设测试版本对应的待测试代码中相应依赖包的版本数据，获得所述每一个测试版本对应的待测试代码。
18.在本公开的再一个实施例中，所述测试模块，具体用于：确定sdk每一api对应的处理数据流；根据所述每一api对应的处理数据流，获得sdk全链路测试用例集；基于所述sdk全链路测试用例集，对所述每一个测试版本对应的待测试代码进行测试，获得测试结果。
19.在本公开的又一个实施例中，所述测试模块，具体用于：确定所述每一api对应的处理数据流中的目标事件，所述目标事件为处理数据流中能够引起数据状态发生变化的事件；根据所述目标事件，构建所述sdk全链路测试用例集。
20.在本公开的又一个实施例中，所述测试模块，具体用于：根据所述目标事件中每一
事件引起数据状态发生变化的数据，确定每一事件对应的待查看数据；基于所述目标事件中每一事件，以及所述每一事件对应的待查看数据，构建所述sdk全链路测试用例集。
21.在本公开的又一个实施例中，所述第一确定模块，具体用于：确定sdk正在被使用的版本；将所述正在被使用的版本作为sdk的待测试版本。
22.在本公开的又一个实施例中，所述测试模块，具体用于：部署测试环境；在所述测试环境，对所述每一个测试版本对应的待测试代码进行测试，获得测试结果。
23.在本公开实施方式的第四方面中，提供了一种计算设备，包括：至少一个处理器和存储器；存储器存储计算机执行指令；至少一个处理器执行存储器存储的计算机执行指令，使得至少一个处理器执行如第一方面提供的sdk测试方法。
24.在本公开实施方式中，在确定sdk的待测试版本后，基于其中每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据，从而，根据每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得每一个测试版本对应的待测试代码，进行测试，提供了一种对sdk的多个版本进行自动化测试的方式，不仅提高测试效率，而且测试过程无需人工参与，减少人力成本。
附图说明
25.通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：
26.图1示意性地示出了根据本公开实施方式提供的应用场景示意图；
27.图2示意性地示出了根据本公开一实施例提供的sdk测试方法的流程示意图；
28.图3示意性地示出了根据本公开一实施例提供的sdk测试的整体流程示意图；
29.图4示意性地示出了根据本公开另一实施例提供的sdk测试方法的流程示意图；
30.图5示意性地示出了根据本公开再一实施例提供的sdk测试方法的流程示意图；
31.图6示意性地示出了根据本公开一实施例提供的sdk一api的调用链路示意图；
32.图7示意性地示出了根据本公开一实施例提供的存储介质的结构示意图；
33.图8示意性地示出了根据本公开一实施例提供的sdk测试装置的结构示意图；
34.图9示意性地示出了根据本公开一实施例提供的计算设备的结构示意图。
35.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
36.下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
37.本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
38.根据本公开的实施方式，提出了一种sdk测试方法、介质及装置。
computer，pc))、车载设备、可穿戴设备(例如智能手表、智能手环)、智能家居设备(例如智能显示设备)等。
55.服务器可以是整体式服务器或是跨多计算机或计算机数据中心的分散式服务器。服务器还可以是各种类别的，例如但不限于，网络服务器，应用服务器，或数据库服务器，或代理服务器。
56.可选的，服务器可以包括硬件，软件，或用于执行服务器所支持或实现的合适功能的内嵌逻辑组件或两个或多个此类组件的组合。例如，服务器例如刀片服务器、云端服务器等，或者可以是由多台服务器组成的服务器群组，可以包括上述类别的服务器中的一种或多种等等。
57.需要说明的是，根据本公开示例性实施方式提供的sdk测试方法，可以在同一设备上执行，也可以在不同设备上执行。
58.参考图2，图2示意性地示出了根据本公开一实施例提供的sdk测试方法的流程示意图。本实施例的执行主体可以根据实际应用场景确定，本公开实施例对此不做特别限制。如图2所示，sdk测试方法包括：
59.s201、确定sdk的待测试版本，并获取该待测试版本中每一个测试版本的列表信息。
60.这里，本实施例可以确定sdk正在被使用的版本，将正在被使用的版本作为sdk的待测试版本。即本实施例对sdk正在被使用的版本进行测试，以分析sdk正在被使用的版本的质量，从而，提高基于sdk正在被使用的版本所开发的应用程序的质量和效率。
61.示例性的，本实施例在确定sdk的待测试版本后，可以从预设存储单元获取该待测试版本中每一个测试版本的列表信息。其中，上述预设存储单元预先存储sdk的多个版本的列表信息，该列表信息包括sdk的每一版本的标识、每一版本中的各个依赖包标识和各个依赖包的版本数据。
62.本实施例可以基于sdk的待测试版本的标识，在从预设存储单元获取该待测试版本中每一个测试版本的各个依赖包标识和各个依赖包的版本数据。其中，上述预设存储单元可以根据实际情况设置，例如将maven仓库设置为预设存储单元。
63.s202、基于上述每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据。
64.可选地，本实施例可以基于从预设存储单元获取的待测试版本中每一个测试版本的各个依赖包标识和各个依赖包的版本数据，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据，并拼装成预设格式，如js对象简谱(javascript object notation，json)格式，以方便后续数据处理。
65.其中，本实施例在进行上述拼装时，可以先基于每一个测试版本中的各个依赖包和各个依赖包的版本数据，获取每一个测试版本的标识，每一个测试版本中的各个依赖包的标识，以及各个依赖包的版本数据，进而，根据每一个测试版本的标识，每一个测试版本中的各个依赖包的标识，以及各个依赖包的版本数据，拼装成预设格式。
66.示例性的，以上述预设格式为json格式，上述测试版本的标识为测试版本的名称，上述依赖包的标识为依赖包的名称为例，本实施例如果确定某一测试版本的标识，即测试版本的名称为“tf保障-2.4.0-snapshot”，该测试版本有两个依赖包，如一个依赖包的标
识，即依赖包的名称为“music-gorilla-gateway-client”，依赖包的版本为“2.4.0-snapshot”，另一个依赖包的标识，即依赖包的名称为“music-gorilla-gateway-client-async”，依赖包的版本为“2.1.0”，进而可以将上述每一依赖包的标识与相应的版本拼装在一起，然后再将各个依赖包拼装后的数据拼装在上述测试版本“tf保障-2.4.0-snapshot”下面，从而，可以将每一个测试版本的标识，每一个测试版本中的各个依赖包的标识，以及各个依赖包的版本数据，拼装成json格式。其中，整个json是一个数组，数组的每个值是一个sdk的版本。
67.s203、根据上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得上述每一个测试版本对应的待测试代码。
68.这里，本实施例可以循环遍历上述拼装后的数据，例如循环遍历上述json数组，首先对数组中的第一个测试版本进行处理，并在处理完成后，依次处理下一个测试版本，直至数组中所有测试版本都处理完成。
69.对于每一测试版本，本实施例可以先获取sdk预设测试版本对应的待测试代码，从而，根据上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，修改上述sdk预设测试版本对应的待测试代码，获得上述每一个测试版本对应的待测试代码。
70.其中，上述sdk预设测试版本可以根据实际情况设置，例如将sdk的待测试版本之前使用的sdk的版本设置为上述sdk预设测试版本。
71.s204、对上述每一个测试版本对应的待测试代码进行测试，获得测试结果。
72.在本实施例中，在进行测试之前还考虑部署测试环境，以便后续在部署好的测试环境中，对上述每一个测试版本对应的待测试代码进行测试，获得测试结果，保证测试正常进行。
73.在本公开的一个实施例中，本实施例在对上述每一个测试版本对应的待测试代码进行测试时，可以基于测试用例进行测试，并在获得测试结果后，进行断言，确定上述每一个测试版本的测试情况。例如以sdk多版本兼容性测试为例，上述预期结果基于多版本之间兼容特性设置，本实施例在获得测试结果后，进行断言，将每一个测试版本的测试结果与预期结果进行比较，如果某一测试版本的测试结果与预期结果一致，则确定该测试版本通过多版本兼容性测试，如果某一测试版本的测试结果与预期结果不一致，则确定该测试版本没有通过多版本兼容性测试。
74.这里，为了更好的理解本实施例，图3以本实施例的执行主体为图1中的控制设备为例对方案进行说明。在进行sdk测试时，例如进行sdk多版本兼容性测试，控制设备可以发起sdk多版本的http接口，确定sdk的待测试版本，进而，从预设存储单元获取上述待测试版本中每一个测试版本的列表信息，从而，基于每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据。对于一个测试版本，控制设备可以从测试设备拉取其中存储的sdk预设测试版本对应的待测试代码，进而，根据上述测试版本中的各个依赖包和各个依赖包的版本数据，修改上述sdk预设测试版本对应的待测试代码，获得上述测试版本对应的待测试代码，并进行代码提交。其中，控制设备还提供一个接口，如git webhook接口，当有代码提交时，会触发测试设备部署，以部署好后续代码测试的测试环境，从而，控制设备在部署好的测试环境中，对上述测试版本对应的待测试代码进行测试，获得测试结果。其中，控制设备可以基于测试用例，如sdk全链路测试用例集，对上述测试版本对
应的待测试代码进行测试，获得测试结果。而且，在上述测试版本测试完成后，控制设备继续进行下一个sdk版本的测试，直至sdk的待测试版本中所有测试版本都测试完成，实现对sdk多版本的自动化测试，提高测试效率。
75.可选地，本实施例提供的sdk测试方法还可以进行平台化，将sdk的选择，及测试用例，如sdk全链路测试用例集做成可选择，供其它有sdk测试的需求接入，满足多种应用需要。
76.本公开实施例中，在确定sdk的待测试版本后，基于其中每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据，从而，根据每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得每一个测试版本对应的待测试代码，进行测试，实现对sdk多个版本的自动化测试，不仅提高测试效率，而且测试过程无需人工参与，减少人力成本。
77.另外，本公开实施例在根据上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，修改上述sdk预设测试版本对应的待测试代码时，可以根据上述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，对上述预设测试版本对应的待测试代码进行调整，从而获得上述每一个测试版本对应的待测试代码，以便后续基于每一个测试版本对应的待测试代码，进行测试，提供一种对sdk的多个版本进行自动化测试的方式，提高测试效率。图4为本公开另一实施例提供的sdk测试方法的流程示意图，如图4所示，该方法包括：
78.s401、确定sdk的待测试版本，并获取该待测试版本中每一个测试版本的列表信息。
79.s402、基于上述每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据。
80.其中，步骤s401-s402的实现方式参见图2实施例中的相关描述，此处不再赘述。
81.s403、获取sdk的预设测试版本对应的待测试代码，根据上述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，对上述预设测试版本对应的待测试代码进行调整，获得上述每一个测试版本对应的待测试代码。
82.可选地，本实施例在对上述预设测试版本对应的待测试代码进行调整时，可以根据上述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，调整上述预设测试版本对应的待测试代码中相应依赖包的版本数据，从而，获得上述每一个测试版本对应的待测试代码。
83.其中，上述预设测试版本对应的待测试代码包括上述预设测试版本中的各个依赖包和各个依赖包的版本数据。本实施例根据上述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，调整上述预设测试版本对应的待测试代码中相应依赖包的版本数据，准确快速地获得上述每一个测试版本对应的待测试代码，保证后续处理正常进行，提高sdk测试效率。
84.s404、对上述每一个测试版本对应的待测试代码进行测试，获得测试结果。
85.其中，步骤s404的实现方式参见图2实施例中的相关描述，此处不再赘述。
86.本公开实施例中，在根据上述每一个测试版本中的各个依赖包和各个依赖包的版
本数据，修改上述sdk预设测试版本对应的待测试代码时，根据上述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，对上述预设测试版本对应的待测试代码进行调整，获得上述每一个测试版本对应的待测试代码，进行测试，提供了一种对sdk的多个版本进行自动化测试的方式，提高测试效率，减少人力成本。
87.另外，本公开实施例对上述每一个测试版本对应的待测试代码进行测试时，考虑到如果通过单元测试的方式，不太容易顾及到整条链路的数据流，尤其对复杂链路，会存在场景的缺失，而且单元测试用例较多时，维护起来也需要成本，因此，构造sdk全链路测试用例集，基于该sdk全链路测试用例集，对上述每一个测试版本对应的待测试代码进行测试，解决上述通过单元测试的方式存在场景缺失的问题，也降低维护成本。图5为本公开再一实施例提供的sdk测试方法的流程示意图，如图5所示，该方法包括：
88.s501、确定sdk的待测试版本，并获取该待测试版本中每一个测试版本的列表信息。
89.s502、基于上述每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据。
90.s503、根据上述每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得上述每一个测试版本对应的待测试代码。
91.其中，步骤s501-s503的实现方式参见图2实施例中的相关描述，此处不再赘述。
92.s504、确定sdk每一应用程序编程接口(applicationprogramminginterface，api)对应的处理数据流。
93.这里，以图6所示的sdk一api的调用链路为例，该链路中的服务之间会存在大量的异步消息队列(message queue，mq)消息，远程过程调用(remote procedure call，rpc)接口，及超文本传输协议(hyper text transfer protocol，http)接口。当外部供应商返回一个状态时，链路上各个服务的数据库会更新成一个状态，当外部供应商更新成另外一个结果时，链路上各个服务的数据库对应的字段也会更新。如果通过单元测试的方式进行sdk测试无法覆盖到整条链路上的状态变化。
94.因此，本实施例在进行sdk测试时，通过确定sdk每一api对应的处理数据流，进而，基于该数据流，获得sdk全链路测试用例集，基于该全链路测试用例集，对上述每一个测试版本对应的待测试代码进行测试，以覆盖到整条链路上的状态变化。
95.s505、根据上述每一api对应的处理数据流，获得sdk全链路测试用例集。
96.可选地，本实施例在根据上述每一api对应的处理数据流，获得sdk全链路测试用例集时，可以先确定上述每一api对应的处理数据流中的目标事件，该目标事件为处理数据流中能够引起数据状态发生变化的事件，进而，根据该目标事件，构建上述sdk全链路测试用例集。
97.示例性的，本实施例可以根据上述目标事件中每一事件引起数据状态发生变化的数据，确定每一事件对应的待查看数据，从而，基于上述目标事件中每一事件，以及每一事件对应的待查看数据，构建上述sdk全链路测试用例集。
98.例如以图6为例，本实施例确定该链路的处理数据流中的目标事件，如业务方抄送数据、供应商回调等，进而，根据该目标事件中每一事件引起数据状态发生变化的数据，确
定每一事件对应的待查看数据，如业务方抄送数据引起网关servicea的数据库dba，后置主题服务serviceb的数据库dbb，以及三方servicec的数据库dbc中的数据状态发生变化，确定该事件对应的待查看数据为网关servicea的数据库dba，后置主题服务serviceb的数据库dbb，以及三方servicec的数据库dbc中的数据，从而，基于上述目标事件中每一事件，以及每一事件对应的待查看数据，构建sdk全链路测试用例集进行测试，如根据上述网关servicea的数据库dba，后置主题服务serviceb的数据库dbb，以及三方servicec的数据库dbc中的数据，构建测试用例，用于测试网关servicea的数据库dba，后置主题服务serviceb的数据库dbb，以及三方servicec的数据库dbc中的数据变化是否符合预期，以实现sdk全链路测试。
99.其中，在基于上述sdk全链路测试用例集，对上述每一个测试版本对应的待测试代码进行测试时，本实施例还可以设置接口，用于对每一api对应的处理数据流中的目标事件中，每一事件对应的待查看数据进行捞取，以便后续基于上述sdk全链路测试用例集，快速准确地校验出数据变化是否符合预期。例如在上述构建测试用例，用于测试网关servicea的数据库dba，后置主题服务serviceb的数据库dbb，以及三方servicec的数据库dbc中的数据变化是否符合预期时，本实施例还可以设置接口，用于把整条链路上的数据库中数据捞出来，即把网关servicea的数据库dba，后置主题服务serviceb的数据库dbb，以及三方servicec的数据库dbc中的数据捞出来，然后基于上述测试用例，校验数据变化是否符合预期。
100.进一步地，以图6所示的链路中的目标事件：业务方抄送数据、供应商回调一次和供应商回调两次为例，本实施例在基于sdk全链路测试用例集，对上述每一个测试版本对应的待测试代码进行测试时，可以针对业务方抄送数据事件，设置a接口，对事件对应的待查看数据进行捞取，例如可以将sdk提供的api封装成http接口，可以默认任意业务方的调用。针对供应商回调一次事件，可以设置b接口，对事件对应的待查看数据进行捞取，例如可以将整条链路上数据库db信息封装成json的接口，返回的是网关servicea的dba，后置主题服务serviceb的dbb，以及三方servicec的dbc，3个数据库里的数据。针对供应商回调两次事件，可以设置c接口，对事件对应的待查看数据进行捞取，例如可以模拟供应商返回的结果，供应商处理机器处理的结果，还有人审的结果。
101.s506、基于上述sdk全链路测试用例集，对上述每一个测试版本对应的待测试代码进行测试，获得测试结果。
102.其中，步骤s506的实现方式参见图2实施例中的相关描述，此处不再赘述。
103.本公开实施例中，在对上述每一个测试版本对应的待测试代码进行测试时，构成sdk全链路测试用例集，基于该sdk全链路测试用例集，对上述每一个测试版本对应的待测试代码进行测试，解决通过单元测试的方式存在场景缺失的问题，也降低维护成本。而且，本公开实施例实现对sdk多个版本的自动化测试，提高测试效率，减少人力成本。
104.示例性介质
105.在介绍了本公开示例性实施方式的方法之后，接下来，参考图7对本公开示例性实施方式的存储介质进行说明。
106.参考图7所示，存储介质70中存储着根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终
端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。
107.所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
108.可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。
109.可以以一种或多种程序设计语言的任意组合来编写用于执行本公开公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备。
110.示例性装置
111.在介绍了本公开示例性实施方式的介质之后，接下来，参考图8对本公开示例性实施方式的sdk测试装置进行说明，其中，sdk测试装置用于实现上述任一方法实施例提供的sdk测试方法，其实现原理和技术效果类似，在此不再赘述。
112.参考图8，图8为本公开一实施例提供的sdk测试装置的结构示意图。如图8所示，sdk测试装置包括：
113.第一确定模块801，用于确定sdk的待测试版本，并获取所述待测试版本中每一个测试版本的列表信息。
114.第二确定模块802，用于基于所述每一个测试版本的列表信息，确定每一个测试版本中的各个依赖包和各个依赖包的版本数据。
115.获得模块803，用于根据所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，获得所述每一个测试版本对应的待测试代码。
116.测试模块804，用于对所述每一个测试版本对应的待测试代码进行测试，获得测试结果。
117.在本公开的一个实施例中，所述获得模块803，具体用于：
118.获取sdk的预设测试版本对应的待测试代码；根据所述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，对所述预设测试版本对应的待测试代码进行调整，获得所述每一个测试版本对应的待测试代码。
119.在本公开的另一个实施例中，所述获得模块803，具体用于：
120.根据所述预设测试版本中的各个依赖包和各个依赖包的版本数据，以及所述每一个测试版本中的各个依赖包和各个依赖包的版本数据，调整所述预设测试版本对应的待测试代码中相应依赖包的版本数据，获得所述每一个测试版本对应的待测试代码。
121.在本公开的再一个实施例中，所述测试模块804，具体用于：
122.确定sdk每一api对应的处理数据流；根据所述每一api对应的处理数据流，获得sdk全链路测试用例集；基于所述sdk全链路测试用例集，对所述每一个测试版本对应的待测试代码进行测试，获得测试结果。
123.在本公开的又一个实施例中，所述测试模块804，具体用于：
124.确定所述每一api对应的处理数据流中的目标事件，所述目标事件为处理数据流中能够引起数据状态发生变化的事件；根据所述目标事件，构建所述sdk全链路测试用例集。
125.在本公开的又一个实施例中，所述测试模块804，具体用于：
126.根据所述目标事件中每一事件引起数据状态发生变化的数据，确定每一事件对应的待查看数据；基于所述目标事件中每一事件，以及所述每一事件对应的待查看数据，构建所述sdk全链路测试用例集。
127.在本公开的又一个实施例中，所述第一确定模块801，具体用于：
128.确定sdk正在被使用的版本；将所述正在被使用的版本作为sdk的待测试版本。
129.在本公开的又一个实施例中，所述测试模块804，具体用于：部署测试环境；在所述测试环境，对所述每一个测试版本对应的待测试代码进行测试，获得测试结果。
130.示例性计算设备
131.在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图9对本公开示例性实施方式的计算设备进行说明。
132.图9显示的计算设备90仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
133.如图9所示，计算设备90以通用计算设备的形式表现。计算设备90的组件可以包括但不限于：上述至少一个处理单元901、上述至少一个存储单元902，连接不同系统组件(包括处理单元901和存储单元902)的总线903。
134.总线903包括数据总线、控制总线和地址总线。
135.存储单元902可以包括易失性存储器形式的可读介质，例如随机存取存储器(ram)9021和/或高速缓存存储器9022，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(rom)9023。
136.存储单元902还可以包括具有一组(至少一个)程序模块9024的程序/实用工具9025，这样的程序模块9024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
137.计算设备90也可以与一个或多个外部设备904(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(i/o)接口905进行。并且，计算设备90还可以通过网络适配器906与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图9所示，网络适配器906通过总线903与计算设备90的其它模块通信。应当理解，尽管图中未示出，可以结合计算设备90使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
138.应当注意，尽管在上文详细描述中提及了sdk测试装置的若干单元/模块或子单
元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
139.此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
140.虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。