Aula02-Definicoes

(1)

Teste de Software

Aula 02 – Definições

(2)

Agenda

 _{Teste de Software}

 _{Defeito, Erro ou Falha?}

 _{Dimensões do Teste}

_{Níveis de Teste}

_{Tipos de Teste}

(3)

Teste de Software

 _{“Teste de software é o processo de executar uma}

aplicação com o objetivo de verificar se ela satisfaz satisfaz

requisitos

requisitos específicos e de detectar erros” - [British detectar erros

Computer Society-SIGST].

 _{Teste de software fornece à equipe do projeto a}

sensibilidade

sensibilidade de dizer se o produto está pronto para ser entregue.

(4)

Teste de Software

 _{“Teste de software consiste na verificação dinâmica}_{verificação dinâmica}

do comportamento de um programa, por meio de

um conjunto finitoconjunto finito de casos de teste, selecionados a

partir de um conjunto infinito de possibilidades,

contra um comportamento esperadocomportamento esperado especificado.”

_{Verificação dinâmica:}_{Verificação dinâmica:}_{Os testes serão}

realizados com o produto ou componente de software em execução.

(5)

Teste de Software

_{Verificação estática:}_{Verificação estática:}_{Os testes são aplicados}

sobre os artefatos, sem a execução do produto ou componente de software.

_{Conjunto finito:}_{Conjunto finito:}_{Os testes são aplicados a um}

conjunto limitado de casos de teste selecionado através do equilíbrio entre os recursos

(6)

Teste de Software

_{Comportamento esperado:}_{Comportamento esperado:}_{É necessário definir}

os resultados aceitáveis. O comportamento

observado do produto pode ser comparado com: • Especificação;

• Expectativas do usuário;

• Comportamento antecipado a partir de requisitos implícitos ou expectativas razoáveis.

(7)

Defeito, Erro ou falha

 _{Geralmente o termo erro é utilizado de forma}

generalizada para definir quaisquer ocorrências de falhas ou até mesmo defeito.

(8)

Defeito, Erro ou falha

 _{Defeito: Está associado ao universo físico. É}

ocasionado por uma ação inconsistente cometida por um indivíduo ao tentar executar uma tarefa

(resolver um problema, implementar um método ou utilizar uma ferramenta). Por exemplo, uma

instrução ou comando incorreto.

 _{Erro: Está associado ao universo da informação. É}

uma manifestação concreta de um defeito gerando um valor obtido diferente do valor esperado. Por consequência de uma falha, o erro acontece

(9)

Defeito, Erro ou falha

 _{Falha: Está associado ao universo do usuário. É um}

desvio na especificação que ocorre em consequência de um erro gerando um

comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros.

(10)

Defeito, Erro ou falha

 _{Um defeito não necessariamente leva a um estado}

de erro, pois a linha de código com defeito pode nunca ser executada.

 _{Um erro também não necessariamente leva a um}

estado de falha, pois talvez uma informação nunca seja usada.

(11)

Dimensões do Teste

1 3 2 Quando testar? Como testar? O que testar? Tipos de Teste Teste de Funcionalidade Teste de Regressão Teste de Interface Teste de Desempenho Teste de Carga Teste de Usabilidade Teste de Volume Teste de Segurança Níveis de Teste Teste de Unidade Teste de Integração Teste de Sistema Teste de Aceitação Técnicas de Teste Teste Estrutural Teste Funcional

(12)

Níveis de Teste

1 3 2 Quando testar? Como testar? O que testar? Tipos de Teste Teste de Funcionalidade Teste de Regressão Teste de Interface Teste de Desempenho Teste de Carga Teste de Usabilidade Teste de Volume Teste de Segurança Níveis de Teste Teste de Unidade Teste de Integração Teste de Sistema Teste de Aceitação Técnicas de Teste Teste Estrutural Teste Funcional

(13)

(14)

(15)

Níveis de Teste

 _{Teste de Unidade}

_{Geralmente realizado pelo desenvolvedor}

(16)

Níveis de Teste

 _{Teste de Unidade (cont.)}

_{Os testes unitários concentram-se em cada}

módulo do software, de acordo com o que é implementado no código fonte.

_{Tem por objetivo explorar a menor unidade do}

projeto, procurando provocar falhas

ocasionadas por defeitos de lógica e de implementação em cada módulo,

(17)

Níveis de Teste

_{Cada módulo é testado individualmente}

garantindo que ele funcione adequadamente.

_{Utiliza as técnicas de teste de caixa branca.}

_{O universo alvo desse tipo de teste são os}

métodos dos objetos ou mesmo pequenos trechos de código.

(18)

Níveis de Teste

_{A interface com o módulo é testada para ter a}

garantia do fluxo de informações.

_{A estrutura de dados local é examinada para ter}

a garantia de que dados armazenados

temporariamente mantêm sua integridade durante todos os passos de execução

(19)

Níveis de Teste

_{Aspectos a serem validados no Teste de}

Unidade:

• Exercitar as linhas de código da unidade;

• Exercitar os desvios condicionais da unidade; • Validar os requisitos funcionais da unidade; • Validar os requisitos de usabilidade da

unidade;

• Validar os requisitos de sistema relativos a unidade.

(20)

Níveis de Teste

 _{Teste de Integração}

_{Geralmente realizado pelo desenvolvedor}

(21)

Níveis de Teste

 _{Teste de Integração (cont.)}

_{As unidades são integradas e módulos}

montados para formarem um pacote de software.

_{Visa provocar falhas associadas às interfaces}

entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto.

_{Utiliza principalmente as técnicas de teste de}

(22)

Níveis de Teste

_{É uma técnica sistemática para a construção da}

estrutura de programa, realizando-se, ao mesmo tempo, testes para descobrir erros associados a interfaces.

_{Requer conhecimento da arquitetura do}

software.

_{Verifica-se as dependências, interfaces e}

(23)

Níveis de Teste

_{Abordagens de teste de integração:}

• Não Incremental (big-bang):

– O programa completo é testado como um todo e o resultado pode ser o caos.

– Quando erros são encontrados, a

correção é difícil porque o isolamento das causas é complicado pela vasta amplitude do programa inteiro.

(24)

Níveis de Teste

_{Abordagens de teste de integração (cont.):}

• Incremental (bottom-up):

– O programa é construído e testado em pequenos segmentos, onde os erros são mais fáceis de serem isolados e corrigidos. – As interfaces têm maior probabilidade de

serem testadas completamente e uma

abordagem sistemática ao teste pode ser aplicada.

(25)

Níveis de Teste

 _{Teste de Sistema}

