軟體測試檔案規範與實務

– 16 分鐘閱讀

軟體測試檔案是軟體開發生命週期中不可或缺的一部分，用於指導測試過程、記錄測試結果，並確保軟體品質。測試檔案的完整性和準確性直接影響測試效率和軟體可靠性。在實際專案中，測試檔案需要根據專案規模和複雜度進行調整，並遵循相關規範，例如 IEEE Std 829。常見的測試檔案型別包括測試計畫（STP）、測試案例、測試程式、測試日誌和異常報告。測試計畫定義了測試範圍、目標、策略和資源分配，而測試案例則描述了具體的測試步驟和預期結果。測試程式詳細說明如何執行測試案例，而測試日誌記錄了測試執行的實際情況，包括測試結果、缺陷和異常。當發現缺陷時，需要撰寫異常報告，詳細描述缺陷的現象、影響和修復建議。測試檔案之間需要相互關聯，例如測試案例需要與需求追蹤矩陣（RTM）關聯，以確保測試覆寫率。

軟體測試檔案規範詳解

軟體測試檔案是確保軟體品質的重要環節，其中軟體測試計畫（STP）檔案的撰寫更是測試流程中的關鍵步驟。本文將根據修改後的STP檔案格式，詳細闡述其內容結構和重點。

測試檔案結構與內容

特殊需求描述

在修改後的STP檔案中，每個測試程式都需要附上其與其他測試程式之間的關係描述，特別是在大型系統中，不同的軟體應用可能會有獨立的STP檔案。因此，「特殊需求」章節用於描述這些測試程式之間的先後順序和相互依賴關係。

執行測試的指示

這部分內容主要針對實際執行測試的人員，通常不是軟體開發者。它提供了關於測試軟體的基本資訊，包括：

  • 當測試程式失敗時應該採取的措施，例如是否應該繼續執行測試或暫停並等待開發團隊解決問題。
  • 如何記錄測試過程中出現的問題或異常。
  • 如何在發生嚴重錯誤時將系統還原到穩定狀態或關閉系統。
  • 如何記錄成功的測試執行，包括簽署確認的流程。

測試程式詳述

每個測試程式都會重複以下結構：

簡要描述

為每個測試程式提供簡短的標題，例如「DIP開關#1測試」。

程式識別碼

每個測試程式都有一個唯一的識別碼（標籤），用於在其他檔案中（如需求追蹤矩陣RTM）參照該測試程式。

目的

詳細描述該測試程式的目的、測試內容及其在整體測試計畫中的位置。

涵蓋的測試案例清單

列出該測試程式所涵蓋的所有測試案例，並確保這些測試案例與其他測試程式中的案例不重複，以保持需求追蹤矩陣的清晰性。

重點整理

  1. 保持測試案例與測試程式之間的清晰對映：確保每個測試案例只被一個測試程式涵蓋，以避免在需求追蹤矩陣中出現複雜的多對多關係。
  2. 詳細記錄測試執行過程中的關鍵資訊：包括失敗處理、問題記錄和成功測試的簽署確認等。
  3. 明確測試程式之間的依賴關係：特別是在大型系統中，不同軟體應用的測試程式可能需要協調執行。
內容解密：

本段落主要闡述了軟體測試檔案的撰寫規範和重點，強調了清晰的結構、完整的內容和準確的對映關係對於軟體測試的重要性。同時，也提到了在實際操作中需要注意的事項，例如失敗處理和簽署確認等。這些內容對於提升軟體品質具有重要的指導意義。

軟體測試檔案編寫

軟體測試檔案（Software Test Documentation）是確保軟體品質的重要工具。本文將介紹軟體測試檔案的結構和內容，幫助開發團隊建立完善的測試流程。

特殊需求（Special Requirements）

在執行測試程式之前，需要確定是否有任何外部資源是必要的，例如資料函式庫、輸入檔案、現有的目錄路徑、線上資源（如網頁）、動態連結函式庫和其他第三方工具等。本文將識別這些外部需求，以確保測試程式能夠順利執行。

測試前的準備工作（Setup Required Prior to Running Procedure）

本文描述了在執行測試程式之前需要進行的任何過程或程式。例如，對於自動駕駛車輛軟體的測試程式，可能需要在測試開始前將車輛駕駛到測試軌道上的指定起點。其他範例可能包括確保有可用的網路或伺服器連線。在某些情況下，測試夾具（如五加侖水桶）的準備也是必要的。

軟體版本號（Software Version Number for This Execution）

