CN110874319A - 自动化测试方法、平台、设备及计算机可读存储介质 - Google Patents

Abstract

本发明提供一种自动化测试方法、平台、设备及计算机可读存储介质。方法包括：根据用户指令生成待测程序对应的测试实例；根据测试实例确定测试资源，并确定测试实例对应的测试资源是否充足，若是，则运行测试实例。本实施例提供的方法、平台、设备及计算机可读存储介质可以根据用户指令生成相应的测试用例，从而能够根据用户的测试需求生成相应的测试用例，再基于该测试用例及其对应的测试资源进行测试，能够仅通过执行本实施例提供的方法的装置，就能够对待测试软件进行所有类型的测试，进而提高测试效率。

Description

自动化测试方法、平台、设备及计算机可读存储介质

技术领域

本发明涉及自动化测试技术，尤其涉及一种自动化测试方法、平台、设备及计算机可读存储介质，属于计算机领域。

背景技术

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

现有技术中，最常用的自动化测试方式是根据不同测试类型选择不同的测试工具进行测试，然后整理发测试报告。

但是，这种方式提供的是点的服务，使用成本较高，例如，用户对软件进行不同类别的测试时，需要选择不同的测试工具，因此，亟需一种自动化测试方法，以解决上述技术问题。

发明内容

本发明提供一种自动化测试方法、平台、设备及计算机可读存储介质，以解决现有技术中对软件进行不同类别的测试时，需要选择不同的测试工具的问题。

本发明的第一个方面是提供一种自动化测试方法，包括：

根据用户指令生成待测程序对应的测试实例；

根据所述测试实例确定测试资源，并确定所述测试实例对应的测试资源是否充足，若是，则运行所述测试实例。

本发明的另一个方面是提供一种自动化测试平台，包括：

生成模块，用于根据用户指令生成待测程序对应的测试实例；

运行模块，用于根据所述测试实例确定测试资源，并确定所述测试实例对应的测试资源是否充足，若是，则运行所述测试实例。

本发明的又一个方面是提供一种自动化测试设备，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并配置为由所述处理器执行以实现如上述第一方面所述的自动化测试方法。

本发明的又一个方面是提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现如上述第一方面所述的自动化测试方法。

本发明提供的自动化测试方法、平台、设备及计算机可读存储介质的技术效果是：

本实施例提供的自动化测试方法、平台、设备及计算机可读存储介质，包括：根据用户指令生成待测程序对应的测试实例；根据测试实例确定测试资源，并确定测试实例对应的测试资源是否充足，若是，则运行测试实例。本实施例提供的方法、平台、设备及计算机可读存储介质可以根据用户指令生成相应的测试用例，从而能够根据用户的测试需求生成相应的测试用例，再基于该测试用例及其对应的测试资源进行测试，能够仅通过执行本实施例提供的方法的装置，就能够对待测试软件进行所有类型的测试，进而提高测试效率。

附图说明

图1为本发明一示例性实施例示出的自动化测试方法的流程图；

图2为本发明另一示例性实施例示出的自动化测试方法的流程图；

图3为本发明一示例性实施例示出的自动化测试平台的结构图；

图4为本发明另一示例性实施例示出的自动化测试平台的结构图；

图5为本发明一示例性实施例示出的自动化测试设备的结构图。

具体实施方式

图1为本发明一示例性实施例示出的自动化测试方法的流程图。

如图1所示，本实施例提供的自动化测试方法包括：

步骤101，根据用户指令生成待测程序对应的测试实例。

其中，本实施例提供的方法可以由自动化测试平台来执行，该自动化测试平台可以分为前端和后端，前端可以运行在网页端，用于与用户进行交互。后端可以运行在服务器中，用于接收通过前端发送的用户指令，并根据用户指令进行操作得到处理结果，并通过前端向用户反馈处理结果。

具体的，用户可以在前端设置用于测试程序的参数。例如，用户可以选择待测试程序，并选择待测试程序的节点Task或工作流Pipeline。

进一步的，待测试程序可以包含多个工作流Pipeline，每个工作流Pipeline具有其相应的功能，例如部署服务、功能测试、性能测试、发送测试报告等。每个工作流Pipeline由多个节点Task组成，这些节点Task有执行的先后顺序，例如，先执行Task1，再执行Task2，最后执行Task3。

实际应用时，节点Task的输入参数可以包括前一个节点Task的输出参数，以及当前节点Task的设置参数。每个节点Task的输出参数可以传递给下一个执行的节点Task。将这些节点Task连接起来就形成了工作流Pipeline。

