有過一些性能測試經驗的人很容易進入此狀態，他們已經熟悉了性能測試的基本流程，能夠比較熟練的使用測試工具開展工作。我大概從事性能測試一年左 右時遇到了這個問題，那時我覺得性能測試的過程沒有太多挑戰，遇到的每一個系統，仿佛都可以用同樣的流程完成。半天時間填寫測試方案，一天時間來準備測試 環境，一天時間準備測試腳本，一到兩天來完成各種測試用例（基準測試、日常壓力測試、峰值壓力測試、絕對并發測試、穩定性測試等），然后就是調優、問題復 測和完成測試報告。在我看來，性能測試好像變成了用一些工具去執行一個個固定的用例。
這樣的工作持續了一段時間后，我感到有些不對勁，一定是哪里出了問題。性能測試難道真的這么簡單，簡單到把任何一個系統套入標準的流程中就可以 了？于是我開始思考測試的意義，為什么要進行性能測試？是因為性能測試可以提供關于瓶頸、缺陷、效率等等我們認為有價值的信息。那僅僅通過一個工具，或者 是一個固定的流程，就可以發現不同系統的這些信息么？這顯然是不可能的。
我開始嘗試盡量深入的去理解被測系統，這個系統的目的是什么，用戶是如何使用系統的，用戶對哪些業務的性能比較敏感，系統的一些關鍵業務實現邏 輯是怎么樣的，從設計實現的角度來看哪些業務的性能可能存在隱患。這些很少是技術層面上的問題，需要做的只是思考，再深入思考。慢慢的我有了些收獲，開始 了解為什么要測這個系統，針對這個特定的系統哪些內容是最重要的，為了獲得需要的信息我需要從哪幾個方面進行測試，為了實現我的想法又需要哪幾種方法或者 工具。（現在我的性能測試過程中，用于理解被測系統、理解用戶、整理測試思路的時間投入大大增加了。你呢，投入了多大比例？）
要做好這些其實很難，每一個被測系統對我來說，仿佛就變成了一個新的挑戰。但是逐漸的我發現自己思考問題更全面了、可以更快的抓住系統的重 點、找到更重要的BUG、對系統的實際性能有了更準確的評估。這里提一個簡單的問題，如何確保你的測試結果和生產環境的性能表現是一致的，也就是說測試結 果能夠真正的反應實際的性能，而不僅僅是代表了你選取的幾個測試場景的性能。話說起來比較繞，但是請認真想一想，你有多大的把握呢？
上面只是寫了一些個人的感想，我覺得如果在“思想”上沒有辦法上到一個新的臺階，你的性能測試生涯可能也就達到“瓶頸”了。如何突破這個瓶 頸，那就需要努力改變自身，多思考多學習，最核心的能力恐怕不是能培訓出來的。一定會有一些人認為性能測試的重點在于“技術”上，于是他們不斷的記住各種 調優配置參數，以為自己掌握了性能的精髓，仿佛什么系統到了他們手上，只要改幾個參數就會出現奇跡。我也經歷了這個階段，也有過幾次自以為挺高明的調優經 歷，也為自己會各種中間件數據庫的配置調優而有些小得意。但現在想想，那還真是一個比較低的層次，思想上抓不住重點、看不全大局，技術上其實也只是一點皮 毛。面對這類人，只要問幾個為什么就會讓他們無法回答，為什么要調優？為什么要調這個參數？如何證明這次調整的效果？
將上文簡單的總結成幾點，希望能給性能測試新手提供一丁點的幫助吧：
- 性能測試的難點在于對被測系統的理解，在于對測試點的分析。為了實現測試的思想，可以有多種方法，手段永遠只是輔助的，只有思想才是根本的。工具 （如LR）更不等于性能測試，不要以為會用LR就懂了性能測試，那只是最低級的測試執行。也不要以為會調幾個參數就懂了性能測試，那同樣是個比較低的層 次。
- 調優等技術不是性能測試的主要目的，好的性能也不是調出來的。測試人員一定要明白自己存在的價值所在，所謂的“技術”只是為了達成自己測試目的的一些手段，同開發人員、DBA相比，你在這些技術上永遠是外行。
- 不要照著文檔模板，填入測試方案。每一個系統都是不同的，要真正的認識到這一點，為每個系統設計出有針對性的測試方案。思考你每一步工作的意義和目的。
- 如何證明測試結果的有效性，其實是個很難的問題，值得花費時間去認真思考。這個過程涉及到一些很重要的內容，如用戶模型的建立，后續會有專門的文章。
- 性能測試是一個需要不斷改進的過程，每一次只需盡量的做到更好，多做一點點以前沒有想到的東西。經過不斷的積累，你會發現自己對性能測試有了更深的認識。