cosGlint Android 封測結束

Android 封閉測試通過心得：規則、填答、與實務提醒

cosGlint 的 Android 正式版終於審查通過了。老實說 Android 在這塊比 iOS 麻煩不少，但我後來把它當成一種「必要的摩擦」。第一次上架時，產品一定相對粗糙；你以為流程在阻礙你，其實它在強迫你把那些「本來想之後再修」的角落一次補齊，於是致命 bug 往往能在封測就被揪出來。

工程師和使用者的思考路徑真的不同。工程師會沿著設計的主幹「合理」地操作，使用者則會走支線、跳步、逆向、甚至把看起來很智障的路徑一路跑到底；你在開發時下意識會略過那些不該發生的情境，但一發布就會被回報 XD。Android 的封閉測試像是一面鏡子：它讓你看到產品在真實手上會怎麼被對待，也逼你把「不該用這樣用」的地方改成「就算這樣用也不會壞」。這過程雖然繁瑣，卻是把產品從「能跑」升級到「能被任何人正確使用」的關鍵。

就像這次的封測我起碼收到了40個 Issue和建議，有很多還真的是我沒意到，但他其實完全不影響使用體驗，但改了會更好，也許只多 0.1 分，但眾多0.1分累積起來也許多了5分。

但這邊請你不要一股腦全部邀請，我覺得可以按照朋友屬性來邀請。

先從「有耐心、願意嘗試」的朋友開始，讓核心流程穩住；等到主要問題都修完，再把「沒耐心、偏直覺操作」的朋友放進來，驗證邊角與異常路徑。

我自己的分組邏輯大概是這樣：

• 願意給建設性回饋、能描述問題的（先邀）：幫你找設計上的誤解與流程斷點。
• 會盲測＋直覺亂按的（第二輪）：幫你測到「不該這樣用」但現實會發生的路徑。
• 不常回訊、容易棄測的（最後）：用來驗證留存與通知策略、看看你能不能把他們拉回來。

邀請節奏也很重要：

• 第 1 週：小規模 5～8 人，快速迭代；每天收斂、每 2～3 天版更一次。
• 第 2 週：擴到 12～18 人，補齊多機型與多網路環境，累積穩定度指標。
• 送審前：再加幾位「不耐煩型」，確認一鍵回退、錯誤提示、空狀態都到位。

如果要跟朋友開口，我都會用比較輕鬆的說法：

• 「Android 第一關比較嚴，我需要 14 天封測人數到門檻，你幫我裝著就好，有更新我會提醒。」
• 「你用直覺亂按的路徑超有價值，遇到怪東西截圖給我就行，敲你不會很頻繁。」
• 「這版我在補角落情境，你先用核心功能，卡到再回我，會有 changelog 跟小修。」

最後記得控管訊息量與更新頻率：對耐心型可以給詳細說明與問卷；對不耐煩型只丟必要提醒（版本重點、需要操作一次的地方），其餘讓他們自然用。這樣能兼顧品質與留存，不會把人嚇跑。

最後我其實強烈建議：把 app 交給朋友測試時，不要先塞一堆說明。為什麼？平常你下載 app，有人站在旁邊講解嗎？沒有吧。那你是怎麼判斷好用或不好用的？靠直覺與介面本身。

封測也該如此：先讓他們自然使用，你安靜觀察；等他們真的卡住、提出疑問，再補最小必要的提示（像是「這裡可以往左滑刪除」、「這個步驟需要權限」）。先閉嘴，不是不服務，而是避免把真實的可用性掩蓋掉。只有在不干擾的前提下收集到的行為與問題，才是你要修的「真問題」。

這時候你就要開始拆解「為什麼他會問這個問題？」到底是哪一層出包：UI/UX、流程、還是文案。

快速診斷的三問：

• 看得懂嗎（UI/文案）：「他沒有找到按鈕／看不懂標籤／用詞太專業？」如果是，就先改名稱、層級與對比，移除行話、補微型說明或空狀態。
• 走得過嗎（流程）：「他不知道下一步／回來之後狀態不見／必填順序不直覺？」如果是，就重排步驟、減少必填、加入進度與回退保留。
• 做得到嗎（系統）：「權限卡住／網路慢載入空白／錯誤提示不明確？」如果是，就補權限導引、骨架載入、錯誤訊息改成可行動（告訴他下一步能做什麼）。

蒐集回饋時，請用「行為＋阻礙」的問法，而不是「感覺」：

• 「你第一次打開時，目標是什麼？卡在哪一步？」
• 「你想完成X時，哪個地方讓你停下來？按了什麼、看到了什麼？」
• 「如果用一句話描述這個畫面在做什麼，你會怎麼說？」（檢驗文案與資訊架構）
• 「哪個按鈕你以為會做到X，但其實沒有？」（檢驗命名與期待對齊）

