CN105843742A - 回归测试方法和*** - Google Patents

Abstract

本发明实施例提供一种回归测试方法和***，其中方法包括：将与服务器端中的功能组件关联的测试应用部署在多个测试终端上；允许多个测试终端在运行测试应用时调用与功能组件关联的规则中心库，其中，规则中心库包括运行测试应用时所需的配置文件和预期的运行结果；接收测试终端运行测试应用后返回的测试报告，其中测试报告中至少包含测试结果和预期的运行结果的对比。本发明实施例提供的回归测试方法和***，通过大规模部署测试应用，建立自主测试逻辑，克服了现有技术中无法进行大规模测试的缺陷，实现了大规模的自动化测试。

Description

回归测试方法和***

技术领域

本发明实施例涉及测试技术领域，尤其涉及一回归测试方法和***。

背景技术

回归测试作为软件生命周期的一个组成部分，旨在检验软件原有功能在修改后是否保持完整。随着现有应用的复杂度不断的提高，新版本的开发需要在各个阶段进行多次回归测试，这对于回归测试也提出了更高的要求。

现有技术中，回归测试的方法通常是将所要测试的软件返回公司客户端进行测试，处理问题较少，且每次间隔时间较长，或在做出较大更新后进行一次回归测试，并在最后通过人工检测或者简单的命令来检查测试结果。

这样的回归测试在验证复杂度较低或者数量较少的情况下可以满足需求，但随着设计和验证情况变得越来越复杂，现有技术越来越难以满足不同设计验证阶段对回归测试提出的要求。现代服务器对象逐渐增多，服务业务逐渐增大，当***添加一个新功能时，很难在较短时间内完成所有要求的回归测试。另外由于地域及网络限制，也很难在有限时间内对新功能进行大规模回归测试。

发明内容

本发明实施例提供一种回归测试方法和***，用以解决现有技术中服务器端的回归测试复杂度较低、无法实现大规模测试的问题。

本发明实施例提供一种回归测试方法，包括：

将与服务器端中的功能组件关联的测试应用部署在多个测试终端上；

允许所述多个测试终端在运行所述测试应用时调用与所述功能组件关联的规则中心库，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

接收所述测试终端运行测试应用后返回的测试报告，其中所述测试报告中至少包含测试结果和预期的运行结果的对比。

本发明实施例提供一种回归测试方法，包括：

运行与服务器端中的功能组件关联的测试应用，调用与所述功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

至少根据所述测试结果和所述预期的运行结果的对比，生成测试报告；

将所述测试报告上报给服务器端。

本发明实施例还提供了一种回归测试***，包括：

部署单元，配置用于将与服务器端中的功能组件关联的测试应用部署在多个测试终端上；

调用控制单元，配置用于允许所述部署单元部署的多个测试终端在运行所述测试应用时调用与所述功能组件关联的规则中心库，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

接收单元，配置用于接收所述测试终端运行测试应用后返回的测试报告，其中所述测试报告中至少包含测试结果和预期的运行结果的对比。

本发明实施例还提供了一种回归测试***，包括：

运行控制单元，配置用于运行与服务器端中的功能组件关联的测试应用，调用与所述功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

报告生成单元，配置用于至少根据所述测试结果和所述预期的运行结果的对比，生成测试报告；

上报单元，配置用于将所述报告生成单元生成的测试报告上报给所述服务器端。

本发明实施例提供的回归测试方法和***，通过大规模部署测试应用，建立自主测试逻辑，克服了现有技术中无法进行大规模测试的缺陷，实现了大规模的自动化测试。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为可以应用于本发明实施例的示例性***架构；

图2为本发明回归测试方法的一个实施例流程图；

图3为本发明回归测试方法的另一个实施例流程图；

图4为本发明回归测试方法的又一个实施例流程图；

图5为本发明回归测试方法的再一个实施例流程图；

图6为本发明回归测试***一个实施例结构示意图；

图7为本发明回归测试***另一个实施例结构示意图；

图8为本发明回归测试***又一个实施例结构示意图；

图9为本发明回归测试***再一个实施例结构示意图；

图10为可以应用于实现本发明实施例的终端设备或服务器的计算机***的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1示出了可以应用本申请实施例的示例性***架构100。

