【51CTO.com原創稿件】性能測試旨在檢查應用程序或軟件在特定負載下工作時的響應性和穩定性，從而檢測應用程序/軟件在響應速度、可擴展性和穩定性方面是否達到預期的要求。

[[335942]]

圖片來自 Pexels

簡而言之，性能測試目標就是為了識別并消除應用程序中的性能瓶頸。

本文將為大家詳細介紹性能測試主要類型、性能測試流程規劃以及面對項目如何開展性能測試策略，如何設計不同場景下的性能測試用例，助你從此遠離性能測試的盲區。

性能測試類型

性能測試主要有[負載測試]，[壓力測試]，[容量測試]和[可靠性/可恢復性測試]這四大主要類型，下面將對這四大主流性能測試類別逐一展開介紹：

 

 

負載測試

負載測試用于測試應用程序在正常和峰值情況下的性能。在負載測試中，我們對應用程序性能好壞的判定依據主要源于該應用程序對用戶請求的響應情況，以及它在不同負載變化下(可接受的程度內)一致響應的能力來檢測的。

負載測試中的核心關注點：

• 在應用程序出現異常情況前，該應用程序所能容納的最大負載量是多少?
• 在系統變慢或出現崩潰之前，數據庫所能處理的數據量有多少?
• 是否有任何與網絡相關的問題需要解決?

壓力測試

壓力測試旨在尋找破壞系統的方法。該測試同時還能為我們找到系統可以承受的最大負載范圍。

通常，壓力測試采用增量方法，通過逐步增加負載來觀察系統各項性能指標的變化情況。

首先，我們可以從應用程序已經測試過的負載開始(例如當前用戶數 100 個);然后慢慢地增加更多的負載來給系統增加壓力(例如從 100 個用戶數逐步增加到 10000)。

當我們發現服務器沒有響應請求的那個點開始，這個點就被認為是斷點(在一些性能測試報告圖表中，往往也視為性能拐點)。

在壓力測試過程中，我們需要關注的問題有：

• 系統在崩潰前能承受的最大負載是多少?
• 在實施壓力測試過程中，系統是如何崩潰的?系統能否在崩潰后自行恢復?
• 被測系統/應用程序在處理異常負載時，有哪幾種中斷方式?

容量測試

容量測試是為了驗證應用程序的性能不受應用程序正在處理的數據量的影響。為了執行容量測試，需要向數據庫中輸入大量數據。

此類測試可以視為增量式測試或穩定性測試。在增量式測試中，數據量是逐漸增加的。

通常，隨著應用程序的使用，數據庫容量會隨數據而增長，例如一個新建立的教育網站，最初只有少量的數據需要存儲，但在 5-10 年后，該網站數據庫中的數據存儲就已有相當規模了。

因此針對數據量逐步遞增至規模龐大的情況下，對應用程序進行容量測試很有必要。

此外容量測試還有另一層含義：應用程序是否能夠在正常及峰值負載條件下滿足當前正在處理的業務量需求?

這通常是為了系統將來可能面臨的情況而進行的可預見性測試，需要納入考察的核心點有：

• 應用程序能夠支持未來的負載嗎?
• 環境是否能夠承受即將增加的負載?
• 要使環境具備足夠的能力，需要哪些額外的資源?

為了確保 Web 應用程序將支持在給定的用戶和/或事務數，且滿足性能要求，我們在測試過程中需要考慮修改處理器容量、網絡帶寬、內存使用情況、磁盤容量等資源，從而滿足目標。對網上銀行實施容量測試就是一個典型案例。

可靠性/可恢復測試

可靠性測試或恢復測試用于驗證應用程序在出現故障或異常行為后，是否能夠恢復到正常狀態，以及恢復階段需要經過多長時間。

例如在某線交易站點出現故障，致使用戶不能在一天的某個點(高峰時間)買賣股票，但在一兩個小時后用戶能夠進行在線股票交易，我們就可以說該應用程序是可靠的，即有能力從異常行為中自行恢復。

性能測試流程

大部分測試工程師們在面對功能測試進展規劃時游刃有余，而當被問起如何開展性能測試時，往往陷入沉默。

究其原因不外乎兩點：

• 幾乎無實戰經驗
• 缺乏對性能測試的整體認知

下面將為大家系統性地介紹性能測試規范化流程：

性能需求收集&分析

性能需求的收集與分析至關重要，這直接影響到后續的性能測試活動是否能有效開展。

對于有性能測試需求的項目，企業內部通常都會有專職的性能測試工程師，或者性能測試團隊(即便人數不多，亦或是臨時組建)。

