效能測試之主要概念

標籤：style   http   io   color   os   使用   sp   for   資料   

什麼是軟體效能？：

      互動式系統：以使用者感受到的回應時間來描述系統的效能

      非互動式系統（銀行業務處理）：回應時間只系統對事件產生的響應所需要的時間

 

如何評價效能的好壞：

使用者視角：對於使用者，最終使用者而言評價系統的效能好壞只有一個字——“快“。終端使用者並不需要關心系統當前的狀態——即使系統這時正在處理著成千上萬的請求，對於使用者來說，由他所發出的這個請求是他唯一需要關心的，系統對使用者請求的響應速度決定了使用者對系統效能的評價。簡單點就是，使用者單擊一個按鈕，發出一條指令或是在web頁面上單擊一個串連考試，到應用系統把本次操作的結果以使用者能察覺的方式展示出來的過程所消耗的時間就是使用者對軟體效能的直觀印象。

系統的電訊廠商和開發商：期望的是能夠讓儘可能多的使用者在任意時刻都擁有最好的體驗，這就要確保系統能夠在同一時間內處理更多的使用者請求。系統的負載（並發使用者數）與輸送量（每秒事務數）、回應時間以及資源使用率（包括軟硬體資源）之間存在著一個“此消彼長”的關係。因此，從系統的電訊廠商和開發商的角度來看，所謂的“效能”是一個整體的概念，是系統的負載與輸送量、可接受的回應時間以及資源使用率之間的平衡。

好的系統意味著更大的最佳並發使用者數和最大並發使用者數。

另外，從系統的視角來看，所需要關注的還包括三個與“效能”有關的屬性：可靠性（Reliability），延展性（Scalability）和 可恢複性（Recoverability）

 

回應時間：

圖中是一個請求的回應時間的組成，包括

C1：使用者請求發出前在用戶端需要完成的預先處理所需要的時間；

C2：用戶端收到伺服器返回的響應後，對資料進行處理並呈現所需要的時間；

A1：Web/App Server 對請求進行處理所需要的時間；

A2：DB Server 對請求進行處理所需的時間；

A3：Web/App Server 對 DB Server 返回的結果進行處理所需的時間；

N1：請求由用戶端發出並達到Web/App Server 所需要的時間；

N2：如果需要進行資料庫相關的操作，由Web/App Server 將請求發送至DB Server 所需要的時間；

N3：DB Server 完成處理並將結果返回Web/App Server 所需的時間；

N4：Web/App Server 完成處理並將結果返回給用戶端所需的時間；

從使用者的角度來看，回應時間＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是從系統的角度來看，回應時間只包括(A1+A2+A3)+(N1+N2+N3+N4)。理解回應時間的組成可以協助我們通過對回應時間的分析來更好的識別和定位系統的效能瓶頸。

從使用者的角度看，所體會到的回應時間有主觀和客觀之分，客觀來說就是上面提到的從使用者操作開始到所有資料返回完成的整個耗時，主觀上說如果採用一種最佳化的資料呈現策略，當少部分資料返回之後就立馬將資料呈現在使用者面前，則使用者感受到的回應時間就會遠遠小於實際的實物回應時間。

對於一個web應用來說，回應時間的標準是2/5/10秒，而對於一個OA系統，每次可能只使用一次該系統，當點擊提交時就算系統在20分鐘後才響應，使用者仍然不會覺得不能接受。所以合理的回應時間取決於實際的使用者需求。

 

輸送量：

單位時間內系統處理的客戶請求的數量。在web系統中主要以請求數（單擊數）/秒、頁面數/秒來體現。

1. 使用者協助設計效能測試情境，以及衡量效能測試情境是否達到了預期的設計目標：在設計效能測試情境時，輸送量可被使用者協助設計效能測試情境，根據估算的輸送量資料，可以對應到測試情境的事務發生頻率，事務發生次數等；另外，在測試完成後，根據實際的輸送量可以衡量測試是否達到了預期的目標。

2. 用於協助分析效能瓶頸：輸送量的限制是效能瓶頸的一種重要表現形式，因此，有針對性地對輸送量設計測試，可以協助儘快定位到效能冰晶所在位置。

?

並發使用者數 ≠ 每秒請求數：

簡單說，當你在效能測試工具或者指令碼中設定了100並發使用者數後，並不能期望著一定會有每秒100個請求發給伺服器。事實上，對於一個虛擬使用者來說，每秒發出多少請求只跟伺服器返迴響應的速度有關。如果虛擬使用者在0.5秒內就收到了響應，那麼它會立即發出第二個請求；而如果要一直等待3秒才能得到響應，它將會一直等到收到響應後才發出第二個請求。也就是說，並發使用者數的設定只是保證伺服器在任一時刻都有100個請求需要處理，而並不一定是保證每秒中發送100個請求給伺服器。

所以，只有當回應時間恰好是1秒時，並發使用者數才會等於每秒請求數；否則，每秒請求數可能大於並發使用者數或小於並發使用者數。

並發使用者數取決於具體的業務情境，它體現的時伺服器端承受的最大並發訪問數。

 

舉個例子：

一個系統有2000使用者（系統使用者數），最高峰時有500人線上（同時線上人數），那麼系統的並發使用者數呢？

500是整個系統使用時最大的業務並發使用者數，並不表示伺服器實際承受的壓力，這與具體的使用者訪問模式有關。例如這500人中，有40%在看公告，20%在填寫表格（表格只有在點擊提交時才會對伺服器產生負擔），20%在發獃，20%在切換頁面，這種情況下只有20%的使用者真正的對伺服器構成了壓力。

 

效能計數器：

描述伺服器或作業系統效能的一些資料指標，在performance test中發揮這監控和分析的關鍵作用。

 

效能測試包括：

驗收效能測試（acceptance performance testing）

負載測試（load testing）

壓力測試（stress testing）

配置測試（configuration testing）

並發測試（concurrency testing）

可靠性測試（reliability testing）

失敗恢複測試（failure testing）

 

對效能測試的一點理解：

        效能測試重要的一點在於對需求的理解，如果沒有正確的理解需求，而充忙的去搭建環境，配置資訊，最後得到的會是不正確的測試結果。而往往一些使用者或者客戶並不十分明確對效能的要求，他們只會給出一個寬泛的表示，那麼這時就需要我們自己去尋找需求，從要求中提煉出準確的需求。明確了需求之後才好進行下一部的操作。當然在這之前對於效能測試的主要內容需要掌握，效能的知識點也不是很多，重要的是在實踐中的領悟，效能測試並不是功能測試，它是從一個系統，站在更大的立場上去宏觀的把握產品，去對系統進行測試，但是並不代表在功能測試的同時不能進行效能測試。效能的要求也會更高，需要瞭解的知識會更多，對系統的架構要有一定的熟悉度。所以想要真正做好效能測試，任重而道遠。加油！

效能測試之主要概念