Introdução aos Testes de Software. N. L. Vijaykumar LAC/INPE

Transcrição

1 Introdução aos Testes de Software N. L. Vijaykumar LAC/INPE

2 Acidente: Therac 25* Equipamento para tratamento de câncer utilizando RADIOTERAPIA e RAIO-X 6 casos de overdose (1985 a 1987) 2 mortes imediatas 2 mortes por câncer desenvolvido devido à overdose 2 casos com ferimentos permanentes *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

3 Acidente: Therac 25* Software assumiu um padrão de temporização da entrada de dados mesmo tendo sido agilizada esta entrada baseada na experiência dos operadores Software foi considerado livre de defeitos Software não passou por uma análise de segurança Qualidade de software não era gerenciada *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

4 Acidente: Therac 25* Alguns módulos de software eram reusados mas sem passar por uma análise de segurança Complexidade desnecessária do software Equipe de desenvolvimento não conhecia técnicas de concorrência de processos -> Equipe sem qualificação *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

5 Acidente: Therac 25* Análise de segurança aplicada em outros componentes também deve ser aplicada no projeto e na implementação do software Testar usos não previstos Qualificar a equipe de desenvolvimento Análise permanente de incidentes *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

6 Acidente com Airbus* Aterrisagem numa pista molhada e com fortes ventos Reversão da turbina somente após o toque do trem esquerdo *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

7 Acidente com Ariane 5* Mesmo em condições favoráveis, o foguete desvia da trajetória e explode Prejuízo de US$400 milhões Ângulo de ataque maior de 20o Comando recebido pelo Computador de Bordo e foi calculado pelo computador de referência que estava em pane Erro de conversão de ponto flutuante de 64 bits para inteiro de 16 bits *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

8 Acidente com Ariane 5* Testes simulando com dados reais Tratamento de exceções Proteger contra exceções no código *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

9 Acidente com Titan IV* Missões comerciais com possibilidade de lançar 2 missões independentes Projeto com 2 conjuntos de interfaces de comunicação: frontal e traseira Responsável por uma missão usou porta traseira Outro responsável por uma outra missão projetou utilizando porta frontal *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

10 Acidente com Titan IV* A troca não foi comunicada a equipe do software Testes realizados com software genérico para comandos com as duas portas Carga útil não se separa Prejuízo de US$300 milhões *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

11 Acidente com Titan IVB* Satélite que foi levado ficou na órbita elíptica Prejuízo de US$1.3 Bilhões ao invés de Faltou verificar dados críticos *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

12 Acidente de Boeing 757 em Colombia* Choque contra montanha perto de aeroporto de Cali As séries 757 e 767 tem muita automatização e requer pouco esforço do piloto A aterrisagem estava prevista numa pista mas o controle indica uma outra *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

13 Acidente de Boeing 757 em Colombia* Para realizar esta mudança, a tripulação deve executar várias operações Por falta de conhecimento do aeroporto por parte dos pilotos, houve uma entrada errônea dos dados Speedbrake acionado para descida não pôde ser desligado ao tentar desviar da montanha *Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade

14 Verificação e Validação (IEEE Definition) VERIFICAÇÃO Confirmar por testes e com provas objetivas que requisitos especificados foram cumpridos. Garante que os produtos de uma dada fase implementam em sua totalidade as entradas para aquela fase ou seja o produto foi construído corretamente (the product was built right)

15 Verificação e Validação (cont.) VALIDAÇÃO Confirmar por testes e com provas objetivas que requisitos particulares para um determinado uso foram cumpridos Prova que o software implementa cada um dos requisitos corretamente e completamente ou seja, o produto correto foi construído (the right product was built)

16 Produtividade e Qualidade em Software Peça produzida em massa numa fábrica Custo do projeto (qualquer que seja) é pequeno quando amortizado sobre produção em grande escala Controle de qualidade e testes desde componentes até produto final antes de despachar

17 Produtividade e Qualidade em Software (cont.) Falhas? descarta ou retrabalho Produtividade numa linha de montagem: Custo dos materiais Retrabalho Componentes descartados Custo de garantia de qualidade Testes

