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