敏捷中的自動化是非常關鍵的。
想想在每個Sprint中添加和交付的許多特性。必須有一種方法來確保新添加的特性不會影響現有功能。
由於短跑持續時間較短，因此幾乎不可能在每次產品在Sprint末端增加時執行整個套裝。擁有一套自動測試服肯定會在這裏扮演更重要的角色。
然而，引入自動化並使其成熟肯定需要一段時間。從長遠來看，在規劃和設計自動化活動方面進行初步投資肯定會有回報。
在敏捷中自動化什麼？
每當我們計劃在我們的項目中引入自動化時，我們中的大多數人都會立即投票選擇“煙霧測試服”或“迴歸測試服”爲最佳選擇。自動化候選。當然，他們是，但當我們想到自動化測試金字塔，我們可以得出結論，這只是金字塔的頂層，我們正在談論。
除了上面的層，我們還有服務層而單位層更重要的是。
那麼，除了吸菸測試和迴歸測試之外，還有哪些測試可以成爲自動化的好選擇呢？
#1)構建和部署
在傳統環境中，我們有預定義的構建，可以每週，每兩週，有時甚至每月。原因之一是這些部署需要時間。這種方法的問題在於，我們必須等待預定義的日期才能修復bug或實現新特性，因此出現了延遲。
第二個原因是，當測試人員完成測試並發現錯誤和缺陷時，程序員已經轉向不同的實現部分，並且對解決舊應用程序的bug不太感興趣。這種方法還延遲了在生產中提供功能的時間。
構建和部署是重複的，有時甚至是無聊的實體。部署構建也需要幾個小時，這會延遲測試，並最終延遲反饋。作爲一個重複的任務，部署成爲自動化的一個很好的候選。
實現自動構建部署的幾個優點是：
沒有可能發生部署錯誤(可以避免人爲錯誤，例如複製不正確的文件或將文件複製到不正確的位置)。
bug/特性一旦修復就可以進行測試。
測試人員有更多的時間進行測試。
該功能可以在較短的時間內轉移到生產中。
快速反饋
#2)單元測試/組件測試
我已經討論過通過使用上一篇教程中的TDD方法.
這形成了金字塔的最低層，因此地基和任何基礎都需要堅固的岩石。開發團隊應該協作並共同工作，以便將大部分測試納入這一層。
#3)API/Web服務測試
Web服務是兩個應用程序在請求和響應方面交換數據或信息的媒介，而不涉及底層體系結構或技術。用更簡單的術語來說-發出請求和驗證響應是我們通常在Web服務測試中所做的事情。
測試web服務需要編寫程序來調用那些Web服務方法，並驗證它返回的值/s。我們甚至可以測試各種排列和組合的服務。擁有Excel表中的所有測試數據，您的程序就可以讀取數據，並通過傳遞測試數據作爲參數調用可測試服務，並驗證結果。
這種特殊的測試是金字塔中間層的一部分。大多數功能測試都可以被推入這一層。解決這個層中出現的缺陷變得很容易，並且它們不會被推遲到UI可用。
#4)GUI背後的測試
相對來說，自動化GUI後面的測試要比自動化實際的GUI容易得多。另一個優點是，無論UI更改如何，功能都保持不變。即使某些UI元素被更改，特性的功能也不會改變。這種技術主要關注業務邏輯和規則。
測試用例大多是用表格格式或電子表格編寫的，並編寫了接受來自這些表的輸入並返回結果的補丁/代碼片段。結果會立即生成，併爲非技術利益相關者運行這些測試並獲得預期結果提供了一個很好的平臺。實現此技術的工具之一是菲尼斯.
#5)非功能性測試
這，這個非功能測試技術基本上包括負荷、性能和壓力測試。市場上有各種各樣的工具可以用於自動化這些測試。
#6)數據比較
我們的許多測試要求我們比較數據文件，包括文本文件、csv或excel文件。
可以將這些文件與進行數據驗證的基線進行比較。
比較可以是相同的數據，但格式不同。當我們從兩個不同的源生成兩個相同的文件時，這種情況基本上就會發生。
這些比較可能是重複的，因此是自動化的。
#7)搜索
從大量的文件中尋找一個特定的實體也可能很乏味，如果這是一項重複的任務，上帝會幫助我們。一個例子是搜索日誌文件。如果這也是一項繁瑣和重複的任務，那麼我們應該考慮將其自動化。
#8)重複任務
任何從與最終用戶交互開始的任務，或者編寫開發它的故事，如果是重複的，都應該在自動化中考慮。我們應該理解，自動化並不意味着必須有一個複雜的工具/技術參與其中。它可以是一個簡單的VB宏，也可以是一個帶有Javascript的Java程序來解決這個問題。
從哪裏開始？
沒有一個要點或一步的指南來說明從哪裏開始自動化。爲團隊啓動自動化需要您集思廣益，並對您想要自動化的方面進行深入的思考，或者自動化的最終目標是什麼？
你可以從以下幾個方面着手：
找出重複的任務，
識別應用程序的疼痛區域
確定測試挑戰
如果您在旅遊項目/團隊中沒有自動化，那麼您可能會選擇一種多層的方法，在這種方法中，單元測試可以首先成爲自動化的目標。這會給你最高的投資回報。
同時，測試人員可以開始進行煙霧測試，然後進行迴歸。一旦團隊獲得了技能並感到舒服，就逐步轉向自動化其他重複任務。
在沒有評估你的需求的情況下，不要直接購買新工具。正如我前面所說，一個簡單的程序或宏可以解決您自動化一些重複任務的目的。所以，在決定買工具之前，做POC並評估該工具是否有效使用。
請閱讀這些文檔，在這些文檔中，我提供了更多關於如何爲自動化選擇正確的測試用例的詳細信息，並在下面的文章中提供了一些關於評估自動化工作的見解。 自動化測試過程的挑戰和硒自動化項目的試驗評估。
一旦最終確定了自動化和工具的範圍，接下來就是設計框架。
記住，在敏捷中，框架是進化的。不要先設計整個框架，然後再實現。設計和實現MVP(最低可行產品)，然後加強現有的框架，以包括更多的功能。如果您希望您的自動化套件是健壯的，您還需要應用良好的編碼和開發實踐。
一些最佳做法
不要一蹴而就的目標是100%的自動化。從小開始。記住，這是一個不斷髮展的過程。
遵循與任何軟件開發相同的敏捷實踐。自動化還需要適當的規劃和設計。當你自動化的時候，你不會想增加你的技術債務。
創建測試自動化待辦事項表。這個待辦事項可以從實現新特性到增強現有特性。給你確定的項目的故事點，並相應地分配它。將這些待辦事項帶到您的Sprint中，並使用看板跟蹤它
爲您的自動化故事編寫驗收標準。這些接受標準可包括：
測試套件與CI的集成
將西裝移植到一個集中的位置
通過電子郵件發送結果
提供在測試失敗時發送錯誤日誌文件
任何其他標準…。
不要花費過多的時間來評估一個新的工具。您可以創建一個優先級清單，列出您希望從新工具中得到的內容，並確定評估它的時間表。如果您沒有在規定的時間內看到您的結果，請轉到下一個。
對什麼是自動化做出明智的決定。並不是每一塊自動化都是有效的，併產生積極的投資回報率。不要僅僅爲了自動化而自動化。
利用適當的開發環境。不要將代碼保存在本地。有一個存儲庫來保存您的代碼，並養成在一天結束時檢查代碼的習慣。
以類似的方式，嘗試從一個集中的位置執行您的自動化測試。讓它成爲獨立的人。應該是團隊中的任何人都可以從他們的機器上觸發腳本，並通過電子郵件獲得結果。
可應用於自動化的敏捷原則是什麼？
一些非常簡單的建議：
保持簡單。做必要的事。我見過很多情況，我們交付糖衣的實現，這使得自動化不必要地複雜。讓我們避免那些不需要的東西
做簡單的事情並不意味着做最簡單的事情。這意味着採取初步的步驟來實現您的自動化目標。您可以使用一個簡單的特性來實現自動化，但是自動化的實現可能會發生複雜的情況。
應用整個團隊的方法。我相信每個人都是敏捷團隊中的測試員。我們不要只對測試人員或開發人員限制自動化工作。爲了實現項目的自動化，每個學科都必須互相取代。這種方法也能有效地解決執行過程中出現的任何技術問題。
該框架是在敏捷中發展而來的。。不要試圖提供太多可能不必要地使自動化部分變得複雜的特性。
花點時間把它做好。花些時間來正確地設計它以避免技術上的債務。
獲得頻繁反饋
應用適當的編碼標準和實踐。設計應該簡單，應用OOPS的概念，並試圖保持測試相互獨立。考慮一下試衣的“可維護性”等因素。
在敏捷自動化過程中，我看到了什麼挑戰嗎？
敏捷世界中的自動化本身的挑戰:
我們得好好計劃。確定合適的測試套件、工具、框架和方法，都需要一個適當的策略。然而，我們應該記住不要過度計劃。記住MVP(最小可行產品)
降低代碼的質量，因爲我們想要快速交付：我們必須記住，技術債務在自動化中也佔有很好的地位。
大多數情況下，團隊不遵循“整體團隊方法”，而是將整個編碼和維護自動化套件的責任留給測試人員，這就增加了測試人員的責任。
自動化功能測試比自動化UI更困難。
在所有這些挑戰中，最關鍵的挑戰是提升測試人員的技能。
爲團隊執行和維護自動化幾乎就像程序員(開發人員)所做的編程(開發)活動。不僅是實現，而且集成自動化適應到CI是重要的，並要求測試人員學習和採用新的技能，學習新的工具和技術。
一些適合敏捷的開源工具
硒WebDriver-用於UI
硒柵-並行執行
黃瓜-用於BDD
JMeter-性能測試
蘇普伊-網絡服務
當Web服務不可用時，WireMock-Web服務測試。
Appium-用於移動
讓我以著名的敏捷測試象限結束：
象限1是單元和組件測試，可以通過TDD方法實現自動化。
象限2討論功能測試，在那裏我們可以應用BDD方法。
象限3是唯一有手動測試範圍的象限。
象限4主要討論一些工具可以實現的測試。它負責負載測試、壓力測試、卷測試和安全性測試。
結語
除了煙霧測試和迴歸測試之外，還有很多自動化的範圍。因此，我們必須打破僅限於這些類型的測試的自動化的概念，這反過來意味着敏捷測試人員的技能集不僅僅需要找到bug和缺陷。
測試人員需要更多的協作和提高他們的編程/自動化技能。如果越來越多的測試是自動化的，這將給測試人員更多的時間來參與更復雜和更具挑戰性的任務。
如果有什麼想法或者意見歡迎大家來我們羣：1192893289 一起交流一起學習一起進步