CN113568839A - 软件测试和统计测试覆盖率的方法、装置、设备及介质 - Google Patents

Abstract

本公开涉及一种软件测试和统计测试覆盖率的方法、装置、设备及介质，上述软件测试的方法包括：获取差异代码，上述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码；对上述差异代码进行编译和插桩，得到带有探针的可执行文件，上述探针用于记录上述可执行文件中的字节码执行程序时所经历的轨迹信息；基于预设的测试用例，对上述可执行文件进行测试，并基于上述探针记录得到测试过程中上述字节码经历的轨迹信息；以及将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果。

Description

软件测试和统计测试覆盖率的方法、装置、设备及介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种软件测试和统计测试覆盖率的方法、装置、设备及介质。

背景技术

在软件的交付过程中，通过单元测试、功能测试、性能测试、兼容性测试、接口自动化测试等手段来保障软件质量。无论哪种测试方法，衡量测试用例设计是否精准和全面都很重要。目前，单元测试往往只有正常路径进行代码走查，功能测试无法覆盖到所有异常场景，漏测可能导致严重的生产故障。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下技术问题：相关技术中，大部分基于测试用例对目标软件的全量代码进行测试，从而得到针对目标软件的测试用例的测试覆盖率信息，进而根据测试覆盖率信息来衡量测试用例设计是否精准和全面，这种全量代码测试的方式，一方面存在测试效率低的问题，另一方面，针对各种类型的测试用例而言，测试的可靠性难以评估，无法确定测试用例是否覆盖了所有代码逻辑，例如功能测试通常采用黑盒测试方法，对于未覆盖到的代码逻辑会出现漏测情况；单元测试往往只有正常路径进行代码走查，也存在无法覆盖到所有代码逻辑的问题。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开的实施例提供了一种软件测试和统计测试覆盖率的方法、装置、设备及介质。

第一方面，本公开的实施例提供了一种软件测试的方法。上述软件测试的方法包括：获取差异代码，上述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码；对上述差异代码进行编译和插桩，得到带有探针的可执行文件，上述探针用于记录上述可执行文件中的字节码执行程序时所经历的轨迹信息；基于预设的测试用例，对上述可执行文件进行测试，并基于上述探针记录得到测试过程中上述字节码经历的轨迹信息；以及将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果。

根据本公开的实施例，将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果，包括：对字节码经历的轨迹信息解析，得到运行测试用例的过程中被覆盖到的候选源代码的信息，上述信息表征被执行的源代码的位置信息和对应执行的源代码内容；从上述候选源代码的信息中筛选出覆盖上述更新源代码的目标信息；根据上述目标信息确定被覆盖的更新源代码的数量；以及基于上述被覆盖的更新源代码的数量和上述更新源代码的结构进行对比，得到测试覆盖率。

根据本公开的实施例，上述对上述差异代码进行编译和插桩，得到带有探针的可执行文件，包括：基于测试用例的类型，确定上述可执行文件的插桩模式为线下插桩模式或运行时插桩模式；在上述插桩模式为线下插桩模式的情况下，在上述差异代码编译的过程中***探针，编译完成的带有探针的字节码结构构成上述带有探针的可执行文件；在上述插桩模式为运行时插桩模式的情况下，对上述差异代码进行编译后得到可执行文件；在测试环境部署并加载上述可执行文件的过程中，在上述可执行文件的字节码中***探针，从而得到带有探针的可执行文件。

根据本公开的实施例，上述基于测试用例的类型，确定上述可执行文件的插桩模式为线下插桩模式或运行时插桩模式，包括：在上述测试用例的类型为单元测试的情况下，确定上述可执行文件的插桩模式为线下插桩模式；在上述测试用例的类型为接口测试、功能测试、性能测试、兼容性测试或自动化测试的情况下，确定上述可执行文件的插桩模式为运行时插桩模式。

根据本公开的实施例，获取差异代码包括：接收用户输入的目标版本软件和历史版本软件的标识信息；根据上述标识信息定位至上述目标版本软件和历史版本软件；对上述目标版本软件和上述历史版本软件分别进行解析，得到关于上述目标版本软件的第一解析树和关于上述历史版本软件的第二解析树；以及对比分析上述第一解析树和上述第二解析树，得到上述目标版本软件相较于相较于上述历史版本软件新增或修改后的更新源代码，上述更新源代码为上述差异代码。

根据本公开的实施例，上述软件测试的方法还包括：根据上述差异代码的测试覆盖率结果来更新上述预设的测试用例，使得更新后的测试用例组合，对上述差异代码的测试覆盖率符合预设要求；其中，上述更新的方式包括：在预设的测试用例的基础上新增一个或多个测试用例，或者对预设的测试用例进行修改后得到修改后的测试用例，上述更新后的测试用例组合对应包括：预设的测试用例和新增的测试用例，或者修改后的测试用例。

