題目與適用場景
一個 Go 服務的單元、基準和 fuzz 測試偶發失敗。開發者希望保存請求樣本、效能摘要和除錯傾印，但不能讓成功測試污染 CI，也不能讓並行測試互相覆蓋。請基於 Go 1.26 testing.T.ArtifactDir、testing.B.ArtifactDir 和 testing.F.ArtifactDir 設計一套產物策略。
Go 1.26 的 ArtifactDir 在啟用 go test -artifacts 時返回輸出目錄下的持久目錄；未啟用時返回測試結束後會刪除的暫存目錄。設計必須把「寫入程式碼」和「是否保留」分開，並尊重測試框架對目錄位置與生命週期的控制。
背景與邊界
本題聚焦 Go 測試程式碼、並行隔離、CI 歸檔和敏感資訊。CI 平台的 artifact 上傳、權限、保留週期和物件儲存由外部系統提供；候選人應明確失敗判定、檔案命名、大小上限、脫敏和重試邊界。
面試官考察點
- 能否正確區分 T、B、F 三種測試上下文的產物目錄。
- 能否在測試失敗時保留證據，同時不把成功執行的暫存檔變成永久噪音。
- 能否處理
t.Parallel、子測試、基準迴圈和 fuzz 重播的並發命名。 - 能否設計可重試、限大小、可歸檔、可定位到提交和測試名稱的檔案格式。
- 能否防止 token、使用者資料、私有 URL 和核心傾印進入公共 CI artifact。
30 秒回答框架
「我會讓測試始終透過 ArtifactDir 取得目錄，並按測試名、執行 ID 和事件序號產生檔名，不自行猜測工作區路徑。預設只在失敗、超過閾值或明確診斷模式寫入關鍵產物；go test -artifacts 的 CI 任務才保留目錄，本地預設讓暫存目錄自動清理。寫入使用暫存檔加 rename，設定大小和數量上限，提交前脫敏並產生 manifest。CI 歸檔以提交、套件、測試和平台中繼資料關聯，上傳失敗不覆蓋原始測試結果。」
分步驟深入解答
- 統一產物入口。 測試函式接收
testing.T、testing.B或*testing.F，呼叫對應的ArtifactDir。不要把os.TempDir、目前工作目錄或 CI 私有路徑硬編碼到測試邏輯中。
- 區分保留策略。 測試程式碼可以在失敗前後都寫入，但僅在
go test -artifacts啟用時期待目錄持久化。預設執行返回暫存目錄，測試結束會清理；CI 任務明確開啟 artifacts，再於歸檔步驟上傳。
- 設計並發命名。 使用測試套件、測試名稱、執行 ID、子測試路徑和單調序號構成邏輯鍵；檔名還要清理路徑分隔符和不可列印字元。
t.Parallel的不同實例不能共享固定debug.json。
- 原子寫入與上限。 先寫同目錄暫存檔，fsync 或關閉成功後再 rename。對單檔、單測試和整個執行設定位元組與數量上限；超限時寫一條摘要，不能因診斷產物拖垮測試機。
func writeArtifact(t *testing.T, name string, data []byte) {
t.Helper()
dir := t.ArtifactDir()
path := filepath.Join(dir, safeName(name)+".json")
tmp, err := os.CreateTemp(dir, ".partial-")
if err != nil { t.Fatalf("create artifact: %v", err) }
defer tmp.Close()
if _, err := tmp.Write(data); err != nil { t.Fatalf("write artifact: %v", err) }
if err := tmp.Close(); err != nil { t.Fatalf("close artifact: %v", err) }
if err := os.Rename(tmp.Name(), path); err != nil { t.Fatalf("publish artifact: %v", err) }
}範例省略大小檢查、脫敏和跨平台檔名處理；生產實作應讓這些約束成為共享測試約定。
- 失敗與閾值觸發。 失敗測試保存最小重現輸入、請求摘要、trace 標識和環境摘要。基準測試只在回歸超過閾值時保存 profile 或樣本；fuzz 測試保存可重播的 seed 和裁剪後輸入，不上傳完整敏感請求。
- CI 歸檔與索引。 產生 manifest，記錄提交 SHA、套件、測試名、Go 版本、OS/架構、產物相對路徑、大小、雜湊和脫敏狀態。上傳按執行 ID 隔離，歸檔失敗要告警但不能把測試誤報為通過。
- 安全和清理。 寫入前移除 token、Cookie、Authorization、個人資料和私有主機名；核心傾印預設關閉。歸檔系統使用最小讀取權限和短保留期，過期自動刪除。開發者下載前仍需檢查內容級別。
- 可測試性。 用一個失敗子測試、一個並行子測試、一個
go test -artifacts執行和一個預設執行驗證生命週期。檢查成功測試是否清理、失敗產物是否可索引、重試是否產生不同執行 ID，以及上傳中斷是否保留本地證據。
高品質示範回答
我會讓所有診斷檔案從 T、B、F 的 ArtifactDir 建立，測試邏輯不關心實際路徑。目錄是否持久化由 go test -artifacts 決定：CI 開啟並歸檔，本地預設使用暫存目錄自動清理。檔名使用套件、測試、子測試路徑、執行 ID 和序號，避免並行覆蓋；寫入使用暫存檔後 rename，並限制大小與數量。
失敗測試保存最小輸入、請求摘要和環境資訊，基準只在回歸閾值觸發時保留 profile，fuzz 保存 seed 和可重播輸入。所有內容先脫敏，manifest 記錄提交、Go 版本、平台、雜湊和檔案大小。上傳失敗只觸發告警，不能改變測試結果。回歸測試覆蓋並行、失敗、預設暫存目錄和 -artifacts 持久目錄，確認成功執行沒有長期噪音。
常見錯誤
- 錯誤表現： 把 ArtifactDir 當成永久目錄 → 失敗原因： 預設執行返回的暫存目錄會在測試結束後清理 → 修正方法： 在 CI 明確使用
-artifacts並配置歸檔。 - 錯誤表現： 所有並行測試寫
debug.json→ 失敗原因： 檔案覆蓋或內容交錯 → 修正方法： 使用測試路徑、執行 ID 和序號命名。 - 錯誤表現： 失敗時把完整 HTTP 請求上傳 → 失敗原因： token 和個人資料洩露 → 修正方法： 脫敏、摘要化和限制保留範圍。
- 錯誤表現： 診斷寫入失敗就讓測試通過 → 失敗原因： 丟失失敗證據並掩蓋環境問題 → 修正方法： 關鍵產物寫入失敗應失敗或明確告警，不能改變斷言結果。
- 錯誤表現： 每次基準迭代都寫 profile → 失敗原因： 產物數量和執行時間失控 → 修正方法： 僅在閾值回歸或明確診斷模式採集。
追問及應對
為什麼不直接使用 os.TempDir？
ArtifactDir 讓測試框架和 CI 決定目錄生命週期，統一支援 T、B、F，並避免測試程式碼依賴執行器路徑。os.TempDir 仍可用於不需要歸檔的輔助檔案，但不應成為測試產物協定。
fuzz 產物如何保證可重播？
記錄 Go 版本、套件、測試名、seed、裁剪後輸入雜湊和必要環境變數。輸入過大或含敏感資料時保存脫敏摘要，並保留內部安全儲存中的完整證據。
基準測試何時寫產物？
先完成基準並比較基線，只在回歸超過預設閾值、明確 -bench 診斷或失敗時寫 profile。產物應帶樣本數量、CPU、執行時間和 commit，避免每次正常執行都歸檔。
上傳 artifact 失敗是否讓 CI 失敗？
測試斷言失敗必須失敗；上傳失敗應按團隊的證據等級決定是否阻斷發布，但至少要告警並保留本地路徑。不要把網路上傳狀態偽裝成測試結果。
如何處理重複執行？
每次執行產生獨立 run ID，歸檔鍵包含提交、平台、套件、測試和嘗試次數。索引可合併展示，但原始檔案不可互相覆蓋；重試需要標明是否使用相同隨機種子。
參考資料
- Go 1.26 Release Notes（Go 官方）
- testing package（Go 官方）
- Go Release History（Go 官方）
面試作答要點
先說明 ArtifactDir 的生命週期，再補並行命名、原子寫入、失敗觸發、manifest、脫敏、CI 歸檔和回歸測試。
一句話總結
ArtifactDir 解決的是測試產物的生命週期入口，可靠診斷還需要隔離、限額、脫敏、索引和可重播證據。
繼續練習
如果 CI 同時執行 fuzz、基準和整合測試，請設計統一 manifest、配額和按失敗優先級上傳的調度策略。