您实际成功地使用了哪些技术来提高代码覆盖率?

删除代码。

我应该注意到,与新代码库相比,这更适用于增加旧代码库的覆盖率。

我想你读过“ Code covered vs. Code Tested ”“是吗?

如该问题所述,

即使至少有一个路径直线代码具有100%的块覆盖率+100%的弧覆盖率+100%的无错误,仍然会有以显示更多错误的方式执行路径/循环的输入数据。

eclemma ,基于EMMA,代码覆盖率工具解释了为什么100%的代码并不总是可能的:因为 partially covered lines 由于:

• 隐式分支位于同一行上。
• 共享构造函数代码。
• 由finally块导致的隐式分支。

因此,所有这4种情况都可能是重构的良好候选者,从而提高代码覆盖率。

现在,我同意弗兰克·克鲁格的回答。一些未涵盖的代码也可能表示需要进行一些重构,包括一些要实际删除的代码;)

2. 生成总体测试覆盖率的报告,并在开发经理之间分发。

我们使用Perl,所以 Devel::Cover 这对我们很有用。显示单元测试期间的每语句覆盖率、分支覆盖率和条件覆盖率,以及POD覆盖率等内容。我们使用易于识别的HTML输出,绿色表示“100%”,黄色和红色表示覆盖率较低。

编辑: 要稍微扩展一下内容:

• 如果条件覆盖不完整,请检查相互依存的条件。如果有,重构。如果不是,您应该能够扩展您的测试,以满足所有条件。
• 如果条件覆盖率和分支覆盖率看起来完整,但语句覆盖率却不完整,则可能是条件覆盖率写错了(例如,在您无意的情况下,总是从sub提前返回),或者您有可以安全删除的额外代码。

FIT testing 提高了我们的代码覆盖率。这很好,因为这是一个完全不同的策略。

背景:我们混合了传统代码和新代码。我们尽可能多地尝试对新东西进行单元/集成测试,但是因为我们正在迁移到Hibernate/Postgres,并且远离OODB,所以测试遗留代码没有多大意义。

对于那些不知道的人来说,FIT是一种从用户角度测试软件的方法。本质上,您可以在HTML表中指定所需的行为:这些表指定针对软件的操作和所需的结果。我们的团队编写“粘合代码”(又名FIT测试),将操作映射到针对代码的调用。请注意,与单元测试相比,这些测试在“从空间”的视图中运行。

使用这种方法,我们将代码覆盖率提高了几个百分点。一个额外的好处是,这些测试将跨越不同的版本:它们将测试遗留代码,但稍后会测试新代码。i、 从某种意义上说,它们可以作为回归测试。