构建一个适应业务变化的自动化框架体系

380 2023-08-22

架构自动化封装 API UI

从大概10年前学习自动化（QTP），到开始规划自动化平台（TestWrite），再到敏捷活文档，对于做工具、框架还是平台云层也算是有点自己的想法。

越是平台越难适应变化，越是工具能力要求越高

对于变化较少的，规范的可以使用平台化的模式统一管理，例如常见的RestFul接口，只需要API地址，Json入参规范和Json出参规范即可；而对于前端原型规范（css或id标记）的也可以通过平台化的录制回放或者RF平台来统一管理。

一直以为都2021年了，前后台分离及规范的前台已经是标配，然而历史债务的问题，老系统的自动化就没有那么的正规。正巧这次为某行进行分层自动化架构设计培训，就遇到了历史问题的情况，完全基于（Java的代码及架构设计）：

前台架构的历史问题

虽然前台已经规范过一次，添加了不少的ID，但是由于本身技术架构的问题，会影响自动化的执行效果（页面渲染后会异步加载Jquery的事件部分，构建对象操作）。在该架构下虽然页面已经渲染完成，但是所有对象都是无法操作的，需要等到异步js加载完成才能实现效果。
后台架构的历史问题

传统系统还无法做到完全的前后台分离，部分接口使用了老式的servlet返回HTML页面，也有部分结构升级了局部的Json体系，在这种情况下对于接口测试也面临着入参配置，出参断言及前后数据依赖维护复杂的问题。

对于比较重要的项目，大规模的自动化回归是有效减少上线质量问题的重要手段，尽早尽快的反馈在测试环境中的问题，通过持续交付来提升缺陷修复周期。那么对于这样的混合历史技术债务的架构怎么构建分层自动化框架体系呢，这里做了几个尝试：

UI方面

基于基本PO的封装，由于无法有效的获取js加载的周期，在全新页面中加入全局等待时间，确保对象操作不受影响，也降低了每个对象都要等待的执行效率低下。
与前端同步的PO封装，同步目录结构及名称，可以极大的提升前端开发与自动化脚本的同步性，甚至赋能前端同步对象变化。
基于业务的页面功能封装，从业务视角进行页面功能封装，让任何一个接手人员可以在不了解方法功能的情况下也能简单完成业务组合及操作。
API方面

使用多套接口基础（OKHTTP和Jsoup），对于标准的Restful基于OKHTTP的封装，基于传统的HTML返回基于Jsoup的封装。因为Jsoup对于返回的HTML能够使用标准的DOM模式处理，在提取对象和断言上会方便很多。
为同一业务构建API方法封装与UI方法对应。在PO中融合UI及API，这样可以快速评估某功能是否实现了UI及API的双重校验，避免遗漏。
支持测试用例的UI及API混用模式，以Junit5为基础。
与研发接口匹配的接口规划及内部（Service层）测试能力。
测试数据构建的策略支持，基于Dao层的驱动能力。
一定的数据Mock隔离能力。
日志方面

统一日志格式及策略，基于底层封装实现任意用例的完整测试执行日志。