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

[[335942]]

圖片來自 Pexels

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

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

性能測試類型

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

 

 

負載測試

負載測試用于測試應用程序在正常和峰值情況下的性能。在負載測試中，我們對應用程序性能好壞的判定依據(jù)主要源于該應用程序?qū)τ脩粽埱蟮捻憫闆r，以及它在不同負載變化下(可接受的程度內(nèi))一致響應的能力來檢測的。

負載測試中的核心關(guān)注點：

• 在應用程序出現(xiàn)異常情況前，該應用程序所能容納的最大負載量是多少?
• 在系統(tǒng)變慢或出現(xiàn)崩潰之前，數(shù)據(jù)庫所能處理的數(shù)據(jù)量有多少?
• 是否有任何與網(wǎng)絡(luò)相關(guān)的問題需要解決?

壓力測試

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

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

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

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

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

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

容量測試

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

此類測試可以視為增量式測試或穩(wěn)定性測試。在增量式測試中，數(shù)據(jù)量是逐漸增加的。

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

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

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

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

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

為了確保 Web 應用程序?qū)⒅С衷诮o定的用戶和/或事務數(shù)，且滿足性能要求，我們在測試過程中需要考慮修改處理器容量、網(wǎng)絡(luò)帶寬、內(nèi)存使用情況、磁盤容量等資源，從而滿足目標。對網(wǎng)上銀行實施容量測試就是一個典型案例。

可靠性/可恢復測試

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

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

性能測試流程

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

究其原因不外乎兩點：

• 幾乎無實戰(zhàn)經(jīng)驗
• 缺乏對性能測試的整體認知

下面將為大家系統(tǒng)性地介紹性能測試規(guī)范化流程：

性能需求收集&分析

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

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

性能測試工程師直接或間接參與客戶方針對系統(tǒng)/應用程序的性能需求調(diào)研會議，以識別和收集應用系統(tǒng)實現(xiàn)技術(shù)和業(yè)務方面的需求。

這包括獲取有關(guān)應用程序的架構(gòu)、技術(shù)和使用的數(shù)據(jù)庫、目標用戶、功能、應用程序使用情況、性能測試需求、硬件和軟件需求等方面的信息。

性能測試工具選擇

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

分別從工具的成本、應用程序使用的協(xié)議、用于構(gòu)建應用程序的技術(shù)、我們?yōu)闇y試而模擬的用戶數(shù)量等等對可用工具列表進行篩選，選取一款合適當前項目情況的性能測試工具。

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

性能測試計劃&設(shè)計

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

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

性能測試用例研發(fā)

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

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

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

④環(huán)境同步：在創(chuàng)建優(yōu)化性能測試用例腳本的同時，需要設(shè)置測試環(huán)境(軟件和硬件)，從而確保性能測試腳本在特定環(huán)境下執(zhí)行(盡可能模擬真實的線上環(huán)境)。

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

性能測試建模

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

性能測試執(zhí)行

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

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

性能測試結(jié)果分析

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

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

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

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

完整報告

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

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

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

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

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

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

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

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

①簡介

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

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

性能測試主要目的如下：

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

下圖清晰展示了性能測試/優(yōu)化過程：

 

注：如在企業(yè)內(nèi)，這里還可以附上被測應用系統(tǒng)的架構(gòu)設(shè)計圖。

②性能測試工作范疇

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

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

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

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

③性能測試方案

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

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

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

根據(jù)性能測試需求分析，通過 JMeter 創(chuàng)建測試腳本和測試場景，針對不同場景設(shè)計虛擬用戶數(shù)及虛擬用戶活動狀態(tài)，盡可能模擬真實場景。

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

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

基本負載測試：為了滿足負載測試下的業(yè)務基準，性能測試團隊將執(zhí)行一個基本負載測試，該測試將有助于識別隨著負載增加而出現(xiàn)的任何系統(tǒng)性能問題，并為下一級別的性能測試創(chuàng)建基線。

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

這有助于對單個 Java 虛擬機(JVM)進行調(diào)優(yōu)，以及對所需 JVM 總數(shù)和處理器的容量規(guī)劃。

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

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

在持久性測試期間，性能測試團隊需要監(jiān)視關(guān)鍵性能指標，例如事務響應時間，CPU，I/O，內(nèi)存等系統(tǒng)資源使用情況是否穩(wěn)定。

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

④性能測試場景

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

【場景 1】：驗證代理和客戶間的并發(fā)會話數(shù)。

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

 

【性能指標設(shè)定】

客戶端關(guān)注指標：

系統(tǒng)&網(wǎng)絡(luò)性能指標：

 

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

如下圖：

 

⑤測試數(shù)據(jù)來源

這里假定所有性能環(huán)境數(shù)據(jù)是生產(chǎn)環(huán)境數(shù)據(jù)的副本，所需的測試數(shù)據(jù)將由項目團隊統(tǒng)一提供。

⑥測試入口&出口準則

 

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

• 訪問環(huán)境中所有應用程序
• 環(huán)境準備就緒
• 性能測試數(shù)據(jù)準備就緒

⑦缺陷管理

缺陷管理如下：

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

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

 

⑧測試工具&技術(shù)

 

⑨測試執(zhí)行停滯及恢復準則

 

⑩可交付成果物

性能測試交付成果包括:

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

⑪角色&職責

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

 

⑫潛在風險及緩解計劃

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

 

⑬性能測試約定規(guī)則

性能測試約定規(guī)則如下：

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

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

總結(jié)

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

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

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

作者：羅小羅

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

編輯：陶家龍

征稿：有投稿、尋求報道意向技術(shù)人請聯(lián)絡(luò) editor@51cto.com

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】