軟體性能測試完整指南

作者 Angela Stringfellow

來源 DZone

原文 https://dzone.com/articles/a-complete-guide-to-performance-testing-types-test

性能測試是軟體測試的一種形式，集中於系統如何在特定的負載下運行系統執行。這不是關於發現軟體bug或者缺陷。性能測試是根據基準和標準來應對。性能測試需要給開發人員提供診斷信息，以便他們清除問題。

軟體系統測試的各種類型

為了理解軟體如何將在用戶系統運行，有幾種不同類型的性能測試在軟體測試期間可以應用。這是非功能測試，目的在於確定系統的準備情況。（功能測試集中於軟體的個別功能。）

Image credit MindsMapped.

負載測試

負載測試檢測系統隨著工作負載增加時的性能。工作負載可能意味著並發用戶或事務。當工作負載增加，監控系統來檢測它的響應時間和系統的持久能力。該工作負載在正常工作條件的參數範圍內。

壓力測試

不像負載測試，壓力測試——也叫做疲勞測試——意味著檢測系統在正常工作條件參數範圍外的性能。可以給這個軟體更多的用戶或事務處理。壓力測試的目標是檢測軟體的穩定性。軟體會在何種程度故障，還有軟體如何從失敗中恢復。

尖峰衝擊測試

尖峰衝擊測試是壓力測試的一種，它評估軟體負載在快速和反覆大幅度增長時的性能。在短時間內，工作負載超出了正常的預期。

耐力測試

耐力測試——也叫做浸泡測試——是評估軟體性能如何在長時間執行正常工作的。耐力測試的目標是檢查系統問題，例如內存泄露。（內存泄露發生在系統無法釋放被丟棄的內存的時候。內存泄漏會損害系統性能，或者導致系統失敗。）

可擴展性測試

可擴展性測試是用來確定軟體是否有效的處理日漸增長的工作負載。這可以通過當監控系統性能時，增加的用戶負載或數據量來確定。並且當CPU和內存等資源變更的時候，工作負載可能保持在相同的水平。

容量測試

容量測試確定軟體在大量、預期數據量下的執行效率。它也被稱為洪水測試，因為這個測試用數據淹沒了系統。

在性能測試種最常見的問題

在軟體性能測試期間，開發人員會尋找性能的癥狀和問題。速度問題——例如緩慢的響應和長時間的載入時間——經常會被觀察和處理。但是還能看到有一些其他的性能問題：

瓶頸效應——發生在當數據流被中斷或者停止的時候，因為沒有足夠的能力處理工作負載。

較差的可擴展性——如果軟體無法處理所需數量的並發任務，結果可能導致延誤，可能增加錯誤，或者發生其他無法預料的行為，這影響到：

磁碟使用情況

CPU使用情況

內存卸扣

操作系統受限

糟糕的網路配置

軟體配置問題——通常設置不是設置在一個足夠的級別上來處理工作負載。

硬體資源不足——性能測試可能暴露出物理內存限制或低效率的CPU。

性能測試7步

Image credit Gateway TestLabs

同樣也被曾作測試台，測試環境是設置軟體、硬體和網路來執行性能測試的地方。為了使用性能測試測試環境，開發人員可以用下面七步：

確定測試環境

確定硬體、軟體、網路配置和可用的工具，讓測試團隊設計測試和儘早確定性能測試挑戰。性能測試環境選擇包括：

有少量低規格伺服器的生產系統子集。

有少量相同規範伺服器的生產系統的子集。

生產系統的複製品。

實際生產系統。

確定性能標準

除了確定性能參數，例如響應時間，吞吐量和限制之外，確定性能測試的成功標準是什麼。

計劃和設計性能測試

確定性能測試方案，考慮賬戶用戶的可變性、測試數據和目標參數。這將創建一到兩個模型。

配置測試環境

準備測試環境的元素和監控資源所需的設備。

執行測試設計

開發測試。

執行測試

除了運行性能測試之外，監控和抓取生產數據。

分析，報告，再測試

分析數據，分享所發現的。使用同樣的參數和不同的參數再次運行性能測試。

性能測試參數測量了什麼

參數需要理解性能測試的質量和效果。除非有測量，否則無法提高。現在解釋下2種定義：

測量——收集的數據，例如它響應一個請求所花的秒數。

參數——使用數據的計算結果，決定結果的質量，例如平均響應時間（總響應時間/請求）

有許多方法可以測量速度、可擴展性和穩定性，但是每輪性能測試無法使用全部方法。在性能測試中所用的參數，下面的是經常用到的：

響應時間

發送一個請求和獲得一個響應的總時間。

等待時間

這也稱為平均延遲，這告訴開發人員在發送請求後接收第一個位元組需要多長時間。

平均載入時間

從用戶的角度來看，交付每個請求所需的平均時間是質量的主要指標。

峰值響應時間

這是完成請求所需的最長時間的測量。峰值響應時間明顯長於平均時間，這可能表明出現問題的異常情況。

錯誤率

這是一個與所有請求相比，計算產生錯誤的請求的百分比。這些錯誤通常發生在負載超過容量的時候。

並發用戶

這是最常見的負載測量——在任意時刻有多少活躍用戶，也稱為負載大小。

