基于Git代码文件检索粒度的自动化回归测试方法

摘要

本发明涉及一种基于Git代码文件检索粒度的自动化回归测试方法，包括以下步骤：1)自动获取Git开发代码主线上有代码变化的文件，得到一张记录了在检测时间内全部有代码变化的文件名列表；2)将被捕捉到的有变化的代码文件转化为受影响的功能特性列表；3)将受影响的功能特性转化为需要运行的自动化回归用例标签；4)将步骤1)、步骤2)、和步骤3)中所有的手动执行操作转化成自动执行，并通过Jenkins平台将其集成起来，实现一键式触发。与现有技术相比，本发明具有粒度更细，频率更高，资源更加节省等优点。

说明书

技术领域

本发明涉及软件自动化测试领域，尤其是涉及一种基于Git代码文件检索粒度的自动化回归测试方法。

背景技术

为了使软件产品能够快速响应市场，软件版本的迭代频率越来越高，项目发布周期越来越短，伴随而来的必然是更多的资源投入。而多出来的这部分投入不再是新功能开发所需的时间和人力，而是每次版本迭代的回归测试所耗费的时间和人力，越是庞大的软件产品，手工回归测试耗费的时间和人力越是大的惊人，回归测试已经成为了项目快速交付的新瓶颈。为了适应越来越频繁的软件迭代版本的交付，寻求高质量、高效率、低成本的回归测试方法成为了目前软件行业迫切需要攻克的难题。

软件项目迭代频率增高同样导致了软件开发过程中会持续产生多个待测版本，传统的集中式版本控制系统要求所有代码提交后才可以构建整包以供测试，若是开发代码质量不高，影响范围却很广，一旦出现问题，解决起来就非常费时费力。这样的情况若是出现的频率很高，则会严重影响开发代码线的稳定性。为了解决这个问题，很多软件项目开发开始采用分布式版本控制系统。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种粒度更细，频率更高，资源更加节省的基于Git代码文件检索粒度的自动化回归测试方法，使得在检测周期内更新的开发代码，都能得到及时的回归测试，既增强了代码线的稳定性和健壮性，又大大降低了回归测试所耗费的时间成本和人力成本，继而打破项目快速迭代交付过程中回归测试所带来的瓶颈。

本发明的目的可以通过以下技术方案来实现：

一种基于Git代码文件检索粒度的自动化回归测试方法，包括以下步骤：

1)自动获取Git开发代码主线上有代码变化的文件，得到一张记录了在检测时间内全部有代码变化的文件名列表；

2)将被捕捉到的有变化的代码文件转化为受影响的功能特性列表；

3)将受影响的功能特性转化为需要运行的自动化回归用例标签；

4)将步骤1)、步骤2)、和步骤3)中所有的手动执行操作转化成自动执行，并通过Jenkins平台将其集成起来，实现一键式触发。

优选地，所述的步骤1)自动获取Git开发代码主线上有代码变化的文件具体为：

第一步：检查是否到检测周期；

第二步：删除前一次残留的标签；

第三步：进入到Git本地仓库的开发代码主库路径，打一个oldtag标签，记录当前旧的代码状态；

第四步：执行更新代码命令；

第五步：此时再打一个标签记为newtag，记录的是当前最新的代码状态；

第六步：通过Git代码管理工具自带的命令git diff，输出新老标签所代表的不同代码版本之间，有代码变动的部分，打印其文件名。

优选地，所述的执行更新代码命令具体为：由多人协作分布式开发编写的远程仓库里的代码将被更新下载到本地代码仓库，使得本地代码状态与远程仓库代码的最新状态一致。

优选地，所述的检测周期为自定义设置，根据项目的具体情况，评估最佳的循环检测周期。

优选地，通过变化的代码文件名，得到所有被影响的功能特性，通过特性规则表来描述某一模块所有的代码文件和与之对应的功能特性之间的关系。

优选地，所述的特性规则表中的对应关系为一对一、一对多、多对一、多对多这四种情况中的一种。

