CN109977016A - 一种测试触发方法、装置和设备以及一种测试系统 - Google Patents

Abstract

本发明实施例公开了一种测试触发方法、装置和设备以及一种测试系统。该测试触发方法，包括：获得目标文件的开发记录；基于开发记录，判断目标文件是否满足测试触发条件；当目标文件满足测试触发条件时，触发与目标文件对应的测试任务，避免了主观因素对测试任务触发的及时性和必要性判断的干扰，可以保证及时对目标文件进行必要的测试，提高了测试触发的准确性和测试的效率。

Description

一种测试触发方法、装置和设备以及一种测试系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种测试触发方法、装置和设备以及一种测试系统。

背景技术

在软件开发时，为了保证软件的正常使用，在代码编写完成后一般需要对其能够实现的功能进行测试，测试通过后再进行软件版本的发布。

目前，测试人员可以在将测试用例上传之后，在Jenkins平台上构建相应的测试任务后，选择对该测试用例触发后，即可开启执行本次测试任务，对目标文件(即被测试的代码)可实现的功能进行测试。Jenkins是一个开源的、基于Java开发的可实现持续集成的软件工具，可用于监控持续重复的工作。它能实时监控集成中存在的错误，提供详细的日志文件和告警功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。

虽然利用Jenkins平台构建相应的测试任务可以实现测试用例的自动化运行，但是仍然需要测试人员主观认为需要进行测试时，再触发测试任务的执行，无法保证测试的及时性和必要性。

发明内容

有鉴于此，本申请实施例提供了一种测试触发方法、装置和设备以及一种测试系统，能够解决现有技术中主观确定测试任务的触发时机，无法保证测试的及时性和必要性的问题。

本申请实施例第一方面提供的一种测试触发方法，所述方法包括：

获得待测目标的开发记录；

基于所述开发记录，判断所述待测目标是否满足测试触发条件；

当所述待测目标满足所述测试触发条件时，触发与所述待测目标对应的测试任务。

可选的，所述基于所述开发记录，判断所述待测目标是否满足测试触发条件，具体包括：

基于所述开发记录，得到所述待测目标的测试权重；

判断所述测试权重是否大于或等于预设权重阈值。

可选的，所述开发记录，包括：文件状态；所述文件状态，包括：新增、修改和删除中的任意一个或多个；所述基于所述开发记录，得到所述待测目标的测试权重，具体包括：

在当前测试时间点，获取所述待测目标的文件状态和所述待测目标在前一个测试时间点的测试权重；

根据所述待测目标的文件状态，得到权重累加值；

将所述待测目标在前一个测试时间点的测试权重和所述权重累加值之和作为所述待测目标在所述当前测试时间点的测试权重。

可选的，所述根据所述待测目标的文件状态，得到权重累加值，具体包括：

当所述待测目标的文件状态为修改时，根据所述待测目标的编辑记录，计算得到所述权重累加值；所述开发记录包括所述编辑记录；

当所述待测目标的文件状态为新增时，将第一预设值作为所述权重累加值；

当所述待测目标的文件状态为删除时，将第二预设值作为所述权重累加值。

可选的，所述根据所述待测目标的编辑记录，计算得到所述权重累加值，具体包括：

根据第一参数和第二参数的比值，得到所述权重累加值；

其中，所述编辑记录包括所述第一参数和所述第二参数，所述第一参数为代码覆盖率，所述第二参数为缺陷总数或需求总数。

可选的，所述获取所述待测目标的文件状态，具体包括：

获取当前文件记录和历史文件记录；所述当前文件记录包括在所述当前测试时间点时目标测试地址内存储文件的文件信息，所述历史文件记录包括在所述前一个测试时间点时目标测试地址内存储文件的文件信息，所述当前文件记录和/或所述历史文件记录包括所述待测目标的文件信息；

根据所述当前文件记录和所述历史文件记录，确定所述待测目标的文件状态。

可选的，所述根据所述当前文件记录和所述历史文件记录，确定所述待测目标的文件状态，具体包括：

判断所述当前文件记录和所述历史文件记录是否均包括所述待测目标的文件信息；

当所述当前文件记录包括所述待测目标的文件信息、所述历史文件记录不包括所述待测目标的文件信息时，所述待测目标的文件状态为新增；

当所述当前文件记录不包括所述待测目标的文件信息、所述历史文件记录包括所述待测目标的文件信息时，所述待测目标的文件状态为删除；

当所述当前文件记录和所述历史文件记录均包括所述待测目标的文件信息时，基于所述当前文件记录、所述历史文件记录和所述待测目标的文件信息，获取当前目标文件和历史目标文件；根据所述当前目标文件的内容和所述历史目标文件的内容，确定所述待测目标的文件状态是否为修改；所述当前目标文件和所述历史目标文件的修改时间不同。

可选的，所述根据所述当前目标文件的内容和所述历史目标文件的内容，确定所述待测目标的文件状态是否为修改，具体包括：

