Q1：什麼是負載測試？什麼是效能測試？

　　A1：負載測試是通過逐步增加系統負載，測試系統性能的變化，並最終確定在滿足效能指標的情況下，系統所能承受的最大負載量的測試，例如，訪問一個頁面的響應時間規定不超過1秒，負載測試就是測試在響應時間為1秒時，系統所能承受的最大併發訪問使用者的數量。

　　效能測試：指在一定的約束條件下（指定的軟體、硬體、網路環境等），確定系統所能承受的最大負載壓力。

Q2.效能測試包含了哪些測試（至少舉出3種）

　　A2：效能測試包含負載測試、壓力測試、大資料量測試、疲勞強度測試等。

Q3.什麼時候開始展開效能測試？效能測試常見的步驟？

　  A3：

Q4.簡述使用Loadrunner的步驟

　　A4：制定效能測試計劃—>開發測試指令碼—>設計測試場景—>執行測試場景—>監控測試場景—>分析測試結果

Q5.什麼時候可以開始執行效能測試？

　　A5：功能測試通過；一般需要進行效能測試的系統，都是使用者量比較大、業務使用比較頻繁、比較重要的功能模組。

Q6.LoadRunner由哪些部件組成？

　　A6：主要有三部分組成：

Q7.你使用LoadRunner的哪個部件來錄製指令碼？

　　A7：使用Virtual User Generator錄製測試指令碼

Q8.LoadRunner的哪個部件可以模擬多使用者併發下回放指令碼？

　　A8：

Q9.什麼是集合點？設定集合點有什麼意義？Loadrunner中設定集合點的函式是哪個？lr中的集合點跟場景設定中全部初始化後在執行有什麼區別？

　　A9：在效能測試過程中，需要模擬大量使用者在同一時刻，訪問系統並同時操作某一任務，可以通過配置集合點來實現，多個使用者同時進行某操作；

　　集合點可以在伺服器上建立密集的使用者負載，使LoadRunner能夠測試伺服器在負載狀態下的效能。

　　設定集合點函式：lr_rendezvous("Meeting")；  // Meeting是集合點名稱

Q10.什麼是場景？場景的重要性有哪些？如何設定場景？

　　A10：場景用於模擬使用者實際業務操作；

　　LoadRunner中場景有手工場景和麵向目標的場景。

　　設定場景：選擇場景型別、設定執行時設定、模擬使用者數、加減壓方式、持續時間，配置負載生成器。

Q11.請解釋一下如何錄製web指令碼？

　　A11：利用Virtual User Generator錄製測試指令碼，錄製步驟：

　　1、選擇合適的協議 

　　2、設定錄製選項 

　　3、開始錄製 

Q12.為什麼要建立引數？如何建立引數？

　　A12：LoadRunner在錄製指令碼的時候，只是忠實的記錄了所有從客戶端傳送到伺服器的資料，而在進行效能測試的時候，為了更接近真實的模擬現實應用，對於某些資訊需要每次提交不同的資料，或者使用多個不同的值進行迴圈輸入。這時，在LoadRunner中就可以進行引數化設定，以使用多個不同的值提交應用請求。

　　【引數化】：使用指定資料來源中的值來替換指令碼錄製生成的語句中的引數。

　　【引數化好處】

　　● 減少指令碼的大小

　　● 提供使用不同的值執行指令碼的能力，更加真實的模擬現實應用。

　　【引數化步驟】

　　● 用引數替換Vuser指令碼中的常量值

　　● 為引數設定屬性和資料來源

Q13.什麼是關聯？請解釋一下自動關聯和手動關聯的不同。

　　A13：【關聯的定義】簡單的說：就是把指令碼中某些寫死（固定）的資料，轉變成動態的資料，或者說將前面語句的結果資料儲存下來，然後在後面的語句提交請求時使用這些資料。

　　【需要關聯的前提條件】：

　　客戶端需要從伺服器端返回資料中獲取部分資料，並將這些部分資料處理後作為自己下一次請求的一部分發出。

