Resposta rápida
"More testing required" é o resultado de uma solicitação de acesso de produção, não uma penalidade de política contra o seu app. O Google analisa o teste fechado que você fez e as respostas que você deu, e depois envia um e-mail ao proprietário da conta. Se a análise não ficar satisfeita, pedem que você continue testando. Comece confirmando qual decisão você recebeu e, em seguida, o que os seus próprios registros estabelecem sobre elegibilidade, uso do app, feedback e prontidão.
Se, em vez disso, o Google recusou o seu app ou a sua versão por um problema apontado, siga as instruções de correção e reenvio desse problema. Mais testadores não resolvem uma decisão de política.
Este artigo é o diagnóstico: qual decisão você recebeu, o que cada evidência estabelece e o que não estabelece, e o que corrigir antes de solicitar de novo. Ele se baseia nos testes fechados que a PrimeTestLab conduz toda semana e na orientação do Google, com links no ponto em que ela é usada. Atualizado em 11 de setembro de 2026.
Como ler este artigo
- Requisito do Google Uma condição obrigatória de elegibilidade, de envio ou de política.
- Orientação do Google O Google recomenda, ou a solicitação pergunta sobre isso. Nenhum limite é publicado.
- Nossa sugestão Uma prática de trabalho vinda dos testes que realizamos, não uma regra pela qual você é avaliado.
Nesta página
Primeiro, identifique o que o Google recusou
Três decisões diferentes acabam recebendo o mesmo nome, "teste fechado recusado", e cada uma exige um trabalho diferente. Confira a redação exata que você recebeu.
Qual mensagem você recebeu?
| O que você recebeu | O que significa | O que fazer em seguida |
|---|---|---|
| O Painel diz que a elegibilidade de teste está incompleta | O Painel identifica uma condição de teste não cumprida. Verifique a condição específica que aparece ali antes de decidir o que precisa continuar. | Conclua o teste fechado: no mínimo 12 testadores, cada um participando nos últimos 14 dias contínuos. |
| "More testing required" depois de solicitar | Sua solicitação foi analisada e ainda não foi aprovada. O Google pede que você continue testando; a decisão e o e-mail para o proprietário da conta trazem as preocupações que foram identificadas. | Percorra as cinco áreas abaixo, corrija o que encontrar e depois solicite de novo pela sua conta. |
| Recusa do app ou da versão por um problema apontado | Uma decisão sobre o próprio app, que aponta um problema de política ou de qualidade. Não é um julgamento sobre o seu número de testadores. | Siga as instruções de correção e reenvio do problema apontado. Mais testadores não vão resolver isso. |
Uma faixa de Produção bloqueada, sozinha, não diz se o que ainda falta é a elegibilidade de teste, uma decisão sobre a solicitação ou outra etapa da conta. Oriente-se pela mensagem específica que você recebeu, não pelo bloqueio.
Fontes: requisitos de teste de apps e acesso de produção e publicação e status da análise.
Confirme que o requisito se aplica a você
Requisito do GoogleO requisito se aplica a contas pessoais de desenvolvedor criadas após 13 de novembro de 2023. O Google afirma que essas contas precisam atender a requisitos específicos de teste antes que um app fique elegível para ser publicado. Se a sua for afetada, três coisas acontecem nesta ordem:
- 1Realize um teste fechado, não apenas um teste interno.
- 2Mantenha no mínimo 12 testadores participando por 14 dias contínuos.
- 3Solicite o acesso de produção e responda às perguntas sobre o teste, o app e a prontidão.
Elegibilidade não é aprovação
Cumprir o requisito deixa você elegível para solicitar. A solicitação é analisada à parte, então 14 dias limpos são o começo do processo, não o fim dele. Detalhes completos: como funciona o requisito de testadores.
Diagnostique o problema em cinco minutos
Abra o Play Console ao lado desta lista e responda a cada pergunta com honestidade. O que você não conseguir responder é por onde começar a ler.
O que isto faz e o que não faz
Isto não lê nada da sua conta do Play Console e não consegue confirmar o seu número de testadores nem as datas de participação. Só coloca o que você já sabe na ordem em que a análise pergunta.
Próximo passo
Use o guia de nova solicitação para os passos depois de uma decisão de mais testes. Se o seu diagnóstico mostrar que você precisa de mais testes com pessoas reais, compare as opções de suporte de teste. Se o Google apontou um problema no app ou de política, corrija isso primeiro; outro grupo de testadores não vai resolver.
Cinco áreas para verificar depois de uma recusa de acesso de produção
Áreas para investigar, na ordem em que dá para investigá-las. Elas não estão classificadas pela frequência com que causam uma recusa, porque nenhum dado publicado estabelece essa ordem.
A elegibilidade ou a continuidade dos testadores está incompleta
O Google pede no mínimo 12 testadores participando continuamente pelos últimos 14 dias. A continuidade é por testador: quem aceita participar, testa por menos de 14 dias e sai não conta naquele período interrompido. Um testador que volta pode qualificar de novo depois de um novo período ininterrupto de 14 dias participando.
O que verificar
- Confirme que você está na faixa fechada. Um testador que ainda esteja inscrito em um teste interno precisa sair dele antes que o seu teste fechado chegue até ele.
- Conte as pessoas que aceitaram participar, não os endereços que você adicionou a uma lista. Adicionar um endereço não faz nada até que a pessoa aceite o link.
- Peça aos testadores que continuem participando até o momento em que você solicitar o acesso de produção, não apenas durante os 14 dias que antecedem a solicitação.
Exemplo ilustrativo: a continuidade é por testador
Se 15 testadores entraram juntos e um sai, os 14 restantes ainda podem qualificar, porque cada um manteve o próprio período ininterrupto. Quem entra depois, como substituto, começa o próprio relógio e não herda o tempo já corrido do testador que saiu.
Mantenha uma pequena margem acima do mínimo. Exatamente 12 testadores já qualificam, então essa margem é uma prática nossa, para absorver uma saída sem que a contagem fique abaixo do exigido, não algo que o Google peça.
Fontes: requisitos de teste de apps para novas contas pessoais de desenvolvedor e configurar um teste aberto, fechado ou interno, para listas de testadores e links de participação. Tutoriais: confira os convites e a participação dos testadores e teste interno versus teste fechado.
Os testadores não usaram o app de forma significativa
A solicitação pergunta se os testadores usaram os recursos e se o uso se pareceu com o que você espera em produção. O Google também diz que pode pedir que você continue testando quando os testadores não se engajaram. A orientação analisada não especifica um limite numérico de engajamento, então o trabalho é descrever o uso real.
Três números que não são o mesmo número
| Métrica | O que ela conta | O que essa métrica estabelece |
|---|---|---|
| Testadores participando | Pessoas que aceitaram o link de participação da sua faixa fechada e continuam participando. | É o número da elegibilidade, e o único dos três ligado à regra dos 12 testadores e dos 14 dias. |
| Público instalado | Usuários com o seu app instalado em pelo menos um dispositivo que eles usaram nos últimos 30 dias. | O app chegou a um dispositivo em uso. Não estabelece que alguém o abriu. |
| Usuários ativos por dia | Pessoas que abriram o app em um determinado dia. | Houve aberturas. Ainda assim não diz quais recursos foram usados nem o que os testadores acharam deles. |
Fonte: ver as estatísticas do app. O Google tem sim os dados de uso, então o engajamento não é invisível para ele. O que não está documentado é quais sinais a análise pondera, e em que nível.
O que verificar
- Dê aos testadores um resumo curto nomeando os fluxos que você quer ver percorridos, e um único canal para responder.
- Peça observações específicas, não um veredito: o que tentaram, em qual dispositivo, o que aconteceu.
- Peça aos testadores que voltem a uma correção importante assim que ela for publicada, para que o registro mostre uma mudança sendo conferida.
Peça aos testadores que concluam as tarefas que importam para o seu app, relatem o que veem com as próprias palavras e voltem às correções importantes depois que elas entrarem no ar. Uma instrução fixa como "abrir o app uma vez por dia" é uma rotina de teste opcional, não uma regra do Google.
O feedback e as respostas da solicitação não trazem evidências específicas
A solicitação pede que você resuma o feedback que recebeu e as mudanças que fez. O Google recomenda anotar os temas do feedback ao longo do caminho, e esse registro é a diferença entre uma resposta específica e uma resposta genérica.
Registro de teste ilustrativo (estrutura, não conteúdo para copiar)
| Build, fluxo, ambiente | Achado | Ação ou verificação |
|---|---|---|
| Build 8; redefinição de senha; Android 14 | A mensagem de nova tentativa não estava clara | Esclarecida no Build 9; o testador conferiu de novo |
| Build 9; configurações salvas; Android 13 | As configurações foram mantidas depois de reabrir o app | Registrado como aprovado; nenhuma mudança necessária |
Este é um formato de registro sugerido, não um modelo nem um anexo exigido pelo Google. Use as colunas como estrutura, nunca as linhas como fatos para colar. Registrar uma verificação bem-sucedida importa tanto quanto registrar um problema: é o que permite responder à pergunta sobre prontidão sem inventar um problema.
O que verificar
- Use a seção de feedback de teste do Play Console, além de qualquer canal que você tenha dado aos testadores. As avaliações públicas da loja não fazem parte disso.
- Agrupe o feedback em temas primeiro, para que um único relato mais insistente não vire o resumo inteiro.
- Preserve a observação específica, seja citando o testador, seja resumindo com precisão.
- Confirme que os recursos que você descreve na solicitação estavam presentes no build testado e foram realmente usados. Registre o que foi testado à parte ou ficou fora deste teste.
Fontes: configurar um teste aberto, fechado ou interno e orientação sobre o acesso de produção. Um modelo de registro reutilizável está no nosso artigo de recuperação, e prepare respostas precisas para o acesso de produção percorre o próprio formulário.
Os achados não foram tratados ou a prontidão não está clara
A solicitação pergunta o que você mudou com base no que aprendeu, e o Google recomenda agir sobre o feedback durante o teste. Nenhuma cota de versões aparece na orientação analisada, então o que importa é se a resposta reflete o que o teste estabeleceu.
O que dizer quando nada precisou mudar
Se o teste não revelou nada que precisasse ser corrigido, descreva os fluxos verificados, os dispositivos em que rodaram e os resultados, e depois explique a decisão de prontidão a partir desse registro. Inventar um problema, ou publicar uma versão cosmética só para ter uma mudança a relatar, deixa a resposta mais fraca.
O que verificar
- Trate primeiro os achados reais e diga qual build levou cada correção.
- Ligue cada mudança ao feedback que a motivou, para que a resposta se leia como causa e efeito.
- Se um problema importante continuar em aberto, resolva antes de apresentar o app como pronto.
Onde essa resposta erra
A resposta fraca diz que o teste correu bem. A resposta forte nomeia o que foi verificado, o que foi encontrado, o que foi feito e como foi conferido. A resposta específica é mais fácil de avaliar.
Persistem problemas de acesso, de estabilidade ou de funcionamento
O Google não permite apps que travam, congelam ou de outra forma não funcionam normalmente. A análise também precisa conseguir chegar ao app: onde houver algo atrás de um login, a versão precisa vir acompanhada de credenciais que funcionem e de instruções.
O que verificar
- Forneça dados de login funcionais para a análise, e os passos necessários para chegar aos recursos restritos, referentes ao build que você enviou.
- Confirme que os testadores conseguem instalar e abrir esse build. Quem ainda estiver em um teste interno precisa sair dele primeiro.
- Rode um relatório de pré-lançamento, depois confira os sinais de crash e de ANR dos fluxos que os seus testadores usaram, e corrija o que for reproduzível.
O que um relatório limpo não prova
Os relatórios de pré-lançamento rodam automaticamente quando há capacidade. Pode ser preciso fornecer credenciais ou uma configuração personalizada para chegar ao conteúdo protegido e percorrer os fluxos relevantes. Um resultado automatizado limpo também não é um teste manual. O Android vitals se apoia em dados de diagnóstico de usuários que aceitaram compartilhá-los, vindos de um subconjunto de dispositivos e de versões do sistema operacional, então uma visualização indisponível pode refletir poucos dados dentro dos filtros que você selecionou. Os limites de mau comportamento que ele publica dizem respeito à qualidade técnica, não a uma nota de corte para o acesso de produção.
Fontes: funcionalidade, conteúdo e experiência do usuário, preparar o app para a análise, usar um relatório de pré-lançamento para identificar problemas e monitorar a qualidade técnica com o Android vitals.
O que cada evidência estabelece e o que não estabelece
Saber a qual pergunta cada evidência responde é o que separa um problema de testadores de um problema de evidência ou de um problema do app.
RespondeSe você estava elegível para solicitar: no mínimo 12 testadores, cada um participando nos últimos 14 dias contínuos.
Não respondeSe algum deles usou o app, ou se as suas respostas foram específicas o bastante.
RespondeQuantos usuários abriram o app em cada dia mostrado.
Não respondeQuantas vezes cada pessoa o abriu, quais recursos ela usou ou o que achou da experiência.
RespondeQue a visualização selecionada não tem dados suficientes para identificar problemas com os filtros atuais.
Não respondeQue o app não travou. O vitals usa dados de usuários que aceitaram compartilhá-los, vindos de um subconjunto de dispositivos e de versões, então uma visualização vazia pode significar que poucos dados foram coletados, e não que nada deu errado.
RespondeQue outro desenvolvedor relatou aquela redação. Vale a leitura, para entender o formato da decisão.
Não respondeO que foi dito à sua própria conta. Mensagens da comunidade reproduzidas são anedóticas e não podem definir o seu prazo.
RespondeUma observação específica sobre a qual você pode agir e que consegue descrever, nas palavras do próprio testador.
Não respondeSe o problema é generalizado. Um relato é uma pista; o padrão entre os testadores é o achado.
O que verificar antes de solicitar de novo
Orientação do Google- 1Leia as duas coisas, a decisão no Play Console e o e-mail para o proprietário da conta, e siga as instruções fornecidas para o seu app.
- 2Conclua qualquer período adicional de teste que o seu app tenha realmente recebido, e mantenha a faixa fechada rodando enquanto isso.
- 3Continue resolvendo as preocupações que a decisão apontou e depois solicite de novo pelas instruções que aparecem na sua conta.
Duas conclusões que você não deve tirar
A ausência de um prazo não é permissão para solicitar de novo imediatamente. E uma instrução para continuar testando não é prova de que o tempo já corrido de cada testador foi zerado: a orientação pública analisada não especifica uma regra universal de reinício, então trate as duas coisas como desconhecidas até que a sua própria conta diga o contrário.
O Google descreve a análise que vem depois como algo que costuma levar sete dias ou menos, dizendo que às vezes pode demorar um pouco mais. Isso é a análise, não o teste que vem antes dela. Passo a passo: como solicitar de novo depois de uma decisão de mais testes necessários.
Fonte: próximas etapas do acesso de produção.
Como manter os testadores engajados
Orientação do GoogleO Google diz que muitos desenvolvedores recrutam entre amigos, familiares, colegas, comunidades e redes sociais, e recomenda testadores que representem o seu público-alvo, diversos o bastante para revelar problemas específicos de dispositivo.
O recrutamento pode falhar quando a participação e o feedback não são gerenciados: um compromisso de 14 dias sem nenhuma estrutura em volta concorre com tudo o mais na semana de um voluntário. Três problemas de participação e de feedback para ficar de olho:
Onde um grupo por conta própria perde a janela
Fonte: requisitos de teste de apps, que é onde o Google fala sobre recrutar testadores. As opções são comparadas em formas legítimas de encontrar 12 testadores.
Teste por conta própria ou teste gerenciado
Os dois caminhos cumprem o mesmo requisito. A diferença é quem acompanha a contagem e cobra o feedback por 14 dias.
| Do que a solicitação depende | Grupo por conta própria | Teste gerenciado |
|---|---|---|
| Manter 12 testadores participando por 14 dias contínuos | Cabe a você acompanhar. Uma saída pode atrasar a elegibilidade se deixar poucos testadores qualificados. | Acompanhado para você, com a lista mantida acima do mínimo. |
| Dispositivos reais | O que os seus voluntários tiverem em mãos. | Dispositivos Android reais, do Android 7 ao Android 17. |
| Para começar | O tempo que o recrutamento levar. | Os testadores costumam começar em 4-6 horas. |
| Feedback que você consegue resumir | Depende inteiramente de como você o coleta. | Coletado por um único canal e reportado a você. |
| Custo | Grátis, mais o seu próprio tempo por 14 dias. | A partir de US$ 19,99 para 12 testadores. |
Nenhum dos caminhos muda a forma como a solicitação é analisada. O teste gerenciado tira o risco de participação; ele não responde por você às perguntas sobre feedback e prontidão, e ninguém pode prometer uma aprovação.
Suporte para o teste
Nossa sugestãoSe o seu diagnóstico aponta para a participação, a PrimeTestLab conduz o teste fechado para você: testadores participando em dispositivos reais pelos 14 dias completos, mantidos acima do mínimo, feedback em um só lugar. Se a lacuna for um login quebrado ou um problema de política apontado, mais testadores não vão resolver.
Starter
12 testadores reais
$19.99
Enterprise
25 testadores reais
$27.99
Professional
20 testadores reais
$29.99
Esse número de conclusão é o nosso próprio registro operacional, não uma taxa de aprovação do Google: o teste gerenciado manteve a contagem de testadores exigida e um período ininterrupto de participação até a data final.
Perguntas e respostas
Por que o Google Play diz "More testing required"?
Sua solicitação de acesso de produção foi analisada e ainda não foi aprovada, então o Google está pedindo que você continue testando. Os exemplos que ele dá incluem não ter 12 testadores participando e testadores que não se engajaram durante o teste fechado. Leia tanto a decisão no Play Console quanto o e-mail enviado ao proprietário da conta para ver as preocupações identificadas.
Preciso de 12 testadores participando por 14 dias contínuos?
Para uma conta pessoal de desenvolvedor criada após 13 de novembro de 2023, sim. O Google exige um teste fechado com no mínimo 12 testadores participando pelos últimos 14 dias de forma contínua. Exatamente 12 já qualifica, e endereços convidados não contam até que cada pessoa aceite participar.
Um testador saiu do teste durante os 14 dias. Preciso começar tudo de novo?
Não necessariamente. A continuidade é medida por testador, então quem manteve o próprio período ininterrupto continua contando. O período interrompido em si não conta, mas um testador que volta pode qualificar de novo depois de um novo período ininterrupto de 14 dias participando. O que não acontece é herança: quem entra depois, como substituto, começa o próprio período em vez de assumir o tempo já corrido do testador que saiu.
O que responder se o teste não revelou nada para corrigir?
Descreva os fluxos que você verificou, os dispositivos em que rodaram e os resultados, e depois explique a sua decisão de prontidão a partir desse registro. Nenhuma cota de versões aparece na orientação analisada, e nada nela diz que você precisa publicar uma atualização durante o teste. Inventar um problema só deixa a resposta mais fraca.
Posso solicitar de novo logo depois de uma recusa?
Solicite de novo assim que a causa-raiz estiver corrigida, e deixe a sua própria prontidão definir o momento. Algumas mensagens indicam um período adicional de teste fechado; outras só dizem para continuar testando, sem prazo nenhum. A ausência de um prazo não é permissão para solicitar de novo imediatamente, e a orientação pública analisada não especifica uma regra universal de reinício.
Quanto tempo o Google leva para analisar uma solicitação de acesso de produção?
O Google descreve a análise como algo que costuma levar sete dias ou menos, e diz que às vezes pode demorar um pouco mais. Isso cobre apenas a análise. O teste fechado que vem antes é um período separado de 14 dias contínuos, e qualquer teste adicional que a sua decisão pedir é separado de novo.
Seu próximo passo
Volte à verificação de cinco minutos e pegue a primeira pergunta que você não conseguiu responder. Corrija essa única coisa, anote o que o teste realmente estabeleceu e solicite de novo seguindo as instruções da sua própria conta. Se a lacuna for de participação e não de evidência, garanta os testadores antes da próxima tentativa, para que a janela não se rompa de novo no meio do teste.
Em resumo
"More testing required" é uma decisão sobre o teste que você fez, as respostas que você deu e se o app está pronto. O piso é fixo e público: no mínimo 12 testadores participando por 14 dias contínuos, para uma conta pessoal de desenvolvedor criada após 13 de novembro de 2023. Acima dele, as suas respostas devem explicar com precisão o que o teste estabeleceu. Uma redação clara não substitui um teste significativo nem um app que funciona.
Documentação oficial do Google