背景原因：
做系統服務壓測都是比較耗時耗人力的，特別是在生產環境上做壓測，壓測的時間都是在晚上 23 點後，甚至在凌晨 1-4 點，每次投入的人力成本較高（經常是晚上通宵加班壓測，疲憊感十足），對於團隊來說，每次大家都很辛苦，但是又不得不做，這是非常苦惱的煩心事。
為了緩解團隊每次投入做壓測的疲憊感，以及降低投入的人力成本，我們對現有的壓測流程做進一步的改善。現有的壓測模式：常態化壓測（例行壓測，摸底壓測）、大促全鏈路壓測，這兩種壓測模式的執行是根據現有業務發展而制定的，但都存在一定時效上的問題，且投入人力成本也不低。
為推進常態化壓測更高效，更貼近業務進行壓測，且分化所有業務流量的焦點集中在大促壓測上，把一些常規壓測操作前置到日常業務迭代需求專案上，根據中、大規模的需求專案試行迭代式壓測，提供更細緻、更小範圍的壓測方式，嘗試解決在壓測上的時效和人力問題。
0 1
壓測流程改進分析
1.以往的壓測模式，主要是常態化壓測為主，全鏈路壓測為輔，壓測時間段也只有特定的幾個時間段（618 大促，雙 11 大促等）才會安排。
2.每次壓測主要針對大促流量的效能指標上考慮，而各服務本身的每個環節存在的問題，等到全鏈路壓測的時候才暴露出來，往往已經滯後了很多（線上壓測存在的弊端）。
3.壓測的投入，雖然每次的壓測都能拿想要的結果，但是人力的成本和時效，並不是很理想。
4.服務間相互的調量大小，以及能承載多少請求，只有透過常態化壓測/全鏈路壓測才發現存在的問題，日常缺少沉澱，經常壓測過程會有超時、限流、熔斷等情況出現，導致壓測的有效性降低。
0 2
迭代式壓測流程
結合分析的方向，制定迭代式壓測流程如下：
結合公司現有的壓測流程，以及存在的不足問題綜合分析考慮，把現有的壓測流程做調整最佳化（降本增效），透過日常迭代專案上線後做壓測，即可做到貼合業務，以可滿足壓測需要，主要有以下 5 個方向改進：
壓測服務的穩定性
透過迭代專案上線後壓測，可以提前瞭解到服務本身的穩定性，是否有存在隱藏的問題。日常迭代需求較多，關聯依賴也多，上線後壓測可以快速瞭解影響範圍，及隱藏的效能問題，如有問題，可根據專案迭代，靈活安排最佳化版本上線。
壓測環境的穩定性
以往生產環境壓測，機器存在問題，經常是透過擴容/或更換機器的方式，臨時解決，並不能提前知道原因是什麼，處理結果相對是滯後的。透過日常迭代專案的壓測，可以提前暴露出在日常條件下生產環境機器是否存在問題，為大促壓測提前做規避措施。
壓測時效
快進快出，專案上線後，最小單位安排壓測任務，且主要以定時壓測為主，靈活壓測時間，第二天上班收集壓測報告，快速得出壓測結果。
壓測人員
● 降低產研發團隊 QA 的學習門檻，把壓測流程和壓測平臺做到足夠簡單
● 不再侷限於特定的幾個人才能做壓測，讓業務團隊每個 QA 都能有參與壓測的機會。
貼合業務
日常迭代專案，參與專案的成員，根據業務的特性評估是否壓測：
● 如不需要壓測，後續則降低/不考慮該業務場景對大促活動的影響面。
● 需要壓測，則評估影響面範圍：
後端重構專案，影響主流程業務
業務需求新增/變更，涉及有核心介面場景
核心業務場景調整
依賴服務介面變更
……
以專案維度評估壓測範圍比較小，能快速明確壓測的指標，以及壓測場景。
● 增加業務 QA 人員對壓測的參與度，同時讓個人在過程可以學習到相關效能測試的知識技能，可作為常態的測試手段。
● 剛好專案測試完，熟悉度還比較熱乎，花費最低成本去建立壓測指令碼和壓測資料，定時壓測完成後，得出結果進行分析的成本也比較低。
● 專案維度的壓測結果沉澱，對後續大促壓測場景規劃，提供更明確壓測範圍，以及可以提前規避掉服務存在的瓶頸問題。
0 3
全流程壓測模式演進
壓測流程流向
以小聚多，把迭代式壓測作為最小壓測單位，最後彙總為例行壓測（常態化壓測）、全鏈路壓測，保障各種鏈路維度覆蓋業務不同顆粒度。參考：常態化壓測 、全鏈路壓測
服務流量流向
0 4
壓測模式對比
0 5
迭代式壓測反饋效果
業務價值
2 月份開始以來，已完成幾個需求的壓測，壓測過程能明顯暴露出 6 個服務隱藏的效能問題，為業務服務規避掉隱藏的效能風險。
結果反饋
0 6
總結
● 業務團隊的 QA 人員需要具備一定的效能測試技能，學會識別專案需求中是否存在隱藏的效能風險；
● 以專案需求作為壓測單位，可能不會覆蓋到服務所有功能，但在日常迭代過程，迭代式壓測相對會比較頻繁，以點到面的切入條件，被壓測的功能也會逐步積少成多；
● 稀釋大促全鏈路壓測和常態化壓測準備及計劃的壓力，融入需求生命週期管理，輕量分散式的完成壓測資產沉澱。
更多內容可以進入個人主頁學習《測試工程師 Python 工具開發實戰》書籍、《大話效能測試 JMeter 實戰》書籍