手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。

设计用例有很多原则，但是最基础的原则是覆盖性，就是要覆盖所有可能的种类（当然种类要自己区分）

例如if i〉0 then a=1 else a=0

当然还有枚举覆盖，路径覆盖等不同的覆盖类型，还有就是要考虑到可能和不可能的类型，比如上例i=a i=“你”会怎么样，那测试用例又要增加

在测试过程中，手工测试的比重一般在30%左右。手工测试一般能够发现一些自动化测试所不能发现的问题，这也是为什么自动化测试取代不了手工测试的原因！

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

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

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

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

手工测试一般是基于后面这几个原因：(1)时间资源不足；(2)技术水平不足。(3)项目周期过短。（4）机器不可代替。在这些情况下，手工测试能够发挥重要的作用。利用手工测试，我们可以定义测试，还可以跟踪测试，直到这些测试因为产品变更被废弃为止。在许多开发团队中，手工测试是以工作任务清单形式存在的，而且将来可以将这些内容进行自动化——除非这个团队采用手工测试的原因是前面两个因素，即：(1)自动化是不可能的；(2)测试自动化的投资回报率太低。

探讨创建并运行一个手工测试的内部机制的过程中，我们必须记住创建手工测试的原因，和我们是如何创建手工测试的。

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

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

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

(1) 运行应用程序。

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

(3) 将网络连接物理断开。

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

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

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

我们已经基本了解了测试场景应该是个什么样子。下面我们使用手工测试类型创建一个测试。

手工测试类型包括纯文本格式和Microsoft Word格式，Microsoft Word格式可以支持丰富格式文本，并可以嵌入图像和表格。创建一个新的手工测试时，我们可以选择两种格式之一，这两种格式分别是：

● Manual Test(text format)(*.mtx)——编辑手工测试时，我们可以在IDE中用文本格式编辑测试。如果没有安装Microsoft Word，那么我们还可以使用Visual Studio编辑手工测试。

● Manual Test(Microsoft Word format)(*.mht)——我们可以使用Microsoft Word作为手工测试编辑工具。Microsoft Word为我们提供了丰富的编辑功能。例如利用这种格式，我们可以在手工测试中嵌入图像，并且可以使文字呈现多种色彩、字体、字级和风格。

1. 文本格式通过阅读本书，读者可以掌握如何通过不同的途径达到同一个目的。例如，我们既可以在Solution Explorer中用鼠标右击一个现有的项目来创建一个手工测试，也可以在Test菜单中单击New Test菜单项来创建一个手工测试。无论选择哪种方法，我们在Add New Test对话框中选中Manual Test (text format)测试类型后，系统都会弹出一个测试模板。

创建一个新的测试类型后，这个新创建的测试随即处于打开状态，我们可以对这个测试进行编辑。手工测试类型也是如此。现在，Visual Studio编辑器已经打开了一个纯文本格式的手工测试，我们现在可以编辑这个手工测试了。

利用上述测试Microsoft Outlook 2007同步行为的测试示例(也就是当Microsoft Outlook 2007执行同步操作时，网络突然断开，此时我们要对Outlook的行为进行测试)，给出了一个完整的测试模板。

2. Microsoft Word格式如果我们在Add New Test 对话框中选择了Manual Test (Word format)，那么系统将显示一个类似的测试模板，唯一的区别就是我们可以使用不同的编辑工具——当前我们可以使用Microsoft Word(可以看到，我们当前使用了Microsoft Word 2003)完成手工测试的编辑工作。与纯文本格式相比，使用Microsoft Word格式可以编辑更为丰富的内容，例如我们可以嵌入屏幕快照，还可以嵌入表格和格式化文本。

zip文件。当然，如果采用了这种修改方式，那么我们必须针对每一种语言进行设置。

我们在View菜单中选中Properties Window菜单项，就可以看到Visual Studio Properties窗口。在Test View窗口或Test Manager窗口中单击某个手工测试后，我们就可以在Properties窗口中看到该测试的属性。具体情况。

如果读者当前尚未打开Test View窗口或Test Manager窗口，那么请读者在View菜单中选择Properties Window菜单项，就可以打开Test View窗口或Test Manager窗口。

我们可以将当前测试的任意一个属性添加到Test View窗口或Test Manager窗口中，这样，我们可以基于该属性的属性值对手工测试进行过滤或分组。

一个手工测试包括表1-1所示的属性。

表 1-1

如果读者需要了解如何在连接到一个Visual Studio Team Foundation Server项目的情况下完成测试工作，请阅读第9章的内容。

执行测试时最常用的两个窗口分别是Test Manager窗口(该窗口仅在VSTEST中可用)和Test View窗口(该窗口在VSTEST和VSTESD中均可用)。我们可以通过选择Test菜单中的Windows菜单项打开Test View窗口。如果读者创建了两个手工测试，那么在打开Test View窗口后，在Test View窗口中，读者可以看到两个手工测试，这两个手工测试都称为ManualTest1。具体情况。

用鼠标右击Test Name属性列(也可以单击Test View窗口中的任意一列属性)，我们可以从下拉菜单(也就是上下文菜单)中选中Add/Remove Columns菜单项。此时系统弹出Add/Remove Columns对话框。这个对话框用一个列表显示了所有的属性，我们可以对这些属性进行排序(我们只要单击该列表的标题就可以完成排序操作)、过滤(需要输入一个关键词，并选择一个属性列，针对该属性列，利用这个关键词进行过滤)和分组(因为该窗口很小，所以可以单击Test View窗口最右端的工具条上的overflow按钮，然后选中对测试进行分组的属性就可以完成分组操作)。

