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

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

São técnicas empregadas durante o processo de desenvolvimento de um software. Visam detectar antecipadamente falhas nos vários artefatos produzidos durante.

Apresentações semelhantes


Apresentação em tema: "São técnicas empregadas durante o processo de desenvolvimento de um software. Visam detectar antecipadamente falhas nos vários artefatos produzidos durante."— Transcrição da apresentação:

1

2 São técnicas empregadas durante o processo de desenvolvimento de um software. Visam detectar antecipadamente falhas nos vários artefatos produzidos durante o processo de desenvolvimento. O teste consiste em executar o programa com a intenção de encontrar erros (bugs). Myers, 1979.

3 Martin Pol Em linhas gerais, podemos dizer que o objetivo dos testes é encontrar defeitos: desta forma os testes são conduzidos para demonstrar a ausência de qualidade expressa pela presença de defeitos, para tal se faz necessário um processo (planejamento, especificação, execução, análise de resultados), considerando-se sempre os riscos do negócio e a qualidade do produto. (Visão do processo, projeto, requisito, risco de negócio e a qualidade para o negócio). Fonte: Software Testing – A Guide to the Tmap Approach – Martin Pol e outros.

4 Errar é humano É preciso garantir que os erros serão eliminados. Aumentar a qualidade do produto. Reduzir o custo

5 Aumento de falhas devido a ausência de qualidade; Aumento dos custos de suporte; Aumento dos custos de desenvolvimento; Falta de confiabilidade do produto no mercado; Insatisfação dos clientes e usuários; Perda de mercado;

6 Teste de Especificações de Requisitos; Teste de Modelos de Análise; Teste de Regras de Negócio; Teste de Unidade; Teste de Integração; Teste de Validação; Teste de Sistema; Teste de recuperação; Teste de Segurança; Teste de estresse; Teste de desempenho; Teste de Interface; Teste de Carga; Teste de Funcionalidade; Teste de Usabilidade; Teste de Portabilidade; Teste de Compatibilidade; Teste de documentos do projeto; Teste de Aceitação.

7 Fonte: Java Magazine 102

8 Fonte:

9 Defeito: resultado de um erro encontrado no código ou documento; Erro: engano cometido por seres humanos; Falha: resultado ou manifestação de um ou mais defeitos. Exemplo: A aplicação entra em looping infinito, devido a um erro de lógica, ocasionando o travamento da mesma.

10 O custo da correção do defeito EspecificaçãoProjetoConstrução e TesteProdução

11 Fonte:

12 É uma métrica de software que fornece uma medida quantitativa da complexidade lógica de um programa. Fornece um limite superior para o número de caminhos independentes em um conjunto-base. Fornece um limite superior para a quantidade de testes que deve ser conduzida para garantir que todos os comandos sejam executados pelo menos uma vez.

13 Pode ser calculada de três maneiras equivalentes: 1. V(G) = R, onde R é o número de regiões do grafo de fluxo. 2. V(G) = E – N + 2,onde E é o número de arestas e N é o número de nós do grafo G. 3. V(G) = P + 1, onde P é o número de nós- predicados contidos no grafo G ( só funciona se os nós-predicados tiverem no máximo duas arestas saindo)

14

15 Caminhos independentes

16 Focaliza na menor unidade de projeto do software: o componente ou módulo. Pode ser conduzido em paralelo para os diversos componentes. Caminhos de controle importantes são testados para descobrir erros dentro dos limites do módulo. Testam unidades lógicas Métodos Objetos Erros mais fáceis de corrigir Devem ser executados continuamente

17 A partir dos módulos testados ao nível de unidade, construir a estrutura do programa, visa descobrir erros associados as interfaces entre os módulos, focando na arquitetura do software.

18 Verificar se as partes, quando colocadas para trabalhar juntas, não conduzem a erros. Todas as técnicas de teste se aplicam, com destaque para o teste funcional. Questão importante: Como agrupar os módulos para se testar a integração entre eles? No paradigma procedimental (Pressman, 2006): Integração Ascendente (bottom-up) Integração Descendente (top-down)

19 Os módulos são integrados movimentando-se de cima para baixo, através da hierarquia de controle, iniciando-se do módulo de controle principal. Teste de Caixa-Preta O teste é particularmente útil para revelar problemas, tais como, funções incorretas ou omitidas, erros de interface, erros de comportamento ou desempenho, erros de iniciação e término.

20 Na técnica Bottom-up, a integração do sistema começa com a partir do nível mais baixo do software, ou seja, o módulo. O módulo é dito como o mais baixo nível se ele não depende de outro módulo.

