目的:
|
對於從「測試構想清單」衍生的每一個測試,定義重要的特性。
|
利用您截至目前為止已收集的資訊,找出並定義實現測試所需的重要特性來設計測試。 請注意,產生的測試設計可能有不同的記錄方式:
-
習慣上,測試設計會記錄為工作成果:測試案例。
-
工作成果:工作量分析模型在概念上是一種特殊且較複雜的「測試案例」,與系統效能測試特別有關。
-
視測試和專案文化的複雜性而定,測試也可能適合直接實現為工作成果:測試
Script, 如果您可以不必建立「測試案例」成果,則可以考慮這種作法。 如果採取這種方式,請以有用的資訊來充分解釋「測試 Script」,說明測試為何有用。 請利用這些註解當做非正式、內嵌的「測試案例」。
利用已收集的資訊,考量測試的每一個層面。
以「黑箱」觀點看待測試,指出測試的重要公開特性。 指出需要輸入什麼來模擬測試及預期會產生什麼輸出。 也要舉出重要的執行條件 - 此步驟不需要解釋或瞭解執行條件的「如何」。
請注意,「輸入」和「預期輸出」可能只是簡單的資料類型值(例如 "A"、"1"),也可能是複雜的多維資料(例如聲音片段、物件),視特定的測試而定。 最好為特定的「輸入」或「預期輸出」定義背後的限定元,不要只是提供特的值。
這讓後續實作或執行測試的人一定可以瞭解「測試資料」背後的理由,讓他們在任何指定的執行情況下,可以選擇更換值和替代值來變化測試。
觀察點是執行測試期間的某個時刻,您想要觀察測試環境在此時刻的某些狀態層面。 在瞭解執行條件及輸入和預期輸出的情況下,
指出測試執行期間要觀察什麼特定點,並指出如何觀察資料。
控制點是測試執行期間的某個時刻,您想要在此時刻上從測試的眾多控制流程中做出決策。
調查可用的「測試情境」,針對每一個情境,考量在哪些地方控制將採取不同的測試執行途徑。 核對所有不同的控制點,將控制點減少到目前測試週期所需的數量。
測試法則包含要測試的預期輸出值和可推測這些值的方法:特定的回應和憑以提供回應的媒介。
例如,若要驗證文書處理套件中使用的字型是否正確呈現,預覽列印可做為媒介來驗證字型呈現。 測試法則指定對照預期結果來驗證實際測試結果所需的格式和功能方面。
|