一种数据测试方法及装置

技术领域

本申请涉及接口自动化测试技术领域，特别涉及一种数据测试方法。本申请同时涉及一种数据测试装置，一种计算设备，以及一种计算机可读存储介质。

背景技术

软件测试作为软件生命周期的一个重要阶段，是保证软件质量的重要手段。在软件测试工作实践中发现，软件接口类型多，结构复杂，且不同类型的软件产品的接口存在较大差异性。随着web业务的日趋复杂、系统愈加庞大，一次完整的全链路功能测试或者性能测试需要录入测试用例也随之增多。由于模块化开发，全链路测试人员需要花费更长的时间来与各部门沟通，并研究各部门所使用的不同格式的接口测试用例，也需要花费更长的时间来录接口入测试用例。

发明内容

有鉴于此，本申请实施例提供了一种数据测试方法。本申请同时涉及一种数据测试装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本申请实施例的第一方面，提供了一种数据测试方法，包括：

接收至少两个测试用例并确定所述至少两个测试用例的测试顺序；

在所述至少两个测试用例中包含第一测试用例的情况下，按照所述第一测试用例的测试顺序进行测试，其中所述第一测试用例为目标格式；

在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；

根据测试结果生成测试报告。

根据本申请实施例的第二方面，提供了一种数据测试装置，包括：

接收模块，被配置为接收至少两个测试用例并确定所述至少两个测试用例的测试顺序；

第一测试模块，被配置为在所述至少两个测试用例中包含第一测试用例的情况下，按照所述第一测试用例的测试顺序进行测试，其中所述第一测试用例为目标格式；

第二测试模块，被配置为在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；

生成模块，被配置为根据测试结果生成测试报告。

根据本申请实施例的第三方面，提供了一种计算设备，包括：

存储器、处理器：

所述存储器用于存储计算机可执行指令，所述处理器执行所述指令时实现所述数据测试方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述数据测试方法的步骤。

本申请提供的数据测试方法，接收至少两个测试用例并确定所述至少两个测试用例的测试顺序；在所述至少两个测试用例中包含第一测试用例的情况下，按照所述第一测试用例的测试顺序进行测试，其中所述第一测试用例为目标格式；在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；根据测试结果生成测试报告。减少了人工重复参与制造接口测试数据的时间，并且提供了用例导入功能，减少测试人员编写用例的时间，通过确定测试顺序，减少处理运行顺序的时间，还能够通过将转换格式，实现测试用例的高兼容性，解决了跨部门、全链路的测试效率问题。

附图说明

图1是本申请一实施例提供的一种数据测试方法的流程图；

图2是本申请一实施例提供的一种应用于支付软件的数据测试方法的处理流程图；

图3是本申请一实施例提供的一种数据测试装置的结构示意图；

图4是本申请一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

测试用例：是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

抓包工具：是拦截查看网络数据包内容的软件。抓包工具由于其可以对数据通信过程中的所有IP报文实施捕获并进行逐层拆包分析。

脚本：(Script)是使用一种特定的描述性语言，依据一定的格式编写的可执行文件。

接下来，对本说明书提供的数据测试方法的基本构思进行简述。

现有技术中，在软件测试时，都是基于模块化进行测试，需要全链路测试人员需要花费较长的时间来与各部门进行沟通。由于软件接口类型多、结构复杂、测试用例的数量大，测试人员还需要研究各部门所使用的不同格式的接口测试用例，这样就造成了测试人员需要花费更长的时间来录接口入测试用例。

针对此现状，本申请发明一款具有格式兼容功能的数据测试方法。首先，各部门依次导入各自的测试用例。然后，运用抓包工具，对人工的全链路操作进行录制。通过录制的接口请求顺序，自动为导入的测试用例排序。随后，通过判断测试用例的格式，使用脚本去解析请求方法、请求体、上下文等封装参数并存入数据库。再把数据库存储的封装参数，组装成的统一pytest格式用例。最后生成测试报告，并分发给各部门。运用格式兼容特性，能减少全链路测试人员录入测试用例的时间，大大的提高了测试的效率、覆盖率以及准确性。

在本申请中，提供了一种数据测试方法，本申请同时涉及一种数据测试装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例提供的一种数据测试方法的流程图，具体包括以下步骤：

