軟件測試之性能測試

  • 2019 年 10 月 6 日
  • 筆記

性能測試是與時間相關的。

主要內容

  1. 性能測試基礎
  2. 概念和術語介紹
  3. 性能測試模型
  4. 性能測試分類介紹
  5. 性能測試實施與管理

性能測試基礎

為什麼要進行性能測試（WHY）（最重要）

  • 應用程序是否能夠很快的響應用戶的要求？
  • 應用程序是否能處理預期的用戶負載並有盈餘能力？
  • 應用程序是否能處理業務所需要的事務數量？
  • 在預期和非預期的用戶負載下，應用程序是否穩定？
  • 是否能夠確保用戶在真正使用軟件時獲得舒服的體驗？ 問題的根源一般是： 在多種平台上的數百個服務器；異構系統、多種應用；數千個工作站；局域網、廣域網和 其它分類型的分佈式網絡體系機構；交錯的故障點。 誤區：提高一下硬件配置就可以提高性能了，因此性能測試不重要？ 該說法是錯誤的。只能是臨時解決問題，而不能從根本上解決問題。

進行性能測試時，要關注什麼？（WHAT）

  • 並發用戶數、吞吐量
  • 平均響應時間
  • 服務器資源佔用情況
  • 可靠性、可擴展性
  • 發現引起系統問題的原因，關注採用何種技術提高系統性能
  • 軟、硬件配置是否合適（容量規劃、硬件選型）

誰來關注？（WHO）

  • 開發人員
    • 系統架構：架構是否合理？
    • 數據庫設計：數據庫設計是否存在問題？
    • 代碼：代碼是否存在性能問題？系統中是否存在不合理的內存使用方式？
    • 設計和代碼：系統中是否存在不合理的線程同步方式和不合理的資源競爭？
  • 系統管理人員
    • 資源利用率：應用服務器和數據庫使用狀況合理嗎？
    • 系統容量：系統最多能支持多少用戶的訪問？最大的業務處理量是多少？
    • 系統穩定性：系統能否支持7*24小時的業務訪問？
    • 系統可拓展性：系統能否實現拓展？系統性能可能的瓶頸在哪？
  • 用戶
    • 響應時間過長會是用戶煩躁不安（3/5/8）。
    • 系統穩定性：出現HTTP 500 錯誤或數據庫崩潰會讓用戶對系統失去信心。
  • 業務人員
    • 參數：如何向用戶提供參數，例如：支持多少用戶使用？響應時間是多少？
  • 測試人員
    • 以上都要關注
    • 能否發現系統中出現的瓶頸？
    • 能否真實有效的評估系統性能能力？

關注的領域主要是？（WHERE）

  • 能力驗證
    • 性能測試中最簡單也是最常用的一種。主要關心：在給定的條件下，系統能否具有預期的表現？
  • 規劃能力
    • 主要關心：應該如何才能使系統具有我們要求的性能能力？
  • 性能調優
    • 性能調優活動回合其他領域的活動交雜在一起。是一種在開發階段和測試階段都可能會涉及到的性能測試應用領域。
  • 發現缺陷 誤區： 性能測試獨立於功能測試 。 此說法是不對的。性能測試是依賴於功能測試。
    • 主要目的是：通過性能測試的手段來發現系統中存在的缺陷。

何時進行性能測試？（WHEN）

  • 一般在功能測試的中後期進行。

概念和術語介紹

性能測試是通過自動化的測試工具模擬各種正常、峰值以及異常負載條件來對系統的各項性能指標的測試。

做性能測試一般關注的性能指標是什麼？

並發數

  • 系統用戶數：該系統的註冊用戶數。例如，QQ有100個註冊用戶。
  • 在線用戶數：即登錄的用戶數。例如，100個人裏面有60個人為在線狀態。
  • 並發用戶數：是對服務器產生壓力的用戶。例如，這60個人裏面只有20個人在進行通信或其他操作。這20個人就是並發用戶數。 並發用戶數：同一時間進行同一操作的用戶數。

響應時間 又叫請求響應時間：TTLB 對請求做出響應所需要的時間一般為：

