一種新型自動(dòng)化測試管理平臺(tái)的實(shí)現(xiàn)

摘 要:由于自動(dòng)化測試有著回歸測試更方便，可運(yùn)行更多更繁瑣的測試，執(zhí)行一些手工測試?yán)щy或不可能進(jìn)行的測試，更好地利用資源的一致性、可重復(fù)性，增加軟件信任度的特點(diǎn)，故越來越多的公司和科研院所開始進(jìn)行自動(dòng)化測試管理平臺(tái)的研究工作。但是，通常開發(fā)出來的自動(dòng)化測試管理平臺(tái)功能單一，缺乏靈活性、可升級(jí)性和集成性，而現(xiàn)代測試管理系統(tǒng)已經(jīng)迫切需要集成自動(dòng)化測試管理平臺(tái)，這樣，落后的測試平臺(tái)設(shè)計(jì)就無法滿足先進(jìn)測試管理系統(tǒng)的需求。這里設(shè)計(jì)一種新型的自動(dòng)化測試管理平臺(tái)，能夠很好地集成到先進(jìn)測試管理系統(tǒng)中，并且容易維護(hù)和升級(jí)。

關(guān)鍵詞:自動(dòng)化測試; 自動(dòng)化測試管理平臺(tái); 人機(jī)接口; 軟件測試; 后臺(tái)數(shù)據(jù)庫

中圖分類號(hào):TP29 文獻(xiàn)標(biāo)識(shí)碼:A

文章編號(hào):1004-373X(2010)09-0151-03

Realization of New Type of Automatic Testing and Management Platform

HUANG Xiao

(Electronic Information Engineering College， South-Central University for Nationalities， Wuhan 430074， China)

Abstract: Because automatic testing can make easy regression testing， run more and complex testing， execute testing that could not be run or hardly run manually， make full use of resources， implement consistence and repeatability， and add the reliance of software， more and more companies and research institutes start to do some research of automatic testing management platform(ATMP)， but the generally developed ATMPs are functionality-single， lack of flexibility， not able to be updated and integrated. While modern testing management system has eagerly wanted to integrate ATMP， but the available ATMP can not satisfy the requirement of advanced testing management system， the new type of ATMP， which can be successfully integrated into the advanced test management system， and easily maintained and updated， is designed.

Keywords: automatic testing; automatic testing and management platform; man-machine interface; software testing; back database

自動(dòng)化測試可理解為測試過程自動(dòng)化和測試結(jié)果分析自動(dòng)化。測試過程的自動(dòng)化指的是不用手工逐個(gè)的對(duì)用例進(jìn)行測試[1]。測試結(jié)果分析自動(dòng)化指的是不用人工一點(diǎn)點(diǎn)去分析測試過程中的中間結(jié)果或數(shù)據(jù)流。軟件自動(dòng)化測試就是模擬手動(dòng)測試步驟，執(zhí)行用某種程序設(shè)計(jì)語言編制的測試程序，控制被測軟件的執(zhí)行，完成全自動(dòng)或半自動(dòng)測試的過程。先進(jìn)的測試管理流程與一流的自動(dòng)化測試管理平臺(tái)是實(shí)施自動(dòng)化測試不可或缺的[2]。為更好地對(duì)測試流程進(jìn)行控制，使之能充分利用自動(dòng)化測試帶來的好處，現(xiàn)代測試管理系統(tǒng)應(yīng)該能支持自動(dòng)化測試。本文分析了一種新型的自動(dòng)化測試管理平臺(tái)(Automatic Testing and Management Platform，ATMP)的體系結(jié)構(gòu)和各部分組成，并對(duì)其中一些關(guān)鍵技術(shù)進(jìn)行了討論。

1 體系結(jié)構(gòu)

如今的產(chǎn)品設(shè)計(jì)變得日益的復(fù)雜，測試系統(tǒng)為了達(dá)到更好的靈活性和可升級(jí)性，正逐漸朝著模塊化、小體積的方向發(fā)展，就是將復(fù)雜的測試系統(tǒng)簡化成模塊化的硬件和軟件去逐一實(shí)現(xiàn)，需要增加測試項(xiàng)目時(shí)只需增加相應(yīng)的功能模塊即可滿足未來的升級(jí)需求[3]。在發(fā)展的大趨勢下，廣大測試工程師對(duì)自動(dòng)化測試系統(tǒng)提出了一系列更具體的需求:更高的系統(tǒng)靈活性;高性能的架構(gòu);更低的系統(tǒng)投資;更長的系統(tǒng)壽命。ATMP在設(shè)計(jì)之初就考慮到了良好的可擴(kuò)展性和可重復(fù)性[4]。