第二方面，本公开的实施例提供了一种统计测试覆盖率的方法。上述统计测试覆盖率的方法包括：接收用户对全量测试或增量测试的选择信息；根据上述选择信息，基于测试覆盖率工具进行对应的代码测试，并输出对应的全量代码测试覆盖率报告或差异代码测试覆盖率报告；其中，在上述选择信息为增量测试的情况下，上述测试覆盖率工具通过执行如上所述的软件测试的方法进行代码测试，从而得到关于差异代码的测试覆盖率结果，并根据上述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告。

根据本公开的实施例，上述测试覆盖率工具的报告输出组件中设置有非必填参数；在用户选择增量测试的情况下，上述差异代码作为上述非必填参数传入至上述报告输出组件中，使得上述报告输出组件根据上述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告；在用户选择全量测试的情况下，上述非必填参数为空。

第三方面，本公开的实施例提供了一种用于软件测试的装置。上述用于软件测试的装置包括：差异代码获取模块、编译和插桩模块、测试模块和测试覆盖率分析模块。上述差异代码获取模块用于获取差异代码，上述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码。上述编译和插桩模块用于对上述差异代码进行编译和插桩，得到带有探针的可执行文件。上述探针用于记录上述可执行文件中的字节码执行程序时所经历的轨迹信息。上述测试模块用于基于预设的测试用例，对上述可执行文件进行测试，并基于上述探针记录得到测试过程中上述字节码经历的轨迹信息。上述测试覆盖率分析模块用于将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果。

上述用于软件测试的装置还包括：测试用例更新模块。上述测试用例更新模块用于根据上述差异代码的测试覆盖率结果来更新上述预设的测试用例，使得更新后的测试用例组合，对上述差异代码的测试覆盖率符合预设要求。其中，上述更新的方式包括：在预设的测试用例的基础上新增一个或多个测试用例，或者对预设的测试用例进行修改后得到修改后的测试用例，上述更新后的测试用例组合对应包括：预设的测试用例和新增的测试用例，或者修改后的测试用例。

第四方面，本公开的实施例提供了一种用于统计测试覆盖率的装置。上述用于统计测试覆盖率的装置包括：信息接收模块和测试覆盖率工具。上述信息接收模块用于接收用户对全量测试或增量测试的选择信息。上述测试覆盖率工具用于根据上述选择信息进行对应的代码测试，并输出对应的全量代码测试覆盖率报告或差异代码测试覆盖率报告。其中，在上述选择信息为增量测试的情况下，上述测试覆盖率工具用于执行如上所述的软件测试的方法来进行代码测试，从而得到关于差异代码的测试覆盖率结果，并用于根据上述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告。

第五方面，本公开的实施例提供了一种电子设备。上述电子设备包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现如上所述的软件测试的方法或者统计测试覆盖率的方法。

第六方面，本公开的实施例提供了一种计算机可读存储介质。上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时实现如上所述的软件测试的方法或者统计测试覆盖率的方法。

本公开实施例提供的上述技术方案与现有技术相比至少具有如下优点的部分或全部：

通过对差异代码进行编译和插桩，得到包含探针的可执行文件，基于预设的测试用例对可执行文件进行测试，测试过程中能够基于探针可执行文件中的字节码经历的轨迹信息，通过将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，能够得到关于上述差异代码的测试覆盖率结果，由此能确定预设的测试用例对于新增和/或修改的更新源代码这一部分的覆盖情况，后续可以针对更新源代码中未完全被覆盖的逻辑补充相应的测试用例，能够提升软件的测试效率，并能够提升评估测试覆盖程度的可靠性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1A示意性示出了适用于本公开实施例的软件测试的方法和装置的一种示例性***架构；

图1B示意性示出了适用于本公开实施例的软件测试的方法和装置的另一种示例性***架构；

图2示意性示出了根据本公开一实施例的软件测试的方法的流程图；

图3示意性示出了根据本公开实施例的操作S201的详细实施流程图；

图4示意性示出了根据本公开实施例的操作S202的详细实施流程图；

图5示意性示出了根据本公开实施例的操作S204的详细实施流程图；

图6示意性示出了根据本公开另一实施例的软件测试的方法的流程图；

图7示意性示出了根据本公开实施例的统计测试覆盖率的方法的流程图；

图8示意性示出了根据本公开实施例的用于软件测试的装置的结构框图；

图9示意性示出了根据本公开实施例的用于统计测试覆盖率的装置的结构框图；以及

图10示意性示出了本公开实施例提供的电子设备的结构框图。

具体实施方式

目前行业内的常见开源工具(例如jacoco，一种开源的Java代码覆盖率工具)只支持全量代码的测试覆盖率采集。这种全量代码测试的方式，一方面存在测试效率低的问题，另一方面，针对各种类型的测试用例而言，测试的可靠性难以评估，无法确定测试用例是否覆盖了所有代码逻辑。

