- 变更覆盖率的必要性
-
- Cover的主要功能：变更覆盖率
测量代码覆盖率（以下称为覆盖率）是为了提高正在开发的软件的质量并执行高质量的测试。如果开发人员直接测试正在开发的源代码，可以更容易地增加覆盖率。但是，如果正在开发的软件被新的开发人员接管或通过另一个组织进行测试，则很难增加覆盖率。如果代码已经通过负责的开发人员或测试人员进行了充分的测试，但是如果由于维护导致源代码、函数、功能的变化而重新执行整个测试场景，将再次消耗大量的工时。并且如果由不知道变更源代码、函数、功能信息的第三方进行测试，则增加/修改的功能可能无法测试，变更后的功能添加的测试场景也无法得到保障。 COVER 产品为此测试环境提供了变更覆盖功能。更改覆盖检测源代码中更改的功能和行，并提供单独管理更改区域的覆盖。
提高软件质量的测试在软件开发的团队/公司中非常普遍。在这种情况下，提高测试效率的方法是测量和管理代码覆盖率（以下简称覆盖率）。在某些情况下，会组建单独的团队进行测试，或者软件开发人员直接测试正在开发的源代码。
如果一个开发者直接测试，由于负责人变动而将软件移交给新的开发者，或者如果测试团队发生变化，通过另一个组织进行测试，则不可避免地难以增加覆盖率。此外，如果在测试已取得很大进展的状态下，由于维护导致源代码/函数/功能变化而重新执行整个测试，则将重复产生相当大的成本。更进一步，如果不知道更改的第三方正在测试，则无法测试修改的部分或无法确保根据更改的附加测试场景。
COVER 提供了变更覆盖功能来解决这个问题（保持测试环境一致）。更改覆盖率功能检测被测源代码中更改的函数和行，帮助单独管理更改区域的覆盖率。
2.利用与配置管理工具链接的变更覆盖率
-变更覆盖率 - 通过与配置管理工具链接更有效地使用
为了实现变更覆盖率，需要许多关于如何寻找源代码的变更点的方法。目前已经出现了各种方法，例如日期标准和用户自己指定的用于选择现有源和新更改源的标准。 首先，如果判断日期，用户会记住现有源的构建日期，并且用户在每次构建时更改现有源的日期。其次，当用户直接指定时，如果源形状很多，对所有形状都设置不方便。此外，如果将当前形状与要构建的形状的先前形状进行比较，则无法在没有用户修改形状的情况下应对频繁的构建。
【幕后故事】在开发Cover产品时，我们在实现变更覆盖功能上花了很多心思。我需要了解使用什么标准来查找源代码中的更改点最有效。在所讨论的方法中，有一种按更改日期由用户指定的方法。在根据第一个日期判断是否更改时，会出现以下问题。如果在同一天多次构建，则每次构建时用户必须记住现有源的构建日期，然后用户必须在构建后更改现有源的日期。其次，如果用户直接指定，随着源配置数量的增加，为每个形状指定变得不方便。此外，如果将要构建的形状与之前的形状进行比较，则存在用户无法单独应对频繁构建的问题。
因此，如果您与配置管理工具链接以增加更改覆盖率的使用，您可以轻松确定要比较的源的标准。 当开发者通过COVER产品与配置管理工具的联动签入源时，可以接收到变更后的源信息，自动确定比对目标标准。 此外，如果在签入条件中设置实现变更覆盖的标准，也可以防止未经测试的源签入。
为了解决这些问题，增加变更覆盖率的使用，通过配置管理工具与覆盖率联动，采用确定变更源标准的方法。 当开发人员签入源代码时，他们会收到更改后的源信息并自动确定比较标准。 此外，通过在可以签入的条件下设置实现变更覆盖率的标准，可以防止签入未经测试的源代码。
3.使用配置管理联动的案例
K公司的开发情景如下。
1.从配置管理工具中查看最新的形状
2.修改和测试源代码
3.在配置管理工具中请求批准变更的源
4. 审批完成后签入更改的来源
如果 COVER 产品与配置管理工具链接，则继续执行以下场景。
1、从配置管理工具中查看最新的形状
2、修改源代码
3、在COVER服务器上注册覆盖测量的源
4、针对更改的来源进行测试
5、在配置管理工具中请求批准更改的源
6、检查K公司的覆盖达标标准是否满足
7、如果满足审批条件，审批完成后签入变更的源
8、通过签到信息设置变更来源变更标准
