開發自動化測試指令碼的技巧和心得

著作權聲明：原創作品，允許轉載，轉載時請務必以超連結形式標明文章 原始出處 、作者資訊和本聲明。否則將追究法律責任。http://tester2test.blog.51cto.com/461899/137372

--- 原著Jose Fajardo《Tips and Hints for Developing Automated Test .s》

---Kiki翻譯於2005/7/22

作者在本文中描述了一些構建更易維護的和健壯的自動化測試指令碼的技巧。作者給那些使用自動化測試載入器並且為將來測試工作而建立自動化測試指令碼庫的測試人員提供了有價值的遠見。本文提供了許多在文檔化測試指令碼，調試測試指令碼，執行測試指令碼的同行評審和同步測試指令碼方面的建議。

增量式調試指令碼
錄製測試指令碼，和其他的軟體開發成果一樣，會變得非常大。為了可以成功的回放，需要調試幾百行的代碼，為了參數化的資料驅動測試指令碼，它可能包含了幾個資料集。常見的調試測試指令碼方法是首先錄製所有的商務程序和需求，然後測試人員回放測試指令碼以驗證並糾正問題。測試人員繼續調試指令碼直到它和可以一（或多）組資料集一起成功地回放。 
當測試指令碼有成百的程式碼，驗證點，分支的邏輯，錯誤處理，參數和資料在多個已錄製的商務程序之間的相關性時，調試並且解決測試指令碼中的問題變得特別的乏味和難以處理。對於調試那些複雜且又冗長的測試指令碼，一個更加容易管理的方法是錄製指令碼的一部分並且在錄製測試指令碼的其他部分之前分開調試他們。在測試單個的部分後，你可以決定測試指令碼的一部分如何和另一部分工作和資料如何從一個已錄製的流程流向其他的流程。在測試指令碼的所有部分都錄製後，測試人員就可以回放整個測試指令碼，並確保指令碼同一個或多個資料集一起從頭到尾被正確地回放了。 
舉個例子，我錄製並自動化了一個執行了以下商務程序的複雜的測試指令碼：

1. 檢查在貨倉中的庫存
2. 執行一次MRP運行
3. 補充庫存
4. 挑出一些要發送的貨物並且進行發貨
5. 確定交貨需要移交的訂單
6. 驗證發送的貨物到達了它們的目的地。

這個測試指令碼有一些程式碼，參數，驗證點和需要象一個整體一樣工作的資料相關性。首先我錄製了每一個單獨的流程並且驗證了他們分別可以成功的回放。然後我將所有錄製好的流程整合尾一個大的測試指令碼並且驗證它同多個資料集一起能夠成功的回放。如前面所述，一個關鍵的目的是確信在繼續錄製整個測試指令碼的剩餘部分之前每一個已錄製的流程可以成功的回放。我沒有錄製所有提及的流程（從1到6）並把它們排列一起回放，而不首先驗證所有的流程可以作為單獨的流程成功的回放。 
這部分是為了避免等待調試指令碼，直到整個測試指令碼錄製好。

測試指令碼的同步
測試載入器會用比終端使用者手工按鍵快的多的速度回放已錄製的測試指令碼。接著由於應用程式可能不夠快地顯示資料或從資料庫取出數值以允許測試指令碼正確地回放，這可能會擊垮所測試的應用程式。當測試地應用程式不能響應測試指令碼時，指令碼執行會突然中斷，然後需要使用者幹涉。為了同步所測試應用程式和回放中地測試指令碼，測試小組在已錄製的測試指令碼中引入了人為的等待時間。為了放慢測試指令碼的執行，嵌入在測試指令碼中的等待時間是最任意的且通過實驗和錯誤最佳估計。等待時間主要的問題是它們要不是等的太長就是不夠長時間。  
例如，測試人員或許注意到對於所測試的應用程式測試指令碼回放得太快。他可能打算放慢它幾次直到測試指令碼執行和測試的應用程式相同步。這個技巧可以會造成相反的結果－甚至失敗－如果在測試執行時，由於外部的因素（例如網路有延遲或系統維護）導致應用程式運行比新引入的等待時間更慢。在這種情況下，每次測試人員將不得不不斷的猜測一個新的合理的等待時間。用等待時間放慢指令碼不是十分科學的，並且對於建立強健的，在沒有使用者幹涉情況下能夠成功啟動並執行自動化測試指令碼沒有什麼協助。 
如果有可能的化，測試人員應該避免引入人為的等待時間或任意的sleep變數以使測試指令碼和應用程式同步。 
"While"語句或嵌套的"loops"語句是用於同步需要同步點的測試指令碼且不管所測試程式的回應時間都可以成功回放的正確的技術。在測試指令碼種插入嵌套的loops或“while”語句也可以減少在測試指令碼回放時使用者的幹涉。例如，我插入"while"語句在錄製好的測試指令碼裡，不斷按Enter鍵直到建立了一個計劃中的協議，不管所測試應用程式要花多長時間產生協議。測試指令碼不依賴所測試應用程式的回應時間工作。
已簽核，通過了同行評審
作為測試準備審核標準的一部分，測試指令碼應該被正式的接受並且在開始測試迴圈之前被批准。SMEs， 業務分析人員和開發人員都應該參與到批准已錄製的測試指令碼中。編寫已自動化的測試指令碼的測試人員應該證明測試指令碼可以成功的在QA環境中回放，如果有可能的話，可以帶上多種資料集。
錄製、回放隱藏的對象