ATMP在邏輯上采用以中心數(shù)據(jù)庫為核心的體系結(jié)構(gòu)，ATMP目前分為測試文檔管理系統(tǒng)、輸出結(jié)果管理、ATMP后臺(tái)數(shù)據(jù)庫、用例管理、BUG跟蹤數(shù)據(jù)庫和人機(jī)接口六大部分，體系結(jié)構(gòu)圖如圖1所示。為了降低它們之間的耦合性，它們都通過共同的ATMP后臺(tái)數(shù)據(jù)庫進(jìn)行交互，以后要進(jìn)行擴(kuò)展的話只需要圍繞中心數(shù)據(jù)庫進(jìn)行操作即可[5]。

2 ATMP后臺(tái)數(shù)據(jù)庫

ATMP后臺(tái)數(shù)據(jù)庫分為測試輸入數(shù)據(jù)庫、測試輸出數(shù)據(jù)庫和測試用例數(shù)據(jù)庫。這些數(shù)據(jù)庫分別和人機(jī)接口、測試文檔管理系統(tǒng)、輸出結(jié)果管理系統(tǒng)、用例管理和BUG跟蹤數(shù)據(jù)庫相聯(lián)系[6]。測試人員通過人機(jī)接口，將輸入數(shù)據(jù)以文本的形式輸入到測試輸入數(shù)據(jù)數(shù)據(jù)庫中，然后調(diào)用相應(yīng)的測試用例數(shù)據(jù)庫中的測試用例進(jìn)行測試，輸出的結(jié)果送到測試輸出數(shù)據(jù)庫。然后測試輸出數(shù)據(jù)庫將輸出結(jié)果整理分類送至輸出結(jié)果管理系統(tǒng)。測試人員可以通過人機(jī)接口直接查看測試結(jié)果。

圖1 ATMP設(shè)計(jì)圖

2.1 測試用例數(shù)據(jù)庫

ATMP中用例分為兩個(gè)部分，用例邏輯和用例代碼。其中用例邏輯是文本格式，由用例管理系統(tǒng)負(fù)責(zé)創(chuàng)建;用例代碼由自動(dòng)化支持系統(tǒng)根據(jù)用例邏輯來創(chuàng)建，它是自動(dòng)化運(yùn)行的基礎(chǔ)。它們的關(guān)系如圖2所示。

圖2 用例邏輯和用例代碼之間的關(guān)系

2.2 測試用例存儲(chǔ)和執(zhí)行結(jié)果

為更有效組織這些測試用例，采用測試用例數(shù)據(jù)庫進(jìn)行集中管理。這樣就可以按照測試階段和被測模塊清晰地組織測試用例，并可以通過人機(jī)接口按照用戶的不同查詢條件顯示不同的數(shù)據(jù)信息(如測試用例執(zhí)行狀態(tài)，執(zhí)行結(jié)果，時(shí)間等)。人機(jī)接口有兩種方式，一種是通過Web頁面來查詢，界面友好，操作方便，適合入門級(jí)測試工程師。而CLI則適合于較高層次的測試工程師，除了可以查詢外，還可以通過一些特殊的工具對(duì)ATMP進(jìn)行升級(jí)和維護(hù)。這兩種方式都可以通過互聯(lián)網(wǎng)遠(yuǎn)程操作。

2.3 測試用例的維護(hù)

為保證測試用例庫中測試用例的有效性，必須對(duì)測試用例庫進(jìn)行維護(hù)。包括如下四個(gè)方面[7]:

(1) 刪除過時(shí)的測試用例。因?yàn)樾枨蟮母淖兊仍蚩赡苁挂粋€(gè)測試用例不再合適被測系統(tǒng)，這時(shí)就應(yīng)該將其刪除。

(2) 刪除冗余的測試用例。如果存在兩個(gè)或更多測試用例針對(duì)一組相同的輸入和輸出進(jìn)行測試，那么就是冗余的，它們的存在會(huì)降低回歸測試的效率，需要定期進(jìn)行整理。

(3) 修改舊的測試用例。自動(dòng)化平臺(tái)升級(jí)，例如測試用例所調(diào)用的函數(shù)名稱發(fā)生變化，這樣會(huì)導(dǎo)致極小部分用例無法正常使用，這時(shí)需要對(duì)用例所調(diào)用的函數(shù)名稱進(jìn)行修改。

(4) 添加新的測試用例。如果發(fā)現(xiàn)某個(gè)關(guān)鍵接口還沒有被測試，就應(yīng)該開發(fā)新的測試用例重新對(duì)其進(jìn)行測試，并將新的測試用例合并到測試用例庫中。

