第5章
VU——用戶行爲的模擬器
LoadRunner之所以強大，很大的原因是VU的功能強大。作爲虛擬用戶的產生器，從橫向上看，VU幾乎支持模擬當今所有主流的軟件客戶端，同時還在不斷地推陳出新；從縱向上看，每個Vuser腳本的設置也是非常繁多和詳細的，達到了精確模擬的效果。
因此，瞭解並熟悉VU是我們“玩轉”LoadRunner要做的第一件事情。
我們最常聽到的關於VU的描述就是：VU通過運行VU腳本模擬了用戶對軟件的操作行爲。
如果我們不刨根問底，探究實質，就難以發現上面這句話的奧妙。
5.1 序：圖靈試驗與LoadRunner VU模擬奧祕
5.1.1 圖靈試驗場景
偉大的計算機之父阿蘭•圖靈曾對人工智能設計過一個著名的“圖靈試驗”，來判斷計算機對人類的模擬能力，圖靈試驗場景如圖5-1所示。
圖靈試驗由計算機、被測試的人和主持試驗的人組成。計算機、被測試的人和測試主持人分別在三個不同的房間內。測試過程是由主持人提出問題，由計算機和被測試人分別回答。被測試人回答問題是儘可能地表明他是“真正的”人，計算機也儘可能逼真地模仿人的思維方式和思維過程。如果試驗主持人聽取對問題的回答後，分不清哪個是人回答的，哪個是計算機回答的，則可以認爲被測試計算機是有人的智能的。
圖5-1 圖靈試驗場景
我們從這個試驗中可以看到模擬需要有三個要素：模擬者（計算機）、被模擬者（真實的人）和觀察者（主持人）。其中觀察者是很重要的一個角色，模擬只有對觀察者纔有意義。而在圖靈試驗中，觀察者通過一定的方式（聞其“答案”不見其人）來判斷這個模擬是否成功。
5.1.2 LoadRunner模擬揭祕
再回頭看看那句話：“VU通過運行VU腳本模擬了用戶對軟件的操作行爲。”與之對應，我們能找到VU是模擬者，用戶是被模擬者，但這句話裏沒有指出觀察者。那麼觀察者是誰？我們性能測試工程師是觀察者麼？顯然不對，用戶的操作行爲是一次次鍵盤輸入，一個個鼠標點擊，而VU在我們眼裏只是一行行腳本程序和配置文件。
想到這裏，可能已經有人得到了答案。沒錯，觀察者其實就是性能測試中被測服務器。
我們發現，完全可以把圖靈試驗應用到我們的VU模擬場景中：
在軟件系統運行時，一個真實的用戶通過操作軟件客戶端來發起和服務器的會話請求，同時，一個VU開始運行它的腳本，也發起了同樣的請求。被測服務器在處理各個“交談”請求並與之分別會話的時候，並不知道哪些請求是來自真實的用戶，哪些是來自VU。這樣，VU成功地模擬了真實的用戶，“騙過”了被測服務器。當然，VU要實現這個目標，之前還需要通過認證，構造合法的請求等步驟，這些VU都要加以實現。
我們弄明白了觀察者是被測服務器這件事情後，有些知識點就清楚多了。
事實：VU是基於網絡協議的。
很明顯，被測服務器是通過各種各樣的網絡協議與客戶端打交道的。VU要“騙過”被測服務器，當然就要遵守這些協議，按規矩、按步驟來動作，否則就會吃“閉門羹”，毫不留情地被服務器拒絕。實際上，如果我們留心的話，可以發現VU每個協議相關的函數都是緊緊圍繞其網絡協議的實現的。同樣，VU錄製生成的也是網絡協議層次的腳本。在回放時，VU將按照錄制下來的網絡事件，一一重放。
基於網絡協議的腳本的一個好處是，我們可以使用相對少的硬件資源，來生成大量的虛擬用戶負載。相比之下，WinRunner和QTP的腳本是基於界面事件（GUI）的，它在一臺主機上同時只能運行一個虛擬用戶的腳本，因爲一個虛擬用戶會佔用整個主機的資源。
推論一：VU不關心用戶在界面上發生的事情。
真實的用戶對軟件客戶端可能有各種各樣的操作，有些會觸發對服務器的請求，有些則不會。而VU的錄製和運行都是基於網絡上的事件的，因此VU在錄製的時候，只對那些網絡事件感興趣，如果有網絡交互發生，就會記錄成腳本，沒有則只會生成一個空腳本，儘管可能用戶在界面上做了很多操作，比如鼠標移動，填寫Web form裏的數據。
推論二：VU中的操作關聯與界面上的操作關聯是不一致的
在我們對軟件系統進行測試的過程中，某些操作是相關聯的。例如，我們測試“查看客戶交易歷史明細”這個事務的系統響應時間，按界面測試思路，我們會這麼做：
首先用客戶查詢系統，查詢出此客戶。
點擊這個客戶，打開另外一個頁面，展現此客戶的基本信息。
點擊基本信息中的“交易歷史明細”，系統經過查詢後，刷新此頁面，顯示明細結果。
顯然，在UI測試中，我們要測試第三步驟，之前必須要完成第一步和第二步。但在VU中就不是這樣了：
這三個操作被VU記錄成三個函數。如果它們是上下文無關的函數（關於上下文相關和上下文無關函數，可參看LoadRunner函數手冊），那麼其實，我們完全可以忽略掉第一和第二個函數，只執行和參數化第三個函數。
案例
疑問：使用LoadRunner錄製一個Java applet技術的Web系統，要錄製的動作是：
點擊一個按鈕後，此時系統調用applet小應用程序。
applet小應用程序在本地加載完後，彈出一個通過XML文件配置對話框，在這個頁面中建立節點樹。
無論LoadRunner採用Web協議、Web Service協議還是Windows Socket協議，在腳本錄製並回放後，到系統中一檢查，發現節點並沒有創建，這是怎麼回事？
解釋：
根據推論一，我們知道VU只捕捉網絡上的事件，在本案例中LoadRunner採用Winsocket協議也無法創建節點，這說明XML樹節點的創建是由Java applet完成的，並且很可能只保持在客戶端本地，並未有和Server同步的跡象。因此，LoadRunner腳本捕捉和回放的腳本只是網絡事件，並不會對客戶端本地產生影響，節點自然不會被創建。
根據推論二，如果我們的目標是測試服務器的性能，那麼完全可以忽略這個問題，繼續錄製。
提示：基於GUI和基於協議的測試工具在實質上是看待同一事物的不同的角度。比如：用戶點擊一個Web頁面上的“無憂測試“的鏈接文字，在QTP會被記錄成link("無憂測試").click的函數，而在LoadRunner中則會被記錄成web_link函數。前者是記錄“鼠標在此鏈接上點擊一次”這個事件，而後者是“客戶端向Web Server發起了一個get URL地址爲www.51testing.com的請求”。LoadRunner和QTP如摸象的盲人一樣，各自從GUI和網絡協議的角度來看用戶點擊的動作。而實際上它們所記錄的只是用戶操作整個過程的一部分。
提示：LoadRunner 8.1從SP2開始，VU協議族中新增了一個特殊的Vuser類型，叫做Web Click and Script，爲什麼說它特殊呢？因爲它和其他基於網絡協議的Vuser不一樣，Web Click採用了QTP的技術，使得VU可以錄製在界面上的一些操作。比如登錄時填寫用戶名、口令這些動作都可以被記錄成腳本。這在本書第10章中將會有所介紹。
把VU的實質弄清楚了之後，我們就可以放心大膽地使用它了。Vugen是個神奇的盒子，我們總能從盒子裏拿到我們想要的東西。