
使用 Rational Robot 實現自動化測試
kerry UML 工程組織咨詢顧問 IBM
自動化測試的好處
在過去的數年中,通過使用自動化的測試工具對軟件的質量進行保障的例子已經數不勝數。到現在為止自動化測試工具已經足夠完善了,我們完全可以通過在軟件的測試中應用自動化的測試工具來大幅度的提供軟件測試的效率和質量。在使用自動化的測試工具的時候我們建議盡早的開始測試的工作,這樣可以使修改錯誤更加的容易和廉價,并且可以減少更正錯誤對軟件開發周期的影響。下圖顯示了手工測試與自動化測試的比較。這個測試案例中包括1750個測試用例和700多個錯誤。
手工測試與自動化測試的比較
通過這個表我們可以看出自動化測試與傳統的手工測試在所有的方面都有很大的不同,尤其是在執行測試和產生測試報告的方面。
短測試周期中手工測試面臨的挑戰
迭代式的開發過程已經顯示了比瀑布式開發的巨大好處,并已逐漸的取代傳統的瀑布式開發成為了目前最流行的軟件開發過程。在迭代開發中強調在較短的時間間隔中產生多個可執行、可測試的軟件版本,這就意味著測試人員也必須為每次個迭代產成的軟件系統進行測試。測試工作的周期被縮短了,測試的頻率被增加了。在這種情況下,傳統的手工測試已經嚴重的滿足不了軟件開發的需求。如下圖所示,當第一個可測試的版本產生后,測試人員開始對這個版本的系統進行測試,很快第二個版本在第一個版本的技術上產生了,測試人員需要在第二次測試時重復上次的測試工作,還要對新增加的功能進行測試,每經過一個迭代測試的工作量會逐步的累加。隨著軟件開發過程的進展,測試工作變得越來越繁重,如果使用手工測試的方法,將很難保證測試工作的進度和質量。在這種情況下應用良好的自動測試工具將勢在必行。通過使用自動化測試工具測試人員只要根據測試需求完成測試過程中的所需的行為,自動化測試工具將自動生成測試腳本,通過對測試腳本的簡單修改便可以用于以后相同功能的測試了,而不必手工的重復已經測試過的功能部分。
手工測試的問題

