軟體測驗回顧(8)

性能測驗，七個主題，完善性能測驗知識體系

• 軟體測驗回顧(8)
  • 28章：軟體性能與性能指標
    • 終端用戶眼中的軟體性能
    • 系統運維人員眼中的軟體性能
    • 軟體設計開發人員眼中的軟體性能
    • 性能測驗人員眼中的軟體性能
    • 衡量軟體性能的三個常用指標
      • 并發用戶數
      • 回應時間
      • 系統吞吐量
  • 29章：性能測驗基本方法
    • 1.并發用戶數、回應時間、系統吞吐量之間的關系
    • 2.常見7種性能測驗方法
      • 1.后端性能測驗
      • 2.前端性能測驗
      • 3.代碼級性能測驗
      • 4.壓力測驗
      • 5.配置測驗
      • 6.并發測驗
      • 7.可靠性測驗
    • 3.性能測驗的四大應用領域
  • 30章：后端性能測驗工具及原理
    • 1.后端性能測驗與后端性能測驗工具的關系
    • 2.后端性能測驗工具和GUI自動化測驗工具最大的區別
    • 3.后端性能測驗原理？
      • 名詞解釋：
    • 4.后端性能測驗場景設計會涉及哪些內容？
    • 5.后端主流性能壓測工具？
  • 31章：前端性能測驗工具及原理
    • WebPagetest
  • 32+33章：LoadRunner實戰
    • 階段一：性能需求收集及負載計劃制定
    • 階段二：錄制增強虛擬用戶腳本
      • 1.識別被測應用使用的協議
      • 2.錄制腳本
      • 3.完善錄制的腳本
        • 1.兩個事務之間的思考時間？
        • 2.輸入資料的引數化
        • 3.腳本關聯操作
        • 4.加入檢查點
      • 4.驗證腳本正確性
    • 階段三：創建并定義性能測驗場景
    • 階段四：執行性能測驗場景
    • 階段五：分析測驗報告
  • 34章：企業級性能測驗案例與經驗分享
    • 1.性能基準測驗
    • 2.穩定性測驗
    • 3.并發測驗
    • 4.容量規劃測驗
    • 1.性能測驗曲線模型
    • 2. 性能測驗流程
    • 測驗報告解讀

28章：軟體性能與性能指標

終端用戶眼中的軟體性能

• 系統回應時間
  • 應用系統處理時間
  • 資料庫處理時間
  • 網路傳輸時間
• 前端展現時間，取決于用戶端的處理能力，

系統運維人員眼中的軟體性能

大量用戶并發訪問時的負載，以及可能的更大負載情況下的系統健康狀態、并發處理能力、當前部署的系統容量、可能的系統瓶頸、系統配置層面的調優、資料庫的調優，以及長時間運行穩定性和可擴展性，

系統運維人員必須在最大并發用戶數和系統回應時間之間進行權衡取舍，

目前，有些系統為了能夠承載更多的并發用戶，往往會犧牲等待時間而引入預期的等待機制，比如，火車票購票網站，就在處理極大并發用戶時采用了排隊機制，以盡可能提高系統容量，但卻增加了用戶實際感受到的回應時間，

軟體設計開發人員眼中的軟體性能

在軟體設計開發人員眼中，軟體性能通常會包含演算法設計、架構設計、性能最佳實踐、資料庫相關、軟體性能的可測驗性這五大方面，

• 演算法設計
  • 核心演算法的設計與實作是否高效
  • 設計上是否采用buffer機制以提高性能，降低I/O；
  • 是否存在潛在的記憶體泄露；
  • 是否存在不合理的資源競爭，
  • 是否存在并發環境下的執行緒安全問題
• 架構設計
  • 是否可以方便地進行系統容量和性能擴展；
  • 應用集群的可擴展性是否經過測驗和驗證；
  • 快取集群的可擴展性是否經過測驗和驗證；
  • 資料庫的可擴展性是否經過測驗和驗證，
• 性能最佳實踐
  • 代碼實作是否遵守開發語言的性能最佳實踐；
  • 關鍵代碼是否在白盒級別進行性能測驗；
  • 是否考慮前端性能的優化；
  • 必要的時候是否采用資料壓縮傳輸；
  • 對于既要壓縮又要加密的場景，是否采用先壓縮后加密的順序，
