準則: 測試中的重要決策
這個準則說明在調整流程的「測試」方面時必須考量的重要事項。
關係
主要說明

決定如何使用工作成果品

決定要使用什麼工作成果及如何使用。除了指出要使用什麼工作成果之外,也必須調整要使用的每一個工作成果,以符合專案的需求。 

下表指出建議哪些「測試」工作成果及哪些可視為選用(亦即,只在特定的情況下使用)。 至於其他調整注意事項,請參閱工作成果說明頁的調整章節。

工作成果 目的 調整(選用、建議)
測試評估摘要 彙總測試結果,主要是供管理小組和測試小組之外的其他關係人使用。 建議大部分專案採用。

當專案文化比較不拘泥形式時,可能只記錄測試結果,不建立正式的評估摘要,會比較合適。 在其他情況下,「測試評估摘要」可以納入成為其他「評量」工作成果的一個區段,例如反覆評量審查記錄
測試結果 這個工作成果是從一或多份測試日誌的原始資料中得出的分析結果。 建議。大部分測試小組都會保留測試結果某種形式的合理詳細記錄。手動測試結果通常會直接記錄在這裡,且會結合從自動化測試中提煉出來的測試日誌。

在某些情況下,測試小組會直接從測試日誌產生測試評估摘要。
測試日誌

這是測試執行期間的原始資料輸出,通常是自動化測試所產生。

選用。

許多執行自動化測試的專案都會有某種形式的測試日誌。各個專案的不同之處,在於得出測試結果之後,會保留或捨棄測試日誌。

如果您需要滿足某些審核需求、您要分析原始測試輸出資料在一段時間內的變更,或開始之時您不確定您可能需要提供的所有分析,您可能會想保留測試日誌。

測試套組 用來將相關的個別測試(測試 Script)放在一起,分組到有意義的子集中。 建議大部分專案採用。

另外,在定義測試正確運作所需要的任何測試 Script 執行順序時,也有這項需要。
測試觀念清單 這是一份列舉的觀念清單,這些觀念是將要處理的有用測試,通常只列出一部分。 建議大部分專案採用。

在某些情況下,會以非正式的方式來定義這些清單,且根據它們定義了測試 Script 或測試案例之後,便會捨棄它們。
測試策略 定義如何針對目標系統的一或多個方面來處理測試工作的策略計劃。 建議大部分專案採用。

建議在大部分情況下,每個專案或專案內的每個階段各有一項單一測試策略。在適當情況下,您可以選擇性地重複使用現有的策略,或根據所處理的測試類型來進一步細分測試策略。
 測試計劃 更詳細的定義主導反覆工作的測試目標、動機、方法、資源、排程及工作成果。 建議大部分專案採用。

建議您每次反覆都要有獨立的測試計劃,以便定義精細而明確的測試策略。(選擇性)您可以將「測試計劃」納入成為反覆計劃的一個區段。
 測試計劃 定義主導一個階段或整個生命週期的高階測試目標、方法、資源、排程及工作成果。 選用。適用於大部分專案。

主要測試計劃用來定義軟體開發生命週期大多部分的高階測試工作策略。(選擇性)您可以將「測試計劃」納入成為軟體開發計劃的一個區段。

請考慮是否在「反覆」測試計劃之外,另外維護一份「主要」測試計劃。主要測試計劃主要是涵蓋一些邏輯和流程制定資訊,這些資訊通常會與整個專案生命週期相關,因此,這個計劃不太可能在反覆之間發生改變。
 測試 Script 測試資料 測試 Script 和測試資料是測試的實現化或實作,其中測試 Script 體現了程序化方面,測試資料體現了定義特性。 建議大部分專案採用。

各專案的不同之處,在於這些工作成果之處理的正式程度。在某些情況下,這些都是非正式和暫時的,對測試小組的評斷是以其他準則為基礎。在其他情況下,尤其是自動化測試,測試 Script 和相關聯的測試資料(或它的子集)是當作測試工作的主要交付項目來處理。
 測試案例

定義一組特定的測試輸入、執行條件,以及預期結果。

產生測試案例的文件,可讓您檢視它們的完整性和正確性,以及在規劃和展開實作工作之前考量它們。

當輸入、執行條件和預期結果非常複雜時,這尤其有用。

我們建議您在大部分專案上,如果處理特定測試的條件非常複雜或成本很高,您便應該定義測試案例。當合約要求的交付項目包括測試案例時,您也必須產生它們的文件。

在大部分其他情況中,我們建議您維護測試觀念清單和實作 的測試 Script,而不要維護詳細的測試案例文字。

部分專案只會概述高階測試案例,細節便交給測試 Script。 另一個常用樣式是在測試 Script 的備註中,產生測試案例資訊文件。

 工作量分析模型

測試案例的特殊類型。用來定義代表性的工作量,以便評量在負荷下運作之系統的相關品質風險。

建議大部分系統採用,尤其是必須評估系統負荷效能的系統,或系統負荷作業有重大品質風險的系統。

部署在獨立式目標系統的系統,通常沒有這項需要。

設計模型中的 可追蹤性類別

實作模型中的 可追蹤性元素

