【JSON-RPC远程过程调用组件库】测试报告

RPC 框架测试报告

一、项目背景

本项目是一个基于 C++ 实现的轻量级 RPC（远程过程调用）框架，旨在解决分布式系统中服务间通信的复杂性。框架提供三大核心能力：基础 RPC 远程调用（同步/异步/回调三种模式）、基于注册中心的服务发现（支持服务注册、发现、上线/下线通知）、主题发布订阅（1:N 消息推送）。底层基于 Muduo 高性能网络库，自定义 TLV 应用层协议解决 TCP 粘包问题，使用 JSON 作为序列化格式。项目为学习型框架，核心价值在于从零理解 RPC 框架的协议编解码、请求路由分发、服务发现机制和发布订阅设计。

二、项目简介

本 RPC 框架包含以下核心功能模块：

• 基础 RPC 模块：客户端通过 TCP 连接直连服务端，发送 JSON 请求调用注册的远程方法（如 Add），支持同步阻塞、异步 Future、回调三种调用模式。服务端通过 RpcRouter 进行方法路由、参数类型校验和回调执行。

• 服务注册与发现模块：RegistryServer 作为注册中心，管理服务提供者的注册/注销，维护方法与主机列表的映射。客户端通过 Discoverer 进行服务发现，支持本地缓存和上线/下线通知推送。

• 发布订阅模块：TopicServer 管理主题的创建/删除/订阅/取消/发布。发布者发布消息后，服务端通过 Topic::pushMessage 遍历订阅者集合并主动推送消息（1:N 推模式）。

• 协议层：自定义 LVProtocol 二进制协议，格式为| 4B len | 4B mtype | 4B idLen | id 字符串 | JSON body |，所有整数字段使用网络字节序。

三、测试计划

3.1 测试策略

采用黑盒集成测试策略。测试客户端基于 Python 实现，完全独立于 C++ 框架代码，通过 TCP 套接字直接构造 LVProtocol 二进制数据包与服务端交互。测试覆盖三个核心模块的 Happy Path、异常边界、并发场景和性能压测。

3.2 测试环境

3.3 提测方式

分模块独立测试：基础 RPC → 发布订阅 → 服务发现 → 异常边界 → 性能压测。各模块用例独立，最后执行全量回归确保无兼容性问题。

四、测试工具

五、测试类型与覆盖情况

六、功能测试

6.1 基础 RPC 模块

测试结果：9/9 全部通过，零失败。

TC-RPC-001: 正常RPC调用 Add(11,22) → 33

{"mtype":3,"mtype_name":"RSP_R","rcode":0,"body":{"rcode":0,"result":33}}

来源:test/log/TC-RPC-001-20260510.txt

TC-RPC-004: 未知方法 Multiply → rcode=5 (NOT_FOUND_SERVICE)

{"mtype":3,"mtype_name":"RSP_R","rcode":5,"body":{"rcode":5,"result":null}}

来源:test/log/TC-RPC-004-20260510.txt

6.2 发布订阅模块

测试结果：11/11 全部通过，零失败。

TC-PUB-004: 发布消息 → 订阅者接收推送

发布者发布 “hello world” 到 “news” 主题 → 发布者收到 rcode=0，订阅者收到 REQ_TOPIC 推送：

{"publish_response":{"mtype":4,"mtype_name":"RSP_TOPIC","rcode":0},"push_message":{"mtype":1,"body":{"optye":4,"topic_key":"news","topic_msg":"hello world"}}}

来源:test/log/TC-PUB-004-20260510.txt

TC-PUB-011: 非法 optype=99 → rcode=6 (INVALID_OPTYPE)

{"mtype":4,"mtype_name":"RSP_TOPIC","rcode":6,"body":{"rcode":6}}

来源:test/log/TC-PUB-011-20260510.txt

6.3 服务发现模块

测试结果：11/11 全部通过，零失败。

TC-SD-010: 端到端全流程 — 服务发现 → 直连 RPC → Add(11,22)=33

{"discovery":{"mtype":5,"mtype_name":"RSP_SERVICE","rcode":0,"body":{"host":[{"host_ip":"127.0.0.1","host_port":9090}],"method":"Add","optye":1,"rcode":0}},"rpc_result":{"mtype":3,"mtype_name":"RSP_R","rcode":0,"body":{"rcode":0,"result":33}}}

来源:test/log/TC-SD-010-20260510.txt

6.4 异常边界测试

测试结果：4/4 全部通过，零失败。

TC-EDGE-002: 超大 body >64KB → 触发 maxDataSize 保护

连接被服务端关闭 (maxDataSize 保护触发)，符合预期