同時,現代的 GUI 開發技術已經非常的先進了,它提供給開發人員快速開發的能力。這就意味著開發人員能夠非?焖俚母淖儜贸绦,并將新的版本交個測試人員進行測試。實際上,很多公司每天都會有多個應用版本產生。如果還是使用傳統的手工測試的方法是根本不可能符合軟件快速開發的要求的。
自動化測試的步驟
自動化測試的步驟:
錄制測試過程成為自動化測試腳本
增強和改進錄制的自動化測試腳本
執行自動化測試腳本完成自動化測試
自動化測試過程
錄制測試過程成為自動化測試腳本
開始自動化測試過程的第一個步驟是根據測試用例(測試需求)錄制測試活動的過程。當測試人員在被測試的應用程序中進行測試的活動時,自動化測試工具將捕獲測試人員與應用程序之間的所有交互,并根據這些交互生成可重用的測試腳本。測試人員在這個階段需要考慮的一個關鍵問題就是,使用的測試工具是否有能力在應用程序的環境中捕獲所有與應用程序的交互。
這里我們要強調的是你需要考慮與測試應用有關的所有環境。讓我們通過一個例子進行說明。假如你的應用是一個基于 Web 的應用,你可能會認為我們測試工具只要能夠支持你使用的瀏覽器就足夠了。但這并不是足夠的,在測試基于 Web 的應用的過程中,一定會去要和一些其他的補助應用打交道,比如也許你需要和某種數據庫查許工具進行交互以確認數據被正確的輸入到了數據庫,或者也許你需要和注冊表編輯器進行交互以驗證注冊表的鍵值;蛘咭苍S你將需要和一個電子郵件的客戶端程序交互來驗證從你的 Web 應用發出的郵件。 你對主要測試環境將是你對瀏覽器,但是你同時要確認你能夠通過測試工具來測試其他所有的輔助環境,這樣才能實現測試的所有環節的自動化。如果某一個測試環節不能被自動化測試工具支持,它將成為阻礙測試效率的瓶頸。
增強和改進錄制的自動化測試腳本
自動化測試過程的第二個步驟是增強和改進已錄制的測試腳本。你需要閱讀錄制好的腳本代碼,并對其進行適當的需改。我們舉例說明,當你錄制一個腳本時,自動化測試工具將記錄你輸入的所有數據。用一個簡單的腳本來說,你的腳本可以讀出一個文本文件的內容,你可以通過設置參數為這個腳本輸入不同的數據集。這樣這個腳本變得更加有用了。
為了實現這一點,你需要確保你能夠得到一種簡單的語言以支持你所有的需要。
你還要確認你的測試工具能夠支持所有你應用程序中的控件。通常情況下,開發人員將創建自己的GUI 或者甚至是一些非 GUI 的對象在應用程序中。你需要確認你能夠通過修改測試腳本來使用這些控件。
執行自動化測試腳本完成自動化測試
執行單個或者少量的測試腳本是十分簡單的,但是當回歸測試不斷的增加時,情況就變得復雜多了。你必須確認你能夠協調測試腳本之間的關系,并能夠從多臺機器上按照多種配置來執行測試腳本。
Ratioanl Robot 幫助你實現有效的自動化測試
Robot 對錄制測試腳本的支持
Robot 可以監測到測試人員與應用程序之間的所有交互行為,并可以產生相應的測試腳本。
現在你必須理解自動化測試中關于驗證點和檢查的主要區別。當你進行手工測試時,通常你可以通過看屏幕中顯示的結果來判斷應用程序執行是否是正確的,或者你可以將屏幕上的結果與文檔或者其他的一些結果基線進行比較。在 Robot 中這種比較是通過在測試腳本中設置驗證點實現的。在執行腳本時Robot 會在驗證點獲取測試感興趣的數據,然后與已設定好的結果集進行比較判斷測試是否通過。這個比較的過程叫作檢查。
Robot支持的環境
目前 Robot 對幾乎所有流行的應用環境多有良好的支持和工作表現。尤其是對象 HTML、Java 和 .NET 應用、 Visual Basic,、PowerBuilder,、Delphi、 Oracle 表單 和 MFC 控件(控件最常用在 C和 C++ 的應用中)有著非常強大的支持。
在 Robot 覆蓋了幾乎所有的應用環境的同時,仍然存在一些用很少被使用的語言和環境創建的程序部分,對于這些環境, Robot 具有一種通用的記錄引擎可以捕獲幾乎所有的基本界面交互。因此可以說,使用 Robot 能過滿足幾乎所有的測試環境要求。
測試的驗證點
驗證點是一個 Robot 測試腳本中的一個術語,在驗證點上你可以檢查某些系統表單的行為。
在 Robot中最常用的驗證點是對象屬性和對象的數據驗證。這些驗證點被用于捕獲對象的狀態和對象測試期間的數據。在 Robot 中創建驗證點與選擇想得到的驗證點和識別想要被測試的對象一樣的簡單。
但是很多情況下我們想要的驗證點可能并不是眼睛可以看到的控件。就像下面圖中顯示的,測試者看到的是瀏覽器中各個元素的結果值,這些結果值 Robot 也可以看到,但測試者卻看不到網頁上對象的屬性,比如網頁的 Cookie 屬性,但是這些對象屬性都可以被 Robot 看見。
Robot 的測試驗證點

一旦驗證點被捕獲了,信息就會被存儲在測試數據區域。在執行回放時,測試捕獲的數據將與測試數據區域中的數據基線進行比較。如果比較結果有任何的不同,他們將獲被標記為"失敗"并被記錄在測試日志中。
Robot 還具有對整個網站的斷裂鏈接進行檢查的能力,這也是通過設置驗證點實現的。
Robot 對增強、改進測試腳本的支持
一旦腳步錄制完成,在某些情況下,你可以直接執行它。對于一個簡單的腳本,可能不需要進行任何的改進工作。然而,多數的測試腳本將從通過改進與增強中受益。改進和增強測試腳本的工作非常簡單,就像在程序代碼中添加幾行代碼以處理一些條件邏輯一樣簡單,這對于有一點開發語言基礎的人來說也是很容易的工作。舉一個簡單的例子,你需要測試在給定的環境中計算機屏幕上是否彈出了一個窗口。在這個例子中,你只需要在測試腳本的代碼中添加簡單的類型聲明以處理窗口是否出現。
靈活的編程語言
Robot 使用 SQA Basic 語言對測試腳本進行編輯。SQA Basic 遵循Visual Basic 的語法規則并且為我們提供了非常適合與測試環境的方便的閱讀語言代碼的方式。通過使用這種語言,即便是很少編程經驗的測試人員也能夠很容易的理解代碼的含義。對于哪些有豐富編程經驗的人來說,他們將會發現,SQA 可以非常靈活的進行一些高級的編程,比如利用 COM 對象或者訪問Windows 的編程接口。
SQA Basic 語言是從 Visual Basic 語言中演化而來的,同時它對語法進行了擴展,添加了一些測試專用的命令。這些新的命令擴展了 Robot 對所有 GUI 對象的編程訪問能力,同時也使通常的編程任務―象創建一個數據驅動的測試―更加的簡單。
Robot 靈活的滿足了客戶需要的擴展性
對于測試人員來說,無法實現自動化測試的一個共同原因是,他們無法測試自定義的控件。自定義的控件通常是被開發人員編寫的,或者是從特定的控件供應商買來的以填補開發的缺口,而這些控件的并不一定會保證是在標準的控件環境下被創建的。這些控件使開發人員的工作更加簡單的同時,卻給測試人員的工作帶來了極大的麻煩。
通常的情況下, Robot的通用錄制機制將可以支持多數的自定義的控件。但是也存在著 Robot 本身無法訪問到被給的屬性或者控件的數據的情況。在這種情況下,也不要感到無助, Robot 具有非常好的擴展接口,這個擴展接口使 IBM Rational 的合作伙伴可以擴展 Robot 的功能,以支持幾乎任何的控件。這就可以使測試人員從問題控件中解脫出來,將精力放到測試任務之中。
Robot 對執行測試腳本的支持
一旦完成了了錄制和改進測試腳本,就應該開始執行腳本完成測試了。
在執行或者回放時, Robot承擔了這個任務。Robot 重復所有的用戶交互,計算當前的應用程序結果與驗證基線的任何差異,并將結果記錄在測試日志中。在所有的測試腳本被執行完后,QA 小組檢查測試日志評估他們應用程序的健康性。
成功的腳本執行的關鍵在于擁有多執行點的能力。有時你可能希望只是執行單個的或者少量的腳本,其他的時候你希望執行所有的測試用例。這兩種情況是需要不同的考慮的。
Robot 對執行測試腳本的靈活性
Robot 給你提供了你所需要的執行腳本的靈活性。你可以以以下的方式執行測試腳本:
從Robot 圖形界面中執行腳本
從Robot 命令行中執行腳本
從TestManager 中執行腳本(具有遠程執行腳本的能力)
Robot 執行測試的方式

