CN109426604A - 代码开发的监控方法及设备 - Google Patents

Abstract

本申请提供了一种代码开发的监控方案，该方案通过获取变更代码以及代码基线，来对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息，然后与对所述代码基线进行覆盖测试确定的代码覆盖基线信息进行对比，确定变更代码对应的代码覆盖变化信息，将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户，使得用户可以确定本次代码变更所引起的代码覆盖变化情况，例如哪些代码在本次代码变更后被覆盖，哪些代码在本次代码变更后覆盖丢失等，由此可以便于用户在开发过程中获知代码的开发情况，更加细粒度了解代码覆盖的相关情况，连续监控代码覆盖的增量式变化。

Description

代码开发的监控方法及设备

技术领域

本申请涉及信息技术领域，尤其涉及一种代码开发的监控方法及设备。

背景技术

代码覆盖(Code Coverage)，是代码评审(Code Review)中度量代码质量的一个关键指标，它通常是由专门的代码集成测试工具生成。以Java语言为例，目前流行的测试工具通常是JUnit、Cobertura、Emma或Clover等代码覆盖测试工具。

行覆盖是代码覆盖的一种类型，也叫做语句覆盖，是指出代码的哪些行被执行。如果一个代码库包含10000个非注释性的代码行，在特定的测试运行中有3500行被执行，那么这段代码的行覆盖率就是35％。此外，有些代码覆盖测试工具也会报告分支覆盖。分支覆盖，试图度量决策点(比如包含逻辑AND或OR的条件块)的覆盖率。与行覆盖一样，如果在特定代码中包含两个分支，并且两个分支在测试中都被覆盖，那么这段代码有100％的分支覆盖率。

通过监控代码覆盖(比如生成代码覆盖报告)来保证代码质量是一项极其重要的实践。尤其是对于已经存在的软件项目，结合单元测试、函数测试、回归测试等测试集合，代码覆盖度量可以增加代码质量度量的深度和精度。尽管代码的高覆盖率并不是减少缺陷的必要条件，但是实践表明高覆盖率的代码的确具有更少的缺陷。在软件的持续集成开发过程中，用户若能够实时监控代码提交对代码覆盖的影响，能够为后续代码的修改提供参考，在一定程度上提升后续的代码质量。

现有的方案中主要侧重于提供全局的、最终的代码覆盖度量，例如直接给出整体的代码覆盖率，无法对每次新的代码变更所引起的代码覆盖变化情况进行增量式的度量，也无法对过去一段时间内的代码覆盖变化提供灵活可定制的查询。因此，现有的技术无法满足用户在大型软件的持续集成开发过程中对于代码覆盖变化情况的监控需求。

申请内容

本申请的一个目的是提供一种代码开发的监控方法及设备，用以解决现有技术中无法满足用户在大型软件的持续集成开发过程中对于代码覆盖变化情况的监控需求的问题。

为实现上述目的，本申请提供了一种代码开发的监控方法，该方法包括：

获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码；

对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息；

将所述代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，所述代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息；

将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户。

基于本申请的另一方面，还提供了一种代码开发的监控设备，该设备包括：

获取装置，用于获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码；

覆盖检测装置，用于对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息，以及将所述代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，所述代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息；

报告生成装置，用于将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户。

此外，本申请还提供了一种代码开发的监控设备，该设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码；对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息；将所述代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，所述代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息；将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户。

本申请提供的方案中，通过获取变更代码以及代码基线，来对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息，然后与对所述代码基线进行覆盖测试确定的代码覆盖基线信息进行对比，确定变更代码对应的代码覆盖变化信息，将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户，使得用户可以确定本次代码变更所引起的代码覆盖变化情况，例如哪些代码在本次代码变更后被覆盖，哪些代码在本次代码变更后覆盖丢失等，由此可以便于用户在开发过程中获知代码的开发情况，更加细粒度了解代码覆盖的相关情况，连续监控代码覆盖的增量式变化。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为目前的软件持续集成框架中代码管理的周期示意图；

图2为本申请实施例提供的代码开发的监控方案中代码基线和报告基线对应关系的示意图；

图3为本申请实施例提供的方案中提交了多次代码变更之后整体代码的代码覆盖率的变化情况图；

图4为本申请实施例提供的方案中关于增量代码的代码覆盖率示意图；

图5为本申请实施例提供的方案中关于代码行数变化值的示意图；