步骤102：接收至少两个测试用例并确定所述至少两个测试用例的测试顺序。

具体的，测试用例是指各部门通过自动化测试平台导入的对某个软件产品的测试用例；测试顺序是指根据对测试用例的分析所确定的针对某个软件产品的所有测试用例的执行的先后顺序。

实际应用中，自动化测试平台界面上会显示有登陆该平台的信息框，测试人员可以通过输入账号、密码、验证码等信息点击登陆按钮登陆该自动化测试平台。在登陆成功之后，由测试人员点击测试按钮并创建一个新的测试计划。此时，完成了进行数据测试的前期准备。

进一步的，在测试计划创建完成的基础上，各部门依次通过各自使用的接口导入测试用例，所述测试用例的格式包括postman格式、har格式、json格式、jmx格式、pytest格式等，即接收至少两个测试用例。之后，根据实际情况确定所述至少两个测试用例的测试顺序。

本申请中通过不同的接口接收至少两个测试用例，从而确定所述至少两个测试用例的测试顺序，为保证所述测试用例的顺利测试以及测试过程的快速、高效做好了准备基础。

进一步的，所述确定所述至少两个测试用例的测试顺序的具体实施过程可以如下：

根据接收所述至少两个测试用例的接口与接口请求顺序，确定所述至少两个测试用例的测试顺序。

具体的，接收所述至少两个测试用例的接口可以包括登陆接口、支付接口、登出接口等；接口请求顺序是指按照某一请求从而请求登陆接口、支付接口、登出接口的顺序。一般来说，在明确了接口请求顺序以及测试用的接口之后，就可以确定测试用的执行顺序，即测试顺序。

例如，有三个测试用例：测试用例A，测试用例B以及测试用例C，其中，测试用例A的接收接口为支付接口，测试用例B的接收接口为登出接口，测试用例C的接收接口为登陆接口。此外，接口请求顺序为：第一个请求的是登陆接口、第二个请求的是支付接口、第三个请求的是登出接口。则可以确定，这三个测试用例的测试顺序为：第一测试测试用例C，第二测试测试用例A，第三测试测试用例B。

实际应用中，在所述根据接收所述至少两个测试用例的接口与接口请求顺序之前，还需要确认接口请求顺序，其具体实施过程可以如下：

通过抓包工具录制人工全链路操作，获取接口请求信息；

解析所述接口请求信息，确定接口请求顺序。

具体的，所述抓包工具可以是Fiddler抓包软件，也可以是其他抓包软件，本申请对此不作限定；所述人工全链路操作指模拟用户进行点击、输入等操作。一般来说，通过Http抓包工具进行人工全链路操作的录制，之后，导出携带有接口请求信息的har文件。可以对har文件进行解封，获取所述接口请求信息。在此基础上，对接口请求信息进行解析，从而确定接口请求顺序。

例如，通过Fiddler抓包软件录制人工全链路操作，获得接口请求信息，对其进行解析，获得第一个请求的是登陆接口、第二个请求的是支付接口、第三个请求的是登出接口的顺序。

本申请中通过抓包工具确定接口请求顺序，在此基础上结合接收测试用例的接口确定所述测试用例的测试顺序，如此可以根据不同的测试用例以及不同的接口请求顺序确定针对于某个特定软件应用的测试用例的执行顺序，适应性更高。

步骤104，在所述至少两个测试用例中包含第一测试用例的情况下，按照所述第一测试用例的测试顺序进行测试，其中所述第一测试用例为目标格式。

具体的，第一测试用例的测试顺序是指为目标格式的某一测试用例在整个数据测试中的顺序，如测试用例A为目标格式，且其测试顺序为3，那么第三个进行测试的为测试用例A。在接收至少两个测试用例，以及确定所述至少两个测试用例的测试顺序的基础上，进一步的，在所述至少两个测试用例中包含第一测试用例的情况下，对目标格式的第一测试用例按照第一测试用例的测试顺序进行测试。

