CN116932368A - 测试需求确定方法及装置 - Google Patents

Abstract

本申请涉及测试技术领域，提供一种测试需求确定方法及装置。所述方法包括：确定目标文件对应的待重测需求；基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；基于所述方法调用关系，确定目标重测需求；其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。本申请实施例提供的测试需求确定方法及装置，可以精准确定目标重测需求，从而可以减少需求上线时出现问题的可能，提高了软件测试的质量，同时节省大量测试时间和人力成本。

Description

测试需求确定方法及装置

技术领域

本申请涉及测试技术领域，具体涉及一种测试需求确定方法及装置。

背景技术

敏捷开发流程中，完整的软件代码环境应包括开发环境、测试环境、用户接收度测试(User Acceptance Test，UAT)环境、生产环境。开发人员开发完成后将代码持续交付到测试环境，测试人员或者自动测试系统对需求进行测试，测试无误后将代码批量部署到UAT环境并进行UAT测试，测试无误后再进行生产环境上线。

将代码从测试环境同步到UAT环境时，而不同批次的发布代码，可能出现已经发布并且通过测试的需求，被后续发布的需求修改了文件内容，从而导致之前已经测试通过的需求受影响。

现有测试流程当中，有两种处理方法：

1、默认这种需要重测的需求是不存在的，但是在实际的上线流程中，由于忽视这种需求直接上线，导致生产环境的需求出现问题。

2、上线前再开一个版本进行全量需求集中测试，而这种集中测试是风险比较大的，临近上线UAT测试出问题，开发人员进行临时修改可能会出现问题，导致需求无法上线。

发明内容

本申请实施例提供一种测试需求确定方法及装置，用以解决后续发布的需求对之前发布的需求产生影响的技术问题。

第一方面，本申请实施例提供一种测试需求确定方法，包括：

确定目标文件对应的待重测需求；

基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；

基于所述方法调用关系，确定目标重测需求；

其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。

在一个实施例中，在所述确定目标文件对应的待重测需求之前，包括：

按照发布时间倒序，对所述最新发布版本和历史发布版本进行遍历，确定所述第一需求和所述历史发布版本中测试通过的第二需求。

在一个实施例中，所述确定目标文件对应的待重测需求，包括：

基于所述目标文件，对所述第二需求包括的文件进行代码分析，确定所述目标文件对应的修改文件；

将所述修改文件对应的第三需求确定为所述待重测需求。

在一个实施例中，所述基于所述方法调用关系，确定目标重测需求，包括：

基于所述方法调用关系对应的方法调用树，确定所述调用方法对应的根节点；

判断第一根节点是否属于受影响根节点集合；

在所述第一根节点属于所述受影响根节点集合的情况下，确定所述第一根节点对应的第一调用方法；

将所述第一调用方法对应的第四需求确定为第一目标重测需求。

在一个实施例中，在所述基于所述第一调用方法，确定第一目标重测需求之后，还包括：

在所述第一目标重测需求包括第二调用方法的情况下，将所述第二调用方法对应的第二根节点加入所述受影响根节点集合；

在所述第二根节点对应第三调用方法的情况下，将所述第三调用方法对应的第五需求确定为第二目标重测需求。

在一个实施例中，在所述基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系之前，还包括：

对所述待重测需求包括的文件进行代码分析，确定所述调用方法；

基于所述调用方法和所述待重测需求，确定所述目标文件的目标链表。

第二方面，本申请实施例提供一种测试需求确定装置，包括：

第一确定模块，用于确定目标文件对应的待重测需求；

第二确定模块，用于基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；

第三确定模块，用于基于所述方法调用关系，确定目标重测需求；

其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。

在一个实施例中，所述测试需求确定装置，还包括：

第四确定模块，用于按照发布时间倒序，对所述最新发布版本和历史发布版本进行遍历，确定所述第一需求和所述历史发布版本中测试通过的第二需求。

第三方面，本申请实施例提供一种电子设备，包括处理器和存储有计算机程序的存储器，所述处理器执行所述程序时实现第一方面所述的测试需求确定方法。

第四方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现第一方面所述的测试需求确定方法。

