本书是一本从测试开发人员和用户角度考虑的实际可用的指导软件测试自动化的书。两位优秀的软件测试顾问讲述了在真正的测试自动化基础设施设计和实施中能够做的和不能做的工作——还有一些实际的建议告诉读者现今最流行的自动化测试方法所能完成的和不能完成的工作。
　　其内容涵盖：
　　◆设定现实的预期：了解何时进行自动化与什么可以进行自动化
　　◆对自动化测试进行计划
　　◆实现控制同步数据驱动测试(CSDDT)框架，这是一个已被证明可以简化并加快测试速度的方法
　　◆使用结构化的测试脚本以简化测试脚本的维护并提高重用性命 自动化单元测试、集成测试、系统／回归测试
　　◆管理自动化测试过程以优化效率 本书还包括一个完整的自动化项目计划的例子，其中包括完整文档、实现、自动化环境、角色、责任等等。http://www.phptr.com/mosley这个站点是一个FTP链接，其中有本书中所描述的所有方法 在自动化测试项目中应用所需要的信息和工具资源。

　　作者简介：
　　DANIEL，J．MOSLEY是客户机—服务器软件测试技术的创始人，他也是《The Handbook of MIS Application Software Testing》 和 《CIient Sever Software Testing on the Desktop and Web》两本书的作者。Mosley是一位CSTE(认证软件测试工程师)，他足质量保证研究所(Quality Assurance lnstitute)的一名高级顾问和研讨班主管，他的著作还有《TEST-RxTM Methodology》。 BRUCEA．POSEY的特长是使用SQA套件和Rational小组测试开发和实现数据驱动、基于框架的测试脚本。他有将近30年的IT从业经验，曾在MasterCard、Deutsche Financial Services、SBC和其他杰出的公司做过多种工作。现在他是Archer Group的董事和首席顾问，该公司的业务主要是软件测试和培训。

