網際網路時代，自動化測試勢不可擋，你還在討論如何做好功能測試？

很多團隊都傾向於認為自動化是一種加速軟體交付的方式，因為這是團隊內部經常能夠感知到的瓶頸。但是，如果他們將自己的開發實踐過程當作一個整體來深入研究的話，那麼他們會得到更好的結果。

一、如何預防 BUGS？

測試，尤其是 UI 層面的自動化測試，通常會被安排在軟體交付週期的最末端，通常會試圖發現一些可能進入生產環境並給終端使用者造成不良影響的 bug（這些 bug 就如同細菌一般）。在這種情況下進行的測試可以探測出 bug 的症狀，開發人員進行的修復就是治療。這就如同我們在等待我們的系統生病併為此採取一些措施。

這種方法對於團隊來說是有一定的效果，但是，現在的工作環境迫使我們用更少的人做更多的事並且要比以往更快地完成任務。因此，這種方法並不能長期可持續地運轉。這時基於預防的方法而非治療的方法就橫空出世了。

透過對如何構建系統作出調整，我們就可以在故障發生之前探測出問題，或者更好的是，讓他們從一開始就不那麼容易產生 bug(這就是所謂的“預防”)。這就意味著我們在 bug 產生前就預防它的發生而非試圖在 bug 產生後再治療它。古語有云：預防勝於治療！

二、我們的測試自動化之旅

在我剛開始加入移動團隊（該團隊負責建立並管理公司的點播產品）時，我們所有的測試都是手工執行的，平均每年我們只在每個平臺上釋出 2 到 3 次。我們知道如果想要加快速度，最明顯的瓶頸就是測試。

在沒有發現新 bug 的情況下，每個迴歸測試周期要花費將近兩週的時間。如果發現了新 bug，那麼開發團隊需要時間理解並確認 bug，確定一個修復方案，然後再應用這個方案。這會導致已經執行的任何測試都變得無效，因此需要重新啟動測試過程，最終導致測試周期花費兩倍以上的時間。

因此，我們開始著眼於將更多的 UI 測試進行自動化處理。我們總是從小的方面開始改變看看這樣的嘗試能否將我們引入我們想要的正確的方向上，並且我們只選擇對新功能進行自動化測試。這種嘗試一旦被證實是有效的，我們就會將自動化測試引入到現存系統的其他領域或者已知的問題領域。

我們組織 3 個朋友作為一個團隊來理解我們想要構建什麼，以及該特性的關鍵接受標準應該是什麼。這為我們提供了一個起點，讓我們瞭解如何分解該特性以及哪些使用者場景需要自動化。

在此基礎上，我們確定了可以用來自動化測試的工具(Calabash 和 Appium)，並在實際環境中應用它們。對我們來說，這是在真實的手機上進行測試，而不是模擬器，為此我們建立了自己的裝置測試場以更好地利用我們的移動裝置，同時也允許它擴大規模以期能夠在整個組織中得到應用。

三、自動化測試帶給我們的好處

起初，自動化給我們帶來了很大的幫助：透過自動化我們可以快速可靠地執行簡單場景的測試用例並迅速得到我們想要的反饋結果。但是隨著時間的推移，在最初的一批bug 被捕獲之後，自動化測試很難再發現新的 bug 了，除非我們手動地修改自動化用例程式碼。

同時，我們也注意到由於某些場景我們無法自動化導致一些 bug 依然存在於系統之中：比如，任何與可用性相關的功能都不得不進行手工測試。

因此，我們最終採取了一種混合的解決方案---自動化用來快速跑一些關鍵場景，讓團隊知道自動化測試沒有明顯地破壞任何東西，以及如果合適的話對任何新功能進行的探索性測試也可以自動化處理。因此，嘗試自動化測試的過程是曲折的，我們在嘗試測試時很容易出錯，又或者手工測試花費的時間太長。

帶給我們自動化之旅的一個意料之外的好處就是我們開始更快地釋出產品，自動化讓我們更加專注於我們正在嘗試完成的工作事項。這就讓我們可以將每一個新特性新功能拆分成更加細小的分支（可以獨立執行的分支）並將這些分支進行自動化測試。

這使得我們可以更快地將各個分支釋出到生產環境中並從終端使用者處得到實時的反饋。起初這一好處並不明顯，因為我們仍在嘗試著識別自動化場景。只有在事後，團隊才能看到這是他們無意中所做的事情帶來的價值。簡單地說，我們開始將工作分解為一小批終端使用者價值。

四、研究我們的開發模式

