寫在前面

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

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

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

案例分析

先看幾個案例。

案例1

一個產(chǎn)品從開發(fā)運維人員傳遞到下一個。

新開發(fā)人員發(fā)現(xiàn)產(chǎn)品設(shè)計文檔已經(jīng)過時，構(gòu)建過程被破壞了。經(jīng)過一個月的分析，每個人都宣稱自己的設(shè)計很差，并堅持重寫大部分代碼。再過幾個月，開發(fā)人員要么辭職，要么被重新分配，如此循環(huán)往復(fù)。

案例2

一個產(chǎn)品在開發(fā)過程中被匆忙完成，開發(fā)人員沒有充分理解它應(yīng)該解決的問題。

交付幾個月后，審查發(fā)現(xiàn)問題，運行和維護系統(tǒng)的成本比自動化執(zhí)行的流程的成本要高。

案例3

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

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

案例4

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

案例5

一個由數(shù)百個幾乎獨立的功能組成的程序，只經(jīng)過了基本的測試就投入使用，就在交付之前，作為調(diào)試的一部分，很大一部分功能被停用。幾乎過了一年，才有人發(fā)現(xiàn)這些功能不見了。

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

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

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

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

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

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

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

從面向?qū)ο蟮健盁o程序員”編程，對我們這個行業(yè)來說，不切實際的鼓吹并不是什么新鮮事。

因此，也許關(guān)于測試自動化的公開信息和分析質(zhì)量不高并不奇怪，而僅僅是該領(lǐng)域不成熟的標志。

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

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

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

剖析自動化測試

揭穿經(jīng)典自動化的理由

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

這句話來自于一個領(lǐng)先的測試工具供應(yīng)商發(fā)布的關(guān)于測試自動化的白皮書，類似的聲明可以在大多數(shù)商業(yè)回歸測試工具的廣告和文檔中找到。

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

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

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

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

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

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

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

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

魯莽假設(shè)2：測試意味著一遍又一遍地重復(fù)相同的動作

一旦一個特定的測試用例被執(zhí)行了一次，并且沒有發(fā)現(xiàn)任何bug，那么這個測試用例找到bug的可能性就很小了，除非一個新的bug被引入到系統(tǒng)中。

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

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

他們的理論是，手工測試的變量更多，針對新功能就更容易發(fā)現(xiàn)bug的特定變化領(lǐng)域。

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

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

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

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

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

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

然而，關(guān)于工具的信息很難獲得，回歸測試工具的最關(guān)鍵的點是不可能評估的，除非我們使用該工具創(chuàng)建或?qū)彶楣I(yè)規(guī)模的測試套件。

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

可學(xué)習(xí)性：能在短時間內(nèi)掌握工具嗎，是否有培訓(xùn)課程或書籍來幫助這個過程？

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

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

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

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

常見的罪魁禍首是被測軟件的變化、內(nèi)存問題、文件系統(tǒng)問題、網(wǎng)絡(luò)故障以及測試工具本身的bug。

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

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

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

每次執(zhí)行套件時都會系統(tǒng)地忽略掉，或者調(diào)試過程中的一個疏忽可能會意外地使數(shù)百個測試失效。

Borland的dBase團隊曾經(jīng)發(fā)現(xiàn)，他們的套件中大約有3000個測試被硬編碼報告成功，而不管產(chǎn)品中實際存在什么問題。為了避免這些問題，應(yīng)該定期對自動化進行測試或?qū)彶椤?/p>

在另一方面，使用基本的測試管理文檔、報告和實踐，更容易發(fā)現(xiàn)相應(yīng)的失誤。

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

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

因此，直接以成本或發(fā)現(xiàn)的bug數(shù)量來比較它們是沒有意義的。

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

魯莽假設(shè)7：自動化將帶來“顯著的勞動力成本節(jié)省”

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

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

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

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

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

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

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

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

自動化本身必須經(jīng)過測試；

每次執(zhí)行套件時，都必須有人仔細檢查結(jié)果，以區(qū)分假陰性和真正的bug；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一種明智的自動化方法

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

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

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

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

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

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

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

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

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

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

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

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

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