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

Apresentação em tema: "Engenharia de Sistemas Embarcados 2006.2 Aula 7: Testando o Sistema Embarcado."— Transcrição da apresentação:

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

2 2006.2Engenharia de Sistemas Embarcados2 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

3 2006.2Engenharia de Sistemas Embarcados3 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 DO 10 I=1.5 destruição do foguete Missão Mariner 1 DO 10 I=1,5. Código correto

4 2006.2Engenharia de Sistemas Embarcados4 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.

5 2006.2Engenharia de Sistemas Embarcados5 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 Testes devem começar o mais cedo possível

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

7 2006.2Engenharia de Sistemas Embarcados7 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?

8 2006.2Engenharia de Sistemas Embarcados8 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

9 2006.2Engenharia de Sistemas Embarcados9 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

10 2006.2Engenharia de Sistemas Embarcados10 Testes Funcionais (Caixa Preta) Testes aleatórios –Utilizado para validar a robustez do sistema Testes de desempenho –Validam o desempenho do sistema

11 2006.2Engenharia de Sistemas Embarcados11 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

12 2006.2Engenharia de Sistemas Embarcados12 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

13 2006.2Engenharia de Sistemas Embarcados13 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?

14 2006.2Engenharia de Sistemas Embarcados14 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?

15 2006.2Engenharia de Sistemas Embarcados15 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

16 2006.2Engenharia de Sistemas Embarcados16 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.

17 2006.2Engenharia de Sistemas Embarcados17 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?

18 2006.2Engenharia de Sistemas Embarcados18 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?

19 2006.2Engenharia de Sistemas Embarcados19 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?

20 2006.2Engenharia de Sistemas Embarcados20 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.

21 2006.2Engenharia de Sistemas Embarcados21 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)

22 2006.2Engenharia de Sistemas Embarcados22 Cobertura de Decisão if (condição é verdadeira) { } Como garantir que o código foi executado DC avalia quantas vezes a decisão foi verdadeira ou falsa

23 2006.2Engenharia de Sistemas Embarcados23 Cobertura de Decisão por Decisão Modificada if (A || B) { } MCDC diz os estados de A e B quando a decisão foi avaliada

24 2006.2Engenharia de Sistemas Embarcados24 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

25 2006.2Engenharia de Sistemas Embarcados25 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

26 2006.2Engenharia de Sistemas Embarcados26 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?

27 2006.2Engenharia de Sistemas Embarcados27 Performance Analyzer da Keil (uVision 3)

28 2006.2Engenharia de Sistemas Embarcados28 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