做自動化測試要考慮什么？34年的測試專家這樣說

寫在前面

這篇文章譯自著名測試專家James Bach的《Test Automation Snake Oil》一文，是筆者在學習和研究探索性測試時偶然發現的一篇較有意義的文章，很好地解答了我們對自動化測試的疑惑。

比如萬能的自動化測試是否可以替代一切，還給我們提供了可行性很強的建議。

正如作者所說：先思考測試，再思考自動化，切莫本末倒置。

案例分析

先看幾個案例。

案例1

一個產品從開發運維人員傳遞到下一個。

新開發人員發現產品設計文檔已經過時，構建過程被破壞了。經過一個月的分析，每個人都宣稱自己的設計很差，并堅持重寫大部分代碼。再過幾個月，開發人員要么辭職，要么被重新分配，如此循環往復。

案例2

一個產品在開發過程中被匆忙完成，開發人員沒有充分理解它應該解決的問題。

交付幾個月后，審查發現問題，運行和維護系統的成本比自動化執行的流程的成本要高。

案例3

花費10萬美元購買一套現代化的集成開發工具，很快就發現，這些工具的功能不夠強大，可移植性不強，也不可靠，不足以服務于大規模的開發工作。

經過近兩年的努力讓它們工作，最終還是被拋棄了。

案例4

編寫軟件是為了自動化一組的業務任務，但是任務變化太大，導致項目遠遠落后于進度，系統的輸出也不可靠。為了幫助手工完成任務，開發人員會周期性地退出項目，這使得他們在軟件上的落后程度進一步加深。

案例5

一個由數百個幾乎獨立的功能組成的程序，只經過了基本的測試就投入使用，就在交付之前，作為調試的一部分，很大一部分功能被停用。幾乎過了一年，才有人發現這些功能不見了。

這些都是我自己的經歷，但我打賭它們聽起來很熟悉。人們經常抱怨大多數軟件項目都失敗了，這也不該驚訝——從外部來看，軟件似乎很簡單，但魔鬼就藏在細節中，不是嗎？

經驗豐富的軟件工程師知道這一點，并以警惕的眼光和懷疑的心態來對待每個新項目。

自動化測試也很困難，再看一下上面的五個例子，它們不是來自產品開發項目，相反，它們每一個都是自動化測試的成果。

在我管理測試團隊和與測試自動化一起工作的9年里(注意，在一些軟件行業最時髦、最富有的公司)，我獲得的最重要的洞察力是，測試軟件項目和任何其他軟件項目一樣容易失敗。

事實上，在我的經驗中，他們失敗的頻率更高，主要是因為大多數組織沒有像對待交付產品那樣，對他們的測試件報以同樣的關心。

奇怪的是，幾乎所有的測試專家、實踐測試人員、測試經理，當然還有銷售測試工具的公司，都以壓倒性的熱情推薦測試自動化。

好吧，也許用“奇怪”這個詞并不合適，畢竟CASE工具曾經風行一時，測試工具只是CASE的另一種。

從面向對象到“無程序員”編程，對我們這個行業來說，不切實際的鼓吹并不是什么新鮮事。

因此，也許關于測試自動化的公開信息和分析質量不高并不奇怪，而僅僅是該領域不成熟的標志。

也許我們還處于贊賞測試自動化很酷的想法階段，還沒有到認識到它的陷阱的地步。

比起其他測試任務，我更喜歡做自動化。大多數全職測試人員，以及可能所有的開發人員都夢想著可以按下一個巨大的綠色按鈕，讓一個充滿忠誠的機器人的實驗室去做艱難的測試工作，解放自己去做其他事，比如玩游戲。然而，我們想要實現這樣的夢想，就必須謹慎行事。

本文對GUI應用回歸測試自動化的“腳本和回放”進行了批判性分析。

剖析自動化測試

揭穿經典自動化的理由

“自動化測試在沒有人為干預的情況下執行一系列操作，這種方法有助于消除人為錯誤，并提供更快的結果。由于大多數產品需要多次測試，而自動化測試通常會帶來顯著的人工成本節省。通常，一個公司在運行兩到三次自動化測試后，就會超過勞動力成本的盈虧平衡點。”

