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

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

負載測試和性能測試
做爲你們最瞭解且最多見的一種性能測試類型，負載測試即包括將常規壓力施加到軟件應用或 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 雲端壓力性能測試軟件試用