這是一個需要填寫的欄位，用於記錄執行測試程式時的軟體版本號。這個欄位並不是強制規定軟體版本，而是要求測試人員在執行測試前填寫當前的軟體版本號。由於在測試過程中可能會遇到缺陷，需要暫停測試並在開發團隊修復缺陷後重新開始，因此需要記錄每個測試程式所使用的軟體版本號。

詳細的測試步驟（Detailed Steps Required to Run This Procedure）

本文包含了執行測試程式所需的步驟。測試程式中的步驟分為兩種型別：操作（actions）和驗證（verifications）。操作是指需要執行的任務，例如向系統提供輸入。驗證則是指檢查某些結果或輸出，以確認系統是否正常運作。

所有程式步驟都必須按順序編號，通常從1開始。驗證步驟之前應加上下劃線或方框符號，以便測試人員在完成步驟後進行核對。

簽核（Sign-off）

在測試程式的末尾，應提供空白行供測試人員、觀察員、客戶代表和管理人員簽署，以確認測試程式已成功完成。簽名和日期是最低要求。每個組織可以規定所需的簽名。

一般資訊（General）

軟體測試檔案的最後一節是一個通用區段，用於放置其他不適合放在其他區段的資訊。

檔案變更程式（Document Change Procedures）

許多組織都有固定的政策來變更測試程式檔案。例如，在進行正式變更之前，可能需要獲得客戶的批准。本文將概述變更軟體測試檔案的規則和必要的審批程式。

附錄和附件（Attachments and Appendixes）

將大型表格、影像和其他檔案直接附加到軟體測試檔案中是非常有用的，這樣讀者就可以隨時查閱這些資料，而不必依賴外部連結。

索引（Index）

如果需要，可以在軟體測試檔案的末尾新增索引。

範例：DAQ DIP開關專案的軟體測試程式

以下是一個簡化的軟體測試程式範例，用於DAQ DIP開關專案。

目錄

[省略]

簡介

本檔案描述了DAQ系統中DIP開關測試程式的一部分。

詞彙表、縮寫詞和縮略語

本文列出了檔案中使用的術語和縮寫詞的定義，例如DAQ（資料擷取系統）、SBC（單板電腦）等。

透過遵循上述，開發團隊可以建立完善的軟體測試檔案，確保軟體品質和可靠性。

軟體測試檔案規範與實務案例分析

軟體測試是確保產品品質的重要環節，透過系統化的測試流程，能有效檢測軟體中的缺陷與問題。本篇文章將探討軟體測試檔案的規範，並以DAQ系統的測試案例進行詳細說明。

軟體測試檔案的組成要素

完整的軟體測試檔案需包含以下主要部分：

  1. 測試計畫（Test Plan）：定義測試範圍、方法與資源組態。
  2. 測試案例（Test Cases）：具體描述測試步驟與預期結果。
  3. 測試程式（Test Procedures）：詳細說明如何執行測試案例。
  4. 測試報告（Test Reports）：記錄測試結果與發現的問題。

內容解密：

  • 測試檔案的結構需符合IEEE相關標準（如IEEE Std 829-2008）。
  • 每個測試案例應有明確的識別符號（如DAQ_STC_701_000_000）。
  • 測試步驟必須清晰且可執行。

DAQ系統測試案例分析

以DAQ系統的RS-232序列埠操作測試為例，說明具體的測試流程：

1. 測試目的

驗證DAQ系統透過RS-232介面接收命令的正確性。

2. 測試步驟

  1. 設定DIP開關1為ON並重啟Netburner。
  2. 使用序列終端機程式連線Netburner的COM1埠。
  3. 輸入help指令並驗證系統回應。

3. 預期結果

  • 系統正確回應help指令並顯示幫助訊息。
  • 當DIP開關1設為OFF時，系統忽略help指令。

4. 特殊需求

  • 需要NULL資料機線連線PC與Netburner。
  • 使用MTTY.exe或Hyperterm等終端機模擬程式。

內容解密：

  • 測試步驟需嚴格按照規定執行，並記錄任何異常情況。
  • 若發現軟體缺陷，需填寫異常報告並重新啟動測試。

乙太網路位址選擇測試

另一個重要測試案例是乙太網路IP位址的初始化驗證：

1. 測試目的

確認DIP開關5和6的設定正確影響乙太網路IP位址。

2. 測試步驟

  1. 設定DIP開關5和6為不同組合。
  2. 重啟Netburner並透過乙太網路連線。
  3. 驗證不同IP位址的連線成功與否。

3. 預期結果

  • DIP開關的不同設定對應正確的IP位址（例如192.168.2.70、192.168.2.71等）。

