性能測試簡介
概念:通過自動化測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。
Why
評估系統能力、識別體系中的弱點、系統調優、驗證穩定性可靠性。
性能不佳的應用通常無法實現企業預期利益，花費了大量時間和金錢，但是卻在用戶中失去了信譽。
相比功能測試和驗收測試(OAT operational acceptance testing)，性能測試容易被忽略，往往在發佈之後碰到性能和擴展性問題才意識到重要性。
Who
測試、開發、架構師、用戶等。
When
預研、單元、接口、系統、在線監控等。
最終用戶眼中的性能
性能”是用戶最終的感受。性能優異的應用在最終用戶執行某項任務時不會產生過度的延遲而引起用戶的不滿。好的應用不會在登錄時顯示空屏，不會讓用戶走神。比如偶然的用戶在購物網站上尋找和購買他們所需要的東西時，客戶中心不會收到差性能的投訴。
多數應用系統在峯值時性能表現不佳。從高層看，應用由客戶端軟件和基礎設施組成，後者包括了運行軟件所需的服務器硬件和網絡基礎設施。另外有些應用還有第3 方服務。任何一個組成部分中出現問題，整個系統的性能就將面臨災難。您可能會簡單地認爲，爲了保證應用性能，觀察應用每個部分在負載壓力下的運行狀況並且 解決所出現的問題即可。這種做法往往“太少”和“太遲”了，因此只能是治標不治本。
關鍵業績指標(KPIs key performance indicators)有服務和效率兩種。
基於服務的：衡量應用系統爲用戶服務的好壞。
- 可用性(Availability): 終端用戶可以使用的應用的總時間。可用性很重要，小小的故障也會導致大量的商務上的花費。用戶無法有效地使用該應用系統，比如應用不響應或者響應慢到無法接受
- 響應時間(response time)：一般指系統響應時間。即用戶發起請求到收到結果的時間。響應有異步和同步兩種。
基於效率的：衡量應用對基礎設施的利用。
- 吞吐量(Throughput)：應用處理速度，比如一定時間內某個頁面的點擊數。
- 利用率(Utilization)：理論資源的使用率。當1000個用戶同時在線時，應用消耗了多少網絡帶寬及在服務器內存和cpu等使用情況。
性能標準
沒有正式的行業標準，但是有許多非正式的標準，試圖對系統的性能好壞做出評價，尤其是B/S應用。比如“頁面最小刷新時間”從20秒到8秒，現在是2秒最佳。用戶和企業都希望系統能夠“即時響應”，但現在這樣的性能很難達到的。
三種性能測試
- 救火(Firefighting)，發佈前很少或從來沒有性能測試。所有性能缺陷在生產環境上發現解決。這是最不可取的，卻依然比較普遍。
- 性能驗證(performance validation)。公司爲性能測試在產品的後期安排了時間，生產環境會發現30%左右的性能bug。這個當前絕大多數公司的做法。
- 性能驅動(performance driven),生命週期中的每一階段都考慮了性能, 生產環境會發現5%左右的性能bug。
爲什麼性能如此糟糕？
- 系統設計階段缺少性能方面的考慮。
設計的時候考慮性能有望產出好性能的應用，至少也能使應用在出現意想不到的性能問題時靈活地能進行修改或重新配置。設計相關的性能問題後期才發現就很難解決，有時候甚至需要重新開發。
多數的應用基於可獨立測試的組件進行開發的，組件在單獨執行的時候性能可能都不錯，切記必須從整體來考慮。這些組件之間的交互必須高效且擴展性好，集成後纔會有好的性能。
- 直到最後一刻才進行性能測試
性能驗證模式下，性能測試直到系統發佈前纔會進行，並且很少考慮到性能測試所需的時間及失敗後所造成的後果。可能無法發現一些嚴重的性能缺陷或發現了性能問題但卻沒有時間解決。
用戶考慮。
有多少終端用戶會實際使用？
用戶位於何處？
多少用戶會同時使用？
用戶如何連接到應用？
後期有多少額外的用戶需要訪問應用？
應用的服務器數量及網絡拓撲？
將應用對網絡容量產生什麼影響？性能測試還不規範
目前性能調優的書籍很多，但是對醫生而言，最重要的是識別病情，識別性能瓶頸比解決問題有時更難。
不使用自動化的測試工具
應用程序使用技術的影響
更多詳細資料參見： 性能測試藝術
性能測試工具概覽
性能測試工具架構
- 腳本：描述用戶的活動，支持不同協議。
- 測試管理模塊: 創建並執行性能測試會話或場景。
- 負載生成器: 生成負載。
- 分析模塊: 分析數據，有些還有自動分析的專家模式。
- 其他模塊: 監控服務器和網絡性能的同時，與其他軟件集成。
選擇性能測試工具
- 協議支持
- 授權：比如最大虛擬用戶數；能支持的額外協議；附加插件集成和特定的技術棧監控，比如Oracle, Python等，)可以與APM(application performance monitoring)與CI(continuous integration)集成。
- 腳本支持：稍微複雜一點的測試就需要深入腳本。考慮腳本修改的難度；考慮測試團隊的技術水平。
- 解決方案與負載測試工具: 有些廠商只提供個負載測試工具，而有些提供性能測試解決方案。解決方案產花費更多，但通常功能更強大，可能包括自動需求管理，自動數據創建和管理，預性能 測試的應用程序調試和優化，響應時間預測和容量建模，APM提供類和方法層面的分析，集成用戶體驗（EYE）監控，管理測試結果和測試資產等。
- 外包：可以免去工具選型等。但是次數太多的成本太高。
- 其他：基於雲平臺的測試。節約硬件成本。缺點：次數太多的成本太高，性能指標監控未必方便。程序不穩定時代價很高。
- 自行開發工具
多進程、多線程、異步、multi-mechanize boom locustio等 - 協議
FTP、IMAP、HTTP 、SNMP等 - 其他工具
Fiddler MITMProxy Wireshark tcpdump postman等
工具選擇概念驗證(POC)
POC至少要有兩個用例：讀數據和寫數據。目的如下：
- 對性能測試工具是否適合目標應用進行技術評估。
- 識別腳本數據要求
- 評估腳本需要的編寫和修改時間
- 展示測試工具的容量。
有效的性能測試
考慮的因素
- 項目計劃
- 應用夠穩定
- 足夠的時間
- 代碼凍結
- 基本的非功能需求
- 設計合適的性能測試環境
- 設置現實合適的性能目標
- 確定並腳本化的關鍵use case
- 測試數據
- 負荷模型
- 精確的性能測試設計
- KPI(Key Performance Indicator)
應用夠穩定
功能要運行穩定，不能10次運行，2次失敗。避免性能測試成爲頻繁的bug修改實踐。功能等問題會掩蓋性能問題。要有嚴格的單元和功能測試保證。
衡量標準如下：
- 簡潔的數據表示：沒有比如大量圖片和冗餘會話，尤其是移動互聯網場景。
- 高效的SQL：關係數據庫基於索引，很少有慢查詢；noSQL儘量少使用連接等。
- 沒有不必要的網絡請求
- 功能穩定：比如HTTP 404，500等錯誤較少。
足夠的時間
- 準備測試環境
- 配置負載注射器
- 識別user case(數天到數週)和腳本化
- 確定和創建測試數據(數天到數週)
- 測試環境安裝配置
- 問題解決
環境
- 理論上要與生產環境完全一致，但是很多原因導致不太可能，下面列出部分原因：
- 服務器的數量和規格: 服務器內容和架構難以複製，儘量保持規格一致，以方便提供基準。
- 帶寬和網絡基礎設施：地理位置難以複製。
- 部署層次：建議完全一致。
- 數據庫大小：建議完全一致。
也有公司直接在生產環境同時部署測試環境或者直接拿生產環境做性能測試，後者注意不要影響用戶，包含數據和服務等。
環境
性能測試的環境類型有
- 生產環境非常接近的副本：通常不太現實。
- 生產環境的子集，層次一致，服務器規格一致，但是數量有所減少：建議達到的方案。
- 生產環境的子集，層次有縮減，服務器規格一致，但是數量有所減少：最常見的方案。
虛擬機
- 虛擬機管理程序層有管理開銷
- 總線和網絡的通信方式不同。前者沒有帶寬和延遲限制。在網絡跨地理位置的情況尤其需要注意。建議虛擬化與生產環境一致。特別注意不要跨層虛擬化在同一機器。
- 物理與虛擬NIC：後者的開銷更大。
雲主機
- 可以簡單理解雲計算爲商品化的虛擬主機，容易部署。
- 可以生成大量負載注射器。
- 使用次數不多便宜
- 快速
- 可擴展
- 易部署
缺點
- 不及時關閉很貴
- 有時不可靠，比如配置的機器無法啓動，IP被牆等。
負載注入容量
單機能模擬的虛擬用戶是有限的，特別注意測試機的CPU和內存等使用率不要過載，儘量使用多的機器機進行測試。注意以下幾點：
- 負載均衡：一些基於IP分配服務器。
- 用戶會話限制：比如一個IP只能一個會話。必要的時候需要使用IP欺騙。
網絡
如果需要需要從廣域網測試，考慮：1，從WAN進行性能測試；2，測試工具模擬；3，網絡模擬(比如linux的iptables和tc命令等)。
環境檢查表
- 服務器數：物理或虛擬服務器的數量。
- 負載均衡策略：負載均衡機制的類型。
- 硬件清單：CPU的類型和數目，內存，網卡的類型和數量。
- 軟件清單：標準版本的軟件清單(不包括中間件)。
- 中間件清單。
- 內部和外部鏈接
另外還需要考慮軟件安裝約束，比如安全考慮。
一致且儘早介入。需要多個部門的通力合作。
C級管理負責預算和策略決定：
•首席信息官（CIO Chief information officer）
•首席技術官（CTO Chief technology officer）
•首席財務官（CFO Chief financial officer (CFO)）
•部門負責人
操作人員
•開發人員
•測試
•架構團隊
•服務提供者（內部和外部）
•終端用戶
•IT或運維
性能目標主要包含可用性、響應時間、吞吐量、併發、網絡利用率和服務器利用率。
在性能測試中併發是同時在線的用戶。要注意併發虛擬用戶和併發實際用戶不一定是同一回事。估算時需要基於二八原理和峯值等。
務實的性能目標
吞吐量通常更適合衡量無狀態的行爲。比如瀏覽購物時通常不會登錄，看中之後纔會登錄，瀏覽購物可以認爲是無狀態的。
響應時間不要隨着併發的增加而大幅度增加，可以基於單個用戶做基準測試。
網絡利用率需要關注數據量、數據吞吐量(可能會導致吞吐量突然下降是容量問題)和數據錯誤率。
服務器利用率主要關注CPU、內存和I/O(磁盤和網絡等)
確定和腳本化關鍵業務user case
關鍵的user case一般不會超過10個， Use-Case檢查表如下：
•記錄每個步驟
•輸入數據和期望的響應
•用戶類型：新的或老用戶，超級用戶，客戶，客服等類型。
•網絡：LAN或WAN
•主動還是被動
確定和腳本化關鍵業務user case
腳本驗證：基於文檔或抓包工具或錄製工具書寫腳本，然後單用戶到多用戶調通。注意腳本不要影響到併發的執行，儘量使用不同的用戶等。
檢查點：業務較複雜時尤其重要。
是否需要登入登出：儘量符合實際情況。
共存：注意共存的應用和網絡共享
測試數據
輸入數據
- 用戶憑據：比如用戶名和密碼。
- 查找規則：通過客戶的姓名和詳細地址，發票號和產品碼甚至是通配符進行查詢。
- 相關文件：比如圖片。
目標數據：需要考慮數據容量是否符合規格的大小，數據回滾等。
會話數據：比如token。
數據安全：數據要保密，同時性能測試工具要實現與服務器端通信的加密方式。
性能測試的類型
1.pipe-clean測試。
2.容量測試(volume)。儘量接近用戶實際使用。
3.隔離測試。
4.壓力測試(stress )。退出標準：沒有更多的用戶可以登錄，響應時間難以接受，或應用程序變得不可用。包含彈力和衝擊測試等。
5.浸泡測試(soak)，又叫穩定測試。發現內存泄漏等問題。
6.冒煙測試，只測試修改的部分。
7.基準測試
pipe-clean, volume, stress和soak test通常都需要進行。
負載模型
負載模型定義了user case的負載分佈及併發和吞吐量的目標。通常先基於容量測試，再擴展到其他類型。注意測試數據、思考時間和步長的影響。比如搜索數據分類：
- 小數據模型：具體的產品名稱或ID。
- 中數據模型：局部產品名稱。
- 大數據模型: 通配符或最小的產品名稱的內容。
需要模擬真實情況下各種user case的分佈。
吞吐量模型對於已有應用可參考Google Analytics或WebTrends，新應用的需要估計。
思考時間代表着延遲和暫停。步長是循環之間的間隔。
負載注入：Big Bang、Ramp-up、Ramp-up (with step)、Ramp up (with step), ramp down (with step)、Delayed start。注意"with step"主要是爲了方便觀察。
KPI參考初級的介紹。
參考資料
- 討論qq羣144081101 591302926 567351477 釘釘免費羣21745728
- 本文最新版本地址
- 本文涉及的python測試開發庫 謝謝點贊！
- 本文相關海量書籍下載
- 本文源碼地址