“自動化測試解放雙手”，測試自動化好處大盤點！

維基百科對測試自動化(Test Automation, 簡稱TA)的定義是：測試自動化就是用特定的軟體去控制測試步驟的執行並且對測試結果和期望結果進行比較。

與TA相對應的是傳統的手動測試(Manual Test)，即人工地去執行測試和比較測試結果。根據定義可知，TA就是把本來需要人去完成的測試任務，以軟體(即程式)的形式，交給計算機去完成。為什麼要以軟體的形式？因為這是計算機能夠理解的。

對於軟體測試來說，TA是典型的”機器換人”，是一個重大的技術變革。那麼，具體來說，這種變革到底能夠帶來什麼好處呢？

如果對軟體測試、介面、自動化、效能測試、測試開發、面試經驗交流。感興趣可以1079636098，群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。

1. 提升軟體測試效率

所謂效率提升，本質上就是生產力的提高。對此，我們從多個角度進行理解：

• 單次測試的時間消耗大大減少：

測試工作通常包含一系列順序執行的測試步驟。計算機不僅執行單個測試步驟更快，而且步驟與步驟之間的切換也是瞬時的。如果由人工執行，不僅執行單個步驟更慢，而且測試步驟之間的轉換也會存在明顯延遲。另外，對於計算機來說，我們很容易通過硬體能力的擴充套件(多核、多機器)，來讓單個測試步驟執行得更快。但是對於人工來說，我們卻無法通過增加人數來達到同樣的目的。

• 在相同時間內，可以執行更多的測試：

我們知道，人要下班，而計算機一直在崗；人要休息，而計算機不知疲倦。計算機可以在深夜、在週末、在任何時候重複執行測試，而人卻無法做到。相同的時間週期內，計算機重複執行測試的次數是人工無法比擬的。另一方面，計算機能夠並行地執行多種測試工作，而人卻很難同時開展兩項不同的測試。

• 通過快速和重複的測試，有利於及早和更多地發現產品問題：

事實上，一切測試工作的出發點和落腳點都在於更快、更多地發現軟體問題(即Bug，下同)。測試執行得越快，發現問題的時間就越早，軟體開發人員經歷的反饋時間就越短。這將有利於他們快速地定位問題和解決問題。另一方面，由於計算機很容易重複地執行測試，我們有可能發現(以及復現，Reproduce)更多偶現的(Occasional)軟體問題。偶現問題通常很難由手動測試發現，而問題一旦漏到客戶那裡，有可能產生嚴重的後果。

2. 承擔特定型別測試

有些測試工作，人工很難、甚至幾乎無法完成，從而只能由計算機承擔。比如說效能測試(Performance Testing)，我們希望測試軟體在大使用者量或高併發量下的效能指標。在實際中，我們幾乎無法去構造成千上萬使用者使用產品的測試場景。這時，我們可以用計算機來模擬這樣的場景。通常，單臺計算機就能夠完成模擬成千上萬使用者的任務。

又比如壓力測試(Stress Testing)，我們希望測試軟體在長時期、不間斷執行時的效能變化。這時，幾乎不可能使用人力去持續不斷地監測軟體的執行狀態，而計算機(例如一個簡單的指令碼程式)就能夠很好地承擔這樣的工作。

3. 測試工作全過程自動化

一項完整的軟體測試工作，包含: (1) 設計並實現測試用例(即Case，下同) (2) 部署和升級被測軟體 (3) 執行測試用例 (4) 收集各種軟體日誌 (5)分析並反饋測試結果等步驟。其中，除了第(1)步外，其他幾步均是高頻工作，通常是每一次軟體迭代都需要做的事情。狹義的TA，實際上僅僅是第(3)步，即測試執行層面的自動化。僅僅單個環節的自動化，對於測試工作整體效率的提升是有限的，因為其他步驟可能成為瓶頸。

