接口测试脚本架构演进

一开始做HTTP接口测试，为图快速起效，直接基于测试用例和接口信息编辑执行测试用例的业务代码。以下总结脚本架构如何根据实际情况演进。
1.受selenium业务脚本page-object架构影响，第一版架构也是interface-object模型。综合yaml文档接口信息数据分离、按不同业务子系统抽象多个类，其中封装所需接口成员方法以供测试用例层重复调用，组合测试用例。
2.接口测试和界面测试所需元素的巨大差异，导致脚本很快重构出第二版架构：system-module-test三层分工。
system基本等效于原来的interface-object内容，但由于用例大多基于功能模块描述，所以第二层的抽象是上下两层的过度，基于子系统接口封装业务操作。这样顶层test层只需要按更真切的模块界面业务逻辑快速清晰编辑测试用例。
3.然后的变更是在test层，跟开发交心后老司机提议用例层把场景和校验逻辑分离。因为对于接口测试，一堆用例很多时候场景可以复用，校验逻辑也是相同的，区别只在触发校验的时间节点不同。
于是乎第三版架构：system-module-test(operate-checkpoint)。这时候，新用例进来，旧的场景传新参+旧校验逻辑放新节点。用例编码速度由于充分利用旧积累事半功倍。
4.这下回顾一番，一堆java se的东西也没啥，yy天长地久的时候翻车了。接口数量有限和逻辑有限，system层没什么乱象。module层由于业务功能成员方法的累积，数据清洗逻辑的扩展，在臃肿到一千行的时候我终于忍无可忍，把它革命重构了。
这次引入面向接口编程思想，模块层所有功能只提供接口面向test用例层。接口的实现，按功能相关程度和加入的时间被重构到各个实现类中。这下模块层终于分较为均匀的拆分了，得益于接口的引入测试脚本可扩展性也长足提高。
--------------------------------------手动分割------------------------------------------
前期后后忙了很久，自信满满对项目回归测试贡献良多。终于有一天某子系统重构，环境配置全都gg后我幡然领悟到了前辈说的“尽量不要在代码写测试逻辑”有多关键。所有逻辑变更对应的脚本变更都压在写测试脚本一人身上，需要重新梳理需求测试点等。随着脚本规模变大这种方式的弊端愈发明显，后续果断推出了读Excel执行测试用例输出报告工具。