性能測試工程師直接或間接參與客戶方針對系統/應用程序的性能需求調研會議，以識別和收集應用系統實現技術和業務方面的需求。

這包括獲取有關應用程序的架構、技術和使用的數據庫、目標用戶、功能、應用程序使用情況、性能測試需求、硬件和軟件需求等方面的信息。

性能測試工具選擇

一旦確認了性能測試需求，接下來就到了性能測試工具選取的環節，如果之前沒有類似的經驗，企業也沒有硬性規定必須使用的工具，那么在這個節點上，我們可以將可用工具逐一羅列。

分別從工具的成本、應用程序使用的協議、用于構建應用程序的技術、我們為測試而模擬的用戶數量等等對可用工具列表進行篩選，選取一款合適當前項目情況的性能測試工具。

選定測試工具后，我們需要為關鍵業務創建腳本，并在 10-15 個虛擬用戶中執行，這就是所謂的(POC—— Proof Of Concept，這是在有限范疇內，對用戶實時活動的一種演示)。

性能測試計劃&設計

根據第一個階段收集的尋求信息，我們需要對性能測試進行整體計劃和設計。測試計劃旨在明確性能測試該如何進行，即性能測試環境、工作負載場景的設計、相關硬件配置等等。

這個階段的輸入是測試需求分析，輸出是測試策略文檔(包含了整個性能測試計劃，設計)，關于測試策略文檔，在下文中將會以實例呈現。

性能測試用例研發

①基于 POC 的測試用例研發：根據上述測試計劃中確定的測試范疇及核心業務功能，開始著手設計編寫性能測試用例;這些初始的測試用例通常是在 POC 期間基于所選的性能測試工具來記錄被測試業務的步驟。

②基于 POC 的測試用例評審：性能測試用例的評審最好能將客戶代表納入以獲得他們的認可，確保被測業務每個步驟的準確性。

③測試用例優化：基于 POC 的測試用例一旦通過評審，我們就可以逐步優化測試用例，例如參數化，等待，集合點等的設置。

④環境同步：在創建優化性能測試用例腳本的同時，需要設置測試環境(軟件和硬件)，從而確保性能測試腳本在特定環境下執行(盡可能模擬真實的線上環境)。

⑤真實用戶 VS 虛擬用戶：如果性能測試在真實的客戶環境下執行，性能團隊還需要考慮如何避免實時用戶及虛擬用戶同時在線的情況，一般而言這類情況可以選擇避開實時用戶大量在線且活躍度相當高的情況。

性能測試建模

為測試執行創建性能負載場景模型， 該階段主要目的是驗證給定的性能指標(來自性能需求)在測試期間是否達到。

性能測試執行

在指定的場景下執行性能測試腳本，性能測試場景是根據上述負載模型設計的，測試執行通過虛擬用戶數遞增模式進行。

例如，如果用戶的最大數量是 100，那么場景首先會運行 10、25、50 個用戶，以此類推，最終會運行 100 個用戶。

性能測試結果分析

測試結果是性能測試人員最重要的交付內容，也是可以證明 ROI(投資回報率)以及性能測試工作真正體現價值的地方。

由于性能測試通常需要進行多次執行才能得出正確的結論，無論通過工具自動生成還是自己匯總測試結果。

有效的性能測試結果分析需要注意這幾點：

• 分析并記錄測試失敗的原因。
• 與前一次測試執行相比，應用程序的性能是否有變化。
• 為了執行性能測試用例，從應用程序構建到測試環境都做過哪些設置更改。
• 對每個性能場景執行的測試用例，及時進行性能測試結果分析，避免最終呈現完整性能測試報告時，出現任何數據指標的遺漏。
• 在總結中需要說明每場測試的目的、對應的虛擬用戶數、測試持續時間、響應時間、吞吐量、不同負載情況下性能指標對比圖、測試過程中出現的錯誤，以及后續改進的建議。

完整報告

完整的性能測試報告以簡潔為主，不需要任何推導，開發團隊需要更多關于分析、比較結果的信息，以及如何獲得結果的細節。

性能測試計劃/策略編寫 Demo

現在我們以一款實時消息傳遞應用程序為例，編寫性能測試策略。

由于用戶對于不同產品的性能需求不盡一致，這里僅以 Demo 呈現性能測試策略編寫的完整過程，大家在工作中可適當對 Demo 模板進行裁剪，以滿足自己當前項目所需。

關于 XXX 在線聊天應用程序：假設這是當前客戶公司內部使用的聊天工作平臺，這個聊天應用程序基于 XMPP 協議支持發送和接收即時消息。

