很多人對效能測試的觀念常常不正確, 有些人認為它很單純, 有些人以為這樣做就可以了. 就讓我們來看看, 大家通常有什麼幻想 XD
迷思 1: 效能測試是在系統開發最後時候才做.
效能測試需要早期就開始規劃, 否則等到最後測試無法通過時, 往往是要修改架構才能符合需求, 這時候已經沒有時間讓你這樣的修改, 你不是裝死就交付出去, 要不然就是專案大延遲.
迷思 2: 執行效能測試將會改善受測系統的效能
進行效能測試只能告訴你, 受測系統是否符合效能的需求. 你要自己進行效能調校(performance turning), 才能改善受測系統的效能
迷思 3: 效能測試是在進行 code profiling 以便調校系統
理由類似上面, 效能測試只是確認受受系統的效能, 是否滿足當初訂的目標. 它不是在做 code profiling.
迷思 4: 效能測試需要在所有功能都沒問題後才做
並不是. 只要受測的 scenario 完成後, 便可以開始進行效能測試. 有些有大問題的地方, 這時候就可以被發現了.
迷思 5: 反應時間(Response time) 應該符合業界標準
沒有所謂的業界標準. 需要根據你的執行的環境(硬體配備, 作業系統, 網路環境等等), 以及受測系統功能的特性, 來決定合適的反應時間.
迷思 6: 增強硬體配備就能改善受測系統效能問題
增強硬體配備確實有幫助受測系統的效能. 但是根據研究, 大約只能增進 40% 左右的效益, 其他部分還是要藉由效能測試和效能調校來改善.
迷思 7: 效能測試和功能測試無關
基本上, 在進行效能測試前, 你需要了解受測系統這個功能如何運作, 遇到某些狀況或錯誤時, 受測系統會如何反應, 這些都會影響你效能測試的設計.
迷思 8: 受測系統存在瓶頸便不可使用
不一定. 有時候系統雖然存在效能瓶頸, 但是如果這個場景不易發生, 這個系統還是可以使用.
迷思 9: 在開發環境進行效能測試即可
效能測試需要一個獨立的環境. 否則外界的影響, 會導致結果失真. 例如, 你以為網路上只有你的封包, 但是在測試過程中, 有可能會有別的網路活動進來, 這樣就有可能導致你結果會有不正確.
迷思 10: 只需要進行一次效能測試, 便能找出瓶頸所在
通常你需要多跑幾次, 確認是環境或是測試程式的問題, 還是真的是受測程式的問題. 就算是受測程式的問題, 也需要多次實驗, 來找出可能發生問題的地方.
全站熱搜
留言列表
