工作成果: 測試構想清單
這個構件列舉構想(通常不完整)來指出可能適合進行的測試。
目的
  • 協助推論測試,以及在專案中及早進行測試。
關係
角色負責: 修改者:
說明
概略輪廓

每一份「測試構想清單」應該儘可能地考量各種不同的想法,包括以下許多方面:

  • 已審查所有相關的測試構想型錄嗎?
  • 清單上遺漏任何品質風險嗎?
  • 清單上遺漏任何相關的誤差模型嗎?
  • 已考量所有可能的攻擊手段嗎?
  • 已考量一或多個相關的肥皂劇?
  • 有其他任何構想是您認為值得考量的嗎?
  • 清單中每一個構想的相對重要性為何?

產生初步的構想清單之後,請考量清單上是否有任何相關的構想可以結合或合併。 根據經驗,大多數清單以七個項目為準,頂多加減兩個。 如需「測試構想清單」內容的詳細資訊,請參閱標題表中在「詳細資訊」章節下的準則。

主要說明

「測試構想清單」在概念性「測試計劃」和更詳細的「測試案例」或具體的「測試 Script」之間提供一個抽象層。目的是擷取潛在測試的構想(通常是不完整或局部的構想),以利於推理測試。在開發週期的初期,或當支援的專案工作成果不存在或不完整時,這個工作成果特別有用。

內容
選用
規劃Yes
調整
表示法選項

在某些領域和測試慣例中,並不認同「測試構想」,頂多視為非工式的工作成果。 因此,「測試構想清單」的內容和格式可能需要修改,才能符合每一個特定組織和專案的需求。

在做記錄時(正式或非正式),有兩種主要的樣式:

  • 第一種是標準的文件結構,採用類似以上的格式。多個「測試構想」通常會一起表達,而單一「測試構想」通常無法獨立代表一份完整的清單。
  • 第二種採用某些形式的表格或資料庫。每一列指定一個「測試構想」,並以直欄來協助排序和依不同準則來過濾。 測試矩陣因果關係表可視為「測試構想清單」的另一種格式。

也應該考慮持續測量「測試構想」的進度、效用、變更管理等。 可考慮採用以規格為主的測試涵蓋率,每一個「測試構想」或「測試構想清單」至少可回溯至一個要測試的規格項目。 例如,追蹤要測試的需求規格元素,通常可反映完整產品需求中的一部分(請參閱技術:測試的重要計量單位)。

「測試構想」可選擇保留在 測試案例 測試 Script 中。這份清單也可從 測試計劃中參照(或者,在小規模測試中,可直接併入)。



詳細資訊