【正文】 iao”這一事務進而影響到action事務。正在運行的虛擬用戶（Running Vuser）圖正在運行的虛擬用戶圖一般會和一些事務響應合并起來一起分析。對于網(wǎng)頁細分功能則應遵循如下原則：l 分析從用戶發(fā)出請求到收到第一個緩沖為止，哪些環(huán)節(jié)比較耗時；l 找出頁面中哪些組成部分對用戶響應時間影響較大；l 找到頁面性能問題后，提出調優(yōu)方案；l 測試調優(yōu)后的性能能否達到要求。比如“超時錯誤”達到90%以上，可能需要硬件上提高配置了；再比如出現(xiàn)較多的“內(nèi)部服務器錯誤”，則可能是程序方面存在問題。整個測試過程的錯誤發(fā)生情況是分析的重點。正常情況應該是當一定范圍內(nèi)的用戶并發(fā)時，事務響應時間應不會有太大變化；l 服務器每秒通過的事務總數(shù)、某一事務每秒通過數(shù)是否穩(wěn)定，如果整個測試過程基本不變，則要分析是服務器達到了處理上限還是Generator產(chǎn)生的壓力達到了上限；l 按照迭代次數(shù)來運行的場景，要分析通過的事務總數(shù)是否與設定一致，如果不一致，則可能腳本有問題，也可能是程序存在功能錯誤，應調整后再測。對于事務，主要看整個過程的事務響應時間是否逐漸變長以及是否存在不能正常執(zhí)行的事務。這個測試應保存證負載發(fā)生器在整個測試過程中CPU、內(nèi)存、帶寬沒有出現(xiàn)瓶頸，否則測試結果無效，如果硬件上都有瓶頸則不能表現(xiàn)出程序中的問題來。如果事務失敗過多，則應該降低壓力進行測試，使結果容易分析。查看事務是否全部通過。這里一般需要重視的是事務執(zhí)行失敗和響應時間過長等。要獲得系統(tǒng)資源情況，必須在Controller里預先指定相關的計數(shù)器。l 網(wǎng)頁細節(jié)（Web Page Breakdown）圖：網(wǎng)頁細分需要在Controller中啟動（Controller菜單中診斷中的配置里面，激活“網(wǎng)頁診斷”）。l 事務（Transactions）圖：描述和事務相關的分析圖：事務綜述圖、事務平均響應時間圖、每秒通過事務數(shù)圖、每秒通過事務總數(shù)圖、事務性能摘要圖、事務響應時間與負載分析圖、事務響應時間百分比圖、事務響應時間分布圖等。當我們打開Analysis，通常是下面這樣的一個界面：在右邊添加新圖處，我們再進行打開新圖的界面，這里還有很多的分析圖這里可以看到系統(tǒng)資源這些都是黑色，不是藍色鏈接，說時這里沒有采集到數(shù)據(jù)，我們需要在Controller中，場景運行之前開啟相應的采集。比如說我們在工作中會經(jīng)常遇到CPU占用率過高，我們可能還會發(fā)現(xiàn)磁盤IO過于頻繁，我們一般會認為是服務器內(nèi)存不足。借助LR的Analysis組件，可以很容易分析。性能分析基礎知識在性能測試中，我們都遵循一個普遍的原則：由外而內(nèi)，由表及里，層層深入。這時我們可以改為逐步加壓。多數(shù)場景都需要迭代執(zhí)行，因此很多測試結果本身就不能反映真實問題，那我們一般按照以下幾個步驟進行判斷結果的有效性：1. 測試環(huán)境是否正常：如果在測試場景的過程中出現(xiàn)過異常，則結果往往不準確，無須進行分析。Memory（內(nèi)存）Pool Nonpaged Byted（非分頁池字節(jié)數(shù)）指在非分頁池中的字節(jié)數(shù)，非分頁池是指系統(tǒng)內(nèi)存(操作系統(tǒng)使用的物理內(nèi)存)中可供對象(指那些在不處于使用時不可以寫入磁盤上 而且只要分派過就必須保留在物理內(nèi)存中的對象)使用的一個區(qū)域。Memory（內(nèi)存）Available Mbytes（可用內(nèi)存）用于描述系統(tǒng)可用內(nèi)存的直接指標，在對系統(tǒng)進行操作系統(tǒng)級別的內(nèi)存分析時，首先應通過該值建立一個初步的印象，了解性能系統(tǒng)測試過程中，系統(tǒng)是否仍然有足夠的內(nèi)存可用。System（系統(tǒng)）Total Interrupts/sec（中斷頻繁度）所有處理器花費在處理中斷上的時間的總和。System（系統(tǒng)）File Data Operations/sec（文件讀寫操作）當前系統(tǒng)中磁盤文件讀寫的頻繁程度。下面列出一些我們常用的計數(shù)器。l 在監(jiān)控圖中可以添加計算機，輸入IP地址后，點擊OK就行了。需要監(jiān)控這幾個方面：操作系統(tǒng)、數(shù)據(jù)庫、中間件服務器等，其中，操作系統(tǒng)的性能表現(xiàn)關系著整個應該系統(tǒng)的性能，屬于基礎的系統(tǒng)資源數(shù)據(jù)。控制集合點在場景的運行中，我們也可以像前面配置集合點一樣的查看和控制集合點的狀態(tài)，即可以停止集合點和用戶，也可以釋放或重置集合點。執(zhí)行測試場景啟動測試場景在場景的[運行]界面中有多個窗口，可以觀查到場景組、場景狀態(tài)、多個視圖及它們的統(tǒng)計數(shù)據(jù)。再在工具菜單內(nèi)選中專家模式，進入選項中的常規(guī)，就可以根據(jù)需要來配置了。我們只需要選擇開始菜單中的“IP Wizard”，進入配置界面。l 當一定比例處于運行狀態(tài)的虛擬用戶到達集合點時釋放。配置集合點我們之前講過集合點，這里會具體配置集合點，以現(xiàn)實一定數(shù)量的并發(fā)，主要用來測試系統(tǒng)某個功能點的并發(fā)負載性能。場景開始后一段時間再開始，這里可以指定具體時間。注意在圖左邊的窗口中，有用戶組的選擇，可以對每個組進行獨立的開始時間、加壓減壓和持續(xù)時間。這種方式主要用來測試系統(tǒng)的極限。第二個是按照指定的時間運行。l 按場景計劃（Schedule by Scenario）按場景計劃有三個選項卡：加壓、持續(xù)時間、減壓。虛擬用戶數(shù)目和每組用戶所在的負載生成器可以直接在此界面中輸入。在這個圖的下半部分，可以看到有兩個標簽頁面：“場景設置”和“加載行為”。面向目標場景在面向目標的測試場景中，可以定義希望達到的目標。通過這些虛擬用戶的并發(fā)執(zhí)行以及及時間的運行，來模擬真實情況下服務器承受的壓力。）其他的項我們一般都使用默認值即可。其 他：我們可以選擇錯誤的處理方式，還可以選擇線程方式運行腳本以得到更大的壓力，最后的選項一般默認就行了。關于檢查點和關聯(lián)的內(nèi)容，可以參見我們的案例“01 checkproperties”。 [MsgId: MMSG27197]Web_reg_find是注冊類型函數(shù)，它本身并不執(zhí)行，不能通過它的返回值來作為事務的判斷條件（因為web_reg_find()的返回值0和1表示web_reg_find()是否注冊成功，并不代表查找的內(nèi)容是否存在，也就是說無論查找的文本內(nèi)容是否存在，都返回0。原因是什么呢 ？Loadrunner以用戶角色向服務器發(fā)送一個登陸請求，卻不會判斷請求的返回消息是什么，只要有返回，即使這是個拒絕登陸的返回，Loadrunner也認為登陸成功了。 需要注意的是：l 集合點一般會創(chuàng)建在用戶事務的開始標志前。以此類推，那完成整個場景就需要數(shù)據(jù)表里至少要有100條數(shù)據(jù)，否則在Controller運行過程中會返回一個錯誤。l User Definde Function：從用戶開發(fā)的dll文件中提取數(shù)據(jù)。l Random Number：隨機數(shù)。腳本錄制的原則n 充分考慮腳本的執(zhí)行效率n 錄制重要的用戶業(yè)務n 選擇你所需要的進行錄制修改腳本參數(shù)化功能 步驟1： 步驟2： 步驟3： 參數(shù)類型有多種：l Date/Time：需要輸入日期的地方，可以用Date/Time類型來替代。只有在腳本運行正確后，才能進入Controller中來創(chuàng)建測試場景。l Lteration Number：測試腳本當前循環(huán)的次數(shù)來生成參數(shù)。l File：在屬性中可以指定文件或數(shù)據(jù)庫中提取數(shù)據(jù)。那編號為1的用戶取前10行數(shù)據(jù)，編號為2的用戶取11~20行數(shù)據(jù)。Vuser從集合釋放后，將執(zhí)行腳本中的下一個任務。至于為什么要用檢查點可以用個小例子做個測試，例如一個登陸腳本登陸的賬號為123456，密碼為123456，可以正確登陸，當把賬號或密碼改掉再執(zhí)行，發(fā)現(xiàn)腳本并沒有報錯，也順利執(zhí)行下來了。Runtime settings/Preferences/Checks39。關聯(lián)所謂的關聯(lián)（correlation）就是把腳本中某些寫死的（hardcoded）資料，轉變成是摘取自服務器所送的、動態(tài)的、每次都不一樣的資料。思考時間：我們一般忽略思考時間，以得到更大的壓力。（如果是使用web_reg_find，則不要求勾選。在場景運行后，Cont