单元测试与新飞机的质量

⾸先不可避免要回答的⼀个问题是，“为何要做单元测试？”，我个⼈的回答是：“这是保证——你写的代码是你想要的结果——的最有效办法！”，当然如果你有更好的办法，请不吝赐教。

没有完备的单元测试的代码所构成的⼀个系统，就像组装⼀架飞机，各个配件没有分别经过严格检验，只在最后组装好后，再通过试飞来检验飞机是否正常⼀样。

尽管软件开发可以“开着飞机换引 擎”，但万⼀引发了线上事故，影响了绩效，减少了发量，这样的成本还是太⾼了。所以优秀的工程师总会想尽⼀切办法保证⾃⼰的出品没有质量问题，而单元测试就是⼀个有⼒的武器，可以⼤幅降低⼤家上线时的紧张指数。

单元测试的重要性

• 单元测试对我们的产品质量是非常重要的。
• 单元测试是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节，是唯一一次有保证能够代码覆盖率达到100%的测试，是整个软件测试过程的基础和前提，单元测试防止了开发的后期因bug过多而失控，单元测试的性价比是最好的。
• 据统计，大约有80%的错误是在软件设计阶段引入的，并且修正一个软件错误所需的费用将随着软件生命期的进展而上升。错误发现的越晚，修复它的费用就越高，而且呈指数增长的趋势。作为编码人员，也是单元测试的主要执行者，是唯一能够做到生产出无缺陷程序这一点的人，其他任何人都无法做到这一点
• 代码规范、优化，可测试性的代码
• 放心重构
• 自动化执行three-thousand times

时间成本指标

微软的统计数据：bug在单元测试阶段被发现，平均耗时3.25小时，如果漏到系统测试阶段，要花费11.5小时。

测试中出现bug的阶段

下面这张图，旨在说明两个问题：85%的缺陷都在代码设计阶段产生，而发现bug的阶段越靠后，耗费成本就越高，指数级别的增高。所以，在早期的单元测试就能发现bug，省时省力，一劳永逸，何乐而不为呢

单元测试的艺术

在《单元测试的艺术》这本书提到一个案例：找了开发能力相近的两个团队，同时开发相近的需求。进行单测的团队在编码阶段时长增长了一倍，从7天到14天，但是，这个团队在集成测试阶段的表现非常顺畅，bug量小，定位bug迅速等。最终的效果，整体交付时间和缺陷数，均是单测团队最少。

单元测试 演进过程

在金字塔模型之前，流行的是冰淇淋模型。包含了大量的手工测试、端到端的自动化测试及少量的单元测试。造成的后果是，随着产品壮大，手工回归测试时间越来越长，质量很难把控；自动化case频频失败，每一个失败对应着一个长长的函数调用，到底哪里出了问题？单元测试少的可怜，基本没作用。

Mike Cohn 在他的着作《Succeeding with Agile》一书中提出了“测试金字塔”这个概念。这个比喻非常形象，它让你一眼就知道测试是需要分层的。它还告诉你每一层需要写多少测试。 测试金字塔本身是一条很好的经验法则，我们最好记住Cohn在金字塔模型中提到的两件事：

• 编写不同粒度的测试
• 层次越高，你写的测试应该越少

同时，我们对金字塔的理解绝不能止步于此，要进一步理解： 我把金字塔模型理解为——冰激凌融化了。就是指，最顶部的“手工测试”理论上全部要自动化，向下融化，优先全部考虑融化成单元测试，单元测试覆盖不了的 放在中间层（分层测试），再覆盖不了的才会放到UI层。

因此，UI层的case，能没有就不要有，跑的慢还不稳定。按照乔帮主的说法，我不分单元测试还是分层测试，统一都叫自动化测试，那就应该把所有的自动化case看做一个整体，case不要冗余，单元测试能覆盖，就要把这个case从分层或ui中去掉。

越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广。比如单元测试，它的关注点只有一个单元，而没有其它任何东西。所以，只要一个单元写好了，测试就是可以通过的；而集成测试则要把好几个单元组装到一起才能测试，测试通过的前提条件是，所有这些单元都写好了，这个周期就明显比单元测试要长；系统测试则要把整个系统的各个模块都连在一起，各种数据都准备好，才可能通过。

另外，因为涉及到的模块过多，任何一个模块做了调整，都有可能破坏高层测试，所以，高层测试通常是相对比较脆弱的，在实际的工作中，有些高层测试会牵扯到外部系统，这样一来，复杂度又在不断地提升。

Google 对测试的分类

Google创立了自己的命名方式，只分为小型测试、中型测试和大型测试。

• 小型测试，针对单个函数的测试，关注其内部逻辑，mock所有需要的服务。小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告
• 中型测试，验证两个或多个制定的模块应用之间的交互
• 大型测试，也被称为“系统测试”或“端到端测试”。大型测试在一个较高层次上运行，验证系统作为一个整体是如何工作的。
  
  

结论

我们的单元测试，既可以针对一个函数写case，也可以按照函数的调用关系串起来写case。 金字塔模型

参考

单元测试到底是什么？应该怎么做？
https://www.zhihu.com/question/28729261

从头到脚说单测——谈有效的单元测试
https://mp.weixin.qq.com/s/okmWMOeBm7cCIZ1zzFr4KQ

Junit源码阅读(六)之Junit中的设计模式
https://www.open-open.com/lib/view/open1454723255511.html

JUnit 源码解析
https://toutiao.io/posts/sir49z/preview

JUnit源码与设计模式欣赏——JUnit学习（三）
https://my.oschina.net/pangyangyang/blog/153320

深入JUnit源码之Runner
https://developer.aliyun.com/article/46869

一文帮你理解什么是单元测试
https://www.cnblogs.com/harlanc/p/6838155.html

分析 JUnit 框架源代码
https://developer.ibm.com/zh/languages/java/articles/j-lo-junit-src/

标签：case,https,单元测试,必要性,测试,com,bug,成本
来源： https://blog.csdn.net/zgpeace/article/details/111718154