聊聊性能測試開始前的準備工做

以前的博客有介紹過完整的性能測試的流程和性能測試需求分析相關的內容，然而在實際的性能測試工做中，測試開始前也有不少的工做要作。

這篇博客，就聊聊性能測試的第一步工做：獲取測試需求，到底須要哪些東西。。。

性能測試流程導圖

1、相關設計文檔

一、系統架構圖：瞭解被測系統的技術架構，包括從客戶端到DB的週轉流程、應用服務器、中間件等；

二、網絡拓撲圖：和系統架構圖相似，這個更多的是體如今不一樣層級之間的網絡拓撲關係，也能夠和系統架構圖結合在一塊兒，根據項目具體狀況而定；

三、需求說明文檔：瞭解被測系統的業務流程，不一樣模塊間的關係，便於後面的業務場景建模；

四、接口設計文檔：大多性能測試都是經過調用模塊間的API來進行模擬併發，瞭解業務模型對應的API，包括協議類型、方法、傳參類型、入參、出參等信息是很必要的；

五、數據庫表設計文檔：測試過程當中產生的數據會寫入哪一個庫哪一個表，不一樣的API參數會對哪張表甚至哪一個字段產生什麼影響，熟悉「數據流」是很必要的一件事情；

 

2、確認性能指標or目的

一、測試目的

測試目的	說明
併發測試	測試系統在必定條件下可承受的最大併發數
容量測試	測試系統在必定配置下的最大服務能力
配置測試	驗證系統在不一樣配置下的性能表現，爲性能調優和擴容提供重要參考
驗收測試	驗證被測系統是否知足實際的業務須要或者驗證系統是否具備它說宣稱的性能表現
穩定性測試	驗證系統在必定的壓力下長時間正確處理請求的能力，通常時間越長，系統穩定性越好
多節點測試	驗證系統在服務集羣下的一個負載均衡能力

二、測試指標

指標名稱	指標數值	指標說明
TPS	100	每秒事務數，很重要的一個指標，衡量系統的處理能力
RT	95%、99%、99.99%	百分比請求的響應時間，即n%之內的RT請求響應時間是多少，百分比越高，RT越低，系統越穩定
error	0.1%、0.01%	錯誤率，便可接受的請求失敗的佔比
Cache	90%、95%	緩存命中率：命中率越高，使用緩存的收益越高，系統的性能越好
CPU	75%、90%	CPU使用率，通常來講75%是一個閾值，超過85%就須要重點關注

 

3、性能測試環境

一、被測系統環境：FAT（生產環境）、UAT（驗收環境）、預發佈環境等；

二、環境類型：docker容器、虛擬機或者其餘類型；

三、web/app/service/db等服務器配置，好比nCnG；

四、配置信息

配置名稱	配置信息
JVM堆內存分配	JVM的堆配置的內存大小
最大鏈接數	中間件、DB的最大鏈接數
線程池配置	線程池數量、回收策略等
timeout	超時時間
異常/錯誤重試次數	請求異常或錯誤時的重試策略、次數

五、服務器/DB登陸帳號、密碼，服務部署路徑、日誌路徑等；

六、擋板/Mock：某些依賴關係較複雜的系統或者模塊，是否須要擋板？若是須要擋板，是來提供？

 

4、預埋數據

一、基礎數據：好比電商系統的庫存數、SKU、用戶信息等；

二、預埋/鋪底數據：根據生產實際的數據量對測試環境的DB進行數據預埋，儘可能和生產保持一致或能夠等量換算（對應的BD實例名）；

三、測試數據：測試數據如何生成？數據生成規則，好比加解密、隨機生成等；

四、垃圾數據：每輪測試產生的垃圾數據如何隔離或者清理；

五、數據脫敏：若是是在生產環境進行壓測，如何進行數據脫敏或者數據隔離防污染策略；

 

5、接口說明

被測系統業務場景對應接口協議類型，好比：

協議類型	所需提供的信息
HTTP	方法、參數類型、host、port、path、請求響應報文等
SCOKET	host、port、請求響應報文等
DUBBO	服務註冊類型（zookeeper）、版本、timeout、重試次數、最大鏈接數、同步/異步、接口名、方法、參數類型、value等

 

6、測試開始前確認

一、容器：鏡像克隆成功，服務部署完成，且完成功能性校驗；

二、壓測機：測試機準備完成，並完成性能測試環境的調試驗證；

三、工具：相關監控工具等部署設置完成，好比服務器監控工具、DB監控工具等；

四、網絡：網絡鏈接通暢（若是有防火牆策略，運維同事應在測試方案評審開始前準備完成，並告知相關人員調試驗證）；

五、數據：基礎數據、預埋數據、測試數據準備完成（正確+可用+數據量級達標）；

 

7、需求變動說明

一、涉及範圍：需求變動類型（業務場景、功能變動等）、環境交付日期、服務器地址、配置信息變動等；

二、提早說明：變動致使延期交付或提早交付的具體工時（能夠精確到半天或者小時），最晚多久，須要提早通知；

三、應對策略：針對不一樣變動類型、影響範圍、風險程度、時間等因素評估如何處理，好比：打回、需求順延排期等；

 

8、交付日期和deadline

一、交付預期時間：方便性能測試同事根據需求緊急狀況、優先級等預估工時，進行工做排期；

二、deadline：即生產發佈時間，根據交付時間和生產發佈時間，確認具體的工做安排（好比從交付到上線只有一週，如何完成任務拆解和細化，不一樣人員安排不一樣的工做，里程碑等）；

 

以上內容，僅供參考，具體的測試需求，還須要根據具體的項目類型、團隊人員構成、職責等進行合理靈活的取捨。。。