图6为在代码开发过程中使用本申请实施例提供的代码开发的监控方案后的工作流程；

图7为本申请实施例提供的一种代码开发的监控设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种代码开发的监控方法，该方法用于在软件开发过程中对软件代码的覆盖情况进行持续监控，从而为代码检测和评审提供数据支持。在软件的持续集成开发过程中，代码的高覆盖率并不是减少缺陷的必要条件，但是实践表明高覆盖率的代码的确具有更少的缺陷，因此用户若能够实时监控代码提交对代码覆盖的影响，能够为后续代码的修改提供参考，在一定程度上提升后续的代码质量。在目前主流的软件持续集成框架中，代码管理的周期如图1所示，大致包括以下三个阶段：

1.编码和提交阶段。完成编码并提交代码变更，在团队协作中，可以基于Git或其他SCM(Software configuration management，软件配置管理)系统。

2.检测和评审阶段。团队协作中完成代码检测，编译测试以及代码评审。

3.发布部署阶段。完成代码的发布和部署。

本申请实施例中提供的方法可以应用于上述的代码管理周期中的第2个阶段，可以基于该方法的处理结果进行代码评审和质量度量。

该方法首先获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码。根据获取到的变更代码和代码基线，可以确定变更后的整体代码。其中，变更代码是指在软件开发过程中用户提交代码变(pull request，PR)的变更内容，代码变更是指在软件开发中开发人员通过若干代码提交(commits)来完成一个功能点，并将功能点对应的代码申请合并进入一个分支的过程。

每一次代码变更的变更内容包括包括新增代码、删除代码和修改代码三种情况中的一种或者几种，其中，对于修改代码的情况，在实际场景中可以理解为先删除代码、后新增代码的组合情况。基于代码基线和变更代码可以确定变更后的整体代码(即更新后的代码)，而每一次提交代码变更后的整体代码也可以作为下一次代码变更的代码基线。

例如在本申请的一种实施例中，代码基线包含100行代码，变更代码的内容可以是新增了10行代码、删除了20行代码或者对其中30行代码进行了修改，并修改为35行代码。对于每一次的代码变更可以建立代码库，保存每一次变更代码的内容，例如可以利用Git进行管理，保存的每一次的代码变更。以前述的代码变更为例，若新增了10行代码，代码库中保存的内容可以是其相对于代码基线的变化情况，例如提交代码变更后的整体代码中第91至100行为新增的10行代码，101至110行为原代码中的第91至100行内容。而每一次代码变更都会生成一个标识信息，实际场景中可以使用commit ID或者PR ID来对每一次代码变更进行记录。

在确定变更后的整体代码之后，对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息。代码覆盖信息可以采用不同类型的代码覆盖进行评价，例如行覆盖、分支覆盖等。以前述新的整体代码为例，对于110行的代码，若采用行覆盖对其代码覆盖情况进行评价，其代码覆盖情况可以是第1至65行以及76至110行被覆盖，第66至75行未被覆盖。

其后，将代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息。代码覆盖变化信息能够用于表示在代码更变的过程中关于代码覆盖的变化情况，例如，对于前述的110行代码，其初始代码为100的代码，若初始代码的整体代码覆盖报告(即报告基线)中其代码覆盖情况为：第1至90行被覆盖，第91至100行未被覆盖，由于初始代码中的91至100行即为新代码中的101至110行内容，则相应的代码覆盖变化情况可以是变更内容中的增量代码(即91～100行)被覆盖，第66至75行覆盖丢失(代码覆盖情况由覆盖变为未覆盖)，第101至110行覆盖新增(代码覆盖情况由未覆盖变为覆盖)。通过上述方式，可以确定本次代码变更所引起的代码覆盖变化情况，例如哪些代码在本次代码变更后被覆盖，哪些代码在本次代码变更后覆盖丢失等。

在确定代码覆盖变化信息之后，将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户，由此可以使得用户更加细粒度了解代码覆盖的相关情况，连续监控代码覆盖的增量式变化。在本申请的一个实施例中，还可以将对变更后的整体代码进行代码覆盖测试确定的代码覆盖信息加入到代码覆盖变化报告中，由此用户在获取代码覆盖变化报告时，可以同时获知关于变更后的整体代码的代码覆盖信息，使得用户能够更加了解代码开发过程中的代码覆盖情况。

