作者:（英） 格雷（ Graham，D.），（英） 福斯特（ Fewster，M.) 著出版社: 机械工业出版社出版时间:2013年04月
第0章 案例研究反思
2017-01-13
对这些问题没有简单而通用的答案，但存在一些公共的要素。我们认为最重要的两个要素是管理问题和测试件架构：
注: 这两个问题需要重点关注，但是又有些宽泛，需后续章节细分析。 但是除此之外还有其它冷门的问题也需关注
0.1.1 自动化测试目标
2017-02-15
自动化测试目标
注: 并非测试的目标，后续学习如何制定出有效的自动化测试目标
0.1.3 ROI和度量标准
2017-02-15
第9章有一个用来评判投资的基于模型测试的ROI计算器的范例。
注: 分析自动化测试案例的ROI，分析案例是否适合做自动化
0.1.5 技能
2017-02-15
自动化测试人员的角色可以看做测试人员和工具之间的桥梁（参见0.2.1节）。
注: 测试架构师：设计自动化测试的整体结构，或将现有框架进行改进以适应新的需求
测试工程师：设计、编写、维护自动化测试的软件、脚本、数据、期望结果以及额外的实用工具
0.1.8 促进项目改变并启动自动化测试的触发器
2017-02-15
试点项目（pilot project）是个好主意，在将自动化测试扩展到更广的范围之前先在小范围内尝试不同的方法，来判断哪种方法最好。
注: 常用技巧，小范围试点验证
0.1.9 工具和培训
2017-02-15
拥有好的工具不能保证在测试自动化中取得成功——必须对整个测试框架进行良好地计划、定制和维护，工具仅仅是一小部分。
注: 工具没有标准的，寻找适合自己项目的，其实就是能够实现自动化需求的就行。
重点还是管理和计划
0.2.1 抽象、抽象、再抽象：测试件架构
2017-02-15
技术因素
注: 使用的工具，语言要接地气，要标准化，要能生成报告，编写的案例要避免过度依赖工具，失败分析要明确
1.2 整个团队的承诺
2017-02-15
敏捷开发团队中的每个人都进行手动测试，所以他们更能体会到自动化测试的好处。
1.3.1 一个可测试的架构
2017-02-15
解决问题的最直接途径未必是最佳途径。
1.3.3 获取测试的基准：GUI冒烟测试
2017-02-15
我们首先追求的是“快赢”，针对系统中每个用户角色的基本功能实现自动测试。
2017-02-15
首先，CI构建过程只运行了少量单元测试和一些覆盖系统高得分点的GUI冒烟测试。随着在这两个级别引入更多测试，我们将GUI测试移到单独的构建过程中并只在晚上运行，这样，我们可以更快得到的反馈信息。
1.11 总结
2017-02-16
总结
注: 核心团队成员稳定，不断尝试新工具，测试和开发互相学习；在使用新工具上一定先做培训，试点时小范围实施，有好的反馈后，大面积推广使用； 该敏捷项目案例支持单元测试覆盖率，GUI功能覆盖率，历时1年过度完成全部回归测试案例的自动化测试案例编写。
2.1 本案例研究的背景
2017-02-16
不要尝试对设计很差的测试实施自动化，先完善测试，再进行自动化。
2.3 自动化测试的目标
2017-02-16
刚开始不要设定太多目标，最初先重点完成某些目标，再逐步添加新的目标。
2.6 管理自动化测试
2017-02-16
我们的测试过程在持续改进，并且我们为测试设计了一个可记录的生命周期，如图2-2所示。
2.10 如何使用自动化测试书中的建议
2017-02-16
所有的测试人员参加国际软件测试认证委员会（International Software Testiing QualificationsBoard, ISTQB）的基础认证课程，这样有助于术语的统一使用和理解，从而有助于增进测试人员间的交流。
第3章 移动到云端：TiP的演化——在线的持续回归测试
2017-02-17
移动到云端：TiP的演化——在线的持续回归测试
注: 通过在云端实施自动化测试，从而将基于产品的自动化测试变更为基于服务的自动化测
在线测试：Testing in Production, TiP
3.3 如何实施TiP
2017-02-17
不要仅仅通过一种途径来实施自动化，尽可能使用多种有用的方法。不同方法之间可以互补并且往往比单独使用一个方法更有效。
3.6.5 易犯的错误
2017-02-17
易犯的错误
注: 1 自动化提示的错误可能是个临时性的错误，如网络断开，解决方案提供重试的机制
2 假的“安全感”比如看起来都没问题其实是分支覆盖不全，要阶段性的做探索性的测试。从整体看结果。 多出现在横向扩展产品的时候
5.4.1 试着用原先的方法来使用新工具
2017-02-17
测试工具与UI构建环境的交互能力是最重要的。
6.3.4 第一个月：了解任务和工具
2017-02-19
分享对工具和策略的理解。
■了解工具，这样就可以根据任务来使用工具。较为完整的文档有助于从文档中找到每项任务的标准实践和最佳实践是什么。
2017-02-19
我们按照自己使用工具的方式，为QC和QTP编写了一个快速指南。同时还一直维护着关于最佳实践及项目中所使用标准的日志，每当有一个新的好方法的时候就补充进去。
6.3.6 敏捷测试方法
2017-02-19
通过频繁地报告自动化进展来获得利益相关者持续的兴趣和支持。
6.3.7 第一阶段的结果
2017-02-19
管理层的支持；
■清晰的目标；
■同样的知识水平；
■对工具的了解；
■在GUI上的实际应用知识；
■对任务的处理策略；
注: 初期达到的目标清单，值得借鉴
2017-02-19
■可用方法，包括描述最佳实践；
■一个符合实际的计划；
■一个符合实际的时间安排表。
6.4.3 统一解决方案
2017-02-19
描述最佳实践以及整个项目阶段应遵循标准的文档。如果我们选择不采用最佳实践，我们必须要有充分的理由，并将其写进最佳实践文档里面，这样我们就能知道哪些地方有差异
注: 定义标准，但是在必要的时候也要允许例外情况。
6.4.4 应用程序结构和QC中的测试用例结构
2017-02-19
组件和测试用例的命名标准是采用面向业务的方法，这样就比较方便找到相应的用例并进行整体的维护。
■测试用例由公共组件和特定组件构成，这就保证了对于同一功能不会出现冗余的组件。
注: 自动化测试组件的划分标准及理念：测试件架构采用标准的方法具有易用性，并有助于长期的维护。
6.4.7 实际产品发布版本中使用的第一个自动化测试
2017-02-19
开发人员必须在变更管理系统中对GUI中的功能和变更进行详细的记录和描述，这样自动化测试团队就知道应该对哪些部分进行维护。
6.5 总结
2017-02-19
总结
注: 1 要掌握对工具的学习使用，制作快速指南及培训
2 最佳实践跟踪记录并做分享
3 业务组件划分为公共组件和特定组件
4 小步快跑，小范围试点，要梳理好自动化功能清单
5 制定GUI开发规范，让开发人员主动反馈修改内容
6 自动生成测试报告(让领导看到成果)
2017-02-19
5个成功的准则
注: ■公司人员必须知晓任务和责任，并达成一致意见。
■进行一个试点项目并定义明确的目标。
■确保整个项目成员对项目有共同的了解和认识，记录最佳实践和标准。
■了解整个业务应用，以确保测试用例的结构和规模是合适的。
■“使它尽量保持简单”
第10章 10年过去了，项目还在进行
2017-02-20
测试文档化
注: 可以长时间使用
10.2.8 我们遇到的其他问题
2017-02-20
维护是很重要的，需要尽早进行良好的设计使得维护工作量最小化。
注: 项目实践需要考虑
10.4.1 将测试人员和自动化人员分离开来
2017-02-20
自动化不能带来好的测试。仅仅对那些有价值的测试进行自动
10.4.2 管理层的期望
2017-02-20
需要很好地理解质量管理、测试策略过程、系统规格说明、测试计划、待测系统和测试自动化工具集的相对成熟度。
注: 成熟度
10.4.3 从特定的工具和工具提供商中独立出来
2017-02-20
对自动化进行良好的设计，以便能够在需要时转向使用不同的工具——保持工具独立性。
11.5.1 关注知识分享
2017-02-21
关注知识分享，对自动化框架中测试运行的结果进行跟踪，设计时考虑速度和易用性。
注: 实现凤凰重生的几点内容
11.5.3 设计时考虑速度和易用性
2017-02-21
可以运行可变数量的测试
注: 项目中可以研究testng通过网页选择执行的测试案例
12.2.2 健康检查和“吸烟者”
2017-02-22
冒烟测试是开始使用自动化的一个好地方，因为它们经常被运行，比较乏味，并且手动测试容易出错。
注: 项目中实现健康检查，最好每天都有这个健康检查的报告呈现，也可单独执行
12.2.3 面临的挑战和汲取的经验教训
2017-02-22
高价值的测试环境健康检查和“吸烟者”的套件已经开发出来，并且仍在使用。
2017-02-22
设定的目标为：减少人工劳动力成本，提高产品质量，增加测试的灵活性，使手动测试资源能够自由变化（具有较高的bug发现率），由于需要较少的临时测试人员而降低了网络资源的紧张程度。
12.3.5 销售自动化
2017-02-22
将自动化的好处传递到高级管理层是必不可少的。比较自动化和手动测试是有效的
注: 整理自动化测试对比手动测试的分析，主要是自动化的开发验证时间，手动测试的人工验证时间，不能单从一个版本看，最好有累计的信息
12.5.1 概念：脚本开发与业务知识相结合
2017-02-22
自动化服务（包括脚本开发、维护、执行、报告，以及工具的内部结构）。
注: 定义清楚岗位职责很重要
15.2.4 代码审查
2017-02-23
对于自动化测试代码、脚本和文档进行审查和复审是非常有效的。
注: 让相近领域的同事提前审查代码，评审会上再谈论
15.2.6 “Checkman for eCATT”工具
2017-02-23
在你的自动化测试套件中谨防“无用”测试用例。
注: 【重要】通过静态检查或案例代码执行覆盖率检查“无用”的案例脚本
16.4.2 编码规约和文档化
2017-02-23
TwinText工具为我们的框架产生一个完整的HTML帮助文件，它可以作为一个参考文档被任何使用该框架的人使用。
注: 框架说明文档
17.3.1 已有的测试工具以及改变的原因
2017-02-23
unit，自动化单元测试
注: 谷歌内部工具TAU（test automation
17.4.6 提交队列该为我们做什么
2017-02-23
提供给开发人员立即反馈的测试用例对于他们来说是最有用的
注: 自动化后期需考虑
17.6.2 一般的自动化测试：我们汲取的经验教训
2017-02-23
建立稳定、可维护的测试用例还是非常困难的
注: 所有的基于浏览器的自动化测试工具都有的问题
18.2 自动化测试框架
2017-02-24
自动化测试框架
注: 看架构图
18.4 抽象层
2017-02-24
挑选最优的抽象层厚度和它的技术。
注: 面向对象的理念进行抽象，定义抽象的厚度。【重要】考虑电商商品录入的抽象
18.5 配置
2017-02-24
自动地检测一个测试的前置条件，如果它们不满足，就不执行该测试。
注: 除了健康体检，单个案例还需要有前置条件检查
18.6 成本和投资回报率
2017-02-24
自动化测试的节约成本
注: 产出物
2017-02-24
每个测试套件映射了一个功能域（一系列的需
19.3 自动化测试用来支持手动探索式测试
2017-02-25
一次性的脚本可以有实际的短期收益。
注: 自动化测试实现多用户并发操作一个业务的实现，考虑公共构建
19.6 通过组合简单的工具模拟现实世界的负载
2017-02-25
使用一种工具的组合能够做到一些单个工具很难或者不可能办到的事情。
20.8 结果报告
2017-02-25
测试结果的分层报告能够节省很多失效分析时间。我们只报告一些测试目标所需要的信息。
21.4.2 缺点
2017-02-25
自动化测试不仅仅是执行测试——记录缺陷日志、调试和状态报告同样需要支持。
21.5.2 框架中目前还不可用的特性
2017-02-25
特性
注: 见文中下图。收集整理好
24.3 测试猴子
2017-02-25
为了真正利用自动化的力量，要跳出自动化回归测试的框框。
注: 猴子测试，随机测试
27.2.3 对QA授权
2017-02-27
清晰的和可测量的目标是自动化的最好起点。
29.6 探索性测试自动化：数据库记录锁定
2017-03-01
好的自动化的候选方案是那些难以手动实现的测试以及那些对手动测试来说过于复杂的测试
29.8.4 学到的经验教训
2017-03-01
对外部的依赖进行封装
注: 作为设计的原则
29.13.2 最终成功的关键：自动化过程
2017-03-01
自动化过程
注: 示意图
分析和设计：理解客户的需求，并确认是否可能在我们当前的技术条件下满足每项需求。
■编写脚本和配置：通过自动化的解决方案来实现客户需求。这可能包含重新编码、编码和创建一些特定的实用工具。
参数定义：在系统中使用用户定义的场景对脚本进行评估，目的在于找出那些需要参数化的元素。
■参数管理：在定制的电子表格中管理大量的数据。
■场景收集：根据系统利益相关人员提供的测试场景来生成电子表格。
■确认：检查电子表格和参数，在电子表格中创建标准去决定测试通过或是失败，并且允许自动化脚本确认已执行测试的结果。
对脚本进行测试：保证测试以期望的方式运行，移除脚本中的任何bug。
■脚本执行：使用已定义的场景和参数运行脚本。
■对结果的评审：在内部对脚本执行的结果进行评审，包括哪些测试通过或者失败，以及任何常见的问题，如环境不可用等。
■对结果进行交流：对结果进行总结，并发送给经理、开发人员、利益相关人员和其他相关人员。