軟體測試檔案是軟體開發生命週期中不可或缺的一部分，用於指導測試過程、記錄測試結果，並確保軟體品質。良好的測試檔案可以減少溝通成本、提高測試效率，並降低錯誤風險。本文從軟體測試案例（STC）檔案的結構開始，逐步探討其內容、實務案例以及程式碼解析，並進一步說明軟體測試程式（STP）的規範與應用，最後提供一些軟體測試檔案的最佳實踐和未來展望。對於測試案例的撰寫，本文以 DAQ 系統的 DIP 開關測試為例，詳細說明瞭測試目標、輸入、預期結果和環境需求等關鍵要素。此外，也提供了 Python 程式碼範例，展示如何模擬 DIP 開關設定和串列終端機命令輸入，並驗證預期輸出。針對 DAQ 系統的命令測試，本文分析了不同 DIP 開關組態下，透過 RS-232 和乙太網路連線的命令接受和拒絕行為，並提供了 Python 程式碼示例，演示如何建立 TCP 連線並與 DAQ 系統進行通訊。
此圖示
@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
內容解密：
- 此圖示展示了軟體開發、軟體測試和軟體測試檔案之間的關係。
- 軟體開發是整個流程的起點，軟體測試是確保軟體品質的重要步驟。
- 軟體測試檔案包含了測試案例、測試步驟和預期結果等重要資訊。
- 這些資訊對於確保軟體產品符合需求規格和達到預期的品質標準至關重要。
軟體測試檔案規範與實務案例解析
軟體測試檔案的撰寫是確保軟體品質的重要環節，本文將探討軟體測試案例（STC）檔案的結構、內容以及實際案例的應用。
軟體測試檔案的重要性
軟體測試檔案用於描述測試案例（輸入和預期結果），以驗證軟體是否正確執行。根據IEEE Std 829-2009標準，軟體測試案例檔案應包含詳細的測試案例描述，以確保軟體符合各項設計需求和要求。
軟體測試案例檔案的結構
一份完整的軟體測試案例檔案通常包含以下幾個部分：
檔案標識與變更歷史
- 包含檔案的唯一識別符號、版本號、變更描述、作者及其角色。
- 版本號應順序編號，第一個批准版本為起始點。
範圍
- 描述該檔案涵蓋的測試範圍，例如針對DAQ系統的DIP開關測試。
術語表、縮寫與簡稱
- 列出檔案中使用的專業術語和縮寫，以避免混淆。
參考文獻
- 列出相關的參考檔案，例如IEEE標準或其他技術檔案。
背景
- 描述測試物件的背景資訊，例如DAQ系統的設計目的和應用場景。
符號表示法
- 說明檔案中使用的識別符號規則，例如測試案例的命名規則。
實務案例：DAQ系統DIP開關測試
檔案標識與變更歷史
- 日期：2018年3月22日
- 檔案版本：DAQ_STC v1.0
- 作者：Randall Hyde
範圍
本檔案僅描述DAQ系統中DIP開關的測試案例。
術語表、縮寫與簡稱
- DAQ：資料採集系統
- SBC：單板電腦
- SDD：軟體設計描述
- SRS：軟體需求規範
- SyRS：系統需求規範
- STC：軟體測試案例
- STP：軟體測試程式
參考文獻
- IEEE Std 830-1998：SRS檔案標準
- IEEE Std 829-2008：STP檔案標準
- IEEE Std 1012-1998：軟體驗證和確認標準
背景
Plantation Productions公司的DAQ系統是一種開放硬體和開源設計的資料採集和控制系統，特別適用於安全關鍵系統，如核能研究反應堆積。
符號表示法
測試案例識別符號採用DAQ_STC_xxx_yyy_zzz格式，其中xxx_yyy來自對應的需求編號，zzz用於建立唯一的識別符號。
測試案例詳述
DAQ_STC_701_000_000
目標：測試透過RS-232的命令接受度。 輸入：
- 將DIP開關1設定為ON位置。
- 在串列終端機上輸入
help命令。 預期結果： - 畫面顯示幫助訊息。 環境需求：
- 硬體：正常啟動的DAQ系統，連線到DAQ的PC（含RS-232埠）
- 軟體：最新版本的DAQ韌體，已安裝串列終端模擬程式。
程式碼解析
def test_daq_dip_switch():
# 設定DIP開關1為ON
dip_switch_1 = True
# 模擬在串列終端機輸入help命令
command = "help"
# 檢查預期結果
if dip_switch_1 and command == "help":
# 預期結果：顯示幫助訊息
expected_output = "幫助訊息"
assert expected_output == get_output_from_terminal()
#### 內容解密：
1. **`dip_switch_1 = True`**：此行程式碼模擬將DIP開關1設定為ON的狀態，用於後續測試條件判斷。
2. **`command = "help"`**：此處定義了在串列終端機上輸入的命令，為了測試DAQ系統是否正確回應`help`命令。
3. **`if dip_switch_1 and command == "help"`**：此條件判斷用於檢查DIP開關1是否為ON以及輸入的命令是否為`help`。只有當兩個條件都滿足時，才進行預期結果的檢查。
4. **`expected_output = "幫助訊息"`**：定義了預期的輸出結果，即畫面應顯示的幫助訊息。
5. **`assert expected_output == get_output_from_terminal()`**：此斷言陳述式用於驗證實際輸出是否與預期輸出一致，確保DAQ系統正確執行了`help`命令。
## 資料擷取系統（DAQ）命令測試案例分析
DAQ系統的命令測試涉及多個不同的測試案例，這些案例主要關注於驗證DAQ系統在不同組態和連線方式下的命令接受和拒絕行為。本文將對DAQ_STC_702_000_000至DAQ_STC_726_000_000等測試案例進行詳細分析。
### 測試案例概述
這些測試案例主要分為兩大類別：
1. **透過RS-232埠的命令測試**：這類別測試主要驗證DAQ系統在RS-232埠上的命令接受和拒絕行為。
2. **透過乙太網路連線的命令測試**：這類別測試主要驗證DAQ系統在乙太網路連線下的命令接受行為。
### RS-232埠命令測試
#### DAQ_STC_702_000_000：測試DIP開關1開啟時的命令接受
* **目標**：驗證當DIP開關1設為ON時，DAQ系統是否能正確接受命令。
* **輸入**：DIP開關1設為ON，並在序列終端機上輸入`help`命令。
* **預期結果**：螢幕顯示幫助訊息。
* **環境需求**：運作中的DAQ系統、具有RS-232埠的PC、最新版本的DAQ韌體、序列終端模擬程式。
#### DAQ_STC_703_000_000：測試DIP開關1關閉時的命令拒絕
* **目標**：驗證當DIP開關1設為OFF時，DAQ系統是否會拒絕命令。
* **輸入**：DIP開關1設為OFF，並在序列終端機上輸入`help`命令。
* **預期結果**：系統忽略命令，無回應。
* **環境需求**：與DAQ_STC_702_000_000相同。
### 乙太網路連線命令測試
#### DAQ_STC_709_000_000至DAQ_STC_712_000_000：測試不同DIP開關組態下的乙太網路位址
* **目標**：驗證在不同DIP開關組態下，DAQ系統的乙太網路連線和命令接受行為。
* **輸入**：根據不同的測試案例，設定DIP開關3、5、6的不同組合，並使用乙太網路終端程式連線到指定的IP地址和埠，發出`help`命令。
* **預期結果**：乙太網路終端連線到DAQ系統，並顯示幫助訊息。
* **環境需求**：運作中的DAQ系統、具有乙太網路埠的PC、最新版本的DAQ韌體、乙太網路終端模擬程式。
### 關鍵觀察與分析
* 這些測試案例表明，DAQ系統的命令接受和拒絕行為與DIP開關的組態密切相關。
* RS-232埠和乙太網路連線的測試結果表明，DAQ系統在不同連線方式下都能正確地接受和處理命令。
* 這些測試案例對於確保DAQ系統在不同組態和環境下的可靠性和正確性具有重要意義。
##### 程式碼實作與解析
```python
import socket
def connect_to_daq(ip_address, port):
try:
# 建立socket物件
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 連線到DAQ系統
client_socket.connect((ip_address, port))
# 傳送help命令
client_socket.sendall(b'help\n')
# 接收回應
response = client_socket.recv(1024).decode('utf-8')
# 關閉socket連線
client_socket.close()
return response
except Exception as e:
return f"連線失敗: {str(e)}"
# 測試連線到DAQ系統
ip_address = '192.168.2.70'
port = 20560
response = connect_to_daq(ip_address, port)
print(response)
內容解密：
connect_to_daq函式：此函式負責建立到DAQ系統的乙太網路連線，並傳送help命令以接收回應。socket.socket(socket.AF_INET, socket.SOCK_STREAM)：建立一個TCP socket物件，用於與DAQ系統建立連線。client_socket.connect((ip_address, port))：使用指定的IP地址和埠號連線到DAQ系統。client_socket.sendall(b'help\n')：透過已建立的連線傳送help命令到DAQ系統。client_socket.recv(1024).decode('utf-8')：接收DAQ系統對help命令的回應，並將其解碼為UTF-8格式的字串。client_socket.close()：完成通訊後關閉socket連線，釋放資源。
程式邏輯與技術考量
- 此程式碼實作了一個簡單的TCP客戶端，用於與DAQ系統建立乙太網路連線並交換資料。
- 使用Python的
socket函式庫進行低階的網路通訊操作，展現了對乙太網路通訊的基本理解和應用能力。 - 程式碼中包含基本的錯誤處理，能夠捕捉並報告連線過程中的異常情況。
軟體測試檔案規範與實務應用
軟體測試檔案的撰寫是確保軟體品質的重要環節，特別是在複雜的系統開發過程中。本文將探討軟體測試案例檔案（Software Test Case, STC）與軟體測試程式檔案（Software Test Procedure, STP）的規範及其在實際測試工作中的應用。
軟體測試案例檔案的變更程式
在進行軟體測試案例檔案的修改時，變更者必須在檔案的1.1節中新增變更記錄，至少包含日期、檔案ID（DAQ_STC）、版本號碼以及變更者的資訊。這樣的記錄方式有助於追蹤檔案的變更歷史，確保檔案的可追溯性。
將STC資訊更新至需求追蹤矩陣（RTM）
由於軟體審查和軟體測試案例的驗證方法是互斥的，因此在RTM中只需要一個欄位來關聯這些物件的標籤。在DAQ系統的RTM中，這個欄位被標記為「軟體測試/審查案例」。當同時新增DAQ_SR_xxx_yyy_zzz和DAQ_STC_xxx_yyy_zzz專案到這個欄位時，由於標籤格式明確區分了驗證型別，因此不會產生歧義。
內容解密：
- 需求追蹤矩陣（RTM）的重要性：RTM用於追蹤需求與測試案例之間的關聯，確保每個需求都有對應的測試案例進行驗證。
- 標籤格式的設計：標籤格式如DAQ_STC_xxx_yyy_zzz，其中各部分的意義需要根據實際專案進行定義，以確保標籤的可讀性和唯一性。
- 更新RTM的步驟：首先定位到具有特定標籤（如DAQ_SRS_xxx_yyy）的需求，然後在同一行中將STC標籤新增到適當的欄位。
軟體測試程式檔案的規範與應用
軟體測試程式檔案（STP）定義了執行一組測試案例的步驟，用於評估軟體系統的品質。STP並非強制性檔案，但它可以簡化測試流程，因為多個測試案例可能具有相同的輸入或輸出條件。
為什麼需要STP？
- 提高測試效率：透過合併具有相同輸入或輸出條件的測試案例，可以減少重複的測試步驟。
- 簡化測試環境設定：多個測試案例可能需要相同的測試環境設定，將這些案例合併到一個STP中可以避免重複設定。
- 滿足測試案例之間的依賴關係：某些測試案例需要按照特定的順序執行，STP可以確保這種依賴關係得到滿足。
IEEE Std 829-2009軟體測試程式檔案的結構
根據IEEE Std 829-2009標準，STP的檔案結構如下：
簡介
- 1.1 檔案識別符
- 1.2 範圍
- 1.3 參考文獻
- 1.4 與其他檔案的關係
詳細資訊
- 2.1 輸入、輸出和特殊需求
- 2.2 執行測試案例的步驟描述
一般資訊
- 3.1 詞彙表
- 3.2 檔案變更程式和歷史記錄
內容解密：
- STP的層級：STP有多個層級，包括單元測試程式（UTP）、整合測試程式（ITP）、系統測試程式（SITP）和驗收測試程式（ATP）。
- STP的自動化：UTP和ITP通常可以自動化執行，以提高測試效率。
- STP之間的關係：SITP和ATP通常源自STC，且ATP可能是SITP的子集，根據客戶或終端使用者的需求進行調整。
軟體測試檔案：STP 詳細
軟體測試程式（STP）是軟體測試過程中不可或缺的檔案，用於詳細描述測試的步驟、需求和相關的測試案例。本文將根據 IEEE 829 標準，詳細闡述 STP 的結構和內容，並提出改進建議。
STP 的重要性與結構
IEEE 829 標準為 STP 提供了一個基本的框架，但實際應用中需要根據具體專案需求進行調整和擴充套件。一個完整的 STP 應該包含以下幾個主要部分：
目錄
簡介
- 檔案標識與變更歷史
- 範圍
- 詞彙、縮寫與簡稱
- 參考文獻
- 描述符號
- 測試執行（新增）
測試程式
- 簡要描述
- 程式標識（Tag）
- 目的
- 涵蓋的測試案例列表
- 特別需求
- 執行前的設定需求
- 軟體版本號
- 詳細執行步驟
- 測試程式的簽核
通用部分
- 檔案變更程式
- 附錄和附件
索引
對 IEEE 829 標準的擴充套件
為了提高 STP 的實用性和可追溯性，我們對 IEEE 829 標準進行了擴充套件，主要包括：
- 描述符號（Notation for Descriptions）：定義測試程式標識（Tag）的格式，例如
proj_STP_xxx，其中proj是專案特定的 ID，而xxx是唯一的數字序列。 - 測試程式標識（Procedure Identification）：在每個測試程式中明確標識其對應的測試案例，以實作對測試案例的可追溯性。
- 特別需求（Special Requirements）：列出執行測試程式所需的特殊條件或資源，如特定的硬體裝置或軟體版本。
- 執行前的設定需求（Setup Required Prior to Running Procedure）：詳細描述在執行測試程式之前需要進行的準備工作。
STP 簡介部分的詳細內容
檔案標識與變更歷史
檔案標識應該是組織內部唯一的，通常包括專案名稱、檔案型別、建立/修改日期、版本號和作者資訊。變更歷史則記錄了檔案的每次修訂資訊。
範圍
與 STC（軟體測試案例檔案）的範圍定義類別似，STP 的範圍描述了該檔案的適用範圍及其與其他測試檔案的關係。通常可以參考 STC 中的範圍定義。
參考文獻
列出與 STP 相關的外部檔案，如 STC 和其他相關的測試檔案。如果系統龐大且包含多個獨立的應用程式，則可能需要為每個應用程式建立獨立的 STP，並在參考文獻中列出其他相關的 STP。
此圖示說明瞭軟體測試程式（STP）的主要結構和組成部分，包括簡介、測試程式和通用部分等。
軟體測試檔案的最佳實踐
在編寫和維護軟體測試檔案（如 STP）時，應遵循以下最佳實踐：
- 保持檔案的更新和一致性：隨著軟體的變更，及時更新相關的測試檔案，確保它們始終保持最新狀態並與其他檔案保持一致。
- 提高檔案的可讀性和可理解性：使用清晰簡潔的語言，避免過於技術性的術語，確保檔案易於被團隊成員理解。
- 加強檔案的可追溯性：透過使用明確的識別符號和交叉參照，提高測試檔案之間以及與其他開發檔案之間的追溯能力。
- 採用適當的工具和技術：利用現代化的檔案管理工具和技術，如版本控制系統，來提高檔案的管理效率和準確性。
詳細分析：
- 上述Plantuml圖表呈現了STP的主要結構，包括簡介、測試程式和通用部分，有助於快速理解STP的整體框架。
- 在STP中加入描述符號、特別需求等擴充套件內容，增強了檔案的可讀性和可操作性。
- 重視檔案的更新、一致性和可追溯性，有助於提升團隊的工作效率和軟體產品的品質。
程式碼範例：
def generate_stp_tag(project_id, sequence_number):
"""
生成STP Tag
:param project_id: 專案ID
:param sequence_number: 序列號
:return: STP Tag
"""
return f"{project_id}_STP_{sequence_number}"
# 示例用法
project_id = "DAQ"
sequence_number = "001"
stp_tag = generate_stp_tag(project_id, sequence_number)
print(stp_tag) # 輸出: DAQ_STP_001
內容解密：
此Python函式generate_stp_tag用於生成符合特定格式的STP Tag。函式接受兩個引數：project_id（專案ID）和sequence_number（序列號），並傳回格式化的STP Tag字串。透過這種方式，可以自動化生成具有唯一性的STP Tag，提高工作效率並減少錯誤。
def create_test_procedure(description, tag, purpose, test_cases, special_requirements, setup_required, software_version):
"""
建立測試程式
:param description: 簡要描述
:param tag: 程式標識（Tag）
:param purpose: 目的
:param test_cases: 涵蓋的測試案例列表
:param special_requirements: 特別需求
:param setup_required: 執行前的設定需求
:param software_version: 軟體版本號
:return: 測試程式字典
"""
test_procedure = {
"description": description,
"tag": tag,
"purpose": purpose,
"test_cases": test_cases,
"special_requirements": special_requirements,
"setup_required": setup_required,
"software_version": software_version,
"steps": [] # 用於存放詳細執行步驟
}
return test_procedure
# 示例用法
test_procedure = create_test_procedure(
description="簡要描述",
tag="DAQ_STP_001",
purpose="測試目的",
test_cases=["TC001", "TC002"],
special_requirements="特殊硬體需求",
setup_required="環境設定需求",
software_version="v1.0"
)
print(test_procedure)
內容解密：
此Python函式create_test_procedure用於建立一個包含必要資訊的測試程式字典。該函式接受多個引數，包括簡要描述、程式標識、目的、涵蓋的測試案例列表、特別需求、執行前的設定需求和軟體版本號，並傳回一個結構化的測試程式字典。這種方法有助於系統化地組織和管理測試程式，提高測試工作的效率和可維護性。
隨著軟體開發技術的不斷進步，軟體測試領域也在不斷演化。未來，我們可以期待以下幾個趨勢：
- 自動化測試的進一步普及：自動化測試將在更多的專案中得到應用，從而提高測試效率，降低人力成本。
- 人工智慧在測試領域的應用：人工智慧技術將被用於最佳化測試案例生成、自動化錯誤檢測等方面，進一步提高軟體品質。
- DevOps與持續整合/持續佈署（CI/CD）的緊密結合：軟體測試將更加緊密地與開發流程整合，透過自動化的CI/CD管道實作快速反饋和持續改進。
透過把握這些趨勢，軟體開發團隊可以更好地應對未來挑戰，提升軟體產品的品質和競爭力。