Robot Framework Keyword: Wait Something Keywords

測試一個Web應用程式免不了Redirect的動作。當我們從頁面A到頁面B要做某些測試時，可能因為電腦或網路剛好很慢，造成待測項目沒有及時出來而fail。這種情況並不一定是個bug! 除此之外還有以下是會用到wait keyword的情況：

點擊Element後，等它回應驗證結果。如Alert視窗，或是經過操作後，希望某個Element出現或消失。
導向後要確認此頁面是否為你要的頁面。
確認系統中Service狀態。

在robot的best practice中，也提及用wait until取代sleep較好，可以減少不必要的浪費。皆下來看看常見的需求該如何透過wait until實作。

Wait Until Page Not Contains Element

RobotFramework中並沒有提供Wait Until Page Not Contains Element的keyword，但這卻是必用的keyword。舉例來說，Dialog會有OK與Cancel，在我們點擊OK或Cancel後，沒甚麼問題的話Dialog就會消失。如果還有下一個動作要執行，我們必須等到這個Dialog消失才能做動作，此時就需要這個keyowrd。而這個Keyword的實作，有兩種方法:

For loop + Page Should Not Contain Element。
Wait Until Keyword Succeeds + Page Should Not Contain Element。

怎麼看都是方法2比較優雅且簡單。可以這樣寫這個keyword:

# Keyword Name: Wait Until Page Not Contains Element
# Arguments:    ${locator} | ${timeout} | ${retry_time}
Wait Until Keyword Succeeds | ${timeout} | ${retry_time} | Page Should Not Contain Element | ${locator} | ${EMPTY} | NONE

用${timeout}來設定timeout的時間，${retry_time}為多久執行一次 Page Should Not Contain Element，${locator}為xpath路徑。如果只是要check某一個text，只要把Page Should Not Contain Element改為Page Should Not Contain即可。

Wait Until Alert Be Present

現在大部分應用程式都透過Ajax讓Client與Server溝通，做了某些操作後會直接反應到Client上。像是連線出問題、成功或錯誤訊息都有可能透過alert的方式告訴使用者。但這在我們操作之後並不會馬上反應，因此需要重複的去確認Alert是否有顯示出來。我們可以透過Wait Until Keyword Succeeds + Alert Should Be Present達到:

# Keyword Name: Wait Until Alert Be Present
# Arguments:    ${msg} | ${timeout} | ${retry_time}
Wait Until Keyword Succeeds | ${timeout} | ${retry_time} | Alert Should Be Present | ${msg}

有時我們會希望操作之後，不要出現非預期的Alert。我們可以透過Wait Until Keyword Succeeds + Alert Should Not Be Present達到，其中Alert Should Not Be Present可以用下面方式實作:

# Keyword Name: Alert Should Not Be Present
# Arguments:    ${msg}
${result} | ${msg} | Run Keyword And Ignore Error | Alert Should Be Present | ${msg}
Should Be True | '${result}'!='PASS'

Run Keyword And Ignore Error是非常好用的keyword，讓你來做某些事情的反向判斷。

後記

使用Wait Until Keyword Succeeds+Alert Should Be Present其實有點浪費。假設某一次retry已經有得到alert message，但不是預期的，這時候還是會繼續retry下去。改透過Get Alert Message取得訊息接著再去判斷，會是比較有效率的做法。

Wait For Service Start/Stop

這是一個比較麻煩的keyword，可能會根據你裝的作業系統影響到你的實作。在RobotFramework中，目前我也還不曉得該如何處理中文的問題，所以只針對英文部分去作處理。而OS的部分Windows較一致沒什麼問題，Linux的部分我的實作可以支援RedHat與SuSe。首先我以Wait For Service Start來說明一下實作流程:

Wait For Service Start

Wait For Service Start = Wait Until Keyword Succeeds + Check Service Start。在timeout與retry_time的部分可根據個人需求決定是否要當參數丟入。

# Keyword Name: Wait For Service Start
# Arguments:    ${service_name}
Wait Until Keyword Succeeds | 60s | 2s | Check Service Start | ${service_name}

