Teste de Sistemas de Software Alexandre Monteiro 1

Teste de Sistemas de Software Alexandre Monteiro 1

Motivação n n n Ocorrência de falhas humanas no processo de desenvolvimento de software é considerável Processo de testes é indispensável na garantia de qualidade de software Custos associados às falhas de software justificam um processo de testes cuidadoso e bem planejado 2

Conceitos Básicos 3

Falha, Falta e Erro n Falha n n Incapacidade do software de realizar a função requisitada (aspecto externo) Exemplo n Terminação anormal, restrição temporal violada 4

Falha, Falta e Erro n Falta n n Causa de uma falha Exemplo n Código incorreto ou faltando 5

Falha, Falta e Erro n n n Estado intermediário (instabilidade) Provém de uma falta Pode resultar em falha, se propagado até a saída 6

Falta, erro e falha Falta Erro Falha Pode iteragir… 7

Noção de confiabilidade n Algumas faltas escaparão inevitavelmente n n n Tanto dos testes Quanto da depuração Falta pode ser mais ou menos perturbadora n Dependendo do que se trate e em qual freqüência irá surgir para o usuário final 8

Noção de confiabilidade n Assim, precisamos de uma referência para decidir n n Quando liberar ou não sistema para uso Confiabilidade de software n n É uma estimativa probabilística Mede a freqüência com que um software irá executar sem falha n n Em dado ambiente E por determinado período de tempo 9

Noção de confiabilidade n Assim, entradas para testes devem se aproximar do ambiente do usuário final 10

Dados e Casos de Teste n Dados de Teste n n Entradas selecionadas para testar o software Casos de Teste n n Dados de teste, bem como saídas esperadas de acordo com a especificação (Veredicto) Cenários específicos de execução 11

Finalidade dos testes n n n Averiguar se todos os requisitos do sistema foram corretamente implementados Assegurar, na medida do possível, a qualidade e a corretude do software produzido Reduzir custos de manutenção corretiva e re-trabalho 12

Finalidade dos testes n n n Assegurar a satisfação do cliente com o produto desenvolvido Identificar casos de teste de elevada probabilidade para revelar erros ainda não descobertos (com quantidade mínima de tempo e esforço) Verificar a correta integração entre todos os componentes de software 13

Eficácia de Testes n n n A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro Um bom caso de teste é aquele que apresenta uma elevada probabilidade de revelar um erro ainda não descoberto Um teste bem sucedido é aquele que revela um erro ainda não descoberto 14

Padronização de Testes n Sistemático n n n Testes aleatórios não suficientes Testes devem cobrir todos os fluxos possíveis do software Testes devem representar situações de uso reais Documentado n Que testes foram feitos, resultados, etc. n Se encontrou ou não erro em determinada situação, deve-se poder repeti-lo Repetível 15

Abordagens de teste n Abordagem funcional (“caixa preta”) n Os testes são gerados a partir de uma análise dos relacionamentos entre os dados de entrada e saída, com base nos requisitos levantados com os usuários n n Especificação (pré e pós-condições) Geralmente é aplicado durante as últimas etapas do processo de teste 16

Abordagens de teste n Abordagem funcional (“caixa preta”) n Objetivo n n Erros associados a não satisfação da especificação Erros na GUI Erros nas estruturas de dados ou acesso ao banco de dados Problemas de integração 17

Abordagens de teste n Abordagem estrutural (“caixa branca”) n n Os testes são gerados a partir de uma análise dos caminhos lógicos possíveis de serem executados Conhecimento do funcionamento interno dos componentes do software é usado 18

Abordagens de teste n Abordagem estrutural n Objetivo n n Garantir que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez Realizar todas as decisões lógicas para valores falsos e verdadeiros Executar laços dentro dos valores limites Executar as estruturas de dados internas 19

Abordagens de teste n Abordagem estrutural n Programador n n Testa o programa em pedaços Encontra quais as partes do programa que já foram testadas Conhece quais partes do programa serão modificadas Verifica os limites internos no código que são invisíveis ao testador externo “É parte da atividade de codificação” 20

Estágios de Teste n n n Teste de Unidade Teste de Aspectos OO Teste de Integração Teste de Sistema Teste de Aceitação 21

Estágios de teste n Teste de unidade n n Componentes individuais (ex. : métodos, classes) são testados para assegurar que os mesmos operam de forma correta Teste de aspectos OO n n n Teste de Iteradores Teste de Abstrações de Dados Teste de Hierarquia de Tipos 22

Estágios de teste n Teste de integração n n A interface entre as unidades integradas é testada Teste de sistema n Os elementos de software integrados com o ambiente operacional (hardware, pessoas, etc. ) são testados como um todo 23

Estágios de teste n Testes de aceitação (“caixa preta”) são realizados pelo usuário n n n Finalidade é demonstrar a conformidade com os requisitos do software Envolve treinamento, documentação e empacotamento Podem ser de duas categorias: n Testes alfa n Feitos pelo usuário, geralmente nas instalações do desenvolvedor, que observa e registra erros e/ou problemas 24

