五分之四的 QA 申請人希望學習如何使用自動化測試。 並不是所有公司都能在工作時間內滿足手工測試人員的這種願望。 Wrike 為員工舉辦了一所自動化學校，並實現了許多人的願望。 我正是作為一名 QA 學生參加了這所學校。
我學會如何使用 Selenium，現在幾乎無需外部幫助即可獨立支援一定數量的自動測試。 並且，根據我們共同的經驗和我個人的結論，我將嘗試推導出最理想的自動化學校的公式。
賴克組織學校的經驗
當自動化學校的需求變得清晰時，它的組織就落到了自動化技術主管 Stas Davydov 的肩上。 除了他還有誰能解釋他們為什麼提出這個倡議、他們是否取得了成果以及他們是否後悔所花費的時間？ 讓我們請他發言：
— 2016 年，我們編寫了一個新的自動測試框架，並使編寫測試變得容易：出現了正常步驟，結構變得更容易理解。 我們提出了一個想法：我們需要讓每個想要編寫新測驗的人都參與進來，並且為了使其更容易理解，我們創建了一系列講座。 我們共同製定了一個主題計劃，每位未來的講師都為自己準備了一個主題並準備了一份報告。
——學生遇到了什麼困難？
——當然主要是建築。 關於我們的測試結構存在許多問題。 在回饋中，關於這個主題的文章很多，我們不得不舉辦額外的講座來更詳細地解釋。
——學校有回報嗎？
- 當然是。 多虧了她，很多人都參與了測試的編寫，平均而言，在醫院裡，每個人都開始更好地了解自動測試是什麼，它們是如何編寫的以及如何啟動的。 自動化工程師的負擔也減輕了：我們現在收到的分析測試幫助請求減少了很多倍，因為測試人員和開發人員已經開始在幾乎所有情況下自己處理這個問題。 嗯，該部門有幾個內部優勢：我們在演示和講座方面獲得了經驗，因此一些自動化工程師已經成功地在會議上進行了演示，並且還收到了一套針對新手入職的強大視頻和演示文稿。
我謹代表我個人補充一點，我們各部門之間的溝通已經簡化到了極為簡單的程度。 例如，現在我幾乎不需要考慮哪些情況以及在什麼層次的原子性上進行自動化。 因此，所有感興趣的各方都在全力關注不斷增長的測試覆蓋率。 沒有人向別人要求不可能的事。
總的來說，這對團隊工作的影響絕對是正面的。 也許閱讀這篇文章的同事也在考慮做類似的事情？ 那麼建議很簡單：如果自動化測試是您的優先事項，那麼這是值得的。 接下來，我們將討論一個更複雜的問題：如何盡可能正確地組織這一切，使各方成本最小，產出最大。
組織技巧
學校很有用，但正如斯塔斯所承認的那樣，存在一些困難，因此有必要安排額外的講座。 作為一名最近的學生，我在比較我自己（無知的情況下）和現在的我自己時，制定了以下步驟，以創建我認為的教導測試人員理解自動化測試的理想方法。
步驟0.建立字典
當然，這一步不僅是 QA 所需要的。 但是，我想明確表示：自動化程式碼庫必須以可讀的形式儲存。 程式語言－尤其重要 語言，然後您就可以開始潛水了。
這是帶有元素名稱的任務視圖的螢幕截圖。 讓我們想像一下，您正在將任務視圖作為黑盒子進行測試，並且從未見過 Selenium。 這段程式碼有什麼作用？
（劇透 - 該任務被代表管理員透過休息刪除，然後我們看到流中有此記錄。）
僅此一步就使 QAA 和 QA 語言更加緊密地結合在一起。 自動化團隊更容易解釋運行結果；手動測試人員在創建案例上花費的精力更少：它們可以變得不那麼詳細。 不過，大家還是互相理解的。 我們甚至在實際訓練開始之前就收到了獎金。
步驟 1. 重複短語
讓我們繼續與語言進行比較。 當我們小時候學習說話時，我們並不是從字源學和語意學開始的。 我們重複“媽媽”、“買玩具”，但不會立即探究這些字的原始印歐語根源。 所以這裡是這樣的：如果不嘗試寫一些有用的東西，就沒有必要深入研究自動測試的技術特徵。
這聽起來有點違反直覺，但它確實有效。
在第一課中，值得介紹如何直接撰寫自動測驗的基礎。 我們幫助設定開發環境（在我的例子中是 Intellij IDEA），解釋使用現有步驟在現有類別中編寫另一個方法所需的最低語言規則。 我們和他們一起編寫一兩個測試，並給他們家庭作業，我將其格式化如下：從主分支中分支出來的一個分支，但已從中刪除了幾個測試。 僅保留了他們的描述。 我們要求測試人員恢復這些測試（當然不是透過 show diff）。
結果，傾聽並採取一切行動的人將能夠：
- 學習使用開發環境介面：建立分支、熱鍵、提交和推送；
- 掌握語言和類別結構的基礎：除了步驟之外，在哪裡插入註入、在哪裡導入、為什麼需要註釋、在那裡找到什麼樣的符號；
- 了解action、wait和check之間的區別，在哪裡使用什麼；
- 請注意自動測試和手動檢查之間的差異：在自動測試中，您可以拉取一個或另一個處理程序，而不是透過介面執行操作。 例如，直接向後端發送評論，而不是打開任務視圖、選擇輸入、鍵入文字並點擊「發送」按鈕；
- 制定下一步將要回答的問題。
最後一點非常重要。 這些答案很容易提前給出，但一個重要的教學原則是，沒有形成問題的答案不會被記住，並且在最終需要時不會被使用。
如果此時 QA 團隊的自動化工程師給他一個任務，讓他在戰鬥中編寫幾個測試，並允許他向他的分支提交子提交，那就太理想了。
不該給予的東西：
- 對開發環境的功能和程式語言本身有更深入的了解，只有在獨立處理分支時才需要這些知識。 它不會被記住，你必須解釋兩三次，但我們很重視自動化工程師的時間，對吧？ 範例：解決衝突、新增檔案、從頭開始建立類別、處理依賴項；
- 與 xpath 相關的一切。 嚴重地。 你需要單獨、一次、非常集中地談論它。
步驟 2. 仔細查看文法
讓我們記住步驟 #0 中的任務視圖螢幕截圖。 我們有一個名為 checkCommentWithTextExists 的步驟。 我們的測試人員已經了解此步驟的作用，我們可以查看該步驟的內部並對其進行一些分解。
裡面有以下內容：
onCommentBlock(userName).comment(expectedText).should(displayed());onCommentBlock 在哪裡
onCommonStreamPanel().commentBlock(userName);現在我們學會說的不是“買玩具”，而是“從 Detsky Mir 商店購買玩具，位於從頂部數第三個架子的藍色櫃子裡”。 有必要解釋一下，我們從較大的元素開始按順序指向一個元素（流 -> 帶有某個人的註釋的區塊 -> 該區塊中指定文字所在的部分）。
不，現在還不是討論 xpath 的時候。 只需簡單提一下，所有這些指令都是由它們描述的，並且繼承是透過它們進行的。 但我們需要談論所有這些匹配者和服務員；他們與此步驟具體相關，並且對於了解正在發生的事情是必要的。 但不要超載：你的學生稍後可以自己研究更複雜的斷言。 最有可能的是，should、waitUntil、displayed();、exist();、not(); 就足夠了。
作業很明顯：一個分支，其中刪除了一定數量的測驗所需的幾個步驟的內容。 讓測試人員恢復它們並使運行再次變得綠色。
另外，如果測試團隊的工作中不僅有新功能，還修復了一些bug，你可以要求他立即針對這些bug編寫測試並發布。 最有可能的是，所有元素都已被描述；僅可能缺少幾個步驟。 這將是一次完美的鍛鍊。
步驟 3. 完全沉浸
對於將繼續履行其直接職責的測試人員來說，盡可能完整。 最後，我們需要談談xpath。
首先我們要先明確一點，所有這些onCommentBlock和comment都是由他們來描述的。
合計：
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"故事的順序非常重要。 首先，我們採用任何現有的 xpath 並顯示元素標籤如何包含一個且僅一個元素。 接下來，我們將討論結構：何時需要使用 WebElement，以及何時需要為新元素建立單獨的檔案。 這將使您更好地理解繼承。
必須明確指出，單一元素是整個任務視圖，它包含一個子元素 - 整個流，其中包含一個子元素 - 單獨的註釋等。 子元素位於頁面上和自動測試框架結構中的父元素內部。
至此，觀眾應該已經牢牢地明白它們是如何繼承的，以及onCommentBlock的點號後面可以輸入什麼內容了。 至此，我們解釋了所有的運算子：/、//、.、[]等。 我們將有關使用的知識添加到負載中 @class 以及其他必要的東西。
學生應該明白如何這樣翻譯xpath。 鞏固——沒錯，就是作業。 我們刪除元素的描述，讓它們恢復測試的工作。
為什麼選擇這條特定的路徑？
我們不應該讓一個人擁有複雜的知識，但我們必須立即解釋一切，這是一個困難的兩難。 這條路徑將允許我們首先讓聽眾提出問題並且不理解某些內容，然後在下一刻回答它們。 如果你談論整個架構，那麼當分析步驟或xpath主題時，其中最重要的部分已經因為難以理解而被遺忘。
然而，你們中的一些人可能能夠分享如何進一步優化流程的經驗。 我很樂意在評論中閱讀類似的建議！
來源： www.habr.com