- 為什么要進行性能測試呢？ 有些問題是只有在大並發或者壓力測試下才會暴露出來的，在平常的公司內部測試中，感覺一切都是正常的，但是把服務放到生產線上，例如某個時刻突然有很多的用戶要向我們的服務發送請求，這時候就考驗到我們的服務是否會死鎖，內存泄漏，能否在一個可接受的范圍內響應，會不會crash，能否處理所有的請求（或者允許損失一定量的請求，比如1%內）等。為了不給用戶糟糕的體驗，所以我們需要在服務上生產線之前就要做好性能測試，但要做好性能測試，除了編寫正確的性能腳本外，也需要分析很多因素的（主要有3大塊：負載機、網絡、被測系統），所以我希望自己能從平常中的點滴開始積累然經驗后不斷擴展。 在性能測試開始之前，是要保證你所要測試的場景中所涉及到的功能測試都已經能跑通，要不然到時候你會崩潰的QAQ
- 要做一個完整的性能測試要有哪些步驟？
– 1. 虛擬用戶腳本編寫（模擬用戶實際操作）
– 2. 場景設計&運行（例如要5000個用戶同時登錄到會議室）
– 3. 分析結果報告
- 如何選擇性能測試工具？
– 1. 只選對的，不選貴的。我的意識是根據自己所測的服務器對外提供了什么協議類型的API來進行相應的選擇，比如我所處的平台新服務器對外提供了HTTP協議的API和基於SessionManager的TCP協議的API。關於HTTP協議的壓測工具倒是有很多的，大家自己百度下，但是關於能測TCP協議的壓測工具，我知道的並且會使用的並不多，只知道可以用能支持socket協議的壓測工具來實現
– 2. 選的測試工具能按自己希望的步驟來編寫虛擬用戶腳本（而不是根據測試工具提供的錄制步驟來完成虛擬用戶腳本）
– 3. 有良好的場景設計功能
– 4. 有易於查看的輸出報告
– 5. 有中文文檔以及google或者百度等上能搜索到較多的疑問解答
綜上所述，我選擇了Loadruner作為我平台服務器初期的性能測試工具，而且loadrunner提供類C語言的腳本編寫（我們在大學都應該學過C/C++，有一定的基礎能幫助我們更快的熟悉腳本編寫）。但是由於loadrunner不易於擴展，是商用工具，要想免費使用只能用loadrunner11版本的破解版，loadrunner11是很早之前的版本，對於一些新功能是無法支持的（例如：我們開發提供了一個SDK的DLL，在LR11中無法加載運行，但在LR12中可以加載運行）。總之工具只是幫助我們完成任務的，要想更好的完成任務，我們就需要不斷的探索更多的解決辦法（以后我會分享其他的開源性能測試工具或者如何自己編寫一個適合我們被測系統的壓測代碼）
- Loadrunner的使用
– 下圖顯示的是LR的3個主要組件，其中Virtual User Generrator是用來編寫虛擬用戶腳本的
– Controller是用來設計場景的
– Analysis是用來分析運行數據，生成結果報告的
– 結合我實際工作中的項目來演示如何使用這3個組件的
Virtual User Generator
由於我們要自己來設計腳本執行的流程順序，暫時使用不到loadrunner提供的錄制功能，所以打開Virtual User Generator,點擊New Script然后選擇一個通用的協議，例如Web(HTTP/HTML)后點擊Create按鈕，經過這些步驟后，就為我們提供了一個初步的編寫腳本用的模版了
• Virtual User Generator
– 虛擬用戶腳本的設計是要考慮到典型場景的，例如一個會議室登錄多個用戶、多個會議室登錄多個用戶等等，接下來的demo將是針對一個會議室登錄多個用戶的場景的。先上圖再逐一分解
– 與最初創建的模版相比，發現上圖左邊的工程區里面多了cJSON.h和JsonDemo.dll2個文件，由於LR支持加載純C編譯的DLL，所以我們就可以像使用python那樣import XX包進來，然后直接使用其中的方法來幫助我們編寫腳本，關於cJSON.h和JsonDemo.dll2個文件這2個文件的作用，將在接下來的腳本分析中說明吧
先上2張我實際寫的項目腳本，為下面的解析提供依據：
Login_CreateGroup腳本：
- Virtual User Generator
– 如何找到純C的源程序，然后編譯成dll，最后導入到loadrunner中為我們所用？就拿剛剛的JsonDemo.dll來說明吧
– 1. 登錄到Json的官網（www.json.org），找到C的源碼然后下載
– 2. 打開Visual Stutio，New一個空的project，選擇Visual C++下的Win32 Console Application，然后把Application Type選擇為DLL
– 3. 右鍵點擊Header Files，Add一個Existing Item…把剛剛下載的C的源碼里面的cJSON.h添加進來，同樣右鍵點擊Source Files， Add一個Existing Item…把剛剛下載的C的源碼里面的cJSON.cpp添加進來
– 4. Build Solution生成DLL（編譯過程中如果有安全提示的話，可以在command line中輸入/D “_CRT_SECURE_NO_WARNINGS” 來解決）
platfrom_room腳本：
- Controller
– 虛擬用戶腳本已經編寫好了， 但是虛擬用戶腳本只是代表一個用戶的某種行為，要想實現並發操作，那就是要模擬很多用戶（例如2000個用戶）的相同操作。
– 在真正的實際設計場景前，有幾個概念需要理解下，什么是“系統用戶數”、“在線用戶數”、“並發用戶數”？舉一個例子來說明下， 假設有一個綜合性的網站，用戶只有在注冊后登錄系統才能夠享有新聞、論壇、博客、免費信箱等服務內容，通過數據庫統計知道了系統的用戶數量為4000人，4000即為“系統用戶數”；通過操作日志可以知道，系統最高峰時有500個用戶同時在線，這里“在線用戶數”即為500；這500個用戶的需求肯定是肯定是不盡相同的， 有的人喜歡看新聞、有的人喜歡寫博客、收發郵件等。假設70%的人在看新聞，10%的人什么也不干，剩下的20%的人寫博客（收發郵件或者不停的跳轉頁面），那么真正對服務器造成壓力的就是這500人中的20%（100人）。那么如何估算“並發用戶數”？
– （1）C=nL/T (2) C1=C+3 √3
– 在公式（1）中，C是平均的並發用戶數；n是login session的數量；L是login session的平均長度；T是考察的時間段長度。
– 在公式（2）中，C1是並發用戶數的峰值，C就是公式（1）中的得到的平均的並發用戶數。該公式的得出是假設用戶的login session產生符合泊松分布而估算得到的
– 下面給出一個實例來講述公式的應用。假設有一個OA系統，該系統有3000個用戶，平均每天有大約400個用戶要訪問系統，對一個典型用戶來說，一天之內用戶從登錄到退出系統的平均時間為4h，在一天之內，用戶只在8小時之內使用該系統。帶入公式（1）得到C=400*4/8=200，那么C1=200+3* √200=242
– 除了上述方法外，還有一種更為廣泛但精度比較差的根據經驗的方法，相應的經驗公式為：C=n/10和C1=r*C。通常用訪問系統用戶最大數量的10%作為平均的並發用戶數量；並發用戶數的最大數量可以通過在並發數上乘以一個調整因子r得到，通常r的取值為2~3。
– 當然在我實際測試過程中的話，我是根據負責人要求的來進行並發測試，比如我主管說服務器要支持5000的並發請求，那么我就按照5000來設計了，等服務上線后，我會查看日志、數據庫然后運用上面的公式再來分析每個階段實際的並發用戶數。
- Controller
– 1. 打開Controller，會出現一個“New Scenario”對話框，把剛剛編寫好的”Login_CreateGroup”和”platform_room”這2個腳本添加到“Scripts in Scenario”。為什么要添加2個腳本，而不是在一個腳本中把我們要操作的步驟全部編寫好呢？ 這就有點像寫代碼，我們會把一些經常要用的且能共用的弄成一個庫，那樣誰要用的時候就直接引入這個庫，會提高效率。所以在設計我平台服務器的性能腳本時候，我就盡量把每個接口都各自編寫成腳本，然后在場景設計中就把這些腳本進行組合。
– 2. 這里介紹下“Schedule by”中的2個重要選項“Scenario”和“Group”,Scenario(場景)：當你按場景進行計划時候，Controller將會同時運行所有參與場景的Vuser組，也就是說，定義的場景運行計划同時應用與所有Vuser組，而Controller將每個操作按比例應用與所有Vuser；Group（組）：當你按Vuser組進行計划時，參與場景的每個Vuser組按其自己單獨的計划運行，也就是說，對於每個Vuser組，你可以指定何時開始運行Vuser組，更直白一點的說，就是當Vuser組和Vuser組之間有依賴關系的時候，就用Group方式。
– 3. 接下來就說說我設計的場景，根據業務我需要先登錄驗證（會返回token），創建分組（會返回groupid），然后請求分配服務地址和登錄會議室，所以呢，我只需要登錄和創建分組一次，就能拿到后續登錄會議室需要的token和grouip，於是我只要運行腳本“Login_CreateGroup”一次，然后再運行腳本“platform_room”很多次就能實現“一個會議室同時登錄很多人”的場景，而且這里需要注意的一點是，這2個腳本是有依賴關系的，“Login_CreateGroup”是要在“platform_room”前面先執行完后，“platform_room”才能執行的。對應到Controller里面的設置如下圖：
- Controller
– 4. 場景設計完了， 接下來就可以執行了， 但是我們性能測試不單單只是給被測系統加壓， 我們還要關注整個測試過程中產生的數據， 然后選出我們所關心的數據，為進一步分析定位問題提供幫助。所以呢， 在開始RUN之前，我們先添加一下自己關心的，要監控的數據，下圖是我監控的一些數據：
- Controller
– 5. 接下來就可以RUN了， 在Running過程中可能會遇到一個問題就是loadrunner卡在那邊不動了， 然后后面的case都失敗了， 通過觀察監控的“Windows Resources”發現某一時段內CPU達到100%了，究其原因發現是因為設置太多的Vusers了（比如5000），這時候負載機因為自身的資源條件限制而引起的，為了解決這一問題，我們可以采用loadrunner的分布式加壓來解決。
– 什么是分布式加壓呢？ 分布式加壓其實就是用另外一台負載機來幫助我們實現一定量的Vusers，那么我們就需要在另一台負載機上安裝loadrunner11軟件，然后在本地負載機的Controller的Load Generators里Add另一台負載機的Name（可以填寫IP地址，比如192.168.6.173），然后點擊connect按鈕，查看status是否變為Ready狀態，最后就可以在不同的虛擬用戶組指定不同的負載機來幫助我們完成性能測試了。
– 具體操作步驟可以參考網上的資料：http://blog.csdn.net/wuyepiaoxue789/article/details/51799657
場景運行完成以后， 不代表我們的性能測試結束， 相反，這才是性能測試的開始，因為接下來，我們需要對運行數據進行分析，找出性能瓶頸，然后調優或者提交BUG。
- Analysis
– 在介紹Analysis的使用之前， 下面將針對一些常用的監控資源進行說明。
- 我大致將監控分為3類
- ①負載機的系統監控與被測系統監控（一般包括CPU使用率、內存、磁盤IO等）
- ②服務器處理能力的指標監控（一般包括吞吐量、每秒事物數、各個事物的響應時間、每秒單擊數等）
- ③網絡監控（根據經驗，就是查看對比前后流量，ping服務器等）
– CPU利用率（% Processor Time）：指處理器執行非閑置線程時間的百分比。這個計數器設計成用來作為處理器活動的主要指示器。它通過在每個時間間隔中衡量處理器用於執行閑置處理線程的時間，並且用100%減去該值得出。可將其視為范例間隔用於做有用工作的百分比。根據應用系統情況，在80%±5%范圍內波動為宜。過低，則服務器CPU利用率不高；過高，則CPU可能成為系統的處理瓶頸。
– 可用物理內存（ Available MBytes ）：當這個數值變小時，Windows開始頻繁地調用磁盤頁面文件。如果這個數值很小，例如小於5 MB，系統會將大部分時間消耗在操作頁面文件上。一般要保留10%的可用內存。最低不能<4M，此值過小可能是內存不足或內存泄漏。
– 磁盤IO（% Disk Time）：指所選磁盤驅動器忙於為讀或寫入請求提供服務所用的時間的百分比。正常值<10，此值過大表示耗費太多時間來訪問磁盤，可考慮增加內存、更換更快的硬盤、優化讀寫數據的算法。若數值持續超過80 (此時處理器及網絡連接並沒有飽和)，則可能是內存泄漏。
– 事務平均響應時間:（ Average Transaciton Response Time ）：隨着測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨着投產時間的變化，整體性能將會有下降的趨勢。好<2s、良好2~5s、差6~10s
– 吞吐量（ Throughput ）:可以依據服務器的吞吐量來評估虛擬用戶產生的負載量，以及看出服務器在流量方面的處理能力以及是否存在瓶頸。
– 每秒點擊次數（ Hits per Second ）:通過對查看“每秒點擊次數”，可以判斷系統是否穩定。系統點擊率下降通常表明服務器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。
虛擬用戶數（Running Vusers）: 這個主要用於與其他監控數據結合來分析問題的。
- Analysis
- 執行結果分析過程
– 場景執行完成以后，需要對運行過程中收集的數據信息進行分析，從而來了解系統性能表現能力，確定系統性能瓶頸。在Loadrunner Controller中，通過單擊【Results】>【Analyze Results】菜單項，啟動Loadrunner Analysis應用，如果左側的Graphs中沒有出現你想要的圖，就點擊工具條按鈕“Add New Graph…”，把關心的圖加入進來，如下圖：
- Analysis
- 合並圖的應用
– 有時候看單一的圖，很難看出圖與圖之間的關聯，所以這時候，我們可以采用合並圖來進行有機的結合。合並圖的方法就是先選擇一張合並圖，然后在圖的空白處單擊鼠標右鍵選擇【Merge Graphs…】選項，接着選擇被合並圖（可以選擇合並圖類型、可以更改標題），如下圖：
- Analysis
- 合並圖的應用
合並圖共提供了3種方式：疊加（Overlay）、平鋪（Tile）和關聯（Correlate），下面針對這3種合並方式做一下簡單的介紹。
（1）疊加方式：使得兩個圖使用相同橫軸的圖的排列方式。合並圖的左側縱軸顯示當前圖的值，右側縱軸顯示被合並圖的值。
（2）平鋪方式：兩個圖一個位於另一個之上，合並圖在下方，而被合並圖在上方，使得兩個圖共同使用一個橫軸，兩個圖分別使用擱置的縱軸
（3）關聯方式：使得合並圖的縱軸將變成合並圖的橫軸，被合並圖的縱軸將變成合並圖的縱軸。