那么，如果在一开始选择仅支持一到两个高优先级的环境，首先部署手动测试，随后对某个测试进行自动化，这种做法会不会更好一些呢？
　　其实，只要你能够减少测试的成本（或者至少能够预期成本的减少），同时交付可维护的自动化脚本，这正是控制成本的管理人员所乐于见到的。在实际实现背后的测试用具或许规模庞大，并且对于运行这些测试用例来说更为重要，但我们应具体情况具体分析。一般来说，在运行第一批脚本的时候，你不大会用到所有的测试用具。因此，我认为更重要的地方在于提供一个一致的测试自动化方案的架构，它能够允许你今后对测试用具进行扩展，而不是一上来要完成所有的测试用具。
　　你可以在这里找到一种可扩展的测试自动化架构的描述，这是一种分层的测试方案。它的做法是将代码分解为多个独立的层，并创建相应的Page Object对象。这种做法不需要你投入大量的时间，却能够为终的方案带来很大的可维护性。而且，终的方案能够在一种还是多种操作系统、web浏览器上工作，这一点真的并不重要，我们可以随后为其添加多平台的支持。
　　另一个值得一提的重要领域是关键字驱动的框架，这种途径意味着你首先需要开发出一个框架（一个关键字的集合），随后才能够通过将这些关键字链接在一起的方式开发测试脚本。
　　我个人认为这种做法是一种糟糕的实践。首先，在电子表格中进行开发非常容易出错，任何一个拼写错误都会造成错误，并且难以通过调试发现。此外，如果你在编写业务逻辑，而生成的测试却不会调用这些逻辑，那好像在开发应用程序的业务逻辑时不提供任何单元测试、或是不提供用户界面一样。另外，你永远都无法预先估计你需要开发多少条关键字，才能够让一定特定的测试得到足够的关键字，从而满足测试脚本的需求。
　　一种推荐方法
　　我将描述一种我个人对测试自动化方案进行计划的方法，按照我的经验来看，这种方式已经证实了它的正确性，不过它也只是“正确的做法”之一。
　　1.客户对于引入测试自动化这种做法的期待是什么？对于当前项目的时间表与技术能力来说，测试自动化是否真的可行？我的看法是，在某些时候，在这一阶段对此问题的回答是“测试自动化完全不适合于实现你的目标”。出现这种情况的一种可能是：自动化的开发工作与所获的益处相比，所投入的精力过于巨大。
　　2.了解将测试系统的技术，并且选择适合的自动化工具以模拟用户的行为也非常重要。
　　3.那么，我们应当选择怎样的方式呢？我在这里要区分两种主要的方式，即“快速而粗糙”的方式，以及“基于解决方案”的方式。“基于解决方案”的方式在上文已经描述过了，“快速而粗糙”则意味着可以说这种方式“只能够在我的机器上运行”。只需一些基本的投入，你能够立即得到一些结果。对于性能测试来说，这种方式不失为一种良好的选择，因为获取系统的性能参数有时（但也并非总是如此）是一种一次性的活动。
　　4.计算整个实现方式的实际收益率，建立一个小型的概念验证，以了解每次发布时手动运行回归测试与冒烟测试的时间，以及运行的次数。这样一来，我们能够理解这种方式所减少的时间成本（也意味着金钱）。
　　5.为测试的实现提出一种基于阶段的路线图。在每一阶段，主要的交付内容是一些自动化的测试脚本，以及使这些脚本实现优化所必需的框架特性。
　　结论
　　在进行测试评估时，我倾向于讨论测试自动化的解决方案。在整个产业都在选择敏捷开发的现阶段，应用程序的各个部分将陆续交付，并保证能够工作及一致性。那么，为什么在进行测试自动化时不选择同样的策略呢？对于完全专注于开发框架这种策略，我们应当坚决说不！我们应当进行增量式的交付（即自动化脚本的部分子集，以及运行这些脚本所必需的部分测试用具），以实现优的、快的收益率