迄今，市面上已经有了很多关于测试自动化的书籍。’它们所提倡的软件测试自动化方法各不相同，级别也有所差异。当然也有人尝试过将软件测试自动化的生命周期用最大众化的方式描述出来(参看第2章中Dustin的论述)。传统上，软件人员通常的做法是尝试用假设的模型来描述我们使用的过程。有些时候这种方法行得通，但有些时候它是行不通的。其问题在于没有经验性的证据能够证明在这些模型上使用的方法是否能够在现实世界中工作。对于大多数受到推荐的软件测试及软件开发方法来说，其基础只是轶事逸闻和项目管理的狂热，而这些是由那些所谓的信息系统专家发起并被首席信息官(Chief lnformation Officer；CIO)们推动发展的。
　　我们不相信自动化测试的生命周期。这只是一个人工构造的概念，而且我们发现它没什么用处。我们也不相信软件测试生命周期，我们所真正相信的是软件测试是属于软件开发过程中的一组紧密相关的活动。我们还相信好的软件测试需要有特定规范的项目管理以及一套它自己的操作技巧。测试也需要一套测试工程师在进行测试活动时能够依赖的工具。这些工具可以是与测试相关的产物，例如测试工程师可以依据的打印出来的测试场景，或者是在执行测试时工程师可以填写的打印出来的测试日志。
　　我们并非是说必须等到有了诸多经验证据之后才能接受并使用IS权威们所鼓吹的工具和技术。我们的意思是我们必须对这些工具和方法进行评估并去其糟粕。真正行之有效的经验是：当从业者(你和我们)尝试使用这些技术时，能够知道哪种技术可行而哪种不行。
　　本书第一作者DanMosley探讨了他在1985年使用的第一个自动化测试工具，那时的技术还相当简陋。他给本科生教授最早的软件测试课程时获得了该产品的评估版拷贝(圣路易斯的华盛顿大学，1985—1992)。在20世纪90年代中期，他与当时在Software Quality Automation(SQA)公司、现在在Rational Software公司(该公司后来吞并了SQA及其产品，其业务主要是提供自动化软件测试工具以及软件测试工程师所需要使用的东西，而译者现在得知Rational Software公司业已被IBM购买，但仍保持Rational品牌)的EricSchurr通了长途电话，作了一次长谈。　　
　　他们讨论了一个好的自动化工具应有的功能和应该包括的特征。通过与Eric的联络，Dan获得并使用了SQA(现在是Rational)的自动化测试工具，那是在早期的1．0版后面出来的版本。现在最新的版本(写本书时)是“Rational Suite Test Studio2002”。Dan对这个产品的使用经验表明，测试自动化不是对草率的测试工作的简单仓促的修正。此外，他的经验还证明了自动化测试不能代替手工测试。Glen Myers在20世纪70年代后期提出了软件测试的基本概念。直到今天，他的《Art of Software Testing(1979)》仍被认为是关于软件测试的最早著作。在我们进行手工测试以及构建自动化测试基础设施时我们仍要遵循他的一些建议。
　　我们对现在测试自动化实践的主要意见是其缺乏前期的测试计划和测试设计活动。我们重复地犯着那些软件开发人员早巳成为痼疾的经典错误——我们在还没有对问题做合适的分析以及对测试基础设施进行设计时就开始了测试工作。这令我们想起了几年前的一个卡通片——某位经理对程序员说：“你开始编写代码吧，我会去研究到底要做什么。”那些“测试”错误东西的自动化测试所带来的结果只有一个：不合适的测试更迅速地被执行完了。
　　任何自动化测试的最终目标都应当是与一套测试需求相对应的一套有计划的测试，这些测试需求反过来也能在自动化测试中体现出来。此外，测试工作的中心是测试数据，而不是测试脚本。这就是为什么有那么多人鼓吹将数据驱动自动化测试作为自动化实现的框架。其基本前提是数据应该驱动测试的进行并且应该体现被测程序(Application Under Test，AUT)的特征。测试脚本仅仅是数据传送工具。只有当设计出好的测试数据后，自动化测试才会有效。
　　自动化测试框架的另一个可操作目标是让测试脚本的维护量减至最少。各测试工具供货商多年主打的传统“捕获徊放”模型导致了高得异乎寻常的脚本维护量，因为测试数据在测试脚本程序中是以硬编码方式实现的。Mosley开发自动化测试脚本的最初经验明确地表明严格使用“捕获徊放”是行不通的。此外，工具内建的测试用例除了测试应用程序的图形用户界面(GUl)外，实际上是没有用处的。真正的功能测试需要测试工程师编写对ALIT进行深度探查的测试数据。GUI测试能够用自动化测试做，并且用最少的工作量就能实现它的自动化。在实际测试中，我们通常用一个单独的测试脚本处理GUI对象，它会对所有GUI对象的属性进行基准和确认测试，这个测试脚本在每一个GUI显示屏都会执行。
　　自动化功能测试需要复杂全面的测试数据对AUT进行测试。这些测试数据必须能够重复产生演示重要系统特征的测试场景。因此，与其他测试相比，自动化功能测试更加复杂也更加困难。它要求测试工程师写出测试脚本的主要部分而不是记录测试。它还意味着要设计有效的测试数据。理解要测试什么(有一套书面的测试需求)并且设计出验证这些需求的数据是编写有价值的自动化功能测试的关键所在。
　　理解如何对测试结果进行验证与知道测试什么同等重要。自动化测试验证也具有数据依赖性。作为最主要的验证方法，自动化测试经常将基准数据捕获并存储起来，稍后与回归测试中捕获的相同数据进行比较。更全面的测试会在测试执行之前、之中和之后对数据库记录进行访问和操作。
　　功能强大的自动化测试框架必须提供测试计划、测试设计、测试构建、测试执行和测试结果验证的工具。一个有效的测试基础设施是建立在集成的中央知识库之上的，测试相关产物可以存储在这个知识库中并能够重用。这个基础设施还应提供可以定制的报告功能。　　，
　　我们两人在合作此书之前就有过合作交流的经历。1996年我们碰到了一起，一同做出了到那时为止第一个真正成功的自动化测试项目。从那时起，我们在很多测试自动化项目中都相互合作。我们逐渐知道了实施成功的自动化测试项目需要什么，以及在IS研发和测试组织中推广自动化测试需要什么。我们知道什么可行，同样也知道什么不可行。
　　经过共同努力，我们实现了一个数据驱动自动化测试的范型，在此之前我们甚至还没有听说过“数据驱动测试”这一现在已经泛滥的业界名词(我们不知道Richard Strang在1996年STAR会议上发表的文章；参看第1章)。在他人刚开始探讨及写作相关文章时，我们已经率先对数据驱动方法进行了实现和完善。当然，对于任何新的热门技术来说，它并不是真正全新的，仅仅是被重新发现了。数据驱动测试也不例外。Berzer在《Software Testing Techniques(1983))一书中就描述过“基于数据驱动的测试设计”。该书出版的时间是大型机时代的晚期以及PC革命的早期，所以它的思路是关于大型机应用程序测试的。他提出的这种过程不是为了测试数据库，而是为了使用数据库结构生成测试数据。他认为该方法“最适合验证系统规约中所规定的功能需求”。通过很简单的步骤就可以将这种方法扩展，以包括那些基于被数据库表结构所支持的业务规则的测试。将测试GUI对象和它们行为的数据加上，你就得到了数据驱动测试。
　　这一时期我们还进行了结构化测试脚本的编写(也称作基于框架的测试)。这也不是什么新的技术。测试脚本就是使用修改过的普通编程语言(VB或C)编写的程序。它们的不同之处在于它们有一些为了软件测试任务而改造的特征。有很多文献都讲述了“结构化程序设计”的概念，例如功能分解、模块结合、模块耦合及模块(功能)重用。由于测试脚本包含的程序是要对另一个程序进行测试，所以它也要遵循被测程序所遵循的设计和构造规则。因此，结构化程序设计概念也适用于自动化测试脚本。
　　因为自动化测试脚本也背负着与其他软件编程相同的包袱，所以它们也有逻辑错误、死循环、硬编码变量等等问题，它们能够由过程和数据一同在测试脚本中实现。所有这些加起来就增加了相关测试套件的维护开销，就像测试脚本所测试的软件系统需要相应的维护开销一样。创建结构化的基于组件的测试脚本并让这些脚本与其所执行的数据相分离是创建有效软件测试自动化基础设施的惟一途径，这样可以达到最佳的测试精度并将测试维护减到最少。
　　最近还有人在开发一种高级的自动化语言，通过使用这种语言，非技术人员例如商业及产品分析人员或系统消费者也可以设计并实施自动化测试。这种尝试被认为是自动化测试发展的下一个阶段。然而迄今为止，我们还没有看到一种足够简化的测试脚本开发方法真正能够得到应用。只有在研究出一套可以支持公共的类Java的测试脚本语言的通用脚本库后，我们才会发现这样做的意义。然而，迄今的多数框架所支持的是精心设计的高级命令语言，而不是面向对象的语言。此外，支持库在提供给脚本编写者的功能方面还不够成熟。为了完成他们的测试需求，各机构必须在现存库的子例程和功能之上添加额外的代码。
　　由于我们是从业者，所以本书的目标是从开发者和用户的角度提供关于测试自动化的有用建议。这其中包括在设计和实现测试自动化基础设施时应该做什么的实际建议和不应做什么的一些告诫。此外还包括对现在流行的测试方法可以和不可以为你的测试做哪些事情的一些建议。
　　我们的例子是在Rational Suite Test Studio平台上开发的，但是我们认为它们可以很容易地被移植到其他自动化测试平台上使用。此外，本书还有一个FTP支持站点(www．phptr．com／mosley)。这个站点中既包括Archer Group的CSDDT(Control Synchronized Data Driven Testing，控制同步的数据驱动测试)方法的模板文件，也包括CarlNagle的DDE(Data Driven Engine，数据驱动引擎)方法(适用于Rational环境)的模板文件，还有Keith Zambelich使用Mercury Interactive的Win Runner自动化测试工具的完全数据驱动方法(Totally Data-Driven)，该方法的基础是Zambelich的“测试计划驱动(Test Plan Driven)”框架并使用了他为WinRunner开发的工具包。通过使用这些资源，你可以轻松地立刻开始进行数据驱动自动化测试。

（美）Daniel J.Mosley,Bruce A.Posey：暂无简介

邓波 黄丽娟 曹青春：暂无简介

在IT产业迅速发展的今天，硬件在质与量方面的飞速发展给人们留下了深刻的印象。相对而言，软件在量的方面同样发展迅速，上千万行的大型系统软件及百万行的应用软件已屡见不鲜，然而软件的质量却一直是令所有人头疼的问题，因为随着规模的扩大，对于质量的保证已经成为了一项异常艰苦的工作。面对这种挑战，人们提出了很多软件过程方法，力图通过严谨的开发过程保证软件的质量。这些努力当然是创造高质量软件产品的有效方法，但对软件进行测试仍然是保证软件质量最重要和最有效的方法。
　　软件规模的扩大同样给测试工作带来了新的问题，手工测试的速度太慢，效率太低。因此人们想到了自动化测试，想通过脚本程序的运行让测试工作自动进行。然而哪些测试内容可以自动化，什么时候进行自动化，这些都是常让测试人员困惑的问题，因为测试自动化是一种新的测试方法，没有什么经验可循。
　　本书的两位作者都是软件测试自动化的专家，在业界最早进行了数据驱动自动化测试的实验并取得了成功。在本书中，他们通过深入浅出的论述和实际的例子向读者介绍了软件测试自动化方法。不同于泛泛而谈，本书中介绍的方法都是以实际案例为基础进行论述和分析的，因而具有极强的操作性，相信各位读者看完全书后也会有自己的体会。对于读者而言，本书致力于讨论软件自动化测试的以下问题：
　　●实施自动化测试时如何考虑测试过程?
　　●什么类型的测试可以自动化实现?
　　●自动化测试的时机如何确定?
　　●自动化测试的内容是什么?
　　●实施自动化测试时如何在时间和代价约束下考虑自动化测试的有效程度?
　　本书的目的是尽量提供对软件自动化测试概念和实施过程的清晰认识和理解。
　　本书共有10章：第1、2章介绍了软件测试自动化的概念及其应用场合；第3章讲述了自动化测试的准备工作，包括测试需求和测试数据的定义；第4章介绍了自动化测试脚本的相关知识；第5、6、7章分别详细讲述了单元测试、集成测试、系统徊归测试的具体方法和内容；第8章深入介绍了CSDDT的知识；第9章的内容为手工测试与自动化测试的结合；第10章讲述了自动化测试的管理。此外本书的附录还包括关于软件测试自动化的网上讨论、自动化实施的方案模板。这些对于读者进一步了解学习和实际应用都会有所帮助。
　　我们相信，本书不仅对软件测试人员提供有效帮助，对关心软件质量和软件过程控制的开发人员也有非常大的参考作用。希望本书的翻译出版能为提高国内软件自动化测试水平作出一点贡献。
　　全书由邓波、黄丽娟、曹青春、崔晓斐、王梅蓉、李昂、金旭、赵宏智、卢世凤、齐悦、郝敏、曹振南、韦华颖、刘学敏等进行翻译。本书最后由邓波统稿。由于时间仓促、、且译堵的水平有限，在翻译过程中难免会出现一些错误，请读者批评指正。
　　译　者
　　2003年5月

