實現自動化測試，首先不是一個技術問題

背景介紹

自動化常常是測試團隊首先想要建設的內容，因為自動化的好處是明顯的，但真正實現自動化測試的時候才發現，這條路上的「坑」比想像的多得多。想要少遇到這些「坑」，首先要用正確的姿勢打開「自動化」。

自動化常常是測試團隊首先想要做的技術建設，因為自動化的好處是明顯的：

這個工作輸出的成果—--工具、腳本框架、自動化用例都是可以長期重複使用的，是「實在」的、「可見」的成果。

自動化在質量守護和問題快速反饋上起了決定性的作用：大部分需要長期更新維護的軟體，都需要自動化能力幫助防止質量劣化、支持重構。

自動化幾乎是測試活動的終極形式：當某一類測試內容已經被研究透徹，形成了一定的規律和模式，那就可以進一步實現自動化測試。因而自動化也是團隊技術進步的標誌之一。

和測試設計一樣，研發團隊開始引入自動化測試的契機，常見的是兩種：

1、出問題了。比如測試周期太長，或者產品頻頻出現升級後老特性出錯。這時研發團隊通常會要求實現自動化測試。

2、有人有時間了。在項目間歇期，或者某個項目計劃不那麼緊迫的時間段，測試團隊自發的想要進行技術能力建設。

如果是出於第一種原因做自動化測試，方法不對，很容易「事與願違」。比如測試周期（或者說是測試效率），研發主管們的邏輯是，如果測試執行的事情機器做了，那麼人應該空出來了，或者相同的人可以做其他更多的事情了，那樣就可以「減員增效」。

而測試經理們真正做的時候就會發現，做自動化很難做到解放人力的地步，即使做到了，那也需要走非常長的路，很可能需要3年以上的時間，經歷過：

工具和架構成型生產自動化用例使之達到必要的覆蓋自動化與用例產生的足夠快開發者也能輕易使用開發者測試達到較高覆蓋遺留到專業測試團隊的缺陷減少需要的測試工作減少減員增效。

在這個過程中的大部分時候，測試團隊甚至需要更多的人。癥結在哪裡呢？現在的測試技術和工具還很難做到「新特性開發就緒的時候，自動化用例也就緒」，即使在使用MBT的團隊中，也只有部分場景能做到。大部分時候，由於介面和處理順序都是在最後關頭才確定的，自動化來不及適配。

又比如保證老特性質量，研發主管們的邏輯是，既然自動化主要是覆蓋老特性，那麼已經實現自動化的老特性，在「未來」的應用中就應該不再有問題。但是現實是：老革命總是遇到新問題。也許是和新特性組合起來會有問題，也許是修改了某個數據會影響到新特性，也許是用戶的使用方式比較特別升級後受到了影響，也許是某個參數有了新的可能取值。這些都不是僅僅依靠覆蓋老特性可以發現的。

如果是出於第二種原因做自動化測試，是不是就不用和研發主管溝通工作目標了呢？並不是，測試需要和研發主管們就工作價值達成一致，是因為實現自動化測試需要獲得研發各個角色的支持，比如：

1、需求工程師的支持，可以確保需求的變動第一時間通知到測試；

2、系統工程師的支持，可以幫助測試工程師明確哪些新、老特性是需要組合使用的；

3、開發主管的支持，可以確保對開發環節的規範性要求能落實。

因此，無論出於什麼原因，在啟動自動化測試建設的時候，就需要明確對於研發整體或測試環節而言，自動化將在成本、效率或質量上發揮什麼作用，自動化測試的目標絕不應該是「自動化率」。

自動化價值挖掘

測試自動化成功開展工作的要素中，技術是最根本的，如果根本沒有完成工作所需的技術手段，或者當前的技術手段應用成本太高、不可靠，那麼一切都是空談，這裡先假設技術不是問題。

大部分的研發經理心中，進度是第一位的，其次是成本，最後是質量，當然人員隊伍最好穩定。天下武功，唯快不破：進度>成本>質量>人。

大部分時候測試想做的事情是關乎質量的，有時候做些工具什麼的可能可以節約成本，或者可以從繁瑣的操作中抽身出來以便做些需要腦子的工作，而通常測試項目不會對進度太有利。前面已經提到，自動化測試要支持研發全面提速，有一個漫長的過程，絕不是一蹴而就的。

