CN112131101A - 一种自动化测试的方法、测试终端和存储介质 - Google Patents

Abstract

本说明书提供一种自动化测试的方法、测试终端和存储介质，该方法包括获取利用测试套对待测试数据进行测试的第一测试信息，所述第一测试信息包括：测试套中每个测试用例的位置信息，以及每个测试用例针对所述待测试数据的测试执行状态，根据所述第一测试信息确定所述待测试数据的测试完成情况。通过该方法，可以根据测试执行状态确定待测试数据经过测试套测试后的测试完成情况。

Description

一种自动化测试的方法、测试终端和存储介质

技术领域

本公开涉及通信技术领域，尤其涉及一种自动化测试的方法、测试终端和存储介质。

背景技术

RF：RobotFramework，是诺西开源的一套自动化测试工具，在web自动化及接口自动化很实用，它是基于Python开发的可扩展关键字驱动的自动化测试框架。

TestSuite：测试套，一组相关的测试的集合构成测试套，可以包含多个测试用例或子测试套。

Testbed：测试床，指软件测试的特定软件、硬件环境，可以包括软件、硬件以及网络构件。

SUT：System under test，即被测试系统。

Json：JavaScript Object Notation，是一种轻量级的数据交换格式。

随着计算机技术的高速发展和软件技术的不断提高，软件已经应用在各行各业，软件的质量就是软件的生命，因此也越来越得到人们的重视。随着软件产品的应用范围越来越广、功能越来越复杂，软件质量的管理也越来越困难，虽然人们在进行软件开发的过程中使用了许多有效的分析、设计和实现方法，但仍然不能避免出现各种各样的错误，因此，采用更加切实有效的方法发现软件产品中的错误和缺陷将成为软件测试人员的首要任务。现阶段可以采用的软件测试方法包括人工测试和自动化测试。

目前的自动化测试框架通常将采用数据驱动方式，即数据与逻辑分离的模式，测试设备等环境配置参数保存于数据部分，独立于测试代码逻辑之外，便于实现测试逻辑复用，并且同一套测试代码可以应用于不同的测试环境上进行测试，各种环境、配置或规格值变化时，只需要更新数据部分，提高了自动化测试的可维护性。

当前基于RF的自动化框架在执行测试时，通常将先读取数据部分(例如testbed文件)，作为整个测试进程的全局变量，当中包含了测试环境的各种参数，例如各个消息交互主机的IP地址、端口号，用户访问权限等。如果需要切换到其他设备环境中进行测试，则需要按实际环境参数更新此数据文件，并重新启动测试进程。

发明内容

本说明书提供了一种自动化测试的方法、测试终端和存储介质，通过该方法，可以根据测试执行状态确定待测试数据经过测试套测试后的测试完成情况。

本说明书实施例提供了一种自动化测试的方法，该方法包括：

获取利用测试套对待测试数据进行测试的第一测试信息；

所述第一测试信息包括：测试套中每个测试用例的位置信息，以及每个测试用例针对所述待测试数据的测试执行状态；

根据所述第一测试信息确定所述待测试数据的测试完成情况。

通过上述实施例可以看出，通过监控测试套中每个测试用例对待测试数据进行测试后的测试执行状态，可以获知各测试用例的测试完成情况，从而可以准确获知在对待测试数据进行测试时，哪些测试用例测试失败，或者未执行，可通过失败或者未执行的测试用例反向定位被测试的待测试数据中存在的问题，同时，还可利用失败或者未执行的测试用例再次对待测试数据进行测试，避免因重复用无问题的测试用例对待测试数据进行测试，降低测试效率。

在其他实施例中，位置信息包括测试用例的位置路径，所述测试执行状态包括：通过、失败、未执行。

由此可以看出，通过位置路径可以标识不同的测试用例，以及可通过位置路径直接调取对应的测试用例，通过测试执行状态可以获知经对应的测试用例测试后的结果信息，便于管理员直观的获知结果。

在其他实施例中，当所述测试用例对应的测试执行状态为失败时，所述方法还包括：

将所述测试执行状态为失败的测试用例记录在测试日志文件中。

