从
测试方法的角度可以手工测试和
自动化测试。
手工测试：不使用任何的测试工具，根据事先设计好的
测试用例来运行系统，测试各功能模块。
自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理是录制、回放技术。
***手工测试
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
设计用例有很多原则，但是最基础的原则是覆盖性，就是要覆盖所有可能的种类（当然种类要自己区分）
例如if i〉0 then a=1 else a=0
测试用例就要在i〉0 i=0 i<0 中间各选择一个用例，比如-5 0 6，这就覆盖了所有的类型。
当然还有枚举覆盖，路径覆盖等不同的覆盖类型，还有就是要考虑到可能和不可能的类型，比如上例i=a i=“你”会怎么样，那测试用例又要增加
在测试过程中，手工测试的比重一般在30%左右。手工测试一般能够发现一些自动化测试所不能发现的问题，这也是为什么自动化测试取代不了手工测试的原因！
需要使用手工测试的场景包括以下四项：
● 如果某项测试
工作难以采用自动测试完成(甚至根本无法采用自动测试完成)，例如：在程序执行的关键时刻，我们需要从物理上断开一个网络连接，其目的在于验证程序处理错误条件的能力，此时我们就可以采用手工测试。
● 对于某些测试，如果我们采用自动测试，可能导致投资回报率(return on investment，ROI)过低。例如，如果我们需要验证一个图形用户界面组件确实能够应用于某个软件产品中的某项功能的开发，而这项功能又将被
其他功能替换。此时，假设使用手工测试方法只需要花费10秒时间，但是，如果使用自动测试，却需要花费几个小时甚至几天的时间编写测试，并且还要维护测试，那么在这种情况下，我们显然应该使用手工测试来解决问题。
● 需要使用自动测试，但是时间不允许进行自动测试的场合。
● 需要使用自动测试，但是开发团队当前技术水平尚不足以支持自动测试的场合。
手工测试一般是基于后面两个原因：(1)时间资源不足；(2)技术水平不足。在这些情况下，手工测试能够发挥重要的作用。利用手工测试，我们可以定义测试，还可以跟踪测试，直到这些测试因为产品变更被废弃为止。在许多开发团队中，手工测试是以工作任务清单形式存在的，而且将来可以将这些内容进行自动化——除非这个团队采用手工测试的原因是前面两个因素，即：(1)自动化是不可能的；(2)测试自动化的投资回报率太低。
探讨创建并运行一个手工测试的内部机制的过程中，我们必须记住创建手工测试的原因，和我们是如何创建手工测试的。
我们想定的场景非常简单，实际上许多测试都可以归结为一些简单步骤的集合。在本例中，用户需要验证Microsoft Outlook 2007可以顺利过渡到Disconnected(断开)状态下继续工作，同时应用程序可以将这个情况向用户报告，而且当连接断开时，不会产生有害后果。在不会引起混淆的情况下，本章后面将这个场景称为应用程序的收/发
功能测试。
创建测试时，许多测试人员遇到的困难是他们无法定义一个完美的测试场景。我的建议是不要让这个困难妨碍测试，也就是说一开始测试时，我们必须抛开一些次要因素，将来可以逐步完善测试。例如，在第一个场景中，我们可以在测试过程中执行其他一些工作，举例来说，我们可以观察当网络连接断开时，应用程序需要用多长时间才能够将此情况通知用户。但是当我们进行手工测试时，一开始并不需要强调将某项功能的响应时间作为测试是否通过的标准。
编写测试时，务必对测试过程中常见的错误加以考虑。也就是说，当我们在编写测试描述及测试步骤时，必须牢记：在实际测试过程中，我们可能并不在测试现场。因此编写的测试必须尽可能地完整、尽可能地详尽。还要牢记的是：编写测试的人员未必是唯一执行测试的人员，团队中其他成员也有可能在执行某个大型测试集的过程中执行某项手工测试，有时候，由于身份变更或任务变更，编写的手工测试还有可能移交到其他人员手中。因此，我们编写测试应尽可能的完整详尽，因为这样做不仅仅是为自己，也是为其他人。举例来说，某个测试人员在执行测试过程中，当他使用一台笔记本计算机进行测试时，一方面他断开了网线与计算机的连接，另一方面他却忘记了关闭笔记本计算机与无线网络之间的连接，这时我们原本希望能够看到错误出现，然而我们却没有得到任何错误提示。显然，这个测试执行过程是不正确的。我们在编写手工测试时，必须在手工测试中描述此类问题。
编写手工测试时，首先要描述测试目的，测试环境及其局限，以及执行测试时常犯错误，然后我们需要深入到测试场景之中。此时，我们必须详细列出测试步骤。
**自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：
1) 软件需求变动不频繁。
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
2) 项目周期足够长。
自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
3) 自动化测试脚本可重复使用。
如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。
另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如
性能测试、配置测试、大数据量输入测试等。
通常适合于
软件测试自动化的场合：
(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；
(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；
(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；
(4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖；
随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本期所要讨论的话题。
自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。
1) 自动化测试需求分析。
当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。
2) 自动化测试框架的搭建。
所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。
而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：
a. 公用的对象。
不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。
b. 公用的环境。
各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。
c. 公用的方法。
当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。
d. 测试数据。
也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。
在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。
