手工测试类型

　　一些测试专家在其所编著的经典著作中（如Cem Kaner博士编著的Testing Computer Software、Boris Beizer编著的Black-Box Testing等）广泛讨论了如何编写手工测试；某些软件测试专家如Elisabeth Hendrickson，在其课程中也对如何编写手工测试给予了关注（http://www.qualitytree.com）。因此在本章我们不打算于讨论如何有效地编写手工测试，同时，我们还要研究手工测试在Visual Studio环境中的创建机制和执行机理。手工测试是指由操作人员手工执行某个测试脚本内容的测试过程。与手工测试对应的是自动测试，即由计算机执行源代码的测试过程。

　　需要使用手工测试的场景包括以下四项：

　　● 如果某项测试工作难以采用自动测试完成（甚至根本无法采用自动测试完成），例如：在程序执行的关键时刻，我们需要从物理上断开一个网络连接，其目的在于验证程序处理错误条件的能力，此时我们可以采用手工测试。

　　● 对于某些测试，如果我们采用自动测试，可能导致投资回报率（return on investment，ROI）过低。例如，如果我们需要验证一个图形用户界面组件确实能够应用于某个软件产品中的某项功能的开发，而这项功能又将被其他功能替换。此时，假设使用手工测试方法只需要花费10秒时间，但是，如果使用自动测试，却需要花费几个小时甚至几天的时间编写测试，并且还要维护测试，那么在这种情况下，我们显然应该使用手工测试来解决问题。

　　● 需要使用自动测试，但是时间不允许进行自动测试的场合。

　　● 需要使用自动测试，但是开发团队当前技术水平尚不足以支持自动测试的场合。

　　手工测试一般是基于后面两个原因：

　　（1）时间资源不足；

　　（2）技术水平不足。

　　在这些情况下，手工测试能够发挥重要的作用。利用手工测试，我们可以定义测试，还可以跟踪测试，直到这些测试因为产品变更被废弃为止。在许多开发团队中，手工测试是以工作任务清单形式存在的，而且将来可以将这些内容进行自动化--除非这个团队采用手工测试的原因是前面两个因素，即：

　　（1）自动化是不可能的；

　　（2）测试自动化的投资回报率太低。

　　定义一个手工测试场景

　　现在我们继续讨论先前给出的测试示例，考虑如何对网络连接物理断开时程序处理错误的能力进行测试。在我们探讨创建并运行一个手工测试的内部机制的过程中，我们必须记住创建手工测试的原因，和我们是如何创建手工测试的。

　　我们想定的场景非常简单，实际上许多测试都可以归结为一些简单步骤的集合。在本例中，用户需要验证Microsoft Outlook 2007可以顺利过渡到Disconnected（断开）状态下继续工作，同时应用程序可以将这个情况向用户报告，而且当连接断开时，不会产生有害后果。在不会引起混淆的情况下，本章后面将这个场景称为应用程序的收/发功能测试。