第1章　什么是测试自动化
1．1　请拒绝新模型
1．1．1　生命周期不是过程
1．1．2　工具不是过程
1．2　自动化需要达到什么程度才足够
1．3　测试过程的各方面
1．3．1　测试计划
1．3．2　测试设计
1．3．3　测试实现
1．4　辅助工作
1．5　测试自动化组的范围和目标
1．5．1　范围
1．5．2　自动化测试框架的假设、约束条件和关键的成功因素
1．6　测试自动化框架的产物
1．7　测试工具分类
1．8　小结
1．9　参考文献

第2章　了解伺时以及对什么进行自动化
2．1　概述
2．2　何时自动化系统测试
2．2．1　自动化的时间总是第一因素
2．2．2　一个极端的例子
2．2．3　一个定量的例子
2．3　对什么进行自动化
2．4　关于创建测试脚本的一点注意事项
2．5　小结
2．6　参考文献

第3章　从头开始：定义测试需求、设计测试数据
3．1　软件刷试需求
3．2　需求收集和测试计划自动化
3．3　从软件需求到测试需求再到测试条件：一个自动化方法
3．4　需求管理与可跟踪性
3．5　功能测试数据设计
3．5．1　黑箱(基于需求的)方法
3．5．2　灰箱(基于需求和代码的)方法
3．5．3　白箱(基于代码的)方法
3．6　基于需求的方法
3．6．1　需求驱动的因果测试
3．6．2　等价划分、边界分析和错误猜测
3．6．3　为等价类定义边界条件
3．6．4　错误猜测
3．7　混合(灰箱)方法
3．7．1　决策逻辑表
3．7．2　DLT作为软件测试工具
3．7．3　一个自动的DLT设计工具
3．8　基于代码的方法
3．8．1　基本测试回顾
3．8．2　基本测试技巧
3．9　小结
3．10　参考文献