事實上，在測試執行自動化的基礎上，將測試工作的其他高頻步驟，例如升級被測軟體、收集軟體日誌、反饋測試結果等，也以自動化的形式實現，是一件水到渠成的事情。將這些繁瑣的、重複的、技術含量低的操作交給計算機去做，不僅進一步提升測試效率，縮短測試反饋時間，而且能夠解放測試工程師，讓其把更多的精力投入到設計並實現更好的測試Case、軟體Bug定位和分析等更有挑戰性的工作上。而這部分工作，通常是計算機難以勝任的。一般來說，能讓計算機做的就不要由人來做；人作為比計算機更寶貴的資源，應當去做計算機無法或很難勝任的事情。

4. 測試進入軟體CI

現代軟體開發，越來越強調以增量開發和快速迭代為特徵的敏捷模式。在實際操作中，開發人員會頻繁提交程式碼。每次程式碼的提交，都會自動觸發軟體持續整合(Continuous Integration, CI )系統的執行。CI在拿到軟體程式碼的改動後，會自動觸發一系列工作，例如靜態檢查程式碼、執行單元測試用例、編包等。CI系統高速、並行地運轉著。

**單元測試通常由開發人員自己完成，並且以程式碼的形式存在，天然就是”自動化的”。**而後續的功能、效能、整合等方面的測試，通常是在CI釋出軟體包之後，才開始以某種形式介入，是低速、序列地運轉著。如果後續的測試能夠實現自動化，那麼也可以進入CI系統，成為CI的一部分。測試進入軟體CI帶來的好處可以從多方面解讀：

• 助力ATDD(Acceptance Test Driven Development)思想落地：

如果說測試驅動開發(TDD)只是軟體開發內部的實踐(Practice)，那麼驗收性測試驅動開發(ATDD)則是業務、開發和測試三方合作下的實踐，更有利於確保軟體的實現符合產品的需求。具體來說，軟體開發的完成應以驗收性測試Case通過為標準。在新功能(Feature)開發階段，驗收性TA Case完全可以早於軟體程式碼準備好(Ready)。每次軟體程式碼的提交，均會自動觸發對應TA Case的執行。TA Case通過了，軟體的開發才算完成。如果TA Case自身存在問題，那麼也可以像修改軟體程式碼一樣通過版本控制工具(例如git)快速地修改、提交和生效。**TA Case一旦通過，軟體開發工作和對應的測試工作同步完成(Done)。**每一個新Feature完成，對應的TA Case便會加入他的迴歸測試集(Regression Pool)。

• 確保後期程式碼改動不破壞已有功能：

軟體程式碼的改動是一個高頻率的事情。實現新的需求、修復軟體Bug、重構等，都會造成程式碼的改動。那麼，如何確保每次改動都不破壞已有的功能？在CI系統中，每次程式碼提交，自動觸發TA迴歸測試集中所有Case的執行。只有所有的Case都通過了，這次程式碼提交才被認為是有效的，才能被合進程式碼的主分支(Master)。在軟體功能一個接著一個完成的同時，迴歸測試集也相應地逐步擴大。迴歸測試集的執行貫穿於軟體開發的整個過程，而不是等到軟體開發全部結束後，再去做迴歸測試。在筆者當前參與的軟體專案中，軟體的功能測試實現了自動化，並且從第一個功能點開始，就進入了CI系統。據統計，功能測試迴歸集平均每個工作日在CI中被執行200多次，一個月內能達到5000次。這樣的迴歸強度是手動測試時代完全不可想象的。

• 開發和測試通過CI實現高度協同工作：

開發和測試之間的”相愛相殺”，是軟體公司一個永恆的話題(本文不展開)。測試進入軟體CI為開發和測試人員提供了一種全新的工作模式。在實踐中，開發和測試人員在同一個軟體倉庫，甚至在同一個程式碼分支上協同工作。開發人員實現產品程式碼(SW Code)，測試人員實現測試程式碼(Test Code)。任何一方做出改動，CI系統會自動進行驗證，並將驗證結果反饋給相關人員。這種線上的、同步的工作模式，實現了軟體開發和測試驗證的”共振“。

