基本介紹
- 中文名：負載壓力測試
- 測試內容：並發性能、疲勞強度、大數據量
- 套用範圍：計算機
- 作用：測試產品發布後計算機系統的性能
基本概述,負載測試,壓力測試,性能測試,分析處理,
基本概述
負載壓力測試有助於確認被測系統是否能夠支持性能需求，以及預期的負載增長等。負載壓力測試不只是關注不同負載場景下的回響時間等指標，它也要通過測試來發現在不同負載場景下會出現的，例如速度變慢、記憶體泄漏等問題的原因。負載壓力測試是性能測試的重要組成部分，負載壓力測試包括並發性能測試、疲勞強度測試、大數據量測試等內容。一般包括如下： 1、性能測試
負載壓力測試中動態參數關聯
負載壓力測試中動態參數關聯性能測試用來保證產品發布後系統的性能能夠滿足用戶需求。其中系統性能包括執行效率、資源占用、穩定性、安全性、兼容性、可擴展性、可靠性等。
2、性能評測
性能評測包括：在真實環境下，檢查系統服務等級的滿足情況，評估並報告整個系統的性能；對系統的未來容量作出預測和規劃。
3、性能調優
負載壓力測試結構剖析
負載壓力測試結構剖析性能調優一般的步驟為首先查找形成系統瓶頸或者故障的根本原因，其次是進行性能調整和最佳化，最後便是評估性能調整的結果。
4、負載測試
負載測試時通過逐步增加系統負載，測試系統性能的變化，並最終確定在滿足性能指標的情況下，系統所能承受的最大負載量的測試。
5、壓力測試
壓力測試是通過逐步增加系統負載，測試系統性能的變化，並最終確定在什麼負載條件下系統性能處於失效狀態，並以此來獲得系統能提供的最大服務級別的測試。
6、並發性測試
a、套用在客戶端性能的測試；
負載壓力測試工具
負載壓力測試工具b、套用在網路上性能的測試；
c、套用在伺服器上性能的測試；
7、疲勞強度測試
8、大數據量測試 大數據量測試包括獨立的數據量測試和綜合數據量測試兩類。
負載測試
伺服器負載測試通過編輯一個巨大的檔案來測試文字處理軟體；
通過傳送一個巨大的作業來測試印表機；
通過成千上萬的用戶信箱來測試郵件伺服器；
有一種比較特別的容量測試是叫作“零容量測試”，它是給系統加上空任務來測試的。 耐久性測試/持久性測試的的例子：在一個循環中不停的運行客戶端超過一個擴展時間段。
負載測試的目的：
找到一些在測試流程中前面的階段所進行的粗略測試中沒有被找出的bugs，例如，記憶體管理bugs，記憶體泄露，緩衝器溢出等等。保證應用程式達到性能測試中確定的性能基線。這個可以在運行回歸試驗時，通過載入特定的最大限度的負載來實現。儘管性能測試和負載測試似乎很像，但他們的目的還是有差異的。一
方面，性能測試使用負載測試的技術，工具，以及用不同的負載程度來測度和基準化系統。在另一方面來講，負載測試是在一些已經定義好的負載程度上進行測試的，通常對系統加上最大負載之後，系統應該仍然可以提供全部功能。這裡需要明確一點，負載測試並不是要對系統載入上過度的負載而使系統不能工作，而是要使系統像一個上滿了油的機器嗡嗡叫。 在負載測試的相關內容中，我想應該非常重要的是要有十分充足的數據來進行測試。從我的經驗中得知，假若不用非常大的數據*去測的話，有很多嚴重的bug是不會的到的。比如說，LDAP/NIS/ActiveDirectory資料庫中成千上萬的用戶，郵件伺服器中成千上萬的信箱，資料庫中成G成G的表，檔案系統中很深的檔案或者目錄的層次，等等。顯然，測試人員就需要使用自動化工具來產生這些龐大的數據集，比較幸運的是任何優秀的腳本語言都可以勝任這些工作。
負載壓力測試站點測試工具
負載壓力測試站點測試工具壓力測試
壓力測試是指通過對系統載入過度的資源或者例系統沒有應該具有的令系統可以正常運作的資源，來使系統崩潰（在某些情況的時候，它又可以叫做負面測試）。進行這個瘋狂行為的主要目的是為了保證系統出 故障及可以適當的恢復，而這個恢復得怎么樣的特性則是叫做可恢復性。 當性能測試需要的是一個可控制的環境和不斷的測度的時候，壓力測試則是令為歡喜的引起混亂及不可預測性（譯者按：從這一點可以看出作者是一個很優秀的測試人員）。還是舉WEB套用系統為例，下面是一些對系統可行的壓力測試方法：兩倍的已經基線的並發用戶數或者HTTP連線數；隨機的關閉及重開連線到伺服器上的網路上集線器/路由器的連線埠（例如，可以通過SNMP命令來實現）；把資料庫斷線然後再重啟；當系統還在運行的時候，重建一個RAID陣列；在WEB和資料庫伺服器上運行消耗資源（如CPU，記憶體，磁碟，網路）的進程。
負載壓力測試
負載壓力測試性能測試
性能測試的目的不是去找bugs,而是排除系統的瓶頸，以及為以後的回歸測試建立一個基準。而性能測試的操作，實際上就是一個非常小心受控的測量分析過程。在理想的情況下，被測軟體在這個時候已經是足夠穩定了，所以這個過程得以順利的進行。一組清晰已定義好的預期值是讓一次有意義的性能測試的基本要 素。如果連你自己都不知道系統性能有些什麼是要測的，那么它對於你要測試的方法手段是沒有指導意義的*。例如，給一個web套用做性能測試，你要知道至少兩樣東西：在不同並發用戶數或者HTTP連線數情況下的負載預期值；可接受的回響時間；當你知道你的目標後，你就可以開始使用對系統持續增加負載的方法來觀察系統的瓶頸所在。重新拿web套用系統來做例子，這些瓶頸可存在於多個層次，你可以使用多種工具來查明它們的所在：在套用層，開發人員可以通過profilers來發現低效率的代碼，比如說較差的查找算法；在資料庫層，開發人員和資料庫管理員（DBA）可以通過特定的資料庫profilers及事件探查器（queryoptimizers）。 在作業系統層，系統工程師可以使用一些工具如在Unix類的作業系統中的top、vmstat、iostat、在Windows系統中的PerfMon來監控CPU，內在，swap、磁碟I/O等硬體資源；專門的核心監控軟體也可以在這一層面上被使用。在網路層上，網路工程師可以使用報文探測器（如tcpdump）。網路協定分析器（如ethereal），還有其它的工具（如netstat、MRTG、ntop、mii-tool）
負載壓力測試模擬網路連線環境
負載壓力測試模擬網路連線環境從測試的觀點來看，上面所有描述的活動都是一種白盒的方法，它對系統從內到外及多角度進行審查及監控。測度數據被取得及分析後，對系統的調整則成為理所當然的下一個步驟。然而，（除了上面的方法外）測試人員在給被測系統運行負載試驗（這裡為了不與我們所理解的負載測試-loadtesting的概念搞混，特譯做負載試驗）的時候，也採取了黑盒的方法。像對於WEB套用來講，測試人員可以使用工具來模擬並發用戶或者HTTP連線及測量回響時間。在我以前使用過的輕量級的負載測試開源工具有ab、siege、httperf。一個更重量級的工具是OpenSTA，但我沒用過。我也還沒有用過TheGrinder這個工具，但它在我將要做的事情中排名靠前。
當負載試驗的結果顯示出系統的性能來沒有達到它的預期目標時，這就是要對套用和資料庫的調整的時候了。同時你要確保讓你的代碼運行得儘可能高效，以及資料庫在給定的作業系統和硬體配置的情況下最最佳化。測試驅動開發（TDD）的實踐者會發現這種上下文結構框架是非常有用的，如可以通過負載試驗及時間試驗的函式性來增強現存單元測試代碼的MikeClark的jUnitPerf。當一個特定的函式或者方法被剖析過和調試過後，開發人員就可以在jUnitPerf中，放入它的單元試驗來確保它可以達到負載及時間上的性能需求。MikeClark稱這為“持續性能測試”。我順便也提一下我已經做了一個基於Python的jUnitPerf的初步研究，我稱之為pyUnitPerf。
負載壓力測試
負載壓力測試假若在調試過應用程式及資料庫後，系統還是沒有達到性能的預期目標，在這種情況下，還是有一些其它的調試的流程可以針對前面講過的那幾個層次來使用的。下面就是一些在應用程式代碼*之外仍可以提高WEB套用系統性能的例子：
使用WEB快取裝制，如Squid提供的裝置；
將高訪問量的網頁靜態化，以避免這些高訪問量對資料庫進行大量的調用；
在水平縮放資料庫群及將它們分為讀寫伺服器和唯讀伺服器後，還要對唯讀伺服器群負載平衡；
通過增加更多的硬體資源（CPU，記憶體，磁碟等）縱向的縮放WEB及資料庫伺服器群；
增加網路的頻寬。
由於現在的WEB套用系統都是十分複雜的系統，性能調試有時要具有一些藝術性才行。在每次修改一個變數及重新測度的時候一定要非常小心，否則的話，在變化中將會有很多難於確定和重複的不確定因素。在一個規範的測試環境比如說一個測試實驗試，它是不會常常的重現實際套用時的伺服器配置環境。在這樣的情況下，分段測試環境，也就是生產實際環境的一個子集就可以派上用場了。但同時系統的期望性能也需要相應的調低一點。“運行負載試驗->測度性能->調試系統”這個循環一直要被重複執行到被測試系統達到了期望的性能標準了才可以停。在這個時候，測試人員就可以明了在正常條件下的系統運轉怎么樣，同時這些就可以做為以後在回歸測試中，評價新版本的軟體性能的一個標準了。性能測試還有另一個目標就是建立一組被測系統的基準數據。在很多行業中都會有這種行業標準的基準數據，比如說TPC公布的。還有很多軟硬體廠家都為了在TCP排名中靠前而對他們的機器進行精心調試。所以說你應當非常謹慎的說明在你進行測試的時候，並沒有在種類繁多的軟硬體產品中進行全部測試。
負載壓力測試
負載壓力測試分析處理
分析原則：
1、具體問題具體分析（這是由於不同的套用系統，不同的測試目的，不同的性能關注點）
2、查找瓶頸時按以下順序，由易到難。
伺服器硬體瓶頸-〉網路瓶頸（對區域網路，可以不考慮）-〉伺服器作業系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，資料庫，web伺服器等）-〉套用瓶頸（SQL語句、資料庫設計、業務邏輯、算法等）註：以上過程並不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到套用系統在將來大的負載壓力（並發用戶數、數據量）下，系統的硬體瓶頸在哪兒就夠了。分段排除法很有效。
壓力測試工具軟體
壓力測試工具軟體分析的信息來源： 1、根據場景運行過程中的錯誤提示信息；
2、根據測試結果收集到的監控指標數據。
一、錯誤提示分析
分析實例：
1、Error:Failedtoconnecttoserver“10.10.10.30:8080″:[10060]Connection
Error:timedoutError:Server“10.10.10.30″hasshutdowntheconnectionprematurely
分析：
負載壓力測試
負載壓力測試A、套用服務死掉（小用戶時：程式上的問題。程式上處理資料庫的問題）
B、套用服務沒有死（套用服務參數設定問題）
例：在許多客戶端連線Weblogic套用伺服器被拒絕，而在伺服器端沒有錯誤顯示，則有可能是Weblogic中的server元素的AcceptBacklog屬性值設得過低。如果連線時收到connectionrefused訊息，說明應提高該值，每次增加25%
C、資料庫的連線（1、在套用服務的性能參數可能太小了；2、資料庫啟動的最大連線數（跟硬體的記憶體有關）。）
分析：可能是以下原因造成
二．監控指標數據分析
1、最大並發用戶數：
套用系統在當前環境（硬體環境、網路環境、軟體環境（參數配置））下能承受的最大並發用戶數。在方案運行中，如果出現了大於3個用戶的業務操作失敗，或出現了伺服器shutdown的情況，則說明在當前環境下，系統承受不了當前並發用戶的負載壓力，那么最大並發用戶數就是前一個沒有出現這種現象的並發用戶數。如果測得的最大並發用戶數到達了性能要求，且各伺服器資源情況良好，業務操作回響時間也達到了用戶要求，那么可行。否則，再根據各伺服器的資源情況和業務操作回響時間進一步分析原因所在。
2、業務操作回響時間：
分析方案運行情況應從平均事務回響時間圖和事務性能摘要圖開始。使用“事務性能摘要”圖，可以確定在方案執行期間回響時間過長的事務。細分事務並分析每個頁面組件的性能。如果伺服器耗時過長，請使用相應的伺服器圖確定有問題的伺服器度量並查明伺服器性能下降的原因。如果網路耗時過長，請使用“網路監視器”圖確定導致性能瓶頸的網路問題
3、伺服器資源監控指標： 記憶體：
1、UNIX資源監控中指標記憶體頁交換速率（Pagingrate），如果該值偶爾走高，表明當時有執行緒競爭記憶體。如果持續很高，則記憶體可能是瓶頸。也可能是記憶體訪問命中率低。
2、Windows資源監控中，如果Process\PrivateBytes計數器和Process\WorkingSet計數器的值在長時間內持續升高，同時Memory\Availablebytes計數器的值持續降低，則很可能存在記憶體泄漏。
記憶體資源成為系統性能的瓶頸的徵兆：很高的換頁率(highpageoutrate)；進程進入不活動狀態；交換區所有磁碟的活動次數可高；可高的全局系統CPU利用率；記憶體不夠出錯(outofmemoryerrors)。
處理器：
1、UNIX資源監控（Windows作業系統同理）中指標CPU占用率（CPUutilization），如果該值持續超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。如果伺服器專用於SQLServer，可接受的最大上限是80-85%合理使用的範圍在60%至70%。
2、Windows資源監控中，如果System\ProcessorQueueLength大於2，而處理器利用率（ProcessorTime）一直很低，則存在著處理器阻塞。
磁碟I/O：
1、UNIX資源監控（Windows作業系統同理）中指標磁碟交換率（Diskrate），如果該參數值一直很高，表明I/O有問題。可考慮更換更快的硬碟系統。
2、Windows資源監控中，如果DiskTime和Avg.DiskQueueLength的值很高，而PageReads/sec頁面讀取操作速率很低，則可能存在磁碟瓶徑。
I/O資源成為系統性能的瓶頸的徵兆： 過高的磁碟利用率(highdiskutilization)；
太長的磁碟等待佇列(largediskqueuelength)；
等待磁碟I/O的時間所占的百分率太高(largepercentageoftimewaitingfordiskI/O)；
太高的物理I/O速率：largephysicalI/Orate(notsufficientinitself)；
過低的快取命中率(lowbuffercachehitratio(notsufficientinitself))；
太長的運行進程佇列，但CPU卻空閒(largerunqueuewithidleCPU)。
4、資料庫伺服器：
SQLServer資料庫：
1、SQLServer資源監控中指標快取點擊率（CacheHitRatio），該值越高越好。如果持續低於80%，應考慮增加記憶體。
2、如果FullScans/sec（全表掃描/秒）計數器顯示的值比1或2高，則應分析你的查詢以確定是否確實需要全表掃描，以及SQL查詢是否可以被最佳化。
3、NumberofDeadlocks/sec(死鎖的數量/秒)：死鎖對應用程式的可伸縮性非常有害，並且會導致惡劣的用戶體驗。該計數器的值必須為0。
4、LockRequests/sec(鎖請求/秒)，通過最佳化查詢來減少讀取次數，可以減少該計數器的值。
快存（共享SQL區）和數據字典快存的命中率： select(sum(pins-reloads))/sum(pins)fromv$librarycache；
select(sum(gets-getmisses))/sum(gets)fromv$rowcache；
自由記憶體：select*fromv$sgastatwherename=‘freememory’。
2、如果數據的快取命中率小於0.90，那么需要加大DB_BLOCK_BUFFERS參數的值（單位：塊）。
緩衝區高速快取命中率：selectname,valuefromv$sysstatwherenamein(‘dbblockgets’，‘consistentgets’‘physicalreads’)HitRatio=1-(physicalreads/(dbblockgets+consistentgets))。
3、如果日誌緩衝區申請的值較大，則應加大LOG_BUFFER參數的值。
日誌緩衝區的申請情況：selectname，valuefromv$sysstatwherename=‘redologspacerequests’。
4、如果記憶體排序命中率小於0.95，則應加大SORT_AREA_SIZE以避免磁碟排序。
記憶體排序命中率：selectround((100*b.value)/decode((a.value+b.value)，0，1，(a.value+b.value)),2)fromv$sysstata，v$sysstatbwherea .name=’sorts(disk)’andb .name=’sorts(memory)’
註：上述SQLServer和Oracle資料庫分析，只是一些簡單、基本的分析，特別是Oracle資料庫的分析和最佳化，是一門專門的技術，進一步的分析可查相關資料。
