背景：

1 常见的接口自动化框架只能覆盖对外接口的测试点，不能覆盖到服务交互异常情况
2 缺少基于微服务的自动化测试框架
3 被测服务涉及到三方服务或其他团队服务，排查问题沟通成本大，其他团队研发不能及时回复会导致问题阻塞

思路：

为解决以上问题，其实只要实现内部交互服务的桩就行，让开发把内部服务的 host 和 port 提取到服务启动配置项，就能实现内部服务 mock 消息；而想要实现自动化首先得在框架入口处启动服务，才能控制服务的依赖关系，接着桩服务可以用 python 的 flask 框架实现 http 服务，用 socket 模块实现 tcp/udp socket 服务。那 python 脚本怎么和这些桩进行通信交互？在桩和 python 建立一个长连接通道即可，只要桩接收到消息直接转发到 python 服务端，python 服务端想 mock 数据返回通过通道进行消息包的发送，装服务接到消息包再转成可处理的协议返回即可，整体思路看下图。

桩框架实现：

httpServerStub.py
http 服务桩模块，主要管理桩服务实例化 socket 客户端的方法以及基于 flask 框架的应用。

httpServerOperate.py
http 桩操作模块，操作方法包括 “桩 socket 客户端的启动”、“http 桩初始化”、“桩下线”、“桩 mock 消息接收”、“桩 mock 消息返回”

HttpCommon.py
支持 http 协议请求时的多线程等待

threadCount.py
校验桩服务启动的正确性

main.py
在框架执行入口定义桩启动方法、服务启动、服务启动校验、用例执行、桩下线、服务下线

测试用例：

用例脚本：

用例 2

• step1：前置，清空文件协作用户
• step2：定义接口入参信息，请求被测服务接口
• step3：接收桩服务收到的请求，并校验
• step4：等待 4s（服务超时时间定的是 3s）
• step5：定义桩的返回体
• step6：校验被测服务的返回结果

用例 3

• step1：前置，清空文件协作用户
• step2：定义接口入参信息，请求被测服务接口
• step3：接收桩服务收到的请求，并校验
• step4：定义桩的返回体，状态码为 403
• step5：校验被测服务的返回结果

框架支持的能力：

• 多个 http 桩服务启动
• 桩服务的上线、下线，可以模拟服务异常下线的场景
• 桩返回超时
• 桩服务接收到的请求定义成变量结果返回到用例层
• 用例层可以执行定义桩的结果返回
• http 协议多线程等待
• python 服务的代码覆盖率统计
• 自动化

框架待办事项：

• java 应用、go 应用的代码覆盖率统计
• socket tcp/udp 桩
• grpc 桩
• 在 testCase 层单用例执行（目前只能从 main 入口执行）

总结：

如果想实现其他协议比方说 socket、grpc，会比 http 桩更容易实现，http 没法把请求和返回独立开，而 socket 协议可以单独控制消息的 send 和 receive。不过服务端测试的核心还是测试用例，尽可能的场景覆盖，自动化的手段只是提高工作效率，晚点我也会更新服务端的测试策略。