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

[[335942]]

圖片來(lái)自 Pexels

簡(jiǎn)而言之，性能測(cè)試目標(biāo)就是為了識(shí)別并消除應(yīng)用程序中的性能瓶頸。

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

性能測(cè)試類型

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

 

 

負(fù)載測(cè)試

負(fù)載測(cè)試用于測(cè)試應(yīng)用程序在正常和峰值情況下的性能。在負(fù)載測(cè)試中，我們對(duì)應(yīng)用程序性能好壞的判定依據(jù)主要源于該應(yīng)用程序?qū)τ脩粽?qǐng)求的響應(yīng)情況，以及它在不同負(fù)載變化下(可接受的程度內(nèi))一致響應(yīng)的能力來(lái)檢測(cè)的。

負(fù)載測(cè)試中的核心關(guān)注點(diǎn)：

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

壓力測(cè)試

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

通常，壓力測(cè)試采用增量方法，通過逐步增加負(fù)載來(lái)觀察系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。

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

當(dāng)我們發(fā)現(xiàn)服務(wù)器沒有響應(yīng)請(qǐng)求的那個(gè)點(diǎn)開始，這個(gè)點(diǎn)就被認(rèn)為是斷點(diǎn)(在一些性能測(cè)試報(bào)告圖表中，往往也視為性能拐點(diǎn))。

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

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

容量測(cè)試

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

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

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

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

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

這通常是為了系統(tǒng)將來(lái)可能面臨的情況而進(jìn)行的可預(yù)見性測(cè)試，需要納入考察的核心點(diǎn)有：

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

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

可靠性/可恢復(fù)測(cè)試

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

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

性能測(cè)試流程

大部分測(cè)試工程師們?cè)诿鎸?duì)功能測(cè)試進(jìn)展規(guī)劃時(shí)游刃有余，而當(dāng)被問起如何開展性能測(cè)試時(shí)，往往陷入沉默。

究其原因不外乎兩點(diǎn)：

• 幾乎無(wú)實(shí)戰(zhàn)經(jīng)驗(yàn)
• 缺乏對(duì)性能測(cè)試的整體認(rèn)知

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

性能需求收集&分析

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

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

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

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

性能測(cè)試工具選擇

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

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

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

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

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

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

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

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

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

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

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

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

性能測(cè)試建模

為測(cè)試執(zhí)行創(chuàng)建性能負(fù)載場(chǎng)景模型， 該階段主要目的是驗(yàn)證給定的性能指標(biāo)(來(lái)自性能需求)在測(cè)試期間是否達(dá)到。

性能測(cè)試執(zhí)行

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

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

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

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

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

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

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

完整報(bào)告

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

性能測(cè)試計(jì)劃/策略編寫 Demo

現(xiàn)在我們以一款實(shí)時(shí)消息傳遞應(yīng)用程序?yàn)槔帉懶阅軠y(cè)試策略。

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

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

此外該平臺(tái)功能進(jìn)行了一些增強(qiáng)，如遠(yuǎn)程 PC 控制、PC 診斷、修復(fù)工具、在線聊天等。

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

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

①簡(jiǎn)介

本文檔目的旨在說明如何在 XXX 聊天應(yīng)用程序上，基于當(dāng)前及未來(lái)狀態(tài)進(jìn)行性能測(cè)試。

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

性能測(cè)試主要目的如下：

• 確保當(dāng)前聊天應(yīng)用程序的任何更新符合規(guī)范的服務(wù)級(jí)別協(xié)議。
• 確保應(yīng)用程序的性能、可用性和穩(wěn)定性不會(huì)因?yàn)樾鹿δ艿奶砑佣艿接绊憽?/li>
• 在持續(xù)增加負(fù)載的情況下，事務(wù)響應(yīng)時(shí)間保持在可接受的范圍內(nèi)。
• 在不斷增加負(fù)載的情況下，JVM 始終顯示穩(wěn)定的內(nèi)存使用情況。

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

 

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

②性能測(cè)試工作范疇

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

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

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

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

③性能測(cè)試方案

XXX 聊天應(yīng)用程序的性能測(cè)試將使用 JMeter 來(lái)進(jìn)行，結(jié)合自定義編寫的 XMPP 插件，這些插件通過 Smack 庫(kù)實(shí)現(xiàn) XMPP 連接。

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

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

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

將每個(gè)測(cè)試場(chǎng)景分解并從以下幾個(gè)方面進(jìn)行檢測(cè)：

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

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

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

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

通過將虛擬用戶數(shù)的值增加到峰值容量的 50%，75%，100% 和 125% 來(lái)進(jìn)行峰值負(fù)載測(cè)試。

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

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

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

④性能測(cè)試場(chǎng)景

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

【場(chǎng)景 1】：驗(yàn)證代理和客戶間的并發(fā)會(huì)話數(shù)。

【測(cè)試方案】：下表列出了不同性能測(cè)試方案及其對(duì)應(yīng)的測(cè)試目標(biāo)。

 

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

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

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

 

【性能測(cè)試階段活動(dòng)及對(duì)應(yīng)輸出】

如下圖：

 

⑤測(cè)試數(shù)據(jù)來(lái)源

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

⑥測(cè)試入口&出口準(zhǔn)則

 

測(cè)試入口&出口準(zhǔn)則如上圖：

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

⑦缺陷管理

缺陷管理如下：

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

缺陷嚴(yán)重級(jí)別定義，如下圖：

 

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

 

⑨測(cè)試執(zhí)行停滯及恢復(fù)準(zhǔn)則

 

⑩可交付成果物

性能測(cè)試交付成果包括:

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

⑪角色&職責(zé)

下圖表格中列出不同角色及其對(duì)應(yīng)的職責(zé)：

 

⑫潛在風(fēng)險(xiǎn)及緩解計(jì)劃

下圖表格中列出潛在風(fēng)險(xiǎn)及緩解計(jì)劃：

 

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

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

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

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

總結(jié)

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

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

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

作者：羅小羅

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

編輯：陶家龍

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

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