【導(dǎo)讀】testingfunctions.

　　

【正文】 端模塊的強大功能幫助下，沒有任何測試知識的測試人員，也可以在很短的訓(xùn)練時間掌握它。此外，由于是純 Java 代碼編寫，自動化測試系統(tǒng)的核心可以支持跨平臺的執(zhí)行，它同樣可以支持分布式執(zhí)行，通過分離作業(yè)控制端和執(zhí)行服務(wù)端來實現(xiàn)。理論上每個測試業(yè)務(wù)都可以支持自動化測試系統(tǒng)，這歸功于其優(yōu)秀的內(nèi)在功能 —— 自定義的 API庫，它可以針對不同的特殊目標(biāo)與 Tcl 腳本語言迅速開發(fā)，并且 API 對工作在前端系統(tǒng)的測試人員來說是透明的，他們需要做的只是根據(jù)具體情況填充合適的數(shù)據(jù)到工作測試界面。 1. 相關(guān)工作 關(guān)于自動化測試最常用的方法包括回歸測試、功能分塊檢測、數(shù)據(jù)驅(qū)動和關(guān)鍵字驅(qū)動。回歸測試通常應(yīng)用在 GUI 測試產(chǎn)品，如 WinRunner。功能分塊檢測方式是數(shù)據(jù)驅(qū)動和關(guān)鍵字驅(qū)動方式的一種初期樣板，從功能不同的數(shù)據(jù)和使用數(shù)據(jù)文件提供的輸入來和預(yù)期的結(jié)果對比驗證。然而，使用這種方法的測試不僅必須保持詳細(xì)的測試計劃的具體數(shù)據(jù)，也必須重新輸入各種所需的數(shù)據(jù)到數(shù)據(jù)文件中。數(shù)據(jù)驅(qū)動的方法是通過電子表格文件記錄數(shù) 據(jù)，如 Excel 和依靠各種 API 和關(guān)鍵數(shù)據(jù)執(zhí)行的測試腳本。關(guān)鍵字驅(qū)動是一種先進(jìn)的數(shù)據(jù)驅(qū)動的方法，該方法使用實際測試人員開發(fā)使用含有特殊關(guān)鍵字的電子表格的測試用例文檔。在這種方法中，整個測試過程是數(shù)據(jù)驅(qū)動和關(guān)鍵字控制處理。由此，自動化測試系統(tǒng)在各項基本功能和工程 API 的支持下和結(jié)合數(shù)據(jù)驅(qū)動和關(guān)鍵字驅(qū)動的方法靈活管理、控制功能，使其具備強大的編程功能。 近年來，有許多自動化測試產(chǎn)品和架構(gòu)大量涌現(xiàn)。布萊克本提出了一種基于模型的使用接口驅(qū)動自動化測試方法稱為自動化測試框架（ TAF），可以結(jié)合需求建模，以支持自動化測 試用例和測試驅(qū)動程序生成。該模型著重于如何讓測試工程師可以開發(fā)更多功能明確的可重用的 套件 模型或系統(tǒng)接口模型。然而，由于聯(lián)合國的規(guī)范要求文檔和嚴(yán)格的業(yè)務(wù)控制，它很難擴大到許多的大型軟件公司，更別說那些中小型公司。同時，基于 套件 的測試方法被提出，如 CBSFG 等。遺憾的是，他們不夠關(guān)心自動化測試的框架結(jié)構(gòu)，而把大部分注意力放在如何生成測試用例。 iSoftTech2 自動化測試系統(tǒng)和 AXE3 自動化測試框架是優(yōu)秀的自動化系統(tǒng)，但沒有分布式和跨平臺的功能。 WinRunner 和 Robot4 等為主導(dǎo)的商業(yè)產(chǎn)品的設(shè)計沒有太多考慮有關(guān)的兼容性和可移植性的問題。這些傳統(tǒng)測試產(chǎn)品關(guān)心跨平臺、分布式控制和分布式執(zhí)行能力的程度還遠(yuǎn)遠(yuǎn)不夠。 2. 自動化測試系統(tǒng)的構(gòu)建 自動化測試系統(tǒng)是根據(jù) Struts 和 MVC 設(shè)計模式且基于 J2EE 開發(fā)的。服務(wù)器端建立在 Tomcat 服務(wù)器上，而客戶端在 JSP 編程的網(wǎng)頁，后端的業(yè)務(wù)邏輯模塊由 Java Bean 或 企業(yè) Java Beans 實現(xiàn)。 自動化測試系統(tǒng)由用戶界面、請求處理程序管理、作業(yè)控制、正常的請求處理程序、執(zhí)行服務(wù)端和 套件 執(zhí)行層等組成。用戶接口模塊提供了方便的操作界面給前端用 戶發(fā)送用戶的操作請求到處理程序管理模塊。 不過，請求處理程序管理模塊不處理這些請求本身，而只是轉(zhuǎn)發(fā)給一些特定的處理程序或活動線程。 實際應(yīng)用中存在兩種用戶的要求。一種屬于測試 套件 或測試工作的相關(guān)邏輯控制，另一種是除第一種外的雜項要求。所有有關(guān)邏輯控制的要求都由工作控制端處理。為了支持分布式執(zhí)行，工作控制端和執(zhí)行服務(wù)端可以運行在不同且獨立的服務(wù)器上。工作控制端可以同步控制多個執(zhí)行服務(wù)端，執(zhí)行服務(wù)端由一個有限狀態(tài)機設(shè)計而成，該狀態(tài)機可以在測試工作中運行測試 套件 隊列 。當(dāng)完成這些工作隊列 中的所有 套件 測試，執(zhí)行 服務(wù)端會通知工作控制端，改變工作狀態(tài)。該 套件 執(zhí)行層負(fù)責(zé)編制和操控某些 套件 或 用例 執(zhí)行一個特定的測試任務(wù)，這就是一個自動測試系統(tǒng)的執(zhí)行核心。 同時，它提供了一個統(tǒng)一的測試框架和各種 API，方便編程測試腳本。 . 請求控制管理 自動化測試系統(tǒng)的前端界面是 Web 頁面 ，測試人員可以制定測試腳本或從 Tcl腳本編程的基本庫制定方案，形成一個完整的程序段。所有的這些請求都將被分配到服務(wù)端，一般來說，從前端接口發(fā)送的每一個請求在執(zhí)行服務(wù)端上都有其自己的處理函數(shù)。 如果 Web 瀏覽器立即發(fā)送每一個請求到相應(yīng)的處理程序， Web瀏覽器就 必須保存所有這些請求和處理函數(shù)之間的關(guān)系，但這會降低整個系統(tǒng)的靈活性和可擴展性。為了解決這個問題，自動化測試系統(tǒng)創(chuàng)建了一個請求處理程序管理模塊保存這些請求和處理函數(shù)之間的關(guān)系。 工作控制端 在自動化測試系統(tǒng)中有 3 種測試方面 —— 作業(yè)、 套件 和 用例 。作業(yè)是一個集成 套件 隊列，可以預(yù)定并分配到指定的服務(wù)端執(zhí)行； 套件 是一個執(zhí)行實體，它被執(zhí)行服務(wù)端分配到符合的執(zhí)行層； 用例 是按照某些業(yè)務(wù)需求用 Tcl 腳本語言設(shè)計的一個可執(zhí)行的腳本。 工作控制端、工作執(zhí)行者和 套件 執(zhí)行者可以分別通過不同的接口更新或查詢自己保存在數(shù)據(jù)庫中的 文件。顯然，工作控制端負(fù)責(zé)控制工作的狀態(tài)，并為分開的執(zhí)行程序分配工作給工作執(zhí)行者。因此，工作控制端在整個工作中起著關(guān)鍵作用，保證了整個系統(tǒng)的順利運行。 一般來說，不同階段有不同的狀態(tài)，而要控制所有這些狀態(tài)，我們就要設(shè)計一個有限狀態(tài)機。 執(zhí)行服務(wù)端 工作控制端根據(jù)其狀態(tài)啟動工作來執(zhí)行，執(zhí)行服務(wù)端接收到這些執(zhí)行工作的命令后建立一個 套件 隊列，并調(diào)用 套件 執(zhí)行層依次執(zhí)行這些 套件 。當(dāng)執(zhí)行服務(wù)端接收到從 套件 執(zhí)行層 返回的結(jié) 果，它會檢查是否 套件 隊列為空，如果不是，它會把下一個 套件 放到 套件 執(zhí)行層執(zhí)行，否則，執(zhí)行服務(wù)端會 通知工作控制端所有的套件 已經(jīng)執(zhí)行完畢。 顯然， 套件 執(zhí)行層由一些可執(zhí)行的腳本或 用例 執(zhí)行命令構(gòu)成，這些腳本可以在特定的模板下用 Tcl 語言編成，這樣可以加快測試速度并保證測試項目的準(zhǔn)確率。 套件 執(zhí)行層另外的功能提供了 API 和外部接口，如 GUI API 和 套接字 API來支持第三方工具 —— WinRunner 或 QTP 等。因此，自動化測試系統(tǒng)具有強大的靈活性和可擴展性。 結(jié)論 與傳統(tǒng)的自動化測試工具相比，自動化測試系統(tǒng)是一種新型的軟件自動化測試系統(tǒng)，被廣泛應(yīng)用在通信行業(yè)并通過大量的試驗取得顯著成效（如在WinRunner 和后 端程序的測試幫助下實行 GUI 測試）。它被視為一種高效和新穎的測試系統(tǒng)，同時具備分布式功能、資源管理功能和可擴展性強等優(yōu)點。值得一提的是，我們可以通過設(shè)計不同的 API 來應(yīng)對不同的測試業(yè)務(wù)，設(shè)計回歸測試腳本到自動化測試系統(tǒng)中執(zhí)行，運用時只需要修改全局輸入變量，而無需修改任何命令行。 從某種意義上講，自動化測試系統(tǒng)實際上是一個普通的自動化測試框架。