Engenharia de Sistemas Embarcados 2006.2

1. Engenharia de Sistemas Embarcados 2006.2 Aula 7: Testando o Sistema Embarcado

2. Testes • Por que testar? • Para descobrir bugs de software • Para reduzir riscos para os usuários e para a empresa • Para reduzir custos de desenvolvimento e manutenção • Para melhorar o desempenho Engenharia de Sistemas Embarcados

3. destruição do foguete Código correto Missão Mariner 1 DO 10 I=1,5. DO 10 I=1.5 Achar Bugs • Teorema da parada • É impossível provar que um programa arbitrário está correto. Contudo, dado o teste adequado, é possível mostrar que o programa está incorreto. • Pode-se mostrar que programas contém bugs . • Teste de software • Não se trata de provar a corretude do programa • Se trata de descobrir bugs Engenharia de Sistemas Embarcados

4. Redução de riscos • Objetivo dos testes • Mostrar para você mesmo, o cliente e agências regulatórias (quando apropriado) que o software funciona como projetado • Encontrar cada uma das falhas ou fraquezas do software antes que este seja colocado em campo. Engenharia de Sistemas Embarcados

5. Testes devem começar o mais cedo possível Redução de Custos • 1990, Custo devido a erros de software na HP  US$ 400 milhões • 50% do custo em retrabalho realizado nos laboratórios • 50% do custo para corrigir problemas identificados em campo após o lançamento do produto  Custo para se Corrigir um problema $ Engenharia de Sistemas Embarcados

6. Para Melhorar Desempenho • Maximizar o desempenho do sistema • Eliminção de código morto • Eliminação de código ineficiente Engenharia de Sistemas Embarcados

7. Que Tipos de Teste? • É preciso testar se a implementação atende aos requisitos da especificação • Testes funcionais • Conhecidos como testes caixa preta • É preciso testar detalhes da implementação • Testes de cobertura • Teste caixa branca • Qual dos dois tipos de teste é melhor? • Qual dos dois tipos de teste deve ser realizado? • Qual dos dois dever ser realizado primeiro e por que? Engenharia de Sistemas Embarcados

8. Quando Parar os Testes? • Quando começar os testes? • Teoricamente quanto tempo se pode ficar testando um sistema? • Quando parar? • Quando o chefe diz que está bom • Quando uma nova iteração do ciclo de teste acha menos que X bugs • Quando um certo valor de cobertura foi atingido sem que se tenha sido descoberto novos bugs • Como determinar o valores X e de cobertura? • Importante definir um critério de parada Engenharia de Sistemas Embarcados

9. Testes Funcionais (Caixa Preta) • Testes de stress • Teste que sobrecarregam de maneira intencional canais, buffers de memória, dispositivos, etc. • Testes de fronteira • Testes onde se aplicam valores de fronteira para se testar transições do sistema • Testes de exceção • Testes que disparam um modo de falha ou modo de exceção • Testes de suposição de erro • Teste baseado na experiência anterior ou com o teste de programas similares Engenharia de Sistemas Embarcados

10. Testes Funcionais (Caixa Preta) • Testes aleatórios • Utilizado para validar a robustez do sistema • Testes de desempenho • Validam o desempenho do sistema Engenharia de Sistemas Embarcados

11. Testes de Cobertura (Caixa Branca) • Qual a fraqueza do teste caixa preta? • Todo o código é exercitado? Por que? • Teste de cobertura  testar todo o código • Quais os pontos críticos do código que devem ser testados? • Statements • Pontos de decisão • Caminhos de decisão Engenharia de Sistemas Embarcados

12. Exemplos de Teste de Cobertura • Cobertura de código • São casos de teste selecionados que executam todos os trechos de código pelo menos uma vez • Cobertura de decisão ou desvio • São casos de teste selecionados porque executam todos os desvios (caminhos falso e verdadeiro) pelo menos uma vez • Cobertura de condição • São casos de teste selecionados porque forçam cada condição em uma decisão para assumir todos os possíveis valores lógicos Engenharia de Sistemas Embarcados

13. Problemas dos Testes Caixa Branca • O que é necessário para se realizar teste caixa branca? • Com relação ao custo de manutenção do teste caixa branca, ele é alto ou baixo? Por que? • Qual a relação da implementação do teste caixa branca com a implementação? Engenharia de Sistemas Embarcados

14. Testes Caixa Cinza • São testes que necessitam apenas de um conhecimento mínimo dos detalhes internos do sistema • São bastante efetivos com testes do tipo suposição de erro • Se o usuário sabe ou suspeita de que há erros no código em determinados pontos é importante testar estes pontos fracos • São interessantes para teste de novas funcionalidades implementadas em um sistema estável. • Por que, testes caixa cinza podem ser aplicados neste caso? Engenharia de Sistemas Embarcados

15. Testando Software Embarcado • O que separa o software embarcado de software comum • Software embarcado deve executar de maneira confiável por longos períodos de tempo • Software embarcado é utilizado com freqüência em aplicações onde a vida humana está em risco • Software embarcado são muitas vezes tão sensíveis ao custo que não há margem para ineficiências • Software embarcado deve com freqüência compensar falhas no hardware embarcado • Eventos no mundo real são normalmente assíncronos e não determinísticos, fazendo com que testes de simulação sejam difíceis e não confiáveis • Sua empresa pode ser processada se o seu código falhar Engenharia de Sistemas Embarcados

