效能測試概述

效能測試主要內容

效能測試是透過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。透過負載測試，確定在各種工作負載下系統的效能，目標是測試當負載逐漸增加時，系統各項效能指標的變化情況。壓力測試是透過確定一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。

效能測試在軟體的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟體評測中心將效能測試概括為三個方面：應用在客戶端效能的測試、應用在網路上效能的測試和應用在伺服器端效能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統效能全面的分析和瓶頸的預測。

效能測試的目的

效能測試目的是驗證軟體系統是否能夠達到使用者提出的效能指標，同時發現軟體系統中存在的效能瓶頸，最佳化軟體，最後起到最佳化系統的目的。

包括以下幾個方面

1．評估系統的能力，測試中得到的負荷和響應時間資料可以被用於驗證所計劃的模型的能力，並幫助做出決策。

2．識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，並突破它，從而修復體系的瓶頸或薄弱的地方。

3．系統調優：重複執行測試，驗證調整系統的活動得到了預期的結果，從而改進效能。

檢測軟體中的問題：長時間的測試執行可導致程式發生由於記憶體洩露引起的失敗，揭示程式中的隱含的問題或衝突。

4．驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。

效能

測試的方法

1、效能測試（performance testing）：它是一種我們常見的一種方法，它是透過模擬生產執行的業務壓力量和使用場景組合，測試系統的效能是否滿足生產效能的要求。簡單地說就是要在特定的執行條件下驗證體系統的能力狀況。

這種方法的主要特點有：

1） 這種方法的主要目的是驗證系統是否有系統說明具有的能力

2） 這種方法需要事先了解被測試系統典型場景，並具有確定的效能目標

3） 這種方法要求在已確定的環境下執行

2、負載測試(load testing)：有時被叫做可量性測試，它主要是透過在被測系統上不斷增加壓力，直到效能達到預定目標或者資源達到飽和狀態。它可以找到體系統的處理能力的極限，為系統調優提供資料。

它的主要特點有

1）它的主要目的是找到系統處理能力的極限

2） 需要在給定的測試環境下進行，也需要考慮被測試體系統的業務壓力量和典型場景，使得測試結果具有業務上的意義

3） 一般用來了解系統的效能容量，或是配合效能調優來使用。

3、、 壓力測試 (stress testing) ：這種方法測試系統在一定飽和狀態下，系統能夠處理的會話能力，以及體系學統是否會出現錯誤。

這種效能測試方法具有以下特點

1) 它的主要目的是檢查系統處於壓力情況下時，應用的表現

2) 一般透過模擬負載等方法，使得系統的資源使用達到較高的水平

3) 一般用於測試系統的穩定性

4、併發測試（concurrency testing）：透過模擬使用者的併發訪問，測試多使用者併發訪問同一個應用、同一模組或者資料記錄時是否存在死鎖或者其它效能的問題

1）主要目的是發現系統中可能隱藏的併發訪問時的問題

2）主要關注系統可能存在的併發問題，例如系統中的記憶體洩漏、死鎖等方面的問題

3）這種方法可以在開發的各個階段使用，需要相關的測試工具的配合和支援

WEB效能測試目標

目標	說明
度量終端使用者響應時間	完成一個業務流程需要多長時間
度量系統容量	在沒有顯著效能下降的前提下，系統能夠處理多大的負載
確定瓶頸	哪些因素會延長響應時間

注：據中國IT實驗室調查，平均響應時間在2秒以內的網頁吸引力是最大的；平均響應時間在5秒以內的為可接受；平均響應時間在10秒以上的為煩躁型（即使用者不可接收型）。

效能測試流程

效能測試流程

第一，分析產品結構，明確效能測試的需求，包括併發、極限的效能要求。

第二，分析應用場景和使用者資料，細分使用者行為和相關的資料流，確定測試點或測試介面，列示系統介面的可能瓶頸，一般是先主幹介面再支線介面，並完成初步的測試用例設計。

第三，依據效能測試需求和確定的測試點進行測試用例設計，並明確不同測試方案的重要程度或優先順序作為取捨評估的依據，必要時在前期產品設計中提出支援效能測試的可測試性設計方案和對測試工具的需求。

第四，完成效能測試用例設計、分類選擇和依據使用者行為分析設計測試規程，並準備好測試用例將用到的測試資料。

第五，確定採用的測試工具。

第六，進行初驗測試，根據測試結果分析效能瓶頸，透過迭代保證基本的指標等測試的環境。

