本文转载自http://blog.csdn.net/kkshizhu520/archive/2007/12/04/1915438.aspx
   
    单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

    在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中， 要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。

    单元测试不仅仅是作为无错编码的一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。

    Visual Studio 2008 单元测试功能介绍

一、测试代码与被测代码分离成独立的两个项目

    单元测试中，测试的代码不能对被测试的代码施加影响。如果将测试代码写入被测试的代码中，测试完成后再删除的话，测试的正确性将得不到保证。因此，在Visual Studio 2008种提供了一种“Test Project”的项目，测试代码写在Test Project中，并且测试工程可以进行重复使用。

二、测试代码的自动生成

    书写测试代码是一件很烦琐的事情，这些代码没有像程序代码一样具有“创造性”，因此该部分代码可以进行自动化生成。Visual Studio 2008就提供了一个自动生成测试代码的测试框架。利用Visual Studio 2008自动生成的代码，只需要很少的改动就可以完成整个测试程序。

三、测试管理

    Visual Studio 2008提供了测试列表来进行测试工作的管理工作，我们需要一个反映目前测试状况的工具，那些测试通过了，那些没有通过，应该提供一个列表来为我们改进测试手段，进行更全面的测试提供指导。
 
    利用Visual Studio 2008来进行单元测试

    假设我们有一个类BankAccount，该类定义了一个银行的账户，私有属性_currentBalance是银行储户的账户金额，depositMoney是存款方法，对帐户增加一笔资金，makePayment是支付方法，对账户减少一笔资金。代码如下：

 

    要对BankAccount类进行单元测试，只需要在BankAccount的定义处鼠标右键，在菜单中选择“Create Unit Tests”即可进入测试项目的创建工作。如下图所示：

 

    在弹出的创建单元测试的对话框中，对需要创建测试的方法和属性进行选择，然后点击“OK”按钮，如图所示：

    紧接着在出现的文本框中输入测试项目的名称“BankAccountDemo.Business.Tests”，点击确定后，测试项目被创建。在这里“BankAccountDemo.Business.”只是用于更好的对命名空间进行规划，完全可以直接使用“BankAccountDemoTest”来作为测试项目的名字。
生成的测试代码如下，为了紧凑的表现代码，将注释代码作了删除。

这个时候的代码并不能开始测试，而需要我们按照测试用例的要求将测试用例的数据加入到测试方法中，并进行结果的比较，修改后的depositMoneyTest方法如下：

 

[TestMethod()]

public void depositMoneyTest()

{

    float initialBalance = 0F; // TODO: Initialize to an appropriate value

    BankAccount target = new BankAccount(initialBalance); // TODO: Initialize to an appropriate value

    float depositAmount = 100F; // TODO: Initialize to an appropriate value

    target.depositMoney(depositAmount);

    Assert.AreEqual(initialBalance + depositAmount, target.CurrentBalance, "Deposit Test: Deposit not applied correctly");

 }

     鼠标右键在depositMoneyTest方法内任意位置单击，在弹出的菜单中选择“Run Tests”，即可以对该方法进行测试。在“Test Results”窗口中显示测试的结果，如下图所示：

 

 

    可以看出，Visual Studio 2008给我们提供了一个功能强大，操作简单的单元测试功能。利用该功能，程序员在编写代码后，可以马上对所编写的类进行单元测试，通过了程序员自行组织的单元测试后再将代码交给测试人员进行进一步测试。

    总结：微软将单元测试功能从Visual Studio 2005 Team System开始集成到开发环境中，是经过了微软公司多年的实践经验证明的。如今，开发环境从以前的单一开发功能，将关注点分散到软件的整个生命周期过程中来，已经成为一个ALM平台。软件开发人员不仅需要做开发工作，而且需要对自己开发的代码进行单元测试，不能将所有的问题全部抛给测试人员。测试人员可以将更多的精力放在系统一级的测试工作上面。

软件单元测试工具比较

一、JTEST

1、简介：

jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类，然后自动生成junit测试用例并执行用例，从而实现代码的最大覆盖，并将代码运行时未处理的异常暴露出来；另外，它还可以检查以DbC（Design by Contract）规范开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的junit用例。Jtest还能按照现有的超过350个编码标准来检查并自动纠正大多数常见的编码规则上的偏差，用户可自定义这些标准，通过简单的几个点击，就能预防类似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。

2、优势：

1）使预防代码错误成为可能，从而大大节约成本，提高软件质量和开发效率

2）使单元测试——包括白盒、黑盒以及回归测试成为可能

3）使代码规范检查和自动纠正成为可能

4）鼓励开发团队横向协作来预防代码错误

3、特征：

1）通过简单的点击，自动实现代码基本错误的预防，这包括单元测试和代码规范的检查

2）生成并执行junit单元测试用例，对代码进行即时检查

3）提供了进行黑盒测试、模型测试和系统测试的快速途径

4）确认并阻止代码中不可捕获的异常、函数错误、内存泄漏、性能问题、安全弱点的问题

5）监视测试的覆盖范围

6）自动执行回归测试

7）支持DbC编码规范

8）检验超过350个来自java专家的开发规范

9）自动纠正违反超过160个编码规范的错误

10）允许用户通过图形方式或自动创建方式来自定义编码规范

11）支持大型团队开发中测试设置和测试文件的共享

12）实现和IBM Websphere Studio /Eclipse IDE 的安全集成

4、价格：昂贵

二、JMETER

1、简介：

JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。使用JMeter进行性能测试

2、特征：

JMeter可以用于测试静态或者动态资源的性能（文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源）。JMeter用于模拟在服务器、网络或者其他对象上附加高负载以测试他们提供服务的受压能力，或者分析他们提供的服务在不同负载条件下的总性能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下测试服务器/脚本/对象的行为。

3、价格：未知

三、JUNIT

1、简介：

JUnit是一个开源的java测试框架，它是Xuint测试体系架构的一种实现。在JUnit单元测试框架的设计时，设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个则是可以利用既有的测试来编写相关的测试。

2、优势：

2.1)junit是完全Free的。

2.2)使用方便。在你提升程序代码的品质时JUnit测试仍允许你更快速的撰写程序 那听起来似乎不是很直觉，但那是事实。当你使用JUnit撰写测试，你将花更少的时间除虫，同时对你程序代码的改变更 俱有信心。这个信心让你更积极重整程序代码并增加新的功能。没有测试，对于重整及增加新功能你会变得没有信心；因为你不知道有甚么东西会破坏产出的结果。采用一个综合的测试系列，你可以在改变程序代码之后快速的执行多个测试并对于你的变动并未破坏任何东西感到有信心。在执行测试时如果发现臭虫，原始码仍然清楚的在你脑中，因此很容易找到臭虫。在JUnit中撰写的测试帮助你以一种极 大(extreme)的步伐撰写程序及快速的找出缺点。

2.3)JUnit非常简单撰写测试应该很简单--这是重点！如果撰写测试太复杂或太耗时间，便无法要求程序设计师撰写测试。使用JUnit你可以快速的撰写测试并检测你的程序代码并逐 步随着程序代码的成长增加测试。只要你写了一些测试，你想要快速并频繁的执行测试而不至于中断建立设计及开发程序。使用JUnit执行测试就像编译你的程序代码那么容易。事实上，你应该执行编译时也执行测试。编译是检测程序代码的语法而测试是检查程序代码的完整性(integrity)。

2.4)JUnit测试检验其结果并提供立即的回馈。 如果你是以人工比对测试的期望与实际结果那么测试是很不好玩的，而且让你的速度慢下来。JUnit测试可以自动执行并且检查他们自己的结果。当你执行测试，你获得简单且立即的回馈； 比如测试是通过或失败。而不再需要人工检查测试结果的报告。

2.5)JUnit测试可以合成一个测试系列的层级架构。 JUnit可以把测试组织成测试系列；这个测试系列可以包含其它的测试或测试系列。JUnit测试的合成行为允许你组合多个测试并自动的回归(regression)从头到尾测试整个测试系列。你也可以执行测试系列层级架构中任何一层的测试。

2.6)撰写JUnit测试所费不多。 使用Junit测试框架，你可以很便宜的撰写测试并享受由测试框架所提供的信心。撰写一个测试就像写一个方法一样简单；测试是检验要测试的程序代码并定义期望的结果。这个测试框架提供自动执行测试的背景；这个背景并成为其它测试集合的一部份。在测试少量的投资将持续让你从时间及品质中获得回收。

2.7)JUnit测试提升软件的稳定性。 你写的测试愈少；你的程序代码变的愈不稳定。测试使得软件稳定并逐步累积信心；因为任何变动不会造成涟漪效应而漫及整个软件。测试可以形成软件的完整结构的胶结。

2.8)JUnit测试是开发者测试。 JUnit测试是高度区域性(localized)测试；用以改善开发者的生产力及程序代码品质。不像功能测试(function test)视系统为一个黑箱以确认软件整体的工作性为主，单元测试是由内而外测试系统基础的建构区块。开发者撰写并拥有JUnit测试。每当一个开发反复(iteration)完成，这个测试便包裹成为交付软件的一部份提供一种沟通的方式，「这是我交付的软件并且是通过测试

2.9)JUnit测试是以Java写成的。 使用Java测试Java软件形成一个介于测试及程序代码间的无缝(seamless)边界。在测试的控制下测试变成整个软件的扩充同时程序代码可以被重整。Java编译器的单元测试静态语法检查可已帮助测试程序并且确认遵守软件接口的约定。

一段测试的程序代码无法单独的执行，它需要是执行环境的一部份。同时，它需要自动执行的单元测试--譬如在系统中周期性的执行所有的测试以证明没有任何东西被破坏。由于单元测试需要符合特定的准则：一个成功的测试不应该是人工检查的（那可要到天荒地老了啊），一个未通过测试的失败应可以产出文件以供诊断修改。而Junit可以提供给我们这些便利.。这样所有测试开发者所需撰写的只是测试码本身了。跟optimizeit、Jtest那些昂贵而又超级麻烦的tool比较起来，其利昭然可见！

3、价格：免费

RFT,QTP,ROBOT工具比较小结

前提：

