黃瓜+硒：功能測試和測試內容

Question

我是前端開發人員，目前我在一家公司工作，我們正在自動化我們的多語言網站。我們實施了句子來模擬使用平臺的服務，代表用戶行爲的句子以及其他句子，以根據行動來檢查內容。

我會問這些最後提到的句子。我們的架構團隊已決定使用以下語句做功能： '在頁面中必須顯示文本「acme city sample」'

如果你看，這個句子不會討論頁面的任何元素。如果該文本存在於頁面的任何位置，則測試將成立。架構師不喜歡使用任何類型的CSS選擇器來定位元素，因爲他們說這是一個功能測試，我們只測試我們能夠在瀏覽器的輸出中看到的元素。所以，所有類型的選擇器的引用都是禁止的。我們只使用xpath來查找包含所需文本的元素，然後檢查是否顯示了這些元素。捍衛這一觀點的另一個原因是，這樣可以減少網站項目和自動化項目之間的耦合。

但是，這個決定對我來說似乎太嚴格了。例如，檢查按某些標準排序的內容很困難。

但是我想知道您對此有何看法，如果您有其他經驗，他們是如何使用測試網站內容的？但是，如果您認爲這是一個很好的決定，我會有興趣閱讀一些參考或文章來理解，因爲這是測試內容的最佳方式。

Answer 1

所以這裏有幾個問題需要解決。

工具語言

在它必須顯示在網頁德文本「極致城市樣本」

我想這意味着你的黃瓜腳本equivilent看起來是這樣的：

Then In the page it must displayed de text "acme city sample" 

（如果情況並非如此，請告訴我，我會更正它 這不是編寫BDD語句的正確方法。在BDD中，您希望將一般行爲映射爲與具體的「實現語言」相對立。一個更好的書寫方式是：

Then I should receive information relevant to "acme city sample" 

這樣你就可以從任何實現中解耦你的預期輸出。以這種方式，如果預期的輸出從文本變爲，可以說，一個圖像。你的最終用戶的總體行爲沒有改變，只是他們如何消費信息。所以我會建議先刪除所有的實現語言。實現語言的

的例子是：

• 點擊
• 類型
• 選擇
• 移動

有可能是，你仍然需要使用這些情況，但在一般避免它們。

避免了XPath

我已經看到了很多人的喜好都選擇某種原因做到這一點，我永遠無法真正理解爲什麼。首先使用CSS選擇器，您可以像xpath一樣執行，並且效率更高。如果可能，我會考慮這樣做。

我們只測試我們能夠在瀏覽器的輸出中看到。

-

另一個原因捍衛這種觀點是，這樣你 降低了網站項目及自動化項目 之間的耦合。

這不是不使用選擇器的原因。 XPath仍然是一個選擇器。我假設你正在這樣做，以快速找到頁面上的文字。假設你知道100％，你永遠不會得到誤報，那麼我可以理解你爲什麼這樣做，但明白這不會減少耦合。如果您的驗收標準從文本更改爲圖片，會發生什麼情況？您的測試將始終與該項目相結合，這是沒有辦法的。你需要問自己的是，使用xpath只會給我一個我親身感受的結果，並且根據需要很容易實現或更改。它是否覆蓋了我們之前編寫的驗收標準？