模板
教程
環境
性能
功能
管理
基于 IBM Rational Robot 的自動化功能測試框架
本文介紹了構建在 IBM Rational Robot 基礎之上的自動化功能測試框架，來幫助組織更好的進行自動化的功能測試。
1. 前言
測試本身就是一項異常艱苦的工作，而成功的進行自動化的功能測試，對很多軟件開發組織來講，更是困難重重。本文介紹了構建在IBM Rational Robot基礎之上的自動化功能測試框架，來幫助組織更好的進行自動化的功能測試。
隨著業務的變化，軟件產品的種類越來越多，軟件產品的升級越來越快，在很多的軟件開發組織中，測試部門承受著巨大的壓力，他們一方面要測試越來越多的軟件產品，一方面要應對越來越短的測試時間，同時，還要面對捉襟見肘的測試資源。
每個版本發布都包括新增加的功能和已有的功能，已有的功能已經在以前的版本中進行過測試，但是還需要在此版本中執行回歸測試。在這種情況下，測試部門往往會考慮到，既然回歸測試的測試用例都已經存在并且已經在上一個版本中執行過，那么在新版本中能否自動的執行這些測試？如果能這樣的話，將極大的節省時間和資源，將有限的資源投入到新功能的測試上，緩解測試的壓力。
通常情況下，軟件開發組織會使用自動化測試工具，使用錄制回放方式來進行功能測試的自動化。但是錄制回放方式并不能解決全部問題。
2.2 錄制回放中存在的問題
業界的經驗表明，雖然錄制回放方式能夠快速的生成測試，但是僅僅單純的使用錄制回放是不夠的。
首先，也是最主要的原因，就是使用錄制回放方式，往往需要耗費時間和資源來調試、維護腳本。這些工作量隨著腳本數量的增加，可能會增大到幾乎不可能再對腳本進行有效維護的地步；其次，使用錄制回放方式，要求應用已經開發完成并且在錄制中不出現錯誤，但是往往當應用達到此條件時已經沒有足夠的時間進行測試；最后，使用錄制回放方式，要求每個測試人員均會使用測試腳本語言“編程”，而當前大多數軟件開發組織測試人員專注于業務，往往沒有興趣和精力來“編程”。
所以，錄制回放方式并不能解決所有的問題，在自動化的功能測試上，需要有測試框架的支持。
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便去點擊界面上的“登錄”按鈕了。
| clearcase/" target="_blank" >cccccc>
'打開文件 =============================== ‘解釋并執行 |
以上是表驅動的簡單示例。在自動化測試中，基于表驅動，還需要解決以下問題：對象識別、驗證點、數據池、分支執行、數據關聯、日志記錄、調用其它腳本、腳本結束。本節將分別展示其在Robot測試技術框架中的實現方式。
3.2.2 對象識別
根據IBM Rational Robot識別對象并執行操作的要求，如果要讓Robot找到界面上的對象并執行相關動作，需要給Robot指定每個對象的對象類型、對象標志、執行動作和數據，如下圖所示。
圖 3. 為Robot指定每個對象的對象類型、對象標志、執行動作和數據
以按鈕舉例來講，如果要讓Robot自動點擊某個按鈕，那么首先要告訴Robot需要在“Button”這種類型的對象上進行操作；其次要告訴Robot，在此類型的對象上要執行什么操作，比如click；第三要告訴Robot要click那個具體的按鈕上，比如要click“登錄”按鈕。
在Robot測試技術框架中，相應的處理為：
|
'打開文件 =============================== ‘對文件中每一行 ‘對按鈕執行的動作 ‘對文本框執行的動作 ‘對組合框執行的動作 =============================== ‘對單選按鈕執行的動作 |
要強調的是，以按鈕為例，雖然在表中需要為界面上每一個具體的按鈕定義一行，但是在測試技術框架中，所有按鈕處理的代碼都是一樣的。
3.2.3 驗證點
沒有驗證點的自動化測試就不能稱之為測試。從這句話中就可以看到驗證點在自動化測試中的重要性。對于驗證點來講，因為不同的測試、不同的應用驗證點都不相同，所以Robot測試技術框架僅僅提供了擴展的機制，不同的驗證點可以通過擴展機制加入到測試技術框架中。
加入驗證點之后，表的定義如下：
最后一行是加入的驗證點。所有的驗證點其對象類型均為VP，不同的驗證點有不同的對象標志，上表中的驗證點是VP_SUM，驗證點的基線數據為24。
在Robot測試技術框架中，處理如下：
|
‘對文件中每一行 ‘對驗證點執行的動作 =============================== ‘驗證點腳本的處理 |
將驗證點的基線數據放入全局變量g_VP_SUM_Baseline中，然后使用CallScript函數來調用驗證點的腳本。對每一個驗證點單獨的創建一個腳本文件，腳本文件的名字和驗證點的標志相同，都是VP_SUM。雖然各個驗證點腳本的內容都不相同，但是一般的步驟是首先從全局變量g_VP_SUM_Baseline中取出基線數據，然后使用SQAGetProperty函數從界面上取實際的數據，再比較實際數據和基線數據。
3.2.4 數據池
往往需要使用不同的數據來運行同一個測試，在自動化測試中是使用數據池來實現的。數據池的增加比較簡單，就是往表中增加表示數據的列，每一列代表一次測試執行所需要的數據。如下表：
從上表中看到，“數據1”這一列代表一次測試的執行所需要的數據，“數據2”代表另外一次測試的執行所需要的數據。
在Robot測試技術框架中，加入循環，按照數據列的數量來進行循環，每一個循環均從第一行執行到最后一行。
3.2.5 執行分支
在測試中，往往是同一個業務或者功能，但是因為輸入的數據、選擇的條件不同，而具有不同的執行流程。執行分支的處理比較簡單，就是在相應的數據列的位置上，填寫代表忽略的特殊標志，比如“IGNORE”，當測試執行到此動作時，判斷其數據是否是“IGNORE”，如果是，就不執行此動作而到下一個動作。對應的表如下：
從上表中看到，第一次執行會執行VP_SUM驗證點，但是第二次執行，因為驗證點相應的數據是“IGNORE”，所以就不會執行VP_SUM驗證點。
在Robot測試技術框架中，在每次執行動作時，先判斷其數據是否是“IGNORE”即可。
3.2.6 數據關聯
在測試中，需要處理數據關聯這種情況。數據關聯是指前一個動作執行完成后，應用產生新的數據，此數據在隨后的動作中需要用到。因為這些數據是在執行的過程中由程序產生的，所以沒有辦法預先在表中準備。在這種情況下對應的表如下：
從上表可以看到，首先使用DC_GETID來將要關聯的數據取出來，然后在需要使用此數據的地方，再使用DC_SETID賦值回去。
在Robot測試技術框架中，取數據的處理如下：
|
‘對文件中每一行 =============================== ‘對數據關聯執行的動作 =============================== ‘數據關聯中，獲取數據腳本的處理 |
對每一個數據關聯，取數據單獨的創建一個腳本文件，腳本文件的名字和數據關聯的名字相同，都比如說都叫DC_GETID。雖然數據關聯取數據腳本的內容各不相同，但是一般的步驟是使用SQAGetProperty函數從界面上取得數據，放入全局變量g_DC_ID中。
在Robot測試技術框架中，賦值回去的處理如下：
|
‘對文件中每一行 ‘對文本框執行的動作 |
即從全局變量g_DC_ID中取出數據，再輸入到文本框中。
3.2.7 其它處理
其它處理包括日志記錄、調用其它腳本以及腳本結束，相應的表如下：
可以看到，在動作類型這一列，使用使用“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測試技術框架，又測試技術框架解釋并執行。
可以看到，使用IBM Rational Robot提供的強大功能所搭建起來的自動化功能測試框架，能夠幫助軟件開發組織成功的實施自動化的功能測試。
1. 通過重用已有的靜態結構和動態結構，能夠有效的促進測試的重用，并且在IBM Rational Robot的支持下，可以自動的執行這些測試
2. 通過使用測試設計工具來生成動態配置，可以看到除測試技術框架的SQABasic腳本外，不需要再維護任何其它的腳本，降低了腳本調試、維護的工作量。并且將來的維護是基于測試設計工具來進行，也降低了自動化測試整體的維護工作量
3. 通過使用測試設計工具來生成靜態配置，能夠做到根據界面的設計來進行配置，而不需要等到待測試應用完全可用，就使得及早測試成為可能
4. 通過支持業務、技術測試人員的分工，在測試技術框架中封裝自動化測試技術細節，使得業務測試人員不需要自動化測試技術的相關知識，只需要通過測試設計工具，就能夠簡單、直觀的進行測試的設計和執行，降低了自動化測試的實施難度
另外，在實施自動化功能測試框架中，還發現兩個有趣的現象。第一，因為可以去自動化的執行測試，所以業務測試人員更多的在使用測試設計工具，從而導致測試設計在整個測試中所占的比重有顯著的提高，有效的提升測試的質量；第二，因為統一、一致的界面操作方式、提示方式和表達方式有利于自動化測試的進行，所以也間接的促使開發團隊在設計、開發過程中更加注重界面的規范性以及界面控件的可測試性。
參考資料
在 developerWorks 上可以找到 Rational Robot專題
關于自動化測試框架的相關概念Choosing a test automation framework
關于作者
陳國偉，IBM中國軟件開發中心實驗室服務高級軟件工程師，專注于Rational軟件。目前主要致力于為客戶提供軟件工程的方法、技術和工具的服務與支持，關注的領域有JAVA開發、RUP實施、用例建模、OOAD、測試以及配置和變更管理。在加入IBM之前，參與ERP、保險、電信等大型軟件項目的管理和開發，擁有6年軟件開發經驗。
