在进行测试自动化项目顾问工作的早期阶段，经常有人请我对于自动化的实现进行评估。而当我给出一个初步的估算时，很快会遇到下一个问题：“这个估算所针对的是一个测试套件还是框架呢？”
　　这种问题经常会让我感到难以回答，因为我不清楚他们问的到底是什么……哪些东西属于测试脚本？哪些东西属于框架？他们之间到底如何区分？
　　让我们首先来明确几个定义。
　　自动化工具
　　自动化工具/指令的作用是与UI进行交互，例如模仿单击按钮、输入文本及验证文本框中的值。至少这个定义是我所能够确认的，不存在任何含糊的地方
　　框架
　　我从前对于框架的认知是偏具体的，即可重用的、与SUT（待测试系统）无关的、并且与自动化工具无关的库，它能够加速自动化的实现。
　　但在IT业界中，框架这个词的使用非常频繁，甚至即使仅仅谈论自动化测试的时候，这个单词在不同的上下文中也会具有不同的含义

　　图1 – 不同的框架示例

　　特定于工具的框架
　　一般来说，商业级自动化工具的提供者，乃至开源社区往往会为他们的工具打造一个完整的基础设施，在其中实现报表生成、测试套件的运行、分布式测试的运行，并与测试的执行环境相集成。举例来说，Selenium工具的主要组件是WebDriver，它作为web浏览器的插件运行，对于在web浏览器中运行的web应用进行DOM模型（即web页面的一种基于xml文档对象模型）的操作。但Selenium还包括大量的额外编码库，以及一个实现了录制-重播功能的工具（Selenium IDE）。所有这一切工具共同组成了Selenium自动化测试框架
　　Serenity是另一个很好的例子，它也是一种特定于工具（围绕着Selenium Web Driver而创建）的框架。但它的目标不在于提供大量的可选组件或插件，因为特定的组件已经由社区专家合而为一了。你可以将它设想为一种加速器，通过它提供对更快的测试自动化实现的启动的支持，同时也支持BDD类型的测试。
　　而在商业产品中，更难以找出测试命令本身所在，原因是商业级的特定于工具的框架（例如HP QTP、Ranorex和TestComplete）通常是一种经过完整构建与部署的基础设施，包含了行为的模拟器、编写脚本的IDE及报表工具。
　　特定于项目的框架
　　这种框架是在特定的应用开发阶段为了实现自动化而开发的，用于支持特定的应用的自动化测试的需求。这种框架的组件可以由其他开源库实现，针对SUT建立一种特定的环境，以支持以下功能中的部分或全部：
　　将经过构建的应用（包括它的组件，例如数据库、服务库和后端）部署到某个环境中；
　　启动应用；
　　运行测试用例；
　　将测试的运行结果报告直接发送给某个测试管理系统
　　提供控件的封装，以支持通过某些特定的控件（例如grid或自定义控件等等）简化自动化的编码工作。
　　另一个需要考虑的重要组件是测试用具（test harness），它能够支持在不同的云环境中运行测试用例，允许在所支持的操作系统与浏览器的运行产生不同的结果。可以选择自行创建这些操作，也可以选择某种工具框架中的组件。
　　佳实践框架
　　框架是个非常吸引人的词，一旦你提到这个词，会令人产生深刻的印象。举例来说，Zachman框架与开发组件之间没有任何关联，它只是一种用于定义企业架构的方法。同样的道理也适用于自行开发的自动化构建框架，它们可以包含用于自动化测试的组件，也可以包含描述如何以佳方式对某个测试进行自动化的方法。对于那些希望首次尝试自动化测试，或是试图理解现有的自动化项目的运行情况的客户来说，自动化测试专家（包括我）通常会为他们推荐这种框架。
　　关键字驱动的框架
　　还有一种类型的框架也不可不提，这是一种针对编码经验较少的员工、特定于工具或项目的框架。这种框架能够让他们编写或维护自动化脚本。经过代码化的关键字（例如Login、Click、NavigateToPage和TypeText等等）是在代码中的某处实现的，这里的代码被实现为了一种关键字的库。
　　测试人员将获得一份关键字的参考引用，因此他们可以在表格中直接编写脚本。这些表格随后将导入某些关键字解释器中，并通过调用某个库中的特定实现而开始执行测试。
　　测试自动化方案
　　我倾向于将特定于某个项目的测试脚本与所有相关的底层框架统称为测试自动化方案，它包含了与整个项目、测试环境管理、测试方案架构以及佳实践相关的所有特定或一般性的框架，同时也包含了测试脚本。因此在进行评估时，我倾向于讨论整个测试自动化方案。
　　如何确定边界？
　　实现测试自动化通常来说意味着巨大的投入，因此重要的是尽早理解并使投入的回报清晰化，否则项目很可能会被取消
　　没错，在某些场景下，你可能需要开发一种特定的测试用具，而这非常耗时。但不能因此决定选择一种独立于测试脚本之外的实现。你需要时刻牢记以佳实践实现自动化测试脚本（以便于日后的维护），这才是重要的。这种做法实际上只会节省你在项目上投入的时间。
　　举一个真实的案例：我曾经参与评估了一个“首次尝试”的自动化项目，它终被取消了。其原因是所有的精力都投入到开发某个环境管理实验之中，以支持运行自动化的各种操作系统。经验丰富的开发者为此投入了数月的开发时间，但管理人员在开发过程中看不到任何投资收益。后还是延续了手动的测试周期。