AutoRunner 功能自動化測試專案實訓之AutoRunner產品設計目標（三）

一、提高迴歸測試的覆蓋率，提高測試質量

對於功能已經完整和成熟的軟體，每次釋出一個新的版本，其中大部分功能和介面都和上一個版本相似或完全相同，這部分功能特別適合於自動化測試， 從而可以讓測試達到測試每個特徵的目的。通過 AutoRunner 來編寫回歸測試的測試用例，並且再每次釋出版本的時候通過執行所有的測試用例來進行迴歸測試，能夠覆蓋大量的功能——人工測試無法進行測試的功能。

二、 每日測試的高效率

DCC 版本的釋出週期往往比較短，也就是開發週期只有短短的幾個月，而在測試期間是每天/每 2 天都要釋出一個版本供測試人員測試，一個系統的功能點有幾千個上萬個，人工測試是非常的耗時和繁瑣，這樣必然會使測試效率低下。AutoRunner 通過高效率的自動執行測試用例，允許每天對版本進行測試，提高測試效率。

三、具有一致性和可重複性

由於每次自動化測試執行的指令碼是相同的,所以每次執行的測試具有一致性, 人是很難做到的. 由於自動化測試的一致性，很容易發現被測軟體的任何改變。

四、 更好的利用資源－－周未/晚上

理想的自動化測試能夠按計劃完全自動的執行, 在開發人員和測試人員不可能實行三班倒的情況下, 自動化測試可以勝任這個任務, 完全可以在週末和晚上執行測試. 這樣充分的利用了公司的資源,也避免了開發和測試之間的等待。

五、 解決測試與開發之間的矛盾

通常在開發的末期,進入整合測試階段,由於每次釋出一個版本的初期,測試系統的錯誤比較少,這時開發人員有等待測試人員測試出錯誤的時間. 事實上在迭代週期很短的開發模式中，存在更多的矛盾， 但自動化測試可以解決其中的主要矛盾。

六、將煩瑣的任務轉化為自動化測試。

大量重複的測試是非常繁瑣的，並且需要消耗大量的人力才能夠完成。自動測試能夠很好的解決這個問題，不需要繁瑣的勞動，不需要大量的人員。

七、 增加軟體信任度

只有經過大量測試用例測試過的版本才是可靠的 ，而只有使用自動測試才能夠保證在段時間內完成大量的測試用例。

八、系統體系結構特性要求

8.1、系統要求

8.1.1、作業系統環境：

WindowsXP~win10；winserver2008~winsever2012

8.1.2、測試用例資料格式：

XML；EXCEL

注：理論上支援 jdbc 介面的資料庫。

8.1.3、AutoRunner 是一個自動化的功能測試工具，它可以和測試管理工具、缺陷跟蹤工具一起來使用，可以將自動化測試的設計和結果統計分析納入到測試管理平臺，給企業以最客觀的測試過程分析和結果統計以達到更好的效果：

AutoRunner

測試管理工具

缺陷跟蹤工具

測試需求管理

測試用例管理

測試計劃

測試執行

測試結構設計

測試指令碼錄製、

編寫、除錯

檢視測試結果

檢視缺陷

檢視缺陷跟蹤報告

 

 

8.2  系統效能

AutoRunner 針對與系統的功能測試自動化，對效能要求不高：自動測試的指令碼執行速度，超過人工執行的速度。

 

 

8.3 、擴充套件能力

8.3.1、擴充套件驗證點：

所謂的驗證點，就是用來驗證被測試系統返回資料或者狀態是否和預期一

致的點。AutoRunner 提供了完整的驗證點功能，用來驗證字串、bitmap

檔案是否正確，對字串可以驗證是否符合定義的“正規表示式”。當然，由

於驗證往往是非常複雜的，例如：當我們使用一個功能向 database中增加

一條記錄後，通過 jdbc 來檢視該記錄是否已經被增加。這就需要使用者根據

具體的資料庫來編寫一個功能來實現特殊的校驗點。

系統提供了基本的校驗方法，允許使用者自己來通過編寫一個特殊校驗的類，

或者一個特殊的方法來定義特殊的校驗點（呼叫的結果如果希望反映的標

準的測試報告中，就需要呼叫系統提供的基本方法），最終實現對驗證點

