如何在上線前測試你的應用程式：實用的上線前計畫

要在上線前測試你的應用程式，請先列出使用者必須能完成的幾個流程，以全新使用者的身分在筆電與手機上逐一執行，然後嘗試各種可能出錯的情況：空白資料、錯誤輸入、第二個帳號、緩慢的網路。涉及金錢或私人資料的功能要格外小心，並在發布後於正式網址上重複主要流程。最後，請找一位從未見過這個應用程式的人，觀察他如何使用。

你不需要 QA 團隊或測試框架。你需要的是一份清單、一兩個小時，以及確實逐項點擊檢查的自律。

步驟一：寫下重要的使用流程

所謂流程，是指使用者前來完成的一項從頭到尾的任務。大多數應用程式有三到六個真正重要的流程。以預約應用程式為例：

1. 註冊並確認帳號
2. 找到課程並預約
3. 取消預約
4. 購買課程票券
5. 工作人員：查看今日的預約

如果你已經寫過使用者故事，其中的驗收條件就已經是你的測試案例。如果還沒有，請為每個流程寫一行，說明「成功」的樣子。

為它們排定優先順序。會帶來收入的流程，或每位使用者都會經過的流程（註冊、登入、核心操作），應該最先、也最完整地測試。

步驟二：以全新使用者身分測試正常流程

「正常流程」指的是流程完全依照預期進行。請以陌生人的體驗來測試：

• 使用私密瀏覽視窗，這樣你不會處於登入狀態，也沒有任何已儲存的資料。
• 使用一個全新帳號，並使用你可以實際收信確認的真實電子郵件。
• 從首頁或連結開始，而不是從你在開發時收藏的頁面開始。

新使用者沒有任何資料。許多錯誤只會在列表是空的、個人檔案沒有照片，或是尚未有任何購買紀錄時才會出現。你自己那個塞滿測試資料的帳號，會把這些錯誤隱藏起來。

步驟三：嘗試把它搞壞

現在，請重複每個流程，並刻意做錯事。

重新整理的情況特別值得留意：如果你一步步點擊時應用程式運作正常，但在較深的頁面重新整理卻出現 404，請參閱部署後如何修正 404 錯誤。

步驟四：用兩個帳號測試權限

對於任何具有帳號系統的應用程式來說，這是最重要、也最常被略過的測試。

建立兩個一般使用者 A 和 B，若你的應用程式有管理員，也請建立一位管理員。

• 以 A 的身分建立一筆紀錄。登入 B 的帳號。B 能看到、編輯或刪除它嗎？除非那是設計上的安排，否則都不應該可以。
• 以 A 的身分複製其中一筆紀錄的網址。登入 B 的帳號，並直接開啟該網址。
• 以一般使用者的身分，透過手動輸入網址來開啟管理頁面。
• 完全登出，然後嘗試相同的網址。

如果這裡發現問題，在修正之前不要上線。檢查必須在伺服器端進行，而不只是隱藏按鈕。我們的AI 打造應用程式資安檢查清單有更深入的說明。

步驟五：在實體裝置上測試

請在真正的手機上開啟應用程式，而不只是縮小瀏覽器視窗。

• 每個按鈕都能不必縮放就點到嗎？
• 鍵盤會遮住你正在輸入的欄位嗎？
• 表格和寬版內容是可以捲動或自動換行，還是把整個頁面推向一側？
• 文字不需要捏放就能清楚閱讀嗎？

如果可以借到，請至少測試一台 iPhone（Safari）與一台 Android 手機（Chrome）。特別是 Safari，在日期、影片與固定定位元素上有它自己的特殊行為。

步驟六：端到端測試金流與電子郵件

任何會刷卡收費或寄送電子郵件的功能，都需要完整走過一遍。

付款。 使用你的金流服務商的測試模式與測試卡號。檢查付款成功、信用卡被拒絕，以及取消結帳的情況。確認付款後，訂單或訂閱會顯示在你的應用程式中，而不只是出現在金流服務商的後台。如果你的應用程式依賴 Webhook（金流服務商傳送給你伺服器的訊息），請確認它們能在已發布的應用程式上收到，而不只是在開發環境中。接著，在上線前切換為正式金鑰，並進行一筆你之後會退款的小額真實購買。

