一種支持自動(dòng)化測(cè)試的測(cè)試管理工具的實(shí)現(xiàn)

1、一種支持自動(dòng)化測(cè)試的測(cè)試管理工具的實(shí)現(xiàn)      摘  要  軟件測(cè)試管理是為了使軟件測(cè)試項(xiàng)目能夠按照預(yù)定的成本、進(jìn)度、質(zhì)量順利完成而對(duì)成本、人員、進(jìn)度、質(zhì)量、過(guò)程和風(fēng)險(xiǎn)等進(jìn)行分析和管理的活動(dòng)。測(cè)試管理關(guān)注人員、過(guò)程、產(chǎn)品三要素的互動(dòng)和變化，測(cè)試過(guò)程和階段的相互作用，測(cè)試與開發(fā)團(tuán)隊(duì)的相互關(guān)聯(lián)與協(xié)調(diào)配合，為使這些過(guò)程能有序的進(jìn)行，開發(fā)出適合自己項(xiàng)目組的測(cè)試管理工具是必需的，同時(shí)由于自動(dòng)化測(cè)試的普及，如何將自動(dòng)化測(cè)試融入進(jìn)來(lái)也是一個(gè)挑戰(zhàn)。本文描述了我們項(xiàng)目組開發(fā)的支持自動(dòng)化測(cè)試的測(cè)試管理工具的結(jié)構(gòu)和

2、功能實(shí)現(xiàn)。    關(guān)鍵字  自動(dòng)化測(cè)試；測(cè)試管理；軟件測(cè)試 1  引言    為了保證軟件產(chǎn)品的質(zhì)量，需要對(duì)軟件過(guò)程進(jìn)行控制，同時(shí)也需要對(duì)軟件產(chǎn)品本身進(jìn)行檢測(cè)，在目前形式化方法和程序正確性證明還無(wú)望成為使用性方法的情況下，軟件測(cè)試在將來(lái)的相當(dāng)長(zhǎng)一段時(shí)間仍然將是軟件質(zhì)量保證的有效方法1。    軟件測(cè)試管理就是通過(guò)一定的管理方法和工具來(lái)對(duì)整個(gè)軟件測(cè)試過(guò)程進(jìn)行監(jiān)控，從而提高軟件測(cè)試的績(jī)效。由于軟件測(cè)試管理的復(fù)雜性，沒有特別的輔助工

3、具，只是依靠人工處理是很麻煩甚至是不現(xiàn)實(shí)的。    對(duì)于測(cè)試工具的選擇一般來(lái)說(shuō)有自己開發(fā)、商業(yè)工具和開源工具三種選擇。第三方工具包括已經(jīng)成熟的商業(yè)軟件和開放源代碼的開源工具，它們都是經(jīng)過(guò)證明的可以放心使用的工具，但是最主要的不足之處在于它們往往為了通用的考慮，按照自己的理解標(biāo)準(zhǔn)化了流程，并且價(jià)格不菲。但是對(duì)剛起步的中小企業(yè)來(lái)說(shuō)，購(gòu)買和使用這樣的通用工具而只使用到其中一小部分功能，甚至有些有自己項(xiàng)目組特色的東西還得不到支持，往往不是最合理的選擇。    隨著近些年測(cè)試自動(dòng)化的呼聲越來(lái)越高，如何將自動(dòng)化測(cè)試的效率提高到

4、應(yīng)有的水平，成了各個(gè)測(cè)試機(jī)構(gòu)首要考慮的問(wèn)題2。我們認(rèn)為，先進(jìn)的測(cè)試管理流程與一流的自動(dòng)化測(cè)試工具包是實(shí)施自動(dòng)化測(cè)試不可或缺的。為更好的對(duì)測(cè)試流程進(jìn)行控制，使之能充分利用自動(dòng)化測(cè)試帶來(lái)的好處，現(xiàn)代測(cè)試管理系統(tǒng)應(yīng)該能支持自動(dòng)化測(cè)試。    結(jié)合公司的實(shí)際情況，我們選擇了自己開發(fā)和開放源代碼相結(jié)合的方式，并采用缺陷跟蹤驅(qū)動(dòng)測(cè)試的模型開發(fā)出了自動(dòng)化測(cè)試管理系統(tǒng)ATMS(Automatic Testing and Management System)來(lái)作為支持自動(dòng)化測(cè)試的基礎(chǔ)設(shè)施。   

