一个良好的自动化测试框架应该具备灵活的，与应用程序无关的，与技术无关和不过时的特点。本文强调的准则可以帮助开发者深层分析测试方案中的代码。这种能力已经被证明在多个自动化项目上是有效的。
　　“自动化框架”这个术语已经为软件测试领域所熟知。尽管很多人都把它与应用在基于UI自动化的技术联系起来，但是它几乎总是被滥用于那些参与测试领域。这大部分的原因是由于大家对自动化框架的应用领域有误解。它应该不仅仅像Coded UI那样，只是一个单纯的UI技术。
　　现在，市场上有很多商业性的和开源的测试自动化框架。使用这些框架的主要问题在于调整他们的学习曲线和满足自动化项目的要求的困难性。虽然有一些广泛应用的遗留框架，但是他们还是有很多缺点。
　　他们缺乏灵活性，再使用昂贵的第三方产品——或者，添加一个单纯的现有用户界面技术，但不提供额外的价值。
　　一个良好的自动化测试框架应该具备灵活的，与应用程序无关的，与技术无关和不过时的特点。它应该支持一个易于安装和使用的结构化和模块化的编程模型。说“易于使用”，我们是假设和期望用户是有经验的软件开发人员。自动化是发展和正确的软件工程技能，对于计划和成功得实施一套自动化是有需要的。
　　开发一个基于UI功能自动化系统背后的想法是，运用这一框架来提高代码的可重用性、稳定性和可维护性。该代码应该是容易编写、调试、部署和运行，发生失败应该易于分析。不管你使用Ranorex，Coded UI，Telerik或Selenium
　　作为底层自动化技术，设计和实现自动化的解决方案都应该是相同的。我们选择去建议和实施的范式和模式是任何开发项目的佳实践，但他们对于UI自动化尤其有用。
　　我们已经在外面公司对几个不同的项目创建了自动化框架。在一些类似的模式中，我们可以提取其中的相同之处。这些项目的主要问题与方法和可重用性的不同相关。除此之外，不同的团队通过使用不同的自动化工具来测试应用程序功能，这也导致了整体的难度。
　　一般来说，一个自动化框架可以被定义为一套可以为自动化软件测试提供支持的假设、概念和工具。它有以下的功能：
　　?定义自动化测试脚本的方法
　　?提供建立联系机制SUT(测试系统)
　　?执行测试和报告结果
　　?减少自动化项目启动时间
　　?建立一个共同的标准
　　基本原则
　　让我们假设我们有一个具有丰富的用户界面和大量的控制的复杂的应用程序，但它只有两个屏幕。应用程序是复杂的事实可能意味着它可以有几十个手动功能测试例子。所有这些使用相同的两个屏幕。那么，我们怎样才能增加这样的测试解决方案的可维护性
　　分层架构模式
　　把软件系统体系结构分解为单独的一层的想法是非常普遍的。第一个是逻辑展示层面，，第二个是业务逻辑层面，第三个层次是负责数据存储。使用这种模式可以降低应用程序的维护成本从每一层内的组件可以改变而不影响其他的水平。同样的方法可以应用于测试系统。
　　测试代码可以分为三层:
　　·为UI自动化工具访问被测系统的接口层
　　·逻辑功能层
　　·测试用例层
　　每一层执行某项任务时都有一个降低测试的费用维护和促进创造一个新的测试的共同的目标。

图1:架构原型，测试系统的多层体系结构

　　Page Object
　　根据每个单独的测试案例来创建单独的测试逻辑、业务库和UI Map，为我们提供了特殊能力来修改当前测试用例。
　　让我们假设我们的应用程序是web邮件服务Gmail，并且两个屏幕之一是登录屏幕。登录流程被所有测试用例中所使用。(例如，为了得到第二个屏幕，您需要执行首先登录到应用程序)。

图2:谷歌邮件登录

　　让我们假定UI中有一些东西改变了，但是不合逻辑的。在我们的特定情况下，每个登录进入Gmail的现在需要输入验证码。

