Upload
rafaela-martinho-schmidt
View
213
Download
0
Embed Size (px)
Citation preview
Engenharia de Sistemas Embarcados 2006.2Aula 7: Testando o Sistema Embarcado
2006.2 Engenharia de Sistemas Embarcados 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
2006.2 Engenharia de Sistemas Embarcados 3
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.5destruiç
ão do foguete
Missão
Mar
iner
1
DO 10 I=1,5.
Código correto
2006.2 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.
2006.2 Engenharia de Sistemas Embarcados 5
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 seCorrigir um problema
Testes devem
começar o mais cedo possível
2006.2 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
2006.2 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?
2006.2 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
2006.2 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
2006.2 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
2006.2 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
2006.2 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
2006.2 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?
2006.2 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?
2006.2 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
2006.2 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.
2006.2 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?
2006.2 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?
2006.2 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?
2006.2 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.
2006.2 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)
2006.2 Engenharia de Sistemas Embarcados 22
Cobertura de Decisão
if (condição é verdadeira) { <então execute estes statements>}
<código subseqüente ao if sem else>
Como garantir que o código foi executado
DC avalia quantas vezes a decisão foi verdadeira
ou falsa
2006.2 Engenharia de Sistemas Embarcados 23
Cobertura de Decisão por Decisão Modificada
if (A || B) { <então execute estes statements>}
MCDC diz os estados de A e B quando a decisão
foi avaliada
2006.2 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
2006.2 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
2006.2 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?
2006.2 Engenharia de Sistemas Embarcados 27
Performance Analyzer da Keil (uVision 3)
2006.2 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