实际应用中，所述目标格式为自动化测试平台默认的格式，或者是人为设定的在该自动化测试平台所指定的格式。对于与自动化测试平台指定格式一致的测试用例，即第一测试用例，无需对其进行其他操作，可以将其保留等待测试。在轮到所述第一测试用例进行测试时，对所述第一测试用例进行测试。

例如，在所述目标格式为pytest格式的基础上，平台接收到三个测试用例，测试用例A，测试用例B以及测试用例C，其中，测试用例A为pytest格式，测试用例B为json格式，测试用例C为postman格式。在确定测试用例的测试顺序为测试用例C-测试用例A-测试用例B的情况下，对于测试用例A不进行操作，等到测试用C测试完毕之后，直接对测试用例A进行测试。

本申请中对于为目标格式的测试用例，按照目标格式的测试用例的测试顺序进行测试，减轻了平台在数据测试时的处理压力，而且可以在一定程度上提高数据测试的速度。

步骤106，在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式。

具体的，第二测试用例的测试顺序是指为非目标格式的某一测试用例在整个数据测试中的顺序，如测试用例B为非目标格式，且其测试顺序为2，那么第二个进行测试的为测试用例B。对于非目标格式的测试用例，由于其格式与平台指定的或者默认的格式不同，若直接对非目标格式的测试用例进行测试，不仅对平台的处理能力有极高的要求，还需要测试人员花费大量的时间进行录制以及协调各接口进行测试。因此，需要将非目标格式的测试用例转换为目标格式的测试用例，即将所述第二测试用例封装为目标格式的测试用例，再按照该测试用例的测试顺序对目标格式的测试用例进行测试。

例如，接收到两个测试用例：测试用例A和测试用例B，其中，测试用例A为jmx格式，测试用例B为pytest格式，且pytest格式为目标格式。若测试顺序为先测试测试用例A，再测试测试用例B，则选择对应于jmx文件的脚本对测试用例A进行解析从而获得测试用例A的封装参数，再根据封装参数将测试用例A封装为pytest格式的测试用例A’；对于测试用例B不用进行操作。在此之后，开始测试测试用例A’，再测试测试用例B。

需要说明的是，步骤104与步骤106并不是简单的先后顺序。对于接收到的测试用例，对于目标格式的测试用例不进行处理；对于非目标格式的测试用例可以同时进行封装，也可以按照接收测试用例的顺序依次进行封装。直到所有的非目标格式的测试用例均封装为目标格式的测试用例后，再整合所有的测试用例按照测试顺序进行测试。或者对于接收到的测试用例，按照测试顺序进行封装并测试，对于目标格式的测试用例，即第一测试用例忽略封装过程直接测试。

例如，接收到三个测试用例：测试用例A、测试用例B以及测试用例C，其中只有测试用例B为目标格式，测试顺序为：测试用例A-测试用例B-测试用例C。对于测试用例B先不做处理，而对于测试用例A和测试用例C需要进行封装处理：可以同时对测试用例A和测试用例C进行封装处理，也可以按照接收顺序，先对测试用例A进行封装处理得到测试用例A’，再对测试用例C进行封装处理得到测试用例C’。此时，所有的测试用例都为目标格式，开始对测试用例A’、测试用例B以及测试用例C’按照测试顺序进行测试。或者，直接按照测试用例的顺序：首先，对测试用例A进行封装，获得测试用例A’并测试；其次，由于测试用例B为目标格式，不需要进行封装，直接对测试用例B进行测试；最后，对测试用例C进行封装，获得测试用例C’并测试。

具体的，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例的实现过程可以为：

确定所述第二测试用例的格式；

根据所述第二测试用例的格式选择与所述第二测试用例对应的脚本；

通过所述脚本将所述第二测试用例进行解析并获得封装参数；

基于所述封装参数将所述第二测试用例封装为目标格式的测试用例。

实际应用中，预先在本地存储了多种类型的脚本。每个脚本可以解析一种格式的测试用例，如脚本A可以解析格式为a的测试用例，脚本B可以解析格式为b的测试用例，因此，在选择第二测试用例对应的脚本之前，需要先确定第二测试用例的格式。在此基础上，根据第二测试用例的格式来选择相匹配的脚本。调用所述脚本对第二测试用例进行解析获得第二测试用例的封装参数，再将封装参数按照预设的目标格式进行封装，形成目标格式的测试用例，即将所述第二测试用例封装为目标格式的测试用例。

