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

維基百科對測驗自動化(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便會加入TA的回歸測驗集(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自身的問題，而這種問題本質上就是軟體問題，解決這些問題的程序，也就是自身軟體能力提升的程序，筆者認為：TA的持續實踐，無形中促進了測驗工程師向測驗開發工程師的轉變，測驗人員本身就懂系統，通過TA的實踐又具備了一定的編程技能，尤其是系統編程(System Programming)技能，這將大大地促進測驗人員的職業發展，并且對部門和公司的發展也是有利的，當然，并不是說所有測驗人員都需要向測驗開發轉，熟練、扎實的純測驗思維與技能依然有著巨大的用武之地，我們將另文討論，

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

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

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

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

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

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

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

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

標籤：其他

上一篇：關系型資料庫的外鍵約束與關聯

下一篇：【分享】自動化測驗工程師職業發展