在实际场景中，用户每一次提交的代码变更都会有相应的commit ID或者PR ID来作为变更代码的标识信息，由此，对于生成的所述代码覆盖变化报告，可以将其保存，例如可以设定一报告库，作为用于存放上述完整代码覆盖报告和增量代码覆盖报告的数据库，并使用每一次代码变更的标识信息对其进行标记，由此建立代码变更和代码覆盖变化报告的对应关系，使得代码基线可以与报告基线保持对应，便于用户根据标识信息提取相应的报告，了解代码覆盖变化情况。图2示出了代码基线和报告基线对应关系的示意图，通过commit ID作为代码变更的标识信息对代码和覆盖报告进行标记，建立其对应的关系。

在本申请的实施例中，向用户提供代码覆盖变化报告时，可以基于用户的查询需求，该查询需求可以根据实际场景中用户对于代码覆盖变化情况的监控需求来确定。例如，查询需求可以规定每一次提交代码变更后都生成代码覆盖变化报告，并提供给用户，便于用户实时获知每一次代码变更的提交对于整体代码的影响。

此外，查询需求也可以携带本次查询的标识信息，通过本次查询的标识信息在保存的所述代码覆盖变化报告中，确定本次查询对应的代码覆盖变化报告，从而实现定制化的监控。当用户需要查询某一次代码变更后的代码覆盖变化报告时，可以通过一定的筛选方式输入待查询的标识信息。例如通过输入时间这一筛选条件确定某一时间之前最近一次的代码变更的标识信息，或者也可以根据代码的版本号确定该次代码变更的标识信息，此外还可以根据代码变更的贡献者(Commitor)，确定该贡献者的所提交的代码变更的标识信息。

在实际场景中，通过查询不同的标识信息，本申请实施例提供的方法可以有以下应用：

1、每次提交代码变更(PR)后生成关于代码覆盖率的报告，用于代码评审。在每次提交代码变更之后，用户可以收到本次代码变更所对应的代码监控报告，该报告可以发布在代码评审页面，或者嵌入到相关工具和插件中，让参与人员方便获得，从而便于进行代码评审。

2、查询两次代码变更之间的代码覆盖率变化。通过提交代码变更以后对应的Commit ID查询相应的代码监控报告，由此可以方便的比较两次代码变更产生的覆盖率差异，作为代码评审等活动的参考。

3、比较代码分支(Branch)或标签(Tag)之间的代码覆盖率变化。代码分支或标签对应在代码开发过程中不同版本的代码，基于Branch/Tag可以确定需要比较的代码变更的Commit ID，由此生成代码监控报告，可以方便的比较不同的Branch/Tag之间的代码覆盖率差异，作为版本发布等活动的参考。

4、比较不同时间周期内的覆盖率变化。通过查询不同时间周期提交代码以后对应Commit ID，进而生成代码监控报告，可以方便的比较不同的时间周期之间的覆盖率差异，作为工作报告等活动的参考。

5、查询某个代码贡献者(Commitor)所提交代码的平均代码覆盖率。通过跟踪不同的Commitor提交代码以后对应Commit ID，进而生成代码监控报告，可以方便确定某个Commitor对于产品代码在不同时间周期之间的代码覆盖信息，作为该Commitor对该产品代码所做贡献的参考。

6、查询某个产品中某一模块(Module)对应代码的代码覆盖率变化。通过跟踪某个Module提交代码变更以后对应Commit ID，进而生成的代码监控报告，可以方便比较该Module在不同时间周期之间的代码覆盖率变化，作为产品发布部署的参考。

为了便于用户能够直观地获知代码覆盖的变化情况，提供灵活可定制的代码覆盖查询功能。其中，代码覆盖报告中包含的代码覆盖变化信息至少包括以下任意一项：

变更内容中增量代码的代码覆盖率。增量代码是指提交代码变更前后的代码中所增加的代码行，例如，对于一次代码变更，可能有新增代码、删除代码和修改代码三种情况，在新增代码和修改代码时会存在部分增加的代码行，这些代码行即为增量代码。对于前述110行的代码中，新增的91至100行的内容即为增量代码，若该10个代码行均被覆盖，则此时变更内容中增量代码的代码覆盖率为100％。图4的柱状图示出了变更内容中增量代码的代码覆盖率情况，对于删除代码的情况，由于不存在增量代码，在图中统一标示为0％。此外，在图中可以进一步示出每一次代码变更之后的整体代码的代码覆盖率、或者整体代码中除增量代码之外的其余代码行的代码覆盖率，如图4中的折线图所示，由此可以显示出代码变更的变更内容对于整体代码或者其余代码的影响。在实际的代码开发场景中，变更内容中增量代码的代码覆盖率一般需要满足一定的要求，例如行覆盖率不能低于90％或95％等，因此可以基于此项指标向用户提供关于本次代码变更的代码质量的参考。