那麼，研發經理不關注質量嗎？應該不是，研發經理對質量的要求是有「底線的」：作為賣點的新特性，或者作為最基本能力的老特性不能正常使用；客戶蒙受損失（比如數據丟失）或退出服務的投訴較多；服務質量、性能明顯下降……

針對基本應用場景的自動化，目的就是防止底線失守。這是自動化的價值之一，不過，通常這類問題只在新產品中常見。

最後，我們是否將研發經理和測試經理的觀點看的太對立了？質量和進度有沒有可能統一？測試能否讓整個研發進程又快又高質量？讓上線過程又快又可控？讓客戶反饋又快又準確……

聽上去有點烏托邦，但是確實有自動化的相關概念就是為了達到這個目的的，耳熟能詳的比如CI、ATDD等。

在業界，也不乏幫助自動化服務於研發流程的案例，比如開發快速的構造測試用例；或者能夠讓使研發過程變成代碼提交後，全自動化驗證；或者可以用於產品上線後是否「健康」的在線自動檢測。

從零開始的自動化，這些價值看上去像是空中樓閣。但如果自動化建設伊始，就只從測試的視角看問題，那麼，最終實現的自動化方案也就只有測試環節、具備測試技能的人能用。

僅僅為了測試覆蓋而實現的自動化，與為了上述目的實現的自動化，二者在方法、工具、實現難度上差別非常大：也許是寫一個用例要配置很多信息，或者是對環境有諸多要求，或者是選擇的介面層次不合適，或者是工具過於厚重不便攜帶，或者是模擬的方法模擬度不高。

所以無論起點在哪裡，目標都是最重要的。當然，目標還是要一步一步的實現的，首先做個測試能用的，這也是不錯的選擇。

自動化的策略選擇

自動化的價值就是自動化實施的目標，目標確定以後，就要確定自動化的策略，簡單的說就是「根據產品、項目、客戶的特點，確定自動化的範圍、優先順序，及其實現和使用的時機。」

說到自動化範圍，通常的反應會是確定哪些特性，或者哪些測試類型（功能、性能、安全）實現自動化。但是可自動化的範圍其實比這個廣，如環境準備、錯誤檢測、測試條件和數據準備、測試執行數據採集和分析、缺陷定位信息整合、代碼檢查和提交等，也都可能實現自動化。即使是功能測試的自動化，也不是只有按特性這一個維度，還可以按「層次」（例如單元、集成、系統等）或者「介面」（例如消息、RPC、UI等）確定自動化範圍。

和其他任何的策略一樣，自動化的策略首先取決於目標。例如，如果你的目標是防止產品上線後，系統的基本功能出錯。那麼策略選擇上就應該是：建立所有基本功能的應用場景基線，並儘可能實現這些場景100%自動化測試；至少在產品發布前實現這些自動化用例；在每次啟動測試、產品發布之前都將這些自動化用例全部測試一遍。

其次，自動化策略也是各種因素權衡的結果。自動化的範圍肯定是覆蓋越廣越好，但同時，範圍也受工作量、開發的規範程度、自動化工具和技術成熟度、質量問題的分布等因素影響。

自動化實現的時機，通常是越早實現價值越大，在新代碼編寫的同時就實現的自動化，可以作為代碼質量門檻使用，在開發的早期攔截更多缺陷。但同時，早期實現的自動化會面臨由於介面變更、業務流程變更等因素導致的自動化用例不可用，或者自動化實現工作量被成倍放大的風險。

自動化用例執行的時機，通常是越早越好、越多越好，因為原則上研發的任何一個環節都可能引入缺陷。但是，你該不會真的以為自動化只是消耗一點計算資源，不需要任何人工的參與吧？

自動化具體的策略選擇和方案設計，恐怕需要一本書來寫，這裡只拋個磚，留待大家自己探索了。

總之，自動化，首先不是一個技術問題，從選擇工具開始並不是它的正確打開方式。你首先要明確自動化的目標，比如針對目前嚴重的問題改善質量；幫助實現高質量、快速的軟體研發；幫助產品上線後儘快、安全、穩定的運行……然後才是制定策略、確定方案、選擇工具。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！