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

標籤：io   ar   使用   sp   on   檔案   資料   art   問題   

隨著時代的發展，軟體規模越來越大，複雜程度越來越高，對測試工作也提出了更高的要求，測試領域也隨之湧現出了各種各種的理論、方法和工具。這其中很重要的一個分支便是測試管理工具，它主要解決的是測試過程中團隊協作的問題，比如缺陷管理、用例管理、測試工作管理等。

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

在設計的過程中，我們確立的目標是在一套軟體裡面可以實現測試全過程的管理。那麼，哪些功能是在這個管理過程中必不可少的呢？經過激烈的討論和不斷的修正，我們整理總結出以下九大功能，它們分別是：測試需求管理、測試案例管理、測試套件管理、測試版本管理、測試計劃管理、測試執行管理、缺陷管理、發行管理和分析報表。下面筆者就這些功能一一闡述。

一、測試需求管理

需求是一款軟體產品的靈魂，是開發與測試最重要的參照標準。很難想象一個沒有需求的軟體如何去設計它的測試案例。無論是測試案例，還是缺陷，都是建立在特定的需求基礎之上的。因此，一款好的測試管理軟體首先具備的便是測試需求管理。

1.1 需求拆分

傳統的專案管理流程中，需求往往以需求規模說明書的形式呈現。需求規格說明書比較全面，但缺點是沒有拆分為需求點，無法實現對某一個具體的功能點的跟蹤。因此在我們設計的測試管理工具中，需求是以需求功能點的形式呈現。這樣有利於針對每一個功能點撰寫測試案例，並進行測試的跟蹤管理。

大模組拆成小需求，小需求拆成需求點，拆分之後，一層層的分級管理便是必不可少的了。為了適應日益複雜的需求和變化響應，需求的模組還需要實現無限級的劃分，這樣可以形成一顆樹狀結構，無論從瀏覽還是管理上都更為靈活和方便。

1.2 需求管理

有了模組之後，緊接著需要實現的便是測試需求的管理。我們需要一個介面來錄入需求，常見的欄位包括：標題、描述、優先順序等。另外也可以對需求進行修改，刪除等操作。

 

1.3 需求搜尋

實現了基本的需求維護功能之後，我們還需要實現需求的搜尋功能，這樣方便我們找到自己想要的需求。

 

二、測試案例管理

好，我們現在有了測試需求，我們就可以為每一個需求撰寫測試案例了。測試案例的維護涉及到模組劃分、測試案例維護、匯入匯出和搜尋等功能。

2.1用例模組劃分

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

2.2用例的維護

下面我們要實現的便是測試案例的基本添加，編輯等操作。這個功能在大多有測試案例管理的工具中都會實現，但需要特別說明的是，在絕大多數的管理工具中，測試案例的步驟是沒有分開的，每一步的預期甚至也是混在一個欄位中。其實這樣並不可科學，不僅會降低用例執行的粒度，還會影響後續的一些資料產生，至於是產生什麼樣的資料,先在這裡 賣個關子，後面解釋：-）。在我們設計的系統中，用例的步驟和每步的預期是完全分開的。

2.3 用例的匯入匯出

目前很多公司還是在使用Excel書寫和儲存測試案例，如果一家公司準備採用一套測試管理系統，將這些用例手工匯入將是一項繁重的工作。 因此測試管理工具需要能夠將Excel裡面的用例匯入到系統，同樣，也能夠將測試案例匯出為Excel格式的檔案。

從資料庫匯出Excel的功能還是比較好實現的，Excel的匯入功能方面，筆者設計的思路是可以通過excel的VBA編程自動實現資料的擷取，並且可以更新回到系統中，這樣會更加方便快捷。目前正在研究摸索中。

2.4 用例搜尋功能

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

三、測試套件管理

有了測試案例之後，緊接著一個問題就會產生，那就是如何組織維護這些用例。除了上面所說的模組功能、匯入匯出和搜尋之外，測試套件功能也可以非常方便的協助測試人員來組織整理自己的測試案例。

測試套件(Test Suite)可能是一個分歧比較多一個概念，在我們看來，測試套件就是一個集合，可以方便的將某一些用例按照某個特徵組織在一起，方便後續的管理和維護。因此從這個角度來實現測試套件的功能就包括測試套件的建立、關聯測試案例、測試套件的瀏覽維護等功能，不再細述。