這句話來自于一個領先的測試工具供應商發布的關于測試自動化的白皮書，類似的聲明可以在大多數商業回歸測試工具的廣告和文檔中找到。

有時，文檔中還夾雜著令人印象深刻的圖表，這些說法與圖標可以歸結為：計算機比人類更快、更便宜、更可靠，因此選擇自動化。

這種推理基于許多不顧后果的假設，讓我們來看看其中的8個：

魯莽假設1：測試是一個“行動序列”

一種更有用的方法是將測試看作是穿插著評估的一系列交互，這些交互中有些是可預測的，有些可以用純粹客觀的術語來指定。

然而，還有許多其他的交互是復雜、模糊和不穩定的。盡管將包含給定測試的一般動作序列概念化通常是有用的，但如果我們試圖將測試簡化為死記硬背的一系列動作，結果將得到一個狹窄和淺層的測試集。

而人工測試則是一個容易適應變化、能夠應對復雜情況的過程。人類能夠檢測出數百種問題模式，一眼望去，就能立刻將它們與無害的異常區分開。

人類甚至可能不會意識到他們正在進行評估，但在“行動序列”中，每一個評估都必須明確規劃。測試可能看起來只是一組行動，但好的測試是一個互動的認知過程。這就是為什么自動化最好只應用于一小部分的測試，而不是大部分的測試過程。

如果你打算將所有必要的測試都執行自動化，可能會花費大量的金錢和時間來創建相對較弱的測試，這些測試忽略了許多有趣的bug，并發現許多“問題”，這些問題最終只不過是意料之外的正確行為。

魯莽假設2：測試意味著一遍又一遍地重復相同的動作

一旦一個特定的測試用例被執行了一次，并且沒有發現任何bug，那么這個測試用例找到bug的可能性就很小了，除非一個新的bug被引入到系統中。

不過，如果測試用例中有變化，就像手工執行測試時通常會出現的情況一樣，那么新問題和舊問題暴露出來的可能性就會更大，可變性是手工測試相對于腳本和回放測試的一大優勢。

當我在Borland的時候，電子表格組用來跟蹤bug是通過自動化還是手動測試發現的——始終如一。超過80%的bug是通過手動發現的，盡管在自動化方面投入了幾年的時間。

他們的理論是，手工測試的變量更多，針對新功能就更容易發現bug的特定變化領域。

高度可重復性的測試實際上可以將發現所有重要問題的幾率降到最低，同理，踩著別人的腳印也可以將踩坑的幾率降到最低。

魯莽假設3：我們可以做自動化測試

一些對人來說容易的任務對計算機來說很難，也許自動化最難的部分是解釋測試結果。對于GUI軟件來說，在忽略無關緊要的問題的同時，自動注意到所有類別的重大問題是非常困難的。

在一個典型的創新軟件項目中，高度的不確定性和變化加劇了自動化的問題。在市場驅動的軟件項目中，通常使用增量開發方法，這幾乎可以保證產品將發生根本性的變化。

再加上通常沒有完整準確的產品規格說明，使得自動化開發有點像開車穿越無指示牌的森林：可以做到，但必須慢一點，有可能會走回頭路，也可能會卡住。

即使我們有一個特定的操作序列，原則上是可以自動化的，但我們只有在擁有合適的的工具的情況下，才能做到這一點。

然而，關于工具的信息很難獲得，回歸測試工具的最關鍵的點是不可能評估的，除非我們使用該工具創建或審查工業規模的測試套件。

以下是在選擇測試工具時需要考慮的一些因素，請注意，其中有多少永遠無法通過閱讀用戶手冊或觀看貿易展演示來評估：

可學習性：能在短時間內掌握工具嗎，是否有培訓課程或書籍來幫助這個過程？

性能闡述：與手工測試相比，該工具的是否足夠快，能夠大幅節省測試開發和執行時間？

非侵入性：該工具模擬實際用戶的效果如何，被測軟件在有沒有自動化的情況下是一樣的嗎?

