再談性能測試之需求調研
阿新 • • 發佈：2018-11-11
測試 width min 策略 占比 ron 變化 參數類型 uri
之前的博客聊聊性能測試開始前的準備工作，聊了一些關於性能測試開始前要做的準備工作。這篇博客，來談談性能測試開始前的需求調研階段，我們要做什麽，關註那些Point。。。
一、基本信息
| 信息類型 | 說明 |
| 項目名稱 | 項目歸屬的業務線，項目名稱 |
| 項目類型 | 新建、叠代、重構。。。 |
| 項目背景 | 因為什麽原因，需要進行性能測試 |
| 測試目的 | 進行性能測試的目的：容量規劃、性能驗證或者其他原因 |
| 測試範圍 | 被測系統業務模塊，屬於什麽業務，有什麽特點 |
| 裏程碑 | 設立此次性能測試的裏程碑，即不同階段的達成以什麽為結束標誌，比如：測試方案、環境準備、測試實施等 |
| 影響因素 | 要實施此次性能測試，有哪些潛在問題，影響因素 |
二、環境信息
| 信息類型 | 說明 |
| 系統架構圖/網絡拓撲圖 | 通過系統架構圖/網絡拓撲圖，可以快速直觀的了解到系統的結構，數據流 |
| 部署方式/部署層級 | 集群、分布式、微服務/web、app、db層 |
| 性能測試環境 | PAT、UAT、SIT不同環境對測試結果的影響不同 |
| 被測系統環境的軟硬件配置 | 比如服務器是幾核幾G，有多少臺；數據庫是幾核幾G，有多少臺 |
| 關鍵參數 | 線程池、最大連接數、消費者數量、內存分配等 |
| 網絡 | 負載機和被測系統的網段、防火墻策略、帶寬、CDN等 |
| 特殊因素 | 是否存在某些特殊因素，會影響測試結果 |
三、應用信息
| 信息類型 | 說明 |
| 業務模型 | 比如支付類業務、批量審核或提交、庫存業務、查詢業務等 |
| 業務場景 | 什麽時間什麽用戶做什麽操作 |
| 協議/接口 | HTTP、Socket、Dubbo。。。 |
| 連接方式 | 長連接、短連接 |
| 通信策略 | 同步、異步 |
| 變更策略 | 參數的加解密、拼接、動態變化、依賴關系等 |
四、性能指標
| 指標類型 | 說明 |
| user | 包括註冊用戶數、在線用戶數、並發用戶數等 |
| TPS |
每秒事務數，包括服務端和數據庫 |
| RT | 包括ART、%RT、MaxRT、MinRT |
| 吞吐量 | 吞吐量在一定程度上可以用來衡量系統的容量 |
| 交易量 | 日/月/某個時間段內的交易量，可更好的衡量系統的容量和存在的壓力 |
| 交易成功率 | 即事務成功率、請求成功率，根據具體需求設定閾值，一般要求99.99%甚至更細的粒度 |
| 資源使用率 | 包括CPU%、Memory%、I/O速率等 |
| 可擴展性 | 隨著並發數的上升，系統的性能表現是否會正比例線性增長 |
五、測試數據
| 數據信息 | 說明 |
| 限制條件 | 用戶操作權限、數據引用次數、數據過期設定（次數、絕對時間） |
| 數據量 | 實際生產環境的數據量為多少，在性能測試環境如何等量代換 |
| 數據類型 | 基礎數據、測試數據、特殊數據 |
| 數據特點 | 是否可以復用、是否具有唯一性、自增、加密、拼接、轉義等 |
| 準備方式 | copy真實環境數據、預埋鋪底數據、腳本脫敏生成數據 |
| 隔離方案 | 如何避免測試數據的汙染？分庫分表？環境隔離？標記區分？ |
六、配置參數
| 參數類型 | 說明 |
| 測試環境 | 性能測試環境是否和生產環境保持一致的配置？如不能，如何解決或等量代換? |
| 操作系統 | 操作系統的版本、超時設置、內存空間等 |
| 軟硬件版本 | 盡可能保證和生產環境一致的版本 |
| 中間件 | 比如JVM的內存分配/GC算法、Tomcat連接數/超時時間、MQ的消費者數量等 |
七、測試模型
| 模型~交易量 | 說明 |
| 交易占比 | 測試交易筆數占總業務量的比例（可忽略占比很少的交易數據） |
| 選取思路 | ①、選取交易量最高的時間段；②、每種交易進行單獨的數據統計 |
| 異常選擇 | ①、如果各時段的交易比例類似，則可按照生產的配比進行轉化；②、如比例差距大，則獨立統計 |
| 交易配比 | 單交易統計後，基於各交易的RT，結合並發用戶數，使總交易數達到交易占比數 |
| ThinkTime | 根據各交易類型和具體場景，選擇ThinkTime是統一設定/隨機設定/按實際場景設定 |
以上即為性能測試需求調研階段，我們要做的事情和關註的Point，僅供參考。。。
再談性能測試之需求調研