Check Service Start

Check Service Start會根據Windows與Linux不同，分別為Check Service Start for Linux與Check Service Start for Windows。

# Keyword Name: Check Service Start
# Arguments:    ${service_name}
Set OS Environment
Run Keyword If | '%{OS_NAME}'=='linux' | Check Service Start for Linux | ${service_name}
Run Keyword If | '%{OS_NAME}'=='windows' | Check Service Start for Windows | ${service_name}

Set OS Environment在這就不特別列出來，實作方法就是去執行一個linux command(ls)再確認retrun code就可以判斷。

Check Service Start for Linux

透過service xxx status取得結果，在判斷內容包含running且不包含not就代表service start。這是在RHEL5、6與SuSe10、11上有測試過的結果。

# Keyword Name: Check Service Start for Linux
# Arguments:    ${service_name}
${result} | Run | service ${service_name} status
@{result1} | Run Keyword And Ignore Error | Should Contain | ${result} | running
@{result2} | Run Keyword And Ignore Error | Should Not Contain | ${result} | not
Should Be True | '@{result1}[0]' == 'PASS' and '@{result2}[0]' == 'PASS'

Check Service Start for Windows

在Windows上不像Linux需要考慮多種情況，僅透過sc query並確認結果包含RUNNING就代表service start。

# Keyword Name: Check Service Start for Windows
# Arguments:    ${service_name}
${result} | Run | sc query ${service_name}
Should Contain | ${result} | RUNNING

Wait For Service Stop

與Wait For Service Start類似，在這我就只針對Check Service Stop for Linux與Check Service Start for Windows進行說明。

Check Service Stop for Linux

Linux service stop訊息較不一致，必須判斷三種狀況，其中一個成立即可。

# Keyword Name: Check Service Stop for Linux
# Arguments:    ${service_name}
${result} | Run | service ${service_name} status
@{result1} | Run Keyword And Ignore Error | Should Contain | ${result} | is not running
@{result2} | Run Keyword And Ignore Error | Should Contain | ${result} | unused
@{result3} | Run Keyword And Ignore Error | Should Contain | ${result} | is stopped
Should Be True | '@{result1}[0]' == 'PASS' or '@{result2}[0]' == 'PASS' or '@{result3}[0]' == 'PASS'

Check Service Stop for Windows

透過sc query並確認結果包含STOPPED就代表service stop。

# Keyword Name: Check Service Stop for Windows
# Arguments:    ${service_name}
${result} | Run | sc query ${service_name}
Should Contain | ${result} | STOPPED

Wait Until Page Contains Element VS. Wait Until Keyword Succeeds + Page Should Contain Element

其實Wait Until Page Contain Element(方法1)可以透過Wait Until Keyword Succeeds + Page Should Contain Element(方法2)實作。用哪一個必須看個人需求，如果想自己控制retry_time就可以透過方法2去實作。但缺點是每try一次就會產生一筆log，間隔越小log越多，對方法1而言不管成功失敗都是只有一筆。

Reduce Logs

之前發現硬碟空間被測試報表佔用非常快，原因是在使用Page Should Contain相關的keyword + retry後，會產生一堆log，且這些log往往是整個網頁的html。這些keyword參數應該會有個loglevel，只要將它設為NONE就不會紀錄一堆網頁內容。假如真的有需要這個log，可嘗試下面的作法:

# Keyword Name: Wait Until Page Not Contains Element
# Arguments:    ${locator} | ${timeout} | ${retry_time}
@{result} | Run Keyword And Ignore Error | Wait Until Keyword Succeeds | ${timeout} | ${retry_time} | Page Should Not Contain Element | ${locator} | ${EMPTY} | NONE
${source} | Run Keyword Unless | '@{result}[0]'=='PASS' | Get Source

先去Ignore掉Wait Until Keyword Succeeds的錯誤，如果有錯的話再執行Get Source即可log html下來。

阿兩的筆記本 Ryoutsu's Notebook

搜尋此網誌