另外，节点Task还可以接收应用程序传入的参数、Pipeline传入的参数，可以设置各个参数的优先级，当参数名称相同时，优先级大的参数有效，例如，应用程序传入的参数优先级为1，Pipeline传入的参数优先级为2，其他Task传入的参数优先级为3，本Task设置的参数优先级为4。

其中，节点Task的设置参数可以是预先设置好的，也可以是测试时用户输入的，例如，用户可以在测试平台的前端设置节点Task的参数。

具体的，用户可以在测试平台前端输入的指令可以是选择一条工作流Pipeline，或选择多个节点Task，还可以包括设置的测试参数，例如用户可在前端设置这条工作流中的压力测试时间为1个小时等参数，再点击前端设置的开始测试按钮，就可以通过测试平台的前端提交一个测试任务，该测试任务为对某个服务进行一个小时的压力测试。

进一步的，前端可以根据用户指令生成待测试程序对应的测试实例。具体可以根据用户选择的节点Task或工作流Pipeline生成相应的运行实例。

步骤102，根据测试实例确定测试资源，并确定测试实例对应的测试资源是否充足，若是，则运行测试实例。

实际应用时，每个测试实例在运行时都需要测试资源进行支撑。例如，在测试待测程序的登录功能时，用于测试的账号、密码就是测试资源。当测试实例包括多个节点Task时，可能需要调用多个测试资源，例如，每个节点Task都有对应的测试资源。

其中，每个节点Task对应的测试资源可以是预先设置的，例如，测试程序的登录功能时，其相应的测试资源可以包括预设的多个账号、密码数据。还可以由用户指定节点Task对应的测试资源。

其中，可以判断测试实例对应的测试资源是否充足，若充足，则可以根据测试资源运行该测试实例。

在一种实施方式中，充足是指每个节点Task所对应的资源都存储在系统中，具体存储的位置不做限制。

在另一种实施方式中，可以由测试平台的主节点接收测试任务，并调用多个从节点Worker分别执行测试用例中的节点Task，例如，测试实例中包括5个Task，可以调用5个Worker分别执行这5个Task，也可以调用2个Worker执行这5个Task，具体的调用Work的数量可以根据节点Task运行时消耗的资源情况设定。这种实施方式中，资源充足还包括从节点Worker资源充足。

具体的，测试用例在执行完毕后会输出结果，可以将这些结果写入数据库，以便用户对其进行查询。

本实施例提供的方法用于对软件进行自动化测试，该方法由安装有本实施例提供的方法的装置执行，该装置通常以硬件和/或软件的方式来实现。

本实施例提供的自动化测试方法，包括：根据用户指令生成待测程序对应的测试实例；根据测试实例确定测试资源，并确定测试实例对应的测试资源是否充足，若是，则运行测试实例。本实施例提供的方法可以根据用户指令生成相应的测试用例，从而能够根据用户的测试需求生成相应的测试用例，再基于该测试用例及其对应的测试资源进行测试，能够仅通过执行本实施例提供的方法的装置，就能够对待测试软件的进行所有类型的测试，进而提高测试效率。

图2为本发明另一示例性实施例示出的自动化测试方法的流程图。

如图2所示，本实施例提供的自动化测试方法，包括：

步骤201，接收用户输入的参数。

其中，用户可以在测试平台的前端设置测试参数，例如，用户设置多个测试的节点Task，并设置这些节点Task的执行顺序。当用户需要测试的功能不在软件的工作流Pipeline中时，用户可以通过设置节点Task及其执行顺序的方式，对软件的该功能进行测试。

具体的，用户还可以在测试平台的前端选择待测试软件中包括的工作流Pipeline，将其作为测试对象。

进一步的，用户还可以设置与每个节点Task对应的测试资源，该测试资源可以预先设置好，也可以由用户进行手动设置。

在用户设置好相应的参数后，可以点击执行按钮，以使测试平台接收用户输入的参数。

其中，对于一个待测试程序来说，可能有多个测试类型，并根据多个测试类型对其进行测试。此时，用户可以设置多个测试类型，并设置每个测试类型对应的参数，测试类型可以包括功能测试、性能对比测试、SC触发测试、内存泄漏测试、结果Diff测试、召回性测试、稳定性测试、流量复制测试等等，每个类型的测试都可以认为是一条由多个节点Task组成的工作流Pipeline。

步骤202，根据参数确定待测程序的节点及节点顺序。

