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數量增大，指標的變化情況。
TAG:bingoTest |