壓力測試計劃實例

　　利用現代的設計技術和正式的技術復審可以減少代碼中存在的初始錯誤，但是錯誤總是存在的，如果開發者找不到錯誤，那么，客戶就會找到它們。越來越多的軟件組織認識到軟件測試是軟件質量保證的重要元素之一，很多軟件開發組織將30%—40%甚至更多的項目資源用在測試上，軟件測試技術和軟件測試策略受到了高度的重視和廣泛的應用。

　　本文不想就軟件測試技術和軟件測試策略作深入的理論分析，而是列舉一個在軟件系統測試階段進行的壓力測試實例，希望能通過這個實例與從事軟件測試相關工作的朋友進行交流。

　　首先介紹一下實例中軟件的項目背景，該軟件是一個典型的三層C/S架構的MIS系統(客戶端/應用服務器/數據庫管)，中間層是業務邏輯層，應用服務器處理所有的業務邏輯，但應用服務器本身不提供負載均衡的能力，而是利用開發工具提供的ORB(對象請求代理)軟件保證多個應用服務器間的負載均衡。本次測試的目的是：進行單個應用服務器的壓力測試，找出單個應用服務器能夠支持的最大客戶端數。測試壓力估算的依據是：假定在實際環中，用戶只啟用一個應用服務器進行所有的業務處理。方法是：按照正常業務壓力估算值的1~10倍進行測試，考察應用服務器的運行情況。

　　壓力測試的詳細計劃如下：

　　壓力測試計劃

　　1、測試計劃名稱

　　河北省公安交通管理信息系統壓力測試計劃。

　　2、測試內容

　　2.1背景

　　本次測試中的壓力測試是指模擬實際應用的軟硬件環境及用戶使用過程的系統負荷，長時

　　間運行測試軟件來測試被測系統的可靠性，同時還要測試被測系統的響應時間。

　　用戶的實際使用環境：

　　◇由兩臺IBM XSeries250 PC Server組成的Microsoft Cluster;

　　◇數據庫管理系統采用Oracle8.1.6;

　　◇應用服務器程序和數據庫管理系統同時運行在Microsoft Cluster上。

　　◇有200個用戶使用客戶端軟件進行業務處理，每年通過軟件進行處理的總業務量為：150萬筆業務/年。

　　2.2測試項

　　應用服務器的壓力測試;

　　2.3不被測試的特性

　　◇系統的客戶端應用程序的內部功能;

　　◇數據庫中的數據量對程序性能的影響。

　　3、測試計劃

　　3.1測試強度估算

　　測試壓力估算時采用如下原則：

　　◇全年的業務量集中在8個月完成，每個月20個工作日，每個工作日8個小時;

　　◇采用80—20原理，每個工作日中80%的業務在20%的時間內完成，即每天80%的業務在1.6小時內完成;

　　測試壓力的估算結果：

　　去年全年處理業務約100萬筆，其中15%的業務處理每筆業務需對應用服務器提交7次請求;70%的業務處理每筆業務需對應用服務器提交5次請求;其余15%的業務每筆業務向應用服務器提交3次請求。根據以往統計結果，每年的業務增量為15%，考慮到今后三年業務發展的需

　　要，測試需按現有業務量的2倍進行。

　　每年總的請求數量為：(100*15%*7+100*70%*5+100*15%*3)*2=300萬次/年。

　　每天的請求數量為：300/160=1.875萬次/天。

　　每秒的請求數量為：(18750*80%)/(8*20%*3600)=2.60次/秒。

　　正常情況下，應用服務器處理請求的能力應達到：3次/秒。

　　3.2測試環境準備

　　3.2.1基本硬件及軟件環境的準備

　　1)網絡環境：公司內部的以太網，與服務器的連接速率為100M，與客戶端的連接速率為10/100M自適應。

　　2)使用兩臺IBM XSeries250(1G內存)PC Server作Microsoft Cluster，安裝系統軟件

　　Windows 2000 Advance Server及Microsoft Cluster Server(MSCS)。

　　3)數據庫管理系統的安裝及配置：在測試用的IBM XSeries服務器上安裝Oracle8.1.6，數據 庫采用Oracle

　　Fail Safe(ofs)的Active/Passive配置。 安裝數據庫管理系統及支撐軟件(包括VisiBroker和BDE

　　Administrator)。

　　4)安裝被測的應用服務器程序。

　　5)客戶端的PC機：10臺(PⅢ600/128M RAM)。

　　3.2.2系統客戶端測試程序的編寫系統客戶端測試程序使用Delphi編寫，要求測試程序實現如下功能：

　　1)模擬一個主要的向應用服務器發送請求并接收響應信息的功能。要求交替模擬兩種情況：第一種，發送的請求至少包括10個參數，參數類型涵蓋字符、日期、數字種類型;接收的

原文轉自：http://www.uml.org.cn/Test/2004092006.htm