Como configurar o teste interno do Google Play (2026)

O teste interno é a única faixa da Play Console que se comporta como um desenvolvedor espera que um software se comporte: você envia um build, ele aparece, as pessoas instalam. Até o dia em que não aparece. Aí você fica encarando um link que abre uma página da Play Store dizendo que o app não está disponível para a sua conta, sem código de erro, sem diagnóstico, e um artigo de ajuda que mistura três faixas de teste ao longo de centenas de linhas. Este guia separa a faixa interna das outras duas, entrega o caminho na Play Console e as regras da lista de testadores na ordem em que você realmente precisa delas, e depois dedica tempo de verdade à família de falhas que lota as discussões de suporte. Onde as próprias páginas do Google divergem entre si, e sobre prazos elas divergem bastante, as duas leituras aparecem aqui, não só a mais conveniente. Tudo nesta página está atualizado em 12 de agosto de 2026.

Como configurar o teste interno?

Antes de começar

Prepare o app, o build, as contas dos testadores e o seu próprio acesso à Play Console. Repare no que não é exigido: ficha da loja pronta, capturas de tela, classificação de conteúdo ou formulário de segurança de dados preenchido. O Google permite explicitamente que um teste interno rode antes de o app estar totalmente configurado. Verificado

• 01
  Um app que já exista na Play Console Criado, não necessariamente preenchido. O primeiro artefato que você enviar fixa o nome do pacote daquele app e ele não pode mais ser alterado, então confirme que o applicationId é mesmo o que você quer manter.
• 02
  Um app bundle válido A formulação do Google é "um app bundle válido". Esse é o único requisito de artefato para colocar um build interno inicial nas mãos dos testadores.
• 03
  Os endereços de e-mail dos testadores Contas do Google. A Ajuda atual especifica uma Conta do Google com Gmail, ou uma conta do Google Workspace. Colete o endereço exato em que cada pessoa vai estar conectada, porque é a essa identidade que a faixa inteira está atrelada.
• 04
  O acesso na Play Console para fazer isso Proprietários e administradores já têm. Um usuário delegado precisa da permissão para lançar apps nas faixas de teste, e gerenciar a faixa e as listas de testadores dela pode exigir a permissão separada de gerenciar faixas de teste e editar listas de testadores. Um botão de lançamento ausente ou esmaecido é problema de acesso, não de build.
• 05
  Assinatura de apps do Play, só na primeira versão Na primeira versão de um app, a Play Console conduz você pela configuração da Assinatura de apps do Play (Play App Signing). É uma etapa única, que aparece durante o envio em vez de ser algo para providenciar antes, mas vale saber que ela vem aí antes de começar.

Etapa 1: abra a faixa de teste interno

Selecione o app e vá em Testar e lançar › Teste › Teste interno. O Google documenta esse caminho de duas formas diferentes. O artigo da Ajuda da Play Console sobre configurar um teste abrevia para Teste › Teste interno, enquanto outra página atual da Ajuda mostra o menu principal completo. As duas descrevem o mesmo destino, então, se o seu console exibir um menu mais curto do que o escrito aqui, você não está no lugar errado.

Etapa 2: crie a sua lista de testadores internos

Abra a aba Testadores na faixa de teste interno e escolha Criar lista de e-mails. Dê um nome à lista, adicione os endereços, salve as alterações e crie a lista. Os endereços podem ser digitados direto na interface separados por vírgula, ou enviados em um CSV. É pelo CSV que as listas são destruídas em silêncio, porque ele carrega três regras documentadas uma única vez e nunca repetidas.

Verificador de lista de testadores

Etapa 3: adicione a lista e um canal de feedback

De volta à aba Testadores, selecione a lista ou as listas de usuários que você quer usar nessa faixa e informe ao Google um URL ou e-mail de feedback. Esse destino aparece para os testadores na página de participação, o que faz dele o único caminho embutido para eles avisarem que algo quebrou.

Etapa 4: crie e lance a versão