RFT使用时间：2个月

QTP使用时间：1个月

ROBOT使用时间：36个月

 

之所以用“小结”是就目前我使用的情况而言的，因为毕竟我对RFT和QTP使用并不是很长时间，下面我将对我使用过的几点，将三个工具加以对照：

 

1.       脚本语言：RFT使用的是JAVA, QTP使用的是VB，ROBOT使用的是SQABasic ；

 

2.       对象识别能力：RFT对象识别能力比ROBOT有了很大的提高，与QTP的对象识别能力不相上下。RFT与QTP都用到了对象库技术，即在录制脚本时，把录制的每个控件作为一个对象记录在对象库里。而且这个对象库里的内容一般是不让修改的（就目前使用的试用版RFT而言，对中文的支持很不友好，在界面上识别的中文全部是乱码）。

 

3.       录制脚本：QTP在录制时不是只录你操作的对象，而是把所有出现在页面上的控件作为对象全部记录下来，这样就导致我们在录脚本时，必须把页面上所有控件的内容改动一下，如果不是这样的话，回放很难成功。举个例说一下：在线预订时，在录制时没有选择日期，入住日期默认是当天的日期，用QTP录制时在它的对象库里会记录下这个入住日期，在第二天回放该脚本时，则不会成功，因为QTP会把日期改为录的那一天，而且这个值不能在脚本里改，这个值在对象库里改不了。一般的解决办法是重新录，这样导致这个脚本的维护性很低。而在ROBOT和RFT中，这点确表现的很好，录什么则记录什么，也可以追加录制，很灵活方便。

 

4.       日志记录能力：RFT的日志记录能力最强。它可以形成HTML日志或TEXT日志或记录在TESTMANAGER里。而且除了文档，它还可以生成伪视频，捕捉在出错前的一个短视频。

 

5.       文本编辑能力：三者之中QTP最弱，ROBOT次之，RFT最强。而且RFT是基于ECLIPS编辑器的，所以编辑功能比之前的ROBOT大大加强。

 

6.       回放速度：QTP的回放速度最快，ROBOT和RFT差不多。

 

7.       数据池：QTP的数据池最简单，不用设计变量类型，而ROBOT和RFT的都要复杂些，特别是RFT还需要指出类型所在的包。

 

8.       对系统资源要求：RFT对系统资源的要求最高，在默认设置下，RFT的回放需要700多M内存，而且是就这一个工具运行而言。

QTP 工具的使用在经过了5天早起的折磨和全英语授课的磨难后， 终于培训完了， 培训归培训， 需要的是持续的学习和大量的实践， 在同时经历过QTP和RObot的培训后，今天想说一些我感觉中的QTP 和Robot 的区别（针对自动化测试部分）：

1， QTP的确比较容易上手，操作也比较人性话，这也是大家公认的，

2， QTP 在9.1版本中增强了 Object Repository 功能，增加了Object Repository Manager 功能 可以让定义过或者曾经识别过的Object在其他录制脚本中重复使用， 这是robot 没有的功能。

3，在录制过的脚本中需要进行增加某些步骤时，QTP使用了KeyWord－Driven的概念， 可以手动设置，

   Robot 在则可以通过 Insert at Cursor 方式 进行插入录制， 这里是各有各的好处。 

4，QTP 如果想要在某个test flow 中使用某个录制过的action， 需要将该action设置为reused，

    Robot 只需要语句call 就可以完成。

5，Robot 可以通过环境变量设置自行启动和运行的时间，和Test manager 协作自动按照顺序运行某些脚本。

   QTP 我还没有了解到相关的功能。

6，QTP 支持 c/s 架构的程序还是不如 Robot， 起码对于我目前测试的 .net 程序来说， QTP居然不识别一些常用控件， robot 则完全没有问题。

7， Robot 检查点更多一些， 比如windows Existence 和Alphanumeric有特别提出来作为检查点。

上面只是我学习之后最直观的一些想法，可能由于使用深度的原因有些出入， 也欢迎大家指正。

很多初入行的朋友使用测试工具进行功能测试的时候,总是会遇到QTP和WinRunner的选择问题,为什么同样一家公司会出两个功能类似的工具哪? 下面是一篇关于这两个工具的对比介绍,其实从我自己的经验来看,WinRunner虽然推出较早,但是因为一些功能的缺陷,导致后期很难推广,而Quick Test Professinal(QTP)虽然没有师兄WinRunner出道早,然后内功深厚,所以很受欢迎,而且Mercury公司以后的主要发展策略是QTP,虽然文章中说并没有计划Phase out WR,但是已经不再出新版本了. 针对这两个工具的3年左右的使用经验,我的感受是WR比QTP的逊色的地方主要是几点:

1. WR的对象管理不如QTP那么有效

2. WR的语言主要是基于类C的TSL,是Mercury发明的语言,明显不如基于VBscrīpt的QTP强

3. WR的稳定性不行,而且无意人为的干扰可能导致回放的失败

4. WR对Java的支持也不如QTP那么强

   Winrunner是专门用于C/S和B/S架构功能测试的自动化测试工具.其强项在C/S架构功能测试上,B/S功能测试更适合于MERCURY公司的另一大测试工具QTP.在QTP的专栏中有介绍.
   WINRUNNER通过插件的形式支持包括DELPHI\JAVA\ORACLE\PEOPLE\SAP\.NET在内的众多主流语言和数据库,目前已经出到了9.2版.

   Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

第一章：软件详细设计评审 一、 课程设计 1.详细设计文档的文档格式、规范 　　介绍如何根据根据概要设计文档完成详细设计文档，并且，保证详细设计文档可以指导后续的编码和单元测试工作； 2.伪码写作注意事项 　　通过实例讲解详细设计的伪码写作规范，讲解详细设计评审的要点； 3.实践环节 　　教师提供两份典型的详细设计案例给学员作为参考。并且提供一份详细设计，由学员完成详细设计的评审工作，找出详细设计中的缺陷； 第二章：单元测试理论 一、课程设计 1. 测试理论基础 2. 什么是单元测试 3. 单元测试的基本方法 4. 桩和驱动 5. 单元测试策略 6. 单元测试过程 7. 单元测试辅助工具 第三章：单元测试用例设计 一、课程设计 1、代码逻辑覆盖方法介绍 1) 代码逻辑覆盖方法： 　　 重点介绍代码逻辑覆盖率的若干种方法，包括代码覆盖、分支覆盖、条件覆盖、分支条件覆盖、路径覆盖几种方法； 2) 代码逻辑覆盖率统计工具： 　　教师结合代码逻辑覆盖率统计工具，可视化的展现代码逻辑覆盖的基本思路和方法； 3) 代码逻辑覆盖率案例和课堂练习 　　教师针对每种覆盖方法提供案例讲解，并且提供课堂练习，由学员分析案例种的代码逻辑覆盖率； 2、基于基本路径覆盖和循环覆盖的单元测试用例设计 1) 基本路径覆盖方法介绍： 　　介绍在单元测试中使用的设计方法——基本路径覆盖方法和循环覆盖方法； 2) 基本路径覆盖方法： 　　详细阐述基本路径覆盖法的使用方法和原则，教师列举案例，并且为学员提供课堂练习； 3) 循环覆盖方法： 　　详细阐述循环覆盖法中的简单循环、嵌套循环、连锁循环、非结构循环四种方法，并且针对每种方法给出案例解释，并分别提供课堂练习； 3、黑盒用例设计方法介绍 1) 边界值方法 　　 讲解边界值方法设计单元测试用例方法和步骤，教师提供案例讲解 2) 等价类方法 　　 讲解等价类设计单元测试用例的方法和设计步骤，教师提供案例讲解，并且提供4种不同类型的等价类划分的课堂练习； 　　 总结等价类和边界值分析的优点和缺点，以及使用的场合限制； 3) 正交试验法 　　讲解正交表的原理，通过案例讲解正交试验法设计单元测试用例的具体方法；并且提供5种不同类型的正交试验法设计单元测试用例的课堂练习； 4) 错误猜测法 　　通过案例讲解错误猜测法设计单元测试用例的方法； 4、单元测试用例设计方法的整合使用方法 　 　整合黑盒测试用例设计方法、基本路径覆盖法、循环覆盖法、以及测试过程中补充单元测试用例的方法，提供整合后的单元测试用例设计的基本思路； 第四章：软件单元测试相关工具 一、课程设计 1、代码静态检查工具pc-lint使用 2、代码逻辑覆盖率检测工具使用 3、实践环节 　　学员通过课堂练习，掌握代码静态检查工具、覆盖率检查工具的使用方法和技巧； 第五章：TCL语言 一、课程设计 1、Tcl概述 　　总体介绍Tcl脚本的特点，以及Tcl脚本在自动化测试领域里面的应用情况。 2、Tcl基本语法 　　Tcl是一门容易上手的语言，本课程通过对比C语言和Tcl脚本语言，讲解Tcl语言的使用方法，以及在使用Tcl语言时候的注意事项。 3、Tcl实践 　　结合教师提供的题目，学员完成课堂实践，通过实践学员掌握Tcl的基本使用方法。为后续的自动化测试框架搭建做好准备工作。 第六章：单元测试执行－tcl方式 一、课程设计 1、Tcl扩展指令 　　Tcl的扩展指令是Tcl在自动化测试领域里面应用的关键所在，本小节讲解Tcl脚本如何与C语言混合编程的方法，以及扩展指令的设计方法。 2、结合Tcl扩展指令搭建自动化测试框架 　　讲解如何结合Tcl扩展指令，搭建基于关键字的自动化测试框架搭建方法，以及类似批处理方式的自动化测试框架搭建方法 3、结合Tcl扩展指令搭建自动化测试框架的课堂实践 　　在教师的指导下，学员完成集合Tcl扩展指令搭建自动化测试框架的课堂实践 4、基于扩展指令的数据驱动自动化测试方法 　　在基于关键字驱动的自动化测试框架基础上，讲解如何实现数据驱动方式的自动化测试框架搭建方法。数据驱动的自动化测试框架可以实现测试用例和测试脚本的分离。 5、基于扩展指令的数据驱动自动化测试方法 　　在教师的指导下，学员完成基于数据驱动方式的自动化测试框架搭建活动。 第七章：单元测试执行-CPPUNIT方式 一、课程设计 1、CppUnit概述 2、CppUnit基本概念 3、CppUnit单元测试框架 4、利用CppUnit进行单元测试实践 　　学员利用cppunit搭建单元测试环境，并结合代码覆盖率工具完成课堂练习；

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。 正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。
    软件错误的状态
