二、軟體測試計畫書
軟體測試計畫書(Software Testing Plan, STP)主要在釐定軟體測試的種類、方法及工作構想，其目的在藉以建立發展人員與測試人員雙方對於測試計畫的共識，作為執行、評估測試工作的準則。
(一)文件大綱
(一)、前言
(1)文件目的 (2)名詞解釋與縮寫符號(B、C) (3)參考文件資料(B、C) 2、軟體驗證計畫 (1)需求確認 (2)功能設計驗證(B, C) (3)細部設計驗證(C) (4)程式碼驗證(C) 3、軟體確認計畫 (1)測試類別 (2)測試機制 A.測試環境 B.測試方法 (3)測試準則 A.測試項目之通過失效準則 B.測試中止及再繼續之原則(B、C) (4)測試工作時程
(5)測試應交付文件 A.測試機制摘述(B、C) B.測試結果彙總清單 C.測試紀錄(B、C) D.測試異常報告(B、C) E.測試涵蓋率(C) 4、附錄
(二)分項說明
1、前言
(1)文件目的
摘要描述本文件之目的與內容。
(2)名詞解釋與縮寫符號(B、C)
描述在本文件中所使用到的特殊名詞、縮寫符號與簡稱。定義用字需解釋清楚、縮寫符號則需說明全文及其意義，並以英文字母順序表列。
(3)參考文件資料(B、C)
參考資料項目為一般國際標準文件所必需，記載並說明此軟體測試計畫書中所參考引用之文獻及範例，軟體專案之文件，組織及作業手冊之編號、標題、改訂版、與日期，及其他相關的文件等。
2、軟體驗證計畫
敘述於專案進行中各階段驗證工作之計畫構想，一般可依下列階段分別說明之：
(1)需求確認
需求確認(Requirement Validation)主要在確認軟體需求規格書的系統需求是否確實合乎用戶之要求，一般會從正確性(Validity)、精確性(Certainty)、一致性(Consistency)、完整性(Completeness)、可測試性(Testability)等角度著手。
(2)功能設計驗證(B, C)
通常功能設計(Functional Design)的工作主要是將用戶需求轉換為功能設計規格書(Functional Design Specification)，表示用戶所能觀察感受到的最終產品之行為。
一般來說，功能設計驗證最主要在確定功能設計規格書的內容是否完全符合用戶的需求，特別是其精確性與完整性，有沒有某些需求被遺落!
(3)細部設計驗證 (C)
細部設計(Detailed Design)或稱為內部設計(Internal Design)是將功能設計規格書轉換為細部設計規格書(Detailed Design Specification)，它包含資料結構設計、系統流程設計、演算法、資料庫設計等資訊，主要在描述該軟體系統如何建構完成。
細部設計規格書可能會依系統的複雜度而分為若干層次，因此為簡化文件項目，本手冊在設計建置階段將前述之功能設計規格書與後續若干層次之細部設計規格書合併統稱為軟體設計規格書。
如同前述，細部設計驗證的方向主要在確定細部設計的完整性、資料結構或演算法的適當性等等。
(4)程式碼驗證(C)
通常程式碼的驗證工作可透過逐步審查(Walkthrough)、檢查(Inspection)、程式碼審查(Code review)等方式進行，以比較程式碼與軟體設計規格書的完整對應，並設法找出變數參照(Variables Reference)、變數宣告(Variables Declaration)、介面、邏輯等方面之可能錯誤。
針對上述每一種驗證工作，我們應分別編撰其驗證計畫。至於驗證計畫之內容，至少應包括下列幾項：
(a)將被驗證之項目
(b)應執行之工作
(c)責任角色
(d)時程表
3、軟體確認計畫
律定軟體開發中及開發完成時所必需執行的測試類別、測試機制及其測試相關作業計畫。
一般來說，軟體確認的測試作業可分為低階測試(Low-level Testing)及高階測試(High-level Testing)等兩大類，前者包括單元測試(Individual Components Testing)，模組、類別或相關元件測試(Modules, Object Class, Related Components Testing)，分系統整合測試(Subsystem Testing)，及系統整合測試等；而高階測試又可分為可用性測試(Usability Testing)、功能測試(Function Testing)、系統測試(System Testing)、驗收測試(Acceptance Testing)等。
可用性測試主要在確認系統產品是否符合實際操作的工作習慣與操作的方便性，而不是強迫使用者去適應軟體系統所擬定的作業方式，以表示系統易學易用的程度。功能測試或稱為功能確認測試
(Function Validation Testing)，目的是在偵測軟體產品系統的功能實際表現與功能設計規格書中之差異；系統測試則是在偵測軟體產品的整體實際表現與軟體需求規格書中之差異，一般可包括容量測試(Volume Testing)、壓力測試(Stress Testing)、安全性測試(Security Testing)、回復測試(Recovery Testing)、型態測試(Configuration Testing)、可靠度測試(Reliability Testing)等等；至於驗收測試則是在確認系統產品是否滿足客戶的需求，一般又分為Alpha (a)測試及Beta (b)測試等兩種方式。
但為維持本指引手冊之簡易性，以下所指之軟體確認計畫將不包括單元測試(模組、類別或相關元件測試)、分系統測試及系統整合測試等低階測試部分，而僅偏重於功能測試及系統測試，且此處之系統測試並擴大範圍涵蓋驗收測試之部分項目。
針對功能測試及系統測試之規劃，其測試計畫書之內容大綱一般應包括下列項目：
(1)測試類別
針對某一個軟體系統，描述其軟體測試是屬於功能測試或系統測試。
(2)測試機制
A.測試環境
詳細描述在此一測試機制中，對週邊環境有那些需求與限制，例如軟體、硬體及網路的需求等。
B.測試方法
描述在此一測試機制中所使用的方法。
通常功能測試所採用的測試方法大都均以黑箱(Black-box)技術為主，例如：等域劃分法(Equivalence Partitioning)、邊界值測試
(Boundary-value Analysis)、錯誤猜測法(Error Guessing)等；而系統測試則應隨所測試的目的不同，再選擇採用適當的測試方法，例如：計時測試、最大容量測試、壓力測試等。圖4.3.1為邊界值測試之舉例：
(3)測試準則
A.測試項目之通過失效準則
說明每一測試項目通過測試或測試失敗的準則，例如，輸入資料和輸出資料都是落在預期範圍之內則為測試通過。
B.測試中止及再繼續之原則(B、C)
說明欲中止全部或部分測試工作之準則，以及在何種原則下才得以繼續進行測試或重複測試；例如，所有測試案例之測試涵蓋率無法達到所規劃者，則應停止未完成及未進行之測試，待設計或獲得足夠的測試案例方得以繼續測試。
(4)測試工作時程
描述測試之工作時程、測試項目之甘特圖表示。
(5)測試應交付文件
A.測試機制摘述(B、C)
對於測試環境包括軟體，硬體，及網路狀況的簡單描述。
B.測試結果彙總清單
根據軟體系統之需求追溯表或需求規格表，標示其各細項是否已被測試通過的清單查核表，測試結果應包括：測試項目、測試案例(或測試案例編號)、及測試結果是否真正符合期望之值等資訊；若有異常則應註明那一部分異常。
若軟體系統之需求或功能非常複雜致其測試項目數量太過龐大時，則追溯表之彙總清單可視實際狀況，以分系統或整合之需求規格的類別表示之。
C.測試紀錄(B、C)
列表記錄實際所採用的測試案例或測試案例編號，及每一案例的實際參數值，例如：正常值、非正常值、臨界值、例外狀況等輸入。若測試案例很多，所產生之測試紀錄(Test Log)很長，可將之置於附錄中。
D.測試異常報告(B、C)
針對測試異常的部份，說明其測試案例，並說明如何追溯該功能，及如何更正；每一測試異常狀況均應列出其對應之測試異常報告，而且最好能註明該異常狀況的異常分類及其嚴重等級例如：非常嚴重(Critical)、重大(Major)、次要(Minor)及表面(Cosmetic)等。
E.測試涵蓋率(C)
測試涵蓋率指整個測試流程中，總共測試了多少百分比之原始程式碼、需求項目或功能項目。
4、附錄
包含完整的測試案例清單、測試紀錄以及其他相關之參考文件。