之前写了一篇FunTester 测试框架架构图初探的文章，花了一张图，主要讲解了FunTester测试框架的内容，最近闲赋在家没啥事儿，也一起顺着思路花了一个FunTester 测试项目的架构图。

有了上一次的经历，对于draw.io工具的使用比较熟练了，基本一半天就画完了，感觉比较粗糙，后期继续优化，有兴趣的欢迎一起交流。

高清图：http://pic.automancloud.com/project.html

FunTester测试框架架构图

主要思路还是依据FunTester 测试框架提供的能力，先进行基础层的封装，然后功能层，然后测试层，然后再根据不同的上层建筑完成其他系统的集成。关于其他系统的集成，这个比较细化，都是对接其他系统，缺乏通共性，暂时没想到怎么画架构图。

项目基础部分几个模块：单项目、多项目和多协议。其中项目通用的包含很多设置项，比如GET、POST请求的传参格式，通用的参数结构，公参，公共的header处理，身份验证的处理，响应初步处理（主要验证业务code和响应结构体）。还有测试数据管理，主要是测试用户、测试接口路径管理，项目关联管理、测试工具类管理（加密解密，参数验签，测试后门等等）。多协议就是指出去HTTP协议以外还需要的其他协议的功能，MySQL、Redis和Socket的部分功能，因为都不是主要协议，所以都是作为辅助测试定位去做的，除了Socket做了点项目化的尝试以外，其他都是脚本化的编写。
业务模块比较简单，就是针对不同的模块设置成一个模块类，类属性，类方法（相当于一个接口封装）以及必要的工具方法，剩下的就是对不同的接口响应进行处理，比如提取必要值和进行简单业务验证功能。
测试实践我只画了一个测试流程，和测试用例的流转，这个意思可以参考之前的文章：如何统一接口测试的功能、自动化和性能测试用例。通过编写功能用例，其中一部分可以用于自动化和性能测试，还有一部分只能用于性能测试。
测试数据构造这块写得不细，实在是情况多种多样。没法写，这个造数据的功能，主要还是依靠功能接口的封装和测试后门完成的。
这里面根据需求不同会用到moco api和JsonPath以及贯穿全项目的消息功能，这个根据不同的具体场景各自分配。

FunTester，腾讯云社区钦定年度作者，非著名测试开发 er，欢迎关注。

↙↙↙阅读原文可查看相关链接，并与作者交流