如何衡量单元测试的好处？

Question

我正在推动公司将单元测试作为开发周期的重要组成部分。我已经使测试框架与我们的MVC框架配合工作，团队中的多个成员现在正在编写单元测试。然而，现在需要改进我们的小时级构建、查找需要使用的固定装置的便利性、添加模拟对象生成器的功能等等工作，我希望能够向管理层提出这些方面的需求。此外，我还想我们能够分配时间编写最关键的现有代码单元测试，如果只是口号式地说“每个人都知道单元测试很好”，我认为这种想法不会得到实现。

如何量化全面可靠的单元测试对项目的积极影响？我可以看一下已经提交的错误数量和严重程度，并将其与代码覆盖率的增加进行相关联，但这是一个相当弱的指标。

- Arkaaito

---

这可能更适合程序员网站。 - Maxpm

它可能是一个较弱的指标，但从商业角度来看，这是唯一的指标：更好的测试投资是否降低了开发成本（包括QA）。如果您跟踪支持成本，那是另一种可能性，但那里存在显著的滞后。 - Anon

匿名者：这很有价值，但是我该如何衡量更好的测试投资是否降低了开发成本呢？提供相关性比没有好，但我正在寻找一种更令人信服的方式，而不仅仅是“我们在单元测试上投入了大量工作，一段时间后我们团队的吞吐量增加了”。 - Arkaaito

假设您有一个正在进行的开发过程，并跟踪错误，您可以发表类似于“对于没有单元测试的项目，我们每个项目月份看到大约50个由QA报告的错误；对于新代码，我们要求70％的覆盖率，我们每个项目月份看到大约20个错误报告。”然后就是测试开发成本与QA和错误修复成本之间的比较。再加上像延迟项目这样的无形因素。 - Anon

这仍然存在引导问题：如何使第一个项目使用单元测试。答案是找到一个愿意查看外部团队结果并愿意增加额外时间的商业赞助者。毫无疑问，这可能很困难，但我相信您能否做到这一点直接关系到您实际推行感染测试文化的能力。 - Anon

Answer 1

Sonar 是一家提供非常有趣的代码检查工具的公司，他们实际上尝试通过程序化的方式来衡量技术债务，这与未经测试的代码和开发人员每小时的价格相关。

- Nathan Feger

Answer 2

测试质量的量化非常困难。

我认为代码覆盖率只是指导而不是测试质量度量标准。您可以在没有测试任何东西的情况下（例如根本没有使用断言）编写100％代码覆盖测试。请参阅我的blog-post，在其中我警告有关指标陷阱。

我所知道唯一明智的定量指标，对业务来说真正重要的是生产代码中错误修复的减少工作量，以及错误严重程度的降低。但仍然非常难以分离出单元测试是这种成功的唯一来源（它也可能是流程或沟通的改进）。

通常我会专注于质性方法：

• 开发人员是否感到更舒适地更改代码（因为测试是可信赖的安全保障）？
• 当生产中出现错误时，分析表明它是未经测试的代码（反之亦然，如果存在单元测试，则结论是它不会发生）

- manuel aldana