Totally Data-Driven Automated Testing


原文:Totally Data-Driven Automated Testing By Keith Zambelich
Sr. Software Quality Assurance Analyst, Automated Testing Evangelist
作者簡介
作者目前為 Automated Testing Specialists, Inc. 這家公司的總裁兼執行長,主要從事自動化測試導入的顧問工作,而且本身也是 Mercury Interactive 認證的 WinRunner CPS(Certified Product Specialist)。
摘要
「軟體測試自動化」已經被許多的軟體測試專家驗證是可行的,並且反覆的運用在許多軟體開發過程中。大多數參與軟體測試的專家也同意自動化測試不只是值得的同時也是必要的。

在軟體測試的市場上有許多針對使用者介面(GUI)應用程式所開發的自動化測試工具,而且其中有些工具所提供的功能,已經足夠滿足軟體測試自動化的需求。但是,我們卻看到越來越多的公司,在購買自動化測試工具之後才發現,實施一個符合成本效益(cost-effective)的自動化測試解決方案(solution)原比其所呈現的還困難。

我們會常常聽到一些抱怨,像是"看軟體測試工具廠商做起來好像很容易,但是當我們的人自己做的時候卻完全不是那麼一回事!"、"事實上我們已經花了六個月的時間在導入自動化測試,但是大部分的測試卻還是停留在人工測試的階段!"或是"要讓整個自動化測試運作起來所花費的時間實在太長了,還不如使用原本的人工測試所花的時間更短!"。

通常最後的結局是"另一個錯誤的採購!",自動化測試工具從此被束之高閣了。

本文的目的是跳脫學術理論,透過作者本身的經驗,以更直覺、忠實的態度來討論自動化測試的議題,讓讀者能夠清楚的瞭解,要成功實施符合成本效益的自動化測試,到底需要哪些條件的配合。

何謂自動化測試?
簡而言之,所謂的自動化測試就是將您現有的手動測試流程給自動化。而且要實施自動化測試的公司或組織,本身必須要有一套「正規(formalized)」的手動測試流程。而這個正規的手動測試流程至少要包含以下的條件:

  • 詳細的測試個案(test cases):從商業功能規格或設計文件而來的測試個案,包含可預期的(predictable)的預期結果(expected result)。

  • 獨立的測試環境(test environment):包含可回覆測試資料的測試環境,以便在應用軟體每次變動後,都可以重複執行測試個案。

假如您目前的測試流程並未包含上述條件,即使您導入了自動化測試,也不會得到多大的好處。

所以,假如您的測試方法(testing methodology)只是將應用軟體移轉到一群由「使用者」或「專家級使用者(subject matter experts)」組成的測試團隊,然後任由他們去敲擊鍵盤執行測試工作。那我建議您先把自動化測試放一邊,把「建立一個有效的測試流程」當成您目前首要的工作。因為要自動化一項不存在的流程是完全沒有意義的。

自動化測試最實際的應用與目的是自動化回歸測試(regression testing)。也就是說,您必須要有用來儲存詳細測試個案的資料庫,而且這些測試個案是可以重複執行於每次應用軟體被變更後,以確保應用軟體的變更沒有產生任何因為不小心所造成的影響。

「自動化測試腳本(script)」同時也是一段程式。為了要更有效的開發自動測試腳本,您必須和一般軟體開發的過程一樣,建立制度以及標準。要更有效的運用自動化測試工具,您至少要有一位受過良好訓練的技術人員,換句話說,您至少要有一位程式設計師(programmer)。

自動化測試的成本效益(Cost-Effective)
首先我要告訴您的是,自動化測試是非常昂貴的(這違反了工具廠商灌輸給您的觀念),而且自動化測試不會取代手動測試或是幫助您縮編(down-size)您原本的測試團隊。對於您的測試流程,您應該將自動化測試看成是附加的選項。


譯註:也就是說即使沒有自動化測試工具,您應該也可以將測試做的很好,工具只是幫您做得更快更多,而且讓您有更多的時間花在設計好的測試個案上。