为了将所述非目标格式的第二测试用例封装为目标格式的测试用例，需要通过所述脚本将所述第二测试用例进行解析并获得封装参数，具体实现过程如下：

通过所述脚本对所述第二测试用例进行解析；

根据关键字定位所述解析结果中的封装参数；

删除所述解析结果中的关键字、分隔符，获得所述第二测试用例的封装参数并存储至数据库。

具体的，所述关键字包括“method”、“url”、“headers”、“cookies”，也可以包括其他关键字。首先，通过运行第二测试用例对应的脚本对第二测试用例进行解析，并获得所述第二测试用例的解析结果。由于无论是哪种格式的测试用例，其封装参数中都包括请求方法、请求地址、请求头、请求体等固定格式的封装参数。因此，对于所述第二测试用例的解析结果，可以通过搜索关键词“method”、“url”、“headers”、“cookies”等定位解析结果中封装参数的位置。在定位成功之后，删除解析结果中封装参数以外的不必要的信息，即删除所述解析结果中的关键字、分隔符，从而分离出所述第二测试用例的封装参数，并将所述第二测试用例的封装参数进行存储。

本申请中通过对第二测试用例进行解析，并根据关键字最终获取第二测试用例的封装参数，从而为后续基于封装参数对第二测试用例进行封装做好了准备基础。

进一步的，在获得所述第二测试用例的封装参数之后，基于所述封装参数对所述第二测试用例进行封装，使其变为目标格式的测试用例，具体实现过程如下：

读取所述数据库，获取所述第二测试用例的封装参数；

将所述封装参数存入目标格式模型框架中对应的位置，生成目标格式的测试用例。

具体的，所述数据库专门用于存储封装参数。一般来说，在进行封装时需要从数据库调取对应的封装参数，即读取所述数据库，获取所述第二测试用例的封装参数。在获得封装参数后将其填入目标格式模型框架中对应的位置，则生成了目标格式的测试用例，即对非目标格式的第二测试用例的封装完成。

进一步地，在所述将所述封装参数存入目标格式模型框架中对应的位置之前，还需要对目标格式模型框架进行创建，具体实现过程如下：

创建目标格式模型框架，所述目标格式模型框架中包括关键字，其中，在所述关键字后预留有用于存储关键字对应的封装参数的位置。

具体的，根据目标格式创建目标格式模型框架，即对于不同的目标格式其目标格式模型框架也不同。其中，目标格式框架中包括关键字以及预留的封装参数的位置。所述目标格式模型框架可以为：“关键词1()关键词2()关键词3()关键词4()……”，也可以为：“关键词1关键词2关键词3关键词4……”等形式。

例如，关键词有4个，分别为：“method”、“url”、“headers”、“cookies”。则构建的目标格式模型框架可以为：method()url()headers()cookies()。若从数据库中读取的第二测试用例的封装参数为：请求方法A、请求地址B、请求头C以及请求体D，则将请求方法A、请求地址B、请求头C以及请求体D填入目标格式模型框架，形成目标格式的测试用例为：method(请求方法A)url(请求地址B)headers(请求头C)cookies(请求体D)。

另外，为了便于测试人员下载目标格式的测试用例以便做进一步拓展测试，所述方法还提供了下载功能，实现过程可以是：接收目标格式的测试用例下载请求，反馈所述目标格式的测试用例。

本申请通过将获取的第二测试用例的封装参数填入预先建立目标格式模型框架中，如此可以快速地将所有的测试用例封装成统一的格式，提高了数据测试的便捷性和易用性。

步骤108，根据测试结果生成测试报告。

具体的，在按照测试用例的测试顺序测试所有目标格式的测试用例的基础上，进一步的，获得测试结果，并根据测试结果生成测试报告，其中所述测试报告可以是allure测试报告。

在实际应用中，可以基于allure-pytest生成allure测试报告。其中，生成allure测试报告可以分为两个部分，第一部分为生成测试报告数据，第二部分为生成测试报告页面。在生成测试报告之后，将所述测试报告分发给此次全链路测试对应的部门，即根据接收测试用例的接口反馈测试结果。这样直接将测试结果反馈给各部门，省去了测试人员与各部门沟通的繁琐程序，同时也便于各部门及时的获得测试结果进行后续分析。

