性能測試基本理論 -1

1、初步概念

一、功能測試：測試產品的功能是否達到要求

二、性能測試：測試產品的性能是否達到要求。（性能的要求高於功能的要求）

 

市場招聘的需求主要有兩方面：

   A、功能測試（手工、自動化）

   B、性能測試（自能經過工具）待遇高於功能自動化，要求比功能高，好比須要查找產品慢的緣由：網絡、服務器、中間件、數據庫等層面問題

 

2、性能測試的課程安排：

一、性能測試的基本概念 ---- 性能測試概念（1天）

對性能測試要求比較高的行業：通信、櫻花、金融、證券、保險、百度、谷歌等系統

對性能要求比較低的：OA辦公自動化

 

二、性能測試的工具部分-- LoadRunner   (全球至少一半以上的性能，使用LoadRunner)

1) LoadRunner的初級部分 -- 三大組件的簡單運行

a、腳本生成器：調代碼、腳本的地方

b、控制檯：比如指揮部

c、結果分析器：好比，每隔三秒鐘出一個結果，分析海量的結果，還能夠繼續的分析。

 

2) LoadRunner的高級部分 -- 三大組件逐個深刻掌握。

3）性能測試的高級部分 ：性能測試工程中，遇到問題（瓶頸），如何查找、定性，進行性能調優。

 

 

LR   HP官網下載   大概4G 免費    問題：用戶數有限  單用戶等

    多個用戶，須要買Licence須要註冊

基本測試流程：

1）建立/編輯腳本

2）運行壓力測試

3）分析測試結果

 

 

從奧運門票提及~

官方新聞以下：10月30日，北京奧組委想境內公衆啓動第二階段奧運會門票預售。然而，爲讓更多的公衆實現奧運夢想

的「先到先得，售完爲止「的銷售政策拔苗助長，公衆紛紛搶在第一時間訂票，導致票務官網壓力激增,...... 致使系統癱瘓。

     從上午9點開始售票到中午12點，3個小時內，票務網站被瀏覽次數達到2000萬此。這雨他們提供的100萬次/小時流量

相差甚遠。

信息提取：    壓力激增 ----  瞬時壓力：併發壓力（性能測試）

                      系統癱瘓 ----  宕機（down機了）

                      3個小時內，網站的流量次數達到2000萬次

                      他們提供的100次/小時     他們：奧組委

  甲方：奧組委                乙方：開發方                   第三方：測試團隊

 

報道~   

       從今天上午的狀況看，公衆購買門票的熱情極其高漲。有些羣衆很早就來到中國銀行排隊等候；官方票務網站的瀏覽量在第一小時

就達到800萬次，每秒鐘從網上提交的門票申請超過20萬張；票務呼叫中心熱線從9點到10點的呼入量超過了200萬人次。

 

信息提取：    瀏覽量第一小時 800萬次           8000000/3600 = 2222次/秒

                      每秒鐘從網上提交的門票申請超過20萬張

瀏覽量(PV,  Page View) ：即頁面訪問量或點擊量，用戶每次刷新即被計算一次。

 

客戶端                    服務器

北京 ---------------->    上海    網絡延遲0.2     每秒鐘差了0.2 *20萬張 = 4萬張 

上海 ----------------->   上海

 

 

項目經理常常安排次測試工程師進行下面的工做：

 ----  測試系統的最大併發用戶數

 ---- 測試系統8小時的最大業務吞吐量

 ---- 測試系統的穩定性和健壯性

 ---- 測試系統在數據達到100萬條記錄時的性能

 ---- 測試系統的核心事物相應時間是否知足用戶的需求

 

 

3、性能測試的概念：

一、性能測試：模擬真實的生產環境，以各類不一樣的壓力（模擬大量用戶）去測試被測系統，去」攻擊「測試系統。同時

記錄下被測系統中各臺服務器的各類重要資源狀況，包括cpu、內存、磁盤和網絡等資源。

二、注意：性能測試以前要作好系統備份。

三、性能測試時首先看性能需求，若是沒有需求，這時要根據與客戶交流、被測系統的相關資料、以及性能測試工程師的

經驗，去編寫測試計劃，進行測試。

四、負載測試和壓力測試的區別：

（國內混用，國外有差異，筆試時須要注意）

1）負載測試是在正常的範圍內測試（也是逐步加壓）

2）壓力測試能夠在極端的範圍內測試