本申请实施例提供的测试需求确定方法及装置，通过从文件粒度根据目标文件确定待重测需求，再从方法粒度根据待重测需求对应的调用方法，确定方法调用关系，从而精准确定目标重测需求，从而可以减少需求上线时出现问题的可能，提高了软件测试的质量，同时节省大量测试时间和人力成本。

附图说明

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

图1是本申请实施例提供的测试需求确定方法的流程示意图；

图2是应用本申请实施例提供的测试需求确定方法的版本发布示意图；

图3是应用本申请实施例提供的测试需求确定方法的方法调用树示意图之一；

图4是应用本申请实施例提供的测试需求确定方法的方法调用树示意图之二；

图5是应用本申请实施例提供的测试需求确定方法的流程示意图。

图6是本申请实施例提供的测试需求确定装置的结构示意图；

图7是本申请实施例提供的电子设备的结构示意图。

具体实施方式

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

在相关技术中，敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。总结地说，敏捷开发就是，开发完成后立刻进行测试，多个需求测试完成后进行一次发布。

一套完整敏捷开发的软件代码环境应包括开发环境、测试环境、UAT环境和生产环境。

开发环境是专门用于开发的服务器。

UAT环境主要是用来作为客户体验的环境。

测试环境一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。

生产环境是指正式提供对外服务的环境，可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。生产环境也就是通常说的真实环境。

本申请提供的测试需求确定方法的执行主体可以是电子设备、电子设备中的部件、集成电路、或芯片。该电子设备可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等，非移动电子设备可以为服务器、网络附属存储器(Network Attached Storage，NAS)、或者个人计算机(personal computer，PC)等，本申请不作具体限定。

下面以计算机执行本申请提供的测试需求确定方法为例，详细说明本申请的技术方案。

图1为本申请实施例提供的测试需求确定方法的流程示意图。参照图1，本申请实施例提供一种测试需求确定方法，可以包括：步骤110、步骤120和步骤130。

步骤110、确定目标文件对应的待重测需求。

其中，目标文件为最新发布版本中测试通过的第一需求包括的文件。

在实际执行中，不管是人工操作还是通过自动化集成的方法都无法避免的引入下面的问题。

如图2所示，UAT环境下存在四个发布版本：UAT1、UAT2、UAT3和UAT4。

不同的发布版本可以包括不同或相同的需求，同一个发布版本可能包含多个需求。多个UAT发布版本发布后，进行封版和生产环境上线。图2中每一个方框代表一个需求，每个需求可以对应一个或多个功能模块。英文字母可以表示需求的命名，英文字母下方的数字表示此需求包括的文件。

UAT1版本中，提交了需求A，需求A包括1文件、2文件和3文件，并且此时并不知道需求A是否测试通过。

UAT2版本中，提交了需求B，需求B包含1文件、4文件和5文件。需求A与需求B包含了同一文件1，此时也不知道需求B是否测试通过。

UAT3版本中，提交了需求A，包含1文件，还提交了需求C，包含6文件、7文件和8文件。

UAT4版本中，提交了需求D，包含1文件、7文件和9文件。

在封板上线时可知，需求B在UAT2测试通过，需求A、C在UAT3测试通过，需求D在UAT4测试通过。

通过比对UAT3版本与UAT2版本，需求A和需求B都修改了1文件，UAT3版本提交的1文件可能会影响需求B的功能实现，则需要判断需求B是否需要重测。

通过比对UAT3版本与UAT4版本，则需要判断需求A和需求C是否需要重测，需求B是否需要重测。

在本申请实施例中，从文件和方法两种粒度判断一个已经测试通过的需求是否会被后续发布的需求影响，进而确定该测试通过的需求是否需要重测。

在文件粒度判断需求是否需要重测的原理是判断测试通过的需求关联的所有文件，是否和后续测试的需求关联的需求有交集，如果有则此需求有概率被影响，从文件粒度上判断此需求需要进行重测。

在本步骤中，先确定最新发布版本中的第一需求，再确定第一需求包括的目标文件。

在持续集成工具上获取UAT版本发布信息。版本发布信息应包含最新发布版本和历史发布版本中全量或者增量的版本发布信息，版本发布信息至少应该包括能够独立标识一个版本的信息，比如版本发布标识(Identity Document，ID)，便于根据版本发布ID可以查询发布版本对应的需求。则可以根据最新发布版本的版本发布ID确定第一需求，进而确定第一需求包括的目标文件。

