Elfriede Dustin、Thom Garrett和Bernie Gauf是IDT（www.idtus.com）的同事。IDT是专门设计、开发和实现自动化软件测试解决方案的公司。Elfriede Dustin领导IDT的自动化软件测试研究工作，她根据多年自动化软件测试的经验编写过多本软件测试著作。Thom Garrett在规划、开发、测试和开发用于军事和商业企业的复杂软件系统方面有二十多年的经验。Bernie Gauf是IDT的总裁。他曾积极参与DoD关于新技术应用的顾问组，并在许多软件测试峰会上演讲。

　　本书讲解什么是自动化测试，为什么要进行自动化测试，以及实施自动化测试过程中的各种方法和需要注意的问题。
　　全书分为两部分。在第一部分，作者以自身的经验向我们阐释自动化测试的重要性以及好处。第二部分用6个要点来讲解需求收集、制定自动化测试的策略、开发自动化测试框架(主要是开发原则)、制定测试计划以及人员安排。附录A是一个测试阶段一览表，附录B快速地讲解了各种类型的测试以及在这些测试中如何应用自动化。附录C用了大量的篇幅介绍各种主流测试工具，以及评估这些工具的方法，附录D是一个真实的自动化框架的案例研究。
　　本书适合软件测试人员、质量评估人员、项目管理人员和软件开发人员阅读。
　　测试占新软件开发的时间和成本的百分比越来越大。使用自动化软件测试（AST），开发人员和软件测试人员可以优化软件测试生命周期，从而减少成本。随着技术和开发发展得越来越复杂，AST将变得不可或缺。本书是根据一些已经证明的实践和自动化测试生命周期方法学（ATLM）而写，提供了更新的实践，为成功实施AST提供了全面指导。
　　在本书中，三位权威专家详细地阐释了AST，系统地回顾了AST的组成元素、能力以及限制。他们利用在防御系统和商业中部署AST的经验，带领你浏览整个实施过程——确定最佳实践、关键的成功因素、关键隐患，以及避免这些隐患的解决方案。
　　本书内容
　　·为AST构建实际可行的商业案例，使用AST获取主动权
　　·澄清测试需求，并开发一个自动化策略反映这些需求
　　·构建高效的测试环境，为该环境选择合适的自动化工具和技术
　　·使用经过证明的指标持续地跟踪过程，并做出相应的调整
　　不管你是测试专业人员、QA专家、项目经理还是开发人员，本书都会带给你前所未有的有效测试，然后使用AST改进整个开发生命周期。

　　本书弥补了我埘软件测试知识的欠缺。它很好地描述了自动化测试与其他测试活动的不同，清晰地讨论了自动化测试所需要的技能力知识。本书是学习自动化软件测试的基础读物，也是实践嚣的权威教材。
　　——Jleft Offutt，乔治梅淼人学软件工程教授
　　本书是软件从业人员在其开发工作中应用自动化软件测试的最佳参考。它是软件测试专业人员的必备读物。
　　——left Rashka，PMP，《Automated Software Testing and Quality Web Systems》的作者之一

　　自动化的问题应该基于ROI的计算，确定有些测试不能自动化有某些理由，比如，通过对ROI的评估，也许会证明（自动化该测试）不合算e。
　　尽管AST通常是基于对手动软件测试工作的改进，但（自动化）测试已开发的软件，需要软件开发。我们开发软件来测试软件，因为当前没有更好的方法。
　　人们已经在这个方向上作出了努力，如IBM的自主计算（autonomic computing）@项目，这有可能在不久的将来提供自我测试（self-testable）组件，虽然已经取得了一些进展，然而截止撰写本书的时候只有少数几家公司已经实施并应用了自主计算这个概念。
　　鉴于目前AST的状态和需要开发软件来测试软件的要求，有效的自动化测试应包括减少人工的参与，尽可能地自动化工作。开发软件测试软件的工作需要有效地改进。使用自动化来实现软件测试自动化是一种有效的方式，可以消除对人工交互的需求和由于手动而造成的错误。改进自动化测试的部分目标就是自动化进行测试自动化。
　　例如，很多公司经常花费时间从零开始开发测试框架，虽然已经有很多框架提供了这些功能，但还是为批处理测试、分布式测试或E-mail提醒创建功能。为了复用和简化功能集成，节约时间和资金，就应该充分利用提供所需功能的开源组件或自由／共享软件。在开发测试框架的新功能之前，查看开源社区，那里往往有许多我们所需要的已经开发好并可以直接下载的东西。我建议，任何自动化测试工作都应该考虑使用开源组件来设计和开发测试自动化框架。当考虑使用开源工具时，请记住开源许可的有效性。一些被认可的开源许可可以在网页上进行核实。
　　自动化测试人员都知道，自动化测试需要有自己的开发生命周期，所以我们借用软件开发社区已经研究出的方法：使用工具帮助自动化生命周期的所有阶段，从需求到设计、实现、测试和缺陷跟踪。作为测试框架的一部分，对于测试过程的开发，可以遵循模型驱动设计（Model-Driven Design，MDD）。