判断所述当前目标文件的内容和所述历史目标文件的内容是否存在差异；

当所述当前目标文件的内容和所述历史目标文件的内容存在差异时，判断存在的差异是否符合预设修改过滤规则；

当所述当前待测目标的内容和所述历史待测目标的内容存在不符合所述预设修改过滤规则的差异时，确定所述待测目标的文件状态为修改。

可选的，所述判断存在的差异是否符合预设修改过滤规则，具体包括：

判断所述差异是否为注释差异；

和/或，

判断所述差异是否为换行/空格差异；

和/或，

判断所述差异是否为头文件差异。

本申请实施例第二方面提供的一种测试触发装置，包括：记录获取单元、条件判断单元和任务触发单元；

所述记录获取单元，用于获得待测目标的开发记录；

所述条件判断单元，用于基于所述开发记录，判断所述待测目标是否满足测试触发条件；

所述任务触发单元，用于当所述条件判断单元判断所述待测目标满足所述测试触发条件时，触发与所述待测目标对应的测试任务。

可选的，所述条件判断单元，具体包括：权重计算子单元和阈值判断子单元；

所述权重计算子单元，用于基于所述开发记录，得到所述待测目标的测试权重；

所述阈值判断子单元，用于判断所述测试权重是否大于或等于预设权重阈值。

可选的，所述开发记录，包括：文件状态；所述文件状态，包括：新增、修改和删除中的任意一个或多个；所述权重计算子单元，具体包括：获取子单元、累加子单元和确定子单元；

所述获取子单元，用于在当前测试时间点，获取所述待测目标的文件状态和所述待测目标在前一个测试时间点的测试权重；

所述累加子单元，用于根据所述待测目标的文件状态，得到权重累加值；

所述确定子单元，用于将所述待测目标在前一个测试时间点的测试权重和所述权重累加值之和作为所述待测目标在所述当前测试时间点的测试权重。

可选的，所述累加子单元，具体包括：第一子单元、第二子单元和第三子单元；

所述第一子单元，用于当所述待测目标的文件状态为修改时，根据所述待测目标的编辑记录，计算得到所述权重累加值；所述开发记录包括所述编辑记录；

所述第二子单元，用于当所述待测目标的文件状态为新增时，将第一预设值作为所述权重累加值；

所述第三子单元，用于当所述待测目标的文件状态为删除时，将第二预设值作为所述权重累加值。

可选的，所述第一子单元，具体用于：

根据第一参数和第二参数的比值，得到所述权重累加值；

其中，所述编辑记录包括所述第一参数和所述第二参数，所述第一参数为代码覆盖率，所述第二参数为缺陷总数或需求总数。

可选的，所述获取子单元，具体包括：记录获取子单元和状态确定子单元；

所述记录获取子单元，用于获取当前文件记录和历史文件记录；所述当前文件记录包括在所述当前测试时间点时目标测试地址内存储文件的文件信息，所述历史文件记录包括在所述前一个测试时间点时目标测试地址内存储文件的文件信息，所述当前文件记录和/或所述历史文件记录包括所述待测目标的文件信息；

所述状态确定子单元，用于根据所述当前文件记录和所述历史文件记录，确定所述待测目标的文件状态。

可选的，所述状态确定子单元，具体包括：信息判断子单元、第一确定子单元、第二确定子单元和第三确定子单元；

所述信息判断子单元，用于判断所述当前文件记录和所述历史文件记录是否均包括所述待测目标的文件信息；

所述第一确定子单元，用于当所述信息判断子单元判断所述当前文件记录包括所述待测目标的文件信息、所述历史文件记录不包括所述待测目标的文件信息时，所述待测目标的文件状态为新增；

所述第二确定子单元，用于当所述信息判断子单元判断所述当前文件记录不包括所述待测目标的文件信息、所述历史文件记录包括所述待测目标的文件信息时，所述待测目标的文件状态为删除；

所述第三确定子单元，用于当所述信息判断子单元判断所述当前文件记录和所述历史文件记录均包括所述待测目标的文件信息时，基于所述当前文件记录、所述历史文件记录和所述待测目标的文件信息，获取当前目标文件和历史目标文件；根据所述当前目标文件的内容和所述历史目标文件的内容，确定所述待测目标的文件状态是否为修改；所述当前目标文件和所述历史目标文件的修改时间不同。

可选的，所述第三确定子单元，具体包括：内容判断子单元、差异判断子单元和修改确定子单元；

所述内容判断子单元，用于判断所述当前目标文件的内容和所述历史目标文件的内容是否存在差异；

所述差异判断子单元，用于当所述内容判断子单元判断所述当前目标文件的内容和所述历史目标文件的内容存在差异时，判断存在的差异是否符合预设修改过滤规则；

