前段时间做的那个自动化测试工具,现在已经用了有一段时间了,虽然都是利用空余时间开发的,还有很多不够完美、可以优化的地方,但至少目前使用起来已经可以满足我们的基本需求了。今天,花点时间把整个工具的框架梳理了一下,也算是为后续的维护、优化做一下前期准备。
工具的整体架构其实很简单,划分如下几个模块:
- ‘executor’:创建发送线程‘sender’和接收线程‘receiver’。
- ‘sender’:循环读取测试用例(多个测试用例文件、每个文件包含多个测试用例),向‘核心服务’发送请求消息。
- ‘receiver’:接收‘核心服务’的应答消息,验证消息内容是否符合预期。
- ‘exec_info’:存储中间数据,包括预期收到的应答消息内容等。
整个测试工具依赖的测试用例从业务角度划分为多个文件,每个文件包含了相应业务的不同测试用例。单个测试用例文件的结构如下:
{ ‘case_1’ : [ { //transaction_1 ‘send’ : {}, ‘recv’ : [ {“message_1”}, {“message_2”} …… ] }, { //transaction_2 }, …… ], ‘case_2’ : [……], …… } |
单个case由多个‘transaction’组成,每个‘transaction’代表一次与‘核心服务’的消息交互,其中,‘send’为由‘sender’发送给‘核心服务’的请求消息,‘recv’为期望‘核心服务’收到‘sender’发送的请求报文后应答的消息内容(可能为多个);‘receiver’在收到‘核心服务’返回的应答报文之后,即比对‘核心服务’返回的应答报文内容与case文件中‘recv’中的相应内容是否一致:每条应答报文的内容都与case文件中的期望内容一致,才认定case测试通过;否则,case认定失败。