A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Testes – visão geral Vanilson Burégio. Roteiro n Introdução a testes de Software n Tipos de teste; n Técnicas de teste; n Plano de Teste; n Casos de teste;

Apresentações semelhantes


Apresentação em tema: "Testes – visão geral Vanilson Burégio. Roteiro n Introdução a testes de Software n Tipos de teste; n Técnicas de teste; n Plano de Teste; n Casos de teste;"— Transcrição da apresentação:

1 Testes – visão geral Vanilson Burégio

2 Roteiro n Introdução a testes de Software n Tipos de teste; n Técnicas de teste; n Plano de Teste; n Casos de teste; n Revisões formais.

3 Introdução a Testes de Software

4 O que é testar?

5 Introdução O desenvolvimento de sistemas de software envolve uma série de atividades de produção onde oportunidades para injeção de falhas humanas são enormes [Pressman, 2007] n Enquanto existir software existirá erro n Testar um software nada mais é do que descobrir, de forma sistemática, erros embutidos durante a construção deste software

6 O que é testar? Teste de software é o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado Teste de software é o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado

7 Objetivo Revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final n Testar é um processo de execução de um programa com a intenção de encontrar um erro n Um bom caso de teste é aquele que possui uma alta probabilidade de encontrar erros ainda não descobertos n Um teste bem sucedido é aquele que realmente descobre um erro ainda não conhecido

8 Então... n Se eu testei um software e não encontrei erros significa que meu software está correto, ou seja, livre erros! Verdadeiro ou Falso?

9 Conceitos Básicos n Caso de Teste: descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado n Procedimento de Teste: é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste n Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto –Critério de Cobertura dos Testes: permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado –Critério de Adequação de Casos de Teste: avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função –Critério de Geração de Casos de Teste: define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente

10 Defeitos no desenvolvimento de Software n Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software

11 Defeitos no desenvolvimento de Software n Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software

12 Defeitos no desenvolvimento de Software n Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software

13 Defeitos no desenvolvimento de Software n Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software

14 Defeitos no desenvolvimento de Software n Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software

15 Defeitos no desenvolvimento de Software n Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software

16 Tipos de Teste de Software

17 Tipos de teste de software n O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software

18 Tipos de teste de software n O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software

19 Tipos de teste de software n O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software

20 Tipos de teste de software n O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software

21 Tipos de teste de software n Teste de Unidade (testes unitários). 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, separadamente. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código n Teste de Integração: 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 n Teste de Sistema: 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. Verifica se o produto satisfaz seus requisitos

22 Tipos de teste de software n Teste de Aceitação: são realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. n Teste de Regressão: Teste de regressão não corresponde a um nível de teste, mas é uma estratégia importante para redução de efeitos colaterais –Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. –Pode ser aplicado em qualquer nível de teste

23 Técnicas de Teste de Software

24 Técnicas de teste de software n Atualmente existem muitas maneiras de se testar um software n Existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas orientados a objeto n Apesar de os paradigmas de desenvolvimento serem diferentes, o objetivo principal destas técnicas continua a ser o mesmo: encontrar falhas no software. n As técnicas de teste são classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste. As técnicas existentes são: –Técnica funcional (Caixa preta) –Técnica estrutural (Caixa branca)

25 Técnicas de teste de software n Teste Estrutural Caixa-branca –avalia o comportamento interno do componente de software –trabalha diretamente sobre o código fonte do componente de software teste de condição; teste de fluxo de dados; teste de ciclos; teste de caminhos lógicos Complexidade ciclomática –exemplo bem prático desta técnica: uso da ferramenta livre JUnit

26 Técnicas de testes caixa-branca n Testes de caminhos lógicos –Notação de grafo de fluxo –Complexidade ciclomática –Derivando casos de teste –Matriz de grafo n Testes de estrutura de controle –Teste de condição –Teste de fluxo de dados –Teste de loops

27 Técnicas de teste de software n Teste Funcional Caixa-preta –o componente de software a ser testado é abordado como se fosse uma caixa-preta –não se considera o comportamento interno do mesmo –dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido –o componente de software a ser testado pode ser: um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade

28 Técnicas de teste de software n Outras técnicas –Outras técnicas de teste podem e devem ser utilizadas de acordo com necessidades de negócio ou restrições tecnológicas teste de desempenho teste de usabilidade teste de carga teste de stress teste de confiabilidade teste de recuperação.

29 Plano de Testes

