一篇文章帶你深入理解什麼是負載測試

介紹
任何軟體開發專案接近完成的時候，它可能已經通過無數次測試了，特別是在測試和開發同時發生的敏捷測試環境下。無論你已經進行過多少輪測試，一旦你的應用程式已接近完成，那麼只有一個辦法知道你的軟體是否可以滿足真實使用者群的實際需求，它就是負載測試。你可以使用負載測試工具來完成這項工作。負載測試是指給軟體、應用程式或網站加上模擬的需求，以測試其在不同的環境下的執行狀態的過程。

負載測試和效能測試
作為大家最瞭解且最常見的一種效能測試型別，負載測試即包括將常規壓力施加到軟體應用或 IT 系統，去看它們是否在正常條件下可以按照預期執行。相對於施壓更大，更殘酷的壓力測試，負載測試確保了在給定引數範圍內，程式或系統不超過其預期設計的處理能力，而壓力測試是有關超載的事情，直到系統崩潰，應用不能執行或不太可能出現的負載場景。這兩種測試方法在驗證給定的前端軟體如一個網站、後端系統如託管該網站的Apache 伺服器是否能夠很好的處理真實負載起著重要的作用。壓力測試故意誘導失敗，這樣你就可以分析所涉及的突破點的風險，然後，也許你會選擇調整方案，使它們更優雅地被打破。壓力測試對於應對突發情況做準備，以及確定給定系統效能承載能力上限是很有價值的。但是，當涉及到簡單地確保軟體應用程式或物理網路在一般情況下可以承載使用者請求和操作，負載測試是完成任務的正確方法。

當然，應該指出的是，如果你的應用程式沒有做好預期，那麼這意味著釋出前的負載測試，在它釋出後將變成一次壓力測試。閱讀我們的負載測試最佳實踐來避免這些常見陷阱。一旦負載啟動引發崩潰，從那一刻起，根據定義，就變成了壓力測試。這是負載測試和壓力測試經常被混淆的主要原因，因為完全相同的測試在某些情況下可能會從負載測試變成壓力測試。

瞭解負載測試
負載測試是為一個應用或系統儘可能地接近成品部署並在使用者群中建立的模擬環境。通過利用專業的測試軟體，負載測試可以讓開發團隊來回答這樣的問題“我的系統在這些環境下按照預期執行了嗎？”，“它的效能足夠好嗎？”正如微軟應用效能測試指南所說：一個負載測試可以測量響應時間，吞吐率和資源利用率，並確定應用程式的效能瓶頸，假設效能瓶頸的出現低於負載峰值。

在這裡，“低於負載峰值”再次簡單地表明，負載測試的引數落在壓力測試（根據定義，指測試系統在或超出最大負載時的執行狀況）範圍內。負載測試可以發現系統延時，頁面載入問題，以及當多個使用者訪問一個應用程式或高併發致使系統崩潰，這類問題在開發和測試環境中容易被忽視即便程式碼已經檢查了很多遍。成百上千人同時訪問軟體時，一些探測不到的問題可能會突然出現。

舉例來說，假設你正在開發一個新的線上投票平臺，並且希望它在負載高峰時段能承受每分鐘10,000次使用者提交請求。在開發軟體時，寫程式碼階段你可能就執行了單元測試，週期性迴歸測試，以確保在新功能開發程式中沒有破壞已有的功能。但你在什麼時候開始做大規模使用者測試？什麼時候你開始測試程式接受成百上千的重疊欄位項，表單提交和其他命令？

從技術角度講，在一個專案生產的末期，才會進行有真實使用者參與的能夠精確模擬系統效能的負載測試。這與汽車生產類似：你可以修復和測試引擎，但如果引擎沒有安裝，則不能測試汽車在道路上的表現。其實，在軟體開發專案中的早期，你就能以一個集中的方式來測試特定元件的負載，例如測試後端效能問題，同時使用者輸入，在延長的時間週期裡輸入的耐力，或其他任何可以給系統施壓，造成延時，記憶體洩漏或功能崩潰的方式。那就意味著你已經進行了負載測試，只不過是以一種受限的形式，並且已經在探索多使用者訪問對系統的影響了。在一個不完整的系統上進行少數使用者輸入測試，效能測試專家 Scott Barber ，上述微軟資源的合著者之一，更願意稱其為“多使用者功能測試。”再次強調，正確的負載測試需要一個幾乎完整的系統，並且通常要求使用可以真實模擬數千使用者的測試軟體。

