敏捷自动化测试
原文：Agile Test Automation – James bach公式化的典型的自动化测试过程
1、 购买一个昂贵的GUI测试执行工具（例如 Rational、Mercury、Compuware等）
2、 定义很多测试用例
3、 招聘一个自动化测试组实现每个测试用例的自动化执行
4、 构建一个完整的测试库和框架
5、 不断地完善和修正
如果你的产品很容易测试并且变更不大的话，以上方式很适合。但是关于自动化测试，我们为什么想得那么狭窄？
尝试把自动化测试想成是“任何使用工具来支持测试”。敏捷自动化测试就是把敏捷开发的原则应用在测试自动化上。
敏捷自动化测试的原则
1、测试自动化意味着使用工具支持测试项目的各个方面，不仅仅是测试执行方面。
2、当测试自动化得到指定的程序员（toolsmiths-“工具铁匠”）支持时，会不断地顺利进行。
3、“工具铁匠”由测试员领导。
4、“工具铁匠”收集并应用各种各样的工具来支持测试。
5、“工具铁匠”帮助实现可测特性并“打造”工具以便利用这些可测特性。
6、 组织实现测试自动化是为了完成某个短期的目标。
7、 避免盲目进行长期的自动化测试任务，而不是基于业务场景的分析。
工具支持测试
1、 测试创建（数据和脚本的产生）
工具可以产生特定的数据，例如：随机的Email信息，或产生数据库，或产生组合参数来覆盖我们的测试。
2、 系统配置
工具可以保持或重现系统参数，把系统设置到某个特定的状态，或创建或回滚到一个“ghost”的磁盘
3、 模拟
工具可以为测试模拟一些不具备的环境条件，这些环境可能会很难出现或提供起来很昂贵。
4、 测试执行
工具可以操作软件系统本身，模拟用户的GUI操作或绕过GUI层直接使用某些测试接口。
5、 问题分析
工具可以使某些不可见的东西可见。稳定地分析产品或分析log文件，或监视系统参数。
6、“预言”
“预言”是通过某些机制来判断错误或成功。工具可以自动地判断产品的某些类型的错误条件。
7、记录和覆盖分析
工具可以帮助记录测试过程覆盖的地方和未覆盖的地方。
8、 试管理
工具可以记录测试结果，组织测试用例。
到处是工具
1、 MSDN库
2、 微软的很多开发工具都包括很多有用的小工具
3、 微软兼容性工具包和其他免费工具（www.microsoft.com）
4、 基于网页的测试资源（HTML checkers、accessibility analyzers等）
5、 widows资源包
6、 脚本语言（例如：Perl、Ruby、TCL）和相关库
7、 共享资源库（www.download.com）
8、 操作系统监视工具（www.sysinternals.com）
9、 开源测试软件（www.opensourcetesting.org）
10、 探索性测试的监视软件（www.spectorsoft.com）
11、 项目组其他人正在使用的工具
“工具铁匠”的任务
1、 快速响应测试员的请求并提供协助
2、 查找影响测试效率的问题
3、 调查测试员关心的问题的可能的解决方案
4、 应用技术改进测试过程
5、 提供产品的可测性功能特性
6、 研究工具并学习怎样使用
7、 收集开发人员或测试员创建的工具
8、 对产品进行评审以便计划自动化的可能性
测试员可能会问“工具铁匠”的问题
1、 我怎样测试这个新的功能？
2、 我如何才能看到产品内部做了什么？
3、 我如何判断测试是否通过？
4、 有没有办法让我能自动地执行这些操作？
5、 有没有办法让bug重现更加容易些？
6、 帮助我调查这些bug
7、 这里有一个测试要执行，你能否帮助我产生1000个变量？
8、 我的测试覆盖了产品的多少地方？
9、 我想对产品进行压力测试，是否有什么工具可以使用？
管理敏捷自动化测试
1、 请求清单
请求清单是测试员发出的自动化测试要求
2、 任务清单
任务清单是每位“工具铁匠”收到的分派任务
3、 移交清单
移交清单是目前被测试组使用的解决方案。每个都包括解决方案对测试效率的影响的简要描述
4、 维护清单
维护清单是需要改进的解决方案的清单。可以考虑把它分成两部分：关键维护和增强维护。
5、 障碍清单
障碍清单是所有尚未解决的影响测试效率的问题清单。这些问题需要新的昂贵的工具、实际的可测试性改进、或者需要更多工作而难以在短期实现
对于一个大型的测试组来说，至少需要一名“工具铁匠”，但是不要把所有测试员都作为“工具铁匠”，因为这样做的成本太高，这样所有测试员都要像“工具铁匠”一样思考问题。