新信息(New)：测试中新报告的软件缺陷；
打开 (Open)：被确认并分配给相关开发人员处理；
修正(Fixed)：开发人员已完成修正，等待测试人员验证；
拒绝(Declined):拒绝修改缺陷；
延期(Deferred): 不在当前版本修复的错误，下一版修复
关闭(Closed)：错误已被修复；

Bug管理的一般流程
 测试人员提交新的Bug入库，错误状态为New。
高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。
开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。
    软件错误流程管理要点
为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。
绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。

作者：钱亦嵘  发表时间:2006-6-15 12:46:23

【摘要】本文从为什么要引入自动化测试出发，深入探讨了企业实施自动化测试的流程。

【关键词】自动化测试自动化测试工具

前言

大家知道，在国内测试行业属于一个新兴行业，与国外测试行业相比，国内也只是近几年才开始重视软件测试的。之所以被关注，原因也许是多方面的，但我想最根本一点就是中国软件要发展。

中国软件这几年发展迅速，很大部分原因是借鉴了国外优秀企业的经验技术，从无到有，学习了国外企业的一整套做事的规范，的确是一种快速成长方法。当然软件测试也应该如此，从不重视到重视，更应该多学习一下如何制定测试流程，缺陷管理以及测试用例设计等优秀理念。在此笔者只想针对自动化测试在企业中的实施谈些个人意见，希望能和大家分享。

当然，自动化测试作为一项新技术，一开始往往会被一些人认为是“无所不能”的，以为一旦有了它就可以解决软件所有的质量问题。难道自动化测试就是传说中所谓的“银弹”吗？结果当然是否定的。假如在实施前没有好好的调查、做好预期准备工作就盲目开展，一旦进入推广实施阶段，往往最终会弄得无法收场的结果。下面让我们先来解决一个问题。

为什么要引入自动化测试

首先，按照笔者的观点，用自动化工具进行测试只不过是测试活动中的一种。真正要在工作中派上用场，也是因为测试工作有了人的参与，而使用工具的目的也只不过是用来减少部分手工测试，将更多人力资源投入到更有价值的工作中，决不能轻重不分。

其次，既然要跟上国际潮流，那么自动化测试技术就是将来大部分测试工程师需要必备的一项技能。这也是笔者为什么要写这篇文章的出发点，希望能帮助大家推动自动化测试在企业中的实施。当然首先要保证一点，要实施自动化测试的企业必须符合具备开展自动化测试的一些先决条件。

笔者就有这样的感受，在企业中，如果想把自动化测试技术应用到工作生产中，没有持之以恒的恒心，坚忍不拔的决心，高度的自信心，是不可能完成这个工作的。那么怎样的时机是有利于开展自动化测试的？实施过程中该注意什么？采用什么策略去避免不必要的损失，提高大家对新技术的兴趣是很有讲究的。下面笔者将一一做出解答。

企业实施自动化流程

1）至关重要的是公司的高层必须认同成立测试部门是很重要的，不是浪费公司的资源；这一点，其实很早就应该达成共识，因为像Microsoft这样的公司也说过“大多数人认为我们是一个软件开发公司，其实我们是一家软件测试公司”的话，从中可以看出测试是非常重要的。然而考虑到公司的长远发展，自动化测试将是今后的一个发展方向。由此看来，自动化测试是有必要深入开展的。

2）在公司大规模使用前，必须要有专人针对不同的自动化测试，去评估究竟该使用哪种测试工具比较好。自动化测试工具又分单元测试工具、功能自动化工具和性能自动化工具，其中又分开源的和商业工具。究竟哪种工具更适合自己公司平台的测试，还需要有专业人员进行评估。

第一、比如说公司是采用Java技术还是.NET技术开发产品的。大多数商用工具都会根据现今最流行的开发平台提供一种自动化测试的解决方案。做测试工具比较专业的有Mercury，Segue，IBM Rational，Compuware，Empirix这几家公司，根据不同测试又有相应的测试工具。

第二、如果考虑到商业软件比较昂贵，还可以考虑一下开源的测试工具。这些工具往往具有小巧，灵活多变，免费的特性，还有个好处就是它的开源。现在全世界范围已经有越来越多的人投入到开源项目中去。已经比较出名的有Apache的Jmeter，Jtest，OpenStar等等。就连全球最大的IT公司IBM现在也把目光聚焦到了这块，由IBM出资1000多万的开源项目Eclipse，在过去也许是唯一一个能和JBuilder开发环境相媲美的开源的开发环境了。但现在在此平台上有了TPTP，但我们同样可以在Eclipse上做我们的功能和性能测试

第三、也许以上工具都无法满足测试的特殊需求，那最好的方法就是自行开发测试工具；这主要集中在嵌入式系统方面。比如手机与手机之间需要做到即时、无误的发送短消息，而一般常用的工具是没有办法做到这方面测试的，那就只能考虑公司内部自己开发测试工具了。

第四、还有就是在选用工具方面，还要充分考虑到工具的可集成性、可扩展性以及平台兼容性。因为实际工作中，我们常常需要把测试流程，需求管理，缺陷管理，配置管理结合的更紧密，通过工具去统一管理。这些都是在选用工具时要考虑到的因素。

3）在全面实施之前，根据以往的经验，笔者建议最好选出几个人进行小规模的实验。这样做的好处一来可以以小见大，从几个人的反映看出自动化测试的雏形；二来可以总结不足之处，在后期的开展中尽量避免；三来，可以把实施所见的成效推广开来，为后期工作的开展做好铺垫。

笔者在企业里就有类似的经历，一个项目已经上线，以后每次发布一个补丁之前，测试人员都需要通过执行一些SIT(System Integration TestCase)测试用例来覆盖整个系统的大部分模块。而执行一遍这样的用例，至少需要花费六个测试人员一天的时间。后来在这个项目内进行了自动化测试的实验，根据SIT的测试用例转换成自动化脚本。运行一个用例脚本只需要十五分钟，而每次也只需要一个测试人员把所有脚本运行一遍就可以了，其他人就可以从中解放出来做其他工作了。像这样比较成功的例子，一定要在后期工作开展时加以宣传，要认大家认识到自动化好处，这样大家才会有积极性去学。

4）有了上面的经验，接下来该在整个部门进行自动化测试的推广了。当然适当给从业人员进行工具的使用技能以及一些相关知识培训还是有必要的。因为在工作中常常发现由于测试工程师掌握知识的差距，每个人对工具上手操作有快有慢。为了尽量给大家造成好的影响，能够更好的开展这项工作，使其能更快的应用到日常工作中去，减轻部分繁琐的重复性劳动，对测试工程师进行培训还是必不可少的。

5）正如软件生命周期有需求分析阶段一样，在录制自动化脚本之前也需要收集需求,这些需求主要是用于后期录制脚本的选取。这些需求可以根据需求人员做的需求文档，也可以选择测试人员的测试用例来转化成脚本，还可以让需求分析人员推荐几个常用的，相对简单的流程转化成脚本。总之一句话，需求就好比源头，从源头抓起才能开发出高质量的脚本。

6）做了前面一系列准备工作，已经有了一个好的开始。接下来就要求大家进行一次头脑风暴，对刚收集来的需求进行分析，设计出一个好的实现方案。这里我想强调两点：

第一、工具只能帮助测试人员去更好的进行测试，至于怎样使用才能提高工作效率，还是需要测试人员在实施前期进行更多的思考，比如思考如何把一个好的设计转化成我们后期的自动化脚本等。因为脚本是不会创造性的发现本身没有涉及到的缺陷，就好比许多测试人员编写测试用例，如果你没有把你要测试的功能点写入测试用例中，根据测试用例执行人员是不会考虑到这一点的。因此设计一个全面，详细的设计方案显得尤其重要。

第二、出于程序可复用的角度考虑，按照怎样的划分粒度，如何把脚本进行好的规划也很重要。例如：将一些使用率高的模块录制成共享脚本，使用者只需要通过一些参数进行使用，无须考虑到内部的具体实现机制。这样还可以大大减少大家的重复劳动量。

7）对工具有了一定认识以后，就到了上手操练阶段。俗话说：“拳不离手，曲不离口”。由于前期投入大量精力、人力、物力，现在正是出成果的时候。但在开发脚本之前，笔者还有几点想着重申明一下：

第一、开发脚本必须遵循一些规范化，就类似于程序员编程规范一样。我们的测试脚本就好比是我们测试人员的程序，同样要形成一个编写规范。因为养成这样的好习惯，是为了能方便维护脚本，避免增加后期的维护量和方便使用者使用；

第二、保证开发的脚本回放没有问题的基础上，适当增加出错处理来增强脚本；

第三、后期还可以在脚本中加入检查点，这样做的好处可以把原来需要人工去校验的地方让脚本去做；

第四、在脚本中增加数据驱动方法，使脚本能覆盖更多的分支路径，进一步提高脚本的集成度。因为前面已经说过了，脚本是不会执行那些没有被编写进去的功能点的，所以说后期测试人员一旦发现这个地方有必要让脚本来代替手工进行执行，就可以不断的增强我们的自动化脚本。

8）最后，切记任何工作的开展并非一朝一夕，新技术的开展将需要投入大量人力物力，而自动化测试就是我们测试工程师必须要坚持的一个长期的发展方向。为了不至于做事只做表面，建议每个测试团队中都必须要有专人去负责推动自动化工作的开展。还必须有专人负责维护脚本，规范脚本，甚至可以引入配置管理工具来统一管理脚本和把经验文档化。只有这样我们的测试财富才会从中不断积累，只有这样自动化测试才能走得更远。

以上总结了几点，都是笔者在企业中推行自动化测试的一些心得体会。最后希望能够有更多人从自动化测试中获得快乐，从繁琐的手工测试中解脱出来。