Estágios de teste n Testes de aceitação (“caixa preta”) são realizados pelo usuário n Testes beta n Feitos pelo usuário, geralmente em suas próprias instalações, sem a supervisão do desenvolvedor. Os problemas detectados são então relatados para o desenvolvedor 25

Tipos de Teste n n São definidos em relação aos diversos tipos de requisitos descritos no documento de requisitos Alguns exemplos são: n n n Teste funcional Teste de recuperação de falhas Teste de segurança Teste de performance Teste de carga 26

Tipos de teste n Teste funcional (regras de negócio) n n A funcionalidade geral do sistema em termos de regras de negócio (fluxo de trabalho) é testada Condições válidas e inválidas 27

Tipos de teste n Teste de recuperação de falhas n n O software é forçado a falhar de diversas maneiras para que seja verificado o seu comportamento Bem como a adequação dos procedimentos de recuperação n A recuperação pode ser automática ou exigir intervenção humana 28

Tipos de teste n Teste de segurança e controle de acesso n n Verifica se todos os mecanismos de proteção de acesso estão funcionando satisfatoriamente Teste de integridade de dados n Verifica a corretude dos métodos de acesso à base de dados e a garantia das informações armazenadas 29

Tipos de teste n Teste de performance n n Verifica tempo de resposta e processamento (para diferentes configurações, número de usuários, tamanho do BD, etc. ) Exemplo n n Recuperar conta de usuário em x segundos São necessários definir n Servidores e clientes, sistemas operacionais e protocolos utilizados 30

Tipos de teste n Teste de volume (carga) n n n Foca em transações do BD Verifica se o sistema suporta altos volumes de dados em uma única transação Verifica o número de terminais, modems e bytes de memória que é possível gerenciar 31

Tipos de teste n Teste de estresse n Verifica a funcionalidade do sistema em situações limite n n Pouca memória ou área em disco, alta competição por recursos compartilhados (ex: vários acessos/transações no BD ou rede) Exemplo: pode-se desejar saber se um sistema de transações bancárias suporta uma carga de mais de 100 transações por segundo ou se um sistema operacional pode manipular mais de 200 terminais remotos 32

Tipos de teste n Teste de configuração ou portabilidade n n Verifica o funcionamento adequado do sistema em diferentes configurações de hardware/software O que testar n n Compatibilidade do software/hardware Configuração do servidor Tipos de conexões com a Internet Compatibilidade com o browser 33

Tipos de teste n Teste de instalação e desinstalação n n Verifica a correta instalação e desinstalação do sistema para diferentes plataformas de hardware/software e opções de instalação O que testar n n n Compatibilidade do hardware e software Funcionalidade do instalador/desinstalador sob múltiplas opções/condições de instalação GUI do programa instalador/desinstalador 34

Tipos de teste n Teste da GUI (usuário) n n n Aparência e comportamento da GUI Navegação Consistência Aderência a padrões Tempo de aprendizagem Funcionalidade 35

Tipos de teste n Teste de documentação n Verifica se a documentação corresponde à informação correta e apropriada: n n online escrita help sensível ao contexto Teste de ciclo de negócios n Garante que o sistema funciona adequadamente durante um ciclo de atividades relativas ao negócio 36

Teste de regressão n n Re-execução de testes feitos após uma manutenção corretiva ou evolutiva Em processos de desenvolvimento iterativos, muitos dos artefatos produzidos nas primeiras iterações são usados em iterações posteriores 37

Teste de unidade 38

Teste de unidade n n Investigar a qualidade de componentes individuais (ex: métodos, classes) Objetivo: n Testar comportamento (especificação) e estrutura interna (lógica e fluxo de dados) 39

Estratégia para Teste de unidade n Driver Módulo a ser testado Interface Estrutura de dados local Condições limite Caminhos independentes Caminhos de tratamento de erros Driver de teste – programa que executa o módulo a ser testado usando os dados do caso de teste e verifica o veredicto n Casos de teste Este será o propósito de uso do JUnit Resultados 40

Teste de Caixa Preta n n Casos de teste são gerados usando somente a especificação Vantagens: n n n Procedimento de teste não é influenciado pela implementação Resultados testes podem ser avaliados por pessoas sem conhecimento da linguagem de programação Robusto em relação a mudanças na implementação (Abordagem XP. . . ) 41

Teste de Caixa Preta n n n Deve-se analisar a relação entre a pré e a pós-condição Tentar cobrir todas as combinações lógicas existentes entre essas partes Dada a relação pré => pós, tem-se n n pré=true => pós=true pré=false => exceção 42

