---原著jose fajardo《tips and hints for developing automated test .s》
---kiki翻譯於2005/7/22
作者在本文中描述了一些構建更易維護的和健壯的自動化測試指令碼的技巧。作者給那些使用自動化測試工具並且為將來測試工作而建立自動化測試指令碼庫的測試人員提供了有價值的遠見。本文提供了許多在文件化測試指令碼，除錯測試指令碼，執行測試指令碼的同行評審和同步測試指令碼方面的建議。
增量式除錯指令碼
錄製測試指令碼，和其他的軟體開發成果一樣，會變得非常大。為了可以成功的回放，需要除錯幾百行的**，為了引數化的資料驅動測試指令碼，它可能包含了幾個資料集。常見的除錯測試指令碼方法是首先錄製所有的業務流程和需求，然後測試人員回放測試指令碼以驗證並糾正問題。測試人員繼續除錯指令碼直到它和可以一（或多）組資料集一起成功地回放。
當測試指令碼有成百的**行，驗證點，分支的邏輯，錯誤處理，引數和資料在多個已錄製的業務流程之間的相關性時，除錯並且解決測試指令碼中的問題變得特別的乏味和難以處理。對於除錯那些複雜且又冗長的測試指令碼，乙個更加容易管理的方法是錄製指令碼的一部分並且在錄製測試指令碼的其他部分之前分開除錯他們。在測試單個的部分後，你可以決定測試指令碼的一部分如何和另一部分工作和資料如何從乙個已錄製的流程流向其他的流程。在測試指令碼的所有部分都錄製後，測試人員就可以回放整個測試指令碼，並確保指令碼同乙個或多個資料集一起從頭到尾被正確地回放了。
舉個例子，我錄製並自動化了乙個執行了以下業務流程的複雜的測試指令碼：
檢查在貨倉中的庫存
執行一次mrp執行
補充庫存
挑出一些要傳送的貨物並且進行發貨
確定交貨需要移交的訂單
驗證傳送的貨物到達了它們的目的地。
這個測試指令碼有一些**行，引數，驗證點和需要象乙個整體一樣工作的資料相關性。首先我錄製了每乙個單獨的流程並且驗證了他們分別可以成功的回放。然後我將所有錄製好的流程整合尾乙個大的測試指令碼並且驗證它同多個資料集一起能夠成功的回放。如前面所述，乙個關鍵的目的是確信在繼續錄製整個測試指令碼的剩餘部分之前每乙個已錄製的流程可以成功的回放。我沒有錄製所有提及的流程（從1到6）並把它們排列一起回放，而不首先驗證所有的流程可以作為單獨的流程成功的回放。
這部分是為了避免等待除錯指令碼，直到整個測試指令碼錄製好。
測試指令碼的同步
測試工具會用比終端使用者手工按鍵快的多的速度回放已錄製的測試指令碼。接著由於應用程式可能不夠快地顯示資料或從資料庫取出數值以允許測試指令碼正確地回放，這可能會擊垮所測試的應用程式。當測試地應用程式不能響應測試指令碼時，指令碼執行會突然中斷，然後需要使用者干涉。為了同步所測試應用程式和回放中地測試指令碼，測試小組在已錄製的測試指令碼中引入了人為的等待時間。為了放慢測試指令碼的執行，嵌入在測試指令碼中的等待時間是最任意的且通過試驗和錯誤最佳估計。等待時間主要的問題是它們要不是等的太長就是不夠長時間。
例如，測試人員或許注意到對於所測試的應用程式測試指令碼回放得太快。他可能打算放慢它幾次直到測試指令碼執行和測試的應用程式相同步。這個技巧可以會造成相反的結果－甚至失敗－如果在測試執行時，由於外部的因素（例如網路有延遲或系統維護）導致應用程式執行比新引入的等待時間更慢。在這種情況下，每次測試人員將不得不不斷的猜測乙個新的合理的等待時間。用等待時間放慢指令碼不是十分科學的，並且對於建立強健的，在沒有使用者干涉情況下能夠成功執行的自動化測試指令碼沒有什麼幫助。
如果有可能的化，測試人員應該避免引入人為的等待時間或任意的sleep變數以使測試指令碼和應用程式同步。
"while"語句或巢狀的"loops"語句是用於同步需要同步點的測試指令碼且不管所測試程式的響應時間都可以成功回放的正確的技術。在測試指令碼種插入巢狀的loops或「while」語句也可以減少在測試指令碼回放時使用者的干涉。例如，我插入"while"語句在錄製好的測試指令碼裡，不斷按enter鍵直到建立了乙個計畫中的協議，不管所測試應用程式要花多長時間產生協議。測試指令碼不依賴所測試應用程式的響應時間工作。
已簽核，通過了同行評審
作為測試準備審核標準的一部分，測試指令碼應該被正式的接受並且在開始測試迴圈之前被批准。smes， 業務分析人員和開發人員都應該參與到批准已錄製的測試指令碼中。編寫已自動化的測試指令碼的測試人員應該證明測試指令碼可以成功的在qa環境中回放，如果有可能的話，可以帶上多種資料集。
錄製、回放隱藏的物件
指令碼可能被錄製為增加或是雙擊**中乙個欄位或字段位置沒有被固定的乙個陣列的值。如果**或陣列中字段的位置從開始錄製時就不斷地變化，指令碼可能在回放時會失敗。測試指令碼經常在回放中失敗就是因為那些沒有顯示或在螢幕中可見的物件的位置發生了改變。
安排重執行指令碼/儲存執行日誌
為了繞過測試工具不能在安排測試指令碼重執行的侷限，測試人員可以通過可以支援多種命令列選項的nt的scheduler安排測試指令碼。測試百年應該將執行日誌儲存在乙個共享的驅動盤或針對審核的測試結果的測試管理工具中。
為關鍵的指令碼建立自動的訊息通知
可以用錯誤處理程式邏輯增強測試指令碼，當錯誤發生時它可以不斷的傳送錯誤資訊給無限裝置或email位址。一些測試指令碼是關鍵性的業務並且可能在午夜批量地執行。正確並成功執行這些關鍵性業務的測試指令碼會作為其他自動化任務的乙個依賴或者前提條件。
通常也包括在關鍵業務指令碼中一旦出現失敗時自動傳送訊息通知的邏輯。
編制文件
為了關閉書本調整所測試應用程式中的日期
更新任何需要唯一資料的字段
為了環境判斷模式（context sensitive）/ 模擬模式（analog） /位圖錄製，調整顯示器設定
列出所有有依賴的測試指令碼
指出為了執行指令碼需要的許可權級別或使用者的角色
在什麼條件下指令碼會失敗，以及重新執行指令碼的繞行方法
需要在指令碼執行過程中開啟或關閉的應用程式
指明資料的格式，例如，歐洲日期格式vs美國日期格式，等等
此外，指令碼中需要包含乙個描述（例如，它是幹什麼用的）和特別用途（例如，回歸測試）的檔案頭。指令碼的檔案頭應該包括指令碼的作者，所有者，建立和修改日期，指令碼可以追溯到的需求識別符，指令碼所支援的業務範圍，指令碼中的變數和引數數量。在測試指令碼中提供這些資訊使以後的測試工作中的指令碼的執行，修改和維護更容易些。
實行測試指令碼的版本控制
許多公司花好幾萬英鎊購買測試工具，但是卻忽略了測試工具的副產品－錄製好的測試指令碼。為了公司構建中的自動化測試指令碼的庫和儲存庫，強烈建議對自動化測試指令碼實行版本控制。版本控制幫助追蹤測試指令碼中的變更，並可維護同一測試指令碼的多個版本。
堅持測試指令碼命名標準和儲存
測試指令碼應當遵循專案公認的命名標準，並且應該儲存在指定的庫中，例如乙個共享的驅動盤或測試管理工具中。
測試經理應當指明包括如下方面的測試指令碼命名標準：
專案的名稱（例如，gsi代表著global sap implementation）
版本號（例如，即將發布或部署的版本號）
主題或測試種類（例如，sc代表安全測試，lt代表負載測試）
有序的測試用例編號
標題或將要測試的功能（例如，來自外部**商的採購業務）
遵循這些技巧使測試人員能夠為他們的組織構建更強健的測試指令碼。當然，開發可維護的測試指令碼最大化自動化測試工具的效益。當自動化測試指令碼用在以後的測試工作中，減少了完成乙個測試迴圈所需要的時間時，公司就可以意識到自動化測試工具帶來的投資回報（roi）。以上的技術將幫助公司構建符合這些目標的測試指令碼.
開發自動化測試指令碼的技巧和心得
作者在本文中描述了一些構建更易維護的和健壯的 自動化 測試 指令碼 的技巧 作者給那些 使用 自動化測試 工具 並且為將來測試 工作 而建立自動化測試指令碼庫的測試人員提供了有價值的遠見。本文提供了許多在文件化測試指令碼，除錯測試指令碼，執行測試指令碼的同行評審和同步測試指令碼方面的建議。增量式除錯...
開發自動化測試指令碼的技巧和心得
原著jose fajardo tips and hints for developing automated test scripts kiki翻譯於2005 7 22 作者在本文中描述了一些構建更易維護的和健壯的自動化測試指令碼的技巧。作者給那些使用自動化測試工具並且為將來測試工作而建立自動化測試...
開發自動化測試指令碼的技巧和心得
作者在本文中描述了一些構建更易維護的和健壯的自動化測試指令碼的技巧。作者給那些使用自動化測試工具並且為將來測試工作而建立自動化測試指令碼庫的測試人員提供了有價值的遠見。本文提供了許多在文件化測試指令碼，除錯測試指令碼，執行測試指令碼的同行評審和同步測試指令碼方面的建議。增量式除錯指令碼 錄製測試指令...