壓力測試工具-Mercury Interactive LoadRunner

支援多元的企業環境，監控點對點的效能；別把壓力測試當功能測試

在應用程式上線前實施壓力測試，了解是否有潛藏的效能瓶頸，及系統的效能極限是否符合需求，才能避免系統上線後因效能問題回收。Mercury Interactive（MI）提供測試及效能監控管理解決方案，測試階段包括TestDirector、WinRunner及LoadRunner等產品；應用程式上線後的效能監控則是Topaz。LoadRunner是壓力測試的工具，也是第一個支援.NET的產品。

由於J2EE市埸成熟，所以目前大部分的測試的工具，均針對J2EE應用程式設計，LoadRunner支援的應用程式架構相當廣泛，包括主從架構、網路應用程式、中介軟體、瀏覽器、資料庫、Oracle、SAP、PeopleSoft等ERP及各種作業系統，甚至可以測試大型主機以終端機連線的架構。

MI在測試方面明確定義企業測試周期，首先應確認測試需求，才能依需求擬定測試計畫，再根據計畫執行功能測試，然後才執行壓力測試，完成後系統才能上線。代理商璨碩科技強調，功能測試完成之前，不能進入壓力測試階段，因為壓力測試必須在功能確認無誤的情況下，檢驗大量使用者執行應用程式，是否出現效能瓶頸。如果兩者一併執行，將干擾壓力測試的結果。

針對網際網路應用程式，璨碩科技建議防火牆內外，都要執行壓力測試。因為防火牆以外包括防火牆、ISP、路由器及實體線路等，都可能是影響效能的問題點。壓力測試不能只求心安

傳統的壓力測試方法，是利用假日或非交易時間，指派大量的人員，同時操作系統，以人工蒐集資料，憑直覺判斷是否可負載大量的交易。如果順利發現問題修改程式，或者未來更新版本，仍必須再次重複這樣勞師動眾的過程，不但浪費人力、物力、金錢與時間，而且粗糙的測試方式，並不夠準確只能求心安。

MI強調的壓力測試，要做到點對點（end-to-end）的監控與分析，從模擬使用者的行為到後端的資料庫，釐清每一個環節的問題，才是有效的壓力測試。

LoadRunner以虛擬使用者產生器，自動產生成千上萬個虛擬使用者，取代真實的使用者，可減少測試所需的硬體及人力資源。再透過監控模組，自動蒐集涵蓋所有項目的資訊，不但數據精準且資料豐富，藉由系統分析及專業顧問的判斷，才能提供有價值可信賴的分析報告。虛擬使用者節省人力成本；Controller控制測試流程

壓力測試的第一步是設計腳本，開啟虛擬使用者產生器時，會要求使用者選擇應用程式類型，例如測試網站應用程式，在輸入網址後，LoadRunner會自動開啟瀏覽器進入網站，讓使用者錄製腳本。

LoadRunner在瀏覽器與網路卡之間，建立一個代理（Proxy）機制複製封包，因此設計測試腳本時，使用者只需操作應用程式，系統會自動錄製測試腳本。LoadRunner記錄的不是使用者按的按鍵或輸入的資料，而是記錄瀏覽器傳送的資料，分析封包中「Get」、「Post」等行為，自動產生Script檔。

測試人員可進一步修改腳本，例如轉換帳號密碼，對應到文字檔或透過ODBC連結資料庫，產生成千上萬個虛擬使用者，也可設定日期、時間及數字等的輸入格式。甚至LoadRunner會自動判斷應用程式是否包含SessionID，詢問使用者是否設定參數對應。

在實際情況下，使用者登入系統後，不會不間斷地操作系統，因此在設定測試流程時，可選擇是否包含停頓時間（Think Time），若模擬使用者的真實行為，可進一步設定停頓的時間範圍。此外，一般應用系統在交易成功後顯示一段文字，表示交易交成，可設定Content check，檢查是否出現指定文字或圖檔。

建立測試的情境時，可設定一臺或多臺電腦為壓力產生器（Load Generator），各別產生多個使用者，MI以TurbolLoad專利技術，可讓電腦在消耗最少的資源的情況，同時產生大量的使用者。

Controller則負責整個測試的監控及操作流程，設定加壓模式、確定執行的業務流程、虛擬使用者人數及測試時間，可同時執行不同的應用程式及腳本。例如選擇測試開始及結束時，一次登出入所有虛擬使用者，或開始時循序遞增，結束時循序遞減。一般而言，建議採用循序漸進遞增的方式增加虛擬使用者，以找出系統的極限。多數應用程式不需安裝代理程式

LoadRunner監控效能的模組是選購的，包括硬體、網路設備、線路、資料庫、網站伺服器、應用伺服器及ERP等，企業可依需求選擇需要的模組。

一般效能監控產品，多必須安裝代理程式（Agent）蒐集資訊，然而LoadRunner對大部分的應用程式架構，不需要安裝代理程式，就可以獲得在壓力測試過程中所需的資料。安裝代理程式必須考量相容性問題，且執行代理程式難以避免會佔用系統資源，最重要的是銀行及證券等安全性要求較高的系統，並不允許加裝任何代理程式。

一般系統本身內建效能監控工具，例如Windows的效能監視器，因此系統本身就可產生效能數據。由於MI與系統廠商技術合作，因此可透過權限設定，以API取得既有的數據，對系統本身的影響最小。依MI的經驗如此的架構，對系統的影響不會超過5%，多在1%以下。

不過由於Java沒有標準的效能計數器（Counter），所以會在應用程式伺服器安裝一個.JAR檔的代理程式。J2EE應用程式可分析Servlet、Method、EJB、JNDI、JDBC、資料庫連線時間及執行時間。為減少對系統效能的影響，LoadRunner的代理程式不會主動傳送資料給主控臺，也不會在伺服器產生記錄，只傳送主控臺要求的數據。

微軟的解決方案中，監控COM+元件是唯一需要安裝代理程式的部分，因為Windows的效能監視器，不包含COM+元件的資訊，所以LoadRunner必須在Windows伺服器安裝代理程式。Auto Correlation自動分析效能瓶頸；了解系統負荷，錢才能花在刀口上

測試結束後LoadRunner的Report模組，會產生基本的Word、HTML格式報表，提供詳細的效能數據。由資訊人員自行從成千上萬筆的資料，分析數據找出效能瓶頸是艱難的任務。

LoadRunner的分析模組提供自動關聯（Auto Correlation）功能，可彙整測試數據，以Auto Correlation可縮小範圍自動分析，並依可能性排序列出效能變慢可能的原因，協助企業找出效能的瓶頸。

先了解系統的負荷，當系統效能未達要求時，壓力測試工具是企業可告訴企業投資的方向，是修改軟體程式還是升級硬體設備，將錢花在刀口上，提高投資報酬率。

應用系統效能提升，對企業內部而言，可節省企業人力工時提高工作效率，而對於對外與營利有關的系統，由於使用者選擇性多，因此忠誠度低，當系統效能及穩定度不足時，客戶將大量流失，透過工具發現潛在的效能問題，在使用者察覺前解決問題避免停機時間，才能減少損失保障營收。

由於壓力測試及效能監控模組的價格昂貴，因此MI提供彈性的解決方案，可選購模組，或以租賃的方式，租借需要的模組及顧問服務，以節省企業成本。文⊙李延華