小菜最近又接到乙個測試任務，這次的專案時乙個舊系統公升級改造專案。小菜接到任務後第一時間找到專案經理討論效能測試範圍，可專案經理扔給小菜乙個100多測試點的文件就走了，這可讓小菜頭痛不已。小菜去找大鳥大吐苦水。
小菜：「大鳥，這次的專案好複雜啊，100多個功能點，光準備測試指令碼都要好幾個星期呢，而且因為沒有監控模組專案經理對處理能力（tps）的要求也說不出個所以然來，這要做好我估計怎麼著也得半年吧」
大鳥 ：「呵呵。。你乙個效能測試做個半年，你那專案還要不要上線了。」
小菜 ：「大鳥你倒是說的輕鬆，這100多個功能點，難道給你做就能半個月就能測的好嗎？」
大鳥：」你要把全部功能點都測到 當然要很久。不過效能測試可做不到像做功能那樣全覆蓋，你可以挑選一些重要功能點納入你的測試範圍「
選擇效能測試範圍都會遵守下面三點：
1. 使用者使用最頻繁的功能
2. 開發人員認為可能存在風險的功能（畢竟親生的）
3. 重要的功能（比如支付等與錢相關的功能）
小菜扣了扣鼻子：「哎˜˜這道理你都和我說過好幾遍啦，可這系統什麼監控模組都沒有怎麼分析使用者使用行為啊。」
大鳥「誰和你說沒有的？中介軟體的access_log就是很好的監控模組。我早就幫你統計好啦，看吧」
「這個系統是用mvc struts編寫的，每乙個使用者提交事件都會對應到乙個.action方法，你只要統計每天每個方法的呼叫次數，就能大致的分析出使用者的使用行為了「
「哦˜˜˜access_log 還能這樣用啊，我一直以為它只是用來排查錯誤的呢 」
「這樣一來測試範圍也差不多可以確定下來了，分析出來的呼叫數量也正好可以作為這次效能測試的指標（tps）」
「哎呀，大鳥啊 經你這麼一整這個專案看來還是蠻簡單的嘛」
「小菜啊 ，效能測試的重點永遠在於分析與挖掘，每乙份你能獲得的資料都是寶貴的，你要懂得如何去分析使用這些資料。」
「大鳥 還是那麼文鄒鄒的，我這道行當然不能和大鳥比啦 」
可以結合這篇部落格的shell 分析下日誌檔案(access_log)
小菜的效能日記 2
小菜拿著兩份測試報告跑去找大鳥，讓他分析為什麼同樣的併發使用者加上think time差距會如此巨大。大鳥笑著說 你等一下我給你畫一張圖，你就懂了。這下我知道怎麼回事了，判斷乙個應用是否滿足效能指標，只需要判斷這個應用每秒能處理多少請求和使用者並沒有直接關係。小菜點著頭說。那a介面每天會有50000...
效能測試 效能環境與資料
效能環境，也是困擾效能測試人員很重要的乙個問題。如何模擬線上真實的環境？如何在測試環境進行的效能測試結果，能準確的反應到生產線上去？先聊下我們的做法。首先確認線上的網路拓撲圖。比如 左邊是線上環境，線上一般是分布式集群部署。比如使用者訪問伺服器a，而伺服器a需要依賴到伺服器b和c提供的服務，而伺服器...
效能測試（一）效能測試的內容
效能測試的型別與劃分網上已經有了很多的定義，比如壓力測試，負載測試，容量測試這三個詞在網上能找到很多版本的定義，大家能夠大體理解就行了，以下內容也只是我個人按照我在實際工作中接觸到的來理解的 1 壓力測試 是在被測系統上不斷增加壓力，知道效能指標超過預定指標。2 負載測試 是指在被測系統上在一定飽和...