何時應進行自動化測試？

我希望可以自動化實現盡可能多的測試。如果只跑一次測試會使我很不舒服。如果一個程序員改變了代碼并引進了一個bug，怎么辦？如果我沒抓住那個缺陷，只是因為我在變化之后沒有進行新的測試，怎么辦？我將不感到可怕嗎？所以我需要使用自動化測試工具來實現多次的重復測試工作。

　　恩，是這樣的，當我使用了自動化測試后也沒有覺得舒服。測試花費了很長的時間，最終發現是我過度的使用了自動化測試。在我定義的測試里其實只有少量的測試需要自動化測試來幫助完成。多余的自動化測試在運行時是不會發現任何有價值的bug的，毫無意義！

　　現在的問題是怎樣做合理的自動化測試呢？當我從事測試這項工作，作為一個測試員我一般會為一些產品功能設計一系列的測試。對他們中的每個來說，我需要決定哪個測試應該使用自動化測試來進行。這篇文章描述了我在權衡測試中的看法。

　　設想

　　為了使我的論點清楚，我一定要避免一次去嘗試描述所有可能的測試設想。如果我挑選一個很有用的設想，清楚的描述它，你作為一個讀者會很好的了解。然后留下你把論點用于你具體的項目中。下面是我的設想：

　　1． 首先，你應該擁有一個固定的自動化的支持。即，自動化工具是可用的。你可以不是一位專家，但是你必須知道怎樣使用他們。寫好配置文件。我設想你使用已有的工具進行工作，不會去使用新的工具，將一些簡單的功能放到配置文件中，或者了解更多的測試自動化。問題是：憑你現有的這些可以證明你的自動化測試一定是正確地嗎？現在給你這個答案還為時過早。

　　在其他情況下，你可能贊同在一個工程后期增加自動化測試。在本文中沒有對到好與不好做辯論，但通過上下文，你會知道自動化測試的價值所在。

　　2． 這里只有兩種可能性：完全的自動化測試，沒有一點的人為操作；全手工進行的自動化測試，使用一次測試后就該扔掉了。這是一個事務上的兩個極端。你可以自動化測試那些組織起來很麻煩的部分，但是其余留下的部分做手工。你可能有足夠用的很仔細的文獻證明能容易再跑一次手動測試。當你深刻理解了從一個極端到另一個極端的時候，你將會清楚的認識到在一個連續的統一體上特殊的測試點應該在哪里。

　　3． 自動化測試和手工測試是似是而非的。當然也不是總是這種情況。例如，負載測試經常需要創造大量的使用者的同時操作的情況。如果需要300個測試員同時使用一個產品，很明顯是很低效的。所以負載測試需要被自動化。

　　4． 通過外部接口所做的測試（“黑箱測試”）。相同的analysis applies在代碼級測試——在文章的后面會給出一個簡短的例子——但是我將不描述全部細節。

　　5． 沒有必要必須什么情況都使用自動化測試。經驗告訴我們在測試中需要把自動化測試和手工測試完美的結合。

　　6． 首先你需要設計好測試然后決定它是否需要被自動化執行。實際上，自動化的需要對設計的影響是很普遍的。這讓人很傷心，因為有些時候測試會被減弱只是因為使用了自動化。但是，如果你理解了自動化測試并正確地使用它，它可以給程序帶來無害的調整甚至改進。

　　7． 你有一定量時間完成你的測試。你應該盡力在規定時間內做更好的測試。在測試開始時，會在是否要測試不那么普通的情況和需要的時間上有一些爭論。

　　Overview

　　我的解決過程用到了這些問題。

　　1. 如果自動化執行一次測試需要的時間多于其做簡單的手工測試的時間，會多多少時間？
　　2. 一個自動化測試過程有一個生命周期，在其生存期它必須賠償那額外的成本。遲早這次試驗可能死嗎？什么事件很可能結束它？
　　3. 在它的生存期內，它測試出額外bug的可能性（是否在測試的第一時間內發現了bug）？怎樣平衡這些不可預測的問題和代價之間的關系？