指令碼可能被錄製為增加或是雙擊表格中一個欄位或欄位位置沒有被固定的一個數組的值。如果表格或數組中欄位的位置從開始錄製時就不斷地變化，指令碼可能在回放時會失敗。測試指令碼經常在回放中失敗就是因為那些沒有顯示或在螢幕中可見的對象的位置發生了改變。 
為了回放那些位置敏感或位置受變更影響的指令碼，有必要用功能性增強指令碼，例如“向下滾屏”，“下一頁”或“尋找”。包含這些實用性功能可以確保需要回放的隱藏對象將可以被識別，增加或是雙擊而不顧其在矩陣，表格，顯示的螢幕上的位置。  
舉個例子，我曾經錄製果一個指令碼，在最初錄製時它需要向下滾屏兩次來尋找一個可以在表格中輸入的空欄位。當我在幾個星期之後回放它時，我不得不向下滾屏四次來尋找空欄位，而不是相之前錄製的兩次。接著指令碼失敗了，因此我在指令碼中嵌入了邏輯判斷以指導指令碼向下滾屏需要的次數來尋找一個空欄位。我通過在一個“while”迴圈中放置一個“下一頁”（"next page"）功能實現了這個目的，它可以驅動指令碼不停的“下一頁”（page down）直到找到空欄位。
安排重運行指令碼/儲存執行日誌
為了繞過測試載入器不能在安排測試指令碼重啟動並執行局限，測試人員可以通過可以支援多種命令列選項的NT的scheduler安排測試指令碼。測試百年應該將執行日誌儲存在一個共用的驅動盤或針對審核的測試結果的測試管理工具中。
為關鍵的指令碼建立自動的訊息通知
可以用錯誤處理程式邏輯增強測試指令碼，當錯誤發生時它可以不斷的發送錯誤資訊給無限裝置或email地址。一些測試指令碼是關鍵性的業務並且可能在午夜批量地運行。正確並成功運行這些關鍵性業務的測試指令碼會作為其他自動化任務的一個依賴或者前提條件。 
通常也包括在關鍵業務指令碼中一旦出現失敗時自動發送訊息通知的邏輯。
編製文檔
為了使測試指令碼可重用並且更容易維護，文檔化所有和執行測試指令碼，測試指令碼的標頭檔，任何執行測試指令碼的特殊條件相關的資訊，例如：

1. 為了關閉書本調整所測試應用程式中的日期
2. 更新任何需要唯一資料的欄位
3. 為了環境判斷模式（context sensitive）/ 類比模式（analog） /位元影像錄製，調整顯示器設定
4. 列出所有有依賴的測試指令碼
5. 指出為了執行指令碼需要的權限等級或使用者的角色
6. 在什麼條件下指令碼會失敗，以及重新運行指令碼的繞行方法
7. 需要在指令碼運行過程中開啟或關閉的應用程式
8. 指明資料的格式，例如，歐洲日期格式VS美國日期格式，等等

此外，指令碼中需要包含一個描述（例如，它是幹什麼用的）和特別用途（例如，迴歸測試）的檔案頭。指令碼的檔案頭應該包括指令碼的作者，所有者，建立和修改日期，指令碼可以追溯到的需求識別符，指令碼所支援的業務範圍，指令碼中的變數和參數數量。在測試指令碼中提供這些資訊使以後的測試工作中的指令碼的執行，修改和維護更容易些。
實行測試指令碼的版本控制
許多公司花好幾萬英鎊購買測試載入器，但是卻忽略了測試載入器的副產品－錄製好的測試指令碼。為了公司構建中的自動化測試指令碼的庫和存放庫，強烈建議對自動化測試指令碼實資料列版本設定。版本控制協助追蹤測試指令碼中的變更，並可維護同一測試指令碼的多個版本。
堅持測試指令碼命名標準和儲存
測試指令碼應當遵循項目公認的命名標準，並且應該儲存在指定的庫中，例如一個共用的驅動盤或測試管理工具中。
測試經理應當指明包括如下方面的測試指令碼命名標準：

1. 項目的名稱（例如，GSI代表著Global SAP Implementation）
2. 版本號碼（例如，即將發布或部署的版本號碼）
3. 主題或測試種類（例如，SC代表安全性測試，LT代表負載測試）
4. 有序的測試案例編號 
5. 標題或將要測試的功能（例如，來自外部供應商的採購業務） 

遵循這些技巧使測試人員能夠為他們的組織構建更強健的測試指令碼。當然，開發可維護的測試指令碼最大化自動化測試載入器的效益。當自動化測試指令碼用在以後的測試工作中，減少了完成一個測試迴圈所需要的時間時，公司就可以意識到自動化測試載入器帶來的投資回報（ROI）。以上的技術將協助公司構建符合這些目標的測試腳