測試管理工具必備九大功能分析

作者：網(wǎng)絡(luò)轉(zhuǎn)載發(fā)布時間：[ 2012/5/10 10:50:18 ] 推薦標簽：

前言

隨著時代的發(fā)展，軟件規(guī)模越來越大，復(fù)雜程度越來越高，對測試工作也提出了更高的要求，測試領(lǐng)域也隨之涌現(xiàn)出了各種各種的理論、方法和工具。這其中很重要的一個分支便是測試管理工具，它主要解決的是測試過程中團隊協(xié)作的問題，比如缺陷管理、用例管理、測試任務(wù)管理等。

目前市面上比較流行的測試管理工具有QC、Mantis、BugZilla、TestLink、Trac、Redmine、 BugFree等。有開源軟件，也有商業(yè)軟件。這些軟件的各自側(cè)重點不同：比如Mantis， BugZilla偏重缺陷管理，TestLink則偏著測試用例管理，QC則更加全面，Trac和Redmine項目管理的概念又更強一些。我們在總結(jié)分析這些軟件的優(yōu)缺點基礎(chǔ)上，結(jié)合自己日常實際工作的需要，設(shè)計了一套測試管理軟件，這篇文章是在設(shè)計這款軟件過程中的總結(jié)和思考，希望可以給大家一些啟發(fā)。

在設(shè)計的過程中，我們確立的目標是在一套軟件里面可以實現(xiàn)測試全過程的管理。那么，哪些功能是在這個管理過程中必不可少的呢？經(jīng)過激烈的討論和不斷的修正，我們整理總結(jié)出以下九大功能，它們分別是：測試需求管理、測試用例管理、測試套件管理、測試版本管理、測試計劃管理、測試執(zhí)行管理、缺陷管理、發(fā)布管理和分析報表。下面筆者這些功能一一闡述。

一、測試需求管理

需求是一款軟件產(chǎn)品的靈魂，是開發(fā)和測試重要的參照標準。很難想象一個沒有需求的軟件如何去設(shè)計它的測試用例。無論是測試用例，還是缺陷，都是建立在特定的需求基礎(chǔ)之上的。因此，一款好的測試管理軟件首先具備的便是測試需求管理。

1.1 需求拆分

傳統(tǒng)的項目管理流程中，需求往往以需求規(guī)模說明書的形式呈現(xiàn)。需求規(guī)格說明書比較全面，但缺點是沒有拆分為需求點，無法實現(xiàn)對某一個具體的功能點的跟蹤。因此在我們設(shè)計的測試管理工具中，需求是以需求功能點的形式呈現(xiàn)。這樣有利于針對每一個功能點撰寫測試用例，并進行測試的跟蹤管理。

大模塊拆成小需求，小需求拆成需求點，拆分之后，一層層的分級管理便是必不可少的了。為了適應(yīng)日益復(fù)雜的需求和變化響應(yīng)，需求的模塊還需要實現(xiàn)無限級的劃分，這樣可以形成一顆樹狀結(jié)構(gòu)，無論從瀏覽還是管理上都更為靈活和方便。

1.2 需求管理

有了模塊之后，緊接著需要實現(xiàn)的便是測試需求的管理。我們需要一個界面來錄入需求，常見的字段包括：標題、描述、優(yōu)先級等。另外也可以對需求進行修改，刪除等操作。

1.3 需求搜索

實現(xiàn)了基本的需求維護功能之后，我們還需要實現(xiàn)需求的搜索功能，這樣方便我們找到自己想要的需求。

二、測試用例管理

好，我們現(xiàn)在有了測試需求，我們可以為每一個需求撰寫測試用例了。測試用例的維護涉及到模塊劃分、測試用例維護、導(dǎo)入導(dǎo)出和搜索等功能。

2.1用例模塊劃分

類似于需求的模塊維護，用例也需要通過模塊的劃分來維護用例。在我們設(shè)計的軟件中，測試用例的模塊和需求的模塊式分開的。讀者肯定會問，為什么還要為用力維護一套模板呢？為什么不重用需求的模塊劃分呢？這是因為在實際項目中，需求是從用戶和產(chǎn)品的角度來看，需求更多的是幫助用戶如何達成一個操作，實現(xiàn)一個功能。但是用例設(shè)計不止要考慮需求，還需要考慮一些異常情況來設(shè)計用例，為用例單獨開設(shè)模塊管理不會影響到原有的需求管理部分。