　　如果這些問題沒有被徹底的解決，其他小的問題就沒有平衡可言。

　　第3個問題是必要的，這個我將在大多數細節里繼續探索。令人遺憾，一個好的答案需要對一個產品有更好的理解，我將解釋應該怎樣去把握一個準確的理解。

　　使用自動化測試會失去什么？

　　通常創造一個自動化測試往往要比手工的進行一次測試所要花費的時間多。（注釋一）而費用上的微小的變化取決于這個產品和它的自動化設計。

　　如果產品需要經過一個GUI(圖形用戶接口)被測試，那么你的自動化測試計劃手稿中就需要準備驅動GUI接口的部分（本質上要有簡單的計劃），在很多時候一個自動化測試其花費會和手工測試差不多。

　　如果你使用GUI capture/replay工具來記錄產品內部接口間的交互并通過這些構建一個腳本的話，自動化測試相對來說是便宜的。但是，當因為錯誤導致需要重頭安排自動化測試的時候，當需要組織整理測試的一些文檔記錄的時候，當測試進程陷入到bug中并且不斷惡化的時候，等等這些，自動化測試就不像人工測試那樣的廉宜。這些小細節下引起的成本的追加往往會不容易使人們注意它。

　　如果你現在正在對一個編譯器進行測試，那么使用自動化測試的成本就會比使用手工的要多一些，應為大部分的時間會為編譯器寫測試計劃，來使編譯器根據計劃進行編譯。這些計劃無論會不會被重復使用都的編寫。而往往這些計劃都不會被重復使用。

　　如果你的測試環境對使用自動化測試非常適合，而使用自動化測試的花費只比手工測試多的10%的話。（我認為這種情況很罕見。）這意味著，一旦你自動化實行了十次測試，做一次手工測試——對產品做一次獨特的測試——這在用戶提出要求前是不可能實行的。如果自動化測試的花費是更大的，那十個自動化測試可以替代運行十個、二十個或者更多的手工測試的話，應該如何掌握和處理呢，我們會發現什么？

　　所以，我們第一個測試自動化的問題應該是這樣的：

　　如果我對它進行自動化測試,我會失去手工測試中的什么?我會丟掉多少bug,自動化測試的嚴格性？

　　依賴于你的設計，其答案是會變化的。假設你是一個電信系統的測試人員，在這里對其質量要求是很高的而且測試的預算會是非常充足的。你的答案可能是“如果我用自動化執行這個測試，我將或許會失去三個手工測試點。但是，我做好了非常漂亮的完整的測試設計工作，我清楚的認識到那些額外的測試只會對現有的測試產生一些價值不高的變化。嚴格的說，他們應該分別的執行，因為我真的懷疑他們也許會發現新的嚴重的bug?！睂δ銇碚f，自動化測試的價值是很低的。

　　或者你正在測試一個產品需求和代碼在最近幾個月內在不停變化的工程的1.0版本。你的答案可能是“嘿！我沒有時間去嘗試為每一個明顯的變化都重新做一次測試。這種情況下，我將會使用自動化來進行測試，同時我要保證其發現新的嚴重的bug的機會降到最低?！睂δ銇碚f，自動化測試的價值是很高的。

　　這是我衡量自動化測試價值的標準——可以第一時間或預先發現bug——這看上去似乎有些古怪。人們通常是用做這項工作所花費的時間來衡量自動化測試的代價的。我之所以使用這樣一個衡量標準是因為自動化測試的目的是在下一次運行中能夠發現更多的bug。發現bug的數目體現了自動化測試的價值，因此衡量自動化測試價值的標準也因該統一到這個上面來。（注釋2）