• 資料庫相關
  • 資料庫表設計是否高效；
  • 是否引入必要的索引；
  • SQL陳述句的執行計劃是否合理；
  • SQL陳述句除了功能是否要考慮性能要求；
  • 資料庫是否需要引入讀寫分離機制；
  • 系統冷啟動后，快取大量不命中的時候，資料庫承載的壓力是否超負荷，
• 軟體性能
  • 是否為性能分析（Profiler）提供必要的介面支持；
  • 是否支持高并發場景下的性能打點；
  • 是否支持全鏈路的性能分析，

性能測驗人員眼中的軟體性能

一個優秀的性能測驗工程師，一般需要具有以下技能：

• 性能需求的總結和抽象能力；
• 根據性能測驗目標，精準的性能測驗場景設計和計算能力；
• 性能測驗場景和性能測驗腳本的開發和執行能力；
• 測驗性能報告的分析解讀能力；
• 性能瓶頸的快速排查和定位能力；
• 性能測驗資料的設計和實作能力；
• 面對互聯網產品，全鏈路壓測的設計與執行能力，能夠和系統架構師一起處理流量標記、影子資料庫等的技術設計能力；
• 深入理解性能測驗工具的內部實作原理，當性能測驗工具有限制時，可以進行擴展二次開發；
• 極其寬廣的知識面，既要有“面”的知識，比如系統架構、存盤架構、網路架構等全域的知識，還要有大量“點”的知識積累，比如資料庫SQL陳述句的執行計劃調優、JVM垃圾回收（GC）機制、多執行緒常見問題等等，

衡量軟體性能的三個常用指標

并發用戶數、回應時間，以及系統吞吐量，

并發用戶數

并發用戶數，是性能需求與測驗最常用，也是最重要的指標之一，它包含了業務層面和后端服務器層面的兩層含義，

• 業務層面的并發用戶數，指的是實際使用系統的用戶總數，但是，單靠這個指標并不能反映系統實際承載的壓力，我們還要結合用戶行為模型才能得到系統實際承載的壓力，
• 后端服務器層面的并發用戶數，指的是“同時向服務器發送請求的數量”，直接反映了系統實際承載的壓力，

為了讓你更好地理解這兩層含義之間的區別，我們先一起來看一個實體：一個已經投入運行的ERP系統，該系統所在企業共有5000名員工并都擁有賬號，也就是說這個系統有5000個潛在用戶，

根據系統日志分析得知，該系統最大在線用戶數是2500人，那么從宏觀角度來看，2500就是這個系統的最大并發用戶數，但是，2500這個資料僅僅是說在最高峰時段有2500個用戶登錄了系統，而服務器所承受的壓力取決于登錄用戶的行為，所以它并不能準確表現服務器此時此刻正在承受的壓力，

假設在某一時間點上，這2500個用戶中，30%用戶處于頁面瀏覽狀態（對服務器沒有發起請求），20%用戶在填寫訂單（也沒有對服務器發起請求），5%用戶在遞交訂單，15%用戶在查詢訂單，而另外的30%用戶沒有進行任何操作，那么此時，這2500個“并發用戶”中真正對服務器產生壓力的只有500個用戶（（5%+15%）*2500=500），

在這個例子中，5000是最大的“系統潛在用戶數”，2500是最大的“業務并發用戶數”，500則是某個時間點上的“實際并發用戶數”，而此時這500個用戶同時執行業務操作所實際觸發的服務器端的所有呼叫，叫作“服務器并發請求數”，

從這個例子可以看出，在系統運行期間的某個時間點上，有一個指標叫作“同時向服務器發送請求的數量”，這個“同時向服務器發送請求的數量”就是服務器層面的并發用戶數，這個指標同時取決于業務并發用戶數和用戶行為模式，而且用戶行為模式占的比重較大，

因此，分析得到準確的用戶行為模式，是性能測驗中的關鍵一環，但，獲得精準的用戶行為模式，是除了獲取性能需求外，最困難的作業，

目前，獲取用戶行為模式的方法，主要分為兩種：

• 對于已經上線的系統來說，往往采用系統日志分析法獲取用戶行為統計和峰值并發量等重要資訊；
• 而對于未上線的全新系統來說，通常的做法是參考行業中類似系統的統計資訊來建模，然后分析，