電子郵件。 使用兩到三家不同服務商的真實信箱註冊。檢查郵件是否確實送達、沒有進入垃圾郵件匣，且郵件中的每個連結都指向正式網域，而不是預覽網址。

步驟七：檢查速度與錯誤

• 開啟瀏覽器的開發者工具（按右鍵 → 檢查），並在每個主要頁面查看主控台分頁。即使畫面看起來沒有問題，紅色的錯誤訊息也值得修正。
• 用手機的行動網路（而非 Wi-Fi）載入網站。如果首屏需要好幾秒，請先檢查圖片大小。
• 在 Chrome 開發者工具中執行 Lighthouse 等免費檢測工具，快速了解效能與無障礙狀況。

步驟八：測試已發布的應用程式，而不只是預覽

預覽與已發布的應用程式並不是相同的環境。在告訴別人你即將上線之前，請在正式網址上重複主要流程：

• 已發布的應用程式是否已設定所有環境變數與機密資訊？
• 它是否使用正確的資料庫，並且資料符合你的預期？
• 登入後的重新導向與電子郵件中的連結，是否使用正式網域？
• 在較深的頁面重新整理時，是否能正確載入？

步驟九：觀察別人使用它

給一兩位測試者一個目標（「幫我預約星期六的瑜伽課」），而不是操作說明。在旁觀察，不要幫忙，並記下他們在哪裡猶豫。這是找出難懂文字與隱藏按鈕最快的方法。若想了解更完整的做法，請參閱如何進行測試版測試。

當他們遇到錯誤時，請妥善記錄下來，包括步驟、預期結果與實際結果。我們的如何寫好錯誤回報指南說明了格式。

使用 AI 協助測試

如果你是用 AI 打造應用程式，可以請它協助規劃與執行測試：

列出這個應用程式的主要使用者流程，並針對每個流程列出最可能出錯的邊界情況：空白狀態、無效輸入、權限，以及重新整理。整理成一份我可以逐項完成的檢查清單。

以兩個不同的測試使用者登入，檢查使用者 B 是否能看到或修改使用者 A 建立的任何內容，包括直接開啟 A 的紀錄網址。在修正任何問題之前，先回報你發現的結果。

請把 AI 自己的測試報告視為初步審查。金流與權限相關的流程，仍然要由你親自點擊檢查。

在 Mythex 中測試

在 Mythex 中，/test 指令會執行應用程式測試：代理程式會以瀏覽器對你的即時預覽進行操作，點擊各個頁面、擷取截圖，並在聊天中回報失效的流程。針對特定流程使用效果最好，例如「測試註冊與預約課程」。使用 /fix 或一般訊息修正找到的問題，然後再次執行 /test。應用程式測試是在預覽環境中進行的，因此發布後仍需自行在正式網址上檢查主要流程。請參閱文件中的應用程式測試，以及當出現問題時的除錯 AI 打造的應用程式指南。

常見錯誤

• 只以自己的身分測試。你那個塞滿資料的管理員帳號，會把空白狀態與權限問題隱藏起來。
• 只在筆電上測試。許多網站的大部分訪客都是從手機進來的。
• 略過第二個帳號。使用者之間的資料外洩，是應用程式上線時可能存在的最嚴重錯誤。
• 完全相信預覽。正式應用程式使用不同的設定，也必須測試。
• 修正錯誤後不重新測試附近的功能。修改某個表單，可能會破壞另一個共用相同程式碼的表單。

上線前檢查清單

• 已列出主要流程並排定優先順序
• 每個流程都能在私密視窗中以全新使用者身分順利完成
• 空白、無效、過長與重複的輸入都有妥善處理
• 每個頁面的重新整理都能正常運作
• 使用者即使透過網址也無法看到或修改彼此的資料
• 一般使用者與未登入的訪客都無法存取管理頁面
• 在實際的 iPhone 與 Android 手機上運作正常
• 付款已測試：成功、被拒、取消，以及之後應用程式會正確更新
• 郵件能送達、不會進入垃圾郵件匣，並且連結指向正式網域
• 主要頁面的主控台沒有紅色錯誤
• 主要流程已在已發布的正式網址上重複測試
• 至少有一位外部人士在你旁觀的情況下試用過

常見問題