**網際網路 。
講到測試，人們腦海中首先浮現的是針對軟體正確性的測試，即常說的功能測試。但是軟體僅僅只是功能正確是不夠的。
講到測試，人們腦海中首先浮現 的是針對軟體正確性的測試，即常說的功能測試。但是軟體僅僅只是功能正確是不夠的。在實際開發中，還有許多其它的非功能因素在起著決定性作用。比如軟體響 應速度，影響軟體響應速度的因素很多，有些是因為演算法不夠高效，有些可能受使用者併發數的影響。
在我所負責的測試專案中，程式功能能夠 滿足客戶需求，但當把程式交付客戶使用時，由於客戶網路應用環境複雜，而我們在壓力測試時沒有周密考慮各種可能發生的情況，軟體程式在巨大負載下頻繁崩 潰，使測試團隊飽受客戶和老闆的抱怨。由此，我認識到隨著網路環境的複雜性和多樣性，壓力測試是軟體質量保證的重要元素之一，絕對不能馬虎了事。
什麼是壓力測試?
在軟體功能測試中，白盒和黑盒技術用於對正常程式功能和效能進行詳盡的檢查和測試。而壓力測試(streetesting)則是用來對付非正常的情況。
(1)什麼是壓力測試
壓力測試是指模擬巨大的工作負荷來測試應用程式在峰值情況下如何執行操作。例如模擬實際軟硬體環境，在超出使用者常規負荷下，長時間執行測試工具來測試被測系統的可靠性，和測試被測系統的響應時間，目的是在極限負載下識別程式的弱點。
(2)壓力測試和負載測試的區別
在這次專案測試前，我一直對壓力測試和負載測試存在著一定 程度的混淆。經過這次系統崩潰後，我對壓力測試和負載測試的區別有了新的認識。壓力測試是在超常規負荷條件下，長時間連續執行系統，檢驗應用程式的各種性 能表現和反應。負載測試是指測試應用程式在常規負荷下，確認響應時間和其它的效能和表現。
實際上，壓力測試也是從比較小的負載開始，逐 漸增加模擬使用者的數量，直到應用程式響應時間超時。壓力測試的特點是長時間連續執行，增加超負荷(併發，迴圈操作，多使用者)來測試什麼時候系統會產生異 常，以及異常處理能力，找出瓶頸所在。現在的我終於明白到其實壓力測試實際上就是超常規的負載測試。
(3)壓力測試的核心原則
乙個有效的壓力測試需要遵循一些核心的基本原則，這些原則可以讓我們在測試過程中時刻提醒我們壓力測試是否還有更多的極端可能。
①重複:最明顯且最容易理解的壓力原則就是測試的重複。換句話說，重複測試就是一遍又一遍地執行某個操作或功能。功能測試是驗證乙個操作能否正常執行，而壓力測試則是確定乙個操作能否在長時間內每次執行時都正常。
②併發:併發是同時執行多個操作的行為。換句話說，就是在同一時間執行多個測試用例。功能測試或單元測試幾乎不會與任何併發設計結合。因此，壓力系統必須超越功能測試，要同時遍歷多條**路徑。
③量級:壓力測試另乙個重要原則就是要給每個操作增加超常規的負載量。就是說壓力測試可以重複執行乙個操作，但是在操作自身過程中也要盡量給程式增加負 擔，增加操作的量級。一般來說，單獨的高強度操作重複自身可能發現不了**錯誤，但與其他壓力測試方法(如併發和量級)結合在一起時，將可以增加發現錯誤 的機會。
④隨機:意思是任何壓力測試都應該多多少少具有一些隨機性。例如隨機組合前面三種壓力測試原則，然後變化出無數種測試形式，就 能夠在每次測試執行時應用許多不同的**路徑來進行壓力測試。當乙個壓力測試結合的原則越多，測試執行的時間越長，就可以遍歷越多的**路徑，發現的錯誤 也會越多。
壓力測試對系統的重要作用
我們對應用程式進行壓力測試時經常會出現這種情況，就是測試到了最後卻發現不明白測試結果有什麼意義?實際上，當我們都不明白壓力測試的意義時，我們就不能設計出各種極限測試用例。
壓力測試不同於功能測試，軟體的正確性並不是它的測試重點，它所看重的是軟體的執行效率，尤其是短時間內訪問使用者數**性增長時軟體的響應速度。因此，明白壓力測試的作用，對我們高效完成壓力測試有至關重要的指導意義。
(1)測試應用程式的可靠性
在系統崩潰後總結之前失敗的壓力測試時，我忽視的第乙個要點就是沒有測試出應用程式在壓力下的可靠性。壓力測試除了對每個單獨的元件進行壓力測試外，更 應該對帶有其所有元件和支援服務的整個應用程式進行集中壓力測試，以檢查在巨大的工作負荷時，應用程式在峰值情況下是否可靠的執行操作。例如，當實際情況 是平均每秒出現1個或2個中斷的情形下，應當對每秒出現10個中斷的情形來進行特殊的測試;又或者把輸入資料的量提高乙個數量級來測試輸入功能是否可靠的 響應。從本質上來說，壓力測試是想要看在最大極限時程式是否可靠的執行。
(2)測試應用程式的併發效能
進行壓力測試需要對實際的併發訪問量有乙個正確的預期估算，否則在負載遠遠大於事前**的壓力下系統將脆弱得不堪一擊。導致系統崩潰的因素有很多，處理能力、儲存速度、響應時間、網路頻寬等無論哪部分出現短板擁堵、後果都可能導致全盤崩潰。
現在我明白，哪怕硬體條件達到了，如果軟體的並行處理能力不足將會導致等候佇列過長，響應時間變慢，系統崩潰也只是時間問題。簡單說就是：壓力測試是考察當前軟硬體環境下系統所能承受的最大併發負荷，並幫助找出軟體程式的瓶頸所在。
(3)測試應用程式的最大負載能力
壓力測試的目的之一是找出應用程式能夠支援的最大客戶端數。通過多次的執行和對測試結果中正在執行使用者數與錯誤使用者的對比，然後根據可接受錯誤率就可得 到該功能的最大負載訪問的使用者數。最大負載壓力測試用來評估在超越最大負載的情況下系統將如何執行，這時的目標是要發現在高負載的條件下應用程式的缺陷 (bug)，例如記憶體洩漏等。因此，最大負載能力不但是應用程式乙個重要的技術指標，也是客戶評估和驗收軟體的乙個關鍵指標。
如何進行高效的壓力測試?
軟體測試有兩句通俗的話：開發是盡可能地讓程式通過;而測試則是盡可能地讓程式通不過。對於壓力測試而言，測試效果好不好，測試計畫的好壞是關鍵。所以，針對不同的情況，分析後有針對的進行測試，比起拿槍亂打、無的放矢顯然要高效得多。
進行一次切實可行的壓力測試並不像乍看之下那麼簡單，遇到的問題也可能非常微妙。例如，我的測試團隊就經常遇到諸如「客戶端每小時將要處理100個客戶 訂單請求」等此類的需求，於是測試團隊就試圖把該需求轉化為某種測試需求，執行這種測試需求的常見方法就是以死迴圈的形式對伺服器進行反覆請求，然後靜觀 其效。然而，通常事情進行得並不順利，原因在於這只是把需求表面化了，沒有分析出測試需求的本質。高效的壓力測試應遵循以下這幾個步驟：
(1)確定測試目標
在確定壓力測試目標中，我們要定義測試的物件，並對每乙個測試物件給出清晰說明，也要定義測試結束的目標。為控制測試的有效性以及完成程度，必須定義準 則和策略。準則必須是客觀的，可量化的，而不能是經驗或感覺。例如壓力測試目標可能是測定終端使用者處理事務的響應時間，它可能隨使用者的增加而增加，但要定 義乙個可接受時間。在確定壓力測試目標過程中，最好能邀請客戶、設計人員等一同對測試目標進行評審。
(2)制定壓力測試計畫
測試計畫內容包括：定義測試資源、制定測試進度表、選擇測試工具等。制定測試計畫的目的是使壓力測試有章可循並得到人力、物力等各方面的保證;在制定測 試進度表時應考慮和開發進度相互協調;對於測試工具的選擇應以滿足測試目標為前提。所以，這並不是說測試工具提供的功能越多就越好，在實際的選擇過程中適 用才是根本。
(3)編寫測試案例和設定測試資料
測試人員一般是根據測試案例進行實際的測試工作，因此測試案例的編寫 應做到客觀全面、重點突出，也就是要求編寫的測試案例應該盡可能模擬真實的負荷，不遺漏重要的測試內容。為了讓所有的測試順利執行，可採取資料驅動方式進 行，同時應該對測試資料進行引數化。另外，一般不提倡在開發環境中進行壓力測試，最好是另外構建測試環境。
(4)結果分析及測試報告
壓力測試執行結束後，應把所有的資料彙總並記錄到檔案中，以方便對測試結果進行分析和得出結論。若測試失敗，應先分析失敗原因，如果是軟體系統造成的， 應返回給設計人員修改。如果測試結果不滿足預期需求，應先對軟體程式進行優化調理，然後再次執行測試，直到可以滿足預期需求或調整已無法改善結果。
最後需要注意的是測試報告。報告應包括測試提要、測試環境和測試結果。提要應簡單說明測試方法、策略、範圍、內容;測試環境應包括資源開銷、環境配置等;測試結果必須包括測試是否通過或拒絕，並要對測試結論進行說明，並對軟體程式的效能做出評價。
完善壓力測試 避免系統崩潰惡果
完善壓力測試 避免系統崩潰惡果 講到測試，人們腦海中首先浮現的是針對軟體正確性的測試，即常說的功能測試 但是軟體僅僅只是功能正確是不夠的。在實際開發 中，還有許多其它的非功能因素在起著決定性作用。比如軟體響應速度，影響軟體響應速度的因素很多，有些是因為演算法不夠高效，有些可能受使用者併發數的影響。在...
使用AB壓力測試工具進行系統壓力測試
ab是apache自帶的乙個很好用的壓力測試工具，當安裝完apache的時候，就可以在bin下面找到ab linux mac windows 1 我們可以模擬100個併發使用者，對乙個頁面傳送1000個請求 ab n1000 c100 其中 n代表請求數，c代表併發數 返回結果 首先是apache的...
服務匯流排yali測試 匯流排壓力測試系統及其方法
匯流排壓力測試系統及其方法 技術領域 0001 本發明涉及一種壓力測試系統及其方法，特別是指以快捷外設互聯標準裝置 pc1 e 產生壓力資料流避免占用 處理器使用時間的匯流排壓力測試系統及其方法。背景技術 0002 近年來，隨著半導體技術的蓬勃發展，目前 處理器 central processing...