PO模型+數據驅動

1.PO模型簡介

 

PO模型即page Objects，直譯意思就是“頁面對象”，通俗的講就是把一個頁面，或者說把一個頁面的某個區域當做一個對象，通過封裝這個對象可以實現調用。

 

舉個最簡單的栗子：

登錄XX首頁驗證三種場景

場景一：有輸入正確的賬號和密碼

場景二：輸入正確的賬號和錯誤的密碼

場景三：輸入正確的賬號+密碼爲空

 

思路：

我需要重複編寫登錄XX的首頁登錄的腳本執行這三個用例，這時候我可以把登錄XX首頁的頁面當做一個類“登錄XX首頁”，每次需要登錄的時候調用這個類，

假如這個登錄頁面有UI元素改變或者新增登錄功能點，我們只需要修改這個類即可，簡而言之就是頁面中重複使用的頁面，可以進行抽象封裝成“類”，實現通用，

並且關於封裝的“類”的命名，儘量能體現類的行爲特點，例如新增組織架構員工，封裝了一個新增員工彈窗的“類”：進入新增員工窗口

 

優點：

1.減少了腳本的冗餘和維護腳本的精力

2.頁面對象與用例分離，使得我們更好的複用

3.增加了用例的可讀性

 

2.數據驅動簡介

數據驅動核心思想就是實現數據與代碼的分離，這麼做的目的，其實也是爲了腳本的易於維護，robotframework框架其實採用的是江湖中說的關鍵字驅動，那麼怎麼基於robotframework實現數據驅動呢？

2.1 create list

結合上面登錄的例子，假如現在有一個場景，需要多次登錄賬號，如果不基於數據驅動，那個我們可能需要寫多份腳本，假如我們通過create list來實現，

如下文，通過創建一個列表和循環在重複登錄不同賬號，不過這種方式當數據多的時候，未免有所不足。

列表-多次登錄兔展賬號
    ${account_list}    Create List    15813349620    13282648174
    ${pw_list}    Create List    111111    111111
    FOR    ${i}    IN RANGE    0    2
    登錄兔展首頁    ${account_list}[${i}]    ${pw_list}[${i}]
    END
    
 *** Keywords ***
登錄兔展首頁
# 簡單的封裝登錄彈窗頁面，即上文所講的PO對象的概念
    [Arguments]    ${account}    ${password}
    Log Many    ${account}    ${password}
    Open Browser    ${test_url}    ${chromeless}
    Maximize Browser Window
    Wait Until Element Is Enabled    css=#g-j-signin-btn    5
    Click Element    css=#g-j-signin-btn
    Select Frame    css=#sso
    Wait Until Element Is Enabled    css=[title=兔展賬戶]    5
    Click Element    css=[title=兔展賬戶]
    Wait Until Element Is Enabled    css=[placeholder=請輸入你的登錄賬戶]    5
    Input Text    css=[placeholder=請輸入你的登錄賬戶]    ${account}
    Wait Until Element Is Enabled    css=[placeholder=請輸入密碼]    5
    Input Text    css=[placeholder=請輸入密碼]    ${password}
    Wait Until Element Is Enabled    //button[@class="g-btn login-btn do-btn"]
    Click Element    //button[@class="g-btn login-btn do-btn"]    #登錄

 

2.2 Template

Template也是robotframework框架可以實現數據驅動的一種方式，如下文，在*** Keywords ***下封裝了一個“登錄首頁”的類，並且設置作爲“模板”，

*** Test Cases ***下就是在“繼承”了登錄首頁模板的前提下，可直接編寫我們的登錄首頁的測試用例，當我們的測試用例需要增加或者變動，維護起來就更加方便

*** Test Cases ***
模板-登錄賬號密碼驗證
    [Template]    登錄首頁
    #登錄首頁用例
    ${EMPTY}    ${EMPTY}    請輸入登錄賬號
    15813349620    111111    PASS
    15813349620    ${EMPTY}    請輸入6-20位字符的密碼
    15966666666    111111    登錄用戶不存在，請先註冊
    
*** Keywords ***
登錄首頁
    [Arguments]    ${account}    ${password}    ${err_info}
    Log Many    ${account}    ${password}    ${err_info}
    Open Browser    ${test_url}    ${chromeless}
    Maximize Browser Window
    Wait Until Element Is Enabled    css=#g-j-signin-btn    5
    Click Element    css=#g-j-signin-btn
    Select Frame    css=#sso
    Wait Until Element Is Enabled    css=[title=兔展賬戶]    5
    Click Element    css=[title=兔展賬戶]
    Wait Until Element Is Enabled    css=[placeholder=請輸入你的登錄賬戶]    5
    Input Text    css=[placeholder=請輸入你的登錄賬戶]    ${account}
    Wait Until Element Is Enabled    css=[placeholder=請輸入密碼]    5
    Input Text    css=[placeholder=請輸入密碼]    ${password}
    Wait Until Element Is Enabled    //button[@class="g-btn login-btn do-btn"]
    Click Element    //button[@class="g-btn login-btn do-btn"]    #登錄
    ${login_info}    Run Keyword And Ignore Error    Wait Until Element Is Not Visible    //button[@class="g-btn login-btn do-btn"]
    #通過js獲取登錄信息
    ${user_login_info}    Run Keyword If    '${login_info[0]}'=='FAIL'    Execute Javascript    return document.getElementsByClassName("error-tips")['1'].textContent
    ...    ELSE IF    '${login_info[0]}'=='PASS'    Set Variable    PASS
    Unselect Frame
    #斷言
    Should Be Equal As Strings    ${user_login_info}    ${err_info}

2.3 ExcelLibrary

待補充。。。

總結：結合roborframework，PO模型+數據驅動是目前江湖上展開UI自動化比較主流的設計思想，如果哪位大佬有更好的建議，歡迎積極分享！！

 

附：關於展開自動化項目的一點建議

1.項目的結構目錄

common：存放公共的庫和全局用戶關鍵字（儘量少定義全局用戶關鍵字，降低腳本的耦合性）
testcase：測試用例，建議測試用例的目錄同官網的目錄一致，目錄下級即測試用例文件，因爲用例腳本會越來    
          越多，這也是便於後面維護和管理，能方便快捷的找到相關用例
data：存放測試數據\測試數據文件，建議數據的存放目錄也同用例目錄，目的也是便於測試數據的管理

 

2.關於什麼功能併入自動化測試中

小弟覺得，可以在現有的功能測試用例中，基於各功能模塊，對測試用例進行“評審”，即篩選，篩選出適合做UI自動化測試的功能用例，什麼叫適合呢，

我覺得有以下幾點：

1.首先當然是UI自動化能實現的（有點廢話。。）

2.功能模塊使用頻繁或者平時用戶反饋問題比較頻繁的功能模塊（視情況而定）

3.實現起來相對不用花費大量的時間成本（本末倒置），當然這個粒度的粗細需後續討論

具體流程：

篩選並評審功能測試用例自動化的可行性--->根據可行性用例模塊化編寫自動化腳本-->本地調試成功並上傳自動化測試平臺