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

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

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

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

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

誤區2：性能測試就是用戶並發測試

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

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

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

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

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

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

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

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

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

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

常見的性能測試誤區