根據 Cem Kanner 的一篇文章 「Improving the Maintainability of Automated Test Suites」 (http://www.kaner.com/),要建立一個自動化測試個案,包含開發、測試、撰寫文件,所花費的時間大約是手動測試個案的3到10倍之多(甚至還要更久)。特別是當您選擇使用「錄製/播放(大部份自動化測試工具都提供此功能)」的方式作為您建立測試腳本的主要方法時,這個公式更是能成立。也就是說只透過「錄製/播放」的方式建立自動化測試所能得到的效益是最少的。

投入自動化測試可以是有效益的,只要您能把握以下的原則(common sense)並將其應用到導入的過程當中:

  • 為您公司或組織選擇一個最符合您測試需求的自動化測試工具。

  • 瞭解不是所有的測試都適合或直得自動化。例如將過度複雜的測試自動化可能會花費更多的成本,那您就要考量值不值得將其自動化。切記,將自動化的重點放在主要的測試個案上。

  • 只有會重複執行的測試才需要自動化。只做一次的測試那就免了吧!

  • 避免只使用「錄製/播放」的方式實施自動化,因為這個方式可能會潛藏著陷阱,而且就長期的考量,這也是最浪費時間的自動化方式。
    不過您可以使用「錄製/播放」的功能,觀察自動化測試工具如何在您的應用軟體上執行測試,這或許對於您在發展測試腳本時會有幫助。

  • 採用「資料驅動(data-driven)」的自動化測試方法,將測試的「輸入資料/預期結果」與測試腳本分開,如此一來,您可以開發更通用(generic)的測試腳本,然後只要更新「輸入資料/預期結果」的資料就可以了。

    接下來我會介紹二種非常有用的資料驅動測試方法。

錄製/播放的神話
每一家自動化測試工具廠商都會告訴你,他們的工具非常容易使用,所以非技術背景的測試人員,只需要簡單錄製測試的操作過程,然後播放錄製好的測試腳本,就可以輕鬆自動化所有的測試。這樣的說法要為自動化測試工具被束之高閣的結果負大部分的責任。

假如可以,我倒是很願意看到說這些話的業務人員,真的在實際的測試上,使用他們自己所賣的工具,然後看看自動化測試是否就如同他們所形容般的如此簡單。

為什麼自動化測試不能單單只靠「錄製/播放」來完成呢?以下幾點將告訴您為什麼:
  • 透過錄製建立的腳本,裡面的資料基本上都是 hard-coded 的,當應用軟體變動時,意味這些 hard-coded 的資料可能也需要修改。

  • 維護這些錄製的腳本,成本是非常高的,高到幾乎不能接受。

  • 透過錄製建立的腳本,不是很可靠,甚至在應用軟體完全沒有變動的情況下直接播放,也可能因為一些例外狀況而出現無法執行的問題。

  • 假如錄製時測試人員使用了錯的資料,那腳本就必須重新錄製。

  • 當軟體變動時,要重新錄製腳本。

  • 所有的測試腳本都必須是在應用程式可以正確執行時才能錄製,假如在錄製過程中發現 bug (錄製的過程也可以看成是作手動測試),測試人員必須回報 bug,而且等到 bug 解決了,整個錄製腳本的動作才能在繼續下去。在這樣的情況下,您可以好好的思考一下,你到底是在測試什麼?

經過2~3個月這樣沒有實質效益的嘗試後,測試人員終究會發現自動化測試並非如工具廠商所形容的簡單,然後他們會放棄自動化測試,重新回到原本手動測試的作法。而工具廠商對他們也不再關心了,畢竟他們的工作是賣工具而不是作軟體測試。
可行的自動化測試方法
就長期的效益上,我們不會將「錄製/播放」當成是我們自動化測試的策略,接下來就讓我們討論以下二種真正有效益的自動化測試的方法論(methodlogies):

Function Decomposition
「Function Decomposition」的主要概念在於將所有測試個案分解成最基本的動作,如 User-Defined Function、Business Function 腳本,並建立可以獨立執行的共用腳本,如 Sub-routine、Utility 腳本。而這些基本腳本可能包含以下動作:

  1. Navigation (e.g. "Access Payment Screen from Main Menu")
  2. Specific (Business) Function (e.g. "Post a Payment")
  3. Data Verification (e.g. "Verify Payment Updates Current Balance")
  4. Return Navigation (e.g. "Return to Main Menu")
除此之外,還需要將「資料」從 Function 中抽離出來。如此一來,當測試人員想要使用不同的輸入資料以及驗證預期結果時,就只要修改資料檔案(data file)就可以了,不需要修改到測試腳本。

在最上層的腳本則是 Driver 腳本,是整個測試的啟動引擎,同時也會作一些初始化動作,如載入 GUI、設定路徑等。Driver 腳本會去呼叫一個或一個以上的 Test Case 腳本。而 Test Case 腳本則是透過呼叫 Business Function 腳本以完成整個測試個案應該執行的功能與驗證。至於 Utility 以及 User-Defined Function 則是可以看成是共用的模組,提供 Driver、Test Case、Business Function 等腳本呼叫使用的。

優點
  1. 較為模組化(modular)的設計,避免重複的腳本,減少建立或維護腳本的成本。
  2. 在應用軟體開發的同時,就可以同步進行腳本建立的動作,而且當應用軟體功能變動時,只需要修改 Business Function 腳本。
  3. 由於應用軟體的功能已經被分解成 Business Function 腳本,測試人員可以隨意組合 Business Function 腳本成為更複雜多樣的測試個案。
  4. 測試輸入資料與驗證資料與腳本分開,儲存在另外的檔案,如純文字檔或 Excel 檔,測試人員可以更容易修改與維護。
  5. 透過判斷 Function 回傳值是 TRUE 或 FALSE ,可以作錯誤處理,讓腳本更有彈性。
缺點
  1. 需要「精通」測試工具腳本語言的工程師。
  2. 每個腳本都會有許多的資料檔,而且資料檔會附在各自的目錄中,增加使用上的複雜性。
  3. 測試人員除了要維護測試計劃之外,還要另外維護資料檔(譯註:相同資料要做二次)。
  4. 對測試工具以及腳本語言來說,使用資料檔可能也要注意資料檔的格式。
Key-Word Driven 或稱為 Test Plan Driven
使用 Key-Word Driven 方法的測試人員會使用類似 Excel 工作表的表格,以輸入關鍵字(Key-Word)的方式建立測試個案。這種測試方法同時也保留了 Function Decomposition 的大部分優點。這個方法的整個過程包含功能都是由關鍵字驅動的,關鍵字控制了整個測試過程。

以下是之前「Post a Payment」範例測試個案的 Key-Word Driven 版本:

COLUMN 1

Key_Word

COLUMN 2

Field/Screen Name

COLUMN 3

Input/Verification Data

COLUMN 4

Comment

COLUMN 5

Pass/Fail

         
Start_Test: Screen Main Menu Verify Starting Point  
         
Enter: Selection 3 Select Payment Option  
         
Action: Press_Key F4 Access Payment Screen  
         
Verify: Screen Payment Posting Verify Screen accessed  
         
Enter: Payment Amount 125.87Enter Payment data  
  Payment Method Check    
         
Action: Press_Key F9 Process Payment  
         
Verify: Screen Payment Screen Verify screen remains  
         
Verify_Data: Payment Amount $ 125.87Verify updated data  
  Current Balance $1,309.77    
  Status Message Payment Posted    
         
Action: Press_Key F12 Return to Main Menu  
         
Verify: Screen Main Menu Verify return to Menu  

上表的 cloums 1 的每一個 Key-Word 都與一個 Utility 腳本有關,而其它欄位就是呼叫此 Utility 腳本所要傳入的參數。您可以看到,事實上測試人員也可以依照這份 Key-Word Driven 測試個案,手動執行測試個案。

下圖說明了整個 Key-Word Driven 運作的機制:



  1. 測試人員會以 Excel 建立如上表的測試個案文件,如 KeyWords_Web.xls

  2. 會有一個驅動腳本啟動整個測試的進行包含一些初始化的工作,如 Driver腳本。

  3. Controller腳本則是負責解析整個測試個案文件的 Key-Word,以便決定要呼叫哪一個 Utility 腳本。

  4. Utility 腳本實際執行每個測試動作,並且使用其它欄位當參數,執行完後將結果回傳給 Controller 腳本。當 Controller 腳本執行到最後一列,整個測試個案就結束執行。

優點
Key-Word Driven 基本上擁有 Function Decomposition 的優點:

  1. 測試人員只要寫一次測試個案就可以了,包含測試資料也是。
  2. 測試個案可以是 Excel、純文字檔等,只要測試工具可以讀取。
  3. 假如「精通」腳本語言的工程師能夠先將那些 Utility 腳本開發好,當測試人員寫好測試個案後,就可以馬上執行自動測試了。
  4. 假如已經存在其它格式的測試個案文件,要將其轉換成為 Key-Word Deiven 的測試個案文件,不會是一件很困難的工作。
  5. 當你針對一個應用軟體已經建立一套 Key-Word Driven 腳本後,接下來對其它應用軟體的測試,可以套用原先的腳本。
缺點
  1. 還是需要「精通」測試工具腳本語言的工程師,坦白說,即使是使用「錄製/播放」也需要「精通」測試工具腳本語言的工程師。
  2. 隨著應用軟體的複雜度,可能用到的 Key-Word 越多,那要寫的 Utility 腳本也會更多,這也會是一項大工程。
消除變動的阻力
某些公司實施自動化測試失敗的原因是,測試人員並不歡迎自動化測試從基礎上改變了他們原本工作的方法。通常,使用哪種自動化測試工具以及如何實施自動化測試都是由管理階層決定的,而且不會諮詢真正從事測試工作的人員。這樣的作法常常會遇到來自於測試人員的阻力,特別是當管理階層本身也不知道如何有效地進行改變。

讓我們分析一些測試人員關心的議題,並探討其解答:

  • 測試工具是要來取代測試人員的。

    完全不正確,自動化測試工具就只是工具,幫助測試人員可以將軟體測試工作做得更好。

    • 自動化測試工具可以幫測試人員執行那些無聊,但是又必須一直重複執行的測試個案。

    • 讓測試人員有更多時間去設計更好、更能有效找到問題的測試個案。

  • 測試人員學習使用測試工具需要花費很長的時間。

    假如使用「Test-Plan Driven」方法,則測試人員就不需要去學習如何使用自動化測試工具,測試人員只需要學習另一種撰寫測試個案文件的方式。學習使用 Key-Word 以及工作表的格式撰寫測試個案,只需要幾個小時的時間就可以搞定。

  • 測試工具對測試人員來說難度太高。

    對於非技術背景的測試人員而言,這也許是實話的,但是我們在前面也討論過,假如能僱用至少一位測試工具專家的話,則非技術背景的測試人員,就不需要去作開發測試腳本的工作,他們所要做的就是設計好的測試個案並且寫下來而已。大部分的自動化工具廠商也提供教育訓練課程,以便協助客戶培訓工具專家。

使用「Test-Plan Driven」方法可以會消除測試人員關於導入自動化測試的不安,測試人員的工作方式不會有什麼重大的改變,唯一的改變是,他們需要學習一種新的格式來撰寫測試個案文件。

人員需求
大部分想要實施自動化測試的公司通常都會忽略「人」這個議題。

自動化測試工具幾乎都使用「腳本(script)」來執行測試個案。就如同我之前提到,所謂的腳本也是一種程式。不同的測試工具可能使用不同的程式語言,有的用C語言,有的用VB,有的可能就用專屬的程式語言。既然腳本也是程式,不管用哪種程式語言,開發腳本也應該被看成是開發一般的應用軟體一樣,需要被管理

為了開發腳本,必須至少有一位資深的程式設計師,來擔任「測試工具專家(Test Tool Specialist)」或「自動化測試工程師(Atuomated Testing Engineer)」這樣的腳色。而且這個人精通哪種語言並不重要,重要的是他想要做這樣的工作。畢竟大部分的程式設計師並不願意呆在測試部門。也許找到這樣的人並不容易,不過很明顯的這個人卻是必須的。

找到這個人之後,他將會負責以下與自動化測試腳本開發有關的工作:

  • 建立開發自動化測試腳本的標準(standards)與程序(procedures)。

  • 建立變更管理(change-management)機制。

  • 建立資料驅動測試方法的細節與基礎建設(inforstructure)。

  • 實做、測試並管理由測試人員撰寫的測試腳本(指的是 Key-Word Driven 的工作表)。

  • 執行測試腳本並提供執行結果。

通常在導入自動化測試時可以考慮,聘請一位顧問(像我),顧問可以幫助您建立整個自動化測試機制,訓練「自動化工程師(Automation Engineer)」以及測試人員,讓整個自動化測試可以運作。就我的經驗,視實際狀況的不同,要建立整個自動化測試機制,少則2~3個禮拜,多則2~3個月就可以完成。當然,這樣的作法只能是短期的協助,長期來看,您還是要訓練,甚至找到熟悉自動化測試的人,這才是真正的長久之道。

除了自動化測試人員,非技術背景的測試人員對於整個自動化測試而言也一樣地重要。您應該避免偏愛某一類的測試人員以免招致反效果。我從事過軟體開發以及軟體測試的工作,就我個人的經驗,可以這樣說,軟體測試是專業的,所以您也應該專業的看待軟體測試人員,畢竟要從業務需求與設計規格的角度,建立好的測試個案,也和軟體開發一樣,同樣是創造力、腦力以及專業技術結合的成果。

結論
  • 了解自動化測試到底可以做什麼以及不可以做什麼,以建立清楚而且合理的期望值。

    • 多學習關於自動化測試的知識,可以幫助您自己更瞭解您所要深入的領域。在網路上有許多的資源。

    • 在您所有測試個案中,試著找出有多少的百分比的測試個案是適合被自動化的,並排除過度復雜的測試個案。

  • 對於成功實施自動化測試的必要條件要有清楚的瞭解。

    • 您需要有技術背景的測試人員才能更有效地發揮測試工具的效益。

    • 必須先具備正規、有效率的手動測試流程,才能實施自動化測試。

    • 在自動化測試實施的初期,您可能需要聘請自動化測試的顧問來協助您導入。

  • 實施可行、有效益的自動化測試方法。

    • 就長期來看「錄製/播放」的方法,維護的花費太高,所以無法獲得自動化測試該有的效益。

    • 「Function Decomposition」方法是可行的,但是不如「資料驅動」來的有效益。

    • 「Test-Plan Driven」是成本效益比最高的自動化測試方法。

      • 對於技術人員的需求最少。

      • 所需開發的測試腳本也最少。




Copyright © 2004 by oldsidney