FunTester测试项目架构图初探

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

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

FunTester测试框架架构图

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

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

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