回應時間

一般來講，回應時間反映了完成某個操作所需要的時間，其標準定義是“應用系統從請求發出開始，到客戶端接收到最后一個位元組資料所消耗的時間”，是用戶視角軟體性能的主要體現，

系統回應時間，又可以進一步劃分為Web服務器時間、應用服務器時間、資料庫時間，以及各服務器間通信的網路時間，

軟體的性能測驗一般更關注服務器端，但是，服務器端回應時間的概念非常清晰、直接，就是指從發出請求起到處理完成的時間

回應時間應該包含兩層含義：技術層面的標準定義和基于用戶主觀感受時間的定義，而在性能測驗程序中，我們應該使用哪個層面的含義將取決于性能測驗的型別，

對于軟體服務器端的性能測驗肯定要采用標準定義，而對于前端性能評估，則應該采用用戶主觀感受時間的定義，

系統吞吐量

系統吞吐量，是最能直接體現軟體系統負載承受能力的指標，所有對吞吐量的討論都必須以“單位時間”作為基本前提，

把“Throughput”翻譯成吞吐率更貼切，因為我們可以這樣理解：吞吐率=吞吐量/單位時間，但既然國內很多資料已經翻譯為了“吞吐量”，所以通常情況下我們不會刻意去區分吞吐量和吞吐率，統稱為吞吐量，

對性能測驗而言，通常用“Requests/Second”“Pages/Second”“Bytes/Second”來衡量吞吐量，當然，從業務的角度來講，吞吐量也可以用單位時間的業務處理數量來衡量，

• “Bytes/Second”和“Pages/Second”表示的吞吐量(考察系統層面或網路層面)，主要受網路設定、服務器架構、應用服務器制約；
• “Requests/Second”表示的吞吐量(考察HTTP或者業務層面)，主要受應用服務器和應用本身實作的制約，

這里需要特別注意的是：雖說吞吐量可以反映服務器承受負載的情況，但在不同并發用戶數的場景下，即使系統具有相近的吞吐量，但是得到的系統性能瓶頸也會相差甚遠，

比如，某個測驗場景中采用100個并發用戶，每個用戶每隔1秒發出一個Request，另外一個測驗場景采用1000個并發用戶，每個用戶每隔10秒發出一個Request，顯然這兩個場景具有相同的吞吐量, 都是100 Requests/second，但是兩種場景下的系統性能拐點肯定不同，因為，兩個場景所占用的資源是不同的，

這就要求性能測驗場景的指標，必然不是單個，需要根據實際情況組合并發用戶數、回應時間這兩個指標，

29章：性能測驗基本方法

1.并發用戶數、回應時間、系統吞吐量之間的關系

1. 當系統并發用戶數較少時，系統的吞吐量也低，系統處于空閑狀態，我們往往把這個階段稱為 “空閑區間”
2. 當系統整體負載并不是很大時，隨著系統并發用戶數的增長，系統的吞吐量也會隨之呈線性增長，我們往往把這個階段稱為 “線性增長區間”，
3. 隨著系統并發用戶數的進一步增長，系統的處理能力逐漸趨于飽和，因此每個用戶的回應時間會逐漸變長，相應地，系統的整體吞吐量并不會隨著并發用戶數的增長而繼續呈線性增長，我們往往把這個階段稱為系統的“拐點”，
4. 隨著系統并發用戶數的增長，系統處理能力達到過飽和狀態，此時，如果繼續增加并發用戶數，最終所有用戶的回應時間會變得無限長，相應地，系統的整體吞吐量會降為零，系統處于被壓垮的狀態，我們往往把這個階段稱為“過飽和區間”，

2.常見7種性能測驗方法

把常用的性能測驗方法分為七大類：后端性能測驗（Back-end Performance Test）、前端性能測驗（Front-end Performance Test）、代碼級性能測驗（Code-level Performance Test）、壓力測驗（Load/Stress Test）、配置測驗（Configuration Test）、并發測驗（Concurrence Test），以及可靠性測驗（Reliability Test）

1.后端性能測驗

是通過性能測驗工具模擬大量的并發用戶請求，然后獲取系統性能的各項指標，并且驗證各項指標是否符合預期的性能需求的測驗手段，