译者序
序
序二
前言
第一部分 什么是自动化软件测试和为什么需要自动化
第1章 自动化软件测试概述
1.1 自动化测试定义
1.2 自动化测试的方法
1.3 AST技术的发展
1.4 各种自动化测试类型
1.5 提供基于AST的产品支持
1.5.1 按照需要对定位和修复产品问题提供支持
1.5.2 对确定出修正给特定程序组件造成的影响提供支持
1.5.3 校验产品修正的准确性和质量
1.5.4 支持产品的STR分类方法
1.6 自动化评估标准
小结

第2章 为什么要使用自动化
2.1 当今测试软件面临的挑战
2.2 减少软件测试的时间和成本
2.2.1 自动测试计划和开发——初始测试的工作量增加
2.2.2 生成测试数据——测试工作／计划减少
2.2.3 测试的执行——测试工作的减少／测试进度的加快
2.2.4 测试结果分析——测试工作的减少／测试进度的加快
2.2.5 错误状态／更正监测——测试工作的减少，测试进度的加快
2.2.6 报告的创建——测试工作的减／测试进度的加快
2.2.7 其他需要考虑的降低因素
2.3 影响软件质量
2.4 改进软件测试程序
2.4.1 改进构建验证测试（冒烟测试）
2.4.2 改进回归测试
2.4.3 多平台兼容性测试和配置测试
2.4.4 改善日常测试的执行
2.4.5 改进重点关注的高级测试问题
2.4.6 完成手动测试无法完成的工作
2.4.7 重现软件缺陷的能力
2.4.8 加强系统专业知识
2.4.9 下班后“无人值守”测试
2.4.10 改进需求定义
2.4.11 改进性能测试
2.4.12 改进压力测试和耐力测试
2.4.13 质量度量和测试优化
2.4.14 改进系统开发生命周期
2.4.15 改进文档和可跟踪性
2.4.16 分布式工作负载和并发测试
小结

第3章 商业案例
3.1 商业案例的定义
3.2 确定业务需要
3.3 在成本和收益方面调整自动化
3.3.1 评估ROI
3.3.2 自动化测试的总节省
3.3.3 测试环境建立的时间节省
3.3.4 测试开发的时间节省
3.3.5 测试执行时间的节省
3.3.6 测试评估／诊断时间节省
3.3.7 ROI的其他几点考量
3.3.8 更多ROI指标
3.4 风险
3.5 其他考虑
小结

第4章 自动化测试失败的原因以及需要避免的陷阱
4.1 通常R&D不重视自动化测试或手动测试的工作
4.2 自动化测试的神话与现实
4.2.1 自动测试计划的生成
4.2.2 测试工具适合所有场景
4.2.3 测试工作立即减少
4.2.4 计划立即缩减
4.2.5 工具的易用性
4.2.6 任何应用都可以使用AST
4.2.7 100％测试覆盖率
4.2.8 捕获／回放等同AST
4.2.9 AST是手动测试活动
4.2.10 忘记了测试的目的是找出缺陷
4.2.11 侧重于系统测试自动化而非自动化单元测试
4.3 软件开发时缺乏针对AST的考虑
4.3.1 在应用中构建可测试性
4.3.2 遵循开放架构标准
4.3.3 遵循标准文档格式
4.3.4 标准化的文档测试用例
4.3.5 遵循编码标准
4.3.6 使用OMG的IDI
4.3.7 GUI测试建议
4.3.8 GuI对象命名标准
4.3.9 代码重用的库概念
4.4 只见树木不见森林——不知道如何选择工具
4.5 缺少工具供应商都遵循的自动化标准
4.6 缺乏企业案例
小结

第二部分 如何实现自动化：获得自动化回报最重要的6个要点
第5章 要点1：了解需求
5.1 理解AST所支持的需求
5.1.1 AUT或SUT需求
5.1.2 AST框架（ASTF）和工具的需求
5.1.3 AST数据需求
5.1.4 测试环境的需求
5.1.5 AST过程需求
5.2 支持.AST需求的更多信息
5.2.1 手动测试过程
5.2.2 设计文档
5.2.3 原型
5.3 当信息不存在时
5.3.1 引导性的访谈
5.3.2 进一步增加知识面
5.3.3 基于遗留应用程序或遗留系统开发需求
5.4 开始实现需求跟踪矩阵（RTM）
5.4.1 RTM中的信息
5.4.2 RTM示例
小结