有鉴于此，本公开的实施例提供了一种软件测试和统计测试覆盖率的方法、装置、设备及介质。上述软件测试的方法包括：获取差异代码，上述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码；对上述差异代码进行编译和插桩，得到带有探针的可执行文件，上述探针用于记录上述可执行文件中的字节码执行程序时所经历的轨迹信息；基于预设的测试用例，对上述可执行文件进行测试，并基于上述探针记录得到测试过程中上述字节码经历的轨迹信息；以及将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果。

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

图1A示意性示出了适用于本公开实施例的软件测试的方法和装置的一种示例性***架构。图1B示意性示出了适用于本公开实施例的软件测试的方法和装置的另一种示例性***架构。

参照图1A所示，适用于本公开实施例的软件测试的方法和装置的一种示例性***架构100包括：终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户(例如为软件测试人员)可以使用终端设备101、102、103通过网络104与服务器105交互，以发送软件测试请求、接收对应的软件测试结果等。终端设备101、102、103上可以安装有软件开发***/工具。

终端设备101、102、103可以是具有显示屏并且能够支持网页浏览的各种电子设备，例如电子设备包括但不限于平板电脑、笔记本电脑、台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103开发得到的软件提供测试服务的服务器(仅为示例)。后台管理服务器可以对软件在测试过程中的记录数据进行分析和处理，并将处理结果(例如软件的测试结果等)反馈给终端设备。

参照图1B所示，适用于本公开实施例的软件测试的方法和装置的另一种示例性的分布式***架构110包括：网页端111、客户端112和部署于网页端111上的软件开发***(或者也可以称为软件开发平台)113。

网页端111可以是具有显示屏并且能够支持网页浏览的各种电子设备。

客户端112为与上述网页端111能够通过网络进行数据通信的设备，能够为网页端111提供分布式服务，例如可以是数据存储、数据处理等服务。

上述软件开发***113可以是DevOps平台(一种一站式软件研发管理平台)，通过负载均衡将流量分散至不同的网页端111和对应提供服务的一个或多个客户端112。

需要说明的是，本公开实施例所提供的软件测试的方法一般可以由服务器105执行，或者也可以由具有一定运算能力的客户端112执行，还可以由终端设备101、102、103在本地进行软件的测试。相应地，本公开实施例所提供的软件测试的装置一般可以设置于服务器105中，或上述具有一定运算能力的客户端112，或终端设备101、102、103上。本公开实施例所提供的软件测试的方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的软件测试的装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

本公开的第一个示例性实施例提供了一种软件测试的方法。

图2示意性示出了根据本公开一实施例的软件测试的方法的流程图。

参照图2所示，本公开实施例提供的软件测试的方法，包括以下操作：S201、S202、S203和S204。上述操作S201～S204可以由服务器105或者用于提供分布式服务(云服务)的客户端112执行，还可以在终端设备的本地执行。

在操作S201，获取差异代码，上述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码。

在操作S202，对上述差异代码进行编译和插桩，得到带有探针的可执行文件，上述探针用于记录上述可执行文件中的字节码执行程序时所经历的轨迹信息。

在操作S203，基于预设的测试用例，对上述可执行文件进行测试，并基于上述探针记录得到测试过程中上述字节码经历的轨迹信息。

在操作S204，将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果。

源代码是用特定编程语言编写的人类可读文本，源代码的目标是为可以转换为机器语言的计算机设置准确的规则和规范。因此，源代码是程序和网站的基础。源代码可以存在于每个软件中，软件按照源代码中的编程进行执行，常用的格式是文本文件。

每次软件开发或升级是在历史版本软件上进行更新，不同版本或不同分支的软件代码之间存在差异。

在操作S201中，获取目标版本软件在历史版本软件的基础上进行更新的源代码，这些更新的源代码中具有：新增的源代码、被删除的源代码、被修改的源代码等类型，将新增和/或修改的源代码(将前后两个版本变化的源代码描述为更新源代码)作为差异代码。上述两个版本的软件的格式例如为带有后缀.java的文件。

在操作S202中，差异代码是源代码形式，通过对差异代码进行编译和插桩，可以得到带有探针的可执行文件，例如.java源代码经过编译后得到带有后缀.class的文件，带有后缀.class的文件是由字节码构成的，在源代码对应的字节码中添加有监测功能的探针。Java class文件是可以运行在任何支持Java虚拟机的硬件平台和操作***上的二进制文件。

在操作S203中，预设的测试用例是用于针对历史版本软件和目标版本软件进行测试的测试用例。根据实际软件测试的需求，预先设置相应的测试用例。测试用例可以是单元测试、接口测试、功能测试、性能测试、兼容性测试或自动化测试中的一种或多种的组合。

在操作S204中，将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果。

测试覆盖率是对测试完成程度的度量，它通常依据某种覆盖准则来对测试用例执行情况进行衡量，以判断测试执行得是否充分。具体而言，测试覆盖率可以表征测试用例是否真正完全覆盖了应用程序代码中的各种可能以及在运行这些测试用例时执行了多少代码。

