Reliability verification of Digital Systems Design based on mutation Analysis

1. Reliability verification of Digital Systems Design based on mutation Analysis Samuel S. Marczak

2. Agenda • Resumo • Introdução • Descrição da Metodologia Proposta • Estudo de Caso

3. Resumo • Nova abordagem para: • Verificação da confiabilidade de um sistema, baseada na técnica de análise de mutantes; • Técnica originalmente proposta para teste de software por intermédio da verificação da adequação de um conjunto de vetores de teste para um determinado programa; • Estudo de caso para ilustrar a abordagem proposta;

4. Agenda • Resumo • Introdução • Descrição da Metodologia Proposta • Estudo de Caso

5. Análise de Mutantes (AM) • É um critério que avalia a adequação de um conjunto de casos de teste em revelar erros específicos; • Principais passos da análise de mutantes: • Dado um produto P; • Um conjunto de casos de teste T, cuja qualidade se deseja avaliar; • Geração do conjunto de mutantes M; • Execução de P com T; • Execução dos mutantes M com T; • Analise dos mutantes;

6. Análise de Mutantes (AM) • Geração do conjunto de mutantes M • Constrói-se um conjunto de produtos, obtidos pela inclusão de alterações, ou desvios sintáticos, em P • Uma hipótese utilizada para guiar a geração dos mutantes é: • A hipótese do programador competente • Assume que os produtos a serem testados estão corretos ou próximos do correto (DeMillo et al., 1978)

7. Análise de Mutantes (AM) • Execução de P • Consiste em executar o produto P usando os casos de teste de T e verificar se seu comportamento é o esperado • Não sendo, o produto apresenta resultados incorretos para algum caso de teste, então um defeito foi detectado; • Caso contrário a aplicação AM continua; • Execução dos mutantes • Cada um dos mutantes é executado usando os casos de teste de T; • Se um mutante apresenta resultado diferente de P, conclui-se que os casos de teste utilzaidos são sensíveis e conseguiram expor a diferença entre P e mutante, neste caso mutante está morto, é descartado; • Se mutante apresenta comportamento igual a P, isto indica uma baixa qualidade de T (não conseguiu distinguir P de mutante);

8. Análise de Mutantes (AM) • Após execução dos mutantes • Medida de adequação dos casos de teste utilizados  escore de mutação: • É um valor no intervalo (0..1) • Fornece uma medida de quanto o conjunto de casos de teste analisado aproxima-se da adequação

9. Análise de Mutantes (AM) • Análise dos mutantes • Requer mais intervenção humana; • 1º decidir se o teste deve continuar ou não; • Se escore de mutação (ms) próximo de 1, pode-se encerrar o teste e considerar T como um conjunto SUFICIENTEMENTE BOM de casos de teste para P; • Se continuar  analisam-se os mutantes que sobrevivem e decidir se esses são ou não equivalentes ao produto original. • Novos casos de teste matam mutantes vivos não equivalentes; • Determinar a equivalência de um mutante ao programa original  não é possível automatizar essa tarefa por completo;

10. Análise de Mutantes (AM) • Na pesquisa preocuparam-se com o seu uso como um critério estimar cobertura de falha  verificação da confiabilidade do sistema; • AM é um critério eficaz em revelar defeitos em programas, mas a aplicação da AM apresenta um custo alto (devido principalmente a gradne quantidade de mutantes gerados e a dificuldade em identificar os mutantes equivalentes ao programa original);

11. Agenda • Resumo • Introdução • Descrição da Metodologia Proposta • Estudo de Caso

12. Descrição da Metodologia Proposta • Uma falha de hardware que afeta uma aplicação  pode ter uma representação equivalente no nível de implementação de software; • Em Al Hayek et al. é proposta uma abordagem baseada em análise de mutantes para testar descrição de hardware VHDL; • Como resultado, essa abordagem gera um conjunto de vetores de teste e obtêm uma cobertura de falha a nível de descrição funcional;