負載測試：是經過逐步增長系統負載，測試系統性能的變化，最終肯定在知足性能指標的狀況下，系統所能承受的最大負載量的測試。

壓力測試 ：逐步增長系統負載，測試系統性能的變化，並最終肯定在什麼負載條件下系統性能處於失效狀態，並以此來獲的系統能提供的最大服務級別的測試。

舉例：一座大橋，橋身上寫最大載重車輛，不能超過60噸（負載測試）。可是在橋樑的內部資料裏面規定最大載重車輛，不能超過70噸（壓力測試）。

五、性能測試的背景課程：

1）數據庫 （不誇張的說，60%-90%的性能問題和數據庫有關）

2）操做系統（Unix、Linux）

3 ）其餘：網絡協議、防火牆等知識.....

六、影響系統性能的主要因素：

硬件 - cpu、內存、硬盤、網卡及其餘網絡設備

操做系統

網絡

中間件、web服務器

數據庫服務器

客戶端

編程語言、程序實現方法、算法

 

六、被測系統：

SUT(System Under Test)

AUT(Application Under Test)

EUT(Environment Under Test)

就是WebServer 和DB Server 兩部分的統稱。

 

進程和線程的區別：線程是由進程分出的，讓更多的任務同時執行。

每一個虛擬用戶就是一個線程，線程比較省資源

 

4、LoadRunner的工做原理：（錄製--回放）和QTP相似

一、錄製時，loadRunner記錄下客戶端和服務器兩者之間的對話。

二、回放時，LoadRunner模擬真實的客戶端向服務器發起請求，並按照腳本去驗證服務器的應答。

 

說明：有時腳本錄不下來，本身寫腳本，發現測試經過了，但實際運行是服務器癱了。

緣由：沒有模擬真的是客戶端相關，接收出現問題，致使失敗。因此本身寫腳本也要模擬真實的客戶端。

 

LoadRunner的三大組件：（三個火槍手）   QAload工具相似

1）虛擬用戶腳本生成器（Virtual User Generator） VUG

功能：錄製、編輯測試腳本

2）壓力調度控制檯（Controller）

功能：建立場景、運行場景、監控場景、收集測試數據

(場景：就是一個大型的配置文件)

3）壓力結果分析器（Analysis）

功能：把收集到的測試數據以圖表的形式展現出來，生成測試報告。

 

熟悉AUT：LR自帶的一個B/S架構的系統

HP LoadRunner -> Sample ->Web -> Start Web Server 先啓動服務器

 

HP LoadRunner ->Sample ->Web ->Hp WebTour打開應用

 

5、關注AUT，進行腳本的錄製

Web tours 航班訂票系統

用戶名：jojo

密碼：bean

 

注意：（瀏覽器指定使用IE）

一、使用LR以前，瀏覽器配置修改：Internet 選項 ->設置 ->選中「每次訪問此頁時檢查」。

緣由：當腳本更新時，會及時查看到

二、拷貝AUT的網址，準備測試（測試時關閉被測網址網頁）

http://127.0.0.1:1080/WebTours/

 

功能：

Flights      訂票

Itinerary    看到訂票路線 訂單

Home        主界面

Sign  Off    退出

 

錄製腳本：使用VUG

HP LoadRunner ->Application ->HP Vurtual User Generator 打開

 

案例：錄製用戶的登錄腳本

  點擊New圖標 -> New Virtual User ->默認協議 ->Create 開始錄製->填入基本信息點擊ok ->自動打開瀏覽器，開始錄製

填寫基本信息：

Application Type 選擇軟件的架構：B/S(Interner application) 或 C/S(Win32 application)

Program to record 選擇瀏覽器類型 -> 默認IE

URL Address: 被測系統的網址  

Working directory: LR工做路徑  默認

Record into Action: 錄製腳本的位置  默認Action（vuser_init 初始化   Action   vuser_end 結束）

關注小操做條（錄製控制功能）

--> 輸入jojo    bean

--> 開始事物   名稱login (插入事物) -> OK

--> Login 按鈕    登錄

--> 結束事物  login  -> OK

--> 改成vuser_end模式，點擊Sing Off 退出

--> 關閉瀏覽器  -> 點擊藍色的Stop鍵結束錄製

 

注意：當LR 的腳本運行得出的result中所有爲pass時，不必定證實腳本正確。由於lr只是在網絡層面上驗證了服務器收到了客戶端發送的數據包

而且返回，可是，返回的應答中數據是否正確（應答頁面是否正確）沒有驗證。