需要说明的是，持续集成是一种DevOps软件开发实践。采用持续集成时，开发人员会定期将代码变更合并到一个中央存储库中，之后系统会自动运行构建和测试操作。持续集成通常是指软件发布流程的构建或集成阶段，需要用到自动化组件和文化组件。持续集成的主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布新软件更新所需的时间。

每个发布版本可以包括多个文件，目标文件可以是最新发布版本中测试通过的第一需求包括的一个或多个文件。

比较最新发布版本和之前已经分析的版本是否是同一个版本。关于已经分析的版本的获取可以有多种方式，可以把之前分析过的版本放到数据库或者每次获取UAT发布版本信息时，标识曾经分析过的版本，判断获取的最新发布版本是否被分析过。

在存在未分析的最新发布版本的情况下，可以通过如下实施方式分析最新发布版本。

在一个实施例中，在步骤110之前，还包括：

按照发布时间倒序，对最新发布版本和历史发布版本进行遍历，确定第一需求和历史发布版本中测试通过的第二需求。

按照发布时间倒序，从最新发布版本到和历史发布版本的顺序进行遍历。倒序遍历过程中第一次出现的需求即可确定为最后测试通过的需求，并记录测试通过的需求所对应的发布版本。

因此，可以确定最新发布版本中测试通过的第一需求和历史发布版本中测试通过的第二需求。

可以理解的是，在本申请实施例中，如果获取的UAT版本信息是从新到旧，则正序遍历，如果获取的UAT版本信息是从旧到新，则逆序遍历。

以图2为例，按照发布时间倒序遍历即为：UAT4、UAT3、UAT2和UAT1。

在遍历UAT4版本时，可以直接确定需求D为测试通过的需求；遍历UAT3版本时，可以直接确定需求A和需求C为测试通过的需求；遍历UAT2版本时，可以直接确定需求B为测试通过的需求；在遍历UAT1版本时，可以确定需求A在UAT1版本没有测试通过。

由此可知，按照发布时间倒序遍历的好处是能够快速获知每个需求最后测试通过是在哪个UAT版本。

当然也可以按照发布时间正序遍历，从历史发布版本到最新发布版本，对所有发布版本进行遍历，直到遍历完所有发布版本，才能确定需求在哪个版本通过。从历史发布版本开始遍历，并不能直接确定需求在哪个版本通过，则需要额外构造一个用于存储测试通过的需求的数据结构。

以图2为例，按照发布时间正序遍历即为：UAT1、UAT2、UAT3和UAT4。

在遍历UAT1版本时，无法确定需求A在UAT1版本是否测试通过。则需要构造一个存储空间存储需求A，并且在后续遍历过程中，需求A可能会不断更新，再将更新后的需求A与存储空间中的原需求A进行替换，直至遍历结束才可确定需求A在哪个版本测试通过。

由此可知，正序遍历需要占用额外的空间开销，且不能直接确定测试通过的需求，效率较低。

本申请实施例提供的测试需求确定方法，通过按照发布时间倒序，可以快速确定所有发布版本中测试通过的需求，且不需要额外的空间开销来保存相应信息。

在一个实施例中，确定目标文件对应的待重测需求，包括：

基于目标文件，对第二需求包括的文件进行代码分析，确定目标文件对应的修改文件；

将修改文件对应的第三需求确定为待重测需求。

在实际执行中，在进行遍历时，还需要进行的操作是分析第一需求和第二需求所包括的文件。

根据代码仓库类型，获取对应的文件提交记录。文件提交记录可以看到每个开发人员提交的代码对源文件的哪些行进行了变动，并得到每个需求中目标文件对应的修改文件。

目标文件为第一需求所包含的文件，修改文件为第二需求所包含的文件与目标文件可以产生交集的文件。

例如：修改文件可以是对目标文件进行增加、删除或者替换代码操作后所对应的文件。

进一步，修改文件对应的第三需求即为待重测需求。

在修改文件对应的第三需求为同一个发布版本的两个需求的情况下，即使它们包括同一目标文件对应的修改文件，但是由于两个需求都是在同一版本进行测试，所以无需对这两个需求都进行重测，待重测需求可以选择同一个发布版本中任意一个修改文件对应的需求。

