可維護的自動化驗收測試
可維護的自動化驗收測試
Dale Emery認為，有些自動化測試因為比較脆弱而且維護成本高，已導致很多公司放棄了實施測試自動化的意愿。在一篇最近發表的文章中，Dale共享了一些避免測試自動化中這些共性問題的實用方法。他以一些比較典型的自動化代碼做引子，推演出一些有利于增強代碼健壯性，降低維護成本的方法。
Dale文章背后的基本理念其實是：測試自動化也是軟件開發。這個簡單但卻毋庸置疑的事實，是他從Elisabeth Hendrickson的理念中借鑒而來的。
對大多數軟件而言，在代碼的整個生命周期中，維護成本很可能比開始的開發過程成本還要高。在測試自動化領域，這點在錄制-回放腳本的應用中體現得尤其明顯。這些腳本容易創建，但往往難于維護。
Dale認為，要讓自動化測試腳本更易于維護，有兩個必知的關鍵因素：附屬信息和代碼重復。
附屬信息泛指那些可以讓測試正常運行所需的所有“材料”，但本質上并非測試的真正組成部分。變量賦值、循環、調用下級子程序、自動點擊按鈕，甚至是腳本語言自己的語法都可以算是附屬信息。所有這些都是必需的，它們描述了測試代碼的工作方式，但也正因為它們，代碼真正要達成的目標也變成了霧里看花。
重復就是指多次重復出現的簡單代碼;眾所周知，這是可維護性的死敵。一個系統的小改動就可能牽動有重復代碼的每個實例。這是錄制-回放類型的自動化測試的一個關鍵問題：到處充斥著重復代碼。
為了明確概念，Dale舉了個測試賬戶創建程序的代碼實例。這是段正確而且很常用的代碼，但有很多附屬信息和重復。通過成功重構，Dale把那些附屬信息藏了起來，去掉了重復代碼。重構后的代碼顯然更易維護。還有一個額外的好處：重構后的代碼清晰顯示了每段測試想要驗證的本質目標。即使對測試工具或相關上下文一無所知，當這段代碼運行失敗時，我們仍然能夠知道是因為沒能實現哪個系統需求才導致失敗。
回溯到1997年，在洛斯阿爾托斯軟件測試研討會(LAWST)上，齊聚一堂的軟件測試專家們也發現了類似的測試自動化方面的問題。Cem Kaner記錄了這次集會的成果并在97年的Quality Week 上做了相關演講。在名為《改進自動化測試套件的可維護性》的論文中，Cem指出：
寫測試用例最常見的方法是利用你自動化測試工具的捕獲功能。太荒謬了……對程序中的用戶界面所做的任何微小改動都會導致腳本癱瘓。與錄制測試用例緊密相連的維護成本實在讓人難以接受。
針對改善自動化測試的可維護性，以下是洛斯阿爾托斯軟件測試研討會(LAWST)小組提出的三條建議：
認識到測試自動化開發也是軟件開發
不論別人如何，測試人員都必須認識到：軟件開發要遵循一定的紀律，而不能采用“快而臟”的方式設計和實現，這至關重要。如若不然，我們只能像自己測試過的程序那樣，無數次吞咽失敗的苦果。
使用數據驅動的架構
很多測試用例的實現邏輯都是相同的，但這個邏輯要經歷各種各樣的輸入和相應的期望輸出的檢驗。通過將數據從測試邏輯中分離出來的方法，就可以去掉代碼重復。這樣，假設要做一個用戶界面的改動，只要在相對底層的測試代碼上做個簡單修改就能修復一大片測試用例了。
使用基于框架的架構
框架使用共享的函數庫的一系列函數，可以把要測試的應用程序和測試腳本分離開來。測試腳本編寫者們或許可以把這些函數當成是測試工具程序設計語言的基礎命令。這樣一來，他們就能獨立地編寫腳本，不受UI的限制了。
這只不過是良好的編程習慣：從雜亂無章的實現細節中解脫出來�；诮涌�、面向對象的設計流派宣傳這樣做的好處已經很多年了，盡管這個概念其實可以追溯到由來已久的子程序理念。
基于一個設計良好的框架，使用數據驅動的實現方式可以大幅降低維護成本。真正的問題是如何做到這一點。Dale的文章給出了這樣的答案：通過一系列重構不斷改良已有代碼，直至它顯示出我們所期望的這些屬性。當你把測試自動化也當成是軟件開發時，這一切就顯得合情合理了。
你有什么樣的自動化測試經歷呢?你遇到過可維護性的問題嗎?你用了什么方法來克服這些問題呢?結果又如何?留下你的意見，和大家分享一下你的經歷吧。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