功能的擴充套件。

 

 

8.3.2、自動錄製時候的針對使用者自定義元件的識別

根據國外測試人員的經驗，編寫指令碼的工作中，大量的工作都被使用者的自

定義元件消耗了。

由於很多的測試工具本身支援一組標準的控制元件，在自動錄製的時候，系統

能夠根據這些元件來生成測試指令碼，並且允許回放這個指令碼來執行測試。

當使用者自定義了一個元件之後，使用者定義的元件是基於基本元件的，系統

就往往無法自動識別這些元件，導致測試人員錄製指令碼的時候非常複雜 ：

名稱不同、識別困難、執行時刻同步點錯誤。

AutoRunner 提供了對元件的定義功能：所有的元件型別必須被定義，並且

只有最上層的已定義型別元件被識別，其他的元件都不會被識別。如果用

戶定義了自己的元件，那麼他只需要把他自己定義元件的：類名、

contexttype增加到元件定義檔案中就可以了。

AutoRunner 的這個功能大大增強了對使用者自定義元件的支援，使得測試人

員能夠錄製正確的指令碼、編寫正確的指令碼，減少差錯。

 

 

8.3.4、對第三方測試管理工具的支援

AutoRunner 提供了對第三方測試管理工具的支援：通過資料檔案或者資料

庫，就可以傳遞測試用例資訊、測試用例資料資訊。

AutoRunner 提供了命令列的支援，支援使用者在遠端啟動和呼叫，這就為第

三方的測試管理工具提供了一個執行呼叫介面。

 

 

8.3.5、對第三方缺陷跟蹤工具的支援：

同樣的，AutoRunner 可以提供針對缺陷跟蹤工具的 API 的呼叫，和第三

方缺陷跟蹤工具達到“無縫連線”。

8.4  可靠性和可用性

8.4.1、系統的可用性和可靠性由幾個指標來衡量：

第一， 系統的出錯處理能力。也就是，當系統出現錯誤之後，

是否能夠提供完善的錯誤處理機制，跳過錯誤，繼續執行允許執行的下一

個功能點測試。

第二， 系統執行過程中工具不會出現異常，導致測試無法正常執行。

第三， 測試指令碼出現異常，提供強大的除錯功能。

第四， 當 AutoRunner 升級之後，原有測試指令碼能夠相容，繼續使用。

具體到 AutoRunner，如下：

系統的出錯處理能力：

對所有的測試用例來說，每一個測試用例都是一個繼承自 class TestCase

的子類，在測試過程中的動作都是呼叫父類 TestCase中的方法來實現的 ，

如：setWindow()，setValue(), getValue(), setProperty(), getProperty()等。這

些方法在 出錯的時候（一 般都是同步點錯誤 ），會丟擲 一個異 常

syncException。

用例只有一個主要的測試過程類：test() throws syncException。當 test()執

行的時候，如果出現異常，就會丟擲一個 syncException，外部的方法會

catch 到這個 syncException，然後使用一個通用的方法來處理錯誤。

測試人員只需要編寫一個標準的錯誤處理方法就可以完成這些所有的工

作。

當然，這個測試人員需要對 java 有一定的瞭解和熟悉，但是這樣的人員只

需要一個就可以了，因為出錯處理程式只需要一個，它用來處理所有的錯

誤，並且使得下一個測試用例可以被執行。

 

 

8.4.3、IDE 的穩定性

在一個大量的測試用例被執行的時候，實際上 IDE 並沒有工作，它只是在

等待響應。

執行測試的過程，就是執行 java 各個不同的類的過程。而 TestCase 是一

個非常健壯的類，不會導致系統出現異常。因此，IDE 從理論上是非常堅

固的。

另外基於 java 的系統一般而言，穩定性都非常好。特別是所有的測試用例

基本上都是繼承自 class TestCase。

 

 

8.4.4、產品升級

當產品升級的時候，對原有測試用例影響最大的就是 TestCase類的變化。

classTestCase實際上只是一個 abstract，只實現了一個基本的 interface，實

際的功能都是由底層的元件來實現的，這個元件在 IDE 啟動的時候被

load，跟測試人員自己編寫的測試用例沒有任何直接關係。