18 Produtividade e Qualidade em Software (cont.) MENOR esforço em garantia de qualidade implica em ALTA taxa de rejeição e conseqüentemente MAIOR o custo líquido BOA inspeção implica em descobrir falhas e domínio de custos de inspeção e conseqüentemente MAIOR o custo líquido Compromisso entre Custos de Garantia de Qualidade x Custos de Fabricação

19 Produtividade e Qualidade em Software (cont.) Estabelecem-se níveis de Testes e Garantia de Qualidade que MINIMIZEM o custo líquido mantendo um certo padrão de qualidade Custos de Testes e Garantia de Qualidade variam desde 2% (produtos de consumo) a 80% (foguetes, reatores nucleares, aviões...)

20 Produtividade e Qualidade em Software (cont.) Relação entre PRODUTIVIDADE e QUALIDADE para Software é bem diferente Custo de Manufatura de Software: fita ou disco, tempo do uso do computador Garantia de Qualidade da Manufatura do Software: check sums ou outros métodos de detecção

21 Produtividade e Qualidade em Software (cont.) Custos do Software são dominados por seu DESENVOLVIMENTO Manutenção do Software é diferente da manutenção do Hardware Não é propriamente uma manutenção Extensão do desenvolvimento: melhorias são projetadas, implementadas e são corrigidas as deficiências

22 Produtividade e Qualidade em Software (cont.) A fatia maior do custo do Software está nos custos dos ERROS (bugs) Custo de DETECTÁ-LOS Custo de CORRIGÍ-LOS Custo de PROJETAR TESTES para ACHÁLOS Custo de EXECUTAR estes TESTES

23 Produtividade e Qualidade em Software (cont.) Diferença principal entre produtividade de uma peça e produtividade de um Software Para Hardware, qualidade é APENAS uma das várias determinantes de produtividade No caso de Software QUALIDADE e PRODUTIVIDADE são INDISTINTAS

24 Produtividade e Qualidade em Software (cont.) Concentração na prevenção de erros Achar sintomas causados pelos erros Diagnóstico claro para facilitar a correção dos erros Prevenir erro é melhor que detectar o erro e corrigí-lo Não há código para corrigir

25 Produtividade e Qualidade em Software (cont.) Teste e depois codifique (D. Gelperin & W. Hetzel) O ideal é suceder na prevenção para que a atividade de testes não seja necessária IMPOSSÍVEL. Então, concentrar em descobrir os erros ERRO é um desvio do comportamento esperado

26 Produtividade e Qualidade em Software (cont.) Saber que o programa está errado não implica em conhecer o erro Diferentes erros podem se manifestar de uma maneira semelhante Um erro pode ter vários sintomas Sintomas e causas podem ser conhecidos somente com testes detalhados

27 Teste e Depuração Objetivo de Teste é mostrar que um programa tem erros Objetivo de Depuração é descobrir o tal erro e projetar e implementar as mudanças no programa para corrigir aquele erro Teste: prova uma falha do programador Depuração: vingança d o programador

28 Função x Estrutura Teste Funcional Programa é visto como CAIXA PRETA Entradas são submetidas e as Saídas são verificadas se estão de acordo com a especificação CONFORMANCE TESTING Preocupação é com a funcionalidade e não com os detalhes da programação Ponto de vista de um USUÁRIO

29 Função x Estrutura (cont.) Teste Estrutural Detalhes da implementação (estilo, controle, linguagem, banco de dados, código). Programa é visto como CAIXA BRANCA Bons sistemas são construídos em camadas Usuário vê apenas a última camada

30 Função x Estrutura (cont.) Camadas mais internas são menos relacionadas com as funcionalidades do sistema e mais com a estrutura ESTRUTURA para uma camada significa que é FUNÇÃO para outra Exemplo: num sistema online, o usuário não tem menor idéia que no sistema há uma rotina de alocação de memória

31 Teste de Unidade Unidade O menor pedaço testável de um software, e que pode ser compilado e ligado Em geral é um trabalho de um programador Teste de Unidade Mostrar que a unidade NÃO SATISFAZ a sua especificação funcional e/ou que a sua estrutura implementada não corresponde à estrutura do projeto

