效能和負載測試的比較和做法

此文比較效能和負載測試的不同,並且舉例說明。例子裡面帶到幾個步驟,值得看看。

(1) 分析和觀察系統瓶頸
– 在測試、折磨被測的軟體時,可以觀察、性能分析這個軟體有任何熱點是需要最佳化的。若我們在測試公司產品時,就可以觀察、監視是否哪個功能或步驟是特別吃資源的。這讓我想到之前微軟測試之道第八章裡面說的「Petri Nets」,也是可以藉由視覺化網絡裡狀態轉換的過程,觀察出有哪些狀態是特別會踩到,需要留意的。
(2) 重新調校系統
– 若使用達到一個量之後,發現某個重複的步驟會導致問題,就可以根據步驟一找出需要調教的部分,最佳化我們的測試。
(3) 建立/比較基線值(baseline number)
– 若我們的程式碼和環境已經達到最佳化了,接下來就是考慮水平開展系統的時候。此時可以先將目前優化過的產出數據當作基準,在水平開展系統後,以相同設定值跑效能測試,可觀察出水平開展的變化是否會導致效能的增進或衰減。
(4) 執行壓力測試
– 在真實產品環境下反覆執行上述的測試。

參考:Petri Nets

此篇介紹壓力測試的實例,雖然是屬於 web的壓力測試,但我們還是可以參考裡面的壓力測試計劃內容。
包含破壞性測試、強度穩定性測試、暫停標準和再啟動要求。
未來可以測試看看上萬人跟隨某一虛擬台長一起聽,持續一段長時間(24小時),看看會不會有問題的這種測試。

此篇介紹「負載壓力測試中監理的工作重點」:
其中一點帶到說測試環境要須盡量接近真實環境,這樣測試出來的結果才具有實際意義。

有些問題是真的給到客戶端使用後才會浮現,姑且除去第三方軟體的侵入性操作因素(ex. 清除資料),考慮到資源競爭或是連線交互作用這些因素,也極有可能會造成我們的軟體失常。

此篇介紹「壓力測試」,其中提到一點是關於壓力測試環境的「累積效應」:
有些測試人員喜歡在壓力測試中讓整個系統重啓,目的是確保後續測試可在一個「乾淨」的環境內進行。雖然這有助於問題的分析,但卻不是個好現象,因為會忽略累積效應,無法捉到一些細微會日積月累的問題。

我們測試時應當清楚目的是如何,非壓力測試時可以讓環境保持乾淨沒關係,但在壓力測試過程中就可以盡量折磨系統,觀察受測系統是否足夠強健承受累積的壓力。

此篇介紹「如何做性能測試」(可往下閱讀整章的五個小節)
其中帶到「GAME(A)」性能測試過程模型,即:
(1) Goal
– 其中的透過觀察性能和負載間的關係,可發現響應時間的「拐點」(響應時間顯著延長的位置)
(2) Analysis(分析)
(3) Metrics(度量)
– 案例結果的 pass/ fail 除了是基於業務級的定義,也有可能是因為案例間的相關係而引起的 pass/ fail。(例:A fail了,B也跟著 fail,因為B會使用到A產出的資料)
>> 削弱腳本間的關聯性可以增強我們的測試品質。
(4) Execution(執行)
(5) Adjust(調整)

此次閱讀範圍:1.1 性能測試的重要意義~1.2.3
其中給予觀念:
功能測試用於確保軟體系統做了正確的事情,性能測試則用於確保軟體系統快速地完成了任務。

也提到不同角色眼中的軟體性能:
包含系統管理員、RD、顧客 眼中在意的性能點(尤其是顧客,時間就是金錢,性能不夠好的產品無法抓住顧客的心)
我們可以參考以上要點,當作把關的參考。

最後提到須對系統的響應時間、用戶數和資源使用進行分析、驗證、優化。

除了藉由檢測幫助受測軟體的優化,我們測試的程式也需要優化,才能更有信心、有效率地配合。

廣告

發表迴響

Please log in using one of these methods to post your comment:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s