2.2用例的維護

下面我們要實現(xiàn)的便是測試用例的基本添加，編輯等操作。這個功能在大多有測試用例管理的工具中都會實現(xiàn)，但需要特別說明的是，在絕大多數(shù)的管理工具中，測試用例的步驟是沒有分開的，每一步的預(yù)期甚至也是混在一個字段中。其實這樣并不可科學(xué)，不僅會降低用例執(zhí)行的粒度，還會影響后續(xù)的一些數(shù)據(jù)生成，至于是生成什么樣的數(shù)據(jù)，先在這里賣個關(guān)子，后面解釋：-）。在我們設(shè)計的系統(tǒng)中，用例的步驟和每步的預(yù)期是完全分開的。

2.3 用例的導(dǎo)入導(dǎo)出

目前很多公司還是在使用Excel書寫和保存測試用例，如果一家公司準備采用一套測試管理系統(tǒng)，將這些用例手工導(dǎo)入將是一項繁重的工作。因此測試管理工具需要能夠?qū)xcel里面的用例導(dǎo)入到系統(tǒng)，同樣，也能夠?qū)y試用例導(dǎo)出為Excel格式的文件。

從數(shù)據(jù)庫導(dǎo)出Excel的功能還是比較好實現(xiàn)的，Excel的導(dǎo)入功能方面，筆者設(shè)計的思路是可以通過excel的VBA編程自動實現(xiàn)數(shù)據(jù)的獲取，并且可以更新回到系統(tǒng)中，這樣會更加方便快捷。目前正在研究摸索中。

2.4 用例搜索功能

同需求的搜索功能，我們同樣也需要對測試用例進行方便的檢索，以便找到自己想要用到的測試用例。

三、測試套件管理

有了測試用例之后，緊接著一個問題會產(chǎn)生，那是如何組織維護這些用例。除了上面所說的模塊功能、導(dǎo)入導(dǎo)出和搜索之外，測試套件功能也可以非常方便的幫助測試人員來組織整理自己的測試用例。

測試套件(Test Suite)可能是一個分歧比較多一個概念，在我們看來，測試套件是一個集合，可以方便的將某一些用例按照某個特征組織在一起，方便后續(xù)的管理和維護。因此從這個角度來實現(xiàn)測試套件的功能包括測試套件的創(chuàng)建、關(guān)聯(lián)測試用例、測試套件的瀏覽維護等功能，不再細述。

四、測試版本管理

在目前的軟件開發(fā)流程中，代碼的版本控制已經(jīng)得到了普遍的應(yīng)用。而由此我們可以引申出測試版本這個概念。一個測試版本可以是對應(yīng)一個Build，也可以對應(yīng)一個時間點，測試版本的概念很重要，通過它我們可以明確我們目前測試的范疇，知曉我們需要執(zhí)行哪些測試用例。同時開發(fā)人員在修復(fù)bug的時候，也可以明確當(dāng)前的修復(fù)工作會影響到哪個版本。

4.1 版本和需求、bug的關(guān)聯(lián)

首先我們需要實現(xiàn)的便是測試版本和需求、bug的關(guān)聯(lián)。也是我們在創(chuàng)建一個測試版本的時候，需要確定這個版本都完成了哪些需求，解決了哪些bug，這樣界定了我們測試的范疇。下圖是我們設(shè)計的系統(tǒng)中實現(xiàn)的創(chuàng)建版本時，需求和bug的關(guān)聯(lián)頁面。

4.2 版本和源代碼管理系統(tǒng)的集成

一個版本肯定對應(yīng)到源代碼管理系統(tǒng)中的某一個路徑，一般是對應(yīng)到類似tags/xxx.1.0.build1類似的目錄。細心的讀者可能已經(jīng)注意到，我們上面圖中的源代碼和存儲地址是以文本框的形式呈現(xiàn)的。這也是我們正在計劃實現(xiàn)的一個功能，是源代碼的版本可以自動從源代碼管理軟件中獲取。比如我可以從Subversion的某一個路徑中獲得對應(yīng)的代碼版本，這樣可以將測試管理系統(tǒng)和代碼管理系統(tǒng)進行有機的結(jié)合。