因此當底層的類發生變化的時候——系統升級可能會帶來底層類的變化

——對測試指令碼沒有影響。

8.5  國際支援

支援多種語言 Unicode 編碼形式；

使用者可以選擇中英文介面的版本。

系統對語言編碼的識別是由系統自動完成，使用者不必考慮選碼的問題。

9. 系統基本功能

9.1  測試用例建立與錄製

建立測試用例

使用者能夠建立一個測試用例。建立的測試用例指令碼是空的，需要使用者自己

來加入包的名字、類的名字等等。

建立測試用例可以在專案瀏覽器中使用右鍵選單或者系統的選單。

如果使用者是一個非常熟悉測試用例的測試人員，就可以自己手工

來編寫測試用例的程式碼了。但是，由於資原始檔不存在，所以如

果希望自己編寫的測試用例能夠執行的話，還需要手工編寫對應的 xm l

資原始檔。

建立測試用例的過程一般是從錄製開始的。

通過錄制建立測試指令碼

當你從選單或者工具條啟動“錄製”命令，系統開始記錄你的所有操作 ，

並且在記錄過程中把生成的指令碼檔案顯示在編輯器上面。

錄製的結果是，你得到了：1）一個可以被執行的測試指令碼檔案；2）測試

指令碼相關的資原始檔，這個資原始檔用來記錄所有指令碼中用到的視窗、組

件的屬性（如：名稱、位置、tabindex、型別等）。

9.2  測試用例編輯

測試用例的結構

測試用例是具有結構的，它能夠執行，首先要符合 java 的語法和主程式入

口。並且它需要使用測試基本類提供的功能來完成測試。

測試用例編輯

AutoRunner 提供了強大的測試用例編輯功能：第一，提供了 java 指令碼的

關鍵字識別技術，能夠識別系統的關鍵字，避免語法錯誤；第二，提供了

實時語法分析的功能，在編輯過程中動態分析語法，並且對語法錯誤動態

報警，儘量避免編譯時刻再出現錯誤。

9.3  測試用例引數化

什麼是資料驅動？

錄製完成測試用例之後，你就得到了一個測試指令碼。如果這個測試指令碼只

能夠被執行一組資料，並且資料是固定不變的，那麼你每一次的測試就只

能夠執行很簡單的功能了。

邊界條件、路徑覆蓋，需要使用一個指令碼、很多組資料輸入才能夠完成 ，

固定的資料無法滿足要求。

資料驅動就是指能夠把需要輸入（和驗證）的資料引數化，通過指令碼執行

不同的資料，就實現了資料驅動，也就是資料與指令碼分離。

AutoRunner 實現了指令碼與資料分離：指令碼使用 java 的指令碼，在指令碼執行

的時候，從資料來源中讀取資料。

AutoRunner 使用了 DataSource這樣一個介面來實現引數化。

DataSource 通過外部定義的元件實現對外部資料來源的操作功能，從外部獲

取資料。

DataSource 本身就是通過外掛來實現的，IDE 只定義了 interface，外部插

件決定系統的行為。通過載入不同的外掛，使用者可以使用不同的資料來源來

訪問資料。如：excel、xml、db 和其他。

測試用例引數化

AutoRunner 在自動錄製完成之後，可以通過選單“引數化”，AutoRunner

會彈出所有的物件樹，提供給使用者勾選，選中部分進行自動引數化。引數

化的結果：1）指令碼變為引數化指令碼；2）資料池自動增加了選擇的引數列

表。

在測試用例引數化之後，使用者仍然可以手工來修改，實現進一步的引數編

輯工作。

建立外部資料來源

只有訪問資料來源的指令碼，沒有外部資料來源，那麼所有的指令碼訪問都會失敗 。

使用者需要建立外部的資料來源。

有兩種方式建立資料來源：

第一，自動通過 IDE 建立。在指令碼檔案中，選中該指令碼的右鍵選單中的“創

建/維護指令碼”，IDE 會自動查詢所有的 datasource 操作，並且更新資料來源。

第二，通過手工建立。需要在外面手工編輯檔案。

9.4  增加同步點和驗證點

同步點的概念

在進行輸入輸出之前，就需要對系統進行同步，使得輸入和輸出能夠針對