通过本实施例可以看出，当测试执行状态我失败时，可以将对应的测试用例(或者测试用例的位置信息)记录在测试日志文件中，便于管理人员查看，同时，选择性的将失败的测试用例记录在测试日志文件中，可以减少管理人员不关心的信息(例如通过测试用例的测试信息)，提高了管理人员的工作效率。

在其他实施例中，当所述测试用例对应的测试执行状态为未执行时，所述方法还包括：

获取所述测试执行状态为未执行的测试用例；

根据所述测试执行状态为未执行的测试用例建立新的测试套；

利用所述新的测试套对所述待测试数据测试。

通过本实施例可以看出，在测试过程中，若测试执行状态为未执行时，可能是由于超时等原因导致的，此时，可以将未执行的测试用例构成新的测试套，再次对待测试数据进行测试，以保证测试的完整性，同时，系统可根据自动的执行上述过程，既自动建立新的测试套，提高了测试效率。

可选的，将所述第一测试信息记载在测试状态表中，并通过Json格式文件保存在测试执行主体中。

本说明书实施例还提供了一种自动化测试的方法，该方法包括：

获取具有测试环境的待测试数据；

获取利用测试套对第一测试环境的待测试数据进行测试的第一测试信息；

当确定所述第一测试信息中的测试执行状态为失败或未执行时，将所述待测试数据的第一测试环境切换为第二测试环境，并继续利用测试套测试；

其中，所述第一测试信息包括：测试套中每个测试用例的位置信息，以及每个测试用例针对所述待测试数据的测试执行状态。

通过本实施例可以看出，可针对待测试数据设置多个测试环境，当通过测试套进行测试后的第一测试信息中的测试执行状态为失败时，可以通过切换测试环境继续进行测试，直到测试环境切换的次数达到计数器的预设阈值时，终止测试。

本说明书实施例还提供了一种测试终端，该终端包括：处理器和机器可读存储介质；

所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器被所述机器可执行指令促使：实现上述任一实施例中的步骤。

本说明书实施例还提供了一种可读存储介质，该存储有机器可执行指令，在被处理器调用和执行时，所述机器可执行指令促使所述处理器：实现上述任一实施例中的步骤。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。

图1为本说明书实施例提供的一种测试架构示意图；

图2为本公开实施例提供的一种自动化测试的流程示意图；

图3为本公开实施例提供的一种测试架构示意图；

图4为本公开实施例提供的一种自动化测试的流程示意图；

图5为本公开实施例提供的一种测试架构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

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

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

目前的自动化测试框架通常将采用数据驱动方式，即数据与逻辑分离的模式，测试设备等环境配置参数保存于数据部分，独立于测试代码逻辑之外，便于实现测试逻辑复用，并且同一套测试代码可以应用于不同的测试环境上进行测试，各种环境、配置或规格值变化时，只需要更新数据部分，提高了自动化测试的可维护性。

当前基于RF的自动化框架在执行测试时，通常将先读取数据部分(例如testbed文件)，作为整个测试进程的全局变量，当中包含了测试环境的各种参数，例如各个消息交互主机的IP地址、端口号，用户访问权限等。如果需要切换到其他设备环境中进行测试，则需要按实际环境参数更新此数据文件，并重新启动测试进程，如图1所示：

测试数据：Testbed文件，包含测试环境相关的信息(如：IP地址、配置参数等)；

RIDE编辑器：robot脚本的编辑开发环境；

测试套：一组相关的测试用例的集合构成测试套，可以包含多个测试用例或子测试套，以文件或目录的形式存放在测试执行主机上；

RobotFramework：Robot自动化测试框架，主要包含Robot测试调用库模块、执行控制逻辑、数据处理模块等；

Python解释器：解释器主要由一个编译器和一个虚拟机构成，在执行Python源码文件时，编译器首先将源文件解释成为字节码，再通过虚拟机执行字节码；

SUT：System under test，即被测试系统。通常测试主机通过SSH连接、Restful接口等方式与被测系统进行交互。

测试进程从测试套中获取所有测试用例的全路径信息，并从testbed文件中获取测试环境相关的信息，启动并依此环境配置数据执行测试，执行至任一用例时，读取此用例的测试脚本具体内容，调用相关的RF或Python库，转换为Python执行码，最终由Python解释器执行。测试执行完成后输出测试结果和日志。

