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的机制。这是一个很好创建自己的验证机制的实践,以便: ?从一个特定的单元测试框架中抽象用例断言 ?为你的需求定制一套验证方法 ?添加特定的逻辑到您的验证方法，让您的验证结果自动写入报告 |