所述修改确定子单元，用于当所述差异判断子单元判断所述当前待测目标的内容和所述历史待测目标的内容存在不符合所述预设修改过滤规则的差异时，确定所述待测目标的文件状态为修改。

可选的，所述差异判断子单元，具体包括：第一判断子单元、第二判断子单元和第三判断子单元中的任意一个或多个；

所述第一判断子单元，用于判断所述差异是否为注释差异；

所述第二判断子单元，用于判断所述差异是否为换行/空格差异；

所述第三判断子单元，用于判断所述差异是否为头文件差异。

本申请实施例第三方面提供的一种测试触发设备，包括处理器以及存储器：

所述存储器，用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器，用于根据所述程序代码中的指令执行如上述第一方面提供的测试触发方法中的任意一种。

本申请实施例第四方面提供的一种测试系统，包括：源码服务器和测试执行设备；所述系统还包括如上述第三方面提供所述的测试触发设备；

所述源码服务器，用于存储待测试的目标文件和所述目标文件的开发记录；

所述测试执行设备，用于在所述测试触发设备触发与所述目标文件对应的测试任务，执行所述测试任务。

本申请实施例第五方面提供的一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行如上述第一方面提供的测试触发方法中的任意一种。

与现有技术相比，本申请至少具有以下优点：

在本申请实施例中，首先获得待测目标的开发记录，再基于该开发记录，判断待测目标是否满足测试触发条件。当待测目标满足测试触发条件时，触发与待测目标对应的测试任务。通过对待测目标的开发过程进行智能分析，判断是否需要对该待测目标对应的文件进行自动测试，避免了主观因素对测试任务触发的及时性和必要性判断的干扰，可以保证及时对待测目标对应的文件进行必要的测试，提高了测试触发的准确性和测试的效率。

附图说明

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

图1为本申请实施例提供的一种测试触发方法的流程示意图；

图2为本申请实施例提供的另一种测试触发方法的流程示意图；

图3为本申请实施例提供的另一种测试触发方法的流程示意图；

图4为本申请实施例提供的另一种测试触发方法的流程示意图；

图5为本申请实施例提供的一种测试触发装置的结构示意图；

图6为本申请实施例提供的一种测试触发设备的结构示意图；

图7为本申请实施例提供的一种测试系统的结构示意图。

具体实施方式

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

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

为了便于理解，下面首先介绍本申请实施例涉及的多个技术术语：

测试用例(Test Case)，指的是为某个测试对象而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试任务，指的是用于实现测试用例的执行任务，可以是自动执行测试用例，还可以是对测试用例的调度方法。

Jenkins，原名Hudson，是一个开源的、基于Java开发的可实现持续集成的软件工具，可用于监控持续重复的工作。它能实时监控集成中存在的错误，提供详细的日志文件和告警功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。跟其他持续集成工具相比，它主要有如下优点：开源，即免费使用；可跨平台安装，如windows、linux、os x等；易安装；Web形式的可视化界面管理；技巧、秘诀(tips)丰富，能提供及时快速的帮助。

目前，在利用Jenkins平台进行测试时，测试人员可以把测试用例上传至版本控制工具(SVN)或者分布式版本控制系统(Git)，并在Jenkins上构建测试任务，选择立即触发测试任务。或者，测试人员可以在测试任务构建完成后，配置源码管理并构建触发器，实现测试任务的定时执行。

现有技术中通过Jenkins构建测试任务，虽可实现测试用例的单次、定时运行，但是在立即触发测试任务时，是在测试人员主观认可需要进行测试的前提下才执行测试任务的触发；而定时执行测试任务，又并不判断是否有执行的必要，或者是在测试人员主观认可需要在这段时间内执行，均无法保证测试的及时性和必要性。

为此，本申请实施例提供了一种测试触发方法、装置、设备及系统，通过对被测目标进行分析，根据被测目标的开发记录对被测目标是否满足测试触发条件进行判断，确定是否需要对被测目标进行测试。当被测目标满足测试触发条件时，触发与被测目标对应的测试任务，避免了主观因素对测试任务执行的及时性和必要性判断的干扰，可以保证及时对被测目标进行必要的测试，提高了测试触发的准确性和测试的效率。

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

参见图1，该图为本申请实施例提供的一种测试触发方法的流程示意图。

本申请实施例提供的测试触发方法，包括：

S101：获得被测目标的开发记录。

可以理解的是，待测目标指的是待检测是否需要进行测试的对象，该对象可以是一个软件功能、文件名、关键词或文件类型等。在实际应用中，待测目标对应的文件可以预先存储在目标测试地址中以便测试，例如，待测目标对应的文件可以存储在源码服务器等存储设备设定的存储地址中。

在一些可能的实现方式中，待测目标可以与目标测试地址中存储的任意一个文件对应，或者，待测目标可以与目标测试地址中存储的指定的一个文件对应，具体实施时可以通过指定的文件路径和/或文件名称确定源码服务器中与待测目标对应的文件。

