有同學私信我，說想付費讓我教他學習性能測試，問我能不能三個月內把性能測試包括全鏈路壓測都熟練掌握，老實說，這要求把我難住了。和他聊了聊關于性能測試的一些話題，發現他對性能測試的理解走入了一些誤區。

在一些技術交流群，同樣遇到過很多同學由于對性能測試理解上的誤區導致的各種問題，比如：

• 注冊用戶數=并發數，然后服務直接被打崩了；
• 直接在生產環境壓測：生產服務掛了，客戶投訴；

當然，這些都是比較基礎的問題，剛入門的同學可能會犯這種錯。如果有一定的項目實踐經驗，就會了解性能測試比我們想象的要復雜得多。除了對技術的廣度和深度有一定要求之外，對業務的熟悉程度，對需求和場景的分析理解能力，甚至在壓測實施過程中的溝通和協調能力，也有一定要的要求。

這篇文章，聊聊和性能測試相關的話題，它的實施目的、在不同場景下的側重點以及一些被大家忽視的點。

性能測試的目的

首先要認識到一點，拋開性能測試涉及到的技術棧，其實性能測試的本質和功能測試沒什么區別。同樣需要需求分析、場景設計、準備測試用例和測試數據。功能測試是手動執行用例，觀察結果，性能測試則大多是借助工具或者腳本來執行測試用例觀察結果。

功能測試的目的是驗證產品設計的功能正確性，找到功能上和設計不符的bug；性能測試則是找到應用服務處理能力存在的瓶頸，然后針對性的優化，為線上的容量規劃和服務穩定性提供支撐。那么問題來了：如何定義所謂的處理能力瓶頸？這就需要錨定業務價值了。

性能測試的需求基本來自業務，比如用戶反饋APP響應太慢、財務或成本部門反映IT的硬件成本太高，或者運營活動由于系統掛了導致業務目標未達成。這些問題歸類來說，都是用戶和業務的痛點訴求：

• APP響應太慢：提升處理速度——降低響應時間(RT)；
• 硬件成本太高：降低硬件成本——提升單位資源的處理能力(TPS)；
• 業務目標未達成：提升系統穩定性——提高業務成功率(99%-99.99%)；

總結一下就是：降低成本、提升用戶體驗、保障業務目標達成，這就是所謂的業務價值！

性能測試的最終目的和功能測試本質上沒區別，就是為用戶提供正確穩定的服務和良好的用戶體驗，保障業務目標達成。為了滿足用戶和業務的訴求而采用的一系列技術方案，都是為了達成這個目的的手段而已。

不同項目側重點

聊完了性能測試的目的，接著回到具體的項目實踐中。日常工作中最常見的項目類型，大概可以分為如下幾種：

版本迭代

版本迭代算是軟件工程師的工作日常了，這種類型的項目中，性能測試主要的側重點聚焦在系統的處理能力方面。即驗證系統是否由于需求迭代&新的代碼引入而導致了系統處理能力下降，主要關注的指標是TPS&99RT&請求成功率等方面。從體系建設的角度來說，可以通過建立性能基線來評估系統長期的性能質量。

配置變更

我們都知道很多的線上故障是變更引起的，但其實很多時候性能的變化，可能就是一個小小的參數變更導致的。細分的話性能測試場景中有一項叫做配置測試，就是為了驗證由于系統各項參數或者服務配置的變化而帶來的性能變化。常見的有下面兩種：

• 軟件參數變更：比如線程池連接數、超時時間等；
• 硬件配置變更：比如服務器升配降配帶來的性能變化對比；

這種配置變更帶來的性能變化，更關注的是中間件和基礎服務層面，因為這種變更往往容易被忽略，但這種變更又會對線上服務的性能和穩定性帶來很大的影響。

新服務上線

在日常的版本迭代之外，還比較常見的是新服務上線這種項目。比如技術改造、服務拆分、引入新的服務供應商等，一般都需要進行性能測試來驗證是否會對已有系統造成影響。

新服務上線進行性能測試的主要目的是驗證系統的健壯性，即發現一些較為明顯的性能問題，比如：內存泄漏、業務超賣、死鎖、慢SQL等情況。

穩定性保障

大部分的性能測試都是在線下環境開展的，但性能測試的結果一定要對線上的容量規劃和穩定性保障提供支撐，否則性能測試沒有太多價值。

雖然已經2023年了，生產全鏈路壓測提出到現在也快11年了，但截至目前大多數公司還是不具備在生產環境進行性能測試的能力，其中原因很多。比如生產環境開展壓測成本高風險大，比如大部分公司并沒有很高的并發訪問量，比如技術建設和儲備不夠深，究其根本原因，其實就是投入和產出的平衡問題。

當然，技術如何創造業務價值是一個很復雜的問題，但有一個關于全鏈路壓測的誤區，也是很多人忽視的。

生產全鏈路壓測只適合某一部分具有特定業務需求的公司，能否實施取決于是否有合適的組織管理能力和對應的技術架構。生產全鏈路壓測并不是銀彈，也不單單只是一種測試的技術手段，如果將生產全鏈路壓測看作一種促進生產服務穩定性的技術實踐，那它有很多可以挖掘的價值點。但在實際落地過程中，只能說對技術的理解和對業務價值的認知，大家都好像走入了誤區。

場景建模的誤區

經常有同學問：我能不能一個用戶的數據拿來重復壓測，反正也是并發請求的。

在功能測試中，我們會根據要測試的場景和測試用例，準備對應的符合場景的測試數據，為什么性能測試的時候反而忽視了呢？這其實也是一個認知誤區：性能測試就是模擬高并發給系統發請求。

正確的做法是和功能測試類似的，建立業務模型&流量模型&數據模型之間的映射關系，準備對應的符合測試場景的測試數據，并且要保證數據量足夠測試使用。