文章出处：www.51testing.com 作者：Bret Pettichord 译者：王威 发布时间：2005-10-19
 
【摘要】 我们对自动化测试充满了希望，然而，自动化测试却经常带给我们沮丧和失望。虽然，自动化测试可以把我们从困难的环境中解放出来，在实施自动化测试解决问题的同时，又带来同样多的问题。在开展自动化测试的工作中，关键问题是遵循软件开发的基本规则。本文介绍自动化测试的 7 个步骤：改进自动化测试过程，定义需求，验证概念，支持产品的可测试性，具有可延续性的设计（ design for sustainability ），有计划的部署和面对成功的挑战。按照以上 7 个步骤，安排你的人员、工具和制定你的自动化测试项目计划，你将会通往一条成功之路。

一个故事 :

我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。

以前，我们有一个软件项目，开发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具，最后选择了一种，并且购买了几份拷贝。她委派一位员工 ——Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作，还有其他的很多任务。他尝试使用刚刚购买的自动化测试工具。当把测试工具应用到软件产品测试中的时候，遇到了问题。这个测试工具太复杂，难于配置。他不得不给测试工具的客户支持热线打了几个电话。最后， Jerry 认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。在打过几个电话后，测试工具厂商派过来一位技术专家。技术专家到达后，找出问题所在，测试工具可以正常工作了。这还算是顺利了。但是，几个月后，他们还是没有真正实现测试自动化， Jerry 拒绝继续从事这个项目的工作，他害怕自动化测试会一事无成，只是浪费时间而已。

项目经理 Anita 把项目重新指派给 Kevin Shorttimer ，一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚获得计算机科学的学位，希望通过这份工作迈向更有挑战性的、值得去做的工作。 Anita 送 Kevin 参加工具培训，避免 Kevin 步 Jerry 的后尘 —— 由于使用测试工具遇到困难而变得沮丧，导致放弃负责的项目。 Kevin 非常兴奋。这个项目的测试需要重复测试，有点令人讨厌，因此，他非常愿意采用自动化测试。一个主要的版本发布后， Kevin 准备开始全天的自动化测试，他非常渴望得到一个机会证明自己可以写非常复杂的，有难度的代码。他建立了一个测试库，使用了一些技巧的方法，可以支持大部分的测试，这比原计划多花费了很多时间，不过， Kevin 使整个测试工作开展的很顺利。他用已有的测试套测试新的产品版本，并且确实发现了 bug 。接下来， Kevin 得到一个从事软件开发职位的机会，离开了自动化的岗位。

Ahmed Hardluck 接手 Kevin 的工作，从事自动化测试执行工作。他发现 Kevin 留下的文档不仅少，并且没有太多的价值。 Ahmed 花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。这个过程中， Ahmed 经历了很多失败，并且不能确信测试执行的方法是否正确。测试执行中，执行失败后的错误的提示信息也没有太多的参考价值，他不得不更深的钻研。一些测试执行看起来仿佛永远没有结束。另外一些测试执行需要一些特定的测试环境搭建要求，他更新测试环境搭建文档，坚持不懈地工作。后来，在自动化测试执行中，它发现几个执行失败的结果，经过分析，是回归测试的软件版本中有 BUG ，导致测试执行失败，发现产品的 BUG 后，每个人都很高兴。接下来，他仔细分析测试套中的内容，希望通过优化测试套使测试变得更可靠，但是，这个工作一直没有完成，预期的优化结果也没有达到。按照计划，产品的下一个发布版本有几个主要的改动， Ahmed 立刻意识到产品的改动会破坏已有的自动化测试设计。接下来，在测试产品的新版本中，绝大多数测试用例执行失败了， Ahmed 对执行失败的测试研究了很长时间，然后，从其他人那里寻求帮助。经过商讨，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。最后，大家根据新接口修改自动化测试，测试都通过了。产品发布到了市场上。接下来，用户立刻打来投诉电话，投诉软件无法工作。大家才发现自己改写了一些自动化测试脚本，导致一些错误提示信息被忽略了。虽然，实际上测试执行是失败的，但是，由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。这个产品终于失败了。

这是我的故事。或许您曾经亲身经历了故事当中某些情节。不过，我希望你没有这样的相似结局。本文将给出一些建议，避免出现这样的结局。

问题

这个故事阐明了几个使自动化测试项目陷入困境的原因：

自动化测试时间不充足：根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间，无法得到真正的关注。

缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。但是，自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。

缺乏经验：尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。

更新换代频繁（ High turnover ）：测试自动化往往需要花费很多时间学习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。

对于绝望的反应：在测试还远没有开始的时候，问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言，测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。

不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。

关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。

遵守软件开发的规则

你可能了解 SEI （软件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分为 5 个界别，该模型用来对软件开发组织划分等级。 Jerry Weinberg （美国著名软件工程专家）也创建了自己的一套软件组织模型，在他的组织模型中增加了一个额外的级别，他称之为零级别。很显然，一个零模式的组织实际上也是开发软件；零模式组织中，在开发人员和用户之间没有差别 [Weinberg 1992] 。恰恰在这类组织环境中，经常采用自动化测试方法。因此，把资源用于自动化测试，并且把自动化测试当作一个软件开发活动对待，把软件测试自动化提升到一级。这是解决测试自动化的核心的方案。我们应该像运作其他的开发项目一样来运作软件自动化测试项目。

像其他软件开发项目一样，我们需要软件开发人员专注于测试自动化的开发任务；像其他软件开发项目一样，自动化测试可以自动完成具体的测试任务，对于具体的测试任务来说，自动化开发人员可能不是这方面的专家，因此，软件测试专家应该提供具体测试任务相关的咨询，并且提供测试自动化的需求；像其他软件开发项目一样，如果在开发编码之前，对测试自动化作了整体设计有助于测试自动化开发的顺利开展。像其他软件开发项目一样，自动化测试代码需要跟踪和维护，因此，需要采用源代码管理。像其他软件开发项目一样，测试自动化也会出现 BUG ，因此，需要有计划的跟踪 BUG ，并且对修改后的 BUG 进行测试。像其他软件开发项目一样，用户需要知道如何使用软件，因此，需要提供用户使用手册。

本文中不对软件开发做过多讲述。我假定您属于某个软件组织，该组织已经知道采用何种合理的、有效的方法开发软件。我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。本文按照在软件开发项目中采用的标准步骤组织的，重点关注测试自动化相关的事宜和挑战。

•  改进软件测试过程

•  定义需求

•  验证概念

•  支持产品的可测试性

•  可延续性的设计（ design for sustainability ）

•  有计划的部署

•  面对成功的挑战

步骤一：改进软件测试过程

如果你负责提高一个商业交易操作的效率，首先，你应该确认已经很好的定义了这个操作的具体过程。然后，在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前，你想知道是否可以采用更简单、成本更低的的方法。同样的，上述过程也是用于自动化测试。我更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。

例如，很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行，再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行，并且单调乏味。怎样才能做好回归测试文档化的工作呢？通常的做法是采用列有产品特性的列表，然后对照列表检查。这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。

在你开始测试自动化之前，你需要完善上面提到的回归测试检查表，并且，确保你已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。如果测试掌握了基本的产品知识，这会更好。确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果，这些通常被忽略，建议测试人员知道。太多的测试人员没有意识到他们缺少什么，并且由于害怕尴尬而不敢去求助。这样一份详细的文档给测试小组带来立竿见影的效果，因为，现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。不过，这时候千万不要走极端去过分细致地说明测试执行的每一个步骤，只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。但是，不要假定他们理解那些存留在你头脑中的软件测试执行的想法，把这些测试设计的思路描述清楚就可以了。

我以前负责过一个软件模块的自动化测试工作。这个模块的一些特性导致实现自动化非常困难。当我了解到这项工作无需在很短的时间内完成后，决定制定一个详细回归测试设计方案。我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷，针对每个缺陷，我写了一个能够发现该问题的测试执行操作。我计划采用这种方法提供一个详细的自动化需求列表，这可以告诉我模块的那一部分最适合自动化测试。在完成上述工作后，我没有机会完成测试自动化的实现工作。不过，当我们需要对这个模块做完整回归测试的时候，我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。依照文档的指导，几乎不需要任何指导的情况下，各自完成了回归测试，并且发现了 BUG 。从某种角度看，这实际上是一次很成功的自动化测试。在这个项目中，我们与其开发自动化测试脚本，还不如把测试执行步骤文档化。后来，在其它项目中，我们开发了自动化测试脚本，发现相关人员只有接受相关培训才能理解并执行自动化测试脚本，如果测试自动化设计的很好，可能会好一些。不过，经过实践我们总结出完成一份设计的比较好的测试文档，比完成一份设计良好的测试脚本简单的多。

另外一个提高测试效率的简单方法是采用更多的计算机。很多测试人员动辄动用几台计算机，这一点显而易见。我之所以强调采用更多的计算机是因为，我曾经看到一些测试人员被误导在单机上努力的完成某些大容量的自动化测试执行工作，这种情况下由于错误的使用了测试设备、测试环境，导致测试没有效果。因此，自动化测试需要集中考虑所需要的支撑设备。

针对改进软件测试过程，我的最后一个建议是改进被测试的产品，使它更容易被测试，有很多改进措施既可以帮助用户更好的使用产品，也可以帮助测试人员更好的测试产品。稍后，我将讨论自动化测试的可测试需求。这里，我只是建议给出产品的改进点，这样对手工测试大有帮助。

一些产品非常难安装，测试人员在安装和卸载软件上花费大量的时间。这种情况下，与其实现产品安装的自动化测试，还不如改进产品的安装功能。采用这种解决办法，最终的用户会受益的。另外的一个处理方法是考虑开发一套自动安装程序，该程序可以和产品一同发布。事实上，现在有很多专门制作安装程序的商用工具。

