CN112749091A - 软件回归测试方法 - Google Patents

Abstract

本申请公开了一种软件回归测试方法；方法包括：对待测试的目标软件进行探索性测试；如果探索性测试通过；则采用预先建立的全面测试用例集进行全面测试；如果全面测试通过，则采用各个渠道包对所述软件进行测试；如果采用各个渠道包对所述软件测试通过，则将所述软件上线。本申请提出了一套完整、有效的回归测试方法，提高了测试的效果，可以更多地发现BUG，降低产品上线后BUG的发生率。通过整套的用例集在发版上线前所进行的自动化回归测试、全面测试、探索测试、渠道包测试有效避免了线上回归测试不足的问题，显著减少线上事故，极大提高项目线上质量。

Description

软件回归测试方法

技术领域

本申请涉及软件测试技术领域，具体而言，涉及一种软件回归测试方法。

背景技术

随着软件技术的发展和市场对软件需求的日益提升，软件的规模越来越大，越来越复杂。所以软件产品在上线运行后的BUG也很多。现有技术中，产品上线前一般仅进行一遍测试；产品上线后，往往还会有很多BUG显现。

发明内容

本申请的主要目的在于提供一种软件回归测试方法，以解决现有技术中由于测试简单而造成产品上线后BUG较多的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种回归测试方法，包括：

对待测试的目标软件进行探索性测试；如果探索性测试通过；

则采用预先建立的全面测试用例集进行全面测试；

如果全面测试通过，则采用各个渠道包对所述软件进行测试；

如果采用各个渠道包对所述软件测试通过，则将所述软件上线。

在一种实施方式中，对待测试的目标软件进行探索性测试，包括：

分别采用安装同一种操作系统的不同品牌的终端分别对待测试的目标软件进行测试；或者，

对于任意一个品牌，分别采用不同系列的终端，依次安装不同的操作系统对待测试的目标软件进行测试；

对于同一品牌、同一系列的终端，分别采用不同的操作系统对待测试的目标软件进行测试。

在一种实施方式中，如果探索性测试或者全面测试不通过，则纪录登录过程中的BUG；将BUG发送给服务器；对所述BUG进行修复后，再次进行探索性测试。

在一种实施方式中，还包括：计算出每种BUG的数量n；

根据预先存储的每种BUG的单个解决时间t和n计算出解决该次测试的多个BUG的理论标准时间；

其中，m为BUG的种类的数量；i为变量；

比较所述TL与T的大小；

如果TL小于T，则确定解决BUG的效率低于平均效率；

如果TL大于T，则确定解决BUG的效率高于平均效率。

在一种实施方式中，还包括：对软件进行升级测试，包括：

对当前版本的软件进行升级，升级到最新版本；判断升级是否正常；

如果没有BUG，则卸载当前版本，安装最新版本的软件。

在一种实施方式中，还包括：对所述测试用例集进行更新。

在一种实施方式中，对所述测试用例集进行更新，包括：

根据当前进行的项目编写对应的新的测试用例；

将所述新的测试用例存储在测试用例集中；或者，

对于新增加的功能编写对应的测试用例；将所述新编写的测试用例存储在用例集中。

在一种实施方式中，采用各个渠道包对所述软件进行测试，包括：

获取各个应用商店的渠道包；

分别采用不同的渠道包对所述软件进行测试，分别纪录对应的BUG；

根据渠道包的标识建立渠道包和对应的BUG的对应关系表；

将所述关系表发送给研发部门的服务器，以对所述BUG进行修复。

第三方面，本申请还提出了一种测试终端，包括发送模块，用于在探索性软件测试结束后，向服务器发送BUG信息；

其中，BUG信息包括：BUG类型、数量；如果是探索性测试，BUG信息还包括终端的品牌和型号；

接收模块，用于接收服务器发送的BUG修复完毕的消息；

计算模块，用于测试结束后，根据预先存储的解决每种BUG的单个平均解决时间和所述BUG的数量计算得到解决多个BUG的理论标准时间；

其中，m为BUG的种类的数量；i为变量；

比较TL与T的大小；

如果TL小于T，则确定解决BUG的效率低于平均效率；

如果TL大于T，则确定解决BUG的效率高于平均效率；

包括发送模块，还用于向服务器发送效率比较结果。

第四方面，本申请还提出了一种服务器，包括：