• 進一步完善CI系統：

軟體的質量，最終是由使用者來評判。CI系統完不完善，取決於自身與終端使用者之間的距離有多遠。筆者認為，CI系統應該是面向交付的。從結果上看，CI輸出的軟體包應當以可供使用者使用為目標。因此，CI應該儘可能地將軟體開發之後的各個測試和驗證階段納入進來，以進一步完善自身。TA，恰恰為測試進入CI提供了必要的前提條件。

5. 測試人員和開發人員的思維方式得到改善

相比技能的進步、流程的改善，TA更大的好處在於思維(mindset)層面。通過TA，測試人員培養了開發思維，而開發人員培養了測試思維。怎麼理解這個觀點？

TA本質上是軟體活動，是將測試工作以程式的形式實現並交給計算機去執行。我們發現，許多測試人員從未寫過一行程式碼，但是在參與了一段時間的TA實踐後，也能夠完成數以百行的、可正常工作的測試程式碼，從而具備了一定的程式設計能力。另外，在編寫、除錯和執行TA Case的過程中，測試人員會遇到許多TA Case自身的問題，而這種問題本質上就是軟體問題。解決這些問題的過程，也就是自身軟體能力提升的過程。筆者認為：他的持續實踐，無形中促進了測試工程師向測試開發工程師的轉變。測試人員本身就懂系統，通過他的實踐又具備了一定的程式設計技能，尤其是系統程式設計(System Programming)技能。這將大大地促進測試人員的職業發展，並且對部門和公司的發展也是有利的。當然，並不是說所有測試人員都需要向測試開發轉。熟練、紮實的純測試思維與技能依然有著巨大的用武之地，我們將另文討論。

對開發人員來說，與測試人員的協同工作，可以加深測試思維。每一個軟體開發人員都須明白：程式碼必須經過測試。軟體的開發應該以驗收性測試通過、使用者需求被滿足為目的，沒有通過測試檢驗的程式碼是沒有價值的。有了牢固的測試理念，開發人員可能開發出更好的程式碼，開發人員交付給測試、運維、使用者的軟體將具有更好的質量。

6. 前途是光明的，道路是曲折的

以上若干好處未必全面，但是都屬於實實在在由TA帶來的。談了這麼多好處，似乎我們要把TA吹上天？然而，實際中TA真的有這麼好的表現嗎？關於測試自動化，可以說“前途是光明的，道路是曲折的”。具體有兩點不能忽視。

1. “天下沒有免費的午餐”。他的好處絕非輕而易舉可以得到。需要有效投入TA，科學實踐TA，才有可能獲得TA帶來的收益。

2. TA只能解決“怎麼測”的問題，不能解決“測什麼”的問題。軟體測試是否成功，相當程度上取決於是否能夠回答好“測什麼”這一重要課題。事實上，如果“測什麼”的問題沒有解決好，TA不僅不能充分發揮優勢，反而可能成為專案的拖累。關於這個觀點，我們會在未來的文章中展開闡述。

有人喜歡創造世界，他們做了開發者；有的人喜歡開發者，他們做了測試員。軟體測試就是一場本該在使用者面前發生的災難提前在自己面前發生了，這會讓他們生出一種救世主的感覺，拯救了使用者，也就拯救者這個軟體，避免了他們被解除安裝的命運。

微信搜一搜【程式設計師一凡】關注這個文縐縐的程式設計師，關注後回覆【面試】有我準備的一線大廠面試資料和簡歷模板，希望大家都能找到心儀的工作，學習是一條時而鬱鬱寡歡，時而開懷大笑的路，加油。如果你通過努力成功進入到了心儀的公司，一定不要懈怠放鬆，職場成長和新技術學習一樣，不進則退。如果有幸我們江湖再見！

如果對軟體測試、介面、自動化、效能測試、測試開發、面試經驗交流。感興趣可以1079636098，群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。