07 BDD 規格案例

5 份 feature · 37 個情境 · 47 個展開例子。Gherkin 語法檢查通過，業務驗收尚未執行。

主要讀者：平台維護者、開發人員、QA 與需求確認者。

1 先討論行為，再決定如何實作

這份規格以 E2E 測試平台的業務能力為主軸，描述「誰在什麼條件下做什麼，以及應看到什麼結果」。Crystal、Northstar 與 Sentry 的 API 和程式碼用來理解現有能力與限制；情境不與個別 API 或程式方法一對一對應。自動化實作日後再決定如何呼叫服務、準備資料及取得結果。

每個情境都是可一起討論的具體例子。範例名稱、數量與排程中的「凌晨兩點」都是說明用資料，不代表正式排程時間或既有資料。

目前是行為規格，尚未連接自動化步驟，也未執行業務驗收。 「現有行為」表示依已核對的實作與規格整理，不表示已在實際環境測試通過。

原需求與驗收範圍見業務流程與UAT 文件。HTML 由這些 .feature 原檔產生，修改情境後重新建置即可同步閱讀版。

Cucumber 建議使用領域語言描述行為，避免把情境寫成操作畫面或內部實作的指令清單。官方寫作建議

本版採用以下約定：

例如「人工重跑保留原結果」可以這樣讀：

Scenario: 重跑計畫保留原結果
  Given 原執行已有失敗結果，且沒有其他工作正在執行
  When 維護者重跑原測試計畫
  Then 平台應建立另一筆執行紀錄
  And 原本的案例結果應仍可查閱

一個情境聚焦一條規則，每句只放一個主要意思。先寫必要前提，再寫一個觸發事件，最後寫可觀察的結果。不要把建立專案、安排排程、執行測試、下載報告全部塞進同一情境。各情境獨立準備資料，不依賴另一情境先跑完。

本目錄涵蓋專案與環境設定、案例維護、計畫與排程、測試執行與重跑、結果與產物。使用者儲存案例、查閱結果或提出重跑要求，是平台接受的業務動作；情境驗證平台如何回應。

日夜環境啟閉、固定時間強制關閉、停機恢復與補跑處置、隔日追查，均由維運人員負責，排除於本 BDD 範圍。即使維運工作採用自動化，也不因此納入產品 BDD。相關政策與處置保留在故障排除手冊。人工除錯、協調修正與核定流程也不寫成 BDD 步驟。

「環境設定」指平台內供測試選用的設定；「排程」指測試計畫的執行安排，兩者都不包含實際環境的啟停維運。

用語	在這份文件中的意思
專案	用來整理相關案例、計畫與設定的範圍
環境設定	案例執行時使用的設定；儲存設定不代表實際環境已啟用
專案共用設定	同一專案內共同使用的測試設定
測試案例	一項要驗證的行為，包含所需步驟與預期結果
步驟	案例中的一項作業或檢查
測試計畫	本次要執行的案例集合；一般案例與準備資料的作業分開理解
排程	計畫的執行時間、環境與通知安排
一次執行／執行紀錄	某次實際測試及其進度與結果；重跑會另有紀錄
已完成	執行流程已結束，不保證所有案例通過
通過	案例或步驟的檢查符合預期
測試產物	執行留下的結果檔案等可下載內容
報告寄送	將結果通知收件人；寄送失敗不應改變已保存的測試結果

標籤只表示需求狀態，不是測試通過的證據。特別注意以下差異：

主題	現況與目標的區別
忙碌時的新工作	現有手動執行會在平台已有測試工作時拒絕新要求；「同環境的新工作保留並等待」是待達成需求，不能視為目前已提供
比對兩份查詢結果	儲存後能完整還原比對設定仍有已知差異，需要修正與驗證
前置資料與相依案例	必要準備失敗時停止、只依本次結果判斷相依條件，都屬待達成需求
空計畫	應讓使用者看出沒有執行案例，避免誤認為全部通過
維護權限	拒絕未授權的重跑要求是待驗證的產品行為

以上目標仍需實際驗證，不能因文件有寫就視為已完成。

每個檔案以 # language: en 開頭，使用標準英文 Gherkin 關鍵字；標題、條件、動作、結果與例子資料保留繁體中文。原檔及 HTML 都使用相同關鍵字。語法採 Given、When、Then 的標準大小寫。Gherkin 官方參考

本文件採兩個空白縮排、半形冒號，每個情境維持三至五個步驟。同一規則才使用例子表；不把不同行為硬塞進同一張表。Gherkin 官方參考

檢查程式使用官方解析器展開例子，並檢查語系、識別碼、標籤、前提／事件／結果及常見實作詞彙。詞彙檢查只是輔助，不能證明業務規則正確，也不能取代需求討論。結果見 BDD 檢查紀錄。

建置方式與所需工具見閱讀版維護說明。後續若接上自動化，應由步驟實作負責技術對應，保留這一層讓業務、QA 與開發人員共同閱讀。