来源:test/log/TC-EDGE-002-20260510.txt

七、自动化测试

7.1 测试脚本清单

7.2 核心测试代码

LVProtocol 协议封包（test/protocol.py）：

importstructdefpack(mtype:int,msg_id:str,body:str)->bytes:"""按 LVProtocol 格式打包: | len(4B) | mtype(4B) | idLen(4B) | id | body |"""id_bytes=msg_id.encode("utf-8")body_bytes=body.encode("utf-8")length=4+4+len(id_bytes)+len(body_bytes)header=struct.pack("!iii",length,mtype,len(id_bytes))returnheader+id_bytes+body_bytesdefunpack_first(data:bytes)->tuple:"""解出第一条完整消息，返回 (mtype, msg_id, body_str, total_msg_len)"""iflen(data)<12:returnNonelength,mtype,id_len=struct.unpack("!iii",data[:12])total_msg_len=4+lengthiflen(data)<total_msg_len:returnNonemsg_id=data[12:12+id_len].decode("utf-8")body_len=length-4-4-id_len body=data[12+id_len:12+id_len+body_len].decode("utf-8")return(mtype,msg_id,body,total_msg_len)

RPC 调用封装：

defrpc_request(method:str,params:dict,msg_id:str=None)->bytes:ifmsg_idisNone:msg_id=str(uuid.uuid4())body=json.dumps({"method":method,"parameters":params})returnpack(0,msg_id,body)# MType.REQ_R = 0

连接池长连接压测（test/test_performance.py核心片段）：

defworker_rpc(task_id:int):conn=socket.socket(socket.AF_INET,socket.SOCK_STREAM)conn.connect((HOST,RPC_PORT))recv_buf=b""whileTrue:idx=get_next_index()start=time.perf_counter()conn.sendall(p.rpc_request("Add",{"num1":task_id*100+idx,"num2":idx}))whileTrue:r=p.unpack_first(recv_buf)ifrisnotNone:recv_buf=recv_buf[r[3]:]record_latency(idx,time.perf_counter()-start)breakrecv_buf+=conn.recv(4096)conn.close()

八、性能测试

8.1 测试方案

采用递增压力模型，分 5 档从 10 线程逐步提升至 200 线程，总请求数从 1000 递增至 10000。前 2 档使用短连接（每次请求新建 TCP），后 3 档使用连接池长连接复用。覆盖三个场景：

8.2 性能测试结果汇总

基础 RPC — Add 方法递增压力：

关键发现：

• 引入连接池后，同等 100 线程下 P50 从 232ms 降至 87.6ms（降幅 62%），吞吐量从 209.5 升至 327.9 req/s（升幅 57%）
• 吞吐量天花板约 320 req/s，受限于公网延迟（~40ms RTT）+ Python GIL 客户端调度开销
• 5 档递增压力、累计 24,000 次请求，零错误
• 服务端 CPU 使用率始终低于 10%，框架自身无性能瓶颈

三场景对比（10线程基线）：

服务发现最快（纯内存查表），发布订阅最慢（每次需 CREATE + PUBLISH 两次往返）。

九、项目测试 Bug 简述

9.1 Bug 优先级统计

本次测试共发现0 个 Bug。

• P0（崩溃级）：0 个
• P1（严重级）：0 个
• P2/P3（一般/轻微级）：0 个

9.2 Bug 详情列表

无。

十、遗留问题

本次测试未发现功能或性能层面的 Bug。以下为项目已知的架构层面待改进项（非本次测试发现的缺陷，而是框架设计阶段的已知局限）：

十一、测试结论

整体测试结果：本次项目测试通过。三大核心模块（基础RPC、发布订阅、服务发现）共 35 个功能 + 异常 + 边界用例全部通过，零失败。性能压测 5 档累计 24,000 次请求零错误，框架稳定可靠。

耗时统计：项目测试耗时约 2 小时（含功能测试 31 用例、异常边界 4 用例、性能压测 3 场景 5 档）。

项目补充信息：

测试总结与优化建议：

1. 后续可补充 WSL/Linux 本地压测，消除公网延迟对性能数据的干扰，获取更准确的服务端吞吐量上限
2. 可增加 JMeter 集成，利用其图形化报告和分布式压测能力
3. 异常测试可进一步覆盖断网重连、服务端 OOM、TCP 半开连接等场景
4. 建议对性能测试中 P95/P99 延迟偏高的问题做 profiling，定位是客户端 Python GIL 还是服务端 EventLoop 排队

本报告部分内容由 AI 辅助生成。测试数据均来源于实际执行结果，日志文件存放于Auto_test/test/log/目录。