內容解密：

  • 使用Hercules.exe等乙太網路終端機程式進行連線測試。
  • 每個步驟需仔細驗證並記錄結果。

軟體測試檔案製作

軟體測試檔案的製作是軟體開發流程中的重要環節，本文將根據IEEE Std 829標準，介紹軟體測試計劃（STP）、測試程式和測試日誌的製作方法。

STP 檔案結構

STP 檔案是軟體測試的藍圖，主要內容包括測試範圍、測試方法、測試資源和測試進度等。以下是 STP 檔案的基本結構：

1. 簡介

  • 檔案識別碼
  • 範圍

2. 總體描述

  • 測試物件描述
  • 測試方法概述
  • 測試環境要求

3. 測試程式詳述

  • 各個測試程式的詳細步驟
  • 預期結果
  • 測試案例覆寫列表

4. 一般資訊

  • 檔案變更程式
  • 附錄和附屬檔案

編寫測試程式

測試程式是 STP 檔案的核心部分，詳細描述瞭如何執行測試。以下是編寫測試程式的關鍵步驟：

  1. 定義測試案例：根據需求和設計檔案，定義需要測試的功能點和案例。
  2. 描述測試步驟：詳細描述每個測試案例的執行步驟，包括輸入資料、預期結果和實際結果的比較。
  3. 記錄測試結果：在執行測試後，記錄實際結果，並與預期結果進行比較。
  4. 更新 RTM：將測試程式與需求和設計檔案進行追蹤，將 STP 標籤新增到 RTM 中。

更新 RTM 與 STP 資訊

RTM（需求追蹤矩陣）是用於追蹤需求與測試案例之間關係的工具。更新 RTM 的步驟如下：

  1. 提取 STP 標籤：從 STP 檔案中提取 STP 標籤。
  2. 填充 RTM：將 STP 標籤填充到 RTM 的對應欄位中。
  3. 排序 RTM：透過 STP 標籤對 RTM 進行排序，以便快速定位相關需求和測試案例。

編寫測試日誌

測試日誌用於記錄測試過程中的事件和異常，以下是編寫測試日誌的關鍵內容：

  1. 記錄測試開始和結束時間。
  2. 描述遇到的異常和缺陷。
  3. 記錄對測試程式的修改和理由。
  4. 記錄人員變更和休息時間。

測試日誌的結構

  1. 簡介

    • 檔案識別碼
    • 範圍

  2. 詳細資訊

    • 描述
    • 事件和活動記錄

  3. 一般資訊

    • 詞彙表
此圖示說明瞭軟體測試的主要流程，包括執行測試程式、記錄測試結果、更新 RTM 和編寫測試日誌等步驟。

軟體測試檔案的製作需要嚴格遵循相關標準和規範，透過詳細的規劃和執行，可以確保軟體產品的品質和可靠性。透過上述，可以有效地製作出符合 IEEE Std 829 標準的軟體測試檔案。

軟體測試檔案記錄之探討

軟體測試檔案記錄（Level Test Logs, LTL）是軟體測試過程中不可或缺的一部分，主要用於記錄測試執行的詳細過程和結果。根據IEEE Std 829標準，LTL檔案結構包含多個重要章節，以下將逐一深入分析其關鍵內容及實際應用考量。

詳細內容結構解析

描述章節

此章節為每個測試日誌唯一出現一次，主要描述適用於所有測試日誌條目的共同資訊，包括：

  • 測試物件的版本號識別
  • 測試程式在執行前的任何變更（如紅線標記）
  • 測試開始與結束的日期及時間
  • 執行測試人員的姓名
  • 測試中止的原因（如有）

活動與事件記錄

此部分記錄了測試程式執行過程中的每個事件，通常包含以下內容：

  • 測試程式執行的描述（程式ID/標籤）
  • 所有參與測試的人員及其角色，包括測試人員、支援人員和觀察員
  • 每次測試執行的結果（透過、失敗、評論）
  • 任何與測試程式的偏差記錄（如紅線標記）
  • 發現的缺陷或異常記錄，並附上相關的異常報告參考（如有生成）

實務應用與挑戰

在實際操作中，Std 829所建議的LTL檔案結構可能因其繁瑣而被簡化。例如，將測試日誌直接附加在測試計劃（STP）後，可以減少重複性工作量。這種做法使得測試日誌能夠沿用STP的前言資訊，從而簡化檔案製作流程。

值得注意的是，LTL存在多種變體，包括元件測試日誌、元件整合測試日誌、系統測試日誌和驗收測試日誌。其中，系統測試日誌和驗收測試日誌較為常見，因為它們通常由獨立於開發團隊的測試人員執行。

