【轉載】自動化測試：為什麼受傷的總是我？

自動化測試專家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的内容對于自動化測試腳本的影響。