开发测试自动化脚本以及自动化框架

在进行测试自动化项目顾问工作的早期阶段，经常有人请我对于自动化的实现进行评估。而当我给出一个初步的估算时，很快就会遇到下一个问题：“这个估算所针对的是一个测试套件还是框架呢？”

这种问题经常会让我感到难以回答，因为我不清楚他们问的到底是什么……哪些东西属于测试脚本？哪些东西属于框架？他们之间到底如何区分？

让我们首先来明确几个定义。

自动化工具

自动化工具/指令的作用是与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等等）是在代码中的某处实现的，这里的代码被实现为了一种关键字的库。

测试人员将获得一份关键字的参考引用，因此他们可以在表格中直接编写脚本。这些表格随后将导入某些关键字解释器中，并通过调用某个库中的特定实现而开始执行测试。

测试自动化方案

我倾向于将特定于某个项目的测试脚本与所有相关的底层框架统称为 测试自动化方案 ，它包含了与整个项目、测试环境管理、测试方案架构以及最佳实践相关的所有特定或一般性的框架，同时也包含了测试脚本。因此在进行评估时，我倾向于讨论整个测试自动化方案。

如何确定边界？

实现测试自动化通常来说意味着巨大的投入，因此重要的是尽早理解并使投入的回报清晰化，否则项目很可能会被取消

没错，在某些场景下，你可能需要开发一种特定的测试用具，而这非常耗时。但不能因此就决定选择一种独立于测试脚本之外的实现。你需要时刻牢记以最佳实践实现自动化测试脚本（以便于日后的维护），这才是最重要的。这种做法实际上只会节省你在项目上投入的时间。

举一个真实的案例：我曾经参与评估了一个“首次尝试”的自动化项目，它最终被取消了。其原因是所有的精力都投入到开发某个环境管理实验之中，以支持运行自动化的各种操作系统。经验丰富的开发者为此投入了数月的开发时间，但管理人员在开发过程中看不到任何投资收益。最后还是延续了手动的测试周期。

那么，如果在一开始选择仅支持一到两个最高优先级的环境，首先部署手动测试，随后对某个测试进行自动化，这种做法会不会更好一些呢？

其实，只要你能够减少测试的成本（或者至少能够预期成本的减少），同时交付可维护的自动化脚本，这正是控制成本的管理人员所乐于见到的。在实际实现背后的测试用具或许规模庞大，并且对于运行这些测试用例来说更为重要，但我们应具体情况具体分析。一般来说，在运行第一批脚本的时候，你不大会用到所有的测试用具。因此，我认为更重要的地方在于提供一个一致的测试自动化方案的架构，它能够允许你今后对测试用具进行扩展，而不是一上来就要完成所有的测试用具。

你可以在这里找到一种可扩展的测试自动化架构的描述，这是一种分层的测试方案。它的做法是将代码分解为多个独立的层，并创建相应的Page Object对象。这种做法不需要你投入大量的时间，却能够为最终的方案带来很大的可维护性。而且，最终的方案能够在一种还是多种操作系统、web浏览器上工作，这一点真的并不重要，我们可以随后为其添加多平台的支持。

另一个值得一提的重要领域就是关键字驱动的框架，这种途径意味着你首先需要开发出一个框架（一个关键字的集合），随后才能够通过将这些关键字链接在一起的方式开发测试脚本。

我个人认为这种做法是一种糟糕的实践。首先，在电子表格中进行开发非常容易出错，任何一个拼写错误都会造成错误，并且难以通过调试发现。此外，如果你在编写业务逻辑，而生成的测试却不会调用这些逻辑，那就好像在开发应用程序的业务逻辑时不提供任何单元测试、或是不提供用户界面一样。另外，你永远都无法预先估计你需要开发多少条关键字，才能够让一定特定的测试得到足够的关键字，从而满足测试脚本的需求。

一种推荐方法

我将描述一种我个人对测试自动化方案进行计划的方法，按照我的经验来看，这种方式已经证实了它的正确性，不过它也只是“正确的做法”之一。

客户对于引入测试自动化这种做法的期待是什么？对于当前项目的时间表与技术能力来说，测试自动化是否真的可行？我的看法是，在某些时候，在这一阶段对此问题的回答是“测试自动化完全不适合于实现你的目标”。出现这种情况的一种可能是：自动化的开发工作与所获的益处相比，所投入的精力过于巨大。
了解将测试系统的技术，并且选择最适合的自动化工具以模拟用户的行为也非常重要。
那么，我们应当选择怎样的方式呢？我在这里要区分两种主要的方式，即“快速而粗糙”的方式，以及“基于解决方案”的方式。“基于解决方案”的方式在上文已经描述过了，“快速而粗糙”则意味着可以说这种方式“只能够在我的机器上运行”。只需一些最基本的投入，你就能够立即得到一些结果。对于性能测试来说，这种方式不失为一种良好的选择，因为获取系统的性能参数有时（但也并非总是如此）就是一种一次性的活动。
计算整个实现方式的实际收益率，建立一个小型的概念验证，以了解每次发布时手动运行回归测试与冒烟测试的时间，以及运行的次数。这样一来，我们就能够理解这种方式所减少的时间成本（也就意味着金钱）。
为测试的实现提出一种基于阶段的路线图。在每一阶段，主要的交付内容是一些自动化的测试脚本，以及使这些脚本实现最优化所必需的框架特性。

结论

在进行测试评估时，我倾向于讨论测试自动化的解决方案。在整个产业都在选择敏捷开发的现阶段，应用程序的各个部分将陆续交付，并保证能够工作及一致性。那么，为什么在进行测试自动化时不选择同样的策略呢？对于完全专注于开发框架这种策略，我们应当坚决说不！我们应当进行增量式的交付（即自动化脚本的部分子集，以及运行这些脚本所必需的部分测试用具），以实现最优的、最快的收益率

关于作者

Sasha 是一位博士及测试自动化方面的专家，在 Softserve Inc. 担任测试自动化的经理。他也是测试自动化方面的传教士及顾问，帮助小型的创业公司以及财富500强公司建立正确的质量保证文化，无论产品的开发环境是敏捷还是瀑布式流程。他还是一位讲师以及培训师，也是 StepsToReproduce 的开发者，这是一个免费的探索性测试工具，其功能可取代Windows系统下的Problem Steps Recorder（一个问题记录组件）。