CN117215959A - 软件测试方法、装置、设备及存储介质 - Google Patents

Abstract

本发明涉及软件测试技术领域，尤其涉及一种软件测试方法、装置、设备及存储介质，本发明通过确定软件在待测试版本的已变更代码和已变更代码对应的功能测试范围，再通过预设用例库查询该测试范围对应的测试用例，进而可以通过该测试用例对待测试版本软件的各代码行进行功能性测试，实现在版本迭代时，自动进行软件版本的测试，同时通过统计测试执行记录是否满足预设测试条件，确定何时结束软件测试，简化测试步骤，避免了现有技术中软件迭代测试时，测试步骤繁琐，成本较高的技术问题，提高了用户软件测试的效率。

Description

软件测试方法、装置、设备及存储介质

技术领域

本发明涉及软件测试技术领域，尤其涉及一种软件测试方法、装置、设备及存储介质。

背景技术

软件测试是软件开发过程中必不可少的环节，当软件迭代更新后，都需要经过一定程度的测试验证才能进行软件的发布，以保证用户使用软件时的可靠性。

目前通常的测试方法是，测试人员根据需求变更和影响的功能设计测试用例来验证功能正确与否。由于通常代码之间存在着极其复杂的内在联系，在识别某个修改的影响范围的时候，没有一个可靠且完整的评估方法来保证所使用的测试用例能够全面覆盖此次修改的影响范围，因而形成测试盲区、遗漏缺陷的风险较大。

同时针对软件的全功能的回归测试虽然可以很大程度提高测试的质量，但显然又是有着极高的时间和人力成本，在大多数时候并不合适，特别是对于一个持续迭代的软件产品，每个版本都需要进行测试工作，还让未发生变更的功能进行反复测试，使得测试效率较低。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供一种软件测试方法、装置、设备及存储介质，旨在解决现有技术中软件迭代测试时，测试步骤繁琐，成本较高的技术问题。

为实现上述目的，本发明提供了一种软件测试方法，所述方法包括以下步骤：

获取待测试版本的已变更代码和对应的测试范围；

通过预设用例库查询所述测试范围对应的测试用例；

基于所述测试用例对所述待测试版本的软件的各代码行进行功能性测试，得到测试执行记录；

统计所述测试执行记录对应的测试覆盖率；

在所述测试覆盖率满足预设测试条件时，结束软件测试。

可选地，所述获取待测试版本的已变更代码和对应的测试范围，包括：

遍历待测试版本的待测试代码文件和历史版本的历史代码文件；

将所述待测试代码文件和所述历史代码文件进行文件对比，得到已变更代码；

解析所述已变更代码，确定所述已变更代码对应的测试范围。

可选地，所述解析所述已变更代码，确定所述已变更代码对应的测试范围，包括：

根据所述待测试代码和所述历史代码文件构建方法调用树；

基于所述已变更代码通过所述方法调用树进行递归搜索，得到目标根节点；

确定所述目标根节点对应的测试功能和测试范围。

可选地，所述统计所述测试执行记录对应的测试覆盖率，包括：

在所述待测试版本软件的各代码行中对所述已变更代码进行编译和插桩，得到可执行文件；

根据插桩模式运行所述可执行文件，并统计所述已变更代码的标记执行量；

根据所述测试执行记录和所述标记执行量之间的比例生成测试覆盖率。

可选地，所述通过预设用例库查询所述测试范围对应的测试用例之前，还包括：

获取各测试用例的代码覆盖范围；

基于预设覆盖原则、所述代码覆盖范围以及各所述测试用例建立预设用例库。

可选地，所述软件测试方法，还包括：

在所述测试覆盖率不满足预设测试条件时，将所述测试执行记录和历史测试执行记录进行合并，得到历史整体覆盖率；

根据所述历史整体覆盖率更新测试用例；

返回所述获取待测试版本的已变更代码和对应的测试范围的步骤，直至所述测试覆盖率满足预设测试条件。