需要说明的是，在实际应用中，为了实现快捷、便利的自动化测试，通常会指定一个或多个文件进行是否需要测试的检测。例如，对源码服务器中存储的全部文件进行是否需要测试的检测，或者，对源码服务器中指定的文件进行是否需要测试的检测。为此，在一些可能的设计中，可以通过设定不同的驱动模式来确定待检测是否需要进行测试的对象(即待测目标)。例如，可以预先设定以下两种驱动模式：全部文件解析驱动模式(full fileanalyze driven mode，FFADM)和指定文件解析驱动模式(specified file analyzedriven mode，SFADM)。其中，FFADM针对源码服务器中全部的文件进行是否需要测试的检测(即解析)，则待测目标与码服务器中存储的任意一个文件对应；SFADM针对源码服务器中指定路径或文件名的文件进行是否需要测试的检测(即解析)，则待测目标即与源码服务器中指定的一个文件对应，待测目标可以是指定的路径或文件名。

在本申请实施例中，开发记录包括了软件开发过程中任意一个或多个阶段(如开发阶段、测试阶段和评审阶段等)中对一个文件(如待测目标对应的文件)的处理记录。例如，开发记录可以包括开发人员在编程过程中对文件的处理记录，和/或，测试人员在测试过程中对文件的处理记录等。作为一个示例，该处理记录可以包括文件状态和/或编辑记录。其中，文件状态指的是文件在存储设备中的存储情况，可以包括新增、修改和删除中的任意一个或多个。编辑记录指的是文件的编译情况，可以包括缺陷总数、需求总数和代码覆盖率中的任意一个或多个。

S102：基于开发记录，判断待测目标是否满足测试触发条件。

在本申请实施例中，开发记录能够代表对待测目标的处理情况，能够反映测试的必要性，因此，以开发记录为基础判断是否需要对待测目标进行测试可以确定测试的必要性，在必要的时候及时的对待测目标进行测试，避免了主观因素对测试触发判断的干扰。下面将结合开发记录的具体情况对如何判断待测目标是否满足测试触发条件进行详细说明，这里先不赘述。

在实际应用中，可以通过对测试时间点进行预先的设定，在到达执行时间点时，执行步骤S102以判断是否需要对待测目标进行测试。例如，可以通过对智能分析周期进行配置，确定步骤S102的执行时机。智能分析周期可配置为单次定点和/或区间定点。其中，单次定点表示在该定点时刻(即一个测试时间点)执行一次步骤S102；区间定点则表示在每个时间区域内的定点时刻(即多个测试时间点)均执行一次步骤S102。

S103：当待测目标满足测试触发条件时，触发与待测目标对应的测试任务。

在根据开发记录判断出待测目标满足测试触发条件时，说明此时需要对待测目标进行测试，触发与待测目标对应的测试任务，该测试任务可以是自动执行测试用例，还可以是对测试用例的调度方法，这里不进行限定。

在实际应用中，还可以根据实际需要配置无需解析驱动模式(no analyzedrivenmode，NADM)，直接将步骤S102的判断结果置为是(即待测目标满足测试触发条件)，直接触发与待测目标对应的测试任务，以满足不同的测试触发需求。

在本申请实施例中，首先获得待测目标的开发记录，再基于该开发记录，判断待测目标是否满足测试触发条件。当待测目标满足测试触发条件时，触发与待测目标对应的测试任务。通过对待测目标的开发过程进行智能分析，判断是否需要对该待测目标对应的文件进行自动测试，避免了主观因素对测试任务触发的及时性和必要性判断的干扰，可以保证及时对待测目标对应的文件进行必要的测试，提高了测试触发的准确性和测试的效率。

下面将详细说明具体如何基于待测目标的开发记录判断其是否满足测试触发条件。

参见图2，该图为本申请实施例提供的另一种测试触发方法的流程示意图。

在本申请实施例中，步骤S102具体可以包括：

S201：基于开发记录，得到待测目标的测试权重。

在本申请实施例中，开发记录中包括的对待测目标的影响因素越多其测试权重越高。因此，通过对测试权重进行智能分析，可以准确的得到待测目标的测试必要性，以便及时的对待测目标对应的文件进行必要的测试。

S202：判断测试权重是否大于或等于预设权重阈值。

当测试权重大于或等于预设权重阈值时，确定待测目标满足测试触发条件；当测试权重小于预设权重阈值时，则确定待测目标不满足测试触发条件。实际应用中，可以根据实际情况对预设权重阈值进行设定，这里不再一一列举。

正如前文所述，在本申请实施例一些可能的实现方式中，开发记录可以包括文件状态。该文件状态，可以包括新增、修改和删除中的任意一个或多个。可以理解的是，不同的文件状态其所需要测试的必要性也不同，例如，一般来说，新增的文件和修改的文件相较于删除的文件更需要进行测试。因此，可以基于待测目标的开发记录，确定其测试权重，并以测试权重为依据对待测目标测试的必要性进行判断，提高测试必要性判断的准确性。