_{Realizado por uma equipe de teste (arquiteto de}

(26)

Níveis de Teste

 _{Teste de Sistema (cont.)}

_{Avalia o software em busca de falhas por meio}

da utilização do mesmo, como se fosse um usuário final.

_{Dessa maneira, os testes são executados nos}

mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um

usuário utilizaria no seu dia-a-dia de manipulação do software.

(27)

Níveis de Teste

 _{Teste de Sistema (cont.)}

_{Requer um ambiente muito semelhante ao da}

produção.

_{Verifica se o software satisfaz seus requisitos.}

_{O propósito primordial é colocar completamente}

à prova o software e para isso, deve-se validar: • Requisitos funcionais

• Requisitos não funcionais

(28)

Níveis de Teste

 _{Teste de Aceitação}

_{Realizados geralmente por um restrito grupo de}

(29)

Níveis de Teste

 _{Teste de Aceitação (cont.)}

_{A aceitação do software é realizada por meio de}

uma série de testes de caixa preta que simulam operações de rotina do sistema de modo a

verificar se seu comportamento está de acordo com os requisitos.

_{A aceitação é bem sucedida quando o software}

funciona de uma maneira razoavelmente esperada pelo cliente.

(30)

Níveis de Teste

 _{Teste de Aceitação (cont.)}

_{A Especificação de Requisitos de Software}

contém os critérios de validação que formam a base para uma abordagem ao teste de

aceitação.

_{Deve-se validar:}

• Requisitos funcionais

• Requisitos não funcionais

(31)

Tipos de Teste

1 3 2 Quando testar? Como testar? O que testar? Tipos de Teste Teste de Funcionalidade Teste de Regressão Teste de Interface Teste de Desempenho Teste de Carga Teste de Usabilidade Teste de Volume Teste de Segurança Níveis de Teste Teste de Unidade Teste de Integração Teste de Sistema Teste de Aceitação Técnicas de Teste Teste Estrutural Teste Funcional

(32)

Tipos de Teste

 _{Teste de Funcionalidade}

_{Utilizado para verificar se as funções do sistema}

são executadas corretamente conforme

especificado na documentação (ex.: casos de uso) e/ou se as regras de negócio estão

aplicadas.

_{Simula todos os cenários de uso do software e}

garante que todos os requisitos funcionais estejam implementados corretamente.

(33)

Tipos de Teste

 _{Teste de Funcionalidade (cont.)}

_{Segue um exemplo simples para teste da}

funcionalidade de autenticação em um sistema:

Usuário Senha Resultado Esperado

válido válida Login efetuado com sucesso válido inválida Erro: “Senha inválida”

inválido válida Erro: “Usuário inválido”

em branco válida Erro: “Campo Usuário obrigatório” válido em branco Erro: “Campo Senha obrigatório”

(34)

Tipos de Teste

 _{Teste de Regressão}

_{É uma estratégia importante para redução de}

“efeitos colaterais”.

_{Testa o software após modificações, com o}

objetivo de verificar se as alterações não afetaram outras partes do software.

_{Consiste em se aplicar, a cada nova versão do}

software ou a cada ciclo de entrega, todos os testes que já foram aplicados nas versões ou ciclos de entrega anteriores.

(35)

Tipos de Teste

 _{Teste de Regressão (cont.)}

_{Exercita as novas funcionalidades}

implementadas bem como as dependências com outras funcionalidades.

(36)

Tipos de Teste

 _{Teste de Interface}

_{Verifica se a navegabilidade e os objetos das}

telas funcionam conforme especificados.

_{Particularmente importante para o}

desenvolvimento orientado a objeto, uma vez que os objetos são definidos por suas

(37)

Tipos de Teste

 _{Teste de Performance}

_{Teste de Desempenho:}

• Testa o software nas situações previstas de pico máximo de acesso e concorrência,

conforme os requisitos não funcionais. • O perfil de funcionamento do software é

monitorado, a fim de identificar e lidar com gargalos de desempenho e processos

(38)

Tipos de Teste

 _{Teste de Performance (cont.)}

_{Teste de Carga (stress):}

• Destinado a avaliar como o sistema responde em condições atípicas simuladas.

• Pode abranger cargas de trabalho extremas, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados.

(39)

Tipos de Teste

 _{Teste de Volume}

_{Verifica a capacidade do software em lidar com}

um grande volume de dados, como entrada e saída ou residente no banco de dados.

_{Não focaliza oscilações de processamento.}

_{Abrange estratégias de teste, como, a entrada}

de dados do volume máximo em cada campo ou a criação de consultas que retornem todo o

conteúdo do banco ou que tenham tantas restrições que não retorne nenhum dado.

(40)

Tipos de Teste

 _{Teste de Usabilidade}

_{Analisa o grau de facilidade de utilização}

(manuseio e interatividade) do software do ponto de vista do usuário final.

_{Enfatizam: fatores humanos, estética,}

consistência na interface do usuário, ajuda on-line e contextual, assistentes e agentes,

documentação do usuário e material de treinamento.

(41)

Tipos de Teste

 _{Teste de Segurança}

_{Testes destinados a garantir que o software e}

os seus dados possam ser acessados apenas por determinados atores.

_{Objetiva detectar as falhas de segurança que}

podem comprometer o sigilo e a fidelidade das informações, bem como provocar perdas de dados ou interrupções de processamento.

(42)

Tipos de Teste

 _{Teste de Acessibilidade}

_{Teste destinado a garantir que o software pode}

ser utilizado por todas as pessoas,

independente de serem portadoras de deficiência ou não.

(43)

Técnicas de Teste

1 3 2 Quando testar? Como testar? O que testar? Tipos de Teste Teste de Funcionalidade Teste de Regressão Teste de Interface Teste de Desempenho Teste de Carga Teste de Usabilidade Teste de Volume Teste de Segurança Níveis de Teste Teste de Unidade Teste de Integração Teste de Sistema Teste de Aceitação Técnicas de Teste Teste Estrutural Teste Funcional

(44)

Técnicas de Teste

 _{Estabelecem o aspecto do software a ser}

considerado para definição dos requisitos de teste a serem satisfeitos.

 _{Direciona a escolha de critérios para geração de}

casos de teste

casos de teste que, ao serem executados,

exercitam os elementos requeridos pela abordagem do teste.

 _{Determinam: Como se enfoca o teste; Como serão}

conduzidos os procedimentos de teste; Como se minimiza os esforços; Como se amplia as chances de detecção de defeitos.

(45)

Técnicas de Teste

 _{Caso de Teste}

_{Conjunto de dados de entrada e os respectivos}

resultados esperados da execução.

_{São fundamentais para o Teste de Software.}

_{Representa um cenário de teste, uma situação}

diferenciada e única de comportamento no

software, com o objetivo de identificar defeitos, erros ou falhas ainda não descobertas.

(46)

Técnicas de Teste

 _{Caso de Teste (cont.)}

_{Alguns autores consideram que as ações do}

usuário, necessárias para execução da função a ser testada, também fazem parte do caso de

teste.

_{Toda a ênfase está na maneira de como}

identificar todos os possíveis cenários de teste.

_{A maneira de gerar casos de teste estará}

(47)

Técnicas de Teste

 _{Ponto de Verificação}

_{Critério para decidir se um determinado estado}

(48)

Técnicas de Teste

 _{Divisão das técnicas de teste:}

_{Teste Estrutural (Teste Caixa Branca)}

_{Teste Funcional (Teste Caixa Preta)}

(49)

Técnicas de Teste

 _{Teste Estrutural (Teste Caixa Branca)}

_{Tem por objetivo verificar se as}

estruturas internas do software operam de maneira adequada.

_{É necessário ter acesso ao}

código fonte.

_{Deriva os requisitos de teste}

com base na implementação da unidade que será testada.

(50)

Técnicas de Teste

 _{Teste Estrutural (Teste Caixa Branca) (cont.)}

_{São exercitados os laços e condições existentes}

no código.

_{Requer a execução dos componentes}

elementares do programa, ou partes do programa.

_{Identifica erros gerados por comandos}

incorretos, ausência de comandos, estrutras incorretas, variáveis não definidas, e erros de inicialização e finalizações de loops.

(51)

Técnicas de Teste

(52)

Técnicas de Teste

 _{Teste Funcional (Teste Caixa Preta)}

_{Testa as funcionalidades com}

a finalidade de garantir que os requisitos do software

construído são plenamente atendidos.

_{Permite a realização do teste}

do ponto de vista do usuário final do sistema.

(53)

Técnicas de Teste

 _{Teste Funcional (Teste Caixa Preta)}

_{Casos de teste são gerados com base nos}

requisitos do sistema a ser testado, como se este fosse uma caixa preta.

_{São fornecidas as entradas e avaliadas as}

saídas para verificar se estão em conformidade com os resultados esperados.

_{É conduzido olhando-se o software através de}

(54)

Técnicas de Teste

 _{Teste Funcional (Teste Caixa Preta) (cont.)}

_{Não considera a estrutura interna do código.}

_{Pode detectar os seguintes tipos de erros:}

• Funções incorretas;

• Funções não implementadas; • Erros de interfaces;

• Erros de desempenho;

(55)

Técnicas de Teste

(56)

Técnicas de Teste

 _{Teste Caixa Cinza}

_{Une as duas Técnicas de}

Teste (Caixa Branca e Caixa Preta): conhecimento interno do produto aliado às saídas esperadas.

_{O testador tem acesso a}

algumas das operações internas do sistema.

(57)

Técnicas de Teste

 _{Teste Caixa Cinza (cont.)}

_{“Testes baseados no conhecimento do}

algoritmo, estados internos, arquitetura ou outras descrições mais alto-nível do

comportamneto do programa” [Doug Holffman].

_{O conhecimento interno do funcionamento pode}

ser: Modelo de Arquiterura da aplicação, Modelo de Dados, Diagrama UML ou Diagrama ER.

(58)

Técnicas de Teste

_{Para aplicar esta estratégia utilizamos como}

suporte, por exemplo, consultas no banco de dados para confirmar que a consulta que os dados da consulta ou filtro que executamos na tela está de acordo com os dados existente no banco.

(59)

Técnicas de Teste

_{Dois tipos de problemas podem ser econtrados}

durante os testes de caixa-cinza:

• O componente encontra uma falha de algum tipo, fazendo com que a operação seja

abortada – A interface com o usuario irá indicar que ocorreu algum problema.

• Os testes executam com sucesso, mas o

conteudo dos resultados está incorreto – Um sistema processando dados incorretos causa erro no resultado. [Elfriede Dustin]