CN105589802A - 软件测试方法及装置 - Google Patents

Abstract

一种软件测试方法及装置，所述方法包括：获取测试案例；启动待测试软件，通过所述待测试软件的用户界面组接收所述测试案例传递的测试参数，驱动待测试软件进行测试，并获取所述待测试软件对于所接收的测试参数的处理结果，所述用户界面组包括两个以上的用户界面，所述用户界面之间具有预设的流转关系；根据所述处理结果，分析得到测试结果。上述的方案可以实现软件的自动化测试，提高软件测试的效率。

Description

软件测试方法及装置

技术领域

本申请涉及软件测试技术领域，特别是涉及一种软件测试方法及装置。

背景技术

随着技术的不断深入发展，移动终端正在从简单的通话工具变为一个综合信息处理平台。这也给移动终端增加了更加宽广的发展空间。

随着智能手机等移动终端设备的普及，人们逐渐习惯了使用应用客户端上网的方式，而目前国内各大电商，均拥有了自己的应用客户端，这标志着，应用客户端的商业使用，已经开始初露锋芒。

现有技术中，在对应用软件进行测试时，一般通过人工完成，工作量异常繁重。因此，现有技术中应用软件的测试方法存在着效率低。

发明内容

本申请实施例解决的是如何实现软件的自动测试，提高软件测试的效率。

为解决上述问题，本申请实施例提供了一种软件测试方法，所述方法包括：

获取测试案例；

启动待测试软件，通过所述待测试软件的用户界面组接收所述测试案例传递的测试参数，驱动待测试软件进行测试，并获取所述待测试软件对于所接收的测试参数的处理结果，所述用户界面组包括两个以上的用户界面，所述用户界面之间具有预设的流转关系；

根据所述处理结果，分析得到测试结果。

可选地，所述待测试软件为应用软件。

可选地，所述启动待测试软件包括：采用反射机制启动所述待测试软件。

可选地，所述启动待测试软件，并通过所述待测试软件的用户界面接收所述测试案例传递的测试参数，驱动待测试软件进行测试，获取所述待测试软件对于所接收的测试参数的处理结果，包括：

启动所述待测试软件的用户界面接收测试案例发送的测试参数；

获取所述待测试软件对于所述用户界面接收的测试参数的执行结果；

判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件；

当确定所述执行结果满足预设的条件时，启动所述待测试软件的下一用户界面接收所述测试案例发送的测试参数，并执行获取所述待测试软件对于所述下一用户界面接收的测试参数的执行结果，判断所述待测试软件对于所述下一用户界面接收的测试参数的执行结果是否满足预设的条件的操作，直至遍历所述用户界面组中的所有用户界面。

可选地，所述判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件包括：通过消息调用相应的处理类，判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件。

可选地，所述启动待测试软件，并通过所述待测试软件的用户界面接收所述测试案例传递的测试参数，驱动待测试软件进行测试，获取所述待测试软件对于所接收的测试参数的执行结果，还包括：当确定所述执行结果不满足预设的条件时，发布错误提示信息。

本申请实施例还提供了一种软件测试装置，所述装置包括：

获取单元，适于获取测试案例；

测试单元，适于启动待测试软件，通过所述待测试软件的用户界面组接收所述测试案例传递的测试参数，驱动待测试软件进行测试，并获取所述待测试软件对于所接收的测试参数的处理结果，所述用户界面组包括两个以上的用户界面，所述用户界面之间具有预设的流转关系；

分析单元，适于根据所述处理结果，分析得到测试结果。

可选地，所述待测试软件为应用软件。

可选地，所述测试单元适于采用反射机制启动所述待测试软件。

可选地，所述测试单元包括：

启动子单元，适于启动所述待测试软件的用户界面接收测试案例发送的测试参数；

获取子单元，适于获取所述待测试软件对于所述用户界面接收的测试参数的执行结果；

判断子单元，适于通过消息调用相应的处理类，判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件。

测试子单元，当确定所述执行结果满足预设的条件时，启动所述待测试软件的下一用户界面接收所述测试案例发送的测试参数，并执行获取所述待测试软件对于所述下一用户界面接收的测试参数的执行结果，判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件的操作，直至遍历所述用户界面组中的所有用户界面。