进一步的，可以根据用户输入的参数确定节点及其顺序。若用户输入的参数中包括节点Task及其相应的顺序，则可以直接获取这些信息，若用户输入的参数包括工作流Pipeline，则用户可以获取该工作流中包括的节点Task及其相应的顺序。

步骤203，根据节点及节点顺序生成测试实例。

实际应用时，节点Task是构成程序的最小单元，对最小单元节点进行高度抽象，可以根据这些最小单元的执行顺序生成测试实例，从而使得这些最小单元能够被重复使用。例如，对程序的第一个功能进行测试时，设置的节点是Task1、Task2、Task3；对程序的第二个功能进行测试时，设置的节点是Task1、Task4、Task5，在这种情况下，可以分别根据Task1、Task2、Task3及其设置顺序生成测试实例1，根据Task1、Task4、Task5及其设置顺序生成测试实例2，分别完成测试。此时不需要用户手动编写测试实例，只要设置与测试功能相应的节点就可以实现测试，且节点Task能够被重复使用，从而更进一步的降低测试成本。

另外，本实施例提供的方法，可以根据用户输入的参数生成测试实例，当用户需要对待测程序进行多类型的测试时，可以根据用户输入的参数生成多个类型的测试实例，从而实现通过一个测试平台完成多类型测试的目的。

其中，当用户设置的参数是节点Task时，可以根据节点及节点顺序生成工作流，并生成工作流的实例。当用户设置的参数本身就是工作流时，还可以不包括步骤202，直接生成该工作流的实例。

步骤204，根据节点确定至少一个从节点，其中，从节点用于运行至少一个测试实例中的节点。

具体的，由于测试实例是基于节点Task生成的，因此，测试实例中包括各个节点Task，可以基于其中包括的节点Task确定从节点Worker，Worker可以是运行节点Task的设备。

进一步的，可以根据节点Task消耗资源的情况确定从节点Worker数量。例如，当节点Task消耗较大时，则可以由一个从节点Worker运行该Task，当存在两个节点Task消耗资源都较小时，则可以由一个从节点Worker运行这两个Task，具体设置情况可以根据从节点Worker的配置以及Task消耗资源的情况而定。

实际应用时，节点Task调用的资源逻辑越复杂，其消耗资源越多。

其中，节点Task可以是待运行的代码程序，从节点Worker用于运行这些代码程序。

步骤205，根据节点对应的节点测试资源、从节点确定测试实例对应的测试资源。

具体的，若用户设置的参数包括节点Task及其顺序时，可以根据节点Task对应的节点测试资源确定测试实例对应的测试资源；若用户设置的参数包括工作流Pipeline，则根据该工作流Pipeline包括的所有节点Task的节点测试资源确定测试实例对应的测试资源。

进一步的，还可以根据从节点Worker确定实例资源，例如，可以根据从节点Worker是否存在，以及从节点Worker内的计算资源等方面确定测试实例的测试资源。

实际应用时，在测试实例运行时，也可以由各个从节点Worker执行节点Task，从而实现整个测试实例被执行。

步骤206，确定测试实例对应的测试资源是否充足。

其中，可以具体确定测试资源中的节点测试资源以及从节点Worker资源是否充足，从而确定测试资源是否充足。若节点测试资源存在，且从节点Worker的计算资源充足，则可以认为测试实例对应的测试资源充足。

若是，则执行步骤207，否则，执行步骤211。

步骤207，运行测试实例。

步骤206-207与步骤102的具体原理和实现方式类似，此处不再赘述。

在步骤207之后，还包括步骤208。

步骤208，将测试实例中每个节点的运行状态写入数据库。

实际应用时，从节点Worker在运行节点Task时，可以由从节点Worker将运行状态写入数据库中，使得测试结果有据可查。例如，测试实例中的Task1运行完毕，测试实例中的Task2运行完毕。

其中，数据库中还可以记录测试结果，例如记录成功或失败。从节点Worker在运行节点Task时，可以将运行结果与预设结果比对，若相同，则在数据库中记录成功，否则，在数据库中记录失败。

并且，还可以使得用户在查询测试状态时，可以根据数据中的数据向用户反馈测试状态。

步骤209，接收查询测试实例测试状态的查询请求。

在运行测试实例的过程中，用户可以通过测试平台的前端查询测试实例的测试状态。例如，可以点击查询状态的按钮向测试平台发送查询请求，该查询请求中可以包括测试标识。

其中，测试平台在生成测试实例之后，还可以包括步骤：

根据测试实例生成测试标识，并向用户反馈所述测试标识。