單一的腳本或者少量的腳本能過從 Robot 圖形界面中或者從命令行被執行。更加復雜的大量的測試腳本能夠在 IBM Rational TestManager 工具中被創建和執行。
當從 TestManager 中執行測試時,你可以獲得在遠程的機器上執行測試的增強能力。通過在遠程的機器上安裝"測試代理",TestManager 可以與遠程的機器進行通訊并計劃在遠程機器上進行測試腳本的執行 - 這個遠程機器可能是在隔壁房間或者根本是在其他的地方!
Robot 與 Rational TestManger 緊密的集成實現自動化測試的有效管理
Robot 通過與 Rational TestMananger 的集成可以實現:
TestManager可以協調測試執行的時間安排和測試腳本的依賴關系
以中心控制的方式計劃在多臺遠程的機器上執行測試
TestManager 可以對測試進行配置 (如被制定到 Windows XP 平臺上的測試只能在 Windows XP 平臺上執行)
從 Rational TestManager 執行測試

從 TestManager 執行測試提供了創建復雜的測試執行組合。TestManager 可以協調測試執行的時間安排和測試腳本的依賴關系。當你的回歸測試不斷增長時,這種能力時絕對必要的。
當從 TestManager 執行測試腳本時,你將獲得管理測試配置的增強能力。TestManager 是"可配置的" ,這就意味著當它計劃在遠程機器上執行一個測試腳本時 -它對遠程機器是可配置的(操作系統、處理器和其他任何條件) - 并針對配置來執行測試腳本。因為一個測試腳本需要對不同的操作系統有一些稍微不同的版本,比如 Windows 98 和 Windows XP。TestManager 將僅僅對被給定的測試代理配置發送正確的測試腳本。
Robot 功能特點的總結
最后我們來對 Robot 成功實現自動化測試的功能特性作一個總結。
Robot 具有廣泛的環境支持。Robot 給你很好的靈活性來測試在幾乎所有環境中被創建的應用程序。
Robot 提供了靈活的和可擴展的腳本語言 - SQA Basic 。 SQA Basic 是足夠簡單易懂的,沒有編程經驗的測試人員也可以很容易的理解,SQA Basic 同時也是足夠強大的,可以滿足專業的測試工程師進行復雜的編程需求。Robot 的通用錄制引擎具有良好的擴展性,使你可以建立對任何控件的支持。當你排除了對控件的困擾時,你便可以將精力放到測試工作上。
Robot 提供了非常靈活的執行測試腳本的方式,你可以通過 Robot 圖形界面和命令行執行測試腳本,也可以從 Rational TestManager 按照不同的配置計劃在遠程機器上的復雜的測試腳本的執行。
關于作者
kerry UML 工程組織 咨詢顧問, 主要從事軟件開發過程的咨詢和指導工作,是 Rational 產品的熱衷者,同時對 J2EE 技術有著豐富的經驗?梢酝ㄟ^ kerrylike@163.com 聯系作者。