第一章 敏捷测试的定义
敏捷方法：Scrum（迭代式增量软件开发过程）、极限编程（XP）、Crystal、动态系统开发方法（DSDM）或特性驱动开发（FDD）等。
敏捷是迭代的和增量的。
极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。
敏捷软件开发宣言：
- 个体和交互胜过流程和工具
- 可用的软件胜过完备的文档
- 客户协作胜过合同谈判
- 响应变化胜过遵循计划
敏捷测试人员的十条法则
提供持续反馈、为客户创造价值、进行面对面的沟通、勇气、简单化、持续改进、响应变化、自我组织、关注人、享受乐趣
支持团队的面向技术测试
单元测试验证代码段的行为。组件测试通过测试类和方法间的交互帮助巩固系统的一个可部署部分的整体设计。
可靠的源码控制、配置管理和持续集成是从指导开发的程序员测试中获取价值的要素。
持续集成是敏捷团队的核心实践。
单元测试的工具
Java的Junit、 .NET的NUnit、Perl和Ruby的Test::Unit、Python的PyUnit
为了帮助支持团队的面向技术测试，敏捷团队需要例如源代码控制、测试自动化、IDE和构建管理工具等。
支持团队的面向业务测试
面向业务的测试同时基于示例和使用编程语言描述需求。
第一象限的活动确保内部质量，最优化项目生产力，减少技术性负债。第二象限测试定义和验证外部质量，同时帮助我们了解何时完成。`
核对以下内容以解决需求问题：
- 业务满足条件
- 对现有功能的影响，如网站、文档、票据、表格和报表
- 法律方面的考虑
- 日常运转流程的影响
- 对UI故事的实物模型的引用
- 帮助文本，或者由谁来提供它
- 测试用例
- 数据迁移（如果适用的话）
- 所需的内部交流
- 与业务伙伴和厂商的外部交流
面向业务测试工具包
面向业务测试的目标是促进客户和开发人员之间的沟通和协作，确保团队在每一次迭代中都产生真正的价值。
作为一名（角色），我需要（功能），因此（业务价值）。
Windows NetMeeting和VNC这样的工具使不同地区的两位同事能够结对测试。 视频会议工具如WebEx和Skype支持远程团队和客户之间的协作和演示。在线白板（如Scriblink）和交互式白板（Mimeo）方便了分散式的白板讨论。
行为驱动开发（BDD）是测试驱动开发的变种。它与领域驱动设计有关，关注领域而不是技术。一些BDD工具包括：用于Java平台的easyb和JBehave、用于.NET的NBehave和Nspec、用于Ruby的RSpec。
Fit（集成测试框架）。可通过http://fit.c2.com了解Fit。
FitNesse是一个基于Fit的Web服务器、Wiki、软件测试开源工具。FitNesse和Fit之间的主要区别在于FitNesse的测试通过Wiki标记符而不是HTML表格编写。它也支持在电子表格中创建测试并导入到测试中。
可通过http://www.fitnesse.org了解FitNesse。
测试Web服务
- CrossCheck——是测试Web服务的一种工具。通过提供WSDL（Web服务描述语言），CrossCheck编译页面并显示一个标签页式的菜单，其中包含的文本框由用户填写。它提供运行模式，可以添加测试到测试集中然后运行。
- Ruby Test::Unit
- soapUI——可用于性能和负载测试。它可以在Excel电子表格或者文本文件中循环遍历各行，可以用于数据驱动测试。
敏捷开源测试工具（GUI测试）
Watir——Watir（Ruby测试Web应用）是一款开源Ruby库，用于自动化Windows上的IE浏览器。还提供对其它浏览器的支持，包括FireWatir（用于Firefox）和SafariWatir（用于Safari）。
Selenium——测试工具集，开源，用于测试Web应用。测试可以写成HTML表格形式或者通过常用编程语言编写，并且可以运行于大多数浏览器。名为Selenium IDE的Firefox插件提供了快速学习该工具的途径。
Canoo WebTest——在WebTest脚本中，测试在XML文件中以“步骤”描述，模仿了用户对web界面的操作。WebTest不像Selenium和Watir那样驱动真实的浏览器，它使用HTML模拟需要的浏览器。WebTest支持测试PDF文件和Excel文件。
如何有效使用工具编写面向业务测试的策略？
1. 增量构建测试
首先确保最明显的用例是正常工作的。编写一个简单、常用路径的自动化测试来证明代码完成了最基本的功能。在测试通过后，再开始考虑其它情况。编写面向业务测试是一种迭代过程。
讨论测试会让开发人员意识到他忽略或者误解了某个需求。
2. 确保测试通过
每当测试在持续集成和构建过程中失败时，全队的最高优先级（除了关键的生产问题）应该是让构建通过测试。
3. 使用合适的测试设计模式
4. 构建/操作/检查 （搭建/执行/验证）
依据测试的目的在内存或者数据库中构建输入数据；调用产品代码来操作这些输入；检查运算结果。
使用真实数据库的测试可以帮助测试那些数据访问层和业务逻辑层无法轻易分离的遗留代码。
5. 基于时间的、活动和事件模式
6. 了解更多
业务逻辑和算法应该能够被测试模块访问，而不需要通过用户界面或者批处理过程。这保证了测试驱动开发，也会生成可测试的架构。
7. 关键词和数据驱动测试
可测试性
o 代码设计和测试设计
o 自动化与手动第二象限测试
o 测试管理
团队需要正确的工具来启发需求和示例，从全局到细节，包括核对表、思维导图、电子表格、模型、流程图和各种软件工具。
第10章 评价产品的面向业务测试
敏捷开发增量迭代的特性带来了一个在开发软件的同时演示其业务价值的机会。
探索测试（ET）——同时进行的测试设计、测试执行和学习。探索测试本身不是一种测试技术，而是一种可以应用于任何测试技术的方式或态度。探索强调个人和交互而不是过程和工具。
作为一个研究性工具，是用户故事测试和自动化回归集的重要补充。探索测试并不是通过详尽的测试来评估软件，它的一个副作用是增加了测试人员对被测系统的了解。它揭示了产品中可以更多地使用自动化测试的区域，并能引出不少对于新特性的想法，而这些新特性往往会演变成新的故事。
可用性测试
o 用户需求和角色测试
o 导航
o 研究竞争对手
API（应用程序编程接口）是可以被其它软件应用或构件执行的一组功能。
o 改变输入参数
o 改变调用顺序
探索测试辅助工具
o 设置测试数据
PerlClip可以用不同类型的输入数据测试文本输入框。从http://www.satisfice.com免费获取。
o 帮助评估测试会话的输出
LogWatch用于监控日志文件中的错误信息。
o 模拟器——用于为系统生成具有关键特征和行为的，类似于真实数据的工具。
o 仿真器——仿真器能复制一个系统的功能，从而与被测的系统行为一致。当要测试系统中与其它系统或设备的接口代码时，仿真器十分有用。
第11章 利用面向技术的测试评价产品
非功能性需求包括配置、安全、性能、内存管理、各种ility（比如可靠性、交互性以及可伸缩性）、恢复，甚至还有数据转换。
可靠性（PSR）测试
如何完成安全性测试任务？
1. 采用持续集成（CI）周期性地运行自动化测试套集。
2. 学习使用开源的静态代码分析工具，将其加到CI中。
3. 安装自动化安全漏洞检测工具，如Nessus（http://www.nessus.org/nessus/）。可以在非GUI模式的命令行中运行Nessus，这样就可以将其集成到CI工具中了。
4. 学习使用开源的fuzzing工具，将其加到CI中。
详情参见https://en.wikipedia.org/wiki/Buffer_overflow和https://en.wikipedia.org/wiki/Uncontrolled_format_string
关于可用于静态代码分析的工具列表，参见https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
可维护性
传统项目通过完整的代码审查或是检测来实现。敏捷团队经常使用结对编程，这本身就包含了持续的代码审查。此外还需：
- 鼓励开发团队使用标准和指南进行应用编码
- 建立GUI的开发标准
- 数据库设计需要灵活和可重用
交互性——不同系统和组织协同工作与分享信息的能力。交互性测试会检查两个或多个通信系统之间端到端的功能。
兼容性
项目类型表明了需要进行多少兼容性测试。
可靠性——软件的可靠性是指系统在常规与意外环境下执行和保持其功能的能力。
一些用于度量可靠性的统计数据有：
- 首次失败时间
- 平均失败时间
性能、负载、压力以及可伸缩性测试
可伸缩性——可伸缩性测试验证应用在多用户访问的情况下是否依旧可靠。重要的是要考虑整个系统而非应用本身。
通常性能测试的目的是确定系统中的瓶颈或是建立基准以供未来测试所用。此外，它还会确保系统符合性能目标和需求并帮助负责人就应用的整体质量做出决策。
负载测试用于在越来越多的用户同时访问时评估系统的行为。压力测试用于在负载超出预期的情况下评估应用的健壮性。
性能与负载测试工具：
开源： Apache Jmeter、Grinder、Pounder、ftptt以及OpenWebLoad
付费： NeoLoad、WebLoad、eValid、LoadTest、LoadRunner以及OSATest
敏捷回顾也是每次迭代计划会议的一部分。
测试自动化前期需要：适当的辅导、充足的时间和强大的管理支持。
将单元测试自动化与持续集成放在首要位置。
测试矩阵是以被测试的功能为纵轴，测试条件为横轴而形成的矩形图表。
有用的迭代度量
- sprint发布的代码经过重构并按要求编码
- sprint发布的代码经过单元测试
- sprint发布的代码包括通过的、自动化的验收测试
- sprint发布的代码被成功集成
- sprint发布的代码无缺陷
测试人员经历的一个迭代
1. 发布或主题计划阶段：
- 故事评估、设定优先级
- 制定测试计划（测试种类、测试基础设施、测试环境、测试数据、测试结果（报告））
- 准备可见性（跟踪测试任务及其状态、传达测试结果、通过的测试数、代码覆盖率、缺陷度量）
2. 迭代前的准备
- 事先明确（客户意见一致、用户故事的规模、资源）
- 确定缺陷的优先级
3. 迭代开始（是确保故事可测试并提供充足测试数据的最后机会）
- 了解细节，确定工作量
- 制作并审查高层次的测试和示例
4. 编码和测试
- 与开发人员合作、与客户交流、处理缺陷、完成测试
- 回归测试
5. 迭代结束时的收尾：
- 迭代演示
- 迭代回顾
- 庆祝成功
用户验收测试（UAT）
敏捷测试成功的7个要素：
1. 使用全队参与方法
2. 利用敏捷测试思维
3. 自动化回归测试
4. 提供和获得反馈
5. 构建核心实践的基础（持续集成、可控的测试环境、管理技术债务、增量工作）
6. 与客户协作
7. 保持大局观