1. 如何對API進行負載測試與調優（一）
本文由Donny譯自 3scale.com 的 《How to load test & tune performance on your API》
這幾年API的作用不斷演化，以前API還只是用來做內部系統之間的集成點，但現在API已成為一個公司的核心系統，一個構建於Web和移動端應用之上的核心系統。
當API僅只用來處理後台的任務（例如生成報告），那麼性能差點也不是問題。但是如今API慢慢地發展成為連接服務與終端用戶的核心紐帶。這種關鍵性的角色變化表明了一個重要的觀點：那就是API的性能真的很重要。
如果API數據源響應快，前端的應用程序的設計好點或差點影響不大，要是響應慢如蝸牛，前端的設計再出色也是然並卵。現在我們的客戶端應用展羨旅示的數據源可能都是來自多個API響應內容的聚合，性能對這種微服務構架來說真的非常重要。
可以毫不誇張的說出色的性能就是你API提供的最好功能。我們知道向目標改進的唯一正確的方法就是找到問題的關鍵點，或者叫關鍵路徑，並不斷迭代測量和調整你的架構系統，直到系統達到預定的目標。對於API來說，測量和提高性能的過程就是負載與壓力測試的過程。
本文將重點介紹如何對你的API進行負載壓力測試。我們會以一個簡單的、未測過的例子開始，然後再添加一個訪問控制層，要確保一切都經過嚴格測試，做好處理真實流量的准備工作。OK，開始吧！
首先我們要明確要測試什麼，可以是對你所有的API介面，或者是對單個API介面，或是對需要排除故障或改進的API介面的常規測試。
本文的其部分，我們將使用一個示例API。這是一個棋牌類游戲的Node.js API。它有三個API介面：
/question – 返回一個隨機黑牌
/answer – 返回一個隨機白牌
/pick – 返回一對隨機的問題與答案
你測試用的負荷情況越和真實環境的越類似，你的負載測試就越有用。如果你不知道實際流量有多少或者你不知道負載在所有介面上是否都一致，那麼就算你知道你的API可以保持400 請求/秒的吞吐量也沒啥鳥用。
所以，你應該先從收集你兄冊凳API的使用數據開始。你可以直接從你的API服務日誌或者從其他你在用的應用性能工具（例如New Relic）中獲取數據。在對你的API進行第一次測試之前，你應該對以下問題做到心中有數：
（1）每秒請求數的平均吞吐量（Average throughput in requests per second）
（2）峰值吞吐量（您在某段時間內獲得的最大流量是多少？）（Peak throughput）
（3）API各介面的吞吐量分布情況（有沒有一些介面的流量遠姿野超其他介面？）
（4）用戶的吞吐量分布情況（少數用戶產生大多數的流量，或者是更均勻分布？）
另外還需要考慮的一個關鍵點是，在測試期間將要模擬的流量會是怎樣的，主要考慮點是：
（1）重復負載生成（Repetitive load generation）
（2）模擬流量模式
（3）真實流量
通常我們最好以最簡單的方法開始測試，然後逐步演化到更為接近真實環境的測試。我們可以先用重復負載生成來做為API介面的第一個測試，這樣不僅可以驗證我們的測試環境是否穩定，更重要的是可以讓我們找到API能承受的最大吞吐量，這樣我們就可以知道API可以達到的性能上限是多少。
找到你的API性能上限值後，你就可以開始考慮如何將你的生成的測試流量塑造得更接近真實環境。使用真實流量來測試是最理想的，但實際操作不太可行。要模擬真實流量比較難，也太花時間。所以我們有一個折中點的方法：先研究你的流量分析數據，並做一個簡單的概率模擬。比如你有100個API介面（提示：原文endpoint在這里我譯為介面，翻譯成端點也可以，不過譯成介面感覺更容易理解），你檢查了上個月的使用情況，發現80%的流量來自20個介面，其中3個介面佔用了50%的流量。那麼你就可以創建一個遵循這種概率的請求列表，並提供給你的負載測試工具。這樣做就相對快多了，並且它相對比較接近你真實負載，可以顯示出你實際環境中可能遇到的問題。
最後，如果你拿到你要測試的API的真實訪問日誌，你就可以用它們來做最接近客觀現實的測試。我們待會兒要討論的大部分負載測試工具，都是接收一個請求列表作為輸入文件。你可以用你的訪問日誌，稍微做一個格式調整就可以匹配每個測試工具所需的格式。搞定這個你就可以在測試環境中輕松重現你的生產流量。
好了，你清楚了你要測試什麼鬼了，准備工作的最後一步就是配置好你的測試環境。你需要一個專用的測試環境。如果你不怕被你老闆罵的話，或者比較任性，你也可以直接在你的生產環境中進行性能測試，不過出問題別說哥事先沒跟你說清楚哈。
如果您已經設好一個預生產或沙箱環境，並且你的API也在上面運行了，那麼你就萬事俱備了。因為本文要用示例API，我們會在AWS的服務實例上設置我們的環境。
在我們的例子中，我們使用一個簡單的API，不需要從磁碟讀取或在內存中保存大型數據集。我們選擇Linux C4.large 實例就夠了。
注意：我們對比過其他相似處理資源數但內存更大的AWS實例，但實際測試中內存大部分沒使用，所以我們選了C4.large
接下來，我們將一個配好的負載測試實例（伺服器）運行起來，這只是一個運行模擬測試程序的伺服器，它會通過從多個並發連接重復發送請求到我們的API伺服器。你需要模擬的負載越高，機器的性能就要求越高。再次，這也是一個CPU密集型工作負載。這里我們選擇具有4個虛擬核，16個 ECU的優化處理器的 c4.xlarge AWS伺服器
我們選擇在相同的可用區內部署所有實例（API伺服器與測試伺服器在同一個區/機房），這樣可以將外部因素對我們測試結果的影響降到最小。
我們有一個沙箱環境來運行我們的API，同時也有另一台伺服器准備開始負載測試。如果這是你第一次做性能測試，你一定會想知道什麼是最好的方法。在本節中，我們將會分享我們如何選擇工具，同時也會介紹一下目前市面上一些公認比較好的工具。
JMeter
在人們意識當中，首當翹楚的估計是 Apache JMeter ，這是一個開源的Java程序，他關鍵的特性就是提供一個強大而完善的創建測試計劃的GUI。測試計劃由測試組件組成，測試組件定義了測試的每一個部分，例如：
（1）用來注入負載測試的線程
（2）參數化測試中使用的HTTP請求
（3）可添加偵聽器，象widget測試組件那樣，可以以不同的方式顯示測主式結果
優點：
（1）它是功能性負載測試的最好工具。你可以設定條件來為復雜的用戶流建模，還可以創建斷言來驗證行為。
（2）輕松模擬復雜的http請求，比如請求前的登錄驗證或文件上傳
（3）可擴展性強，有很多社區插件可以修改或擴展內置的行為
（4）開源並且免費
缺點：
（1）GUI學習曲線陡峭，一大堆的選項，在你運行第一個測試之前你得了解大量的概念。
（2）測試高負載時，操作步驟很麻煩。你需要先使用GUI工具來生成XML測試計劃，然後在非GUI模式下導入測試計劃運行測試，因為GUI會消耗掉本用於生成負載的大量資源。你還需要注意所有的偵聽器（收集數據與展示測量的組件）哪些要被禁用或啟用，因為它們也很耗資源。測試結束後後，你需要將原始結果數據導入GUI以才能查看結果。
（3）如果你的目標是測試一段時間內的持續吞吐量（例如在60秒內每秒請求1000次），那麼很難找到正確的並發線程數量和計時器來求出一個比較穩定的數值。
JMeter只是我們在開始測試時用的工具，我們很快開始尋找其他替代方案。原因是，如果你的目標是在Web應用上壓力測試復雜的用戶流，那麼JMeter可能是最好的工具，但如果你只是需要在一些HTTP API介面上進行性能測試，那用它就是殺雞用牛刀了。
Wrk
Wrk 是一款和傳統的 Apache Benchmark （最初用來做Apache伺服器的測試工具）非常相似的工具。wrk和ab完全不同於JMeter：
（1）一切都是可以通過命令行工具配置和執行的。
（2）配置少但強大，只有基本生成HTTP負載的必要幾項配置
（3）性能強悍
然而，和傳統ab工具相比還是有幾個優勢的地方，主要是：
（1）多線程，所以能利用多核處理器的優勢，更容易生成更高的負載
（2）利用Lua腳本很容易進行擴展默認的行為
不好的地方，主要是生成的默認報告在內容與格式上都受到限制（僅文本，無繪圖）。當你的目標是找到你的API可以處理的最大負載量，那麼wrk是你最佳選擇工具。wrk用起來很快就可以上手。
Vegeta
Vegeta 是一款開源命令行工具，但它採用的方式不同於我們以前所見的工具。它專注於如何達到與維持每秒請求數速率。也就是說它側重在測試支撐每秒X次請求時API會有怎樣的服務行為，當你有實際的數據或對你將要達到的峰值流量有個估算時就非常有用，你可以用於驗證你的API是否能滿足你的需求。
SaaS 工具
正如你之前所看到的，運行一個簡單的負載測試需要准備好配置環境。最近有些產品提供負載測試服務。我們試過兩個， Loader.io 和 Blazemeter （話外：阿里也有性能測試工具 PTS ，老外估計沒試過）。
注意：我們只試了這兩個工具的免費版，所以得到的測試結果僅適用於免費版的限定。
Blazemeter
這個產品和我們前面提到的JMeter一樣有同樣的毛病：如果你只需要用在高負載測試，你需要在GUI界面上創建測試計劃，然後在另一個運行非GUI模式的JMeter中導入這些計劃。Blazemeter允許你上傳JMeter的測試計劃到他們的雲端並運行，但可惜的是免費版只能設置50個並發用戶。
Loader.io
它是一款 SendGrid 出品的簡單而強大的雲負載測試服務工具。它有你所需要的功能和漂亮的可視報告。 Loader.io 的免費版還是不錯的，每秒最多可以有10000次請求的吞吐量，你基本上就可以用它來運行一個真實的負載測試。
我們推薦使用多個工具，以便可以多重檢查我們的測試結果，不同的工具有不同的功能與方法，可以更多方面地反映測試結果。
我們先嘗試找到我們的API可以承受的最大吞吐量。在這個吞吐量下，我們的API服務達到最大CPU利用率，同時不會返回任何錯誤或超時。這個吞吐量就可作為我們後面測試要用的每秒請求數。
同樣，重要的是要注意到：CPU是限制因素之一，但你也還必須清楚地知道哪些資源會成為你API的性能瓶頸。
我們有必要在API伺服器上安裝一些工具，以便我們在測試過程中監控資源的利用率情況。我們使用 Keymetrics.io 和 PM2 模塊。
我們的Node.js應用運行了一個非常簡單的HTTP 服務。Node.js是單線程設計的，但為了利用c4.large AWS實例中提供的雙核，我們使用PM2的集群功能來運行應用程序的兩個工作進程。
由於我們的API是完全無狀態的，所以很容易使用PM2的 核心集群模塊（PM2在內部直接使用）。PM2提供的集群功能提供了不錯的快捷命令來start/stop/reload應用程序，也可以監控進程。
我們先使用Loader.io對API進行測試。以下是持續30秒，每秒10,000次請求的測試結果，10000次請求是Loader.io免費版中允許的最大吞吐量。
在測試期間，我們觀察到API伺服器的CPU處理器在測試期間只有幾次達到100％的容量。
這表示我們的API可能還可以處理更高的吞吐量。我們接下來通過運行wrk進行第二次測試證實了這一點。我們的目標就是要將我們的API伺服器性能推到極限。
wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions
這里是我們對這個測試做了多次重復測試的結果：
Running 1m test @ http://api-server/question
4 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 62.23ms 30.85ms 1.35s 99.39%
Req/Sec 4.07k 357.61 5.27k 94.29%
Latency Distribution
50% 60.04ms
75% 63.85ms
90% 64.17ms
99% 75.86ms
972482 requests in 1.00m, 189.89MB read
Requests/sec: 16206.04
Transfer/sec: 3.16MB
結果表明，我們的預感被證實：它達到16,206請求/秒，同時保持合理的延遲，第99百分位只有75.86毫秒。 我們將這作為我們的基準最大吞吐量，因為這一次我們看到了API伺服器的最大容量處理能力：
我們剛看到用一個簡單的方式來找出你的API可承受的最大流量負載，同時在這過程中我們介紹並討論了我們看到的一些工具。
請繼續關注本文的第二部分，我們將介紹如何控制流量，不要讓隨隨便便一個客戶端就可以輕松搞跨您的API。 我們將展示如何通過在架構前端添加代理來確保我們的API的性能不受影響。
本文譯自： How to load test & tune performance on your API
2. 如何對Web應用程序進行負載測試
定義測試策略 到目前為止，您肯定參加過這樣的會議，客戶倚靠在寬大的會議桌上，問您：「這個系統能處理上千個用戶嗎？」傳統的負載測試方法要求您編寫腳本並執行測試，以試圖給出此問題的精確答案。對於這種測試，您需要定義「處理」的含義以及 1000 名典型用戶在站點活動時的情形。您需要定義測試用例以代表各種用戶活動：例如，購買股票或注冊新的帳戶。接下來，您必須估計用戶在這些測試用例上的分布。對以下數據進行假設，即模擬真實用戶與應用程序交互時，需要多長的思考時間（或等待時間）。因此，負載測試期間活動的可從某個方面大致反映出同樣數量的真實用戶在站點活動時的情形。 這種方法有幾個不足之處。首先，其結果不會比您做的假設更好。顯然，不正確的假設將使結果出現偏差。 其次，估計真實用戶需要大量客戶端硬體。如果對每名虛擬用戶給定需要的處理能力和內存量，則典型的客戶端計算機可以處理大約 200 名虛擬用戶。因此，對 2000 名用戶並發處理級別的測試需要 10 台客戶端計算機 — 這是一筆重大投資。測試使用 HTTPS 的站點將需要多得多的客戶端硬體。 最終，此方法難以向您的開發團隊提供以操作為導向的信息。當某處出現故障時，常常難以再現該問題。 作為備選方案，我們建議您圍繞以下這些關鍵問題設計測試用例： �6�1 系統瓶頸在哪裡？系統能同步處理多少個並發請求？ �6�1 在響應時間變得不可接受之前，一台機器能處理多少名不同步的超級用戶？ �6�1 添加額外的硬體時，結果是線形增長的嗎？ �6�1 有任何穩定性問題會妨礙站點運行於生產環境中嗎？ 此方法將使用開發團隊（此開發團隊參與可能出現問題的領域）提供的附加信息。請關注這些領域。對於上一個示例，其瓶頸可能出在定單提交領域。從這里您可以派生出更具體的問題，例如「提交流程可以同時處理多少個請求？」攻擊這些特定領域是最快且成本最小的方法，用來向開發團隊提供以操作為導向的信息，以便他們能改進系統。在使用這種方法的同時，我們推薦您記住遵循以下建議。 關注負載測試正如我們已提到的那樣，首先要做的是構建導致潛在瓶頸和穩定性問題的腳本。這種「數據第一，假設第二」的方法使您能夠從應用程序收集原始數據，然後根據假設確定更高級別的結果。不用擔心為識別低風險站點的腳本編寫問題。例如，為站點的幫助領域或只讀文檔領域編寫腳本不大可能出現系統瓶頸。 同步請求使用同步請求攻擊瓶頸。此處的這個主意是模擬最壞的情況：即，站點上的用戶精確地在同一時間攻擊瓶頸。通過使用戶同步，您可以重復進行此測試。如果不同步結果，則難以再現故障情況。可以使用同步點做到這一點，同步點是大多數較健壯（成本也較高）的測試工具中提供的一項功能。同步點迫使每名虛擬用戶一直等到剩餘的用戶到達腳本中定義的點後，才能開始下一請求。它允許您精確並重復地確定站點的潛在瓶頸區域能處理的並發用戶數。例如，下限可以是 7 名並發同步用戶。 創建循環測試用例腳本使測試用例循環。在另一種方法中，每次測試用例迭代前後，站點應處於相同狀態。這允許您長時間地重復運行測試用例。 使用超級用戶最後，使用我們所稱的超級用戶。正如前面所提到的，超級用戶運行時思考時間設置為零。請記住，思考時間假設是用於常規測試中，以使虛擬用戶模擬真實用戶。但是，如果將虛擬用戶思考時間減半，則伺服器的實際負載將加倍。在另一種方法中，伺服器真正關心的與負載有關的變數是每秒的請求數。虛擬用戶的數量及其思考時間結合起來生成該負載。 讓我們進行一些數學運算以使此概念更清晰。下面的公式計算訪問站點的真實用戶生成的負載（請求數/秒）： 例如，某個站點有 100 名並發用戶，假設下載時間為 10 秒，思考時間為 30 秒，則每秒將生成 2.5 頁。如果我們假設每頁 3 個請求，則在 Web 伺服器上將轉化為每秒 7.5 個請求。 以超級用戶運行測試時，觀察每秒請求數，並與剛剛計算的值比較。根據我們的經驗，真實用戶數與超級用戶數的比例通常約為 15:1。對於同一個示例，這意味著 (100/15) 名超級用戶將生成與 100 名普通用戶相同的負載。再舉一個例子，假設在 10 名超級用戶之後響應時間變得不可接受。請注意轉換回真實用戶數的該點每秒請求數。現在您可以進行任何希望的思考時間假設，甚至可以更改它而無需重新運行測試。在幾天的測試之後，您將能根據直覺從超級用戶數轉換成真實用戶數。此方法允許您保持用戶數可控，減少所需的客戶端硬體數量，並包含負載測試軟體的成本。 這些超級用戶測試用例對於多機測試很有用。要測試站點的可伸縮性，可添加第二台 Web 伺服器和一個負載平衡器，並重復超級用戶測試。理想情況下，在看見相同的相應次數之前，您將能加倍超級用戶數量。 要回答穩定性問題，可運行測試，以在延長的時間段內維持合理數量的並發且未同步超級用戶。我們在上一個項目中熬了很多個通宵，甚至 24 小時晝夜不停，但持續時間與應用程序有關。我們稱之為「內置」測試。一旦您已採取步驟識別並潛在地解決了找到的瓶頸，則重復同步點測試，看下限是否有所增長。然後用所支持的新的並發用戶數重新運行「內置」測試。以努力提高此數字為目標重復該循環，直到達到質量條。 但是有多少用戶呢？ 盡管此方法向開發團隊提供了有價值的信息，但它使得您更難於回答會議室的問題。不過，您可以近似地估計答案。例如，假設站點的最壞情況瓶頸顯示，每台計算機多於 20 名超級用戶的情況下，響應時間超過 10 秒。根據您從我們建議的公式計算的結果，近似地估計有 300 名真實用戶（20 名超級用戶 × 15 名真實用戶）。此時，您可以做出與常規用例中相同的假設。通常情況下，有百分之多少的用戶正在使用站點的此領域？假設預期 50% 的用戶正在使用此領域，而其他領域，例如文檔或資料庫讀取，用戶比例則沒有這么大。這意味著具有一台 Web 伺服器的系統將處理大約 600 名用戶。 到目前為止，我們已討論了在能明確地指向站點的一個瓶頸領域的情況下該如何做，但如果影響性能的領域不止一個時您又應如何做呢？答案是創建單獨查看各個領域的測試腳本。首先孤立地運行這些腳本，然後一起運行。再比較結果，看站點的一個領域對另一個領域的影響有多大。
3. loadrunner包含哪些組件
1．Virtual User Generator（虛擬用戶生成器）用於捕獲最終用戶業務流程和創建自動性能測試腳本（宴冊也稱為虛擬用戶腳本）。
2．Controller 用於組織、驅純祥知動、管理和監控負載測試
3．負載生成器用於通過運行虛擬做消用戶生成負載
4．Analysis 有助於您查看、分析和比較性能結果
5．Launcher 為訪問所有 LoadRunner 組件的統一界面
4. loadrunner如何使用
1、使用LoadRunner 完成測試一般分為四個步驟：
2、Vvitrual User Generator 創建腳本
創建腳本，選擇協議
錄制腳本
編輯腳本
檢查修改腳本是否有誤
3、中央控制器（Controller）來調度虛擬用戶
創建Scenario，選擇腳本
設置機器虛擬用戶數
設置Schele
如果模擬多機測試，設置Ip Spoofer
4、運行腳本
分析scenario
分析測試結果
5、安裝LoadRunner 中文版
LoadRunner 分為Windows 版本和Unix 版本。如果我們的所有測試環境基於Windows
平台， 那麼我們只要安裝Windows 版本即可。本章講解的安裝過程就是LoadRunner7.8中文的Windows 版本的安裝。
6、使用LoadRunner進行負載/壓力測試
7、錄制基本的用戶腳本
創建用戶腳本需要用到VuGen。提示： 運行VuGen 最好在1024*768 的解析度下， 否則有些工具欄會看不到。
啟動Visual User Generator 後， 通過菜單新建一個用戶腳本， 選擇系統通訊的協議。
這里我們需要測試的是Web 應用，同時考慮到後台SQL資料庫所以我們需要選擇Web(HTTP/HTML)協議＋SQL SERVER協議，確定後， 進入主窗體。通過菜單來啟動錄制腳本的命令。
8、在URL 中添入要測試的Web 站點地址..。
●測試http://lms.ah.sp.com.cn/lms-lmm/loginForm.do選擇要把錄制的腳本放到哪一個部分， 默認情況下是「Action」。
這里簡單說明一下：VuGen 中的腳本分為三部分：vuser_init、vuser_end 和Action。其
中vuser_init 和vuser_end 都只能存在一個， 不能再分割， 而Action 還可以分成無數多個部分（ 通過點擊New 按鈕， 新建ActionXXX）。在錄制需要登陸的系統時， 我們把登陸部分放到vuser_init 中， 把登陸後的操作部分放到Action 中， 把注銷關閉登陸部分放到vuser_end 中。（ 如果需要在登陸操作設集合點， 那麼登陸操作也要放到Action 中， 因為vuser_init 中不能添加集合點） 在其他情況下， 我們只要把操作部分放到Action 中即可。注意： 在重復執行測試腳本時，vuser_init 和vuser_end 中的內容只會執行一次， 重復執行的只是Action 中的部分。
點「 選項 」按鈕， 進入錄制的設置窗體， 這里一般情況下不需要改動。
●然後點「OK」 後，VuGen 開始錄制腳本。在錄制過程中， 不要使用瀏覽器的「 後退」 功能，LoadRunner 支持不太好！ 錄制過程中， 在屏幕上會有一個工具條出現。錄制的過程和WinRunner 有些類似， 不再多介紹。錄制完成後， 按下「 結束錄制」 按鈕，VuGen 自動生成用戶腳本， 退出錄制過程。
完善測試腳本
當錄制完一個基本的用戶腳本後， 在正式使用前我們還需要完善測試腳本， 增強腳本的
靈活性。一般情況下， 我們通過以下幾種方法來完善測試腳本。插入事務、插入結合點、插入註解、參數化輸入。這里只舉例介紹參數化如何設置，其它只作簡單介紹。
插入事務
事務（Transaction）： 為了衡量伺服器的性能， 我們需要定義事務。比如： 我們在腳本
中有一個數據查詢操作， 為了衡量伺服器執行查詢操作的性能， 我們把這個操作定義為一個事務， 這樣在運行測試腳本時，LoadRunner 運行到該事務的開始點時，LoadRunner 就會開始計時， 直到運行到該事務的結束點， 計時結束。這個事務的運行時間在結果中會有反映。
插入事務操作可以在錄制過程中進行， 也可以在錄制結束後進行。LoadRunner 運行在
腳本中插入不限數量的事務。
具體的操作方法如下： 在需要定義事務的操作前面， 通過菜單或者工具欄插入。輸入該事務的名稱。注意： 事務的名稱最好要有意義， 能夠清楚的說明該事務完成的動作。插入事務的開始點後， 下面需要在需要定義事務的操作後面插入事務的「 結束點」。同樣可以通過菜單或者工具欄插入。默認情況下， 事務的名稱列出最近的一個事務名稱。一般情況下， 事務名稱不用修改。事務的狀態默認情況下是LR_AUTO。一般情況下， 我們也不需要修改， 除非在手工編寫代碼時， 有可能需要手動設置事務的狀態。
插入集合點
插入集合點是為了衡量在加重負載的情況下伺服器的性能情況。在測試計劃中， 可能會
要求系統能夠承受1000 人同時提交數據，在LoadRunner 中可以通過在提交數據操作前面加入集合點， 這樣當虛擬用戶運行到提交數據的集合點時，LoadRunner 就會檢查同時有多少用戶運行到集合點，如果不到1000 人，LoadRunner 就會命令已經到集合點的用戶在此等待， 當在集合點等待的用戶達到1000 人時，LoadRunner 命令1000 人同時去提交數據， 從而達到測試計劃中的需求。
注意： 集合點經常和事務結合起來使用。集合點只能插入到Action 部分，vuser_init 和vuser_end 中不能插入集合點。具體的操作方法如下： 在需要插入集合點的前面， 通過菜單或者工具欄操作輸入該集合點的名稱。注意： 集合點的名稱最好要有意義， 能夠清楚的說明該集合點完
成的動作。
插入注釋
注釋的作用就不多說了， 不過插入注釋最好是在錄制過程中。具體的操作方法如下： 在需要插入注釋的前面， 通過菜單或者工具欄操作
參數化輸入
如果用戶在錄制腳本過程中， 填寫提交了一些數據， 比如要增加資料庫記錄。這些操作
都被記錄到了腳本中。當多個虛擬用戶運行腳本時， 都會提交相同的記錄， 這樣不符合實際的運行情況， 而且有可能引起沖突。為了更加真實的模擬實際環境， 需要各種各樣的輸入。參數化輸入是一種不錯的方法。
用參數表示用戶的腳本有兩個優點：
① 可以使腳本的長度變短。
② 可以使用不同的數值來測試你的腳本。例如， 如果你企圖搜索不同名稱的圖書， 你
僅僅需要寫提交函數一次。在回放的過程中， 你可以使用不同的參數值， 而不只搜索一
個特定名稱的值。
參數化包含以下兩項任務：
① 在腳本中用參數取代常量值。
② 設置參數的屬性以及數據源。
參數化僅可以用於一個函數中的參量。你不能用參數表示非函數參數的字元串。
另外， 不是所有的函數都可以參數化的。
參數化輸入的講解， 我們採用一個例子的方式來進行。
在本例中我們參數化用戶的登陸名：
先看如下腳本，通過腳本錄制找到用戶登陸部分，如圖
參數名隨意取，建議取通俗易懂的名字，下面我們重點介紹一下參數的類型。
●DateTime： 很簡單， 在需要輸入日期/時間的地方， 可以用DateTime 類型來替代。
其屬性設置也很簡單， 選擇一種格式即可。當然也可以定製格式。
.●Group Name：暫時不知道何處能用到，但設置比較簡單。在實際運行中，LoadRunner
使用該虛擬用戶所在的Vuser Group 來代替。但是在VuGen 中運行時，Group Name
將會是None
.●Load Generator Name： 在實際運行中，LoadRunner 使用該虛擬用戶所在Load Generator 的機器名來代替。
.●Iteration Number： 在實際運行中，LoadRunner 使用該測試腳本當前循環的次數來
代替。
.●Random Number： 隨機數。很簡單。在屬性設置中可以設置產生隨機數的范圍
.●Unique Number：唯一的數。在屬性設置中可以設置第一個數以及遞增的數的大小。
注意： 使用該參數類型必須注意可以接受的最大數。例如： 某個文本框能接受的
最大數為99。當使用該參數類型時， 設置第一個數為1， 遞增的數為1， 但100 個
虛擬用戶同時運行時，第100 個虛擬用戶輸入的將是100，這樣腳本運行將會出錯。
注意： 這里說的遞增意思是各個用戶取第一個值的遞增數， 每個用戶相鄰的兩次循
環之間的差值為1。舉例說明： 假如起始數為1， 遞增為5， 那麼第一個用戶第一
次循環取值1， 第二次循環取值2； 第二個用戶第一次循環取值為6， 第二次為7；
依次類推。
●Vuser ID： 設置比較簡單。在實際運行中，LoadRunner 使用該虛擬用戶的ID 來代
替，該ID 是由Controller 來控制的。但是在VuGen 中運行時，Vuser ID 將會是–1。
File： 需要在屬性設置中編輯文件，添加內容，也可以從現成的資料庫中取數據（ 下
面我們將會介紹）
●User Defined Function： 從用戶開發的dll 文件提取數據。就目前我認為， 這種方式
沒有必要。VuGen 支持C 語言的語法，在VuGen 中重新編寫類似的函數應該不難。
上面的例子中， 我們取隨機數即可。點「Properties… ..」 按鈕， 進行屬性設置窗口
添入隨機數的取值范圍為（1-50）， 選擇一種數據格式。在「屬性」 中有以下幾
個選項：
◆Each Occurrence：在運行時， 每遇到一次該參數， 便會取一個新的值
◆Each iteration：運行時， 在每一次循環中都取相同的值
◆Once：運行時， 在每次循環中， 該參數只取一次值
這里我們用的是隨機數， 選擇Each Occurrence 非常合適。
下面我們再介紹用資料庫中的用戶名來參數化登陸用戶名。
框選住登陸名，點滑鼠右鍵，彈出對話框，選擇「替換為新參數」彈出對話框，此時參數名輸入：name，參數類型選擇File，如圖
注意： 參數的文件名不要使用con.dat、pm.dat 或者lpt*.dat 等系統裝置名下面我們將會連接資料庫， 從數據表中選擇用戶名。點「數據向導」 按鈕，顯示如圖
添入連接字元串， 點「創建」 按鈕，選擇事先配置好的ODBC連接。在SQL語句里輸入select查詢語句，出現如圖窗口
提醒： 在參數數據顯示區， 最多隻能看到100 行， 如果數據超過100 行， 只能點「編輯」 按鈕， 進入記事本看。
「選擇下一行 」 有以下幾種選擇：
●Sequential： 按照順序一行行的讀取。每一個虛擬用戶都會按照相同的順序讀取
●Random： 在每次循環里隨機的讀取一個， 但是在循環中一直保持不變
●Unique ： 唯一的數。注意： 使用該類型必須注意數據表有足夠多的數。比如Controller 中設定20 個虛擬用戶進行5 次循環， 那麼編號為1 的虛擬用戶取前5 個數， 編號為2 的虛擬用戶取6-10 的數， 依次類推， 這樣數據表中至少要有100 個數據， 否則Controller 運行過程中會返回一個錯誤。
「按編號」指選擇列表中的那一列數據，從左到右分別是1、2、3依次
通常用在有關聯性的數據上面。我們這里取值Sequential 即可。完成設置關閉即可
4.3 單機運行測試腳本
經過以上的各個步驟後， 腳本就可以運行了。運行腳本可以通過菜單或者工具欄來操作。
執行「 運行」 命令後，VuGen 先編譯腳本， 檢查是否有語法等錯誤。如果有錯誤，VuGen
將會提示錯誤。雙擊錯誤提示，VuGen 能夠定位到出現錯誤的那一行。為了驗證腳本的正
確性， 我們還可以調試腳本， 比如在腳本中加斷點等， 操作和在VC 中完全一樣， 相信大家誰都不會感到陌生。如果編譯通過， 就會開始運行。然後會出現運行結果。