概述一下效能測試流程？

• 1.分析效能需求。挑選使用者使用最頻繁的場景來測試。確定性能指標，比如：事務通過率為100%，TOP99%是5秒，最大併發使用者為1000人，CPU和記憶體的使用率在70%以下
• 2.制定效能測試計劃，明確測試時間(通常在功能穩定後，如第一輪測試後進行)和測試環境和測試工具
• 3.編寫測試用例
• 4.搭建測試環境，準備好測試資料
• 5.編寫效能測試指令碼
• 6.效能測試指令碼調優(指令碼增強)。設定檢查點、引數化、關聯、集合點、事務，調整思考時間，刪除冗餘指令碼
• 7.設計測試場景，執行測試指令碼，監控伺服器
• 8.分析測試結果，收集相關的日誌提單給開發
• 9.迴歸效能測試
• 10.編寫測試報告

如何確定系統最大負載？

通過負載測試，不斷增加使用者數，隨著使用者數的增加，各項效能指標也會相應產生變化，當出現了效能拐點，比如，當用戶數達到某個數量級時，響應時間突然增長，那麼這個拐點處對應的使用者數就是系統能承載的最大使用者數

你們系統哪些地方(哪些功能)做了效能測試？

選用了使用者使用最頻繁的功能來做測試，比如：登陸，搜尋，提交訂單

你們的併發使用者數是怎麼確定的？

1）會先上線一段時間，根據收集到的使用者訪問資料進行預估

2）根據需求來確定（使用高峰時間段，註冊使用者數，單次響應時間等

你們效能測試在什麼環境執行？

參考答案：我們會搭建一套獨立的效能測試環境進行測試

你們效能測試什麼時間執行？

基準測試：功能測試之後，系統比較穩定的時候再做。

負載測試：夜深人靜，系統沒人用的時候

怎麼分析效能測試結果？

首先檢視事物通過率(錯誤率)，然後分析其他效能指標，比如，確認響應時間，事務通過率，CPU等指標是否滿足需求；如果測試結果不可信，要分析異常的原因，修改後重新測試(複測)。

在確定性能測試結果可信後，如果發現以下問題，按下面的思路來定位問題

問題一：響應時間不達標

檢視事務所消耗的時間主要在網路傳輸還是伺服器，如果是網路，就結合Throughput(網路吞吐量)圖，計算頻寬是否存在瓶頸，如果存在瓶頸，就要考慮增加頻寬，或對資料的傳輸進行壓縮處理；如果不存在瓶頸，那麼，可能是網路不穩定導致。如果主要時間是消耗在伺服器上，就要分別檢視web伺服器和資料庫伺服器的CPU，記憶體的使用率是否過高，因為過高的CPU，記憶體必定會造成響應時間過長，如果是web伺服器的問題，就把web伺服器對應上對應的使用者操作日誌取下來，發給開發定位；如果是資料庫的問題，就把資料庫伺服器對應上對應的日誌取下來，發給開發定位。

問題二：伺服器CPU指標異常

分析思路：就把web伺服器對應上對應的使用者操作日誌取下來，發給開發定位。

問題三：資料庫CPU指標異常

分析思路：把資料庫伺服器對應上對應的日誌取下來，發給開發定位。

問題四：記憶體洩漏

分析思路：把記憶體的heap資料取出來，分析是哪個物件消耗記憶體最多，然後發給開發定位。

問題五：程式在單使用者場景下執行成功，多使用者執行則失敗，提示連不上伺服器。

原因：程式可能是單執行緒處理機制

如何識別系統瓶頸？

從TPS指標分析，TPS即系統單位時間內處理事務的數量。觀察當前隨著使用者數的增長期系統每秒可處理的事務數是否也會增長

如何判斷系統的效能是變好了還是變壞了

通過基準測試對比效能指標

你們的效能測試需求哪裡來？

1：客戶提供需求

2：運維提供需求(負責伺服器的穩定性)

3：開發提供需求

如何實現200使用者的併發？

在指令碼對應的請求後新增集合點(絕對併發)

相對併發：執行緒組設定200執行緒數

什麼情況下要做關聯，關聯是怎麼做的？

當指令碼的上下文有聯絡，就用關聯。

比如登入的token關聯，增刪改查主鍵id關聯

有驗證碼的功能，怎麼做效能測試？

1、將驗證碼暫時遮蔽，完成效能測試後，再恢復

2、使用萬能的驗證碼

你們效能測試做的是前臺還是後臺？

BS專案：測試的是後臺伺服器的效能和瀏覽器端效能；

APP專案：手機端和伺服器端的效能都做

效能測試指標有哪些

響應時間

吞吐量

cpu

記憶體

io

disk

如何指令碼增強？

1、做引數化

2、做關聯

3、新增事務

4、新增斷言

5、新增集合點(jmeter的同步定時器)

6、新增思考時間(jmeter的統一隨機定時器和固定定時器)

如何找到併發數、平均響應時間、tps的最佳平衡點？

先回顧下基礎，效能測試常用的指標有三個：併發、響應時間、tps

　　併發：跑道里參加賽跑的人數（這裡的併發是廣義的併發，即同一個時間段內對系統發起的請求數量）

　　響應時間：也就是平均每個事務的處理時間

tps：每秒處理的事務數

需求指標：分為單指標和多指標

　　單指標：一般是單測試tps，或者根據併發測試響應時間，或者根據響應時間測試併發，只考慮單指標的很少

　　多指標：要同時考慮多個指標，比如tps + 響應時間(<1s)

這個題，意思就是要找到這三個指標同時最佳值的點，即：不能只追求併發數大，而忽略tps，所以，這是一個多指標效能需求，假設是這樣的：要求響應時間1秒以內，併發數要儘可能的多，tps要儘可能的大。

是不是依舊有點懵逼？先畫一個簡單的示意圖，方便大家理解：隨著併發數增加，響應時間肯定是越來越高，所以，上面紅線是響應時間；

隨著併發數增加，tps是先升高到峰值，然後下降（也可能是一直平穩，或者平穩一段時間再下降），所以，上面藍線是tps；

紫色表示併發使用者數；

該怎麼去找這個最佳平衡點呢？

1.儘可能多的做不同併發數下的壓測，記錄下響應時間（1s以內）和最大tps，當然，伺服器端，各個伺服器的資源利用率在可接受範圍內（每個公司不一樣，我們是90%以內）；

2.然後根據獲取到的不同併發下的指標資料（併發數、tps、響應時間），畫出上圖，關注右側的交點，即tps下降的地方和響應時間的交點，這個點的tps最大，如果響應時間在1s以內，此時併發數也是比較大的，這個點就可以認為是三個指標都不錯的平衡點（當然，我這裡把tps放在第一位優先考慮了，這個就看大家最在乎哪個指標了，排個優先順序）；如果響應時間大於1s，最佳平衡點就往左找，找到響應時間為1秒的點，此時對應的tps和併發值，就是最佳平衡點。總之，測試取樣越多，獲取的平衡點就越準確。

另外，如果是用loadrunner作為併發工具，併發過程中是可以增加或者減少併發使用者數的，就不用必須壓完一次，再調整併發數繼續壓，但是，loadrunner併發過程中調整了併發數，還是要儘可能跑久一點，比如10-15min。