3 測試文檔模板管理

為有效進(jìn)行軟件測試管理，在項(xiàng)目準(zhǔn)備階段創(chuàng)建測試過程中用到的各種管理模板，項(xiàng)目測試執(zhí)行過程中填充和更新模板內(nèi)容，這樣可以保證不會(huì)遺漏重要測試內(nèi)容并保持文檔格式一致性。目前ATMP中存在如下模板:

測試用例模板(測試用例邏輯部分) 描述該用例是用來測試軟件的何種功能的。

測試任務(wù)完成情況模板 用來統(tǒng)計(jì)截止目前為止，所完成的測試用例占整個(gè)測試計(jì)劃用例的百分比，可以提醒測試人員測試進(jìn)度是否滯后。

每日、每周、每月進(jìn)度模板 當(dāng)日、當(dāng)周、當(dāng)月所完成的測試用例占整個(gè)測試計(jì)劃用例的百分比。

通過和失敗統(tǒng)計(jì)模板 用來統(tǒng)計(jì)失敗和通過的測試用例，和預(yù)定的認(rèn)為成功的百分比相比較，可以判定整個(gè)測試計(jì)劃是否通過。

4 BUG跟蹤數(shù)據(jù)庫

BUG跟蹤數(shù)據(jù)庫BTD(BUG Tracking Database)是對(duì)軟件BUG進(jìn)行系統(tǒng)管理和跟蹤控制的數(shù)據(jù)庫，它記錄軟件測試、BUG修正和驗(yàn)證過程的全部BUG的處理信息，ATMP中的測試是以它為驅(qū)動(dòng)進(jìn)行的。ATMP中，對(duì)BUG進(jìn)行跟蹤管理，確保每個(gè)被發(fā)現(xiàn)的BUG都能夠及時(shí)得到處理是測試工作的一項(xiàng)重要內(nèi)容。每個(gè)BUG都有它的生命周期，從被報(bào)告開始到被解決結(jié)束。在這個(gè)生命周期中它在不同狀態(tài)中轉(zhuǎn)換。在ATMP中，這里為BUG設(shè)計(jì)了如下BUG跟蹤管理狀態(tài)模型。

4.1 BUG報(bào)告和處理

標(biāo)識(shí)一個(gè)BUG時(shí)，應(yīng)該正確給它分配嚴(yán)重程度、可視性、相關(guān)性和優(yōu)先級(jí)別。其中嚴(yán)重程度標(biāo)識(shí)了一個(gè)BUG對(duì)系統(tǒng)執(zhí)行的破壞度，可視性是指在何種環(huán)境下能觀察到這個(gè)BUG，相關(guān)性指的是這個(gè)BUG和其他的BUG的關(guān)聯(lián)關(guān)系，優(yōu)先級(jí)別標(biāo)識(shí)BUG何時(shí)修復(fù)。每當(dāng)一個(gè)BUG被處理完成的時(shí)候，ATMP將給它分配一個(gè)處理碼。

4.2 BTD的功能與組成

BTD的功能與組成如圖3所示[8]。

圖3 BUG跟蹤系統(tǒng)模塊組成圖

各模塊詳細(xì)說明如下[9]:

查詢模塊 根據(jù)查詢條件，查找滿足條件的BUG。

及時(shí)通知模塊 BTD發(fā)生任何變化，該模塊都會(huì)以郵件的形式通知相關(guān)人員。

備份模塊 全部備份或者備份滿足條件的BUG跟蹤數(shù)據(jù)庫中的BUG。

修改模塊 用于開發(fā)人員和測試人員更新BUG狀態(tài)信息;開發(fā)人員驗(yàn)證、修改、更新BUG的信息;測試人員補(bǔ)充BUG內(nèi)容，驗(yàn)證和關(guān)閉修正的BUG。

權(quán)限控制模塊 為測試人員、開發(fā)人員和項(xiàng)目管理人員分配不同的權(quán)限，如瀏覽、報(bào)告、修改、查詢、統(tǒng)計(jì)、分析、刪除、備份等。

分析報(bào)告模塊 統(tǒng)計(jì)和分析滿足條件的BUG，輸出分析結(jié)果，并以數(shù)據(jù)、文字、表格和統(tǒng)計(jì)圖形等形式形成報(bào)告。

BTC。BUG處理中心，負(fù)責(zé)處理各個(gè)模塊發(fā)出的指令和模塊間信息的交換。

5 BUG跟蹤數(shù)據(jù)庫的缺陷管理