用户可以根据测试平台向其反馈的测试标识查询测试状态。用户可以在测试平台的前端输入测试标识，并点击查询按钮，从而向测试平台发送查询请求。测试标识可以是测试实例的ID。

步骤210，根据查询请求在数据库中确定测试实例对应的节点的运行状态，根据节点的运行状态确定测试实例的测试状态，并反馈测试状态。

具体的，测试平台可以根据查询请求在数据库中查找相应测试实例的节点的运行状态。例如可以根据查询请求中包括的测试实例标识，查找测试实例的节点的运行状态，如运行状态可以是测试实例1的节点3的运行状态为完毕，成功。

进一步的，可以根据测试实例中每个节点的运行状态确定该测试实例的测试状态。例如全部节点的运行状态均完毕，则该测试实例的测试状态也为完毕。

实际应用时，可以由测试平台的后端将测试状态发送到测试平台的前端，从而使用户能够通过测试平台前端看到测试实例的测试状态。

步骤211，将测试实例放入任务池中，并按照预设规则运行测试实例。

其中，可以预先设置任务池，用于存放资源不充足的测试实例。还可以设置预设规则，用于运行资源不充足的测试实例。

在一种实施方式中，将测试实例放入任务池后，可以定期轮询测试资源，若测试用例对应的测试资源充足，则运行该测试用例，具体可以将其提交给从节点Worker，由从节点Worker获取该测试用例的测试资源，并运行该测试用例。

在另一种实时方式中，还可以将任务池中的测试实例按照一定规则提交给从节点Worker，以使从节点Worker继续运行这些测试用例。

进一步的，可以按照FIFO规则将任务池中的测试实例提交给从节点Worker。FIFO规则是先入先出队列，可以将先放到任务池中的测试实例发送给从节点Worker。

其中，在步骤210之后，也可以接受用户发送的查询测试状态的步骤，此时，可以向用户反馈测试资源不充足的信息。

实际应用时，在测试实例运行完毕后，若测试失败，则可以向待测试程序的开发人员发送失败的消息，还可以发送包括测试失败数据的消息。若测试成功，则可以自动生成测试报告。

本实施例提供的自动化测试方法中，还可以包括预发场景，每个待测试程序都包括不同类型的工作流，具体包含服务部署、启动、停止，方便各个程序快速部署。还可以通过拓扑关系建立完整业务的上下游链路，从而在测试时，可以测试一个完整的业务。

其中，本实施例提供的方法中，在对待测试程序进行测试时，可以更改的只有正在测试的业务，例如测试登录功能，则只有登录功能对应的数据可以被更改，其他数据均不变，从而避免其他数据改变造成测试不准确的问题。

图3为本发明一示例性实施例示出的自动化测试平台的结构图。

如图3所示，本实施例提供的自动化测试平台，包括：

生成模块31，用于根据用户指令生成待测程序对应的测试实例；

运行模块32，用于根据所述测试实例确定测试资源，并确定所述测试实例对应的测试资源是否充足，若是，则运行所述测试实例。

其中，生成模块31与运行模块32连接。

本实施例提供的自动化测试平台，包括生成模块，用于根据用户指令生成待测程序对应的测试实例；运行模块，用于根据测试实例确定测试资源，并确定测试实例对应的测试资源是否充足，若是，则运行测试实例。本实施例提供的自动化测试平台，可以根据用户指令生成相应的测试用例，从而能够根据用户的测试需求生成相应的测试用例，再基于该测试用例及其对应的测试资源进行测试，能够仅通过本实施例提供的测试平台，就能够对待测试软件的进行所有类型的测试，进而提高测试效率。

本实施例提供的自动化测试平台的具体原理和实现方式均与图1所示的实施例类似，此处不再赘述。

图4为本发明另一示例性实施例示出的自动化测试平台的结构图。

如图4所示，在上述实施例的基础上，本实施例提供的自动化测试平台，所述生成模块31，包括：

接收单元311，用于接收所述用户输入的参数；

确定单元312，用于根据所述参数确定待测程序的节点及节点顺序；

生成单元313，用于根据所述节点及所述节点顺序生成所述测试实例。

其中，所述生成单元313具体用于：

根据所述节点及所述节点顺序生成工作流，并生成所述工作流的实例。

可选的，所述运行模块32，包括：

从节点确定单元321，用于根据所述节点确定至少一个从节点，其中，所述从节点用于运行至少一个所述测试实例中的所述节点；

