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

文章回顾了作者从10年前开始学习自动化技术的经历，包括规划自动化平台和敏捷活文档。作者指出，平台化适合规范且变化少的场景，例如RestFul接口，而前端原型规范也可以通过平台化管理来统一处理。但是，对于那些历史遗留问题较多的老系统，自动化面临更大的挑战。

文章进一步探讨了在一个为某银行设计分层自动化架构的培训中遇到的前后台架构的历史问题。前台的问题在于技术架构导致页面渲染后的对象无法立即操作，需要等待异步的JavaScript加载完成。后台问题则在于系统无法完全实现前后台分离，旧接口返回HTML页面，而局部结构则升级为Json体系，使得接口测试的配置和维护变得复杂。

作者提出，对于重要项目，大规模的自动化回归是减少上线质量问题的关键。因此，针对混合历史技术债务的架构，作者尝试构建分层自动化框架体系。在UI方面，作者采用了全局等待时间和与前端同步的页面对象（PO）封装，以及基于业务的页面功能封装，以提高自动化脚本的可靠性和前后端的协同工作效率。API方面，则使用了OKHTTP和Jsoup等工具来封装接口调用，并集成UI和API测试，采用数据Mock隔离等策略来提高测试效率。此外，作者还强调了统一日志格式及策略的重要性。

虽然由于时间和个人能力的限制，作者未能完整构建活文档架构及报告体系，但自动化测试只是质量保证中的一部分。作者还介绍了与研发同步构建质量中台、质量度量、精准覆盖率获取、持续交付模式、环境构建等内容。文章最后提到，质量意识应该是全局性的，并强调了技术支持在最终交付框架中的作用，使其成为未来可参考的架构模板。作者还提到了有意向的读者可以通过微信获取内推简历的机会。