另一些产品改进需要利用工具在测试执行的日志中查找错误。采用人工方法，在日志中一页一页的查询报错信息很容易会让人感到乏味。那么，赶快采用自动化方法吧。如果你了解日志中记录的错误信息格式，写出一个错误扫描程序是很容易的事情。如果，你不能确定日志中的错误信息格式，就开始动手写错误扫描程序，很可能面临的是一场灾难。不要忘记本文开篇讲的那个故事中提到的测试套无法判断测试用例是否执行失败的例子。最终用户也不愿意采用通过搜索日志的方法查找错误信息。修改错误信息的格式，使其适合日志扫描程序，便于扫描工具能够准确的扫描到所有的错误信息。这样，在测试中就可以使用扫描工具了。

通过改进产品的性能对测试也是大有帮助的。很显然的，如果产品的性能影响了测试速度，鉴别出性能比较差的产品功能，并度量该产品功能的性能，把它作为影响测试进度的缺陷，提交缺陷报告。

上面所述的几个方面可以在无需构建自动化测试系统的情况下，大幅度的提高测试效率。改进软件测试过程会花费你构建自动化测试系统的时间，不过改进测试过程无疑可以使你的自动化测试项目更为顺利开展起来。

步骤二：定义需求

在前面的故事中，自动化工程师和自动化测试的发起者的目标存在偏差。为了避免这种情况，需要在自动化测试需求上保持一致。应该有一份自动化测试需求，用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。很多人认为自动化测试显然是一件好事情，但是，他们不愿意对自动化测试的目标给出清晰的描述。下面是人们选用自动化测试的几个原因：

•  加快测试进度从而加快产品发布进度

•  更多的测试

•  通过减少手工测试降低测试成本

•  提高测试覆盖率

•  保证一致性

•  提高测试的可靠性

•  测试工作可以由技术能力不强测试人员完成

•  定义测试过程，避免过分依赖个人

•  测试变得更加有趣

•  提高了编程技能

开发管理、测试管理和测试人员实现自动化测试的目标常常是有差别的。除非三者之间达成一致，否则很难定义什么是成功的自动化测试。

当然，不同的情况下，有的自动化测试目标比较容易达到，有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高，测试人员必须能理解充分的理解自动化测试，从而通过自动化测试不断发现软件的缺陷。不过，自动化测试不利于测试人员不断的积累测试经验。不管怎么样，在开始自动化测试之前应该确定自动化测试成功的标准。

手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源，建立测试环境，执行测试用例。测试过程中，如果有什么异常的情况发生，手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果，记录测试结果，复位被测试的软件系统，准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况，研究测试过程可疑的现象，寻找测试用例执行失败的过程，设计并执行其他的测试用例帮助定位软件缺陷。接下来，他们写作缺陷报告单，保证缺陷被修改，并且总结所有的缺陷报告单，以便其他人能够了解测试的执行情况。

千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分，部分的采用自动化测试是最好的方法。或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择，或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。我听到有人讲，除非测试的各个环节都采用自动化方式，否则不是真正意义上的自动化测试，这真是胡言乱语。如果仅仅是为了寻找挑战，可以尝试在测试的每个环节都采用自动化方法。但是，如果寻找成功测试的方法，请关注那些可以快速建立的，可以反复利用的自动化测试。

定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。通过定义自动化测试需求，距离成功的自动化测试近了一步。

步骤三：验证概念

在前面的故事当中，那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。不过，在项目的进行中，他得到了来自各个方面的支持。

你可能还没有认识到这一点，不过，你必须验证自动化测试项目的可行性。验证过程花费的时间往往比人们预期的要长，并且需要来自你身边的各种人的帮助。

很多年前，我从事一个测试自动化项目的工作，参加项目的人员有各种各样的好点子。我们设计了一个复杂的自动化测试系统，并且非常努力工作去实现系统的每个模块。我们定期的介绍测试自动化的设计思路和工作进度，甚至演示已经完成的部分功能。但是，我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。最后，整个项目被取消了，此后，我再也没有犯这个错误。

你需要尽可能快地验证你采用的测试工具和测试方法的可行性，站在产品的角度验证你所测试的产品采用自动化测试的可行性。这通常是很困难的，需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。你需要做是验证概念 —— 一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性，从而验证了你的测试概念。你选择的用来验证概念的测试套是评估测试工具的最好的方式。

对于很多人来说，自动化测试意味着 GUI 自动化测试，我不同意这种观点。我曾经做过 GUI 和非 GUI 自动化测试，并惊奇的发现这两类测试的测试计划有很大的互补性。不过， GUI 测试工具很昂贵、并且过分讲究。选择合适的 GUI 测试工具是很重要的，因为，如果没有选择合适的测试工具，你会遇到很多不可预测的困难。 Elisabeth Hendrickson 曾经写过一篇关于选择测试的工具的指导性文章 [Hendrickson 1999] 。我建议在评估测试工具中，找出能够验证你的想法的证据是很重要的环节。这需要测试工具至少有一个月试用期，你可能打算现在购买一份测试工具，然后直到评估完成后再购买更多份。你需要在付出大笔金钱购买测试工具的之前，找出工具存在的问题。这样，你可以从测试工具供应商得到更好的帮助，当你打算更换工具的时候，你不会感觉很为难。

下面是一些候选的验证概念的试验：

回归测试：你准备在每个版本运行同样的测试用例吗？回归测试是最宜采用自动化测试的环节。

配置测试：你的软件支持多少种不同的平台？你打算在所有支持的平台上测试执行所有的测试用例吗？如果是的，那么采用自动化测试是有帮助的。

测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。

非 GUI 测试：实现命令行和 API 的测试自动化比 GUI 自动化测试容易的多。

无论采用什么测试方法，定义一个看得见的目标，然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。

步骤四：支持产品的可测试性

软件产品一般会用到下面三种不同类别的接口：命令行接口（ command line interfaces ，缩写 CLIs) 、应用程序接口（ API ）、图形用户接口（ GUI ）。有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。从本质上看， API 接口和命令行接口比 GUI 接口容易实现自动化，去找一找你的被测产品是否包括 API 接口或者命令行接口。有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者 API 接口，从而支持产品的可测试性。

下面，更多多的讲解 GUI 自动化测试相关内容。这里有几个原因导致 GUI 自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有 “ 录制回放 ” 或者 “ 捕捉回放 ” 功能，这确实是个很好的方法。可以手工执行测试用例，测试工具在后台记住你的所有操作，然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法，但是很多时候却不能奏效。很多软件测试文章的作者得出结论 “ 录制回放 ” 虽然可以生成部分测试脚本，但是有很多问题导致 “ 录制回放 ” 不能应用到整个测试执行过程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 结果， GUI 测试还是主要由手工完成。

第二个原因，把 GUI 自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的 GUI 接口技术才能使 GUI 测试工具正常工作。这个主要的困难也是 GUI 自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。另外，还需要分析测试工具中的 BUG ，并且给工具打补丁。也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。 GUI 测试中，困难总是意外出现，让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。

第三个原因， GUI 设计方案的变动会直接带来 GUI 自动化测试复杂度的提高。在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。一般来讲，第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候，就开展 GUI 自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。不管怎样，即便界面的修改会导致测试修改脚本，你也不应该反对开发人员改进图形界面。一旦原始的设计完成后，图形界面接口下面的编程接口就固定下来了。

上面提到的这些原因都是基于采用 GUI 自动化测试的方法完成产品的功能测试。图形界面接口当然需要测试，可以考虑实现 GUI 测试自动化。不过，你也应该考虑采用其他方法测试产品的核心功能，并且这些测试不会因为图形界面发生变化而被中断，这类测试应该采用命令行接口或者 API 接口。我曾经看到有人选择 GUI 自动化测试，因为，他们不打算修改被测试产品，但是，最终他们认识到必须对产品做修改，以保证 GUI 测试自动化可以正常工作。无论你选择哪种方法，自动化都需要对被测试的产品做修改。因此，采用可编程的接口是最可靠的。

为了让 API 接口测试更为容易，应该把接口与某种解释程序，例如 Tcl 、 Perl 或者 Python 绑定在一起。这使交互式测试成为可能，并且可以缩短自动化测试的开发周期。采用 API 接口的方式，还可以实现独立的产品模块的单元测试自动化。

一个关于隐藏可编程接口的例子是关于 InstallShield—— 非常流行的制作安装盘的工具。 InstallShield 有命令行选项，采用这种选项可以实现非 GUI 方式的安装盘，采用这种方式，从提前创建好的文件中读取安装选项。这种方式可能比采用 GUI 的安装方式更简单更可靠。

另一个例子是关于如何避免基于 WEB 软件的 GUI 自动化测试。采用 GUI 测试工具可以通过浏览器操作 WEB 界面。 WEB 浏览器是通过 HTTP 协议与 WEB 服务器交互的，所以直接测试 HTTP 协议更为简单。 Perl 可以直接连接 TCP/IP 端口，完成这类的自动化测试。采用高级接口技术，譬如客户端 JAVA 或者 ActiveX 不可能利用这种方法。但是，如果在合适的环境中采用这种方式，你将发现这种方式的自动化测试比 GUI 自动化测试更加便宜更加简单。

我曾经受雇在一家公司负责某个产品 GUI 相关的自动化测试，该产品也提供命令行接口，不过，他们已经实现了 GUI 的自动化测试。经过一段时间的研究，我发现找到图形界面中的 BUG 并不困难，不过，用户并不关注图形界面，他们更喜欢使用命令行。我还发现我们还没有针对最新的产品功能（这些功能即可通过 GUI 的方式，也可以通过命令行的方式使用）实现自动化测试。我决定推迟 GUI 自动化测试，扩展命令行测试套，测试新增的产品功能。现在回过头看这个决定，我没有选择 GUI 自动化测试是最大的成功之处，如果采用了 GUI 自动化测试所有的时间和努力都会浪费在其中。他们已经准备好做 GUI 自动化测试了，并且已经购买了一套测试工具和其他需要的东西，但我知道在开展具体的 GUI 自动化测试活动中，会遇到各种各样的困难和障碍。

无论你需要支持图形界面接口、命令行接口还是 API 接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，未来的测试工作中，你很可能成功。尽可能早的启动自动化测试项目，提出可测试性需求，会使您走向自动化测试成功之路。

步骤五：具有可延续性的设计

