性能測試新手常犯錯誤總結（一）：找不到測試點，不知為何而測

05-24

來自專欄性能測試

有過一些性能測試經驗的人很容易進入此狀態，他們已經熟悉了性能測試的基本流程，能夠比較熟練的使用測試工具開展工作。我大概從事性能測試一年左右時遇到了這個問題，那時我覺得性能測試的過程沒有太多挑戰，遇到的每一個系統，彷彿都可以用同樣的流程完成。半天時間填寫測試方案，一天時間來準備測試環境，一天時間準備測試腳本，一到兩天來完成各種測試用例（基準測試、日常壓力測試、峰值壓力測試、絕對並發測試、穩定性測試等），然後就是調優、問題複測和完成測試報告。在我看來，性能測試好像變成了用一些工具去執行一個個固定的用例。

這樣的工作持續了一段時間後，我感到有些不對勁，一定是哪裡出了問題。性能測試難道真的這麼簡單，簡單到把任何一個系統套入標準的流程中就可以了？於是我開始思考測試的意義，為什麼要進行性能測試？是因為性能測試可以提供關於瓶頸、缺陷、效率等等我們認為有價值的信息。那僅僅通過一個工具，或者是一個固定的流程，就可以發現不同系統的這些信息么？這顯然是不可能的。

我開始嘗試盡量深入的去理解被測系統，這個系統的目的是什麼，用戶是如何使用系統的，用戶對哪些業務的性能比較敏感，系統的一些關鍵業務實現邏輯是怎麼樣的，從設計實現的角度來看哪些業務的性能可能存在隱患。這些很少是技術層面上的問題，需要做的只是思考，再深入思考。慢慢的我有了些收穫，開始了解為什麼要測這個系統，針對這個特定的系統哪些內容是最重要的，為了獲得需要的信息我需要從哪幾個方面進行測試，為了實現我的想法又需要哪幾種方法或者工具。（現在我的性能測試過程中，用於理解被測系統、理解用戶、整理測試思路的時間投入大大增加了。你呢，投入了多大比例？）

要做好這些其實很難，每一個被測系統對我來說，彷彿就變成了一個新的挑戰。但是逐漸的我發現自己思考問題更全面了、可以更快的抓住系統的重點、找到更重要的BUG、對系統的實際性能有了更準確的評估。這裡提一個簡單的問題，如何確保你的測試結果和生產環境的性能表現是一致的，也就是說測試結果能夠真正的反應實際的性能，而不僅僅是代表了你選取的幾個測試場景的性能。話說起來比較繞，但是請認真想一想，你有多大的把握呢？

上面只是寫了一些個人的感想，我覺得如果在「思想」上沒有辦法上到一個新的台階，你的性能測試生涯可能也就達到「瓶頸」了。如何突破這個瓶頸，那就需要努力改變自身，多思考多學習，最核心的能力。一定會有一些人認為性能測試的重點在於「技術」上，於是他們不斷的記住各種調優配置參數，以為自己掌握了性能的精髓，彷彿什麼系統到了他們手上，只要改幾個參數就會出現奇蹟。我也經歷了這個階段，也有過幾次自以為挺高明的調優經歷，也為自己會各種中間件資料庫的配置調優而有些小得意。

但現在想想，那還真是一個比較低的層次，思想上抓不住重點、看不全大局，技術上其實也只是一點皮毛。面對這類人，只要問幾個為什麼就會讓他們無法回答，為什麼要調優？為什麼要調這個參數？如何證明這次調整的效果？

將上文簡單的總結成幾點，希望能給性能測試新手提供一丁點的幫助吧：

1、性能測試的難點在於對被測系統的理解，在於對測試點的分析。為了實現測試的思想，可以有多種方法，手段永遠只是輔助的，只有思想才是根本的。工具（如LR）更不等於性能測試，不要以為會用LR就懂了性能測試，那只是最低級的測試執行。也不要以為會調幾個參數就懂了性能測試，那同樣是個比較低的層次。

2、調優等技術不是性能測試的主要目的，好的性能也不是調出來的。測試人員一定要明白自己存在的價值所在，所謂的「技術」只是為了達成自己測試目的的一些手段，同開發人員、DBA相比，你在這些技術上永遠是外行。

3、不要照著文檔模板，填入測試方案。每一個系統都是不同的，要真正的認識到這一點，為每個系統設計出有針對性的測試方案。思考你每一步工作的意義和目的。

4、如何證明測試結果的有效性，其實是個很難的問題，值得花費時間去認真思考。這個過程涉及到一些很重要的內容，如用戶模型的建立，後續會有專門的文章。

5、性能測試是一個需要不斷改進的過程，每一次只需盡量的做到更好，多做一點點以前沒有想到的東西。經過不斷的積累，你會發現自己對性能測試有了更深的認識。