一個大型集中項目的性能測試實例

從2004年8月底至2004年10月中，本人在北方L省的一個全省集中的交換網管項目中負責該項目的性能測試工作。該性能測試歷時1個半月多，投入了3.6人月，占總的項目測試投入的17％。性能測試共進行了三輪，測試實現了預期的目標，測試過程中共發現影響性能的2級缺陷5個，三級缺陷8個，其中有一個缺陷導致了架構的部分變更。缺陷修改完成后，整個系統的采集效率提升了60％，告警入庫效率提升了20％，應用的修改也使得系統具有了更強的穩定性。從測試的結果來說，本次測試取得了比較滿意的效果，在測試過程中，本人也有一些心得和體會，因此，通過這篇文章記錄本次性能測試的過程，希望能和各位同仁進行性能測試的更加深入的交流。
　　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次的告警”；
　　針對這兩份文檔中的描述，我們至少可以確定我們需要針對以下兩種情況進行測試：
　　1、 針對600個網元話務報告的采集和處理進行測試，采集過程要求在一小時完成；報表生成需要在5分鐘內完成；
　　2、 針對600個網元的告警處理能力進行測試，在告警產生的均值為200次/秒，峰值產生為600次/秒的情況下，告警從產生到呈現的時間間隔不超過5秒；
　　粗看起來，這兩個指標的定義已經很詳細了，但仔細考究，其實這樣的描述還是遠遠不夠的，例如，對第一個指標，話務周期（多長時間產生一次數據）必須要指明，因為5分鐘的話務周期和1小時的話務周期在處理速度上是有很大差別的；對第二個指標，必須說明在多少呈現告警客戶端的條件下，因為多個告警客戶端和單個告警客戶端在性能上肯定會有不同。
　　除了從文檔中獲取的指標外，直接從用戶處獲取的指標也很重要，例如，在可客戶的溝通中就發現，客戶對于實時性能數據的呈現時間也非常關注，但在需求中并未提到該需求，當然，通過和客戶直接溝通獲取的指標必須經過變更控制，在文檔中變更體現后才能被正式納入測試目標。
　　還有一個指標的來源就是個人經驗了，作為一門實踐性的學科，個人經驗在測試中發揮的作用也是不能忽視的，例如，根據系統的實現，在測試指標中增加“300用戶并發時MQ服務器的MQ派生進程數不得超過200個”等。
　　本次測試最終確定的需要驗證的性能指標為14個，其中從文檔中直接映射的為6個，從客戶獲得并經過變更控制認可的為2個，根據經驗補充的為6個。
　　測試策略描述對整個測試采取的方法，本次測試的測試策略規定，測試最少為2輪，每輪測試應該執行所有的測試用例至少一次，在一輪測試過程中程序需要保持“鎖定”，不允許進行修改，每輪測試結束后需要形成測試結果記錄文檔；所有的待驗證指標都達到后才能稱為本測試結束，測試結束后需要提供完整的測試報告，記錄整個測試過程和中間結果。
　　測試終止準則確定測試終止的原則，對本次測試，我們定義了每輪的終止準則“所有測試用例至少執行一次”，定義了整個測試的終止準則“所有待驗證指標都達到”。
　　測試環境與測試工具確定本測試需要使用的測試工具和定義需要使用的測試環境，這部分的內容非常重要，對于測試環境，在計劃階段需要盡可能地考慮到各種可能的情況，設備資源限制的情況等，否則，在測試執行時才發現環境不完整就很被動了；對于需要使用的測試工具，測試設計階段也應該進行詳細的規劃，采用商用工具還是自己開發工具？到底需要哪些工具才能滿足測試的需要？好的規劃可以讓你盡早安排相關人員的配合（例如，需要找開發人員協調開發測試工具），反之，把希望寄托在“我有XX測試工具”或是“XX測試工具據說很好用”就一定會導致測試的失敗。
　　測試資源配置描述執行本測試需要的人員和時間資源，一方面可以作為工作量的評估與項目經理和客戶進行溝通，另一方面，也可以盡早規劃工作安排。
　　3. 測試用例與測試數據
　　確定了測試計劃后，就可以針對測試計劃中確定的需要測試的指標設計測試用例了。同樣，設計的測試用例也需要向客戶解釋清楚并得到客戶的認可。一般來說，客戶比較關注的“這個測試用例怎么能說明系統達到了性能指標？”和“我怎么檢驗你的測試結果？”，因此需要通過會議或是其他方式與客戶盡可能地溝通，在本項目的測試中，我們在第一輪測試中就出現了因為與客戶溝通不夠出現的問題，其實在測試用例執行之前，我們已經和客戶進行了測試用例的確認，但在執行過程中，用戶表示希望能看到更詳細的中間結果，導致我們只能重新修改了部分測試工具和測試環境，導致測試執行未能按計劃完成。第一輪測試完成后，我們就再次和用戶對測試用例進行了詳細的審核，包括每個用例的詳細輸入、輸出，以及如何驗證輸出。
從已確定的測試指標產生測試用例沒有單一的法則，這個就是測試設計員（Test Designer）的基本功了，在這里不進行描述。
　　關于測試用例的書寫格式在51cmm和其他很多網站上都有討論，我個人的感覺是不必要太多拘泥于測試用例的書寫方式，一般只要測試用例描述清楚了測試步驟、輸入、預期輸