可选地，所述将所述测试执行记录和历史测试执行记录进行合并，得到历史整体覆盖率，包括：

根据所述测试执行记录和历史测试执行记录确定当前版本对应的第一代码覆盖率和上一版本对应的第二代码覆盖率，所述第一代码覆盖率为当前版本的未变更代码、变更代码以及新增代码之和，所述第二代码覆盖为上一版本的未变更代码、变更代码以及新增代码之和；

计算所述第一代码覆盖率和第二代码覆盖率的比值，得到历史整体覆盖率。

此外，为实现上述目的，本发明还提出一种软件测试装置，所述软件测试装置包括：

获取模块，用于获取待测试版本的已变更代码和对应的测试范围；

查询模块，用于通过预设用例库查询所述测试范围对应的测试用例；

测试模块，用于基于所述测试用例对所述待测试版本的软件的各代码行进行功能性测试，得到测试执行记录；

统计模块，用于统计所述测试执行记录对应的测试覆盖率；

执行模块，用于在所述测试覆盖率满足预设测试条件时，结束软件测试。

此外，为实现上述目的，本发明还提出一种软件测试设备，所述软件测试设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的软件测试程序，所述软件测试程序配置为实现如上文所述的软件测试方法的步骤。

此外，为实现上述目的，本发明还提出一种存储介质，所述存储介质上存储有软件测试程序，所述软件测试程序被处理器执行时实现如上文所述的软件测试方法的步骤。

本发明公开了一种软件测试方法，所述软件测试方法包括：获取待测试版本的已变更代码和对应的测试范围；通过预设用例库查询所述测试范围对应的测试用例；基于所述测试用例对所述待测试版本的软件的各代码行进行功能性测试，得到测试执行记录；统计所述测试执行记录对应的测试覆盖率；在所述测试覆盖率满足预设测试条件时，结束软件测试，与现有技术相比，本发明通过确定软件在待测试版本的已变更代码和已变更代码对应的功能测试范围，再通过预设用例库查询该测试范围对应的测试用例，进而可以通过该测试用例对待测试版本软件的各代码行进行功能性测试，实现在版本迭代时，自动进行软件版本的测试，同时通过统计测试执行记录是否满足预设测试条件，确定何时结束软件测试，简化测试步骤，避免了现有技术中软件迭代测试时，测试步骤繁琐，成本较高的技术问题，提高了用户软件测试的效率。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的软件测试设备的结构示意图；

图2为本发明软件测试方法第一实施例的流程示意图；

图3为本发明软件测试方法第二实施例的流程示意图；

图4为本发明软件测试方法第三实施例的流程示意图；

图5为本发明软件测试方法一实施例的版本覆盖率计算场景示意图；

图6为本发明软件测试装置第一实施例的结构框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的软件测试设备结构示意图。

如图1所示，该软件测试设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(Wireless-Fidelity，Wi-Fi)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对软件测试设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及软件测试程序。

在图1所示的软件测试设备中，网络接口1004主要用于与网络服务器进行数据通信；用户接口1003主要用于与用户进行数据交互；本发明软件测试设备中的处理器1001、存储器1005可以设置在软件测试设备中，所述软件测试设备通过处理器1001调用存储器1005中存储的软件测试程序，并执行本发明实施例提供的软件测试方法。

本发明实施例提供了一种软件测试方法，参照图2，图2为本发明一种软件测试方法第一实施例的流程示意图。

本实施例中，所述软件测试方法包括以下步骤：

步骤S10：获取待测试版本的已变更代码和对应的测试范围。

需要说明的是，本实施例方法的执行主体可以是具有数据处理、程序运行以及通信传输等功能的设备，例如：控制计算或者云端服务器等设备，还可以是其他可以实现相同或者相似功能的设备，本实施例对此不做具体限制，在本实施例以及下述实施例中，将会以控制计算机为例进行说明。