Escolha Criar nova versão, adicione o app bundle, revise e faça o lançamento com os controles atuais do console. As variantes da Play Console diferem tanto no texto exato dos botões que decorar uma sequência de cliques além disso atrapalha mais do que ajuda, então a instrução para onde a documentação atual do Google para.

Etapa 5: copie e compartilhe o link de participação

Copie o link compartilhável dos testadores e envie. Esta é a etapa que confunde desenvolvedores desde pelo menos 2018, e a confusão é totalmente compreensível: todo outro sistema de convite da internet manda um e-mail, e o fluxo documentado do Google entrega um link para você distribuir. Não conte com a Play Console para convidar os testadores por você.

Duas condições determinam se esse link já existe. O link de participação só aparece quando o status do app é Publicado. Enquanto o app estiver em Draft ou Pending publication, não há nada para copiar, e reler a aba Testadores mil vezes não faz um link surgir. Verificado

Etapa 6: cada testador entra no teste e instala

A última etapa é do testador, e é a única que você não pode fazer por ele. Cada pessoa abre o seu link conectada exatamente na conta que você adicionou, conclui a participação naquela página, depois segue o link da Play Store e instala. Até isso acontecer, essas pessoas estão elegíveis mas não inscritas, e testador elegível não recebe nada. Envie o link com o nome da conta que você convidou escrito ao lado, porque entrar no teste com a identidade errada é uma das falhas mais relatadas desse fluxo e parece exatamente um link quebrado.

Quem faz o quê

A sequência inteira, em uma tabela

Deslize a tabela para o lado para ver todas as colunas

Quanto tempo até os testadores instalarem?

Cinco relógios diferentes correm durante um teste interno, e as reclamações de prazo quase sempre nascem de comparar os dois errados. O build chegar ao sistema de distribuição do Google é uma coisa. O link de participação ficar no ar para o testador é a segunda. Uma mudança publicada alcançar quem já entrou é a terceira. O app instalado se atualizar sozinho é a quarta. E a ficha provisória da loja ser substituída pelo nome real do app é a quinta, que é o motivo de um build interno perfeitamente funcional ainda parecer inacabado por alguns dias.

Minha espera ainda é normal?

A única versão útil dessa pergunta inclui o que você está esperando, porque a resposta varia por um fator de centenas entre as etapas. A ferramenta abaixo pede as duas coisas, cita o que o Google realmente publica para aquela etapa e deixa claro que os pontos de corte numéricos são a leitura deste guia, não do Google.

Relógio de propagação

Todos os relógios, lado a lado

Deslize a tabela para o lado para ver todas as colunas

O ponto editorial que vale levar daqui: segundos, minutos, algumas horas e até 48 horas são todos verdadeiros ao mesmo tempo, porque descrevem pedaços diferentes do mesmo processo. Qualquer artigo que achate tudo isso em um número só vai enganar alguém exatamente no momento em que essa pessoa precisa de precisão. Verificado

Uma versão interna espera pela análise do Google?

A formulação importa aqui, porque as duas fontes do Google não dizem a mesma coisa do mesmo jeito. A página de produto do teste interno divulga o recurso como uma forma de distribuir builds sem precisar esperar pelas análises de apps. A Central de Ajuda da Play Console é mais cautelosa: diz que os testes internos podem não passar pelas análises habituais de política e segurança do Play.

Ou seja, a afirmação correta é que o teste interno normalmente deixa você distribuir sem esperar pelo fluxo padrão de análise de apps, e a incorreta é que versões internas nunca são analisadas. O Google não prometeu isenção categórica de toda análise, e escrever que prometeu é como um artigo fica errado na primeira vez que a versão interna de alguém for retida. Verificado, com ressalva de formulação

O teste interno conta para os 12 testadores?

Este é o mal-entendido mais caro de todo o assunto, e ele está sendo espalhado ativamente. Pelo menos um artigo de 2026 muito compartilhado descreve o requisito obrigatório como algo que se cumpre na faixa de teste interno. A própria página de requisitos do Google diz o contrário, em palavras que não deixam margem para interpretação.

A regra de decisão, em uma linha

