Um dispositivo se desconecta no meio de um teste. O aplicativo relata um tempo limite, o firmware é reiniciado e a próxima tentativa é bem-sucedida. Por onde você deve começar?
Para desenvolvedores que trabalham com dispositivos conectados, interfaces de navegador ou protótipos de hardware, um erro de aplicativo geralmente é apenas o sintoma final. Substituir o código sem registrar as condições em torno de uma falha pode fazer com que você procure a camada errada.
Este tutorial cria um pequeno log de diagnóstico baseado em navegador. Ele registra medições, preserva as condições de teste e exporta evidências para outro desenvolvedor revisar. Você precisa de conhecimentos básicos de HTML e JavaScript; nenhuma estrutura ou instrumento conectado é necessário.
1. Defina a pergunta antes de coletar dados
Considere uma placa de desenvolvimento hipotética que se desconecta quando um periférico é iniciado. Várias explicações permanecem possíveis: uma exceção de firmware, um problema de transporte ou um problema de fonte de alimentação.
Comece com uma pergunta testável: “A tensão de alimentação medida muda quando este periférico é iniciado?” Essa pergunta diz o que registrar e o que manter constante.
Use uma placa em bom estado da mesma revisão, quando disponível. Combine o firmware, o cabo, a fonte, o periférico e a carga de trabalho. Uma comparação perde valor quando várias condições mudam juntas.
Registre a observação separadamente da explicação:
Campo
Exemplo
Observação
Dispositivo desconectado durante inicialização periférica
Medição
Medição de fornecimento em um ponto de teste nomeado
Condições
Revisão B da placa, firmware 1.4.2, periférico habilitado
Hipótese
Instabilidade na oferta pode contribuir para a desconexão
Próximo teste
Repita com um fornecimento verificado sob a mesma carga de trabalho
A hipótese permanece provisória. Uma leitura feita após a reinicialização do dispositivo não estabelece o que aconteceu durante a falha.
2. Escolha evidências que respondam à pergunta
Logs de aplicativos, rastreamentos de firmware e medições de bancada respondem a diferentes perguntas. Um tempo limite estabelece que uma operação não terminou a tempo; ele não identifica um componente com falha.
Para uma visão do equipamento especializado usado na solução de problemas de placas telefônicas, a visão geral do DIYFIXTOOL de Ferramentas de diagnóstico em nível de chip discute imagens térmicas, inspeção de raios X BGA e testes de indutância. Trate-o como uma introdução de autoria do fornecedor às categorias de equipamentos; use a documentação do instrumento e referências específicas da placa ao interpretar as medições.
O registro abaixo deixa deliberadamente a interpretação para o operador. Insira um valor numérico, sua unidade e as condições sob as quais foi medido. Não transforme uma leitura isolada em um veredicto automático de “chip com defeito”.
Para medições físicas, siga a documentação da placa e do instrumento e trabalhe dentro do seu treinamento. Este tutorial aborda o registro do software em vez de um procedimento para testar ou reparar um dispositivo ligado.
3. Crie um formulário pequeno e acessível
Salve o seguinte como index.html e sirva-o através do seu servidor de desenvolvimento local habitual. Por exemplo, se o Python estiver instalado, execute python -m http.server 8000 em seu diretório e abra http://localhost:8000.
4. Preserve os dados sem esconder falhas
O aplicativo armazena uma série de registros como JSON. Ao recarregar, ele analisa esse JSON e verifica os tipos de campo esperados antes de renderizá-lo. A análise por si só não valida a estrutura dos dados armazenados.
SitePoints guia para repetir respostas JSON fornece informações úteis sobre como trabalhar com objetos e matrizes após analisar JSON.
Cada célula da tabela usa textContent, portanto, uma nota contendo HTML é exibida como texto em vez de inserida como marcação. O Documentação MDN para textContent explica esse comportamento.
As operações de armazenamento ficam dentro dos blocos try…catch porque a persistência do navegador pode falhar. A interface mantém novas medições na memória e oferece uma exportação quando o salvamento falha. Ele não afirma que essas medições sobreviverão a uma recarga.
Para outro projeto prático de JavaScript vanilla, SitePoint’s Tutorial do visualizador de Markdown explora a construção e persistência da interface do usuário do navegador.
Como Documentação localStorage do MDN explica, o armazenamento pertence à origem do documento. Abrir o aplicativo em uma porta diferente pode, portanto, mostrar um log diferente. Este protótipo é uma ferramenta de navegador único, portanto, exporte sessões importantes e evite registrar identificadores de clientes ou conteúdos privados de dispositivos.
5. Compare as medições sob condições correspondentes
Suponha que duas leituras hipotéticas sejam 3,29 V e 3,08 V. A diferença entre elas é −0,21 V. Essa aritmética é direta; seu significado depende da especificação do trilho, da incerteza de medição, da carga de trabalho e do tempo.
Não adicione um limite de tensão universal à aplicação. Um limite específico do dispositivo deve vir de sua especificação ou de um procedimento de teste estabelecido.
Se a falha for breve, uma medição de estado estacionário inserida manualmente poderá perdê-la completamente. Registre essa limitação. A próxima investigação pode exigir uma captura correlacionada com o tempo, em vez de outra leitura estática.
Ao compartilhar uma sessão, inclua a revisão do firmware, a revisão da placa, as configurações do instrumento e as etapas de reprodução. Um colega deverá ser capaz de repetir a comparação sem adivinhar como a leitura foi obtida.
6. Verifique o fluxo de trabalho antes de confiar nele
Tente adicionar uma leitura decimal e uma leitura negativa e recarregue a página. Confirme se ambos os valores e suas unidades permanecem intactos. Digite uma nota contendo teste e verifique se aparece literalmente na tabela.
Exporte o JSON e inspecione a contagem de registros. Em seguida, simule o armazenamento bloqueado e confirme se a interface reporta a falha enquanto permite a exportação da sessão atual.
Para uma aplicação maior, adicione entradas editáveis, metadados de instrumentos e registros de linha de base explícitos. Um serviço compartilhado também precisaria de controles de acesso, validação no servidor e uma política de retenção. Essas adições devem seguir as necessidades do fluxo de trabalho de diagnóstico.
Transforme um sintoma em uma investigação reproduzível
O protótipo final capta um mínimo útil: o que foi medido, onde, quando e sob quais condições. Seu valor vem da preservação de evidências que outra pessoa pode inspecionar.
Quando um erro de aplicativo atinge o firmware ou hardware, esse registro ajuda você a escolher o próximo experimento. Repita a falha, altere uma variável e documente o que as novas evidências suportam antes de decidir o que corrigir.