接收模块，用于接收每一个第一终端发送的BUG信息；以及接收第一终端发送的效率比较结果；其中，BUG信息包括：BUG类型、数量、BUG的产生时间；如果是探索性测试，BUG信息还包括第一终端的品牌和型号；

存储模块，用于存储所述的BUG信息；

发送模块，用于将BUG信息发送给第二终端，以使研发人员修复BUG；以及将BUG修复完毕的信息发送给第一终端；以及将效率结果发送给第二终端；

第一终端用于对软件进行测试；

第二终端用于对软件进行维护；对BUG进行修复。

本发明的上述的技术方案，通过整套的用例集在发版上线前所进行的自动化回归测试、全面测试、探索测试、渠道包测试、老版本测试有效避免了线上回归测试不足的问题，大大减少甚至避免了线上事故的出现，很大程度的提高了项目的线上质量。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

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

图2是根据本申请实施例的另一种软件回归测试方法的流程图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

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

首先，介绍一下本申请的专业术语。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重。

本申请提出了一种软件回归测试方法，参见附图1所示的软件回归测试方法的流程图；该方法包括：

步骤S102，对待测试的目标软件进行探索性测试；

其中，探索性测试指的是目标软件在测试终端上进行安装；因为软件在测试终端A上能够安装成功；但是在测试终端B上可能安装失败。操作系统不同，安装的结果可能也不同。所以需要对各个品牌、型号、安装不同操作系统的测试终端分别进行初步探测性测试。

其中，测试终端可以为智能手机、平板电脑、笔记本等。

对于任意一个品牌，分别采用不同系列的测试终端，依次安装不同的操作系统进行测试；

对于同一品牌、同一系列的测试终端，分别安装不同的操作系统进行测试。

示例性的，测试终端为智能手机；采用不同品牌的手机进行测试；比如华为手机、小米手机、努比亚手机、OPPO手机等分别安装应用程序并进行登录；并且手机还可以安装不同的操作系统。

参见表1；

表1

具体进行探索性测试时，对于每一种型号的手机，每一种操作系统，分别纪录对应的测试的结果，包括BUG名称、BUG的数量、BUG的类型等。

对于同一种品牌，还可以采用不同型号的手机分别进行测试，参见表2。

表2

检测安装登录的过程；如果出现BUG，则进行记录并返给软件研发人员进行维护。

步骤S104，如果探索性测试通过；则采用预先建立的全面测试用例集进行全面测试；

其中，全面测试用例集中，包括了用户从下载安装应用程序、注册登陆、浏览页面、下订单购买药品、注销等所有流程的用例。

步骤S106，如果全面测试通过，则采用各个渠道包对所述软件进行测试；

其中，渠道包为从对应的应用商店的页面下载获得；每个渠道包设置有标识。

步骤S108，如果采用各个渠道包对所述软件测试通过，则将所述软件上线。

本发明的技术方案，通过进行探索性测试，可以发现软件在安装的过程中的一些初步显现的问题。本申请提出了一套完整、有效的回归测试方法，提高了测试的效果，可以更多地发现BUG。降低上线后的BUG发生率。

软件开发过程中版本的迭代频率也越来越快，针对此种情况，在一种实施方式中，对软件进行升级测试，对当前版本的软件进行升级，升级到最新版本；判断升级是否正常；如果没有BUG，则卸载当前版本，安装最新版本的软件。

示例性的，当前在手机中按照的软件版本为老版本的软件；对手机上的老版本软件升级到最新版本。判断升级的过程中是否有BUG；如果没有BUG，升级正常，则卸载老版本的软件，安装最新版本的软件，如果不能够正常升级，则对新版本的软件进行维护。

在一种实施方式中，还包括：对所述测试用例集进行更新。根据当前进行的项目编写对应的新的测试用例；将所述新的测试用例存储在测试用例集中；

示例性的，对于一个推荐医生的项目；需要用户进行注册，输入自己的当前的医疗信息；当用户在搜索界面输入某种疾病后，显示该疾病的医生列表；

对于如此新的项目就需要编写新的测试用例，在测试时，用户输入用户名或者密码不正确，也可能登陆进系统；或者登陆进系统之后，某个医生的头像不能够显示，或者歪曲变形，则确定存在BUG。

对于新增加的功能编写对应的测试用例；将所述新编写的测试用例存储在用例集中。

示例性的，产品新增加了一种新的功能。比如，地址管理功能，用户能够添加或者删除已经有的地址。就需要编写新的测试用例进行测试；测试过程中，可能出现的BUG有：地址不能够正常删除；地址不能够正常编辑。或者显示出了其他用户的地址。