13. Descrição da Metodologia Proposta • Al Hayek, aplica o conjunto de vetores de teste em uma estrutura gate-level de uma compilação VHDL e verifica a capacidade de tal conjunto de teste detectar falhas stuck-at; • Após definir algumas heuristicas para aumentar a capacidade de detecção de falha do conjunto de teste original, Al Hayek demonstra que a cobertura de falha no gate-level era elevada na maioria dos circuitos simulados;

14. Descrição da Metodologia Proposta • A idéia do trabalho é verificar (no mais alto nível de descrição) a confiabildiade do sistema contra falhas transientes ou permanentes em um HW; • Exceto a parte de HW e os canais de comunicação, a parte de SW do sistema não é confiável  Qualquer falha que afeta a parte de SW pode fazer o sistema falhar;

15. Descrição da Metodologia Proposta • Propuseram uma adaptação da abordagem de analise de mutantes, originalmente proposta para teste em software em 1978 por DeMillo; • Técnica para definir uma análise de mutante fraca; • Antes da geração da análise de mutates fraca ser aplicada para o programa original, é necessário construir uma estrutura de dados para os mutantes (MDS), que captura todas as informações importantes sobre a execução do programa; • Weiss et al. Propõe uma estrutura;

16. Descrição da Metodologia Proposta • Uma modificação da versão do MDS de Weiss é proposta, a fim de adaptá-lo ás exigências da análise de mutantes fraca; • O MDS é constituído por duas partes: uma matriz I, que representa o programa de entrada dos vetores de teste (cada elemento aponta para)  a matriz C contendo o nome e o estado de todos os comparadores de saídade um programa durantea execução do programa.

17. Descrição da Metodologia Proposta • Destacam que: • |Cn| representa o número de saídas verificadas juntamente com o programa; • |Ik| é o número de entradas de vetores de teste;

18. Descrição da Metodologia Proposta • A análise de mutante é aplicada não só para o código Handel-C (linguagem de programação usada para implementar a parte de HW de um projeto), mas também para código C que implementa a parte de SW; • Em função  é preciso co-simular o sistema, parcialmente descrito em C e Handel-C, no que diz respeito a um conjunto predefinido de mutantes; • Para tal finalidade, um conjunto de operadores de mutação dedicado para Handel-C e C é desenvolvido;

19. Descrição da Metodologia Proposta • Conjunto de operadores de mutantes para descrição Handel-C e C

20. Descrição da Metodologia Proposta • Exemplo de 8 mutantes para rotina crypt; • Cada uma das 8 declarações de mutantes é executa por um determinado tempo;

21. Descrição da Metodologia Proposta • 1º mutante: é uma substituição de operador lógico (LOR); • 2º mutante: é uma substituição de constante por variável (CVR); • 3º mutante: é uma substituição de constante (CR); • 4º mutante: é uma substituição de operação por um delay de 1 ciclode clock de duração (ODR); • 5º mutante: é uma substituição de operador aritmético (AOR); • 6º mutante: é uma substituição de operador bit (BOR*); • 7º mutante: é uma substituição de variável por constante (VCR) • 8º mutante: é uma substituição de uma operação por um pulo de 0 ciclos de clock de duração (OSR*).

22. Agenda • Resumo • Introdução • Descrição da Metodologia Proposta • Estudo de Caso

23. Estudo de Caso • Programa mencionado anteriormente com criptografia; • Programa consiste principalmente em três rotinas: is_valid, crypt e set_bit; • Segundo o trabalho publicado por by Al Hayek et al. [14], cinco vetores de teste para cada mutante declarado em um programa são suficientes para testar uma descrição hardware VHDL  com uma cobertura de falha stuck-at corresponde a 97%; • A fim de simplificar o estudo de caso, foi gerado cinco vetores de teste por mutante declarado no programa;