大叔大婶带你走一条接地气的测试进阶之路
【周问日答】(3)为什么一定要做单元测试?
上一篇 /
下一篇 2017-10-21 12:12:32
/ 个人分类:测试问答
【提问】
为什么一定要做单元测试?
【旧识】
很久之前,我在学习《Head First Java》那本书的时候,应该是我第一次接触单元测试。书中在教到写一个类的时候,都是按照下面的顺序:
- 伪代码(一种算法描述语言,让你专注于逻辑,而不需要考虑程序语言的语法)
- 测试代码(测试功能程序的代码)
- 功能代码(实现功能需求的代码)
开始实践时还不太理解为什么按照这个顺序去做,觉得都还没有完成可以测试的代码,就去写测试代码,意义在哪?后来看了书中的解释,并自己实践了一段时间,觉得还是有一定好处的。在开始写真实类的代码之前,通过思考和编写测试代码,可以更好的了解要实现的这个类应该要做的事情。
这应该就是我最初对单元测试的理解:通过写测试代码去测试功能代码。
【新知】
在之后这些年的项目过程中,听到开发抱怨最多的就是:时间太紧了,哪有时间做单元测试?等都集成好之后,提交给测试先,发现问题再改吧。先不说那些通过 KPI 指标来约束开发必须做单元测试的,因为那种只是因为公司要求做单元测试才去做的,其实并不清楚为什么要做。
我们就从产品研发本身来看看为什么一定要做单元测试吧:
- 质量保证工作的前置,问题修复的成本肯定是越早越低。
拿制造业举例:检测工作都是从最小的零部件开始的,当问题被发现在最小零部件的检测时,修复起来很容易,但如果最小零部件被组装成了成品之后,再发现问题,修复起来就会复杂很多,成本也就增加了很多。
- 产品发布的敏捷化要求。
(1)互联网产品越来越多地偏向敏捷化,在软件编码过程中,原来独立的由单元模块组装成完整的系统的过程已经不太适用了,这个过程已经慢慢地变为一个持续性地过程,也就是持续集成。持续集成的第一步就是自动构建,想要保证自动构建的成功,就需要有合格的单元代码,想要单元代码合格,就需要单元测试。所以,单元测试是后续系统持续集成的前提和基础,是持续集成合格输入的保障。
(2)测试驱动开发(Test-Driven Development,TDD)是敏捷开发中的核心实践。而这里的测试,指的也就是单元测试。
- 根据被测对象的功能要求编写一段最简单的、必然会执行失败的单元测试代码。
- 开发最简单的、可以让单元测试执行成功的功能代码。
- 重构代码,让代码满足功能需求。
- 修改单元测试代码,增加新的用例,让执行变为失败。
- 修改和重构代码,让执行可以成功。
TDD 就是这么一个测试先行和持续重构的迭代过程,从而保证单元测试的100%代码覆盖。
作者简介:14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
相关阅读:
- 编写有效的软件测试报告[转载] (fengyun32, 2009-1-08)
- 如何有效控制需求变更?【转】 (fengyun32, 2009-1-08)
- WEB测试总结(架构、设计)--参考 (fengyun32, 2009-1-08)
- 软件测试知识(1) (muyang327, 2009-2-14)
- 软件测试知识(2) (muyang327, 2009-2-14)
- 测试人员的误区:迷信自动化 (fengyun32, 2009-3-05)
- Web测试需要了解的知识 (zzzmmmkkk, 2013-6-02)
- 软件测试知识框架——黑盒 (Aimelyccc, 2013-6-24)
- 【周问日答】(1)测试策略能帮助我们做什么? (sunsky528, 2017-10-18)
- 【周问日答】(2)制定测试策略有没有章法可循? (sunsky528, 2017-10-19)
收藏
举报
TAG:
测试知识
测试问答