web性能测试基础 知识（引用）
1.1基本概念
并發(fā)用戶：用戶并發(fā)一般發(fā)生在使用比較頻繁的模塊中，而且遇到異常通常都是程序的問題。
用戶并發(fā)數(shù)量：在線用戶數(shù)量是計算并發(fā)用戶數(shù)量的主要依據(jù)之一。=使用系統(tǒng)的用戶數(shù)量*(5%~20%)
并發(fā)主要針對WEB服務器而言，是否并發(fā)的關鍵是看用戶的操作是否對服務器產生了影響。
吞吐量：一次性能測試過程中網(wǎng)絡上傳輸?shù)臄?shù)據(jù)量的總和。
吞吐率:吞吐量/傳輸時間，單位時間內網(wǎng)絡上傳輸?shù)臄?shù)據(jù)量，也可以指單位時間內處理的客戶端請求數(shù)量。吞吐率用“請求數(shù)/秒”或者“頁面數(shù)/秒”來衡量。
點擊率：每秒鐘用戶向web服務器提交的HTTP請求數(shù)。點擊率越大，對服務器的壓力也越大。重要的是分析點擊時產生的影響。
點擊不是指鼠標的一次“單擊”操作，因為在一次“單擊”操作中，客戶端可能向服務器發(fā)出多個HTTP請求。
1.2WEB性能測試種類
壓力測試：確定一個系統(tǒng)的瓶頸或者不能接收用戶請求的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。
負載測試：在被測系統(tǒng)上不斷增加壓力 ，直到性能指標達到極限，響應時間超過預定指標或者某種資源已經達到飽和狀態(tài)。這種測試可以找到系統(tǒng)的處理極限，為系統(tǒng)調優(yōu)提供依據(jù)。
大數(shù)據(jù)量測試：針對某些系統(tǒng)存儲、傳輸、統(tǒng)計查詢等業(yè)務進行大數(shù)據(jù)量的測試。
配置測試：通過測試找到系統(tǒng)各資源的最優(yōu)分配原則。
可靠性測試：可以施加cpu資源保持70%-90%使用率的壓力，連續(xù)對系統(tǒng)加壓運行8小時，然后根據(jù)結果分析系統(tǒng)是否穩(wěn)定。即加載一定壓力的情況下，使系統(tǒng)運行一段時間。
并發(fā)測試：多以發(fā)現(xiàn)一些算法設計上的問題。
性能測試以用戶并發(fā)測試為主的測試。
性能測試主要是為了發(fā)現(xiàn)軟件問題和硬件瓶頸。
對于性能方面給系統(tǒng)留有30%左右的擴展空間即可。????????????????????????????????????
1.3Web全面性能測試模型
1.3.1預期指標的性能測試
主要指需求分析和設計階段提出的一些性能指標。
針對每個指標都要編寫一個或者多個測試用例來驗證系統(tǒng)是否達到要求。
預期指標的性能測試用例通常以單用戶為主，如果涉及并發(fā)用戶內容，則歸并到并發(fā)用戶測試用例中進行設計。
1.3.2并發(fā)性能測試
選擇具有代表性、關鍵的業(yè)務來設計用例，并且用戶的設計應該面向“模塊”
用戶并發(fā)性能測試分為：獨立核心模塊并發(fā)性能測試，組合模塊并發(fā)性能測試
獨立核心模塊并發(fā)：完全一樣功能的并發(fā)測試；完全一樣操作的并發(fā)測試；相同/不同的子功能并發(fā)。
針對獨立核心模塊用戶并發(fā)性能的測試用例設計，可發(fā)現(xiàn)一些核心算法或者功能方面的問題，如一些多線程、同步并發(fā)算法在單用戶模式下測試是很難發(fā)現(xiàn)問題的，通過模擬多用戶的并發(fā)操作，更容易驗證其是否正確和穩(wěn)定。
核心模塊測試一般屬于基本的性能測試，它較多地關注模擬的“功能”，一般不會對服務器進行測試。
?
組合模塊并發(fā)：具有耦合關系的核心模塊進行組合并發(fā)測試；彼此獨立的、內部具有耦合關系的核心模塊組的并發(fā)測試；基于用戶場景的并發(fā)測試。
組合模塊測試一般發(fā)現(xiàn)接口方面的功能問題，并盡早發(fā)現(xiàn)綜合性能問題。
在實際中，各種類型的用戶都會對應一組模塊，相當于不同的業(yè)務組在并發(fā)訪問系統(tǒng)，要充分考慮實際場景，如話費管理系統(tǒng)中的每月10日左右的收費高峰等場景。
在編寫組合模塊用戶并發(fā)性能測試用例時，不但要考慮用戶使用場景，還要注意并發(fā)點的運用，并發(fā)點是指一定數(shù)量的用戶開始執(zhí)行同一功能或者操作的時間點，一組測試場景通常包含多個并發(fā)點，從而實現(xiàn)了核心模塊同一功能或者操作的真正并發(fā)。
?
1.3.3獨立業(yè)務性能測試
獨立業(yè)務實際是指一些核心業(yè)務模塊對應的業(yè)務。這些模塊通常具有功能比較復雜，使用比較頻繁，屬于核心業(yè)務等特點。主要測試這類模塊和性能相關的一些算法、還要測試這類模塊對并發(fā)用戶的響應情況。
用戶并發(fā)測試是核心業(yè)務模塊的重點測試內容。
1.3.4組合業(yè)務性能測試
是最接近用戶實際使用情況的測試，也是性能測試的核心內容。
組合并發(fā)的突出特點是根據(jù)用戶使用系統(tǒng)的情況分成不同的用戶組進行并發(fā)，每組的用戶比例要根據(jù)實際情況來進行匹配。
用戶并發(fā)測試是組合業(yè)務性能測試的核心內容。“組合”并發(fā)的突出特點是根據(jù)用戶使用系統(tǒng)的情況分成不同的用戶組進行并發(fā)，每組的用戶比例要根據(jù)實際情況來進行匹配。
1.3.5網(wǎng)絡性能測試
為準確展未帶寬、延遲、負載和端口的變化是如何影響用戶的響應時間的。主要是測試應用系統(tǒng)的用戶數(shù)目與網(wǎng)絡帶寬的關系。
調整性能最好的辦法就是軟硬相結合。
1.3.6大數(shù)據(jù)量測試
主要是針對對數(shù)據(jù)庫有特殊要求的系統(tǒng)進行的測試，主要分為三種：
1．實時大數(shù)據(jù)量：模擬用戶工作時的實時大數(shù)據(jù)量，主要目的是測試用戶較多或者某些業(yè)務產生較大數(shù)據(jù)量時，系統(tǒng)能否穩(wěn)定地運行。
2．極限狀態(tài)下的測試：主要是測試系統(tǒng)使用一段時間即系統(tǒng)累積一定量的數(shù)據(jù)時，能否正常地運行業(yè)務
3．前面兩種的結合：測試系統(tǒng)已經累積較大數(shù)據(jù)量時，一些實時產生較大數(shù)據(jù)量的模塊能否穩(wěn)定地工作。
大數(shù)據(jù)量測試用例的設計:1,歷史數(shù)據(jù)引起的大數(shù)據(jù)量測試和2運行時大數(shù)據(jù)量測試
首先確定系統(tǒng)數(shù)據(jù)的最長遷移周期和選擇一些前面的核心模塊或者組合模塊的并發(fā)用戶測試用例作為其主要內容即可.
1.3.7服務器性能測試
性能測試的主要目的是在軟件功能良好的前提下，發(fā)現(xiàn)系統(tǒng)瓶頸并解決，而軟件和服務器是產生瓶頸的兩大來源，因此在進行用戶并發(fā)性能測試，疲勞強度與大數(shù)據(jù)量性能測試時，完成對服務器性能的監(jiān)控，并對服務器性能進行評估。
服務器性能測試用例設計就是確定要采集的性能計數(shù)器，并將其與前面的測試關聯(lián)起來。
1.3.8設計性能測試用例注意的原則：
可以滿足預期性能指標測試用例要求的，就沒有必要設計更多的內容，因為用例越多，執(zhí)行的成本也越高。
一定要服從整體性能測試策略，千萬不能僅從技術角度來考慮設計“全面”的測試用例，“全面”應該以是否滿足自己的測試要求作為標準。
適當裁剪原則
只有根據(jù)實際項目的特點制定合理的性能測試策略、編寫適當?shù)男阅軠y試用例，并在測試實施中靈活地變通才可以做好性能測試工作。
測試計劃：主要包含測試范圍、測試環(huán)境、測試方案簡介、風險分析等，測試計劃要進行評審后方可生效。
測試報告：主要包含測試過程記錄、測試分析結果、系統(tǒng)調整建議等。
測試經驗總結：不斷總結工作經驗是建立學習型團隊的基礎，實踐－總結－再實踐
2.1人員之間的配合關系
客戶代表：可了解一些項目的背景知識，例如客戶在軟件性能方面的需求，是否關注性能測試等，這些都是制定性能測試策略的依據(jù)。
需求分析員：確定哪些業(yè)務是核心業(yè)務，為后面編寫核心業(yè)務模塊相關的測試用例打下良好的基礎，并且他們對用戶群體構成以及系統(tǒng)的擴展目標較清楚，這些都是設計性能測試的數(shù)據(jù)來源。
架構師：了解系統(tǒng)的結構，使設計出的性能測試用例在“恰當”的地方施壓。
2.2性能測試的范圍確定
對測試項或測試需求進行打分，根據(jù)綜合評分確定性能測試工作包含的測試內容，評分要素主要包含客戶關注度、性能風險、測試的成本等，性能風險主要指如果不進行該項性能測試需求，投產系統(tǒng)可能潛在的風險。
客戶關注程度或者性能風險較高的均應劃分到測試范圍內。
?
| 編號 | 測試需求 | 性能風險 (10分) | 用戶關注度(10分) | 成本投入 (10分) | 總分 |
| 1 | 系統(tǒng)運轉一年的數(shù)據(jù)量測試 | 7 | 10 | 6 | 23 |
| 2 | …… | …… | ? | ? | ? |
2.3目標系統(tǒng)的業(yè)務分析
確定系統(tǒng)的核心模塊：業(yè)務比較復雜或用戶使用較頻繁
確定模塊件的耦合關系：清晰了解核心模塊間數(shù)據(jù)傳輸方式，通過確定模塊間如何接口，可以真實地模擬多用戶并發(fā)時的情況，尤其可以確定用戶并發(fā)時一些算法是否正確。
分析系統(tǒng)壓力點：多是用戶使用較頻繁或數(shù)據(jù)流量較大的地方。
2.4用戶及場景分析
一，基于用戶實際使用情況的場景測試，二，為了特殊測試目的(擴展性、穩(wěn)定性)而設計的場景測試。
確定系統(tǒng)有多少類典型的用戶，每類用戶的大概數(shù)量以及在不同時間段各類用戶大概按照何種比例來使用系統(tǒng)。較常見的用戶場景有如下三種：
一天內不同時間段的使用場景
系統(tǒng)運行不同時期的場景
不同業(yè)務模式下的用戶場景
2.5整體規(guī)劃
性能測試規(guī)劃的重點是時間、質量、成本等項目管理要素。
2.5.1常見的性能測試工具
Loadrunner:是一種預測系統(tǒng)行為和性能的負載測試工具,目前很多公司執(zhí)行性能測試的首選工具.
Rational performance: rational 系列產品之一,功能非常強大,和loadrunner競爭比較激烈.
QALoad:compu ware 公司的產品
Webload:專門用于web性能測試的工具
WAS:全稱是Microsoft Web Application Stress Tool,微軟提供的免費性能測試工具
Apache JMeter :開源的性能測試工具
openSTA:開源的性能測試工具
2.5.2測試結果記錄規(guī)范管理
測試結果數(shù)據(jù)是分析系統(tǒng)瓶頸的主要依據(jù),大量的測試結果文件要進行規(guī)范管理,統(tǒng)一文件的命名規(guī)范.例如:2007-1-12-dbtest-oracleserver-50-once
2.5.3測試環(huán)境管理與維護
執(zhí)行性能測試盡量不要破壞用戶環(huán)境,而且要預先制定相應的備份/恢復策略,以便系統(tǒng)發(fā)生意外時可以恢復到測試前的狀態(tài).
性能測試很有可能產生大量的垃圾數(shù)據(jù),消除垃圾數(shù)據(jù)是測試結事后首當其沖的工作
測試時還要監(jiān)控測試機的使用情況,除非保證場景消耗的資源不會超出測試機的負載能力,否則就應該認真監(jiān)控測試機,因為一旦測試機發(fā)生瓶頸,所有測試結果均無實際意義.
2.5.4測試分析與經驗總結
主要關注性能測試規(guī)劃與設計、測試用例設計、測試工具與技術、性能分析等方面。
性能測試用例的設計分析：可用性、執(zhí)行效果、執(zhí)行時間、還應該分析用例的設計方法、設計思路等。
對于瓶頸：應用系統(tǒng)、數(shù)據(jù)庫、web服務器等有時會因配置參數(shù)不正確導致系統(tǒng)性能不高，可積累解決這方面問題的經驗，以便于以后快速解決問題。
1．隨著壓力的加大，吞吐率的曲線在增加到一定的時候，出現(xiàn)變化緩慢，甚至平坦的狀態(tài)，很有可能標明網(wǎng)絡出現(xiàn)帶寬瓶頸。類似地，當壓力加大時，點擊率/TPS曲線出現(xiàn)變化緩慢或平坦的趨勢，很有可能服務器開始出現(xiàn)瓶頸。
2．吞吐率與TPS具有很強的關聯(lián)性：如果隨著壓力的加大，吞吐率和TPS的變化呈大體一致的趨勢，即一起增加，說明在測試的壓力下，系統(tǒng)沒有出現(xiàn)顯著的性能瓶頸。
3.1性能分析的步驟
1．首先從響應時間做為分析性能的起點。查看響應時間以判斷是否滿足用戶對性能的期望。
2．考察系統(tǒng)的瓶頸是在網(wǎng)絡環(huán)節(jié)還是在服務器環(huán)節(jié)。
針對服務器分析主要涉及應用程序、web服務器、數(shù)據(jù)庫服務器、操作系統(tǒng)等。
首先應該分析業(yè)務或者用戶事務的響應時間，根據(jù)測試結果來分析哪些業(yè)務真正變慢了，然后分析web資源的處理情況，最后對頁面組成元素的響應時間進行分解。
3.1.1用戶事務分析
1．查看結果綜述圖：查看事務的平均響應時間，以及事務的通過率
2．查看事務綜述圖和事務平均響應時間分析圖：查看事務通過和失敗的數(shù)值，來判斷是程序算法出現(xiàn)問題還是服務器存在內存泄漏現(xiàn)象。
3．每秒通過事務數(shù)分析圖：可確定系統(tǒng)在任何給定時刻的實際事務負載。當發(fā)現(xiàn)每秒通過的事務數(shù)減少時，就需要更加深入的分析，配合服務器監(jiān)控數(shù)據(jù)一起分析。
4．事務性能摘要圖：重點關注事務的平均和最大執(zhí)行時間，如果其范圍不在用戶可以接受的時間范圍內，需要進行原因分析。
5．事務響應時間與負載分析圖：正在運行的虛擬用戶和平均事務響應時間圖的組合，通過它可以看出在任一時間點事務響應時間與用戶數(shù)目的關系，從而掌握系統(tǒng)在用戶并發(fā)方面的性能數(shù)據(jù)，為擴展應用系統(tǒng)提供參考，對分析具有漸變負載的測試場景比較有用。
6．事務響應時間分布情況分布圖：預先定義相關事務可以接受的最小和最大事務響應時間，則可以使用此圖確定服務器性能是否在可以接受的范圍內。
3.1.2web資源分析
1．點擊率圖：每秒點擊次數(shù)，即點擊率圖顯示在場景運行過程中虛擬用戶每秒向web服務器提交的HTTP請求數(shù)，可依據(jù)點擊次數(shù)來評估虛擬用戶產生的負載量，還可將其與”平均事務響應時間”圖進行比較，以查看點擊次數(shù)對事務性能產生的影響。
系統(tǒng)點擊率下降通常表明服務器的響應速度在變慢。
2．吞吐率圖：顯示場景運行過程中服務器每秒的吞吐量。度量單位是字節(jié)，表示虛擬用戶在任何給定的某一秒上從服務器獲得的數(shù)據(jù)量。
點擊率：每秒服務器處理的HTTP申請數(shù)
吞吐率：客戶端每秒從服務器獲得的總數(shù)據(jù)量。
每秒HTTP響應數(shù)圖還能返回其他各類狀態(tài)碼信息，通過分析狀態(tài)碼，可以判斷服務器在壓力下的運行情況。
常見的http狀態(tài)代碼：從200-505均有其含義。如202：已經接受請求，但處理尚未完成。
3．每秒連接數(shù)圖：顯示在運行過程中每秒新建立的TCP/IP連接數(shù)。新連接數(shù)應該是每秒點擊次數(shù)的一小部分，理想情況下，很多的HTTP請求都應該使用同一連接，而不是每個請求都新打開一個連接。
3.1.3網(wǎng)頁元素細分
通過它可深入地分析網(wǎng)站上那些下載很慢的圖像或中斷的鏈接等有問題的元素。
頁面分解總圖：可顯示某一具體事務在測試過程的響應情況，進而分析相關的事務運行是否正常。
1．下載時間細分：查看靜態(tài)gif圖片和動態(tài)的jsp代碼。
2．組件細分（隨時間變化）：可以選擇不同的元素查看測試過程中其下載時間的變化曲線。適用于需要在客戶端下載控制較多的頁面，通過分析控件的響應時間，很容易就能發(fā)現(xiàn)哪些控件不穩(wěn)定或者比較耗時。
3．下載時間細分（隨時間變化）：查看jsp頁面主要時間花在如receive,first buffer,connection等。
下載時間細分：宏觀，整個測試過程頁面元素響應時間的統(tǒng)計分析結果
下載時間細分（隨時間變化）：微觀，顯示場景運行過程中每一秒內頁面元素響應時間的統(tǒng)計結果。
4．第一次緩沖時間細分（隨時間變化）：可查看頁面運行時間主要花在服務器還是網(wǎng)絡傳輸上。
?
服務器分析通常從web服務器和數(shù)據(jù)庫服務器入手。
服務器分析的第一步，分析測試工具對web服務器和數(shù)據(jù)庫服務器相關計數(shù)器的監(jiān)控結果，然后確定在壓力下是web服務較慢還是數(shù)據(jù)處理較慢。
Web服務較慢：查看web服務器的各種參數(shù)配置，如最大連接數(shù)、最大內存等是否設置的合理。查看內存、CPU、硬盤
數(shù)據(jù)處理較慢：一般是數(shù)據(jù)庫配置發(fā)生問題，或是硬件資源配置太低。如oracle,要查看內存配置、運行模式等信息。
?
4.1數(shù)據(jù)庫調優(yōu)策略
1．修改sql語句中影響速度的寫法
2．增加或者修改索引
???針對表間的連接創(chuàng)建索引
???針對查找建立索引
???使用索引時，遵守以下原則可達到更好的效果
???第一：一般建立在多個字段上的一個組合索引優(yōu)于針對單個字段建立的多個索引，根據(jù)值匹配條件創(chuàng)建的索引也需要遵循同樣的原則：
???第二：創(chuàng)建組合索引時，精確匹配的字段放在非精確匹配字段前面，取值范圍大的字段放在取值范圍小的字段前面，可以提高查詢速度，如身份證字段應該放在性別字段前面。
???第三：索引并不是越多越好，當數(shù)據(jù)庫記錄較多時，意味著數(shù)據(jù)庫要付出的開銷將會很大，從而降低數(shù)據(jù)庫其他方面的性能。
3．調整相應數(shù)據(jù)庫的系統(tǒng)參數(shù)（系統(tǒng)投產生的調優(yōu)，通常由廠商的配合完成）
一般檢查項為：復雜語句支持，大對象功能支持，并發(fā)查詢性能，吞吐量，數(shù)據(jù)遷移（導出備份）。
4.2weblogic/oracle相關分析
主要監(jiān)控：%processor, Avalable Mbytes(空閑內存), JVM內存，connection Delay Time（數(shù)據(jù)庫連接池建立數(shù)據(jù)庫連接的時間）
Oracle運行平臺AIX監(jiān)控（unix），cpu的使用率（cpu utilization），disk traltic(磁盤負載)，page-in,page-out rate的使用情況。
以及oracle本身相關報告：相看緩沖區(qū)調整緩存，應用程序的i/o操作。
4.3性能測試用例設計要基于用戶語言
即滿足用戶要求又相對全面的性能測試用例，設計時要基于“用戶語言”，易于用戶理解的、大綱形 式的測試用例，這樣涉及的技術語言不多，用戶很容易看懂。這樣使得用戶在現(xiàn)場測試階段能夠提出很多改進建議，并同意對用例進行調整（刪減近一半的用例）， 可以為后期執(zhí)行測試節(jié)約成本。
性能測試實施的特點之一就是不會嚴格按照測試用例來執(zhí)行，通常是在項目中對用戶進行一定的調整，然后再去執(zhí)行，對于測試用例進行調整，刪除、修改、增加，這是很正常的，基本成本來進行設計和執(zhí)行。
轉載于:https://www.cnblogs.com/zyp1/p/5784986.html
總結
以上是生活随笔為你收集整理的web性能测试基础 知识（引用）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： redis命令学习
- 下一篇： FZU Problem 2238 Dax