整体代码相较于代码基线的代码行数变化值。即代码提交后，整体代码的行数增加或者减少了多少行，如图5所示。

整体代码相较于代码基线的代码覆盖率的变化值。即代码提交后，整体代码的代码覆盖率上升或者降低的值，例如前例中代码基线的100行代码中，代码覆盖率为90％，在提交代码变更后，110行的整体代码的代码覆盖率为90.91％，整体代码相较于代码基线的代码覆盖率的变化值为0.91％，即代码覆盖率上升了0.91％。

此外，若向用户提供的代码覆盖变化报告中，还包含有对变更后的整体代码进行代码覆盖测试确定的代码覆盖信息，则该代码覆盖信息可以至少包含以下任意一项：

整体代码的代码覆盖率。例如对于100行的代码，若90行被覆盖，则其代码覆盖率为90％，在实际场景中可以采用任意一种代码覆盖的评价方式，例如行覆盖、分支覆盖等，对与多次代码变更可以通过多个整体代码的代码覆盖率，体现代码覆盖率的变化情况。图3示出了提交了多次代码变更之后整体代码的代码覆盖率的变化情况图。在实际的代码开发场景中，在代码变更之后整体代码的代码覆盖率与代码基线的代码覆盖率相比，不能有显著下降，应该保持相同的水平或者增加，因此可以基于此项指标，生成包含图3的报告，以提示用户此次代码变更对整体代码所造成的影响是否符合预期。

整体代码中未被覆盖的代码行。即详细代码的摘要，通过标记(例如颜色、符号等)来标示代码覆盖异常的位置，例如通过红色来标示未被覆盖的代码行。

在实际场景中，在向用户提供代码覆盖变化报告时，可以通过可视化的形式向用户呈现。由于可以在每次进行代码变更时自动生成并提供代码覆盖变化报告，因此可以在整个代码开发的过程中持续为用户提供关于代码覆盖的相关信息，从而使得用户可以更加直观的连续监控代码覆盖的增量式变化。

图6示出了在代码开发过程中使用本申请实施例提供的代码开发的监控方法后的工作流程，包括以下步骤：

步骤S601，程序员根据一个需求或者BUG在代码基线的基础上开始编写代码。

步骤S602，代码编写结束，提交本次代码变更(PR)。

步骤S603，触发代码覆盖测试，收集提交代码变更后的整体代码的整体代码覆盖报告(CR)，该整体代码覆盖报告(CR)包含了对变更后的整体代码进行代码覆盖测试确定的代码覆盖信息。

步骤S604，将本次的整体代码覆盖报告(CR)与报告基线对比，收集本次代码变更的增量代码覆盖报告(RR)，该增量代码覆盖报告(RR)中包含了变更代码对应的代码覆盖变化信息。

步骤S605，基于整体代码覆盖报告和增量代码覆盖报告中的包含信息，可以生成关于变更代码的代码覆盖变化报告，供用户查看。

步骤S606，自动打包代码。

步骤S607，进行代码评审，可以基于前述的报告进行。

步骤S608，对通过评审的代码进行自动回归测试、性能测试。

步骤S609，代码上线或发布。

基于同一发明构思，本申请实施例中还提供了代码开发的监控设备，该设备对应的方法是前述实施例中的代码开发的监控方法，并且其解决问题的原理与该方法相似。

本申请提供的代码开发的监控设备，包括获取装置、覆盖检测装置和报告生成装置，其中，由获取装置首先获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码。根据获取到的变更代码和代码基线，可以确定变更后的整体代码。其中，变更代码是指在软件开发过程中用户提交代码变(pull request，PR)的变更内容，代码变更是指在软件开发中开发人员通过若干代码提交(commits)来完成一个功能点，并将功能点对应的代码申请合并进入一个分支的过程。

每一次代码变更的变更内容包括包括新增代码、删除代码和修改代码三种情况中的一种或者几种，在实际场景中可以理解为先删除代码、后新增代码的组合情况。基于代码基线和变更代码可以确定变更后的整体代码(即更新后的代码)，而每一次提交代码变更后的整体代码也可以作为下一次代码变更的代码基线。