如图1所示，***架构100可以包括终端设备101、102、网络103和服务器104。网络103用以在终端设备101、102和服务器104之间提供通信链路的介质。网络103可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户110可以使用终端设备101、102通过网络103与服务器104交互，以接收或发送消息等。终端设备101、102上可以安装有各种通讯客户端应用，例如即时通信工具、邮箱客户端、社交平台软件、音频视频软件等。

终端设备101、102可以是各种电子设备，包括但不限于个人电脑、智能手机、平板电脑、个人数字助理、可穿戴设备等等，终端设备101、102还可以是智能家电、路由器等。

服务器104可以是提供各种服务的服务器。服务器可以对接收到的数据进行存储、分析等处理，并将处理结果反馈给终端设备。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

首先参考图2，其示出了本发明回归测试方法的一个实施例流程图200。

如图2所示，在步骤201中，将与服务器端中的功能组件关联的测试应用部署在多个测试终端上。

在本实施例中，把与功能组件关联的测试应用部署在多个测试终端上。其中多个测试终端可以是多个地域的多个测试终端，测试终端可以是如图1中所示的101和102，即各种电子设备。通过大规模的部署，可以实现大规模的测试，并且由于测试终端可以属于多个地域，所以可以进行多地域的测试，避免在本地做完回归测试之后再分发到各地区又出现各种由于网络、地域而引起的问题。

接着，在步骤202中，允许所述多个测试终端在运行所述测试应用时调用与所述功能组件关联的规则中心库，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果。

在本实施例中，规则中心库可以是存储着关联的函数的库，也可以是数据库中的对应表，还可以是其他形式的对应关系，本申请在此方面没有限制。其中主要存储的是测试应用时所需的配置文件和预期的运行结果。例如，配置文件可以是测试请求，预期的运行结果可以包含预期的运行时间和md5值等，本申请在此方面没有限制。

之后，在步骤203中，接收所述测试终端运行测试应用后返回的测试报告，其中所述测试报告中至少包含测试结果和预期的运行结果的对比。

在本实施例中，终端运行测试应用之后会向服务器返回一个测试报告，该测试报告中至少可以包括测试结果和预期的运行结果的对比。服务器接收该文件并将其存储起来以备之后对数据进行整理。

进一步参考图3，其示出了本发明回归测试方法的另一个实施例流程图300。

如图3所示，在步骤301中，选择多个地域的多个测试终端。

其中，多个地域可以包括国内的多个地区，北京，上海，重庆等，也可以是国外的某个地方如纽约，伦敦等。可以理解为在全球的多个地区部署多个测试终端。测试终端可以是手机，电脑，电视，路由器等。

继而，在步骤302中，将与服务器端中的功能组件关联的测试应用部署在多个测试终端上。

接着，在步骤303中，允许所述多个测试终端在运行测试应用时调用与功能组件关联的规则中心库。

之后，在步骤304中，接收测试终端运行测试应用后返回的测试报告。

由于上述三个步骤与图2中的步骤201，步骤202，步骤203相互对应，在此不再赘述。

然后，在步骤304中，统计一段时间内的所有测试报告中出现测试结果和预期的运行结果的对比不一致的测试报告的数量。

在本实施例中，基于之前接收的测试报告，对其中出现测试结果和预期的运行结果的对比不一致的测试报告进行统计。即如果预期结果是2s内返回，返回某一个界面，而测试结果中没有在相应时间内返回，或者返回的界面与预期的界面不同，则认为该测试结果与预期的运行结果不一致。

最后，在步骤305中，当所述数量大于预定阈值时，取消所述服务器端中的所述功能组件。

在本实施例中，可以设定一个预定阈值，当不一致测试报告的数量超过此阈值，则说明此次发布的新功能BUG较多，不宜发布，需要撤回，于是可以取消服务器端的该功能组件。

在本实施例中，通过统计不一致的测试报告，可以很好地把控功能组件的质量，当出现问题时可以及时取消该组件。并且由于测试的范围较大，终端较多，测试结果也会比较客观，不容易受网络状态、终端状况和地域情况的影响。

参考图4，其示出了本发明回归测试方法的又一个实施例流程图400。

如图4所示，在步骤401中，运行与服务器端的功能组件关联的测试应用，调用与功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果。

在本实施例中，通过运行相关测试应用，对功能组件进行测试。而在该过程中，通过调用规则中心库中的相应的配置文件，可以生成测试结果。

继而，在步骤402中，至少根据所述测试结果和所述预期的运行结果的对比，生成测试报告。