第七，迭代進行全面的效能測試，完成計劃中的效能測試用例的執行。

第八，完成效能測試評估報告。

效能測試結果的分析流程

具體問題具體分析（這是由於不同的應用系統，不同的測試目的，不同的效能關注點）

• 查詢瓶頸時按以下順序，由易到難。

伺服器硬體瓶頸-〉網路瓶頸（對區域網，可以不考慮）-〉伺服器作業系統瓶頸（引數配置）-〉中介軟體瓶頸（引數配置，資料庫，web伺服器等）-〉應用瓶頸（SQL語句、資料庫設計、業務邏輯、演算法等）

注：以上過程並不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（併發使用者數、資料量）下，系統的瓶頸在哪兒就夠了。

分析的資訊來源：

•1 根據場景執行過程中的錯誤提示資訊

•2 根據測試結果收集到的監控指標資料

設計效能測試用例的原則

設計效能測試用例注意的原則：

可以滿足預期效能指標測試用例要求的，就沒有必要設計更多的內容，因為用例越多，執行的本也越高。

一定要服從整體效能測試策略，千萬不能僅從技術角度來考慮設計“全面”的測試用例，“全面”應該以是否滿足自己的測試要求作為標準。

只有根據實際專案的特點制定合理的效能測試策略、編寫適當的效能測試用例，並在測試實施中靈活地變通才可以做好效能測試工作。

效能測試輸出文件：

測試計劃：主要包含測試範圍、測試環境、測試方案簡介、風險分析等，測試計劃要進行評審後方可生效。

測試報告：主要包含測試過程記錄、測試分析結果、系統調整建議等。

測試經驗總結：不斷總結工作經驗是建立學習型團隊的基礎，實踐－總結－再實踐

參考文件

效能測試術語及縮寫詞

測試時間 ：一輪測試從開始到結束所使用的時間

併發執行緒數 ：測試時同時訪問被測系統的執行緒數。注意，由於測試過程中，每個執行緒都是以儘可能快的速度發請求，與實際使用者的使用有極大差別，所以，此資料不等同於實際使用時的併發使用者數。

每次時間間隔 ：測試執行緒發出一個請求，並得到被測系統的響應後，間隔多少時間發出下一次請求。

平均響應時間 ：測試執行緒向被測系統發請求，所有請求的響應時間的平均值。

處理能力 ：在某一特定環境下，系統處理請求的速度。

cache影響係數：測試資料未必如實際使用時分散，cache在測試過程中會比實際使用時發揮更大作用，從而使測試出的最高處理能力偏高，考慮到這個因素而引入的係數。

使用者習慣操作頻率：根據使用者使用習慣估算出來的，單個使用者在一段時間內，使用此類功能的次數。通常以一天內某段固定的高峰使用時間來統計，如果一天內沒有哪段時間是固定的高峰使用時間，則以一天的工作時間來統計。

預期平均響應時間 ：由使用者提出的，希望系統在多長時間內響應。注意，這個值並不是某一次訪問的時間，而是一段時間多次訪問後的平均值。

最大併發使用者數 ：在給定的預期平均響應時間下，系統最多能支援多少個併發使用者。這個資料就是實際可以同時使用系統的使用者數。

併發 ：狹義的併發一般分兩種情況。一種是嚴格意義上的併發，即所有使用者在同一時刻做同一件事情或操作，這種操作一般針對同一型別的業務。另一種併發是廣義的併發。這種併發與狹義的併發的區別是儘管多個使用者對系統發出了請求或進行了操作，但是這些請求或操作可以是相同的，也可以是不同的。對整體系統而言，任然有很多使用者同時對系統進行操作，因此，仍然屬於併發的範疇。

可以看出，廣義的併發是包含狹義的併發的，而且廣義的併發更接近使用者的實際使用情況，因為對大多數系統而言，只有數量很少的使用者進行“嚴格意義上的併發”。對於效能測試而言，這兩種併發一般都需要進行測試，通常的做法是先進行嚴格意義上的併發測試。嚴格意義上的併發一般發生在使用比較頻繁的模組中，儘管發生的機率不是特別高，但是一旦發生效能問題，後果很可能是致命的。嚴格意義上的併發測試往往和功能測試關聯起來，因為只要併發功能遇到異常通常都是程式的問題，這種測試也是健壯性和穩定性測試的一部分。