Use o teste interno para um QA privado e rápido com gente de confiança. Use o teste fechado quando precisar do teste obrigatório de pré-produção. É essa a regra inteira, e é de propósito tudo o que este guia diz sobre a comparação: a análise completa das três faixas está em teste interno, fechado e aberto, que foi feito para essa pergunta.

Deslize a tabela para o lado para ver todas as colunas

A quem o requisito realmente se aplica

O requisito tem um escopo, e é nesse escopo que mora quase toda a confusão. A página do Google documenta a regra para as contas pessoais de desenvolvedor qualificadas criadas depois de 13 de novembro de 2023. O Google anunciou a política em 9 de novembro de 2023, e é por isso que você vê as duas datas citadas como início.

Sobre contas organizacionais, tome cuidado com a formulação. A página de requisitos do Google restringe a regra às contas pessoais; ela não traz nenhuma frase dizendo que contas organizacionais estão isentas. A formulação defensável é que o requisito está documentado para as contas pessoais de desenvolvedor qualificadas e que a página citada não o impõe às contas organizacionais. Escopo inferido

Participar por 14 dias não é a mesma coisa que usar por 14 dias

O limite numérico é escrito em termos de testadores participando continuamente, não em termos de uso diário. Essa é a parte mensurável. Separadamente, o Google avalia o que você relata sobre o seu teste quando pede o acesso de produção e pode exigir mais testes se a contagem de testadores ou o engajamento for insuficiente. As páginas concorrentes costumam achatar essas duas coisas em uma regra inventada sobre minutos de uso por dia.

Ou seja: o limite é a continuidade da participação, e o engajamento é avaliado em cima disso, não no lugar disso. O que isso significa na prática para um teste em andamento está em a regra dos 14 dias consecutivos e em o requisito dos 12 testadores explicado. Verificado

Por que meu link de teste interno não funciona?

Esta é a falha que lota as discussões da comunidade sobre teste interno, e a menos documentada de todas. Os desenvolvedores chegam nela depois de terem feito tudo o que a Play Console pediu, e é por isso que a experiência desnorteia tanto: não há código de erro, não há diagnóstico, e a página anuncia alegremente que o app não está disponível para a sua conta, como se a conta fosse o problema, e não o sintoma. Os relatos vão de uma pergunta no Stack Overflow de 2018 até discussões da Comunidade de Desenvolvedores do Google de julho de 2026, em inglês e em português, descrevendo o mesmo punhado de causas.

O movimento útil é parar de pensar nisso como um link quebrado e começar a pensar como um circuito. A regra de entrega do Google é uma série de condições, e um contato aberto interrompe tudo o que vem depois. Quatro estados cobrem as causas que mais se repetem nesses relatos: fora da lista de testadores, na lista mas sem ter aceitado participar, participando mas usando a Conta do Google errada e configurado corretamente e ainda propagando. O último nem é um defeito, e é justamente por isso que tanto tempo é desperdiçado com ele.

Encontre a chave aberta

Ajuste cada chave abaixo conforme o que você confirmou de fato, não conforme o que você supõe. As chaves estão em ordem de quão barato é verificar cada uma, então a primeira que continuar aberta é a que vale resolver primeiro.

Simulador das chaves de acesso

“Este app não está disponível para sua conta”

O acesso do testador está preso a uma identidade, não a um aparelho nem a um link. O Google exige que a conta esteja incluída na configuração de testadores e tenha aceitado participar daquele programa de teste. Se faltar uma das metades, a Play Store não tem como distinguir aquela pessoa de um estranho que achou o seu URL.

O motivo de isso aparecer tanto na prática é banal: celulares e navegadores costumam estar conectados a várias Contas do Google, e a que abre um link nem sempre é a que você convidou. Discussões da Comunidade de Desenvolvedores do Google de março de 2026 descrevem testadores que não conseguem nem trocar para a identidade certa, porque o seletor de contas se comporta de um jeito diferente do esperado, e discussões em português de meados de 2025 relatam o mesmo padrão, com uma resposta que aponta direto para a conta selecionada no Google Play. Relatado pela comunidade

Não existe link de participação para copiar

