Automação de teste com hardware embarcado

Question

Alguém já teve automatizar sucesso testar diretamente no hardware incorporado?

Especificamente, eu estou pensando em automatizar uma bateria de testes de unidade para os módulos da camada de hardware. Precisamos ter maior confiança em nosso código da camada de hardware. Muitos dos nossos projetos utilizam interrupção temporizadores conduzido, ADCs, io de série, dispositivos de SPI serial (memória flash), etc ..

É isso mesmo vale a pena o esforço?

Nós normalmente alvo:

Processador: 8 ou 16 bits microcontroladores (algumas coisas DSP)
Idioma: C (às vezes c ++).

Answer 1

Claro. Na indústria automotiva usamos $ 100.000 custom-built testadores para cada novo produto para verificar o hardware e software estão operando corretamente.

Os desenvolvedores, no entanto, também construir um testador barato (sub $ 1.000), que inclui um monte de USB I / O, A / D, PWM in / out, etc e quer scripting uso na estação de trabalho, ou construído propositadamente LIS / software de teste SIL como MxVDev.

Hardware no teste Loop (HIL) é provavelmente o que você quer dizer, e ele simplesmente envolve algum hardware USB I / O ligado ao I / O do seu dispositivo, com o software no computador que executa testes contra ela.

vale Se ele depende.

Na indústria de alta confiabilidade (avião, automóvel, etc) o especifica de clientes muito extensos testes de hardware, então você tem que tê-lo apenas para obter o lance.

Na indústria o consumidor, com projectos não complexos, geralmente, não vale a pena.

Com qualquer projeto onde há mais do que alguns programadores envolvidos, porém, é realmente bom ter um teste de regressão noturno no hardware - é difícil para simular corretamente o hardware para o grau necessário para satisfazer-se que o teste de software é suficiente.

O teste mostra então imediatamente quando um problema entrou na compilação.

Geralmente você executar tanto caixa preta e teste de caixa branca - você tem código de diagnóstico em execução no dispositivo que lhe permite espionar os sinais e memória no hardware (que pode ser apenas um depurador, ou pode ser o código que você escreveu que reage a mensagens em um ônibus, por exemplo). Isso seria teste de caixa branca, onde você pode ver o que está acontecendo internamente (e até mesmo causar algumas coisas a acontecer, como erros de memória críticos que não podem ser testados sem introduzir o erro você mesmo).

Nós também executar um monte de testes 'caixa preta', onde o caminho de diagnóstico é ignorado e apenas o I / O é estimulado / ler.

Para uma configuração muito mais barato, você pode obter conselhos $ 100 microcontrolador com USB e / ou ethernet (como a família Atmel UC3), que você pode conectar ao seu dispositivo e executar testes básicos.

É especialmente útil para a manutenção do produto - quando o projeto é feito, armazenar algumas placas de trabalho, o testador, e um conjunto completo de software em CD. Quando você precisa fazer uma modificação ou depurar um problema, é fácil de configurar tudo de volta para cima e trabalhar sobre ela com algum conhecimento (depois de testar) que a principal funcionalidade não foi afetada por suas alterações.

-Adam

Answer 2

Sim. Tenho tido sucesso, mas não é um problema stragiht-forward para resolver. Em poucas palavras aqui é o que a minha equipa fez:

1. Definido uma variedade de testes de unidade usando um C framework de teste de unidade de home-construído. Basicamente, apenas um monte de macros, a maioria dos quais foram nomeados TEST_EQUAL, TEST_BITSET, TEST_BITVLR, etc.

2. escreveu um gerador de código de inicialização que levou estes testes compilados e orquestrada-los em um ambiente de execução. É apenas um pequeno driver que executa nossa rotina inicialização normal - mas em vez de ir para a malha de controle, ele executa um conjunto de testes. Quando terminar, ele armazena o último conjunto para executar na memória flash, em seguida, ele redefine a CPU. Ela irá então executar, em seguida, ao lado suite. Isso é para fornecer isolamento encerra uma suíte morre. (No entanto, você pode querer desativar este para garantir que seus módulos de cooperar. Mas isso é um teste de integração, não um teste de unidade.)

3. Os ensaios individuais iria log sua produção utilizando a porta serial. Este foi OK para o nosso projeto, porque a porta serial estava livre. Você terá que encontrar uma maneira de armazenar seus resultados se todos os seus IO é consumido.

Funcionou! E foi ótimo ter. Usando nosso datalogger personalizada, você pode apertar o botão "Test" e um par de minutos mais tarde, você teria todos os resultados. Eu recomendo.

Atualização para esclarecer como funciona o piloto de testes.

