软件单元测试技巧

单元测试?

Test

Brief Agenda

程序员为什么要做测试 测试的一些基本概念 测试先行的概念 单元测试的基本做法和常见工具

测试不是我的工作你是这样的程序员么？

测试是测试部门的责任，我 的责任应该关注在写代码上 测试不是一种技术工作，毫 无乐趣可言，请不要骚扰我。 我可是一个了不起的EJB程 序员 我们有测试人员，有集成/系 统/确认测试，他们迟早会发 现我的错误。请不要浪费我 的时间。 不要侮辱我，我写的程序， 怎么可能有错误。测试是完 全没必要的。

离我远一点，我是程序员

你做了测试了吗？大部分中小公司，和软件开发管理处于早期阶 段的团队，没有专门的测试工作和测试流程， 测试只是在产品提交给用户之前，组织若干人 员对最终产品作一次基本功能的确认测试而已。 更多时候，测试的实际工作是用户来完成的。

后果

软件的质量完全取决于 程序员的个人技能和责 任心，具有很大的随机 性 后期维护成本高昂

1个月的开发，几天的测试，然后花 1,2年的时间去修补错误 这个项目我已经维护了3年了

根本原因是软件自身复 杂的结构

虫虫和天上的星星一样多

软件的结构系统 用户需求

模块

系统结构

功能

集成

类

单元

方法

错误可能会随机的分布在任何一个地方

测试模型

软件自身的复杂程度决定了即使是最优秀的程序员也 不可能不制造任何错误。 软件自身的复杂程度决定了不可能只通过对最终产品 的1,2种类型的测试就可以排除系统中的大部分错误 测试必须并行的融入到软件开发生命周期的各个阶段， 以覆盖软件结构和开发生命周期的不同关注点。 主要的模型有传统的瀑布模型，和v模型，以及改良 的x模型

V模型

测试活动融入整个软件开发的 生命周期 不同阶段的测试强调的是从不 同视角关注不同的方面，尽可 能早而全的出去错误，不累计 错误。 每一种类型测试的效果，将严 格依赖于前期阶段其他类型测 试的执行的正确，完整与否。 测试有分工，合适的人在合适 的时候承担合适的测试 改良的有x模型

时间和成本

缺陷的发现时间越晚，修复的成本越高，在部署阶段每个 缺陷的修复成本都会及其高昂(每一个major以上的缺陷 修复都不得不作完整的系统测试和确认测试),严格实施 scm的组织尤其昂贵。

什么是单元测试

盖房子，至少要保证每一块砖都是好的

单元测试测试的软件最小的可执行单元的正确性，即 类或方法 单元测试通常是一段可执行代码，并能验证执行结构 是否和

预期相等 每个单元测试至少应该有两个测试例子( Test Case ):Negative/Positive

单元测试可以是黑盒也可以是白盒，取决于执行方法

什么是单元测试(Unit Test)盖房子，至少要保证每一块砖都是好的

单元测试是其他类型测试的基础。不认真，完整的单 元测试会导致其他类型测试起不到好的效果 程序员最了解自己的程序单元，最适合做单元测试 传统的重量级的方法学里，UT test case由设计人员 在系统设计阶段开发，并用来验证编码人员的工作质 量

单元测试是成本最低的测试活动

发现一个Defect所需要的时间 91年数据

程序员的责任

程序员的价值在于和他人合 作，开发出高质量的代码， 而不是一堆新技术名词堆砌 的虫件(bugware)。 程序员必须对自己的代码质 量负责，单元测试是对自己 代码质量的基本承诺。 程序=UT+CODE 不做单元测试，就会影响团 队其他人员的工作。测试人 员有权利对没有做过UT的代 码说No.不愿意做UT的人， 不属于任何团队。程序=UT + CODE

实践证明(个人工作经历)

代码质量最好的程序员是UT 做的最好的程序员。 开发速度最快的程序员，是 UT做的最好的程序员 80%以上的非需求性错误， 都集中在没有做UT和不方便 做UT的代码块。 UT的质量直接影响了 IT/ST/UAT的质量。

程序=UT + CODE

测试很重要，但是

我已经调试运行过代码了，他应该是正确的，为什么还 要浪费额外的时间 程序已经能跑起来了，这期间我实际已经手工作了测试， 只是没有记录和编写代码而已

我没有时间做测试，工期已经很紧张了，能写完代码 就不错了，虽然我知道以后要返工。 我不知道应该怎么样去做测试

调试不等于UT

调试只会关注于程序的某个方面，通常是最优 路径。UT至少要关注正/负2个方面，还需要保 证一定的覆盖率 调试，尤其是J2EE应用的调试要耗费大量的 时间，没有UT的效率高(后面再细讲) 调试不可重现，在代码变跟以后，软件质量无 法保证

UT一定要做到自动化

只有用代码编写的UT,才能够重现，才能真 正节约未来手工测试的时间。 只有用代码编写的UT ,才能做到自动化，才能 在软件开发的任何时候都能快速，简单的大批 量执行，保证能准确地定位错误，保证不会因 为修改而引入新的错误。在系统开发的后期尤 为明显。 自动化的UT,才能保证回归测试的有效执行。

UT节约的是你未来的时间

编写UT代码的时间节约了未来修改/维护低质 量代码的时间 学习做UT的时间，是为了以后你可以更好的 关注你的代码 如果使用Test-driven的思想

自

身就变成设计的一部分，你不会再感到是在浪 费时间，编写UT的过程，就是设计的过程 UT快速的定位错误所在，节约了你调试的时间。

如何进行UT ---传统的做法，在it之前进行UT需求 设计 编码 评审 rework UT

严格的瀑布模型，UT作为生命周期的一个阶段 UT 的Test Case一般做为设计的一部分。 UT的执行通常在代码review以后 Test case单独编写和执行 成本高昂，尤其是严格执行SCM的情况。

UT本身是作为一种最终的质量检测手段，只能节约未来的时间. 完整全面的UT 需要大量的时间，精力,需要和PR结合

程序员通常感觉不到UT带来的眼前好处，得不到任何乐趣，抵 制执行。

如何进行UT ---传统的做法 *场景程序员先开始设计数据表。然后开始依 次编写数据访问对象，strust action,jsp 页面。他检查了一遍代码，确定每件事 看起来都是不错的，于是他开始把所有 的东西集成在一块。当然，通常是跑不 起来的，经过若干个小时辛苦的调试， 中间不断的修改代码，重起app server。 终于在数据访问对象中发现了一个错误。 若干时间以后，在代码被review以后， 程序员开始做枯燥无味的单元测试工作， 这个时候，他最想做的事情其实是睡觉。

迫于时间和成本的压力，pm/程序员往往会简化或者不执行UT的过程

如何进行UT ---改良， 写一点，测一点需求 设计 编码 编写Test case 运行ut,定位错误 Code review rework

程序员每编写完一个程序单元，就编写UT代码 首先通过运行UT代码来定位程序的错误，而不是直 接调试代码，节约了大量调试的时间。

如果能把程序划分为尽可能小的单元，通过执行ut代码，就 能快速的定位错误的所在，调试就可以避免 可有效的保证以前编写的代码的正确性，不需要拖到增量结 束以后再执行。

错误能尽早的发现，不需要等到Code review以后再 修复，成本很低

本文来源：https://www.bwwdw.com/article/7an1.html