优选地，所述的特性规则表制定好以后，通过脚本工具将步骤1)中的执行结果“有代码变化的文件名列表中的文件名”与特性规则表进行比对，若存在，则输出对应的特性，组成一张功能特性列表，即实现在检测周期内，所有有代码变化的文件影响到的功能特性列表输出出来。

优选地，所述的步骤3)具体为：

将步骤2)输出的功能特性转化为自动化回归的用例标签，用以筛选用例执行，这同样需要一张规则表，将此规则表命名为标签规则表；

所述的标签规则表的直接对应关系为“功能特性：用例标签”；

所述的标签规则表是完全匹配特性列表的，即步骤2)输出的功能特性列表项一定能在此标签规则表中找到对应的自动化用例标签，同样需要一个脚本工具，来实现自动查找特性，输出对应标签，组成一张用于回归测试的自动化用例标签列表，通过这张用例标签列表来筛选触发自动化回归用例。

优选地，所述的步骤4)具体为：

设置各工作模块：

Job0_downGitcode：用于首次下载开发代码，在同一个构建节点上此任务只运行一次；

Job1_GetchangefilesList：用于获取到开发主线仓库的所有代码有变化的文件名，并将文件名列表输出到SRT_changeFilesList.txt，上传公共文件服务器；

Job2_DiffpropertyRole：用于得到代码变化影响到的功能特性列表，同样输出到SRT_propertyList.txt，并上传公共文件服务器；

Job3_DiffsuitetagRole：用于得到受影响特性所对应的用例标签列表，输出到SRT_suitetagList.txt，并上传公共文件服务器；

AT_SlimsizeRT：用于通过用例标签筛选运行自动化测试用例，并邮件通知用例执行结果；

Job0_downGitcode在同一构建节点上只需要运行一次，

而Job1_GetchangefilesList，Job2_DiffpropertyRole，Job3_DiffsuitetagRole和AT_SlimsizeRT任务均可多次重复运行，且执行顺序不变，在Jenkins上通过设置关联任务，将这些任务串联起来，形成的效果是一旦Job1_GetchangefilesList执行成功，自动触发Job2_DiffpropertyRole开始运行，同理，一旦Job2_DiffpropertyRole运行完成，则自动触发Job3_DiffsuitetagRole，完成后，接着触发AT_SlimsizeRT任务。

优选地，所述的下载开发代码的存放路径，放在此任务工作空间的同级目录下。

与现有技术相比，本发明具有以下优点：

1、精准性：实现针对文件级代码变更的回归测试，即只针对有代码变化的文件所影响的功能特性进行回归测试，缩小了回归测试的范围，提高了回归测试的精准性；

2、时效性：可通过适当增加检测频率，使得任何有效提交的开发代码都能及时的得到回归测试的检验，及时发现问题并解决，长时间的保证代码线的健壮性与稳定性；

3、资源节省：通过缩小测试范围来降低回归测试的工作量；通过使用RF自动化框架编写自动化回归用例来减少重复性的测试劳动，节约人力；通过Jenkins集成平台，有选择的触发自动化测试用例来避免全量用例集覆盖所造成的时间浪费，同时减少人工干预，还可以利用非工作时间运行这些自动化回归测试用例，再次缩短回归测试阶段的时间成本。

4、软件越是庞大，应用本发明所带来的优势越明显。

附图说明

图1为自动获取Git开发主线上有代码变化的文件的流程图；

图2为Jenkins集成整体流程图；

图3为对比脚本逻辑示意图。

具体实施方式

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

本发明Git是目前世界上最先进的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理，因为其适应分布式开发，速度快，灵活，解决冲突容易，可以支持离线工作等优点，而被广泛应用于各种规模的敏捷开发项目中。

Git提供了便捷的多人协作分支管理，可以让不同工程师在各自的分支上开发代码并自测，也可以与其他分支自由的合并联调，构包验证，这时再将这些进行过基本测试的代码合并到同一条代码线上，可以极大程度的保证这条代码线的稳定性，我们人为的定义这条代码线为开发代码主线(以下简称开发主线)。在开发主线上构建的整包才可以成为每次项目迭代版本发布的回归测试对象。

