如何量化单元测试的价值

Question

我们的组织正在考虑将单元测试集成到我们的软件开发工作流中。我听过很多关于它如何鼓励更好、易于维护和精心设计的代码的轶事故事。作为一名程序员，我理解其中的好处。

但是，为了在可能影响客户的项目中使用单元测试建立共识，我想从节省开发人员时间的角度，从数量上展示它的价值。

在我的案例中，是否有人愿意分享历史数据或经验，作为单元测试的量化证据？

Answer 1

单元测试很便宜。

每次运行单元测试时，您都不需要付钱给测试人员手动执行该测试，或者亲自执行测试。一台计算机可以一次又一次地进行同样的测试，并保持完美的保真度(每次以完全相同的方式执行测试)。

每次自动测试捕捉到您在重构过程中错过的错误时，您都可以通过防止QA人员报告它来节省费用，并通过阻止该bug向客户报告来节省金钱和声誉资本。

自动化测试，特别是单元测试，可以节省成本，因为它能尽早捕获bug。发现一个bug越晚，它就越昂贵(按数量级计算)：

Answer 2

这是一个图表，从我的经验与和没有单元测试。右边栏中有多少问题适用于您的项目？

                  With Unit Tests               Without Unit Tests
----------------- ----------------------------- -----------------------------
Development       Code/Test/Refactor            Cut and Paste/Hack 
Process           or Test/Code/Refactor         to minimize code change 
                                                and avoid complete retest

Module Coupling   Limited by continuous         Tangled due to need to
                  refactoring                   add features with minimal
                                                code change

Program Design    Evolving through Refactoring  Frozen due to risk of change

Velocity          Increasing as higher-level    Decreasing as code volume and
over Time         functions are factored out    coupling increase 

Bugs detected     Mostly by developer           Mostly by QA or Customer

Cost of bugs      Lower                         Higher

您应该能够指出代码卷不必要地增加或模块耦合增加的特定实例，以尽量减少重新测试的需要。然而，如果他们不相信自己有问题，并且对改进不感兴趣，那么你可能无能为力。即使持续维护变得不经济，他们也可能认为这只是所有软件项目的正常结果。

只有当管理层知道他们应该进行测试时，我才成功地改进了测试，但不知道如何在经济上做到这一点。当一个组织对过程改进不感兴趣时，需要极大的耐心来实现变革。你有多耐心？

Answer 3

我曾经对一个大型系统的许多版本和不同模块进行了统计，基本上测量了每个功能代码LOC的单元测试LOC的数量，并根据每个功能LOC在手工测试中发现的bug数量绘制了图。结果如下所示：

More Bugs
^
|
| +
|+    +  +     +
|   +    +          +   +       
|  +        +    +     +    + + 
|+     + +         +      +  +  +   +
|    +        +        +    +    + +
---------------------------------------> More Unit tests

线性插值显示，与没有测试的代码相比，单元测试最多的代码中的bug减少了近50%。但是正如您所看到的，存在很大的差异，很可能与模块的复杂性、开发人员的经验和能力以及代码的成熟度有关。