本申请提供的数据测试方法，接收至少两个测试用例并确定所述至少两个测试用例的测试顺序；在所述至少两个测试用例中包含第一测试用例的情况下，按照所述第一测试用例的测试顺序进行测试，其中所述第一测试用例为目标格式；在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；根据测试结果生成测试报告。减少了人工重复参与制造接口测试数据的时间，并且提供了用例导入功能，减少测试人员编写用例的时间，通过确定测试顺序，减少处理运行顺序的时间，还能够通过将转换格式，实现测试用例的高兼容性，解决了跨部门、全链路的测试效率问题。

下述结合附图2，以本申请提供的数据测试方法在支付软件测试中的应用为例，对所述数据测试方法进行进一步说明。其中，图2示出了本申请一实施例提供的一种应用于支付软件的数据测试方法的处理流程图，具体包括以下步骤：

步骤202，登录接口自动化测试平台。

实际应用中，测试人员可以通过输入账号和密码登陆该自动化测试平台，也可以通过账号和验证码登录该自动化测试平台，并创建一个支付软件X的测试计划。

步骤204，导入任意格式的测试用例。

具体的，测试用例是指各部门通过自动化测试平台导入的各自对支付软件X的测试用例。在测试计划创建完成的基础上，由各部门依次导入测试用例，其中，所述测试用例的格式可以是postman格式、har格式、json格式、jmx格式、pytest格式等。

步骤206：录制人工操作，确定测试用例的测试顺序。

测试顺序是指根据对所述测试用例的分析所确定所述三个测试用例的执行的先后顺序。具体的，通过Fiddler抓包软件录制人工全链路操作，获取支付软件的接口请求信息，解析所述支付软件的接口请求信息，确定接口请求顺序。一般来说，通过Fiddler抓包软件进行人工全链路操作的录制，之后，导出携带有接口请求信息的har文件。可以对har文件进行解封，获取所述接口请求信息。在此基础上，对接口请求信息进行解析从而获得接口请求顺序：获得第一个请求的是登陆接口、第二个请求的是支付接口、第三个请求的是登出接口的顺序。进一步的，可以根据接收所述测试用例的接口与接口请求顺序，确定所述测试用例的测试顺序。

具体的，对于支付软件X来说，所述测试用例的接口包括登陆接口、支付接口、登出接口，所述接口请求顺序为：登陆接口、支付接口、登出接口。此时，根据测试用例分别导入的接口和接口请求顺序就可以确定所述测试用例的测试时的先后顺序。

例如，导入了三个测试用例，分别为测试用例一，测试用例二以及测试用例三，其中，测试用例一的接收接口为支付接口，测试用例二的接收接口为登出接口，测试用例三的接收接口为登陆接口。按照接口请求顺序，对三个测试用例的测试顺序进行确定，即：第一个进行测试的是测试用例三，第二个进行测试的是测试用例一，第三个进行测试的是测试用例二。

本申请中通过不同的接口接收测试用例，从而确定所述测试用例的测试顺序，为保证对支付软件X测试的顺利进行以及测试过程的快速、高效做好了准备基础。且本申请中通过Fiddler抓包软件确定接口请求顺序，在此基础上结合接收测试用例的接口确定所述测试用例的测试顺序，如此可以根据不同的测试用例以及不同的接口请求顺序确定支付软件X的测试用例的执行顺序，适应性更高。

步骤208，判断测试用例的格式并运行对应的脚本，获得封装参数。

具体的，对于所述测试用例中为pytest格式的测试用例，由于其已经是目标格式的测试用例，无需对其进行操作；对所述测试用例中的为其他格式的测试用例，由于其格式为非目标格式，平台不能直接对其他格式的测试用例进行测试。分别确定所述其他格式的测试用例的格式，并选择对应的脚本对所述其他格式的测试用例解析并获得封装参数，并存储在数据库中。

