用Docker打包Python執行環境
1.功能測試
2.自動化測試
uI自動化測試
APL自動化測試
3.效能測試
4.安全測試(滲透測試)
效能測試:
1.效能測試理論
2.效能測試的方法
3.效能測試工具實戰
4.程式碼級別的效能測試
效能對軟體而言是一種指標,是衡量軟體使用者體驗最核心的指標之一,給使用者最直觀的感受就是產品的響應時間。
衡量一個產品的效能指標有很多,但是主要是響應時間(反應快還是反應慢),以及吞吐量(同時多少個人可以訪問這個系統,比如一碼通,同時是否支撐1000萬同時進行核酸檢測)
怎麼檢視響應時間?
1、滑鼠右鍵,點選檢查
使用者立場:
在使用者的角度而言,軟體效能就是使用者操作的響應時間。一般而言關於響應時間業界的說法具體如下:
• 1-3秒,屬於優的表現
• 3-5秒,可以接受,屬於中間的表現
• 5秒以上,無法接受
在實際的工作裡面,如果測試的一個頁面,響應時間大於5秒,那麼一般情況下,需要反饋程式設計師,也就是說提交一個優化的問題單\
運維:維護伺服器,管理伺服器的,還有就是負責公司的網路環境。阿里雲,IBM的小型伺服器
運維除了關注響應時間外,也會關注更多底層的資源資訊,這些資源資訊具體可以彙總為如下: • 系統資源(CPU和記憶體) • 資料庫資源(IOPS資源) • JVM記憶體是否夠用 • 系統的最大容量
系統資源:CPU和記憶體(memory) 資料庫(database,db):資料庫就是儲存資料的,對於資料庫而言,讀寫的速度就顯得非常重要,衡量讀寫的速度的指標是IOPS
JVM記憶體是否夠用: Java語言,特點是跨平臺的,Java跨平臺是通過jvm來實現的,就是Java 編寫的程式都有記憶體的大小設定,如果程式超過這個記憶體的大小設定,那麼就出現了記憶體洩露(Out Of Memory ,OOM)
開發視角 開發的關注度會更加的全面,畢竟程式碼都是程式設計師來編寫的,具體可以彙總為如下: • 前後互動的響應時間 • 中介軟體的引數設定 • 記憶體釋放洩露 • 連線數洩露 • 是否存在不合理的記憶體使用方式 • 是否存在不合理的執行緒同步方式 • 系統中是否存在不合理的資源競爭 • 系統架構&程式碼結構
中介軟體的引數設定: 中介軟體(RabbitMQ,Kafka,Redis)
連線數洩露: 資料庫(DB):程式設計師需要查詢資料,前提是連線到資料庫,但是資源有限,如果之前的佔用了沒釋放,那麼導致後面的連線不上,然後就洩露了
架構: 單體架構----》垂直架構---〉SOA架構----》微服務架構
單體架構:所有的程式碼整合到一起
垂直架構:按照模組來整合不同的程式碼
SOA架構:不同模組之間的資料同步
微服務架構:按照業務型別把每個業務寫成一個服務
SAAS:Software As A Sevice 中文意思:軟體即服務
PAAS: Platform As A Service 中文意思:平臺即服務
測試視角 使用者關注的視角屬於全棧性的,需要考慮使用者視角的產品體驗,也要監控以及關注運維視角和開發視角,所以效能測試中測試的具體工作職責可以總結為:
• 設計合理的場景和測試用例來驗證系統的資源資料
• 驗證在高併發的情況下架構是否滿足
• 給架構師以及開發人員提供中介軟體配置引數的合理值範圍
• 使用技術手段監控系統,DB,中介軟體,全鏈路監控的方式來監控系統資源情況
WEB前端
響應時間=⽹絡時間+應⽤程式的處理時間
併發使用者數 效能測試的核心是驗證當前系統能否支援現有使用者的訪問,也就是說系統可以承受在同一時間段多少使用者來訪問系統,比如王者榮耀的遊戲,是否可以承受同時線上人數一個億的人同時進行玩遊戲?
併發使用者數,可以說:不論從業務視角出發,還是服務端承受壓力而言,描述的是同一時間同時向客戶端發出請求的客戶,某些時候也稱為“併發測試”。這中間主要體現的是服務端承受的最大併發訪問數。
吞吐量 主要⽤於資料傳輸⽅⾯,也就是被測試系統的執⾏效率。該術語⽤於描述資料傳輸速度(位元組/秒或者⽐特/秒),在 某些情況下(如DB層⾯),吞吐量指的是操作的速度,也就是每秒運算元或者每秒業務數。或者也可以說單位時 間內客戶端請求的數量,直接體現系統的效能承載能力。
一碼通而言:場景早上6點至7點學生上班族都開始做核酸檢測,那麼併發使用者數指的是這個時間段服務端能夠承受的最大使用者數,吞吐量指的是這個時間段,每秒能夠同時多少人進行核酸檢測
效能計數器:
指的是效能測試過程中,需要收集哪些資料,並且收集的這些資料對效能測試有幫助 系統:cpu memory db:iops
被測系統:響應時間,併發使用者數,吞吐量
效能測試什麼時候開始合適?
效能測試最好建議是在功能測試的基礎上,也就是說系統測試的沒什麼問題了,再做效能測試
使用率 對於服務所請求的資源,使⽤率描述的是所給定的時間區間內資源的繁忙程度。對於儲存資源來說,使⽤率指的就 是所消耗的儲存容量。如⼀個業務中,會使⽤⼤量的記憶體資源,總的記憶體資源是4G,在⼀定資料量的情況下執⾏該 業務形態,記憶體使⽤率從100M⼀直佔⽤到3G,然後隨著業務形態記憶體資源得到釋放呈下降的趨勢,那麼可以說內 存使⽤率最⾼為75%,可能會存在OOM的錯誤資訊,也可能會存在記憶體洩露的情況。所以使⽤率分兩個維度,⼀ 個是系統資源的使⽤率,另外⼀個是系統內部署服務對系統資源的使⽤率。
當系統的資源使用率(cpu和記憶體)達到60%以上,那麼可能系統就會存在很卡的情況。
思考時間 思考時間英文名稱是Think Time,也稱為休眠時間,在業務視角,思考時間指的是使用者在進行操作時,每個請求之間的間隔時間。
IOPS 該術語主要是針對資料庫的,也就是每秒發⽣的輸⼊/輸出操作的次數,是資料傳輸的⼀個度量⽅法。⽤於磁碟的 讀寫,IOPS值的是每秒讀和寫的次數。
兩個維度:
1、針對磁碟
2、針對資料庫的讀寫
事務:一系列操作動作的組合,如登入,輸入賬戶,輸入密碼,點選登入按鈕,可以說是登入的事務
TPS統計的是每秒處理的事務數,即系統每秒能夠處理的事務的數量
QPS指的是 每秒查詢率
資源排程: 系統的資源是有限的,假設所有的程式都啟動,很明顯資源不夠,那麼這個時候誰先執行,誰後執行。誰先搶到資源,誰先執行,這個過程中資源會不停的切換。
在作業系統的級別上,程序是作業系統最小的執行單位。什麼是程序,程序是每個程式執行後,都是一個獨立的程序。現在的軟體都是可以同時幹很多的事,比如抖音,可以同時看視訊的同時也可以發私信,也可以聊天,這個過程中,發私信,聊天,看視訊,都是由執行緒來支撐執行的,所以了,現在的軟體可以說是多執行緒的模式。
在程序角度,多執行緒內部都是共享資料的(如你拿你的抖音看視訊,聊天,發私信,其實是同一個人)。
排程策略:在資源有限的情況下,所有的任務都可以執行,但是如果資源在不夠的情況下,那麼就會有排隊的機制。
排隊的機制: 佇列(資料結構),先進先出。Queue,有這麼幾個方法: put():進隊 get():出隊 empty():隊伍是否為空
• CPU密集型:應⽤程式執⾏繁重的計算,通常運⾏時間⽐較⻓,會佔⽤⼤量的CPU
• IO密集型:應⽤程式執⾏I/O,計算不多,會佔⽤⼤量的記憶體資源 系統的最⼩粒度是執行緒,也就是說系統排程中粒度最細的就是對執行緒的排程。
cpu;存在大量的計算任務,佔用大量的cpu,而佔用少量記憶體
io:佔用大量記憶體而佔用少量cpu
等待佇列 在程式中,都會涉及到等待佇列的,不管是同步互動還是非同步的互動中,都會涉及它的最⼤佇列,這樣設計的核⼼ 思想是防⽌在客戶端⾼併發的情況下服務端在沒有佇列的情況下出現雪崩以及最終導致服務端出現癱瘓,
搜尋
複製