engenharia de sistemas embarcados 2006.2 aula 7: testando o sistema embarcado

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


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


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.


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


Para Melhorar Desempenho

• Maximizar o desempenho do sistema• Eliminção de código morto• Eliminação de código ineficiente


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?


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


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


Testes Funcionais (Caixa Preta)

• Testes aleatórios– Utilizado para validar a robustez do sistema

• Testes de desempenho– Validam o desempenho do sistema


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


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


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?


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?


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


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.


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?


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?


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?


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.


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)


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


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


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


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


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?


Performance Analyzer da Keil (uVision 3)


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 2006.2 aula 7: testando o sistema embarcado

Documents