此外該平臺功能進行了一些增強，如遠程 PC 控制、PC 診斷、修復工具、在線聊天等。

對于這個應用程序，我們假設項目團隊已經決定使用 JMeter 進行性能測試，使用 JIRA 進行缺陷跟蹤。

性能測試策略文檔的第一頁應該包含文檔的標題和公司的版權;第二頁應該包含文檔控制，包括文檔版本歷史、審閱者和審批者列表和貢獻者列表;第三頁應包含目錄，其中涉及以下主題：

①簡介

本文檔目的旨在說明如何在 XXX 聊天應用程序上，基于當前及未來狀態進行性能測試。

XXX 聊天應用程序是一個用于內部遠程支持的工作平臺，具有在線聊天、客戶識別、遠程 PC 控制、PC 診斷和修復工具等功能。

性能測試主要目的如下：

• 確保當前聊天應用程序的任何更新符合規范的服務級別協議。
• 確保應用程序的性能、可用性和穩定性不會因為新功能的添加而受到影響。
• 在持續增加負載的情況下，事務響應時間保持在可接受的范圍內。
• 在不斷增加負載的情況下，JVM 始終顯示穩定的內存使用情況。

下圖清晰展示了性能測試/優化過程：

 

注：如在企業內，這里還可以附上被測應用系統的架構設計圖。

②性能測試工作范疇

XXX 聊天應用程序性能測試工作范疇如下(In Scope)：

• 通過對系統詳細調研，獲取關鍵事務處理節點，構建負載分配。
• 確定性能測試的關鍵場景。
• 使用前一個版本的結果作為未來版本的基線。
• 確認其他用于分布式壓測的代理機性能測試環境，以及使用的性能測試工具。
• 使用 JMeter 模擬各種峰值負載，并為負載場景準備性能測試腳本。
• 為服務器設置性能指標監控，以便在測試執行階段識別性能瓶頸。
• 發布性能測試結果。
• 與項目干系人協作溝通，確定可行的調優方案，針對已識別的性能問題給出解決方案。
• 為該產品將來版本確定性能需求基線。

以下任務不在此次性能測試工作范疇中(Out of Scope)：

• 功能測試，UAT，系統測試和安全測試;對任何第三方接口進行性能測試/監視。
• 性能調優;(大多數時候調優是由不同的團隊完成的，如果團隊中有性能工程師來調優系統，可以將其這部分工作添加到 In Scope 中)。
• 安全/滲透測試/白盒測試。
• 性能測試的數據生成。
• 非功能測試(例如，故障轉移、災難恢復、備份、可用性)，而不是性能測試。
• 第三方應用程序性能測試和調優。
• 從性能團隊的角度來看，應用程序代碼更改，優化供應商支持的產品/服務器配置等都超出范圍。
• 基礎設施支持/構建部署/環境準備/數據庫恢復/網絡支持等。

③性能測試方案

XXX 聊天應用程序的性能測試將使用 JMeter 來進行，結合自定義編寫的 XMPP 插件，這些插件通過 Smack 庫實現 XMPP 連接。

這些庫用來創建連接、實現用戶登錄并向 XMPP 服務器發送聊天消息。將這些庫打包進成一個 Jar 文件，然后部署到 JMeter 中，并根據測試場景進行設計。

JMeter 工作臺即 JMeter 服務器，安裝在本地機器上，JMeter 工作臺通過負載生成器產生所需的負載，向聊天服務器所在系統發出請求，與此同時 JMeter 工作臺負責監視聊天服務器所在系統的行為。

根據性能測試需求分析，通過 JMeter 創建測試腳本和測試場景，針對不同場景設計虛擬用戶數及虛擬用戶活動狀態，盡可能模擬真實場景。

將每個測試場景分解并從以下幾個方面進行檢測：

基線測試：1 個虛擬用戶數+多個迭代運行每個場景，以確定應用程序性能是否滿足業務服務水平。

基本負載測試：為了滿足負載測試下的業務基準，性能測試團隊將執行一個基本負載測試，該測試將有助于識別隨著負載增加而出現的任何系統性能問題，并為下一級別的性能測試創建基線。

峰值負載/可伸縮性測試：性能測試團隊針對不斷增加虛擬用戶數進行多次測試，以滿足預期負載，同時檢測應用程序性能，建立性能曲線，確定當前應用程序部署是否能夠支持峰值用戶負載下的服務水平協議。

這有助于對單個 Java 虛擬機(JVM)進行調優，以及對所需 JVM 總數和處理器的容量規劃。

通過將虛擬用戶數的值增加到峰值容量的 50%，75%，100% 和 125% 來進行峰值負載測試。

