系列原創：測試人員喜歡在得到某個達不到預期的效能結果後，進行一下「調優」。效能測試新手誤區
pm有時也會布置任務，測試完成後「調乙個優」。
一些人貌似有了這種觀念：調優才使效能測試有意義、效能測試的目的就是調優、做調優才能顯出測試人員的水平……
隨著經驗的增長和對效能更深入的認識，我越來越體會到調優是乙個複雜的過程，不是動動嘴、改倆個引數這麼簡單，只有通過科學的方法和紮實的技能才能做好，以至於我使用這個詞的頻率越來越低，因為不敢輕易說出口……
在你再一次調優之前，先考慮以下幾個問題：
如果問起這個問題，得到的回答通常是「因為效能不夠好」，那麼接下來我會問效能不好體現在**？你要調什麼？希望得到什麼結果？
如果你不能足夠準確的回答第乙個「體現在**」的問題，後兩個也一定沒有答案，所謂的調優自然也無從談起。而這第乙個問題的答案其實也就是定位的過程。
舉乙個小例子。如果我已經發現資料庫較慢，通過進一步監控又發現了乙個cache的spinlock contention這個指標超過了正常的範圍。那麼我會猜測可能是這塊快取的爭用導致了資料庫的執行狀況變差，針對這個現象我知道可以通過將cache分割槽來減少爭用，改變配置後再重新測試和監控，這就可以算是一次調優的嘗試。
但如果你只停留在資料庫慢的這個層面上，又怎麼能進行調優呢？
所以，需要調優的乙個前提是「定位到問題」或者「發現了瓶頸」。
又有人說了，沒有問題為什麼不能調優？沒有問題，我們可以讓系統變得更好！
但是，所謂的「更好」如何衡量？「好」到什麼程度時不需要繼續「好」了呢？
請記住，瓶頸永遠存在，消滅了乙個，就必然會引入另乙個。
調優的目標也不是「沒有瓶頸」，而是系統在其所承受的壓力下，效能表現足夠好，那就夠了！
「足夠好」其實也就是沒有問題。
理解了上面的內容，這個問題的答案就很明顯，調優必然是針對具體的問題或瓶頸。
而問題和瓶頸，指的是「效能不好」這個現象的直接原因，而不是那些不痛不癢的其他因素。
好比奧拓比奧迪跑得慢，最主要的問題在於發動機（不懂車，隨便一說），而不是奧拓車的外型不夠流線、輪胎抓地不夠好……
如果把精力放在改善外型、輪胎這些方面上，確實會讓奧拓變得更"快"，但是從原問題（比奧迪慢）上來看，這都是沒有意義的。
至於如何準確的定位出問題，針對問題又如何下手，這就是技術能力，只能依靠不斷的學習、長期的積累了。
不過依然存在一些比較科學的工作方法，可以讓你盡快的抓住重點。如在系統執行正常時採集乙份足夠完整的效能指標作為基準，當出現狀況時再次採集乙份相同的指標，對比其中的差異，從差異處入手。
經常見到這種人，一聽到資料庫慢，直接加大記憶體分配、加快取、加連線數、加大各種資源配置……典型的胡亂「調優」。
同乙個問題，可能可以從多個方面進行處理。
乙個慢sql，優化的方式可能是加個索引、繫結快取、改寫sql、表分割槽、甚至是公升級硬體。
資源爭用問題，既可以從配置層面進行優化、減小爭用發生的機率，又可以從程式的實現方式上做改變、從源頭上避免爭用。
假設多種處理方式，都可以滿足期望，那麼應該從哪個層面下手呢？
這就需要考慮到工作量、效果、隱患等多種因素，當然也不排除幾種優化共同作用。
這是乙個工作方法是否科學的問題。
每一次試驗，都需要能夠驗證是否有效。有效的保留，無效的則復原。
除了對原問題的驗證，還必須確認對其他部分是否產生了***。理論上這就需要在每一次調優嘗試後，進行一次足夠全面的複測。
否則，很容易出現「拆東牆補西牆」的問題。
記住以下幾個要點：
只有真正理解調優的目的，並按照科學的方法行動，你的努力才會體現出價值。
效能測試新手誤區（五） 這是效能問題麼
經常會見到新人提出這樣的效能問題 100使用者時，a操作響應時間達到了xx秒，請修改 場景執行2個小時後，系統沒有響應了 面對這樣的問題，開發人員一定會覺得很無助，他們甚至不知道問題是什麼。即使從測試人員的角度來看，這也算不上是乙個合格的問題。甚至是不是真正的問題，都要暫時打上問號。那麼乙個合格的效...
效能測試新手常犯錯誤總結（七） 你需要調優麼
測試人員喜歡在得到某個達不到預期的效能結果後，進行一下 調優 pm有時也會布置任務，測試完成後 調乙個優 一些人貌似有了這種觀念 調優才使效能測試有意義 效能測試的目的就是調優 做調優才能顯出測試人員的水平 隨著經驗的增長和對效能更深入的認識，我越來越體會到調優是乙個複雜的過程，不是動動嘴 改倆個引...
效能測試新手誤區（一）
系列原創 效能測試新手誤區 有過一些效能測試經驗的人很容易進入此狀態，他們已經熟悉了效能測試的基本流程，能夠比較熟練的使用測試工具開展工作。我大概從事效能測試一年左右時遇到了這個問題，那時我覺得效能測試的過程沒有太多挑戰，遇到的每乙個系統，彷彿都可以用同樣的流程完成。半天時間填寫測試方案，一天時間來...