黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：

1）功能错误或遗漏；

2）界面错误；

3）数据结构或外部数据库访问错误；

4）性能错误；

5）初始化和终止错误。

白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：

1）如何测试功能的有效性？

2）何种类型的输入会产生好的测试用例？

3）系统是否对特定的输入值尤其敏感？

4）如何分隔数据类的边界？

5）系统能够承受何种数据率和数据量？

6）特定类型的数据组合会对系统产生何种影响？

运用黑盒测试方法，可以导出满足以下标准的测试用例集：

1）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；

2）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。

1）空测试对任何软件都是不充分的。

2）对任何软件都存在有限的充分测试集合。

3）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。

4）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。

5）即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。

6）软件测试的充分性应该与软件的需求和软件的实现都相关。

7）软件越复杂，需要的测试数据就越多。这一特性称为复杂性。

8）测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

在软件开发过程中，每产生一个文档，都必须对它进行测试，以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的，也与项目管理过程相一致。每当一个文档通过了静态测试，就标志着一项开发工作的总结，标志着项目取得了一定的进展，进入了一个新的阶段。

静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段，由于可运行的代码尚未产生，不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小，因此，在这些阶段，静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上，人们总结出了一些行之有效的静态测试技术和方法，如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合，对软件开发过程进行监视、控制，从而保障软件质量。

Brian Marick

测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。

在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。

测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：

1）插入一个新的条目

2）插入失败－条目已经存在

3）插入失败－表已满

4）哈希表在插入前为空

这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。

Roger S. Pressman

图形用户界面（GUI）对软件测试提出了有趣的挑战，因为GUI开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时，GUI的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在GUI设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见GUI测试的指南：

窗口：

·窗口是否基于相关的输入和菜单命令适当地打开？

·窗口能否改变大小、移动和滚动？

·窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？

·当被覆盖并重新调用后，窗口能否正确地再生？

·需要时能否使用所有窗口相关的功能？

·所有窗口相关的功能是可操作的吗？

·是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？

·显示多个窗口时，窗口的名称是否被适当地表示？

·活动窗口是否被适当地加亮？

·如果使用多任务，是否所有的窗口被实时更新？

·多次或不正确按鼠标是否会导致无法预料的副作用？

·窗口的声音和颜色提示和窗口的操作顺序是否符合需求？

·窗口是否正确地被关闭？

下拉式菜单和鼠标操作：

·菜单条是否显示在合适的语境中？

·应用程序的菜单条是否显示系统相关的特性（如时钟显示）？

·下拉式操作能正确工作吗？

·菜单、调色板和工具条是否工作正确？

·是否适当地列出了所有的菜单功能和下拉式子功能？

·是否可以通过鼠标访问所有的菜单功能？

·文本字体、大小和格式是否正确？

·是否能够用其他的文本命令激活每个菜单功能？

·菜单功能是否随当前的窗口操作加亮或变灰？

·菜单功能是否正确执行？

·菜单功能的名字是否具有自解释性？

·菜单项是否有帮助，是否语境相关？

·在整个交互式语境中，是否可以识别鼠标操作？

·如果要求多次点击鼠标，是否能够在语境中正确识别？

·光标、处理指示器和识别指针是否随操作恰当地改变？

数据项：

·字母数字数据项是否能够正确回显，并输入到系统中？

·图形模式的数据项（如滚动条）是否正常工作？

·是否能够识别非法数据？

·数据输入消息是否可理解？

Roger S. Pressman

通常，客户/服务器软件的测试发生在三个不同的层次：

1）个体的客户端应用以“分离的”模式被测试——不考虑服务器和底层网络的运行；

2）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；

3）完整的C/S 体系结构，包括网络运行和性能，被测试。

下面的测试方法是 C/S 应用中经常用到的：

应用功能测试——客户端应用被独立地执行，以揭示在其运行中的错误。

服务器测试——测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。

数据库测试——测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。

事务测试——创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。

网络通信测试——这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。

“每一个程序都能正确地做某件事，但是这并不是我们想要它作的事情。”这样的软件不能算一个质量好的软件。

我们如何定义软件质量呢？可以从不同的角度来看待软件质量并对其定义，它们有一些共同点：强调软件与得到了清晰描述的功能和性能需求的符合度、明显的文档标准以及被认为是所有专业开发的软件所具备的隐式特征。

ISO9126从如下几个方面来衡量软件质量：功能性、可靠性、可用性、可维护性、效率、可移植性。

如下三个方面应该尤其被重视：

1、软件需求是质量测度的基础。需求符合性的缺乏也就是缺乏质量；

2、特定的过程定义了一套开发标准，用以指导软件开发的方式。如果标准未能遵守，那么缺少质量就几乎是肯定的结论；

3、除了功能需求等显示的需求外，要对非功能的隐式需求重视（例如，对好的可维护性的期望）。如果软件符合其他显式的需求，但是未能满足隐式需求，软件质量仍然是值得怀疑的。

软件质量是一个多因素的复杂混合，这些因素随着不同的应用和需要它们的用户而变化。测试时需要根据一定的质量标准有针对性的进行测试。

Roger S. Pressman

许多基于计算机的系统必须在一定的时间内从错误中恢复过来，然后继续运行。在有些情况下，一个系统必须是可以容错的，这就是说，运行过程中的错误不能使整个系统的功能都停止。在其他情况下，一个系统错误必须在一个特定的时间段之内改正，否则就会造成严重损失。

恢复测试是通过各种手段，让软件强制性地发生故障，然后来验证恢复是否能正常进行的一种系统测试方法。如果恢复是自动的（由系统本身来进行的），重新初始化、检查点机制、数据恢复和重启动都要进行正确验证。如果恢复是需要人工干预的，那么要估算修复的平均时间是否在可以接受的范围之内。

Roger S. Pressman

任何管理敏感信息或者能够对个人造成不正当伤害的计算机系统都是不正当或非法侵入的目标。侵入包括了范围很广的活动：只是为练习而试图侵入系统的黑客；为了报复而试图攻破系统的有怨言的雇员；还有为了得到非法的利益而试图侵入系统的不诚实的个人。

安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。引用 Beizer 的话来说：“系统的安全当然必须能够经受住正面的攻击——但是它也必须能够经受住侧面的和背后的攻击。”

在安全测试过程中，测试者扮演着一个试图攻击系统的个人角色。测试者可以尝试去通过外部的手段来获取系统的密码，可以使用可以瓦解任何防守的客户软件来攻击系统；可以把系统“制服”，使得别人无法访问；可以有目的地引发系统错误，期望在系统恢复过程中侵入系统；可以通过浏览非保密的数据，从中找到进入系统的钥匙；等等。

只要有足够的时间和资源，好的安全测试就一定能够最终侵入一个系统。系统设计者的任务就是要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息的价值。