　　【自動關聯與手工關聯的不同】：自動關聯是在指令碼錄製過程中，VuGen會根據已經制定好的規則，自動找出需要關聯的值或指令碼錄製完成後，執行指令碼一次，通過Correlation Studio自動找出需要關聯的資料，並建立關聯；而手動關聯是需要錄製兩份相同業務流程的指令碼，輸入的資料要相同，利用WinDiff工具，找出兩份指令碼之間不同之處，也就是需要關聯的資料，再通過web_reg_save_param函式手動建立關聯，將指令碼中用到關聯的資料引數化。

Q14.你如何找出哪裡需要關聯？請給一些你所在專案的例項。

　　A14：

　　1、錄製兩份相同業務流程的指令碼，輸入的資料要相同

　　2、利用BeyondComparePortable工具，找出兩份指令碼之間不同之處，也就是需要關聯的資料

　　3、通過web_reg_save_param函式手動建立關聯，將指令碼中用到關聯的資料引數化。

　　示例：

　　通過錄制兩份指令碼，進行對比，可知jsessionid、sap-ext-sid、sap-wd-cltwndid、sap-wd-tstamp需要進行關聯。

Q15.你在哪裡設定自動關聯選項？

　　A15：錄製選項中進行設定，如下圖所示：

Q16.哪個函式是用來擷取虛擬使用者指令碼中的動態值？（手工關聯）

　　A16：Web_reg_save_param函式主要根據需要做關聯的動態資料前面和後面的固定字串來識別、提取動態資料，所以在做關聯時，需要找出動態資料的左、右邊界字串。

　　1.函式原型：

　　int web_reg_save_param (const char *ParamName, <List of Attributes>, LAST);

　　2.引數說明：

　　ParamNam：存放動態資料的引數名稱

　　List of Attributes：其它屬性，包含Notfound、LB、RB、RelFrameID、Search、ORD、SaveOffset、Convert、SaveLen。

● Notfound：指當找不到要找的動態資料時，怎麼處理。

　　● Notfound=error，當找不到動態資料時，發出一個錯誤資訊，為LoadRunner的預設值。

　　● Notfound=warning，當找不到動態資料時，不發出錯誤資訊，只發出警告，指令碼會繼續執行下去不會中斷。

　　● LB:動態資料的左邊界字串，該引數為必選引數，並區分大小寫。

　　● RB:動態資料的右邊界字串，該引數為必選引數，並區分大小寫。

　　● ORD:指提取第幾次出現的左邊界的資料，該引數為可選引數，預設值是1。假如值為All,則查詢所有符合條件的資料並把這些資料儲存在陣列中。

　　● Search：搜尋的範圍。可以是Headers（只搜尋Headers）、Body（只搜尋Body部分，不搜尋Headers）、Noresources（只搜尋Body部分，不搜尋Header與Resource）或是All（搜尋全部範圍，此為預設值），該引數為可選引數。

　　● RelFrameID：相對於URL而言，欲搜尋的網頁的Frame，此屬性可以是All或是具體的數字，該引數為可選引數。

　　● SaveOffset：當找到符合的動態資料時，從第幾個字元開始才儲存到引數中，該引數為可選引數，此屬性值不可為負數，其預設值是0.

　　● Convert：可能的值有兩種:

　　● HTML_TO_URL:將HTML-encoded資料轉成URL-encoded資料格式。

　　● HTML_TO_TEXT:將HTML-encoded資料轉成純文字資料格式。

　　● SaveLen：從Offset開始算起，到指定長度內的字串，才儲存到引數中，該引數為可選引數，預設值為-1，表示儲存到結尾整個字串。

Q17.你在VUGen中何時選擇關閉日誌？何時選擇標準和擴充套件日誌？標準日誌以及擴充套件日誌的區別？

　　A17：在測試場景執行時，關閉日誌，因為日誌資訊過多，也會影響效能測試結果；在除錯測試指令碼時，可以選擇標準或擴充套件日誌，用於輸出除錯資訊。

　　可以在執行時設定中，進行日誌設定，如下圖所示：

     標準日誌：指令碼執行過程中，將函式集及資訊傳送到日誌檔案中