30 Processo de teste n Exemplo baseado no RUP (Rational Unified Process) Nosso foco agora!

31 Plano de testes n Objetivo –identificar e descrever os testes que serão executados e implementados –plano de testes possuirá os requisitos para o teste e as estratégias de teste n O projetista de teste é o responsável pelo planejamento dos testes

32 Planejar testes n Técnicas que asseguram o levantamento adequado de informações desta atividade –entrevistas –questionários –monitoramento de funções

33 Planejar testes n Atividades: –Selecionar requisitos a testar –Definir prioridades –Planejar testes de regressão –Definir estratégia dos testes –Definir o registro dos resultados dos testes e defeitos descobertos –Definir recursos humanos –Definir cronograma de testes –Realizar checklist

34 Plano de Testes (ver exemplo de modelo)

35 Casos de Teste (Projetar Testes)

36 Processo de teste n Exemplo baseado no RUP (Rational Unified Process) Nosso foco agora!

37 Projetar testes n Objetivo –Detalhar o projeto dos casos de testes o suficiente para que não haja dúvida ou ambigüidade, de modo que possa ser feitas a implementação e posterior execução

38 Planejar testes n Artefatos de entrada Documento de Requisitos Especificação de Casos de Uso Plano de Testes Lições aprendidas n Artefatos de saída Modelo de testes Casos de teste Procedimentos de teste

39 Projetar testes n Passos: –Identificar casos de teste –Descrever casos de teste –Identificar casos de teste a serem automatizados –Definir massa de dados

40 Casos de teste n Identificar casos de teste –Além dos requisitos que serão testados, deve-se definir também quais testes serão realizados para os requisitos selecionados (casos de teste) –A identificação dos casos de teste é feita por meio da análise dos fluxos de eventos dos diferentes cenários possíveis para os casos de uso Para cada cenário deve-se ter, no mínimo, um caso de teste correspondente. A análise dos requisitos não-funcionais também deve gerar casos de testes

41 Projetar testes n Descrever casos de teste –Este passo tem como objetivo descrever os casos de testes identificados na fase de planejamento. Essa descrição deve conter: Condição inicial para execução: Descrever qual a configuração do ambiente em que esse caso de teste será executado e qual o estado inicial do sistema para que possa ser executado corretamente e outras pré-condições, como "deve existir um cliente cadastrado na base de dados". Passos específicos do teste a ser executado: Passos que devem ser executados para a correta execução do caso de teste. Pode incluir referências a rotinas comuns ou outros casos de teste.

42 Projetar testes n Descrever casos de teste –Essa descrição deve conter ainda: Resultados esperados: Quais os critérios de sucesso do teste (pode ser um valor específico ou algo mais genérico, como "Observar que a aplicação montou uma tela contendo a mensagem 'Cadastro realizado com sucesso' e que o banco foi alterado"). Condição final de execução: O estado que o sistema deve estar ao término da execução. Por exemplo, "a execução deste caso de teste deve manter a base de dados inalterada".

43 Documento de casos de teste (Ver exemplo de modelo)

44 Revisões formais

45 Motivação n Quando artefatos defeituosos são produzidos.... –Geramos retrabalho para corrigir defeitos –custo de retrabalho para correção de defeitos aumenta na medida que o processo de desenvolvimento progride n Iniciativas devem ser realizadas no sentido de encontrar e corrigir defeitos tão logo sejam introduzidos n Uma abordagem que tem se mostrado eficiente nesse sentido: revisão dos artefatos produzidos ao longo do processo de desenvolvimento de software Custo de desenvolvimento / Esforço Tempo / Produtividade Qualidade

46 Inspeção de Software n Inspeção de software é um tipo particular de revisão que pode ser aplicado a todos os artefatos de software e possui um processo de detecção de defeitos rigoroso e bem definido Inspeções de Software nos Diferentes Artefatos

47 Inspeção de Software n Processo tradicional de inspeção envolve: –planejamento da inspeção –indivíduos revisando um determinado artefato –um encontro em equipe para discutir e registrar os defeitos –a passagem dos defeitos para o autor do artefato para que possam ser corrigidos –uma avaliação final sobre a necessidade de uma nova inspeção

48 Exemplo de questão


Carregar ppt "Testes – visão geral Vanilson Burégio. Roteiro n Introdução a testes de Software n Tipos de teste; n Técnicas de teste; n Plano de Teste; n Casos de teste;"

Apresentações semelhantes


Anúncios Google