性能測試原理及性能測試實例分析(3)

　　…………………………..}

　　在上面的例子中，我們主要對每筆交易進行了transaction化。在交易開始時設置開始檢測點，交易結束時設置結束檢測點，并給loadrunner報出交易狀態。實際的腳本中在回收交易響應消息時還進行了拆包，在應用層上對交易狀態進行識別，并非例子中只在socket層加以判斷。

　　針對查詢流程測試，由于loadrunner工具支持基于http的web訪問錄制功能，我們將考慮采用以錄制腳本為主，手工編寫腳本為輔的方法，生成查詢業務腳本，通過loadrunner來執行。由于查詢腳本基本由錄制生成http請求和應答，不同的壓力測試工具錄制會有差別，這里就不再寫出查詢腳本樣例。

　　A:并發登陸測試場景

　　并發登陸750用戶/分鐘，登陸響應時間在30秒之內。仔細考慮一下，這里的并發登陸750用戶/分鐘指的是系統能夠在1分鐘內接受750個用戶的登陸請求，而處理的效果如何則在交易終端體現，即登陸響應時間?；谶@樣的理解，我們把用戶性能指標轉化為如下的測試場景：

　　從第一秒鐘開始，用loadrunner每秒鐘登陸13個用戶，并保持socket連接，直到1分鐘結束，從終端向系統一共發送750個左右的用戶登陸請求，系統在一分鐘內建立了750個連接。在終端觀察并統計登陸響應時間。如果系統不能響應持續增加的登陸請求或平均登陸響應時間大于30秒，并發登陸測試場景都不能算通過。為了幫助用戶更加深入了解系統的能力，我們對系統的瞬時并發能力進行測試，即測試系統所能承受的最大的瞬時并發用戶登陸連接請求個數。這個場景通過loadrunner在登陸前設置同步點來實現，這個結果將結合上一個結果一同反映系統的登陸處理能力。

　　B:交易流程測試和查詢流程測試：

　　在這里我們只對系統的業務負載能力做測試(并發處理能力在登陸測試中已經得到考證)。測試場景如下：

　　在loadrunner中，建立goal-orented的測試場景，以400筆/秒為目標，將調度權交給loadrunner來試圖達到這個指標。

　　C: 綜合測試：

　　交易流程測試和查詢流程測試同時進行。

　　以上的測試場景要求均可在loadrunner中的Controller進行設置完成。

　　測試場景的創建之后，我們的測試任務更加具體化和清晰化。

　　在loadrunner中的controller中開啟unix系統資源計數器，weblogic計數器，DB2計數器，檢測系統資源消耗情況，并最終和測試結果數據合并，成為分析圖表。

　　測試結果可在測試執行完畢后，通過loadrunner工具中的Analysis(分析器)獲得。

　　A: 并發登陸測試

依照設計好的測試場景，用loadrunner工具在一分鐘內漸增向系統發送登陸請求。分別進行三次，結果如下

　　表格 2登陸測試結果數據表

　　注：這里的登陸成功用戶指的是系統接受了登陸請求，并建立了連接。平均響應時間在登陸腳本里設置檢測點，由loadrunner工具自動獲得。

　　考察系統的瞬時并發處理能力：在完成上一步測試的前提下，逐步增加瞬時并發登陸用戶數，直到系統極限。

測試執行結果如下：

　　B: 負載測試

　　交易流程測試：

　　測試結果如下：

　　對于通過網絡接口發送的批量業務請求，均在性能指標所指定的時間范圍內得到請求成功的反饋消息，說明主機已經處理成功。

　　在通過網絡接口發送業務請求的同時，開啟IE，通過實際終端界面進行登陸和交易，系統響應時間延長，界面顯示和刷新明顯變慢，到業務量高峰時期，界面已經不能顯示任何信息，處于不可工作的狀態。

　　需求說明的是系統正常工作時，每個界面終端不僅應該能夠展示己方的交易信息，還要展示其他交易單位的交易信息和系統信息。因此當交易量大的時候，界面需要展示的信息量是巨大的，這本身對終端界面是一個性能考驗。

　　查詢流程測試：

　　本流程測試在交易流程測試之后進行,以利用其生成的數據。

　　測試結果基本滿足性能指標。

　　綜合測試

　　由于交易流程測試的未通過，本測試已經不能執行。

　　A:并發測試結果分析

　　根據上述的并發測試響應時間表，我們可以得出以下的結論：

　　被測系統在一分鐘內并不能接受750個用戶的登陸請求，其可接受的登陸請求用戶數大概為490個左右。在這樣的條件下，登陸響應時間在用戶要求范圍之內。

　　被測系統的瞬時并發處理能力約為122個用戶。

　　B: 交易流程測試結果分析及性能評價

　　根據交易流程測試結果可知，通過腳本程序進行業務行為，發送業務請求消息到回收主機處理回應消息，這段時間系統是順暢的，反應也是迅速的，但是在終端界面卻不能即時展現消息。這說明信息的回饋通路在終端界面出現了性能瓶頸。當界面需要在短時間內展示大量交易信息時，已經不能承受負荷。這與終端采用java applet技術有關。

　　C: 查詢流程測試結果分析

　　查詢流程基本符合性能指標。

　　需要說明的是，實際中，以上每個場景的測試都執行了多次，中間件參數進行了多次的調優。從以上測試的結果分析也可以看出，我們的性能測試瓶頸不是出現在中間件產品上，而是在自身開發的程序上。

原文轉自：http://www.kjueaiud.com