進公司以來，對于LoadRunner的使用以及對性能測試的理解和認識，一直都是一知半解，僅僅停留在基本腳本的編寫和優化上，對于腳本對服務端的壓力和性能的測試，總是模模糊糊，沒有系統的認識。經過幾次跟同事的討論，碰撞，產生了一些思路，今夜涼風習習，騎著車，腦海里任由思路上躥下跳，慢慢地變得規律起來，到家之后，略作整理，形成了一套重構方案，將之前的一些牛角尖問題解了開來。后續會慢慢同步學習和實踐的經驗教訓和心得。
1、獨立單個接口的腳本結構，盡量避免接口之間的互相依賴，因為我們做【性能測試】的目的是測試服務端的性能，而不是邏輯或流程，那個屬于【接口測試】或【功能測試】的范疇；
2、剝離登錄、登出接口，放入init和end里；
3、每個原本就相對獨立的接口，按場景封裝到一個USR文件或Action里，便于分析不同接口對應的服務端和DB的處理性能；
4、測試數據的準備：現網數據或者創建數據；
a. 例如Phone數據，要根據實際估算量來選定數據源，不能無限制的使用，沒有意義；
b. 商戶數據，老用戶，新用戶，不同狀態的訂單數據，
5、原本互相依賴的接口，盡可能地剝離開來，針對該接口所處理的業務，設計業務數據的準備腳本：
以訂單接口為例：
a. 建立LR Test的服務類型，在手工測試和性能測試的數據庫沒有分離開之前避免影響手工測試；
b. 取一組號碼創建該服務類型的店鋪；--數據庫查詢當前50VUser，生成店鋪的效率；
c. 取同一組號碼發送對應服務項目的訂單；--數據庫查詢當前50VUser，生成訂單的效率，包括用戶訂單和商戶訂單；
d. 同一組號碼的店鋪執行搶單；
e. 依次進行，放在不同的USR文件里，分組執行，比如b/c可以順序執行，d可以隔天執行；
6、將不同場景的腳本分發到不同的負載終端上執行，模擬接近真實的線上場景；
階段I：
負載測試：對系統不斷加壓，直到飽和不能再壓了，目的是為了找到系統最大的負載能力，為性能調優提供數據。
壓力測試：指將系統壓到一定的飽和程度，此時系統處理業務的能力，系統是否會出現錯誤。
階段II：
配置測試：通過調整系統軟硬件環境，將系統調優到最佳配置。
并發測試：通過模擬用戶并發訪問某個模塊或接口，觀察系統是否會出現死鎖、處理速度是否明顯下降等性能問題。
階段III：
基準測試：在一定的軟件、硬件和網絡環境下，模擬一定數據量的VU運行一種或多種業務，將測試數據作為基線數據，在系統調優或評測過程中，通過運行相同的業務場景來比較調優效果。
可靠性測試：當系統在一定的業務壓力下，持續運行一段時間，觀察系統是否達到要求的穩定性，比如無故障運行多少天。
【原計劃細節】
1、基于梳理好的接口做用戶場景分析，甄別出需要做接口測試的和性能測試的接口；
2、采用當前的運行場景，執行10次腳本，執行過程中可以在40
3、分析baseline數據，從多維度檢查存在性能問題的地方，并提交給開發做優化方案；
4、同步基于產品運營提供的期望并發用戶數+不同場景，換算成期望的性能targetline；
5、根據產線服務器配置和本地服務器配置的對比，粗略換算出當前的baseline和targetline的差距；
6、評估不同優化方案的可行性；
7、代碼調優或配置調優；
8、腳本驗證，并更新baseline；
9、重復6、7、8；
吞吐量=（虛擬用戶數*在測試時間內每個虛擬用戶數 發出的請求字節數）/測試時間，即單位時間內服務器處理的字節數。
吞吐量應該是隨著VU數量的增加而增大，當系統出現性能瓶頸時，吞吐量就不會隨著VU的數量而增大了，而是趨于平衡，所以我們必須通過不斷添加VU來測試吞吐量的拐點，即服務器吞吐量的最大值。
吞吐率=吞吐量/測試時間：單位時間從服務器返回的字節數，也可以指單位時間內服務器處理客戶提交的請求數，是衡量網絡性能的一個重要指標。
從事務的角度說，如果把每次點擊作為一次提交事務來對待，那么TPS和每秒點擊率的概念是等同的。
注意：每秒點擊率是Web系統服務器處理的最小單位，但點擊一次不代表客戶端只向服務器端發送一個HTTP請求。僅僅反應的是客戶端提交的請求數，而不能表現服務器端當前承受的壓力，因為服務器端不一定會全部處理，有可能出現被拒絕，所以每秒點擊率不能直接反映服務器處理請求的能力。
