資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法學效能測試教程（定義、型別、指標、示例）
效能測試
效能測試是一種軟體測試方法，用於在特定負載下計算軟體應用程式的速度、響應時間、穩定性、可靠性、可擴充套件性和資源利用率。效能測試的主要目標是觀察和消除軟體應用程式中的效能瓶頸。它也稱為“效能測試”，是效能工程的一部分。
效能測試的目標是確定軟體產品的效能如何。
應用程式的速度決定了它的響應速度。
軟體應用程式可以處理的最大使用者負載取決於其可擴充套件性。
穩定性 - 確定應用程式在承受不同負載時是否穩定。
效能測試的目的是什麼？
軟體系統不只有功能和特性需要考慮。軟體應用程式的效能，例如響應時間、可靠性、資源利用率和可擴充套件性，也很重要。效能測試的目的是消除效能瓶頸，而不是發現bug。進行效能測試是為了向利益相關者提供有關其應用程式的效能、穩定性和可擴充套件性的資訊。此外，效能測試揭示了在產品釋出到市場之前需要解決的問題。
如果沒有效能測試，軟體更有可能出現問題，例如當多人同時使用時速度緩慢、在不同作業系統上的不穩定以及可用性差。在預期的負載下，效能測試將確定其程式是否滿足速度、可擴充套件性和穩定性標準。由於效能測試不足或不存在而以較差的效能指標投放市場的程式，可能會獲得不好的聲譽，並且無法實現銷售目標。
關鍵任務應用程式，例如空間發射計劃或救生醫療裝置，也應進行效能測試，以驗證它們是否可以在較長時間內不間斷地執行。
根據鄧白氏公司的資料，59%的財富500強企業平均每週停機時間為1.6小時。鑑於財富500強企業平均每小時向其至少10,000名員工支付56美元，因此這類企業的停機成本的勞動力部分將達到每週896,000美元，或每年超過4600萬美元。據預測，Google.com僅延遲5分鐘（2013年8月19日）就會使這家搜尋巨頭損失545,000美元。最近的一次亞馬遜網路服務中斷據信已導致企業每秒損失1100美元的銷售額。
因此，效能測試至關重要。
效能測試型別
負載測試 − 負載測試評估應用程式處理預期使用者負載的能力。在軟體程式上線之前，目標是識別效能瓶頸。
壓力測試 − 壓力測試是讓應用程式承受高負載以檢視其在高流量或資料處理方面的管理能力的過程。目標是找出應用程式的臨界點。
耐力測試 − 耐力測試確保程式能夠在較長時間內承受預期的負載。
尖峰測試 − 尖峰測試檢查軟體對使用者負載的巨大峰值的響應。
容量測試 − 容量測試包含大量測試。資料被輸入資料庫，並監控軟體系統的總體行為。目標是測試軟體應用程式在不同資料庫容量下的效能。
可擴充套件性測試 − 可擴充套件性測試的目標是檢視軟體程式在維持使用者負載增加方面的“擴充套件”能力如何。它有助於規劃軟體系統的容量擴充套件。
典型的效能問題
速度、響應時間、載入時間和可擴充套件性不足是最常見的效能問題。速度是應用程式最關鍵的特性之一。潛在使用者會放棄執行緩慢的應用程式。效能測試確保您的程式執行速度足夠快，以保持使用者的注意力和興趣。檢視下面常見的效能問題列表，您會發現速度是許多問題的共同特徵：
載入時間過長 − 應用程式的載入時間是指應用程式啟動所需的時間。這應該限制到最低限度。雖然有些應用程式不可能在不到一分鐘的時間內載入，但有些可以。如果可能的話，載入時間應保持在幾秒鐘。
響應時間差 − 使用者將資料寫入應用程式並應用程式響應該輸入所需的時間稱為響應時間。通常，這應該是一個相當快的過程。如果使用者被迫等待太久，他們會失去興趣。
可擴充套件性差 − 當軟體產品無法處理預期的使用者數量或無法適應足夠廣泛的客戶範圍時，則稱其可擴充套件性差。為了確保應用程式能夠處理預期的使用者數量，應該進行負載測試。
瓶頸 − 瓶頸是系統中的障礙，它降低了系統的整體效能。當編碼缺陷或硬體問題在特定條件下導致吞吐量下降時，這被稱為瓶頸。通常，一段有缺陷的程式碼是瓶頸的根源。解決瓶頸問題的關鍵是找到導致速度變慢的程式碼部分並嘗試在那裡糾正它。瓶頸通常透過改進或新增更多硬體來緩解。CPU 佔用率是常見的效能瓶頸。
- 記憶體利用率
- 網路利用率
- 作業系統的限制
- 硬碟使用率
效能測試過程
效能測試中使用的方法可能差異很大，但測試目標保持不變。它可以幫助您證明您的軟體系統滿足預定義的效能標準。它還可以用於比較兩個不同軟體系統的效能。它還可以幫助您識別導致軟體系統效能不佳的區域。
下面概述了執行效能測試的步驟。
確定您的測試環境 - 瞭解您的物理測試環境、生產環境和測試工具。在開始測試過程之前，瞭解將使用的硬體、軟體和網路設定。這將有助於測試人員開發更高效的測試。它還有助於識別效能測試方法中測試人員可能面臨的潛在問題。
確定性能驗收標準 - 包括吞吐量、響應時間以及資源分配目標和限制。除了這些目標和限制之外，制定專案成功標準也很重要。因為專案規範通常不提供各種效能基準，所以應賦予測試人員建立效能標準和目標的權力。有時根本沒有。如果可能，找到一個可比較的應用程式進行比較是設定效能目標的一種有用的方法。
計劃和設計效能測試 – 找出終端使用者的行為可能有何不同，並選擇關鍵場景來測試所有可能的用例。必須模擬一系列終端使用者，規劃效能測試資料，並定義指標。
配置測試環境 - 在開始測試之前，確保環境已準備好。也安排好工具和其他資源。
實現測試設計 - 根據您的測試計劃編寫效能測試。
執行測試 - 執行測試並仔細檢視它們。
分析、調整和重新測試 - 透過分析、調整和重新測試來整合、評估和溝通測試結果。然後微調並再次測試以確定性能是提高還是降低。當 CPU 成為瓶頸時停止，因為每次重新測試的改進往往會越來越少。然後您可能需要考慮升級 CPU 效能。
效能測試工具
市場上有許多不同型別的效能測試工具。您用於測試的工具將取決於許多引數，包括支援的協議型別、許可證成本、硬體要求、平臺支援等等。下面提供了一些常用測試工具的集合。
- LoadNinja
- HP LoadRunner
- JMeter
我們應該測試哪些應用程式的效能？
只有客戶端-伺服器系統才進行效能測試。這意味著任何沒有基於客戶端-伺服器架構構建的應用程式都不需要進行測試。
例如，Microsoft Calculator 不是面向客戶端-伺服器的，並且不支援多個使用者，因此它不是效能測試的候選物件。
效能測試用例示例
當 1000 個使用者同時訪問網站時，確保響應時間小於 4 秒。
當網路連線緩慢時，檢查應用程式在負載下的響應時間是否在可接受的範圍內。
在應用程式崩潰之前，檢查它可以管理的最大使用者數。
同時讀寫500條記錄時，檢查資料庫執行時間。
檢查應用程式和資料庫伺服器在高負載下的CPU和記憶體利用率。
檢查應用程式在低、中、中等和高負載情況下的響應時間。
在實際效能測試執行過程中，“可接受範圍”、“高負載”等模糊詞語將被替換為實際值。這些指標由效能工程師根據應用程式的技術架構和業務需求設定。
結論
在軟體工程中，任何軟體產品上市前都需要進行效能測試。它既能保證客戶滿意度，又能保護投資者的投資免受產品失敗的風險。客戶滿意度、忠誠度和留存率往往遠遠超過效能測試的成本。
瀏覽量：803