则，步骤S201具体可以包括：

S2011：在当前测试时间点，获取待测目标的文件状态和待测目标在前一个测试时间点的测试权重。

在本申请实施例中，测试权重的初始值可以为0，则对第一个测试时间点而言，前一个测试时间点的测试权重即为测试权重的初始值。测试时间点可以根据实际需要具体设定，具体可以参见上述的相关说明，不再赘述。

作为一个示例，当待测目标对应的文件在前一个测试时间点时未存储在目标测试地址中，但在当前测试时间点时存储在目标测试地址中时，待测目标的文件状态为新增；当待测目标对应的文件在前一个测试时间点时的内容和在当前测试时间点的内容不同时，待测目标的文件状态为修改；当待测目标对应的文件在前一个测试时间点时存储在目标测试地址中，但在当前测试时间点时未存储在目标测试地址中时，待测目标的文件状态为删除。

在具体实施时，可以预先构建一个当前文件记录，以记录当前测试时间点时，目标测试地址中存储文件的文件信息。还可以预先构建一个历史文件记录，用于记录前一个测试时间点时目标测试地址中存储文件的文件信息。可以理解的是，当前文件记录和历史文件记录中至少有一个包括待测目标的文件信息。该文件信息包括但不限于以下的任意一个或多个：文件名称、路径和更新时间等。在达到当前测试时间点时，可以自动从目标测试地址获取最新的文件名、路径、更新时间，更新当前文件记录和历史文件记录。

当当前文件记录中包括待测目标的文件名、但历史文件记录中不包括待测目标的文件名时，待测目标的文件状态为更新；当历史文件记录中包括待测目标的文件名、但当前文件记录中不包括待测目标的文件名时，待测目标的文件状态为删除；当当前文件记录和历史文件记录均包括待测目标的文件名时，可以根据待测目标在智能分析临时表和智能分析表中记录的更新时间，判断两个的内容是否存在差异，从而确定其文件状态是否为修改。

具体的，如图3所示，步骤S2011具体可以包括：

S301：获取当前文件记录和历史文件记录。

其中，当前文件记录包括在当前测试时间点时目标测试地址内存储文件的文件信息，历史文件记录包括在前一个测试时间点时目标测试地址内存储文件的文件信息，当前文件记录和/或历史文件记录包括待测目标的文件信息。对当前文件记录和历史文件记录的说明可以参照上述相关内容，不再赘述。

S302：根据当前文件记录和历史文件记录，确定待测目标的文件状态。

由于当前文件记录和历史文件记录分别记录了两个不同测试时间点的文件信息，即可以此为依据确定待测目标的文件状态。

具体的，在一些可能的设计中，步骤S302可以包括：

S3021：判断当前文件记录和历史文件记录是否均包括待测目标的文件信息。

S3022：当当前文件记录包括待测目标的文件信息、历史文件记录不包括待测目标的文件信息时，待测目标的文件状态为新增；

S3023：当当前文件记录不包括待测目标的文件信息、历史文件记录包括待测目标的文件信息时，待测目标的文件状态为删除；

S3024：当当前文件记录和历史文件记录均包括待测目标的文件信息时，基于当前文件记录、历史文件记录和待测目标的文件信息，获取当前目标文件和历史目标文件；根据当前目标文件的内容和历史目标文件的内容，确定待测目标的文件状态是否为修改。

可以理解的是，当前目标文件为待测目标在当前测试时间点对应的文件，历史目标文件为待测目标在前一个测试时间点对应的文件。在一个例子中，当前目标文件和历史目标文件可以是同名但修改时间不同，例如，当前目标文件和历史目标文件可以是同一个软件功能对应的不同版本的文件。

这里需要说明的是，在实际应用中存在不影响其软件功能的内容修改，如注释修改、换行、增加或减少空格、头文件名变更等，这些修改不影响软件功能的实现无需进行测试。因此，在本申请实施例一些可能的实现方式中，为了提高测试的效率，当在待测目标在当前文件记录和历史文件记录中均包括待测目标的文件信息时，需要对待测目标对应的文件在不同测试时间点是否存在不影响其软件功能的内容修改进行过滤，当二者之间存在影响其软件功能的修改时，才确定待测目标的文件状态为修改。

则，在一些可能的实现方式中，如图4所示，步骤S3024具体可以包括：

S401：判断当前目标文件的内容和历史目标文件的内容是否存在差异；若是则执行步骤S402；

在实际应用中，可以利用任意一种文件对比的方法对待测目标的内容和参考文件的内容是否存在差异进行判断，如逐行扫描，这里不进行限定。当待测目标的内容和参考文件的内容存在差异时，说明确定待测目标相比参考文件进行了修改。