可选地，所述判断子单元适于通过消息调用相应的处理类，判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件。

可选地，所述测试单元还包括：提示子单元，适于当确定所述执行结果不满足预设的条件时，发布错误提示信息。

与现有技术相比，本申请的技术方案具有以下的优点：

通过待测试软件的用户界面组的用户界面接收测试案例传递的测试参数，由于所述用户组中的用户界面具有预设的流转关系，可以在满足预设的条件时，自动启动所述用户界面组中相应的用户界面接收测试案例传递的测试参数，因此，可以实现软件的自动化测试，提高软件测试的效率。

附图说明

图1是本申请实施例中的一种软件测试方法的流程图；

图2是本申请实施例中的另一种软件测试方法的流程图；

图3是本申请实施例中的一种软件测试装置的结构示意图；

图4是本申请实施例中的一种的测试单元的结构示意图。

具体实施方式

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的子单元或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

为解决现有技术中存在的上述问题，本申请实施例采用的技术方案通过待测试软件的用户界面组的用户界面接收测试案例传递的测试参数，由于所述用户组中的用户界面具有预设的流转关系，可以在满足预设的条件时，自动启动所述用户界面组中相应的用户界面接收测试案例传递的测试参数，因此，可以实现软件的自动化测试，提高软件测试的效率。

为使本申请的上述目的、特征和优点能够更为明显易懂，下面结合附图对本申请的具体实施例做详细的说明。

图1示出了本申请实施例中的一种软件测试方法的流程图。如图1所示的软件测试方法，可以包括：

步骤S101：获取测试案例。

在具体实施中，所述测试案例中包括测试所需的测试参数。

步骤S102：启动待测试软件，通过所述待测试软件的用户界面组接收所述测试案例传递的测试参数，驱动待测试软件进行测试，并获取所述待测试软件对于所接收的测试参数的处理结果，直至遍历所述用户界面组中的所有用户界面。

在具体实施中，所述用户界面组包括两个以上的用户界面，所述用户界面之间具有预设的流转关系。

步骤S103：根据所述处理结果，分析得到测试结果。

在具体实施中，通过对所述处理结果的分析，可以得到所述待测试软件的测试结果。

图2示出了本申请实施例中的另一种软件测试方法的流程图。如图2所示的软件测试方法，可以包括：

步骤S201：获取测试案例。

在具体实施中，所述测试案例可以由用户事先编写完成，并统一存放在测试用例管理平台中，例如，存放在测试用例服务器中，用户可以通过登录所述测试用户服务器，选取特定测试目所需的测试案例，并可以指定所述测试案例的执行时间，从而可以实现测试案例的获取和运行的自动化。

在本申请一实施例中，当获取到测试所需的测试案例以后，接着可以执行测试案例的初始化，以生成测试所需的所有测试参数。例如，创建账号、订单和账号的初始化等。

步骤S202：启动所述待测试软件的用户界面接收测试案例发送的测试参数。

在本申请一实施例中，当获取到相应的测试案例以及测试所需的所有参数时，可以通过反射机制启动所述待测试的应用(APP)软件。之后，整个测试流程中的所述待测试软件的用户界面(测试执行流程中预设的首个用户界面)出现，所述用户界面接收所述测试案例传递的相应的测试参数，所述待测试软件根据所述用户界面所接收的测试参数执行相应的操作。

这里需要指出的是，所述用户界面为所述待测试软件在实际运行时，与用户进行交互的接口，例如，应用软件的欢迎界面、登陆界面等。所述用户界面可以接收用户输入的数据。

在具体实施中，测试案例传递的测试参数可以用于模拟用户输入的数据和用户对于用户界面的操作。

步骤S203：获取所述待测试软件对于所述用户界面接收的测试参数的执行结果。

在具体实施中，当接收到通过用户界面接收的测试参数时，所述待测试软件可以执行相应的操作。