但是，目前当测试套中有用例执行失败时，测试进程不会停止，整个测试套仍然会全部执行，问题环境将因后续用例的持续执行而被破坏，不利于后续进行版本问题定位。

如图2所示，本说明书实施例提供了一种自动化测试的方法，该方法包括：

S101获取利用测试套对待测试数据进行测试的第一测试信息；

S102所述第一测试信息包括：测试套中每个测试用例的位置信息，以及每个测试用例针对所述待测试数据的测试执行状态；

S103根据所述第一测试信息确定所述待测试数据的测试完成情况。

在步骤S101中，获取待测试数据，并将待测试数据输入测试脚本中(例如Robot脚本)，并通过测试套对待测试数据进行测试，并输出第一测试信息。

其中第一测试信息包括测试用例的位置路径和测试执行状态，由于测试套包括数个测试用例，通过位置路径可以准确的找到对应的测试用例，所以第一测试信息中通过位置路径来锁定对应的测试用例。同时，测试执行状态可以包括：“通过、失败、未执行”，其中，“通过”表示用该状态对应的测试用例对待测试数据进行测试后的结果为通过测试；同理，“失败”表示用该状态对应的测试用例对待测试数据进行测试后的结果为未通过测试；“未执行”表示用该状态对应的测试用例对待测试数据进行测试时未获得测试结果，或者因其他原因导致漏测。

为了实现上述测试过程，本说明书实施例还提供了一种自动测试的架构示例图，如图3所示：

在该架构中，增加了测试状态表模块，用于记录第一测试信息，如“用例1：状态1”，表示通过测试套中的用例1对待测试数据进行测试后的完成情况，其中，状态1为通过用例1测试后的测试执行状态，其可以为“通过、失败、未执行”。其中，可以通过Json格式文件将该第一测试信息保存在测试状态模块中。

在步骤S103中，可以根据第一测试信息确定所述待测试数据的测试完成情况，并且可以根据该第一测试信息定位测试过程中遇到的出现问题的测试用例，进一步的，可以根据第一测试信息对出现问题的测试用例再次进行测试，或者弹出问题测试用例的位置信息，便于管理员进行后续操作。

在一种实施例中，系统可以获取第一测试信息中测试执行状态为失败的测试用例，并将该测试用例对应的位置信息、测试执行状态记录在测试日志文件中，当管理员需要定位问题时，可直接通过测试日志文件定位出现问题的测试用例。

在另一种实施例中，系统可以获取第一测试信息中测试执行状态为未执行的测试用例，并通过其对应的测试用例的位置信息获取该测试用例，通过获取的该测试用例构成新的测试套，通过该新的测试套再次对待测试数据进行测试。由此看出，在本实施例中，系统可以根据第一测试信息自动生成新的测试套，并利用新的测试套对待测试数据进行测试。

通过上述实施例可以看出，本方案创造性的将测试套中的测试用例进行分离，并将通过每个测试用例测试的结果进行标记，从而可以直观的获知在对待测试用例进行测试时，测试套中那些测试用例是通过的，那些是失败的，那些又是未执行的，管理员可以针对上述结果直接定位出现问题的测试用例，提高了测试效率以及问题定位的准确性。

本说明书实施例还提供了一种自动化测试的方法，如图4所示，该方法包括：

S401获取具有测试环境的待测试数据；

S402获取利用测试套对第一测试环境的待测试数据进行测试的第一测试信息；

S403当确定所述第一测试信息中的测试执行状态为失败或未执行时，将所述待测试数据的第一测试环境切换为第二测试环境，并继续利用测试套测试；

其中，所述第一测试信息包括：测试套中每个测试用例的位置信息，以及每个测试用例针对所述待测试数据的测试执行状态。

在步骤S401中，管理员可以预置多套测试环境的待测试数据，用于在通过测试套进行测试失败时，切换待测试数据的测试环境继续执行测试，如图5所示，为执行本实施例的一种测试架构示例。