管理考量

大多數元件或元件整合測試因其自動化特性或由開發團隊頻繁執行而較少正式記錄。相反，系統測試和驗收測試因其重要性而需要詳細的日誌記錄。

動態檔案特性與記錄儲存

與其他靜態的Std 829檔案不同，測試日誌是一種動態檔案，每次測試執行都會產生不同的內容。因此，儲存所有測試日誌（包括失敗的測試）至關重要，因為它們提供了缺陷發現和修正的證據。

為何儲存所有測試日誌？

  • 提供完整的測試歷史記錄
  • 證明缺陷已被發現、修正並重新測試
  • 避免客戶對測試過程的質疑

若丟棄失敗的測試日誌，可能會引起客戶對測試真實性的懷疑。完整保留所有測試日誌，不僅展現了專業性，也增加了客戶對測試結果的信任度。

軟體測試檔案化中的測試日誌與異常報告

在軟體測試過程中，測試日誌（Test Log）與異常報告（Anomaly Report, AR）的檔案化是確保軟體品質與追蹤問題的重要環節。本篇文章將探討測試日誌的儲存、電子化與紙本化的議題，以及異常報告的撰寫與其在軟體開發過程中的重要性。

測試日誌的重要性與儲存

測試日誌記錄了測試執行的詳細過程，包括測試步驟、測試結果、以及任何在測試過程中發生的異常情況。這些日誌不僅是軟體測試是否合格的證明，也是未來維護與改進的參考依據。

  • 保留舊的測試日誌：即使測試過程中有紅線（redlines）或中斷，保留原始的測試日誌也是必要的。這證明瞭測試團隊已經盡到了品質保證的責任。
  • 無需保留舊的測試程式：如果測試程式在執行過程中被修改，只要相應的測試日誌中有記錄，就可以不必保留舊的測試程式。

測試日誌的電子化與紙本化

在數位時代，許多組織開始採用電子化的測試日誌，但仍有一些組織或客戶堅持使用紙本化的測試日誌。

電子化測試日誌的問題

電子化測試日誌容易被偽造，特別是當使用文書處理軟體而非專門的測試日誌應用程式時。雖然優秀的程式設計師不會偽造測試日誌，但仍有部分人會這樣做，從而損害了整個軟體工程師群體的聲譽。

紙本化測試日誌的優勢

紙本化的測試日誌更難被偽造，因為它們需要手寫記錄。客戶通常需要紙本的測試日誌，並期望這些日誌被妥善儲存，以滿足法律上的要求。

推薦解決方案

使用專門設計的軟體應用程式來建立和管理測試日誌，這些應用程式能夠自動將記錄存入資料函式庫，使資料更難被偽造。對於客戶，可以列印出資料函式庫中的報告，提供紙本或電子PDF版本。

異常報告（Anomaly Report, AR）

當發現軟體缺陷時，應當使用異常報告（AR）來正式記錄。AR捕捉了有關缺陷的重要資訊，包括發現日期、發現者、缺陷描述、以及重現缺陷的步驟。

AR的重要性

AR是追蹤系統缺陷的正式方式，對於維護系統品質至關重要。它確保了所有發現的問題都被妥善記錄和跟進，而不是僅憑口頭溝通就直接進行修改。

AR的內容

  • 發生日期和時間
  • 發現者或記錄者
  • 缺陷描述
  • 重現缺陷的步驟（如果問題是可重現的）
此圖示說明瞭軟體測試檔案化的流程
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 軟體測試檔案規範與實務

package "NumPy 陣列操作" {
    package "陣列建立" {
        component [ndarray] as arr
        component [zeros/ones] as init
        component [arange/linspace] as range
    }

    package "陣列操作" {
        component [索引切片] as slice
        component [形狀變換 reshape] as reshape
        component [堆疊 stack/concat] as stack
        component [廣播 broadcasting] as broadcast
    }

    package "數學運算" {
        component [元素運算] as element
        component [矩陣運算] as matrix
        component [統計函數] as stats
        component [線性代數] as linalg
    }
}

arr --> slice : 存取元素
arr --> reshape : 改變形狀
arr --> broadcast : 自動擴展
arr --> element : +, -, *, /
arr --> matrix : dot, matmul
arr --> stats : mean, std, sum
arr --> linalg : inv, eig, svd

note right of broadcast
  不同形狀陣列
  自動對齊運算
end note

@enduml

內容解密：

