JSON-RPC服务测试实战：从工具选型到自动化

1. JSON-RPC服务测试实战指南

最近在重构一个分布式系统的通信模块，把原来的HTTP接口改成了JSON-RPC协议。本以为只是换个传输格式的小改动，结果在测试环节踩了不少坑。今天就把这次JSON-RPC服务测试的经验系统梳理一下，特别是那些官方文档里不会写的实战细节。

JSON-RPC作为轻量级的远程调用协议，相比RESTful API更适合内部服务间的复杂交互。但它的测试方法和普通API测试有很大不同——不仅要验证参数和返回值，还要处理协议本身的规范校验、批量请求、错误码映射等特殊场景。下面就从环境搭建到异常处理，完整走一遍JSON-RPC服务的测试全流程。

2. 测试环境准备

2.1 测试工具选型

工欲善其事必先利其器，先对比下主流的JSON-RPC测试工具：

我最终选择Postman+curl的组合方案：

• Postman用于日常手工测试和调试
• curl命令集成到CI/CD流水线
• 压测阶段再用JMeter补充

提示：如果服务端用了自签名证书，记得在Postman设置里关闭SSL验证（Settings → General → SSL certificate verification）

2.2 请求构造要点

一个标准的JSON-RPC 2.0请求示例：

json复制{
  "jsonrpc": "2.0",
  "method": "user.getInfo",
  "params": {
    "user_id": 12345,
    "fields": ["name", "email"]
  },
  "id": "req_001"
}

关键字段说明：

• jsonrpc: 必须严格写"2.0"，这是协议版本标识
• method: 推荐使用"模块.操作"的命名约定
• params: 结构化参数比位置参数更易维护
• id: 请求唯一标识，建议前缀+序号方便追踪

3. 核心测试场景设计

3.1 基础功能验证

先测试单请求-单响应的基本流程：

bash复制# 使用curl测试示例
curl -X POST http://service:8080/rpc \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "math.add",
    "params": {"a": 5, "b": 3},
    "id": "test_001"
  }'

预期响应：

json复制{
  "jsonrpc": "2.0",
  "result": 8,
  "id": "test_001"
}

需要验证：

1. 响应头Content-Type是否为application/json
2. 响应jsonrpc字段是否为"2.0"
3. id是否与请求严格一致
4. 业务结果是否正确

3.2 批量请求测试

JSON-RPC支持批量请求，这是重点测试项：

json复制[
  {
    "jsonrpc": "2.0",
    "method": "cache.get",
    "params": {"key": "user_123"},
    "id": "batch_1"
  },
  {
    "jsonrpc": "2.0",
    "method": "cache.set",
    "params": {"key": "user_123", "value": "active"},
    "id": "batch_2"
  }
]

特别注意：

• 响应顺序必须与请求顺序一致
• 单个请求失败不应影响其他请求
• 批量上限需要性能测试（建议不超过50个）

3.3 异常场景测试

这些边界case最容易出问题：

1. 非法JSON格式

   bash复制curl -d '{"jsonrpc":"2.0"' http://service:8080/rpc
   

   应返回Parse error错误：

   json复制{
     "jsonrpc": "2.0",
     "error": {
       "code": -32700,
       "message": "Parse error"
     },
     "id": null
   }
   

2. 方法不存在

   json复制{
     "jsonrpc": "2.0",
     "method": "not.exists",
     "id": "err_001"
   }
   

   应返回Method not found（-32601）

3. 参数校验失败

   json复制{
     "jsonrpc": "2.0",
     "method": "user.delete",
     "params": {},  // 缺少必填user_id
     "id": "err_002"
   }
   

   应返回Invalid params（-32602）

4. 自动化测试实践

4.1 Postman测试脚本

在Postman的Tests标签页添加断言脚本：

javascript复制// 验证协议版本
pm.test("jsonrpc version is 2.0", function() {
    let jsonData = pm.response.json();
    pm.expect(jsonData.jsonrpc).to.eql("2.0");
});

// 验证请求ID匹配
pm.test("request ID matches", function() {
    let jsonData = pm.response.json();
    pm.expect(jsonData.id).to.eql(pm.request.body.jsonrpc.id); 
});

// 业务逻辑断言
pm.test("result is positive number", function() {
    let jsonData = pm.response.json();
    pm.expect(jsonData.result).to.be.a('number').above(0);
});

4.2 CI集成方案

GitLab CI示例配置：

yaml复制test_rpc:
  image: curlimages/curl:latest
  script:
    - |
      response=$(curl -s -o /dev/null -w "%{http_code}" \
        -H "Content-Type: application/json" \
        -d '{"jsonrpc":"2.0","method":"health.check","id":"ci_001"}' \
        http://service:8080/rpc)
      
      if [ "$response" -ne 200 ]; then
        echo "Health check failed with status $response"
        exit 1
      fi

5. 性能测试要点

5.1 JMeter配置技巧

1. HTTP Header配置：

   • 必须添加：Content-Type: application/json
   • 建议添加：Accept: application/json

2. 参数化请求：
   使用CSV Data Set Config读取测试数据：

   csv复制method,params
   user.get,{"id":1001}
   order.list,{"status":"paid"}
   

3. 断言规则：

   • 响应代码必须为200
   • 响应包含"jsonrpc":"2.0"
   • 错误率低于0.1%

5.2 监控指标

关键性能指标建议阈值：

6. 常见问题排查

6.1 错误代码速查表

6.2 日志分析技巧

1. 请求追踪：
   在服务端日志中搜索请求ID，例如：

   bash复制grep "req_001" /var/log/rpc-service.log
   

2. 慢查询分析：

   bash复制awk '$NF > 1 {print $0}' /var/log/rpc-access.log | sort -nk10
   

3. 错误聚合：

   bash复制cut -d' ' -f6 /var/log/rpc-error.log | sort | uniq -c | sort -nr
   

7. 测试经验总结

1. ID生成策略：

   • 使用UUID虽然通用但难以阅读
   • 推荐格式：[测试类型]_[序号]（如perf_001）
   • 在复杂场景下添加时间戳后缀

2. 批量请求优化：

   • 单个批量请求不超过1MB
   • 响应时间超过5秒的建议拆分
   • 重要操作避免使用批量模式

3. 版本兼容性：

   • 明确区分1.0和2.0协议
   • 在响应头添加X-JSON-RPC-Version
   • 文档中标注各方法的最低版本

4. 安全测试补充：

   • 测试注入攻击：在method字段尝试system.exec
   • 检查敏感数据是否在错误信息中泄露
   • 验证HTTPS强制实施情况

这次测试过程中最大的教训是：JSON-RPC协议虽然简单，但规范细节很多。特别是错误处理部分，我们最初没有严格遵循标准错误码，导致客户端解析混乱。后来通过建立错误码映射表，才解决了跨团队协作的问题。建议在项目初期就制定好错误处理规范，这能节省大量后期调试时间。