1

事務響應時間 事務是一組密切相關的操作組合。登錄就是一個事務。

每秒事務通過數 TPS是指每秒系統能夠處理的事務數。它是衡量系統處理能力的重要指標。 當壓力加大時，TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是服務器開始出現瓶頸了。如果環境沒有大的變化，對於同一系統會存在一個最大處理事務能力，它並不隨着並發用戶數的增減而改變。

點擊率 每秒點擊數代表用戶每秒向Web服務器提交的HTTP請求數。 點擊率越大，服務器壓力越大。

吞吐量 單位時間內系統處理的客戶請求的數量。（根據業務來說的）直接體現軟件系統的性能承載能力，一般來說用請求數或頁面數來衡量。

從業務角度，吞吐量也可以用訪問人數/天或是處理的業務數/小時來衡量； 從網絡角度，吞吐量可以用位元組/天來衡量。

思考時間 就是用戶兩個執行動作之間停留的時間。

資源利用率 不同系統資源的使用情況。CPU，網絡，磁盤，網絡。

性能測試模型

曲線拐點模型

總結：隨着並發用戶數的增加，吞吐量與資源利用率增加，說明系統在積極處理，所以響應時間增加的並不明顯，處於比較好的狀態。但隨着並發用戶數的持續增加，壓力也在持續加大，吞吐量與資源利用率都達到了飽和，隨後吞吐量急劇下降，造成響應時間急劇增長。輕壓力區與重壓力區的交界點是系統的最佳並發用戶數，因為各種資源都利用充分，響應也很快；而重壓力區與拐點區的交界點就是系統的最大並發用戶數，因為超過這個點，系統性能將會急劇下降甚至崩潰。

性能測試分類

基準測試、性能測試、負載測試、壓力測試、配置測試、並發測試、可靠性測試、失效恢複測試、大數據量測試

基準測試 有基礎的標準，這樣能通過對比發現系統的不同點與變化。 應用場景：

  1. 可以在制定的標準下通過基準測試建立一個性能基準，這樣以後當系統的環境、參數發生變化之後，再進行一次相同標準下的測試，即可看出變化對性能的影響。
  2. 系統進行基準測試可以在較早的階段發現性能問題。
  3. 某系統從來沒有進行任何性能測試，需要對該系統做一次性能評估作為後續開發調優的參考。

狹義性能測試 通過模擬生產運行的業務壓力和使用場景組合，測試系統的性能能否滿足生產系統要求。是一種常見的測試方法。

負載測試 負載測試是在被測系統上不斷增加壓力，直到性能極致。例如：響應時間已經超過預定指標或者某種資源使用已將達到飽和狀態。 主要目的是：找系統的負載極限，為系統調優提供數據。

壓力測試 壓力測試的目的是：找出高負載下系統的問題，例如資源競爭、同步問題、內存泄露等。

負載測試和壓力測試兩者可以結合進行。 負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加是，系統各項性能指標的變化情況。 壓力測試，是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。

配置測試 是通過被測系統的軟/硬件環境的調整，了解各種不同環境對系統性能影響的程度，從而找到各項資源的最有分配原則。

並發測試 是通過模擬用戶的並發訪問，測試多用戶並發訪問同一應用，同一模塊或者數據記錄時是否存在死鎖或者其他性能問題。

並發用戶數和並發數是不一樣的。

可靠性測試 是通過給系統加載一定的業務壓力的情況下，讓應用系統持續運行一段時間，測試系統在這種條件下是否能夠穩定運行。

失效恢複測試

  1. 失效恢複測試方法是針對有備份和負載均衡的系統設計的，這種測試方法可以用來檢驗如果系統局部發生故障， 用戶能否繼續使用系統，以及如果這種情況發生，用戶將受到多大程度的影響。
  2. 一般的關鍵業務系統都會採用熱備份或是負載均衡的方式來實現。這種業務系統一般要求有一台或幾台服務器出 現問題，應用系統仍然可以正常執行業務。該方法就是在測試中模擬設備故障，驗證預期的恢復技術是否可以正常發揮作用 。
  3. .不是所有的系統都需要進行這種類型的測試，尤其是並沒有明確給出系統需要持續運行指標的系統。