本申请实施例提供的测试需求确定方法，可以实现文件粒度判断需求是否需要重测，并将修改文件对应的需求确定为待重测需求。

步骤120、基于待重测需求对应的调用方法，确定调用方法对应的方法调用关系。

在确定待重测需求之后，对待重测需求包括的文件进行代码分析，可以使用一些代码分析工具，如java代码对应的静态代码分析工具asm、spoon等，通过对字节码进行分析，进而可以确定每个待重测需求对应的调用方法，根据字节码中的invoke字段可以确定方法调用关系。

步骤130、基于方法调用关系，确定目标重测需求。

基于方法调用关系，可以确定不同的调用方法之间是否产生影响。

例如：假设目标文件包含3个声明了的方法，其中有两个方法在目标文件外被其他方法调用。如果不确定方法调用关系，则会认为这两个方法是相关的，修改其中一个会影响另外一个，但是实际上这两个方法并无关系，这两个方法的代码没有交集，也没有调用其他相同的方法。因此，这两个方法对应的需求就不需要重测。

由此可知，基于可以方法调用关系，将产生影响的调用方法对应的需求筛选出来作为目标重测需求。

本申请实施例提供的测试需求确定方法，通过从文件粒度根据目标文件确定待重测需求，再从方法粒度根据待重测需求对应的调用方法，确定方法调用关系，从而精准确定目标重测需求，从而可以减少需求上线时出现问题的可能，提高了软件测试的质量，同时节省大量测试时间和人力成本。

在一个实施例中，基于方法调用关系，确定目标重测需求，包括：

基于方法调用关系对应的方法调用树，确定调用方法对应的根节点；

判断第一根节点是否属于受影响根节点集合；

在第一根节点属于受影响根节点集合的情况下，确定第一根节点对应的第一调用方法；

将第一调用方法对应的第四需求确定为第一目标重测需求。

需要说明的是，从方法粒度的重测判断是依赖于文件粒度的判断的，之所以往下细化到方法粒度，是因为可能存在这样的情况，两个需求虽然修改了同一个文件，但是具体修改得地方是两个完全不相关的地方，这样的两个需求就无需进行重测。

所以进行方法粒度需求重测判断的时候，重要的一个地方是如何界定两个需求在同一个文件内修改得地方没有关系。

本申请实施例提出了一种基于类中方法调用树的根节点是否一致的方法来判断需求关系。

通过静态代码分析工具，如asm或者spoon等将项目代码进行分析，根据字节码中的invoke字段可以确定调用方法，不断地构建方法调用关系，最终能够生成整个项目内的方法调用树，可以确定调用方法对应的根节点。

整个项目是由很多个方法调用树构成的森林，而每一个类文件仅包含部分方法的情况，就类似于给森林的一部分进行截取，对具体每一个文件进行分析，就是对被截取的树节点进行分析，具体实现是在分析过程中每一次访问新的节点就进行判断，如果调用方法不属于对应的文件，则说明已经超出了限定范围。

由于在同一个文件内部的任意两个调用方法必有至少一个相同的祖先节点，但是如果以目标文件作为界定范围，分析目标文件包含的所有调用方法，则在此目标文件范围内的两个调用方法，在调用关系树上不一定能找到相同的祖先节点。通过这样相对影响的判断，能够进一步提高方法影响范围的精度。

如图3所示，其中的每一个圆圈表示一个调用方法。这样做的好处是能提高需求变更影响的范围精度。比如图3中A.java包含三个树节点，则说明此文件包含3个声明了的调用方法，其中有两个方法，在A文件外被其他方法调用，如果不通过文件对方法调用关系进行限制，则会认为A文件中这两个方法是相关的，修改其中一个会影响另外一个，但是实际上这两个方法并无关系，他们代码没有交集，也没有调用其他相同的方法，所以通过将方法调用关系限制在A文件里面，可以实现更精确的判断。

在实际执行中，根据方法调用树，可以遍历所有根节点，并判断第一根节点是否属于受影响根节点集合。受影响根节点集合是基于最新发布版本中所包含的需求以及对应的调用方法确定的。

在第一根节点属于受影响根节点集合的情况下，可以确定第一根节点对应的第一调用方法，说明最新发布版本中目标文件对应的调用方法影响了第一调用方法对应的第四需求，则将第四需求确定为第一目标重测需求。

