效能測試 (Performance test) 是軟體測試中非常專業的一塊, 主要是來確認受測系統的效能. 量測系統到底有多快, 是否滿足當初所設定的目標. 如果沒有滿足則會進行系統調校, 直到受測系統 meet 目標為止.
為了完成效能測試, 我們需要有一套流程, 確保該做的事情都有做, 因此, 讓我們看看這個流程要做什麼
A. 評估受測系統
做任何事情, 都要了解任務的目標為何, 否則最後可能都需要再花額外的時間來修正. 因此, 要和利害關係人確認, 做這個效能測試的目的為何：只是要知道受測系統能跑多快, 還是要進行效能調校, 亦或是有做就可以.
接著你還要知道要測試哪些場景(scenario), 在怎樣軟硬體環境下執行, 以及相對應的通過條件為何. 這些要確認後, 你才知道要怎麼規劃這個測試.
B. 建構測試資產
首先, 你要制定好效能測試的策略, 哪些先測, 要測多久, 要測幾次, 在哪個環境測試等等. 這些要知道, 才能規劃你測試的進行.
另外, 效能測試往往不見得能很順利, 所以你需要做好最壞的打算, 譬如: 受測系統不夠穩定到可以測試, 測試機器環境不夠, 調教時間超乎預期的久等等. 你需要思考當遇到這些狀況發生時, 你打算怎麼因應. 也就是做好風險管理.
最後, 就是要準備自動化的腳本. 你需要能產生大量的測試資料, 並且也需要能收集和分析測試結果. 這些腳本需要花時間打造, 並且也要花時間確認其正確性. 我想妳一定不樂見最後是測試程式的錯, 而不是受測系統的問題.
C. 執行效能測試
這個階段就是要來執行自動化腳本. 一開始時, 你要先進行 pilot run, 先確保你腳本的正確性, 確定每次都可以產生出相同的模擬結果, 並且環境也是安裝正確的. 否則之後才發現有錯, 可是會浪費很多時間.
接著, 不是只針對受測系統下去執行就好. 為了要知道受測系統效能到底好不好, 你可能需要有個 baseline. 因此你要先針對 baseline 去做測試, 這樣之後受測系統測完後, 才有比較的基礎.
D. 分析測試結果
這個部分通常是最難, 也是最重要的工作. 為什麼這樣說呢?
最難的原因, 是你需要了解受測系統架構, 才能夠分析慢在哪裡, 或者是哪個地方有可疑. 這可能需要開發人員的幫忙, 否則不太容易抓到重點.
最重要的原因, 是因為如果測試完後沒有分析的建議出來, 只是說測試通不通過, 那這個測試在大多人數心中是沒有價值的, 因為測試完後沒有帶來任何資訊.
E. 效能調校
正常來說, 很少有受測系統一次就過關的. 往往需要來回好幾次. 這時候你要做的, 是要根據開發人員的需求, 幫他控制變因, 或者是在多收集一些資訊, 好讓他知道問題出現在哪. 因此, 你的自動化腳本設計的好不好, 會決定你這時候日子好不好過. 如果可以改些參數, 就可以達到 RD 的要求, 那事情就很 perfect. 如果還需要對測試腳本加功能, 這個測試時間就會拖很久, 因為說不定還要確認舊的測試是沒有影響的. 有影響的話, 還需要再來一次. 哭哭.
上述的狀況還算簡單, 最怕的是根本看不出為什麼慢, 這時候你要做的便不是改自動化腳本, 而是要去做些探索式測試, 或者是 profiling, 幫助開發人員找出更多線索, 這又是另外一條漫長的道路.
好了, 以上就是效能測試大概要做的事情, 有沒有體會到測試人員的辛苦了.
可是瑞凡, 我們專案從來沒有訂效能測試的目標, 也不需要作系統調校, 這個測試只是要交報告的, 不需要有這麼認真的流程啦 .....
全站熱搜
留言列表
