客戶回報軟體錯誤要附什麼？整理重現步驟與環境資訊

整理軟體缺陷回報所需的發生時間、重現步驟、裝置與版本、預期與實際結果、個資遮蔽和工程追蹤方式，讓交接資料更容易重現與核對。

客服收到「某功能好像壞了」時，最有用的不是先猜原因，而是整理出工程人員可以照著重做、逐項核對的資料。本文聚焦在缺陷回報包：發生時間、操作步驟、環境版本、預期與實際差異，以及可安全交接的證據；一般操作疑問與故障排查則分開處理。

錯誤發生時間如何記錄

先記下事件第一次出現的日期與當地時間，並註明時區。例如，假設某次回報發生於 10 月 18 日 14:32，可寫成「10 月 18 日 14:32，台北時間（UTC+8）」。若時間只是客戶回憶，就寫「約 14:30」，不要把估計整理成精確分鐘。再分開記錄收到回報的時間、最近一次發生時間，以及整理回報資料的時間；三者用途不同，工程人員才能看出問題是否仍在發生，或只是回看先前事件。

把時間和當時正在做的事配對，例如登入後首次開啟對話、送出訊息後等待，或切換頁面後看到空白。若只發生一次，就註明「目前觀察到一次」；若重複發生，列出每次時間，或至少記錄第一次、最近一次與大致頻率。用「每次重新開啟頁面後」這類可觀察條件，取代「常常」「偶爾」等模糊說法。不要把推測的原因寫進時間紀錄。

如果事件很快恢復，可以補上起訖，例如「14:32 首次出現，14:40 再操作時已恢復」；恢復時間不清楚，就標明未知。跨時區時保留客戶提供的原始時間與時區，再附上清楚標示的換算時間，不要只留下換算後的數字。時間若取自裝置畫面或系統紀錄，也註明來源。這些資訊有助於工程人員對照其他紀錄，但不需要為了填滿欄位而猜測伺服器事件時間。

若知道問題最後一次正常出現的時間，也可一併記下，但要說明是客戶記憶、畫面紀錄或其他可核對的來源。第一次發現不一定等於問題開始發生，因此不要把「今天才注意到」寫成「今天才出現」。若時間只有大致範圍，可寫明例如上午或某次操作後，並保留未知項目。這樣工程窗口能判斷哪些時間可用來比對紀錄，也不會把不確定的線索當成精確事實。

重現步驟怎麼逐條寫

從操作前的狀態開始寫，讓接手者知道要用什麼帳號狀態、開哪個頁面、是否已登入，以及有沒有必要的測試資料。帳號與資料可用代稱，例如「測試帳號 A 有一筆未讀對話」，不必放入真實客戶內容。每一步只寫一個動作，使用可直接照做的動詞：開啟頁面、選取測試對話、輸入一段測試文字、按下送出。若有前置條件，就明確寫在步驟之前。

每個動作後補上看到的結果，尤其要指出從哪一步開始與預期不同。可用編號列出先後順序，不要把登入、切換頁面、送出與重新整理塞在同一句，否則難以判斷哪個動作觸發差異。錯誤發生後不要自動加上重試步驟，除非重試是穩定重現所需條件；若重試會改變資料或畫面狀態，也要記下重試前後的差異。

一組步驟只描述一條操作路徑，並寫明次數與停止點。例如，假設測試者從首頁進入測試對話、送出一次測試訊息、等待約五秒後停止，且不重新整理，就把這些條件逐條列出。若只有完成某項設定才會出現問題，指出該設定狀態即可，不要貼上無關的設定教學。最後記錄目前是每次都能重現、間歇發生，還是暫時無法重現。這是觀察結果，不是對缺陷原因的判定。

若客服曾協助客戶操作，分清楚哪些步驟由客戶實際完成，哪些是客服轉述或依資料整理；也記下測試使用的資料是否已存在、操作是否會改動資料。若同一現象可由不同入口觸發，分成兩條路徑各自記錄，不要合併成一串看似相同的操作。交接前可請另一位同事只看步驟照做一次，若他需要猜測按哪裡或用哪筆資料，就補足那個前置條件；這是在檢查說明是否清楚，不是請客戶自行排障。

裝置與版本需要哪些欄

環境資訊的目的是讓工程人員在相近條件重跑，不是收集所有裝置資料。優先記錄裝置種類與型號（知道才填）、作業系統及版本、使用的應用程式或瀏覽器名稱與版本，以及軟體本身顯示的版本。手機回報可記下 iOS 或 Android 版本；電腦回報則寫明 Windows、macOS 或其他系統的版本。可以從裝置設定、應用程式資訊頁或瀏覽器的「關於」頁查看，欄位名稱以實際環境為準，不要猜測版本號。

再補充可能影響重現的條件，例如使用公司或個人裝置、是否連著公司網路、是否使用 VPN 或代理伺服器，以及登入角色是否有特定權限。只記與差異有關的事實；不需要提供 Wi-Fi 密碼、裝置序號或個人帳號。若不知道瀏覽器版本，寫「尚未確認」，比把猜測當成資料更可靠。剛更新版本或重新開機時，也可記下大致時間與是否已完整關閉再開啟。

同一問題若只在某個環境出現，分列發生與未發生的環境，例如「手機瀏覽器有問題，桌面瀏覽器目前正常」，並把兩台裝置的版本分開記錄。整理時可依序填裝置、作業系統、軟體版本、網路條件及發生結果，並標明資訊是客戶提供、客服查看，還是尚未確認。先交足以重現的核心資訊即可；若工程窗口還需要其他欄位，再針對缺少的條件追問，不必要求客戶一次提供與問題無關的細節。

