测试之路--单元测试

一月蔷薇_456

单元测试难于进行的原因是：程序员会主观的认为自己的代码或者自己的方法的逻辑是正确的，因
此认为自己再次进行单元测试是浪费时间

单元测试可以理解为是测试每一个方法是否逻辑完整以及正确，
接口测试是针对一个完整的功能（此功能可能需要很多个方法互相调用和链接来执行），
功能测试就是将产品将会提供给用户的功能进行正确性等的测试
要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。我认为，比较简单的办法是为
产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测
试函数。而Junit这一类的工具其实就是帮助我们简化这一过程的

单元测试误解

它浪费了太多的时间
一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开
始启动工作了。这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往
这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。

在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小
的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：
软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的
Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件
集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。

在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦
完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开
发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试
是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少
的好处。

编写单元测试，如果只测试代码的一条正确路径，让它正确走一遍，并不算是真正的完成。软件开
发是一项复杂的工程，在测试某段代码的行为是否和你的期望一致时，你需要确认：在任何情况下，
这段代码是否都和你的期望一致；譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的
时候。

如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：
1）、对于所编写的代码，你在调试上面花了多少时间。
2）、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新
确认这些代码上面。
3）、对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。

如果我让测试员或者QA人员没有工作，那么我会觉得很内疚。
你并不需要担心这些。请记住，我们在此只是谈论单元测试，而它只是一种针对源码的、低层次的，
为程序员而设计的测试。在整个项目中，还有其他的很多测试需要这些人来完成，如：功能测试、
验收测试、（这两个测试属于黑盒测试的范畴）性能测试、环境测试、有效性测试、正确性测试、
正规分析等等。

测试用例设计

下面谈谈测试用例设计。前面已经说了，测试用例的核心是输入数据。预期输出是依据输入数据和
程序功能来确定的，也就是说，对于某一程序，输入数据确定了，预期输出也就可以确定了，至于
生成/销毁被测试对象和运行测试的语句，是所有测试用例都大同小异的，因此，我们讨论测试用
例时，只讨论输入数据。
前面说过，输入数据包括四类：参数、成员变量、全局变量、IO媒体，这四类数据中，只要所测试
的程序需要执行读操作的，就要设定其初始值，其中，前两类比较常用，后两类较少用。显然，把
输入数据的所有可能取值都进行测试，是不可能也是无意义的，我们应该用一定的规则选择有代表
性的数据作为输入数据，主要有三种：正常输入，边界输入，非法输入，每种输入还可以分类，也
就是平常说的等价类法，每类取一个数据作为输入数据，如果测试通过，可以肯定同类的其他输入
也是可以通过的。下面举例说明：
正常输入
例如字符串的Trim函数，功能是将字符串前后的空格去除，那么正常的输入可以有四类：前面有空
格；后面有空格；前后均有空格；前后均无空格。
边界输入
上例中空字符串可以看作是边界输入。
再如一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个：0和100。
非法输入
非法输入是正常取值范围以外的数据，或使代码不能完成正常功能的输入，如上例中表示年龄的参
数，小于0或大于100都是非法输入，再如一个进行文件操作的函数，非法输入有这么几类：文件不
存在；目录不存在；文件正在被其他程序打开；权限错误。

如果函数使用了外部数据，则正常输入是肯定会有的，而边界输入和非法输入不是所有函数都有。
一般情况下，即使没有设计文档，考虑以上三种输入也可以找出函数的基本功能点。实际上，单元
测试与代码编写是“一体两面”的关系，编码时对上述三种输入都是必须考虑的，否则代码的健壮
性就会成问题。

目前很多软件公司的单元测试还很不正规，只是由开发人员来简单地编译和调试一下自己的程序，
没有相应的单元测试计划、单元测试用例和代码覆盖率的统计。绝大部分程序员从骨子里不喜欢
写单元测试，这是不争的事实。

如何给程序员减压，但又能做好单元测试呢?
分配测试组的人去写单元测试，这其实是很有好处的。

这其中有一个值得一提的问题，大部分业务可以确定下来，但并非全部的业务。很多时候连客户
不知道自己真正要什么，实现了之后客户不满意，就要再整理需求再改代码。这种情况决定了不
可能先写测试再写实现，如果只写实现，那么客户要求改时只改实现代码，如果是先写单元测试
，那么改程序的时候要改两份代码

可以这样，已经确定的业务，先讨论这个模块的单元测试策略，双方指定单元测试的框架流程，
由测试人员编写单元测试代码。程序员写完代码后，由测试人员编写的单元测试代码去对碰程序
员的代码，得出相关的测试报告。
好处是，职责分离了，测试组的人能提前介入，对以后的集成测试很有好处。而且程序员的负担
减少了，虽然程序员不写单元测试代码了，但由于一开始跟测试人员在一起，会对测试流程熟悉，
对代码编写很有好处。对于没有确定的业务，就暂时先实现

梦想家