正確的視窗或者元件，以免出現異常和錯誤。如果同步條件沒有出現，系

統就需要等待一段時間，來滿足執行系統的要求，使得需要操作的元件能

夠顯示出來。

自動同步和手工同步點

所謂的自動同步點，是隻在操作過程中，由於本身需要執行操作，如對某

個元件輸入一串字元，而需要等待這個元件出現，這種同步點是系統在操

作過程中自動加入的，我們稱為“自動同步點”。

也有一些情況，需要手工增加一些同步點，當系統執行到一定時候，需要

等待一個條件出現再繼續執行，這種同步點我們稱為“手工同步點”。

使用者需要關心的是手工同步點，例如：需要等待一個 image 能夠正確顯示 ，

然後再繼續下面的工作。它不是單純的等待，而是每間隔一段時間就去查

看是否滿足同步條件，如果滿足系統就繼續執行，如果不滿足而系統超時

時間沒有達到，就繼續等待。如果出現超時，那麼就丟擲 SyncException。

驗證點

測試的目的是看執行一個過程，結果是否和預期結果一致。

驗證的方法就是檢視結果是否一致，這個點我們稱作“檢查點”。

驗證成功則繼續執行，驗證不成功也需要繼續執行，並且把結果寫入測試

報告。

AutoRunner 的驗證點需要手工加入——AutoRunner 不知道使用者需要檢查

那些內容。

增加驗證點

使用者可以使用編輯器來增加檢查點，AutoRunner 提供了方法讓使用者來增加

驗證點。

9.5  測試用例執行

測試用例執行

當測試用例只有能夠被執行才有意義。在 AutoRunner 裡，測試用例是一

個 java 的類（特殊的 java 類）。

這個類首先被編譯，然後執行。通過選單上的“執行”項，你可以執行這

個測試用例。

如果編譯出現錯誤，則會在資訊欄中提示錯誤。

執行支援標準輸出，並且把標準輸出顯示在 AutoRunner 下面的輸出框裡面。

多次執行

當測試用例被執行的時候，AutoRunner 會提示，需要使用者輸入當前測試腳

本被引數化之後，需要使用的資料列表的行號範圍。輸入之後，會多次執

行這個測試指令碼，每次使用一行的資料，達到一個指令碼中執行多次的目標。

測試跟蹤除錯

測試指令碼本身也可能出錯，也可能由於被測試物件的變化（如缺少了一個

物件）而出現錯誤。

因此，定位和排除錯誤的方法，我們使用了跟蹤除錯。AutoRunner 使用了

java 作為測試指令碼，並且每個測試指令碼都是一個 java 的類。因此

AutoRunner 實現了 java 的跟蹤體系結構：JDA。

AutoRunner 允許使用者設定斷點、檢視本地變數值、檢視指定的變數的值 ，

並且提供了單步執行的各種模式。

 

 

10.AutoRunner  的特點

10.1、評估自動測試工具的關鍵在於：

第一，很高的建立測試用例的生產率；

第二，降低使用者的二次開發成本；

第三，便於維護使用；

第四，便於測試案例的資料驅動擴充套件；

第五，測試用例資源的延續性；

第六，擴充套件性。

下面，我們就 AutoRunner 在這幾個方面的特點簡要介紹：

 

AutoRunner 具有很高的生產率。自動測試工具建立一個測試用例指令碼的

時間成本為手工測試一次的 3－10 倍，可見建立自動測試的起始是需要一

定的成本的。

如何降低建立測試用例的成本，是自動測試工具的關鍵。AutoRunner 的優

勢在於：首先，優秀的自動識別元件功能。指令碼能夠在錄製完成之後直接

使用，能夠自動適應出現的各種情況，如：視窗位置、title、大小等的變

化，元件位置、名稱的變化。通過自動識別能夠識別處元件，從而降低對

編寫指令碼的要求，提高了自動錄製的可用性。第二，提供了資料驅動框架 。

很多測試工具雖然支援引數化的功能，但是需要手工完成資料驅動框架 ，

才能夠實現資料驅動：從指定的檔案中獲取資料。AutoRunner 自動定義標

準的資料驅動模式，定義了標準的資料驅動格式，降低了增加測試用例的