以下是可直接複製填寫的空白格式，尚未確認的項目保留空白或標示待確認：

若拿得到兩種環境的資料，可先只比較一項明顯不同的條件，並把兩邊操作步驟保持一致；若步驟或測試資料也不同，就不能把差異直接歸因於裝置或版本。這個比較只用來說明目前觀察到的環境範圍，不代表已找出原因。

預期與實際結果怎麼比

預期結果要寫明完成哪個動作後，畫面或資料應呈現什麼；實際結果則記錄當時真正看到的狀況。兩者盡量使用同一個對照點，例如送出一則測試訊息後，它是否出現在對話紀錄；按下保存後，剛才輸入的內容是否仍保留。不要只寫「不能用」「怪怪的」或「結果錯誤」。若預期來自已確認的需求或既有操作方式，可指出依據；若只是操作人的理解，就標明「我原本預期」，避免把假設寫成規格。

接著描述差異的範圍：每次都發生或只發生過一次、只影響單筆測試資料或多筆資料、是否延遲後才更新，以及有沒有出現錯誤文字。保留錯誤內容的原意，但複製到回報前先遮蔽個人資料或識別資訊。可以說明工作流程停在哪一步、目前有沒有替代做法；避免直接推斷服務整體不可用，也不要替工程人員判定責任。

假設示例：在測試頁面輸入「測試訊息」並按送出，預期是訊息出現在對話紀錄；實際上按鈕停止顯示載入後，紀錄裡仍沒有該訊息。這只是描述格式的假設，不代表任何真實產品問題。如果訊息約三十秒後才出現，也要記下等待時間和最後狀態，不要把延遲誤寫成完全未送出。可用「動作、預期、實際」三項逐列對照；不確定的預期就標示待確認，截圖則註明擷取時間及對應步驟。

若畫面內容和資料紀錄看起來不一致，分開描述各自觀察到的結果，例如畫面顯示什麼、重新進入頁面後看到什麼；不要自行推斷資料是否已儲存。若結果會因等待時間不同而改變，記錄操作後多久查看，以及等待期間是否又做了其他操作。這些差異能幫助工程人員重現同一個觀察點，也方便後續確認驗證是否涵蓋原本回報的現象。

哪些個資應先遮蔽

交接前先只保留重現問題所需的內容。姓名、電話、電子郵件、客戶編號、對話中可辨識個人的資訊，都應檢查是否需要遮蔽。密碼、一次性驗證碼、登入連結、Cookie、存取權杖等可用來登入或取得權限的內容，不應附在一般缺陷回報裡。若錯誤畫面同時露出個人資料，把相關區域遮住，再確認畫面沒有在側欄、通知、網址參數或其他視窗重複顯示同一資訊。

遮蔽時保留理解問題所需的上下文，例如按鈕位置、錯誤提示、發生時間與操作順序；只把敏感值替換成「已遮蔽」或一致的代稱，不要整張裁掉造成看不出操作位置。若多個步驟涉及同一位測試對象，可使用相同代稱維持前後關係，但不要保留可反查身分的真實識別碼。螢幕錄影也要檢查通知、切換分頁、游標附近及播放過程中短暫露出的內容。

若工程人員確實需要檢視含敏感內容的原始資料，先確認公司核准的存放位置、存取對象與交付方式，再依內部流程提供最小範圍的證據；不要把原始對話直接貼到多人可見的工單或公開連結。交付遮蔽版本前，再從頭檢視一遍：文字是否能反白複製出被遮住的內容、影像是否仍含敏感區域、檔名或附件說明是否暴露身份。完成後在回報中簡單記下已遮蔽的資料類型，讓接手者知道哪些內容是刻意隱去的。

附件也要檢查檔名、文件屬性及截圖外圍資訊；直接用畫筆塗黑後，最好另存成無法還原遮蔽內容的版本，再以一般檢視方式確認。若證據需要保留原始檔，將原始檔和可分享版本分開，依團隊既有權限流程處理。若不確定某項資訊能否提供，先只交遮蔽版本並向指定窗口確認，避免為了讓問題看起來完整而擴大資料範圍。

工程接手後如何追狀態

交出回報包時，用一小段摘要指出問題現象、最短重現路徑、發生環境，以及最重要的預期與實際差異；附件則連到有權限控管的存放位置。確認工程窗口知道由誰負責接手，以及接下來會在哪個時間點或事件後更新進度。這個更新點可以是完成重現確認、發現缺少資料或有處理結果，不必在尚未查明前承諾修復日期。客服也應記下摘要交付時間和接手對象，避免只留下無人確認的訊息。

追蹤狀態時，使用團隊實際採用的流程名稱；若沒有共用名稱，可在文字更新中說明目前是待確認、正在重現、已確認差異或等待驗證。這些是溝通用語，不表示任何特定工單系統一定有對應按鈕或欄位。每次更新只補新證據：哪一步已能重現、在哪個版本觀察到差異、還缺哪項環境資訊。若工程窗口要求補件，把問題縮小成可回答的一兩項，並說清楚為什麼需要，避免重複索取整份資料。

有處理結果後，確認回覆包含適用的環境或驗證條件；若仍無法重現，就保留原步驟與目前未知項目，不要自行把案件描述成已解決。客服轉告客戶時，只陳述已確認的進度與下一個更新點；待同一重現路徑再次核對後，再記錄驗證結果。現在可先用一個不含個資的例子，依本文六項整理出回報包；若也在整理客戶服務流程，可到 ReplyBot 官方網站 查看相關資訊，並以官網現有內容確認適用範圍。