1. 背景
本人參與的項目是一個全省大集中的交換網管項目，該項目使用的所有服務器（數據庫服務器、應用服務器、采集服務器、認證服務器、WEB服務器）均部署在省中心機房，所有的數據采集和處理都在省中心完成，地市通過反拉終端通過WEB和Socket方式訪問省中心的服務器�？紤]全省的需要，在整個系統上線后，總的用戶數應該在1500左右。
圖1是本項目的結構示意圖。
在我們這個系統之前，L省的交換網管采用的是本地網管理方式，也就是每個地市都有自己的本地網網管系統，對省中心提供的數據僅僅是定期的報表。采用分散的本地網網管形式，每個本地網系統僅需要支持少量本地用戶的訪問，因此在性能方面沒有過多的考慮，也沒有進行過性能方面的測試。
我們為L省提供的新的解決方案是全省大集中的統一交換網管，一方面所有的用戶都通過統一的平臺對系統數據進行訪問，另一方面，系統通過已有的DCN網絡對分布在地市的網元進行采集�？紤]到用戶數據訪問地集中、集中帶來的數據訪問需求的增加（在以前的老系統上，省中心只能通過地市定期的上報報表獲知地市運行情況，但在新系統中，省中心要求可以隨時從任一位置獲取系統數據）、對網元采集的統一，新系統需要承受的壓力要遠遠大于老系統現有壓力的疊加。因此，十分有必要根據目前的情況，對整個系統進行一次較為全面的性能測試。
我們的系統采用Oracle數據庫，IBM MQ消息平臺，采用的開發工具包括VS.NET、Perl、HP aCC和HP Temip平臺。整個系統由6個Unix應用模塊、8個PC應用模塊和三個WEB項目構成。
本次性能測試進入的條件是項目代碼已經基本完成并經過集成測試，1、2級遺留BUG數為0，3級遺留BUG數不超過5個。
說明：對于這樣一個集中式的系統，DCN網絡性能其實也應該是一個被重點考慮的對象，但根據L省以前類似項目經驗，目前的DCN網絡足夠支撐當前應用的運行，也就是說，在性能測試過程中不需要考慮由于DCN網絡原因造成的數據丟失和應用程序異常的情況。
2. 測試計劃
在初步確定了性能測試的要點后，我們就可以依據更具體的要求來制定性能測試計劃了，一般來說，性能測試計劃需要與客戶進行良好的溝通，測試目標、終止準則、策略、測試資源配備都需要和客戶經過溝通才能最終確定下來。實際操作中，建議至少召開一次正式會議，會議形成的結論要用會議紀要的方式確定下來，對最終確定的測試計劃需要客戶的簽字認可。
一份測試計劃至少需要包括測試對象、測試目標、測試策略、測試終止準則、測試環境與測試工具、測試資源配置（人員與時間）幾個方面的內容，本文不打算羅列出項目測試計劃中的所有內容，只就主要問題進行說明。
測試對象自然是本集中交換網管系統的性能；
測試目標在上文已經提到，需要和用戶溝通，得到用戶的認可。制定合理的測試目標并不容易，尤其是受限于現有項目文檔的詳細程序，單靠文檔描述很難制定出合理的測試目標，在本項目的測試中，我們結合了文檔描述、用戶要求和個人經驗，經過和用戶的討論，才最終確定了測試目標。
根據項目要求，我們對測試總體目標定義為“驗證系統的總體處理能力”，對于系統的擴展性，不作為本次測試的目標。測試結論要求給出系統能否達到設計性能、系統性能瓶頸所在。其中，“系統能夠達到設計性能”是本次測試的最關注內容。
“系統能夠滿足設計性能”的目標達成需要明確定義性能應該達到的指標。鑒于該部分的工作比較重要，以下將本次測試中的應達到性能指標確定過程詳細給出（當然，下文的例子中并沒有包含全部的數據），希望能給需要的同仁一點幫助。
需求和設計階段確定的性能相關指標是性能測試需要確定的性能指標的首要來源，對我們的這個系統而言，在需求文檔中確定的指標有三個：
1、 “能在一小時完成話務報告的采集，在5分鐘內完成報表的生成”；
2、 “具有600網元的告警和話務處理能力”；
3、 “告警要求在5秒內呈現”；
在設計文檔中，對于告警處理能力有更詳細的指標定義：
1、 “能處理平均每秒200次的告警”；
2、 “能處理峰值為每秒600次的告警”；
針對這兩份文檔中的描述，我們至少可以確定我們需要針對以下兩種情況進行測試：
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/