应当说明的是，传统技术中，由于代码变更包括但不限于：变量映射关系的变更、增减以及功能算法的增减等方式，在进行软件测试时，为了避免出现较大的运行问题，需要针对软件在该版本能够实现的功能进行大数量级的测试，从而避免用户在使用时出现故障。

但是在正式测试过程中，为了软件运行的稳定性，需要对软件在待测试版本的所有功能进行测试，其中包括了没有发生变更的代码对应的功能，这些未发生变更的代码对应的功能会较大程度影响软件测试的效率，但是由于软件代码量级较大，测试人员又无法确定那些功能或者那些代码行是没有发生变更的，这也软件测试造成了较大干扰。

可以理解的是，已变更代码是指归属于同一代码块中发生代码变更的所有代码，也就是说只要一个代码块中任意一行代码只要发生了改变，其上游或者下游的代码行都会被标记为已变更代码。

测试范围是指已变更代码的上一级代码块所实现的功能范围，例如：为了比较两个数组之间的大小关系，可以分别将两个数组内的数值进行累加，在比较两个数值累加值，可以确定两个数组之间的大小关系，在这个过程中，若是数组A中的数值发生改变，那么已变更代码为数组A对应的代码块，其所影响的范围为整个比较两个数组之间的大小关系对应的上一级代码块。

具体来说，比较数组A{1，2，3}和数组B{1，2，4}之间的大小关系，若是代码块A用于计算数组A的累加值，代码块B用于计算数组B的累加值，代码块C用于比较两个累加值，当数组A中的数组发生变化时，其影响的范围包括代码块A、代码块B以及代码块C，对应的测试范围也就是代码块A、代码块B以及代码块C。

步骤S20：通过预设用例库查询所述测试范围对应的测试用例。

应当说明的是，预设用例库中存储有各种测试用例的功能覆盖范围，通过测试范围与测试用例之间的映射关系，可以在预设用例库中查询到用于进行软件测试的测试用例。

进一步地，所述通过预设用例库查询所述测试范围对应的测试用例之前，还包括：

获取各测试用例的代码覆盖范围；

基于预设覆盖原则、所述代码覆盖范围以及各所述测试用例建立预设用例库。

在具体实现中，预设覆盖原则是指各个测试用例之间保持最小的代码覆盖范围交集，即使得各个测试用例对应的代码覆盖范围不重合或者重合较少的部分，主要用于精简测试用例的作用，提高后续软件测试效率，并当代码再次发生变动时，可以根据已变更代码和其对应的代码影响范围得到新的变更影响范围，还可以从用例库中快速筛选出合适的用例，以达到对影响范围的测试覆盖，提高了软件测试的可靠性。

步骤S30：基于所述测试用例对所述待测试版本的软件的各代码行进行功能性测试，得到测试执行记录。

需要说明的是，由于测试用例可以实现不同的功能，在基于测试用例对待测试版本软件的各代码行进行功能性测试时，其得到的运行结果差别较大，因此可以通过记录各个测试用例的执行记录，以确定各测试用例是否成功执行，来判定各代码行是否存在错误。

步骤S40：统计所述测试执行记录对应的测试覆盖率。

可以理解的是，测试覆盖率用于评估在测试过程中对软件的哪些部分进行了测试，表示被测试的代码、功能或需求在整体范围内的覆盖情况，测试覆盖率包括但不限于语句覆盖率、分支覆盖率、函数覆盖率、条件覆盖率以及路径覆盖率等。

进一步地，所述统计所述执行记录对应的测试覆盖率，包括：

在所述待测试版本软件的各代码行中对所述已变更代码进行编译和插桩，得到可执行文件；

根据插桩模式运行所述可执行文件，并统计所述已变更代码的标记执行量；

根据所述执行记录和所述标记执行量之间的比例生成测试覆盖率。

在具体实现中，在进行完测试工作后，导出各代码行的执行记录，得到被执行过的标记代码。被执行过的标记代码量与总体待测的标记代码量之比，便是测试的覆盖率。被标记但未被执行过的代码，便是没有被测试到的逻辑，需要继续增加测试用例和丰富测试方法来达到对被测代码更高的覆盖率。