用例編號		XXXX_NFT_PT_XX	用例對應功能點
用例類型		性能	用例優先級
用例簡要描述		XXXXXXX
用例依賴關系		無	用例依賴用例
用例創建人			用例執行時間
用例執行先決條件		1． 使用一臺采集服務器作測試用； 2． 已通過模擬程序產生每秒300條告警的告警數據； 3． 所有告警產生和呈現時間記錄在本地日志文件中。
檢測方法		1． 由網元模擬程序產生特定告警（T1）； 2． 告警被上層應用呈現的時間由上層應用記錄（T2）； 3． 計算T2－T1，結果小于5秒；
修改記錄
〔修改人〕		（修改時間）	（修改內容）
用例描述
步驟	操作		輸入數據	預期輸出
1	用戶啟動主界面，進入告警監控界面
2	產生一個特定告警（便于識別），發送至系統		XXXX（特定告警的詳細內容）	特定告警的發送時間記錄在文件XXXX中
3	在告警監控界面上查看特定告警			觀察到特定告警出現的時間（記錄在文件XXXX中）和告警實際發生時間相差不超過5秒
測試結果描述：
測試		測試結論：		簽名：

　　從本測試用例中可以看到，測試用例已經詳細定義了用例執行的先決條件、測試輸入和輸出，以很直觀的方式給出了測試用例的各個要素。
　　設計測試用例的過程中，同時需要關注的是測試數據的產生和維護。
　　在上一個測試用例的例子中，“特定告警的詳細內容”就是一個被選擇的測試數據，如何選擇具體的測試數據需要根據測試的具體需求而定，沒有統一的法則。但在設計測試用例時，一定要明確每個用例的數據需求并將這種需求綜合起來，并形成對測試環境的測試數據的維護策略，以便在測試用例執行時能順利進行。
　　一般而言，我們可以考慮初始測試數據的需求、考慮測試用例之間的依賴關系、記錄每個用例對數據的要求，然后最終確定需要哪些測試數據和如何維護測試數據。
　　【小結】
　　本文記錄了一個對大型集中項目的性能測試過程，對于性能測試過程中的測試目標選擇、測試用例的設計、測試數據的產生和維護進行了較為詳細的討論，后續的“下”篇中將重點描述測試環境準備、測試工具應用、測試實施、測試報告方面的內容，并對性能測試過程中的一些問題進行了討論，希望各位同仁不吝指正。

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