示例性的，在对地址进行测试时，获取信息确认页中的地址信息；如果能获得地址信息，则测试正常；如果没有地址，则确定为BUG。比如，张三给李四购买药品，但是忘记填写李四的地址，则配送员无法送达。

在一种实施方式中，如果探索性测试或者全面测试不通过，则纪录登录过程中的BUG；将BUG发送给研发部门的服务器；对所述BUG进行修复后，再次进行探索性测试。

示例性的，测试人员在测试终端进行测试，测试终端可以是手机，也可以是笔记本电脑；进行探索性测试或者全面测试。

如果测试不通过，测试终端纪录BUG，将BUG信息发送给软件研发部门的服务器；

其中，BUG信息包括：此次测试发现的BUG的数量；BUG的种类；每种BUG的名称。

为了提醒研发人员及时修改BUG，在一种实施方式中，服务器接收到BUG信息后，向研发人员的客户端发送提示信息，提示有BUG产生。

具体实施时，BUG修改完成后，服务器向测试终端发送修改完成的消息。测试终端再次进行测试。测试终端可以纪录BUG发现的时间点T1；以及BUG解决完成的时间点T2；以及BUG的类型；BUG的数量。计算时间差T＝T2-T1；根据BUG的类型、BUG的数量；以及时间差计算研发的BUG解决的效率。生成响应的等级评分，从而可以促进研发人员的积极性。

具体的，在很短的一个时间内，解决了多个BUG，并且BUG的类型为严重，则确定解决BUG的效率为高。

其中，BUG等级可以预先设定。

如果BUG的数量不多，并且等级轻微，但是用了很长的时间解决，时间大于解决的平均时间或者时间阈值，则确定BUG的解决效率为低。

其中，时间阈值可以为24小时；平均解决时间可以预先对大数据进行统计得到。

为了定量计算衡量解决BUG的效率。在一种实施方式中，测试终端可以存储每种BUG的单独一个的平均解决时间t；

其中，上述的t时预先对大量的数据进行统计得到的。

测试结束后，测试终端计算出每种BUG的数量n；

测试终端根据上述的参数计算出该次测试的多个BUG的理论标准时间；

其中，m为BUG的种类的数量；i为变量；

测试终端比较上述TL与T的大小；

如果TL小于T，则确定解决BUG的效率低于平均效率；

如果TL大于T，则确定解决BUG的效率高于平均效率。

在一种实施方式中，测试终端还可以向服务器发送上述的计算结果。

当今的软件升级频繁，在一种实施方式中，还包括：对软件进行升级测试，对当前版本的软件进行升级，升级到最新版本；判断升级是否正常；如果没有BUG，则卸载当前版本，安装最新版本的软件。

在一种实施方式中，采用各个渠道包对所述软件进行测试时，获取各个应用商店的渠道包；

示例性的，分别根据华为应用商店、小米应用商店的网址下载渠道包；渠道包设置有标识。

分别采用不同的渠道包对所述软件进行测试，纪录对应的BUG；

根据渠道包的标识建立渠道包和对应的BUG的对应关系表；

将所述关系表发送给研发部门的服务器，以对所述BUG进行修复。

参见本申请提出的另一种回归测试的方法，参见附图2所示的另一种回归测试的方法的流程图；该方法包括：

步骤S201，对用例进行筛选，建立用例集。

具体实施时，可以根据当前进行的项目编写新的用例集，也可以从现有的用例集中进行筛选，并做好维护，为全面测试做好充分准备。

步骤S202，建立自动化用例集；使用自动化用例集进行自动化回归测试。

示例性的，从用例集中剔除掉非自动化用例得到自动化用例。不能够自动化进行的用例，比如，在进行登录验证的过程时，需要手动操作拖动图片到预定的位置，进行验证。

对软件的版本更新及维护。

步骤S203，在上线发版前先将测试环境以及灰度环境发现的问题进行再次回归测试，再根据用例集进行线上的全面测试。

其中，产品发版前的阶段包括测试阶段和预发布阶段。灰度环境为预发布环境。在发版前，将测试环境和预发布阶段的BUG进行再次回归测试。

步骤S204，对版本进行探索测试；

具体实施时，采用各种不同品牌、型号的测试终端和各个不同的操作系统做更深度的回归。

步骤S205，在探索测试完成后，将问题进行整理，待开发修复后再次做全面测试。

