软件单元测试分为狭义的单元测试和广义的单元测试。
前者是指对被测代码的各种函数、接口等进行测试，以验证它们的功能、性能和安全性。
后者是指对页面的每一个组件（如文本框、按钮等）进行测试，以验证它们的功能、性能和安全性，有时也被称为组件测试。
传统的软件开发方式是先写产品代码，再写测试代码，最后用测试代码来验证产品代码。
但是在敏捷方法中，特别是敏捷中的极限编程鼓励进行测试驱动开发，即先写测试代码，再写产品代码，最后对代码进行重构。
其好处是能够充分考虑程序需要处理的正常场景和异常场景，尽可能一次性地写出正确的产品代码，从而提高开发效率。
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 单元测试在敏捷开发模式中的地位
单元测试属于支持团队的面向技术的测试。支持团队说明单元测试是在特性团队中进行的；面向技术表示单元测试的技术含量比业务含量要重。这里需要特别指出，单元测试不是不注重业务知识。
虽然在很多互联网公司，为了提高研发速度缩小了单元测试的规模，然而单元测试的优势和地位依然是不可被取代的！
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