落地修正的優先順序：

1. 先改「看得懂」（命名、層級、對比、空狀態），讓人不需要說明就能使用。
2. 再改「走得過」（步驟順序、分段、減摩擦），把必填降到最少、訊息在關鍵時機出現。
3. 最後補「做得到」（權限導引、載入骨架、錯誤可行動），避免黑箱與死路。

小技巧：

• 記錄第一次嘗試的3步之內是否能形成「正迴圈」（完成一次核心任務）。如果做不到，問題多半在文案與畫面結構。
• 將所有提示改成「動詞＋結果」（例如：「上滑刪除」→「左滑即可刪除這條通知」）。
• 每個錯誤訊息附一個可操作的動作與回退選項（「重試」「稍後再說」「聯絡支援」）。

Android 封閉測試怎麼過？

我不敢說照做就一定過，但以下是我這次實際通過的做法與填答參考。

封閉測試規則（Play Console）

• 需要至少 12 位測試者，連續 14 天封閉測試，期間不可刪除 app。
• 建議使用「測試意見回饋」功能回報給開發者（不強制，但 Google 建議）。就像正式版的評分與評論機制一樣。
• 測試期間不要移除 app（避免時間被重置或判定不合格）。

實務操作與送審策略

• 至少要有 12 個 Google 帳號點選加入測試，時間才會開始計算。要不要下載 app？有人說不用，但我第一次送審被退，是否因為沒裝機不確定，因為我也把送審理由寫得很隨意 XD
• 第二次我就認真找人實際測試，並把送審問答每一項都填得很扎實。期間確實有版更與 changelog。
• 14 天一到會出現「申請正式版」按鈕。每一格都仔細填，但最好是你真的有做到。別完全沒更新就寫「我更新了一堆事項」這種會被看穿的東西 XD
• Google 之後會進行約 1～7 天的審查。我大概第 6 天收到通過通知。第一次被退件的理由是「需要更多測試回饋來修正 app」。
• 這階段 Google 會特別檢查你宣告的條款是否與 app 行為一致。舉例：如果有取得使用者資料，隱私政策要明確揭露。不一致就會退件。

我的填答參考

1. 請說明測試人員在封閉測試期間的參與度
   受測者於封測期間持續使用核心與新功能。因為多為親友，能直接、完整地收集使用回饋。期間我多次提出版本更新並調整功能，這些回饋協助驗證設計假設、重排優先順序，並縮小與實際體驗的落差。
2. 請簡短說明測試人員給予了哪些意見，以及這些意見的收集方式
   主要透過直接訪談與即時回饋，依使用者意見調整：

• 個人化分析：導覽可見性優化、適合度標準校正、次數即時更新、返回時困擾同步
• 通知中心：加入滑動已讀/刪除、支援系統訊息已讀
• 日記：修正照片/產品對應、列表字體與 emoji 顯示、暫停分享功能
• 香籤：改名、補預設資料夾、修復初始化與等級上限檢核
• 商品：補圖、支援刪除未分析項目
• 其他：登入取消提示、驗證碼顯示對比、任務卡字體、圖片重複識別、聊天/分析次數限制明確顯示

3. 應用程式的目標對象為何？
   一般消費者中在意保養成分與實際效果者：包含敏感肌、痘痘/油性肌、孕期與母嬰族群。也適用於需要快速查核成分與說明的美妝門市人員與內容創作者，作為第三方資訊工具。
4. 請說明應用程式如何為使用者帶來價值
   以第三方視角提供成分解釋、風險提示、個人化適合度分數、產品比較與書籤追蹤；用清楚的圖文與分數協助決策，縮短搜尋與比對時間、提升購買信心。資料僅供資訊參考，無醫療診斷或療效宣稱。
5. 您根據封閉測試期間取得的意見回饋，對應用程式做了哪些調整？
   與第 2 題相同（同上）。
6. 您如何判定應用程式已準備好推出正式版？
   完成 QA/UAT 與回歸測試，核心任務全數通過；無 PO/P1 重大 bug，僅剩低優先修補；Crash-free ≥99.5%、ANR <0.3%、啟動 <2s；主流機型覆蓋通過，並已配置監控/告警與可回滾機制，判定可發正式版。

個資與 IAP 的提醒（個人開發者）

如果你要使用 Google 的 IAP 內購且是個人開發者，你的個資基本上是公開的：姓名、住址（法人還會有電話）。能不能填假住址？很可能在開發者註冊那關就卡住，請三思。如果你是法人就相對無所謂。

小結

Android 的封閉測試流程雖然繁瑣，但值得。它迫使你面對真實使用情境與回饋，把「看起來不可能」的路徑也補齊。認真填答、確實更新、條款一致，基本上就能順利通過。