例如在本申请的一种实施例中，代码基线包含100行代码，变更代码的内容可以是新增了10行代码、删除了20行代码或者对其中30行代码进行了修改，并修改为35行代码。对于每一次的代码变更可以建立代码库，保存每一次变更代码的内容，例如可以利用Git进行管理，保存的每一次的代码变更。以前述的代码变更为例，若新增了10行代码，代码库中保存的内容可以是其相对于代码基线的变化情况，例如提交代码变更后的整体代码中第91至100行为新增的10行代码，101至110行为原代码中的第91至100行内容。而每一次代码变更都会生成一个标识信息，实际场景中可以使用commit ID或者PR ID来对每一次代码变更进行记录。

在确定变更后的整体代码之后，覆盖检测装置可以对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息。代码覆盖信息可以采用不同类型的代码覆盖进行评价，例如行覆盖、分支覆盖等。以前述新的整体代码为例，对于110行的代码，若采用行覆盖对其代码覆盖情况进行评价，其代码覆盖情况可以是第1至65行以及76至110行被覆盖，第66至75行未被覆盖。

其后，覆盖检测装置将代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息。代码覆盖变化信息能够用于表示在代码更变的过程中关于代码覆盖的变化情况，例如，对于前述的110行代码，其初始代码为100的代码，若初始代码的整体代码覆盖报告(即报告基线)中其代码覆盖情况为：第1至90行被覆盖，第91至100行未被覆盖，由于初始代码中的91至100行即为新代码中的101至110行内容，则相应的代码覆盖变化情况可以是变更内容中的增量代码(即91～100行)被覆盖，第66至75行覆盖丢失(代码覆盖情况由覆盖变为未覆盖)，第101至110行覆盖新增(代码覆盖情况由未覆盖变为覆盖)。通过上述方式，可以确定本次代码变更所引起的代码覆盖变化情况，例如哪些代码在本次代码变更后被覆盖，哪些代码在本次代码变更后覆盖丢失等。

报告生成装置在确定代码覆盖变化信息之后，将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户，由此可以使得用户更加细粒度了解代码覆盖的相关情况，连续监控代码覆盖的增量式变化。在本申请的一个实施例中，报告生成装置还可以将对变更后的整体代码进行代码覆盖测试确定的代码覆盖信息加入到代码覆盖变化报告中，由此用户在获取代码覆盖变化报告时，可以同时获知关于变更后的整体代码的代码覆盖信息，使得用户能够更加了解代码开发过程中的代码覆盖情况。

在实际场景中，用户每一次提交的代码变更都会有相应的commit ID或者PR ID来作为变更代码的标识信息，由此，对于生成的所述代码覆盖变化报告，可以通过设备的存储装置将其保存，例如可以设定一报告库，作为用于存放上述完整代码覆盖报告和增量代码覆盖报告的数据库，并使用每一次代码变更的标识信息对其进行标记，由此建立代码变更和代码覆盖变化报告的对应关系，使得代码基线可以与报告基线保持对应，便于用户根据标识信息提取相应的报告，了解代码覆盖变化情况。图2示出了代码基线和报告基线对应关系的示意图，通过commit ID作为代码变更的标识信息对代码和覆盖报告进行标记，建立其对应的关系。

在本申请的实施例中，向用户提供代码覆盖变化报告时，可以基于用户的查询需求，该查询需求可以根据实际场景中用户对于代码覆盖变化情况的监控需求来确定。例如，查询需求可以规定每一次提交代码变更后都生成代码覆盖变化报告，并提供给用户，便于用户实时获知每一次代码变更的提交对于整体代码的影响。

此外，查询需求也可以携带本次查询的标识信息，获取装置可以在用户查询是获取到本次查询的标识信息，而报告生成装置通过本次查询的标识信息在保存的所述代码覆盖变化报告中，确定本次查询对应的代码覆盖变化报告，从而实现定制化的监控。当用户需要查询某一次代码变更后的代码覆盖变化报告时，可以通过一定的筛选方式输入待查询的标识信息。例如通过输入时间这一筛选条件确定某一时间之前最近一次的代码变更的标识信息，或者也可以根据代码的版本号确定该次代码变更的标识信息，此外还可以根据代码变更的贡献者(Commitor)，确定该贡献者的所提交的代码变更的标识信息。

在实际场景中，通过查询不同的标识信息，本申请实施例提供的方法可以有以下应用：

