我正在推动我的公司将单元测试作为开发周期的主要部分。我已经让测试框架与我们的MVC框架一起工作，团队的多个成员现在正在编写单元测试。不过，我现在需要做的工作是改进我们的每小时构建，确定需要使用哪些灯具，为模拟对象生成器添加功能等等，以及我希望能够将这项工作的案例提交给管理层。另外，我希望我们为现有代码中最关键的部分分配时间来编写单元测试，而且我没有看到这种情况发生在没有比“每个人都知道单元测试是好的”更具体的情况下。
如何量化（全面和可靠）单元测试对项目的积极影响？我当然可以查看提交的错误的数量和严重程度，并将其与我们的代码覆盖率增加相关联，但这是一个相当弱的指标。
答案 0 :(得分：3)
Sonar是一家制作非常有趣的代码检查工具的公司，他们实际上尝试measure technical debt programaticaly，这与未经测试的代码和每小时的开发者价格相关。
答案 1 :(得分：1)
测试质量的量化非常困难。
我认为代码覆盖率仅作为指导而非测试质量指标。您可以在不测试任何内容的情况下编写100％代码覆盖率的测试（例如，根本不使用任何断言）。另请查看我的blog-post，其中我警告了指标陷阱。
我所知道的唯一合理的量化指标以及对业务有用的指标实际上减少了生产代码中错误修复的工作量。还减少了bug严重性。仍然很难确定单元测试是这种成功的唯一来源（它也可能是过程或通信的改进）。
一般来说，我会专注于定性方法：