RobotFramework Keyword: Wait Something Keywords

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

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

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

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

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

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

# 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即可。

現在大部分應用程式都透過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取得訊息接著再去判斷,會是比較有效率的做法。

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

之前發現硬碟空間被測試報表佔用非常快,原因是在使用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下來。