之前写了一篇FunTester测试框架架构图初探的文章，花了一张图，主要讲解了FunTester测试框架的内容，最近闲赋在家没啥事儿，也一起顺着思路花了一个FunTester测试项目的架构图。
有了上一次的经历，对于draw.io工具的使用比较熟练了，基本一半天就画完了，感觉比较粗糙，后期继续优化，有兴趣的欢迎一起交流。
FunTester测试框架架构图
主要思路还是依据FunTester测试框架提供的能力，先进行基础层的封装，然后功能层，然后测试层，然后再根据不同的上层建筑完成其他系统的集成。关于其他系统的集成，这个比较细化，都是对接其他系统，缺乏通共性，暂时没想到怎么画架构图。
项目基础部分几个模块： 单项目、 多项目和 多协议。其中项目通用的包含很多设置项，比如
GET、POST请求的传参格式，通用的参数结构，公参，公共的header处理，身份验证的处理，响应初步处理（主要验证业务code和响应结构体）。还有测试数据管理，主要是测试用户、测试接口路径管理，项目关联管理、测试工具类管理（加密解密，参数验签，测试后门等等）。多协议就是指出去HTTP协议以外还需要的其他协议的功能，MySQL、Redis和Socket的部分功能，因为都不是主要协议，所以都是作为辅助测试定位去做的，除了Socket做了点项目化的尝试以外，其他都是脚本化的编写。业务模块比较简单，就是针对不同的模块设置成一个模块类，类属性，类方法（相当于一个接口封装）以及必要的工具方法，剩下的就是对不同的接口响应进行处理，比如提取必要值和进行简单业务验证功能。
测试实践我只画了一个测试流程，和测试用例的流转，这个意思可以参考之前的文章： 如何统一接口测试的功能、自动化和性能测试用例。通过编写功能用例，其中一部分可以用于自动化和性能测试，还有一部分只能用于性能测试。
测试数据构造这块写得不细，实在是情况多种多样。没法写，这个造数据的功能，主要还是依靠功能接口的封装和测试后门完成的。
这里面根据需求不同会用到
moco api和JsonPath以及贯穿全项目的消息功能，这个根据不同的具体场景各自分配。
FunTester，腾讯云社区钦定年度作者，非著名测试开发er，欢迎关注。
点击阅读原文，查看公众号历史文章
本文分享自微信公众号 - FunTester（NuclearTester）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
