建模性能測試

的目的負載測試是在應用程序上模擬真實的用戶活動。如果使用了非代表性的用戶旅程，或者未定義適當的加載策略，則應用程序在加載下的行為將無法正確驗證。

建模性能測試不需要技術技能，隻需要時間來充分理解應用程序的來龍去脈:

• 用戶如何在係統上工作;他們的習慣
• 何時/何地/多久使用一次應用程序
• 外部事件和活動高峰之間有什麼關係嗎?
• 公司的商業計劃是否與申請活動有關?
• 用戶社區是否會在不同地區擴展?
• 是否有專注於應用推廣的營銷計劃?如果是，觀眾是誰?
• 是否存在與其他係統共享的架構層?

為了在性能建模過程中充分理解應用程序，應該涉及以下角色:

• 功能架構師
• 業務分析師(s)
• 項目負責人

當然，不同的職能角色會提供不同的反饋。目標應該是理解應用程序、最終用戶的習慣，以及應用程序與組織當前/未來狀態的關係。

係統日誌或數據庫提取也很有用。它們很容易指出目前在生產中使用的主要組件和功能領域。它們還將檢索每個業務流程每小時的事務數。

• 在考慮用戶負載時，重要的是要了解並發用戶數量和預期受眾中的用戶數量之間的差異。交付給5000個用戶的應用程序可能隻有500個用戶同時訪問它。
• 如果對最大並發用戶數沒有任何估計，則可以根據每個業務操作/小時的事務數來計算用戶數量。

建立服務水平協議和服務水平目標

服務水平協議而且服務水平目標是自動化和性能驗證的關鍵。項目負責人和功能架構師需要為應用程序定義理想的響應時間。沒有“標準”響應時間。

sla / slo使性能工程師能夠提供on狀態性能測試結果。有了這些，性能測試可以很容易地自動化，以確定應用程序的幾個版本之間的性能回歸。

如果組件測試並且正確理解項目早期階段的性能測試，必須定義組件級別的SLA或SLO以實現成功的自動化。

測試選擇

每次測試運行將解決一個風險-並提供性能需求的狀態。

大多數項目隻關注達到應用程序的極限。這對於驗證規模和體係結構配置非常重要。但是，它很可能不能滿足所有的性能需求。

還需要運行其他測試來驗證應用程序的性能。這些測試將有助於驗證性能需求:

• 單元測試:許多項目忽略了單元測試的力量。如果單個用戶的性能不能接受，就不要開始運行負載測試。單元測試允許應用程序使用深入的分析工具，並為開發人員提供有用的信息。這一步應該是任何負載測試策略的強製部分。

• 連接測試:假設每天早上，所有應用程序用戶都在大致相同的時間連接到係統，然後喝杯咖啡或與同事聊天。即使應用程序的業務組件上沒有主要活動，體係結構也必須處理這種高峰用戶會話場景。這應該是顯而易見的，以確保每次發生這種情況時係統不會崩潰。通過驗證這一點，Ops團隊的工作將會輕鬆得多。這個測試將增加所有預期的用戶。

• 生產活性測試:每個應用程序都有主要的業務操作。這些操作通常導致更新數據或將數據插入數據庫。因此，應該很好地理解每天/小時創建的記錄數量。生產活動測試確保係統能夠處理與生產中預期的事務數/小時相關的負載。該測試將加載/驗證數據庫中業務組件的行為。這類測試的兩個主要需求是每個用戶每小時行程的事務數和適當的思考時間。
• 峰值測試:每個應用程序都會經曆容量峰值。即使這些峰值出現的頻率不高，每年隻有一兩次，也必須確保應用程序能夠處理它們。峰值測試的目的是在短時間內模擬用戶的重要增長(例如，零售網站模擬典型的假日銷售狂潮導致的活動)。

• 浸泡測試:應用程序/體係結構很可能在幾天甚至幾周內都可用。在沒有為維護任務設置專門的時間的情況下，體係結構在很長一段時間內不發生故障地運行是很重要的。浸泡測試在較長的時間框架內運行固定數量的用戶。通過這個測試，可以很容易地識別任何內存泄漏/網絡連接，從而可以很容易地監控環境當前配置的穩定性。

• 批量測試:有些應用程序設計了異步任務或批處理。批處理對真實用戶的影響是什麼?批處理測試將運行生產活動，並在特定測試時刻觸發批處理的執行。目的是確定批處理是否對用戶體驗有任何影響。

一些其他的負載測試可以根據業務的限製和用戶的位置來使用。總有一些與公司/組織相關的事件會影響應用程序負載。

例如，為交易應用程序設計的負載將取決於不同市場的開放時間。這款應用將分為三個典型的階段:第一階段麵向亞洲用戶，第二階段麵向歐洲用戶和其他亞洲用戶，第三階段麵向美國用戶，將三個國家的用戶結合在一起。每次市場開盤或收盤時，交易活動都會出現高峰。因此，測試將包括不同的負載類型，並結合各種業務用例組合。

另一方麵，還有一些測試用於在維護任務或生產事件期間驗證平台可用性:

• 故障轉移測試:該測試的目的是模擬環境中的生產故障。這種類型的測試是必須的，以驗證環境的可用性，並確保故障轉移集群機製能夠正確響應。當體係結構有N個節點時，驗證N-1或N-2節點是否能夠處理預期負載(以避免生產問題期間的事件級聯)是很重要的。運維團隊可能還感興趣的是，他們是否可以在不將應用程序設置為維護狀態的情況下完成維護任務。大多數高可用性應用程序在架構的不同層上都有許多節點:web服務器、應用程序服務器、數據庫等。每層應該有一個測試。