如果專案必須開發其他重要的特殊化行為來容納和支援測試,這些方面是藉由將可測試性類別併入設計模型和將可測試性元素併入實作模型中來表示。

當必要之時。

 Stub 是「測試類別」和「測試元件」的通用種類。

 測試自動化架構

利用若干不同的架構視圖來描述系統的不同面向,以提供測試自動化系統的架構概觀。

選用。

當大量人員將合作建置自動化測試時,或當測試自動化系統預期需要長時間進行維護時,建議測試架構相對複雜的專案採用。

在某些情況下,這可能只是一個集中記錄的白板圖,供相關各方參考。

 測試介面規格

依分類器來定義一組用來測試(可測試性)的必要行為(明確地說,就是類別、子系統或元件)。一般類型包括測試存取、Stub 行為、診斷記載和測試 oracle。

選用。

許多專案在類別、使用者介面等方面的可見作業,都有足夠的測試可存取性。

建立測試介面規格的某些一般原因包括讓 GUI 測試工具能夠與工具和診斷訊息記載常式互動的 UI 延伸規格,當針對批次流程時,尤其如此。



決定如何檢視工作成果

本節提供一些準則來協助您決定應該如何檢視測試工作成果。如需一般指引,請參閱準則:審查層次

問題

問題檢視的處理會隨著環境定義而大不相同,不過,一般而言,都是將它們當作非正式正式-內部正式-外部來處理。在問題追蹤系統中,通常都會強制執行這個檢視流程,或至少在工作流程管理的協助之下進行。一般意見是,檢視的正式程度通常會與所感受的嚴重性或問題的影響相關,不過,專案文化和對於形式的執著程度等因素,通常都會影響到如何處理檢視的選項。

在某些情況下,您可能需要考慮分開處理問題(也稱為症狀或失敗)和錯誤(錯誤的來源)。如果是小型專案,您通常只需要追蹤問題及隱含地處理錯誤來進行管理。不過,由於系統的複雜度會增加,因此,最好是分開管理問題和錯誤。例如,同一個錯誤可能會造成許多問題。因此,如果修正了某個錯誤,就必須找出報告的問題,並通知提出問題的使用者;只有在問題和錯誤是分開識別時,才可能做到這一點。

測試計劃和測試策略

在不容輕忽測試的任何專案中,您需要某種形式的測試計劃或策略。一般而言,每項反覆都需要一份測試計劃,以及某種管理測試策略的形式。您可以選擇性地建立和維護一份主要測試計劃。在許多情況下,這些工作成果都是作為非正式項目來檢視;也就是說,會檢視它們,但並沒有正式核准。當測試可見度對在測試小組之外的關係人而言非常重要時,就應該將它當作 正式-內部項目來看待,甚至是當作正式-外部項目來看待。

測試 Script

測試 Script 通常是以非正式的方式來處理;也就是說,它們是由測試小組的內部人員來核准。如果測試 Script 要給許多測試人員使用,且要供許多不同的測試共用或重複使用,就應該將它們當作正式-內部來處理。

測試案例

測試小組所建立且相依於環境定義的測試案例,通常都是利用非正式流程來檢視,或完全不檢視。在適當情況下,測試案例可以由其他小組成員來核准,這時可將它們看成正式-內部,或由外部關係人來核准,這時可將它們看成正式-外部

作為一般的啟發式作法,我們建議您只規劃正式檢視必須檢視的測試案例,這通常只限於一小組代表最重要測試案例的子集。例如,當客戶想要先驗證再釋出產品時,可能會選取測試案例的某個子集來作為這項驗證的基礎。這些測試案例應該以正式-外部的方式來處理。

測試設計和實作中的工作成果

可測試性類別是在設計模型中,可測試性元素則是在實作模型中。另外,還有兩個其他相關的工作成果(不過,不是測試專用):設計模型中的套件,以及實作模型中的子系統。

這些工作成果是設計和實作工作成果,不過,它們是為了支援軟體測試功能而建立的。它們自然應該與設計和實作工作成果放在一起。請記得命名或標示它們,但要將它們與核心系統的設計和實作清楚分開。請遵循設計和實作工作成果的檢視程序來檢視這些工作成果。

決定反覆核准準則

當您進入每次的反覆時,請用心清楚定義測試工作怎麼樣才算夠,以及要基於什麼來測量這項判斷。請與核准決策的負責人或群組進行這方面的討論。

以下是處理反覆之核准的方法範例:

  • 專案管理小組核准反覆,且檢視測試評估摘要來評量測試工作。
  • 客戶檢視測試評估摘要來核准反覆。
  • 客戶根據處理全體測試之特定子集的示範結果來核准反覆。這個測試子集最好應該在反覆的初期,便事先清楚定義好,獲得共識。這些測試是以正式 - 外部的方式來處理,通常稱為驗收測試
  • 客戶會處理他們自己的獨立測試來核准系統品質。再說明一次,這些測試的本質應該在反覆的初期,便事先清楚定義好,獲得共識。這些測試是以正式 - 外部的方式來處理,通常稱為驗收測試

這是一項很重要的決策 - 如果您不知道目標是什麼,您將無法到達這個目標。