第4章　纵观自动化测试脚本的发展及测试的自动化程度
4．1　开发自动化测试脚本
4．1．1　单元级别的测试
4．1．2　系统级别的测试
4．1．3　特殊的系统级别的测试
4．2　记录还是编写测试脚本
4．3　小结
4．4　参考文献

第5章　自动化单元测试
5．1　引言
5．2　单元测试的合理性
5．3　单元测试过程
5．4　严格的单元测试方法
5．5　单元测试规格说明
5．6　单元测试的任务
5．7　单元测试的经验法则
5．8　单元测试数据
5．9　单元测试框架
5．10　小结
5．11　参考文献

第6章　自动化集成测试
6．1　引言
6．2　什么是集成测试
6．3　日常构建版本冒烟测试
6．4　构建冒烟测试的目标
6．5　自动化构建版本冒烟测试清单
6．6　小结
6．7　参考文献

第7章　自动化系统徊归测试框架
7．1　数据驱动方法
7．2　框架驱动(结构化)测试脚本
7．2．1　开发框架驱动测试脚本
7．2．2　ArcherGroup框架
7．3　业务规则测试
7．4　GUI测试
7．5　属性测试
7．6　输人数据测试
7．7　格式化测试数据文件
7．8　应用级错误
7．9　创建外部数据输入文件
7．10　数据文件小结
7．11　业务规则测试的代码构造
7．11．1　Shell脚本
7．11．2　主脚本
7．11．3　读取数据以后
7．12　使代码清晰健壮
7．13　CarlNagle　DDE框架
7．13．1 DDE综述
7．13．2 DDE发展成果
7．14　KeithZambelich提出的面向Mercury Interactive产品用户的测试计划驱动测试框架
7．15　Zambelieh方法总结
7．16　"测试计划驱动"方法体系结构
7．17　小结
7．18　参考文献

第8章　深入了解控制同步数据驱动测试框架
8．1　创建数据驱动测试脚本
8．2　实现CSDDT方法
8．3　一般问题和解决方法
8．3．1　问题：数据输入
8．3．2　解决方法：使用输入数据文本文件
8．3．3　问题：程序流改变
8．3．4　解决方法：让输入数据做驱动
8．3．5　问题：管理应用程序改变
8．3．6　解决方法：记录或修改非常小的一部分代码
8．4　设置通用的启动和结束测试条件
8．5　修改已记录的代码以接受输入数据
8．6　非常重要的习惯
8．7　为通用操作创建函数--隔离命令对象
8．8　继续程序流
8．9　使用多个输入记录来创建测试场景
8．10　使用动态数据输入--关键字替换
8．11　使用库文件或包含文件(Rational Robot中的*.sbh文件和*.sbl文件)
8．12　实用脚本
8．13　调试脚本--当测试发现错误的时候
8．14　实现CSDDT模板脚本
8．15　DD脚本
8．16　SQABasic32包含文件
8．17　一个CSDDT框架的例子
8．17．1　脚本文件清单
8．17．2　库文件清单
8．17．3　安装例子文件的说明
8．18　小结
8．19　参考文献

第9章　用自动化工具改进手工测试过程
9．1　引言
9．2　半自动化手工测试步骤
9．3　使用列表框
9．4　手工测试中的产物
9．5　小结
9．6　参考文献

第10章　管理自动化测试
10．1　编写有效的测试脚本和测试数据
10．2　管理手工和自动化测试脚本
10．3　测试套件维护
10．4　小结
10．5　参考文献
附录A　数据驱动自动化：用户组
讨论
附录B　自动化测试的术语与定义
附录C　使用Rational Suite TestStudio的
测试自动化项目计划的例子
附录D　测试自动化项目工作计划
模板