• 恢複測試:與退化測試相反，恢複測試通過停止其中一個節點，然後在應用程序加載時重新啟動它來啟動。它的目的是觀察節點在重新啟動後對重負載的反應。

此外，在負載測試期間，可能還包括一些操作情況，以便在清理緩存時測量應用程序行為。

還有一點可能會影響應用程序的性能:數據。在進行負載測試時，通常會使用數據較少的測試數據庫，或者至少是出於安全目的而匿名化的數據庫。匿名進程通常創建以相同字母/數字開頭的記錄。因此，負載測試期間使用的所有索引都無法與正常生產數據庫的索引相提並論。

數據在生產中快速增長。數據庫的行為根據數據庫的大小而有很大不同。如果數據庫的生命周期很長，那麼驗證不同大小數據庫的性能以確定輕數據庫和重數據庫之間的限製是否不同可能是有意義的。為了實現這一點，應該使用指向數據庫各個領域的大型數據集(例如，永遠不要使用所有帳戶都以AA或AAA2開頭的名稱列表)。相反，從a到Z保留一組有代表性的數據。

測試的類型和複雜性將在項目生命周期中發生變化:

包括思考時間

性能設計的一個重要元素，認為時間是實際用戶在兩個業務操作之間所需的時間:

• 讀取屏幕上顯示的信息的時間
• 是時候在表單中填寫信息了
• 其他不引起與應用程序服務器交互的實際用戶操作

因為現實世界中每個用戶的行為都不一樣，所以思考時間總是不一樣的。因此，重要的是:

• 收集每個場景中每個業務步驟的思考時間。避免對每一步使用相同的思考時間。總有屏幕顯示最終用戶需要閱讀的信息或在進入下一步之前需要填寫的表單。每個動作都應該有一個特定的思考時間。
• 計算平均最小思考時間和平均最大思考時間/動作。
• 讓負載測試工具從指定範圍(最小值和最大值)隨機選擇一個思考時間。

假設應用程序是一個有大牆和大門的城堡。將被驗證的組件(通過負載測試)位於城堡內部。這堵牆將代表代理服務器、負載平衡器、緩存層、防火牆等。

如果在不包括思考時間的情況下運行測試，那麼隻有主門會被擊中。好吧，它可能會壞，但很有可能它會在短時間內鎖住所有東西。要溫柔聰明，躲開防守。主門將允許進入，位於城堡內部的組件將能夠進行適當的負載測試。

驗證用戶體驗

如前所述，一旦應用程序組裝好，測試目標就會改變。在某種程度上，用戶體驗的質量也需要驗證。

移動應用、富互聯網應用(RIA)，以及複雜AJAX框架在大多數用於度量響應時間的方式上具有挑戰性。在過去，度量被限製為下載時間和第一個字節的時間(TTFB）.

這種方法沒有意義，因為大部分有助於用戶體驗的呈現時間依賴於本地ActiveX/JavaScript或本地應用程序邏輯。因此，測試度量不能局限於TTFB和下載時間，因為主要目標是驗證應用程序的整體用戶體驗。

通過結合兩種解決方案可以測量用戶體驗:負載測試軟件(Tricentis NeoLoad)和基於瀏覽器或移動的測試工具。

的負載測試工具將在應用程序上產生98%的負載。基於瀏覽器或基於移動設備的測試工具將生成另外2%的負載，以便在應用程序加載時檢索真實的用戶體驗(包括呈現時間)。

這意味著需要仔細識別基於瀏覽器/移動的解決方案監視的業務流程和事務。

監控

在沒有監控的情況下運行測試就像在收音機裏看恐怖電影。你會聽到人們莫名其妙地尖叫。監視是獲得與體係結構行為相關的度量的唯一方法。

然而，由於以下原因，許多項目往往缺乏績效監控:

• 缺乏工具
• 擔心啟用監視所需的需求

盡管監視不局限於不同服務器的操作係統，但其目的是驗證體係結構的每一層都是可用的和穩定的。架構師需要花費時間來構建最聰明的架構，因此有必要度量不同層的行為。

監視允許更全麵地理解架構，並調查環境的各個部分的行為:

• 操作係統:CPU、內存、磁盤和網絡利用率
• 應用程序服務器:內存利用率、垃圾收集器、線程利用率、會話
• Web服務器:worker，會話數
• 數據庫:緩衝池、緩存利用率、事務數、提交數、索引查詢的百分比
• 緩存服務器:命中率

許多項目使用生產監視工具從體係結構中檢索度量。不建議使用這種方法，因為生產監控在每個數據點之間的粒度很大(每2-5分鍾一次)。在負載測試中，至少每5秒收集一次監視數據是很重要的。需要給性能工程師每一個識別瓶頸的機會。當一個峰值在測試過程中隻出現幾秒鍾時，有足夠的粒度來指出瓶頸是至關重要的。

監控需要技術要求，如係統帳戶、要啟動哪些服務、要打開的防火牆端口等。即使似乎難以滿足這些要求，但如果與業務處進行適當的溝通，就可以進行監測;提前將這些需求發送給他們將有助於溝通。

監控的一個關鍵要點:在早期階段預測需求。

下一個步驟

本文是四部分係列文章的第三篇，重點介紹現代性能測試的實用指南:

第一部分-性能測試的實用介紹

第二部份-建立性能測試策略

第3部分-建模性能測試

第4部分-執行性能測試

這篇文章最初是於2018年1月發布，最近一次更新於2021年7月。