Web效能測試種類與全面測試模型
WEB效能測試種類
壓力測試:確定一個系統的瓶頸或者不能接收使用者請求的效能點,來獲得系統能提供的最大服務級別的測試。
負載測試:在被測系統上不斷增加壓力 ,直到效能指標達到極限,響應時間超過預定指標或者某種資源已經達到飽和狀態。這種測試可以找到系統的處理極限,為系統調優提供依據。
大資料量測試:針對某些系統儲存、傳輸、統計查詢等業務進行大資料量的測試。
配置測試:通過測試找到系統各資源的最優分配原則。
可靠性測試:可以施加cpu資源保持70%-90%使用率的壓力,連續對系統加壓執行8小時,然後根據結果分析系統是否穩定。即載入一定壓力的情況下,使系統執行一段時間。
併發測試:多以發現一些演算法設計上的問題。
效能測試以使用者併發測試為主的測試。
效能測試主要是為了發現軟體問題和硬體瓶頸。
對於效能方面給系統留有30%左右的擴充套件空間即可。
Web全面效能測試模型
預期指標的效能測試
主要指需求分析和設計階段提出的一些效能指標。
針對每個指標都要編寫一個或者多個測試用例來驗證系統是否達到要求。
預期指標的效能測試用例通常以單使用者為主,如果涉及併發使用者內容,則歸併到併發使用者測試用例中進行設計。
併發效能測試
選擇具有代表性、關鍵的業務來設計用例,並且使用者的設計應該面向“模組”
使用者併發效能測試分為:獨立核心模組併發效能測試,組合模組併發效能測試
獨立核心模組併發:完全一樣功能的併發測試;完全一樣操作的併發測試;相同/不同的子功能併發。
針對獨立核心模組使用者併發效能的測試用例設計,可發現一些核心演算法或者功能方面的問題,如一些多執行緒、同步併發演算法在單使用者模式下測試是很難發現問題的,通過模擬多使用者的併發操作,更容易驗證其是否正確和穩定。
核心模組測試一般屬於基本的效能測試,它較多地關注模擬的“功能”,一般不會對伺服器進行測試。
組合模組併發:具有耦合關係的核心模組進行組合併發測試;彼此獨立的、內部具有耦合關係的核心模組組的併發測試;基於使用者場景的併發測試。
組合模組測試一般發現介面方面的功能問題,並儘早發現綜合效能問題。
在實際中,各種型別的使用者都會對應一組模組,相當於不同的業務組在併發訪問系統,要充分考慮實際場景,如話費管理系統中的每月10日左右的收費高峰等場景。
在編寫組合模組使用者併發效能測試用例時,不但要考慮使用者使用場景,還要注意併發點的運用,併發點是指一定數量的使用者開始執行同一功能或者操作的時間點,一組測試場景通常包含多個併發點,從而實現了核心模組同一功能或者操作的真正併發。
獨立業務效能測試
獨立業務實際是指一些核心業務模組對應的業務。這些模組通常具有功能比較複雜,使用比較頻繁,屬於核心業務等特點。主要測試這類模組和效能相關的一些演算法、還要測試這類模組對併發使用者的響應情況。
使用者併發測試是核心業務模組的重點測試內容。
組合業務效能測試
是最接近使用者實際使用情況的測試,也是效能測試的核心內容。
組合併發的突出特點是根據使用者使用系統的情況分成不同的使用者組進行併發,每組的使用者比例要根據實際情況來進行匹配。
使用者併發測試是組合業務效能測試的核心內容。“組合”併發的突出特點是根據使用者使用系統的情況分成不同的使用者組進行併發,每組的使用者比例要根據實際情況來進行匹配。
網路效能測試
為準確展未頻寬、延遲、負載和埠的變化是如何影響使用者的響應時間的。主要是測試應用系統的使用者數目與網路頻寬的關係。
調整效能最好的辦法就是軟硬相結合。
大資料量測試
主要是針對對資料庫有特殊要求的系統進行的測試,主要分為三種:
1.實時大資料量:模擬使用者工作時的實時大資料量,主要目的是測試使用者較多或者某些業務產生較大資料量時,系統能否穩定地執行。
2.極限狀態下的測試:主要是測試系統使用一段時間即系統累積一定量的資料時,能否正常地執行業務
3.前面兩種的結合:測試系統已經累積較大資料量時,一些實時產生較大資料量的模組能否穩定地工作。
大資料量測試用例的設計:1,歷史資料引起的大資料量測試和2執行時大資料量測試
首先確定系統資料的最長遷移週期和選擇一些前面的核心模組或者組合模組的併發使用者測試用例作為其主要內容即可.
伺服器效能測試
效能測試的主要目的是在軟體功能良好的前提下,發現系統瓶頸並解決,而軟體和伺服器是產生瓶頸的兩大來源,因此在進行使用者併發效能測試,疲勞強度與大資料量效能測試時,完成對伺服器效能的監控,並對伺服器效能進行評估。
伺服器效能測試用例設計就是確定要採集的效能計數器,並將其與前面的測試關聯起來。
設計效能測試用例注意的原則:
可以滿足預期效能指標測試用例要求的,就沒有必要設計更多的內容,因為用例越多,執行的成本也越高。
一定要服從整體效能測試策略,千萬不能僅從技術角度來考慮設計“全面”的測試用例,“全面”應該以是否滿足自己的測試要求作為標準。
適當裁剪原則
只有根據實際專案的特點制定合理的效能測試策略、編寫適當的效能測試用例,並在測試實施中靈活地變通才可以做好效能測試工作。
測試計劃:主要包含測試範圍、測試環境、測試方案簡介、風險分析等,測試計劃要進行評審後方可生效。
測試報告:主要包含測試過程記錄、測試分析結果、系統調整建議等。
測試經驗總結:不斷總結工作經驗是建立學習型團隊的基礎,實踐-總結-再實踐
壓力測試:確定一個系統的瓶頸或者不能接收使用者請求的效能點,來獲得系統能提供的最大服務級別的測試。
負載測試:在被測系統上不斷增加壓力 ,直到效能指標達到極限,響應時間超過預定指標或者某種資源已經達到飽和狀態。這種測試可以找到系統的處理極限,為系統調優提供依據。
大資料量測試:針對某些系統儲存、傳輸、統計查詢等業務進行大資料量的測試。
配置測試:通過測試找到系統各資源的最優分配原則。
可靠性測試:可以施加cpu資源保持70%-90%使用率的壓力,連續對系統加壓執行8小時,然後根據結果分析系統是否穩定。即載入一定壓力的情況下,使系統執行一段時間。
併發測試:多以發現一些演算法設計上的問題。
效能測試以使用者併發測試為主的測試。
效能測試主要是為了發現軟體問題和硬體瓶頸。
對於效能方面給系統留有30%左右的擴充套件空間即可。
Web全面效能測試模型
預期指標的效能測試
主要指需求分析和設計階段提出的一些效能指標。
針對每個指標都要編寫一個或者多個測試用例來驗證系統是否達到要求。
預期指標的效能測試用例通常以單使用者為主,如果涉及併發使用者內容,則歸併到併發使用者測試用例中進行設計。
併發效能測試
選擇具有代表性、關鍵的業務來設計用例,並且使用者的設計應該面向“模組”
使用者併發效能測試分為:獨立核心模組併發效能測試,組合模組併發效能測試
獨立核心模組併發:完全一樣功能的併發測試;完全一樣操作的併發測試;相同/不同的子功能併發。
針對獨立核心模組使用者併發效能的測試用例設計,可發現一些核心演算法或者功能方面的問題,如一些多執行緒、同步併發演算法在單使用者模式下測試是很難發現問題的,通過模擬多使用者的併發操作,更容易驗證其是否正確和穩定。
核心模組測試一般屬於基本的效能測試,它較多地關注模擬的“功能”,一般不會對伺服器進行測試。
組合模組併發:具有耦合關係的核心模組進行組合併發測試;彼此獨立的、內部具有耦合關係的核心模組組的併發測試;基於使用者場景的併發測試。
組合模組測試一般發現介面方面的功能問題,並儘早發現綜合效能問題。
在實際中,各種型別的使用者都會對應一組模組,相當於不同的業務組在併發訪問系統,要充分考慮實際場景,如話費管理系統中的每月10日左右的收費高峰等場景。
在編寫組合模組使用者併發效能測試用例時,不但要考慮使用者使用場景,還要注意併發點的運用,併發點是指一定數量的使用者開始執行同一功能或者操作的時間點,一組測試場景通常包含多個併發點,從而實現了核心模組同一功能或者操作的真正併發。
獨立業務效能測試
獨立業務實際是指一些核心業務模組對應的業務。這些模組通常具有功能比較複雜,使用比較頻繁,屬於核心業務等特點。主要測試這類模組和效能相關的一些演算法、還要測試這類模組對併發使用者的響應情況。
使用者併發測試是核心業務模組的重點測試內容。
組合業務效能測試
是最接近使用者實際使用情況的測試,也是效能測試的核心內容。
組合併發的突出特點是根據使用者使用系統的情況分成不同的使用者組進行併發,每組的使用者比例要根據實際情況來進行匹配。
使用者併發測試是組合業務效能測試的核心內容。“組合”併發的突出特點是根據使用者使用系統的情況分成不同的使用者組進行併發,每組的使用者比例要根據實際情況來進行匹配。
網路效能測試
為準確展未頻寬、延遲、負載和埠的變化是如何影響使用者的響應時間的。主要是測試應用系統的使用者數目與網路頻寬的關係。
調整效能最好的辦法就是軟硬相結合。
大資料量測試
主要是針對對資料庫有特殊要求的系統進行的測試,主要分為三種:
1.實時大資料量:模擬使用者工作時的實時大資料量,主要目的是測試使用者較多或者某些業務產生較大資料量時,系統能否穩定地執行。
2.極限狀態下的測試:主要是測試系統使用一段時間即系統累積一定量的資料時,能否正常地執行業務
3.前面兩種的結合:測試系統已經累積較大資料量時,一些實時產生較大資料量的模組能否穩定地工作。
大資料量測試用例的設計:1,歷史資料引起的大資料量測試和2執行時大資料量測試
首先確定系統資料的最長遷移週期和選擇一些前面的核心模組或者組合模組的併發使用者測試用例作為其主要內容即可.
伺服器效能測試
效能測試的主要目的是在軟體功能良好的前提下,發現系統瓶頸並解決,而軟體和伺服器是產生瓶頸的兩大來源,因此在進行使用者併發效能測試,疲勞強度與大資料量效能測試時,完成對伺服器效能的監控,並對伺服器效能進行評估。
伺服器效能測試用例設計就是確定要採集的效能計數器,並將其與前面的測試關聯起來。
設計效能測試用例注意的原則:
可以滿足預期效能指標測試用例要求的,就沒有必要設計更多的內容,因為用例越多,執行的成本也越高。
一定要服從整體效能測試策略,千萬不能僅從技術角度來考慮設計“全面”的測試用例,“全面”應該以是否滿足自己的測試要求作為標準。
適當裁剪原則
只有根據實際專案的特點制定合理的效能測試策略、編寫適當的效能測試用例,並在測試實施中靈活地變通才可以做好效能測試工作。
測試計劃:主要包含測試範圍、測試環境、測試方案簡介、風險分析等,測試計劃要進行評審後方可生效。
測試報告:主要包含測試過程記錄、測試分析結果、系統調整建議等。
測試經驗總結:不斷總結工作經驗是建立學習型團隊的基礎,實踐-總結-再實踐
相關文章
- 效能測試學習(1)-效能測試分類與常見術語
- 小白測試系列:介面測試與效能測試的區別
- 效能測試之測試分析與調優
- web伺服器效能測試Web伺服器
- 軟體測試學習 ——五種軟體測試模型模型
- Jmeter介面測試+效能測試JMeter
- web測試與手機app測試的異同WebAPP
- (一)效能測試(壓力測試、負載測試)負載
- App測試、Web測試和介面測試一般測試流程APPWeb
- 測試面試題集錦(五)| 自動化測試與效能測試篇(附答案)面試題
- 效能測試
- 微服務測試之效能測試微服務
- 效能測試之測試指標指標
- 大話效能測試系列(1)- 效能測試概念與主要指標指標
- 測試方法的七種分類
- 軟體測試主要種類大全
- 探索性測試的分類與測試用例
- 新潮測試平臺之效能測試
- 【PG效能測試】pgbench效能測試工具簡單使用
- Jmeter效能測試:高併發分散式效能測試JMeter分散式
- 測試開發之效能篇-效能測試設計
- 效能測試面試題面試題
- 功能測試、自動化測試、效能測試的區別
- Web安全測試Web
- 【效能測試】效能測試各知識第1篇:效能測試大綱【附程式碼文件】
- 效能測試流程
- Kafka效能測試Kafka
- Redis 效能測試Redis
- 效能測試-概述
- JMeter效能測試JMeter
- PR效能測試工具升級到全鏈路效能測試與分析平臺
- 初識效能測試(測試小白麵試總結)
- ArrayBlockingQueue 和 LinkedBlockingQueue 效能測試與分析BloC
- 測試測試測試測試測試測試
- MYSQL 效能測試方法 - 基準測試(benchmarking)MySql
- 效能測試有哪些指標需要測試?指標
- 介面測試和效能測試的區別
- 軟體效能測試常見指標。在哪裡測試測試?指標