　　擴充套件日誌：可以將詳細的指令碼執行資訊輸出到日誌檔案中，可以選擇以下三種擴充套件日誌資訊：

　　● 引數替換：指令碼執行過程中，可以將引數及當前引數值輸出到日誌檔案中

　　● 伺服器返回的資料：將伺服器返回給客戶端的資料輸出到日誌檔案中

　　● 高階跟蹤：所有的虛擬使用者資訊和函式呼叫輸出到日誌檔案中

Q18.你如何除錯LoadRunner指令碼？

　　A18： 通常採用以下方法除錯LoadRunner測試指令碼

　　● 斷點

　　【方法】在指令碼的任意一行上按右鍵選單或F9增加斷點。

　　● 單步跟蹤

　　【方法】通過選單命令VUser—>Run Step by Step或F10，可以控制指令碼以語句為單位執行。

　　● 日誌輸出

　　【方法】通過日誌輸出函式lr_message、lr_log_message、lr_output_message輸出。

　　● 對話方塊輸出

　　綜上，在實際測試工作中，基本上使用前三種方法，對話方塊輸出基本上沒用過。

Q19、你在LR中如何編寫自定義函式？請給出一些你在以前進行的專案中編寫的函式。

　　A19：在編寫使用者自定義函式之前，需要首先為函式建立外部庫（DLL）檔案，將這些庫檔案放在bin目錄下，一旦庫檔案已經被新增並且將使用者自定義函式作為引數，函式應該為以下格式：__declspec (dllexport) char* (char*， char*)

Q20.在執行設定下你能更改那些設定？

　　A20：可以修改Run Logic、pacing、Log、Think Time等，見下圖；可以測試實際需要，修改相關選項。

Q21.你在不同的環境下如何設定迭代？

　　A21：在“執行時設定”中設定，如下圖所示：

Q22.你如何在負載測試模式下執行功能測試？

　　A22：在負載測試模式下，可以通過同時執行數個虛擬使用者，通過增加虛擬使用者數，確定伺服器在多大的負載量下，仍然可以正常執行，我一般進行核心功能操作，驗證核心功能執行是否正常。

Q23.什麼是逐步遞增？你如何來設定？

　　A23：虛擬使用者數隨著負載時間逐漸增加，可以幫助確定系統響應時間減慢的準確時間點。

　　可以在“加壓”選項卡中進行設定：如下圖所示，將設定更改為：“每 30 秒啟動 2 個 Vuser”

Q24.以執行緒方式執行的虛擬使用者有哪些優點？

　　A24：以執行緒方式執行的虛擬使用者，在預設情況下，Controller為每50個使用者僅啟動一個mmdrv程序，而每個使用者都按執行緒方式來執行，這些執行緒使用者將共享父程序的記憶體，這就節省了大量記憶體空間，從而可以在一個負載生成器上執行更多的使用者。

Q25.當你需要在出錯時停止執行指令碼，你怎麼做？

　　A25：取消執行設定中的“Continue on error”複選框。

　　或者使用lr_abort函式。

Q26.響應時間和吞吐量之間的關係是什麼？

　　A26：當系統吞吐量未達到系統處理極限時，系統性能不會衰減，交易平均響應時間一般也不會遞增，當系統達到吞吐量極限時，客戶端交易會在請求佇列中排隊等待，等待的時間會記錄在響應時間中，故交易平均響應時間一般會遞增。

Q27.說明一下如何在LR中配置系統計數器？

　　A27：以windows資源監控為例，可右鍵點“新增度量”，輸入系統IP、選擇平臺型別，確定即可，詳細參加LR自帶操作手冊^_^。

　　對於監控不同型別的作業系統，需要做一些準備工作，可參見監控作業系統資源部分。

Q28.你如何識別效能瓶頸？

　　A28：

自己的理解，瓶頸產生在以下幾方面：

• 1、網路瓶頸，如頻寬，流量等形成的網路環境
• 2、應用服務瓶頸，如中介軟體的基本配置，CACHE等
• 3、系統瓶頸，這個比較常用：應用伺服器，資料庫伺服器以及客戶機的CPU，記憶體，硬碟等配置
• 4、資料庫瓶頸，以ORACLE為例，SYS中預設的一些引數設定
• 5、應用程式本身瓶頸，