为了解释如何在Test View窗口中增加一列属性，以及如何根据某个属性对测试进行分组，下面我们用一些测试对此进行说明。首先我们在测试项目中添加一些测试，将Owner属性显示为一个属性列，然后在Group By位置处，选择测试类型。

我们在Test View窗口中执行的所有操作都同样可以应用于Test Manager窗口，但是，正如我们在第2章所讨论的那样，在Test View窗口中，我们还可以将测试分组为不同列表。

执行一个手工测试与执行其他测试没有什么不同。为了选中一个测试，我们可以在Test Manager窗口中或在Test View窗口中单击一个测试，如果需要选中多个测试，那么在按下Shift键的同时，我们可以选中鼠标两次单击范围内的所有测试；此外在按下Ctrl键的同时，我们还可以选中一组不同的测试。

选中测试后，单击Test Manager窗口中或Test View窗口中的工具条上的Run Selection图标。令鼠标指针在工具条每个按钮上方悬停片刻，我们可以观察到每个按钮的描述信息，从而可以了解该按钮的具体功能。

我们知道，在Visual Studio中，为了完成某项工作，可以采用多种不同的方法。观察窗口中的工具条，我们可以发现，对于某项通过单击工具条按钮可以完成的操作，通过用鼠标右击属性列或对象后，利用上下文菜单，同样可以完成这项操作。此外，当我们在一个窗口中工作时，主窗口一般都会为我们提供一个工具条，帮助我们在当前窗口迅速完成工作。这一点对测试也同样成立：主窗口菜单下方的Test Tools工具条可以帮助我们在测试窗口中迅速完成相关工作。为了显示Test Tools工具条，我们可以在View菜单中选中Toolbars子菜单，然后再选择Test Tools菜单项，就可以显示出Test Tools工具条。

启动执行手工测试之后，我们马上可以看到一个信息提示，通知我们当前运行的测试包含了一个手工测试。出现这个信息提示的原因是：当我们执行一组测试时，如果当前运行的测试包含了一个手工测试，那么运行这些测试的测试人员可以没有意识到这种情况将会导致测试发生暂停。有的时候，测试人员启动一个大型测试之后去吃午饭，然而，当他们吃完午饭后返回办公室时却发现，他们离开后大概一分钟，测试就已经暂停下来等待手工干预，这种情况确实令人非常不快，常常使人充满了挫折感。

测试开始执行后，Visual Studio将读取当前测试的运行配置信息(我们在第2章讨论了运行配置信息)，从而可以确定需要复制那些文件，是否需要插装被测试程序来收集代码覆盖信息等内容。Visual Studio根据测试列表中的内容，一个接一个地执行测试，当遇到一个手工测试时，将显示一条诸如“Manual Test ‘manualtest1’ is ready for execution”(手工测试manualtest1已准备好执行)之类的信息。此时，测试暂停并等待测试人员根据手工测试步骤一步步地完成手工测试过程，测试人员需要根据他们所观察到的结果判断该手工测试是否通过。在Visual Studio IDE中，手工测试显示为一个标签文档(tabbed document)，显示内容非常类似。

这个标签文档包括四个部分的内容：

● Apply工具条按钮——只有当测试人员单击了该文档中Select Result分组部分中的Pass or Fail选项按钮后，这个按钮才会成为活动的。

● Select Result分组——在这个分组中包括两个选项按钮，即Pass选项按钮和Fail选项按钮。利用这两个选项按钮，测试人员可以确定手工单步执行测试脚本的测试结果。

● Comments文本框——在这个文本框中输入的信息可以保存为测试结果，如果测试发生失效，那么测试工程师可以在这个文本框中输入更为详细的失效信息。

●测试脚本视图——这个标签文档窗口的底部给出了测试脚本的内容。测试人员可以利用Visual Studio内置的文本编辑器或Microsoft Word编写测试脚本。

如果读者使用Microsoft Word编写手工测试，那么当测试执行时，请读者注意测试人员所看到的表格和嵌入图片的显示方式。纯文本格式的测试版本可能会对相关内容进行大幅度简化。

测试人员确定测试输出结果后，单击Apply按钮，随即可以看到Test Results窗口，这个窗口显示了测试输出结果。单击Apply按钮后，用于为测试人员显示手工测试脚本的标签文档窗口也同时变为只读的。这个文档窗口已经成为当前运行测试历史的组成部分了。

最后，我们说明一下手工测试类型存在的不足之处(此处所说的不足之处，系指除了需要人工交互之外的其他不足之处)。如果某个测试需要在远程计算机上运行，那么手工测试是不能作为这个测试的组成部分的；此外，如果某个测试被配置为验证一个团队完成的某个构建的稳定性，那么这类测试无法作为这个测试的组成部分来执行；最后，这类测试无法用命令行工具(即mstest.exe)来执行。之所以存在这些问题，其根本原因都是因为手工测试需要人工干预，而我们很难远程执行手工测试，也就是说，这个功能要求执行测试的远程计算机停止运行，并且在继续执行之前提示用户采取行动。因为这会导致无法事先预料的测试暂停(因为测试人员可能会忘记测试中包括了手工测试)，而团队也常常没有时间来解决这些方面的问题，所以我们可以采用的唯一解决方案是：将手工测试步骤打印出来，带到实验室，然后在某台合适的计算机上运行手工测试。完成测试后，返回办公室，在本地计算机上运行手工测试，然后根据测试过程中发现的情况，将测试结果标记为Passed或Failed。确实，这种方法不是最优方法，但是在产品开发时间的限制下，我们常常无法及时实现手工测试，所以我们也只能采用这个办法。