例如，当所述用户界面接收到用户输入的支付一万元人民币的请求(通过测试案例执行所述的支付请求)时，待测试软件可以将用户的支付请求发送至相应的快捷支付服务端，并接收所述快捷支付服务端所发送的支付请求执行结果，并在用户界面上将所述支付请求的处理结构显示给客户。

步骤S204：判断所述待测试软件根据所述用户界面接收的测试参数的执行结果是否满足预设的条件。

在本申请一实施例中，当待测试的用户界面出现时，可以以消息通知的方式调用相应的处理类，来判断所述待测试软件根据所述用户界面接收的测试参数的执行结果是否满足预设的条件。

例如，上述的支付请求的执行流程中，当待测试软件通过用户界面所接收的用户的支付请求不成立时，例如，账号、密码错误时，待测试软件应在用户界面上将用户支付请求不成立的原因显示给客户。此时，通过消息通知的方式调用的处理类，则可以判断用户界面上是否出现用户支付请求不成立的原因的错误提示信息，以此来判断待测试软件的相应功能是否正常运行。

步骤S205：启动所述待测试软件的下一用户界面接收所述测试案例发送的测试参数，并执行获取所述待测试软件对于所述下一用户界面接收的测试参数的执行结果，判断所述待测试软件对于所述下一用户界面接收的测试参数的执行结果是否满足预设的条件的操作，直至遍历所述用户界面组中的所有用户界面。

在具体实施中，当确定所述待测试软件根据用户界面所接收的测试参数的执行结果满足预设的条件时，便可以自动启动整个测试流程中设定出现的下一用户界面。

当下一用户界面出现时，测试案例可以将相应的测试参数通过下一用户界面传递至所述待测试软件，并执行获取所述待测试软件对于下一用户界面接收的测试参数的执行结果的操作。

同样地，在本申请一实施例中，当所述待测试软件的下一界面出现时，可以通过消息通知的方式调用对应的处理类，来对所获取的待测试软件对于所述下一用户界面所接收的测试参数的执行结果进行校验，以确定所述待测试软件的相应功能是否正常运行，直至所述用户界面组中的所有用户界面遍历，整个测试过程结束。

在本申请一实施例中，当整个测试流程执行结束时，进入测试的断言阶段。在所述断言阶段可以在测试流程结束时，对于待测试软件的运行状况进行断言，例如，可以对测试流程中的用户界面组中的用户界面的断言，或者也可以为对于测试案例中的测试参数的断言等。

当通过判断确定所述待测试软件根据所述用户界面接收的测试参数的执行结果不满足预设的条件，可以执行步骤S206。

步骤S206：发布错误提示信息。

在具体实施中，当通过判断确定所述待测试软件根据所述用户界面接收的测试参数的执行结果不满足预设的条件，可以发布相应的错误提示信息，以提示相关用户采取相应的措施。

图3示出了本申请实施例中的一种软件测试装置的结构示意图。如图3所示的软件测试装置300，可以包括获取单元301、测试单元302和分析单元303，其中：

获取单元301，适于获取测试案例。

测试单元302，适于启动待测试软件，通过所述待测试软件的用户界面组接收所述测试案例传递的测试参数，驱动待测试软件进行测试，并获取所述待测试软件对于所接收的测试参数的处理结果，所述用户界面组包括两个以上的用户界面，所述用户界面之间具有预设的流转关系。

分析单元303，适于根据所述处理结果，分析得到测试结果。

图4示出了本申请实施例中的一种测试单元的结构示意图。如图4所示的测试单元400，可以包括启动子单元401、获取子单元402、判断子单元403和测试子单元404，其中：

启动子单元401，适于启动所述待测试软件的用户界面接收测试案例发送的测试参数。

获取子单元402，适于获取所述待测试软件对于所述用户界面接收的测试参数的执行结果。

判断子单元403，适于判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件。

测试子单元404，当确定所述执行结果满足预设的条件时，启动所述待测试软件的下一用户界面接收所述测试案例发送的测试参数，并执行获取所述待测试软件对于所述下一用户界面接收的测试参数的执行结果，判断判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件的操作，直至遍历所述用户界面组中的所有用户界面。

