網通系統壓力測試方案
微軟（中國）****
版本控制
目錄一、概述 4
1.1專案背景和測試目的 4
1.2被測系統介紹 4
1.3測試可接收條件 5
二、測試需求 5
三、測試方法 5
3.1測試方法 5
3.2測試案例 9
3.3測試流程 9
3.4資料檔案準備 9
3.5測試指令碼說明 10
四、測試環境 10
4.1網路拓撲圖 10
4.2環境配置 10
五、測試實施 11
5.1試資源與進度 11
5.2 測試機構和人員職責 12
六、試儲存管理規範 13
6.1儲存內容、地點、命名規則 13
6.2儲存目錄結構 14
6.3備份 14
附錄1：env_check_list 15
附錄2：測試工具原理 16
為了保障網通即將建設的綜合營帳系統能夠順利實施，網通希望在專案正式實施前了解未來系統是否可以使用目前已經選用的技術進行搭建，即了解專案技術的可行性。另外，網通還希望了解使用不同技術實現的差異。
本次被測系統是針對網通專案的乙個前期實驗系統。系統邏輯結構圖如下：
圖1、系統邏輯結構圖
整個系統分為三個主要部分，主要功能包括：
1. 系統a
系統a是整個系統的資料入口，可以將客戶請求傳給biztalk或者直接傳給系統b。系統a可以通過兩種方法接收客戶請求傳給系統。一種通過tuexdo (a)接收使用者請求，另一種可以直接通過weblogic(a)接收使用者請求。
2. biztalk
biztalk是整個系統的中心，負責連線系統a和b，主要目的是同步處理系統訊息。另外，由於測試需要，biztalk本身可以接收使用者請求（http）。
3. 系統 b
可以看作系統的服務端。接收biztalk的請求，並返回結果。
1、 每次測試交易成功率在90%以上
2、 使用者每個請求的響應時間低於2秒
每次測試，以上條件必須同時滿足，方視為本次測試通過。
本次測試的需求包括：
1、 biztalk系統的處理能力
2、 整個系統能夠支援多少使用者同時訪問
3、 不同技術間實現的差異
測試過程採用自動測試工具進行。目前暫時決定使用mercury interactive公司的測試產品：loadrunner。
1、 測試biztalk系統的處理能力：
圖2、測試biztalk系統的處理能力
模擬多個web型別的虛擬使用者，同時向biztalk系統傳送http請求，之後記錄每個虛擬使用者的響應時間。
2、 整個系統能夠支援多少使用者同時訪問
方法一：
模擬多個web型別的虛擬使用者，同時向weblogic(a)傳送http請求，之後記錄每個虛擬使用者的響應時間。
圖3、測試整個系統能夠支援多少使用者同時訪問（方法一）
方法二：
模擬多個tuxedo型別的虛擬使用者（即模擬tuxedo客戶端），同時向tuxedo(a)的服務傳送tuxedo請求，之後記錄每個虛擬使用者的響應時間。
圖4、測試整個系統能夠支援多少使用者同時訪問（方法二）
3、不同技術間實現的差異
方法一：
模擬多個tuxedo型別的虛擬使用者（即模擬tuxedo客戶端），同時向tuxedo(a)的服務傳送tuxedo請求，並且tuxedo（a）傳送的請求，不經過biztalk系統，之後記錄每個虛擬使用者的響應時間。
圖5、測試不同技術間實現的差異（方法一）
方法二：
模擬多個web型別的虛擬使用者，同時向weblogic(a)的傳送http請求，並且weblogic（a）傳送的請求，不經過biztalk系統，之後記錄每個虛擬使用者的響應時間。
圖6、測試不同技術間實現的差異（方法二）
正式測試過程如下：
1、 確認被測環境正常（env_check_list）
2、 確認測試環境設定（env_check_list）
3、 開始測試
4、 儲存測試結果
5、 系統除錯
6、 應用除錯
7、 環境維護
圖7、測試網路拓撲圖
圖8、測試組織結構圖
● 儲存內容：
a) 測試指令碼
b) 測試場景
c) 測試結果
d) 相關文件
e) 資料檔案
● 儲存地點：
執行控制台的主機硬碟上，儲存結構見下面圖9。
● 命名規則：
a) 測試指令碼
ltscr_app_[subapp_]version
說明：ltscr：load test script
app：業務名稱
subapp：子業務名稱（[ ]可選）
version：指令碼的版本號
b) 測試場景
ltsce_app_[subapp_]concurruser_iteration
說明：ltsce：load test scenario
app：業務名稱
subapp：子業務名稱（[ ]可選）
concurruser：併發使用者數
iteration：每個使用者迴圈次數
c) 測試結果
ltres_ app_[subapp_]concurruser_iteration _time
說明：ltres：load test result
app：業務名稱
subapp：子業務名稱（[ ]可選）
concurruser：併發使用者數
iteration：每個使用者迴圈次數
time：第幾次測試
圖9、測試儲存結構圖
說明：script：儲存測試指令碼
scenario：儲存測試場景
result：儲存測試結果
document：儲存相關文件
datafile：儲存資料檔案
測試結果每天在測試結束後備份一次，將「d:\loadtest」目錄，全部備份到磁帶機或「\\anypc\c:\ loadtest_bak」
日期：2023年___月___日___時___分
測試結果名稱
檢查內容如下：
測試監督簽字
mercury interactive 公司的客戶機/伺服器系統的壓力測試工具loadrunner，其工作原理為：通過乙個中心控制點，在乙個或幾個主機上同時模擬成百上千的實際使用者的操作，從而生成一致的、可測量的及可重複的系統負載，並記錄特定交易操作的響應時間。概要地說：
首先錄製應用程式的操作過程，測試工具會自動生成可執行的指令碼，該指令碼執行起來，從伺服器端看，就如同乙個實際的使用者在進行操作，我們稱為虛擬使用者。然後，通過中心控制點（controller）設定測試場景，控制許多個虛擬使用者在多台agent機器上同時執行，監控執行狀態，收集響應時間等效能資料。
● 使用虛擬使用者（vuser）替代實際使用者
每個模擬的使用者即為乙個虛擬使用者，其實就是乙個執行的測試指令碼。
測試計畫模版
專案開發單位 專案使用單位 專案測試單位 測試計畫 僅供內部使用 北京久其軟體股份 版權所有不得複製 修訂歷史記錄 注 以下提供的模板用於久其公司軟體測試。其中包括用方括號括起來並以斜體 顯示的文字，它們用於向作者提供指導，在發布此文件之前應該將其刪除。按此樣式輸入的段落將被自動設定為普通樣式。目錄...
軟體測試計畫模版
由安博測試空間技術中心提供 專案開發單位 廣州奧虎資訊科技 專案使用單位 天悅酒店 專案測試單位 廣州奧虎資訊科技 測試計畫 僅供內部使用 北京久其軟體股份 版權所有不得複製 修訂歷史記錄 注 以下提供的模板用於久其公司軟體測試。其中包括用方括號括起來並以斜體 顯示的文字，它們用於向作者提供指導，在...
軟體測試計畫模版
簡要的說明本測試計畫的目標，包括測試範圍 測試資源 測試工具 風險分析 測試策略。例如 本文件為 xx產品 xx版本的專案測試計畫，本計畫對軟體測試範圍 測試資源 進度安排 測試工具 風險分析 測試策略進行指導性說明，從而保證測試實施過程的順暢溝通，並對測試進度進行跟蹤控制，應對測試過程中的各種變更...