成本。雖然建立一個測試指令碼需要一定的時間，但是在測試指令碼建立之後

增加一組資料的時間卻非常短。

 

10.2、模糊識別。AutoRunner 對每種元件定義了標準的模糊識別指標。在錄製

測試用例之後，系統的資原始檔就會根據系統的配置檔案生成確定識別權

重的指標。在測試指令碼被執行的時候，通過權重演算法來進行模糊識別和匹

配。

 

 

10.3、關鍵字驅動。AutoRunner 提供了領先的關鍵字驅動技術，支援指令碼編寫

使用專家檢視，不熟悉指令碼的使用者使用關鍵字檢視，並且實現在指令碼檢視

與關鍵字檢視之間的相互轉換，既提升了效率，也提升了易用性，既能夠

給熟悉指令碼的測試工程師提供高效的工作平臺，也能夠給不熟悉測試指令碼

的測試工程師使用方便。

使用者可以對系統配置檔案的識別引數進行調整，達到修改整個錄製指令碼識

別引數權重的目標，便於提高整個專案中指令碼開發的效率。

在使用者錄製完成指令碼之後，可以對對應的資原始檔的權重屬性進行修改 ，

使系統能夠定製具體的模糊識別物件，對指令碼元件識別演算法作特殊處理。

通過模糊識別演算法，能夠極大地提高指令碼執行的可靠性，對於由於類似組

件位置、大小等變化之下的指令碼執行，能夠起到非常良好的效果：使用者不

需要因為介面小的修改而導致來修改測試指令碼。

 

10.4、便於維護使用。用例完成之後，隨著應用系統的修改、應用系統版本的提

升，同樣需要維護這個測試用例庫，因此維護使用是非常重要的功能。

維護方便性主要體現在幾個方面：簡潔的框架、容易理解的指令碼、方便的

除錯功能。

10.5、AutoRunner 提供了針對測試用例的框架，這個框架包括：用例層次劃分

（AutoRunner 的用例由 Action 組成，每個 Action 包含對一個 Window 的

所有操作，AutoRunner 允許在用例之間共享 Action 來提高系統的可維護

性）、資料驅動框架、自動同步、資料校驗模式等。使用這些框架能夠非

常容易的維護測試用例庫。

10.6、AutoRunner 採用了 java 的語法，測試人員使用的語法非常簡單，便於理

解和使用。並且，由於系統提供了關鍵字驅動的框架，所以對一般的維護

而言，根本不需要了解 java，只需要知道最基本的操作就可以。

AutoRunner 遵守 JDA 的標準，提供了最強大的系統除錯功能：從設定斷

點、單步執行、變數檢視、表示式檢視等方面提供支援，便於測試人員容

易排除錯誤。

10.7、另外，AutoRunner 提供了強大的編輯器，在一般編輯器能夠動態識別語法

關鍵字的基礎上，還能夠同時提供語法檢查——在編輯的時候從事語法檢

查，對錯誤的語法實時提示。這個編輯器對於比較缺乏程式設計經驗的程式設計師

來說非常重要。

 

10.8、測試用例資源的延續性和擴充套件性。測試用例庫本身也是一種資源它和應用

版本是對應的關係，隨著應用系統版本的升級，用例庫也會升級，那麼回

歸測試的效果才能夠最大化。

對於自動化測試工具來說，要保證這個資源，就需要保證：測試指令碼的兼

容性 。另外由於隨著應用的發展，測試工具的功能需要大幅度的提升，

因此工具的可擴充套件性也需要保證才能夠保證測試用例資源的延續性。

AutoRunner 使用了 java 語言作為基礎，並且實現了 java 除錯功能，可

以隨著 java 的發展不斷的發展，擴充套件自己的功能。

採用 java 語言是一個巨大的優勢，比測試工具自己使用一種語言要方便的

多。從根本上說，AutoRunner 不是採用了哪種語言的語法，而是從根本上

就是 java 語言。這和採用 vbscript 或者 c 語言語法的工具是截然不同的。

在擴充套件外部功能方面，由於 AutoRunner 使用了 java 語言，允許使用外部

的包，也就是說可以任意增加指令碼本身的功能而不受語法的限制和工具本

身是否支援外部包的限制——在最大程度上提高了擴充套件性。