何謂 Keyword-Driven Testing？(转自oldsidney 學習筆記)

很喜欢oldsidney 的文章,在这转载下~

转自oldsidney 學習筆記http://blog.joycode.com/oldsidney/articles/23580.aspx

何謂 Keyword-Driven Testing？

Mercury 新發表的 QuickTest Professional 8.0，又出現了一個新的名詞 (對我來說是新的名辭啦) - Keyword-Driven Testing。到底什麼是 Keyword-Driven Testing 呢？

以錄製方式建立測試的問題

一般來說，自動化測試通常是透過錄製的方式建立測試腳本的，這樣的方式看似容易，但是實際上會遇到下列的問題：

1. 測試人員大多不具技術背景，難以完全掌握測試工具
2. 應用軟體必須達到一定的穩定性，才能開始錄製測試腳本
3. 自動化測試腳本與文件是分開的
4. 維護自動化測試腳本的成本非常高

關鍵字驅動 (Keyword-driven )

在 QuickTest 8 的「關鍵字驅動 (Keyword-driven )」測試架構，主要是為了解決上述「透過錄製產生測試腳本」的問題的。

透過「關鍵字驅動 (Keyword-driven )」測試架構，測試人員不需要「錄製測試腳本」，進而改成「設計測試腳本」。

建立 Object Repository

在之前的文章有提到，通常測試工具都是「Object Base」的。在 QuickTest 儲存 Object 的地方稱為「Object Repository」。

所以一開始，要先將應用軟體的 GUI Object，先記錄在「Object Repository」中。所以會先開啟「Object Repository」，按下「Add Objects」按鈕，將應用軟體的 GUI Object 加入「Object Repository」中。



接下來點選應用軟體視窗的標題列，會出現對話視窗問您是不是要把您剛剛點選的視窗加入「Object Repository」，點選「OK」。



由於您選擇的 Object 是一個視窗，所以 QuickTest 還會進一步問您，是不是連視窗內的所有 Object 都要加入「Object Repository」，選取「Selected object and all its descendants」後點選「OK」。



之後，您就會看到 「Object Repository」中會出現這個視窗內的所有 GUI Object。



接下來，建議您將那些 Object 名稱很奇怪，或是看不出代表哪一個 Object 的 Object 名稱作個修改。例如我將原本名為「Button_5」的 object，改名成為「NewOrder」。

在使用測試工具時，這是非常重要的一個動作，為您測試腳本中的 object 名稱，訂定一個統一的規範，可以替日後的維護，減少非常多的成本喔！



可以開始設計測試腳本了

接下來，您可以開始設計測試腳本的工作了！注意我使用的是「設計」而不是「錄製」，因為建立測試腳本的過程，就像是您在一個 Excel 文件上設計測試個案一樣。

您將會設計每個測試步驟，每個測試步驟主要有三個元素：

• Item：這個測試步驟是作用在哪個 object 上，可能是個視窗、按鈕、或是輸入欄位。
• Operation：在這個 object 上，您要執行什麼動作，如Click、Type、Select。
• Value：有些動作，會需要輸入資料，如從一個清單 (list) 上選擇某個選項，或是在輸入欄位 (edit box) 中輸入某些值，您必須告訴 QuickTest 要用什麼資料。

而且當您設計好一個測試步驟後，在 Documentation 欄位，會自動以英文句子顯示這個步驟的說明，這也是 QuickTest 的另一個新功能「Auto-documentation」，您在設計測試步驟的同時，文件也自動產生了。

接下來，我將以在 Flight ( QuickTest 內建的範例程式 )，建立一個「新增訂單」的測試個案。

這個測試個案的第一個步驟就是先 Active Flight Reservation 的主視窗。要建立這一個測試步驟，以要在 Keyword View 上的 Action1 下方點一下，就會出現 Object 的清單，供我選擇要作用的 object。我只要選擇「Flight Reservation」這個視窗 object 就行啦。



接下來，因為我要讓這個 Flight Reservation 視窗 Active，所以我只要在 「Operation」欄位選取 Active 。因為這個 Active 不需要任何的資料，所以我不用在 「Value」欄位中輸入任何資料。

所以我的第一個測試步驟就完成了。同時也可以看到在 「Documentation」欄位中自動出現「Make the "Flight Reservation" window active.」的說明。



第二個測試步驟，我需要在主視窗上的「Data of Flight:」中輸入出發日期，我同樣也按照上面的方式，在「Item」欄位選擇「Data of Flight:」，在「Operation」欄位選擇「Type」，然後在「Value」欄位輸入我要出發的日期「12/12/04」，到這裡我已經完成我的第二個測試步驟。



至於其餘的步驟，我也是以同樣的方式去完成，你可以看到整個測試腳本其實和你透過錄製的方式所建立的測試腳本一樣，這個測試腳本已經是一個可以執行的測試腳本。



結論

所以，您可以看到整個測試腳本建立的過程，完全不需要去執行整個「新增訂單」的操作流程，只要先完成應用軟體的使用介面 (UI) ，就可以建立一個已經準備好可以執行的測試腳本。

這也表示您的應用軟體只要有使用介面 (UI) 就可以了，並不需要真的可以運作。所以測試人員不需要等到應用軟體已經開發得差不多，才開始建立測試腳本。測試人員可以更早就開始建立測試腳本了。

聽起來是不是有點像 XP 所說的「測試先行」的概念呀！

同時在建立測試腳本的過程中，測試步驟的文件也同時產生。

至於測試腳本的維護，也與建立的過程一樣簡單，不管是使用介面 (UI) 還是操作流程的變動，都可以輕鬆改變測試腳本。

對於技術背景不深的測試人員、系統分析師、使用者，建立測試腳本就像是在一個 Excel 中撰寫測試個案一樣簡單。

以上就是我目前所了解的 Keyword-Driven Testing！