Git同时提供一个可以快速找到某一时刻版本的管理机制，这就是标签管理。Git的标签是版本库的一个快照，但是本质是一个指向某个commit的指针，所以创建和删除标签都是瞬时完成的。我们可以利用标签来获取不同版本之间的代码差异，以此为基础得到较为精准的回归测试范围。这样就避免了全量回归测试带来的时间和人力上的资源浪费。

降低回归测试的成本，除了要缩小回归测试的范围，还可以通过用自动化测试来代替手工测试，进一步节约人力成本。本研究采用目前比较主流的自动化测试工具RobotFramework(以下简称RF)，RF是一款开源的自动化测试框架，具备很好的可扩展性，可以集成很多测试库，测试人员也可以使用Python来创建自己需要的测试库，利用已有的关键字，创建自己需要的关键字，形成更高级别的行为，可以同时测试多种类型的客户端或者接口，可以利用“标签”功能对测试用例进行分类和有选择的执行。

最后借用Jenkins持续集成平台实现远程控制Robot Framework自动化测试用例的执行，可以减少自动化回归测试中的人工干预，利用夜晚等非工作时间来完成测试任务，大大缩短了回归测试阶段整体所占用的时间，进一步节约时间成本。

本发明基于Git代码文件检索粒度的自动化回归测试方法，包括以下步骤：

第一部分：自动获取Git开发代码主线上有代码变化的文件。

此部分的目的是要定期找到有代码变更的文件，确认较为精准的回归测试对象。

Git标签管理工具可以提供使用不同标签对代码状态差异的查询操作。流程图如图1所示，具体步骤如下：

第一步：首先检查是否到检测周期；

第二步：删除前一次残留的标签；

第三步：进入到Git本地仓库的开发代码主库路径，打一个oldtag标签，记录当前旧的代码状态；

第四步：执行更新代码命令，此时，由多人协作分布式开发编写的的远程仓库里的代码将被更新下载到本地代码仓库，使得本地代码状态与远程仓库代码的最新状态一致；

第五步：此时再打一个标签记为newtag，记录的是当前最新的代码状态；

第六步：通过Git代码管理工具自带的命令git diff，输出新老标签所代表的不同代码版本之间，有代码变动的部分，打印其文件名。

本次自动获取代码变化文件的循环结束后，实现的效果是得到一张记录了在检测时间内全部有代码变化的文件名列表，接下来将继续检测是否到检测周期，进入下一个循环。

检测周期是自定义设置的，可以根据项目的具体情况，评估最佳的循环检测周期，检测的间隔时间不宜过长，过长则导致无法保证新变更的代码得到及时的回归测试；也不宜过短，过短则可能会出现回归用例执行失败，而失败的原因可能是因为多人提交代码时间有差导致某一功能模块代码不完整，而不是因为代码本身有问题导致的。这会直接产生用于排查用例执行失败原因的工作量，耗费额外的，不能产生价值的时间。所以寻找到匹配项目的最合适的检测周期，可以最大程度的发挥回归测试方法所达到的效果。

第二部分：将被捕捉到的有变化的代码文件转化为受影响的功能特性列表。

此部分的目的是通过变化的代码文件名，得到所有被影响的功能特性，为了完成此目的就需要一张规则表来描述某一模块所有的代码文件和与之对应的功能特性之间的关系，将其命名为特性规则表。

特性规则表中的对应关系可能是一对一，一对多，多对一，多对多这四种情况中的一种。例如某一代码文件的修改可能只影响1个功能特性，或者影响到多个功能特性，也可能多个代码文件所描述的是同一个功能特性，还存在多个代码文件共同影响着2个或2个以上的功能特性。

这一技术环节的输入是变化的文件名，要求的输出是被影响的功能特性表，所以这张特性规则表的直接对应关系为“文件名：影响特性”。下面来举例说明，如何实现上述四种对应关系：

一对一关系：Filename1:特性A

