當提到可接受的測試自動化，最重要的一步是在適當的位置有一個適當的測試自動化團隊框架。這篇文章對一些不同的自動化測試適用場景有一些已證明的項目——由一個自動化或者回歸團隊主導，以敏捷的適應性——幫助組織享受長期的測試自動化的成功。

公司發起一項新的測試自動化倡議——任何銷售人員設計銷售相關的工具——傾向認為他們的成功取決于完美的上線。作為一個測試自動化顧問，我喜歡提供一個真實的基于我在領域里所見的檢查。如果你沒有準備好，最初的上線可能是坎坷崎嶇的路，但是在長期中，那不是要制造而是破壞你的測試自動化倡議。

近來我親眼看到一些公司沒有準備就開始出現測試自動化。執行這個“策略”的風險是測試者們可能要因為這些原因堅持測試自動化：

• 他們覺得沒有它生活得很好
• 他們不想要（或沒有時間）學習新工具
• 他們擔心它太復雜而且需要獲取跟上進度的努力超過了感知到的好處

一個不充分的計劃——或者完全不計劃——上線很明顯不是最好的發起一個測試自動化倡議的最好方法。無論如何，我發現了從堅固的上線中恢復比沒有一個恰當的測試自動化退隊結構而去獲得持續的測試自動化來得簡單些。

我喜歡去為一些不同的測試自動化采用場景去分享一些已證明的實踐，幫助了很多機構享受長期的成功——甚至當最初的上線不理想時。

自動化團隊正一個接一個項目地上線我們的測試自動化

?

??

我能提供的最好一條建議是從小事開始，然后做大的。已證明的第一個實踐是從創建自動化團隊開始。

這個團隊將從不同的項目迭代并且開始從最重要的測試用例起自動化。這讓你證明在倡議中的進度并且讓你看到了一些應用程序的改變如何影響主應用程序功能性。

我建議從最有影響力的測試用例開始：覆蓋你的頭等業務風險的那些。這創造了強有力的回歸文件夾的建立，它提供了最快的應用程序變化是否先破壞了正在工作的功能的反饋。

自動化團隊應該包含至少一位測試設計專家，他通過回顧需求并使用測試用例設計方法制定出應該被自動化的測試用例。然后，測試設計專家或者兩個或三個自動化專家中的一位能評估是否需要測試數據管理，然后他們能合作指定測試用例。同時，測試設計專家將關注下一個項目。

取決于你想要測試的軟件以及你定制它多少，一個自動化工程師是必要的。他們將確保常規的控制被創建然后被維護。

團隊的大小將會隨著擴大，取決于測試用例和團隊處理的項目的數量。這些建議只是為了最初的上線。一旦上線開始進行，你們將會想開始招募盡可能多的人員。

一旦測試用例被自動化，他們能通宵在虛擬機上運行，然后在日常基礎上報告執行結果。為使測試自動化加入與運轉的最重要的事情是確實在執行測試用例！假如你不是正執行你的用例，你不會從它們得到任何價值，不論你的測試集設計得如何好并且它如何好地覆蓋你的主要業務風險。

取決于你的公司架構（敏捷或不是，測試團隊或者獨立的測試員們），自動化團隊可能主要以教導每個人關于上線自動化最佳實踐的實施以及當他們開始他們自己的測試自動化時的需要考慮的項目多樣性為主。

在測試人員開始采用測試自動化之前，必須做個決定：誰負責這些測試用例？這是主要的。假如自動化團隊（或者后來回歸團隊）是負責的，然后他們不得不與測試人員們和商務方面做更多的溝通。假如它是測試員們的的責任，他們需要足夠的時間去保證所有的測試用例在執行并且符合業務需求。每一個組織需要去決定什么是對他們最好的，取決于他們的架構和工作模式。

不管你負責哪個方向，確保節約足夠的時間來溝通。一方面，新的測試用例需要被回歸團隊審核然后為執行而創建。另一方面，回歸測試結果（尤其失敗的測試用例）需要被共享使得負責的團隊成員或者測試員們能審查它們并必要時更新測試。至少，確保測試員們獨立地檢查回歸結果并做合適的調整，這樣回歸團隊能從共享文件夾里推出新的測試用例，自己審核它們。

回歸團隊在每個項目上領導和指導測試員們

?

?

?我所見過的最有效率的設置是建立一支初始的自動化團隊，它包含一個回歸團隊，一旦測試自動化基金會被成立，其他就要準備驅動它向前。

回歸團隊仍然為在最初的項目里創建測試用例負責，維護存在的測試用例，執行測試用例，保護測試架構，并且監督拓寬的測試自動化建立和項目。你能把這個團隊叫做優秀測試中心。

關于這個建立，可能有項目和更大的改變由測試設計專家指導著，他關注正確的格式并提供它應該看起來像什么的預覽。他們就像軟件藝術家（或者以我們為例，測試藝術家）。

回歸團隊是“定位群”，假如你有關于問題的疑問或者你想要引進新的創新。所有者和責任應該應該是回歸團隊的，因為他們有測試文件夾的最好概覽。

從一個資源的角度，你在回歸團隊里需要高技能的人，但是你能僥幸逃離經驗少的作為測試員的團隊成員。假如測試員們需要比培訓提供的更多的知識，他們能經常問回歸團隊，他們然后能通過共享他們建立起的知識提供幫助。

敏捷環境的適應

對于敏捷團隊，測試自動化被團隊里的敏捷測試員驅動。這個人應該比一個自動化專家更先進——他們需要理解測試用例設計、需求、測試用例創作和執行，以及核心的測試最佳實踐，并且他們需要一個測試什么以及如何有效測試它的好的理解。

我建議一個開發和測試從一個Sprint到另一個Sprint持續的建立：

?

?

?

?

當開發結束了Sprint n-1的特性，測試開始。同時，開發能持續特性2（Sprint n），等等。只是確保為修復bug和更深入改進保留時間。

我們分離開發和測試嗎？

最后，當談到架構，我想要給頻繁發生的一對問題增加我的兩分錢：我們的開發需要測試嗎，或者我們需要分離開發和測試嗎？我們在測試中使用軟件開發工程師（簡稱SDETs）嗎？

理論上，你也可以通過有開發測試來節約時間和金錢因為開發最知道代碼。但是實話實說：開發從沒有足夠的時間去完成每個人想要完成的開發任務。假如他們也為測試自動化負責，那意味著他們甚至沒有時間去完成那些任務。而且即使開發們最知道代碼，你確定他們能檢查邊界條件嗎？預計風險并嘗試詢問合適的問題？探究系統并把它推向失敗？

我的意見是有些人不寫代碼更適合做這個。那些其他人關注于通過應用程序獲取實際的業務目標并嘗試思考每一個能導向系統一個錯誤的指導的可能性。從我所在領域里見過的，那通常不是一個開發的強項。

旋轉桌子

所有這些建議是基于我的幫助用戶適應測試自動化的個人經驗。我知道每個讀者可能有關于這的不同觀點——而且我鼓勵你在下面去分享關于它的想法。什么幫助你最多了？你如何在你的公司建立測試自動化？你面對的挑戰是什么？

轉載于:https://www.cnblogs.com/fengye151/p/11519115.html

總結

以上是生活随笔為你收集整理的为了可持续的测试自动化，透过表面看本质（译）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。