5、0;本文分析了ATMS的體系結(jié)構(gòu)和各部分組成，并對(duì)其中一些關(guān)鍵技術(shù)進(jìn)行了討論。2  體系結(jié)構(gòu)    現(xiàn)在基于源代碼的軟件測(cè)試工具已經(jīng)開始被業(yè)界廣泛使用，以求提高軟件的可重用性，可維護(hù)性等質(zhì)量屬性，由于本項(xiàng)目組的軟件自動(dòng)化測(cè)試才剛起步，ATMS應(yīng)該能和以后可預(yù)期的測(cè)試過(guò)程的進(jìn)一步完善和需求的變更同步，這樣，ATMS在設(shè)計(jì)之初就應(yīng)該有良好的可擴(kuò)展性和可重復(fù)性。    ATMS在邏輯上采用了以中心數(shù)據(jù)庫(kù)為核心的體系結(jié)構(gòu)，ATMS目前分為測(cè)試文檔管理系統(tǒng)、缺陷跟蹤管理和自動(dòng)化測(cè)試支持系統(tǒng)三大部分(體系結(jié)

6、構(gòu)圖如圖1所示)，為了降低它們之間的耦合性，它們都通過(guò)共同的中心數(shù)據(jù)庫(kù)進(jìn)行交互，以后要進(jìn)行擴(kuò)展的話只需要圍繞中心數(shù)據(jù)庫(kù)進(jìn)行操作即可。圖13  測(cè)試文檔管理系統(tǒng)    軟件測(cè)試文檔是指導(dǎo)和管理軟件測(cè)試過(guò)程的重要依據(jù)，測(cè)試文檔包括測(cè)試計(jì)劃、測(cè)試進(jìn)度、測(cè)試用例、缺陷管理文檔、進(jìn)度報(bào)告等。這里介紹ATMS中我們主要分為測(cè)試用例管理和測(cè)試文檔管理(包括測(cè)試計(jì)劃，測(cè)試進(jìn)度等測(cè)試文件的模板)。3.1  測(cè)試用例組成    ATMS中用例分為三個(gè)部分，用例邏輯、用例數(shù)據(jù)和用例代碼。其中用例邏

7、輯和用例數(shù)據(jù)是文本格式，由用例管理系統(tǒng)負(fù)責(zé)創(chuàng)建；用例代碼由自動(dòng)化支持系統(tǒng)在CPPUNIT中創(chuàng)建，它是自動(dòng)化運(yùn)行的基礎(chǔ)。它們的關(guān)系如圖2所示。圖23.2  測(cè)試用例存儲(chǔ)和執(zhí)行結(jié)果    為更有效組織這些測(cè)試用例，采用測(cè)試用例數(shù)據(jù)庫(kù)進(jìn)行集中管理。這樣就可以按照測(cè)試階段和被測(cè)模塊清晰地組織測(cè)試用例，并可以按照用戶的不同查詢條件顯示不同的數(shù)據(jù)信息(如測(cè)試用例執(zhí)行狀態(tài)，執(zhí)行結(jié)果，時(shí)間等)。3.3  測(cè)試用例的維護(hù)    為保證測(cè)試用例庫(kù)中測(cè)試用例的有效性，必須對(duì)測(cè)試用例庫(kù)進(jìn)行維護(hù)。包括

8、如下四個(gè)方面：     刪除過(guò)時(shí)的測(cè)試用例    因?yàn)樾枨蟮母淖兊仍蚩赡苁挂粋€(gè)測(cè)試用例不再合適被測(cè)系統(tǒng)，這時(shí)就應(yīng)該將其刪除。     刪除冗余的測(cè)試用例    如果存在兩個(gè)或更多測(cè)試用例針對(duì)一組相同的輸入和輸出進(jìn)行測(cè)試，那么就是冗余的，它們的存在會(huì)降低回歸測(cè)試的效率，需要定期進(jìn)行整理。     添加新的測(cè)試用例    如果發(fā)現(xiàn)

9、某個(gè)關(guān)鍵接口還沒有被測(cè)試，就應(yīng)該開發(fā)新的測(cè)試用例重新對(duì)其進(jìn)行測(cè)試，并將新的測(cè)試用例合并到測(cè)試用例庫(kù)中。3.4  測(cè)試文檔模板管理    為有效進(jìn)行軟件測(cè)試管理，在項(xiàng)目準(zhǔn)備階段創(chuàng)建測(cè)試過(guò)程中用到的各種管理模板，項(xiàng)目測(cè)試執(zhí)行過(guò)程中填充和更新模板內(nèi)容，這樣可以保證不會(huì)遺漏重要測(cè)試內(nèi)容并保持文檔格式一致性。    目前ATMS中存在如下模板：     測(cè)試用例模板(測(cè)試用例邏輯部分)     每日進(jìn)度模板

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