S402：判断存在的差异是否符合预设修改过滤规则；当当前待测目标的内容和历史待测目标的内容存在不符合预设修改过滤规则的差异时，则执行步骤S403。

在本申请实施例中，预设修改过滤规则用于过滤不影响软件功能的修改，如注释修改、换行、增加或减少空格、头文件名变更等。当待测目标的内容和参考文件的内容之间存在不符合预设修改过滤规则的差异时，说明对待测目标实现的软件功能和/或实现软件功能的方式进行了修改，有一定测试的必要。在实际应用中，可以根据实际开发情况对预设修改过滤规则进行设定，这里不进行限定。

在一个例子中，步骤S402至少可以包括以下三种可能的实现方式中的任意一个或多个：

第一种可能的实现方式，步骤S402可以包括：判断差异是否为注释差异；第二种可能的实现方式，步骤S402可以包括：判断差异是否为换行/空格差异；第三种可能的实现方式，步骤S402可以包括：判断差异是否为头文件差异。

S403：确定待测目标的文件状态为修改。

当待测目标存在影响实现的软件功能和/或实现软件功能的方式的修改时，确定其文件状态为修改，进而根据修改的文件状态对其测试的必要性进行判断，能够提高测试的效率。

S2012：根据待测目标的文件状态，得到权重累加值。

可以理解的是，在每个测试时间点时，根据待测目标在该测试时间点的文件状态，可以得到前一个测试时间点至当前测试时间点，待测目标的操作情况对其测试必要性的影响(即权重累加值)。

在实际应用中，可以根据实际需要对待测目标的文件状态对应的权重累加值进行设定。在一个例子中，当待测目标的文件状态为新增或删除时，可以将权重累加值设定为5。在另一个例子中，当待测目标的文件状态为修改时，还可以根据对待测目标对应文件的编辑记录，确定该权重累加值。

则，在一个具体的例子中，步骤S2012可以包括：

S2012a：当待测目标的文件状态为修改时，根据编辑记录，得到权重累加值。

在本申请实施例中，获得的开发记录可以包括该编辑记录。作为一个示例，该编辑记录，可以包括：缺陷总数、需求总数和代码覆盖率中的任意一个或多个。实际应用中，该编辑记录可以从自动化运行踪迹文件中获得。

可以理解的是，在软件开发过程中，开发人员一般会针对比较重要的功能(如重要的需求单、引起缺陷很多的功能等)进行软件的开发，对待测目标进行修改，因此，可以根据这些编辑记录判断是否需要对待测目标进行测试，以保证软件开发的质量。

例如，当代码覆盖率为0时，可以直接将权重累加值设置为1；当测试代码覆盖率不为0时，可以根据代码覆盖率计算得到权重累加值。

在实际应用中，因为在开发过程中随着代码覆盖率的上升，需求总数和缺陷总数也会随之增加，所以当代码覆盖率和缺陷总数(bug count)均不为零时，可以根据代码覆盖率和缺陷总数的比值确定权重累加值；当代码覆盖率和需求总数均不为零时，可以根据代码覆盖率和需求总数的比值确定权重累加值。

则，可选的，步骤S2012a具体可以包括：根据第一参数和第二参数的比值，得到权重累加值；

其中，编辑记录包括该第一参数和该第二参数，第一参数可以为代码覆盖率，第二参数可以为缺陷总数或需求总数。

作为一个示例，当缺陷总数、需求总数和代码覆盖率均不为零时，可以根据公式W＝1+CC/BC+CC/DC计算得到权重累加值W；

当代码覆盖率为零时，W＝1；当缺陷总数为零，代码覆盖率和需求总数不为零时，可以根据公式W＝1+CC/DC计算得到权重累加值W；

当需求总数为零，代码覆盖率和缺陷总数不为零时，可以根据公式W＝1+CC/BC计算得到权重累加值W；

当需求总数和缺陷总数为零，代码覆盖率不为零时，可以根据公式W＝1+CC/10计算得到权重累加值W；

其中，CC为代码覆盖率，BC为缺陷总数，DC为需求总数。

S2012b：当待测目标的文件状态为新增时，将第一预设值作为权重累加值。

S2012c：当待测目标的文件状态为删除时，将第二预设值作为权重累加值。

在实际应用中，可以根据实际的编译和测试情况对第一预设值和第二预设值进行设定(如设为5)，这里不进行限定。

S2013：将待测目标在前一个测试时间点的测试权重和得到的权重累加值之和作为待测目标在当前测试时间点的测试权重。

在本申请实施例中，累加每个测试时间点对应的测试权重作为当前测试时间点的测试权重，综合考虑一段时间内对待测目标对应文件的处理记录对测试必要性的影响，更加准确、及时进行必要的测试。当得到的测试权重大于或等于预设权重阈值时，则说明对待测目标测试的必要程度达到预设要求，待测目标满足测试触发条件，需触发待测目标对应的测试任务。此时，触发与待测目标对应的测试任务，保证了及时对待测目标进行必要的测试，提高了测试的效率。