　?。ㄗ⑨?：有一些例外。例如，或許測試可以被制成模板。用一個工具可以通過處理這些模板中的表單來驅動產品的測試。而向模版表格中填入數據做自動化測試要比做手工測試快的多?？纯碵Pettichord96]和[Kaner97]的風格，如果用手工測試的花費會很大，我們就不會去牽扯它。但是需要小心：人們往往會低估自動化測試的花費。舉個例子來說，將需要輸入的數據填寫到表單中會是一件非常easy的事，但是自動化測試的結果的驗證卻會是一件花費很大的事情。感謝Dave Gelperin在這個問題上給我的提示。）

　?。ㄗ⑨?：在我和Cem Kaner的談話中，第一次讓我感到應該這樣衡量自動化測試的價值。Noel Nyman指出這是約翰 Daly規則的一個特別的情形，就像你總是問題：“我在做測試的時候還有哪些bug沒有發現？”）

　　在預算上需要注意的地方

　　我想讓你盡可能的準確估計在你的自動化測試中平均會出現的bug數是多少，并將結果告訴我。你的答案不應該是“0.25”或是“0.25±0.024”。你的答案應該象這樣“我會努力減少bug數的出現”或者“我的bug決不會再次出現”。

　　稍后，你會被要求估計一個測試的生命周期（生存時間）。這個答案應該是這個樣子的："不會超過軟件的發布時間" 或者 "a long time" than "34.6 weeks".

　　然后，你會被要求估計在測試生命周期內可以找到多少個bug？答案依然是模糊的。

　　最后，你會被要求對自動化測試和手工測試模糊估計的結果做一個比較并做一個結論。

　　這樣做有用嗎？

　　回答是肯定的。當你考慮選擇誰的時候，需要做出這樣的比較——也許不是在表面上做的——盡管是一些少的比較模糊的數據。我的經驗是快速的回答這些問題希望可以引導一次優秀的測試，不去管答案是否精確。我在這里傾向于不需要精確的去回答這些問題，但是有用的問題和容易被誤解的問題必須要做精確的回答，不要給別人帶來誤導。

　　How Long Do Automated Tests Survive?（一次自動化測試的生命期會有多久？）

　　當代碼做了改動之后，自動化測試顯示出它的價值所在。除了一些極少數類型的測試以外，在代碼未作任何改動之前去做重復測試是一個浪費時間而且沒有任何效果的做法：它會找出一些bug，但和你第一次做測試所發現的是一樣的。（例外，像所用時間測試和壓力測試可以概略的用同一中方式來分析。因為簡單我忽略了它們。（I omit them for simplicity.））

　　但是一個測試不會永遠的持續下去。一些觀點指出，產品上所做的變動很可能破壞一個測試。這個被破壞的測試將不得不做出修改或是被丟棄。我有一個很合理的近似值是這樣的，我們去做一個測試的修改和拋棄已有的測試而重新編寫一個新的測試的價值是同樣的（注釋3）。但是無論在變化后你做什么補救，如果修改和重新編寫都不能達到要求的話，我認為放棄它而使用手工測試會比較好一些。

　　簡而言之，測試的有用壽命看起來像是這一樣:

　　當決定是否做自動化測試的時候，你必須估計出存在多少會影響測試的代碼。如果你的答案是“不多”，那么自動化測試在發現bug上的表現會特別的出色。

　　你需要一些背景知識來估計一個測試的壽命。你還需要了解一些代碼影響測試的途徑。在這里我們從一個特別簡單的圖表開始：

　?。ㄗ⑨?：如果你使用錄制工具能夠將一次測試重放，那樣的價值將會比在開始測試時記錄其預期結果要有價值的多?；ㄒ恍r間和精力在這個上面是在一次測試中是很有必要的。如果你要修改測試腳本，你需要正確地理解這個腳本，修改它測試它，確定你沒有可能揭露的所有問題。你會發現新的測試腳本不可能完成老腳本能做的所有功能，所以可以將一個修改測試保留新舊兩個測試腳本。如果你的testing effort已經確定下來，那么去修改一個測試要比從頭開始寫一個測試要好的多。這些將會不影響你在紙上做的工作；那樣做會減少自動化測試所需要的花費。這一切的前提是你要清楚的認識和把握一次修復所需要的代價，人們往往會把代價估計不足。）