21 Esses testes são projetados em função da estrutura do componente e podem permitir verificação mais precisa de comportamento do produto. Ele permite ao avaliador concentrar a atenção nos pontos mais importantes ou perigosos do código, de uma maneira mais precisa do que no caso do teste caixa- preta. Tais pontos podem até ser identificados durante o desenvolvimento e cobertos com o uso de assertivas e testes. Alguns exemplos de testes são: Duplicar informações (por exemplo, tentar cadastrar duas vezes exatamente os mesmos dados); Imprimir relatórios para bases de dados vazias; Procurar registros inexistentes.

22

23 Teste de caixa preta, descobrindo funções incorretas ou ausentes; erros de interface; erros nas estruturas de dados ou no acesso a bancos de dados externos; erros de desempenho, e erros de inicialização e término.

24 Duas condições... Corretas ou lista de deficiência. Dependendo do erro á uma negociação.

25 Verificar elementos da configuração.

26 Teste realizados pelo próprio cliente, podendo ser mal interpretadas. Teste Alfa Realizado com um usuário junto ao desenvolvedor que registra qualquer problema.

27 Realizado em uma ou mais instalações. O próprio usuário registra os problemas. EXEMPLO: Jogos Online (Beta).

28 É uma fase do processo de teste de software e de hardware em que o sistema já completamente integrado é verificado quanto a seus requisitos num ambiente de produção.

29 O objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas em relação aos objetivos originais.

30 É um procedimento que visa identificar as falhas de segurança de um ambiente e aproveitá-las para invadi-lo, obtendo acesso indevido a informações e recursos.

31 Permite avaliar as vulnerabilidades em aplicações e serviços frente a diferentes tipos de ataques de segurança – como Ataques de negação de serviço ou Ataque man-in-the-middle – e descobrir novas vulnerabilidades antes que sejam exploradas por atacantes.

32 É um teste realizado para confrontar os programas com situações anormais, executa o sistema de uma forma que exige recursos em quantidade, frequência, ou volume anormais.

33 Tem como objetivo avaliar o comportamento do sistema em situações onde há poucos recursos ou há concorrência por recursos: Pouca memória disponível; Capacidade máxima especificada de clientes ou processos executando; Alta concorrência por recursos.

34 É similar ao teste de carga mas com o intuito de testar o software a fim de encontrar o seu limite de processamento de dados no seu melhor desempenho. No teste normalmente é avaliada a capacidade resposta em determinados cenários e configurações. Geralmente ocorre paralelamente ao teste de estresse.

35 Tem como objetivo medir o desempenho do sistema em uma situação normal de uso, bem como quanto requer de recursos de hardware, tempo de espera entre as ações e transações, com base no cenário que se espera ter normalmente em produção.

36 Quando erro é encontrado

37 Dois resultados, corrigida e removida, ou não descoberta. Tentativa de reprodução do problema, reduzindo até sua essência. Divisão e Conquista. Usado um depurador.

38 Objetivo: descobrir e corrigir a causa de um erro de software. Três categorias: Força bruta (Quando tudo falha, computador) backtracking (Manual, pequenos programas) Eliminação da causa (Participação binária, isolar o problema) Gerar outros erros então... CUIDADO.

39 O GNU Debugger, mais conhecido por GDB, é um depurador, ou debugger, do projeto GNU. Ele pode ser usado para depuração em muitos sistemas do tipo Unix e suporta muitas linguagens de programação, como C, C++ e FORTRAN.

40 PRESSMAN, Roger S. Engenharia de Software. 3º Edição. São Paulo: Pearson Education do Brasil, p. MAZOLLA, Vitório B. Engenharia de Software. Disponível em:. Acesso em 10 de abril.http://www.pucrs.br/edipucrs/online/projetoSI/6-Engenharia/ESoft_01.pdf CUNHA, Simone Projeto de Teste de Software. Disponível em:. Acesso em 23 de abril.http://testwarequality.blogspot.com.br/p/projeto-de-teste.html NETO, Pedro de A. dos S. Teste de Software. Disponível em:. Acesso em 25 de abril.http://www.ufpi.br/subsiteFiles/pasn/arquivos/files/CursoTesteNovoPDFParte1.pdf TOZELLI, Paulo Análise do Teste de Software – Parte 02: Recursos Humanos. Disponível em:. Acesso em 1 de maio.http://imasters.com.br/artigo/9817/software/analise-do-teste-de-software-parte-02/

41


Carregar ppt "São técnicas empregadas durante o processo de desenvolvimento de um software. Visam detectar antecipadamente falhas nos vários artefatos produzidos durante."

Apresentações semelhantes


Anúncios Google