漲薪技術|0到1學會性能測試第12課-腳本開發技巧之檢查點

前面的推文我們掌握了性能測試分析器的使用，包括摘要視圖、常見視圖介紹和如何生成測試報告，單純看這些報告還是遠遠不夠，今天開始給大家分享性能測試腳本開發技巧，後續文章都會系統分享幹貨，帶大家從0到1學會性能測試，另外還有教程等同步資料，+小編VX(flyhappy111)領取即可!

LoadRunner錄制結束後會自動生成一段腳本。這段腳本雖然很簡單，但很實用，适合初學者學習。但是在真正進行項目性能測試時，隻靠LoadRunner自動生成的腳本還是不夠，很難達到業務的要求。是以，在錄制腳本結束後，要對腳本進行完善，使其能達到業務模拟的要求，這樣盡可能地使虛拟使用者模拟時更接近使用者的實際使用。

01腳本開發之檢查點

在進行壓力測試時，經常會有頁面間資料傳遞的操作。如果在測試過程中傳遞資料的次數逐漸增多，頁面就有可能會發生傳遞混亂，或者用戶端與伺服器端資料傳輸被中斷、傳輸過程中産生了錯誤的資料等情況。為了判斷資料傳遞的正确性，更重要的是為了節省人工檢查的步驟和時間，LoadRunner提供了在腳本中插入檢查點的方法，在每次運作時都檢查伺服器傳回頁面的資訊是否正确，這樣可以大大提高測試效率。檢查點的原理是通過檢查點函數将傳回值的結果反映在Controller的狀态面闆上和Analysis統計結果中。這個原理是基于LoadRunner中很多的API函數的傳回值會改變腳本的運作結果。比如，檢查點函數web_find，如果它檢查到的結果為空，它的傳回值就為LR_FAIL，這樣整個結果置為FAIL;反之，檢查到的結果為成功，則web_find傳回值是LR_PASS，整個結果置為PASS。

為什麼要插入檢查點

通常在測試過程中使用到兩種檢查點，文本檢查點和圖檔檢查點。那麼為什麼需要插入檢查點呢?以飛機訂票系統的登入功能為例，我們來觀察在不插入檢查點回放，事務結束狀态的情況。首先錄制登入的腳本，腳本如下(部分核心代碼)：

​web_reg_save_param("WCSParam2",
     "LB/IC=userSession value=", 
    "RB/IC=>", 
    "Ord=1", 
    "Search=Body", 
    "RelFrameId=1", 
    LAST);

  web_url("nav.pl", 
    "URL=http://127.0.0.1:1080/WebTours/nav.pl?in=home", 
    "Resource=0", 
    "RecContentType=text/html", 
    "Referer=http://127.0.0.1:1080/WebTours/welcome.pl?signOff=true", 
    "Snapshot=t7.inf", 
    "Mode=HTTP", 
    LAST);

  web_concurrent_end(NULL);

  web_url("mer_login.gif", 
    "URL=http://127.0.0.1:1080/WebTours/images/mer_login.gif", 
    "Resource=1", 
    "RecContentType=image/gif", 
    "Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home", 
    "Snapshot=t8.inf", 
    LAST);

  lr_start_transaction("Login");

  lr_think_time(14);
web_submit_data("login.pl", 
    "Action=http://127.0.0.1:1080/WebTours/login.pl", 
    "Method=POST", 
    "RecContentType=text/html", 
    "Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home", 
    "Snapshot=t9.inf", 
    "Mode=HTTP", 
    ITEMDATA, 
    "Name=userSession", "Value={WCSParam2}", ENDITEM, 
    "Name=username", "Value=test1", ENDITEM, 
    "Name=password", "Value=1", ENDITEM, 
    "Name=JSFormSubmit", "Value=off", ENDITEM, 
    "Name=login.x", "Value=46", ENDITEM, 
    "Name=login.y", "Value=6", ENDITEM, 
    LAST);

  web_concurrent_start(NULL);

  web_url("nav.pl_2", 
    "URL=http://127.0.0.1:1080/WebTours/nav.pl?page=menu&in=home", 
    "Resource=0", 
    "RecContentType=text/html", 
    "Referer=http://127.0.0.1:1080/WebTours/login.pl", 
    "Snapshot=t10.inf", 
    "Mode=HTTP", 
    LAST);

  web_url("login.pl_2", 
    "URL=http://127.0.0.1:1080/WebTours/login.pl?intro=true", 
    "Resource=0", 
    "RecContentType=text/html", 
    "Referer=http://127.0.0.1:1080/WebTours/login.pl", 
    "Snapshot=t11.inf", 
    "Mode=HTTP", 
  LAST);
  web_concurrent_end(NULL);           

在這個腳本中并沒有插入檢查點，回放腳本，日志檔案如圖6-1所示。

從回放日志中可以看出，登入事務是正确的，使用者成功登入，這沒有問題，現在将web_submit_data函數使用者名和密碼的參考修改一下，将其修改為如下代碼：

web_submit_data("login.pl", 
    "Action=http://127.0.0.1:1080/WebTours/login.pl", 
    "Method=POST", 
    "RecContentType=text/html", 
    "Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home", 
    "Snapshot=t9.inf", 
    "Mode=HTTP", 
    ITEMDATA, 
    "Name=userSession", "Value={WCSParam2}", ENDITEM, 
    "Name=username", "Value=abcdef00133", ENDITEM, 
    "Name=password", "Value=ddaa", ENDITEM, 
    "Name=JSFormSubmit", "Value=off", ENDITEM, 
    "Name=login.x", "Value=46", ENDITEM, 
    "Name=login.y", "Value=6", ENDITEM, 
    LAST);           

重新回放腳本，回放日志如圖6-2所示。

從回放日志中可以清晰的看到，登入還是成功的，但實際情況下使用使用者名為abcdef00133，密碼為ddaa是不可能登入成功的。從LoadRunner的Run-Time Viewer視圖中也可以看出，Run-Time Viewer視圖結果如圖6-3所示。

登入成功後正常的情況是，Welcome後面會顯示出登入的使用者名。這個例子說明一個問題，當事務的結束狀态為成功時，并不能說明業務真的做成功了，那麼同理，當在分析器中看到事務的成功率為100%時，平均事務響應時間也是在期望範圍内時，也不能說明系統沒有問題，也有可能出現這種情況，業務沒有做成功，但事務的結束狀态都被置為成功了，這樣分析到的結果就完全錯了。那麼LoadRunner是如何确定事務結束狀态為PASS的呢?其實LoadRunner本身無法實際去判斷業務是否做成功，其判斷事務是否成功的依據是結束事務函數(lr_end_transaction)是否被執行，如果結束事務函數執行成功，那麼LoadRunner則會将事務的結束狀态設定為PASS。從這個例子可以看出，如果需要确定事務是否成功，其實首先應該判斷是否登入成功，隻有當登入成功時，才能确定登入事務是成功的，是以其實檢查點的根本目的是驗證測試過程中的步驟是否被正确的執行，也可以了解為業務是否被正确的執行，隻有這樣才能保證後期分析的資料是正确的。