例如可以通过对字节码经历的轨迹信息解析，得到运行测试用例的过程中被覆盖到的候选源代码的信息，该信息实际上表征执行了哪些行的哪些源代码，即，表征被执行的源代码的位置信息和对应执行的源代码内容。这些候选源代码涵盖差异代码中的代码和目标版本软件中除差异代码之外的其他代码，在差异代码的测试覆盖率结果中只关注覆盖差异代码(即上述更新源代码)的那部分信息。因此，后续从上述候选源代码的信息中筛选出覆盖差异代码的目标信息；根据上述覆盖差异代码的目标信息确定被覆盖的差异代码的数量；基于上述被覆盖的差异代码的数量和上述更新源代码的结构进行对比，得到测试覆盖率。

基于上述操作S201～S204，通过对差异代码进行编译和插桩，得到包含探针的可执行文件，基于预设的测试用例对可执行文件进行测试，测试过程中能够基于探针可执行文件中的字节码经历的轨迹信息，通过将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，能够得到关于上述差异代码的测试覆盖率结果，由此能确定预设的测试用例对于新增和/或修改的更新源代码这一部分的覆盖情况，后续可以针对更新源代码中未完全被覆盖的逻辑补充相应的测试用例，能够提升软件的测试效率，并能够提升评估测试覆盖程度的可靠性。

图3示意性示出了根据本公开实施例的操作S201的详细实施流程图。

根据本公开的实施例，参照图3所示，获取差异代码的操作S201包括以下子操作：S2011、S2012、S2013和S2014。

在子操作S2011，接收用户输入的目标版本软件和历史版本软件的标识信息。

这里的用户可以是具有软件测试需求的人员，例如为软件测试人员。上述标识信息包括：仓库地址和代码分支版本号，或者事务提交ID(commitId)。例如，上述目标版本软件和历史版本软件可以存储于数据库中，通过根据标识信息来实现对数据库中的目标版本软件和历史版本软件的定位和获取。

在子操作S2012，根据上述标识信息定位至上述目标版本软件和历史版本软件。

在子操作S2013，对上述目标版本软件和上述历史版本软件分别进行解析，得到关于上述目标版本软件的第一解析树和关于上述历史版本软件的第二解析树。

在子操作S2014，对比分析上述第一解析树和上述第二解析树，得到上述目标版本软件相较于相较于上述历史版本软件新增或修改后的更新源代码，上述更新源代码为上述差异代码。

示例性的，可以基于版本控制***来实施上述子操作S2011～S2014，版本控制***可以是Git(一种分布式版本控制***)或SVN(Subversion的简称，是一个开放源代码的版本控制***)。

JGit是一个用于操作git的Java库，支持使用代码操作git获得指定分支和master之间的差异。示例性的，在编码语言为java形式的情况下，可以通过JGit来实现子操作S2011～S2014。org.eclipse.jgit主要用于从git获取代码，并获取到存在变更的文件。javaparser-core是一个java解析类，能将class类文件解析成树状，方便去获取差异类，从而得到差异代码。

图4示意性示出了根据本公开实施例的操作S202的详细实施流程图。

根据本公开的实施例，参照图4所示，上述对上述差异代码进行编译和插桩，得到带有探针的可执行文件的操作S202，包括以下子操作：S2021、S2022a、S2022b和S2023b。

在子操作S2021，基于测试用例的类型，确定上述可执行文件的插桩模式为线下插桩模式或运行时插桩模式。

在子操作S2022a，在上述插桩模式为线下插桩模式(offline)的情况下，在上述差异代码编译的过程中***探针，编译完成的带有探针的字节码结构构成上述带有探针的可执行文件。

在子操作S2022b，在上述插桩模式为运行时插桩模式(on-the-fly)的情况下，对上述差异代码进行编译后得到可执行文件。

在子操作S2023b，在测试环境部署并加载上述可执行文件的过程中，在上述可执行文件的字节码中***探针，从而得到带有探针的可执行文件。

根据本公开的实施例，上述基于测试用例的类型，确定上述可执行文件的插桩模式为线下插桩模式或运行时插桩模式，包括：在上述测试用例的类型为单元测试的情况下，确定上述可执行文件的插桩模式为线下插桩模式；在上述测试用例的类型为接口测试、功能测试、性能测试、兼容性测试或自动化测试的情况下，确定上述可执行文件的插桩模式为运行时插桩模式。

接口测试是在测试***组件间接口的一种测试。接口测试主要是用于检测外部***与***之间以及内部各个子***之间的交互点。测试的重点主要是要检查数据的交换，传递和控制管理过程，以及***间的相互逻辑依赖关系等。

功能测试(Functional testing)，也称为行为测试(behavioral testing)，根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对***的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下***的性能，目标是测试当负载逐渐增加时，***各项性能指标的变化情况。压力测试是通过确定一个***的瓶颈或者不能接收的性能点，来获得***能提供的最大服务级别的测试。应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。