持久性測試/穩定性測試：性能測試團隊基于不同時長(8 小時/16 小時/24 小時)持續運行指定的測試，以識別隨著時間推移所產生的內存泄漏及其他性能問題，同時檢驗整體系統的穩定性。

在持久性測試期間，性能測試團隊需要監視關鍵性能指標，例如事務響應時間，CPU，I/O，內存等系統資源使用情況是否穩定。

假定性能測試環境是生產環境的一個副本，測試將在增量負載下運行，以確定應用程序在那種負載情況下未達到性能要求，或出現異常行為。

④性能測試場景

注：企業中所有的測試場景可以集中編寫在 Excel 文檔里，這里僅以一個測試場景為例。

【場景 1】：驗證代理和客戶間的并發會話數。

【測試方案】：下表列出了不同性能測試方案及其對應的測試目標。

 

【性能指標設定】

客戶端關注指標：

系統&網絡性能指標：

 

【性能測試階段活動及對應輸出】

如下圖：

 

⑤測試數據來源

這里假定所有性能環境數據是生產環境數據的副本，所需的測試數據將由項目團隊統一提供。

⑥測試入口&出口準則

 

測試入口&出口準則如上圖：

• 訪問環境中所有應用程序
• 環境準備就緒
• 性能測試數據準備就緒

⑦缺陷管理

缺陷管理如下：

• 本項目將使用 JIRA 缺陷管理模塊對缺陷進行記錄和跟蹤直至關閉。
• 在測試執行階段發現的缺陷將被記錄在 JIRA 中，這些缺陷將由開發團隊根據以下嚴重性級別進行修復。
• 缺陷審查會議將提上每日工作日程，參與者包括測試、開發、質量分析師和業務團隊。
• 隨著項目發布上線日期推進，修復缺陷的標準將變得更加嚴格，因此在每日缺陷評審會議上，需要發布缺陷修復標準的指導策略。

缺陷嚴重級別定義，如下圖：

 

⑧測試工具&技術

 

⑨測試執行停滯及恢復準則

 

⑩可交付成果物

性能測試交付成果包括:

• 性能測試策略
• 性能需求文檔
• 性能測試場景文檔
• 性能測試腳本
• 性能測試結果

⑪角色&職責

下圖表格中列出不同角色及其對應的職責：

 

⑫潛在風險及緩解計劃

下圖表格中列出潛在風險及緩解計劃：

 

⑬性能測試約定規則

性能測試約定規則如下：

• 性能測試環境是真實產品環境的復制(即硬件、軟件、接口、集成層等與真實產品保持一致性)。
• 性能腳本將根據使用率高的關鍵業務流程來設計。
• 在性能測試開始之前，必須解決所有基礎設施問題，此后所做的任何系統配置更改都將導致無效的測試結果。
• 性能測試執行前提：必須確保應用程序是穩定的，可以在性能測試環境中使用。
• 硬件和軟件資源(如用戶產生負載的工具、控制器/代理機器)準備就緒。
• 性能測試范圍的任何變更都必須經由變更控制流程， 同時性能測試團隊將對變更引起的時間/資源影響做出評估。
• 啟用應用程序跟蹤日志。

到此我們就完成了聊天應用程序性能測試計劃的編寫，在真實企業項目中，大家可以基于實際情況對文檔內容自行裁剪。

總結

不難發現要成功完成一個性能測試項目，我們需要確保性能測試計劃階段各方面的準確性。

即計劃、基于測試需求分析的用例開發、場景設計、測試執行和結果分析，這些關鍵點都必須按照正確的方式進行，加上合理的風險預估及緩解策略。

希望通過本篇分享，能夠豐富你在性能測試領域的認知及實踐，同時學會如何編寫一份帶有詳細示例的性能測試計劃文檔，為后續性能測試活動的開展奠定良好的基礎。

作者：羅小羅

簡介：英國 TOP10 計算機專業，計算機科學與技術碩士，先后就職于匯豐，JPMorgan，HP，交行，阿里等國內外知名企業。涉及項目領域主要有：互聯網金融，電商，教育，醫療等。現任就職于某世界 500 強公司，擔任測試開發團隊負責人，帶領團隊構建并持續優化自動化測試框架，研發自動化測試輔助類工具;擅長領域：單元/接口/性能/安全/自動化測試/CD/CI/DevOps;個人持續研究領域：自動化測試模型/數據分析/算法/機器學習等。

編輯：陶家龍

征稿：有投稿、尋求報道意向技術人請聯絡 editor@51cto.com

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】