Seleção de Dados de Teste n Há várias técnicas para seleção de dados de teste { n n Particionamento Fronteiras Pares ortogonais Etc. 43

Particionamento Determinando partições Selecionando representantes 44

Fronteiras n n Estatísticas indicam que há uma maior suscetibilidade a erros nas fronteiras de partições (limites dos tipos) Tanto em dados válidos quanto inválidos n n Assim, para x > 0, não bastaria usar qualquer x > 0 (particionamento) Mas sim x = 1 (válido no limite) e x = 0 (inválido no limite) 45

Fronteiras n A técnica da seleção de dados pelas fronteiras é muito indicada para investigar bom funcionamento de n n Arrays Vetores Algoritmos de busca/ordenação Etc. 46

Teste de Caixa Branca n n n Casos de teste são gerados a partir da implementação Não se pode avaliar o grau de cobertura de uma funcionalidade pelo teste de caixa preta A idéia é gerar dados de teste que permitam exercitar algum critério em relação ao código (cobertura) 47

Grafo de fluxo de controle nó = bloco de comandos seqüenciais aresta ou ramo = transferência de controle 1 bloco seqüencial 1 1 3 2 2 4 if-then-else seleção 1 . . . m 3 n case 2 1 2 3 while 3 repeat-until repetição 48

Grafo de fluxo de controle: Exemplo Cálculo de xy 1. read x, y; 2. if y < 0 3. then p : = 0 - y 4. else p : = y; 5. z : = 1. 0; 6. while p 0 do 7. begin z : = z * x; p : = p - 1; end; 8. if y < 0 9. then z : = 1 / z; 10. write z; end; 1 y<0 2 3 y 0 4 5 p 0 6 7 y<0 8 y 0 9 10 49

Critérios de cobertura n Tipos n n Cobertura de instruções Cobertura de decisões Cobertura de condições Cobertura de caminhos 50

Cobertura de instruções 1 y<0 2 3 y 0 Critério: cada instrução deve ser executada pelo menos 1 vez 4 5 p 0 nós dados {1, 2, 3, 5, 6, 7, 6, 8, 9, 10} x, y < 0 (4, -1) 6 {1, 2, 4, 5, 6, 8, 10} 7 y<0 predicados x, y = 0 (4, 0) 8 y 0 9 10 51

Cobertura de decisões 1 y<0 2 3 y 0 4 5 p 0 6 Critério: cada ramo deve ser percorrido pelo menos 1 vez ramos predicados dados {(1, 2), (2, 3), (3, 5), (5, 6) x, y < 0 (4, -1) x, y = 0 (4, 0) (6, 7), (7, 6), (6, 8), (8, 9), (9, 10)} {(1, 2), (2, 4), (4, 5), (5, 6), 7 y<0 (6, 7), (7, 6), (6, 8), (8, 10)} 8 y 0 9 10 52

Cobertura de decisões c 1. if a >= 0 and a <= 200 2. then m : = 1 3. else m : = 3 4. “Dep. em a. . . ” ramos dados {(1, 2), (2, 4)} a=5 {(1, 3), (3, 4)} a = -5 c 1 2 c 3 4 53

Cobertura de decisões/condições c 1. if a >= 0 and a <= 200 2. then m : = 1 3. else m : = 3 4. “Dep. em a. . . ” ramos dados {(1, 1 A), (1 A, 2), (2, 4)} a=5 {(1, 1 A), (1 A, 3), (3, 4)} a = 500 {(1, 3), (3, 4)} a = -5 1 a 0 a 200 a<0 1 A 2 a > 200 3 4 Critério: todas as condições devem ser avaliadas para valores V/F em cada (sub)decisão 54

Aproximação do Fluxo Completo j = k; for(int i=1; i<=100; i++) if(Tests. pred(i*j)) j++; Quem são os casos de testes para o fragmento de código acima? 55

Aproximação do Fluxo Completo n Laços com iterações fixas n n Laços com iterações variáveis n n Considerar 2 iterações e situações de terminação do laço Considerar 0, 1 e 2 iterações, bem como casos de terminação Recursão n Considerar situações onde não haverá chamada recursiva e com apenas 1 chamada 56

Iteração Fixa j = k; for(int i=1; i<=100; i++) if(i==j) break; else if(Tests. pred(i*j)) j++; 1 i 2 e (j=1 ou j=2) 57

Iteração Variável while( x<y || x>z ) {. . . } 1. x < y || x > z (1 e 2 iterações) 2. x y && x z + Condições de terminação 58

Recursão static int fat(int i) { int res; if(i==0) res = 1; else res = i * fat( i – 1 ); return res; } 1. i = 0 2. i = 1 59

Teste de Abstrações de Dados n n n Testar os métodos de maneira conjugada Testes devem explorar propriedades esperadas para a composição de métodos Seqüências de testes devem ser originadas tanto pelo teste de caixa preta quanto o de caixa branca 60

Exemplo n n Suponha uma classe com métodos inserir, remover, consultar, etc. Então, seqüências como: n n consultar(x) -> inserir(x) -> remover(x) inserir(x) -> consultar(x) remover(x) -> consultar(x) 61

Automação de Testes Integrada n n n Testar é essencial como referencial de qualidade Falhas humanas são comuns Realizar todos os testes, associados a artefatos modificados, é imprescindível 62

Bibliografia n n Liskov, B. et al. Program Development in Java (Cap. 10) Sommerville, I. Software Engineering (Cap. 20) 63