簡述性能測試流程？
1.分析性能需求。挑選用戶使用最頻繁的場景來測試，比如：登陸，搜索，下單等等。確定性能指標，比如：事務通過率為100%，TOP99%是5秒，最大並發用戶為1000人，CPU和內存的使用率在70%以下
2.制定性能測試計划，明確測試時間(通常在功能穩定后，如第一輪測試后進行)和測試環境和測試工具
3.編寫測試用例
4.搭建測試環境，准備好測試數據
5.編寫性能測試腳本
6.性能測試腳本調優。設置檢查點、參數化、關聯、集合點、事務，調整思考時間，刪除冗余腳本
7.設計測試場景，運行測試腳本，監控服務器，
8.分析測試結果，收集相關的日志提單給開發
9.回歸性能測試
10.編寫測試報告
如何確定系統最大負載？
通過負載測試，不斷增加用戶數，隨着用戶數的增加，各項性能指標也會相應產生變化，當出現了性能拐點，比如，當用戶數達到某個數量級時，響應時間突然增長，那么這個拐點處對應的用戶數就是系統能承載的最大用戶數。
你們系統哪些地方(哪些功能)做了性能測試？
選用了用戶使用最頻繁的功能來做測試，比如：登陸，搜索，提交訂單
你們的並發用戶數是怎么確定的？
1）會先上線一段時間，根據收集到的用戶訪問數據進行預估
2）根據需求來確定（使用高峰時間段，注冊用戶數，單次響應時間等
你們性能測試在什么環境執行？
參考答案：我們會搭建一套獨立的性能測試環境進行測試
你們性能測試什么時間執行？
基准測試：功能測試之后，系統比較穩定的時候再做。
負載測試：夜深人靜，系統沒人用的時候
怎么分析性能測試結果？
首先查看事物通過率，然后分析其他性能指標，比如，確認響應時間，事務通過率，CPU等指標是否滿足需求；如果測試結果不可信，要分析異常的原因，修改后重新測試
think_time的作用是什么？
模擬真實生產用戶操作，考察對服務器所造成的影響。
在確定性能測試結果可信后，如果發現以下問題，按下面提供的思路來定位問題
問題一：響應時間不達標
查看事務所消耗的時間主要在網絡傳輸還是服務器，如果是網絡，就結合Throughput(網絡吞吐量)圖，計算帶寬是否存在瓶頸，如果存在瓶頸，就要考慮增加帶寬，或對數據的傳輸進行壓縮處理；如果不存在瓶頸，那么，可能是網路不穩定導致。如果主要時間是消耗在服務器上，就要分別查看web服務器和數據庫服務器的CPU，內存的使用率是否過高，因為過高的CPU，內存必定會造成響應時間過長，如果是web服務器的問題，就把web服務器對應上對應的用戶操作日志取下來，發給開發定位；如果是數據庫的問題，就把數據庫服務器對應上對應的日志取下來，發給開發定位。
問題二：服務器CPU指標異常
分析思路：就把web服務器對應上對應的用戶操作日志取下來，發給開發定位。
問題三：數據庫CPU指標異常
分析思路：把數據庫服務器對應上對應的日志取下來，發給開發定位。
問題四：內存泄漏
分析思路：把內存的heap數據取出來，分析是哪個對象消耗內存最多，然后發給開發定位。
問題五：程序在單用戶場景下運行成功，多用戶運行則失敗，提示連不上服務器。
原因：程序可能是單線程處理機制
如何識別系統瓶頸？
從TPS指標分析，TPS即系統單位時間內處理事務的數量。觀察當前隨着用戶數的增長期系統每秒可處理的事務數是否也會增長
如何判斷系統的性能是變好了還是變壞了
通過基准測試對比性能指標
你們的性能測試需求哪里來？
1：客戶提供需求
2：運維提供需求
3：開發提供需求
如何實現200用戶的並發？
在腳本對應的請求后添加集合點
什么情況下要做關聯，關聯是怎么做的？
當腳本的上下文有聯系，就用關聯。
比如登錄的token關聯，增刪改查主鍵id關聯
有驗證碼的功能，怎么做性能測試？
1、將驗證碼暫時屏蔽，完成性能測試后，再恢復
2、使用萬能的驗證碼
你們性能測試做的是前台還是后台？
BS項目：測試的是后台服務器的性能和瀏覽器端性能；
APP項目：手機端和服務器端的性能都做
性能測試指標有哪些
響應時間
吞吐量
cpu
內存
io
disk
如何腳本增強？
1、做參數化
2、做關聯
3、添加事務
4、添加斷言
5、添加集合點
6、添加思考時間