手工测试分析和总结.docx

手工测试

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

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

例如ifi〉0thena=1elsea=0

测试用例就要在i〉0i=0i0 中间各选择一个用例，比如 -506，这就覆盖了所有的类型。当然还有枚举覆盖，路径覆盖等不同的覆盖类型，还有就是要考虑到可能和不可能的类型，比

如上例i=ai=“你”会怎么样，那测试用例又要增加

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

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

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

对于某些测试，如果我们采用自动测试，可能导致投资回报率 (returnoninvestment，ROI)过低。例如，如果我们需要验证一个图形用户界面组件确实能够应用于某个软件产品中的某项功能

的开发，而这项功能又将被其他功能替换。此时，假设使用手工测试方法只需要花费 10秒时间，但是，如果使用自动测试，却需要花费几个小时甚至几天的时间编写测试，并且还要维护测试，那么

在这种情况下，我们显然应该使用手工测试来解决问题。

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

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

手工测试一般是基于后面两个原因： (1)时间资源不足；(2)技术水平不足。在这些情况下，手工测试能够发挥重要的作用。利用手工测试，我们可以定义测试，还可以跟踪测试，直到这些测试因

为产品变更被废弃为止。在许多开发团队中，手工测试是以工作任务清单形式存在的，而且将来可

以将这些内容进行自动化——除非这个团队采用手工测试的原因是前面两个因素，即： (1)自动化是不可能的；(2)测试自动化的投资回报率太低。

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

我们想定的场景非常简单，实际上许多测试都可以归结为一些简单步骤的集合。在本例中，用

户需要验证MicrosoftOutlook2007 可以顺利过渡到Disconnected(断开)状态下继续工作，同时应用程序可以将这个情况向用户报告，而且当连接断开时，不会产生有害后果。在不会引起混淆的情

况下，本章后面将这个场景称为应用程序的收 /发功能测试。

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

编写测试时，务必对测试过程中常见的错误加以考虑。也就是说，当我们在编写测试描述及测试步骤时，必须牢记：在实际测试过程中，我们可能并不在测试现场。因此编写的测试必须尽可能地完整、尽可能地详尽。还要牢记的是：编写测试的人员未必是唯一执行测试的人员，团队中其他

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

编写手工测试时，首先要描述测试目的，测试环境及其局限，以及执行测试时常犯错误，然后

我们需要深入到测试场景之中。此时，我们必须详细列出测试步骤。在收 /发功能这个例子中，测试场景非常简单，只有三个步骤：

运行应用程序。

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

将网络连接物理断开。

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

状态