從奧運會票務系統癱瘓所看到的---關于性能測試

　　在今天舉行的發布會上，有外國媒體提問：有兩個問題，票務的問題是一個合作的問題，是北京奧組委和技術部門合作的，也是合資企業在負責技術系統，具體票務系統是誰負責的，出現問題，具體由哪個部門負責？整個票務技術系統的花費是多少，昨天出現這樣的問題，肯定帶來了很大的花費，造成了多少經濟的損失，這個錯誤應該由誰來負責，造成損失有多大？

　　對此，容軍回答說：“我們的技術服務商是由美國ticket master公司和兩家中方的合資企業�！�

　　他表示，我認為目前這個階段，最重要的任務是要解決問題，是要解決當前遇到的困難，盡快地拿出一個可行的實施方案，盡快地能夠再次向公眾實施門票的銷售。至于責任的問題，我們會根據具體的問題具體分析，有關的協議條款也是規定比較明確的，但是我認為目前這個工作是放在第二位的事情，包括剛才提到的費用方面的損失，我們也需要經過評估。

         從以上新聞中，我們不難看出這里面關于軟件測試技術在WEB網站測試中的應用之不足。奧運會網絡票務系統設計的最高峰值為100萬次/小時并發登錄，而當天的官方網站訪問量達800萬次/小時，就連呼叫中心的訪問量也超過380萬次/小時，票務系統在開始運作不到半小時就徹底癱瘓。我們可以分析一下這個事件出現的原因：

一、對網絡訪問量的估計有嚴重缺陷

      大家都知道，基于B/S架構的WEB系統，在做系統測試時分功能性測試和性能測試兩大方面的工作，而在做性能測試時要考慮到系統的負載測試和壓力測試。為了能夠避免出現系統性能由于訪問量的劇增導致系統癱瘓、崩潰，一般是要進行壓力測試后做網絡負載均衡，此次現象的發生說明在做系統測試時沒有考慮到網絡訪問量的突變。

二、沒有對票務系統的服務器做有效的冗余

      在WEB系統中，需要對服務器做冗余備份，當系統的負載超過一定峰值時，必須啟動備份的服務器進行負載均衡，以減少由于網絡風險而帶來的損失。奧運會票務系統的最大峰值負載為100萬并發/小時，當系統的閥值在80萬--90萬次并發/小時的時候，就要啟動備份服務器以緩解系統的壓力。

三、系統的測試工作嚴重缺乏

      當一個大型軟件系統尤其是基于B/S架構的WEB網站，往往關注比較多的是功能上是否實現了即定的功能、是否和數據庫聯接、表單遞交是否成功、易用性好壞、兼容性如何等等，偏偏對系統的性能測試工作準備不足或沒有做足夠的考慮。

    綜合以上表述，我們可以看出在一個基于B/S架構的WEB網站，做系統測試時需要考慮的問題要復雜得多，也更說明性能測試在WEB系統中的重要作用。