例如，对于json格式的测试用例A，选择对应于json文件的脚本对测试用例A进行解析从而获得测试用例A的封装参数，并将参数存入存储库；对于格式为jmx格式的测试用例B，选择对应于jmx文件的脚本对测试用例B进行解析从而获得测试用例B的封装参数，并将参数存入存储库。

进一步的，对所述其他格式的测试用例运行对应的脚本，获得封装参数的具体实现过程如下：

选择对应于其他格式的脚本对其他格式的测试用例进行解析；

根据关键字定位所述其他格式的测试用例的解析结果中的封装参数；

删除所述其他格式的测试用例的解析结果中的关键字、分隔符，获得所述其他格式的测试用例的封装参数并存储至数据库。

具体的，所述关键字包括“method”、“url”、“headers”、“cookies”。先根据其他格式的测试用例的格式选择对应的脚本对测试用例而进行解析，并获得所述其他格式的测试用例的解析结果，通过搜索关键词“method”、“url”、“headers”、“cookies”等定位所述其他格式的测试用例的解析结果中封装参数的位置，并删除所述其他格式的测试用例的解析结果中封装参数以外的不必要的信息，从而分离出所述其他格式的测试用例的封装参数，并将所述其他格式的测试用例的封装参数进行存储。

本申请中通过对测试用例中其他格式的测试用例进行解析，并根据关键字最终获取其他格式的测试用例的封装参数，从而为后续基于封装参数对其他格式的测试用例进行封装做好了准备基础。

步骤210，统一封装为pytest格式的测试用例。

基于所述封装参数将所述其他格式的测试用例封装为pytest格式的测试用例，按照所述其他格式的测试顺序对所述pytest格式的测试用例进行测试。首先读取数据库，获得其他格式的测试用例的封装参数，并将将所述其他格式的测试用例的封装参数分别填写在pytest格式模型框架中对应的位置中。

具体的，在进行封装时需要从数据库调取对应的封装参数，即读取所述数据库，获取所述其他格式的测试用例的封装参数，将其分别填入pytest格式模型框架中对应的位置，则生成了pytest格式的测试用例。在此之前，还需要对pytest格式模型框架进行创建，具体实现过程如下：

创建pytest格式模型框架，所述pytest格式模型框架中包括关键字，其中，在所述关键字后预留有用于存储关键字对应的封装参数的位置。

本申请通过将获取其他格式的测试用例的封装参数填入预先建立pytest格式模型框架中，如此可以快速地将所有的非pytest格式的测试用例封装成pytest格式，提高了数据测试的便捷性和易用性。

另外，为了便于测试人员下载pytest格式的测试用例以便做进一步拓展测试，所述方法还提供了下载功能，实现过程可以是：接收pytest格式的测试用例下载请求，反馈所述pytest格式的测试用例。

步骤212，全链路运行pytest格式的测试用例。

对于所有的测试用例，知道所有的测试用例都为pytest格式的测试用例时，按照测试用例的测试顺序，对所有的pytest格式的测试用例进行测试。例如，有三测试用例：测试用例一、测试用例二、测试用例三，假定测试顺序为测试用例二、测试用例一、测试用例三，其中测试用例二和测试用例三为其他格式。可以先对测试用例二和测试用例三进行封装得到pytest格式的测试用例2和pytest格式的测试用例3，然后按照pytest格式的测试用例2、测试用例一、pytest格式的测试用例3的顺序进行测试。

步骤214，生成allure测试报告。

具体的，在按照测试用例的测试顺序测试所有pytest格式的测试用例的基础上，进一步的，获得测试结果，并根据测试结果生成allure测试报告。在实际应用中，可以基于allure-pytest生成allure测试报告。

步骤216，给各部门分发测试报告。

在生成测试报告之后，将所述测试报告分发给此次导入测试用例的各个部门，即根据接收测试用例的接口反馈测试结果。这样直接将测试结果反馈给各部门，省去了测试人员与各部门沟通的繁琐程序，同时也便于各部门及时的获得测试结果进行后续分析。