Cheque o status do app antes de qualquer outra coisa. O Google mostra o link de participação apenas quando o status do app é Publicado. Em Draft ou Pending publication o link não está escondido nem atrasado: ele ainda não existe. Esta é a correção mais limpa de todo o conjunto de diagnósticos, porque a condição é binária e visível no seu próprio console. Verificado

Está publicado, mas ninguém acha na pesquisa do Play

Isso é o comportamento esperado, não um defeito. O Google afirma que um teste interno ou fechado anterior ao teste aberto ou à produção não aparece na pesquisa da Play Store. Testadores que ouvirem "pesquisa o app no Play" vão falhar todas as vezes, por mais correta que esteja a sua configuração, e vão dizer, com razão, que o app não existe.

Envie o link direto. Diga na mensagem, com todas as letras, que pesquisar não vai funcionar, porque é a primeira coisa que qualquer pessoa tenta. Verificado

Alguns testadores continuam na versão antiga

Trabalhe três causas em ordem. Primeiro, propagação: mudanças publicadas depois podem levar várias horas para chegar aos testadores, então uma atualização recente pode simplesmente não ter chegado. Segundo, códigos de versão: o usuário recebe o maior código de versão compatível entre todas as faixas para as quais está elegível. Como todo usuário está elegível para a produção, um código de versão de produção mais alto pode ser entregue no lugar de uma versão de teste mais baixa, o que cria aquela situação confusa em que o seu build interno mais novo é real, está correto e mesmo assim não é o que o testador tem. Terceiro, elegibilidade de faixa: uma conta participando do teste interno não fica elegível para receber builds fechados ou abertos, então, se você levou o trabalho para outra faixa, aquela conta está olhando para a faixa errada. Verificado

Está tudo certo e mesmo assim falha

Agora, e só agora, vale tentar os remédios da comunidade: reiniciar o aparelho, reiniciar a Play Store, limpar o cache ou os dados da Play Store, ou abrir o link em um perfil de navegador limpo. Isso vem de discussões da Comunidade de Desenvolvedores do Google, não de política do Google, e é relatado como algo que funcionou para alguém, não como comportamento documentado. Colocar essas tentativas em primeiro lugar é como se perdem dias, porque elas não corrigem um problema de configuração e ainda fazem um atraso de propagação passar por solução. Relatado pela comunidade

Existe também um caso limite genuíno. Uma discussão da comunidade de fevereiro de 2026 descreve um link de teste interno que nunca funcionou, e outra de maio de 2026 relata um erro HTTP 500 na página de participação. Não há causa raiz estabelecida para nenhum dos dois, e inventar uma explicação técnica seria pior do que admitir isso. Se a sua configuração está comprovadamente correta, as janelas de propagação já passaram e a falha é persistente ou devolve erro de servidor, esse é um momento razoável para acionar o suporte da Play Console em vez de continuar mudando configurações. Causa não verificada

Do sintoma à correção, com grau de evidência

Deslize a tabela para o lado para ver todas as colunas

Limites e regras que quase todo mundo erra

Deslize a tabela para o lado para ver todas as colunas

Teste interno ou compartilhamento interno de apps

São dois recursos diferentes com nomes confusamente parecidos, e escolher o errado custa uma tarde. O teste interno é a faixa formal que este guia inteiro descreve: uma versão, uma lista gerenciada de até 100 testadores, a participação de cada um e atualizações entregues pelo Google Play. O compartilhamento interno de apps (internal app sharing) é uma ferramenta de compartilhamento rápido que pega um APK ou app bundle enviado e devolve um link de download para você repassar. Ele tem controles de acesso próprios, só que outros: a página do Google sobre o recurso deixa você restringir os downloads a listas de e-mails ou liberar o link para qualquer pessoa a quem você enviar, e nos dois casos o testador precisa antes ativar o compartilhamento interno de apps dentro do app da Play Store dele.

