一、性能測試概述
1、關於性能測試目標：
①TPS
②一定並發用戶數下功能點的響應時間
③一定響應時間內功能點的並發用戶數
性能測試不是達到既定目標即可，還要測試軟件功能能夠達到的極限值。
2、關於性能測試的場景：
在腳本錄制調試完成后，需要進行場景的設置，進而對腳本進行壓測，分析壓測的結果。
性能測試場景：
單場景 → 單獨某個功能、接口，測試目標是多少(一般10--15分鍾)
混合場景 → 發現線程死鎖和數據庫死鎖(一般10--15分鍾)
穩定性場景 → 系統是否穩定運行，發現系統是否有內存泄漏(過程)、內存溢出(結果，系統崩潰)(一般N*12小時)
在進行場景的壓測時，相當重要的一點是要保證數據庫表中有足夠的數據量。
3、loadrunner負載機
用其它機子做負載機為"分布式負載"，這時候在用作負載的機子上，只需要安裝loadrunner Agent這個模塊就可以了，在進行分布式負載時，可能出現連接不上負載機的情況，檢查網絡及防火牆的狀況。
二、Controller的場景概述
三、手工性能測試場景
1、為什么要使用分布式負載：
在進行並發的時候，一台PC機能夠發送的並發數，可能達不到測試的要求，那么就需要用多台機子進行並發，每台機子分擔一定的並發數。
Controller應與Load Generator分開。若測試需要的vu數，超過單負載機所能產生的vu數，則負載機本身將成為性能瓶頸，這是不合理的。
例如，負載機內存512M，一個vu占2.5M，則單台負載機只能產生200vu，若需測試500vu，一台controller調用多台Generator，要考慮負載均衡問題，帶寬問題。
2、Controller的場景設置：
①Controller中負載機的設置如下圖：
在進行腳本壓測時候，可以如下圖進行快速的操作：
上邊我們已經描述了在Scenario Groups中，如何進行腳本的選擇及負載機是如何進行設置的，接下來要對腳本的並發數及運行時間進行設置：
②腳本虛擬用戶初始化：
一般在進行虛擬用戶設置的時候，選擇彈出框Edit Action中的第一個或者第三個選項
③虛擬用戶並發數及加載方式的設置：
注意：在此次設置了多少個虛擬用戶進行並發，並不表示在進行壓測時，就有設置的並發用戶數運行，實際的並發數，取決於服務器的處理能力及代碼，TPS/RPS(每秒通過的事務/每秒通過的請求數)
- 思考：
壓測時2000個用戶並發，每秒加載2個用戶，並發15分鍾，問在15分鍾里，用戶數能夠加載完嗎
進行如下設置：
由上圖可知，用戶的加載時間，不包含用戶的並發時間
同理用戶的退出時間，也不包含在用戶的並發時間內，所以說以上"壓測時2000個用戶並發，每秒加載2個用戶，並發15分鍾，問在15分鍾里，用戶數能夠加載完嗎"的描述是錯誤的。
如下圖設置：
loadrunner的運行方式有兩種：進程方式、線程方式
默認情況下以線程方式運行
在腳本運行前，加載2000個並發用戶，這時服務器會啟動40個(2000/50=40)mmdrv進程(1個mmdrv進程默認有50（可修改）個線程。也就是說如果是50個進程並發的話，系統會啟動一個mmdrv的進程(負載機進程)，如果多於50個線程，就對應啟動x個mmdrv進程。如果是以進程方式運行的話，一個並發就是一個mmdrv進程。進程比較耗內存資源，線程比較耗CPU可以這么理解。)
產生的影響：
對負載機來說，開始壓力會大一些
對服務器來說，服務器沒有任何緩存時間，一下子來2000個並發，可能導致服務器崩潰
熱負載：一點一點的加並發
冷負載：所有並發一次性向服務器發送
loadrunner支持壓測的同時，增加並發用戶數，如下圖：
在壓測時候對比上圖①運行的虛擬用戶數②請求的響應時間③tps 進行分析
④腳本的串聯運行：
方式一、
方式二、lr和QC進行集成
方式三、定時任務
四、面向目標的性能測試場景
五、Analysis：
1、新增監控視圖：
2、Analysis報告的簡單分析：
上圖中，如果標准方差在5以內取Average做作為平均相應時間，如果標准方差大於5取90 Percent作為響應時間。
3、Analysis中，進行視圖的合並操作，如下圖：
一般合並並發用戶數和響應時間或者並發用戶數和tps，可以看到不同並發用戶數下的響應時間或者tps值的變化情況。
並發用戶數下的響應時間不包含失敗事務或者請求的響應時間。
六、測試目標對應測試場景的設置實戰
實戰1、測試響應時間：測試網易體育20個並發的響應時間如何設置？(測試某個功能/接口的響應時間，前提條件是多少個並發)
直接加載需要的用戶數去測試某個功能/接口，並發15分鍾，得出平均時間即可
在手工場景下進行如下設置：
腳本運行完后，根據標准方差的大小，取平均響應時間或者百分之90的響應時間
實戰2、測試最大tps 需要知道測試哪個接口或者功能(包含條件是1秒)
直接從1個用戶開始測試，通過不斷的加壓(加用戶)去測試最大tps，最大tps的標識是隨着用戶的不斷增加，tps不再增加或者tps反而減小，那么那個不再增加的tps或者出現拐點的tps就是最大的tps
在手工測試場景下，進行如下設置：
擴展：
項目的某一功能的tps如何評估：
①tps是開發、項目經理或者產品經理制定的。分析線上日志，1s最大有多少個用戶或請求通過
②只知道在線用戶數，如何去衡量系統某個功能的tps是合理的
測試人員心里預估值來源：
最精確來源，線上日志分析(可用awk命令統計日志每分鍾通過的請求數，進而得到tps)；
其次可以用28(百分之80的用戶會在百分之20的時間段內同時做一件事情)原則，前提知道在線用戶數，和用戶的訪問習慣，譬如有100個用戶，在預定的某個10分鍾內，要做某件事，那么 100個用戶*80%=80個用戶，10分鍾*20%=2分鍾 tps=80/(2*60)
實戰3：測試最大並發用戶數：測試某個功能/接口，響應時間在多少秒以內
用戶直接從1開始測試，逐漸加大並發用戶數，觀察響應時間，直到響應時間達到需要的秒數，再繼續觀察響應時間是否穩定，如果穩定，那么這個並發數就是最大並發，如果不穩定，那么就需要增加或減少用戶
四、其它的一些問題：
這里描述一些問題，表述其思考方式，以便舉一反三：
1、發送的請求大於處理請求，出現排隊的情況，響應時間會越來越長。
2、在允許同一個用戶多點登錄的情況下，在進行壓測的時，不需要進行登錄用戶的參數化操作；如若不允許同一個用戶進行多點登錄的話，就需要進行參數化。
3、性能測試壓測對象是action中的事務，在init中不影響，參數化的時候，用once的時候，不需要做參數化。
4、lr的循環嵌套：
cotroller里的運行時間 - while(endtime>0) → action的迭代 - while(迭代次數>0) → 腳本里的循環
故在腳本中，設置迭代的次數並不影響壓測時，controller的顯示。
5、loadrunner測試手機app:app和web一樣，app本身就相當於web瀏覽器，后台調的都是服務，對server有並發對app本身沒有並發，測試app分為兩部分：后台的服務器的性能(接口),接口不需要錄制，只需要知道app接口的說明文檔，自己手寫腳本；app本身，相當於web前端性能測試，需要用到其它前端性能測試工具。
6、IP欺騙：模擬本機局域網段內的大量IP來進行操作。服務器識別的是網卡IP，單網卡一個IP，雙網卡倆IP。
---------
釋然、感恩，感恩遇到她，感恩曾經一起的美好... ...
越努力越精彩，加油！！！
--------------