每秒請求

多少請求被處理。

事務通過/失敗

對成功或不成功請求的總數的測量。

吞吐量

以千位元組每秒的速度度量，吞吐量顯示測試期間使用的帶寬量。

CPU利用率

CPU需要多少時間來處理請求。

內存利用率

需要多少內存來處理請求。

性能測試最佳實踐

也許性能測試最重要的小建議就是早測試，常測試。一個單獨的測試將無法告訴開發人員他們所需知道的全部。成功的性能測試是許多的反覆測試和小測試組成的。

在開發中儘可能的早測試。當項目結束時，不要等待並急於進行性能測試。

性能測試不僅僅針對已完成的項目。測試單個單元或模塊也是有價值的。

進行多項性能測試，以確保一致的發現和確定參數的平均值。

應用常常涉及多個系統，例如資料庫、伺服器和服務。單獨測試各個單元，而且一起測試。

Image credit Varun Kapaganty

除了反覆測試，通過一系列性能測試的最佳實踐，性能測試將會更加成功。

讓開發人員、IT人員和測試人員一起參與創建一個性能測試環境。

記住真正的用戶將使用正在進行性能測試的這個軟體。確定結果將如何影響用戶，而不僅僅是測試環境伺服器。

超越性能測試參數。通過計劃一個測試環境來開發一個模型，這個測試環境儘可能多地考慮用戶活動。

基線測量為確定成功或失敗提供了一個起點。

性能測試最好在儘可能接近生產系統的測試環境中進行。

將性能測試環境與用於質量保證測試的環境隔離開來。

任何性能測試工具都不需要做任何事情。有限的資源可能會進一步限制選擇。為了更適合研究性能測試工具。

儘可能保持測試環境的一致性。

計算出的平均值將提供可執行的參數。跟蹤異常值也有價值。這些極端的測量可能暴露出可能的失敗。

當準備報告分享性能測試結果時，請考慮聽眾。此外，還包括報告中的任何系統和軟體更改。

5個性能測試常犯的錯誤

還有一些錯誤會導致性能測試時不太可靠的結果:

測試時間不足

不包括開發人員

不使用與生產系統類似的QA系統

優化軟體不足

沒有故障排除的計劃

性能測試錯誤理論

性能測試的錯誤理論可能導致錯誤或遵循性能測試最佳實踐的失敗。根據Sofia Palamarchuk的說法，這些理念在開發軟體時可能會耗費大量金錢和資源：

性能測試是開發的最後一步

在前面性能測試最佳實踐部分中提到過，預期和解決性能測試問題應該是軟體開發的早期部分。儘早執行解決方案將比軟體開發結束時的主要修復成本要低。

硬體越多就能解決性能問題

增加處理器、伺服器或內存，簡單的增加成本，不解決任何問題。更多有效的軟體可以在硬體增加或改善時更好的運行和避免潛在的問題。

測試環境「非常接近」

在一個類似於生產環境的測試環境中進行性能測試，是一個性能測試的最佳實踐。這些元素之間的差異可以顯著地影響系統性能。在精確的生產環境中進行性能測試可能是不可能的，但是嘗試匹配：

硬體組件

操作系統和設置

系統上使用的其他應用程序

資料庫

現在什麼有用，就全面的起作用

對於推算出的結果要小心。不要採用小的性能測試結果，並且假設當元素髮生變化時，它們將是相同的。而且，它們是在對立面工作的。不要根據負載測試來推斷最小的性能和需求。所有的假設都應該通過性能測試來驗證。

一個性能測試方案就夠了

不是每個性能問題都可以在一個性能測試方案中檢測到。但是資源確實限制了可能發生的測試數量。在中間的是一系列性能測試，它們針對的是風險最高的情況，對性能會產生最大的影響。此外，問題可能出現在設計良好之外和設計良好的性能測試。監視生產環境也可以檢測性能問題。

測試了每個部分等於測試了全部系統

雖然隔離功能用於性能測試是很重要的，但是單獨的組件測試結果並不會添加到整個系統範圍的評估中。但是，測試一個系統的所有功能可能是不可行的。一個完全可能的性能測試必須使用可用的資源來設計。但是要注意沒有測試過的東西。

是什麼對他們有用，對我們有用

如果一組用戶確實遇到了複雜的問題或性能問題，那麼不要認為這是對所有用戶的性能測試。使用性能測試來確保平台和配置如預期的那樣工作。

軟體開發人員經驗豐富，不需要性能測試

缺乏經驗並不是造成性能問題的唯一原因。即使是過去開發過免費軟體的開發人員也犯了錯誤。特別是當多個並發用戶在系統中時，更多的變數開始發揮作用。

一個完整的載入測試說明了一切

在總負載中運行一個測試來發現所有性能問題是很吸引人的。除了這種測試，它往往會暴露出許多性能問題，以至於很難將注意力集中在單個解決方案上。從較低的負載開始，逐步向上擴展可能看起來是一個不必要的緩慢過程，但是它會產生更容易的結果，從而更有效地排除故障。

測試腳本是實際的用戶

確保測試自動化正在以真實用戶的方式使用該軟體。當性能測試參數被更改時，這一點尤為重要。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！