在开篇的故事中，我们看到由于自动化工程师把注意力仅仅集中在如何使自动化运转起来，导致测试自动化达不到预期的效果。自动化测试是一个长期的过程，为了与产品新版本的功能和其他相关修改保持一致，自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过，测试人员应该相信得到的结果，测试执行的实际结果也应该是通过了。其实，有很多存在问题的测试用例表面上执行通过了，实际上却执行失败了，并且没有记录任何错误日志，这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果，而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误，都会导致这种失败的测试自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。

性能： 提高代码的性能往往增加了代码的复杂性，因此，会威胁到代码的可靠性。很少有人关心如何对自动化本身加以测试。通过我对测试套性能的分析，很多测试套都是花费大量的时间等候产品的运行。因此，在不提高产品运行性能的前提下，无法更有效的提高自动化测试执行效率。我怀疑测试自动化工程师只是从计算机课程了解到应该关注软件的性能，而并没有实际的操作经验。如果测试套的性能问题无法改变，那么应该考虑提高硬件的性能；测试套中经常会出现冗余，也可以考虑取出测试套中的冗余或者减少一个测试套中完成的测试任务，都是很好的办法。

便于分析： 测试自动化执行失败后应该分析失败的结果，这是一个棘手的问题。分析执行失败的自动化测试结果是件困难的事情，需要从多方面着手，测试上报的告警信息是真的还是假的？是不是因为测试套中存在缺陷导致测试执行失败？是不是在搭建测试环境中出现了错误导致测试执行失败？是不是产品中确实存在缺陷导致测试执行失败？有几个方法可以帮助测试执行失败的结果分析，某些方法可以找到问题所在。通过在测试执行之前检查常见的测试环境搭建问题，从而提高测试套的可靠性；通过改进错误输出报告，从而提高测试自动化的错误输出的可分析性；此外，还可以改进自动化测试框架中存在的问题。训练测试人员如何分析测试执行失败结果。甚至可以找到那些不可靠的、冗余的或者功能比较独立的测试，然后安全地将之删除。上面这些都是减少自动化测试误报告警、提高测试可分析性的积极有效的方法。另外，有一种错误的测试结果分析方法，那就是采用测试结果后处理程序对测试结果自动分析和过滤，尽管也可以采用这种测试结果分析方法，不过这种方法会使自动化测试系统复杂化，更重要的是，后处理程序中的 BUG 会严重损害自动化测试的完整性。如果由于自动化测试本身存在的缺陷误把产品中的正常功能视为异常，那该怎么办？我曾经看到测试小组花费开发测试自动化两倍的时间来修改测试脚本，并且不愿意开展培训过程。那些仅仅关注很浅层次测试技术的测试管理者对这种方法很感兴趣，他们排斥采用隐藏测试复杂度的方法。

综上所述，应该集中精力关注可以延续使用的测试套，从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

可读性： 很多情况下，在测试人员开始测试项目之前，公司已经有了一套测试脚本，并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它，但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性，在具体应用中，那些脚本常常没有多大的实用价值，越来越让人迷惑。因此，测试人员很难确定他们实际在测试什么，反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本，并且理解测试脚本究竟测试了什么，这是很关键的。好的文档是解决问题的手段之一，对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法，我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩，把所有执行的产品相关的命令记录到日志里。这样，当分析日志确定执行了哪些产品命令，命令采用了何种参数配置时，可以提供一个非常好的测试记录，里面记录了自动化测试执行了什么，没有执行什么。如果测试脚本可读性不好，很容易变得过分依赖并没有完全理解的测试脚本，很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后，可以更容易的开展同行评审活动。

可维护性： 在工作中，我曾经使用过一个测试套，它把所有的程序输出保存到文件中。然后，通过对比输出文件内容和一个已有的输出文件内容的差别，可以称已有的输出文件为 “ 标准文件 ” （ “gold file” ）。在回归测试中，用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了，它会产生很多错误的警告。随着时间的推移，软件开发人员会根据需要修改产品的很多输出信息，这会导致很多自动化测试失败。很明显，为了保证自动化测试的顺利进行，应该在对 “ 标准文件 ” 仔细分析的基础上，根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是，每次只检查选定的产品的某些特定输出，而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试，这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改，并研究使测试修改量最小的方法，测试中采用库是解决问题的方法。当产品发生变化的时候，只需要修改相关的库，保证测试与产品的变动同步修改即可。

完整性： 当自动化测试执行后，报告测试执行通过，可以断定这是真的吗？这就是我称之为测试套的完整性。在前面的故事中，当没有对自动化测试完整性给予应有的关注的时候，发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果？自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败，但是，对于自动化测试误报告警的情况，大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效，当测试发现异常的时候，能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法，分类包括 PASS ， FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果，它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分，另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ，这个 BUG 引起测试队列中部分测试用例被跳过，没有执行。当测试队列运行完毕后，没有上报任何错误，我不得不通过走读代码的方式发现了这个 BUG 。如果，我没有关注到这个 BUG ，那么可能在认识到自动化测试已经出现问题之前，还在长时间运行部分测试用例。

独立性： 采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候，通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化，测试执行是由一台不会说话的计算机完成的，你必须告诉计算机什么样的情况下测试执行是失败的，并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境，因此，保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档，以便一个接着一个有序地完成测试执行，每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误，这个错误源于 “ 多米诺骨牌 ” 测试套，当一个测试执行失败，会导致后续一系列测试失败。更糟糕的是，所有的测试关联紧密，无法独立的运行。并且，这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后，人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式，不过，重要的是在不牺牲测试的可靠性的前提下保证测试的独立性，如果测试可以在无需人看守情况下运行，那么测试的执行效率就不是大问题了。

可重复性： 自动化测试有时能够发现问题，有时候又无法发现问题，对这种情况实在没有什么好的的处理办法。因此，需要保证每次测试执行的时候，测试是以同样的方式工作。这意味着不要采用随机数据，在通用语言库中构造的随机数据经常隐藏初始化过程，使用这些数据会导致测试每次都以不同的方式执行，这样，对测试执行的失败结果分析是很让人沮丧的。这里有两个使用随机数据发生器的的方法可以避免上述情况。一种方法是使用常量初始化随机数据发生器。如果你打算生成不同种类的测试，需要在可预测，并且可控制的情况下建立不同类型的随机数据发生器。另外一个办法是提前在文件中或数据库中建立生成随机测试数据，然后在测试过程中使用这些数据。这样做看起来似乎很好，但是我却曾经看到过太多违反规则的做法。下面我来解释到底看到了什么。当手动执行测试的时候，往往匆匆忙忙整理文件名和测试数据记录。当对这些测试采用自动化测试方法，该做哪些工作呢？办法之一是，可以为测试中使用的数据记录给固定的命名。如果这些数据记录在测试完成后还要继续使用，那么就需要制定命名规则，避免在不同的测试中命名冲突，采用命名规则是一种很好的方法。然而，我曾经看到有些测试只是随机的命名数据记录，很不幸，事实证明采用这种随机命名的方式不可避免的导致命名冲突，并且影响测试的可重复性。很显然，自动化工程师低估了命名冲突的可能性。下面的情况我遇到过两次，测试数据记录的名字中包含四个随机产生的数字，经过简单的推算如果我们采用这种命名方式的时候，如果测试使用了 46 条记录，会存在 10% 冲突的可能性，如果使用 118 条记录，冲突的几率会达到 50% 。我认为测试当中使用这种随机命名是出于偷懒的想法 —— 避免再次测试之前写代码清除老的数据记录，这样引入了问题，损害了测试的可靠性和测试的完整性。

测试库： 自动化测试的一个通用策略是开发可以在不同测试中应用的测试函数库。我曾经看到过很多测试函数库，自己也写了一些。当要求测试不受被测试产品接口变动影响的时候，采用测试库方法是非常有效的。不过，根据我的观察测试库已经使用的太多了，已经被滥用了，并且测试库往往设计的不好，没有相关的文档支撑，因此，使用测试库的测试往往很难开展。当发现问题的时候，往往不知道是测试库自身的问题，还是测试库的使用问题。由于测试库往往很复杂，即便在发现测试库存在问题，相关的维护人员也很不愿意去修改问题。通过前文中的论述，可以得出结论，在一开始就应该保证测试库设计良好。但是，实际情况是测试自动化往往没有花费更多的精力去保证一个优良设计的测试库。我曾经看到有些测试库中的功能根本不再使用了或仅仅使用一次。这与极限编程原则保持一致，即 " 你将不需要它 " 。这会导致在测试用例之间的代码出现一些重复，我发现微小的变化可能仍然存在，很难与测试库功能协调。你可能打算对测试用例作修改，采用源代码的方式比采用库的方式更容易修改。如果有几个测试，他们有某些共同的操作，我使用剪切和粘贴的方式去复制代码，有的人认为我采用的方法不可理喻。这允许我根据需要修改通用代码，我不必一开始尝试和猜测如何重用代码。我认为我的测试是很容易读懂的，因为阅读者不必关心任何测试库的语法。这种办法的优势是很容易理解测试，并且很方便扩展测试套。在开发软件测试项目的时候，大多数程序员找到与他们打算实现功能类似的源代码，并对源代码做修改，而不是从头开始写代码。同样，在写测试套的过程中可以采用上述方法，这也是代码开发方式所鼓励的方法。我比较喜欢写一些规模比较小的测试库，这些库可以被反复的使用。测试库的开发需要在概念阶段充分定义，并且文档化，从始至终都应该保持。我会对测试库作充分的测试后，才在测试中使用这些测试库。采用测试库是对所有面临的情况作权衡的。千万不要打算写一个大而全的测试库，不要希望有朝一日测试人员会利用你的测试库完成大量的测试，这一天恐怕永远不会到来。