其中，插桩包括线下插桩和运行实时插桩，所述线下插桩是指在代码编译或执行之前，在源代码中插入特定的代码片段(称为插桩代码)，以实现对程序行为的监控、数据采集或调试等目的，具体步骤包括：确定目标插桩工具或框架，并将所述目标插桩工具集成到开发环境中；在目标插桩位置插入相应的插桩代码；编译源代码，生成插桩后的可执行文件或库；本地运行插桩后的程序，并观察插桩代码的执行情况，其中目标插桩位置可以是函数入口、循环体、条件判断等。

运行插桩是指在程序执行过程中动态地插入特定代码(称为插桩代码)来监控、修改或扩展程序的行为。与线下插桩不同，运行插桩是在实际运行环境中进行，通常用于调试、性能分析、运行时监控等目的。

其中，运行插桩是指在程序执行过程中动态地插入特定代码(称为插桩代码)来监控、修改或扩展程序的行为。与线下插桩不同，运行插桩是在实际运行环境中进行，通常用于调试、性能分析、运行时监控等目的。

运行插桩的具体步骤如下：选择适合的插桩工具或框架，并将其集成到目标系统中。常见的插桩工具包括DynamoRIO、Pin、Valgrind等。根据需要，在目标程序的关键位置(如函数入口、循环体、条件判断等)插入所需的插桩代码。插桩代码可以用来记录跟踪程序的执行路径、收集性能数据、捕获异常等。编译和链接目标程序，将插桩代码嵌入到二进制可执行文件或库中。在实际运行环境中启动被插桩的程序。当程序执行到插桩点时，插桩代码会被执行。根据插桩代码的功能，可以进行相应的行为监控、数据采集、性能分析等操作。收集插桩数据并进行分析，以获取对程序行为的理解、调试问题或评估性能等。

通过手动添加或某些语言的覆盖率工具(例如对于Java语言使用JaCoCo)为被测试代码增加运行时标记，这样当对编译得到的测试版本软件进行测试时，便可以收集到这些代码行的执行情况。

步骤S50：在所述测试覆盖率满足预设测试条件时，结束软件测试。

应当理解的是，预设测试条件可以是测试覆盖率大于一定阈值，该阈值可以设定更为90％，本实施例对此不做具体限制。

本实施例通过确定软件在待测试版本的已变更代码和已变更代码对应的功能测试范围，再通过预设用例库查询该测试范围对应的测试用例，进而可以通过该测试用例对待测试版本软件的各代码行进行功能性测试，实现在版本迭代时，自动进行软件版本的测试，同时通过统计测试执行记录是否满足预设测试条件，确定何时结束软件测试，简化测试步骤，避免了现有技术中软件迭代测试时，测试步骤繁琐，成本较高的技术问题，提高了用户软件测试的效率。

参考图3，图3为本发明一种软件测试方法第二实施例的流程示意图。

基于上述第一实施例，在本实施例中，所述步骤S10，包括：

步骤S101：遍历待测试版本的待测试代码文件和历史版本的历史代码文件。

需要说明的是，为了确定待测试版本的已变更代码，通过获取待测试版本的待测试代码文件和历史版本的历史代码文件，其中历史版本是指上一次更新的版本，例如：待测试版本为1.1.2，那么上一次更新的版本为1.1.1。

步骤S102：将所述待测试代码文件和所述历史代码文件进行文件对比，得到已变更代码。

应当理解的是，在获得待测试代码文件和历史代码文件之后，读取待测试代码文件中的各代码行，以及历史代码文件中的各代码行，从而依靠代码版本管控系统，通过文件对比(例如diff命令)可以找出发生变更的代码行。

步骤S103：解析所述已变更代码，确定所述已变更代码对应的测试范围。