资源确定单元322，用于根据所述节点对应的节点测试资源、所述从节点确定所述测试实例对应的所述测试资源。

可选的，所述测试平台还可以包括：

写入模块33，用于将所述测试实例中每个所述节点的运行状态写入数据库。

还包括查询模块34，用于：

接收查询所述测试实例测试状态的查询请求；

根据所述查询请求在所述数据库中确定所述测试实例对应的所述节点的运行状态，根据所述节点的运行状态确定所述测试实例的测试状态，并反馈所述测试状态。

可选的，若所述测试实例对应的所述测试资源不充足，则：

所述运行模块32将所述测试实例放入任务池中，并按照预设规则运行所述测试实例。

本实施例提供的自动化测试平台的具体原理和实现方式均与图2所示的实施例类似，此处不再赘述。

图5为本发明一示例性实施例示出的自动化测试设备的结构图。

如图5所示，本实施例提供的自动化测试设备包括：

存储器51；

处理器52；以及

计算机程序；

其中，所述计算机程序存储在所述存储器51中，并配置为由所述处理器52执行以实现如上所述的任一种自动化测试方法。

本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，

所述计算机程序被处理器执行以实现如上所述的任一种自动化测试方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (14)

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

根据用户指令生成待测程序对应的测试实例；

根据所述测试实例确定测试资源，并确定所述测试实例对应的测试资源是否充足，若是，则运行所述测试实例。

2.根据权利要求1所述的方法，其特征在于，所述根据用户指令生成待测程序对应的测试实例，包括：

接收所述用户输入的参数；

根据所述参数确定待测程序的节点及节点顺序；

根据所述节点及所述节点顺序生成所述测试实例。

3.根据权利要求2所述的方法，其特征在于，所述根据所述节点及所述节点顺序生成所述测试实例，包括：

根据所述节点及所述节点顺序生成工作流，并生成所述工作流的实例。

4.根据权利要求2或3所述的方法，其特征在于，所述根据所述测试实例确定测试资源，包括：

根据所述节点确定至少一个从节点，其中，所述从节点用于运行至少一个所述测试实例中的所述节点；

根据所述节点对应的节点测试资源、所述从节点确定所述测试实例对应的所述测试资源。

5.根据权利要求2或3所述的方法，其特征在于，还包括：

将所述测试实例中每个所述节点的运行状态写入数据库。

6.根据权利要求5所述的方法，其特征在于，还包括：

接收查询所述测试实例测试状态的查询请求；

根据所述查询请求在所述数据库中确定所述测试实例对应的所述节点的运行状态，根据所述节点的运行状态确定所述测试实例的测试状态，并反馈所述测试状态。

7.根据权利要求1所述的方法，其特征在于，若所述测试实例对应的所述测试资源不充足，则：

将所述测试实例放入任务池中，并按照预设规则运行所述测试实例。

8.一种自动化测试平台，其特征在于，包括：

生成模块，用于根据用户指令生成待测程序对应的测试实例；

运行模块，用于根据所述测试实例确定测试资源，并确定所述测试实例对应的测试资源是否充足，若是，则运行所述测试实例。

9.根据权利要求8所述的平台，其特征在于，所述生成模块，包括：

接收单元，用于接收所述用户输入的参数；

确定单元，用于根据所述参数确定待测程序的节点及节点顺序；

生成单元，用于根据所述节点及所述节点顺序生成所述测试实例。

10.据权利要求9述的平台，其特征在于，所述运行模块，包括：

从节点确定单元，用于根据所述节点确定至少一个从节点，其中，所述从节点用于运行至少一个所述测试实例中的所述节点；

资源确定单元，用于根据所述节点对应的节点测试资源、所述从节点确定所述测试实例对应的所述测试资源。

11.根据权利要求9所述的平台，其特征在于，还包括：

写入模块，用于将所述测试实例中每个所述节点的运行状态写入数据库；

还包括查询模块，用于：

接收查询所述测试实例测试状态的查询请求；

根据所述查询请求在所述数据库中确定所述测试实例对应的所述节点的运行状态，根据所述节点的运行状态确定所述测试实例的测试状态，并反馈所述测试状态。

12.根据权利要求8所述的平台，其特征在于，若所述测试实例对应的所述测试资源不充足，则：

所述运行模块将所述测试实例放入任务池中，并按照预设规则运行所述测试实例。

13.一种自动化测试设备，其特征在于，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并配置为由所述处理器执行以实现如权利要求1-7任一种所述的方法。

14.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被处理器执行以实现如权利要求1-7任一种所述的方法。

Images