Answer 3

Sim.

A dificuldade depende do tipo de hardware que você está tentando teste. Como já foi dito anteriormente, o problema vai ser a complexidade do estímulo externo que você precisa aplicar. estímulo externo é, provavelmente, o melhor alcançado com algum equipamento de teste externo (como Adam Davis descreveu).

Uma coisa a considerar, porém, é exatamente o que é que você está tentando verificar.

É tentador supor que para verificar a interação do hardware e do firmware então você tem realmente nenhuma opção a não ser aplicar diretamente estímulo externo (ie. Aplicando DACs a todas as suas entradas ADC, etc.). Nestes casos, porém, os casos de canto que você realmente quer teste são muitas vezes vai ser sujeita a questões de calendário (por exemplo. Interrupções chegar quando você está executando a função foo ()) que vão ser incrivelmente difícil de teste em uma forma significativa - e ainda mais difícil de obter resultados significativos de. (Ie. Os primeiros 100 mil vezes Nós rodamos este teste foi bem. A última vez que ele correu ele falhou. Por quê?!?)

Mas a verificação do hardware deve ser feito separadamente. Uma vez feito isso, a menos que ele está mudando regularmente (através de imagens FPGA para download ou semelhantes), então você deve ser capaz de assumir que as obras de hardware e puramente testar o seu firmware.

Portanto, neste caso você pode se concentrar na verificação dos algoritmos que são usados ??para processar seus stimulii externas. Por exemplo, chamar suas rotinas de conversão ADC com um valor fixo como se viessem do seu ADC diretamente. Estes testes são repetíveis e, portanto, do benefício. Eles vão exigir teste especial constrói embora.

Testing os caminhos de comunicação do seu dispositivo vai ser relativamente simples e não necessita de código especial constrói.

Answer 4

Temos tido bons resultados com testes automatizados em nossos sistemas embarcados. Temos de teste escrito em alto nível (fácil de programar e depurar) línguas que são executados em máquinas de teste dedicados. Estes testes geralmente fazem verificação de sanidade ou gerar entradas aleatórias nos dispositivos, em seguida, verificar o comportamento correto. Há um monte de trabalho para gerar e manter esses testes. Nós projetamos um quadro e, em seguida, deixar internos de trabalho sobre os próprios testes.

Não é uma solução perfeita, e os testes são certamente propenso a erros, mas a parte mais importante é a melhoria em seus buracos de cobertura existentes. Encontre o maior buraco e design algo para cobri-lo de forma automatizada, mesmo se não é perfeito ou não vai cobrir o recurso inteiro. Mais tarde, quando todo seu material é coberto um pouco, você pode voltar e endereço a pior cobertura ou a maioria dos recursos críticos.

Algumas coisas a considerar:

• O que é a pena de um bug firmware? Como fácil é a atualização de firmware no campo.
• Que tipo de cobertura que meu teste de fornecer? É uma verificação de sanidade simples? É o suficiente configurável que pode testar vários cenários diferentes?
• Uma vez que o teste falhou, como você vai reproduzir esse valor, a fim de depurá-lo? Será que quis registrar todas as configurações do dispositivo e de teste para que você possa eliminar tantas variáveis ??quanto possível? configuração do dispositivo, versão do firmware, versão do software de teste, todas as entradas externas, todo o comportamento observado?
• O que você está testando contra? É o suficiente clara especificação sobre o que o comportamento esperado do dispositivo que você está testando ou você está validando contra o que você acha que o código deve fazer?

Answer 5

Se o seu objetivo é testar o seu código do driver de baixo nível você provavelmente precisará criar algum tipo de dispositivo de ensaio, utilizando cabos de auto-retorno ou várias unidades interligadas para permitir que você exercer cada driver. Emparelhamento uma placa com em bom software com uma placa de executar uma compilação de desenvolvimento permitirá que você teste para regressões em protocolos de comunicação, etc.

testar estratégias específicas dependem do hardware que você deseja testar. Por exemplo, os ADCs pode ser testada através da apresentação de uma forma de onda conhecido e conversão de uma série de amostras, então a verificação para a gama adequada, a frequência, o valor médio, etc.

Eu encontrei este tipo de teste a ser muito valiosa no passado, permitindo-me para modificar com confiança e melhorar o código do driver sem medo de quebrar as aplicações existentes.

Answer 6

Sim, eu faço isso, embora eu sempre tive uma porta serial disponível para teste de I / O.

É frequentemente difícil deixar a unidade totalmente não modificada. Alguns ensaios requerem uma linha comentado ou uma chamada, por exemplo, adicionados Para lidar com um cão de guarda.

