性能測試學習總結

第一個總結


1.什麼是性能測試 performance testing
2.性能測試的核心 core activities
3.性能測試的必要性 why
4.性能測試和項目的具體情況 relevance of project context
5.性能調優

性能測試在給定負載下測試響應時間、吞吐量、系統可靠性、可擴展性。
主要目的有:
確定待測軟件是否可上線:
確定待測軟件是否達到某個定好的性能標準
比較待測軟件在各種系統或系統配置下的性能情況
定位性能問題
爲性能調優服務
確定吞吐量級別

核心:
確定性能瓶頸
確定性能基線baseline
支持性能調優
驗證是否達到性能需求或目標
收集其他性能相關的信息
估算上線需要的硬件配置

核心活動:
1.確定測試環境
確定測試環境和生產環境上可用於測試的工具和資源。
包括硬件、軟件、網絡配置。

2.確定性能測試目標
響應時間:從用戶的角度
吞吐量:從業務的角度
服務器資源使用量:從系統的角度
有時有例外情況,比如目標是檢查不同的系統配置中哪一種配置性能更好

3.計劃和設計測試
確定要測試的主要場景
確定需要準備的測試數據

4.配置測試環境
準備測試環境、測試工具、確定測試人員、如有必要的話確定測試環境上已安裝好服務器資源監控器

5.實現測試腳本
錄製、編寫腳本,實現3中計劃和設計的測試

6.測試執行
執行測試、監控服務器資源;
確認測試的執行,確認測試數據、測試結果的手機
在測試執行時做好服務器資源監控

7.分析結果、報告、下一輪測試
彙總並共享測試結果,測試員分析測試結果、聯合其他角色分析測試結果、
如有必要,可以重新定義測試優先級和重新執行一些測試
當所有結果符合測試目標,所有需要的信息已收集,則完成了在這種環境配置下這些場景的性能測試。




爲什麼要做性能測試?

1.確定待測軟件是否可上線:
驗證是否滿足需求,包括當前的性能需求和未來的,是否可以通過升級硬件等方式應對未來的需求。
收集和給出能證明用戶有可能對系統不滿的數據證明
指出系統的穩定性、擴展性和響應時間是否有可能引起用戶的不滿。
2.確認系統硬件性能足夠
檢查當前系統的容量,包括未來的系統設備需求
比較不同的系統配置,看看哪個性能最好
確認待測軟件的性能足夠好
3.確認系統的軟件性能足夠
每一次改動軟件前後確定性能需求
比較系統當前的性能指標和期望的性能指標
4.提高性能調優效率
分析系統在不同負載級別下的性能
確認系統性能瓶頸
提供需要的數據:如速度、擴展性、穩定性以便確定是否需要性能調優以及何時進行性能調優

項目的具體情況 
比如說有:
項目的願景
性能測試目標
性能測試接受指標
產品開發生命週期
項目日程計劃
項目資金
可用的工具和環境
測試員和測試團隊的技能
發現的性能問題的優先級
產品性能不好可能造成的商業上的影響

系統本身、用戶期望、商業動機、性能測試的原因
性能測試價值,項目管理和人員,流程,項目日程


性能調優:
參與者:(聯合性能調優組)
• Product vendors 
• Architects 
• Developers 
• Testers 
• Database administrators 
• System administrators 
• Network administrators 
流程:
• 測試在測試環境上執行,確保測試結果可復現
• 當測試結果顯示性能達不到期望值(或期望待測軟件佔用更少的系統資源)時,進入性能調優過程。
  調優需要對測試環境或待測軟件進行一定的修改或配置,常常需要進行臨時性修改或配置來看看性能是否得到提升。
• 聯合性能調優組需要對測試環境具有獨立的、全權的控制權以提高調優的效率。
• 在對測試環境進行修改或配置後,應開始或重新執行性能測試,以便檢測這次改動的效果。
• 整個調優流程通常需要快速而多次地進行測試-修改-測試的流程。如果調優團隊在調優階段是全職調優,那麼調優的效率會比較高
• 當調優結束,測試環境通常需要初始化,同時保留所有調優時認爲對提高性能有幫助的修改並去掉所有調優時被認爲對性能沒有好處的改動,
  然後再重新執行一輪性能測試以證明調優後性能得到了提升。

性能測試,負載測試,壓力測試
performance testing
測試系統的速度、穩定性等。
測響應時間、吞吐量、系統資源佔用率等。
通常要在從低到高多種負載情況下測試。

也常常指代這三種性能測試的總稱。

load testing
在預期生產環境的負載情況下進行測試,或者說接近能處理的負載極限。但不會去故意超出極限來使系統出錯。
測試指標同performance testing

stress testing
在超出預期生產環境的負載情況下進行測試,或者說超出能處理的負載極限,會故意超出極限來使系統出錯。
也要包括在諸如內存不足、磁盤空間不足、服務器錯誤等等情況下檢查待測系統在何種情況下會出錯,如何出錯,
以及找出監控哪些指標可以預測待測系統將會出錯。

白盒層面的性能測試
 at the application level, developers can use profilers to spot inefficiencies in their code (for example poor search algorithms)
 at the database level, developers and DBAs can use database-specific profilers and query optimizers
 at the operating system level, system engineers can use utilities such as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows) to monitor hardware resources such as CPU, memory, swap, disk I/O; specialized kernel monitoring software can also be used
 at the network level, network engineers can use packet sniffers such as tcpdump, network protocol analyzers such as ethereal, and various utilities such as netstat, MRTG, ntop, mii-tool
黑盒層面的性能測試
opensta、grinder、loadrunner?

基線測試-baselines
創建基線:跑一組性能測試,收集性能數據,
對基線來說,只有在每次只能改一個配置的情況下,基線纔有意義。
如果改了兩個配置,無法以基線來判斷是哪個改動導致性能上升或下降

用基線來確定待測軟件在不同版本間的性能是提升了還是下降了。

• 基線的創建可以針對系統、組件、應用,也可以針對應用的不同層次,如數據庫、web服務等。
• 基線可以用於未來版本的比較和性能優化
• 基線應可重用
• 基線是一組數據,比如響應時間、cpu佔用率、內存使用率、磁盤空間佔用率、網絡帶寬
• 基線數據可以共享給團隊作爲性能參考
• 基線要跟着程序變。比如程序重新架構過了,基線要重測。
• 要了解系統。

基線測試-benchmarking
benchmarking是把系統的性能指標和基線baseline做對比的過程。
這裏的基線可以使自己測出來的,也可以是行業標準之類的。

以web應用爲例,可以對行業標準baseline做一系列的對比得到一個分數。
再比較你的應用和其他應用針對同一個baseline的得分。

發佈了2 篇原創文章 · 獲贊 1 · 訪問量 4萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章