RPC框架测试详解

框架测试手册

本文档中的框架特指rpc框架，写此文档的目的是为了让测试同学

了解如何测试一个框架，测试的时候需要关注哪些方面的测试内容。

一、简单介绍

服务通讯框架(Service Communication Framework)支持跨平台具 有高并发、高性能、高可靠性,并提供异步、多协议、事件驱动的中间层服务框架。

组成模块

服务容器 :

用于宿主开发人员所开发的服务，接收和处理来自客户端 的请求。

客户端:

多种平台客户端，调用者就像在调用本地接口一样方便，同时还提供了负载均衡，容错等机制。

序列化:

提供了跨平台的二进制序列化解决方案。

通讯协议:

分为传输协议和数据协议.

传输协议用于进行数据传输，数据协议用于 请求和响应结果的内容数据。

二、测试内容

各组成模块需要测试的大致内容，下面以一个图来描述各模块需要进行测试的详细内容，并提炼出每个模块的测试思路和解决方案。

三、各模块如何测试

客户端和服务管理平台两大块内容提出测试思路和解决方案。

模块一: 序列化

1、测试整体思路

核心思想： 设计的测试case必须能够保证反序列化的结果跟序列化前的数据相同。

客户端和服务端都需要此验证逻辑。

2、测试步骤

测试分为两大步骤

第一步：序列化模块单元测试：

仅关注各种类型的数据是否在服务端和客户端都能够正确序列化和反序列化。

验证的过程，是通过在服务端和客户端打印日志，观察对比。

日志中关注的细节包括：

序列化的数据，反序列化出来是否是正确，每种类型序列化需要消耗的时间

传入优化参数optimize=true, 跟非优化进行对比，查看优化后，序列化压缩的字节大小，客户端和服务端的typeId是否相等

第二步：

将序列化模块集成到整个框架中，进行整体的集成化测试。

具体集成测试思路图如下图：

据此可以实现验证逻辑的自动化，方便后续的序列化功能的回归。

3、测试用例

模块二: 协议

因为协议是封装在底层，包含在client与server的交互中，所以在集成序列化测试的过程中，已经将协议⼀并测试了，针对协议的模块不⽤单独写测试⽤例。

模块三: manager模块

manager模块即服务管理平台模块。

配置更新的核心思想：客户端本地存储的配置信息,(包括服务配置、数据上报配置及降级配置信息)与服务管理平台上的配置保持一致。

数据上报的核心思想：对客户端的请求进行统计后上报到服务管理平台，分为正常请求量、超时请求量及异常请求量。

测试功能点如下图所示

补充说明：

1. 配置更新的主要方式有推和拉两种:

推：若服务管理平台与客户端已经建立socket，服务管理平台的更新会主动推送到客户端

拉：在以下两种情况下，客户端会主动从服务管理平台拉取配置信息

客户端本地已有配置信息，在启动时与服务管理平台的配置比对，本地配置不是最新的，则从服务管理平台拉取最新配置信息

客户端有定时刷新机制，会定时检测，若本地的配置信息与服务管理平台不一致，则拉取最新的配置

2. 数据上报的结果在服务管理平台分三个视图来看，正常、异常和超时。

3. 数据上报是按照自然时间来上报的，每分钟的第一秒进行上报。

模块四: 负载&容灾模块

1、测试内容

1.1 负载负载

服务部署在集群上，负载主要是看客户端的request是否按照约定的负载策略请求到集群的每个节点上。

1.2 容灾容灾

在服务出现异常时(包括停止服务、重启服务、网络抖动等)，检验客户端的容错能力。

补充说明：服务或方法降级后的负载，只能通过log日志来观察，在服务管理平台中，服务提供方是看不到负载情况的，只能在调用方的异常视图中可以看到。

模块五: 性能稳定性模块

1、测试指标设计和收集

主要关注四个指标：QPSCPU的使用率内存使用率(使用很少，可忽略)

负载情况指标的收集方法：top命令观察cpu的使用率服务管理平台查看QPS

2、主要的测试场景

2.1 客户端并发量增大，Socket数量增大，指标的变化情况。