数据驱动测试： 把测试数据写入到简单表格中，这种测试技术得到了越来越广泛的应用，这种方法被称为表驱动（ table-driven ），数据驱动 (data-driven) 或者 “ 第三代 ” 自动化测试（ "third generation" automation ）。这需要写一个解析器，用来解释表格中的数据，并执行测试。该测试架构的最主要的好处是，它允许把测试内容写在具有一定格式的表格中，这样方便数据设计和数据的检视。如果测试组中有缺少编程经验的业务专家参与测试，采用数据驱动测试方法是很合适的。数据驱动测试的解析器主要是由测试库和上层的少量开发语言写成的代码组成的，所以，上面关于测试库的说明放在这里是同样合适的。在针对上面提到的少量代码的设计、开发、测试的工作，还存在各种困难。代码所采用的编程语言是不断发展的。也许，测试人员认为他们需要把第一部分测试的输出作为第二部分测试的输入，这样，加入了新的变量。接下来，也许有人需要让测试中的某个环节运行一百次，这样加入一个循环。你可以采用其他语言，不过，如果你预料到会面临上述情况的时候，那么做好采用一些能够通过公开的渠道获取的编程语言，比如 Perl,Python 或者 TCL ，这样比设计你自己的语言要快的多。

启发式确认： 我曾经看到很多测试自动化没有真正意义上的结果校验，其原因有两个，一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的，另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过，采用手工校验测试结果的方法是真正意义上的测试校验。标准文件（ Gold file ）是另外一中校验测试结果的方法。首先，捕获被测试程序的输出，并检视程序的输出，然后，把输出信息文档化，并归档，作为标准文件。以后，自动化测试结果与标准文件作比较，从而达到结果校验的目的。采用标准文件的方法，也有弊端。当产品发生变化，自动化测试的环境配置发生变化，产品的输出发生变化的时候，采用标准文方法，会上报大量的误报告警。做好的测试结果校验方法是，对输出结果的特定内容作分析，并作合理的比较。有时候，很难知道正确的输出结果是什么样的，但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法，是因为担心如果结果校验漏掉了任何信息，可能导致自动化测试自身出现错误。不过，我们在测试过程中往往采用折衷的做法，没有采用大而全的测试结果校验方法，这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法，那么他必须找相关人员咨询，寻找一种合适的测试结果校验策略，这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下，找到被测试产品的缺陷。

把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，你将进一步迈向成功的自动化测试。

步骤六：有计划的部署

在前面的故事中，当自动化工程师没有提供打包后的自动化测试程序给测试执行人员，会影响到测试执行，测试执行人员不得不反过来求助自动化工程师指出如何使用自动化测试程序。

作为自动化工程师，你知道如何利用自动化方法执行测试和分析执行失败的结果。不过，测试执行人员却未必知道如何使用自动化测试。因此，需要提供自动化测试程序的安装文档和使用文档，保证自动化测试程序容易安装和配置。当安装的环境与安装的要求不匹配，出现安装错误的时候，能够给出有价值的提示信息，便于定位安装问题。

能够把自动化测试程序和测试套作为产品对待，那真是太好了。你应该对自动化测试程序和测试套开展测试，保证它们不依赖于任何专用的库或者是设备上的任何其他程序。

保证其他测试人员能够随时利用已经提供的自动化测试程序和测试套开展测试工作；保证自动化测试是符合一般测试执行人员的思维习惯的；保证测试执行人员能够理解测试结果，并能够正确分析失败的测试执行结果；这需要自动化工程师提供自动动化测试相关的指导性文档和培训。

作为测试管理者，你希望在自动化工程师离开前，能够识别并修改测试套中的所有问题。自动化工程师迟早会离开的，如果你没有及时的把测试套中的问题提出来，就会面临废弃已有的测试套的决定。

良好的测试套有多方面的用处。良好的测试套支持对产品新版本的测试；良好的测试套在新的软件平台上可以很方便的验证产品的功能；良好的测试套支持每天晚上开始的软件每日构造过程；甚至开发人员在代码 check in 之前，用良好的测试套验证代码的正确性。

测试套的共享也很重要。很难预见以后什么人会继续使用你开发的测试套。因此，尽量让产品开发测试团队中的成员都很容易获得你的测试套。可以把测试套放在公司的内部网络上，这是个很好的办法。这样，大家就不必为了获取一份需要的测试套而四处打听。有些人总是感觉自己的测试套还没有最终完工或者不够完美，而没有拿出来与人分享，这种做法一定要改变，共享出来的测试套不一定非常完美，共享才是关键。

有计划的自动化测试部署，保证你的测试套能够被产品相关人员获取到，你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。

步骤七：面对成功的挑战

当你完成了所有的事情，测试套已经文档化了，并且文档已经交付了。测试执行人员能够理解要开展的测试，并知道如何完成测试执行。随着你所负责产品的进一步开发和维护，测试被反复重用。虽然，在自动化使测试变简单的同时，也总是使测试过程复杂化。测试人员需要学习如何诊断自动化测试执行失败的情况，如果不这样做，测试执行人员会认为执行失败的情况是由自动化引起，然后，自动化工程师被叫过来帮助诊断每一个执行失败的情况，开发人员往往也会认为执行失败是由于自动化测试自身引起的问题，这样，测试执行人员就不得不学习通过手工的方式，或者通过采用少量脚本的方式重现自动化测试发现的问题，以证明他们确实发现了产品当中的 BUG 。

测试套的相关工作还没有结束，为了提高测试覆盖率或者测试新的产品特性，需要增加更多的测试。如果已有的测试不能正常工作，那么需要对之修改；如果已有的测试是冗余的，那么需要删除这部分测试。

随着时间的推移，开发人员也会研究你设计的测试，改进产品的设计并且通过模拟你的测试过程对产品做初步测试，研究如何使产品在第一次测试就通过，这样，你设计的测试很可能无法继续发现新的问题，这种现象被称为一种杀虫剂悖论。这时候，会有人对你的测试有效性提出质疑，那么，你必须考虑是否应该挖掘更严格的测试，以便能够发现开发人员优化之后的产品中的缺陷。

以前，我提到过一个基本上无法实现的设想，设想通过按下一个按钮就完成了所有的测试工作。自动化测试是不是全能的，手工测试是永远无法完全替代的。

有些测试受测试环境的影响很大，往往需要采用人工方法获取测试结果，分析测试结果。因此，很难在预先知道设计的测试用例有多大的重用性。自动化测试还需要考虑成本问题，因此，千万不要陷入到一切测试都采用自动化方法的错误观念中。

我曾经主张保证给与测试自动化持续不断的投入。但是，在开展自动化测试的时候，一个问题摆在面前，测试自动化应该及时的提供给测试执行人员，这个不成问题，但是如何保证需求变更后，能够及时提供更新后的自动化测试就是个大问题了。如果自动化测试与需求变更无法同步，那么自动化测试的效果就无法保证了，测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。识别项目计划中的软件发布日期，然后把这个日期作为里程碑，并计划达到这个里程碑。当达到这个里程碑后，自动化工程师应该做什么呢？如果自动化工程师关注当前产品版本的发布，他需要为测试执行人员提供帮助和咨询，但是，一旦测试执行人员知道如何使用自动化测试，自动化测试工程师可以考虑下一个版本的测试自动化工作，包括改进测试工具和相关的库。当开发人员开始设计产品下一个版本中的新特性的时候，如果考虑了自动化测试需求，那么自动化测试师的设计工作就很好开展了，采用这种方法，自动化测试工程师可以保持与开发周期同步，而不是与测试周期同步。如果不采用这种方式，在产品版本升级的过程中，自动化测试无法得到进一步的改进。

持续在在自动化投入，你会面临成功的挑战，当自动化测试成为测试过程可靠的基础后，自动化测试的道路将会越来越平坦。

参考文献：

Bach, James. 1996. “Test Automation Snake Oil.” Windows Technical Journal , (October): 40-44. http://www.satisfice.com/......st_automation_snake_oil.pdf

Dustin, Elfriede. 1999. “Lessons in Test Automation.” Software Testing and Quality Engineering (September): 16-22.
http://www.stickyminds.co......RT&Function=edetail

Fewster, Mark and Dorothy Graham. 1999. Software Test Automation , Addison-Wesley.

Groder, Chip. “Building Maintainable GUI Tests” in [Fewster 1999].

Kit, Edward. 1999. “Integrated, Effective Test Design and Automation.” Software Development (February). http://www.sdmagazine.com/articles/1999/9902/9902b/9902b.htm

Hancock, Jim. 1997 “When to Automate Testing.” Testers Network (June).
http://www.data-dimensions.com/Testers'Network/jimauto1.htm

Hendrickson, Elisabeth. 1999. “Making the Right Choice: The Features you Need in a GUI Test Automation Tool.” Software Testing and Quality Engineering Magazine (May): 21-25. http://www.qualitytree.com/feature/mtrc.pdf

Hoffman, Douglas. 1999. “Heuristic Test Oracles: The Balance Between Exhaustive Comparison and No Comparison at All.” Software Testing and Quality Engineering Magazine (March): 29-32.

Kaner, Cem. 1997. “Improving the Maintainability of Automated Test Suites.” Presented at Quality Week. http://www.kaner.com/lawst1.htm

Linz , Tilo and Matthias Daigl. 1998. “How to Automate Testing of Graphical User Interfaces.” European Systems and Software Initiative Project No. 24306 (June). http://www.imbus.de/html/GUI/AQUIS-full_paper-1.3.html

Jeffries, Ronald E., 1997, “XPractices,”
http://www.XProgramming.com/Practices/xpractices.htm

Marick, Brian. 1998. “When Should a Test Be Automated?” Presented at Quality Week. http://www.testing.com/writings/automate.pdf

Marick, Brian. 1997. “Classic Testing Mistakes.” Presented at STAR. http://www.testing.com/writings/classic/mistakes.html

Pettichord, Bret. 1996. “Success with Test Automation.” Presented at Quality Week (May). http://www.io.com/~wazmo/succpap.htm

Thomson, Jim. “A Test Automation Journey” in [Fewster 1999]

Weinberg, Gerald M. 1992. Quality Software Management: Systems Thinking . Vol 1. Dorset House.

最近公司要上自动化测试工具，不知要选择哪种工具好？

目前公司的应用主要是通讯产品的网管。设计到大量的WEB应用测试和脚本的测试。

WEB测试不说也知道，有许多控件，基本是JAVA的。

脚本测试主要是到UNIX的环境中，进入一种应用接口，输入一堆一堆的命令，如检查UNIX中的文件和数据库中的数据。