软件兼容性测试是指检查软件之间能否正确地进行交互和共享信息。随着用户对来自各种类型软件之间共享数据能力和充分利用空间同时执行多个程序能力的要求，测试软件之间能否协作变得越来越重要。软件兼容性测试工作的目标是保证软件按照用户期望的方式进行交互。兼容性通常有四种：向前兼容与向后兼容、不同版本间的兼容、标准和规范、数据共享兼容。

自动化测试是指利用自动化测试工具(相当于软件开发工具)，经过对测试需求的分析(软件过程中的需求分析)，设计出自动化测试用例(软件过程中的需求规格),从而搭建自动化测试的框架(软件过程中的概要设计)，设计与编写自动化脚本(详细设计与编码)，测试脚本的正确性，从而完成该套测试脚本(即主要功能为测试的应用软件)。

自动化测试的测试类型可以包括：白盒测试、黑盒测试等。不同的测试类型使用的自动化测试方法不同，白盒测试主要针对代码级的单元测试，黑盒测试主要面对功能级和***级的验证测试。

根据不同的测试用例类型确定对应的插桩模式，进而在不同的时机进行探针的注入操作。以测试覆盖率工具Jacoco为例，其同时支持on-the-fly和offline的两种插桩模式。On-the-fly模式中，Java虚拟机(JVM)中通过-javaagent参数指定特定的jar文件启动Instrumentation(Instrumentation是Java提供的一个来自JVM的接口，该接口提供了一系列查看和操作Java类定义的方法，例如修改类的字节码、向classLoader的classpath下加入jar文件等。使得开发者可以通过Java语言来操作和监控JVM内部的一些状态，进而实现Java程序的监控分析，甚至实现一些特殊功能(如AOP、热部署))的代理程序，代理程序在通过Class Loader装载一个class前判断是否转换修改class文件，将统计代码(探针)***class，测试覆盖率分析可以在JVM执行测试代码的过程中完成。

offline模式中，在测试前先对文件进行插桩，然后生成插过桩的class或jar包，测试插过桩的class和jar包后，会生成动态覆盖信息到文件，最后统一对覆盖信息进行处理，并生成报告。

图5示意性示出了根据本公开实施例的操作S204的详细实施流程图。

根据本公开的实施例，参照图5所示，将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果的操作S204，包括以下子操作：S2041、S2042、S2043和S2044。

在子操作S2041，对字节码经历的轨迹信息解析，得到运行测试用例的过程中被覆盖到的候选源代码的信息，上述信息表征被执行的源代码的位置信息和对应执行的源代码内容。

在子操作S2042，从上述候选源代码的信息中筛选出覆盖上述更新源代码的目标信息。

在子操作S2043，根据上述目标信息确定被覆盖的更新源代码的数量。

在子操作S2044，基于上述被覆盖的更新源代码的数量和上述更新源代码的结构进行对比，得到测试覆盖率。

基于上述子操作S2041～S2044，能够快速定位至覆盖上述更新源代码的目标信息，并得到预设的测试用例对于上述差异代码的测试覆盖程度。

图6示意性示出了根据本公开另一实施例的软件测试的方法的流程图。

参照图6所示，本公开实施例提供的软件测试的方法除了包括上述操作S201～S204之外，还包括操作S601：根据上述差异代码的测试覆盖率结果来更新上述预设的测试用例，使得更新后的测试用例组合，对上述差异代码的测试覆盖率符合预设要求。上述操作S601和操作S201～S204可以是构成多个迭代循环过程，在一次迭代过程中，操作S201～S204执行之后执行一次更新测试用例的操作；然后再基于更新后的测试用例组合作为预设的测试用例，进行下一次迭代。

其中，上述更新的方式包括：在预设的测试用例的基础上新增一个或多个测试用例，或者对预设的测试用例进行修改后得到修改后的测试用例，上述更新后的测试用例组合对应包括：预设的测试用例和新增的测试用例，或者修改后的测试用例。

在一实施例中，采用新增测试用例的方式来进行更新。上述操作S601包括：根据上述差异代码的测试覆盖率结果确定上述更新源代码(差异代码)中未被覆盖到的更新源代码；构建关于上述未被覆盖到的更新源代码的新增测试用例；验证上述新增测试用例对上述未被覆盖到的更新源代码的测试覆盖率是否符合预设要求；在不符合预设要求的情况下，继续构建新增测试用例，直至验证结果符合预设要求。

在另一实施例中，采用修改原有测试用例的方式来进行更新。上述操作S601包括：根据上述差异代码的测试覆盖率结果确定上述更新源代码(差异代码)中未被覆盖到的更新源代码；构建更改测试用例；验证上述更改测试用例对上述未被覆盖到的更新源代码和已被覆盖的更新源代码的测试覆盖率是否符合预设要求；在不符合预设要求的情况下，继续构建更改测试用例，直至验证结果符合预设要求。在修改原有测试用例的场景下，原先的覆盖情况可能会发生变化，因此需要同时验证更改测试用例针对所有的更新源代码的实际覆盖情况。

