自動化測試專家 Elfriede Dustin 在 2008 年 10 月的《 Software Testing and Performance 》雜志上發表文章，深入探討了為什么如此多的自動化測試項目會最終失敗。

?

1 、 IDT 的自動化測試調查

???????? IDT （ Innovative Defense Technologies ）在 2007 年進行了一次軟件自動化測試的研究調查。調查研究表明：雖然很多公司都認為自動化測試是非常有用的，但是很少有公司真正成功地實施了自動化測試。在問及沒有很好地開展自動化測試的原因時，大部分人回答是由于缺乏資源，例如：時間、預算、技術等，其中：

??? ? 37% 認為缺乏時間。

??? ? 17% 認為缺乏足夠的預算。

??? ? 11% 認為缺乏合適的工具。

??? ? 20% 認為缺乏專家的技術指導。

????????研發領域的技術在過去 20 、 30 年間得到了高速的發展。然而我們對這些技術的測試能力并沒有跟上發展的速度。現實告訴我們，測試變得越來越重要。 IDT 研究測試技術多年，發現一些有趣的東西：

（ 1 ）軟件測試開始和軟件開發一起驅動著業務。

????????以前，業務驅動著軟件和測試的技術發展。現在，軟件和測試技術逐漸對業務起著驅動作用。業務部門可以有很好的業務 idea ，但是如果軟件開發和測試部門不能很好地交付產品，或者測試能力有所欠缺的話，業務的競爭力會很快地消失。搶占市場的先機很重要，但是應該給予產品開發和質量保證更多的關注。

（ 2 ）應該給予“感知質量”更多的測試

????????質量過程和標準往往過于關注數據，例如出現了多少個 Bug 、缺陷的密度等數據，而忽略了顧客的“感知質量”。例如，對于一個產品，頻繁出現的 10 個缺陷，并且會影響到關鍵的功能運行，這往往會被顧客認為是一個低質量的產品，即使相對于整個項目而言，缺陷密度是非常低的。

????????相反地，如果發布的產品中有 100 個缺陷，但是不經常出現，而且幾乎不影響正常的功能操作，顧客則會認為這是個高質量的產品，即便從數據看來，其缺陷率非常高。

????????到目前為止，并沒有太多“基于使用的測試”的研究。“基于使用的測試”探索感知質量的內涵，追求高的感知質量，從而獲得更高的顧客滿意度。在? Elfriede Dustin 看來， amazon.com 相比起其他在線書店網站，擁有更高的顧客感知質量，因為 amazon.com 的用戶體驗非常友好。

????????我們的目標是提高產品的感知質量。提高的途徑是：讓測試專注在那些最常使用的功能上（確保正常工作，沒有任何缺陷），專注于測試那些最常用功能的可用性、可靠性。

（ 3 ）測試人員總是會受到責備

???????? Deadline 臨近，而在多種環境下的測試周期看起來是無止境的。測試人員通常會因為 Deadline 而受到責備，還會因為項目超出預算、沒有覆蓋產品的所有 Bug 、缺乏創新等，受到責備。

????????但是，通常造成這種結果的真正原因是因為缺乏系統工程的過程。例如，對于一個上百萬行代碼、包含大量功能模塊的產品，僅僅依靠測試組的黑盒測試，費盡九牛二虎之力才找到一些 Bug 。

????????從另外一個角度來看，測試對項目進度拖延的真正原因是：不良的開發習慣導致充滿 Bug 的代碼，需要很長的、重復的修改周期。

????????還有一個原因是：缺乏單元測試。調查分析表明：單元測試越充分、越有效，則系統測試會開展得越順利，系統測試的周期也會越短。

????????不能忽略的一個問題是產品構建。構建（ Build ）和發布（ Release ）的過程應該自動化。如果沒有實現構建的自動化，那么軟件構建的過程將會是非常浪費時間、并且容易出錯的一件事情。

????????另外，如果 Deadline 本身設置得就不合理，那么導致失敗的可能性就非常大。有些 Deadline 的設置沒有考慮清楚究竟需要多長的時間來開發和測試軟件。