1、每次提交代码变更(PR)后生成关于代码覆盖率的报告，用于代码评审。在每次提交代码变更之后，用户可以收到本次代码变更所对应的代码监控报告，该报告可以发布在代码评审页面，或者嵌入到相关工具和插件中，让参与人员方便获得，从而便于进行代码评审。

2、查询两次代码变更之间的代码覆盖率变化。通过提交代码变更以后对应的Commit ID查询相应的代码监控报告，由此可以方便的比较两次代码变更产生的覆盖率差异，作为代码评审等活动的参考。

3、比较代码分支(Branch)或标签(Tag)之间的代码覆盖率变化。代码分支或标签对应在代码开发过程中不同版本的代码，基于Branch/Tag可以确定需要比较的代码变更的Commit ID，由此生成代码监控报告，可以方便的比较不同的Branch/Tag之间的代码覆盖率差异，作为版本发布等活动的参考。

4、比较不同时间周期内的覆盖率变化。通过查询不同时间周期提交代码以后对应Commit ID，进而生成代码监控报告，可以方便的比较不同的时间周期之间的覆盖率差异，作为工作报告等活动的参考。

5、查询某个代码贡献者(Commitor)所提交代码的平均代码覆盖率。通过跟踪不同的Commitor提交代码以后对应Commit ID，进而生成代码监控报告，可以方便确定某个Commitor对于产品代码在不同时间周期之间的代码覆盖信息，作为该Commitor对该产品代码所做贡献的参考。

6、查询某个产品中某一模块(Module)对应代码的代码覆盖率变化。通过跟踪某个Module提交代码变更以后对应Commit ID，进而生成的代码监控报告，可以方便比较该Module在不同时间周期之间的代码覆盖率变化，作为产品发布部署的参考。

为了便于用户能够直观地获知代码覆盖的变化情况，提供灵活可定制的代码覆盖查询功能。其中，代码覆盖报告中包含的代码覆盖变化信息至少包括以下任意一项：

变更内容中增量代码的代码覆盖率。增量代码是指提交代码变更前后的代码中所增加的代码行，例如，对于一次代码变更，可能有新增代码、删除代码和修改代码三种情况，在新增代码和修改代码时会存在部分增加的代码行，这些代码行即为增量代码。对于前述110行的代码中，新增的91至100行的内容即为增量代码，若该10个代码行均被覆盖，则此时变更内容中增量代码的代码覆盖率为100％。图4的柱状图示出了变更内容中增量代码的代码覆盖率情况，对于删除代码的情况，由于不存在增量代码，在图中统一标示为0％。此外，在图中可以进一步示出每一次代码变更之后的整体代码的代码覆盖率、或者整体代码中除增量代码之外的其余代码行的代码覆盖率，如图4中的折线图所示，由此可以显示出代码变更的变更内容对于整体代码或者其余代码的影响。在实际的代码开发场景中，变更内容中增量代码的代码覆盖率一般需要满足一定的要求，例如行覆盖率不能低于90％或95％等，因此可以基于此项指标向用户提供关于本次代码变更的代码质量的参考。

整体代码相较于代码基线的代码行数变化值。即代码提交后，整体代码的行数增加或者减少了多少行，如图5所示。

整体代码相较于代码基线的代码覆盖率的变化值。即代码提交后，整体代码的代码覆盖率上升或者降低的值，例如前例中代码基线的100行代码中，代码覆盖率为90％，在提交代码变更后，110行的整体代码的代码覆盖率为90.91％，整体代码相较于代码基线的代码覆盖率的变化值为0.91％，即代码覆盖率上升了0.91％。

此外，若向用户提供的代码覆盖变化报告中还包含有对变更后的整体代码进行代码覆盖测试确定的代码覆盖信息，则该代码覆盖信息可以至少包含以下任意一项：

整体代码的代码覆盖率。例如对于100行的代码，若90行被覆盖，则其代码覆盖率为90％，在实际场景中可以采用任意一种代码覆盖的评价方式，例如行覆盖、分支覆盖等，对与多次代码变更可以通过多个整体代码的代码覆盖率，体现代码覆盖率的变化情况。图3示出了提交了多次代码变更之后整体代码的代码覆盖率的变化情况图。在实际的代码开发场景中，在代码变更之后整体代码的代码覆盖率与代码基线的代码覆盖率相比，不能有显著下降，应该保持相同的水平或者增加，因此可以基于此项指标，生成包含图3的报告，以提示用户此次代码变更对整体代码所造成的影响是否符合预期。