針對網路瓶頸，現在冒似很少，不過也不是沒有，首先想一下如果有網路的阻塞，斷網，頻寬被其他資源佔用，限速等情況，應用程式或系統會是什麼情況，針對WEB，無非是超時，HTTP400，500之類的錯，針對一些客戶端程式，可能也是超時，掉線，伺服器下發的，需要伺服器返回的資訊獲取不到還有一種更明顯的情況，應該就是事務提交慢，如果封裝事務的程式碼再不完善，一般造成的錯誤，無非就是資料提交不完整，或者因為網終原因+程式碼缺陷造成重複性提交。如此綜合下來，肯定是考慮網路有瓶頸，然後考慮網路有問題時，怎樣去優化，是需要優化互動的一些程式碼，還是介面之類的。

應用服務的瓶頸的定位，比較複雜，學習中，不過網上有很多資料可以參考的。一般像tomcat，weblogic之類的，有預設的設定，也有經過架構和維護人員進行試驗除錯的一些值，這些值一般可以滿足程式釋出的需要，不必進行太多的設定，可能我們認識的最基本的就是JAVA_OPTS的設定，maxThreads，time_out之類的引數我們做藉助LR，Jemeter或webload之類的工具，執行效能測試，尤其是對應用服務造成了壓力，如果應用服務有瓶頸，一般我們設定的log4j.properties，日誌都會記錄下來。然後根據日誌，去進一步確定應用服務的問題

系統瓶頸，這個定位雖說比較複雜，但是有很多前輩的經驗值參考，不作說明，相信用LR的同行，也可以從效能記數器中得出一些指標值，加上nagios，cacti，可以很明顯的看出系統哪些資源夠用，哪些資源明顯不夠用。不過，一般系統瓶頸的造成，是因為應用程式本身造成的。關於這點兒的分析和定位，就需要歸入應用程式本身瓶頸分析和定位了。

現在基本所有的東東，都離不開資料庫這個後臺，資料庫的瓶頸實在是不知道是什麼概念，資料庫管理員的工作，資料庫管理員日常做的工作，可能就是有瓶頸定位的工作，比如：查詢一下V$sys_event，V$sysstat，v$syssql之類的表，比對一下日常正常情況下的監控資料，看一下有沒有異常等。其他方面，我也不是太瞭解。

應用程式瓶頸，這個是測試過程中最需要去關注的，需要測試人員和開發人員配合執行，然後定位，我這兒做的大都是執行性的，比如會有指令碼去執行，開發人員會結合jprofiler之類的工具，去看一下堆遍歷，執行緒剖析的情況確定哪兒有問題。

大致是這樣，沒有實際操作過逐步細化分析，先可以監控一些常見衡量CPU，記憶體，磁碟的效能指標，進行綜合分析，然後根據所測系統具體情況，進行初步問題定位，然後確定更詳細的監控指標來分析。

Q29.如果web伺服器、資料庫以及網路都正常，問題會出在哪裡？

　　A29：問題可能出在系統本身或應用伺服器、或為應用編寫的程式碼編寫中。

Q30.如何發現web伺服器的相關問題？

　　A30：可以利用web資源監控器發現web伺服器相關問題，在場景執行過程中，可以利用監控器分析web伺服器吞吐量、每秒點選率、每秒HTTP響應數、每秒頁面下載數，以及web伺服器硬體資源使用情況等。

Q31.如何發現數據庫的相關問題？

　　A31：可以通過資料庫監控器和資料資源圖發現數據庫相關的問題，例如在執行Controller之前，可以指定需要度量的資源，之後可以根據監控的資料，分析資料庫相關的問題。

Q32.解釋所有web錄製配置？

　　A32：選擇錄製協議、設定錄製選項、選擇瀏覽器、選擇存放路徑、開始錄製。

Q33.解釋一下覆蓋圖和關聯圖的區別？

