Cody Blog

Testopia 測試案例管理系統簡介

Why Testopia ?

最近想研究一些時下流行的測試案例(Test Case)管理系統,之前有稍微裝一下Test Link來玩看看。因為看到《How Google Tests Software》裡面有提到一點,就是在Gogole裡,如果自動化測試測試沒過的話,會直接自動新增一筆Bug Tacker給相關人員,可見其相當重視自動化測試的品質,讓Automation的Bug提升到跟Product Bug相等重要。這也讓我重新思考 Bug Tracking System 對於Automation們的重要性。所以這讓我注意到另一套 Test Case Management System: Testopia。我覺得Testopia最大的特色,就是他是一套Bug Tracking System: Bugzilla 的延伸套件。也就是如果我們採用了Testopia來當我們的測試案例管理系統的話。也就相當於能直接擁有一套 Bug Tracking System了。這成為我想玩玩看 Testopia 的最大理由 :)

安裝 Testopia:

要玩 Testopia 之前要先安裝 Bugzilla,關於 Bugzilla 的安裝,這邊有記錄,安裝 Testopia 其實很簡單,下載 Testopia 的 tarball file : 當下最新的版本是2.5版

  1. 解壓縮︰ tar zxvf testopia-2.5-BUGZILLA-4.2.tar.gz

  2. 把裡面的內容丟到 bugzilla 的根目錄,例如 /var/www/html/bugzilla

  3. 執行 checksetup 的 perl 檔 : ./checksetup.pl

這樣就安裝完成了。

Testopia 的架構

Testopia 手冊裡面有一張圖很清楚地表達整個 Testopia 的架構 …

測試案例如何區分 RAT, FAST, TOFT ?

我相信更了解測試案例的分類,可以加速測試案例的設計與開發,並且讓開發人員對於測試目標能更了解。一般而言,測試案例種類至少可分成以下幾種:

  • Release Acceptance Test(RAT)
  • Functional Acceptance Simple Test(FAST)
  • Task-Oriented Function Test(TOFT)
  • Force-Error Test(FET)
  • Boundary Test
  • Volume Test
  • Stress Test

之前在學著開測試案例的時侯,前輩有教過各種測試案例種類的差別。網路上也有一些文章討論。最容易讓人分不清大概就是RAT和FAST的差別了。RAT跟FAST都是Acceptance Test。就字面上的意思的確讓人很容易分不清。對我而言,其實測試案例就分成兩類,一種是測正常軟體正向的Test case,或是測試Error handle的FET兩種。然後測Positive Test Case 又依照不同的屬性又可以分成 RAT、FAST、TOFT、Boundary、Volume、Stress。但由於一個軟體建構出來之後。一般而言,皆需通過測試案例的測試,才代表其品質有一定程度的保障。然而,什麼先測,什麼後測?當然是重要的先測。而重要性粗分的話,大概可以分成:

RAT > FAST > TOFT = Boundary = FET > Volume = Stress 

RAT是用來評斷這個Build是否能被測試,在某些流程中,如果RAT Test cases Fail的話,QA人員可以要求不要測這個Build,繼續測試之前的Build。因為這個Build存在著重大的Defect,無法進行接下來的測試。所以RAT Testcase理論上數量應該很少,例如安裝的部份就一定至少會有一條RAT,畢竟如果軟體都沒辦法安裝起來的話,接下來就沒辦法測試了。

FAST可視為某個Module最重要的TestCase,如果不能Pass的話,很可能就會影響到接下來TOFT沒辦法繼續測試。所以可以把某個Module當中最重要的幾個Testcase挑出來當成FAST。 TOFT基本上只要不是被拿去當RAT跟FAST的Positive Test Case的剩下就可以當Test Case。FET是故意製造出一些情況讓程式出錯,測Error Handle是否有處理得當的Test Case,這種TestCase通常可以找到不少的Defect,因為畢竟Developer會比較容易忽略一些Error Handle Boundary Test專測一些臨界情況 …