A regra prática: use o compartilhamento interno de apps para jogar um build na mão de um colega nos próximos dez minutos, e use a faixa de teste interno quando quiser histórico de versões, lista de testadores e um build que dê para promover depois. A expiração em 60 dias é o detalhe que pega as pessoas, porque um link que funcionava em um relatório de bug de dois meses atrás está simplesmente morto, e não mal configurado. Nenhum dos dois recursos conta para o teste fechado com 12 testadores. Verificado

A pegadinha das compras no app

Não repita a afirmação comum de que tudo é gratuito durante o teste interno. A regra do Google separa o app do que é vendido dentro dele. O app pago em si é gratuito para o testador interno instalar. As compras no app continuam cobrando, a menos que a conta daquele testador também esteja configurada como testadora de licença.

Essa distinção vale dinheiro de verdade em um teste que envolve assinaturas, e pelo menos um artigo comparativo bem posicionado hoje afirma exatamente o contrário. Se os seus testadores vão passar por um fluxo de compra, configure o teste de licença antes ou espere cobranças reais. Verificado

Duas coisas que não são problema seu

Boa parte dos conselhos genéricos sobre teste interno que circulam por aí manda você consertar o que não pode ser a causa, o que desperdiça tempo e às vezes quebra uma configuração que estava funcionando.

Afirmações checadas, com veredito

Cada linha abaixo é uma afirmação que circula por aí sobre o teste interno. A coluna de veredito traz o que as fontes primárias sustentam, não o que soa razoável.

• Falso
  “O teste interno vale como o teste dos 12 testadores.” A página de requisitos do Google pede especificamente um teste fechado. Este é o erro mais caro do assunto, porque custa às pessoas a janela inteira de 14 dias.
• Desatualizado
  “Você ainda precisa de 20 testadores.” Histórico desde 11 de dezembro de 2024. O mínimo atual é 12.
• Falso
  “Testadores internos recebem todas as compras de graça.” Só o app pago em si é gratuito. As compras no app são cobradas, a menos que o teste de licença esteja configurado.
• Falso
  “Se o seu testador está no exterior, adicione o país dele.” O Google isenta o teste interno dessa limitação de distribuição de forma explícita.
• Enganoso
  “Se o link não funciona na hora, ele está quebrado.” O próprio Google prevê algumas horas para o primeiro link e várias horas para as mudanças posteriores.
• Enganoso
  “Os testadores recebem o link de participação por e-mail automaticamente.” O fluxo documentado pelo Google é o desenvolvedor copiar o link compartilhável e distribuir. Não planeje nada contando com a Play Console para convidar os testadores.
• Parcial
  “Dá para usar um Grupo do Google no teste interno.” A Ajuda atual do Console documenta listas de e-mails para o teste interno e Grupos do Google para o teste fechado. O recurso testers da API de publicação aceita grupos de forma mais ampla, mas isso não determina o comportamento do Console em 2026 nesta faixa. Use o método documentado, a lista de e-mails, e não planeje contando com um grupo.
• Parcial
  “O Google permite exatamente uma faixa interna.” A API de publicação expõe a faixa interna padrão como uma faixa única e conhecida, e a Ajuda documenta faixas fechadas adicionais com nome próprio sem publicar um número de faixas internas. Diga "a faixa de teste interno padrão" em vez de afirmar que existe um limite rígido.
• Verdadeiro
  “Dá para rodar um teste interno antes de terminar a ficha da loja.” O Google diz que um app bundle válido já basta para distribuir internamente antes de o app estar totalmente configurado.
• Verdadeiro
  “O feedback dos testadores de um teste não vai prejudicar a minha nota pública.” O Google afirma que o feedback de usuários de teste não afeta a nota pública do app.

Encerrar um teste interno

Pause a faixa. Os testadores ficam com a cópia que já instalaram, mas param de receber atualizações de teste por ela. Vale saber disso antes de supor que pausar uma faixa apaga o app do celular de alguém, porque não apaga. Verificado

Como levar um build para o teste fechado?

Esta é a etapa que a maioria das pessoas alcança depois de um teste interno bem-sucedido, e é aqui que o relógio do acesso de produção começa de verdade. A instrução abaixo evita de propósito um roteiro botão a botão, porque as variantes da Play Console diferem e um caminho de cliques decorado é a primeira coisa a quebrar.

