基本概述
負載壓力測試中動態參數關聯1、性能測試
性能測試用來保證產品發布後系統的性能能夠滿足用戶需求。其中系統性能包括執行效率、資源占用、穩定性、安全性、兼容性、可擴展性、可靠性等。
2、性能評測
負載壓力測試結構剖析性能評測包括：在真實環境下，檢查系統服務等級的滿足情況，評估並報告整個系統的性能；對系統的未來容量作出預測和規劃。
3、性能調優
性能調優一般的步驟為首先查找形成系統瓶頸或者故障的根本原因，其次是進行性能調整和最佳化，最後便是評估性能調整的結果。
4、負載測試
負載測試時通過逐步增加系統負載，測試系統性能的變化，並最終確定在滿足性能指標的情況下，系統所能承受的最大負載量的測試。
負載壓力測試工具壓力測試是通過逐步增加系統負載，測試系統性能的變化，並最終確定在什麼負載條件下系統性能處於失效狀態，並以此來獲得系統能提供的最大服務級別的測試。
6、並發性測試
並發性測試的過程，是一個負載測試和壓力測試的過程。即逐漸增加並發用戶數負載，直到系統的瓶頸或者不能接收的性能點。並發性測試分為三類：
a、套用在客戶端性能的測試；
b、套用在網路上性能的測試；
c、套用在伺服器上性能的測試；
7、疲勞強度測試
8、大數據量測試
大數據量測試包括獨立的數據量測試和綜合數據量測試兩類。
負載測試
伺服器負載測試容量測試的例子：
通過編輯一個巨大的檔案來測試文字處理軟體；
通過傳送一個巨大的作業來測試印表機；
通過成千上萬的用戶信箱來測試郵件伺服器；
有一種比較特別的容量測試是叫作“零容量測試”，它是給系統加上空任務來測試的。
耐久性測試/持久性測試的的例子：在一個循環中不停的運行客戶端超過一個擴展時間段。
負載測試的目的：
找到一些在測試流程中前面的階段所進行的粗略測試中沒有被找出的bugs，例如，記憶體管理bugs，記憶體泄露，緩衝器溢出等等。保證應用程式達到性能測試中確定的性能基線。這個可以在運行回歸試驗時，通過載入特定的最大限度的負載來實現。儘管性能測試和負載測試似乎很像，但他們的目的還是有差異的。一方面，性能測試使用負載測試的技術，工具，以及用不同的負載程度來測度和基準化系統。在另一方面來講，負載測試是在一些已經定義好的負載程度上進行測試的，通常對系統加上最大負載之後，系統應該仍然可以提供全部功能。這裡需要明確一點，負載測試並不是要對系統載入上過度的負載而使系統不能工作，而是要使系統像一個上滿了油的機器嗡嗡叫。
在負載測試的相關內容中，我想應該非常重要的是要有十分充足的數據來進行測試。從我的經驗中得知，假若不用非常大的數據*去測的話，有很多嚴重的bug是不會的到的。比如說，LDAP/NIS/ActiveDirectory資料庫中成千上萬的用戶，郵件伺服器中成千上萬的信箱，資料庫中成G成G的表，檔案系統中很深的檔案或者目錄的層次，等等。顯然，測試人員就需要使用自動化工具來產生這些龐大的數據集，比較幸運的是任何優秀的腳本語言都可以勝任這些工作。
壓力測試
負載壓力測試站點測試工具當性能測試需要的是一個可控制的環境和不斷的測度的時候，壓力測試則是令為歡喜的引起混亂及不可預測性（譯者按：從這一點可以看出作者是一個很優秀的測試人員）。還是舉WEB套用系統為例，下面是一些對系統可行的壓力測試方法：兩倍的已經基線的並發用戶數或者HTTP連線數；隨機的關閉及重開連線到伺服器上的網路上集線器/路由器的連線埠（例如，可以通過SNMP命令來實現）；把資料庫斷線然後再重啟；當系統還在運行的時候，重建一個RAID陣列；在WEB和資料庫伺服器上運行消耗資源（如CPU，記憶體，磁碟，網路）的進程。
性能測試
負載壓力測試在作業系統層，系統工程師可以使用一些工具如在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提供的裝置；
將高訪問量的網頁靜態化，以避免這些高訪問量對資料庫進行大量的調用；
通過負載平衡的方法來水平縮放WEB伺服器的結構；
在水平縮放資料庫群及將它們分為讀寫伺服器和唯讀伺服器後，還要對唯讀伺服器群負載平衡；
通過增加更多的硬體資源（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、資料庫啟動的最大連線數（跟硬體的記憶體有關）。）
分析：可能是以下原因造成
A、套用服務參數設定太大導致伺服器的瓶頸；B、頁面中圖片太多；C、在程式處理表的時候檢查欄位太大多。
二．監控指標數據分析
1、最大並發用戶數：
套用系統在當前環境（硬體環境、網路環境、軟體環境（參數配置））下能承受的最大並發用戶數。在方案運行中，如果出現了大於3個用戶的業務操作失敗，或出現了伺服器shutdown的情況，則說明在當前環境下，系統承受不了當前並發用戶的負載壓力，那么最大並發用戶數就是前一個沒有出現這種現象的並發用戶數。如果測得的最大並發用戶數到達了性能要求，且各伺服器資源情況良好，業務操作回響時間也達到了用戶要求，那么可行。否則，再根據各伺服器的資源情況和業務操作回響時間進一步分析原因所在。
2、業務操作回響時間：
分析方案運行情況應從平均事務回響時間圖和事務性能摘要圖開始。使用“事務性能摘要”圖，可以確定在方案執行期間回響時間過長的事務。細分事務並分析每個頁面組件的性能。如果伺服器耗時過長，請使用相應的伺服器圖確定有問題的伺服器度量並查明伺服器性能下降的原因。如果網路耗時過長，請使用“網路監視器”圖確定導致性能瓶頸的網路問題
負載壓力測試記憶體：
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）一直很低，則存在著處理器阻塞。
CPU資源成為系統性能的瓶頸的徵兆：很慢的回響時間(slowresponsetime)；CPU空閒時間為零(zeropercentidleCPU)；過高的用戶占用CPU時間(highpercentuserCPU)；過高的系統占用CPU時間(highpercentsystemCPU)；長時間的有很長的運行進程佇列(largerunqueuesizesustainedovertime)。
磁碟I/O：
1、UNIX資源監控（Windows作業系統同理）中指標磁碟交換率（Diskrate），如果該參數值一直很高，表明I/O有問題。可考慮更換更快的硬碟系統。
2、Windows資源監控中，如果DiskTime和Avg.DiskQueueLength的值很高，而PageReads/sec頁面讀取操作速率很低，則可能存在磁碟瓶徑。
壓力測試工具軟體過高的磁碟利用率(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(鎖請求/秒)，通過最佳化查詢來減少讀取次數，可以減少該計數器的值。
1、如果自由記憶體接近於0而且庫快存或數據字典快存的命中率小於0.90，那么需要增加SHARED_POOL_SIZE的大小。
負載壓力測試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資料庫的分析和最佳化，是一門專門的技術，進一步的分析可查相關資料。
軟體測試
| 軟體測試定義是：為了發現程式中的錯誤而執行程式的過程.它是幫助識別開發完成（中間或最終的版本）的計算機軟體（整體或部分）的正確度(correctness) 、完全度(completeness)和質量(quality)的軟體過程；是SQA(software quality assurance)的重要子域。希望在完成這個詞條的同時，與大家共同學習。 |