我們開始意識到 UI 自動化測試並沒有真正帶給我們想要的回報。正因為如此，我們開始研究開發過程中的其他領域，看看是否可以做出些許改進。但作為一個團隊，我們的問題之一是，我們太過接近流程，以至於無法客觀地看到哪些是有效的，哪些是無效的。為了克服這個問題，我們請來了一位敏捷教練來幫助我們的團隊。事實上，我們引入了兩位教練：一個是幫助團隊理解他們正在使用的流程，另一個是幫助我們更好地理解我們實際上是如何構建我們的系統的。

敏捷教練都來自於團隊外部，因而他們可以質疑我們系統的任一部分，而不用擔心冒犯任何人。他們會問一些簡單的問題，讓我們瞭解我們工作方法背後的原因，並將我們從“我們一直都是這樣做的”迴圈中解脫出來。例如，用於管理我們工作的 stand upboard 通常有 backlog、next、dev、wait - For -test、in test and done 等列，但是我們從來沒有想過要問為什麼我們有 next 和 wait - For -test 列。

我們的教練能夠提供幫助的是：我們為什麼要將軟體開發工作分解成這些小項，為什麼開發和測試被視為兩個不同的活動。教練的方法並不是簡單地改變我們的開發過程，但他們能幫助我們明白問題的根源在哪(未釋出的功能卡放在任務看板的 next 和 wait-for-test 列)，讓團隊看到透過消除開發和測試列（next 和 wait-for-test），取而代之的是一個簡單的正在進行（in-progress）的列，很多工作依然可以順利進行。您可以在我的文章 In test colum 中找到更多關於使用這種方法的好處.

五、我們學到了什麼

我們發現的最大問題是：就敏捷開發實踐而言，我們的團隊中存在“形式主義”。僅僅因為我們有 standups（站會），以小團隊的形式工作，並在 sprint 結束時釋出東西，但並不意味著我們實際上是敏捷的。這只是意味著我們有一些儀式，讓我們看起來像“敏捷”。事實證明，並不是每個人都很清楚我們為什麼要這麼做，甚至不清楚我們這樣做的好處是什麼。

我們所做的第一件事就是澄清什麼是敏捷：它更多的是基於客觀反饋的可持續軟體交付過程，而不是試圖儘可能快地釋出你所能釋出的任何東西並期望最好的結果。我們透過讀書俱樂部促進團隊討論來實現團隊內部對於“敏捷”一詞達成一致的理解。這有助於團隊成員更好地掌握敏捷實踐背後的原則，並在他們的工作中做出更好的決策。

我們還開始研究我們實際上是如何在程式碼級別構建系統的，並試圖將開發人員在如何提交程式碼、提交的頻率和提交的大小這些內容視覺化。這並不是試圖讓開發人員難堪，而是幫助他們理解作為一個團隊，他們是如何影響程式碼庫的，並試圖鼓勵開發人員養成更高效的習慣；比如對於較小的、有重點的任務進行提交，而不是在一天結束時的一次性提交大量的程式碼。如果他們確實做了大量的提交，那也可以，但是要讓其他開發人員知道他們為什麼這樣做，來促進團隊成員間相互學習。

我們對團隊最大的改變之一是鼓勵結對程式設計，因此沒有一個開發人員單獨開發一個特性。這加快了程式碼評審的速度，但他們也不太可能相互推卸責任。比起在某些專案中僅由資深成員來審查程式碼而言，結對程式設計還有助於更快地提高我們團隊中較年輕成員的技能和知識，使他們能快速地提高生產力。

六、為了擁有更加高效健康的開發模式，我的一些建議

在團隊工作中，需要在這個團隊中確定一個高效、健康的開發流程。一個行之有效的方法是建立一個團隊影片俱樂部。這允許成員從日常活動中抽出一些時間來學習構建軟體的新工具或新方法。在每次會議結束時，團隊討論都由會議負責人(專案經理、技術負責人或將想法帶給團隊的人)推動，來探索如何使用這些概念來幫助團隊嘗試新事物。

然後選擇一個概念，並對結果應該是什麼有一個清晰的想法。我們以更好的單元測試為例，單元測試對團隊意味著什麼?更好的單元測試會給團隊帶來什麼？一旦你有了這些答案，你就可以想出多種方法來達到這個目的，這樣你就可以選擇一個可以讓你快速而客觀地見證結果的方法。

你需要弄清楚，你所使用的新過程或新技術是否真的幫助你在規定的時間內實現了你的目標。如果是這樣，那就太好了。如果沒有，你需要停止嗎？做更多調整嗎？您還需要決定誰將實際進行這一嘗試，以及他們將如何與團隊的其他成員進行溝通。

記住，如果你想讓任何新流程或想法在團隊中站穩腳跟，那麼團隊中每個人都需要參與其中；否則，遇到的第一個困難就是，這個想法將停止或緩慢執行，因為只有參與嘗試的人才能從中有所收穫。

加我VX：ww-51testing   回覆關鍵詞“測試”領取限量軟體測試學習資料哦~~