第6章 要点2：开发自动化测试策略
6.1 AST策略文档
6.2 范围和自动化测试目标
6.2.1 决定要自动化哪些测试
6.2.2 优先级——基于优先级的功能计划的自动化需求
6.2.3 定义测试目标：示例
6.3 确定方法
6.4 自动化软件测试框架
6.5 AST环境／配置
6.5.1 测试配置
6.5.2 其他测试环境的自动化测试需求
6.5.3 自动化测试环境管理——自动化CM
6.6 自动化RTM
6.6.1 需要标准的测试用例模板，对自动化框架极其有用
6.6.2 链接到测试用例
6.6.3 更新测试用例的步骤，包括通过失败结果
6.6.4 更新RTM，包括通过，失败结果
6.7 自动化的缺陷跟踪
小结

第7章 要点3：测试自动化软件测试框架（ASTF）
7.1 验证ASTF是否满足特定需求，功能是否表现得如预期那样
7.2 对所有ASTF相关工件，包括设计、开以及相关测试用例进行同级评审
7.2.1 作为软件开发生命周期一部分的同级评审
7.2.2 评估所有ASTF组件
7.2.3 评审测试用例
7.2.4 评审测试逻辑
7.2.5 评审测试数据
7.2.6 评审自动化的测试代码
7.3 验证需求和覆盖率
7.3.1 跟踪能力
7.3.2 覆盖率
7.4 举行一次用户审查
小结

第8章 要点4：持续跟踪过程并作相应调整
8.1 AST程序跟踪和缺陷预防
8.1.1 技术交换和走查
8.1.2 内部检查
8.1.3 检查约束和相关风险
8.1.4 实现风险缓解策略
8.1.5 维护AST过程和环境的完整性
8.1.6 定义、沟通和跟踪进度和成本
8.1.7 跟踪工作、问题和缺陷
8.2 AST度量
8.2 可自动化的百分比或自动化指标
8.2.2 自动化进展
8.2.3 测试进度
8.2.4 自动化测试覆盖率百分比
8.2.5 缺陷密度
8.2.6 缺陷趋势分析
8.2.7 缺陷移除效率
8.2.8 自动化软件测试ROI
8.2.9 其他软件测试度量
8.3 根本原因分析
小结

第9章 要点5：实施AST过程
9.1 AST的阶段和里程碑
9.2 AST阶段1：需求收集——分析自动化测试需求
9.3 AST阶段2：测试用例设计和开发
9.4 AST阶段3：开发自动化测试软件框架（ASTF）和测试脚本
9.5 AST阶段4：自动化测试的执行和结果报告·
9.6 AST阶段5：程序审查和评估
9.7 虚拟质量门槛
9.8 过程度量
小结

第10章 要点6：人尽其才
10.1 程序管理
10.1.1 AST阶段1：需求收集——分析自动化测试需求
10.1.2 AST阶段2：测试用例设计与开发
10.1.3 AST阶段3：开发自动化软件测试框架和测试脚本
10.1.4 AST阶段4：自动化测试执行和结果报告
10.1.5 AST阶段5：审查并评估程序
10.2 系统工程
10.2.1 AST阶段1：需求收集——分析自动化测试需求
10.2.2 AST阶段2：测试用例设计和开发
10.2.3 AST阶段3：开发自动化测试框架和测试脚本
10.2.4 AST阶段4：自动化测试的执行和结果报告
10.2.5 AST阶段5：审查并评估程序
10.3 软件开发
10.3.1 AST阶段1：需求收集——分析自动化测试需求
10.3.2 AST阶段2：测试用例设计和开发
10.3.3 AST阶段3：开发自动化软件测试框架和测试脚本
10.3.4 AST阶段4：自动化测试的执行和结果报告
10.3.5 AST阶段5：程序审查和评估
10.4 配置管理
10.4.1 AST阶段1：需求收集——分析自动化测试需求
10.4.2 AST阶段2：测试用例设计和开发
10.4.3 AST阶段3：开发自动化软件测试框架和测试脚本
10.4.4 AST阶段4：自动化测试的执行和结果报告
10.4.5 AST阶段5：审查并评估程序
10.5 质量保证
10.5.1 AST阶段1：需求收集——分析自动化测试需求
10.5.2 AST阶段2：测试用例设计和开发
10.5.3 AST阶段3：开发自动化软件测试框架和测试脚本
10.5.4 AST阶段4：自动化测试的执行和结果报告
10.5.5 AST阶段5：审查并评估程序
10.6 领域专家（$ME）
10.7 培训
小结

附录
附录A 过程一览表
附录B 将AST应用到的各种测试类型
附录C 工作中的利器
附录D 案例研究：自动化软件测试框架（ASTF）示例