本申请提供的数据测试方法，登录接口自动化测试平台；导入任意格式的测试用例；录制人工操作，确定测试用例的测试顺序；判断测试用例的格式并运行对应的脚本，获得封装参数；统一封装为pytest格式的测试用例；全链路运行pytest格式的测试用例；生成allure测试报告；给各部门分发测试报告。减少了人工重复参与制造接口测试数据的时间，并且提供了用例导入功能，减少测试人员编写用例的时间，通过确定测试顺序，减少处理运行顺序的时间，还能够通过将转换格式，实现测试用例的高兼容性，解决了跨部门、全链路的测试效率问题。

与上述方法实施例相对应，本申请还提供了数据测试装置实施例，图3示出了本申请一实施例提供的一种数据测试装置的结构示意图。如图3所示，该装置包括：

接收模块302，被配置为接收至少两个测试用例并确定所述至少两个测试用例的测试顺序；

第一测试模块304，被配置为在所述至少两个测试用例中包含第一测试用例的情况下，按照所述第一测试用例的测试顺序进行测试，其中所述第一测试用例为目标格式；

第二测试模块306，被配置为在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；

生成模块308，被配置为根据测试结果生成测试报告。

所述接收模块302，还被配置为根据接收所述至少两个测试用例的接口与接口请求顺序，确定所述至少两个测试用例的测试顺序。

所述装置还包括：

处理模块，被配置为通过抓包工具录制人工全链路操作，获取接口请求信息，解析所述接口请求信息，确定接口请求顺序。

所述第二测试模块306，还被配置为确定所述第二测试用例的格式，根据所述第二测试用例的格式选择与所述第二测试用例对应的脚本，通过所述脚本将所述第二测试用例进行解析并获得封装参数，基于所述封装参数将所述第二测试用例封装为目标格式的测试用例。

所述第二测试模块306，还被配置为通过所述脚本对所述第二测试用例进行解析，根据关键字定位所述解析结果中的封装参数，删除所述解析结果中的关键字、分隔符，获得所述第二测试用例的封装参数并存储至数据库。

所述第二测试模块306，还被配置为读取所述数据库，获取所述第二测试用例的封装参数，将所述封装参数存入目标格式模型框架中对应的位置，生成目标格式的测试用例。

所述装置还包括：

创建模块，被配置为创建目标格式模型框架，所述目标格式模型框架中包括关键字，其中，在所述关键字后预留有用于存储关键字对应的封装参数的位置。

反馈模块，被配置为根据接收测试用例的接口反馈测试结果。

本申请提供的数据测试装置，包括接收模块，被配置为接收至少两个测试用例并确定所述至少两个测试用例的测试顺序；第一测试模块，被配置为在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；第二测试模块，被配置为在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；生成模块，被配置为根据测试结果生成测试报告。减少了人工重复参与制造接口测试数据的时间，并且提供了用例导入功能，减少测试人员编写用例的时间，通过确定测试顺序，减少处理运行顺序的时间，还能够通过将转换格式，实现测试用例的高兼容性，解决了跨部门、全链路的测试效率问题。

上述为本实施例的一种数据测试装置的示意性方案。需要说明的是，该数据测试装置的技术方案与上述的数据测试方法的技术方案属于同一构思，数据测试装置的技术方案未详细描述的细节内容，均可以参见上述数据测试方法的技术方案的描述。

图4示出了根据本申请一实施例提供的一种计算设备400的结构框图。该计算设备400的部件包括但不限于存储器410和处理器420。处理器420与存储器410通过总线430相连接，数据库450用于保存数据。

计算设备400还包括接入设备440，接入设备440使得计算设备400能够经由一个或多个网络460通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备440可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本申请的一个实施例中，计算设备400的上述部件以及图4中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图4所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备400可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备400还可以是移动式或静止式的服务器。

其中，处理器420用于执行如下计算机可执行指令：

接收至少两个测试用例并确定所述至少两个测试用例的测试顺序；

在所述至少两个测试用例中包含第一测试用例的情况下，按照所述第一测试用例的测试顺序进行测试，其中所述第一测试用例为目标格式；

在所述至少两个测试用例中包含第二测试用例的情况下，选择与所述第二测试用例对应的脚本将所述第二测试用例封装为目标格式的测试用例，并按照所述第二测试用例的测试顺序进行测试，其中所述第二测试用例为非目标格式；

根据测试结果生成测试报告。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的数据测试方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述数据测试方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述数据测试方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据测试方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述数据测试方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。