Um grande salvamento quebrado é evidência, não uma explicação.
Quando um salvamento falha ao carregar, uma busca desaparece, ou uma migração viola uma regra de jogo, o primeiro artefato pode ser enorme: centenas de campos, coleções aninhadas, um longo histórico de ação, um instantâneo de conteúdo e um ambiente que não existe mais. Esse artefato é valioso porque reproduz o problema. É difícil porque ele dá a um desenvolvedor muito mais informações do que eles podem raciocinar ao mesmo tempo. Ler isso linha por linha muitas vezes produz suposições em vez de uma explicação.
A depuração Delta muda o objetivo. Em vez de pedir a uma pessoa para identificar o valor relevante, pergunte a um predicado determinístico se um candidato ainda demonstra a falha. Em seguida, remova ou simplifique partes do estado enquanto o predicado permanece verdadeiro. O resultado final é um caso de regressão mínimo: pequeno o suficiente para rever, estável o suficiente para repetir e explícito sobre o invariante que permanece quebrado.
Minimal não significa visualmente minúsculo ou universalmente menor. O objetivo útil é um contraexemplo materialmente reduzido sob um custo limitado. Um redutor pode parar quando nenhum grupo inteiro pode ser removido, quando um orçamento de execução está esgotado, ou quando o dispositivo é compreensível o suficiente para se tornar um teste de regressão. A propriedade preservada importa mais do que um resumo ideal.
Estabelecer reprodutibilidade antes da redução
A redução só funciona quando a falha é repetivel. Primeiro capture o predicado preciso: o carregador atual lança um erro classificado, um retorno invariante é falso, um estado resultante difere semanticamente do resultado esperado, ou uma sequência de ação produz uma concessão inválida? Evite usar um predicado vago como “o jogo parece errado”. O predicado deve retornar a mesma resposta para as mesmas entradas, ou o redutor irá perseguir o ruído.
Grave o ambiente ao lado do candidato: compilação ou commit da aplicação, versão de migração, versão do adaptador, instantâneo de conteúdo e configuração, semente determinística, pressupostos da plataforma e hash de fixação inicial. Se um relógio ao vivo, fonte aleatória, busca de configuração remota ou trabalhador de fundo puder alterar o resultado, substituí- lo por um limite determinístico de teste ou gravá- lo como uma limitação explícita. O redutor não deve testar secretamente um novo ambiente em cada tentativa.
Para falhas de sequência de ação, preserve o estado inicial e as ações ordenadas separadamente. Um estado final pode ocultar a operação que o produziu. Um conjunto de sequências pode expressar “partir deste perfil, realizar essas sete solicitações, então o invariante falha.” Essa separação permite que o redutor encolhe campos, coleções e ações sem confundir um tipo de evidência para outro.
Reduzir campos e coleções em partições
Comece com partições grosseiras. Divida o nível superior salvar em grupos de campo, remova um grupo de uma cópia de trabalho e execute o predicado. Se a falha persistir, mantenha a remoção; se ela desaparecer, restaure o grupo e subdivida- a. Isto é mais eficiente do que remover um campo de cada vez de um objeto grande. Continue em registros aninhados e coleções assim que uma região relevante for identificada.
As colecções precisam de cuidados especiais. Os itens de inventário, os registos de procura, os contadores e o histórico de eventos podem referir- se uns aos outros. A remoção de um item pode alterar os índices da lista, as regras de capacidade ou os saldos agregados. Normalize a ordenação onde a ordem não é significativa, preserve identificadores estáveis onde as referências as exigem e indique se um item em falta deve estar ausente, nulo ou representado por um recurso legado explícito. Um redutor não deverá transformar um defeito de migração real num erro de análise causado por uma entrada de teste mal formada.
Use o valor encolhendo após a redução estrutural. Mova inteiros para zero ou um limite importante, encurtar strings, substituir um identificador longo por um identificador de teste seguro, e reduzir timestamps para uma época estável apenas quando o seu valor exato não é a condição sob teste. Cada simplificação deve manter o predicado verdadeiro. Isto muitas vezes revela que um bug de perfil aparente complexo é realmente “um ID de item aposentado mais um inventário completo” ou “um contador negativo após uma versão ignorada”.
Reduzir as sequências de acção sem alterar o seu significado
Algumas falhas surgem apenas após o tempo: uma tentativa de compra após uma reconexão, uma gravação após uma atualização de configuração ou uma migração após um tutorial interrompido. Aplique a mesma ideia de particionamento às ações. Remova uma metade contígua da sequência, repita e mantenha a remoção se o invariante ainda falhar. Depois subdivide. Preservar as ações de configuração necessárias, mas desafie a navegação incidental, leituras repetidas e mutações não relacionadas.
As ações devem ter parâmetros estáveis e expectativas de resultados. Um redutor que substitui todas as solicitações por um ID de transação aleatória recente não está mais testando a semântica de repetição original. Um redutor que remove a carga inicial de flag de recursos pode alterar o contexto de configuração. Grave a identidade da ação, entradas relevantes, fonte confiável versus não confiável, e o ponto em que o invariante é verificado. Isto torna a sequência final útil tanto para desenvolvedores quanto para QA.
Quando uma sequência depende da concorrência, escolha um esquema determinístico. Registre a ordem em que os trabalhadores ou clientes simulados atingem limites críticos. Se a falha só ocorre sob uma corrida, um teste pode precisar de uma barreira controlada em vez de chamadas de sono dependentes do tempo. O objetivo não é fingir que a concorrência é simples; é fazer com que a saída observada reprodutível o suficiente para raciocinar.
Preservar o invariante violado no artefato final
Um pequeno dispositivo sem uma asserção torna- se outro arquivo misterioso. Armazene o invariante violado ao lado do dispositivo em termos claros: direito duplicado para uma identidade de transação, referência de catálogo desconhecida após migração, moeda negativa, inacessível completada quest ou descompasso semântico após uma viagem de ida e volta. Inclua a classificação esperada e a observada. O dispositivo deve falhar por uma razão, não apenas porque uma função retorna falsa.
Compare antes e depois do estado semanticamente. Um 'diff' em bruto poderá conter actualizações reescritas, arrays reordenados, IDs gerados ou formatação de serialização. Um 'diff' semântico realça os valores que afectam o invariante. Ele poderá comunicar que um item mudou de um 'fallback' legado válido para um ID desconhecido, ou que um saldo foi incrementado duas vezes para a mesma chave de registo. Mantenha o normalizador estreito e documentado; um 'normalizador' amplo poderá apagar o próprio defeito que o redutor pretende preservar.
Escreva um manifesto de repetição com a localização do dispositivo, o hash de origem, o hash reduzido, a impressão digital do ambiente, a semente determinística, a sequência de acção, se existir, o nome predicado e o resultado esperado. Este manifesto permite que outra pessoa execute o caso sem ter acesso ao estado original sobredimensionado. Ele também torna o dispositivo adequado para o CI, onde um caso minimizado deve ser rápido e claro em vez de dependente de uma máquina local privada.
Saber quando a redução deve parar
Cada tempo de execução de predicados. Algumas migrações são lentas; alguns cenários precisam de adaptadores de serviço; algumas condições de falha são flácidas até que um ambiente seja corrigido. Defina orçamentos para tentativas, tempo de parede e contagem de artefatos. Pare quando a instalação for pequena o suficiente para explicar o problema, quando nenhuma partição pode ser removida sem perder a falha, ou quando o trabalho restante requer julgamento de domínio em vez de encolhimento mecânico.
A redução tem limites. Ela não pode decidir se um item legado deve mapear para uma substituição, se uma busca aposentada precisa de compensação, ou se um valor salvo é legal em uma economia redesenhada. Essas são decisões de produto. Ela também não pode reduzir com segurança dados criptografados ou sensíveis copiando-os para ferramentas amplas. Nesses casos, crie um equivalente sintético que preserva a condição estrutural ou mantenha a investigação restrita dentro do limite de acesso adequado.
Não publique um estado de jogador bruto como um dispositivo de regressão. Retire nomes, informações de contacto, dados de recepção, identificadores do dispositivo, tokens de acesso e qualquer campo não necessário para o predicado. Uma ferramenta mínima é uma oportunidade para melhorar a privacidade, bem como a diagnosticabilidade. O artefato final deve ser seguro para incluir no corpus de teste do projeto e útil o suficiente para evitar a recorrência.
Lista de verificação prática
- Defina um predicado de falha determinístico antes de remover qualquer estado.
- Grave o aplicativo, adaptador, conteúdo, configuração, semente e ambiente de fixação.
- Mantenha o estado inicial e a sequência de ação separados quando o comportamento se desdobra ao longo do tempo.
- Reduzir os grupos de topo primeiro, em seguida, aninhados campos, coleções e valores.
- Preservar referências e validade estrutural enquanto desafia a relevância semântica.
- Use um programa de concorrência controlado em vez de repetições dependentes do tempo.
- Armazene a classificação invariante, esperada, o diff semântico e o replay manifesto com o resultado.
- Parar em um contraexemplo limitado útil; não otimizar indefinidamente para minimalidade teórica.
- Redigir ou sintetizar dados sensíveis antes de um dispositivo entrar em testes de rotina.
Perguntas mais frequentes
A depuração delta é apenas para falhas?
Não. O predicado pode ser um crash, mas também pode ser um jogo violado invariante, uma contagem de direitos errados, uma viagem de ida e volta de save-load falhada, uma classificação de migração rejeitada, ou um descompasso entre o estado esperado e observado. É mais útil sempre que uma entrada complexa produz um resultado que não deve ocorrer.
E se a falha for intermitente?
Primeiro, reduza o não determinismo. Corrija as sementes, configure a captura, isole os limites do tempo e da rede e controle a concorrência. Se o resultado permanecer probabilístico, use um predicado baseado em limiares apenas com cuidado e registre essa limitação. Um cenário menor e estável geralmente é mais valioso do que uma grande estrutura flácida.
Um redutor pode ser executado contra dados de produção?
A redução de rotina não deve. Use dispositivos sintéticos ou editados e um ambiente controlado. Uma investigação de incidente restrita pode precisar de provas protegidas, mas isso é um processo operacional separado com controles de acesso, regras de retenção e revisão. Não faça do conjunto de regressão uma cópia dos dados do jogador.
O que o Persistium reivindica aqui?
Persistium está em desenvolvimento como uma família de produtos de confiabilidade local-primeiro. Esta nota apresenta um fluxo de trabalho de redução geralmente útil e não afirma que um produto público automaticamente diagnostica economias arbitrárias, observou falhas do cliente, ou opera um serviço de análise hospedado.
