Define escopo, camadas, fixtures, cenários, casos de borda, asserções e critérios de aceitação para testes móveis. Esta referência fixa o limite de adoção, comportamento em falhas e evidências observáveis, deixando os limites específicos do ambiente configuráveis.
Status do pacote: contexto de referência pronto para revisão humana. O contrato e os cenários de teste estão completos, mas não se afirma que uma implementação adotante os tenha aprovado.
Decisão
Para testes móveis, adote um plano de teste baseado em risco versionado com fixtures reproduzíveis e gates próprios. Trate o bloco como um contrato de lançamento e regressão construído a partir de casos representativos positivos, de limite, negação, falha e recuperação. Este pacote é um contrato de referência: a equipe adotante deve escolher limites numéricos, provedores, jurisdições e responsáveis operacionais com base em evidências do seu próprio ambiente.
Escopo
- Os atores, entradas, saídas, estados, versões de política ou esquema e resultados visíveis externamente descritos por este bloco de teste móvel.
- Interfaces primárias e alternativas, trabalhos em segundo plano, caches, integrações, caminhos de suporte e evidências que podem exercitar o mesmo limite.
- Configuração específica de adoção, implantação, recuperação e responsabilidades de verificação necessárias para aplicar a referência com segurança.
Fora deste bloco
- Escolher um fornecedor universal, framework, jurisdição, limite numérico, período de retenção ou objetivo de nível de serviço para todos os adotantes.
- Afirmar que os cenários empacotados foram executados contra uma implementação a jusante ou que esta referência concede certificação legal, de segurança ou acessibilidade.
Contrato
- Relacione cada teste crítico a um comportamento, limite, incidente ou risco e afirme resultados visíveis externamente ou evidências duráveis.
- Controle relógio, aleatoriedade, identidade, rede e dependências de dados para que reexecuções distingam defeitos do produto de instabilidade da fixture.
- Mantenha dados sensíveis de produção e credenciais fora das fixtures; gere casos sintéticos representativos de limite e abuso.
- Defina critérios de retentativa, quarentena, propriedade, expiração e remoção para testes instáveis; retentativas não podem transformar uma falha em sucesso silencioso.
- Registre versão da fixture, ambiente, configuração, resultado observado e localização da evidência para cada execução decisória.
- Separe falha do produto, falha de dependência, falha da infraestrutura de teste e evidência inconclusiva nos relatórios.
- Cubra combinações suportadas de sistema operacional, classe de dispositivo, tela, entrada, localidade, acessibilidade, permissão, armazenamento, energia, rede e ciclo de vida do aplicativo por risco.
- Use contas e fixtures determinísticas, isole efeitos de push e armazenamento, capture evidências de dispositivo e build, e teste interrupção, background, atualização, restauração e recuperação em recursos baixos.
Orientações de implementação
- Construa o menor conjunto determinístico de fixtures que abranja classes de risco, adicionando casos derivados da produção somente após revisão segura de privacidade.
- Modele entradas, saídas, atores, estados, invariantes, efeitos colaterais e evidências de testes móveis antes de selecionar detalhes de framework ou fornecedor.
- Armazene a versão aplicável do contrato ou política de testes móveis com estado material para que migrações, replay e decisões de suporte permaneçam atribuíveis.
- Introduza o caminho por trás da implantação controlada, compare resultados esperados e observados, e mantenha uma rota de recuperação testada até que a evidência de adoção esteja completa.
Tratamento de falhas e salvaguardas
- Um ambiente de teste quebrado reporta um resultado de infraestrutura distinto da falha do produto e não pode satisfazer um gate de lançamento obrigatório.
- Estado inválido ou contraditório de teste móvel é rejeitado ou colocado em quarentena; a implementação nunca supõe um valor que amplie autoridade ou duplique um efeito.
- Retentativas são limitadas e usam identidade durável; após esgotamento, o trabalho alcança um estado terminal inspecionável com um responsável contabilizável.
Verificação e operações
- Execute a suíte duas vezes a partir de um estado limpo e confirme que ordenação, retentativas e execução paralela não alteram o veredito.
- Monitore sucesso, negação, falha de validação, falha de dependência, esgotamento de retentativa e recuperação por versão do contrato sem dimensões sensíveis do payload.
- Reexecute fixtures positivas e negativas pareadas após mudanças em política, esquema, dependência, migração ou limite e preserve a evidência resultante.
Suposições de adoção
- Nomes e valores no exemplo são uma fixture concreta, não padrões universais; adotantes os substituem por meio de evidências documentadas e propriedade.
- O sistema adotante pode fornecer identidade autenticada, versões duráveis de operação ou registro, telemetria limitada e um caminho controlado para mudanças.
Os exemplos com aparência executável neste pacote são fixtures e contratos de aceitação. Execute o validador da coleção para verificar estrutura e metadados, depois traduza e execute os cenários no repositório alvo antes de registrar evidências da implementação.