BUG跟蹤數(shù)據(jù)庫(BTD)是一種可以提高BUG處理效率的工具，要充分發(fā)揮其作用，需要對(duì)BUG跟蹤數(shù)據(jù)庫進(jìn)行有效的管理。

5.1 用戶角色的劃分

使用BTD的用戶有多種類型，這些用戶在整個(gè)測試系統(tǒng)中扮演了不同的角色。為了更有效地對(duì)BTD中每個(gè)BUG進(jìn)行正確處理，保證BUG處理的客觀性和安全性，我們對(duì)不同的使用者分配不同的BUG處理權(quán)限。默認(rèn)情況下，數(shù)據(jù)庫有三個(gè)組，測試組、研發(fā)組、項(xiàng)目管理組?？梢愿鶕?jù)需要隨時(shí)添加和減少這些組的成員。各組對(duì)應(yīng)權(quán)限如表1所示。

5.2 BUG數(shù)據(jù)分析和顯示

強(qiáng)大的數(shù)據(jù)統(tǒng)計(jì)分析能力是該系統(tǒng)的一大特色，以基于BUG跟蹤數(shù)據(jù)庫的BUG信息作為分析的數(shù)據(jù)來源，以表格和圖形的形式表現(xiàn)BUG的分布情況。目前支持以下三種統(tǒng)計(jì)和分析方式:

(1) 測試組每天、每周、每月報(bào)告的新BUG統(tǒng)計(jì)和分析。

(2) 不同測試人員的BUG數(shù)量統(tǒng)計(jì)。

(3) BUG嚴(yán)重級(jí)別和BUG類別統(tǒng)計(jì)與分析。

由于采用了中心數(shù)據(jù)庫，各模塊分層架構(gòu)的體系結(jié)構(gòu)，很方便以后增加新的分析和顯示方式，底層的數(shù)據(jù)庫和邏輯無需修改。

表1 成員權(quán)限對(duì)應(yīng)表

組名成員專有權(quán)限公共權(quán)限

測試組測試工程師測試主管重新打開未修正的BUG

檢查和確認(rèn)BUG

提交新BUG

關(guān)閉已修正的BUG

研發(fā)組研發(fā)工程師研發(fā)主管修正BUG

添加修正BUG的信息

項(xiàng)目管理組項(xiàng)目經(jīng)理創(chuàng)建數(shù)據(jù)庫

保存關(guān)閉數(shù)據(jù)庫

瀏覽BUG

分類查詢BUG

統(tǒng)計(jì)分類BUG

6 結(jié) 語

自動(dòng)化測試體系需要一個(gè)完整的解決方案才能實(shí)現(xiàn)。自動(dòng)化測試的引入、強(qiáng)大的資源整合能力和有效的自動(dòng)化測試體系的設(shè)計(jì)將是實(shí)現(xiàn)自動(dòng)化測試的十分重要的因素，這也是本測試平臺(tái)設(shè)計(jì)的理念[10]。雖然軟件的自動(dòng)化測試無法取代手動(dòng)測試，但是由于自動(dòng)化測試能顯著提高軟件測試的有效性和效率，將在越來越多的軟件測試管理系統(tǒng)中得到應(yīng)用。

參考文獻(xiàn)

[1]PRESS Rgoer S.軟件工程——實(shí)踐者的研究方法[M].北京:機(jī)械工業(yè)出版社，2000.

[2]崔啟亮.國際化軟件測試[M].中國:電子工業(yè)出版社，2006.

[3]BACH James. Test automation snake oil[J]. Windows Technical Journal， 1996，15(9): 40-44.

[4]FEWSTER Mark， GRAHAM Dorothy. 軟件測試自動(dòng)化技術(shù)[M].北京:電子工業(yè)出版社，2000.

[5]EDWARD Kit， Integrated， effective test design and automation[J]. Software Development， 1999，21(2): 36-38.

[6]ELFRIEDE Dustin. Lessons in test automation[J]. Software Testing and Quality Engineering， 1999，19(9): 16-22.

[7]DOUGLAS Hoffman. Heuristic test oracles: the balance between exhaustive comparison and no comparison at all[J]. Software Testing and Quality Engineering Magazine， 1999，19(13): 29-32.

[8]BRET Pettichord. Success with test automation[J]. Quality Week， 1996，13(6): 31-39.

[9]GUCKENHEIMER Sam. The revolution in software testing. rational software[M]. [S.l.]:[s.n.]， 2002.

[10]NEWKIRK James， MARTIN Robot C. Extreme programming in practice[M].中文版.北京:人民郵電出版社，2002.