32 Teste de Componente Componente Integração de uma ou mais unidades Pode ser uma unidade ou um sistema Teste de Componente Mostrar que o componente NÃO SATISFAZ a sua especificação funcional e/ou que a sua estrutura implementada não corresponde à estrutura do projeto

33 Teste de Integração Integração Processo onde os componentes agregados em componentes maiores são Teste de Integração Teste de Componente pode ter sido satisfatório. Mesmo assim, a combinação destes componentes não está correta

34 Teste de Integração (cont.) Exemplos Chamadas ou retornos incorretos Critérios de validação de dados Manipulação errônea de objetos

35 Teste de Integração (cont.) Exemplos (cont.) Considere rotina A que chama a si próprio Teste inicial de componente NÃO INCLUI a chamada a sub-componentes a chamada recursiva a A não é testada Teste de Integração é testar a chamada a A e o retorno Tem-se agora um novo componente integrado pois trabalha com o mecanismo de pilha; então teria que passar por um teste adicional

36 Teste completo é possível? Qual é o objetivo de teste? Se fosse para PROVAR que um programa não tem erros Em Teoria, isto é impossível Na Prática, isto também é impossível

37 Teste completo é possível? (cont.) Abordagens demonstrando programa está correto que Teste Funcional Teste Estrutural Provas de Correção (Correctness Proofs) o

38 Teste Funcional Qualquer programa trabalha com um número FINITO de entradas Independente do significado destas entradas, será que não dá para considerá-las como um stream de bits? Então, um teste completo seria colocar o programa rodando para todas as possíveis combinações destas streams

39 Teste Funcional (cont.) Para cada entrada Aceita e produz uma saída correta Aceita e produz uma saída errada Não aceita e informa deste fato Considere um string de entrada de caracteres 2 combinações possíveis de entradas e suas saídas correspondentes

40 Teste Funcional (cont.) É impraticável Supondo que cada teste demore 1 microsegundo DUAS VEZES A IDADE ESTIMADA DO UNIVERSO

41 Teste Funcional (cont.) Quem garante que o hardware e o software usados para: Gerar as entradas Comparar a saída resultante com a saída esperada Documentar estes fatos São livres de erros?????????????????????

42 Teste Funcional (cont.) O problema é que Testes Funcionais são condicionados na SUPOSIÇÃO que as ferramentas de testes e ferramentas que preparam os testes são corretas Somente a rotina em teste está ERRADA No mundo real, isto seria um ABSURDO

43 Teste Estrutural Testes tem que ser projetados de tal forma que eles seriam suficientes para garantir que TODO O CAMINHO dentro da rotina seja executada O que fazer quando se encontra loops infinitos? E se dentro de cada destes loops houverem vários caminhos?

44 Teste Estrutural (cont.) Mesmo uma rotina pequena poderá ter milhões (ou bilhões) de caminhos Isto faz com que teste completo seja impraticável Aqui também devem haver garantias que entradas preparadas são livres de erros, etc.

45 Prova de Correção Provas formais dependem de uma combinaçao de conceitos funcionais e estruturais A especificação tem que ser descrita formalmente (linguagem matemática) Prova indutiva é usada nos comandos para verificar se há saída correta para a combinação de todas as entradas

46 Prova de Correção (cont.) Na prática, isto é muito caro Tem sido usado muito em rotinas numéricas ou em software crucial como kernel de segurança ou pedaços de um compilador Há outros problemas também

47 Prova de Correção (cont.) Quem garante que a especificação é possível de se obter? Quem garante que dá para provar a consistência e completude desta especificação? É provado que isto é um problema não solúvel

48 Barreiras para Teste Completo Manna, Z. & Waldinger, R. The logic of computer programming. IEEE Transactions on Software Engineering 4: , 1978 Não se pode ter certeza que as especifcações estão corretas Nenhum sistema de verificação pode verificar se todos os programas estão corretos Não se pode ter certeza que um sistema de verificação está correto.

49 Qual a solução? Mudar a abordagem de PROVA ABSOLUTA para DEMONSTRAÇÃO CONVINCENTE Realizar testes suficientes para garantir que a probabilidade de falha devido aos erros que hibernam é baixa o suficiente para aceitar O que é suficiente?