一对多关系：Filename2:特性B、特性C、特性D

多对一关系：Filename3:特性E

Filename4:特性E

多对多关系：Filename5:特性F、特性G

Filename6:特性F、特性G

Filename7:特性F、特性G

我们将回归测试中所有的文件名一一列出来，无论文件名与影响特性属于哪一种对应关系，特性规则表都可以用上述方式描述出来。

特性规则表制定好以后，还需要一个脚本工具，将本发明中第一部分的执行结果——有代码变化的文件名列表中的文件名与特性规则表进行比对，若存在，则输出对应的特性，组成一张功能特性列表，即实现在检测周期内，所有有代码变化的文件影响到的功能特性列表输出出来，也就是本次回归功能点的测试范围。

第三部分：将被影响的功能特性转化为需要运行的自动化回归用例标签。

此部分的目的是将第二部分输出的功能特性转化为自动化回归的用例标签，用以筛选用例执行，这同样需要一张规则表，为了区分，将此规则表命名为标签规则表。

标签规则表的直接对应关系为“功能特性：用例标签”，为了简化标签规则表的复杂度，我们不用单一功能特性作为对比项，直接将第二部分输出的功能特性组合作为对比项，下面来举例说明，标签规则表的组织格式如下(以第二部分输出的特性为例)：

特性A：标签Ⅰ

特性B、特性C、特性D：标签Ⅱ

特性E：标签Ⅲ

特性F、特性G：标签Ⅳ

标签规则表是完全匹配特性列表的，即第二部分输出的功能特性列表项一定能在此标签规则表中找到对应的自动化用例标签。它同样需要一个脚本工具，来实现自动查找特性，输出对应标签，组成一张用于回归测试的自动化用例标签列表。此时就可以通过这张用例标签列表来筛选触发自动化回归用例。

第四部分：将上述技术与Jenkins集成，实现一键触发。

此部分的目的是将第一部分、第二部分、第三部分中所有的手动执行操作转化成自动执行，并通过Jenkins平台将其集成起来，实现一键式触发。流程图如图2所示，下面来进行分别说明：

Job0_downGitcode：用于首次下载开发代码，在同一个构建节点上此任务只运行一次，以后只需要更新代码即可，不需要重复下载整个代码库，节约了后续任务的运行时间。注意，下载的开发代码的存放路径，不要直接放在此任务的工作空间下，否则任务每次运行前进行临时文件清理时，就会删除掉已经下载的开发代码，建议放在此任务工作空间的同级目录下。

Job1_GetchangefilesList：用于获取到开发主线仓库的所有代码有变化的文件名，并将文件名列表输出到SRT_changeFilesList.txt，上传公共文件服务器，便于查看和取用，例如ftp服务器。

Job2_DiffpropertyRole：用于得到代码变化影响到的功能特性列表，同样输出到SRT_propertyList.txt，并上传ftp服务器。

Job3_DiffsuitetagRole：用于得到受影响特性所对应的用例标签列表，输出到SRT_suitetagList.txt，并上传ftp服务器。

AT_SlimsizeRT：用于通过用例标签筛选运行自动化测试用例，并邮件通知用例执行结果。

Job0在同一构建节点上只需要运行一次，而Job1，Job2，Job3和AT任务均可多次重复运行，且执行顺序不变，在Jenkins上通过设置关联任务，可以将这些任务串联起来，形成的效果是一旦Job1执行成功，自动触发Job2开始运行，同理，一旦Job2运行完成，则自动触发Job3，完成后，接着触发AT任务。这样就可以将所有任务操作集成起来，实现了一键式触发。

此外，Job1执行的频率间隔就是代码检测周期，可以通过设置Job1的自动触发时间来实现代码检测频率的调整。

应用本发明提出的回归测试方法与Jenkins平台集成，形成了一个完整的自动化回归测试系统，又称细粒度自动化回归测试系统，此部分针对某一备份软件项目为例，详细描述该系统的组成和实现细节。

此自动化回归系统包含5个任务，每个任务的功能作用已在技术解决方案第四部分内容中阐述，此间不再赘述。下面将逐个描述任务实现细节。