假设需求1、需求2、需求3和需求4都修改了同一个目标文件，且分别对应的调用方法为A、B、C和DE。如图4所示，在目标文件内方法调用关系对应了3棵方法调用树，根节点分别为X、Y和Z。

首先将需求1对应的A方法的根节点加入受影响根节点集合中，因为需求1是最新发布版本中测试通过的一个需求，无需重测。需求2、需求3和需求4是文件粒度重测判断确定的待重测需求。

对于需求2，其影响的调用方法是B，B对应的第一根节点是Y，Y不在受影响节点集合内，于是需求2无需重测。

对于需求3，其影响的调用方法是C，C对应的第一根节点是Z，Z不在受影响节点集合内，于是需求3无需重测。

对于需求4，其影响的调用方法是D和E，第一调用方法D对应的第一根节点是X，X在受影响节点集合内，于是需求4需要重测。

因此，将第一调用方法D对应的需求4确定为第一目标重测需求。

本申请实施例提供的测试需求确定方法，通过分析方法调用树，可以快速找到根节点，并可以判断目标文件内调用方法之间是否相关，进而确定相关的调用方法对应的需求为目标重测需求。

在一个实施例中，在基于第一调用方法，确定第一目标重测需求之后，还包括：

在第一目标重测需求包括第二调用方法的情况下，将第二调用方法对应的第二根节点加入受影响根节点集合；

在第二根节点对应第三调用方法的情况下，将第三调用方法对应的第五需求确定为第二目标重测需求。

在确定第一目标重测需求之后，可以确定第一目标重测需求是否还包括其他调用方法，即第二调用方法。

将第二调用方法对应的第二根节点也加入受影响根节点集合。

在第二根节点属于受影响根节点集合的情况下，需要确定第二根节点对应的所有调用方法。又第二根节点已对应第二调用方法，在第二根节点还对应第三调用方法的情况下，将第三调用方法对应的第五需求确定为第二目标重测需求。

例如：如图4所示，对于需求4，其影响的调用方法是D和E，第一调用方法D对应的第一根节点是X，X在受影响节点集合内，于是需求4需要重测。将第一调用方法D对应的需求4确定为第一目标重测需求。

将需求4包含的所有调用方法对应的根节点都加入受影响根节点集合，于是将第二调用方法E对应的第二根节点Z加入受影响根节点集合。由于第二根节点Z还对应需求3对应的第三调用方法C，则将第三调用方法C对应的需求3确定为第二目标重测需求。

本申请实施例提供的测试需求确定方法，通过分析方法调用树，可以快速找到根节点，并可以判断目标文件内调用方法之间是否相关，进而确定相关的调用方法对应的需求为目标重测需求。

在一个实施例中，在基于待重测需求对应的调用方法，确定调用方法对应的方法调用关系之前，还包括：

对待重测需求包括的文件进行代码分析，确定调用方法；

基于调用方法和待重测需求，确定目标文件的目标链表。

分析每个待重测需求，可以得到个待重测需求中，由于目标文件而产生影响的修改文件，根据修改文件，可以确定修改文件属于的代码块，从而得到对应的受影响的调用方法。

可以将版本发布信息、最新发布版本和历史发布版本对应的所有需求、待重测需求和以及受影响的调用方法整合到一个数据结构中，也可以分开储存。

遍历上述数据，可以针对每一个目标文件以及目标文件对应的修改文件，维护一个目标链表。

按照尾插法保存每个发布版本中修改文件对应的需求集合。

要注意的是，一定是按照一个发布版本为集合添加此版本所有需求到链表上作为一个节点。对于同一个发布版本的两个需求，即使它们影响的文件有交集，但是由于两个需求都是在同一版本进行测试，所以无需对这两个需求进行重测。所以待重测需求一定是不在同一个版本的。

每一个目标文件对应的目标链表，将从第二个节点开始之后的所有节点加入一个集合，此集合减去第一个节点对应的集合，节点中剩下的需求即为从文件粒度需要重测的需求。可以理解的是，第一个节点对应的需求集合是最新发布版本中所包括的第一需求。

本申请实施例提供的测试需求确定方法，通过建立目标链表，可以快速确定目标文件对应的待重测需求以及对应的调用方法，便于确定目标重测需求。