性能指標，除了包括并發用戶數、回應時間和系統吞吐量外，還應該包括各類資源的使用率，比如系統級別的CPU占用率、記憶體使用率、磁盤I/O和網路I/O等，再比如應用級別以及JVM級別的各類資源使用率指標等，

后端性能測驗的場景設計主要包括以下兩種方式：

• 基于性能需求目標的測驗驗證；
• 探索系統的容量，并驗證系統容量的可擴展性

2.前端性能測驗

前端性能關注的是瀏覽器端的頁面渲染時間、資源加載順序、請求數量、前端快取使用情況、資源壓縮等內容，希望借此找到頁面加載程序中比較耗時的操作和資源，然后進行有針對性的優化，最終達到優化終端用戶在瀏覽器端使用體驗的目的，

業界普遍采用的前端測驗方法，是雅虎（Yahoo）前端團隊總結的7大類35條前端優化規則，你可以通過雅虎網站查看這些規則，以及對各規則的詳細解讀，

• 減少http請求次數：
• 減少DNS查詢次數：
• 避免頁面跳轉：面跳轉相當于又打開一個新的頁面，耗費的時間就會比較長，所以要盡量避免使用頁面跳轉；
• 使用內容分發網路（CDN）：
• Gzip壓縮傳輸檔案：

3.代碼級性能測驗

是指在單元測驗階段就對代碼的時間性能和空間性能進行必要的測驗和評估，以防止底層代碼的效率問題在專案后期才被發現的尷尬，

如果你從事過性能測驗相關的作業，一定遇到過這樣的場景：系統級別的性能測驗發現一個操作的回應時間很長，然后你要花費很多時間去逐級排查，最后卻發現罪魁禍首是代碼中某個實作低效的底層演算法，這種自上而下的逐級排查定位的方法，效率通常都很低，代價也很高，

需要在專案早期，對一些關鍵演算法進行代碼級別的性能測驗，以防止此類在代碼層面就可以被發現的性能問題，遺留到最后的系統性能測驗階段才被發現，

碼級性能測驗并不存在嚴格意義上的測驗工具，通常的做法是：改造現有的單元測驗框架，

最常使用的改造方法是：

1. 將原本只會執行一次的單元測驗用例連續執行n次，這個n的取值范圍通常是2000~5000；
2. 統計執行n次的平均時間，如果這個平均時間比較長（也就是單次函式呼叫時間比較長）的話，比如已經達到了秒級，那么通常情況下這個被測函式的實作邏輯一定需要優化，

4.壓力測驗

壓力測驗，通常指的是后端壓力測驗，不斷對系統施加壓力，并驗證系統化處于或長期處于臨界飽和階段的穩定性以及性能指標，并試圖找到系統處于臨界狀態時的主要瓶頸點，所以，壓力測驗往往被用于系統容量規劃的測驗，

5.配置測驗

配置測驗，主要用于觀察系統在不同配置下的性能表現，通常使用后端性能測驗的方法：

6.并發測驗

并發測驗，指的是在同一時間，同時呼叫后端服務，期間觀察被呼叫服務在并發情況下的行為表現，旨在發現諸如資源競爭、資源死鎖之類的問題，

“集合點并發”：為了達到準確控制后端服務并發數的目的，我們需要讓某些并發用戶到達該集合點時，先處于等待狀態，直到參與該集合的全部并發用戶都到達時，再一起向后端服務發起請求，簡單地說，就是先到的并發用戶要等著，等所有并發用戶都到了以后，再集中向后端服務發起請求，

在實際專案中，我建議在要求的并發數上進行適當放大，比如要求的并發數是100，那我們集合點并發數可以設定為120，

7.可靠性測驗

可靠性測驗，是驗證系統在常規負載模式下長期運行的穩定性，雖然可靠性測驗在不同公司的叫法不同，但其本質就是通過長時間模擬真實的系統負載來發現系統潛在的記憶體泄漏、鏈接池回收等問題

真實環境下的實際負載，會有高峰和低谷的交替變化，我們會每12小時模擬一個高峰負載，兩個高峰負載中間會模擬一個低峰負載，依次回圈3-7天，形成一個類似于“波浪形”的系統測驗負載曲線，同樣地，可靠性測驗也會持續3-7天，