Job1的构建脚本如下：

首先设置开发主线本地仓库的检测路径；进入此路径下，删除前一次构建残留的两个标签；然后设置当前本地仓库的状态标签Slimsizeold，接着从开发主线远程仓库中拉取最新代码至本地仓库，设置代码仓库更新后的状态标签Slimsizenew；最后执行Git代码管理工具自带的命令git diff来输出新老标签代表的不同代码状态之间，有代码变化的文件名，并重定向到一个txt文件中，将此txt文件拷贝到任务的工作空间下，利用Jenkins的插件，就可以将任务工作空间中的文件上传到ftp服务器上，以供后续任务使用。

同时针对备份项目实例，制定检测周期为24小时，调试任务时，测试整套任务的最长执行时间不超过4小时，因此设置此任务的自动发起时间为每天凌晨3点，这样测试工程师每天上班时就可以查看自动化回归测试的执行结果，处理相关问题。

Job2的构建脚本如下所示：

首先从ftp上下载Job1产生的有代码变化的文件名列表到本任务的工作空间；然后将特性规则表和对比脚本从测试代码仓库拷贝出来，也存放到本任务的工作空间；最后将对比脚本转化成可执行文件，并运行，同时将运行结果上传到ftp服务器上。

此任务涉及三个文件：变化代码文件列表SRT_changeFilesList.txt、特性规则表propertyrole.txt、对比脚本change_propertyList.sh。

其中特性规则表propertyrole.txt可以根据测试所需适当修改，如下所示：

以某备份软件中的文件备份项目为例，除了影响特性列和文件名列，还额外添加了模块列和开发负责人列。模块列用于区分其他模块拥有相同的特性，例如操作系统备份也有新建备份，启动备份等功能特性。添加开发负责人列，可以在回归测试用例执行失败时，快速找到对应的开发负责人来处理问题。

对比脚本change_propertyList.sh中的逻辑如图3所示，首先逐行读取特性规则表propertyrole.txt，若是读取不到下一行，则对比操作执行完毕；若是还可以读取到一行内容，则将这一行字符以冒号为分隔符拆分成变量，特性规则表则被拆分成4个变量，分别是模块变量、影响特性变量、文件名变量、开发负责人变量；将对比标准变量，即文件名变量与输入文件SRT_changeFilesList.txt逐个比对，若比对不成功，则读取特性规则表的下一行，若比对成功，则将对比结果变量，即影响特性变量输出到指定文件中，命名为SRT_propertyList.txt。

Job3的构建脚本如下所示：

与Job2的处理逻辑一致，首先从ftp上下载Job2产生的功能特性列表到本任务的工作空间；然后将标签规则表和对比脚本从测试代码仓库拷贝出来，存放到本任务的工作空间；最后将对比脚本转化成可执行文件，并运行，同时将运行结果上传到ftp服务器上。

此任务同样涉及三个文件：功能特性列表SRT_propertyList.txt、标签规则表tagrole.txt、对比脚本change_suitetagList.sh。

其中标签规则表tagrole.txt示例如下所示：

同样做了适当的修改变形，除了影响特性与用例标签的基本对应关系，还添加了影响特性的所属模块，用例标签的备注和测试负责人。

对比脚本change_suitetagList.sh的处理逻辑与Job2的对比脚本处理逻辑一致，如图3所示，不过此时的对比标准变量则是模块的影响特性，输入文件是影响特性列表SRT_propertyList.txt，对比结果变量是用例标签，最终输出的是由用例标签列表组成的文件SRT_suitetagList.txt。

AT任务是通过Job3产生的标签作为构建参数，在自动化运行节点环境上，带参执行调用命令，并将自动化用例的执行日志和结果打印出来。

以上就是细粒度自动化回归测试系统的内部组成和实现细节，并以某一备份软件项目为例，优化细粒度回归方法中的特性规则表和标签规则表，使之更加匹配项目，方便测试人员对此回归测试系统的执行与跟踪。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。