（ 4 ）開發人員不做測試

????????雖然已經有不少的開發人員采用單元測試、測試驅動的開發方式，他們確實做得不錯。但是開發人員仍然缺少集成和系統方面的測試。開發人員往往傾向于關注自己編寫的功能模塊的問題，缺乏對整個系統的全局觀。

????????為什么開發人員不做一下系統測試呢？他們沒有時間，他們不是專業的測試人員，他們缺少測試的技巧，他們忙著開發新的代碼和功能，并且測試系統整合部分的代碼不是他們的職責。

????????開發人員疲于應付新功能的開發，以便滿足那些不合理的 Deadline 。畢竟，大部分人認為搶占市場是很關鍵的。然而，事實證明，我們不僅僅要關注? R&D ，還要關注 R&D&T 。

?

2 、自動化測試的最佳實踐

????????很自然地，大家希望借助于自動化測試來縮短系統測試的周期，緩解測試的壓力。但是，如果在設計和代碼開發的過程中缺乏對自動化測試的考慮，例如提高應用程序的可測試性，我們可能會掉入自動化測試的陷阱中去。

????????為了避免掉入自動化測試的陷阱， Elfriede Dustin 總結了幾個最佳實踐，其中包括：

（ 1 ）提高應用程序的可測試性。

????????軟件開發人員可以通過在程序中構建更多的可測試特性，來幫助測試人員開展自動化測試。可以有多種方式來提高可測試性，其中一種比較常見的方式是提供日志或 跟蹤機制，從而提供關于程序正在做什么的信息，包括正在操作的數據，以及關于應用程序狀態、運行中的錯誤等方面的信息。測試工程師可以利用這些信息來判斷 錯誤是否發生，跟蹤測試執行過程中的各種處理流程。

????????在應用程序執行過程中，所有模塊都會寫入關于方法、函數、當前處理對象等詳細的日志信息。通常日志會寫到文件或數據庫中，并且按一定的格式寫入，以便后期地分析和調試。

????????在某些復雜的 C/S 結構系統或 Web 系統中，日志文件可能會寫到多個機器上，因此日志中應該包含足夠的信息用于判斷在機器之間執行的順序和路徑。但是也不能包含太多的信息，否則將影響后期的分析過程。這些日志信息對于開發人員定位問題的本質有重要的作用，可以減少問題分析和定位、調試的時間。

（ 2 ） GUI 和接口測試的建議

????????錄制回放型的測試工具通過腳本語言記錄測試工程師在程序界面上的操作，然后通過回放來做一些基本的驗證。由于需要與 GUI 打交道，任何 GUI 的細微變化都可能引起腳本回放的失敗。因此，如果是基于位圖的錄制，則要注意下面幾個方面：

??? ?控件的字體不要隨便改動。

??? ?界面的顏色不要隨便改動。

??? ?顯示的設置需要保持不變。

??? ?如果可能，應該保持操作系統的標準設置。

????????開發人員在做界面層的修改之前，需要考慮到界面的修改對自動化測試腳本的影響，尤其是在界面基線已經建立起來之后，需要慎重考慮 GUI 的修改。

???????? GUI 測試工具通常是基于對象的屬性來識別對象的，因此開發人員最好能知道 GUI 測試工具的工作原理，這樣可以在修改 GUI 時盡量避免對自動化測試腳本造成的影響。

?

3 、小結

????????為了避免掉入那些主要的自動化測試陷阱， R&D 應該在開發過程中把測試這個“ T” 也考慮進去，而不僅僅考慮那些最新最酷的開發技術。如果發明并使用了最新最好的技術，但是不能被充分測試或者很難被測試到，那么我們如何知道它們的質量水平呢？！

? ? ? ?測試自動化是個很關鍵的技術，在開發軟件的過程中，程序員需要把測試效果和可測試性等因素考慮進去。并且，還應該明白修改 GUI 的內容對于自動化測試腳本的影響。

自動化測試：為什么受傷的總是我？