模板
教程
環境
性能
功能
管理
軟件測試 > 測試技術 > 軟件測試工具 > Mercury軟件測試工具 > LoadRunner >
Loadrunner使用經驗交流
LoadRunnerMILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">的基本原理這邊不詳細介紹了，估計大家都很清楚了。這里強調一點：LoadRunner不關心服務器內部的處理，所以有時在javascript:tagshow(event, '%B2%E2%CA%D4');" href="javascript:;" target=_self>測試時可能會發現，我們對系統施加了很大壓力時，所有虛擬用戶都測試通過了，但請求響應時間不正常的短，那一般來說，系統測試有問題，這就是因為LoadRunner沒有去驗證是否服務器真的處理了請求。
下面介紹一下我使用Loadrunner測試時的一些心得、經驗與教訓。
一、性能測試步驟
使用LoadRunner進行性能測試的步驟：測試計劃-》設計測試用例-》錄制測試腳本-》執行測試-》分析測試結果，這個測試步驟和常規的測試過程很類似。
測試計劃
•分析應用系統
•計劃LoadRunner執行過程
——》
設計測試用例
•分析測試需求
•確定測試負載
•確定用例細節
——》
錄制測試腳本
在編輯腳本時，要注意幾點：
•錄制基本的虛擬用戶腳本
•優化腳本（設置Run-Time屬性；參數化；設置事務集合點；腳本回放等）
•配置Run-Time屬性
•在單機模式運行測試腳本
•將虛擬用戶腳本合并到測試場景中
——》
執行測試
在執行測試場景時，要注意幾點：
•運行一個完整的測試場景
•控制虛擬用戶組
•控制獨立的虛擬用戶
•手工從集合點釋放虛擬用戶
•手工向一個執行的場景增加虛擬用戶
在監控測試場景時，要注意幾點：
•開始監控器
•打開在線監控器圖表
•服務器資源監控
•設置監控器屬性
——》
分析測試結果
因為分析測試結果部分涉及的東西比較多，所以這里先暫時只給出個例子。
估計性能測試總工作量：
因為在編寫材料時，有同事提出比較關心性能測試的工作量，所以我將這個例子項目的性能測試工作量進行了統計。
某移動知識管理系統在系統初驗前，項目總工作量是49.06人月，測試總工作量是8.644人月（即186人日），測試占項目總工作量的17.62%。其中，性能測試占測試總工作量的14.3%，與前面介紹的性能測試估算比例9%相比大出很多。這是因為參與這個項目的測試組沒有性能測試經驗，并且這個項目性能需求比較多，客戶對系統性能要求比較高。單單到客戶處進行性能測試，就不下10次，這還需要包括前期的實施準備工作。因為移動的機房和我們測試客戶機不在同一個地方，所以，每次進行性能測試之前，都需要很多人的協助。所以，從工具學習、到腳本問題處理、溝通、測試執行上，這個項目都花了不少時間。后面另一個項目因為有了前面項目的經驗積累，整個性能測試工作的工作量占整個項目性能測試工作量的8.2%。
下面我使用該項目的一個性能測試點對腳本的錄制這塊介紹。
場景介紹：
[-o!mC)L0培訓考試在線考試，要求能夠實現500個人同時在線考試。
*[&Gi:l8Lb!E9O0關鍵點：ITPUB個人空間j l)Y9]v ],K f
每個人登陸系統后，不能再次登陸系統
4? I+AD+@| R0500人同時提交試卷時，并發性要求很大
E#dXn D0
因為沒有系統，先大致給大家描述一下界面。
由于錄制腳本是整個性能測試的一個基礎，所以，這里先主要講腳本的錄制。
假設：并發性最大的情況是考試時間到時，系統自動提交試卷的這一時刻。
這里主要強調幾點：
1.參數化的幾個注意點：
1)空格問題
2)參數設置方式
3)16進制的參數化（多用幾個用戶錄制腳本，對比腳本不同的地方）
——》
二、測試經驗
6D5B)u Z X s0tfx02.我們不可能對所有的系統功能都進行性能測試。
n7{^5f*v _ EcM(N0在測試設計時需要結合當時的實際系統，先分析軟件可能存在的瓶頸，此時可依據80/20原則（帕雷托原則）分析，再依此制定性能測試的方案：ITPUB個人空間E:[7QY2p;M q
1）對系統資源的利用；
T$B.})qj02）數據大量傳輸；ITPUB個人空間y o v"Tx$u\N
3）數據轉換（獲取其它庫表中數據轉換為XML格式，或二進制）；
0^dO9VU2VOB04）使用的頻度（分析用戶習慣）
對可能成為瓶頸的模塊要細分，同時又要分析用戶行為習慣，用戶行為習慣是很重要的。有些模塊可能開發人員認為并發會很多，但實際上，可能可能一天只用一次。
3.不要丟棄原來舊的測試結果
~0J2@9MP\01）可以量化開發產生的影響
3~`9H/J/n Y*I02）可以把現在和以前的性能進行對比
)w3F*kyY\I03.不要把測試腳本復雜化
T&i$}7C qO3p f04.使系統的think-time時間更貼近實際情況。ITPUB個人空間t+r]i |p;J ]
5.對于B/S架構的系統 ，在錄制腳本之前，將瀏覽器的cache和cookie清空。ITPUB個人空間vx1~ h7T5v-Z
三、教訓
l 在現場錄制腳本，臨時碰到問題，導致花了很長時間調試腳本
解釋：我第一次在移動培訓室里現場錄制腳本時，卻臨時碰到問題，花了很長時間修改腳本，并且還好那時是有微軟服務的人現場指導，否則可能那天的測試都沒法進行了。
應對：
1)在公司要多試，并將腳本調通，并記下錄制步驟，及注意事項
2)在計劃測試前，到客戶處將腳本錄制好
3)測試工具的選擇應恰當。剛開始選擇微軟VS.net里自帶的ACT進行測試，但是因為該工具有些東西不是很穩定。導致測試的多次延誤，后面選擇使用LoadRunner進行測試了。
l 執行測試時開始沒有注意腳本執行情況和測試客戶機、服務器資源情況
解釋：執行測試時發現腳本執行時報錯，還有就是服務器、測試客戶機資源不夠的情況，如果碰到這些情況時，要停止測試，分析原因。如果是測試腳本執行出錯，需要對腳本進行調整；如果遇到服務器資源不夠，那么要減少對本機的負載；如果是服務器資源不夠，那么需要減少對服務器的負載。因此，在執行測試時，不是讓腳本自己跑，而要時刻關心執行情況，避免測試結果誤差過大。因為當出現異常時，響應時間會異常的短，這時的測試結果很不準確。
l 測試前沒有記錄測試機器名、機器位置、機器配置
解釋：結果沒有唯一的標識，收集、分析結果很混亂。因為分析結果時需要參考機器配置。
l 沒有準備安裝光盤
解釋：不要只在帶過去的筆記本上有安裝程序。兩個原因：1)增加安裝客戶端的速度。因為安裝程序時，要從本機上進行安裝，避免從網絡安裝，這樣每臺機器都要進行拷貝安裝程序，然后再安裝，速度很慢。
2)萬一帶過去的筆記本無法連到測試環境內時，那就很麻煩了。
l 在執行測試時，才發現測試工具安裝有問題
解釋：測試客戶機測試工具和測試腳本能否正確運行要提前確認，不可等到所有準備工作做好了，要開始執行測試時才發現問題。因為曾經碰到過這樣的例子，那時使用ACT進行測試，那時到客戶處進行測試時，才發現同樣方式下安裝的ACT，有部分機器就無法正確運行腳本，導致測試整整推遲了2小時。而這個項目的性能測試大部分時候需要在凌晨時才能進行的，推遲2小時意味著可能在用戶上班前無法完成測試。如果是借同事的機器進行測試，推遲測試完成時間意味著將影響其他同事的工作。
l 所有測試客戶機與服務器時間不一致
解釋：兩方面考慮：
1) 數據整理時，如果時間不一樣，數據合并會有問題
2) 因為使用的版本問題，需要有較多的測試客戶機，一個人要操作很多臺機器，通常需要設置場景的開始運行時間，如果機器時間不一致，那很難達到并發的效果。
原文轉自：http://www.anti-gravitydesign.com
