| kerry (kerrylike@163.com) 自動化測試的好處 在過去的數(shù)年中,通過使用自動化的測試工具對軟件的質(zhì)量進(jìn)行保障的例子已經(jīng)數(shù)不勝數(shù)。到現(xiàn)在為止自動化測試工具已經(jīng)足夠完善了,我們完全可以通過在軟件的測試中應(yīng)用自動化的測試工具來大幅度的提供軟件測試的效率和質(zhì)量。在使用自動化的測試工具的時候我們建議盡早的開始測試的工作,這樣可以使修改錯誤更加的容易和廉價,并且可以減少更正錯誤對軟件開發(fā)周期的影響。下圖顯示了手工測試與自動化測試的比較。這個測試案例中包括1750個測試用例和700多個錯誤。 手工測試與自動化測試的比較
| 測試步驟 | 手工測試 | 自動化測試 | 通過使用工具的改善測試的百分比 | | 測試計劃的開發(fā) | 32 | 40 | -25% | | 測試用例的開發(fā) | 262 | 117 | 55% | | 測試執(zhí)行 | 466 | 23 | 95% | | 測試結(jié)果分析 | 117 | 58 | 50% | | 錯誤狀態(tài)/更正檢測 | 117 | 23 | 80% | | 產(chǎn)生報告 | 96 | 16 | 83% | | 時間總和 | 1090 | 277 | 75% |
通過這個表我們可以看出自動化測試與傳統(tǒng)的手工測試在所有的方面都有很大的不同,尤其是在執(zhí)行測試和產(chǎn)生測試報告的方面。 短測試周期中手工測試面臨的挑戰(zhàn) 迭代式的開發(fā)過程已經(jīng)顯示了比瀑布式開發(fā)的巨大好處,并已逐漸的取代傳統(tǒng)的瀑布式開發(fā)成為了目前最流行的軟件開發(fā)過程。在迭代開發(fā)中強(qiáng)調(diào)在較短的時間間隔中產(chǎn)生多個可執(zhí)行、可測試的軟件版本,這就意味著測試人員也必須為每次個迭代產(chǎn)成的軟件系統(tǒng)進(jìn)行測試。測試工作的周期被縮短了,測試的頻率被增加了。在這種情況下,傳統(tǒng)的手工測試已經(jīng)嚴(yán)重的滿足不了軟件開發(fā)的需求。如下圖所示,當(dāng)?shù)谝粋€可測試的版本產(chǎn)生后,測試人員開始對這個版本的系統(tǒng)進(jìn)行測試,很快第二個版本在第一個版本的技術(shù)上產(chǎn)生了,測試人員需要在第二次測試時重復(fù)上次的測試工作,還要對新增加的功能進(jìn)行測試,每經(jīng)過一個迭代測試的工作量會逐步的累加。隨著軟件開發(fā)過程的進(jìn)展,測試工作變得越來越繁重,如果使用手工測試的方法,將很難保證測試工作的進(jìn)度和質(zhì)量。在這種情況下應(yīng)用良好的自動測試工具將勢在必行。通過使用自動化測試工具測試人員只要根據(jù)測試需求完成測試過程中的所需的行為,自動化測試工具將自動生成測試腳本,通過對測試腳本的簡單修改便可以用于以后相同功能的測試了,而不必手工的重復(fù)已經(jīng)測試過的功能部分。 手工測試的問題 同時,現(xiàn)代的 GUI 開發(fā)技術(shù)已經(jīng)非常的先進(jìn)了,它提供給開發(fā)人員快速開發(fā)的能力。這就意味著開發(fā)人員能夠非常快速的改變應(yīng)用程序,并將新的版本交個測試人員進(jìn)行測試。實際上,很多公司每天都會有多個應(yīng)用版本產(chǎn)生。如果還是使用傳統(tǒng)的手工測試的方法是根本不可能符合軟件快速開發(fā)的要求的。 自動化測試的步驟 自動化測試的步驟: 錄制測試過程成為自動化測試腳本
增強(qiáng)和改進(jìn)錄制的自動化測試腳本
執(zhí)行自動化測試腳本完成自動化測試 自動化測試過程 錄制測試過程成為自動化測試腳本 開始自動化測試過程的第一個步驟是根據(jù)測試用例(測試需求)錄制測試活動的過程。當(dāng)測試人員在被測試的應(yīng)用程序中進(jìn)行測試的活動時,自動化測試工具將捕獲測試人員與應(yīng)用程序之間的所有交互,并根據(jù)這些交互生成可重用的測試腳本。測試人員在這個階段需要考慮的一個關(guān)鍵問題就是,使用的測試工具是否有能力在應(yīng)用程序的環(huán)境中捕獲所有與應(yīng)用程序的交互。 這里我們要強(qiáng)調(diào)的是你需要考慮與測試應(yīng)用有關(guān)的所有環(huán)境。讓我們通過一個例子進(jìn)行說明。假如你的應(yīng)用是一個基于 Web 的應(yīng)用,你可能會認(rèn)為我們測試工具只要能夠支持你使用的瀏覽器就足夠了。但這并不是足夠的,在測試基于 Web 的應(yīng)用的過程中,一定會去要和一些其他的補(bǔ)助應(yīng)用打交道,比如也許你需要和某種數(shù)據(jù)庫查許工具進(jìn)行交互以確認(rèn)數(shù)據(jù)被正確的輸入到了數(shù)據(jù)庫,或者也許你需要和注冊表編輯器進(jìn)行交互以驗證注冊表的鍵值。或者也許你將需要和一個電子郵件的客戶端程序交互來驗證從你的 Web 應(yīng)用發(fā)出的郵件。 你對主要測試環(huán)境將是你對瀏覽器,但是你同時要確認(rèn)你能夠通過測試工具來測試其他所有的輔助環(huán)境,這樣才能實現(xiàn)測試的所有環(huán)節(jié)的自動化。如果某一個測試環(huán)節(jié)不能被自動化測試工具支持,它將成為阻礙測試效率的瓶頸。 增強(qiáng)和改進(jìn)錄制的自動化測試腳本 自動化測試過程的第二個步驟是增強(qiáng)和改進(jìn)已錄制的測試腳本。你需要閱讀錄制好的腳本代碼,并對其進(jìn)行適當(dāng)?shù)男韪?。我們舉例說明,當(dāng)你錄制一個腳本時,自動化測試工具將記錄你輸入的所有數(shù)據(jù)。用一個簡單的腳本來說,你的腳本可以讀出一個文本文件的內(nèi)容,你可以通過設(shè)置參數(shù)為這個腳本輸入不同的數(shù)據(jù)集。這樣這個腳本變得更加有用了。 為了實現(xiàn)這一點,你需要確保你能夠得到一種簡單的語言以支持你所有的需要。 你還要確認(rèn)你的測試工具能夠支持所有你應(yīng)用程序中的控件。通常情況下,開發(fā)人員將創(chuàng)建自己的GUI 或者甚至是一些非 GUI 的對象在應(yīng)用程序中。你需要確認(rèn)你能夠通過修改測試腳本來使用這些控件。 執(zhí)行自動化測試腳本完成自動化測試 執(zhí)行單個或者少量的測試腳本是十分簡單的,但是當(dāng)回歸測試不斷的增加時,情況就變得復(fù)雜多了。你必須確認(rèn)你能夠協(xié)調(diào)測試腳本之間的關(guān)系,并能夠從多臺機(jī)器上按照多種配置來執(zhí)行測試腳本。 Ratioanl Robot 幫助你實現(xiàn)有效的自動化測試 Robot 對錄制測試腳本的支持 Robot 可以監(jiān)測到測試人員與應(yīng)用程序之間的所有交互行為,并可以產(chǎn)生相應(yīng)的測試腳本。 現(xiàn)在你必須理解自動化測試中關(guān)于驗證點和檢查的主要區(qū)別。當(dāng)你進(jìn)行手工測試時,通常你可以通過看屏幕中顯示的結(jié)果來判斷應(yīng)用程序執(zhí)行是否是正確的,或者你可以將屏幕上的結(jié)果與文檔或者其他的一些結(jié)果基線進(jìn)行比較。在 Robot 中這種比較是通過在測試腳本中設(shè)置驗證點實現(xiàn)的。在執(zhí)行腳本時Robot 會在驗證點獲取測試感興趣的數(shù)據(jù),然后與已設(shè)定好的結(jié)果集進(jìn)行比較判斷測試是否通過。這個比較的過程叫作檢查。 Robot支持的環(huán)境 目前 Robot 對幾乎所有流行的應(yīng)用環(huán)境多有良好的支持和工作表現(xiàn)。尤其是對象 HTML、Java 和 .NET 應(yīng)用、 Visual Basic,、PowerBuilder,、Delphi、 Oracle 表單 和 MFC 控件(控件最常用在 C和 C++ 的應(yīng)用中)有著非常強(qiáng)大的支持。 在 Robot 覆蓋了幾乎所有的應(yīng)用環(huán)境的同時,仍然存在一些用很少被使用的語言和環(huán)境創(chuàng)建的程序部分,對于這些環(huán)境, Robot 具有一種通用的記錄引擎可以捕獲幾乎所有的基本界面交互。因此可以說,使用 Robot 能過滿足幾乎所有的測試環(huán)境要求。 測試的驗證點 驗證點是一個 Robot 測試腳本中的一個術(shù)語,在驗證點上你可以檢查某些系統(tǒng)表單的行為。 在 Robot中最常用的驗證點是對象屬性和對象的數(shù)據(jù)驗證。這些驗證點被用于捕獲對象的狀態(tài)和對象測試期間的數(shù)據(jù)。在 Robot 中創(chuàng)建驗證點與選擇想得到的驗證點和識別想要被測試的對象一樣的簡單。 但是很多情況下我們想要的驗證點可能并不是眼睛可以看到的控件。就像下面圖中顯示的,測試者看到的是瀏覽器中各個元素的結(jié)果值,這些結(jié)果值 Robot 也可以看到,但測試者卻看不到網(wǎng)頁上對象的屬性,比如網(wǎng)頁的 Cookie 屬性,但是這些對象屬性都可以被 Robot 看見。 Robot 的測試驗證點 一旦驗證點被捕獲了,信息就會被存儲在測試數(shù)據(jù)區(qū)域。在執(zhí)行回放時,測試捕獲的數(shù)據(jù)將與測試數(shù)據(jù)區(qū)域中的數(shù)據(jù)基線進(jìn)行比較。如果比較結(jié)果有任何的不同,他們將獲被標(biāo)記為"失敗"并被記錄在測試日志中。 Robot 還具有對整個網(wǎng)站的斷裂鏈接進(jìn)行檢查的能力,這也是通過設(shè)置驗證點實現(xiàn)的。 Robot 對增強(qiáng)、改進(jìn)測試腳本的支持 一旦腳步錄制完成,在某些情況下,你可以直接執(zhí)行它。對于一個簡單的腳本,可能不需要進(jìn)行任何的改進(jìn)工作。然而,多數(shù)的測試腳本將從通過改進(jìn)與增強(qiáng)中受益。改進(jìn)和增強(qiáng)測試腳本的工作非常簡單,就像在程序代碼中添加幾行代碼以處理一些條件邏輯一樣簡單,這對于有一點開發(fā)語言基礎(chǔ)的人來說也是很容易的工作。舉一個簡單的例子,你需要測試在給定的環(huán)境中計算機(jī)屏幕上是否彈出了一個窗口。在這個例子中,你只需要在測試腳本的代碼中添加簡單的類型聲明以處理窗口是否出現(xiàn)。 靈活的編程語言 Robot 使用 SQA Basic 語言對測試腳本進(jìn)行編輯。SQA Basic 遵循Visual Basic 的語法規(guī)則并且為我們提供了非常適合與測試環(huán)境的方便的閱讀語言代碼的方式。通過使用這種語言,即便是很少編程經(jīng)驗的測試人員也能夠很容易的理解代碼的含義。對于哪些有豐富編程經(jīng)驗的人來說,他們將會發(fā)現(xiàn),SQA 可以非常靈活的進(jìn)行一些高級的編程,比如利用 COM 對象或者訪問Windows 的編程接口。 SQA Basic 語言是從 Visual Basic 語言中演化而來的,同時它對語法進(jìn)行了擴(kuò)展,添加了一些測試專用的命令。這些新的命令擴(kuò)展了 Robot 對所有 GUI 對象的編程訪問能力,同時也使通常的編程任務(wù)―象創(chuàng)建一個數(shù)據(jù)驅(qū)動的測試―更加的簡單。 Robot 靈活的滿足了客戶需要的擴(kuò)展性 對于測試人員來說,無法實現(xiàn)自動化測試的一個共同原因是,他們無法測試自定義的控件。自定義的控件通常是被開發(fā)人員編寫的,或者是從特定的控件供應(yīng)商買來的以填補(bǔ)開發(fā)的缺口,而這些控件的并不一定會保證是在標(biāo)準(zhǔn)的控件環(huán)境下被創(chuàng)建的。這些控件使開發(fā)人員的工作更加簡單的同時,卻給測試人員的工作帶來了極大的麻煩。 通常的情況下, Robot的通用錄制機(jī)制將可以支持多數(shù)的自定義的控件。但是也存在著 Robot 本身無法訪問到被給的屬性或者控件的數(shù)據(jù)的情況。在這種情況下,也不要感到無助, Robot 具有非常好的擴(kuò)展接口,這個擴(kuò)展接口使 IBM Rational 的合作伙伴可以擴(kuò)展 Robot 的功能,以支持幾乎任何的控件。這就可以使測試人員從問題控件中解脫出來,將精力放到測試任務(wù)之中。 Robot 對執(zhí)行測試腳本的支持 一旦完成了了錄制和改進(jìn)測試腳本,就應(yīng)該開始執(zhí)行腳本完成測試了。 在執(zhí)行或者回放時, Robot承擔(dān)了這個任務(wù)。Robot 重復(fù)所有的用戶交互,計算當(dāng)前的應(yīng)用程序結(jié)果與驗證基線的任何差異,并將結(jié)果記錄在測試日志中。在所有的測試腳本被執(zhí)行完后,QA 小組檢查測試日志評估他們應(yīng)用程序的健康性。 成功的腳本執(zhí)行的關(guān)鍵在于擁有多執(zhí)行點的能力。有時你可能希望只是執(zhí)行單個的或者少量的腳本,其他的時候你希望執(zhí)行所有的測試用例。這兩種情況是需要不同的考慮的。 Robot 對執(zhí)行測試腳本的靈活性 Robot 給你提供了你所需要的執(zhí)行腳本的靈活性。你可以以以下的方式執(zhí)行測試腳本: 從Robot 圖形界面中執(zhí)行腳本
從Robot 命令行中執(zhí)行腳本
從TestManager 中執(zhí)行腳本(具有遠(yuǎn)程執(zhí)行腳本的能力) Robot 執(zhí)行測試的方式 單一的腳本或者少量的腳本能過從 Robot 圖形界面中或者從命令行被執(zhí)行。更加復(fù)雜的大量的測試腳本能夠在 IBM Rational TestManager 工具中被創(chuàng)建和執(zhí)行。 當(dāng)從 TestManager 中執(zhí)行測試時,你可以獲得在遠(yuǎn)程的機(jī)器上執(zhí)行測試的增強(qiáng)能力。通過在遠(yuǎn)程的機(jī)器上安裝"測試代理",TestManager 可以與遠(yuǎn)程的機(jī)器進(jìn)行通訊并計劃在遠(yuǎn)程機(jī)器上進(jìn)行測試腳本的執(zhí)行 - 這個遠(yuǎn)程機(jī)器可能是在隔壁房間或者根本是在其他的地方! Robot 與 Rational TestManger 緊密的集成實現(xiàn)自動化測試的有效管理 Robot 通過與 Rational TestMananger 的集成可以實現(xiàn): TestManager可以協(xié)調(diào)測試執(zhí)行的時間安排和測試腳本的依賴關(guān)系
以中心控制的方式計劃在多臺遠(yuǎn)程的機(jī)器上執(zhí)行測試
TestManager 可以對測試進(jìn)行配置 (如被制定到 Windows XP 平臺上的測試只能在 Windows XP 平臺上執(zhí)行) 從 Rational TestManager 執(zhí)行測試 從 TestManager 執(zhí)行測試提供了創(chuàng)建復(fù)雜的測試執(zhí)行組合。TestManager 可以協(xié)調(diào)測試執(zhí)行的時間安排和測試腳本的依賴關(guān)系。當(dāng)你的回歸測試不斷增長時,這種能力時絕對必要的。 當(dāng)從 TestManager 執(zhí)行測試腳本時,你將獲得管理測試配置的增強(qiáng)能力。TestManager 是"可配置的" ,這就意味著當(dāng)它計劃在遠(yuǎn)程機(jī)器上執(zhí)行一個測試腳本時 -它對遠(yuǎn)程機(jī)器是可配置的(操作系統(tǒng)、處理器和其他任何條件) - 并針對配置來執(zhí)行測試腳本。因為一個測試腳本需要對不同的操作系統(tǒng)有一些稍微不同的版本,比如 Windows 98 和 Windows XP。TestManager 將僅僅對被給定的測試代理配置發(fā)送正確的測試腳本。 Robot 功能特點的總結(jié) 最后我們來對 Robot 成功實現(xiàn)自動化測試的功能特性作一個總結(jié)。 Robot 具有廣泛的環(huán)境支持。Robot 給你很好的靈活性來測試在幾乎所有環(huán)境中被創(chuàng)建的應(yīng)用程序。 Robot 提供了靈活的和可擴(kuò)展的腳本語言 - SQA Basic 。 SQA Basic 是足夠簡單易懂的,沒有編程經(jīng)驗的測試人員也可以很容易的理解,SQA Basic 同時也是足夠強(qiáng)大的,可以滿足專業(yè)的測試工程師進(jìn)行復(fù)雜的編程需求。Robot 的通用錄制引擎具有良好的擴(kuò)展性,使你可以建立對任何控件的支持。當(dāng)你排除了對控件的困擾時,你便可以將精力放到測試工作上。 Robot 提供了非常靈活的執(zhí)行測試腳本的方式,你可以通過 Robot 圖形界面和命令行執(zhí)行測試腳本,也可以從 Rational TestManager 按照不同的配置計劃在遠(yuǎn)程機(jī)器上的復(fù)雜的測試腳本的執(zhí)行。 |