值得说明的是，解析已变更代码，确定已变更代码对应的测试范围可以是通过溯源或者递归搜索的方式找到已变更代码所归属的根节点，进而根据根节点所对应的注释或者标记符等信息确定测试功能和测试范围。

进一步地，所述解析所述已变更代码，确定所述已变更代码对应的测试范围，包括：

根据所述待测试代码和所述历史代码文件构建方法调用树；

基于所述已变更代码通过所述方法调用树进行递归搜索，得到目标根节点；

确定所述目标根节点对应的测试功能和测试范围。

在具体实现中，根据对应开发语言的语法规则解析出代码行所属的方法，从而得到所有发生变更的方法集合，遍历所有代码，构建出全代码的方法调用树，变更的方法将分布在这棵树的某些枝叶节点上，沿着某一个变更方法的枝叶节点向上递归搜索，最后会终止在一个根节点上，这个根节点所代表的功能入口便可认为是该变更方法所影响到的功能，对每个变更方法进行如此搜索便可以得到受影响的代码范围，这些受影响的代码所涉及到的功能范围便是需要测试验证的范围，由此可以更清晰准确地得到测试应该涵盖的功能和测试范围。

本实施例通过对待测试版本的代码文件和历史版本的代码文件进行对比，从而确定两个代码文件中包含的代码行的差异，进而确定已变更代码，再通过递归搜索的方式对已变更代码进行溯源，确定其对应的根节点和功能，进而确定测试范围，精确的划分需要进行测试的代码范围，极大的提高了软件测试的效率。

参考图4，图4为本发明一种软件测试方法第三实施例的流程示意图。

基于上述第二实施例，在本实施例中，所述步骤S50之后，还包括：

步骤S60：在所述测试覆盖率不满足预设测试条件时，将所述测试执行记录和历史测试执行记录进行合并，得到历史整体覆盖率。

需要说明的是，测试覆盖率不满足预设测试条件时，即测试用例或者测试策略选用不当，可以通过调整测试用例和测试策略实现覆盖率的提高。

进一步地，为了计算历史整体覆盖率，所述将所述执行记录和历史执行记录进行合并，得到历史整体覆盖率，包括：

根据所述执行记录和历史执行记录确定当前版本对应的第一代码覆盖率和上一版本对应的第二代码覆盖率，所述第一代码覆盖率为当前版本的未变更代码、变更代码以及新增代码之和，所述第二代码覆盖为上一版本的未变更代码、变更代码以及新增代码之和；

计算所述第一代码覆盖率和第二代码覆盖率的比值，得到历史整体覆盖率。

在具体实现中，参考图5，图5为本实施例覆盖率计算的示意图，当存在产品的两个代码版本，版本A与版本B。可见版本B的代码由版本A中未变更的部分(用O代表)加上版本A中变更的部分(用C代表)，再加上版本B中新增的部分(用N代表)组成。经过覆盖率测试后，得到A、B两个版本上的测试执行数据，包括在版本A上测试得到的未变更部分的执行数据(O’)，在版本B上测试得到的变更部分执行数据(C’)，以及版本B上测试得到的增加部分执行数据(N’)。由此可以推导出新版本B的总体历史测试覆盖率为：(O’+N’+C’)/(O+N+C)。

步骤S70：根据所述历史整体覆盖率更新测试用例。

可以理解的是，在历史整体覆盖率低于一定阈值时，可以根据历史调整的方案从用例库中快速筛选出合适的用例，以达到对影响范围的测试覆盖。

步骤S80：返回所述获取待测试版本的已变更代码和对应的测试范围的步骤，直至所述测试覆盖率满足预设测试条件。

本实施例通过根据待测试版本的执行记录和历史版本的历史执行记录进行合并，从而计算出历史整体的覆盖率，实现对软件总体的测试覆盖情况监控形成软件产品的测试覆盖率记录，为后续测试用例或者测试方法的调整留下参考案例，提高产品持续更新迭代过程的测试效率。

