软件单元测试分为狭义的单元测试和广义的单元测试。
前者是指对被测代码的各种函数、接口等进行测试,以验证它们的功能、性能和安全性。
后者是指对页面的每一个组件(如文本框、按钮等)进行测试,以验证它们的功能、性能和安全性,有时也被称为组件测试。
传统的软件开发方式是先写产品代码,再写测试代码,最后用测试代码来验证产品代码。
但是在敏捷方法中,特别是敏捷中的极限编程鼓励进行测试驱动开发,即先写测试代码,再写产品代码,最后对代码进行重构。
其好处是能够充分考虑程序需要处理的正常场景和异常场景,尽可能一次性地写出正确的产品代码,从而提高开发效率。
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 单元测试在敏捷开发模式中的地位
单元测试属于支持团队的面向技术的测试。支持团队说明单元测试是在特性团队中进行的;面向技术表示单元测试的技术含量比业务含量要重。这里需要特别指出,单元测试不是不注重业务知识。
虽然在很多互联网公司,为了提高研发速度缩小了单元测试的规模,然而单元测试的优势和地位依然是不可被取代的!
最后: 为了回馈铁杆粉丝们,我给大家整理了完整的软件测试视频学习教程,朋友们如果需要可以自行免费领取 【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。