自动化软件测试实施指南

.2.2.1 自动测试计划和开发—初始测试的工作量增加 18
2.2.2 生成测试数据—测试工作/计划减少 19
2.2.3 测试的执行—测试工作的减少/测试进度的加快 21
2.2.4 测试结果分析—测试工作的减少/测试进度的加快 22
2.2.5 错误状态/更正监测—测试工作的减少/测试进度的加快 23
2.2.6 报告的创建—测试工作的减少/测试进度的加快 25
2.2.7 其他需要考虑的降低因素 25
2.3 影响软件质量 26
2.4 改进软件测试程序 28
2.4.1 改进构建验证测试（冒烟测试） 29
2.4.2 改进回归测试 29
2.4.3 多平台兼容性测试和配置测试 30
2.4.4 改善日常测试的执行 30
2.4.5 改进重点关注的高级测试问题 30
2.4.6 完成手动测试无法完成的工作 30
2.4.7 重现软件缺陷的能力 31
2.4.8 加强系统专业知识 31
2.4.9 下班后“无人值守”测试 31
2.4.10 改进需求定义 31
2.4.11 改进性能测试 31
2.4.12 改进压力测试和耐力测试 32
2.4.13 质量度量和测试优化 32
2.4.14 改进系统开发生命周期 33
2.4.15 改进文档和可跟踪性 33
2.4.16 分布式工作负载和并发测试 33
小结 33
第3章 商业案例 35
3.1 商业案例的定义 35
3.2 确定业务需要 36
3.3 在成本和收益方面调整自动化 38
3.3.1 评估roi 38
3.3.2 自动化测试的总节省 38
3.3.3 测试环境建立的时间节省 40
3.3.4 测试开发的时间节省 40
3.3.5 测试执行时间的节省 41
3.3.6 测试评估/诊断时间节省 42
3.3.7 roi的其他几点考量 42
3.3.8 更多roi指标 44
3.4 风险 44
3.5 其他考虑 45
小结 46
第4章 自动化测试失败的原因以及需要避免的陷阱 47
4.1 通常r&d不重视自动化测试或手动测试的工作 48
4.2 自动化测试的神话与现实 50
4.2.1 自动测试计划的生成 51
4.2.2 测试工具适合所有场景 51
4.2.3 测试工作立即减少 52
4.2.4 计划立即缩减 52
4.2.5 工具的易用性 52
4.2.6 任何应用都可以使用ast 53
4.2.7 100%测试覆盖率 54
4.2.8 捕获/回放等同ast 55
4.2.9 ast是手动测试活动 56
4.2.10 忘记了测试的目的是找出缺陷 56
4.2.11 侧重于系统测试自动化而非自动化单元测试 56
4.3 软件开发时缺乏针对ast的考虑 57
4.3.1 在应用中构建可测试性 57
4.3.2 遵循开放架构标准 59
4.3.3 遵循标准文档格式 60
4.3.4 标准化的文档测试用例 60
4.3.5 遵循编码标准 61
4.3.6 使用omg的idl 61
4.3.7 gui测试建议 61
4.3.8 gui对象命名标准 62
4.3.9 代码重用的库概念 63
4.4 只见树木不见森林—不知道如何选择工具 63
4.5 缺少工具供应商都遵循的自动化标准 65
4.6 缺乏企业案例 67
小结 67
第二部分 如何实现自动化：获得自动化回报最重要的6个要点
第5章 要点1：了解需求 69
5.1 理解ast所支持的需求 70
5.1.1 aut或sut需求 70
5.1.2 ast框架（astf）和工具的需求 71
5.1.3 ast数据需求 72
5.1.4 测试环境的需求 73
5.1.5 ast过程需求 76
5.2 支持ast需求的更多信息 78
5.2.1 手动测试过程 78
5.2.2 设计文档 78
5.2.3 原型 79
5.3 当信息不存在时 81
5.3.1 引导性的访谈 81
5.3.2 进一步增加知识面 82
5.3.3 基于遗留应用程序或遗留系统开发需求 83
5.4 开始实现需求跟踪矩阵（rtm） 85
5.4.1 rtm中的信息 85
5.4.2 rtm示例 86
小结 89
第6章 要点2：开发自动化测试策略 90
6.1 ast策略文档 91
6.2 范围和自动化测试目标 91
6.2.1 决定要自动化哪些测试 92
6.2.2 优先级—基于优先级的功能计划的自动化需求 95
6.2.3 定义测试目标：示例 96
6.3 确定方法 97
6.4 自动化软件测试框架 102
6.5 ast环境/配置 105
6.5.1 测试配置 106
6.5.2 其他测试环境的自动化测试需求 107
6.5.3 自动化测试环境管理—自动化cm 107
6.6 自动化rtm 112
6.6.1 需要标准的测试用例模板，对自动化框架极其有用 113
6.6.2 链接到测试用例 113
6.6.3 更新测试用例的步骤，包括通过/失败结果 113
6.6.4 更新rtm，包括通过/失败结果 114
6.7 自动化的缺陷跟踪 116
小结 116
第7章 要点3：测试自动化软件测试框架（astf） 117
7.1 验证astf是否满足特定需求，功能是否表现得如预期那样 118
7.2 对所有astf相关工件，包括设计、开发以及相关测试用例进行同级评审 118
7.2.1 作为软件开发生命周期一部分的同级评审 119
7.2.2 评估所有astf组件 121
7.2.3 评审测试用例 121
7.2.4 评审测试逻辑 123
7.2.5 评审测试数据 123
7.2.6 评审自动化的测试代码 125
7.3 验证需求和覆盖率 128
7.3.1 跟踪能力 129
7.3.2 覆盖率 129
7.4 举行一次用户审查 129
小结 130
第8章 要点4：持续跟踪过程，并作相应调整 131
8.1 ast程序跟踪和缺陷预防 131
8.1.1 技术交换和走查 132
8.1.2 内部检查 132
8.1.3 检查约束和相关风险 132
8.1.4 实现风险缓解策略 132
8.1.5 维护ast过程和环境的完整性 133
8.1.6 定义、沟通和跟踪进度和成本 133
8.1.7 跟踪工作、问题和缺陷 134
8.2 ast度量 134
8.2.1 可自动化的百分比或自动化指标 137
8.2.2 自动化进展 138
8.2.3 测试进度 139
8.2.4 自动化测试覆盖率百分比 140
8.2.5 缺陷密度 141
8.2.6 缺陷趋势分析 141
8.2.7 缺陷移除效率 142
8.2.8 自动化软件测试roi 143
8.2.9 其他软件测试度量 144
8.3 根本原因分析 144
小结 145
第9章 要点5： 实施ast过程 146
9.1 ast的阶段和里程碑 147
9.2 ast阶段1：需求收集—分析自动化测试需求 147
9.3 ast阶段2：测试用例设计和开发 149
9.4 ast阶段3：开发自动化测试软件框架（astf）和测试脚本 150
9.5 ast阶段4：自动化测试的执行和结果报告 151
9.6 ast阶段5：程序审查和评估 152
9.7 虚拟质量门槛 153
9.8 过程度量 154
小结 154
第10章 要点6：人尽其才 155
10.1 程序管理 161
10.1.1 ast阶段1：需求收集—分析自动化测试需求 161
10.1.2 ast阶段2：测试用例设计与开发 161
10.1.3 ast阶段3：开发自动化软件测试框架和测试脚本 161
10.1.4 ast阶段4：自动化测试执行和结果报告 161
10.1.5 ast阶段5：审查并评估程序 161
10.2 系统工程 163
10.2.1 ast阶段1：需求收集—分析自动化测试需求 163
10.2.2 ast阶段2：测试用例设计和开发 164
10.2.3 ast阶段3：开发自动化测试框架和测试脚本 164
10.2.4 ast阶段4：自动化测试的执行和结果报告 164
10.2.5 ast阶段5：审查并评估程序 164
10.3 软件开发 165
10.3.1 ast阶段1：需求收集—分析自动化测试需求 165
10.3.2 ast阶段2：测试用例设计和开发 166
10.3.3 ast阶段3：开发自动化软件测试框架和测试脚本 166
10.3.4 ast阶段4：自动化测试的执行和结果报告 166
10.3.5 ast阶段5：程序审查和评估 166
10.4 配置管理 167
10.4.1 ast阶段1：需求收集—分析自动化测试需求 167
10.4.2 ast阶段2：测试用例设计和开发 167
10.4.3 ast阶段3：开发自动化软件测试框架和测试脚本 167
10.4.4 ast阶段4：自动化测试的执行和结果报告 168
10.4.5 ast阶段5：审查并评估程序 168
10.5 质量保证 168
10.5.1 ast阶段1：需求收集—分析自动化测试需求 168
10.5.2 ast阶段2：测试用例设计和开发 168
10.5.3 ast阶段3：开发自动化软件测试框架和测试脚本 169
10.5.4 ast阶段4：自动化测试的执行和结果报告 169
10.5.5 ast阶段5：审查并评估程序 169
10.6 领域专家（sme） 169
10.7 培训 169
小结 170
附录
附录a 过程一览表 173
附录b 将ast应用到的各种测试类型 177
附录c 工作中的利器 190
附录d 案例研究：自动化软件测试
框架（astf）示例 222

