簡介: 本文介紹了構建在 IBM Rational Robot 基礎之上的自動化功能測試框架,來幫助組織更好的 進行自動化的功能測試。
1. 前言
測試本身就是一項異常艱苦的工作,而成功的進行自動化的功能測試,對很多軟件開發組織來講,更 是困難重重。本文介紹了構建在IBM Rational Robot基礎之上的自動化功能測試框架,來幫助組織更好的 進行自動化的功能測試。
2. 現實的挑戰
2.1 自動化測試的迫切需求
隨著業務的變化,軟件產品的種類越來越多,軟件產品的升級越來越快,在很多的軟件開發組織中, 測試部門承受著巨大的壓力,他們一方面要測試越來越多的軟件產品,一方面要應對越來越短的測試時間 ,同時,還要面對捉襟見肘的測試資源。
每個版本發布都包括新增加的功能和已有的功能,已有的功能已經在以前的版本中進行過測試,但是 還需要在此版本中執行回歸測試。在這種情況下,測試部門往往會考慮到,既然回歸測試的測試用例都已 經存在並且已經在上一個版本中執行過,那麼在新版本中能否自動的執行這些測試?如果能這樣的話,將 極大的節省時間和資源,將有限的資源投入到新功能的測試上,緩解測試的壓力。
通常情況下,軟件開發組織會使用自動化測試工具,使用錄制回放方式來進行功能測試的自動化。但 是錄制回放方式並不能解決全部問題。
2.2 錄制回放中存在的問題
業界的經驗表明,雖然錄制回放方式能夠快速的生成測試,但是僅僅單純的使用錄制回放是不夠的。
首先,也是最主要的原因,就是使用錄制回放方式,往往需要耗費時間和資源來調試、維護腳本。這 些工作量隨著腳本數量的增加,可能會增大到幾乎不可能再對腳本進行有效維護的地步;其次,使用錄制 回放方式,要求應用已經開發完成並且在錄制中不出現錯誤,但是往往當應用達到此條件時已經沒有足夠 的時間進行測試;最後,使用錄制回放方式,要求每個測試人員均會使用測試腳本語言“編程”,而當前 大多數軟件開發組織測試人員專注於業務,往往沒有興趣和精力來“編程”。
所以,錄制回放方式並不能解決所有的問題,在自動化的功能測試上,需要有測試框架的支持。
3. 解決之道
3.1 概述
IBM Rational Robot是一款優秀的自動化測試工具,自動化功能測試框架是基於Robot之上構建的。如 下圖:
圖 1. 基於Robot的自動化功能測試框架
業務測試人員類似於當前軟件開發組織中使用手工執行測試的測試人員。可以看到,在解決方案中, 除傳統的業務測試人員外,增加了技術測試人員角色。技術測試人員偏重於自動化測試相關技術,實際上 並不直接執行測試。
解決方案的核心是使用Robot的SQABasic腳本開發的Robot測試技術框架。此Robot測試技術框架以表驅 動為指導思想,讀入動態結構,解釋並執行動態結構中的每一項,是自動化測試的引擎。同時,為了提高 Robot測試技術框架的易用性,在解決方案中還包括測試設計工具,它是使用其它編程語言,比如JAVA、 Dephi等開發的應用程序。在測試設計工具中,測試技術人員首先建立和待測試應用一一對應的靜態結構 ,此靜態結構以頁面為單位,隨後業務測試人員從靜態結構中選擇不同的頁面,組成測試動態結構,即測 試用例,隨後,此動態結構被Robot測試技術框架讀入並解釋執行。
3.2 Robot測試技術框架
3.2.1 表驅動介紹
Robot測試技術框架是基於表驅動測試思想。表驅動測試就是預先在表中定義清楚代表每一步執行操作 的關鍵字,然後由腳本讀入表中的每一行,根據關鍵字來執行對應的動作。以CQ Web登錄界面為例:
圖 2. ClearQuest Web登錄界面
當要自動執行“登錄”按鈕時,可以如下圖來定義此表:
登錄然後在Robot的腳本中,打開表,讀入此行並執行。這樣的話,Robot便去點擊界面上的“登錄”按鈕 了。
'打開文件
Dim sData() as string
InFileName = getExcelFileName
ReadExcelData InFileName, sData()
===============================
‘解釋並執行
Select Case (sKeyWord)
Case "登錄"
Window SetContext, "currentwindow", ""
PushButton Click, "Text=登錄", ""
以上是表驅動的簡單示例。在自動化測試中,基於表驅動,還需要解決以下問題:對象識別、驗證點 、數據池、分支執行、數據關聯、日志記錄、調用其它腳本、腳本結束。本節將分別展示其在Robot測試 技術框架中的實現方式。
3.2.2 對象識別
根據IBM Rational Robot識別對象並執行操作的要求,如果要讓Robot找到界面上的對象並執行相關動 作,需要給Robot指定每個對象的對象類型、對象標志、執行動作和數據,如下圖所示。
圖 3. 為Robot指定每個對象的對象類型、對象標志、執行動作和數據
以按鈕舉例來講,如果要讓Robot自動點擊某個按鈕,那麼首先要告訴Robot需要在“Button”這種類 型的對象上進行操作;其次要告訴Robot,在此類型的對象上要執行什麼操作,比如click;第三要告訴 Robot要click那個具體的按鈕上,比如要click“登錄”按鈕。
動作類型 對象類型 對象標志 執行動作 數據 G Button 確定 Click G EditBox 姓名 Click Jack G ComboBox 角色列表 Click 系統管理員 G RadioButton 區域 Click在Robot測試技術框架中,相應的處理為:
'打開文件
Dim sData() as string
InFileName = getExcelFileName
ReadExcelData InFileName, sData()
===============================
‘對文件中每一行
Select Case (sObjType)
Case "Button"
ProcessButton(sObjAction, sObjData, sData)
Case “EditBox”
ProcessEditBox(sObjAction, sObjData, sData)
Case “ComboBox”
ProcessComboBox(sObjAction, sObjData, sData)
Case “RadioButton”
ProcessRadioButton(sObjAction, sObjData, sData)
===============================
‘對按鈕執行的動作
Select Case(sObjAction)
Case “Click”
Window SetContext, "currentwindow", ""
PushButton Click, "Text=" & sObjData, ""
===============================
‘對文本框執行的動作
Select Case(sObjAction)
Case “Click”
EditBox Click, "Name=" & sObjData, ""
InputKeys "^+{HOME}{DELETE}"
InputKeys sData
===============================
‘對組合框執行的動作
Select Case(sObjAction)
Case “Click”
ComboBox Click, "Name=" & sObjData, ""
ComboListBox Click, "Name=" & sObjData, "Text=" & sData
===============================
‘對單選按鈕執行的動作
Select Case(sObjAction)
Case “Click”
RadioButton Click, "Name=" & sObjData
要強調的是,以按鈕為例,雖然在表中需要為界面上每一個具體的按鈕定義一行,但是在測試技術框 架中,所有按鈕處理的代碼都是一樣的。
3.2.3 驗證點
沒有驗證點的自動化測試就不能稱之為測試。從這句話中就可以看到驗證點在自動化測試中的重要性 。對於驗證點來講,因為不同的測試、不同的應用驗證點都不相同,所以Robot測試技術框架僅僅提供了 擴展的機制,不同的驗證點可以通過擴展機制加入到測試技術框架中。
加入驗證點之後,表的定義如下:
動作類型 對象類型 對象標志 執行動作 數據 G Button 確定 Click G HTMLLink 鏈接 Click G ComboBox 角色列表 Click 系統管理員 G RadioButton 區域 Click V VP VP_SUM VP_SUM 24最後一行是加入的驗證點。所有的驗證點其對象類型均為VP,不同的驗證點有不同的對象標志,上表 中的驗證點是VP_SUM,驗證點的基線數據為24。
在Robot測試技術框架中,處理如下:
‘對文件中每一行
Select Case (sObjType)
Case ……
Process……
Case “VP”
ProcessVP(sObjAction, sData)
===============================
‘對驗證點執行的動作
g_VP_SUM_Baseline = sData
CallScript sObjAction
===============================
‘驗證點腳本的處理
sData = g_VP_SUM_Baseline
SQAGetProperty “”, “”, sActual
if sData = sActual then
……
else
……
end if
將驗證點的基線數據放入全局變量g_VP_SUM_Baseline中,然後使用CallScript函數來調用驗證點的腳 本。對每一個驗證點單獨的創建一個腳本文件,腳本文件的名字和驗證點的標志相同,都是VP_SUM。雖然 各個驗證點腳本的內容都不相同,但是一般的步驟是首先從全局變量g_VP_SUM_Baseline中取出基線數據 ,然後使用SQAGetProperty函數從界面上取實際的數據,再比較實際數據和基線數據。
3.2.4 數據池
往往需要使用不同的數據來運行同一個測試,在自動化測試中是使用數據池來實現的。數據池的增加 比較簡單,就是往表中增加表示數據的列,每一列代表一次測試執行所需要的數據。如下表:
動作類型 對象類型 對象標志 執行動作 數據1 G Button 確定 Click G HTMLLink 鏈接 Click G ComboBox 角色列表 Click 系統管理員 普通管理員 G RadioButton 區域 Click V VP VP_SUM VP_SUM 24 24從上表中看到,“數據1”這一列代表一次測試的執行所需要的數據,“數據2”代表另外一次測試的 執行所需要的數據。
在Robot測試技術框架中,加入循環,按照數據列的數量來進行循環,每一個循環均從第一行執行到最 後一行。
3.2.5 執行分支
在測試中,往往是同一個業務或者功能,但是因為輸入的數據、選擇的條件不同,而具有不同的執行 流程。執行分支的處理比較簡單,就是在相應的數據列的位置上,填寫代表忽略的特殊標志,比如 “IGNORE”,當測試執行到此動作時,判斷其數據是否是“IGNORE”,如果是,就不執行此動作而到下一 個動作。對應的表如下:
動作類型 對象類型 對象標志 執行動作 數據1 G Button 確定 Click G HTMLLink 鏈接 Click G ComboBox 角色列表 Click 系統管理員 普通管理員 G RadioButton 區域 Click V VP VP_SUM VP_SUM 24 IGNORE從上表中看到,第一次執行會執行VP_SUM驗證點,但是第二次執行,因為驗證點相應的數據是 “IGNORE”,所以就不會執行VP_SUM驗證點。
在Robot測試技術框架中,在每次執行動作時,先判斷其數據是否是“IGNORE”即可。
3.2.6 數據關聯
在測試中,需要處理數據關聯這種情況。數據關聯是指前一個動作執行完成後,應用產生新的數據, 此數據在隨後的動作中需要用到。因為這些數據是在執行的過程中由程序產生的,所以沒有辦法預先在表 中准備。在這種情況下對應的表如下:
動作類型 對象類型 對象標志 執行動作 數據1 G Button 確定 Click G HTMLLink 鏈接 Click G ComboBox 角色列表 Click 系統管理員 普通管理員 G RadioButton 區域 Click V VP VP_SUM VP_SUM 24 IGNORE G DC DC_GETID DC_GETID G EditBox 交易號 Click DC_GETID DC_GETID
從上表可以看到,首先使用DC_GETID來將要關聯的數據取出來,然後在需要使用此數據的地方,再使 用DC_SETID賦值回去。
在Robot測試技術框架中,取數據的處理如下:
‘對文件中每一行
Select Case (sObjType)
Case ……
Process……
Case “DC”
ProcessDC(sData)
===============================
‘對數據關聯執行的動作
CallScript sData
===============================
‘數據關聯中,獲取數據腳本的處理
SQAGetProperty “”, “”, g_DC_ID
對每一個數據關聯,取數據單獨的創建一個腳本文件,腳本文件的名字和數據關聯的名字相同,都比 如說都叫DC_GETID。雖然數據關聯取數據腳本的內容各不相同,但是一般的步驟是使用SQAGetProperty函 數從界面上取得數據,放入全局變量g_DC_ID中。
在Robot測試技術框架中,賦值回去的處理如下:
‘對文件中每一行
Select Case (sObjType)
Case ……
Process……
Case “EditBox”
ProcessEditBox(sObjAction, sObjData, sData)
===============================
‘對文本框執行的動作
Select Case(sObjAction)
Case “Click”
EditBox Click, "Name=" & sObjData, ""
InputKeys "^+{HOME}{DELETE}"
InputKeys g_DC_ID
即從全局變量g_DC_ID中取出數據,再輸入到文本框中。
3.2.7 其它處理
其它處理包括日志記錄、調用其它腳本以及腳本結束,相應的表如下:
動作類型 對象類型 對象標志 執行動作 數據1 G Button 確定 Click G HTMLLink 鏈接 Click G ComboBox 角色列表 Click 系統管理員 普通管理員 G RadioButton 區域 Click V VP VP_SUM VP_SUM 24 IGNORE G DC DC_GETID DC_GETID G EditBox 交易號 Click DC_GETID DC_GETID L 輸入交易號 輸入交易號 S Order Order X可以看到,在動作類型這一列,使用使用“L”代表記錄日志,日志的內容存放在這一行的數據列中, 比如上表中的“輸入交易號”;使用標志“S”代碼調用其它腳本,要調用的腳本名稱存放在這一行的數 據列中,比如上表中的“Order”;使用標志“X”代表腳本結束。
在Robot測試技術框架中,相應的處理如下:
‘對文件中每一行
Select Case (sActType)
Case “G”
Process……
Case “L”
Log(sData)
Case “S”
CallScript sData
Case “X”
Exit
3.3 測試設計工具
測試設計工具的最主要的目的就是為了提高Robot測試技術框架的易用性,幫助測試人員生成表驅動所 需要的表。另外,測試設計工具通過使用數據庫,能夠在工具級別為測試重用提供支持。測試設計工具主 要包括兩方面的功能:供技術測試人員創建測試的靜態結構;供業務測試人員創建測試的動態結構。
測試的靜態結構要求和應用保持一致,以頁面為單位。即應用中各個功能的層次結構是如何來安排的 ,就相應的在測試設計工具中按照這種安排來建立靜態結構,直到每個頁面為止。這樣來設計的好處是: 首先,靜態結構和應用保持一致,將來應用發生變化,比較容易定位到靜態結構中需要修改的地方;其次 ,建立靜態結構,應用是什麼樣子,就建立成什麼樣子,照搬即可,不需要很多的業務知識,比較適合於 技術測試人員;最後,靜態結構和應用保持一致,將來業務測試人員設計測試的動態結構時,能夠方便的 根據應用在靜態結構中找到相應的頁面。
以下是已經建好的靜態結構的示例:
圖 4. 靜態結構示例
可以看到,左邊是和應用功能組織保持一致的樹形結構。點開“集團理財”節點,可以在右邊的上半 部分看到此頁面中的元素,頁面上每一個元素都按照Robot技術框架的要求輸入必要的信息,比如對象類 型、對象標志、執行動作等。這些內容是由技術測試人員根據頁面來輸入的。如果不希望人工輸入的話, 那麼也可以開發相應的工具去解析頁面,來自動的生成每個頁面的元素,或者是使用IBM Rational Functional Tester(簡稱RFT)的對象映射功能,由RFT去頁面上抓取對象來生成。
測試的動態結構和測試的要求有關。在創建測試用例的過程中,測試用例的每一個步驟,均是選自靜 態結構中的一個頁面,將頁面加入到測試用例中之後,還可以指定此次測試用例要測試頁面上那些元素。 另外,在測試的動態結構中,還可以指定測試數據、驗證點、數據關聯等操作。當設計完成後就直接生成 真正可以被Robot測試技術框架所執行的表。
以下是已經建好的動態結構的示例:
圖 5. 動態結構示例
可以看到,左邊是和按照測試的要求組織起來的測試用例。點開“票據托管”這個測試用例,可以在 右邊的上半部分看到此測試用例的執行步驟,比如第一步是“登錄”,第二步是“票據托管導航”,依次 下來是“票據托管”和“退出”,這些步驟都是從靜態結構中選出來的。當點擊測試步驟中“票據托管” 這個頁面,在下方將此頁面的元素顯示出來,業務測試人員可以為每一個測試元素輸入數據、指定數據關 聯、添加驗證點等。
當業務測試人員設計好測試用例後,就可以將測試用例傳遞給Robot測試技術框架,又測試技術框架解 釋並執行。
4. 結論
可以看到,使用IBM Rational Robot提供的強大功能所搭建起來的自動化功能測試框架,能夠幫助軟 件開發組織成功的實施自動化的功能測試。
1. 通過重用已有的靜態結構和動態結構,能夠有效的促進測試的重用,並且在IBM Rational Robot的 支持下,可以自動的執行這些測試
2. 通過使用測試設計工具來生成動態配置,可以看到除測試技術框架的SQABasic腳本外,不需要再維 護任何其它的腳本,降低了腳本調試、維護的工作量。並且將來的維護是基於測試設計工具來進行,也降 低了自動化測試整體的維護工作量
3. 通過使用測試設計工具來生成靜態配置,能夠做到根據界面的設計來進行配置,而不需要等到待測 試應用完全可用,就使得及早測試成為可能
4. 通過支持業務、技術測試人員的分工,在測試技術框架中封裝自動化測試技術細節,使得業務測試 人員不需要自動化測試技術的相關知識,只需要通過測試設計工具,就能夠簡單、直觀的進行測試的設計 和執行,降低了自動化測試的實施難度
另外,在實施自動化功能測試框架中,還發現兩個有趣的現象。第一,因為可以去自動化的執行測試 ,所以業務測試人員更多的在使用測試設計工具,從而導致測試設計在整個測試中所占的比重有顯著的提 高,有效的提升測試的質量;第二,因為統一、一致的界面操作方式、提示方式和表達方式有利於自動化 測試的進行,所以也間接的促使開發團隊在設計、開發過程中更加注重界面的規范性以及界面控件的可測 試性。