本公开的第二个示例性实施例提供了一种统计测试覆盖率的方法。

图7示意性示出了根据本公开实施例的统计测试覆盖率的方法的流程图。

参照图7所示，本公开实施例提供的统计测试覆盖率的方法，包括以下操作：S701、S702。

在操作S701，接收用户对全量测试或增量测试的选择信息。

在操作S702，根据上述选择信息，基于测试覆盖率工具进行对应的代码测试，并输出对应的全量代码测试覆盖率报告或差异代码测试覆盖率报告。

上述操作S702包含两个并列的分支：操作S702a和S702b。

其中，在操作S702a，在上述选择信息为增量测试的情况下，上述测试覆盖率工具通过执行如上所述的软件测试的方法进行代码测试，从而得到关于差异代码的测试覆盖率结果，并根据上述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告。

在操作S702b，在上述选择信息为全量测试的情况下，上述测试覆盖率工具进行全量代码测试，从而得到关于全量代码的测试覆盖率结果，并根据上述全量代码的测试覆盖率结果来生成差异代码测试覆盖率报告。

根据本公开的实施例，上述测试覆盖率工具的报告输出组件中设置有非必填参数；在用户选择增量测试的情况下，上述差异代码作为上述非必填参数传入至上述报告输出组件中，使得上述报告输出组件根据上述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告；在用户选择全量测试的情况下，上述非必填参数为空。

上述报告为可视化形式，其文件格式为：html、xml等。

通过二次开发的Jacoco生成差异代码测试覆盖率报告，关于Jacoco二次开发改造逻辑如下：在report(报告输出)阶段增加非必填参数(对应于测试覆盖率工具的报告输出组件中设置有非必填参数)，用来接收差异代码的内容，不传入该参数时，默认计算全量代码覆盖率，并输出全量代码测试覆盖率报告；传入参数时则计算的是差异代码覆盖率，输出差异代码测试覆盖率报告，测试和输出结果的灵活性较高。

本公开的实施例中，以采用运行时插桩模式(on-the-fly)为例，部署应用服务时，在启动脚本中增加-javaagent参数，启动脚本starup.sh中增加的指针的参数形式例如为：

-javaagent:/tmp/jacoco/lib/jacocoagent.jar＝include＝*,output＝tcpserver,port＝6600,add ress＝*,append＝true。

启动测试，运行/执行单元测试、接口测试、功能测试、性能测试、兼容性测试等对应测试用例。预先配置好插桩模式与对应测试用例的类型，针对性进行指针***/注入。

在测试完成后，进行导出操作。例如通过执行dump命令生成特定协议格式的文件，例如为exec文件，导出的命令行示例如下：java-jar jacococli.jar dump–addresslocalhost–port 6600–destfile./jacoco-demo.exec。在一实施例中，可以是在服务端进行测试后将测试结果导出至本地，以jacoco(一种开源的Java代码覆盖率工具)作为代码覆盖率工具为例，导出的方式可以是通过执行dump命令生成exec文件。或者，在另一实施例中，直接在本地执行测试。

对于全量代码的测试覆盖率，直接通过调用原生jacoco的全量代码测试覆盖率结果生成测试报告。

对于差异代码的测试覆盖率，需要先计算差异代码，通过实施上述操作S201可以获取到差异代码。

后续可以基于差异代码测试覆盖率报告中的颜色标记，分析出未执行或未完全执行的代码逻辑，并对应补充相应的测试用例(对应于第一实施例中的操作S601)。

本公开的第三个示例性实施例提供了一种用于软件测试的装置。

图8示意性示出了根据本公开实施例的用于软件测试的装置的结构框图。

参照图8所示，本公开实施例提供的用于软件测试的装置800包括：差异代码获取模块801、编译和插桩模块802、测试模块803和测试覆盖率分析模块804。

上述差异代码获取模块801用于获取差异代码，上述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码。上述差异代码获取模块801包含用于实现上述子操作S2011～S2014的功能模块或子模块。

上述编译和插桩模块802用于对上述差异代码进行编译和插桩，得到带有探针的可执行文件。上述探针用于记录上述可执行文件中的字节码执行程序时所经历的轨迹信息。上述编译和插桩模块802包含用于实现上述子操作S2021、S2022a、S2022b和S2023b的功能模块或子模块。

上述测试模块803用于基于预设的测试用例，对上述可执行文件进行测试，并基于上述探针记录得到测试过程中上述字节码经历的轨迹信息。

上述测试覆盖率分析模块804用于将上述字节码经历的轨迹信息与上述更新源代码的结构进行对比分析，得到关于上述差异代码的测试覆盖率结果。上述测试覆盖率分析模块804包含用于实现子操作S2041～S2044的功能模块或子模块。

