常見的效能測試誤區

標籤：情境   實戰   環境   領域   測試方法   條件   情況   處理   lan   

摘自《web效能測試實戰》，該書為06年出版的，經過12年時間效能測試領域技術的沉澱，對於誤區闡述的觀點在當下並不是太難理解，就挑幾個記下來。

誤區1：效能測試獨立於功能測試

　　效能測試和功能測試時緊密聯絡在一起的，原因之一是很多效能問題是由軟體自身功能缺陷引起的。如果應用系統功能不完善或者代碼運行效率低下，通常會帶來一些效能問題。功能測試通常要先於效能測試或者同步進行，軟體功能完善可以保證效能測試更加順利。

　　功能測試可以發現效能問題，效能測試也能發現功能問題。例如，並發使用者測試就能發現一些演算法設計上的問題。在一些業務處理上，通常採用多線程的同步演算法，通過並發使用者測試很容易發現演算法中存在的一些缺陷。

　　很多時候如果軟體效能要求比較高，效能測試和功能測試會同步進行。因為如果後發現效能問題可能無法補救。

 

誤區2：效能測試就是使用者並發測試

　　書中的觀點相信現在應該不存在，在前面的《效能測試-開發世界的狂野一面》一文中已經闡述了各種類型的測試方法。

　　效能測試是一項工作，應該按照PDCA的模式運行（PDCA：計劃（plan）、執行（do）、檢查（check）、處理（Act））

 

誤區3：系統存在瓶頸就不可使用

　　系統發現瓶頸，的確是一件讓人頭疼的事情。

　　發現瓶頸的目的主要是為了掌握系統特性，為改善和擴充系統提供依據。

 

誤區4：不切合實際的效能指標

　　書中的觀點在於對軟體應用需求的不瞭解，亂提需求。是的，這種情況下應該勇敢的說出NO!

　　對待效能問題要根據實際情況來決定，系統效能滿足使用者現在以及未來一定時期的需求。

 

誤區5：效能測試結果由並發數懟出來的資源使用率來決定

　　這是目前看到的比較常見的一種情況，在不瞭解系統架構、資料流、業務情境、測試策略、軟硬體環境、伺服器參數配置等等必要條件下，死懟並發數得出來的資源使用率為結果，這麼下結論顯然是有錯誤的、沒有意義的。任何一項條件沒有滿足，那麼這個結果就是不完整的。

　　

 

常見的效能測試誤區