軟體測試檔案是軟體開發生命週期中不可或缺的環節，用於指導測試流程、記錄測試結果，並確保軟體品質。IEEE Std 829-2008 標準提供了一套完整的測試檔案規範，涵蓋了測試計畫、測試設計、測試案例和測試程式等方面。測試計畫檔案依測試層級分為主測試計畫（MTP）和層級測試計畫（LTP），LTP 又可細分為單元、整合、系統和驗收測試計畫。測試設計檔案則與測試計畫對應，也分為不同層級，用於詳細描述測試設計細節。軟體審查清單（SRL）用於追蹤需審查的軟體需求，並透過程式碼審查來驗證。實務上，SRL 與可追溯性矩陣（RTM）結合使用，確保所有需求都被覆寫。
軟體測試檔案規範
軟體測試是確保軟體品質的重要環節，而完善的測試檔案則是測試過程中的關鍵。本章節將介紹軟體測試檔案的相關規範與實務。
測試計畫的重要性
軟體測試計畫是一份描述測試範圍、組織和活動的檔案，主要提供測試過程的管理概覽。IEEE Std 829-2008 提供了測試計畫的詳細規範，以下將根據該標準介紹主要的測試計畫型別。
主測試計畫（Master Test Plan, MTP）
主測試計畫是組織層級的頂層管理檔案，用於追蹤整個專案（或多個專案）的測試過程。軟體工程師通常不直接參與 MTP 的編制，但專案經理或專案負責人可能會參與其中。
MTP 大綱（根據 IEEE Std 829-2008）
簡介 1.1 檔案識別碼 1.2 範圍 1.3 參考文獻 1.4 系統概述與主要功能 1.5 測試概述 1.5.1 組織 1.5.2 主測試排程 1.5.3 完整性層級架構 1.5.4 資源摘要 1.5.5 責任歸屬 1.5.6 工具、技術、方法和度量指標
主測試計畫的詳細內容 2.1 測試流程（包含測試層級定義） 2.1.1 流程：管理 2.1.2 流程：採購 2.1.3 流程：供應 …
內容解密：
上述大綱顯示了 MTP 的主要結構，包括簡介、詳細內容和一般性規定。簡介部分提供了檔案的整體概覽，而詳細內容則闡述了測試流程、管理要求和報告需求。
層級測試計畫（Level Test Plan, LTP）
層級測試計畫根據開發階段的不同，分為多種型別，如單元測試計畫、整合測試計畫、系統測試計畫和驗收測試計畫等。開發團隊通常會參與 LTP 的編制，因為這些檔案涉及軟體設計的詳細特徵。
LTP 大綱（根據 IEEE Std 829-2008）
簡介 1.1 檔案識別碼 1.2 範圍 1.3 參考文獻 1.4 在整體序列中的層級 1.5 測試類別和整體測試條件
本層級測試計畫的詳細內容 2.1 測試專案及其識別碼 2.2 測試追溯矩陣 2.3 待測功能 …
內容解密：
LTP 大綱涵蓋了簡介、詳細內容和管理規定。簡介部分說明瞭檔案的目的和範圍，而詳細內容則描述了測試專案、測試方法和交付成果。
軟體測試檔案的實際應用
軟體測試檔案在實際開發過程中扮演著重要的角色。它們不僅為測試團隊提供了明確的指引，也幫助開發團隊瞭解測試的要求和目標。透過遵循 IEEE Std 829-2008 等標準，組織可以確保其測試檔案的規範性和一致性。
軟體測試檔案規範詳解
軟體測試檔案的撰寫是確保軟體品質的重要環節。IEEE Std 829提供了一套完整的測試檔案規範，涵蓋了測試計畫、測試設計、測試案例和測試程式等各個方面。本文將對軟體測試檔案的相關規範進行深入解析。
測試計畫檔案的層級架構
軟體測試計畫檔案（Test Plan Documentation）按照測試層級可分為四類別：
- Master Test Plan (MTP)：整體測試計畫
- Level Test Plan (LTP)：各層級測試計畫
- Component Test Plan (CTP)：元件測試計畫
- Component Integration Test Plan (CITP)：元件整合測試計畫
- System Test Plan (STP)：系統測試計畫
- Acceptance Test Plan (ATP)：驗收測試計畫
這些檔案的架構遵循IEEE Std 829的建議格式，主要包含以下幾個部分：
1. 簡介與識別資訊
- 檔案識別碼（Document Identifier）
- 測試計畫識別碼（Test Plan Identifier）
- 簡介（Introduction）
- 測試專案（Test Items）
2. 測試範圍與方法
- 特性需測專案（Features to Be Tested）
- 不需測特性（Features Not to Be Tested）
- 方法（Approach）
3. 測試透過/失敗標準
- 特性透過/失敗標準（Item Pass/Fail Criteria）
- 暫停/還原標準（Suspension/Resumption Criteria）
4. 檔案管理與變更控制
- 詞彙表（Glossary）
- 檔案變更程式與歷史（Document Change Procedures and History）
測試設計檔案的實務應用
**Level Test Design (LTD)**檔案描述了測試的設計細節，同樣分為四個層級：
- Component Test Design (UTD)
- Component Integration Test Design (ITD)
- System Test Design (SITD)
- Acceptance Test Design (ATD)
LTD的主要目的是集中管理測試相關的共通資訊，避免在多個測試檔案中重複記載相同的內容。實務上，可以將LTD的部分內容直接合併到測試案例和測試程式檔案中，以提高檔案的可讀性和維護性。
軟體審查清單的建立與應用
**Software Review List (SRL)**是用於追蹤需要透過審查而非測試來驗證的軟體需求。SRL檔案的主要內容包括：
簡介與識別資訊
- 檔案識別碼（Document Identifier）
- 變更歷史（Document Change Procedures and History）
系統描述與審查專案清單
- 整體系統描述（General System Description）
- 審查專案清單（Checklist）
每個審查專案包含：
- 審查識別碼（Review Identifier）
- 審查專案說明（Discussion of Item to Review）
SRL 範例解析
以DAQ DIP開關專案為例，SRL檔案用於審查那些難以透過正式測試程式驗證，但可透過原始碼審查輕易確認的系統需求。
### SRL 範例結構
1. 簡介
- 檔案識別碼：DAQ_SRL v1.0
- 日期：2018年3月23日，版本1.0
2. 範圍
本SRL針對DAQ DIP開關初始化專案中，不適合進行正式測試的需求。
3. 預期讀者
主要為參與專案測試/審查的成員，也可供專案管理與開發團隊參考。
程式碼審查要點說明
在進行程式碼審查時，需要注意以下幾點：
- 審查重點：檢查程式碼是否正確實作了相關需求。
- 審查方法：透過人工檢視原始碼和建置系統。
- 檔案記錄：將審查結果記錄在SRL中。
程式碼審查流程圖示
此圖示展示了程式碼審查的基本流程，從開始到完成各階段的工作重點。
軟體測試檔案規範與實務應用
軟體測試檔案是軟體開發過程中不可或缺的一部分，負責記錄測試案例、測試過程及測試結果。本文將根據IEEE Std 829-2008標準，探討軟體測試檔案的規範與實務應用。
軟體審查清單（SRL）的重要性
軟體審查清單（SRL）是用於驗證軟體是否符合既定的需求規格。SRL中的每個審查專案都與特定的需求相關聯，並使用特定的標籤（tag）進行標識。
SRL標籤格式
SRL標籤的格式為DAQ_SR_xxx_yyy_zzz，其中：
xxx_yyy是與對應需求相關的字串zzz是一個數字序列，用於建立唯一的識別符號
實務應用
在DAQ DIP開關系統的例子中，SRL包含了多個審查專案，例如：
DAQ_SR_700_000_000：驗證程式碼是否為Netburner MOD54415評估板編寫DAQ_SR_702_001_000：驗證軟體是否建立了一個單獨的任務來處理串列埠命令
新增SRL專案至可追溯性矩陣（RTM）
將SRL專案新增至RTM，可以實作對審查專案的追溯。只需在RTM中找到對應的需求，並將SRL標籤新增至相應的列中即可。
軟體測試案例檔案（STC）
軟體測試案例檔案（STC）用於描述測試案例的詳細資訊。根據IEEE Std 829-2008，STC檔案包括四個層級：
- 元件測試案例（UTC）
- 元件整合測試案例（ITC）
- 系統測試案例（SITC）
- 驗收測試案例（ATC）
STC檔案結構
STC檔案的結構如下：
簡介
- 檔案識別符號
- 範圍
- 參考文獻
- 上下文
- 描述符號
詳細資訊（每個測試案例）
- 測試案例識別符號
- 目標
- 輸入
- 結果
- 環境需求
- 特殊程式需求
- 案例間依賴關係
全域資訊
- 詞彙表
- 檔案變更程式和歷史記錄
自動化測試的最佳實踐
在實務中，UTC和ITC通常會合併成同一份檔案。使用自動化測試程式可以大大提高測試效率。透過軟體工具執行所有單元和整合測試，是軟體工程的最佳實踐之一。
此圖示展示了從系統需求規格（SyRS）到自動化測試的流程。
軟體測試檔案的重要性與建立
軟體測試是確保軟體品質的關鍵步驟，而建立完善的測試檔案則是測試流程中的重要環節。IEEE Std 829-2008 提供了一套完整的軟體測試檔案建立，包括測試計畫（Test Plan）、測試案例（Test Case）與測試報告（Test Report）等。本文將探討軟體測試檔案的建立方法與其重要性。
自動化測試與手動測試的平衡
在現代軟體開發流程中，自動化測試已成為提高測試效率與降低人為錯誤的重要手段。透過自動化測試，開發團隊可以快速執行大量測試案例，大幅縮短測試時間並提升測試品質。然而，並非所有測試案例都適合自動化，有些複雜或特殊情境仍需要手動測試。因此，建立一份完善的統一測試案例（UTC）或獨立測試案例（ITC）檔案，以涵蓋手動測試的部分，是非常必要的。
許多採用敏捷開發模式與測試驅動開發（TDD）的團隊，通常會放棄正式的 UTC 與 ITC 檔案，而傾向於使用非正式的測試程式或自動化測試指令碼。這種做法在某些情況下是可行的，但對於大型企業或需要遵循嚴格法規要求的專案來說，仍需要提供一定的檔案以證明測試流程的完整性。
重複性測試的重要性
無論是正式或非正式的測試程式，建立一個可重複的測試流程是至關重要的。迴歸測試（Regression Test）需要確保每次程式碼變更後，軟體功能仍然正常運作。因此，建立詳細的測試案例（Test Case）是確保測試可重複性的關鍵。
在單元測試與整合測試階段，測試資料的生成通常結合黑箱測試（Black-box Testing）與白箱測試（White-box Testing）。黑箱測試根據系統需求（SyRS 與 SRS）生成測試資料，而白箱測試則需要分析原始碼，以確保程式碼的每個部分都被充分測試。《Write Great Code, Volume 6: Testing, Debugging, and Quality Assurance》將進一步探討如何生成黑箱與白箱測試資料。
系統整合測試與驗收測試的檔案要求
在系統整合測試（SIT）與驗收測試（ATC）階段，正式的測試檔案變得尤為重要。特別是在客戶定製的系統或涉及法規遵從性的專案中，必須提供完整的測試檔案以證明軟體符合其需求。SITC（System Integration Test Case）與 ATC（Acceptance Test Case）檔案通常直接源自系統需求，如圖 12-2 所示。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 軟體測試檔案規範詳解
package "軟體測試架構" {
package "測試層級" {
component [單元測試
Unit Test] as unit
component [整合測試
Integration Test] as integration
component [端對端測試
E2E Test] as e2e
}
package "測試類型" {
component [功能測試] as functional
component [效能測試] as performance
component [安全測試] as security
}
package "工具框架" {
component [pytest] as pytest
component [unittest] as unittest
component [Selenium] as selenium
component [JMeter] as jmeter
}
}
unit --> pytest : 撰寫測試
unit --> integration : 組合模組
integration --> e2e : 完整流程
functional --> selenium : UI 自動化
performance --> jmeter : 負載測試
note right of unit
測試金字塔基礎
快速回饋
高覆蓋率
end note
@enduml
此圖示說明瞭 SITC 與 ATC 檔案的來源，其中 ATC 檔案通常是 SITC 的子集，並且可能會根據實際需求合併或刪減某些測試案例。
測試案例檔案的結構
一份完整的 STC 檔案應該包含以下幾個部分：
檔案識別資訊
檔案識別資訊應包括唯一的檔名稱或編號、發布日期、作者資訊、檔案狀態（如草稿或最終版本）、核准簽署以及版本號碼。這樣的資訊有助於在其他檔案中（如 STP 與 RTM）參照該測試案例檔案。
範圍描述
此部分應簡要總結待測的軟體系統及其功能。這有助於讀者快速瞭解該檔案的適用範圍。
參考檔案
此部分列出所有與 STC 相關的內部與外部參考檔案。內部參考檔案可能包括 SyRS、SRS、SDD、RTM 與 MTP 等，而外部參考檔案則可能涉及相關的標準（如 IEEE Std 829-2008）或法規要求。
內容解密：
本段落闡述了軟體測試檔案的結構和內容。首先，檔案識別資訊確保了檔案的唯一性和可追溯性，這對於後續的檔案管理和參照至關重要。其次，範圍描述幫助讀者理解檔案的適用範圍，避免誤用或混淆。最後，參考檔案的列出提供了進一步閱讀和驗證的依據，增強了檔案的完整性和權威性。這些內容共同構成了軟體測試檔案的基本框架，為軟體測試提供了堅實的基礎。
最終檢查與驗證
在完成軟體測試檔案的建立後，進行最終檢查與驗證是必不可少的步驟。這包括檢查檔案的完整性、正確性和一致性，以確保所有必要的資訊都已包含且準確無誤。同時，也需要驗證檔案的格式是否符合相關標準的要求。
透過嚴格的檢查與驗證流程，可以及時發現並修正檔案中存在的問題，從而提高檔案的品質和可靠性。這對於確保軟體測試的有效性和可信度具有重要意義。
內容解密：
最終檢查與驗證是軟體測試檔案建立過程中的關鍵步驟。它確保了檔案的準確性和完整性，避免了因檔案錯誤而導致的後續問題。透過仔細檢查和驗證，可以提高檔案的品質，為軟體測試提供可靠的依據。這不僅有助於提升軟體品質，也為專案的順利進行提供了保障。
軟體測試檔案（Software Test Documentation）詳解
軟體測試檔案是軟體開發過程中不可或缺的一部分，它詳細記錄了測試案例、測試步驟、預期結果等重要資訊。本篇文章將探討軟體測試檔案的結構和內容，幫助讀者更好地理解和編寫軟體測試檔案。
軟體測試案例（STC）結構
軟體測試案例（STC）是軟體測試檔案的重要組成部分，它包含了測試案例的詳細資訊。STC 的結構如下：
12.4.1 簡介
本文提供了 STC 的概述，包括測試案例的範圍、參考檔案、上下文和標記法。
- 測試案例範圍：描述了測試案例所涵蓋的功能或模組。
- 參考檔案：列出了與測試案例相關的檔案，如需求規格說明書等。
- 上下文：提供了測試案例所需的背景資訊，如自動化測試生成工具或網際網路工具的使用。
- 標記法：描述了測試案例的標記格式，如
proj_STC_xxx_yyy_zzz。
12.4.2 詳細資訊
本文詳細描述了每個測試案例的資訊，包括測試案例識別碼、目標、輸入、預期結果、環境需求、特殊程式需求、案例間依賴關係和透過/失敗標準。
- 測試案例識別碼：為每個測試案例分配一個唯一的識別碼，如
DAQ_STC_002_000_001。 - 目標：簡要描述了測試案例的目的或目標。
- 輸入：列出了執行測試案例所需的輸入資料及其關係。
- 預期結果：描述了測試案例的預期輸出資料和行為。
- 環境需求：列出了執行測試案例所需的硬體、軟體和其他環境條件。
- 硬體環境需求：描述了所需的硬體裝置及其組態設定。
- 軟體環境需求：列出了所需的軟體及其版本/組態。
- 其他環境需求：提供了其他必要的環境資訊，如組態細節等。
- 特殊程式需求：描述了執行測試案例所需的特殊條件或約束。
- 案例間依賴關係：列出了必須在當前測試案例之前執行的其他測試案例。
- 透過/失敗標準：定義了評估測試案例是否透過的標準。
程式碼範例與解析
以下是一個簡單的測試案例範例，用於演示如何編寫軟體測試檔案：
def add_numbers(a, b):
return a + b
# 測試案例：驗證加法函式的正確性
def test_add_numbers():
# 輸入資料
a = 2
b = 3
# 預期結果
expected_result = 5
# 執行測試
result = add_numbers(a, b)
# 驗證結果
assert result == expected_result, f"預期結果為 {expected_result}，但實際結果為 {result}"
#### 內容解密：
1. `add_numbers` 函式接受兩個引數 `a` 和 `b`，並傳回它們的和。
2. `test_add_numbers` 函式是一個測試案例，用於驗證 `add_numbers` 函式的正確性。
3. 在 `test_add_numbers` 中，我們定義了輸入資料 `a` 和 `b`，以及預期結果 `expected_result`。
4. 執行 `add_numbers` 函式並將結果儲存在 `result` 變數中。
5. 使用 `assert` 陳述式驗證實際結果是否與預期結果一致。如果不一致，則輸出錯誤訊息。
軟體測試檔案的未來趨勢
隨著軟體開發技術的不斷進步，軟體測試檔案也在不斷演變。未來，我們可以期待看到更多自動化和智慧化的軟體測試工具和技術，以提高軟體測試的效率和準確性。