併發使用者數量 ：關於併發使用者數量，有兩種常見的錯誤觀點。一種錯誤觀點是把併發使用者數量理解為使用系統的全部使用者的數量，理由是這些使用者可能同時使用系統；還有一種比較接近正確的觀點是把使用者線上數量理解為併發使用者數量。實際上，線上使用者不一定會和其他使用者發生併發，例如正在瀏覽網頁資訊的使用者，對伺服器是沒有任何影響的。但是，使用者線上數量是統計併發使用者數量的主要依據之一。

併發主要針對伺服器而言，是否併發的關鍵是看使用者的操作是否對伺服器產生了影響。因此，併發使用者數量的正確理解是，在同一時刻與伺服器進行互動的線上使用者數量。這些使用者的最大特徵是和伺服器發生了互動，這種互動既可以是單向傳送資料的，也可以是雙向傳送資料的。

併發使用者數量的統計方法目前還沒有準確的公式，因為不同的系統會有不同的併發特點。例如OA系統統計併發使用者的經驗公式為：使用系統的使用者數量*（5%~20%）。對於這個公式，沒有必要拘泥於計算出的結果，因為為了保證系統的擴充套件空間，測試時的併發使用者數量就會稍稍大一些，除非要測試系統能承受的最大併發使用者數量。舉例說明：如果一個OA系統的期望使用者為1000個，只要測試出系統能支援200個併發使用者就可以了。

請求響應時間：請求響應時間是指從客戶端發出請求到得到響應的整個過程的時間。這個過程從客戶端發出一個請求開始計時，到客戶端接收到從伺服器端返回的響應結果計時結束。在某些工具中，請求響應時間通常會被稱為"TTLB"，即"Time to last byte"，意思是從傳送一個請求開始，到客戶端接收到最後一個位元組的響應為止所耗費的時間。請求響應時間的單位一般為“秒”或“毫秒”。

事物響應時間 ：事物可能由一系列請求組成，事物的響應時間主要針對使用者而言，屬於宏觀上的概念，是為了向使用者說明業務響應時間而提出來的。例如：跨行取款食物的響應時間就是由一系列的請求組成的。事物響應時間和業務吞吐率都是直接衡量系統效能的引數。

吞吐量：指在一次效能測試過程中網路上傳輸的資料量的總和。吞吐量/傳輸時間，就是吞吐率。

吞吐率（ Throughput ） ：通常用來指單位時間內網路上傳輸的資料量，也可以指單位時間內處理的客戶端請求數量。是衡量網路效能的重要指標。

但是從使用者或業務角度來看，吞吐率也可以用“請求數/秒”或“頁面數/秒”、“業務數/小時或天”、“訪問人數/天”、“頁面訪問量/天”來衡量。例如在銀行卡審批系統中，可以用“千件/每小時”來衡量系統的業務處理能力。

TPS（Transaction Per Second）：每秒鐘系統能夠處理的交易或事物的數量。它是衡量系統處理能力的重要指標。TPS是LoadRunner中重要的效能引數指標。

點選率（Hit Per Second） ：秒鐘使用者向Web伺服器提交的HTTP請求書。這個指標是Web應用特有的一個指標：Web應用是“請求-響應”模式，使用者發出一次申請，伺服器就要處理一次，所以“點選”是Web應用能夠處理交易的最小單位。如果把每次點選定義為一次交易，點選率和TPS就是一個概念。不難看出，點選率越大，對伺服器的壓力也越大。點選率只是一個效能參考指標，重要的是分析點選時產生的影響。

需要注意的是，這裡的點選不是指滑鼠的一次“單擊”操作，而是在一次“單擊”操作中，客戶端可能向伺服器發出多個HTTP請求。

資源利用率：資源利用率指的是對不同系統資源的使用程度，例如伺服器的CPU利用率、磁碟利用率等。資源利用率是分析系統效能指標而改善效能的主要依據，因此，它是Web效能測試工作的重點。

資源利用率主要針對Web伺服器、作業系統、資料庫伺服器、網路等，是測試和分析瓶頸的主要引數。在效能測試中，要根據需求採集具體的資源利用率引數來進行分析。

成功率＝成功次數÷（成功次數＋失敗次數）

處理能力＝成功次數÷測試時間

最短平均響應時間＝MIN（平均響應時間）

最高處理能力＝MAX（處理能力）×（1－cache影響係數）

最大併發使用者數＝（最高處理能力－1÷（預期平均響應時間－最短平均響應時間＋（1÷最高處理能力）））÷使用者習慣操作頻率

注：公式要注意各時間單位的不同和轉換