第 8 贴【 2004 － 5 － 17 】：软件测试策略
Roger S. Pressman
测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤。
人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。
软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。
第 9 贴【 2004 － 5 － 18 】：白盒测试
Rex Black
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1 ）保证一个模块中的所有独立路径至少被使用一次；
2 ）对所有逻辑值均需测试 true 和 false ；
3 ）在上下边界及可操作范围内运行所有循环；
4 ）检查内部数据结构以确保其有效性。
“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？ ” 答案在于软件自身的缺陷：
1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ” 的处理则难于发现。
2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。
正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。
第 10 贴【 2004 － 5 － 19 】：黑盒测试
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：
1 ）功能错误或遗漏；
2 ）界面错误；
3 ）数据结构或外部数据库访问错误；
4 ）性能错误；
5 ）初始化和终止错误。
白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
1 ）如何测试功能的有效性？
2 ）何种类型的输入会产生好的测试用例？
3 ）系统是否对特定的输入值尤其敏感？
4 ）如何分隔数据类的边界？
5 ）系统能够承受何种数据率和数据量？
6 ）特定类型的数据组合会对系统产生何种影响？
运用黑盒测试方法，可以导出满足以下标准的测试用例集：
1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。
第 11 贴【 2004 － 5 － 20 】：软件测试充分性准则
（ 1 ）空测试对任何软件都是不充分的。
（ 2 ）对任何软件都存在有限的充分测试集合。
（ 3 ）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。
（ 4 ）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
（ 5 ）即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
（ 6 ）软件测试的充分性应该与软件的需求和软件的实现都相关。
（ 7 ）软件越复杂，需要的测试数据就越多。这一特性称为复杂性。
（ 8 ）测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。
第 12 贴【 2004 － 5 － 21 】：静态测试
在软件开发过程中，每产生一个文档，都必须对它进行测试，以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的，也与项目管理过程相一致。每当一个文档通过了静态测试，就标志着一项开发工作的总结，标志着项目取得了一定的进展，进入了一个新的阶段。
静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段，由于可运行的代码尚未产生，不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小，因此，在这些阶段，静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上，人们总结出了一些行之有效的静态测试技术和方法，如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合，对软件开发过程进行监视、控制，从而保障软件质量。
第 13 贴【 2004 － 5 － 22 】：什么是测试需求？
Brian Marick
测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。
在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。
测试的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。
这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1 ）插入一个新的条目
2 ）插入失败－条目已经存在
3 ）插入失败－表已满
4 ）哈希表在插入前为空
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。
第 14 贴【 2004 － 5 － 30 】： GUI 测试
Roger S. Pressman
图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南：
窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？
下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？
数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？
第 15 贴【 2004 － 5 － 31 】： Client/Server 测试
Roger S. Pressman
通常，客户 / 服务器软件的测试发生在三个不同的层次：
（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。
下面的测试方法是 C/S 应用中经常用到的：
应用功能测试 —— 客户端应用被独立地执行，以揭示在其运行中的错误。
服务器测试 —— 测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。
数据库测试 —— 测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。
事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。
网络通信测试 —— 这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。
