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

寫在前面

這篇文章譯自測試人James Bach的《Test Automation Snake Oil》一文，是筆者在學習和研究探索性測試時偶然發現的一篇較有意義的文章，很好地解答了我們對自動化測試的疑惑。   加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

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

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

案例分析

先看幾個案例。

案例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。

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

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

最後：

可以到我的個人號：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！