设计测试自动化框架的最佳实践

2024-12-13   出处: medium.com  作/译者:Govinda Solanki/空山新雨

  1. 保持简单直观(KISS 原则)
    您的自动化框架应该简单易懂。

    • 将复杂的测试分解成更小的、可重用的模块。这使得理解、维护和重用代码片段变得更加容易。
    • 给测试用例、方法和变量选择有意义的名称。
    • 避免过度设计。不要添加不必要的复杂性,如额外的设计模式或抽象,除非它们解决了眼前的问题。
      过度设计举例:使用单例模式的WebDriver增加了不必要的复杂性。因为当您需要并行运行测试时,它可能会造成问题,它会导致每个测试将共享相同的WebDriver实例。

      public class SingletonDriverFactory {
          private static WebDriver driver;
          private SingletonDriverFactory() {}
          public static WebDriver getDriver() {
              if (driver == null) {
                  driver = new ChromeDriver();
              }
              return driver;
          }
      }
      
  2. 基于组件的结构设计
    测试自动化框架应遵循模块化方法,其中的组件松散耦合,框架一部分的变化不影响其他部分。这意味着测试数据、实用方法、页面对象和测试执行都将使用单独的模块。
    举例:

    • 测试数据处理模块:这样就可以将所有测试数据放在JSON或XML等外部文件中。
    • 实用程序模块:常见的功能如读取JSON文件或截屏等都可以放在这里。
    • 测试用例模块:所有测试用例都将位于此处,这里可能会用到TestNG的注解(annotations)特性。
    • UI自动化的页面对象模型(POM):POM将测试逻辑与页面结构分开。每个网页都由一个Java类表示,将与Web元素的交互封装在变量和方法里面。当用户界面发生变化时,这种模式维护起来更简单。
  3. 通过API或DB管理测试数据和前提条件
    执行UI自动化时,最好通过API或DB而不是UI本身来设置测试数据和前提条件。
    与API或DB驱动的测试相比,UI测试用例往往更脆弱(不稳定)。
    另外通过API或DB设置测试数据比通过用户界面导航要快得多,从而减少了测试整体的执行时间。
    通过分离测试数据设置,用户界面测试可以更专注于用户界面的测试。这有利于形成更集中、更准确的测试。
  4. 避免在测试自动化框架中使用Excel
    虽然Excel是一个多功能工具,但它并不总是管理自动化测试数据的最佳选择。原因如下:

    • 版本控制和协作问题: Excel文件不是基于文本的,这样就很难在Git等版本控制系统中进行有效的管理,从而难以跟踪修改并进行有效的协作。

    • 性能问题: 与JSON、XML或数据库等其他格式相比,Excel文件的读写速度更慢。在运行大型测试套件时,这可能会大大降低测试的执行速度。

    • 数据完整性: Excel文件很容易受到意外损坏或产生错误的格式,这都可能会导致测试失败或结果不正确。而基于文本的文件格式更强大,不容易出现意外错误。
    • 不适合复杂数据:在Excel中处理嵌套或分层数据会很困难。而JSON或XML等格式能更自然地处理复杂的数据结构,大大提高测试用例的灵活性。
    • 有限的自动化支持: 操作Excel需要额外的库支持,如Apache POI(Java)。这些增加了框架的复杂性和依赖性,使得维护和排除故障变得更加困难。

    • 难于持续集成: 与基于代码的框架相比,将基于Excel的测试集成到CI/CD流水线中更具挑战性。

      通过选择JSON、XML、数据库或CSV等替代方案,您的自动化框架在处理大规模和复杂的测试数据方面将变得更快、更容易管理、更强大。

  5. 使用设计模式
    设计模式可以改善自动化框架的结构和可维护性。

    • 工厂模式:在不暴露内部创建逻辑的情况下创建新的对象。
    • 策略模式:在运行时选择不同的策略或行为。
    • 构建器模式:帮助逐步构建复杂的对象。
  6. 使用SonarLint等静态代码分析工具
    SonarLint等工具有助于检测代码中的潜在问题,如错误、代码异味(通常表明代码可能难以理解、维护或扩展)或安全漏洞。
    比如:SonarLint可以突出显示未使用的变量或函数等问题,这有助于保持干净高效的代码。它直接与IDE集成,并能在编写代码时提供实时反馈。
  7. 数据驱动测试
    使用数据驱动的方法,您可以使用多组测试数据运行同一测试脚本。
    这提高了可重用性,使得测试代价变小,测试覆盖范围更大。
  8. 异常处理和日志记录
    合理的异常处理和日志记录对于理解测试失败至关重要。
    自动化框架中的每个操作都应该被记录下来,测试失败时抛出的异常信息应该是有明确意义的。
  9. 识别可自动化的测试
    专注于那些可预测的、重复的和关键的测试,从而提高效率和准确性。
    这里的目标应该是识别适合自动化的那些测试,而不是试图自动化所有的测试。

    • 选择经常执行的测试。
    • 对于UI自动化,尝试优先自动化那些包含业务最关键路径的测试。
  10. 用于UI自动化的等待工具

    • 避免使用硬编码等待:避免使用像Thread.sleep() 这样的硬编码等待,因为它们可能会使测试变慢且不可靠。
    • 集中等待逻辑:创建一个专用的等待实用程序类来封装所有等待逻辑,使其更容易维护和更新。
    • 使用显式等待,而不是隐式等待:专注于等待满足特定条件,例如可点击或可见的元素。
    • 超时参数化:允许为不同场景自定义不同超时值,且具有合理的默认值。
    • 超时策略: 设置符合实际的超时时间,避免长时间的延迟。找到一个既能确保元素加载又不会使测试变慢的平衡点。
      过度使用等待(即使是显式等待)也会使测试变得笨拙。只等待必要的条件并优化轮询间隔
  11. API自动化的 POJO类
    与直接验证JSON相比,在API自动化中使用POJO(Plain Old Java对象)类有几个优势。虽然一些团队可能会为了简单起见而跳过POJO类,但使用它们是有充分理由的。

    • 强类型和编译时安全性:POJO类使用强类型,这确保您正在处理的数据具有明确定义的结构。编译时错误可以帮助更早地发现问题,例如类型不匹配或字段缺失,减少直接使用JSON可能遇到的运行时错误。
    • 代码可读性和可维护性:当使用POJO时,您的数据结构是清晰的,这会使代码更具可读性,更容易维护。同时避免了需要浏览嵌套的地图或JSON字符串来提取字段,对于复杂的API来说更容易出错且可读性较低。
    • 重构更容易: 当API响应结构发生变化时,基于POJO的代码更容易重构和适应变化,因为只需要修改POJO类,其余代码可以保持不变。如果没有POJO,您必须更新代码中直接访问JSON结构的多个不同位置。
    • 完整响应类型校验: POJO类可用于自动映射和验证整个API响应。Jackson或Gson等工具允许JSON到对象的转换的同时验证字段类型。这可以防止手动检查可能引起的部分验证问题,即一些字段可能会被遗漏。

      长远来看,在API自动化中使用POJO更具可扩展性、可维护性和稳健性。虽然在创建POJO类方面可能会引入一些初始开销,但在可读性、测试结构、类型安全性和灵活性方面的好处远远超过了这些开销。在某些情况下,跳过POJO可能比较有效,但对于具有不断发展的API的复杂应用程序来说,POJO提供了更好的结构,并减少了不稳定测试的几率。

  12. 遵循DRY原则(不要重复自己)

    • 避免在定位器(XPath)中重复:在页面对象(PO)类中集中 管理定位器,而不是在多个测试用例中重复使用它们。
    • 明智地使用继承: 在不同测试中需要共同功能的情况下,继承可以帮助共享相同的方法。然而,注意避免过度使用继承,因为它可能导致紧密耦合。
    • 可重用的测试设置(Setup)和清理(Teardown) :使用基类在一个地方测试设置和清理环境,而不是在每个测试中重复设置逻辑。识别在多个测试用例中重复的常见测试步骤,并将其提取为可重用的方法或函数。
  13. 独立的测试
    独立的测试不仅可以实现并行执行,还使维护更加容易。虽然实现完全独立的测试并不总是可能的,但设计可以独立运行的测试用例是公认的一种最佳实践。因为这种方法提高了可靠性,减少了依赖性,并允许更快、更高效的测试。
  14. 避免硬编码—使用配置文件
    将URL、凭据和其他数据存储在配置文件中,而不是使用硬编码。
  15. 坚持SOLID原则
    遵循SOLID(面向对象设计中的五个设计原则的首字母缩写)原则可以提高代码的可维护性和灵活性。
  16. 定期审查和重构

    • 定期审查和更新测试自动化框架:这确保了它保持有效并适应不断变化的需求。
    • 识别需要改进的地方:尽可能地优化性能、提高可维护性或增加测试覆盖范围。
    • 更新过时的库和工具:使用最新的技术更新自动化框架。
    • 删除冗余或不必要的代码:优化测试脚本来提高效率。
    • 提高测试覆盖范围:确保测试彻底覆盖所有相关场景。
  17. 测试报告
    您的测试报告应该是可定制的。因为并非所有项目都需要相同的报告细节,因此测试报告应允许配置显示/隐藏屏幕截图、日志或环境详细信息等部分。
    报告里要包含那些执行时间超长或经常无法优化测试流程的测试。
    在报告顶部包含汇总统计数据,以快速概述整体测试执行情况。

最后,以上这些只是些指导方针,一般来说您需要根据您组织的具体需求来进行相应的调整。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
22° /227 人阅读/0 条评论 发表评论

登录 后发表评论
最新文章