本书内容包括：敏捷开发中的测试自动化；管理层的支持是如何导致自动化成功与否的；设计良好的测试件结构和抽象层的重要性；如何衡量收益和ROI（投资回报率）；管理的因素，包括技能、项目规划、项目领域和项目期望；基于模型的测试（MBT）、猴子测试和探索式测试自动化；标准、沟通、文档和灵活性在企业级测试自动化中的重要性；测试支持性活动的自动化；对哪些测试进行自动化，以及不要对哪些进行自动化；自动化测试的隐藏开销：对其进行的维护和错误分析；测试自动化的正确目标：为什么“为了发现bug”并不是一个好的目标；重点强调一些学到的教训，真知灼见和有用的小技巧等等自动化测试的许多方面。
自动化测试不再是奢侈品而成为软件测试的必需品。随着应用程序和系统规模越来越大、越来越复杂，仅仅依赖手动测试已经无法全面地测试系统。随着技术的变动，越来越多的公司加入到了敏捷开发的阵营中，必须对这些程序进行测试，而且速度要快。测试自动化是非常基本的需求，但有时糟糕的自动化只会适得其反——如何才能知道应该在哪里进行自动化呢？
作者Dorothy Gramham和Mark Fewster之前写的《Software Test Automation》这本书在自动化测试领域影响深远，它为很多公司指明了测试成功的方向。本书讲述了一些公司应用自动化的经历，其中涉及了很多项目，从复杂的政府部门系统到医疗设备，从SAP业务过程开发到Android移动应用和云计算。本书讨论了管理方面和技术方面的因素，讲述了成功和失败的例子、卓越的想法以及灾难性的决定，为读者提供了可以借鉴的经验教训。
本书对于那些考虑、实施、使用、管理测试自动化的人来说是无价之宝。测试人员、开发人员、自动化人员以及自动化架构师、测试经理、项目经理、分析师、QA专家和技术总监都可以从本书受益。
本书主要内容：
敏捷开发中的测试自动化
管理层的支持力度是如何导致自动化成功和失败的
设计良好的测试件结构和抽象层的重要性
如何衡量收益和ROI
管理的因素，包括技能、项目规划、项目领域和项目期望
基于模型测试（MBT）、猴子测试和探索式测试的自动化
标准、沟通、文档和灵活性在企业级测试自动化中的重要性
测试支持性活动的自动化
明智的选择：对哪些测试进行自动化、不要对哪些测试进行自动化
自动化测试的隐藏开销：对其进行的维护和错误分析
测试自动化的正确目标：为什么“为了发现bug”并不是一个好的目标
重点强调一些学到的教训、真知灼见和有用的小技巧
作者简介
Dorothy Graham 软件测试领域的大师级人物，有着40余年的软件测试经验，曾获得软件测试领域欧洲卓越成就奖。世界知名的顾问，Grove Constaltants公司的创始人，在软件测试的学术研究方面有极深的造诣，写作经验也极为丰富，著有软件测试领域的世界名著《Software Test Automation》，影响深远。
Mark Fewster 软件测试领域的大师级人物，在软件测试和自动化领域有30余年的工作经验。现担任英国计算机协会软件测试专家兴趣小组（BCS SIGiST）和信息系统考试委员会 （ISEB）的委员。最近20年致力于为软件测试的各个方面提供培训和咨询服务。经常在国内和国际会议与研讨会上发表演讲，并且与Graham合著了软件测试领域的世界名著《Software Test Automation》。
译者简介
朱少民 国内软件测试界的领军人物和资深专家，二十多年来一直从事软件测试、质量管理和过程改进等工作，先后出版十多部著作，包括测试方面的畅销书《完美测试》、《全程软件测试》、《轻轻松松自动化测试》、《软件测试方法和技术》等，经常在国内外会议上发表演讲。之前曾任思科-网迅（中国）软件有限公司QA高级总监，目前是同济大学软件学院教授、中国科技大学软件学院教指委委员。
用于软件测试自动化的工具已经发展了近30年，但还是有很多自动化测试的尝试会失败，或者至少并非那么成功，这是为什么呢？
在笔者的前一本书《Software Test Automation》中，提出了一些有效的自动化测试原则，为了验证这些原则今天是否依然有效，以及是否还有其他的原则可以应用于自动化测试中，所以我们开始收集现实世界中自动化测试实施案例。结果很高兴地发现：在过去10年中，许多人在软件测试自动化领域取得了很大的成功，其中不少人参考了我们的书。当然，我们并不是唯一描述或发现了这些好的自动化实践的人，然而找寻一些成功的而且能在一段时间内都适用的实践在今天看来还是难以实现。我们希望本书中的故事会帮助更多的人在自动化测试的尝试中取得成功。
本书收集了当前的很多关于自动化测试的真实故事。自从我们上一本关于自动化测试的书在1999年出版以来，自动化测试技术有了很大的飞跃。我们想要找出什么样的方法是成功的、哪种应用程序正在通过自动化测试来完成测试的，以及近几年来测试自动化是如何改变的。不同的人会用不同的方式去解决自动化相关的问题——我们想要知道我们从他们的经历中能学到什么，以及在什么样的情形下如何用新的方式应用自动化测试。
本书中的案例研究包括一些成功的方法，同时也包括一些不成功的方法。本书旨在教会读者如何避免错误，以及如何从实际成功的例子里汲取经验教训。本书旨在帮助读者从其他一些专家真实的经历中学到大部分自动化测试的经验。
本书中的案例研究主要是关于测试执行过程中的自动化，其他一些自动化的类型在一些章节中也会提及。我们着重研究系统级的自动化（包括一些用户验收测试），尽管其他的一些章节也会包括单元测试或集成测试。我们将在不同的应用程序、环境和平台下描述测试自动化，每章用到的工具包括商业的、开源的以及公司内部的程序，这些工具可以用在传统开发或者敏捷开发项目中。我们很惊奇地发现有近90种商业或者开源软件正在使用，这些软件的名称列在附录A中（附录包含了每章作者用到的各种工具，不仅仅是测试用的工具）。
本书描述的实例都是真实的，虽然在一些案例中没有透露作者或者公司名称。我们鼓励这些案例研究的作者去描述到底发生了什么，而不是仅仅给我们一些通常的建议，所以本书的描述是相当真实的。
在收集这些实例的过程中，我们也遇到了很多困难，比如，我们很难涉及各种行业中的应用。那些在公司里坚持不懈地致力于发展自动化测试的人给我们留下了深刻的印象。然而，我们也遇到了他们中的许多人遇到的一些困难，这些困难有时候会导致测试失败。相信本书中讲述的经历会帮助你在自动化测试道路上更加成功。
案例研究的附加内容（我们得到的经验）
本书并不是一系列文章的简单组合，我们和每一章的作者一起工作，以便将一些最有价值的信息传达给读者。我们对于每一章的审校都是非常全面的，我们通常进行很多轮审校，提出问题及改动建议（特别感谢每章作者的耐心和他们传达的额外信息）。我们最开始收集的文档超过了500篇，所以这里每一章的内容都是精挑细选的。
我们会提供一些真知灼见、经验教训和小窍门，帮助读者从本书中尽可能汲取大部分知识。每一章都有我们的一些评论，这些评论包含了一些我们认为非常有用的要点。仔细注意以下这些有用的标记：
真知灼见（good point）：值得注意的观点（即使它们并不是那么新）。
真知灼见
管理层的支持至关重要，但是期望必须是符合实际的。
经验教训（lesson）：从失败中学到的教训——我们最好不要做的事情。
经验教训
和软件开发一样，自动化开发也需要进行规范化。
小窍门（tip）：一些看起来新的、有趣的诀窍，可用来帮助我们解决特定的问题。
小窍门
使用一个“转换表”记录一些可能发生改变的事情，这样自动化可以使用一些不变的标准术语。
在你读每一章的时候，我们会用一些感叹词来提醒读者重要的地方，比如，“注意这里”，“看这里”或者“这会非常有用”。
如何阅读本书
每一章都是独立的，读者能够以任何次序阅读各章节。本书的章节安排是为了让那些从头读到尾的读者更好地体验自动化测试的各个方面。
为了帮读者确定读各章的顺序，请看表P-1，其中总结了各章的特点。这张表让读者能够初步了解各章包含的针对特殊应用的工具和开发方法等，读者也能快速找到和其最相关的章节。
在“前言”之后，第0章描述了全书概况，并且对书中关于管理层和技术的问题发表了我们自己的观点（以及自己的测试件体系结构的图例）。第0章将各作者在自动化过程中涉及的或与任务相关的建议重点提炼出来。这一章是本书的“行动纲要”（executive summary）。
第1~ 28章讲述的是多个案例研究，每一章都是由一名或多名作者撰写，在这些章中，作者主要讲述了：他们做了什么，哪些方案可行性良好，什么方案出现了问题，以及学到了哪些教训。一些章涉及了非常专门的信息，如文件结构和自动化代码；而其他章讲述的内容则更加通用。有一章（第10章）的内容来自于《Software Test Automation》这本书，我们更新了其内容，其他章节都是新写的。
第29章可以单独看成一本迷你书——它包含了一系列短篇故事，取材自几十个人身上发生的真实故事，故事的长度从半页到几页不等，每个故事都很有趣，并且包含了很多有用的信息。
在本书的最后，附录包含了在文章中提到过的工具，这些工具有些是商业工具，有些是开源工具。
致谢
本书包含的资料来自于我们认识的、在会议中遇见的那些人，还有一些人是在看到了我们发布在网站和实事通信上找寻软件测试自动化方面作者的材料后，响应并投稿的。2009年秋天，我们开始了本书的编写工作，从2009年12月到2011年12月，我们两个人在本书上花费了850多个小时，这还不算所有章节和奇闻轶事的作者所花费的时间。
感谢所有章节的作者，感谢他们花费大量时间和精力写作，并且在本书编写的整个阶段都的我们保持联系。同时感谢那些参与第29章写作的作者：Michael Albrecht、Mike Bartley、Tessa Benzie、Jon Hagar、Julian Harty、Douglas Hoffman、Jeffrey S. Miller、Molly Mahai、Randy Rice、Kai Sann、Adrian Smith、Michael Snyman、George Wilkinson和Jonathon Lee Wright。
感谢所有在本书编写过程中给予帮助的人：Claudia Badell、Alex Blair、Hans Buwalda、Isabel Evans、Beth Galt、Mieke Gevers、Martin Gijsen、Daniel Gouveia、Linda Hayes、Dion Johnson、Audrey Leng、Kev Milne、Andrew Poller、David Trent以及Erik Van Veenendaal。同时感谢参与各章审校的作者。
感谢Pearson出版团队，感谢他们的帮助和鼓励，以及为出版这本书所做的工作，他们是：Christopher Guzikowski、Raina Chrobak、Sheri Cain、Olivia Basegio和自由职业者Carol Lallier。
——Dorothy Graham
Macclesfiled，英国
www.dorothygraham.co.uk
——Mark Fewster
Llandeilo，英国
www.grove.co.uk
2011年12月
表P-1
章 号 作 者 应用程序领域 地 点 生 命 周 期 项目人员数量/人
1 Lisa Crispin 金融、Web 美国 敏捷开发 9~12
2 Henri van de Scheur 数据库 挪威 3~30
3 Ken Johnson,
Felix Deschamps 企业服务器 美国 带有敏捷因素的传统开发周期 >500
4 Bo Roop 测试工具 美国 瀑布模型 12~15
5 John Kent 从大型主机到基于Web的系统 英国 传统开发周期 40
6 Ane Clausen 两个项目：保险业和养老金 丹麦 没有特定模型，
敏捷开发 3~5
7 Elfriede Dustin 政府：国防部 美国 敏捷开发 几百
8 Alan Page 设备驱动程序 美国 传统开发周期 几百
9 Stefan Mohacsi,
Armin Beer 欧洲航天局的服务 奥地利、意大利和德国 传统开发周期 >100
10 Simon Mills 金融：保险业 英国 混乱的模型，而且一直在变动 几十
11 Jason Weden 网络设备 美国 传统开发周期（瀑布模型） 25
12 Damon Yerg（笔名） 政府服务 澳大利亚 V模型 几百
13 Bryan Bakker 医疗设备 荷兰 V模型 50
14 Antti J skel inen,
Tommi Takala,
Mika Katara Android平台上的智能手机应用程序 芬兰 2
15 Christoph Mecke,
Melanie Reinwarth, Armin Gienger ERP系统（SAP），两个项目：卫生服务系统和银行系统 德国和印度 传统开发周期 10
16 Bj rn Boisschot 能源部门的SAP应用程序 比利时 传统开发周期 12
章 号 作 者 应用程序领域 地 点 生 命 周 期 项目人员数量/人
17 Michael Williamson 基于Web的系统，分布式系统 美国 敏捷开发 15
18 Lars Wahlberg 金融市场系统 瑞典 增量开发到敏捷开发 20（通常情况下）
19 Jonathan Kohl 各种系统，从Web到嵌入式 加拿大 敏捷开发和传统开发周期 几个~60
20 Albert Farré,
Benet,Christian Ekiza Lujua,
Helena Soldevila
Grau, Manel
Moreno Jáimez,
Fernando Monferer Pérez, Celestina Bianco 4个项目，都是医疗软件 西班牙、美国和意大利 螺旋式开发，原型开发，瀑布模型 2~17
21 Seretta Gamda 保险业 德国 迭代开发 27
22 Wim Demey 定制的软件包 比利时 传统的V模型
23 Ursula Friede 保险业 德国 传统开发周期（V模型） 30
24 John Fodeh 医疗应用程序和设备 丹麦 传统开发周期
（V模型），增量模型 30
25 Mike Baxter,
Nick Flynn,
Christopher Wills,
Michael Smith 空中交通控制 英国 传统开发周期 15~20
26 Ross Timmerman,
Joseph Stewart 嵌入式：汽车系统 美国 分阶段的瀑布模型 8
27 Ed Allen,
Brian Newman 基于Web的、移动的、桌面的、社交渠道的（语音、聊天、email） 美国 传统的开发周期 28
28 Harry Robinson,
Ann Gustafson
Robinson 针对电话系统的错误报告系统 美国 瀑布模型 总共30人，4人直接参与项目
“你手中的这本书是关于自动化测试的不可多得的至宝，它讲述了在自动化测试的实践中什么是好实践，什么不是。本书使你避免陷入自动化测试的泥潭，从而更可能取得成功。”
——Linda Hayes
“在本书中，Dorothy Graham 和Mark Fewster通过一系列引人注目的案例研究展示了自动化测试中的各种学习经历，每个案例研究都讲述了自动化使用的工具和方法。本书内容如此全面，是同类书中第一本带读者深入到自动化测试世界中的书籍。本书包含了许多案例研究，案例研究讲述了在自动化过程中都发生了什么，案例包含的项目来自各行各业，测试环境包括了各种技术环境。通过找出各个案例之间的类似点以及对某些主题的重复，能够帮助读者更加理解应该避免哪些错误。通过本书，读者可以了解到需要做些什么才能取得测试自动化的成功。
——Andrew L. Pollner， ALP International Corporation的总裁和CEO
“在畅销书 《Software Test Automation: Effective Use of Test Execution Tools》出版之后很多年，Mark Fewster和Dorothy Graham又写出了一本畅销书。敏捷方法已经赋予自动化测试在当今测试实践中的主导地位。本书从各种不同视角讲述了自动化测试的案例研究，这些案例写得都很好，这使得本书非常有实用价值。我强烈地将本书推荐给那些从事或者想要从事自动化测试的人。”
——Erik van Veenendaal，Improve Quality Services的创始人，TMMi Foundation 的副主席
“阅读本书就像参加一个测试学术会议一样，书中包含了多个案例研究和对自动化测试深刻的见解。但是本书要比参加学术会议便宜得多，而且还不需要到处奔波去参加会议。令我印象尤其深刻的是，本书在第0章中浓缩了我能想到的使得自动化成功的各个方面。这是在学术会议中得不到的。
——Hans Buwalda
“本书包含了大量令人兴奋的、写得很好的、涉及范围极广的案例研究，案例讲述了在现实世界中自动化测试的经验、技巧、教训和其他值得记住的要点。对于任何需要向经理和同事证明在自动化实践中什么是好的、什么是不好的人员来说，本书都是非常有用的。”
——Isabel Evans，FBCS CITP，质量经理，Dolphin Computer Access
“本书首先讲述了使得自动化测试有效的基本手段。之后讲述了各种情境下的自动化测试中值得注意的事项。本书会指导你：因合理的缘由而应用自动化测试，如何采取适合于公司和项目的自动化方法，以及如何避免各种错误。对于任何参与测试的人——无论是管理人员、测试人员，还是自动化测试人员，本书都非常有价值。”
——Martin Gijsen，自由的测试自动化架构师
“Fewster和Graham为我们提供了连接自动化测试理论与现实之间的一座重要桥梁。自动化测试的框架设计和实施是一种非精确的科学，亟须一套可复用的标准，而这套标准只能从不断涌现的先例中总结出来，而本书则能帮助建立这样的先例。就如同在司法系统中使用先前判决案例作为支持当下做出法律判决的依据一样。在自动化框架设计与实施上，从本书所能习得的各式案例，适用于帮助人们做出当下的决定，支持这样的活动或教育相关人员。1
——Dion Johnson，Automated Testing Institute（ATI）软件测试顾问及首席咨询师
“即使我一贯秉持‘自动化测试无用’的立场，本书也的确让我驻足思考。它让我开阔了思维，同时也让我做出‘噢，原来这种情况我没考虑到’的反省。对于那些想要参与自动化测试的公司，我推荐将本书作为入门参考书。”
——Audrey Leng
“本书是一个惊人的成就。我相信它是自动化测试方面写得最好的书之一。Dot和Mark通过对28个案例研究的叙述给予我们一个完全崭新的概念，包括引人注目的小窍门、真知灼见以及经验教训。这些案例研究来自于生活经验中，既有成功的，也有失败的，包括了自动化的多个方面、不同的环境以及多种混合的解决方案。书本来就是智慧之源，而作者采用了非常好的方式——利用叙述故事的形式给我们留下很深的印象，从而增强学习效果。无论读者处于何种层次，本书是所有想要进入或者已经进入自动化测试领域的人所必备的。它的确是同类型书中独一无二的。”
——Mieke Gevers
计算机\程序设计
自动化测试不再是奢侈品而成为软件测试的必需品。随着应用程序和系统规模越来越大、越来越复杂，仅仅依赖手动测试已经无法全面地测试系统。随着技术的变动，越来越多的公司加入到了敏捷开发的阵营中，必须对这些程序进行测试——而且速度要快。测试自动化是非常基本的需求，但是糟糕的自动化只会适得其反——如何才能知道应该在哪里进行自动化呢？
作者Dorothy Gramham和MarkFewster之前写的《Software Test Automation》这本书在自动化测试领域影响深远，它为很多公司指明了测试成功的道路。现在本书讲述了一些公司应用自动化的经历，本书涉及了很多项目，从复杂的政府部门系统到医疗设备，从SAP业务过程开发到Android移动应用和云计算。本书讨论了管理方面和技术方面的因素，讲述了成功和失败的例子、卓越的想法和灾难性的决定，为读者提供了可以借鉴的经验教训。
本书对于那些考虑、实现、使用、管理测试自动化的人来说是无价之宝。测试人员、分析师、开发人员、自动化人员以及自动化架构师、测试经理、项目经理、QA专家和技术总监都可以从本书受益。
本书主要内容：
敏捷开发中的测试自动化
管理层的支持力度是如何导致自动化成功与否的
设计良好的测试件结构和抽象层的重要性
如何衡量收益和ROI
管理的因素，包括技能、项目规划、项目领域和项目期望
基于模型的测试（MBT）、猴子测试和探索式测试自动化
标准、沟通、文档和灵活性在企业级测试自动化中的重要性
测试支持性活动的自动化
对哪些测试进行自动化，以及不要对哪些进行自动化
自动化测试的隐藏开销：对其进行的维护和错误分析
测试自动化的正确目标：为什么“为了发现bug”并不是一个好的目标
重点强调一些学到的教训、真知灼见和有用的小技巧
（英）Dorothy Graham, Mark Fewster 著：暂无简介
朱少民 张秋华 赵亚男 译：暂无简介
时光荏苒，转眼间本书的翻译工作已经进行了半年多，算是没有辜负出版社的期望，按时完成翻译任务。当初，看到本书的英文版，就有翻译本书的强烈愿望。本书作者Dorothy Gramham和Mark Fewster之前写的《Software Test Automation》就很有影响，作为其姊妹篇，本书一定会更胜一筹。更让我感兴趣的是本书的组织结构和众多引人入胜的故事。
本书的作者实际不只是Dorothy Gramham和Mark Fewster他们两位，而是30多位来自世界各地的自动化测试的成功探索者，包括Lisa Crispin、微软的Alan Page等测试大师。本书可以看做是这些自动化人员的自传，每一章自成体系，一章一个案例，进行深入的剖析，30多个案例形成了自动化测试的一顿大餐。这些从事自动化测试多年的测试人遍布全球，分布在美国、英国、德国、印度、荷兰、挪威、丹麦、比利时、加拿大、澳大利亚等地，同我们分享他们在自动化测试过程中所经历的酸甜苦辣，其中有过迷茫，有过失败，也有喜悦和激动。自动化测试的故事，有浪漫之旅，也有历经坎坷、披荆斩棘才走完的艰辛之路；更有凤凰涅槃、绝地逢生，迎来自动化测试春天的感人故事。这些自动化测试之旅，短的有一年，而长的会跨越六年、持续十多年，甚至像《星球大战》那样，有前传，还有后传。每个故事都是他们亲身经历的，让我们感同身受。
本书就像是一本写实的小说，里面有很多个性鲜明的人物。如喜欢将还没有通过各项测试的正在开发中的版本向客户展示的经理，也有偶然间因为某些突然冒出来的想法从开发转向测试的技术人员；既有人认为自己作为测试人员不应该写代码，也有经理认为能写代码的都是程序员，都应该去开发部门等；既有自己做了很伟大的事情却因为公司制度以及测试衡量标准的原因导致没有能够升迁的技术人员，也有为各种软件公司提供咨询的专家。当我们阅读本书的时候，仿佛自己也参与到了这些项目的自动化测试之中。当看到项目所取得的惊人成就时，一种自豪感会油然而生；当看到应用自动化导致项目越来越糟时，自己也会感到迷茫，不知何去何从；在突破层层困难，拨开云雾见天日之时，自己心中便会有“柳暗花明又一村”的顿悟；当自己辛辛苦苦搭建起来的框架和之前无数个日日夜夜的努力，却因为管理层的原因导致项目中断时，不禁会感到彷徨与无奈。
本书展示了丰富的自动化测试对象，除了经典的政府信息系统、企业ERP系统、通用的数据库系统之外，还包括从主机到Android移动应用，从汽车电子系统、医疗设备到设备仿真、硬件接口等的自动化测试。而且，本书自动化测试所处的环境也是千差万别，所涉及的项目之广也是同类书籍所不及的：
有涉及传统的V模型，也有涉及敏捷的开发模型；
有基于关键系统（如北大西洋东部领空的空中交通控制系统）的自动化测试，也有一般商业系统（如保险公司）的自动化测试；
有基于模型的自动化测试，让我们领略数学严谨的同时，见证低成本高收益的自动化测试；
有针对自由的猴子测试、探索式测试来实现其自动化方式，让手动测试和自动化测试相辅相成；
有针对云端实施自动化测试、在线的持续回归测试，将基于产品的自动化测试变更为基于服务的自动化测试。
在翻译本书的同时，译者深深地感受到了自动化的魅力和力量。测试自动化在节省了大量人力的同时，也在推动整个软件行业的前进。正如本书所述，正确地采用自动化能够极大地提升软件的质量和测试的效率。然而在错误的地方应用自动化只会带来更大的开销。本书呈现了一些失败的案例，目的是告诉读者，单单技术方面的因素并不能决定自动化测试的结果，管理方面的因素也要考虑到其中。如自动化框架很好、人员积极性很高，并且已取得了不少积极的效果，但是却因为其他一些无法抗拒的因素最终走向了失败。在很多故事中，我们可以看到作者反复强调：“一些经理本身不懂测试自动化，他处在经理这个位置更多是像被强插在这个位置的。”这在现实中并不少见，公司应该对经理进行培训，使其可以促进自动化测试的良好发展，而不是作为阻碍因素。本书可以为这些经理提供各种真知灼见，指导他们如何促进自动化的发展，也可以指导技术人员如何斗智斗勇，从经理那里获得应有的资源，同时尽量从自动化测试启动时就让经理们也参与其中，并通过不断地向他们展示自动化进度和成果来获取其支持。
正如一句广告词“简约而不简单”，这句话用来描述本书恰到好处。每个章节都用一种平易近人的语气来讲述，故事好像一个接着一个地发生。但是作者想要表达的事情并不简单，作者不断地去找寻各种方式，向读者呈现一个个故事背后的必然性和偶然性，并且强调什么样的实践是好的，什么是坏的。作者的一些观点在本书中多次出现，如“自动化测试并不便宜”、“不要忽略管理因素”、“自动化测试是对手动测试的补充而非替代”。作者反复强调这些，就是要警示读者，在自动化领域有很多经验教训，我们应该对此有着清晰的认识。这些观点一遍一遍被反复强调，警示着我们不要重蹈覆辙。在阅读本书时，除了了解和掌握自动化测试的各种应用方法、技术和工具之外，还会对自动化实施及其引导、管理等方面的各项影响因素有所明察，从而杜绝虚幻、脱离实际的想法。看完本书，我们能更好地领会自动化测试的自然规律，吸取很多前人留下的宝贵经验，增长见识，使我们自己少走弯路，采用更有效的自动化测试方式和方法，以完成我们的测试使命。
最后，感谢机械工业出版社华章分社引进了这么优秀的英文原著，并给予了我们大力支持，使得本书的中译本能够和读者见面。我们还要感谢天津策艺公司柴阿峰、迈瑞血球研发中心肖利琼、宁波大学刘慰等三位友人以及同济大学郭智超、俞诗嘉等两位同学。他们从百忙中抽出宝贵时间，帮忙校对，进一步提高了翻译质量。
希望本书能成为一种有效的助推力量，让更多的测试人员参与到自动化测试的实践中来，促进国内自动化测试百花齐放、百家争鸣。使自动化测试不再是奢侈品而成为软件测试的必需品，惠及千千万万的软件项目，最终促进国内软件行业的发展。
译者
于美丽的同济大学嘉定校区
本书赞誉
译者序
序
前言
第0章 案例研究反思 / 1
0.1 管理层问题 / 1
0.2 技术因素 / 6
0.3 总结 / 12
第1章 敏捷团队的自动化测试之旅：第一年 / 13
1.1 本案例研究的背景 / 14
1.2 整个团队的承诺 / 14
1.3 建立自动化策略 / 15
1.4 利用验收测试驱动开发，使用FitNesse测试GUI / 18
1.5 使用增量方法 / 20
1.6 正确度量 / 20
1.7 庆祝成功 / 21
1.8 引入工程冲刺 / 22
1.9 团队成功 / 22
1.10 持续改进 / 24
1.11 总结 / 24
第2章 终极数据库自动化 / 25
2.1 本案例研究的背景 / 25
2.2 测试中的软件 / 26
2.3 自动化测试的目标 / 27
2.4 开发内部测试工具 / 28
2.5 结果 / 30
2.6 管理自动化测试 / 31
2.7 测试套件和类型 / 31
2.8 现状 / 33
2.9 在经过一段很艰难的时光后才得到的经验教训 / 33
2.10 如何使用自动化测试书中的建议 / 34
2.11 总结 / 36
2.12 致谢 / 36
第3章 移动到云端：TiP的演化——在线的持续回归测试 / 37
3.1 本案例研究的背景 / 38
3.2 将测试移到云端 / 39
3.3 如何实施TiP / 41
3.4 每月服务评审记分卡样例 / 43
3.5 Exchange TiP v2——将TiP迁移到Windows Azure云端 / 46
3.6 我们的心得 / 47
3.7 总结 / 49
3.8 致谢 / 50
第4章 Automator的自动化 / 51
4.1 本案例研究的背景：我的第一份工作 / 52
4.2 我的伟大构想 / 53
4.3 一个突破 / 54
4.4 总结 / 58
第5章 自动化人员自传：从主机到框架的自动化 / 60
5.1 本案例研究的背景 / 61
5.2 主机绿屏自动化测试项目 / 63
5.3 主机和基于脚本工具的差异 / 65
5.4 使用新的基于脚本的工具 / 66
5.5 IBM Maximo的自动化测试 / 70
5.6 总结 / 74
5.7 参考文献 / 74
第6章 项目1：失败！项目2：成功！ / 76
6.1 本案例研究的背景 / 77
6.2 项目1：失败 / 77
6.3 项目2：成功 / 78
6.4 下一个时间段：真实地测试 / 85
6.5 总结 / 92
第7章 复杂政府系统的自动化测试 / 93
7.1 本案例研究的背景 / 93
7.2 自动化需求分析 / 94
7.3 我们的自动化测试解决方案——自动化测试和再测试 / 95
7.4 自动化测试解决方案的应用 / 101
7.5 总结 / 102
第8章 设备仿真框架 / 103
8.1 本案例研究的背景 / 103
8.2 设备仿真框架的诞生 / 104
8.3 构建DSF / 105
8.4 自动化目标 / 106
8.5 案例研究 / 107
8.6 没有银弹 / 110
8.7 总结 / 111
8.8 致谢 / 111
第9章 ESA项目中基于模型的测试用例生成 / 112
9.1 本案例研究的背景 / 113
9.2 基于模型的测试和测试用例生成 / 113
9.3 我们的应用：ESA多任务用户服务项目 / 116
9.4 学到的经验和教训 / 121
9.5 总结 / 125
9.6 参考文献 / 126
9.7 致谢 / 126
第10章 10年过去了，项目还在进行 / 127
10.1 本案例研究的背景：之前的故事 / 128
10.2 每月进行自动化测试的保险报价系统 / 128
10.3 接下来发生了什么 / 138
10.4 总结 / 138
第11章 凤凰在灰烬中重生 / 141
11.1 本案例研究的背景 / 141
11.2 凤凰的诞生 / 142
11.3 凤凰的死亡 / 144
11.4 凤凰的重生 / 145
11.5 凤凰的新生 / 148
11.6 总结 / 152
第12章 政府机构运作系统的自动化测试之旅 / 155
12.1 本案例研究的背景 / 156
12.2 该机构的自动化测试 / 156
12.3 2000~2008年 / 159
12.4 三次巧合 / 162
12.5 在测试团队中完善能力 / 165
12.6 未来的方向：继续旅程 / 166
12.7 总结 / 168
第13章 使用硬件接口的自动化可靠性测试 / 169
13.1 本案例的研究背景 / 170
13.2 采取措施的必要性 / 170
13.3 自动化测试启动（增量式方法） / 171
13.4 来自管理层的支持 / 172
13.5 测试框架的进一步开发 / 174
13.6 部署并改进报告形式 / 177
13.7 总结 / 178
第14章 Android应用的基于模型GUI测试 / 180
14.1 本案例研究的背景 / 181
14.2 使用TEMA工具集的MBT / 182
14.3 应用行为建模 / 187
14.4 测试用例的生成 / 190
14.5 连接和适配 / 191
14.6 结果 / 194
14.7 总结 / 194
14.8 致谢 / 195
14.9 参考文献 / 195
第15章 SAP业务流程的自动化测试 / 197
15.1 本案例研究的背景 / 198
15.2 标准和最佳实践 / 200
15.3 eCATT使用实例 / 203
15.4 总结 / 207
15.5 致谢 / 208
第16章 SAP实现的自动化测试 / 209
16.1 本案例研究的背景 / 210
16.2 项目概述 / 211
16.3 第1阶段：概念的证明 / 212
16.4 第2阶段：项目启动 / 217
16.5 总结 / 226
第17章 选择了错误的工具 / 228
17.1 本案例研究的背景 / 228
17.2 （可能）早已存在的自动化测试 / 230
17.3 必要的决策：新工具还是主要维护成本 / 231
17.4 继续推进eggPlant工具 / 233
17.5 我们在eggPlant项目之后还将做什么 / 239
17.6 总结 / 239
第18章 市场交易系统的自动化测试：十年经验和三个框架 / 242
18.1 本案例研究的背景 / 243
18.2 自动化测试框架 / 243
18.3 测试角色 / 245
18.4 抽象层 / 246
18.5 配置 / 248
18.6 成本和投资回报率 / 249
18.7 总结 / 251
第19章 自动化测试不仅仅是回归测试：发挥创造性思维 / 253
19.1 本案例研究的背景 / 254
19.2 任务自动化的两个故事 / 254
19.3 自动化测试用来支持手动探索式测试 / 258
19.4 自动化测试数据交互 / 260
19.5 自动化测试和监测 / 262
19.6 通过组合简单的工具模拟现实世界的负载 / 264
19.7 总结 / 265
19.8 参考文献 / 265
第20章 医疗设备软件需要优秀的自动化软件测试 / 267
20.1 本案例研究的背景 / 268
20.2 每个项目不同方法的比较 / 272
20.3 项目HAMLET / 274
20.4 项目PHOENIX / 275
20.5 项目DOITYOURSELF / 277
20.6 项目MINIWEB / 279
20.7 测试执行 / 280
20.8 结果报告 / 281
20.9 总结 / 283
第21章 通过后门（通过支持手动测试）进行自动化 / 287
21.1 本案例研究的背景 / 288
21.2 我们的技术解决方案 / 288
21.3 通过ISS测试站实现测试自动化 / 291
21.4 实现测试自动化 / 293
21.5 支持手动测试 / 296
21.6 新的手动测试过程 / 298
21.7 总结 / 302
21.8 参考文献 / 303
第22章 使用自动化测试为可移植性测试增值 / 305
22.1 本案例研究的背景 / 306
22.2 可移植性测试：喜欢它或者讨厌它 / 306
22.3 将软件组合起来作为解决方案 / 307
22.4 总结 / 312
22.5 致谢 / 312
第23章 保险公司中的自动化测试：感受我们测试的方法 / 313
23.1 本案例研究的背景 / 313
23.2 应用程序 / 314
23.3 目标 / 315
23.4 我们做的工作 / 315
23.5 教训 / 317
23.6 总结 / 318
第24章 使用测试猴子的冒险之旅 / 320
-24.1 本案例研究的背景 / 320
24.2 自动化回归测试的局限性 / 321
24.3 测试猴子 / 322
24.4 实现测试猴子 / 324
24.5 使用测试猴子 / 325
24.6 收益和局限性 / 328
24.7 总结 / 329
24.8 参考文献 / 329
第25章 在NATS对SYSTEM-OF-SYSTEMS的自动化测试 / 330
25.1 本案例研究的背景 / 331
25.2 测试执行工具的集成 / 333
25.3 工具的试点项目 / 333
25.4 系统使用中（In-Service）的测试模式 / 334
25.5 实现 / 334
25.6 典型的脚本模板 / 336
25.7 得到的教训 / 338
25.8 总结 / 339
第26章 对汽车电子系统进行自动化测试 / 340
26.1 本案例研究的背景 / 341
26.2 自动化项目的目标 / 342
26.3 自动化项目的简史 / 342
26.4 自动化项目的结果 / 344
26.5 总结 / 345
第27章 宏伟目标、改变和测试转型 / 346
27.1 本案例研究的背景 / 346
27.2 管理层的认可 / 347
27.3 构建自动化框架的故事 / 350
27.4 自动化测试框架的描述 / 352
27.5 测试环境 / 355
27.6 度量标准 / 356
27.7 总结 / 358
第28章 自动化探索测试：超越当前时代的例子 / 361
28.1 本案例研究的背景 / 362
28.2 什么是故障管理工具 / 362
28.3 测试故障管理系统中的事务 / 363
28.4 用编程的方法结构化测试用例 / 365
28.5 思考自动化测试的新方式 / 365
28.6 测试故障管理系统的工作流 / 366
28.7 运行中生成测试 / 371
28.8 项目的冲刺阶段 / 372
28.9 发布之后 / 373
28.10 总结 / 374
28.11 致谢 / 374
第29章 测试自动化的轶事 / 375
29.1 三个小故事 / 375
29.2 需要更多对自动化的理解 / 378
29.3 自动化测试的第一天 / 379
29.4 尝试开始实施自动化 / 384
29.5 与管理层作斗争 / 385
29.6 探索性测试自动化：数据库记录锁定 / 387
29.7 在嵌入式硬件-软件计算机环境中进行测试自动化所得到的教训 / 392
29.8 传染性的时钟 / 395
29.9 自动化系统的灵活性 / 397
29.10 使用过多工具（跨部门的支持不够）的故事 / 398
29.11 成功的案例却有着意料之外的结局 / 401
29.12 合作能够克服资源的限制 / 404
29.13 取得了大规模成功的自动化过程 / 405
29.14 测试自动化并不总是像看上去那样 / 409
附录A 工具 / 413
案例研究的作者简介 / 422