此外，本发明实施例还提出一种存储介质，所述存储介质上存储有软件测试程序，所述软件测试程序被处理器执行时实现如上文所述的软件测试方法的步骤。

由于本存储介质采用了上述所有实施例的全部技术方案，因此至少具有上述实施例的技术方案所带来的所有有益效果，在此不再一一赘述。

参照图6，图6为本发明软件测试装置第一实施例的结构框图。

如图6所示，本发明实施例提出的软件测试装置包括：

获取模块10，用于获取待测试版本的已变更代码和对应的测试范围。

查询模块20，用于通过预设用例库查询所述测试范围对应的测试用例。

测试模块30，用于基于所述测试用例对所述待测试版本的软件的各代码行进行功能性测试，得到测试执行记录。

统计模块40，用于统计所述测试执行记录对应的测试覆盖率。

执行模块50，用于在所述测试覆盖率满足预设测试条件时，结束软件测试。

在一实施例中，所述获取模块10，还用于遍历待测试版本的待测试代码文件和历史版本的历史代码文件；将所述待测试代码文件和所述历史代码文件进行文件对比，得到已变更代码；解析所述已变更代码，确定所述已变更代码对应的测试范围。

在一实施例中，所述获取模块10，还用于根据所述待测试代码和所述历史代码文件构建方法调用树；基于所述已变更代码通过所述方法调用树进行递归搜索，得到目标根节点；确定所述目标根节点对应的测试功能和测试范围。

在一实施例中，所述统计模块40，还用于在所述待测试版本软件的各代码行中对所述已变更代码进行编译和插桩，得到可执行文件；根据插桩模式运行所述可执行文件，并统计所述已变更代码的标记执行量；根据所述测试执行记录和所述标记执行量之间的比例生成测试覆盖率。

在一实施例中，所述查询模块20，还用于获取各测试用例的代码覆盖范围；基于预设覆盖原则、所述代码覆盖范围以及各所述测试用例建立预设用例库。

在一实施例中，所述统计模块40，还用于在所述测试覆盖率不满足预设测试条件时，将所述测试执行记录和历史测试执行记录进行合并，得到历史整体覆盖率；根据所述历史整体覆盖率更新测试用例；返回所述获取待测试版本的已变更代码和对应的测试范围的步骤，直至所述测试覆盖率满足预设测试条件。

在一实施例中，所述统计模块40，还用于根据所述测试执行记录和历史测试执行记录确定当前版本对应的第一代码覆盖率和上一版本对应的第二代码覆盖率，所述第一代码覆盖率为当前版本的未变更代码、变更代码以及新增代码之和，所述第二代码覆盖为上一版本的未变更代码、变更代码以及新增代码之和；计算所述第一代码覆盖率和第二代码覆盖率的比值，得到历史整体覆盖率。

本实施例通过确定软件在待测试版本的已变更代码和已变更代码对应的功能测试范围，再通过预设用例库查询该测试范围对应的测试用例，进而可以通过该测试用例对待测试版本软件的各代码行进行功能性测试，实现在版本迭代时，自动进行软件版本的测试，同时通过统计测试执行记录是否满足预设测试条件，确定何时结束软件测试，简化测试步骤，避免了现有技术中软件迭代测试时，测试步骤繁琐，成本较高的技术问题，提高了用户软件测试的效率。

应该理解的是，虽然本申请实施例中的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

需要说明的是，以上所描述的工作流程仅仅是示意性的，并不对本发明的保护范围构成限定，在实际应用中，本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的，此处不做限制。

另外，未在本实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的软件测试方法，此处不再赘述。

此外，需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

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

获取待测试版本的已变更代码和对应的测试范围；

通过预设用例库查询所述测试范围对应的测试用例；

基于所述测试用例对所述待测试版本的软件的各代码行进行功能性测试，得到测试执行记录；

统计所述测试执行记录对应的测试覆盖率；

在所述测试覆盖率满足预设测试条件时，结束软件测试。

2.如权利要求1所述的软件测试方法，其特征在于，所述获取待测试版本的已变更代码和对应的测试范围，包括：

