曾經我們幫助客戶進行軟件性能測試的時候，客戶不解的問，不是必須通過功能測試后才可以測試性能嗎？可能有很多人會存在這樣的疑問，在這里，我們的多位專家根據多年經驗總結出性能測試的10大誤區，希望能給大家帶來幫助。

　　誤區1：應用程序必須通過功能測試后才可以測試性能。

　　應該盡早的進行性能測試。性能測試可以發生在各個測試階段中，即使是在單元層，一個單獨模塊的性能也可以使用白盒測試來進行評估，然而，只有當整個系統的所有成分都集成到一起后，才能檢查一個系統的真正性能。

　　性能測試從早開始，完成一個小模塊，對小模塊的接口進行性能測試，一般耗費資源很少，但可以防止問題在項目最后出現，花費很大的精力去修改。

　　而有些資料中提到的：在系統代碼開發和功能測試完成之后，進行性能測試的說法，是為了檢查系統整體性能的做法。一般經常出現在驗收性能測試中。

　　誤區2：軟件性能測試要向功能測試一樣，覆蓋到所有功能。

　　性能測試的主要目的是為了系統調優。不可能對所有的系統功能都進行性能測試。在測試設計時需要結合當時的實際系統，先分析軟件可能存在的瓶頸，此時可依據80/20原則分析：對系統資源的利用、數據大量傳輸、數據轉換、用戶使用頻率、邏輯復雜度等進行分析，選擇要執行的功能和場景，再依次制定性能測試的方案。

　　誤區3：系統吞吐率隨著并發量增加而增加。

　　隨著并發量的增加吞吐率并不是線性增長的。并發量從小逐漸增大，開始階段吞吐率隨著并發量的增加線性變化；當并發量達到某一值時，系統處理能力趨于飽和（也可能某一硬件條件達到臨界值），此時再逐漸增大并發，會有一些請求處于等待狀態，所以響應時間變慢，吞吐率趨于穩定；當并發量達到系統的最大處理能力后，再增加并發，系統處理能力會下降，吞吐率也會下降，最終可能發生宕機。

　　誤區4：客戶給出性能指標，我們一定要想法設法達到。

　　根據用戶提供的指標進行可行性分析，分析這些指標在理想狀態下是否可以達到。比如有這么一個要求：有一臺服務器，希望能承載10000個用戶每秒200kb的傳輸。從CPU、Disk、網卡等方面分析都是很難達到的，也是很難測試的。需要和客戶商討增加硬件配置或者通過其他途徑來解決。

　　誤區5：壓力測試、負載測試、容量測試等這些不同類型的測試一個一個分開來執行。

　　現實場景是復雜的，測試也需要盡可能的模擬負載的場景。在一個整體的系統性能測試場景中，應該包括各個類型的測試。而需要檢查某一個方面的指標或分析某個性能問題時，盡量保證場景簡單、單一、容易模擬。

　　誤區6：做性能測試主要就是性能測試工具的使用；我做不好性能測試，是因為對測試工具不熟悉；測試工具可以自動生成我所需要的報表；依靠性能測試工具就能準確定位系統瓶頸；

　　測試工具在測試中只能起到輔助性作用。而測試方案、測試場景的分析、問題的定位這才是性能測試的關鍵。不要期望測試工具能夠生成你想要的東西（報表、瓶頸分析），工具只是盡可能多的提供我們分析的依據。

　　誤區7：在線用戶數就是并發用戶數。并發用戶數高意味著PV（頁面瀏覽量）大。

　　并發用戶數*用戶訪問頁面數=PV

　　誤區8：提高一下硬件配置就可以提高性能了，因此性能測試不重要。

　　隨著軟件規模的擴大，提高硬件配置只是解決性能問題的一個基本手段。因為如果軟件自身存在性能問題，再多的資源可能也不夠用，例如：內存泄露問題，隨著時間的增加，內存終究會被耗盡，最后導致系統崩潰；數據庫連接等配置信息、數據庫死鎖是和硬件很難掛鉤的；算法邏輯問題導致程序緩慢。即使要提高配置，也要首先用性能測試的方式得出哪些硬件可能存在瓶頸。

　　誤區9：性能測試獨立于功能測試

　　一方面，整體性能測試的場景設計要求的系統功能非常熟悉；另一方面，功能測試可以發現性能問題，性能測試也能發現功能問題。很多性能問題時由于軟件自身功能缺陷引起的。如果應用系統功能不完善或者代碼運行效率低下，通常會帶來一些性能問題。功能測試可能會發現這些問題。

　　誤區10：隨便找個環境下進行一下性能測試就可以了。

　　做性能問題分析可以在類生產環境上進行，配置可以有些差別，但是，整體性性能測試、驗收性性能測試要盡量在用戶生產環境下進行。

====================================分割線================================

最新內容請見作者的GitHub頁：http://qaseven.github.io/