在本实施例中，通过比对之前生成的测试结果与规则中心库中的预期结果，即可以得出测试报告。该测试报告中可以记载测试结果与预期结果是否一致，以及不一致时的测试环境，日志文件等。

之后，在步骤403中，将所述测试报告上报给服务器端。

在本实施例中，生成测试报告之后，将该测试报告再发回给服务器以供服务器进行数据的收集和整理。

在本实施例中，由于在规则中心库中整理出来每一个测试请求所对应的预期结果，只需比对该预期结果和测试结果即可。极大地缩短了回归测试的流程和时间。

进一步参考图5，其示出了本发明回归测试方法的再一个实施例流程图500。

如图5所示，在步骤501中，检测测试终端的网络状况和/或负载状况。

在本实施例中，由于终端会存在网络付费及不同的负载情况，而测试的原则应该是不影响终端的正常工作，所以可以选择在终端空闲的时候，或者是至少应该在终端处于非付费网络时进行相关测试。当然，还可以是在凌晨之后的某一段时间用户终端处于非使用状态而又有非付费网络连接时进行相关测试。

之后，在步骤502中，当检测到所述测试终端处于非付费网络和/或所述测试终端为轻负载时，允许启动与服务器端中的功能组件关联的测试应用。

在本实施例中，通过之前的检测，在终端空闲，轻负载时可以进行相关测试，非付费网络也是需要的，以免产生额外的费用。

在步骤503中，运行与服务器端中的功能组件关联的测试应用，调用与所述功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果。

在步骤504中，至少根据所述测试结果和所述预期的运行结果的对比，生成测试报告。

在步骤505中，将所述测试报告上报给服务器端。

其中，步骤503，步骤504和步骤505与图4中的步骤401，步骤402和步骤403对应，在此不再赘述。

请参考图6，其示出了本发明回归测试***一个实施例结构示意图600。

如图6所示，本发明的回归测试***600包括部署单元601，调用控制单元602以及接收单元603。其中，部署单元601，配置用于将与服务器端中的功能组件关联的测试应用部署在多个测试终端上；调用控制单元602，配置用于允许所述部署单元部署的多个测试终端在运行所述测试应用时调用与所述功能组件关联的规则中心库，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；接收单元603，配置用于接收所述测试终端运行测试应用后返回的测试报告，其中所述测试报告中至少包含测试结果和预期的运行结果的对比。

进一步参考图7，其示出了本发明回归测试***另一个实施例结构示意图700。

如图7所示，本发明的回归测试***600包括选择单元701，部署单元,702，调用控制单元703，接收单元704，统计单元705以及回滚单元706。其中，选择单元701，配置用于选择多个地域的多个测试终端；部署单元702，配置用于将与服务器端中的功能组件关联的测试应用部署在多个测试终端上；调用控制单元703，配置用于允许所述部署单元部署的多个测试终端在运行所述测试应用时调用与所述功能组件关联的规则中心库，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；接收单元704，配置用于接收所述测试终端运行测试应用后返回的测试报告，其中所述测试报告中至少包含测试结果和预期的运行结果的对比；统计单元705，配置用于统计一段时间内的所有测试报告中出现测试结果和预期的运行结果的对比不一致的测试报告的数量；以及回滚单元706，配置用于当所述统计单元统计的数量大于预定阈值时，取消所述服务器端中的所述功能组件。

参考图8，其示出了本发明回归测试***又一个实施例结构示意图800。

如图8所示，本发明回归测试***800包括运行控制单元801，报告生成单元802和上报单元803。其中，运行控制单元801，配置用于运行与服务器端中的功能组件关联的测试应用，调用与所述功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；报告生成单元802，配置用于至少根据测试结果和预期的运行结果的对比，生成测试报告；以及上报单元803，配置用于将报告生成单元生成的测试报告上报给所述服务器端。

进一步参考图9，其示出了本发明回归测试***再一个实施例结构示意图900。

如图9所示，本发明回归测试***包括检测单元901，启动控制单元902，运行控制单元903，报告生成单元904和上报单元905。其中，检测单元901，配置用于检测测试终端的网络状况和/或负载状况；启动控制单元902，配置用于当检测单元检测到所述测试终端处于非付费网络和/或所述测试终端为轻负载时，允许启动与服务器端中的功能组件关联的测试应用；运行控制单元903，配置用于运行与服务器端中的功能组件关联的测试应用，调用与所述功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；报告生成单元904，配置用于至少根据测试结果和预期的运行结果的对比，生成测试报告；以及上报单元905，配置用于将报告生成单元生成的测试报告上报给所述服务器端。

