第二條路線上主要運行的是查詢指令信息。
查詢指令產生時，通過http協議訪問weblogic上的web服務器和應用服務器上的相應組件，以JDBC接口訪問后臺的DB2數據庫，并把數據庫返回的結果發送至終端界面。
在本條流程線上的加壓主要驗證weblogic處理能力，數據庫中索引是否創建合理。
兩條流程線相對獨立，但又是互相依賴的。由于是對同一個數據庫系統進行讀操作和寫操作，查詢流程的結果依賴于交易流程數據的產生，交易流程的產生的數據又通過查詢流程得到驗證。在進行壓力測試時，兩者的協同會對數據庫形成壓力的沖擊。
鑒于以上分析，結合用戶性能指標，我們決定把本次性能測試分解為如下幾個子測試來進行。A: 并發登陸測試：750個終端一分鐘內并發登陸系統，并且響應時間在30秒之內。
B: 業務負載測試
此下又有三個子測試。
- 交易流程測試：多個終端發起交易請求，逐漸加壓，以達到300筆/秒的壓力為限。
- 查詢流程測試：多個終端進行查詢，逐漸加壓，以達到400筆/秒的壓力為限。查詢成功與否以所請求的web頁面完全展現為標準。（查詢響應能力其實和數據庫中的數據量有關系，后來和用戶進一步確認，基礎數據為30萬條）
- 綜合測試：
在上面兩種測試都通過的情況下，進行綜合測試。
2)性能測試的執行過程，性能測試依照下面的步驟來進行：
本次壓力測試采用MI公司的loadrunner工具，腳本編輯和編譯工作在VU Generator(腳本作坊)中進行。
理想的腳本是對現實世界的業務行為進行了完全無誤的模擬，這其實是不可能的。我們的目標是使模擬的誤差在我們認可的范圍之內，并能有方法加以控制。
針對并發登陸測試和交易流程測試，由于兩者運行機理相同，都是終端調用socket client，和交易前置的socket server建立連接，將請求消息發送至交易前置機。我們考慮采用將此部分java socket程序編入測試腳本程序，生成登陸和交易業務腳本，通過loadrunner來執行。這樣做的好處是繞過終端IE界面復雜的處理邏輯，直接施壓在前置機上（這種方式同時也帶來了偏差，在執行測試場景時通過其它方法得到了一定的彌補）。
腳本除了要實現與前置機的socket連接，業務發送等功能，還要建立用戶信息數據池，設置檢測點、異常退出點，為腳本執行后的結果統計和分析提供正確的依據。
交易業務腳本內容略。部分如下：
public class Actions {/*登陸變量初始化*/ProtocolManager protocol;//ProtocolManager為實現socket連接的類 ServiceName service; //ServiceName對服務端的信息進行了封裝，包括IP地址和端口號。LoginMessage login；//LoginMessage為登陸時需要向服務器發送的消息，待服務器確認并返回回應消息時，登陸成功。protocol = new ProtocolManager(); //創建ProtocolManager類的protocol對象service = ServiceName.getInstance();//獲得ServiceName的實例login=new LoginMessage();//創建LoginMessage類的login對象service.setIP("200.31.10.18");//設置服務端的IP地址service.setPort(17777);//設置服務端的端口號/*設置登陸消息*/ login.serUserName(lr.eval.string(“{loginName}”));//從數據池里讀出用戶名，設置在login成員變量里login.setPasswd(“1234”);//數據庫中添加的用戶密碼都為1234/*發送登陸消息*/protocol.login(login);//發送登陸消息lr_start_transaction("trade");//交易開始點TradeMessage trademessage;//生成交易消息/*設置交易消息*/………………………….
………………………….
/*發送交易消息*/………………………….
………………………….
if(sendfail)lr_end_transaction("trade", LR_FAIL);//如果發送交易消息失敗，交易結束，返回。/*循環回收主機返回的處理信息*/…………………………
…………………………
if(recievefail)lr_end_transaction("trade", LR_FAIL);//如果不能接收到主機處理回應消息，交易結束，返回。if(recievesuccess)lr_end_transaction("trade", LR_PASS);//如果接收到主機成功處理的回應消息，交易結束，返回。…………………………..
}在上面的例子中，我們主要對每筆交易進行了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進行設置完成。
測試場景的創建之后，我們的測試任務更加具體化和清晰化。
- 第三步：運行測試場景，同步監測被測系統性能行為
文章來源于領測軟件測試網 http://www.k11sc111.com/
