前幾天，分享了《一篇文章告訴你怎么做性能測試》一文，收到一些朋友的反饋；
有些朋友說，做性能，不需要了解業務邏輯，直接按接口文檔，或者抓包寫壓測接口的腳本，然后壓測、監控、分析、調優、回歸；
我覺得這樣的回答，可能是他們沒吃過不熟悉業務邏輯的虧；
最近壓測的時候，遇到一個等待鎖超時的問題，就是因為不熟悉業務邏輯造成設計的腳本不合理，下面和大家分享一下：
由於是臨時任務、時間緊迫、對應的開發又出差了，他遠程信誓旦旦給我說直接壓，根本不給我熟悉業務邏輯的機會，趕鴨子上架一樣；
請求參數用戶名是變化的，做了參數化，由於各種客觀因素，參數數據只准備了100個，參數取值策略是唯一、用完后循環；
當壓一會兒后，就會出現下面的錯：等待鎖超時
經過分析定位（過程暫時略過，本文重點是說明熟悉業務邏輯的重要性），問題的原因是如果相同用戶反復請求，會出現等待鎖超時，因為相同用戶從第二次請求開始，都是update操作，會鎖行數據，其余更新相同數據的請求就等待，最終出現超時，經和開發溝通，確實如此，且這種場景的概率是很低的，隨后協調資源，重新調整了壓測腳本的參數數據量，相同用戶只發送一次請求，重新壓測，未出現此問題；
所以，壓測前熟悉業務邏輯是非常有必要的，除了可以設計合理的性能腳本，還可以在分析定位的時候，方便我們定位代碼邏輯問題。