其中，在图5中的测试数据中设置了n个测试环境的Testbed，当通过测试套进行测试时，通过第一测试信息中的测试执行状态信息确定存在失败或未执行的测试用例时，可以通过切换测试环境，继续对待测试数据进行测试。

在一种实施例中，管理员可以设置计数器，该计数器用于对测试环境的切换次数进行技术，同时，针对该计数器还可设置预设阈值，例如该预设阈值可以为该待测试数据的测试环境的个数，当计数器计数达到预设阈值时，可以认为待测试数据的测试环境均切换一遍，如果还存在测试执行状态为失败或未执行时，系统也不再进行测试，而是终止测试并反馈测试结果，或者将测试执行状态为失败或未执行的测试用例信息记录在测试日志中。

通过上述实施例可以看出，当测试套中有测试用例执行失败时，问题环境上的测试进程停止，问题环境不会因后续测试用例的持续执行而被破坏，方便后续进行版本问题定位；同时，当一轮测试套执行存在多个测试用例失败，能多次自动切换被测环境(在测试环境数足够的情况下)，直至完成所有测试，保留每个失败测试用例的问题环境以及测试日志，及大地提高测试效率。

本说明书实施例可以应用在可执行运算以及存储的设备中，例如PC机、移动式笔记本、测试终端等。

具体的，本说明书实施例还提供了一种测试终端，该终端包括：处理器和机器可读存储介质；

所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器被所述机器可执行指令促使：实现上述各实施例中的步骤。

本说明书实施例还提供了可读存储介质，存储有机器可执行指令，在被处理器调用和执行时，所述机器可执行指令促使所述处理器：实现上述各实施例中的步骤。

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

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (10)

1.一种自动化测试的方法，其特征在于，所述方法包括：

获取利用测试套对待测试数据进行测试的第一测试信息；

所述第一测试信息包括：测试套中每个测试用例的位置信息，以及每个测试用例针对所述待测试数据的测试执行状态；

根据所述第一测试信息确定所述待测试数据的测试完成情况。

2.根据权利要求1所述的方法，其特征在于，所述位置信息包括测试用例的位置路径，所述测试执行状态包括：通过、失败、未执行。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一测试信息确定所述待测试数据的测试完成情况，具体包括：

根据第一测试信息中的各测试用例对应的测试执行状态确定针对待测试数据的测试完成情况。

4.根据权利要求2所述的方法，其特征在于，当所述测试用例对应的测试执行状态为失败时，所述方法还包括：

将所述测试执行状态为失败的测试用例记录在测试日志文件中。

5.根据权利要求2所述的方法，其特征在于，当所述测试用例对应的测试执行状态为未执行时，所述方法还包括：

获取所述测试执行状态为未执行的测试用例；

根据所述测试执行状态为未执行的测试用例建立新的测试套；

利用所述新的测试套对所述待测试数据测试。

6.根据权利要求1所述的方法，其特征在于，将所述第一测试信息记载在测试状态表中，并通过Json格式文件保存在测试执行主体中。

7.一种自动化测试的方法，其特征在于，所述方法包括：

获取具有测试环境的待测试数据；

获取利用测试套对第一测试环境的待测试数据进行测试的第一测试信息；

当确定所述第一测试信息中的测试执行状态为失败或未执行时，将所述待测试数据的第一测试环境切换为第二测试环境，并继续利用测试套测试；

其中，所述第一测试信息包括：测试套中每个测试用例的位置信息，以及每个测试用例针对所述待测试数据的测试执行状态。

8.根据权利要求7所述的方法，其特征在于，获取所述待测试数据的待测试数据的测试环境个数；

根据所述测试环境个数设置计数器；

当将所述待测试数据的第一测试环境切换为第二测试环境时，所述计数器执行减一操作；

当所述计数器低于预设阈值时，终止利用测试套对所述待测试数据测试。

9.一种测试终端，其特征在于，所述终端包括：处理器和机器可读存储介质；

所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器被所述机器可执行指令促使：实现权利要求1-8任一所述的方法。

10.一种可读存储介质，其特征在于，存储有机器可执行指令，在被处理器调用和执行时，所述机器可执行指令促使所述处理器：实现权利要求1-8任一所述的方法步骤。

Images