O documento apresenta uma introdução ao teste de software, discutindo sua história, objetivos, processos, técnicas e ferramentas. Inclui tópicos como planejamento, projeto, execução e entrega de testes, níveis de teste, técnicas como caixa preta e branca e critérios como análise de valor limite e tabela de decisão. Por fim, fornece referências sobre o tema.
1. Minicurso - Teste de Software
Vanilton Pinheiro
Congresso Amazônico de Computação
e Sistemas Inteligentes - CACSI 2015
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. Para que Testar Software?Para que Testar Software?
Introdução
7. 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
8. 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.
9. 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
11. 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.
12. Processo de Teste de Software
Planejar
Projetar
Executar
Entregar
Plano de
Teste
Especificações
de teste
Resultado
dos testes
Sumário dos
testes
14. Níveis ou Fases de Teste
Unidade
Integração
Sistema
Aceitação
18. Técnicas de Teste
Requisito Z
Regressão Desempenho
Integração
Codificação
Depuração
Segurança Resultado Z ou ≅
Z
CAIXA
CINZA
20. 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
21. 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
22. 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
23. 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
24. 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.
28. 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
29. 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";
}
30. 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
31. 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.
32. 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
33. 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
34. 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";
}
35. 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.
36. 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
41. 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.
Notas del editor
Cem Kaner define &quot;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&quot;. [ 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