但有一個對所有規則的例外。對網際網路應用而言有一個很明確的多使用者問題，從智慧電話的 GPS 應用，到線上多人視訊遊戲，負載測試可以在系統上進行，而不必通過眾多使用者，因為多個使用者不是負載的唯一可能來源。有時負載可能是由大檔案，大量的計算，甚至是弱網連線造成的。想想在 Acrobat 中開啟 PDF ，或在 Photoshop 中開啟一個 PSD 。系統遇到壓力時負載便產生。執行開啟檔案的速度夠快嗎？如果檔案過大，會使應用程式崩潰嗎？你用什麼標準來判斷你的應用開啟檔案的“速度夠快”？能開啟檔案是可以接受的，但如果需要5分鐘呢？誰制定了系統的理想承載能力的標準，又依據什麼呢？負載測試人員繪製的使用者的主觀偏好和系統的目標功能之間的界限又在哪裡呢？

要成為一個優秀的負載測試人員並能分析負載測試結果，往往還需要具備超過軟體工程和測試專業知識的東西，要深諳使用者體驗。

**負載測試的未來：瞭解使用者的真實想法
負載測試工具和效能測試工具的最終目的一般總是為了降低風險**，無論是對於軟體成功功能的風險，終端使用者感知的風險，或對公司底線的風險。當然，所有這三個是緊密交織在一起，所以，對於一個開發人員或測試人員知道它們是如何相互關聯的是很重要的。要敢於提出建議，如果你專注於減少中間標準，那麼使用者感知和其他兩個因素通常會水到渠成。許多負載測試的問題歸根結底，更多的在於使用者感知，而非具體理想的頁面載入時間和其他技術統計資料。

實際上，雖然反覆進行負載測試通常需要專門的軟體，但由於人為複雜因素的存在，資料解讀並不會像看起來那麼簡單。例如，如果有人來到一個只載入文字的網站，那麼使用者期待它立即載入，即便是一兩秒鐘的載入時間也是很難容忍的，但如果他們期望載入嵌入的視訊，那麼使用者對響應時間將更寬容。寬頻時代的到來，我們已經逐漸習慣接收這些。隨著心理學對使用者體驗要素更深入的探索，發現了很多微妙的細節，實際上人們更傾向於網站內訪問速度均勻一致的緩慢，例如，整體載入速度較快，但有內部速度不一致的心理。因此，沒有這種心理層面的認知，真正瞭解使用者的願望和期望，再多的負載測試資料也不會以最大的感知效果來自動幫你改進軟體。

換句話說，如果你不理解人類的心理、使用者的行為和反應，你就不可能實現一個很真實的負載測試，並且更糟的是，你可能會誤解測試結果。這就是為什麼在執行負載測試時儘可能地模擬真實的終端使用者體驗很重要的原因，重複模擬使用者在接近最大負載時訪問一個網站或應用程式，分析測試結果，然後對系統進行相應的，盡最大可能來減少使用者體驗中的不愉快因素。由於開發週期越來越短，軟體公司可以通過簡單地專注於特定的故障以使使用者體驗更平穩和高效，而不是解決高負載情況下遇到的所有問題，這樣可以節省時間和金錢。

本文由 OneAPM 張宇編譯自 SMARTBEAR 網站的文章《 What is LOAD TESTING ?》
本文轉自 OneAPM 官方部落格
原文連結：https://smartbear.com/learn/performance-testing/what-is-load-testing/

點選此處，免費申請 OneAPM 雲端壓力效能測試軟體試用