软件单元测试分为狭义的单元测试和广义的单元测试。

前者是指对被测代码的各种函数、接口等进行测试，以验证它们的功能、性能和安全性。

后者是指对页面的每一个组件（如文本框、按钮等）进行测试，以验证它们的功能、性能和安全性，有时也被称为组件测试。

传统的软件开发方式是先写产品代码，再写测试代码，最后用测试代码来验证产品代码。

但是在敏捷方法中，特别是敏捷中的极限编程鼓励进行测试驱动开发，即先写测试代码，再写产品代码，最后对代码进行重构。

其好处是能够充分考虑程序需要处理的正常场景和异常场景，尽可能一次性地写出正确的产品代码，从而提高开发效率。

01 软件测试应该贯彻始终

在DevOps下鼓励软件测试贯彻始终，即软件测试的左移和右移。

针对单元测试，主要考虑软件测试的左移，由于在开发阶段修改缺陷的代价非常小，因此建议尽可能做到让大部分缺陷在单元测试阶段被发现。

测试左移是指代码静态和动态的自动化和手工测试，并且结合测试驱动开发让测试人员配合开发人员，尽可能保障产品的质量。测试右移是指在生产环境中进行软件测试，如全链路测试、混沌测试等。

02 软件测试金字塔

谈到软件测试金字塔，就不得不提到Mike Cohn版本的测试金字塔，如图1所示。

图1  Mike Cohn版本的软件测试金字塔模型

Mike Cohn认为开发一个软件产品需要最多的是单元测试，其次是接口测试，最后是UI（User Interface，界面）测试。

在软件测试金字塔模型中，越往上需要集成得越多，修复缺陷的速度越慢，消耗的成本越高；反之，越往下需要集成得越少，修复缺陷的速度越快，消耗的成本越低。

2009年，在伦敦召开的XP日会议上，Google发布了一份报告，报告指出：在单元测试阶段修复缺陷的成本为5美元，构建阶段修复缺陷的成本为50美元，集成测试阶段修复缺陷的成本为500美元，系统测试阶段修复缺陷的成本为5000美元。

根据Mike Cohn测试金字塔模型，Google也提出了自己的测试金字塔模型，如图2所示。

图2  Google版本的软件测试金字塔模型

我们可以认为单元测试为小型测试，接口测试为中型测试，UI测试为大型测试，可见Mike Cohn版本的软件测试金字塔模型与Google版本的本质上是一致的。

上面所述的软件测试主要是指自动化测试，而探索式测试也是不可被忽略的。据统计，基于接口和UI的自动化测试在回归测试中占有重要作用，而探索式测试对于发现产品新功能中的缺陷起着至关重要的作用。因此，在Mike Cohn软件测试金字塔模型上加上探索式测试，就形成了图3所示的改进版的软件测试金字塔模型。

图3  Mike Cohn改进版的软件测试金字塔模型

单元测试的缺点是减缓研发的速度，特别是在产品初期，这显然不符合互联网公司提出的“快鱼吃慢鱼”的思想，由此提出缩小单元测试的规模，扩大接口测试的规模，故形成了蜂巢形模型或纺锤形模型，如图4和图5所示。

图4  蜂巢形模型

图5  纺锤形模型

03 单元测试在传统开发模式中的地位

单元测试在传统开发模式中的地位，如图6所示。

在传统开发模式中，单元测试是验证编码的活动。

图6  单元测试在传统开发模式中的地位

04 单元测试在敏捷开发模式中的地位

单元测试在敏捷开发模式中的地位，如图7所示。

图7  单元测试在敏捷开发模式中的地位

单元测试属于支持团队的面向技术的测试。支持团队说明单元测试是在特性团队中进行的；面向技术表示单元测试的技术含量比业务含量要重。这里需要特别指出，单元测试不是不注重业务知识。

虽然在很多互联网公司，为了提高研发速度缩小了单元测试的规模，然而单元测试的优势和地位依然是不可被取代的！

 

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取