大數據量測試 有兩種類型：

  1. 獨立的數據量測試 針對某些系統存儲、傳輸、統計、查詢等業務進行大數據量測試。
  2. 綜合數據量測試 是和壓力測試、負載測試、並發測試、可靠性測試相結合的綜合測試方案。

各個測試類型的測試目的

  • 性能測試：能力驗證
  • 負載測試：規劃能力、性能調優
  • 壓力測試：能力驗證、規劃能力、性能調優、發現缺陷
  • 配置測試：規劃能力、性能調優
  • 並發測試：發現缺陷
  • 可靠性測試：能力驗證
  • 失效恢複測試：能力驗證、性能調優、發現缺陷

性能測試實施

性能測試的實施：

  • 前期準備（功能穩定、組件團隊）
  • 選擇工具（進行對於工具的培訓）
  • 性能測試方案（需求、計劃、方案、策略、資源）
  • 性能測試設計（準備環境—設計場景—編寫腳本—輔助工具）
  • 性能測試執行（執行腳本—記錄結果）
  • 性能調優與分析
  • 性能測試報告

性能測試前期準備

  1. 系統基礎功能驗證 確保當前需要進行測試的應用系統具備了進行性能測試的條件。 確保當前進行性能測試的應用系統版本已經穩定。
  2. 組建測試團隊 確定團隊內角色的構成，以及確定人員的技能。

測試工具

  1. 工具選擇 選擇項目適合的性能測試工具。Loadrunner。
  2. 工具應用技能培訓 為項目組的相關參與者進行測試工具的應用技能培訓，以使參與者能夠具備測試需要的技能 。
  3. 確認工具應用過程 確定測試工具在測試中的具體應用範圍，並不是「工具無所不能」，哪些工作使用工具完成，哪些無法使用工具完成 。

性能測試方案

  • 調研測試需求
    • 測試業務範圍
    • 測試環境：硬件環境、軟件環境、網絡環境
    • 測試目的
    • 性能指標：業務性能指標、系統性能指標
  • 測試策略和測試資源需求
    • 測試策略：測試工具、測試方式、測試執行
  • 性能測試計劃：即是如何實施性能測試，概括為以下5點：
  1. 編寫性能測試方案
  2. 測試環境準備： 應用軟件部署、檢查 數據庫基礎數據導入
  3. 測試腳本、測試數據 腳本參數化 腳本調試
  4. 測試執行 壓力測試、系統調優 負載測試
  5. 編寫性能測試報告

各種測試通用的實施步驟：需求—方案—代碼實現—執行—產出報告

性能測試設計

  1. 測試環境設計 性能測試的結果與測試環境之間的關聯性非常大，無論那種性能測試，都必須首先確定測試的環境，包括系統的 軟/硬件環境、數據庫環境等等 。
  2. 測試場景設計 測試場景模擬的一般是實際業務進行的一個剖面，其包括業務、業務比例、測試指標的目標、測試過程中需要監控 的性能計數器 。
  3. 測試用例的設計 對測試場景近一步細化，一般包括：測試類型、測試內容描述、前置條件、業務操作序列、參數化需求。驗證點等。
  4. 腳本和輔助工具開發

性能測試執行

  1. 建立測試環境
  2. 部署測試腳本和測試場景
  3. 執行測試和記錄結果

性能測試分析與調優

測試結果分析是最難的部分。是一個靈活的過程，每次性能測試結果的分析都需要測試分析人員具有相當程度的對 軟件性能、軟件架構和各種性能測試指標的了解，性能測試分析需要藉助各種圖表。 通用方法：拐點分析法。

性能測試報告

  1. 要測試的目標 本次性能測試預期要達到的性能要求。
  2. 測試概要描述 結構、時間、地點、人員、工具、環境、測試過程簡介
  3. 測試結果和數據
  4. 測試結論

本文轉自：https://blog.csdn.net/bit666888/article/details/81746538

VirMach 便宜 VPS

QNews

QNews