? 執行資料驗證點
功能測試指導書
資料的驗證點主要驗證的選取物件基本資料，包括物件名稱、類型及資料內容等。若符合錄製時給定的結果值則驗證通過，反之則失敗。 ? 執行內容驗證點
內容的驗證點是驗證選中的物件的詳細屬性，包括是否取得焦點、位置、大小(如圖片)、文字或值以及標題等等，錄製時可依照規格需要選取需要驗證的屬性並給予比對值。實際測試時比對成功則該驗證點通過，反之則測試失敗。 ? 取得特定的內容值
錄製後的腳本將以Java Code的方式呈現，在測試過程中若是以上兩種驗證方式仍不足夠，則有需要將畫面的屬性值於程式碼中宣告成一變數，此類情況則可使用?取得特定內容值?的驗證方式。選定了需要宣告成變數的屬性則可以在程式碼中操作該變數，透過程式碼的撰寫進行更進一步的驗證方式。例如希望依照不同的查詢結果有不同的操作行為，則可以將查詢結果的文字欄位的text屬性設成一個String變數，再透過if-else等邏輯控制方式來決定後續的操作或驗證。 ? 等待選取的測試物件
網頁程式中需要考量不同頁面轉換時網路速度造成的載入時間不一，假設錄製劇情時A頁面連到B頁面僅需要0.5秒，但是實際測試時可能因為網路速度使得B頁面的載入時間變成5秒，若沒有設定?等待選取的測試物件?很可能會因為畫面中物件載入不完全被工具判斷為測試失敗。因此在錄製時必須考量到載入速度，可在B頁面中選定等待的測試物件(通常選定最後載入的元件，以保證頁面已完全載入)，則實測時系統會每個間隔時間測試該元件是否已經存在，直到設定的等待時間到達為止。
4. 功能測試準則
4.1 測試資料準備
進行系統測試時為了讓測試過程中每個操作行為皆能正確執行，或是為了讓每個驗證點皆能正確的與結果值進行比對，在實際進行測試前施測人員必須準備好測試的資料。準備測試資料的目的在於保留及恢復當初錄製劇情時的系統資料，每一次測試的開始前都必須先將待測環境的資料恢復成初始值。
依照資料恢復的方式測試資料的準備可以分成下列兩種方法： ? RFT反向錄製
功能測試劇情常常針對系統基本功能進行測試，其中新增、讀取、刪除、修改等功能最為常見。以修改資料為例，我們預期讀進一筆為?A?的資料，並嘗試修改為?B?後存檔。這
Version: V1.0
日期：2013/9/13
頁次： 3
功能測試指導書
樣的測試案例若是沒有事前準備測試資料，會使得下次執行測試時讀取到上一次測試時存檔的資料?B?。為了讓每次的測試能夠順利執行，我們可以利用RFT自動化操作的功能來反向錄製劇情，在驗證關鍵劇情功能後，再將資料?B?修改成資料?A?的動作也錄製成劇情的一部分。這樣一來每次測試完成也會自動將資料恢復。其他類似功能也可透過RFT反向錄製來恢復資料，如新增後將資料自動刪除、刪除後將資料重新新增…等等。表一列出可利用RFT錄製反向劇情的可能情況。
表一：正反向劇情模式表(註：[ ]表示系統功能、{ }表RFT功能)
測試劇情(正向) 資料恢復(反向) 資料新增 資料修改 資料刪除 資料修改 可能操作順序 [新增]?輸入資料?[存檔]?[查詢]?{驗證}?[刪除] [查詢]?[編輯]?修改資料?[存檔]?[查詢]? {驗證}?[編輯]?修改資料?[存檔] [查詢]?[刪除]?[查詢]?{驗證}?[新增]? 輸入資料?[存檔] 資料刪除 資料新增 ? 測試前整理資料庫環境
並非所有的資料適合利用RFT反向的錄製來恢復，根據應用系統的特性或權限不同可能使用者可以新增資料但是無法透過介面操作來完成刪除資料。這樣的情況下測試人員僅能直接操作資料庫來完成資料的回復。錄製劇情時找到資料在資料庫中新增的位置並透過查詢語言(SQL)來完成資料的回復，並且記錄下該句SQL指令以供日後可重複使用。
4.2 驗證點設定
RFT提供了四種驗證點的設定(請參考3.1.3)，驗證點的設定方式及位置以能滿足測試案例關鍵劇情的驗證為主，然而除了驗證關鍵劇情之外為了讓測試能順利進行，過程中仍然會有必要設定關鍵劇情之外的驗證點。另外，驗證點的設置RFT將自動產生驗證點名稱，建議應將驗證點的名稱重新命名成有意義且可讀性高的文字，以便於日後維護。以下將針對上述兩部分分別說明驗證點設定的方式與原則。 ? 驗證測試劇情
測試劇情中每一個步驟的輸出值皆須設立驗證點來驗證該功能。例如：輸入某查詢條件則必須查詢出特定的結果。則我們可以在查詢結果畫面設定驗證點驗證該查詢結果得正確性。同樣的道理，輸出特定的視窗(如：對話視窗)、特定的畫面(如：登入後連到主畫面)、特定的圖式(如：畫面產生已簽核圖示)、元件特定的狀態(如：唯讀欄位狀態)等等。劇情錄製人員須能判斷測試劇情中每一步驟的輸出值為何，並選擇適當的驗證方式。
Version: V1.0
日期：2013/9/13
頁次： 4
? 其他驗證點設定
功能測試指導書
除了測試劇情中必要的驗證點之外，在整個劇情的測試中仍然需要設定其他驗證點來確保劇情能更順利的播放。以網頁系統為例，畫面的呈現可能必須要考量到網路的速度。當A頁面要連到B頁面之際可以先在B頁面載入完成後設定?等待選取的測試物件?，以確保往後測試時不會因為網路速度而影響主要劇情的驗證。另外，在與畫面上元件互動時也可設定?等待選取的測試物件?來確保該物件已經存在於頁面中。例如：劇情需要按下畫面上某個按鈕則可在按下按鈕前設定等待該測試物件，以保證在按下按鈕前按鈕已經存在於畫面上。這一類的驗證點設定可以幫助日後回歸測試的流暢，但也不適合設定太多，否則容易造成測試的效率不佳或是維護上的不方便。
表二：常用驗證點設定時機與方法
驗證時機 驗證物件 驗證方式 網頁頁面轉換(A連至B) B頁面上最後產生的物件 等待選取的測試物件 按下功能按鈕 編輯資料 功能按鈕 資料欄位 等待選取的測試物件 執行內容驗證點並選擇\”屬性(False) 執行內容驗證點並選擇\”屬性(True)
存檔 資料欄位 4.3 測試範圍
錄製功能測試劇情時會在RFT中產生一測試專案，此測試專案內容可以依照待測專案的特性對應於測試專案。一般來說，相關性較高的功能會錄製在同一個劇情當中，再由許多的劇情組成一個RFT的測試專案，而測試專案內的規畫方式由小到大可能有： ? 依功能 ? 依程式 ? 依模組
無論測試專案的規畫方式為何或是如何界定測試的最小單位，測試範圍依照測試案例或是使用案例分為關鍵劇情以及次要劇情，其中必須測試的範圍即所有的關鍵劇情，以及關鍵劇情中所有的輸出值。
Version: V1.0
日期：2013/9/13
頁次： 5
功能測試指導書
4.4 通過標準
4.4.1 測試通過條件
功能測試的通過標準主要參考RFT所產生的測試記錄與報告。功能測試的通過必須符合下列兩個條件：
(1) 所有的測試劇情皆需完整播放 (2) 所設置的驗證點需要100%通過
功能測試的失敗代表次此的程式修正影響了主要功能，必須重新修改程式內容並廢止此次的版本更新，直到通過功能測試為止。
4.4.2 測試通過畫面
圖一列出RFT所產生的測試報表，其中左側區域列出本次測試的測試記錄，主要內容為未通過測試的驗證點、產生警告的驗證點以及所有設定的驗證點。而右側畫面則記錄了每個驗證點的通過或失敗情況。
圖一：RFT測試記錄與報告
5. 功能測試流程
5.1 RFT使用方式
請參考文件RFT7_RecordingATestScript.pdf
5.2 功能測試流程
Version: V1.0
日期：2013/9/13
頁次： 6
功能測試指導書
下圖(圖二)列出功能測試含劇情錄製之流程圖，實施功能測試人員應參照流程圖指示進行功能測試。
開始否初次測試是錄製劇情並設置驗證點產生Script回放Script產生測試報告修改程式測試通過否是結束 圖二：功能測試流程圖
Version: V1.0
日期：2013/9/13
頁次： 7