Minicurso - Teste de software (CACSI 2015)

1.610 visualizações

Publicada em

Apresentar um breve histórico do Teste de Software, juntamente com o processo de teste de software e seus níveis, técnicas, tipos e critérios realizando exercícios práticos.
Contextualizar os alunos de ferramentas de apoio ao teste e boas práticas nas atividades de teste de software.

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.610
No SlideShare
0
A partir de incorporações
0
Número de incorporações
774
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Cem Kaner define "testes cinza-box como envolvendo entradas e saídas, mas o projeto de teste é educado por informações sobre o código ou o funcionamento do programa de um tipo que, normalmente, seria fora da vista do testador". [ 10 ] teste Gray-box técnicas são:
    Efeitos positivos [ editar ]
    Oferece benefícios combinados: Como teste Gray-box é uma combinação de caixa-branca e teste de caixa-preta, que serve vantagens de ambos os testes.
    Não invasiva: Baseia-se na especificação funcional, vista arquitetônico enquanto não em código-fonte ou binários que torna invasivo demais.
    Inteligente Teste Authoring: Cinza-box testador lida com cenário inteligente teste, por exemplo, tratamento de tipo de dados, protocolo de comunicação, tratamento de exceções .
    Teste Imparcial: Apesar de todas as vantagens e funcionalidades acima, testes Gray-caixa mantém limite para testes entre testador e desenvolvedor. [ 12 ]
    Efeitos negativos [ editar ]
    Cobertura de código parcial: Em testes cinza-box, o código-fonte ou binários estão desaparecidas por causa do acesso limitado a interna ou a estrutura das aplicações que resulta em acesso limitado para passagem caminho de código.
    Defeito de identificação: Em aplicações distribuídas, é difícil associar identificação de defeitos. Ainda assim, os testes Gray-box é uma benção para saber como adequada desses sistemas lançar exceções e como bom são essas exceções tratadas em sistemas distribuídos com ambiente web services. [ 12 ] [ 13 ]
    Testes Gray-box é bem adequado para aplicações web . Aplicações Web têm sistemas de rede ou distribuídas; devido à ausência de código fonte ou binários que não é possível a utilização de testes de caixa branca. Teste de caixa-preta também não é utilizado devido a apenas contrato entre o cliente eo desenvolvedor, por isso é mais eficiente usar o teste de cinza caixa como informação relevante está disponível no Web Serviços Definition Language (WSDL). [ 14 ]
    Teste cinza da caixa é adequada para testes de domínio funcional ou negócio . O teste funcional é feita basicamente um teste de interações do usuário com pode ser systems.As externos testes cinza-box pode se adapte de forma eficiente para testes funcionais devido às suas características; ele também ajuda a confirmar que o software atende aos requisitos definidos para o software. [ 15 ] [ 16 ] [ 17 ] [ 18 ]
    Caixa cinza é chamado assim porque o programa de software, aos olhos do testador é como uma caixa cinza / semi-transparente; dentro do qual se pode ver parcialmente.
    http://searchsoftwarequality.techtarget.com/definition/gray-box
  • Minicurso - Teste de software (CACSI 2015)

    1. 1. Minicurso - Teste de Software Vanilton Pinheiro Congresso Amazônico de Computação e Sistemas Inteligentes - CACSI 2015
    2. 2. Sobre o Instrutor • Líder de Teste na Fpftech, Scrum Master pela Scrum Alliance, Pós-Graduado em Engenharia de Software com Ênfase em Desenvolvimento Web e Bacharel em Ciência da Computação ambos pela Uninorte Laureate. twitter.com/_vanilton vanilton.pinheiro@vanilton.net br.linkedin.com/in/vaniltonpinheiro caboquinhotester.wordpress.com
    3. 3. Para que Testar Software?Para que Testar Software? Introdução
    4. 4. Introdução
    5. 5. Sprint 1
    6. 6. Breve História do Teste de Software 1961 - Computer Programming Fundamentals (Leeds e Weinberg). O livro apresenta um capítulo sobre teste de software. 1979 - Glenford Myers publica o primeiro livro somente sobre Teste de Software chamado "A arte de testar software". 1969 - "Teste mostra a presença e não a ausência de defeitos", Dijkstra usa essa afirmação falando em uma conferência para o comitê de ciência da OTAN na Itália. 1960 - 1980 Década Eventos 1980 - 1990 1983 - A norma IEEE 829, primeira versão do padrão de documentação de teste de software é pulbicada. 1986 - Paul Book publica modelo V. 1990 - Taxonomia de defeitos Boris Beizer e Paradoxo do Pesticida
    7. 7. Breve História do Teste de Software 1991 - ISO 9126 (Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e Portabilidade) 1999 - Martin Pol e Koomen lançam o modelo Test Process Impromement voltado para melhoria de processos de teste de software. 1995 - Daniel Mosley aplica pela primeira vez o conceito de tabelas de decisão em teste de software. 1990 - 2000 Década Eventos 2000- 2010 2002 - Criado na Europa e atualmente com sede na Bélgica o International Software Testing Qualifications Board órgão responsável pelo exame de certificação ISTQB Certified Tester. 2003 - Lançado por Emerson Rios e Trayahu Moreira o livro Teste de Software que é o primeiro sobre esse assunto especificamente escrito em português. 2006 - Realizado no Brasil o primeiro exame CBTS – Certificação Brasileira em Teste de Software.
    8. 8. Atualmente • Metodologias ágeis – Extreme Programming (XP) – Scrum – Kanban Testes ágeis • Teste é responsabilidade de todos • Todas etapas do desenvolvimento • Técnica • Automação de Teste (redução esforço manual) • Colaboração • Comunicação
    9. 9. Processo de Teste de Software • O Processo de Testes de Software representa uma estruturação de etapas, atividades, artefatos, papéis e responsabilidades que buscam a padronização dos trabalhos e ampliar a organização e controle dos projetos de testes.
    10. 10. Processo de Teste de Software Planejar Projetar Executar Entregar Plano de Teste Especificações de teste Resultado dos testes Sumário dos testes
    11. 11. Níveis ou Fases de Teste Unidade Integração Sistema Aceitação
    12. 12. Sprint 2
    13. 13. Técnicas de Teste Requisito X Resultado X CAIXA BRANCA CAIXA PRETARequisito y Resultado y
    14. 14. Técnicas de Teste Requisito Z Regressão Desempenho Integração Codificação Depuração Segurança Resultado Z ou ≅ Z CAIXA CINZA
    15. 15. Tipos de Teste • Funcional – Verificação da consistência entre o produto implementado e os requisitos funcionais • Não -Funcional – Teste executado para medir características não-funcionais • Aceitação – Verifica se o software funciona de acordo com as necessidades do cliente
    16. 16. Tipos de Teste • Alfa – Realizado com usuários finais na organização desenvolvedora antes de liberar uma versão • Beta – Realizado fora da organização, preferencialmente nos locais dos usuários finais • Regressão – Repetição de teste num programa já testado, depois de haver modificação
    17. 17. Tipos de Teste • Desempenho – Executado dentro de um contexto de sistema – Exemplos • Número de usuários simultâneos • Configuração da máquina • Segurança – Elaboração de casos de teste que possam subverter as verificações de segurança do programa
    18. 18. Tipos de Teste • Estresse – Submeter o sistema a situações anormais Execução do sistema exigindo dos recursos mais do que foi projetado para suportar • Usabilidade – Avaliação do sistema feita por especialistas, a partir da observação e análise do comportamento do usuário durante a navegação e execução de tarefas específicas • Sanidade ou Fumaça – Comprime um conjunto de testes não exaustivos, garantindo que as principais funcionalidades funcionem
    19. 19. Tipos de Teste • Macaco – Teste executado sem um planejamento prévio – Geralmente feito por ferramentas automatizadas • Exploratório – Teste baseado na experiência com área de atuação de testes definidos e tempo de exploração. • Ad-hoc – Teste baseado na experiência sem área de atuação de testes definidos e sem tempo de exploração.
    20. 20. Prática – Validando um Login
    21. 21. Critérios de Teste - Partição de Equivalência Classe de Equivalência. Entre valores 0 – 16 todos são equivalentes. 0-16 Não empregar. 17-18 Pode ser empregado Parcial. 19-55 Pode ser empregado Integral. 56-99 Não empregar. Exemplo: sistema recursos humanos – empregar pessoas com base na idade (Copeland, 2014) • Reduzir número de Casos de Teste e propõe boa cobertura de código • Empregado intuitivamente
    22. 22. Critérios de Teste - Partição de Equivalência Classe de Equivalência. Entre valores 0 – 16 todos são equivalentes. Como deveriam ser derivados os casos de teste para o exemplo abaixo? A. 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 90, 91, 92, 93, 94 , 95, 96 , 97, 98, 99 B. 5,18,45,58 if(idade >= 0 && idade <= 16) { empregar = "Não empregar"; } if(idade >= 17 && idade <= 18) { empregar = "Empregar Parcial"; } if(idade >= 19 && idade <= 55) { empregar = "Empregar Integral"; } if (idade >= 56 && idade <= 99) { empregar = "Não empregar"; }
    23. 23. Critérios de Teste - Partição de Equivalência Intervalo de dados discretos (hipotecas de 1 a 5 casas) Definição das Classes • Em geral são definidas duas classes inválidas e uma válida. • Para a classe válida poderia ser escolhido 2. • Para as classes inválidas poderia ser: -2 e 8
    24. 24. Critérios de Teste - Partição de Equivalência Aplicação e Limitações •Reduz significativamente o numero de casos de teste em relação ao teste exaustivo. •Mais adequado para o teste de produtos com domínios de entrada divididos em intervalos ou conjuntos. •Assume que os valores dentro da mesma classe são equivalentes. •Aplicável em todas as fases de teste: unidade, integração, sistema e aceitação.
    25. 25. Prática - Partição de Equivalência • Derive casos de teste para as classes válidas e inválidas conforme a imagem abaixo: Inválido Válido Inválido
    26. 26. Critérios de Teste - Análise do Valor Limite • Critério básico • Seleção pequeno conjunto de casos de teste O Limite Ponto acima do limite Ponto abaixo do limite
    27. 27. Prática - Análise do Valor Limite Derive casos de teste para as limites válidos e inválidos conforme a imagem abaixo: if(numero >= 18 && numero <=70 ){ idadeEleitor= "Eleitor obrigatório"; } else{ idadeEleitor= "Eleitor não obrigatório"; }
    28. 28. Critérios de Teste - Tabela de Decisão • Tabelas de Decisão representam regras de negócio complexas por meio de um conjunto de decisões. Regra1 Regra2 Regra3 Regra4 Condições Casado(a)? Sim Sim Não Não Tem Filhos? Sim Não Sim Não Ações Desconto(R$)? 60 25 50 0 Suponha que uma companhia de seguros ofereça desconto especial para motoristas que são casados e/ou com filhos.
    29. 29. Prática – Tabela de Decisão Suponha que uma empresa de aluguel de veículos proporciona um desconto de 50% caso o motorista não possua infração nos últimos 2 anos. Outro desconto de 5% é dado ao motorista a cada 3 alugueis no mesmo ano pela empresa. E acima de 4 empréstimos um dia grátis é dado o motorista. Regra1 Regra2 Regra3 Regra4 Regra5 Regra6 Regra7 Regra8 Condições Infração nos 2 últimos anos? Sim Sim Sim Sim Não Não Não Não 3 alugueis no ano? Sim Sim Não Não Sim Sim Não Não Mais de 3 alugueis no ano? Sim Não Sim Não Sim Não Sim Não Ações Desconto 50%? Não Não Não Não Sim Sim Sim Sim Desconto 5%? Sim Sim Não Não Sim Sim Não Não Dia grátis? Sim Não Sim Não Sim Não Sim Não
    30. 30. Ferramentas de Teste
    31. 31. Rereferências • http://imasters.com.br/artigo/6102/software/processo-de-teste-de-software-parte-01/ • http://www.devmedia.com.br/processo-de-teste-de-software-revista-java-magazine-101/23795 • RIOS Emersom, História resumida em fatos do Teste de Software, disponível em http:// www.iteste.com.br/LinkClick.aspx?fileticket=FI3CvtavRpk%3d&tabid=249&mid=440 • https://viniciussabadoti.wordpress.com/2010/08/03/historico-sobre-testes-de-software/ • http://www.great.ufc.br/ctqs/images/arquivos/NTTteste.pdf • Copeland, L. A practitioner's guide to software test design. Artech House Publishers, 2004. • Maldonado, J. C.; Barbosa, E. F.; Vincenzi, A. M. R.; Delamaro, M. E.; Souza, S. R. S.; Jino, M. Introdução ao teste de software. Relatório Técnico 65 { Versão 2004-01, Instituto de Ciências Matemáticas e de Computação { ICMC-USP, disponível on-line: http://www.icmc.usp.br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_ND_65.pdf., 2004.

    ×