效能測試範圍與使用者行為模型

  小菜最近又接到一個測試任務，這次的專案時一箇舊系統升級改造專案。小菜接到任務後第一時間找到專案經理討論效能測試範圍，可專案經理扔給小菜一個100多測試點的文件就走了，這可讓小菜頭痛不已。小菜去找大鳥大吐苦水。
小菜：“大鳥，這次的專案好複雜啊，100多個功能點，光準備測試指令碼都要好幾個星期呢，而且因為沒有監控模組專案經理對處理能力（TPS）的要求也說不出個所以然來，這要做好我估計怎麼著也得半年吧”
大鳥 ：“呵呵。。你一個性能測試做個半年，你那專案還要不要上線了。”
小菜 ：“大鳥你倒是說的輕鬆，這100多個功能點，難道給你做就能半個月就能測的好嗎？”
大鳥：”你要把全部功能點都測到 當然要很久。不過效能測試可做不到像做功能那樣全覆蓋，你可以挑選一些重要功能點納入你的測試範圍“
選擇效能測試範圍

1. 使用者使用最頻繁的功能
2. 開發人員認為可能存在風險的功能（畢竟親生的）
3. 重要的功能（比如支付等與錢相關的功能）

小菜扣了扣鼻子：“哎˜˜這道理你都和我說過好幾遍啦，可這系統什麼監控模組都沒有怎麼分析使用者使用行為啊。”
大鳥“誰和你說沒有的？中介軟體的access_log就是很好的監控模組。我早就幫你統計好啦，看吧”

“這個系統是用mvc struts編寫的，每一個使用者提交事件都會對應到一個.action方法，你只要統計每天每個方法的呼叫次數，就能大致的分析出使用者的使用行為了“
“哦˜˜˜access_log 還能這樣用啊，我一直以為它只是用來排查錯誤的呢 ”
“這樣一來測試範圍也差不多可以確定下來了，分析出來的呼叫數量也正好可以作為這次效能測試的指標（TPS）”
“哎呀，大鳥啊 經你這麼一整這個專案看來還是蠻簡單的嘛”
“小菜啊 ， 效能測試的重點永遠在於分析與挖掘，每一份你能獲得的資料都是寶貴的，你要懂得如何去分析使用這些資料。