2011-01-14 228 views
3

在我們的QA團隊中,我們針對開發人員所做的每項提交都運行一套自動化測試。由於每天有很多這樣的提交,並且沒有開發人員想要等待超過幾分鐘才能獲得反饋,所以我們僅限於5分鐘的測試。在這5分鐘內,我們想要運行儘可能多的測試。測試網站的最佳實踐

我們發現硒測試對我們的需求是最好的:主要是因爲它們是可靠的。如果硒測試報告JS錯誤,你95%確定這是一個真正的錯誤。 (這是我們從使用HTMLUnit的經驗中學到的一個非常重要的屬性)。然而,運行硒測試是緩慢和沉重的。 (我們維護一個小CPU場,以便我們可以異步運行許多硒服務器和許多腳本)。

最近我們提出了一種新的方法 - 只在你真正需要的地方使用硒:彈出窗口,ajax,一般的JS ..在其他地方使用「文本瀏覽器」。例如,如果要檢查以下鏈接「作品」:

<a href='/somewhere'> link </a> 

你並不真正需要的硒。你可以執行GET請求到頁面,然後使用正則表達式/解析頁面並使用xpath/..底線 - 你不需要JS引擎。顯然這是一個更輕,更快的測試。

我們已經有很多成功使用這種方法,我們碰到了以下幾個環節:

<a href='/somewhere-1' onclick="foo()" > link 1 </a> 
<a href='/somewhere-2' onclick="foo()" > link 2 </a> 
... many more such links ... 

因此,在這種情況下,你真的沒有來運行按下每一個環節硒腳本。只需點擊其中一個使用硒(這樣你就可以測試JS功能foo()的功能),然後使用文本瀏覽器來驗證其他鏈接的href

我的問題是你認爲我們應該在哪裏畫線?我很樂意聽到你的意見 - 有沒有「文本瀏覽器」工具(我們沒有與WebDriver合作)?

回答

1

這聽起來像是我在做什麼和我期望開發人員做的事情之間的界限有點​​模糊。

在我看來,開發者應該對他的foo()函數進行單元測試。 TDD in Javascript在工具支持上有點低,但應該發生。

如果函數是單元測試,那麼硒就成爲了更多的測試用戶需求的地方,而不是代碼級別的單元。

也就是說,質量保證和開發團隊之間的交互在社交上非常複雜,並且可能很難得到同意遵循這種方法。