在具体实施中，所述测试单元400还可以包括：提示子单元405，适于当确定所述执行结果不满足预设的条件时，发布错误提示信息。

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

以上对本申请实施例的方法及系统做了详细的介绍，本申请并不限于此。任何本领域技术人员，在不脱离本申请的精神和范围内，均可作各种更动与修改，因此本申请的保护范围应当以权利要求所限定的范围为准。

Claims (12)

1.一种软件测试方法，其特征在于，包括：

获取测试案例；

启动待测试软件，通过所述待测试软件的用户界面组接收所述测试案例传递的测试参数，驱动所述待测试软件进行测试，并获取所述待测试软件对于所接收的测试参数的处理结果，所述用户界面组包括两个以上的用户界面，所述用户界面之间具有预设的流转关系；

根据所述处理结果，分析得到测试结果。

2.根据权利要求1所述的软件测试方法，其特征在于，所述待测试软件为应用软件。

3.根据权利要求1所述的软件测试方法，其特征在于，所述启动待测试软件包括：采用反射机制启动所述待测试软件。

4.根据权利要求1所述的软件测试方法，其特征在于，所述启动待测试软件，并通过所述待测试软件的用户界面接收所述测试案例传递的测试参数，驱动待测试软件进行测试，获取所述待测试软件对于所接收的测试参数的处理结果，包括：

启动所述待测试软件的用户界面接收测试案例发送的测试参数；

获取所述待测试软件对于所述用户界面接收的测试参数的执行结果；

判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件；

当确定所述执行结果满足预设的条件时，启动所述待测试软件的下一用户界面接收所述测试案例发送的测试参数，并执行获取所述待测试软件对于所述下一用户界面接收的测试参数的执行结果，判断所述待测试软件对于所述下一用户界面接收的测试参数的执行结果是否满足预设的条件的操作，直至遍历所述用户界面组中的所有用户界面。

5.根据权利要求4所述的软件测试方法，其特征在于，所述判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件包括：通过消息调用相应的处理类，判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件。

6.根据权利要求4所述的软件测试方法，其特征在于，所述启动待测试软件，并通过所述待测试软件的用户界面接收所述测试案例传递的测试参数，驱动待测试软件进行测试，获取所述待测试软件对于所接收的测试参数的执行结果，还包括：当确定所述执行结果不满足预设的条件时，发布错误提示信息。

7.一种软件测试装置，其特征在于，包括：

获取单元，适于获取测试案例；

测试单元，适于启动待测试软件，通过所述待测试软件的用户界面组接收所述测试案例传递的测试参数，驱动待测试软件进行测试，并获取所述待测试软件对于所接收的测试参数的处理结果，所述用户界面组包括两个以上的用户界面，所述用户界面之间具有预设的流转关系；

分析单元，适于根据所述处理结果，分析得到测试结果。

8.根据权利要求7所述的软件测试装置，其特征在于，所述待测试软件为应用软件。

9.根据权利要求7所述的软件测试装置，其特征在于，所述测试单元适于采用反射机制启动所述待测试软件。

10.根据权利要求7所述的软件测试装置，其特征在于，所述测试单元包括：

启动子单元，适于启动所述待测试软件的用户界面接收测试案例发送的测试参数；

获取子单元，适于获取所述待测试软件对于所述用户界面接收的测试参数的执行结果；

判断子单元，适于判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件。

测试子单元，当确定所述执行结果满足预设的条件时，启动所述待测试软件的下一用户界面接收所述测试案例发送的测试参数，并执行获取所述待测试软件对于所述下一用户界面接收的测试参数的执行结果，判断所述待测试软件对于所述下一用户界面接收的测试参数的执行结果是否满足预设的条件的操作，直至遍历所述用户界面组中的所有用户界面。

11.根据权利要求10所述的软件测试装置，其特征在于，所述判断子单元适于通过消息调用相应的处理类，判断所述待测试软件对于所述用户界面接收的测试参数的执行结果是否满足预设的条件。

12.根据权利要求10所述的软件测试装置，其特征在于，所述测试单元还包括：提示子单元，适于当确定所述执行结果不满足预设的条件时，发布错误提示信息。