3.性能測驗的四大應用領域

• 能力驗證
• 能力規劃
• 性能調優
• 缺陷發現

30章：后端性能測驗工具及原理

1.后端性能測驗與后端性能測驗工具的關系

千萬不要簡單地把使用后端性能測驗工具等同于后端性能測驗，它只是后端性能測驗中的一個必要步驟而已，

完整的后端性能測驗應該包括性能需求獲取、性能場景設計、性能測驗腳本開發、性能場景實作、性能測驗執行、性能結果報告分析、性能優化和再驗證，

使用性能測驗工具獲得性能測驗報告只是性能測驗程序中的一個必要步驟而已，而得出報告的目的是讓性能測驗工程師去做進一步的分析，以得出最終結論，并給出性能優化的措施，

2.后端性能測驗工具和GUI自動化測驗工具最大的區別

• 模擬用戶行為的方式，
  • GUI：模擬的是用戶的界面操作
  • 性能：模擬的是用戶的客戶端與服務器之間的通信協議和資料
• 測驗的執行方式
  • GUI：單用戶執行并驗證功能結果
  • 性能：模擬大量的并發用戶

3.后端性能測驗原理？

名詞解釋：

1.我們把這些基于協議模擬用戶行為的腳本稱為虛擬用戶腳本，而把開發和產生這些腳本的工具稱為虛擬用戶腳本生成器，

2.我們把實際發起測驗負載的機器稱為壓力產生器，

3.有了多臺壓力產生器，那就需要一個專門的控制器來統一管理與協調這些壓力產生器，我們把這個專門的控制器稱為壓力控制器，

4.后端性能測驗工具需要監控應用服務器、資料庫服務器、訊息佇列服務器、快取服務器等各種資源的占用率，我們通常把完成監控和資料收集的模塊稱為系統監控器，

5.后端性能測驗工具通常能夠基于該報告生成各類指標的各種圖表，還能將多個指標關聯在一起進行綜合分析來找出各個指標之間的關聯性，我們把完成這部分作業的模塊稱為測驗結果分析器，

首先，后端性能測驗工具會基于客戶端與服務器端的通信協議，構建模擬業務操作的虛擬用戶腳本，

然后，開發完成了虛擬用戶腳本之后，后端性能測驗工具會以多執行緒或多行程的方式并發執行虛擬用戶腳本，來模擬大量并發用戶的同時訪問，從而對服務器施加測驗負載，

接著，在施加測驗負載的整個程序中，后端性能測驗工具除了需要監控和收集被測系統的各種性能資料以外，還需要監控被測系統各個服務器的各種軟硬體資源，

最后，測驗執行完成后，后端性能測驗工具會將系統監控器收集的所有資訊匯總為完整測驗報告，

4.后端性能測驗場景設計會涉及哪些內容？

• 并發數多少？
• 測驗剛開始時，以什么樣的速率來添加并發用戶？(爬坡的速度是多少？)
• 達到最大并發數維持多久？(保持多長時間？)
• 測驗結束，以什么樣的速率來減少并發用戶？(下坡的速度是多少？)
• 壓測需要包含的業務？各個業務操作的占比是多少？(需要壓測的業務流量占比)
• 一輪結束、間隔多久進行下一輪？
• 同一虛擬用戶，業務操作間隔多久？(思考時間)
• 需要監控被測服務器哪些指標？
• 出錯處理的方式是什么？
• 需要多少臺壓力發生器？

5.后端主流性能壓測工具？

LoadRunne 和JMeter

LoadRunner:

? 傳統軟體企業采用，(按照并發用戶數收費的，并發用戶數越高收費也越貴）

傳統軟體企業，需要測驗的并發用戶數并不會太高，通常是在幾百到十幾萬這個數量級，

LoadRunner對海量并發的測驗支持并不太好；

JMeter

? 互聯網企業的并發用戶請求數量很高，很多軟體都會達到百萬，甚至是千萬的級別，

? 開源的JMeter中，用戶完全可以根據需求進行擴展

31章：前端性能測驗工具及原理

WebPagetest

這塊我不做關注，略

32+33章：LoadRunner實戰

階段一：性能需求收集及負載計劃制定

• 系統整體的并發用戶數，比如，高峰時段會有10萬用戶同時在線；
• 并發用戶業務操作的分布情況，比如，20%的用戶在做登錄操作，30%的用戶在做訂單操作，其他50%的用戶在做搜索操作；
• 單一業務操作的用戶行為模式，比如，兩個操作之間的典型停留時間，完成同一業務的不同操作路徑等；
• 并發用戶高峰期的時間分布規律，比如，早上8點會有大量用戶登錄系統，晚上6點后用戶逐漸退出；
• 達到最高峰負載的時間長度，比如，并發用戶從0增長到10萬花費的總時間；
• …

獲取這些測驗需求時性能測驗中最難的兩個作業之一，另一個最難的作業是，測驗結果分析與性能問題定位，而其他類似性能測驗腳本開發、場景設計等作業看起來很有技術含量，但實際都是一些相對機械性的重復作業，

對于性能測驗設計人員來說，到底如何獲得這個明確的性能需求呢？

你可以采用80/20原則對高峰時段的用戶負載進行建模

性能測驗需求的定義與計劃非常復雜，牽涉到專案的方方面面，不可能通過閱讀一兩篇文章就快速掌握這一技能，需要不斷地沉淀在實戰中獲得的經驗，

從宏觀角度，我把整個性能測驗程序劃分成了五個階段：性能需求收集以及負載計劃制定、錄制并增強虛擬用戶腳本、創建并定義性能測驗場景、執行性能測驗場景，以及分析測驗報告，

在我看來，這五個階段最難的兩部分作業分別是：明確具體的性能測驗需求，以及測驗結果分析與性能問題定位，因為這兩部分作業，要大量依賴于測驗工程師的能力以及經驗積累，所以，就像一名優秀的醫生一樣，優秀的測驗工程師，需要在實際的工程專案中不斷積累和總結經驗，

階段二：錄制增強虛擬用戶腳本

LoadRunner開發虛擬用戶腳本主要包括以下四個步驟：

1. 識別被測應用使用的協議；
2. 錄制腳本；
3. 完善錄制得到的腳本；
4. 驗證腳本的正確性，

1.識別被測應用使用的協議

如果已經知道被測系統采用的協議，則可以跳過這個步驟，

2.錄制腳本

要將這些操作步驟在虛擬用戶腳本中封裝成“事務”（Transaction），

封裝為“事務”的目的是統計回應時間，因為LoadRunner中的回應時間都是以“事務”為單位的，

在錄制腳本的程序中，我強烈建議直接對發起后端呼叫的操作添加事務定義，而不要等到腳本生成后再添加，因為LoadRunner腳本的可讀性并不好，在錄制完的腳本中添加事務定義的難度會很大，

在錄制程序中，直接添加事務操作也很簡單，主要包括如下三步：

1. 在開始執行GUI操作前，先點擊圖2中的“事務開始”按鈕并填寫事務名稱；
2. 執行GUI操作；
3. 操作完成后，點擊圖2中的“事務結束”按鈕，

這樣你剛才執行GUI操作的腳本就會被lr_start_transaction(“事務名稱”)和lr_end_transaction(“事務名稱”，LR_AUTO)包圍起來，也就完成了添加事務的定義，

3.完善錄制的腳本

錄制的腳本不能直接使用，我們還需要對錄制的腳本做以下處理：

• 在兩個事務之間加入思考時間（Think Time）；
• 對界面輸入的資料做引數化（Parameterization）操作；
• 完成腳本的關聯（Correlation）操作；
• 加入檢查點（Check Point），

1.兩個事務之間的思考時間？

思考時間：兩次發起請求之間往往會有一個時間的間隔，(了讓虛擬用戶腳本能夠更真實地模擬實際用戶的行為，我們就需要在兩個事務之間加入一定的等待時間，)

在實際專案中，一般先粗略估計一個值（比如15 s），然后在實際執行負載場景的程序中，再根據系統吞吐量調整，

調整思考時間時，無需逐行修改虛擬用戶腳本代碼，可以在Run-time Settings（運行時設定）中很方便地完成，

2.輸入資料的引數化

凡是引數檔案中使用的測驗資料都需要在執行性能測驗前，在被測系統中事先準備好

3.腳本關聯操作

關聯的主要作用是，取出前序呼叫回傳結果中的某些動態值，傳遞給后續的呼叫，

LoadRunner提供了功能強大的關聯函式web_reg_save_param()，這個關聯函式支持多種動態值的獲取方式，用得最多的是基于“前序字串匹配”加上“后續字串匹配”的方式，其中，字串匹配，支持正則運算式，

需要特別注意的是web_reg_save_param()函式是注冊型函式，必須放在獲取動態值所屬的請求前面，相當于先宣告，后呼叫，

4.加入檢查點

性能測驗腳本，不像功能測驗腳本那樣需要加入很多的斷言，往往只在一些關鍵步驟后加入很少量的檢查點即可，這些檢查點的主要作用是，保證腳本按照原本設計的路徑執行，

最常用的檢查點函式是web_reg_find()，它的作用是通過指定左右邊界的方式“在頁面中查找相應的內容”，

4.驗證腳本正確性

1. 以單用戶的方式，在有思考時間的情況下執行腳本，確保腳本能夠順利執行，并且驗證腳本行為以及執行結果是否正確；
2. 以單用戶的方式，在思考時間為零的情況下執行腳本，確保腳本能夠順利執行，并且驗證腳本行為以及執行結果是否正確；
3. 以并發用戶的方式，在有思考時間的情況下執行腳本，確保腳本能夠順利執行，并且驗證腳本行為以及執行結果是否正確；
4. 以并發用戶的方式，在思考時間為零的情況下執行腳本，確保腳本能夠順利執行，并且驗證腳本行為以及執行結果是否正確，

只有上述四個測驗全部通過，虛擬用戶腳本才算順利完成

階段三：創建并定義性能測驗場景

根據前面的測驗場景，進行圖形操作即可

階段四：執行性能測驗場景

點擊執行即可，還可以監控測驗執行的程序

階段五：分析測驗報告

性能測驗報告的解讀，需要豐富的系統架構、性能理論以及大量實戰經驗的積累，這個話題已經超出了我今天要分享的范圍，所以我也就不再繼續展開了，

這里有留言推薦 wrk測驗工具的，先記錄下來

34章：企業級性能測驗案例與經驗分享

• 性能基準測驗；
• 穩定性測驗；
• 并發測驗；
• 容量規劃測驗

1.性能基準測驗

性能基準測驗，通常被稱為Performance Benchmark Test，是每次對外發布產品版本前必須要完成的測驗型別，通過執行固定的性能測驗場景得到系統的性能測驗報告，然后與上一版本發布時的指標進行對比，如果發現指標有“惡化”的趨勢，就需要進一步排查，

惡化趨勢表現：

• 同一事務的回應時間變慢了
• 系統資源的占用率變高了
• 網路帶寬的使用量變高了，比如，上一版本中，發送總位元組數是20 MB，接收總位元組數是200 MB，但是在最新的被測版本中發送總位元組數變成了25 MB，接收總位元組數變成了250 MB，

以最常見的事務回應時間變慢為例，和你說明一下排查方法，

假設，通過性能基準測驗的比較結果得知，用戶登錄的回應時間從2 s變成了4 s，

1. 首先要做的是驗證在單用戶的情況下，是否會出現回應時間變長的問題.
   1. 將用戶登錄的虛擬用戶腳本單獨拿出來，建立一個單用戶運行的性能測驗場景并執行，觀察用戶登錄的回應時間是否變慢，
   2. 如果變慢了，就說明這是單用戶登錄場景就可重現的性能問題，后續的處理也相對簡單了，解決方法是：分析單用戶登錄的后端日志檔案，看看完成登錄操作的時間具體都花在了哪些步驟上，相比之前哪些步驟花費的時間變長了，或者是多出了哪些額外的步驟，
   3. 如果沒有變慢，則說明我們必須嘗試在有壓力的情況下重現這個性能問題，為此，我們要基于用戶登錄的虛擬用戶腳本構建并發測驗的場景，但是我們并不清楚在這個場景設計中到底應該采用多少并發用戶、加入多長的思考時間，這時，通常的做法是，直接采用性能基準測驗中的并發用戶數和思考時間，去嘗試重現問題，如果無法重現，我們可以適當地逐步加大測驗負載，并觀察回應時間的變化趨勢
   4. 這里需要注意的是，千萬不要使用過大的測驗負載，因為測驗負載過大的話，系統資源也會成為性能瓶頸，一定會使回應時間變長，但這時，回應時間變長主要是由資源瓶頸造成的，而不是你開始要找的那個原因，

通過對每個預發布版本的性能基準測驗，我們可以保證新發布系統的整體性能不會下降，這也就是性能基準測驗最終要達到的目的，

從性能基準測驗的設計角度來看，你需要特別注意以下三點：

1. 性能基準測驗中虛擬用戶腳本的選擇以及配比，需要盡可能地匹配實際的負載情況；
2. 總體的負載設計不宜過高，通常被測系統的各類占用率指標需要控制在30%以內，盡量避免由于資源瓶頸引入的操作延時；
3. 每次性能基準測驗前，一般需要對系統資源以及網路資源做一輪快速的基準測驗，以保證每次被測環境的一致性，同時也要保證資料庫的資料量在同一個級別上，總之，你需要采用一切可能的手段，來確保多次性能基準測驗之間的環境一致性，

2.穩定性測驗

穩定性測驗，又稱可靠性測驗，主要是通過長時間（7*24小時）模擬被測系統的測驗負載，來觀察系統在長期運行程序中是否有潛在的問題，

穩定性測驗，通常直接采用性能基準測驗中的虛擬用戶腳本，但是性能測驗場景的設計和性能基準測驗場景會有很大不同：

一般是采用“波浪式”的測驗負載，比如先逐漸加大測驗負載，在高負載情況下持續10多個小時，然后再逐漸降低負載，這樣就構成了一個“波浪”，整個穩定性測驗將由很多個這樣的波浪連續組成，

穩定性測驗成功完成的標志，主要有以下三項：

• 系統資源的所有監控指標不存在“不可逆轉”的上升趨勢；
• 事務的回應時間不存在逐漸變慢的趨勢；
• 事務的錯誤率不超過1%，

由于穩定性測驗執行的時間成本很高，往往需要花費3~7天的時間，所以我們一般是在其他所有測驗都已經完成，并且所有問題都已經修復之后才開始穩定性測驗，

雖然很多時候，尤其是產品版本已經逐漸走向成熟期時，穩定性測驗并不會發現問題，但是千萬不要小看穩定性測驗帶來的價值，因為穩定性測驗一旦發現問題，那么這些問題都是很嚴重而且非常隱蔽的大問題，

3.并發測驗

并發測驗，是在高并發情況下驗證單一業務功能的正確性以及性能的測驗手段，

高并發測驗一般使用思考時間為零的虛擬用戶腳本來發起具有“集合點”的測驗，

并發測驗，往往被當作功能測驗的補充，主要用于發現諸如多執行緒、資源競爭、資源死鎖之類的錯誤，

加入“集合點”一般有兩種做法：

1. 在虛擬用戶腳本的錄制程序中直接添加；
2. 在虛擬用戶腳本中，通過加入lr_rendezvous()函式添加，

4.容量規劃測驗

容量規劃測驗，是為了完成容量規劃而設計執行的測驗，

容量規劃的主要目的是，解決當系統負載將要達到極限處理能力時，我們應該如何通過垂直擴展（增加單機的硬體資源）和水平擴展（增加集群中的機器數量）增加系統整體的負載處理能力的問題，

容量規劃測驗具體要怎么做呢？

使用性能基準測驗中的虛擬用戶腳本，以及各個業務操作腳本的百分比，壓測單機部署的被測系統，我們會采用人工的方式不斷增加測驗負載直到單機系統的吞吐量指標到達臨界值，由此就可以知道單臺機器的處理能力，

理論上講，整個集群的處理能力將等于單臺機器的處理能力乘以集群的機器數，但是實際情況并不是這樣，實際的集群整體處理能力一定小于這個值，但具體小多少就是要靠實際的測驗驗證了，

補充性能測驗工具wrk，goreplay

附上華為云的性能測驗策略與指標分析

1.性能測驗曲線模型

2. 性能測驗流程

測驗報告解讀

標籤：其他

上一篇：軟體測驗回顧(5)-GUI自動化測驗

下一篇：如何區分真大佬和偽大佬