应当理解，图6、图7、图8和图9中记载的诸单元与图2、图3、图4以及图5描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征以及技术效果同样适用于图6、图7、图8和图9中的诸单元，在此不再赘述。

值得注意的是，本发明的实施例中的单元并不用于限制本发明的方案，例如部署单元可以描述为用于将与服务器端中的功能组件关联的测试应用部署在多个测试终端上的单元。另外，还可以通过硬件处理器来实现相关功能模块，例如部署单元也可以用处理器实现，在此不再赘述。

下面参考图10，其示出了适于用来实现本申请实施例的终端设备或服务器的计算机***1000的结构示意图。

如图10所示，计算机***1000包括中央处理单元(CPU)1001，其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行各种适当的动作和处理。在RAM 1003中，还存储有***1000操作所需的各种程序和数据。CPU 1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。

以下部件连接至I/O接口1005：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。

特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

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

Claims (12)

1.一种回归测试方法，包括：

将与服务器端中的功能组件关联的测试应用部署在多个测试终端上；

允许所述多个测试终端在运行所述测试应用时调用与所述功能组件关联的规则中心库，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

接收所述测试终端运行测试应用后返回的测试报告，其中所述测试报告中至少包含测试结果和预期的运行结果的对比。

2.根据权利要求1所述的方法，其中，在将测试应用部署在多个测试终端上之前包括选择多个地域的多个测试终端。

3.根据权利要求1所述的方法，其中，所述预期的运行结果包括反馈时间和预期返回值。

4.根据权利要求1-3中任一项所述的方法，其中，在接收所述测试终端运行测试应用后返回的测试报告后包括：

统计一段时间内的所有测试报告中出现测试结果和预期的运行结果的对比不一致的测试报告的数量；

当所述数量大于预定阈值时，取消所述服务器端中的所述功能组件。

5.一种回归测试方法，包括：

运行与服务器端中的功能组件关联的测试应用，调用与所述功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

至少根据所述测试结果和所述预期的运行结果的对比，生成测试报告；

将所述测试报告上报给服务器端。

6.根据权利要求5所述的方法，其中，在运行与服务器端中的功能组件关联的测试应用之前还包括：

检测测试终端的网络状况和/或负载状况；

当检测到所述测试终端处于非付费网络和/或所述测试终端为轻负载时，允许启动与服务器端中的功能组件关联的测试应用。

7.一种回归测试***，包括：

部署单元，配置用于将与服务器端中的功能组件关联的测试应用部署在多个测试终端上；

调用控制单元，配置用于允许所述部署单元部署的多个测试终端在运行所述测试应用时调用与所述功能组件关联的规则中心库，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

接收单元，配置用于接收所述测试终端运行测试应用后返回的测试报告，其中所述测试报告中至少包含测试结果和预期的运行结果的对比。

8.根据权利要求7所述的***，其中，在所述部署单元之前还包括选择单元，配置用于选择多个地域的多个测试终端。

9.根据权利要求7所述的***，其中，所述预期的运行结果包括反馈时间和预期返回值。

10.根据权利要求7-9中任一项所述的***，其中，在所述接收单元之后还包括：

统计单元，配置用于统计一段时间内的所有测试报告中出现测试结果和预期的运行结果的对比不一致的测试报告的数量；

回滚单元，配置用于当所述统计单元统计的数量大于预定阈值时，取消所述服务器端中的所述功能组件。

11.一种回归测试***，所述***包括：

运行控制单元，配置用于运行与服务器端中的功能组件关联的测试应用，调用与所述功能组件关联的规则中心库，生成测试结果，其中，所述规则中心库包括运行所述测试应用时所需的配置文件和预期的运行结果；

报告生成单元，配置用于至少根据所述测试结果和所述预期的运行结果的对比，生成测试报告；

上报单元，配置用于将所述报告生成单元生成的测试报告上报给所述服务器端。

12.根据权利要求11所述的***，其中，在所述运行控制单元之前还包括：

检测单元，配置用于检测测试终端的网络状况和/或负载状况；

启动控制单元，配置用于当检测单元检测到所述测试终端处于非付费网络和/或所述测试终端为轻负载时，允许启动与服务器端中的功能组件关联的测试应用。