定义一个手工测试场景
手工测试类型
一些测试专家在其所编著的经典著作中（如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（断开）状态下继续工作，同时应用程序可以将这个情况向用户报告，而且当连接断开时，不会产生有害后果。在不会引起混淆的情况下，本章后面将这个场景称为应用程序的收/发功能测试。
创建测试时，许多测试人员遇到的困难是他们无法定义一个完美的测试场景。我的建议是不要让这个困难妨碍测试，也是说一开始测试时，我们必须抛开一些次要因素，将来可以逐步完善测试。例如，在第一个场景中，我们可以在测试过程中执行其他一些工作，举例来说，我们可以观察当网络连接断开时，应用程序需要用多长时间才能够将此情况通知用户。但是当我们进行手工测试时，一开始并不需要强调将某项功能的响应时间作为测试是否通过的标准。
编写测试时，务必对测试过程中常见的错误加以考虑。也是说，当我们在编写测试描述及测试步骤时，必须牢记：在实际测试过程中，我们可能并不在测试现场。因此编写的测试必须尽可能地完整、尽可能地详尽。还要牢记的是：编写测试的人员未必是执行测试的人员，团队中其他成员也有可能在执行某个大型测试集的过程中执行某项手工测试，有时候，由于身份变更或任务变更，编写的手工测试还有可能移交到其他人员手中。因此，我们编写测试应尽可能的完整详尽，因为这样做不仅仅是为自己，也是为其他人。举例来说，某个测试人员在执行测试过程中，当他使用一台笔记本计算机进行测试时，一方面他断开了网线与计算机的连接，另一方面他却忘记了关闭笔记本计算机与无线网络之间的连接，这时我们原本希望能够看到错误出现，然而我们却没有得到任何错误提示。显然，这个测试执行过程是不正确的。我们在编写手工测试时，必须在手工测试中描述此类问题。
编写手工测试时，首先要描述测试目的，测试环境及其局限，以及执行测试时常犯错误，然后我们需要深入到测试场景之中。此时，我们必须详细列出测试步骤。在收/发功能这个例子中，测试场景非常简单，只有三个步骤：
（1） 运行应用程序。
（2） 启动应用程序的发送/接收功能。
（3） 将网络连接物理断开。
上述步骤执行结束后，下面要描述测试的预期执行结果。在这个例子中，我们要区分程序当时是否与邮件服务器连接，因为用户界面能够显示程序状态，因此我们根据图形用户界面来判断程序状态。此时用户界面应该显示Disconnected一词。在我们终创建的测试中，这个显示反馈的行为应该作为测试模板中的组成部分。
虽然我们仅仅给出了一个简单示例，但是只要将手工测试的其他方面考虑进来，我们可以编写出复杂的手工测试。编写手工测试时，我们还可以考虑的其他方面包括：可访问性（此时我们要确保即使用户视力不佳，也能够及时发现其测试工具提供的用户界面所发生的变化）、可用性（在一个可控制的环境中，令用户运行测试，测试目的在于检验以下情况：当用户突然无法收发邮件时，用户是否能够马上发现网络断开）、安全性（其他应用程序是否能够利用这个功能并造成不良后果？），以及地理政治方面的因素（当把Disconnected一词翻译为其他语言时，是否会造成误解或政治纠纷？）。
观察测试如何随时间流逝而发生演化也是一项重要工作。我们可以在测试中专门提供一个位置，在这个位置中我们可以将测试更新人员名单记录下来。这样当测试发生问题时，其他测试人员可以及时知道他们应该向谁咨询。
现在我们已经基本了解了测试场景应该是个什么样子。