50 Qual a solução? (cont.) Suficiente depende da aplicação O que é suficiente para um jogo não é suficiente para um reator nuclear Técnicas de testes e modelos de confiabilidade estão em constante evolução e será possível, baseado em resultados de testes, fazer uma medida quantitativa da confiabilidade do sistema

51 Teste de Conformidade Foco maior será dado a testes funcionais ou seja teste tipo CAIXA PRETA (Black box testing) Este caso é considerado como Teste de Conformidade (Conformance Testing), i.e., a implementação está ou não está de acordo com a especificação

52 Teste de Conformidade (cont.) Exemplos: Protocolos de comunicação Sistemas concorrentes Falhas e recuperação de sistemas Configuração de sistemas Banco de dados distribuídos

53 Teste de Conformidade (cont.) Não se pode testar algo sem primeiro entendê-lo Ou seja, teria que entender o que a Implementação Sob Teste (IUT) deve fazer Teste pode ser considerado um problema de busca: combinações de entradas e estados

54 Teste de Conformidade (cont.) Se houver uma especificação e se for possível modelá-la por alguma técnica, pode-se então gerar os casos de teste Executaria a implementação sob teste (IUT) baseado nos casos obtidos acima Poderia confrontar com a especificação para dar um veredito se a IUT está ou não de acordo com a especificação

55 Teste de Conformidade (cont.) Força bruta está fora de questão!!! Testes aleatórios não leva ao objetivo Então, esta busca deve ser Sistemática Focada Automatizada

56 Teste de Conformidade (cont.) Sistemática Para garantir que toda a combinação seja testada Focada Aproveitar as vantagens de se ter informações disponíveis sobre onde existiriam possíveis erros

57 Teste de Conformidade (cont.) Automatizada Para produzir e executar o maior número de testes consistentes e repetitivos Para atingir estes três objetivos, o ideal é utilizar MODELOS Testes baseados em Modelos (ModelBased Testing) Testing

58 Modelagem Modelagem é utilizada para representar um sistema real onde se pode captar relações essenciais A vantagem é que modelos são mais fáceis de serem desenvolvidos e analisados do que sistemas físicos e.g., modelos são usados para explorar vários tópicos através de simulação

59 Modelagem (cont.) No caso de testes, modelagem deve facilitar a representação da especificação para gerar os casos de testes Qual técnica a ser utilizada para modelar a especificação? Grafo (Máquina de Estados)

60 Modelagem (cont.) a/0 Estado inicial S1 Seqüência abb S1, S2 e S3 Saída: S1 b/0 b/1 S2 a/1 b/1 011 S3 a/0 [Lee & Yannakakis, 1996]

61 Métodos para Geração de Seqüências de Testes Método T (Transition Tour) Método U (UIO Unique Input/Output) Método D Método W

62 Exemplo Método T B/0 0 B/1 A/0 A/1 4 B/1 2 B/0 B/1 A/0 A/1 A/0 3 1 B A B A B A A A A A A A B B [Sidhu & Leung, 1989] 4 2

63 Switch Cover Method

64 Switch Cover Method (cont.) Step 1 Dual Graph creation Step 4 Nodes are traversed Result: abf, abrbf, cf, crbf Step 2 Arc creation, considering all nodes in the original graph Step 3 Transformation into a Eulerized Graph by balancing the polarity of the nodes

65 Exemplo: Command Recog Component from OBDH

66 PerformCharts em Testes Geração de casos de testes Vários métodos desde que o software esteja especificado em Diagramas de Estado Usar PerformCharts para especificar um software complexo em Statecharts para gerar automaticamente o diagrama de estados Associar um método (geração de casos de teste transition tour, switch cover, W) à especificação

67 PerformCharts em Testes (cont.)

68 PerformCharts em Testes (cont.) Mapping the Methodology Step a: PcML Specification <States> </States> <Root Name="ReceivingCommand" Type="AND"> <State Name="A" Type="XOR" Default="Idle"> <State Name="Idle" Type="BASIC"/> <State Name="CountingTime" Type="BASIC"/> </State> <State Name="B" Type="XOR" Default="WaitingSync"> <State Name="WaitingSync" Type="BASIC"/> <State Name="CheckingField" Type="XOR" Default= WaitingExpId > <State Name="WaitingExpId" Type="BASIC"/> <State Name="WaitingType" Type="BASIC"/> <State Name="WaitingSize" Type="BASIC"/> <State Name="Aborting" Type="BASIC"/> <State Name="WaitingChecksum" Type="BASIC"/> <State Name="WaitingData" Type="BASIC"/> </State> </State> </Root>

69 PerformCharts em Testes (cont.) M a p p in g t h e M e t h o d o lo g y S t e p b : C + + P r o g r a m ( o u t p u t ) S t a t e c h a r t R e c e iv in g C o m m a n d ; // S t at e s R e c e iv // S t at e A R e c e iv R e c e iv R e c e iv // S t at e Re c e Re c e Re c e Re c e Re c e B iv iv iv iv iv R e c e iv R e c e iv R e c e iv // Ev ents R e c e iv in g C o m m a n d. c r e a t e R o o t ( " R e c e iv i n g C o m m a n d ", A N D ) ; in g C o m m a n d. c r e a t e S o n S t a t e ( " A ", O R, " R e c e iv in g C o m m a n d " ) ; in g C o m m a n d. c r e a t e S o n S t a t e ( " I d le ", B A S I C, " A " ) ; in g C o m m a n d. c r e a t e S o n S t a t e ( " C o u n t in g T i m e ", B A S I C, " A " ) ; in in in in in g g g g g C C C C C o o o o o m m m m m m m m m m a a a a a n n n n n d d d d d.c.c.c.c.c re re re re re a a a a a t t t t t e e e e e S S S S S o o o o o n n n n n S S S S S t t t t t a a a a a t t t t t e e e e e ( ( ( ( ( " B ", O R, " R e c e iv in g C o m m a n d " ) ; " W a it i n g S y n c ", B A S I C, " B " ) ; " C h e c k in g F ie l d ", O R, " B " ) ; " W a it i n g E x p I d ", B A S I C, " C h e c k i n g F ie l d " ) ; " W a it i n g T y p e ", B A S I C, " C h e c k i n g F ie ld " ) ; in g C o m m a n d. s e t D e f a u lt E n t r y ( " A ", " I d le " ) ; in g C o m m a n d. s e t D e f a u lt E n t r y ( " B ", " W a it i n g S y n c " ) ; in g C o m m a n d. s e t D e f a u lt E n t r y ( " C h e c k in g F ie l d ", " W a it in g E x p id " ) ; in g C o m m a n d. c r e a t e P r i m E v e n t ( " E B 9 ", 1. 0 ) ; R e c e iv in g C o m m a n d. c r e a t e P r i m E v e n t ( e id r c ", 1. 0 ) ; R e c e iv in g C o m m a n d. c r e a t e P r i m E v e n t ( c o m m a n d r e c e iv e d " ) ; R e c e iv in g C o m m a n d. c r e a t e P r i m E v e n t ( s t a r t in g t i m i n g c o u n t in g " ) ;

70 PerformCharts em Testes (cont.) M a p p in g t h e M e t h o d o lo g y S t e p c : F la t F S M ( o u t p u t ) N O D E L A B E L = R e ce iv in g C o m m a n d... Le v el = 0... T y p e = A N D... * * * R O O T N O D E* * *... So n s = A -> B * * * * * * N O D E LABEL = A... Le v el = 1... T y p e = O R... Fa t h e r = R e ce iv in g C o m m a n d... D e fa u lt = I d le..... S o n s = I d le - > C o u n t i n g T i m e * * * * * * N O D E L A B E L = I d le... Le v el = 2... T y p e = B A SIC... Fath e r = A... So n s = * * * * * *

71 PerformCharts em Testes (cont.)

