Continuamos a série de artigos sobre testes de automação de sistemas embarcados. Este artigo mostrará como integrar rápida e relativamente fácil a capacidade de controlar a potência do dispositivo em teste a partir de um script de teste, além de simular a pressão de botões mecânicos em um comando a partir de um script de teste.
Então, o que temos:
- Dezenas de dispositivos incorporados nos quais você precisa testar a nova versão do FirmWare (para ser mais preciso, a montagem diária do firmware)
- Devido à natureza do procedimento de inicialização do FW, pode ser necessário redefinir a energia (o chamado modo de download de firmware no modo Captura ao Ligar)
- Em alguns momentos específicos da execução do script de teste, gostaria de simular o pressionamento dos botões mecânicos localizados na placa de depuração do sistema incorporado
Por que o ponto 3 pode ser necessário? No meu caso, a tarefa é a seguinte - no caso de uma exceção crítica da execução do código, o sistema “sobe” para um estado meio morto do qual não sai até que seja desligado (outro motivo para o gerenciamento de energia). Mas o mais interessante é que, nesse modo, você pressiona o botão mecânico especialmente projetado para esse fim, o chamado Log de exceção - informações de depuração nas quais será possível tentar entender em que lugar ocorreu uma exceção no código.
É precisamente por esse motivo que, para a automação efetiva da configuração de teste, tornou-se necessário redefinir a potência do dispositivo e simular o pressionamento dos botões mecânicos na placa de depuração, "salvando" informações muito importantes sobre o Exception de perdê-lo em breve. mais cedo ou mais tarde, um script de teste percebendo que não há resposta do dispositivo tentará reanimá-lo, redefinindo a energia.
Uma pequena digressão lírica - às vezes você fica semanas atrás dessa exceção, porque surge apenas ocasionalmente quando todas as estrelas convergem e várias outras condições não são atendidas. Portanto, cada um desses logs de depuração é muito importante e necessário.
A análise da depuração da placa de circuito mostrou que o botão simplesmente fecha a linha GPIO puxada para +3,3 V no GND. Portanto, se você "solda" o botão e usa o relé para fechar a linha GPIO no chão, será o que você precisa.
Em seguida, surgiu a questão de escolher um dispositivo / módulo para controle ao qual foram apresentados os seguintes requisitos:
- O número máximo de relés (você precisa de 2 peças por dispositivo e há dezenas de dispositivos)
- Acesso Ethernet
- Gerenciar comandos de URL
- Capacidade de copiar e dimensionar o sistema
Por tradição, eles pararam no módulo Etherent do relé Laurent-128:
O módulo, por todos os parâmetros, nos deixou felizes: podemos gerenciar 14 dispositivos de uma só vez (um relé para energia, outro com o toque de um botão) usando comandos de URL (muito conveniente para linguagens de script nas quais a automação de teste é escrita).
O diagrama de conexão e comunicação da placa de depuração do dispositivo em teste e do módulo de controle é mostrado na figura abaixo:
"Soldar" nos contatos de um botão mecânico no exemplo de um dos dispositivos testados tem a seguinte aparência:
Viva! A parte técnica está pronta. A única coisa que resta é adicionar o código dos procedimentos de teste para que, se necessário (faça o download da imagem do firmware após uma redefinição de energia ou depure o registro com o toque de um botão), forneça um comando para ligar / desligar o relé desejado.
A sintaxe dos URLs do comando de controle é simples e óbvia. Por exemplo, para habilitar o relé sob o número 4, você precisa usar o seguinte endereço HTTP:
http://192.168.0.101/cmd.cgi?psw=Laurent&cmd=REL,4,1
E aqui está uma função simples no Perl, chamada do procedimento de teste principal, se você precisar "puxar" o relé:
Observo que o sistema funciona de maneira confiável, sem falhas e congelamentos. O Laurent-128 e o Laurent-112 usado anteriormente (para 12 relés) trabalharam por alguns anos sem falhas e paradas, levando em consideração o trabalho diário.
E aqui está um exemplo de uma exceção que foi identificada durante os testes com um conjunto diário extraordinário de firmware. Depois que ficou claro para o script de teste que não havia resposta do dispositivo na porta serial (isto é, "morreu"), foi feita uma tentativa de pressionar o botão mecânico de emergência para registrar a depuração e isso funcionou - o relatório de teste final gerado pelo próprio script de teste foi preenchido com informações úteis o local de uma possível falha do sistema para análise posterior pela equipe de desenvolvimento:
