5.18-效能測試（一）
軟體測試：功能、自動化（UI僅由程式碼來作業系統，無人工、API）、效能、安全（滲透測試）
效能測試學習章節：理論；方法；實戰；程式碼級別效能測試；資源監控
一、測試理論
1.效能是衡量軟體使用者體驗最核心的指標。
2.給使用者最直觀的體驗是響應時間（速度快慢）和吞吐量（同時多少個使用者可以訪問這個系統）
如何檢視響應時間
開啟淘寶網右鍵檢查，network清空資料並重新整理頁面 右下角紅色load為響應時間（多少毫秒）
使用者視角
1.軟體效能是使用者操作的響應時間。
2.響應時間：1-3秒網路速度優秀；3-5秒可以接受；5秒以上無法接受
如果測試一個頁面響應時間大於5秒，需要反饋程式設計師並提交一個優化問題單
運維
1.維護和管理伺服器並負責公司網路環境。阿里雲、IBM的小型伺服器
2.運維除關注響應時間外，也會關注更多底層的資源資訊，資源資訊如下： • 系統資源（CPU和記憶體）
CPU和記憶體(memory) 資料庫(database,db)
• 資料庫資源（IOPS資源）
儲存資料,因此讀寫速度就非常重要。衡量讀寫速度指標是IOPS
• JVM記憶體是否夠用
Java語言特點跨平臺，Java通過jvm跨平臺，Java 編寫程式都有記憶體大小設定，如果程式超過記憶體大小設定，會出現記憶體洩露(Out Of Memory ,OOM)
• 系統的最大容量
開發
程式碼是由程式設計師寫，因此開發會關注的更全面，總結如下： • 前後互動的響應時間 • 中介軟體的引數設定（rabbitMQ,redis，kafka）
Redis：快取穿透。存到記憶體裡，目的是查詢時候讀取速度很快
• 記憶體釋放洩露 • 連線數洩露
資料庫(DB):程式設計師需要連線到資料庫查詢資料。由於資源有限，如果之前佔用的沒釋放，會導致後面的連線不上就會洩露
• 是否存在不合理的記憶體使用方式 • 是否存在不合理的執行緒同步方式 • 系統中是否存在不合理的資源競爭 • 系統架構&程式碼結構
單體（所有程式碼整合一起）
垂直（按照模組整合不同程式碼）
SOA（不同模組之間資料同步）
微服務（按照業務型別把每個業務寫成一個服務。企業使用最多）
SAAS：Software As A Service 軟體即服務
PAAS: Platform As A Service 平臺即服務
測試
使用者關注視角屬於全棧性，測試需要考慮使用者產品體驗也要監控及關注運維和開發視角，效能測試工作職責為：
• 設計合理的場景和測試用例來驗證系統的資源資料
• 驗證在高併發情況下架構是否滿足
• 給架構師以及開發人員提供中介軟體配置引數的合理值範圍
• 使用技術手段監控系統，DB，中介軟體，全鏈路監控的方式來監控系統資源情況
WEB前端
前端效能是效能測試中比較熱門的技術，具體關注的點：
• 瀏覽器資源載入（HTML解析，圖片資源載入，CSS檔案資源載入）
• 前端快取技術的優化是否合理性
• 前端與後端的互動性耗時
響應時間
⼀次操作完成的時間，是客戶端傳送請求到服務端後，服務端返回到客戶端的響應資料的時間。包含用於等待和服務的時間，以及用來返回結果的時間。
響應時間=網路時間+應用程式的處理時間
客戶端<---》路由器(DNS)<---〉nginx中介軟體<--->淘寶服務<--->淘寶資料庫
併發使用者數
1.效能測試核心是驗證當前系統能否支援現有使用者的訪問，系統可以承受在同一時間段多少使用者訪問系統。比如王者榮耀，是否可以承受同時線上一億人同時進行玩遊戲？
2.併發使用者數，不論從業務視角出發，還是服務端承受壓力，指同一時間同時向客戶端發出請求的客戶，也稱為“併發測試”。是服務端承受的最大併發訪問數。
吞吐量
用於資料傳輸，被測試系統的執行效率。⽤於描述資料傳輸速度(位元組/秒或者⽐特/秒)，如DB資料庫，吞吐量指操作速度，每秒運算元或者每秒業務數或單位時間內客戶端請求的數量，體現系統性能承載能力。
例如一碼通：
效能計數器
效能測試過程中需要收集哪些資料，並且收集的這些資料對效能測試有幫助 系統：cpu memory db:iops
被測系統：響應時間，併發使用者數，吞吐量
效能測試什麼時候開始合適？
效能測試最好是在功能測試的基礎上，系統測試完全OK再做效能測試
使用率
分兩個維度：系統資源的使⽤率；系統內部署服務對系統資源的使⽤率
系統內部署服務，對系統資源的使⽤率對於服務所請求的資源，使⽤率指所給定的時間區間內資源的繁忙程度；對於儲存資源來說，使⽤率指所消耗的儲存容量
如⼀個業務中，會使⽤⼤量的記憶體資源，總的記憶體資源是4G，在⼀定資料量的情況下執⾏該業務形態，記憶體使⽤率從100M⼀直佔⽤到3G，隨著業務形態記憶體資源得到釋放呈下降的趨勢，記憶體使⽤率最⾼為75%，會存在OOM的錯誤資訊和記憶體洩露的情況。
當系統的資源使用率(cpu和記憶體)達到60%以上，系統就會存在很卡的情況
思考時間
Think Time也稱休眠時間，在業務視角指使用者在進行操作時，每個請求之間的間隔時間。
IOPS 磁碟和資料庫讀寫
主要針對資料庫，指每秒發⽣的輸⼊/輸出操作的次數，是資料傳輸的⼀個度量⽅法。⽤於磁碟的讀寫，IOPS值的是每秒讀和寫的次數。
TPS/QPS
TPS：統計每秒處理的事務數。即系統每秒能夠處理事務的數量
事務：一系列操作動作的組合。如登入，輸入賬戶，輸入密碼，點選登入按鈕
QPS:每秒查詢率
資源排程
系統資源是有限的，假設所有程式都啟動資源會不夠，誰先搶到資源誰先執行，過程中資源會不停的切換。
在作業系統級別上，程序是作業系統最小的執行單位。什麼是程序，程序是每個程式執行後，都是一個獨立的程序。現在的軟體都是可以同時幹很多的事，比如抖音，可以同時看視訊的同時也可以發私信，也可以聊天，這個過程中，發私信，聊天，看視訊，都是由執行緒來支撐執行的，所以現在的軟體是多執行緒的模式。
在程序角度，多執行緒內部都是共享資料的（如拿抖音看視訊，聊天，發私信，其實是同一個人）。
排程策略：在資源有限的情況下，所有的任務都可以執行，如果不夠的情況，就會有排隊的機制。
排隊的機制：
佇列（資料結構），先進先出。
Queue：put()：進隊 get()：出隊 empty()：隊伍是否為空
CPU密集型
1.應⽤程式執⾏繁重的計算，通常運⾏時間⽐較⻓，會佔⽤⼤量的CPU ；
2.存在大量計算任務，佔用大量CPU而佔用少量記憶體；
IO密集型
1.應⽤程式執⾏I/O，計算不多，會佔⽤⼤量的記憶體資源。系統的最⼩粒度是執行緒，系統排程中粒度最細的就是對執行緒的排程。
2.佔用少量CPU佔用大量記憶體
等待佇列
在程式中都會涉及等待佇列。同步互動和非同步互動中，都會涉及它的最⼤佇列，核心是防⽌在客戶端⾼併發時及服務端在沒有佇列時，出現雪崩以及最終導致服務端出現癱瘓
服務端的穩定性測試怎麼保障？ 客戶端在持續高併發的情況下發送請求給服務端，服務端處理能力有限，導致資源出現瓶頸的同時排隊的任務越來越多，最後服務端就出現癱瘓。為了服務端不出現崩潰，服務端一般會使用佇列的機制。例如：服務最多可以處理任務是30個，如果過來的任務是少於30個，則全部同時處理，如果過來的任務是100個，則70個任務在排隊。
1、佇列設定的值是多少?最⼤可以運⾏的任務是多少？ 2、需要測試到排隊的策略機制，模擬⼤批量的程式進⾏排隊，⼀個任務執⾏結束後，佇列位置釋放 ⼀個，等待中的可以⽴刻進⼊並執⾏，這中間就設計到先進先出或先進後出，以及執行緒優先順序的設計策略 3、執行緒在排隊的過程中，設定最⼤的等待時間是多少，⼀個執行緒不可能永遠處於等待中，等待多久還沒到執⾏的階段，這時服務針對排隊等待的執行緒處理的機制是？這個時間專業術語就是：訪問等待時間 4、⼀個執行緒完整的時間是由三部分組成，響應時間：客戶端發起請求時間+訪問等待時間+邏輯執⾏時間 +返回給客戶端的時間。在測試中，把每個執行緒名稱設定為uuid，這樣它都是獨⽴的，可以依據這個 uuid，讓開發配合輸出每個階段的時間輸出，就可以得到每個階段的具體時間，根據時間再來判斷時間是否優化。