此圖示呈現了軟體測試的基本流程。首先，測試人員開始測試並建立測試日誌。然後，他們執行測試，如果發現缺陷，則建立異常報告並跟進修復。無論結果如何，最終都需要儲存測試日誌。這種流程確保了軟體測試的嚴謹性和可追溯性。

軟體測試檔案中的異常報告（Anomaly Reports）撰寫

軟體測試過程中，異常報告（Anomaly Reports）是記錄和管理缺陷的重要檔案。IEEE Std 829 提供了一套撰寫異常報告的標準格式和內容。本文將探討異常報告的結構、內容以及相關的最佳實踐。

異常報告的重要性

異常報告不僅記錄了測試過程中發現的缺陷，還提供了詳細的缺陷描述、影響評估、修復建議等資訊。這些資訊對於開發團隊快速定位和修復缺陷、測試團隊驗證修復結果以及專案管理者評估專案風險和進度至關重要。

異常報告的結構

根據 IEEE Std 829，異常報告通常包含以下幾個主要部分：

  1. 簡介（Introduction）

    • 檔案識別碼（Document Identifier）：為異常報告分配一個唯一的識別碼，以便於其他檔案（如測試日誌和測試報告）參考。
    • 範圍（Scope）：簡要描述異常報告中未涵蓋的其他內容。

  2. 詳細資訊（Details）

    • 摘要（Summary）：簡要描述異常的概況。
    • 發現日期（Date Anomaly Discovered）：記錄異常被發現的日期和時間（如果適用）。
    • 上下文（Context）：提供軟體版本、安裝/組態資訊，以及相關的測試程式和測試日誌參考。
    • 異常描述（Description of Anomaly）：詳細描述缺陷，包括重現步驟、輸入、實際結果、預期結果等。
    • 影響（Impact）：評估缺陷對系統使用者的影響，並提出可能的變通方法。
    • 緊急程度評估（Originator’s Assessment of Urgency）：根據缺陷的嚴重性和風險評估，提出修復的緊急程度。
    • 修復措施描述（Description of Corrective Action）：估計修復缺陷所需時間、成本和風險，並規劃必要的迴歸測試。
    • 狀態（Status of the Anomaly）：記錄缺陷的當前狀態，如「開啟」、「已分配修復」、「已修復」等。
    • 結論和建議（Conclusions and Recommendations）：分析缺陷發生的原因，並提出改進開發流程的建議，以及新增測試案例的建議。

  3. 一般資訊（General）

    • 檔案變更程式和歷史（Document Change Procedures and History）：記錄異常報告格式的變更歷史和變更程式。

程式碼範例與解析

def generate_anomaly_report(anomaly_details):
    report = {
        "document_identifier": "AR-001",
        "scope": "描述異常報告的範圍",
        "references": ["測試日誌-001", "測試程式-001"],
        "summary": anomaly_details["summary"],
        "date_discovered": anomaly_details["date_discovered"],
        "context": anomaly_details["context"],
        "description": anomaly_details["description"],
        "impact": anomaly_details["impact"],
        "urgency_assessment": anomaly_details["urgency_assessment"],
        "corrective_action": anomaly_details["corrective_action"],
        "status": "open",
        "conclusions_and_recommendations": anomaly_details["conclusions_and_recommendations"]
    }
    return report

# 使用範例
anomaly_details = {
    "summary": "系統在特定輸入下當機",
    "date_discovered": "2023-04-01",
    "context": "軟體版本 1.0，Windows 10 環境",
    "description": "當輸入特定引數時，系統出現當機。",
    "impact": "高，影響使用者經驗",
    "urgency_assessment": "高",
    "corrective_action": "修復相關程式碼，並進行迴歸測試",
    "conclusions_and_recommendations": "建議增加相關測試案例以預防類別似問題"
}

report = generate_anomaly_report(anomaly_details)
print(report)

內容解密：

  1. generate_anomaly_report 函式：此函式用於生成異常報告的結構化資料。它接受一個包含異常詳細資訊的字典 anomaly_details 作為輸入，並傳回一個按照 IEEE Std 829 標準格式組織的異常報告字典。
  2. report 字典：字典中包含了異常報告各個部分所需的資訊，如檔案識別碼、範圍、摘要、發現日期、上下文、描述、影響、緊急程度評估、修復措施描述、狀態以及結論和建議等欄位。
  3. anomaly_details 字典：這是一個範例輸入，包含了特定異常的詳細資訊。在實際應用中，這些資訊將由測試人員根據實際發現的缺陷填寫。
  4. 輸出結果：函式傳回一個結構化的異常報告，可以進一步轉換為所需的格式（如 PDF 或 HTML）進行儲存或分發。
玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。