开始测试

除了大爆炸模式之外，每一种模式中开发小组都要根据需求文档编写一份产品说明书，用以定义软件是什么样的。

产品说明书通常是利用文字和图形描述产品的书面文档。

确保最终产品符合客户要求以及正确计划测试投入的唯一方法是在产品说明书中完整描述产品。

编写详细产品说明书的另一个好处是软件测试员可以将其作为测试项目的书面材料，据此可以在编写代码之前找出软件缺陷。

黑盒测试和白盒测试

软件测试员用于描述测试方式的两个术语是黑盒测试和白盒测试。

在黑盒测试中，软件测试员只需知道软件要做什么——而无法看到盒子里的软件是如何运行的。只要进行一些输入，就能得到某种输出结果。他不知道软件是如何运行的。只要进行一些输入，就能得到某种输出结果。他不知道软件如何运行、为什么会这样，只知道程序做了什么。

在白盒测试（有时也称为透明盒测试）中，软件测试员可以访问程序员的代码，并通过检查代码的线索来协助测试——可以看到盒子里面。测试员根据代码检查结果判断或多或少可能出错的数目，并据此定制测试。

静态测试和动态测试

描述软件测试的另外两个术语是静态测试和动态测试。静态测试是指测试不运行的部分——只是检查和审核;动态测试是指通常意义上的测试——使用和运行软件。

对这些术语最好的一个类比是检查二手汽车的过程。踢一下轮胎、看看车漆、打开引擎盖检查都属于静态测试技术。发动汽车、听听发动机声音、上路行驶都属于动态测试技术。

静态黑盒测试——测试产品说明书

测试产品说明书属于静态黑盒测试。产品说明书是书面文档，而不是可执行程序，因此是静态的。

软件测试员可以利用书面文档进行静态黑盒测试，认真查找其中的缺陷。

如果项目没有产品说明书怎么办？这表明开发小组采用了大爆炸模式或者松散的边写边改模式。对于测试者而言，这是一种困难的情况。软件测试员的任务是尽早找出缺陷——最理想的是在软件代码编写之前——但是如果产品没有说明书，这显然是不可能的。尽管产品说明书没有写，然而总会有人知道产品是什么样的。这个人可能是开发人员、项目经理或销售人员。走路、谈话和产品说明书一样都使用同样的技术来评估“大脑中的”说明书，就好像它们写在纸上一样。记下收集到的信息并反复斟酌就可以得到更详细的资料。对开发小组说：“这是我准备测试和提交缺陷的内容。”他们很快就会补充很多细节。

对产品说明书进行高级审查

测试产品说明书的第一步不是马上钻进去找缺陷，而是站在一个高度上进行审查。审查产品说明书是为了找出根本性的问题、疏忽或遗留之处。也许这更像是研究而不是测试，但是研究的根本是为了更好地了解软件该做什么。如果能够很好地理解产品说明书的诸多为什么和怎么做，就可以更好地进行细节检查。

假设自己是客户

当软件测试员第一次接到需要审查的产品说明书时，最容易做的事是把自己当做客户。研究一下客户会是什么人;和市场人员或者销售人员聊一下，了解他们对最终用户的认识;如果产品是一个内部使用的软件项目，找到使用它的人谈一谈。

了解客户所想是很重要的。请记住，质量的定义是“满足客户要求”，软件测试员必须了解并测试软件是否符合那些要求。

研究现有的标准和规范

下面是可以考虑作为标准和规范的一些例子。但这并不是明确规定，对具体软件是否适用需经研究：

公司惯用语和约定

如果软件是为某公司定制的，就应该采用该公司职员常用的术语和约定。

行业要求

医药、工业和金融行业的应用软件有其必须严格遵守的标准。

政府标准

政府——特别是军队系统有严格的标准。

图形用户界面

如果软件运行在Microsoft Windows或者Apple Macintosh操作系统下，关于软件外观和用户的感受具有公开的标准。

安全标准

软件及其界面和协议可能需要满足一定的安全标准或级别。也许还需要进行独立的认证，以确保其满足必要的标准。

软件测试员的任务不是定义软件要符合何种标准和规范，这是项目经理或编写产品说明书的人的任务。软件测试员要做的是观察，“检查”采用的标准是否正确、有无遗漏。在对软件进行确认和验收时，还要注意是否与标准和规范相抵触，把标准和规范视为产品说明书的一部分。

审查和测试类似软件

了解软件最终结果的方法是研究类似软件，例如竞争对手的产品或者小组开发的类似产品。软件通常不会完全一样，但是类似软件有助于设计测试条件和测试方法，还可能暴露意想不到的潜在的问题。

在审查竞争产品时要注意的问题包括：

规模  软件的功能强大还是单一？代码多还是少？这些差别与测试有关吗？

复杂性  软件测试简单还是复杂？这会影响测试吗？

测试性  是否有足够的资源、时间和经验来测试软件？

质量和可靠性  软件是否完全满足质量要求？可靠性高还是低？

安全性  竞争对手软件的安全性（不管是宣称还是实际的）和自身的比较起来如何？

产品说明书的低层次测试技术

产品说明书属性检查清单

优秀产品说明书应具有8个重要的属性：

完整  是否有遗漏和丢失？完全吗？单独使用时是否包含所有内容？

准确  既定解决方案正确吗？目标定义明确吗？有没有错误？

精确、不含糊、清晰  描述是否一清二楚？是否有单独的解释？容易看懂和理解吗？

一致  产品功能描述是否自相矛盾，或与其他功能有无冲突？

贴切  描述功能的陈述是否必要？有没有多余信息？功能是否符合原来的客户要求？

合理  在规定的预算和进度下，以现有人力、工具和资源能否实现？

代码无关  产品说明书是否坚持定义产品，而不是定义其软件设计，而不是定义其软件设计、架构和代码？

可测试性  功能能否测试？给测试员提供的建立验证操作的信息是否足够？