魯莽假設4:自動化測試更快，因為它不需要人工干預

所有自動化測試套件都需要人工干預，哪怕只是診斷結果和修復有問題的測試，要讓一個復雜的測試套件順利運行，也可能出乎意料地困難。

常見的罪魁禍首是被測軟件的變化、內存問題、文件系統問題、網絡故障以及測試工具本身的bug。

魯莽假設5：自動化減少了人為錯誤

確實減少了一些錯誤，比如人類在被要求執行一長串測試時會犯的錯誤。

但其他錯誤被放大了，任何在生成主比較文件時未被注意到的bug都會消失。

每次執行套件時都會系統地忽略掉，或者調試過程中的一個疏忽可能會意外地使數百個測試失效。

Borland的dBase團隊曾經發現，他們的套件中大約有3000個測試被硬編碼報告成功，而不管產品中實際存在什么問題。為了避免這些問題，應該定期對自動化進行測試或審查。

在另一方面，使用基本的測試管理文檔、報告和實踐，更容易發現相應的失誤。

魯莽假設6：我們可以量化手動測試和自動化測試的成本和收益

事實是，手動測試和自動化測試實際上是兩個不同的過程，而不是兩種不同的方式來執行同一個過程。它們的動態是不同的，它們傾向于揭示的bug也是不同的。

因此，直接以成本或發現的bug數量來比較它們是沒有意義的。

此外，最好的評估方法是在一系列真實的軟件項目的背景下進行。這就是為什么我建議把測試自動化作為一個優秀的測試策略的多方面追求的一部分，而不是一個支配過程的活動，或者獨立于它。

魯莽假設7：自動化將帶來“顯著的勞動力成本節省”

“通常，一家公司在進行兩到三次自動化測試后，就會超過勞動力成本的盈虧平衡點。”這種估計可能來自實地數據，也可能來自營銷專家的想法，無論如何，這都是無稽之談。

自動化測試的成本由幾個部分組成:闡述自動化開發的成本-操作自動化測試的成本-產品變化時維護自動化的成本-其他必要的新任務的成本。

這必須與任何剩余的人工測試的成本進行權衡，這可能會相當多。事實上，我從未經歷過這樣的自動化，它將手動測試的需求減少到如此程度，以至于手動測試人員最終需要做的工作更少。

這些成本如何計算取決于很多因素，包括被測試的技術、使用的測試工具、測試開發人員的技能，以及測試套件的質量。

編寫一個測試腳本并不一定需要很多精力，但是構建一個合適的測試工具可能需要幾周或幾個月的時間。決定購買哪種工具、自動化哪些測試、如何將自動化跟蹤到測試過程的其余部分，當然還有學習如何使用工具，然后實際編寫測試程序的過程，也是如此。

要思考出一個全面的方法來處理這個過程（即一個產生有用的產品）通常需要幾個月的全職工作，如果自動化開發人員對測試自動化的問題或工具和技術的細節缺乏經驗，則需要更長的時間。

持續的維護成本如何呢？大多數自動化測試的成本分析完全忽略了因為自動化而必須完成的特殊的新任務，比如：

測試用例必須被仔細地記錄下來；

自動化本身必須經過測試；

每次執行套件時，都必須有人仔細檢查結果，以區分假陰性和真正的bug；

必須審查待測試產品中的根本變化，以評估它們對測試套件的影響，并且可能必須編寫新的測試代碼來應對它們；

如果被測試的產品隨后被移植到一個新的平臺，甚至是同一個平臺的新版本，那么必須要做移植測試。

這些新任務對測試人員的日常生活產生了重大影響，我工作過的大多數GUI軟件測試團隊都嘗試過讓所有測試人員做兼職自動化工作，但每個團隊最終都放棄了這個想法，轉而選擇一個專門的自動化工程師或團隊。

編寫測試代碼和執行交互式手測試是如此不同的活動，一個被分配到這兩種職責的人將傾向于專注于其中一項而忽略另一項。

而且，由于自動化開發是軟件開發，它需要一定的開發人才數量，有些測試人員做不到。無論如何，對自動化持嚴肅態度的公司通常最終會有全職員工來做這件事，而這必須計入到整體戰略的成本中。

