要求指南
正式版存取權問卷這樣回答就對了（逐題範例）
完成封閉測試並申請正式版存取權時，必須回答與測試相關的問題。問卷由人員閱讀並判斷，回答太簡略就會遭拒。本文逐一說明 Google 詢問的三部分題目，並把較弱和較好的回答並列，告訴您該寫些什麼。
最後確認：2026年9月20日。
1. 問卷看的是什麼
完成 14 天的封閉測試後，就可以在 Play Console 申請正式版存取權。申請時必須回答與封閉測試相關的問題，Google 會由人員閱讀並審查這些回答。審查通常在 7 天內完成。
重點只有一個：Google 看的是您是否真的做了測試，而不只是走個形式。因此，「測試已順利完成」這種句子沒有提供任何資訊，是說服力不足的回答；寫出您看到了什麼、修正了什麼，才是有力的回答。
2. 第 1 部分：封閉測試資訊
這部分詢問您如何進行測試，共有四個問題。
招募測試人員是否困難
這是詢問難易度的問題，沒有標準答案。請誠實回答，再補充一句您是如何招募的就夠了。
這樣寫說服力不足
不困難，很容易。
這樣寫比較好
並不容易。只靠親友和社群人數不足，因此同時使用了實體裝置測試服務，確保有 12 位以上的測試人員。
測試人員是否使用了應用程式的所有功能
與其斷言全部都用過，不如區分清楚確認到哪個範圍，更能取得信任。如果有沒用到的功能，最好也寫出原因。
這樣寫說服力不足
是的，所有功能都使用過了。
這樣寫比較好
從首次啟動到主要畫面（不需登入即可使用的首頁、清單、詳細資料），已在所有裝置上確認。付款和推播通知需要真實帳戶，因此只用開發人員帳戶確認過。
測試人員的使用方式是否與實際使用者相似
這樣寫說服力不足
是的，很相似。
這樣寫比較好
測試方式是安裝後每天執行應用程式，並確認能進入首頁，因此在使用時間上，與一天使用多次且時間較長的實際使用者有所差異。不過，我們在多家製造商、多個 OS 版本上反覆確認了首次啟動是否正常。
收集了哪些意見、如何收集
這是最重要的題目。請分開寫收集方法和 收集到的內容。
這樣寫說服力不足
測試人員說運作得很好。
這樣寫比較好
透過各裝置的執行紀錄和執行畫面截圖進行確認，失敗的執行會連同錯誤代碼和裝置型號一起記錄。我們發現在 2 部 Android 11 裝置上，首次啟動時權限要求畫面會被遮住。
3. 第 2 部分：應用程式資訊
這部分是關於應用程式本身的問題，會詢問目標對象、價值主張，以及推出第一年的預估安裝次數。這部分與測試無關，寫事實就好，不必寫行銷文案。
- 目標對象 — 寫得具體一點，例如「20～30 多歲、早上很難起床的上班族」。避免寫「所有使用者」。
- 價值主張 — 用一句話說明與競爭應用程式有何不同。與其列出功能，不如寫「它能替使用者做什麼」。
- 第一年預估安裝次數 — 以範圍回答，不要誇大比較好。沒有根據的大數字，反而會讓人懷疑應用程式的準備情況。
4. 第 3 部分：正式版準備情況
這部分詢問您如何將測試中學到的東西反映到應用程式中。這是最能左右核准結果的地方。
這樣寫說服力不足
修正了錯誤並提升了穩定性。
這樣寫比較好
測試期間更新了三次。1.0.3 修正了 Android 11 權限畫面被遮住的問題；1.0.4 根據首次啟動載入時間過長的觀察，縮短了啟動畫面；1.0.5 則降低了低階裝置的記憶體用量。
同時寫出版本號碼和修正內容，審查人員就能加以確認。因此，在測試期間 每隔 3～4 天上傳一次更新，對撰寫這個回答有很大的幫助。
5. 作答前要準備的資料
憑記憶填寫問卷，內容就會流於籠統。先準備好以下五項資料，每一題都能直接引用。
- 測試開始日和結束日，以及這段期間維持的安裝裝置數
- 測試期間上傳的版本清單，以及每個版本的變更內容
- 執行失敗的裝置，以及當時的錯誤和 OS 版本
- 首次啟動畫面截圖（證明權限要求和新手導覽正常的資料）
- 沒有確認到的功能及其原因
6. 不該寫的回答
- 編造不存在的意見回饋。如果寫出「12 位測試人員都說 UI 很好用」這種無法查證的句子，一旦出問題，有風險的不是應用程式，而是帳戶。
- 每一題都只回答「是」。完全沒有遇到任何困難的回答，反而會讓人覺得您根本沒做測試。
- 直接照抄範本。同樣的句子在多個應用程式中重複出現，審查人員是看得出來的。
- 用功能清單充篇幅。問卷問的不是功能清單，而是您從測試中學到了什麼。
常見問題
- 可以使用代寫問卷的服務嗎？
- 不建議。編造不存在的測試人員經驗並提交，等於向 Google 提供不實資訊；一旦出問題，有風險的不是應用程式，而是開發人員帳戶。根據實際發生的事親自撰寫比較安全，通過的機率也比較高。
- 一定要用英文寫嗎？
- 用中文寫也可以。不過，句子冗長或含糊就無法傳達重點，因此最好以數字和具體事實為主，簡潔地撰寫。
- 測試人員實際上沒有提供意見回饋，該怎麼寫？
- 不要編造沒有收到的意見，請寫實際做過的事。例如在各裝置執行時確認到的錯誤、當機紀錄、安裝失敗裝置的 OS 版本等，這些在測試過程中觀察到的事實，就足以作為依據。
- 要寫多長？
- 重點不在篇幅，而在具體程度。每題 3～5 句就夠了，重要的是有沒有數字（裝置數、期間、版本數）和實際的變更內容。
- 遭拒後要從頭再來嗎？
- 視遭拒原因而定。如果是問卷內容不足而遭拒，可以補充後重新申請；但如果是測試本身沒有達到要求，可能需要再進行一段時間的封閉測試。