软件缺陷不只是通常所说程序中存在的错误或疏忽，即俗称的Bug。其范围更大，除程序外还包括其相关产品：项目计划、需求规格说明、设计文档、测试用例、用户手册等等中存在的错误和问题。需要强调，在软件工程整个生命周期中任何背离需求、无法正确完成用户所要求的功能的问题，包括存在于组件、设备或系统软件中因异常条件不支持而导致系统的失败等都属于缺陷的范畴。

　　软件测试的任务是发现软件系统的缺陷，保证软件的优良品质。但在软件中是不可能没有缺陷的。即便软件开发人员，包括测试人员尽了努力，也是无法完全发现和消除缺陷。我们无论做什么事情，首先要有个方向和目标。软件需求说明书是在做软件系统中起这样的作用。它确定系统的整体功能和环境，当然还有性能，及其他的方面。软件需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述软件需求。

　　关键的问题是一定要编写软件需求文档。我曾经听过一个项目中途更换了所有的开发者，客户被迫与新的软件需求分析者坐到一起。系统的分析人员说：“我们想与你谈谈你的软件需求。”客户的第一反应便是：“我已经将我的要求都告诉你们前任了，现在我要的是给我编一个系统”。而实际上，软件需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你确信你已明白用户的软件需求，那完全是自欺欺人。

　　软件需求的另外一种定义认为软件需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。有些软件需求分析专家拓展了这个概念：“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性：

　　软件需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

　　从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“软件需求”术语存在，真正的“软件需求”实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述软件需求的那些名词的理解上务必达成共识。

　　开发软件系统为困难的部分是准确说明开发什么。为困难的概念性工作便是编写出详细技术软件需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。

　　从以上定义可以发现，软件需求并未包括设计细节、实现细节、项目计划信息或测试信息。软件需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的软件需求，如开发环境软件需求或发布产品及移植到支撑环境的软件需求。尽管这些软件需求对项目成功也至关重要，但它们并非本书所要讨论的。

　　软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。软件测试需求也仅仅以为测试需求只是高级测试人员给后面的测试用例设计人员提供了测试用例的题目或者大纲，使测试用例的设计人员根据测试需求查漏补缺使设计出来的测试用例能够更有效，对需求覆盖更全面。尤其设计测试用例的人员可能是多人分工，可能造成他们只对自己负责的系统熟悉，但是对其他系统不太熟悉，测试需求可以减少因为测试用例设计者对软件整体系统的认识度不够造成测试用例设计上面的一些问题，所以我对测试需求的第一个认识是认为他可以指导设计测试用例。随着时间的推移，我逐渐明白了软件测试需求的另一个作用，是更好的做计划，你的测试需求越详细，那么是说明你测试的功能点的数量越清晰，换句话说，根据你写的测试需求，能够对软件测试的时间安排能够有个大体的估计，现在好多公司对测试都要求做计划安排，那么详细的测试需求不但可以使你可以制定出更有效的计划，同时也能使你的计划更有说服力，这使我明白了测试需求的另外一个作用，可以安排测试计划，并对自己的测试计划提供强有力的证据。可见软件测试需求对发现软件缺陷有多大重要。