1. 01
   Abra a faixa de destino Vá em Testar e lançar › Teste › Teste fechado e gerencie a faixa fechada que você quer usar.
2. 02
   Crie uma versão nessa faixa A versão do teste fechado é uma versão própria, mesmo carregando o artefato que você já testou.
3. 03
   Reaproveite o artefato testado com Adicionar da biblioteca Selecione a versão que você enviou durante o teste interno em vez de enviar o bundle de novo. Essa é a parte documentada na Ajuda atual do Google sobre versões (resposta 9859348). Verificado
4. 04
   Configure os testadores do teste fechado Use os controles de testadores da própria faixa fechada. Para o teste fechado, a Ajuda atual aceita listas de e-mails ou Grupos do Google, o que é uma diferença real em relação à faixa interna.
5. 05
   Revise e faça o lançamento Depois compartilhe o link de participação do teste fechado do mesmo jeito que você compartilhou o interno. Valem as mesmas duas condições: estar na lista e ter aceitado participar.

Dá para manter os mesmos testadores?

Sim como pessoas, não como participações simultâneas, e é essa distinção que estraga mais testes fechados do que qualquer outra coisa nesta etapa.

Uma conta que está participando do teste interno não fica elegível para receber builds de teste aberto ou fechado. A orientação do Google é que o testador saia do interno primeiro e só então entre no teste fechado. Ou seja, aquele seu grupo de QA interno cuidadosamente montado pode virar o grupo do teste fechado, mas cada pessoa precisa sair ativamente da faixa interna antes de conseguir ver qualquer coisa na fechada.

Deslize a tabela para o lado para ver todas as colunas

Daqui em diante a mecânica é outro assunto: recrutar gente que vai continuar participando por 14 dias contínuos, fazer com que essas pessoas sejam contadas corretamente e passar pelo formulário de acesso de produção. Isso está em como convidar testadores para o teste fechado, por que a Play Console mostra 0 testadores participando e o formulário de acesso de produção.

Onde entra a PrimeTestLab

Vale ser preciso sobre essa passagem de bastão, porque as duas faixas falham por motivos completamente diferentes. O teste interno falha na configuração: um link que ainda não existia, uma conta que nunca aceitou participar, uma janela de propagação que ninguém esperou terminar. Isso se resolve lendo com atenção, que é para o que servem os primeiros dois terços deste guia.

O teste fechado falha por causa de gente. A condição numérica publicada pelo Google é de no mínimo 12 testadores participando do teste fechado nos últimos 14 dias continuamente, o que na prática significa doze pessoas de verdade que entram e que ainda estão lá na segunda semana. Além dessa contagem, você quer esses testadores instalando e usando o build para valer, porque o Google pergunta sobre engajamento, uso de recursos e feedback quando analisa o pedido de acesso de produção. Nenhuma das duas metades é um problema de documentação, e nenhum conhecimento de console resolve isso. A maioria dos desenvolvedores descobre isso no momento em que termina o teste interno e percebe que o requisito não andou nem um passo.

Fazer o teste fechado por conta própria ou passar adiante

Deslize a tabela para o lado para ver todas as colunas

Sim, 25 testadores hoje custam menos que 20. Isso é promoção, não erro de digitação: o Enterprise está com o maior desconto dos três planos neste momento, o que também dá a ele o menor custo por testador, cerca de $1.12 contra $1.50 no Professional. Os dois planos fazem o mesmo teste fechado; a promoção é o único motivo de a ordem se inverter, e a página de preços tem o valor atualizado, caso ele tenha mudado desde que isto foi escrito.

Em 7.400+ apps de 120+ países, mantemos uma taxa de sucesso de 99,9% no requisito de teste fechado. O que não vamos dizer é que a aprovação é garantida. O Google analisa o pedido de acesso de produção pelos critérios dele e pode pedir mais testes, e quem promete um resultado certo está falando de algo que não controla. O que assumimos é a parte que controlamos: se o teste não passar, você tem novo teste grátis ou reembolso total.

Perguntas frequentes sobre o teste interno

Conclusão