这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨， 当编码完成以后并且面临代码测试任务的时候，
他们就阅读这些代码并找出它实际上做了什么， 把他们的测试工作基于已经写好的代码的基础上。 当然， 他们无法证明任何事情。
所有的这些测试工作能够表明的事情就是编译器工作正常。 是的， 他们也许能够抓住(希望能够)罕见的编译器Bug， 但是他们能够做的仅仅是这些。
如果他们首先写好一个详细的规格说明， 测试能够以规格说明为基础。 代码就能够针对它的规格说明， 而不是针对自身进行测试。
这样的测试仍然能够抓住编译器的Bug， 同时也能找到更多的编码错误， 甚至是一些规格说明中的错误。 好的规格说明可以使测试的质量更高，
所以最后的结论是高质量的测试需要高质量的规格说明。
在实践中会出现这样的情况： 一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。 你怎样做才会有更多的收获，
而不仅仅是发现编译器的Bug? 第一步是理解这个单元原本要做什么， --- 不是它实际上做了什么。 比较有效的方法是倒推出一个概要的规格说明。
这个过程的主要输入条件是要阅读那些程序代码和注释， 主要针对这个单元， 及调用它和被它调用的相关代码。 画出流程图是非常有帮助的，你可以用手工或使用某种工具。 可以组织对这个概要规格说明的走读(Review)， 以确保对这个单元的说明没有基本的错误， 有了这种最小程度的代码深层说明， 就可以用它来设计单元测试了。
3.3 我是个很棒的程序员， 我是不是可以不进行单元测试?
在每个开发组织中都至少有一个这样的开发人员， 他非常擅长于编程， 他们开发的软件总是在第一时间就可以正常运行， 因此不需要进行测试。
你是否经常听到这样的借口?
在真实世界里， 每个人都会犯错误。 即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。 但真正的软件系统是非常复杂的。
真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。
编码不是一个可以一次性通过的过程。 在真实世界中， 软件产品必须进行维护以对操作需求的改变作出反应，并且要对最初的开发工作遗留下来的Bug进行修改。 你希望依靠那些原始作者进行修改吗?
这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。
在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。
文章来源于领测软件测试网 https://www.ltesting.net/