整体代码中未被覆盖的代码行。即详细代码的摘要，通过标记(例如颜色、符号等)来标示代码覆盖异常的位置，例如通过红色来标示未被覆盖的代码行。

在实际场景中，在向用户提供代码覆盖变化报告时，可以通过可视化的形式向用户呈现。由于可以在每次进行代码变更时自动生成并提供代码覆盖变化报告，因此可以在整个代码开发的过程中持续为用户提供关于代码覆盖的相关信息，从而使得用户可以更加直观的连续监控代码覆盖的增量式变化。

综上，本申请提供的方案中，通过获取变更代码以及代码基线，来对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息，然后与对所述代码基线进行覆盖测试确定的代码覆盖基线信息进行对比，确定变更代码对应的代码覆盖变化信息，将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户，使得用户可以确定本次代码变更所引起的代码覆盖变化情况，例如哪些代码在本次代码变更后被覆盖，哪些代码在本次代码变更后覆盖丢失等，由此可以便于用户在开发过程中获知代码的开发情况，更加细粒度了解代码覆盖的相关情况，连续监控代码覆盖的增量式变化。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个如图7所示的代码开发的监控设备，该设备包括用于存储计算机程序指令的存储器720和用于执行程序指令的处理器710，其中，当该计算机程序指令被该处理器执行时，触发该设备运行基于前述根据本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (11)

1.一种代码开发的监控方法，其中，该方法包括：

获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码；

对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息；

将所述代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，所述代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息；

将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户。

2.根据权利要求1所述的方法，其中，该方法还包括：

将对变更后的整体代码进行代码覆盖测试确定的代码覆盖信息加入到代码覆盖变化报告中。

3.根据权利要求1或2所述的方法，其中，该方法还包括：

保存所述代码覆盖变化报告；

基于所述变更代码的标识信息对所述代码覆盖变化报告进行标记。

4.根据权利要求3所述的方法，其中，该方法还包括：

获取本次查询的标识信息；

根据本次查询的标识信息，在保存的所述代码覆盖变化报告中，确定本次查询对应的代码覆盖变化报告，以便将该代码覆盖变化报告提供给用户。

5.根据权利要求1或2所述的方法，其中，所述代码覆盖变化信息至少包括以下任意一项：

所述变更代码的代码覆盖率；

所述变更后的整体代码相较于代码基线的代码行数变化值；

所述变更后的整体代码相较于代码基线的代码覆盖率的变化值。

6.一种代码开发的监控设备，其中，该设备包括：

获取装置，用于获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码；

覆盖检测装置，用于对变更后的整体代码进行代码覆盖测试，确定代码覆盖信息，以及将所述代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，所述代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息；

报告生成装置，用于将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户。

7.根据权利要求6所述的设备，其中，所述报告生成装置，还用于将对变更后的整体代码进行代码覆盖测试确定的代码覆盖信息加入到代码覆盖变化报告中。

8.根据权利要求6或7所述的设备，其中，该设备还包括：

存储装置，用于保存所述代码覆盖变化报告，并基于所述变更代码的标识信息对所述代码覆盖变化报告进行标记。

9.根据权利要求8所述的设备，其中，所述获取装置，还用于获取本次查询的标识信息；

所述报告生成装置，还用于根据本次查询的标识信息，在保存的所述代码覆盖变化报告中，确定本次查询对应的代码覆盖变化报告，以便将该代码覆盖变化报告提供给用户。

10.根据权利要求6或7所述的设备，其中，所述代码覆盖变化信息至少包括以下任意一项：

所述变更代码的代码覆盖率；

所述变更后的整体代码相较于代码基线的代码行数变化值；

所述变更后的整体代码相较于代码基线的代码覆盖率的变化值。

11.一种代码开发的监控设备，其中，该设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：获取变更代码，以及代码基线，该代码基线为变更代码对应的变更前的整体代码；对变更后的整体代码进行代码覆盖测试，确定第码覆盖信息；将所述代码覆盖信息与代码覆盖基线信息进行对比，确定该变更代码对应的代码覆盖变化信息，其中，所述代码覆盖基线信息为对所述代码基线进行覆盖测试确定的代码覆盖信息；将该代码覆盖变化信息加入到代码覆盖变化报告中，以便将该代码覆盖变化报告提供给用户。