Web 性能測試需求分析方法

這是一個會議系統, 面向市場推廣活動, 看到廣告的人, 都可能會來參加該會議, 但是會議支持人數的上限 1000.

-- 從每小時訪問量, 再根據業務邏輯, 推算各典型業務可能的壓力. 推算出性能測試指標.

        大量用戶可能因為廣告效應， 訪問量比較大， 估計高峰時段, 每小時訪問量： 2W ~ 5 W, 以 2w 為例。毛估：

30% 會直接離開

70% 會逗留 - 其中40% 瀏覽頁面(8000左右)，10%（2000 左右） 加入/離開會議， 5%(1000 ) 填寫登記表 ， 5%（1000） 填寫調查表， 0.1 %(20) 安排會議。

        因此典型業務的大概估計是：

        關鍵頁面： 每小時 8000, 每秒 2 page 左右. 首頁加上進來馬上離開的人，每秒最多 10 page. 模擬并發時， 并發用戶之間時延 100 ms – 500ms的高斯時間. 操作動作時延以實際錄制時延為準。

        登陸: 包含加入會議有個對登記者的驗證過程， 估計最大并發數在每秒10 個以內.

        安排會議： 安排會議的并發量應該會非常少，估計最大并發數在每秒5 個以內.

        加入會議： 通常我們一個會議人數限制在1000 人， 由于我們通常提早15分鐘通知， 估計加入峰值在15 分鐘內。 最多15 分鐘(900s) 加入 1000 人。 最多每秒加 2 個人。并發用戶時延可考慮在 100ms - 500ms 。

        離開會議： 離開會議會產生高峰， 1000 人估計會在2 分鐘內退出， 退出后的調查頁面估計有20% 會在2 分鐘內同時提交。 退出返回頁面要求支持瞬間每秒 10 個并發。 調查頁面支持每秒 10 并發.


        根據以上分析，系統對并發量要求很低! 所以并發上幾乎沒有問題。 關鍵參數是響應時間和出錯率。 我們需要類比在用戶典型行為下的響應時間和出錯率！比較同類網站的響應時間.

QA 的測試重點就是：

1. 關鍵模塊的單獨壓力測試(沒有時延)， 先保證不存在代碼錯誤問題。

2. 典型用戶行為的測試，重點關注響應時間和出錯率。 實現性能優化.

3. 典型用戶行為下的穩定性測試

4. 比較同類網站的響應時間.

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