根据本公开的实施例，上述用于软件测试的装置800还包括：测试用例更新模块。上述测试用例更新模块用于根据上述差异代码的测试覆盖率结果来更新上述预设的测试用例，使得更新后的测试用例组合，对上述差异代码的测试覆盖率符合预设要求。其中，上述更新的方式包括：在预设的测试用例的基础上新增一个或多个测试用例，或者对预设的测试用例进行修改后得到修改后的测试用例，上述更新后的测试用例组合对应包括：预设的测试用例和新增的测试用例，或者修改后的测试用例。如何更新的过程可以参照第一个实施例的描述。

本公开的第四个示例性实施例提供了一种用于统计测试覆盖率的装置。

图9示意性示出了根据本公开实施例的用于统计测试覆盖率的装置的结构框图。

参照图9所示，本公开实施例提供的用于统计测试覆盖率的装置900包括：信息接收模块901和测试覆盖率工具902。

上述信息接收模块901用于接收用户对全量测试或增量测试的选择信息。

上述测试覆盖率工具902用于根据上述选择信息进行对应的代码测试，并输出对应的全量代码测试覆盖率报告或差异代码测试覆盖率报告。其中，在上述选择信息为增量测试的情况下，上述测试覆盖率工具用于执行如上所述的软件测试的方法来进行代码测试，从而得到关于差异代码的测试覆盖率结果，并用于根据上述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告。具体而言，参照图9所示，上述测试覆盖率工具902包含能够实施上述操作S201～S204对应的功能模块或子模块：差异代码获取模块9021、编译和插桩模块9022、测试模块9023和测试覆盖率分析模块9024。除此之外，还可以进一步包括用于实施操作S601的功能模块或子模块：测试用例更新模块。

上述测试覆盖率工具902用于在上述选择信息为全量测试的情况下，进行全量代码测试，从而得到关于全量代码的测试覆盖率结果，并根据上述全量代码的测试覆盖率结果来生成差异代码测试覆盖率报告。

本实施例中，上述装置900可以是对应于图1B所示的分布式***架构110。示例性的，网页端111(前端)采用Vue框架，通过npm run build命令进行打包部署。客户端(服务端)112为Springboot框架，数据库使用Mysql库，通过maven install命令对工程进行构建编译，部署时启动jar(Java ARchive，一种跨平台的软件包文件格式)包即可。

测试覆盖率工具902可以安装于网页端111，可以根据流量分配至对应服务的客户端112进行测试数据处理，以得到关于差异代码的测试覆盖率结果。

上述第三个实施例中，差异代码获取模块801、编译和插桩模块802、测试模块803和测试覆盖率分析模块804中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。差异代码获取模块801、编译和插桩模块802、测试模块803和测试覆盖率分析模块804中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，差异代码获取模块801、编译和插桩模块802、测试模块803和测试覆盖率分析模块804中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

上述第四个实施例中，信息接收模块901、差异代码获取模块9021、编译和插桩模块9022、测试模块9023和测试覆盖率分析模块9024中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。信息接收模块901、差异代码获取模块9021、编译和插桩模块9022、测试模块9023和测试覆盖率分析模块9024中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，信息接收模块901、差异代码获取模块9021、编译和插桩模块9022、测试模块9023和测试覆盖率分析模块9024中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

本公开的第五个示例性实施例提供了一种电子设备。

图10示意性示出了本公开实施例提供的电子设备的结构框图。

参照图10所示，本公开实施例提供的电子设备1000包括处理器1001、通信接口1002、存储器1003和通信总线1004，其中，处理器1001、通信接口1002和存储器1003通过通信总线1004完成相互间的通信；存储器1003，用于存放计算机程序；处理器1001，用于执行存储器上所存放的程序时，实现如上所述的软件测试的方法或者统计测试覆盖率的方法。

本公开的第六个示例性实施例还提供了一种计算机可读存储介质。上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时实现如上所述的软件测试的方法或者统计测试覆盖率的方法。

该计算机可读存储介质可以是上述实施例中描述的设备/装置中所包含的；也可以是单独存在，而未装配入该设备/装置中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

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

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims (12)

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

获取差异代码，所述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码；

对所述差异代码进行编译和插桩，得到带有探针的可执行文件，所述探针用于记录所述可执行文件中的字节码执行程序时所经历的轨迹信息；

基于预设的测试用例，对所述可执行文件进行测试，并基于所述探针记录得到测试过程中所述字节码经历的轨迹信息；以及

将所述字节码经历的轨迹信息与所述更新源代码的结构进行对比分析，得到关于所述差异代码的测试覆盖率结果。

2.根据权利要求1所述的方法，其特征在于，将所述字节码经历的轨迹信息与所述更新源代码的结构进行对比分析，得到关于所述差异代码的测试覆盖率结果，包括：