72 PerformCharts em Testes (cont.) M a p p in g t h e M e t h o d o lo g y S t e p d : B a s e o f f a c t s ( o u t p u t ) i n it i a l ( i d l e _ w a i t i n g s y n c ). t r a n s ( i d le _ w a it i n g s y n c, t r a n s it io n 0, c o u n t i n g t i m e _ w a i t i n g e x p i d, L 0, L n ) : r e c e iv e l( 'E B 9 ', L 0, L 1 ), t ra n s m it ( L 1, L n ). t r a n s ( c o u n t i n g t i m e _ w a i t i n g e x p i d, t r a n s it i o n 2, e n d, L 0, L n ) : r e c e i v e l ( 'w a it i n g t i m e e x p i r e d ', L 0, L 1 ), t ra n s m it ( L 1, L n ). t r a n s ( c o u n t i n g t i m e _ w a i t i n g e x p i d, t r a n s it i o n 3, c o u n t i n g t i m e _ w a it i n g t y p e, L 0, L n ) : r e c e i v e l ( e i d r c ', L 0, L 1 ), t ra n s m it ( L 1, L n ).

73 PerformCharts em Testes (cont.) M a p p in g t h e M e t h o d o lo g y S t e p e : T e s t C a s e s ( o u t p u t ) s e n d d a t a (L,E B 9 ) re cd a t a ( ) s e n d d a t a ( L, w a it i n g t i m e e x p i r e d ) re cd a t a ( ) s e n d d a t a (L,E B 9 ) re cd a t a ( ) s e n d d a t a ( L,e id rc ) re c d a t a ( ) s e n d d a t a ( L, w a it i n g t i m e e x p i r e d ) re cd a t a ( ) s s s s e e e e n n n n d d d d d d d d ata ata ata ata (L,E B 9 ) re cd a t a ( ) ( L,e id rc ) re c d a t a ( ) ( L,t y p e rc ) re c d a t a ( ) ( L, w a it i n g t i m e e x p i r e d ) re cd a t a ( ) s s s s s e e e e e n n n n n d d d d d d d d d d ata ata ata ata ata (L,E B 9 ) re cd a t a ( ) ( L,e id rc ) re c d a t a ( ) ( L,t y p e rc ) re c d a t a ( ) ( L,s iz e rc ) re c d a t a ( ) ( L, w a it i n g t i m e e x p i r e d ) re cd a t a ( ) s s s s s s e e e e e e n n n n n n d d d d d d d d d d d d ata ata ata ata ata ata (L,E B 9 ) re cd a t a ( ) ( L,e id rc ) re c d a t a ( ) ( L,t y p e rc ) re c d a t a ( ) ( L,s iz e rc ) re c d a t a ( ) ( L,d a ta rc) re cd a t a ( ) (L,ck s u m rc) re cd a t a ( )

74 In s tâ n c ia P cm L E n tr a d a d a P e r fo r m C h a r ts M EF SSc oh eum r ac e P c cm o Ld e C a so s de T e ste A p lic a ç ã o P erl X M L M o d e lo d o S t sai st tee Cm ah ae mr t s ( H a r e l) P cm L R e s u lta d o program a em C ++ P e r fo r m C h a r ts C ondado M o d e sto A p lic a ç ã o Java A v a l ia ç ã o de D e se m p e n h o

75 PerformCharts em Testes (cont.) PcM L S p e c if ic a t io n P e r l S c r ip t Test Cases C+ + Prog ram Condado Pe rfo rm C h a rts B ase of Facts FSM ( X M L fo rm a t) X S LT Parser

76 Bibliografia Lee, D.; Yannakakis, M. Testing Finite State Machines: State Identification and Verification, IEEE Transactions on Computers, 43(3), 1994 Lee, D.; Yannakakis, M. Principles and Methods of Testing Finite State Machines A Survey. In: Proceedings of the IEEE, 84(8), 1996, pp Martins, E.; Sabião, S.B.; Ambrósio, A.M. ConData: a tool for automating Specification based Test Case Generation for Communicating Systems. Software Quality Journal, 8(4), , 1999 Sidhu, D.P.; Leung, T. Formal Methods for Protocol Testing: A Detailed Study, IEEE Transactions on Software Engineering, 15(4), 1989, pp

77 Bibliografia (cont.) Beizer, B. Software Testing Computer Press, Techniques. International Thomson Binder, R. V. Testing Object-Oriented Systems: Models, Patterns and Tools. Addison Wesley. 1999

78