Teste de software em sistemas embarcados automotivos
ÍNDICE DE CONTEÚDO
- Teste de software em sistemas embarcados
- Validação de software embarcado para sistema automotivo
- Objetivos de testes
- Black box testing vs White boxing test
- Teste baseado em Modelo
Olá caro leitor! Você se interessa por sistemas automotivos? Software embarcado? Teste de software? Esse artigo reúne algumas das técnicas de verificação e validação de software embarcado para sistemas embarcados. No final são apresentadas algumas fontes de materiais úteis para aqueles que querem se aprofundar ou começar na área de qualidade de software embarcado. Vamos “embarcar” nesta jornada juntos ?
Teste de software em sistemas embarcados
Teste de software é umas das técnicas analíticas de garantia de qualidade aplicada a software, usualmente reconhecida como a mais significativa e a usada com mais frequência.
Um equívoco comum quando pensa-se em teste é acreditar que tal tarefa consiste apenas em executar testes, ou seja, executar o software e verificar os resultados. Entretanto de acordo com a BSTQB (Brazilian Software Testing Qualifications Board), teste de software é um processo que inclui muitas atividades diferentes, e a execução do teste (incluindo a verificação dos resultados) é apenas uma dessas atividades. O processo de teste também inclui atividades como planejamento de teste, análise, modelagem e implementação dos testes, relatórios de progresso, resultados de testes e avaliação da qualidade de um objeto de teste.
Quando trata-se de sistemas embarcados a validação de software torna-se ainda mais importante uma vez que tais sistemas têm como característica comum a interação com o mundo físico, por vezes controlando hardware e atuadores. Tais sistemas podem ser encontrados em sistemas médicos, no setor de aviação, automotivo e no uso doméstico. E apresentam características comuns como:
- Devem executar de maneira confiável por longos períodos de tempo;
- São utilizados com frequência em aplicações onde a vida humana está em risco;
- São muitas vezes tão sensíveis ao custo que não há margem para ineficiências.
Atualmente há no mercado diferentes tipos de sistemas embarcados e todos eles possuem características que podem diferir enormemente entre um e outro. Uma questão que deve ser levada em conta é o tipo de sistema embarcado que está sendo testado e esse artigo se aterá a sistemas automotivos.
Validação de software embarcado para sistema automotivo
O projeto de um veículo exige uma validação rigorosa, principalmente pelo fato de estar exposto a riscos iminente à vida humana, portanto de maneira geral o tempo para validação é usualmente longo e custoso para as empresas da área automotiva.
Comumente a validação de software automotivo envolve muitos especialistas em diferentes níveis de teste e diferentes atividades de teste em vários estágios do projeto. Uma maneira de se abordar as diferentes etapas em que deve-se testar um software é usar o modelo ‘V’. Tal modelo dedica-se a descrever o processo de teste e validação porque vincula de maneira adequada as fases de desenvolvimento do sistema e propõe ainda que os testes unitários e integração também podem ser utilizados para verificar o projeto de software. Isto é, durante os testes de unidade e de integração., os programadores e a equipe de testes devem garantir que todos os aspectos do projeto foram implementados corretamente no código.
Figura 1: Modelo V conceitual de Engenharia de Sistemas/Desenvolvimento de Produto.
Objetivos de testes
Segundo a BSQTB os objetivos típicos de testes são:
- Evitar defeitos, avaliar os produtos de trabalho, como requisitos, estórias de usuários, modelagem e código;
- Verificar se todos os requisitos especificados foram cumpridos;
- Verificar se o objeto de teste está completo e validar se funciona como os usuários e stakeholders esperam;
- Criar confiança no nível de qualidade do objeto de teste;
- Encontrar defeitos e falhas reduz o nível de risco de qualidade inadequada do software;
- Fornecer informações suficientes aos stakeholders para que tomem decisões especialmente em relação ao nível de qualidade do objeto de teste;
Black box testing vs White boxing test
Os testes de software podem ser divididos em 2 grupos que têm características e focos diferentes.
No modelo white boxing test (Caixa branca) engenheiro de testes tem acesso ao código fonte, conhece a estrutura interna do produto sendo analisado e possibilita que sejam escolhidas partes específicas de um componente para serem avaliadas. Esse tipo de teste, também conhecido como teste estrutural, é projetado em função da estrutura do componente e permite uma averiguação mais precisa do comportamento dessa estrutura.
No modelo black boxing (Caixa preta) o engenheiro de testes não tem acesso ao código fonte e desconhece a estrutura interna do sistema. É também conhecido como teste funcional, pois é baseado nos requisitos funcionais do software. O foco, nesse caso, é nos requisitos da aplicação, ou seja, nas ações que ela deve desempenhar.
Teste baseado em Modelo
Teste baseado em modelo é uma forma de teste de software onde os casos de teste são derivados de um modelo que descreve aspectos (geralmente funcionais) do sistema sendo testado. Tais casos são conhecidos como a suite abstrata de testes, e seu nível de abstração está intimamente relacionado ao nível de abstração do modelo.
Por serem baseados em modelos e não no código fonte propriamente dito, o teste baseado em modelo é visto como uma forma de teste de caixa-preta. E é altamente utilizado na indústria automotiva para validação de software. Este tipo de teste começou a ser utilizado na indústria em áreas onde simulações eram extensivas e o modelo poderia ser descrito. Primeiramente foi aplicado nas área de sistemas de segurança em sistemas que requerem alta confiabilidade, tempo de resposta curto e determinístico, geralmente baseado em vários sensores de entrada com dois atuadores/dispositivos controlados. Por exemplo: airbags, proteções contra capotagem, controle de estabilidade, etc. Além de aplicações de body control com protocolos determinísticos, gateway de alta velocidade com centenas de entradas e saídas digitais (com algumas analógicas), tolerantes a falhas (escassez, sobrecarga etc.) Por exemplo: controle de luzes, acesso remoto, painéis de controle etc.
Figura 2: Validação baseada em modelo. Fonte: autor
Veículos são plataformas extremamente caras para realizar todos os testes em ambiente real além de alguns testes serem muito difíceis de serem executados em baixo nível dentro de um carro, sendo assim algumas estratégias de teste e planejamento são necessárias.
Model-in-the-loop (MiL) – Nesse estágio o modelo do sistema é construído e simulado em um ambiente virtual. Geralmente, usa-se um programa computacional que permite a modelagem matemática do sistema por digrama de blocos, apresentando uma interface que permita a visualização gráfica da sua dinâmica e dos sinais envolvidos. Normalmente, não é obrigatório o uso de algoritmos de solução de equações diferenciais de passo fixo (fixed-step solver). Isso ocorre, pois ainda não há muita preocupação com o hardware do sistema de controle e nem com qual frequência ele irá operar, ou seja, o sistema ainda não possui um clock em tempo real. O objetivo aqui é identificar os requisitos do sistema e simular seu comportamento adquirindo conhecimento sobre ele.
Software-in-the-loop (SiL) – Nesta etapa é testado o software em uma configuração de malha fechada ou de malha aberta. Os componentes de software em testes são normalmente implementados em linguagem C, programados manualmente, ou gerados automaticamente por códigos baseados em modelos.
Hardware-in-the-loop (HiL) – Na simulação Hardware in the Loop uma parte do sistema é simulada computacionalmente (software) e outra parte, que apresenta características complexas de serem modeladas, é incorporada fisicamente ao sistema (hardware).
Figura 3: Esquema de teste baseado em modelo. Fonte: autor
O último nível de integração envolve o teste no veículo propriamente dito. Neste estágio o teste da central de controle é executado no carro real.
Se você está iniciando no mundo de sistemas embarcados automotivos e quer conhecer um pouco mais sobre o cenário validação e verificação. Deixo aqui fontes de conhecimentos interessantes:
https://www.youtube.com/watch?v=LfiQpKDAnPQ – Teste e verificação (Softing Automotive)
https://elearning.vector.com/?lang=en – Vector E-learning
https://www.youtube.com/watch?v=1Y-1zz6rZxo – Univesp, Gerência e qualidade de software
Referências
Livro: Automotive Embedded Systems Handbook Edited by Nicolas Navet and Françoise Simonot-Lion
Tese: Planejamento e Estruturação de testes de software em sistemas eletrônicos – Kleber Nogueira Hodel
Certified Tester Foundation Level Syllabus – BSQTB
Blog: https://blog.onedaytesting.com.br/teste-de-software/