对字节码经历的轨迹信息解析，得到运行测试用例的过程中被覆盖到的候选源代码的信息，所述信息表征被执行的源代码的位置信息和对应执行的源代码内容；

从所述候选源代码的信息中筛选出覆盖所述更新源代码的目标信息；

根据所述目标信息确定被覆盖的更新源代码的数量；以及

基于所述被覆盖的更新源代码的数量和所述更新源代码的结构进行对比，得到测试覆盖率。

3.根据权利要求1所述的方法，其特征在于，所述对所述差异代码进行编译和插桩，得到带有探针的可执行文件，包括：

基于测试用例的类型，确定所述可执行文件的插桩模式为线下插桩模式或运行时插桩模式；

在所述插桩模式为线下插桩模式的情况下，在所述差异代码编译的过程中***探针，编译完成的带有探针的字节码结构构成所述带有探针的可执行文件；

在所述插桩模式为运行时插桩模式的情况下，对所述差异代码进行编译后得到可执行文件；在测试环境部署并加载所述可执行文件的过程中，在所述可执行文件的字节码中***探针，从而得到带有探针的可执行文件。

4.根据权利要求3所述的方法，其特征在于，所述基于测试用例的类型，确定所述可执行文件的插桩模式为线下插桩模式或运行时插桩模式，包括：

在所述测试用例的类型为单元测试的情况下，确定所述可执行文件的插桩模式为线下插桩模式；

在所述测试用例的类型为接口测试、功能测试、性能测试、兼容性测试或自动化测试的情况下，确定所述可执行文件的插桩模式为运行时插桩模式。

5.根据权利要求1所述的方法，其特征在于，所述获取差异代码，包括：

接收用户输入的目标版本软件和历史版本软件的标识信息；

根据所述标识信息定位至所述目标版本软件和历史版本软件；

对所述目标版本软件和所述历史版本软件分别进行解析，得到关于所述目标版本软件的第一解析树和关于所述历史版本软件的第二解析树；以及

对比分析所述第一解析树和所述第二解析树，得到所述目标版本软件相较于相较于所述历史版本软件新增或修改后的更新源代码，所述更新源代码为所述差异代码。

6.根据权利要求1-5中任一项所述的方法，其特征在于，还包括：

根据所述差异代码的测试覆盖率结果来更新所述预设的测试用例，使得更新后的测试用例组合，对所述差异代码的测试覆盖率符合预设要求；

其中，所述更新的方式包括：在预设的测试用例的基础上新增一个或多个测试用例，或者对预设的测试用例进行修改后得到修改后的测试用例，所述更新后的测试用例组合对应包括：预设的测试用例和新增的测试用例，或者修改后的测试用例。

7.一种统计测试覆盖率的方法，其特征在于，包括：

接收用户对全量测试或增量测试的选择信息；

根据所述选择信息，基于测试覆盖率工具进行对应的代码测试，并输出对应的全量代码测试覆盖率报告或差异代码测试覆盖率报告；

其中，在所述选择信息为增量测试的情况下，所述测试覆盖率工具通过执行权利要求1-5中任一项所述的方法进行代码测试，从而得到关于差异代码的测试覆盖率结果，并根据所述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告。

8.根据权利要求7所述的方法，其特征在于，所述测试覆盖率工具的报告输出组件中设置有非必填参数；

在用户选择增量测试的情况下，所述差异代码作为所述非必填参数传入至所述报告输出组件中，使得所述报告输出组件根据所述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告；

在用户选择全量测试的情况下，所述非必填参数为空。

9.一种用于软件测试的装置，其特征在于，包括：

差异代码获取模块，用于获取差异代码，所述差异代码为目标版本软件相较于历史版本软件新增和/或修改的更新源代码；

编译和插桩模块，用于对所述差异代码进行编译和插桩，得到带有探针的可执行文件，所述探针用于记录所述可执行文件中的字节码执行程序时所经历的轨迹信息；

测试模块，用于基于预设的测试用例，对所述可执行文件进行测试，并基于所述探针记录得到测试过程中所述字节码经历的轨迹信息；以及

测试覆盖率分析模块，用于将所述字节码经历的轨迹信息与所述更新源代码的结构进行对比分析，得到关于所述差异代码的测试覆盖率结果。

10.一种用于统计测试覆盖率的装置，其特征在于，包括：

信息接收模块，用于接收用户对全量测试或增量测试的选择信息；

测试覆盖率工具，用于根据所述选择信息进行对应的代码测试，并输出对应的全量代码测试覆盖率报告或差异代码测试覆盖率报告；

其中，在所述选择信息为增量测试的情况下，所述测试覆盖率工具用于执行权利要求1-5中任一项所述的方法来进行代码测试，从而得到关于差异代码的测试覆盖率结果，并用于根据所述差异代码的测试覆盖率结果来生成差异代码测试覆盖率报告。

11.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现权利要求1-8中任一项所述的方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-8中任一项所述的方法。

Images