.　　第二部分：如何实现自动化：获得自动化回报最重要的6个要点
　　一旦管理层被本书第一部分所列举的商业案例说服，并理解要避免的陷阱和自动化测试的现实，那么下一步就是确定如何自动化。本书第二部分则设法解决如何成功实施各种各样的自动化软件测试任务。我们确定了6个要点来成功实施自动化软件测试，如下所示。
　　第5章，要点1：了解需求。本章涵盖了在开发自动化测试策略之前理解需求的重要性。在此我们讨论当需求无法满足时如何收集信息并解决问题的方法。
　　第6章，要点2：开发自动化测试策略。本章讨论开发自动化测试方式的详细步骤，包括测试环境的考虑、针对自动化测试脚本的配置管理，以及其他相关工件等。在此，我们还将讨论当决定自动化时该考虑什么，以及选择合适的工具的重要性，而不论这些工具是开源的、供应商提供的，还是自主开发的。
　　第7章，要点3：测试自动化软件测试框架（ASTF）。本章介绍了理解测试技术以及记录测试用例的重要性。自动化人员常常忘记了文档仍然是自动化测试程序的重要部分。测试用例文档将作为自动化软件测试工作的蓝图。本章描述了从测试用例跟踪回需求的重要性；测试用例的内容（应该包括输入和期望结果等内容）；以及如何记录测试用例—这已成为开发和实施自动化测试的基础。
　　第8章，要点4：持续跟踪过程，并作相应调整。本章会阐释跟踪自动化程序开始时设定目标的重要性。例如，在第3章对商业案例开发的讨论中解释了定义目标的需要，本章会讨论如何进行同行评审（peer review）、检查，以及各种可以帮助评估和跟踪针对该目标的进展。
　　第9章，要点5：实施AST过程。本章指出对轻量级过程的需求。有些自动化测试脚本可以在没有什么过程的时候实现成功，但为了有效地实施大规模的自动化测试程序，就必须要实施一个轻量级的可调整的过程。本章概括性地讨论了该过程，并会在其他各章关联相关细节。
　　第10章，要点6：人尽其才，了解所需的技能。本章会明确开发自动化软件测试所需的技能。比如，把一种技术水平相近的软件开发团队组合在一起，包括需求分析、设计、开发以及测试。要点6指出，尽管测试技术和分析技能很重要，但有效地实施自动化软件测试还需要软件开发技能。这里描述的技能与第9章描述的自动化测试过程是并行的。
　　读者对象
　　本书的目标读者是软件测试的专业人员，比如测试经理、测试部门领导以及相关从业人员。它同样适合于质量评估专业人员、QA（质量评估）部门领导，以及相关从业人员。想要改进软件交付的效率和质量的项目管理人员和软件开发人员也将从本书受益。
　　作者简介
　　Elfriede Dustin、Thom Garrett和Bernie Gauf是IDT（www.idtus.com）的同事，IDT是专门设计、开发和实现自动化软件测试解决方案的公司。
　　Elfriede Dustin根据她多年亲身实践自动化软件测试的经验编写过多本软件测试著作和许多文章。Elfriede领导IDT的自动化软件测试研究规划的工作。
　　Thom Garrett在为DoD的复杂系统和商业公司，比如PBS（Public Broadcasting Service，公共广播业务）、DSR（Digital System Resources，数字系统资源）公司和AOL（America Online，美国在线公司）构建商业应用程序制定计划、测试和开发方面特别有经验。Thom获得了旧金山大学的硕士学位。
　　Bernie Gauf是IDT的总裁。Bernie曾多次受邀参加DoD关于新技术应用、测试会议的顾问组，并作为演讲嘉宾分享他在自动化软件测试方面的深刻见解。
　　其他有贡献的作者
　　Scott Bindas是Innovative Defense Technologies(IDT)的软件开发经理。特别是，他的软件团队曾经发布过一个自动化软件测试框架，用于融合各种开源的、第三方的以及IDT开发的软件解决方案。在加入IDT之前，Scott在一个主要做防御系统的公司担任首席软件工程师。他的主要职责是为海军的潜水艇应用程序做软件设计、开发以及测试。Scott拥有麻省理工大学达特茅斯学院的理学士学位。
　　Marcus Borch是IDT开发自动化软件测试套件的软件开发技术领导，他的职责是为自动化各种类型的软件测试设计和实现测试模块，范围从功能测试到系统级别的测试。他曾在主要的防御供应商里做了超过8年的软件工程师。他毕业于纽约州立大学，以优异成绩获得了计算机科学学位。
　　Vincent Vallarine是IDT实现自动化测试解决方案的高级软件工程师。在1999年从罗得岛大学获得计算机工程学位后，Vincent在主要防御供应商单位里开始了他的职业生涯。在防御供应商单位里，他是一名软件工程师，主要职责是为海军作战系统设计、实现并测试软件。他还获得了麻省理工大学达特茅斯学院计算机科学学位。