直接使用Selenium RC或機器人框架使用Selenium

我不得不承認，我愛上了Selenium，因爲它的記錄和播放功能以及來自IDE的記錄操作的測試用例生成功能。但我還是猶豫了一下推進到實施階段由於偶然細節（例如，定位與DOM事件，xpath..etc），它們在錄製過程中內置到測試用例，這可能使測試用例易出故障時一旦它被導入到RC，就會發生html更改。我完全理解這是測試人員的工作中的一部分，作爲迴歸測試的一部分，不時調整預期結果，但我也不希望花費在此上的時間比進行手動測試所需的時間更長。直接使用Selenium RC或機器人框架使用Selenium

據我所知硒與機器人框架具有測試案例的關鍵字形式。我的猜測是它允許我們將附帶的細節提取到各種關鍵字中，這可能會使測試用例更容易調整並且更易於維護。（請糾正我，如果我錯了）

可以理解的，聽取有效的UI自動化環境中應該如何設置建議。我應該使用Selenium RC還是Selenium與Robot框架？爲什麼？

在此先感謝

來源

2011-02-04 Daniel

或者，任何人使用sikuli？它如何與硒元素比較？測試箱可以輕鬆整合到測試跑步者身上嗎？ – Daniel 2011-02-18 19:23:05

你是絕對正確的，在製作腳本附帶且多變的細節是記錄和回放自動化的最大的問題。記錄後，您可以明顯地從腳本中刪除細節，但在我看來，最好從一開始就手動構建可重用的庫和代碼腳本。

使用「真正」的編程語言編碼的腳本一個很好的選擇是使用你提到的一些更高水平的自動化框架，如Robot Framework。正如你推測的那樣，Robot的可重用關鍵字和變量使得從測試中提取細節變得非常簡單。 SeleniumLibrary's demo中的測試案例很好地說明了這一點，演示還展示瞭如何通過Robot使用Selenium。

您還詢問過有關Sikuli的問題。我從來沒有用過它，但它確實看起來很有趣。您可能對this great how-to感興趣，它解釋瞭如何通過Robot Framework使用它。

來源

2011-03-09 14:16:09

公司正在使用FitNesse的，不是機器人，但控制硒，我們有同樣的問題。我們從對DOM做出假設轉換爲僅通過ID訪問元素。由於這在Fitnesse中很麻煩，我們目前正在努力將Selenium後端添加到我們自己的Framework（以前只有Java和Smalltalk的後端）。

因此，通過要求與某個ID的元素存在於DOM我們當然會打破我們的測試中，如果有人將刪除頁面中的元素;然而，我們發現這種行爲是非常有用的，因爲這會強制執行與實施進行的測試的合同，並且一旦有人破壞實施，我們發現缺少元素是件好事。

此外，它是很好的做法，以保持UI自動化膚淺：只考什麼存在與硒的網頁上，並直接調用底層的功能測試業務邏輯。

來源

2011-02-23 18:01:48

糾正我，如果我錯了，聽起來像你的公司強迫Web開發人員將ID的元素標籤。而且，如果ID是測試人員和開發人員之間的合同，這將大大降低在測試用例中引入偶發事件的風險。而且，修復它所花的時間確實是因爲需求的改變。請問我們公司的QA工程師如何使用Selenium IDE或簡單地編寫代碼生成他們的測試用例。這個選項相對於其他選項有什麼好處。期待你的回覆。謝謝 – Daniel 2011-02-25 03:33:17

是的，我們使用ID的每個DOM元素。但這些可以自動生成，開發人員和測試人員可以很容易地找到它們，因爲它們被粘貼到原始html中（沒有間接的，這只是爲了我們的測試不是爲了外部消費）。一旦測試人員擁有一個ID，他不需要再導航DOM樹，但可以按ID選擇並編寫一個表格形式的測試用例，如| 123 | contains | asdf |，並且如果其中一個測試表注意到錯誤，測試套件可以將元素ID提供給立即知道他們分手的確切位置的開發人員。 – 2011-02-25 11:22:16

直接使用Selenium RC或機器人框架使用Selenium

回答

相關問題