遍历待测试版本的待测试代码文件和历史版本的历史代码文件；

将所述待测试代码文件和所述历史代码文件进行文件对比，得到已变更代码；

解析所述已变更代码，确定所述已变更代码对应的测试范围。

3.如权利要求2所述的软件测试方法，其特征在于，所述解析所述已变更代码，确定所述已变更代码对应的测试范围，包括：

根据所述待测试代码和所述历史代码文件构建方法调用树；

基于所述已变更代码通过所述方法调用树进行递归搜索，得到目标根节点；

确定所述目标根节点对应的测试功能和测试范围。

4.如权利要求1-3中任一项所述的软件测试方法，其特征在于，所述统计所述测试执行记录对应的测试覆盖率，包括：

在所述待测试版本软件的各代码行中对所述已变更代码进行编译和插桩，得到可执行文件，插桩包括线下插桩和运行实时插桩；

根据插桩模式根据插桩模式运行所述可执行文件，并统计所述已变更代码的标记执行量；

根据所述测试执行记录和所述标记执行量之间的比例生成测试覆盖率；

所述线下插桩的方式包括：确定目标插桩框架，并将所述目标插桩框架集成到开发环境中；在目标插桩位置插入相应的插桩代码；编译插桩代码，生成插桩后的可执行文件；本地运行可执行文件，并获取插桩代码的执行情况信息；

所述运行实时插桩包括：确定目标插桩框架，并将所述目标插桩框架集成到开发环境中；在目标程序的关键位置插入目标插桩代码；编译和链接目标插桩代码；在待测试版本软件运行过程中，启动被插桩的程序。

5.如权利要求1-3中任一项所述的软件测试方法，其特征在于，所述通过预设用例库查询所述测试范围对应的测试用例之前，还包括：

获取各测试用例的代码覆盖范围；

基于预设覆盖原则、所述代码覆盖范围以及各所述测试用例建立预设用例库，其中，所述预设覆盖原则是指各个测试用例之间保持最小的代码覆盖范围交集。

6.如权利要求1-3中任一项所述的软件测试方法，其特征在于，所述软件测试方法，还包括：

在所述测试覆盖率不满足预设测试条件时，将所述测试执行记录和历史测试执行记录进行合并，得到历史整体覆盖率；

根据所述历史整体覆盖率更新测试用例；

返回所述获取待测试版本的已变更代码和对应的测试范围的步骤，直至所述测试覆盖率满足预设测试条件。

7.如权利要求6所述的软件测试方法，其特征在于，所述将所述测试执行记录和历史测试执行记录进行合并，得到历史整体覆盖率，包括：

根据所述测试执行记录和历史测试执行记录确定当前版本对应的第一代码覆盖率和上一版本对应的第二代码覆盖率，所述第一代码覆盖率为当前版本的未变更代码、变更代码以及新增代码之和，所述第二代码覆盖为上一版本的未变更代码、变更代码以及新增代码之和；

计算所述第一代码覆盖率和第二代码覆盖率的比值，得到历史整体覆盖率。

8.一种软件测试装置，其特征在于，所述软件测试装置包括：

获取模块，用于获取待测试版本的已变更代码和对应的测试范围；

查询模块，用于通过预设用例库查询所述测试范围对应的测试用例；

测试模块，用于基于所述测试用例对所述待测试版本的软件的各代码行进行功能性测试，得到测试执行记录；

统计模块，用于统计所述测试执行记录对应的测试覆盖率；

执行模块，用于在所述测试覆盖率满足预设测试条件时，结束软件测试。

9.一种软件测试设备，其特征在于，所述软件测试设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的软件测试程序，所述软件测试程序配置为实现如权利要求1至7中任一项所述的软件测试方法。

10.一种存储介质，其特征在于，所述存储介质上存储有软件测试程序，所述软件测试程序被处理器执行时实现如权利要求1至7任一项所述的软件测试方法。