　　A33：覆蓋圖：合併兩個圖的內容，使用同一個X軸，合併圖左Y軸顯示當前圖的值，合併圖右Y軸顯示被合併圖的值。

　　關聯圖：當前活動圖的Y軸變為合併圖的X軸，被合併圖的Y軸變成合並圖的Y軸。

Q34.你如何設計負載？標準是什麼？

　　A34：負載測試計劃多少使用者數量、使用什麼型別的機器、以及在什麼環境下進行。主要基於兩個重要的文件，任務分佈圖和事務資訊，任務分佈圖告訴我們在負載時間段內，某一個事務使用的使用者數，高峰使用率及低峰使用率均來自該文件；

　　事務資訊告訴我們事務名及優先順序，在設計場景時可以參考。

Q35.Vuser_init中包括什麼內容？

　　A35：Vuser_init中包含在指令碼執行過程中只需執行一次的指令碼。一般來說，所有需要初始化的都可以放在vuser_init裡面，比如登入。

Q36. Vuser_end中包括什麼內容？

　　A36：vuser_end中一般包含退出的過程，比如退出系統，主要在指令碼執行完成或停止時執行，在設定了迭代次數時，vuser_end和vuser_int均只執行一次。

Q37.什麼是think time？think_time有什麼用？

　　A37：思考時間：使用者在各步驟之間停下來進行思考的時間，由於使用者基於其經驗水平和目標而與應用程式進行互動操作，因此技術水平更高的使用者工作起來可能會比新使用者要快。

　　通過啟用思考時間，可以使 Vuser在負載測試期間更準確地模擬其對應的真實世界使用者。

Q38.解釋以下函式及他們的不同之處。

　　A38：lr_debug_message：傳送除錯資訊到輸出視窗或業務監控日誌檔案中

　　lr_output_message：傳送日誌資訊到輸出視窗或業務監控日誌檔案中

　　lr_error_message：傳送錯誤資訊到輸出視窗或業務監控日誌檔案中

　　lrd_stmt：賦予一個SQL語句用於處理

　　lrd_fetch：獲取結果集中的下一行資料

Q39.什麼是吞吐量？

　　A39：客戶端每秒從伺服器接收到的資料，或系統伺服器每秒能處理通過的交易數。一般隨著虛擬使用者數的增加，吞吐量也增加，說明網路頻寬比較充足，反之，吐過隨著虛擬使用者數的增加，吞吐量比較平穩，呈直線狀態，則說明網路頻寬成為瓶頸，限制了資料傳輸。

Q40.場景設定有哪幾種方法？

　　A40：面向目標的場景設定和手動場景

Q41.在進行效能測試的時候，我們需要知道一些有效的效能指標，下面我們來列出一些主要的效能指標：

　　A41：

一是，通用指標（指Web應用伺服器、資料庫伺服器必需測試項）：

      *ProcessorTime：指伺服器CPU佔用率，一般平均達到70%時，服務就接近飽和；

      *Memory Available Mbyte：可用記憶體數，如果測試時發現記憶體有變化情況也要注意，如果是記憶體洩露則比較嚴重；

      *Physicsdisk Time ：物理磁碟讀寫時間情況。

      二是，Web伺服器指標：

      *Avg Rps：平均每秒鐘響應次數＝總請求時間/秒數；

      *Avg time to last byte per terstion（mstes）：平均每秒業務角本的迭代次數；*Successful Rounds：成功的請求；

      *Failed Rounds：失敗的請求；

      *Successful Hits：成功的點選次數；

      *Failed Hits：失敗的點選次數；

      *Hits Per Second：每秒點選次數；

      *Successful Hits Per Second：每秒成功的點選次數；

      *Failed Hits Per Second：每秒失敗的點選次數；

      *Attempted Connections：嘗試連結數。

      三是，資料庫伺服器指標：

      *User 0 Connections ：使用者連線數，也就是資料庫的連線數量；

      *Number of deadlocks：資料庫死鎖；

      *Butter Cache hit：資料庫Cache的命中情況。

web效能測試中，如何獲得dns解析時間？

lr的help文件中提到了 ms_dns_* 的函式