16. Modos de Falha de Tempo Real • Ambiente de teste de software embarcado • Testar a ocorrência de cenários típicos e de pior caso para situações de tempo real • Deve-se testar situações não convencionais • Exemplo de um carro: o que acontece com o software quando ligo o rádio, limpadores de pára-brisa e faróis simultaneamente? • O que acontece com o software de um rádio se eu o ligo e desligo 100 vezes rapidamente? • Deve-se testar todas as seqüências críticas do sistema • Seqüências críticas são combinações de eventos que causam o maior atraso entre o disparo de um evento e sua resposta. Engenharia de Sistemas Embarcados

17. Modos de Falha de Tempo Real • Deadlines • Suponha um sistema que deve ser ativado as 17:00hs. O que acontece se uma seqüência crítica acontece exatamente neste horário? • Hard deadline: dealine que deve ser respeitado sempre • Carga do sistema • O que pode acontecer com chamadas de funções do tipo malloc() quando o sistema está com a carga máxima ou próxima a isso? Engenharia de Sistemas Embarcados

18. Medindo Cobertura de Teste • Instrumentação de Software • Baseada em log de execução • Cobertura de código pode ser medida pela inserção de chamadas de trace no início de cada bloco básico de statements seqüenciais • Bloco Básico • Conjunto de statements com um único ponto de entrada no topo e um ou vários pontos de sáida em baixo • Cada estrutura de controle: goto, return ou decisão marca o final de um bloco básico • Cada statement de um bloco básico deve ser executado uma vez que se entra no bloco • Possível Implementação • Pode ser realizada utilizando-se printf() • Esta implementação se adequa a sistemas embarcados? Por que? Engenharia de Sistemas Embarcados

19. Medindo Cobertura de Teste • Problema • Utização de printf() pode tornar o código bastante lento. Muito intrusivo • Sistemas pequenas podem não possuir um meio conveniente para visualização de saída ou seja não dão suporte a printf() • Possíveis Implementações • Escrita em posição de memória • Quais as vantagens e desvantagens? • Escrita em posição única de memória com analisador lógico • Como funcionaria? Quais as vantagens e desvantagens? Engenharia de Sistemas Embarcados

20. Resumo dos Problemas de Log de Software • Altamente intrusivo • Deixa o sistema mais lento • Aumenta o tamanho do código • Pode mascarar bugs • Pode gerar falhas que não existiriam sem o log. • O que poderia ser um exemplo? • Problemas da cobertura de código • Mostra que parte do código foi exercitada, mas não mostrar por que foi exercitada. Engenharia de Sistemas Embarcados

21. Melhorando a Cobertura de Código • Cobertura de Decisão (Decision Coverage DC) • Cobertura de Decisão por Condição Modificada (Modified Condition Decision Coverage MCDC) Engenharia de Sistemas Embarcados

22. Como garantir que o código foi executado DC avalia quantas vezes a decisão foi verdadeira ou falsa Cobertura de Decisão if (condição é verdadeira) { <então execute estes statements> } <código subseqüente ao if sem else> Engenharia de Sistemas Embarcados

23. MCDC diz os estados de A e B quando a decisão foi avaliada Cobertura de Decisão por Decisão Modificada if (A || B) { <então execute estes statements> } Engenharia de Sistemas Embarcados

24. Instrumentação por Hardware • Avaliação de desempenho e cobertura de teste • Emulação de memória • Utilização de bit de cobertura que pode ser verificado • Analisador Lógico • Utiliza amostragem estatística • Disparo é realizado a intervalos aleatórios • Buffer de trace é carregado para o computador para análise • Analisadores de Desempenho de Software • Ferramentas com suporte em hardware específicas para teste de cobertura e análise de desempenho • Exemplo: Cadillac Tools Engenharia de Sistemas Embarcados

25. Como Testar Desempenho • Testar o tempo de execução de uma função • Muitas vezes não é um processo determinístico • Utilização de métodos estatísticos • Quais fatores podem modificar o tempo de execução de uma função? • Fatores que podem modificar o tempo de execução de uma função • Conteúdo das caches de dado e instrução no momento de acesso • Carregamento de tarefa em um RTOS • Interrupções e outras exceções • Requisitos de processamento de dados de uma função Engenharia de Sistemas Embarcados

26. Como Testar Desempenho • Medidas estatísticas • Tempo mínimo de execução da função • Tempo máximo de execução da função • Tempo médio de execução da função • Tempo acumulado de execução da função • Código Morto • Gera imagem de código maior • Pode alterar desempenho do código. Como? Engenharia de Sistemas Embarcados

27. Performance Analyzer da Keil (uVision 3) Engenharia de Sistemas Embarcados

28. Testando Desempenho • Utilizar o arquivo de mapeameamento do ligador • Identificar endereços de memórias das funções • Identificar endereços dos pontos de entrada e saída • Observar os endereços no barramento • Registrar o tempo em que acessos aos endereços ocorrem • Calcular os intervalos de tempo entre os acessos aos endereços de entrada e saída da função Engenharia de Sistemas Embarcados