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