基于上述实施例提供的测试触发方法，本申请实施例还提供了一种测试触发装置。

参见图5，该图为本申请实施例提供的一种测试触发装置的结构示意图。

本申请实施例提供的测试触发装置，包括：记录获取单元100、条件判断单元200和任务触发单元300；

记录获取单元100，用于获得待测目标的开发记录；

条件判断单元200，用于基于开发记录，判断待测目标是否满足测试触发条件；

任务触发单元300，用于当条件判断单元判断待测目标满足测试触发条件时，触发与待测目标对应的测试任务。

可选的，条件判断单元200，具体可以包括：权重计算子单元和阈值判断子单元；

权重计算子单元，用于基于开发记录，得到待测目标的测试权重；

阈值判断子单元，用于判断测试权重是否大于或等于预设权重阈值。

在本申请实施例一些可能的实现方式中，开发记录，可以包括：文件状态；文件状态，可以包括：新增、修改和删除中的任意一个或多个；则，权重计算子单元，具体可以包括：获取子单元、累加子单元和确定子单元；

获取子单元，用于在当前测试时间点，获取待测目标的文件状态和待测目标在前一个测试时间点的测试权重；

累加子单元，用于根据待测目标的文件状态，得到权重累加值；

确定子单元，用于将待测目标在前一个测试时间点的测试权重和权重累加值之和作为待测目标在当前测试时间点的测试权重。

在本申请实施例一些可能的实现方式中，累加子单元，具体可以包括：第一子单元、第二子单元和第三子单元；

第一子单元，用于当待测目标的文件状态为修改时，根据待测目标的编辑记录，计算得到权重累加值；开发记录包括编辑记录；

第二子单元，用于当待测目标的文件状态为新增时，将第一预设值作为权重累加值；

第三子单元，用于当待测目标的文件状态为删除时，将第二预设值作为权重累加值。

可选的，第一子单元，具体可以用于：根据第一参数和第二参数的比值，得到权重累加值；其中，编辑记录包括第一参数和第二参数，第一参数为代码覆盖率，第二参数为缺陷总数或需求总数。

在本申请实施例一些可能的实现方式中，获取子单元，具体可以包括：记录获取子单元和状态确定子单元；

记录获取子单元，用于获取当前文件记录和历史文件记录；当前文件记录包括在当前测试时间点时目标测试地址内存储文件的文件信息，历史文件记录包括在前一个测试时间点时目标测试地址内存储文件的文件信息，当前文件记录和/或历史文件记录包括待测目标的文件信息；

状态确定子单元，用于根据当前文件记录和历史文件记录，确定待测目标的文件状态。

在本申请实施例一些可能的实现方式中，状态确定子单元，具体可以包括：信息判断子单元、第一确定子单元、第二确定子单元和第三确定子单元；

信息判断子单元，用于判断当前文件记录和历史文件记录是否均包括待测目标的文件信息；

第一确定子单元，用于当信息判断子单元判断当前文件记录包括待测目标的文件信息、历史文件记录不包括待测目标的文件信息时，待测目标的文件状态为新增；

第二确定子单元，用于当信息判断子单元判断当前文件记录不包括待测目标的文件信息、历史文件记录包括待测目标的文件信息时，待测目标的文件状态为删除；

第三确定子单元，用于当信息判断子单元判断当前文件记录和历史文件记录均包括待测目标的文件信息时，基于当前文件记录、历史文件记录和待测目标的文件信息，获取当前目标文件和历史目标文件；根据当前目标文件的内容和历史目标文件的内容，确定待测目标的文件状态是否为修改；当前目标文件和历史目标文件的修改时间不同。

在本申请实施例一些可能的实现方式中，第三确定子单元，具体可以包括：内容判断子单元、差异判断子单元和修改确定子单元；

内容判断子单元，用于判断当前目标文件的内容和历史目标文件的内容是否存在差异；

差异判断子单元，用于当内容判断子单元判断当前目标文件的内容和历史目标文件的内容存在差异时，判断存在的差异是否符合预设修改过滤规则；

修改确定子单元，用于当差异判断子单元判断当前待测目标的内容和历史待测目标的内容存在不符合预设修改过滤规则的差异时，确定待测目标的文件状态为修改。

可选的，差异判断子单元，具体可以包括：第一判断子单元、第二判断子单元和第三判断子单元中的任意一个或多个；

第一判断子单元，用于判断差异是否为注释差异；

第二判断子单元，用于判断差异是否为换行/空格差异；

第三判断子单元，用于判断差异是否为头文件差异。

基于上述实施例提供的测试触发方法和装置，本申请实施例还提供了一种测试触发设备。

参见图6，该图为本申请实施例提供的一种测试触发设备的结构示意图。

本申请实施例提供的测试触发设备，包括：处理器610以及存储器620：