步骤S206，对新版本的各个渠道包进行线上回归验证测试，并对老版本进行线上回归。

步骤S207，发版完成后测试人员在第一时间对新版版再次进行全面测试。

第二方面，本申请还提出了一种测试终端；该测试终端用于软件测试。

包括发送模块，用于在探索性软件测试结束后，向服务器发送BUG信息。

BUG信息包括：BUG类型、数量；如果是探索性测试，BUG信息还包括测试终端的品牌和型号。

接收模块，用于接收服务器发送的BUG修复完毕的消息。

计算模块，用于测试结束后，根据预先存储的解决每种BUG的单个平均解决时间和所述BUG的数量计算得到解决多个BUG的理论标准时间；

其中，m为BUG的种类的数量；i为变量。

测试终端比较上述TL与T的大小。

如果TL小于T，则确定解决BUG的效率低于平均效率。

如果TL大于T，则确定解决BUG的效率高于平均效率。

包括发送模块，还用于向服务器发送上述的效率比较结果。

第三方面，本申请还提出了一种服务器，包括接收模块，用于接收每一个第一终端发送的BUG信息；其中，BUG信息包括：BUG类型、数量、BUG的产生时间；如果是探索性测试，BUG信息还包括第一终端的品牌和型号；

存储模块，用于存储所述的BUG信息；

值得强调的是，第一终端为多个，服务器会存储多个不同品牌、不同型号，以及不同操作系统的第一终端的信息并存储。

发送模块，用于将BUG信息发送给第二终端，以使研发人员修复BUG；以及将BUG修复完毕的信息发送给第一终端；

其中，第一终端为测试部门使用的终端，用于对软件进行测试；

第二终端为软件研发部门使用的终端，用于对软件进行维护，修复BUG。

接收模块，还用于接收第一终端发送的效率比较结果。

本申请还提出了一种测试系统，包括上述的第一终端、服务器和第二终端。

其中，第二终端用于接收到BUG信息后，对BUG进行修复；以及接收到服务器转发的效率结果。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件与软件组合来实现。当应用软件时，可以将相应功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (7)

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

对待测试的目标软件进行探索性测试；

如果探索性测试通过，则采用预先建立的全面测试用例集进行全面测试；

如果全面测试通过，则采用各个渠道包对所述软件进行测试；

如果采用各个渠道包对所述软件测试通过，则将所述软件上线。

2.如权利要求1所述的回归测试方法，其特征在于，对待测试的目标软件进行探索性测试，包括：

分别采用安装同一种操作系统的不同品牌的终端分别对待测试的目标软件进行测试；或者，

对于任意一个品牌，分别采用不同系列的终端，依次安装不同的操作系统对待测试的目标软件进行测试；

对于同一品牌、同一系列的终端，分别采用不同的操作系统对待测试的目标软件进行测试。

3.如权利要求1所述的回归测试方法，其特征在于，如果探索性测试或者全面测试不通过，则纪录BUG；将BUG信息发送给服务器；接收到服务器发送的对所述BUG进行修复完毕的信息后，再次进行探索性测试。

4.如权利要求3所述的回归测试方法，其特征在于，还包括：

计算出每种BUG的数量n；

根据预先存储的每种BUG的单个解决时间t和n计算出解决多个BUG的理论标准时间；

其中，m为BUG的种类的数量；i为变量；

比较所述TL与T的大小；

如果TL小于T，则确定解决BUG的效率低于平均效率；

如果TL大于T，则确定解决BUG的效率高于平均效率。

5.如权利要求1所述的回归测试方法，其特征在于，软件上线后，还包括：对软件进行升级测试，具体包括：

对当前版本的软件进行升级，升级到最新版本；判断升级是否正常；

如果没有BUG，则卸载当前版本，安装最新版本的软件。

6.如权利要求1所述的回归测试方法，其特征在于，还包括：对所述测试用例集进行更新，具体包括：

根据当前进行的项目编写对应的新的测试用例；

将所述新的测试用例存储在测试用例集中；或者，

对于新增加的功能编写对应的测试用例；

将新编写的测试用例存储在用例集中。

7.如权利要求1所述的回归测试方法，其特征在于，采用各个渠道包对所述软件进行测试，包括：

获取各个应用商店的渠道包；

分别采用不同的渠道包对所述软件进行测试，分别纪录对应的BUG；

根据渠道包的标识建立渠道包和对应的BUG的对应关系表；

将所述关系表发送给服务器，以对所述BUG进行修复。

Images