图5为应用本申请实施例提供的测试需求确定方法的流程示意图。参照图5，本申请实施例提供一种测试需求确定方法，可以包括如下步骤。

步骤501、获取UAT版本发布信息。具体的，发布信息应包含全量或者增量的版本发布信息，版本发布信息至少应该包含能够独立标识一个发布版本的信息，比如版本发布ID，可以根据版本发布ID查询不同发布版本对应的需求。

步骤502、判断是否有未分析发布版本。若是，进入步骤503，若否，进入步骤505。

步骤503、获取最新发布版本包括的需求。

步骤504、通过svnLog/gitLog找到上述需求对应的目标文件、历史发布版本中目标文件的变动范围以及变动范围对应的修改文件；

维护目标文件对应需求的目标链表，目标链表用于指示目标文件对应的待重测需求；

将所有目标链表加入Map中，从UAT版本发布信息中删除最新发布版本对应的版本发布信息。因为最新发布版本包括的第一需求是无需重测的需求。

步骤505、遍历Map，遍历List中所有需求，遍历需求对应修改文件的所有调用方法。

步骤506、对项目代码整体静态编译分析，生成方法调用关系以及方法调用树。

步骤507、通过并查集计算所有调用方法对应的方法调用树的根节点。

步骤508、判断根节点是否在受影响节点集合内。若是，进入步骤509，若否，进入步骤510。

步骤509、确定此根节点对应的需求，并将此需求的所有调用方法对应的根节点都加入受影响集合，并确定此需求需要重测。

步骤510、此根节点对应的需求无需重测。

本申请实施例提供的文件内两个调用方法是否相关的判断，创新的结合方法调用关系和利用类似于并查集不断查找父节点的思想，通过在同一个目标文件内进行对森林的剪切，保证判断的范围不超过整个文件，规避了目标文件内两个毫不相关的方法调用同一个工具类，从而判断这两个调用方法是相关的问题，或者同一目标文件内毫不相关的两个调用方法被目标文件外另一个方法调用，从而判断这两个调用方法相关的问题。

本申请实施例提供的测试需求确定方法，可以精准确定目标重测需求，可以减少生产环境上需求出现问题的可能，也能通过仅测试少量的受影响的需求，减少测试人员的工作量，付出少量的工作量就可以提高需求上线的质量。

下面对本申请实施例提供的测试需求装置进行描述，下文描述的测试需求装置与上文描述的测试需求方法可相互对应参照。

图6为本申请实施例提供的测试需求确定装置的结构示意图。参照图6，本申请实施例提供一种测试需求确定装置，可以包括：第一确定模块610、第二确定模块620和第三确定模块630。

第一确定模块610，用于确定目标文件对应的待重测需求；

第二确定模块620，用于基于待重测需求对应的调用方法，确定调用方法对应的方法调用关系；

第三确定模块630，用于基于方法调用关系，确定目标重测需求；

其中，目标文件为最新发布版本中测试通过的第一需求包括的文件。

本申请实施例提供的测试需求确定装置，通过从文件粒度根据目标文件确定待重测需求，再从方法粒度根据待重测需求对应的调用方法，确定方法调用关系，从而精准确定目标重测需求，从而可以减少需求上线时出现问题的可能，提高了软件测试的质量，同时节省大量测试时间和人力成本。

在一个实施例中，测试需求确定装置，还包括：

第四确定模块，用于按照发布时间倒序，对最新发布版本和历史发布版本进行遍历，确定第一需求和历史发布版本中测试通过的第二需求。

在一个实施例中，所述第一确定模块610，还用于：

基于所述目标文件，对所述第二需求包括的文件进行代码分析，确定所述目标文件对应的修改文件；

将所述修改文件对应的第三需求确定为所述待重测需求。

在一个实施例中，所述第三确定模块630，还用于：

基于所述方法调用关系对应的方法调用树，确定所述调用方法对应的根节点；

判断第一根节点是否属于受影响根节点集合；

在所述第一根节点属于所述受影响根节点集合的情况下，确定所述第一根节点对应的第一调用方法；

将所述第一调用方法对应的第四需求确定为第一目标重测需求。

在一个实施例中，所述装置还包括：

分析模块，用于在所述第一目标重测需求包括第二调用方法的情况下，将所述第二调用方法对应的第二根节点加入所述受影响根节点集合；