IMHO, este é melhor do que nenhum teste de unidade em tudo. E é claro que você precisa fazer um teste completo de integração / sistema também.

Answer 7

Unidade testando projetos embarcados é bastante diffucult, já que normalmente requer um estímulo externo e measurment externo.

Temos sido bem sucedidos no desenvolvimento de um protocolo serial externo (RS232 ou UDP ou tcpip mensagens) com comandos básicos para o exercício do hw com o registo de depuração nos drivers de baixo nível à procura de condições errôneas ou mesmo condições ligeiramente anormais (especiamente para o limite verificação)

Mas, uma vez desenvolvido, em seguida, pode executar o teste após cada compilação, se necessário. Ele certamente vou permitir que você entregar um produto de melhor qualidade.

Answer 8

Eu sei que isso é velho agora, mas talvez ele vai ajudar. Sim, você pode fazê-lo, mas isso depende de quanto você quer investir na solução que deseja. Mais de dois anos tenho trabalhado em teste e validação para a camada MCAL de AUTOSAR. Este é tipo do menor você pode obter quando se trata de teste de software. Era uma espécie de teste de nível de componente. Alguns podem chamá-lo de nível de unidade mas foi um pouco maior do que isso porque estávamos a testar as APIs dos componentes Mcal. Coisas como:. ADC, SPI, UTI, DIO e assim por diante

A solução utilizada envolvidos: - um quadro de teste que foi executado no micro-alvo - uma caixa dSPACE para fornecer e ler sinais de e para o alvo quando necessário - XCP acesso através Vector canapé para desencadear a recolha de execução do teste e os resultados - um quadro python para realizar o controle de teste e validação dos resultados

Os casos de teste foram escritos em C e eles eram mostradas no alvo, juntamente com o software sob teste. Foi um teste caixa preta porque nós não alteram de forma alguma a implementação do MCAL. E eu acho que nem mesmo a sequência de inicialização foi tocado. Uma tarefa ocioso foi utilizado para verificar continuamente o estado de uma bandeira que era o sinal para começar a executar um teste. Uma tarefa 10 ms foi usado para realmente executar o teste. Um caso de teste foi de fato um caso switch. Cada caso neste interruptor foi uma etapa de teste. Python foi desencadear a execução de teste no nível etapa de teste. A coisa boa com esta abordagem era a reutilização de etapas com diferentes parâmetros. Este controlo de teste, o que executar e como, foi feito por Python através de uma estrutura de dados, que actua como controlo de teste de uma API entre a implementação do teste e o teste de desencadeamento e mecanismo de avaliação. Isto é o que Canape foi usado para. Para definir o teste a ser executado, e ler os resultados do teste. Cada valor obtido por um passo de teste foi armazenado em uma matriz parte da estrutura de dados. A etapa de teste em si não estava envolvido em qualquer validação porque o alvo foi considerada um componente não trust-capazes do ambiente de teste. A validação foi feita por Python com base nas especificações de teste. Python foi analisar estas especificações e foi capaz de criar automaticamente scripts de teste de disparo, incluindo os critérios de validação para cada etapa de teste. A especificação de cada caso de teste foi uma série de teste passos descrições juntamente com os seus critérios de validação. Algumas dessas etapas foram dSPACE passos relacionados. Como exemplo, um passo foi inicializar algo e estava ligando para alguns capturando algumas arestas em um canal já configurado, eo próximo passo foi aplicar o sinal no canal por comandar o equipamento dSPACE.

A solução mais barata que envolvem o uso de uma placa em casa em vez do equipamento dSPACE. Até certo ponto, mesmo um gerador de sinal programável pode ser usado, mas que não iria ajudar se você precisa sinais Validar saída-ed pelo alvo.

Answer 9

Se o seu objetivo é a fabricação de teste (assegurando que os módulos são devidamente montado, não shorts inadvertidas / abre / etc), você deve se concentrar primeiro em testar cabos e conectores, seguido por conexões socketed e soldadas, em seguida, o próprio PCB. Esses itens podem ser testados para calções e abre encontrando padrões de acesso que impulsionam cada linha indivíduo alto, enquanto os seus vizinhos são baixos e vice-versa, então a leitura de volta os valores das linhas.

Sem saber mais detalhes sobre o seu hardware é difícil ser mais específico, mas os processadores mais incorporados pode definir O pins para um modo GPIO que simplifica este tipo de teste I /.

Se você não estiver executando cama-de-pregos testar em seu PCAs, este teste deve ser considerado um primeiro passo obrigatório para placas recém-fabricados.