　　假設你的工作是要寫一組測試來檢測用戶是否輸入了正確的電話號碼，那么你就需要檢查是否是輸入了有效地阿拉伯數字而非其它字符等等。如果你清楚其中的代碼（據我了解很少人會這樣）你可以設計一個規劃列表將校驗電話號碼的代碼使用高亮顯示做出標記。通常稱它為 the code under test。這部分代碼可以更加完善你的測試任務。

　　在大多數時候，你不可能有機會直接運用the code under test。例如：你不可能直接得到確認電話號碼的那部分代碼，因為它通常會是一個用戶的一部分屬性，就需要通過用戶接口來測試，將與其關聯的那部分代碼組織起來，使這部分轉變到內部程序的數據，并會按照常規將這部分數據表現出來。當然，你也不能直接對表現出來的數據進行檢測，因為轉變會通過其他的代碼來將其轉變成在用戶界面可見的最后的數據（就像非法的數據會轉換成錯誤信息）。我稱這些代碼為intervening code——介于測試本身和code under test之間的代碼。

　　Changes to the intervening code（對介入其間的代碼進行變化）

　　介入其間的代碼是導致測試死亡的主要因素。而且用戶圖形界面接口較上文提到的那個接口和一些硬件驅動接口相比更是這個樣子。例如：假設用戶接口要求你輸入電話號碼，但是現在變化為要求提供一個電話按鍵區的視覺表現。這時你要使用鼠標敲擊號碼模擬使用真實的電話。（這是個非常愚蠢的主意，但是這怪異的事情已經發生了。）盡管接口傳給了code under test一個正確的值，但是用戶界面的變化很可能破壞一次自動化測試，是因為很可能使用者再沒有地方輸入電話號碼了。

　　就像另外的一個例子，一個輸入的錯誤用戶界面會用其它的方法來告訴用戶。它可能會刷新主窗體使其顯示紅色同時發出特殊的聲音來代替彈出的提示信息來告知你不能完成這次操作。但是，如果你的測試是通過測試是不是彈出提示信息來判定的，那么將視這種正常的運行為一個bug。很顯然這個測試就沒有效果了。

　　"Off the shelf "測試自動化工具能做避免測試死亡的有限制的工作。例如：大多數的GUI自動化測試工具都可以忽視文本框大小、位置和顏色的改變。從而把握像上面兩段所提到的那些大的改變，但是需要事先定制。這需要在你的工程中有一些人去創建test libraries。這樣就要求你，一個測試人員，在編寫好測試的特殊術語，盡可能多的忽略用戶接口的細節。例如，你的自動化測試可能包含這樣一行定制的信息：try 217-555-1212 try是test library程序，它的作用是將電話號碼翻譯成接口可以知道的術語。如果用戶界面接受在輸入框中輸入字符，try會在其中輸入電話號碼。如果需要通過顯示在屏幕上的特定圖形區域鍵入電話號碼時，try也會做到。

　　test library 可以有效地將那些不相關信息過濾掉。這樣我們就可以詳細的準確的測試那些與功能相關的數據。在輸入上，增加這些附加信息是intervening code所必須的。在輸出上，它們將intervening code中的信息全部壓縮到一個很重要的模塊中，其中的信息實際上可以當作是Code Under Test的一個延伸。這種過濾可以用左圖來描述：

　　多數用戶界面的變化不會需要對測試做更改，而只需要對test library做相應的修改。應為test Code要比library Code多的多，所以只修改library Code的代價會很低。

　　但是，盡管我們有更好的補償性的代碼也不可能將測試從所有的變化中隔離出來。它僅僅是盡可能的去預期所有的事情。所以其中有很多可能性，將來很可能出現一些問題破壞你的測試。你必須問自己這樣一個問題：

　　在變化中Intervening Code會把測試保護到什么程度?

　　你需要估計intervening Code的改變對測試造成影響的可能性。要保證用戶界面永遠的不會改變是一件不可能的事情，這就使你需要不停的改變自動化測試的腳本以保證測試可以自動的執行。（我不會相信界面凍結后永遠不會變化，除非manager答應如果以后每做一個新的修改將會給我100美元）

　　如果變化是可能的，你一定會被詢問對你的test Library保護你的測試不受其影響正常執行有多大的信心。如果說test Library不能保護測試，那么起碼它可以很容易的做出改動以適應變化。如果花費一個半小時的時間可以拯救300個測試，那么所做的一切是值得的。但是，小心：很多人往往低估了維護test Library的困難，特別是在變化后需要手工的對測試test Library進行反復的修改。不應該馬上就放棄，拋棄所有的測試類和test Library，從頭開始，因為很可能只需要簡單的修改就可以完成需要的測試。

　　如果你沒有test Library——如果你正在使用自動化GUI測試工具來捕獲和重放模式——你不要期待會有任何保護。一次對界面的修改會讓你的大部分的測試“死亡”。往往不會有足夠的時間來允許我們完成對發生變化的測試進行修改，我們不得不在少的花費和短的生命生存期之間做出選擇。

　　Changes to the code under test（改變測試下的代碼）

　　Intervening Code不是唯一可以變化的代碼，code under test同樣可以變化。特別的是，它可以改變使其完全不同的去做某件事。

　　例如，假設幾年前某個人寫了一個關于點話號碼的校驗測試，為了檢查那些不符合要求的電話號碼，就像1-888-343-3533。在當時，沒有888這樣的電話號碼，但是現在卻存在這樣的號碼。這樣就導致了測試拒絕888號碼給出提示，盡管現在這個號碼是合法的，但是測試腳本會按照先前的規則進行測試從而拒絕它。解決這件事情可能很簡單也可能很復雜。如果你了解問題所在那么這件事是一件很容易的事情：只需要將“888”改為“889”。但是可能很困難對測試做足夠的解釋去了解測試電話號碼整個的方法?；蛘吣銢]有意識到“888”再現在來說是一個合法的號碼，所以你會認為測試理所應當的測出這條Bug。測試在你使用一些假的“Bug”來騷擾開發人員之前是不會固定不變的。

　　所以，在決定是否要進行自動化測試之前你同樣需要問自己這樣的幾個問題：

　　code under test 行為的穩定行如何？

　　注意強調的“穩定性”——只要他們保持外部可試行為相同代碼的代碼就OK！

　　不同類型的產品，不同類型的code under test有不同的穩定性。電話號碼實際上還是相當穩定的。再如一個銀行帳目管理系統可以說是一個相當穩定的系統，如果每次存100元需要收取30元的手續費那么記錄到帳的就是130元，這種關系是穩定的（除非銀行改變了收費的標準）。而用戶的界界面是相當的不穩定的一個因素。

　　增加行為往往是無害的。例如，可能有這樣一個檢查，測試從一個帳戶撤回 $100 由于 $30 生產錯誤導致操作失敗但是帳戶余款方面的沒有改變。但是，現在測試被重寫，增加了一個新的特性：顧客可以根據需要確定是否需要“自動透支保護”功能，它允許用戶提取多余他帳戶內存在的錢數。這種變化不會破壞現有的測試，只要默認的帳戶測試保持原來的行為。（當然，新的測試必須依*新的行為來運行。）

　　我們的立足點在哪里呢？

　　現在我們知道了自動化測試應該跳遠的障礙：必須保證自動化測試的價值要大于采用手工測試的價值。我們需要估計一個測試的生命周期，它可以有機會創造出價值的時間段?，F在，我們需要詢問一下它可以創造出價值的實際可能性。我們可以期待它能發現什么樣的Bug？

原文轉自：http://www.kjueaiud.com