As ferramentas usadas para automação de testes de software em sistemas incorporados são diversos, geralmente dependendo da hardware específico, arquitetura de software e necessidades de teste. As empresas de sistema usam absolutamente essas ferramentas, pois o teste manual de sistemas incorporados é incrivelmente demorado e propenso a erros, especialmente considerando as interações muitas vezes complexas de software de hardware.


Aqui está um detalhamento de categorias e exemplos de ferramentas comuns:

1. Estruturas de teste: Eles fornecem a estrutura e a organização para testes automatizados.

* Teste do Google (GTEST): Uma estrutura de teste C ++ amplamente usada, conhecida por sua simplicidade e extensibilidade. Comumente usado em projetos incorporados que usam C ++.
* Unidade: Uma estrutura de teste de unidade leve e de plataforma cruzada adequada para projetos C e C ++. Popular em sistemas incorporados devido à sua pequena pegada.
* CPPUTEST: Outra estrutura de teste de unidade C ++ projetada especificamente para sistemas incorporados, enfatizando o uso mínimo de recursos.
* Cunit: Uma estrutura de teste de unidade para C.
* testComplete: Uma estrutura comercial que suporta scripts em vários idiomas e pode automatizar testes de GUI (embora menos comuns diretamente em sistemas incorporados de metal nu)

2. Ambientes/corredores de execução de teste: Eles gerenciam a execução de suítes de teste e relatórios de resultados.

* Muitos IDEs incorporam corredores de teste: Por exemplo, o Eclipse CDT pode se integrar a estruturas como o Google Test.
* Scripts personalizados: Freqüentemente, as equipes de sistemas incorporados escrevem seus próprios scripts (por exemplo, usando Python ou Bash) para orquestrar a execução do teste, principalmente para testes de integração e nível de sistema.
* Integração contínua/implantação contínua (CI/CD): Jenkins, Gitlab CI, Azure DevOps, etc., são comumente usados ​​para automatizar o processo de construção e teste, inclusive para sistemas incorporados. Eles geralmente se integram às estruturas de teste e corredores.


3. Ferramentas específicas de hardware: Essas ferramentas geralmente preenchem a lacuna entre o software de automação de teste e o hardware incorporado.

* JTAG Debuggers: Ferramentas como as de Segger, Lauterbach ou ARM fornecem interfaces para depurar e testar o hardware em um nível baixo. Eles também podem desencadear testes e capturar resultados.
* emuladores no circuito (iCes): Os ICES permitem cenários de teste mais sofisticados do que o JTAG, incluindo frequentemente recursos de rastreamento e emulação em tempo real. Normalmente são soluções de ponta.
* simuladores de hardware no loop (HIL): São sistemas avançados que simulam o ambiente externo do sistema incorporado, permitindo testes completos da interação do sistema com o mundo real sem a necessidade de componentes físicos ou situações potencialmente perigosas.
* Analisadores de barramento Can/lin/Ethernet: Essas ferramentas capturam e analisam a comunicação em ônibus automotivos e industriais, cruciais para testar sistemas incorporados se comunicando sobre esses protocolos.
* analisadores de osciloscópio/lógica: Para exame de sinal de hardware direto.


4. Ferramentas de análise de cobertura de teste: Isso medem o quão minuciosamente o conjunto de testes cobre o código.

* gcov (gcc): Uma ferramenta interna dentro do compilador GCC que fornece informações de cobertura de código.
* Ferramentas comerciais: Ferramentas mais sofisticadas fornecem relatórios de cobertura detalhados, incluindo cobertura de filial, cobertura de condições e MC/DC (Condição Modificada/Cobertura de Decisão), que é frequentemente exigida pelos padrões de segurança (como a ISO 26262).

5. Ferramentas de gerenciamento de teste: Isso ajuda a organizar e gerenciar o processo de teste.

* jira, Azure DevOps, testrail: Essas são ferramentas comuns para gerenciar casos de teste, rastrear bugs e relatórios sobre os resultados dos testes.


Quais ferramentas as empresas usam: A escolha depende muito de fatores como:

* Orçamento: Ferramentas de código aberto como o Google Test e a Unity são atraentes por razões de custo. As ferramentas comerciais oferecem recursos mais avançados, mas vêm com um preço.
* Complexidade do projeto: Projetos simples podem precisar apenas de uma estrutura de teste de unidade, enquanto sistemas complexos exigirão um conjunto de ferramentas mais extenso.
* Padrões de segurança: As aplicações críticas de segurança (automotivo, aeroespacial, médico) geralmente exigem o uso de ferramentas que cumprem padrões específicos e oferecem análise avançada de cobertura.
* Plataforma de hardware: As interfaces e hardware de depuração disponíveis influenciarão a escolha das ferramentas.
* Especialização em equipe: As habilidades da equipe de engenharia determinarão a viabilidade de adotar e usar ferramentas específicas.


Em resumo, as empresas de sistema envolvidas no desenvolvimento de sistemas incorporados usam uma ampla gama de ferramentas, geralmente combinando opções de código aberto e comerciais para criar uma infraestrutura de teste personalizada que atenda às suas necessidades específicas e requisitos de projeto. A tendência é para aumentar a automação e a integração com pipelines de CI/CD.