在所述第二根节点对应第三调用方法的情况下，将所述第三调用方法对应的第五需求确定为第二目标重测需求。

在一个实施例中，所述装置还包括

第五确定模块，用于对所述待重测需求包括的文件进行代码分析，确定所述调用方法；

基于所述调用方法和所述待重测需求，确定所述目标文件的目标链表。

图7示例了一种电子设备的结构示意图，如图7所示，该电子设备可以包括：处理器(processor)710、通信接口(Communication Interface)720、存储器(memory)730和通信总线740，其中，处理器710，通信接口720，存储器730通过通信总线740完成相互间的通信。处理器710可以调用存储器730中的计算机程序，以执行测试需求确定方法的步骤，例如包括：

确定目标文件对应的待重测需求；

基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；

基于所述方法调用关系，确定目标重测需求；

其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。

此外，上述的存储器730中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各实施例所提供的测试需求确定方法的步骤，例如包括：

确定目标文件对应的待重测需求；

基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；

基于所述方法调用关系，确定目标重测需求；

其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。

另一方面，本申请实施例还提供一种处理器可读存储介质，所述处理器可读存储介质存储有计算机程序，所述计算机程序用于使处理器执行上述各实施例提供的方法的步骤，例如包括：

确定目标文件对应的待重测需求；

基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；

基于所述方法调用关系，确定目标重测需求；

其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。

所述处理器可读存储介质可以是处理器能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NANDFLASH)、固态硬盘(SSD))等。

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

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

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

Claims (10)

1.一种测试需求确定方法，其特征在于，包括：

确定目标文件对应的待重测需求；

基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；

基于所述方法调用关系，确定目标重测需求；

其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。

2.根据权利要求1所述的测试需求确定方法，其特征在于，在所述确定目标文件对应的待重测需求之前，包括：

按照发布时间倒序，对所述最新发布版本和历史发布版本进行遍历，确定所述第一需求和所述历史发布版本中测试通过的第二需求。

3.根据权利要求2所述的测试需求确定方法，其特征在于，所述确定目标文件对应的待重测需求，包括：

基于所述目标文件，对所述第二需求包括的文件进行代码分析，确定所述目标文件对应的修改文件；

将所述修改文件对应的第三需求确定为所述待重测需求。

4.根据权利要求1所述的测试需求确定方法，其特征在于，所述基于所述方法调用关系，确定目标重测需求，包括：

基于所述方法调用关系对应的方法调用树，确定所述调用方法对应的根节点；

判断第一根节点是否属于受影响根节点集合；

在所述第一根节点属于所述受影响根节点集合的情况下，确定所述第一根节点对应的第一调用方法；

将所述第一调用方法对应的第四需求确定为第一目标重测需求。

5.根据权利要求4所述的测试需求确定方法，其特征在于，在所述基于所述第一调用方法，确定第一目标重测需求之后，还包括：

在所述第一目标重测需求包括第二调用方法的情况下，将所述第二调用方法对应的第二根节点加入所述受影响根节点集合；

在所述第二根节点对应第三调用方法的情况下，将所述第三调用方法对应的第五需求确定为第二目标重测需求。

6.根据权利要求1-5任一项所述的测试需求确定方法，其特征在于，在所述基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系之前，还包括：

对所述待重测需求包括的文件进行代码分析，确定所述调用方法；

基于所述调用方法和所述待重测需求，确定所述目标文件的目标链表。

7.一种测试需求确定装置，其特征在于，包括：

第一确定模块，用于确定目标文件对应的待重测需求；

第二确定模块，用于基于所述待重测需求对应的调用方法，确定所述调用方法对应的方法调用关系；

第三确定模块，用于基于所述方法调用关系，确定目标重测需求；

其中，所述目标文件为最新发布版本中测试通过的第一需求包括的文件。

8.根据权利要求7所述的测试需求确定装置，其特征在于，所述测试需求确定装置，还包括：

第四确定模块，用于按照发布时间倒序，对所述最新发布版本和历史发布版本进行遍历，确定所述第一需求和所述历史发布版本中测试通过的第二需求。

9.一种电子设备，包括处理器和存储有计算机程序的存储器，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6任一项所述的测试需求确定方法。

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6任一项所述的测试需求确定方法。