图3:谷歌邮件登录与验证码

　　这意味着每个测试案例现在应该更新为新的登录流程。但是一般来说，这只符合逻辑地更新一段代码。此时Page Object和功能方法模式的作用显而易见。如果只有一个页面对象宣布登录屏幕和一个登录方法，只需要两个参数(即登录名和密码)，然后只有身体的登录功能方法需要更新，以涵盖所有情况下与这种变化有关。
　　页面的无缝衔接
　　页面的无缝衔接的实现背后的想法是，在页面对象的所有方法返回另一个页面对象类实例(下一个SUT上下文页面)。例如，登录方法在我们的样例返回主应用程序默认的屏幕。它使一系列步骤的功能测试用例编写一个接一个，使这种用方法去链接。因此，业务方法本身能够通过IDE的智能感知，为测试脚本的开发人员的代码提出建议。
　　面向切面编程
　　面向切面编程实现方面似乎是很有价值的，特别是如果你需要用特定方法到try-catch块，或写报告日志条目进入/退出方法。这种方式，包含面向切面实现方面有助于提高自动化代码，使它更具可读性和可以理解的。
　　构建/运行时验证
　　自动化框架也经常建议企业标准。大多数开发人员常将同样的自动化方案应用在不同的项目上，这是一个十分棘手的问题。所以，自动化框架可以提供一系列设施，去验证在商业程序库或者功能测试中的方法是否是佳方案。
　　有不同的方法可进行验证：
　　·使用IDE扩展/插件等可能设置自定义构建的规则(例如：ReSharper， StyleCop for Visual Studio)
　　·编写自己的ID扩展名
　　·编写一个机制，可以验证测试是否包含预期的属性在运行，如果有什么不正确的在运行，它将因描述性的错误而失败。
　　以下提供一些可被验证的项目的简单列表：
　　·测试脚本的命名
　　·有适当的注释/描述
　　·业务方法的返回值/参数
　　·解决方案分层 (确认不会有交叉层次访问冲突在自动化代码中出现)。
　　·自动化测试框架的硬件支持
　　显然，该框架不能只包括佳实践。没有人能够在没有任何基础设施来支持他们的情况下继续做下去。以下提供的是一些有助于更好的理解自动化框架实现的指引。
　　首先我们需要以某种方式运行测试。在大多数情况下，单元测试框架是用于运行功能测试和衡量结果。有了各种技术/语言的支持，能够为功能测试代码和持续集成（CI）系统完美的结合提供了多种选择的单元测试框架。
　　为测试运行加载配置
　　测试配置很大程度上取决于SUT域和测试细节。例如，在大多数测试流的所有配置(如参数、远程连接服务器等)可以只是在测试脚本中写死的。
　　在数据驱动的测试中， 当相同的测试可以使用不同的配置（例如，输入参数）多次运行的情况下，单元测试框架还提供从外部存储设备读取数据测试脚本。
　　因此，如果需要自定义配置加载的实现你的自动化框架的话，您需要仔细反复检查。
　　报告测试结果
　　报告测试结果/调试测试信息是自动化框架的重要的功能之一。
　　有以下几个原因:
　　?报告分析简化了测试应用程序/故障排除，所以你的报告的信息越多，它提供的支持越好。
　　?报告是所有的项目经手人观察到的结果。
　　如果你想跟踪测试执行在一段时间内的一些动态变化，你应该运用额外的设备将测试结果地保存到数据库，这样可以作比较。
　　别忘了把一些花俏的东西放进报告表示层(xml / html)，如公司标志、结构化输出等。这些事情能够极大地改善你的管理。如果你提供一个“时间”报告，图表也需要高度重视。
　　验证
　　再者，大多数单元测试框架已经有一套支持在测试脚本中执行Assert/Verify的机制。这是一个很好创建自己的验证机制的实践，以便:
　　?从一个特定的单元测试框架中抽象用例断言
　　?为你的需求定制一套验证方法
　　?添加特定的逻辑到您的验证方法，让您的验证结果自动写入报告