cosGlint Android 封測結束 | HCYTLOG

2026-10-08 更新：本文保留 cosGlint 在 2025 年通過封測的經過與填答資料；封測門檻改依 Google 官方文件說明，分清楚加入測試、安裝和實際參與，避免把個人經驗當成保證通過的規則。

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

當年的封測回饋，讓我看到開發時漏掉的事

cosGlint 的 Android 正式版終於通過審查了。老實說，Android 在這塊比 iOS 麻煩不少，但封測也有它的用處。第一次上架時，產品還比較粗糙，這些流程會逼你把「本來想之後再修」的地方補齊，致命 bug 往往就能提早被揪出來。

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

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

邀請朋友的節奏，和送審門檻分開安排

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

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

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

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

當時我建議分階段邀請，方便先穩住核心流程。這是回饋蒐集的安排，不能直接當成兩週就能送審的時間表：

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

如果第二週才達到 12 位測試者，這 12 人仍要各自連續加入測試至少 14 天，才符合申請正式發布資格的門檻。可以先用 internal testing 找問題，再安排符合人數的 closed testing；Google 官方規則把兩種測試分開說明。

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

「我需要你加入 Android 封測，至少連續 14 天保持加入狀態，也請實際試用核心功能。遇到問題截圖給我，有更新我會提醒。」
「你用直覺亂按的路徑超有價值，遇到怪東西截圖給我就行，敲你不會很頻繁。」
「這版我在補角落情境，你先用核心功能，卡到再回我，會有 changelog 跟小修。」

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

自然使用，再把卡住的地方拆成問題

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

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

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

快速診斷的三問：

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

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

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

把回饋轉成修正時，我當時的安排是：

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

小技巧：

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

Android 封閉測試怎麼過？

我不敢說照做就一定過。以下把官方門檻和我當時送審的做法分開，填答只能反映你實際做過的測試。

適用帳號與 14 天的計算方式

至少 12 人、連續 14 天的要求，適用於 2023-11-13 後建立的個人開發者帳號，不是所有 Android 開發者都套用同一門檻。
申請時至少要有 12 位測試者已連續保持加入（opted in）14 天。退出測試後再加入，必須重新累積連續的 14 天。
加入測試、安裝 app 和實際使用是不同事情。官方連續天數要求指的是 opt-in 狀態，不能把「解除安裝」直接寫成「退出測試」；但沒有實際測試與回饋，也不代表具備發布準備。
可透過 Google Play 的測試意見回饋、訪談或其他明確管道蒐集回饋，送審時說明參與度和修正結果。

以上依 Google 官方新個人帳號測試規則整理，查核日期為 2026-10-08。安裝後放著就好，無法替代使用核心功能的測試。

實務操作與送審策略

第一次送審被退時，我的填答很隨意，也不確定大家是否確實測過。不能把那次退件歸因於「沒安裝」；後來我改找人實際使用，再整理參與和回饋紀錄。
第二次我就認真找人實際測試，並把送審問答每一項都填得很扎實。期間確實有更新版本，也有 changelog。
滿足符合資格的 12 位測試者各自連續 opt-in 14 天後，才能申請正式發布資格。每一格都仔細填，而且要真的有做到；別沒更新就寫「我更新了一堆事項」XD。
我當時大概第 6 天收到通過通知。官方目前說審查通常不超過 7 天，但偶爾更久，也可能因參與不足而要求繼續測試；我的時程不是保證。第一次被退件的理由是「需要更多測試回饋來修正 app」。
這階段 Google 會特別檢查你宣告的條款是否與 app 行為一致。舉例：如果有取得使用者資料，隱私政策要明確揭露。不一致就會退件。

我的填答參考

下面保留當時的回答與版本功能。Crash-free、ANR、啟動時間和測試覆蓋等數字，都應有自己的量測紀錄；不要沒有測過就直接照抄，也不要把這些自訂發布標準當成 Google 統一門檻。

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

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

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

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

2026-10-08 補充：依 Google 官方開發者帳號資料說明，個人帳號會公開法定姓名、國家與開發者 email，若在 Google Play 營利，還會公開完整地址；部分地區另有額外揭露要求。組織帳號也會公開法定名稱、地址、開發者 email 與電話，所以「法人就無所謂」說得太輕了。上架與營利前先確認公開資訊，別填假資料來避開身分驗證。

小結

這次封測雖然繁瑣，卻讓我發現不少開發時沒想到的使用方式。送審時，把參與紀錄、回饋和實際修正寫清楚，也確認條款和 app 行為一致；能不能通過仍由審查決定，沒有一套填答保證成功。