不計后果的假設8：自動化不會傷害測試項目

最后留下了我們在追求自動化策略時面臨的所有問題中最棘手的一個：將我們不理解的東西自動化是危險的。

如果我們在引入自動化之前沒有弄清楚測試策略，測試自動化的結果將是大量完全沒有人能理解的測試代碼。

隨著套件的原始開發人員漂移到其他任務中，其他人接管維護工作，套件在測試團隊中獲得了某種歸屬身份。維護者害怕扔掉任何舊的測試，即使它們看起來毫無意義，因為它們可能在以后被證明是重要的。

因此，這套套件繼續增加新的測試，成為一個越來越神秘的神諭，就像一些古老的喜馬拉雅大師或迪士尼電影中的說話橡樹。沒有人知道套件實際測試的是什么，也沒有人知道產品“通過測試套件”意味著什么，而且規模越大，就越不可能有人不費苦心地去尋找。

這種情況在我個人身上發生過（不止一次，在我吸取教訓之前），我也看到和聽說過這種情況發生在許多其他測試經理身上。

大多數人甚至沒有意識到這是一個問題，直到有一天一個開發經理問測試套件覆蓋了什么，不覆蓋什么，沒有人能夠給出答案。

或者有一天，在最需要它的時候，整個測試系統崩潰了，并且沒有手動的過程來進行備份。這種情況的諷刺之處在于，誠實地嘗試更專業地進行測試，最終可能會確保它是盲目和無知地完成的。

手動測試策略也可能會受到混淆的影響，但是當測試是從相對較小的一組原則或文檔動態創建時，審查和調整策略就容易得多。是的，手動測試速度較慢，但更靈活，它可以應對不完整和不斷變化的產品和規格的混亂。

一種明智的自動化方法

盡管本文提出了關注，但我確實相信測試自動化，畢竟我是一名測試自動化顧問。

就像可以有高質量的軟件一樣，也可以有高質量的自動化測試。然而，要創建好的測試自動化，我們必須小心謹慎，這條道路充滿了陷阱。以下是一些需要牢記的關鍵原則:

仔細區分自動化和它所自動化的過程。測試過程應該是一種便于審查的形式，并映射到自動化過程中，套件將與人工測試一起使用，而不是作為人工測試的替代品。

仔細選擇測試工具。從其他測試人員和組織收集經驗，在購買之前嘗試候選工具的評估版本。

仔細考慮購買或構建一個測試管理工具，一個好的測試管理系統可以真正幫助使套件更可查看和可維護。

確保測試套件的每一次執行都會產生一個狀態報告，其中包括哪些測試通過了，哪些測試失敗了，以及實際發現的bug。該報告還應詳細說明為維護或增強套件所做的任何工作，我發現這些報告是分析自動化的成本效益的不可或缺的原始材料。

確保產品足夠成熟，使不斷更改測試的維護成本不會壓倒所提供的任何好處。

幾年前的一天，在一場猛烈的夜間風暴中發生了一次停電，影響了我們團隊創建的測試套件。當我們第二天早上到達工作地點時，我們發現我們的套件已經自動重啟了自己，重置了網絡，從中斷的地方重新開始，并完成了測試。

為了讓我們的套件變得如此防彈，我們做了很多工作，我們很高興。事情是這樣的，我們后來在審查套件中的測試腳本時發現，在大約450個測試中，只有大約18個測試是真正有用的。

這是一個很長的故事，但它的結果是，我們有一個可靠性極高測試套件，發現我們正在測試的軟件的任何重要的bug。

我已經把這個故事告訴了其他不以為然的測試經理,他們不認為這種事情會發生在他們身上，但如果測試的機器讓你從測試的技巧上分心，它就會發生。

自動化是個好想法，但要讓它成為一項好的投資，秘訣是先考慮測試，然后再考慮自動化。如果測試是為了了解軟件質量的一種手段，那么自動化只是一種手段中的手段。你不會從廣告中了解到這一點，但它只是支持有效軟件測試的眾多策略之一。

最后：在我的V：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。