四、測試版本管理

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

4.1 版本和需求、bug的關聯

首先我們需要實現的便是測試版本和需求、bug的關聯。也就是我們在建立一個測試版本的時候，需要確定這個版本都完成了哪些需求，解決了哪些bug，這樣就界定了我們測試的範疇。是我們設計的系統中實現的建立版本時，需求和bug的關聯頁面。

 

4.2 版本和原始程式碼控制系統的整合

一個版本肯定對應到原始程式碼控制系統中的某一個路徑，一般是對應到類似tags/xxx.1.0.build1類似的 目錄。細心的讀者可能已經注意到，我們上面圖中的原始碼和儲存地址是以文字框的形式呈現的。這也是我們正在計劃實現的一個功能，就是原始碼的版本可以自動 從原始程式碼控制軟體中擷取。 比如我可以從Subversion的某一個路徑中獲得對應的代碼版本，這樣就可以將測試管理系統和代碼管理系統進行有機的結合。

五、測試計劃管理

現在我們有了測試需求，有了測試版本，有了測試案例，還有了測試套件，那麼我們接下來就可以開始執行測試了吧？ 先別急，做什麼事最好都有一個計劃，測試工作也不例外。 所謂測試計劃，其實就是如何來測試某一個版本，保證其代碼品質。 站在測試組織管理的角度來看待，這裡麵包括這樣幾個工作：

5.1 提交測試，建立測試工作

當一個測試版本建立之後，我們就可以提交測試進行測試了。提交測試主要註明要測試哪一個版本，預期開始和結束的時間是什麼，還可以有一些備忘的資訊。

 

5.2 測試案例的確定

當一個測試工作建立之後，我們需要為這個測試工作確定好都要執行哪些測試案例。由於每個測試版本都有註冊這個版本所完成的需求或者解決得BUG，因為確定需要執行的測試案例的過程，就是根據相應的需求或者BUG篩選測試案例的過程。

 

5.3 測試案例的指派

那麼通過上述的用例篩選功能，確定好這一次測試需要執行的用例之後，下一步的工作就是將測試案例做好分配。當然，如果某一個測試工作只有自己來進行，那麼這個工作就可以省卻。但如果一個測試需要很多人一起完成，或者是需要外包給第三方公司進行，那麼就可以通過這個功能來指派測試案例。

 

六、測試執行管理

測試計劃做完之後，每個人頭上負責執行的測試案例也就都非常清楚了。這時候每個人要做的事情就是執行自己頭上所負責的測試案例

6.1 測試案例執行

首先我們來看下測試案例的執行頁面：

 

由於我們設計的測試案例是分開步驟地，所以在執行測試案例的時候，可以非常清晰的確定每一個步驟執行的結果。

在測試工作的用例列表介面，可以查看每一個用例最後的執行情況。

 

6.2 從測試結果建立BUG

當一個測試案例執行失敗之後，就可以從測試結果中直接建立一個BUG，指派相應的開發人員進行解決。

 

大家可以看到，我們可以自動產生BUG的重現步驟：-） 這就是將測試案例步驟分開的好處。

七、缺陷管理

缺陷管理是一個測試管理工具中最重要的功能了。當測試過程中產生了bug之後，開發人員和測試人員的互動就通過bug來進行。這裡麵包括基本的建立bug、解決bug、編輯、驗證關閉，啟用等功能。這一塊的功能和邏輯大家都比較熟悉，不再贅述。

我們想特別和大家分享的一點是bug到測試案例的轉化。有的bug非常的經典，也非常重要，但是在這個bug出現的時候，當前系統裡並沒有用例 覆蓋它，所以我們需要將其放在用例庫裡面，以保證後續的版本不再重返類似的問題。因此我們設計的系統中還提供了bug轉為用例的功能。

將Bug的步驟自動計算為用例的步驟，是不是很酷？

八、發行管理

當開發人員解決了若干bug之後，就可以重新建立一個測試版本，然後提交測試，然後又是測試計劃，測試執行... … 如此往返，直到最後一個階段測試工作終結，我們就可以建立一個發布了。

在建立發布的時候，需要選擇一個測試版本(build)，而這個測試版本又關聯了這個發布所完成的需求、所設計的用例以及所提交的bug，由此與前面的工作完美的形成了閉合。

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