存储器610，用于存储程序代码，并将程序代码传输给处理器；

处理器620，用于根据程序代码中的指令执行如上述实施例提供的测试触发方法中的任意一种。

基于上述实施例提供的测试触发方法、装置和设备，本申请实施例还提供了一种测试系统。

参见图7，该图为本申请实施例提供的一种测试系统的结构示意图。

本申请实施例提供的测试系统，包括：源码服务器710和测试执行设备720；还包括如上述实施例提供的测试触发设备730；

源码服务器710，用于存储待测试的目标文件和目标文件的开发记录；

测试执行设备720，用于在测试触发设备730触发与目标文件对应的测试任务，执行测试任务。

基于上述实施例提供的测试触发方法和装置，本申请实施例还提供了一种计算机可读存储介质。该计算机可读存储介质用于存储程序代码，该程序代码用于执行如上述实施例提供的测试触发方法中的任意一种。

需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统或装置而言，由于其与实施例公开的方法相对应，所以描述比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述，仅是本申请的较佳实施例而已，并非对本申请作任何形式上的限制。虽然本申请已以较佳实施例揭露如上，然而并非用以限定本申请。任何熟悉本领域的技术人员，在不脱离本申请技术方案范围情况下，都可利用上述揭示的方法和技术内容对本申请技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本申请技术方案的内容，依据本申请的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本申请技术方案保护的范围内。

Claims (10)

1.一种测试触发方法，其特征在于，所述方法包括：

获得待测目标的开发记录；

基于所述开发记录，判断所述待测目标是否满足测试触发条件；

当所述待测目标满足所述测试触发条件时，触发与所述待测目标对应的测试任务。

2.根据权利要求1所述的方法，其特征在于，所述基于所述开发记录，判断所述待测目标是否满足测试触发条件，具体包括：

基于所述开发记录，得到所述待测目标的测试权重；

判断所述测试权重是否大于或等于预设权重阈值。

3.根据权利要求2所述的方法，其特征在于，所述开发记录，包括：文件状态；所述文件状态，包括：新增、修改和删除中的任意一个或多个；所述基于所述开发记录，得到所述待测目标的测试权重，具体包括：

在当前测试时间点，获取所述待测目标的文件状态和所述待测目标在前一个测试时间点的测试权重；

根据所述待测目标的文件状态，得到权重累加值；

将所述待测目标在前一个测试时间点的测试权重和所述权重累加值之和作为所述待测目标在所述当前测试时间点的测试权重。

4.根据权利要求3所述的方法，其特征在于，所述根据所述待测目标的文件状态，得到权重累加值，具体包括：

当所述待测目标的文件状态为修改时，根据所述待测目标的编辑记录，计算得到所述权重累加值；所述开发记录包括所述编辑记录；

当所述待测目标的文件状态为新增时，将第一预设值作为所述权重累加值；

当所述待测目标的文件状态为删除时，将第二预设值作为所述权重累加值。

5.根据权利要求4所述的方法，其特征在于，所述根据所述待测目标的编辑记录，计算得到所述权重累加值，具体包括：

根据第一参数和第二参数的比值，得到所述权重累加值；

其中，所述编辑记录包括所述第一参数和所述第二参数，所述第一参数为代码覆盖率，所述第二参数为缺陷总数或需求总数。

6.根据权利要求3-5任意一项所述的方法，其特征在于，所述获取所述待测目标的文件状态，具体包括：

获取当前文件记录和历史文件记录；所述当前文件记录包括在所述当前测试时间点时目标测试地址内存储文件的文件信息，所述历史文件记录包括在所述前一个测试时间点时目标测试地址内存储文件的文件信息，所述当前文件记录和/或所述历史文件记录包括所述待测目标的文件信息；

根据所述当前文件记录和所述历史文件记录，确定所述待测目标的文件状态。

7.一种测试触发装置，其特征在于，所述装置包括：记录获取单元、条件判断单元和任务触发单元；

所述记录获取单元，用于获得待测目标的开发记录；

所述条件判断单元，用于基于所述开发记录，判断所述待测目标是否满足测试触发条件；

所述任务触发单元，用于当所述条件判断单元判断所述待测目标满足所述测试触发条件时，触发与所述待测目标对应的测试任务。

8.一种测试触发设备，其特征在于，所述设备包括处理器以及存储器：

所述存储器，用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器，用于根据所述程序代码中的指令执行权利要求1-9任意一项所述的测试触发方法。

9.一种测试系统，其特征在于，所述系统包括：源码服务器和测试执行设备；所述系统还包括如权利要求8所述的测试触发设备；

所述源码服务器，用于存储待测试的目标文件和所述目标文件的开发记录；

所述测试执行设备，用于在所述测试触发设备触发与所述目标文件对应的测试任务，执行所述测试任务。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行权利要求1-6任意一项所述的测试触发方法。