创建测试时，许多测试人员遇到的困难是他们无法定义一个完美的测试场景。我的建议是不要让这个困难妨碍测试，也是说一开始测试时，我们必须抛开一些次要因素，将来可以逐步完善测试。例如，在第一个场景中，我们可以在测试过程中执行其他一些工作，举例来说，我们可以观察当网络连接断开时，应用程序需要用多长时间才能够将此情况通知用户。但是当我们进行手工测试时，一开始并不需要强调将某项功能的响应时间作为测试是否通过的标准。

　　编写测试时，务必对测试过程中常见的错误加以考虑。也是说，当我们在编写测试描述及测试步骤时，必须牢记：在实际测试过程中，我们可能并不在测试现场。因此编写的测试必须尽可能地完整、尽可能地详尽。还要牢记的是：编写测试的人员未必是执行测试的人员，团队中其他成员也有可能在执行某个大型测试集的过程中执行某项手工测试，有时候，由于身份变更或任务变更，编写的手工测试还有可能移交到其他人员手中。因此，我们编写测试应尽可能的完整详尽，因为这样做不仅仅是为自己，也是为其他人。举例来说，某个测试人员在执行测试过程中，当他使用一台笔记本计算机进行测试时，一方面他断开了网线与计算机的连接，另一方面他却忘记了关闭笔记本计算机与无线网络之间的连接，这时我们原本希望能够看到错误出现，然而我们却没有得到任何错误提示。显然，这个测试执行过程是不正确的。我们在编写手工测试时，必须在手工测试中描述此类问题。

　　编写手工测试时，首先要描述测试目的，测试环境及其局限，以及执行测试时常犯错误，然后我们需要深入到测试场景之中。此时，我们必须详细列出测试步骤。在收/发功能这个例子中，测试场景非常简单，只有三个步骤：

　　（1） 运行应用程序。

　　（2） 启动应用程序的发送/接收功能。

　　（3） 将网络连接物理断开。

　　上述步骤执行结束后，下面要描述测试的预期执行结果。在这个例子中，我们要区分程序当时是否与邮件服务器连接，因为用户界面能够显示程序状态，因此我们根据图形用户界面来判断程序状态。此时用户界面应该显示Disconnected一词。在我们终创建的测试中，这个显示反馈的行为应该作为测试模板中的组成部分。

　　虽然我们仅仅给出了一个简单示例，但是只要将手工测试的其他方面考虑进来，我们可以编写出复杂的手工测试。编写手工测试时，我们还可以考虑的其他方面包括：可访问性（此时我们要确保即使用户视力不佳，也能够及时发现其测试工具提供的用户界面所发生的变化）、可用性（在一个可控制的环境中，令用户运行测试，测试目的在于检验以下情况：当用户突然无法收发邮件时，用户是否能够马上发现网络断开）、安全性（其他应用程序是否能够利用这个功能并造成不良后果？），以及地理政治方面的因素（当把Disconnected一词翻译为其他语言时，是否会造成误解或政治纠纷？）。

　　观察测试如何随时间流逝而发生演化也是一项重要工作。我们可以在测试中专门提供一个位置，在这个位置中我们可以将测试更新人员名单记录下来。这样当测试发生问题时，其他测试人员可以及时知道他们应该向谁咨询。

　　现在我们已经基本了解了测试场景应该是个什么样子。