作者 | 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

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

1. 確定測試環境

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

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

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

   ○ 生產系統的複製品。

   ○ 實際生產系統。

2. 確定性能標準

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

3. 計劃和設計效能測試

   確定性能測試方案，考慮賬戶使用者的可變性、測試資料和目標引數。這將建立一到兩個模型。

4. 配置測試環境

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

5. 執行測試設計

   開發測試。

6. 執行測試

   除了執行效能測試之外，監控和抓取生產資料。

7. 分析，報告，再測試

   分析資料，分享所發現的。使用同樣的引數和不同的引數再次執行效能測試。

效能測試引數測量了什麼

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

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

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

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

響應時間

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

等待時間

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

平均載入時間

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

峰值響應時間

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

錯誤率

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

併發使用者

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

每秒請求

多少請求被處理。

事務通過/失敗

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

吞吐量

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

CPU利用率

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

記憶體利用率

需要多少記憶體來處理請求。

效能測試最佳實踐

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

• 在開發中儘可能的早測試。當專案結束時，不要等待並急於進行效能測試。

• 效能測試不僅僅針對已完成的專案。測試單個單元或模組也是有價值的。

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

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

Image credit Varun Kapaganty

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

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

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

• 超越效能測試引數。通過計劃一個測試環境來開發一個模型，這個測試環境儘可能多地考慮使用者活動。

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

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

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

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

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

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

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

5個性能測試常犯的錯誤

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

• 測試時間不足

• 不包括開發人員

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

• 優化軟體不足

• 沒有故障排除的計劃

效能測試錯誤理論

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

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

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

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

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

測試環境“非常接近”

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

• 硬體元件

• 作業系統和設定

• 系統上使用的其他應用程式

• 資料庫

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

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

一個性能測試方案就夠了

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

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

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

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

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

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

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

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

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

測試指令碼是實際的使用者

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