11、態(tài)模型。4.1  缺陷報(bào)告    標(biāo)識(shí)一個(gè)缺陷的時(shí)候，能正確給它分配嚴(yán)重程度、可視性和優(yōu)先級(jí)別是很重要的。其中嚴(yán)重程度標(biāo)識(shí)了一個(gè)bug對(duì)系統(tǒng)執(zhí)行的破壞度，可視性是哪個(gè)能觀察到這個(gè)bug，優(yōu)先級(jí)別標(biāo)識(shí)bug何時(shí)修復(fù)。    表1、表2和表3分別標(biāo)識(shí)了嚴(yán)重程度、可視性和優(yōu)先級(jí)的可能值。表1嚴(yán)重程度描述0待分配1致命-系統(tǒng)崩潰或者不可修復(fù)錯(cuò)誤2嚴(yán)重-功能沒有實(shí)現(xiàn)3一般-功能實(shí)現(xiàn)錯(cuò)誤4輕微-文檔/拼寫錯(cuò)誤5待觀察-不能重現(xiàn)的錯(cuò)誤6正常-系統(tǒng)正確功能，非bug表2優(yōu)先級(jí)描述0待分配1必須馬上修改2盡快修改

12、3有空時(shí)修復(fù)4可修復(fù)可不修復(fù)表3可視性描述0待分配1超過(guò)75%客戶可能面對(duì)這個(gè)bug225-74%客戶可能面對(duì)這個(gè)bug310-24%客戶可能面對(duì)這個(gè)bug4低于10%客戶可能面對(duì)這個(gè)bug4.2  缺陷處理    每當(dāng)一個(gè)bug被處理完成的時(shí)候，ATMS將給它分配一個(gè)處理碼，表4是系統(tǒng)所有結(jié)束碼列表。表 4結(jié)束碼(解決途徑)解決與否詳細(xì)描述設(shè)計(jì)一部分解決非bug，是系統(tǒng)設(shè)計(jì)組成部分不能修復(fù)解決由于時(shí)間，花費(fèi)等別的*暫時(shí)不解決被報(bào)告人取消解決報(bào)告人認(rèn)識(shí)不是bug，取消報(bào)告延期否暫不修復(fù)，以后再修復(fù)重復(fù)的解決和現(xiàn)存bug重復(fù)已

13、解決解決Bug被修復(fù)不可復(fù)現(xiàn)否開發(fā)人員不能復(fù)現(xiàn)這個(gè)bug，需要重新定義bug路徑需要更多信息否Bug報(bào)告中信息不足   4.3DTD的功能與組成    DTD的功能與組成如圖3所示。圖3  缺陷跟蹤系統(tǒng)模塊組成圖    各模塊詳細(xì)說(shuō)明如下：    報(bào)告模塊。用于軟件測(cè)試人員向數(shù)據(jù)庫(kù)報(bào)告新的缺陷。    權(quán)限控制模塊。為測(cè)試人員、開發(fā)人員和項(xiàng)目管理人員分配不同的權(quán)限，如瀏覽、報(bào)告、修改、查

14、詢、統(tǒng)計(jì)、分析、刪除、備份等。        分析模塊。統(tǒng)計(jì)和分析滿足條件的缺陷，輸入分析結(jié)果；分析結(jié)果可以存成文件，可以包括數(shù)據(jù)、文字、表格和統(tǒng)計(jì)圖形等內(nèi)容。    備份模塊。備份當(dāng)前缺陷跟蹤數(shù)據(jù)庫(kù)的缺陷；全部備份或者備份滿足條件的缺陷。    查詢模塊。根據(jù)查詢條件，查找滿足條件的缺陷；包括簡(jiǎn)單條件查詢和復(fù)雜條件查詢。    修改模塊。用于開發(fā)人員和測(cè)試人員更新缺陷狀態(tài)信息；開發(fā)人員驗(yàn)證報(bào)告的

15、缺陷，修改缺陷，更新修改缺陷的信息；測(cè)試人員補(bǔ)充缺陷內(nèi)容，驗(yàn)證和關(guān)閉修正的缺陷。5  缺陷跟蹤數(shù)據(jù)庫(kù)的缺陷管理    缺陷跟蹤數(shù)據(jù)庫(kù)(DTD)是一種可以提高缺陷處理效率的工具，要充分發(fā)揮它的作用，需要對(duì)缺陷跟蹤數(shù)據(jù)庫(kù)進(jìn)行有效的管理3 。5.1  角色和權(quán)限劃分    使用DTD的用戶有多種類型，而且他們使用的目的關(guān)注的內(nèi)容也各不相同，為更有效地對(duì)DTD中每個(gè)缺陷進(jìn)行正確處理，保證缺陷處理的客觀性和安全性，我們對(duì)不同的使用者分配不同的缺陷處理權(quán)限。 

