Rational 公司邀請我看了看它們的新產品,Rational PobotJ。它們邀請我有兩個原因。一個原因很明顯,就是由于我長時間進行測試自動化的工作,了解大量的人們正確使用(以及誤用)這些測試工具的方式。第二個原因就是由于我從來沒有使用過Rational Robot或者該公司的Test Manager模型,所以憑借我的自動化背景可以清晰地洞察出他們是如何設計軟件測試自動化解決方案的。
Rational 公司邀請我看了看它們的新產品,Rational PobotJ。它們邀請我有兩個原因。一個原因很明顯,就是由于我長時間進行測試自動化的工作,了解大量的人們正確使用(以及誤用)這些測試工具的方式。第二個原因就是由于我從來沒有使用過Rational Robot或者該公司的Test Manager模型,所以憑借我的自動化背景可以清晰地洞察出他們是如何設計軟件測試自動化解決方案的。
我拿到了一份Rational RobotJ的β版,然后就急于開始研究Rational 的最新工具會給軟件測試帶來什么樣的變化。多年來,我已編寫了很多Rational Visual Test自動化腳本,我很想看看這個工具在測試基于Web的應用程序領域中會取得什么樣的成就。
我花了幾分鐘安裝該工具,到處點擊來熟悉界面的內容,主要是想看看這到底是個什么東西,最后我決定先使用一下工具欄中的Record new RobotJ script 按鈕。這東西到底怎么樣,我暗自思忖,且看看它會創建出什么樣的冗長腳本來,既可以準確地記錄我的操作,還可以保持同步,以保證回放功能確實好使。當使用記錄和回放(record-and-playback)工具時,我稍稍有點嘲諷心理。
雖然更喜歡舊式優秀的匆匆編寫代碼的方式,但是我還是渴望了解這個工具的更多功能。不過,使用記錄器是了解有關自動化工具以及正確使用該工具的最佳方式之一。您馬上就會發現,記錄器不僅僅曾經是(現在也是)深入學習RobotJ的偉大工具,它也是Rational所希望的幫助人們創建大量測試腳本的最佳方式。它也確實做得很棒!
我曾經聽到過有關測試自動化的傳言,據說Rational 準備發布一種新產品,主要用于測試HTML與基于Java 的web 應用程序。而且,考慮到面向對象編程語言的特有優點,準備使用Java 作為其編程語言。我很想看到它的面世,越快越好。這肯定是一種新型有關編程的玩具語言,我已經等不及要使用它了。
多年來我一直選擇Rational Visual Test 編寫軟件測試自動化的腳本。它使用類似Visual Basic 的語言,編程進行起來簡單直接,同時它也具備使用指針處理復雜數據結構的高級功能,這也使它成為一種真正的語言。Visual Test 甚至在版本6.0中加入了測試網頁的功能。該功能確實好使,而且一直在發揮著作用,但是在測試工具中加入此功能的最初目的是用來測試Microsoft 的Windows 程序的。Visual Test 一直努力成為終極的、無所不能的軟件測試自動化工具,而且可以肯定地說,多年來它一直如此。
現在,我仍然使用VT ,即使對于那些非測試的解決方案。但是,當一種主要用于測試web應用程序的新型工具即將發布的時候,我確實想看看它到底能夠實現什么功能,而且我也十分喜歡使用Java 作為腳本語言。
我一直盡力將良好的編程實踐教授給我的學生和客戶,同時還有創建類似面向對象腳本的方法,以及使用并不是那么面向對象的語言完成數據隱藏、封裝和簡單形式的繼承。這些方法都十分有效,但是如果使用面向對象語言的話,就不僅僅是鼓勵使用這些方法那么簡單了,而是可以加強進行這些實踐。這就是我為什么喜歡RobotJ 使用Java 作為其腳本語言的原因了。
我想我還是從簡單的地方開始吧:單擊一些鏈接來看看它在屏幕顯示不下時是否較好地處理了瀏覽器窗口的滾動以及頁面加載的滯后時間是否較長。但是,隨后我又從另一個角度進行了一下思考:如果測試駕駛一輛承諾具有強大發動機和超速懸掛裝置的新型轎車,我能僅僅坐在那里來驗證轉彎信號是否好使嗎?或者來檢驗車載音響中的噪聲程度嗎?好,是的,確實如此。但是除此之外,我肯定想要親自駕駛它,經過大量的彎道,同時收聽廣播中的Talk of the Nation。
顯然,我不會第一次駕駛就經過太多的彎道,因為我不想撞到墻上。我只想讓我記錄的源代碼確實可以進行工作;我還是對記錄的腳本有點懷疑,不知道它是否能夠正常工作。于是,我單擊了記錄按鈕,并且按照下述步驟進行操作:
作為一名測試自動化程序員,我對于使用RobotJ 記錄器預想了很多概念。這些概念都是通過使用Visual Test 和其他測試自動化工具得出的。我預先考慮了許多問題,尤其是:
兼容性:最初,我有點擔心它與Microsoft Internet Explorer 6.0的兼容性問題。Microsoft 不斷快速地推出其瀏覽器的更新版本,我不知道RobotJ 是否能夠跟得上節奏。Rational 肯定在使用IE API 提供的內部對象模型,Visual Test 團隊也是如此,但是Microsoft 的內部二進制數字并不總是如預期那樣的有效,還需要開發團隊再進行大量的工作。我設想對于RobotJ 開發人員也是如此。
腳本長度:我擔心可能會創建出很長的腳本,里面還帶有大量的延遲或者休眠語句,用來模擬我在鍵入和單擊過程中的實際延遲。我也在期待著有大量的命令檢驗瀏覽器窗口的大小和位置、屏幕分辨度以及其他有時可能造成致命故障的錯誤,并且創建出很長的腳本。
延遲的問題:我預想腳本僅僅可以在理想狀態下運行,服務器可以在記錄創建時或者比其更快地進行響應。在服務器滯后時,我預想肯定需要在特定點暫停,例如在單擊鏈接以跳離當前頁時,并使用附加源代碼調整腳本。
不過,我所得到的給了我一個驚喜,讓我非常高興:
兼容性:點擊鏈接,鍵入多個<input type=text>輸入框控件、<textarea> 控件、<select><option>下拉列表框、<input type=submit>按鈕,使用post和get方法提交表單,所有這些都工作正常,沒有問題。我還沒有使用其他的瀏覽器進行測試,但是我很高興地發現它正確地識別了測試狀態下網頁上的許多不同控件,而且更重要的是,回放功能也成功運行。
簡潔的源代碼:源代碼是簡潔的,并且具有良好的可讀性。通過使用Helper 的基類,所有的外部源代碼都從視圖中隱藏起來,只剩下我感興趣的源代碼。正如預料的那樣,加入了注釋幫助指導自動化程序員了解源代碼中的每行都進行了什么操作。不過,還有些我沒有預料到的附加信息也包括于注釋中,特別是按下Place Order Now 按鈕所提交的信息。
同步性:由于源代碼中沒有明顯地加入休眠或者延遲信息,同時Helper 基類也可以處理所有的控件識別問題,所以操作只有在單擊控件時才得以執行。如果是這樣的話,腳本就不會記錄填寫表單和點擊恰當控件的信息。不過,如果頁面仍處于裝載狀態或者仍在識別頁面上的控件和鏈接時,它也可以耐心等待。
為了讓您更加明白,我嘗試在本文檔的開始幾頁中創建一些示例腳本。創建的源代碼展示于下一頁的清單1 中。(注意:必須進行一些細小的格式操作,使本文檔中的代碼更加可讀,包括移去一些自動創建的注釋)。在隨后幾頁中,我會教您如何使用RobotJ 創建這些腳本,并討論一些有關創建腳本的關鍵問題,然后研究運行腳本得到的結果。
原文轉自:http://www.anti-gravitydesign.com