我的效能測試工作流程

1、須透過功能測試

效能測試是基於現狀的調優，未透過功能測試情況下，沒有參考意義。每一次開始效能測試都應該先進行功能測試。

2、圍繞問題做簡單建模

瞭解問題的流程上的大致節點，根據設計文件 (需求文件/開發文件) 或是程式碼估算每個節點的時間複雜度，在實際測試中，可以以此來參考，發現問題節點。如果遇到問題節點，才去對問題節點做進一步解析。

3、得出測試鏈路測試

一般而言效能測試都有業務導向，他們都會基於簡單的目的，功能在壓力下使用依舊流暢或者是可用。如支援10萬人同時下單，可能你無法從產品口中得到10w這種準確的指標，但是你可以很容易的得出下單的這個需求，而具體合適的效能指標，可以透過同行經驗，或是已有的資料，進行資料分析得出。如果是全新的體系，則需要摸索中得出了 (就好像傳統的介面會以響應時間作為指標，如今文字類的大模型，可以將每秒生成多少 token 作為自己的指標一樣)

但是你可能會遇到異常業務流程比正常業務流程的耗時更長的問題。如果你沒有線上資料 (埋點和記錄明細) 支援，我建議你都進行測試，避免意外。如果不是的情況下，完成正常業務流程的測試即可。

在上面的舉例中，瀏覽 -> 詳情 -> 選sku -> 瀏覽的流程，比直接下單的時間複雜度要高。這也和我們的實操很相符，花時間去選購商品，或者對常購商品的直接購買。於是在上面的估算中得出了兩條鏈路。

4、進行梯度壓力測試

不同的壓力對應不同的能力，在實測中記錄表現。得出效能拐點。

5、效能最佳化

引起這個問題一般有兩個原因，未達到明確的效能要求，未達到行業要求。最佳化時要先檢驗設計和實際實施是否有出入 (索引沒建、索引失效、快取失效)，如有出入則修改後二次測試，直至實施達到設計。如無出入，考慮最佳化方案，提高能力。

6、設計餘量

為抵抗流量激增帶來的風險，設計餘量有助於我們抵抗一些特殊場景。如實際測試為 10tps。7tps 則是合適的值。同時也可以為監控提供參考，預防突然死亡

7、擴充套件方案設計

系統支援橫向或縱向擴充套件，以應對餘量不足時，可直接透過擴充套件解決問題，如直接新增伺服器，磁碟更換 (提高 IO)， 新增硬碟 (攤分 IO)。而此類擴充套件本身在正常情況下，能多支援 90% 或以上的壓力