16、0;  默認(rèn)情況下，數(shù)據(jù)庫(kù)有四個(gè)組，測(cè)試組、質(zhì)量保證組、修正缺陷組、項(xiàng)目管理組?？梢愿鶕?jù)需要隨時(shí)添加和減少這些組的成員。    各組對(duì)應(yīng)權(quán)限如表所示。專有權(quán)限是本組成員才有的權(quán)限，公共權(quán)限是每個(gè)使用缺陷數(shù)據(jù)庫(kù)的人員都有的權(quán)限。表5.2  缺陷數(shù)據(jù)分析和顯示    本系統(tǒng)具有較為強(qiáng)大的數(shù)據(jù)統(tǒng)計(jì)分析能力，以基于缺陷跟蹤數(shù)據(jù)庫(kù)的bug信息作為分析的數(shù)據(jù)來(lái)源，以表格和圖形的形式表現(xiàn)缺陷的分布情況，并且可以選擇統(tǒng)計(jì)和分析的頻率(每周或者每天)。目前實(shí)現(xiàn)的有如下三種。 

17、0;  (1)測(cè)試團(tuán)隊(duì)每天報(bào)告的新缺陷統(tǒng)計(jì)和分析。    (2)不同測(cè)試人員的缺陷數(shù)量統(tǒng)計(jì)。    (3)缺陷嚴(yán)重級(jí)別和缺陷類別統(tǒng)計(jì)與分析。    由于我們采用的是中心數(shù)據(jù)庫(kù)的體系結(jié)構(gòu)，當(dāng)需要以別的方式體現(xiàn)缺陷的分布情況時(shí)只需要更改圖的表示層就可以，而邏輯和數(shù)據(jù)庫(kù)層無(wú)需更改。6  自動(dòng)化測(cè)試支持系統(tǒng)    自動(dòng)化測(cè)試是管理和實(shí)施各種測(cè)試活動(dòng)的一種方法，即測(cè)試用例的設(shè)計(jì)，測(cè)試腳本的開發(fā)和執(zhí)行，并借助

18、自動(dòng)化工具來(lái)驗(yàn)證測(cè)試需求4。而缺陷回歸是我們軟件開發(fā)和缺陷管理中的主要問(wèn)題，也是測(cè)試中不可避免的話題。對(duì)現(xiàn)有功能更新的同時(shí)，也影響原有的行為，這是造成bug的主要原因，避免這一問(wèn)題的主要解決方法是構(gòu)建自動(dòng)化的測(cè)試，實(shí)現(xiàn)回歸測(cè)試。    回歸測(cè)試我們可以采用商業(yè)工具、開源工具和自己開發(fā)，考慮到開發(fā)周期和與本系統(tǒng)的兼容，我們?cè)诙喾N選擇方案中選擇了在ATMS中內(nèi)嵌開源自動(dòng)化測(cè)試工具CPPUNIT5的方法來(lái)支持自動(dòng)化測(cè)試，由于CPPUNIT是個(gè)開放源代碼的工具，這使得我們可以通過(guò)修改其源代碼使之符合我們的需要，在本系統(tǒng)中，當(dāng)每次CPPUNIT自動(dòng)化測(cè)試完成之后，我們加入引導(dǎo)，把相應(yīng)的運(yùn)行結(jié)果寫入ATMS指定的中心數(shù)據(jù)庫(kù)中，同時(shí)指示ATMS有新的數(shù)據(jù)更新。這樣由于ATMS和CPPUNIT共用相同的中心數(shù)據(jù)庫(kù)，能夠達(dá)成數(shù)據(jù)上的一致性，并完成所需交互。其數(shù)據(jù)流如圖4所示。 圖    從圖可以看出，當(dāng)做自動(dòng)化測(cè)試的人員拿到需要自動(dòng)化的用例的文本描述后，將其按照CPPUNIT的規(guī)范寫成可以在CPPUNIT框架下運(yùn)行的用例代碼。然后和需要的用例數(shù)據(jù)一起通過(guò)CPPUNIT自動(dòng)運(yùn)行，結(jié)果自己寫到系統(tǒng)的中心數(shù)據(jù)庫(kù)，這樣