1.自动化测试需编写自动化测试脚本，而你对自动化脚本只是略知一二，由于项目成本的限制，不可能再增加专门编写测试脚本的人员，而对这个问题你如何解决？
答：
     我的解决方案是：软件测试自动化 。在项目成本的限制不能增加专门编写测试脚本人员的这样的经济以及人力的限制条件下，我认为测试自动化是一个很好的解决方案。
     具体解决方案：利用自动化的测试支持工具。尤其是在时间、资源或成本有限的这种棘手的问题下，利用自动化的测试支持工具是一非常好的解决方法。这样的自动化的测试支持工具有很多，我们在自动化脚本只是略知一二和项目成本的限制不能再增加专门编写测试脚本的人员的情况下，我们可以选用自动化的测试支持工具来进测试自动化，这种工具只需我们进行一些简单的操作，而且对我们所做的操作可以自动生成所需的脚本。有一种这样的工具如WinRuuner，它可以确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，可以对简单的操作来自动完成应用程序的功能性测试。用WinRuuner创建一个测试，只需点击鼠标和键盘，就能完成一个标准的业务操作流程，WinRunner自动记录所做的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。而且还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式，满足测试团队中业务用户和专业技术人员的不同需求。这就十分符合我们所需的要求。

2.单元测试自动化，你打算使用哪些工具或框架？
答：
     （1）JUnit是一个开源的java测试框架，它是Xuint测试体系架构的一种实现。在JUnit单元测试框
架的设计时，设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个是可以利用既有的测试来编写相关的测试。而且junit是完全Free的，所以是一个既经济又强大的单元测试自动化框架。
     （2）LUnit是一个单元测试框架，用于对数据库存储过程进行回归测试。用 Java/JUnit/XML开发。
     （3）Jtest是一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类，然后自动生成junit测试用例并执行用例，从而实现代码的最大覆盖，并将代码运行时未处理的异常暴露出来；另外，它还可以检查以DbC（Design by Contract）规范开发的代码的正确性。不过价格昂贵。
     （4）Ckrunner用在J2EE环境中进行应用程序的单元测试。它不仅支持Struts actions, servlets，过滤器和标签类还包括一个JDBC和一个JMS测试框架，可以用于测试基于EJB的应用程序。
     （5）Rrogate Test framework是一个值得称赞单元测试框架，特别适合于大型，复杂Java系统的单元测试。这个框架能与JUnit,MockEJB和各种支持模拟对象（mock object ）的测试工具无缝给合。这个框架基于AspectJ技术。
      总之：具体选用那种工具或框架，应该根据公司自身和具体单元测试自动化的情况来定。

3.为了能让单元测试自动化顺利实施，实施前的培训非常重要，结合你选择的工具或框架谈谈培训内容重点，及时间的安排？
答：
    1、为了能让单元测试自动化顺利实施，那么这是对单元自动化测试的培训。因此，第一应该了解“软件详细设计评审”，它包括：（1）详细设计文档的文档格式、规范。应知道如何根据根据概要设计文档完成详细设计文档，并且，保证详细设计文档可以指导后续的编码和单元测试工作；（2）伪码写作注意事项。
    第二应该掌握“单元测试理论”，它包括：测试理论基础，什么是单元测试，单元测试的基本方法，桩和驱动，单元测试策略，单元测试过程，单元测试辅助工具。
    第三应该掌握“单元测试用例设计”。
    第四应该熟知“软件单元测试相关工具”，知道怎么使用，使用方法，及使哪些工具或框架适合对哪些测试要求能更好达到更高质量的测试。这就需要对所选择的工具及框架有相当的了解和对其使用的技术。这是培训的重点。在培训中应让学员充分掌握对选择的JUnit、LUnit、Jtest、Ckrunner、Rrogate Test framework等工具的了解和使用方法，及对它们的性能、优点和适合什么样的情况下的测试等特性应十分了解，这对于具体实践工作中很重要，这将直接影响到测试的质量。
    2、培训的时间安排：培训的时间安排可以是在软件开发前进行为期一到两个月的培训时间，然后从学员中筛选优秀的学员正式应用到软件开发中来；或者在边开发期间边实地实战培训，具体参与软件开发，这样面对实践专家技术指导，如此的培训有一定的风险，但培训的效果也是比较显著和具体。

     
4.Robot和WinRunner都是自动化功能测试的利器，它们之中都各自蕴含着向自己独特的一套自动化测试框架和方法论，请综合评价这两个工具并最终选择哪个更合适会在项目上使用，说明理由。
答：
      （1）Robot：
    Robot测试技术框架是基于表驱动测试思想。表驱动测试就是预先在表中定义清楚代表每一步执行操作的关键字，然后由脚本读入表中的每一行，根据关键字来执行对应的动作。Robot 可以通过环境变量设置自行启动和运行的时间，和Test manager 协作自动按照顺序运行某些脚本；再则可以通过 Insert at Cursor 方式 进行插入录制，而且Robot 不仅支持 c/s 架构的程序完全没有问题而且只需要语句call 就可以完成。
    Robot执行完整的功能测试。记录和回放遍历应用程序的脚本，以及测试在查证点处的对象状态。
    Robot执行完整的性能测试。Robot和Test Manager协作可以记录和回放脚本，这些脚本有助于断定多客户系统在不同负载情况下是否能够按照用户定义标准运行。
      在SQA Basic、VB、VU环境下创建并编辑脚本。Robot编辑器提供有色代码命令，并且在强大的集成脚本开发阶段提供键盘帮助。测试IDE下Visual Basic、Oracle Forms、Power Builder、HTML、Java开发的应用程序。甚至可测试用户界面上不可见对象。
     脚本回放阶段收集应用程序诊断信息，Robot同Rational Purify、Quantify、Pure Coverage集成，可以通过诊断工具回放脚本，在日志中察看结果。
    Robot使用面向对象记录技术：记录对象内部名称，而非屏幕坐标。若对象改变位置或者窗口文本发生变化，Robot仍然可以找到对象并回放。
    Robot提供的强大功能所搭建起来的自动化功能测试框架，能够帮助软件开发组织成功的实施自动化的功能测试。通过重用已有的静态结构和动态结构，能够有效的促进测试的重用，并且在IBM Rational Robot的支持下，可以自动的执行这些测试。 通过使用测试设计工具来生成动态配置，可以看到除测试技术框架的SQABasic脚本外，不需要再维护任何其它的脚本，降低了脚本调试、维护的工作量。并且将来的维护是基于测试设计工具来进行，也降低了自动化测试整体的维护工作量。通过使用测试设计工具来生成静态配置，能够做到根据界面的设计来进行配置，而不需要等到待测试应用完全可用，就使得及早测试成为可能。通过支持业务、技术测试人员的分工，在测试技术框架中封装自动化测试技术细节，使得业务测试人员不需要自动化测试技术的相关知识，只需要通过测试设计工具，就能够简单、直观的进行测试的设计和执行，降低了自动化测试的实施难度。
      （2）WinRunner：
    WinRunner是一种强大的企业级自动化功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。WinRunner自动记录你的操作并生成所需的脚本代码随着时间的推移，开发人员会对应用程序做进一步的修改，并需要增加另外的测试。使用WinRunner，不必对程序的每一次改动都重新创建测试。除了创建并运行测试，WinRunner还能验证数据库的数值，从而确保业务交易的准确性。
创建好测试脚本，并插入检查点和必要的添加功能后，就可以开始运行测试。运行测试时，WinRunner会自动操作应用程序，就象一个真实的用户根据业务流程执行着每一步的操作。测试运行过程中，如有网络消息窗口出现或其它意外事件出现，WinRunner也会根据预先的设定排除这些干扰。
    Winrunner是专门用于C/S和B/S架构功能测试的自动化测试工具，其强项在C/S架构功能测试上WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试，从而大大地节省时间和资源，因此可以充分利用公司的测试投资。
       （3）我选用Winrunner的理由：
    虽然Robot和WinRunner都是自动化功能测试的利器，它们之中都各自蕴含着向自己独特的一套自动化测试框架和方法论，但我认为WinRunner更合适会在项目上使用。
 如果时间或资源有限，这样的问题会很棘手。人工测试的工作量太大，还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。而用WinRuuner创建一个测试，只需点击鼠标和键盘，就能完成一个标准的业务操作流程，WinRunner自动记录所做的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。而且还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式，满足测试团队中业务用户和专业技术人员的不同需求。因此我认为WinRunner更合适会在项目上使用。

4.Bug跟踪管理是一个不可忽视的环节，请你作为这个项目定义一个合理的bug跟踪流程，绘制流程图并附文字说明。
答：
     1、Bug跟踪管理系统对于一个软件开发团队的Bug管理是非常有效的，它能记录和跟踪每个出现的问题，为软件开发团队提供有效的交互平台，Bug跟踪管理系统从另一定程度上还可以提高团队效率和增强团队工作氛围。同时，作为问题记录的数据库，能积累处理问题的经验，有利于以后维护。bug跟踪系统用于帮助公司和软件开发团队跟踪工作中的Bug，管理和记录这些Bug的出现及处理过程，并为用户提供事务分配和自动通知的平台。常见的Bug跟踪工具有很多，网上很容易找到最新的，华军软件下载区就有。
     2、只是有Bug跟踪管理工具还远远不能正常完成具体的Bug跟踪管理，还需要为自己公司定义一个合理的Bug跟踪流程，绘制出Bug跟踪流程图。对于比较大型的公司或开发团队，比较倾向于自己开发符合自己需求的Bug跟踪管理系统。我的Bug跟踪流程图：

    Bug跟踪流程图如下：

 

 

 

 

 

 

 

 

 

 

4.除了上述问题，你认为还可能有哪些问题是需要考虑解决的？
答：(参考来源于网络)
     （1）自动化测试时间不充足：根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间，无法得到真正的关注。
     （2）缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。但是，自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。
     （3）缺乏经验：尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。
     （4）更新换代频繁：测试自动化往往需要花费很多时间学习，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。
     （5）对于绝望的反应：在测试还远没有开始的时候，问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言，测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。
     （6）不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。
     （7）关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。