SlideShare uma empresa Scribd logo
https://www.facebook.com/alvarofpinheiroaulas/ 
br.linkedin.com/in/alvarofpinheiro/ 
TESTES DE SOFTWARE 
http://www.alvarofpinheiro.eti.br
“O objetivo do Teste de Software 
é encontrar bugs, 
encontrá-los o mais cedo possível 
e 
garantir que os bugs sejam 
corrigidos” (Patton, 2005) 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
INTRODUÇÃO 
http://www.alvarofpinheiro.eti.br
O que é um bug? 
 Várias definições existem em cada empresa 
 Um bug é: um defeito, falta, problema, incidente, anomalia, CR, etc. 
 Empresas usualmente perdem um bom tempo discutindo isso 
 Mas normalmente a conclusão é que um bug é apenas um bug 
 Uma definição mais formal de bug pode ser feita se pensando 
quando um bug ocorre [Patton, 2005] 
 Um bug ocorre quando uma ou mais das opções abaixo for 
verdadeira: 
 O software NÃO faz algo que a especificação diz que ele deveria fazer 
 O software FAZ algo que a especificação diz que ele NÃO deveria fazer 
 O software faz algo que a especificação não menciona 
 O software NÃO faz algo que a especificação NÃO menciona, mas 
deveria mencionar 
 O software é difícil de usar, entender, ou na visão do testador pode ser 
visto pelo usuário final como não estando correto 
http://www.alvarofpinheiro.eti.br
Bugs clássicos: 
 CD-ROM Rei Leão da Disney 
 Lançado em 1994 
 Primeiro CD-ROM da Disney (muita propaganda e grandes vendas) 
 Lançado antes no natal 
 Não foi testado em diferentes configurações de PCs e não informava a 
configuração mínima 
 Bug do ano 2000 
 Computadores não estavam preparados para o ano 2000 
 Sistema de Telefones de AT&T nos EUA 
 Toda a rede caiu por causa de um switch case errado 
 Sistema de Foguetes em Nara e Agência Européia 
 O foguete explodiu no lançamento pois o código feito na Nasa estavam 
no sistema métrico inglês e o da agência Européia no sistema 
internacional 
http://www.alvarofpinheiro.eti.br
Qual o custo de um bug? 
 O custo de um bug está diretamente associado a fase 
do ciclo de desenvolvimento em que o bug é 
encontrado 
 Um bug encontrado durante a especificação 
pode custar 1 dolar. O mesmo bug encontrado 
no release pode custar 100x mais 
http://www.alvarofpinheiro.eti.br
Por que bugs ocorrem? 
 Usualmente a razão de um bug ocorrer, depende do tamanho e 
do tipo do sistema 
Sistemas de Média e 
Grande Porte 
Sistemas de Pequeno Porte 
http://www.alvarofpinheiro.eti.br
Por que bugs ocorrem? 
 Problemas de especificação são a principal causa de bugs 
 Mais de 50% 
 Em Sistemas Pequenos 
 Problemas no código são a principal causa de bugs: 75% 
 Erros durante a construção (low level design + code + unit tests + 
integração) correspondem por pelo menos 35% dos erros 
 Quanto maior o projeto menor o número de erros na construção é maior 
o número na especificação 
 Problemas se especificação são em geral o maior causador de bugs em 
um software 
 Quanto maior o software, maior o número de erros na arquitetura e 
design de alto níve 
http://www.alvarofpinheiro.eti.br
Tipos de Bug 
 Vários estudos buscaram definir tipos de bug e suas 
porcentagens de ocorrência 
 Nenhum dos estudos foi muito conclusivo, mas vários 
pontos importantes foram levantados 
 O escopo dos erros é limitado: 85% dos erros podem ser 
corrigidos modificando apenas 1 rotina (classe) [Endres, 1975] 
 Maioria dos erros não está no código, mas no domínio da 
aplicação e não são problema do código em si 
 Vários erros são simples erros de digitação: 35% dos erros de 
código são erros de digitação [Weiss, 1975]. 
http://www.alvarofpinheiro.eti.br
Tipos de Bug 
 Maioria dos erros são simples de corrigir 
 85% dos erros podem ser corrigidos em menos de 1 hora 
 Apenas 1% dos erros levam mais que alguns dias para corrigir 
 80% do esforço de manutenção é gasto em apenas 20% dos erros 
 Os erros são concentrados em partes específicas do código 
 80% dos erros está em apenas 20% do código [Endres, 1975] 
 50% dos erros pode ser encontrado em 5% do código [Jones, 2000] 
 Os testes que buscam identificar quais são essas partes 
específicas do código podem reduzir em muito o custo de 
manutenção 
 Algumas vezes é melhor reescrever as rotinas nos quais os erros estão 
concentrados 
http://www.alvarofpinheiro.eti.br
Por que testes precisam se realizados? 
 Existem várias técnicas de encontrar bugs 
 Nenhuma técnica consegue garantir que TODOS os bugs sejam 
encontrado 
 Testes de software é uma das possíveis técnicas que podem ser 
aplicadas 
 Nenhuma técnica consegue encontrar mais de 85% dos bugs 
 Testes unitários + testes de componente + testes de sistemas 
atingem no máximo 60% dos bugs 
http://www.alvarofpinheiro.eti.br
Por que testes precisam se realizados? 
 Testes precisam ser realizados, mas não são suficientes para 
garantir que todos os bugs sejam encontrados 
 O ideal é combinar diferentes técnicas para garantir que a maioria 
dos bugs sejam encontrados o mais cedo possível 
 Algumas organizações chegam a atingir 95% de bugs encontrados 
combinando diferentes técnicas 
 Vários estudos comparam eficiência de técnicas de encontrar 
bugs 
 Grupo de programadores com média de 11 anos de experiência 
 Avaliou um código com 15 erros conhecidos 
 3 técnicas foram usadas 
 Testes contra a especificação 
 Execução de testes unitários e de sistemas 
 Inspeções da especificação e dos testes unitários 
 Em média apenas 5 erros foram encontrados 
 Testes usualmente atingem no máximo 50-60% de cobertura 
[Johnson 1994] 
http://www.alvarofpinheiro.eti.br
O que testar? 
 Definir o que testar no software é uma decisão fundamental 
 Essa definição deve levar em conta a “qualidade final” do 
software 
 Qualidade do produto  “satisfação final do usuário” 
 Satisfação do usuário  “experiência de uso” do software 
 Caso a “experiência de uso” seja boa a satisfação final do usuário 
será boa, mesmo que o software ainda apresente bugs 
Todas as funcionalidades que apresentam 
riscos para a qualidade do software DEVEM ser testadas 
http://www.alvarofpinheiro.eti.br
Riscos 
 É importante identificar quais os possíveis problemas que podem 
causar dificuldades na realização das atividades de teste? 
 Cada possível problema é chamado de “risco” 
 Para cada risco deve-se avaliar pelo menos 
 Probabilidade de ocorrer 
 Plano de contingência caso o risco de torne um fato 
 Prioridade do risco 
 Outros aspectos podem ser avaliados para cada risco de acordo 
com o processo de gerenciamento de risco da organização 
http://www.alvarofpinheiro.eti.br
O que testar? 
Experiência de uso 
Software Usuário 
Testes 
Testes 
Software Usuário 
Os testes estão cobrindo 
As áreas com riscos para 
qualidade 
http://www.alvarofpinheiro.eti.br
Conceitos em Testes de Software 
 Processos de Testes 
 Estágios de Teste 
 Tipos de Teste 
 Abordagens de Teste 
 Procedimentos de Teste 
 Projetos de Testes 
 Técnicas de Testes 
 Ferramentas de Testes 
http://www.alvarofpinheiro.eti.br
Foco de Teste 
 O foco dos testes muda de acordo com o estágio de testes sendo 
realizado, assim como o testador realizando a atividade 
 Este foco varia de 
 Testes de estruturais 
 Testes comportamentais 
 Testes reais 
Desenvolvedor Engenheiro de Testes Usuário 
Testes 
Estruturais 
Testes 
Comportamentais 
Testes 
Reais 
http://www.alvarofpinheiro.eti.br
Foco de Teste – Testes Estruturais 
 Buscam encontrar erros internos no software. 
 Focam diretamente no código 
 Encontram erros como 
 Um método pode estar recebendo um inteiro de 24 bits e tentando 
guardá-lo em 16 bits 
 Um algoritmo específico pode não estar tratando todos os possíveis 
fluxos de execução 
 Testes estruturais estão associados ao estágios de teste unitários 
e de componente 
 Eles são realizados então pelo desenvolvedor de software ou por 
um desenvolvedor de software em testes (testes de componente) 
http://www.alvarofpinheiro.eti.br
Foco de Teste – Testes Comportamentais 
 Encontram erros de mais alto nível no domínio da aplicação e 
não mais no código 
 Focam nas funcionalidades do sistema como um todo 
 Encontram erros como 
 Um usuário sem permissão conseguem realizadas operações sensíveis 
do sistemas 
 O sistema não implementa uma determinada regra de negócio como 
deveria 
 Testes comportamentais estão associados aos testes de sistema 
 Eles são realizados usualmente por engenheiros de teste 
http://www.alvarofpinheiro.eti.br
Foco de Teste – Testes Reais 
 Encontram erros no sistema como um todo, mas agora focando nas 
necessidades finais do usuário 
 Usuários reais tendem a encontrar problemas que não são vistos pelos 
engenheiros de teste 
 Os tipos de erros encontrados podem ser parecidos com os 
encontrados nos testes comportamentais 
 Também podem ser encontrados erros como 
 Uma funcionalidade bem importante pode estar escondida em um sub-menu em 
vez de estar exposta mais claramente 
 A forma como o sistema foi implementado não está resolvendo o problema do 
usuário 
 Estes testes usualmente são realizados por usuários finais 
 Os testes reais estão associados a um teste de aceitação 
http://www.alvarofpinheiro.eti.br
Procedimento de Teste 
 O procedimento de testes está diretamente relacionado ao 
conceito de caso de teste 
 Cada caso de teste está associado a um diferente “cenário” a 
ser testado 
 Para cada requisito existem diferentes cenários a serem testados 
 Para validar um caso de testes é necessário 
 Definir o ambiente no qual o teste será realizado 
 Definir a entrada deste caso de teste 
 Definir a saída esperada para cada entrada 
 Definir os passos a serem realizados para executar os testes 
 O conjunto de passos acima determina o que um procedimento 
de testes 
http://www.alvarofpinheiro.eti.br
Resultado de Testes 
 Quando cada caso de teste é executado, o seu resultado deve 
ser coletado 
 Existem diferentes abordagens para definir o resultado de um 
caso de teste especifico 
 A mais comum define as seguintes opções 
 Passou  todos os passos do caso de testes foram executados com 
sucesso para todas as entradas 
 Falhou  nem todos os passos foram executados com sucesso para 
uma ou mais entradas 
 Bloqueado  o teste não pode ser executado, pois o seu ambiente não 
pode ser configurado, ou pode alguma dependência externa 
http://www.alvarofpinheiro.eti.br
Testes: Cerificações 
O maior problema das certificações são a falta de padronização 
em seus conteúdos. Por isso, é indicado se que escolha o 
programa que mais se adéqua as necessidades da empresa e se 
incentive as pessoas a tirá-la e a experiência é insubstituível. 
American Society for Quality’s (ASQ) 
Certified Software Quality Engineer (CSQE); 
Quality Assurance Institute’s (QAI) 
Certified Software Test Engineer (CSTE) 
International Institute for Software Testing’s (IIST) 
Certified Software Test Professional (CSTP) 
Institute of Electrical and Electronic Engineers’ (IEEE) 
Certified Software Development Professional (CSDP) 
British Computer Society’s (BCS) 
Information Systems Examination Board (ISEB) 
http://www.alvarofpinheiro.eti.br
Testes: Modelo de Documento 
Missão: <uma breve sentença sobre a missão dessa sessão> 
Áreas: <area1 do requisito1> <area2 do requisito2> <...etc> 
Início: <data e hora de início> 
Testador: <nome do testador> 
Tarefas: <descrição das atividades> 
Duração: <os valores são "curta", "normal", ou "longa”> 
Preparação da Sessão: <% da duração da sessão gasta na preparação, entre 0-100> 
Projeto e Execução de Testes: <% da duração da sessão gasta procurando bugs, entre 0-100> 
Investigação e Reportagem dos Bugs: <% da duração da sessão gasta investigando problemas, 0-100> 
Descrição x Oportunidade: <descrição da duração da sessão que foi gasta na missão de investigação> 
Arquivos de Dados: <a sintaxe é o formato do aquivo ex.: "foo.bat“ e se não houver arquivos de dados, #N/A> 
Notas dos Testes: <formato de texto livre> 
Bugs: <listar os bugs com uma tag #BUG, o formato do texto é livre e se não houverem bugs, usar #N/A> 
Exemplo para Bugs encontratos: 
#BUG Título do bug 
Passos para reprodução: 
1 - … 
2 - … 
Resultado: ... 
Esperado: ... 
Issues: <o mesmo formato da sessão de BUG acima, se não houverem ISSUES, use #N/A> 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
EQUIPES 
http://www.alvarofpinheiro.eti.br
Equipes de Testes 
Existem várias maneiras de se organizar testes, porém 
a forma que se mostra mais adequada é a criação de 
um grupo independente de teste.E independência 
significa reconhecer os engenheiros de teste como 
especialistas, ou seja, não são desenvolvedores e 
respondem a uma gerência independente da gerência 
de desenvolvimento. É importante salientar, que 
engenheiros de teste possuem responsabilidades 
diferentes e, consequentemente, evoluem 
diferentemente, e que devem ser imparciais e não se 
influenciarem pela pressão do desenvolvimento. 
http://www.alvarofpinheiro.eti.br
Equipes de Testes: Times Independentes 
A funcão principal desse time é fazer testes, seja para um ou 
vários produtos. Ele não deve estar subordinado a mesma 
gerência de desenvolvimento, o que faz com que esse time não 
sofra as pressões internas de prazo de entrega do produto. Essa 
maneira tem uma grande 
vantagem de ter profissionais especializados em testes e a 
garantia de que os testes podem ser realizados tão bem quanto o 
desenvolvimento do sistema. Sua desvantagem é que, por 
passarem a existir dois times onde um tem a missão de encontrar 
problemas no que o outro desenvolveu, pode começar a haver 
desentendimentos entre esses eles. Entretanto, isso pode ser 
minimizado a nível gerencial, lembrando sempre que ambos 
estão contribuindo para a qualidade do produto final que é parte 
do esforço de ambos; estimulando a comunicação entre os times; 
inicializando o processo de teste o quanto antes. 
http://www.alvarofpinheiro.eti.br
Equipes de Testes: Times Integrados 
Os engenheiros de teste e os engenheiros de sistemas 
fazem parte de um mesmo time. Normalmente, é o que acontece 
em empresas projetizadas. Como todos fazem parte de um 
mesmo time, é mais fácil fazer com que os testes sejam iniciados 
cedo. Contudo, pelo mesmo motivo, é difícil captar bons recursos, 
pois, geralmente eles já estão em outras equipes. Um outro 
problema que ocorre com frequência é que, pelo fato do 
gerente ser encarregado tanto do desenvolvimento quanto do 
teste, ele pode se sentir mais tentado a entregar o produto no 
prazo acordado para não ferir seu cronograma, fazendo com que 
o serviço de teste seja comprometido por encurtar o tempo 
anteriormente planejado para o teste. 
http://www.alvarofpinheiro.eti.br
Equipes: Desenvolvedores 
São responsáveis por desenvolver e testar os sistema os 
problemas de comunicação são eliminados; a priorização da 
correção de bugs torna-se mais fácil; o bom conhecimento do 
design e do código faz com que seja mais fácil de encontrar qual 
a razão do bug. Porém, outros problemas vêm à tona, como: a 
falta de um conhecimento mais aprofundado do negócio limita o 
nível de teste a ser feito; a falta de conhecimento técnico de tipos, 
estratégias, métodos, processos de teste dificulta à realização do 
serviço de teste; a experiência com programação faz com que 
eles fiquem tentados, e às vezes limitados, a testar apenas o que 
o sistema deve fazer, não criando cenários de teste onde se tem 
de fato a maior probabilidade de encontrar bugs. 
http://www.alvarofpinheiro.eti.br
Equipes: Coordenadores de Testes 
Quando não existe grupo de testes, um coordenador de teste 
Deve ser escolhido para formar e liderar um time temporário de 
teste que poderá ser composto por desenvolvedores, 
engenheiros de qualidade, vendedores, usuários, etc. O 
coordenador escolhido deve ter um perfil pré-estabelecido para 
que se tenha sucesso nesse modelo, como por exemplo: 
experiência, credibilidade, boa comunicação e habilidades de 
gestão. Ainda assim, ele irá enfrentar problemas com a captação 
de recursos, pois como o time é temporário, os melhores recursos 
não serão facilmente cedidos por seus gerentes definitivos. A 
falta de pessoas experientes, de um ambiente de teste, de casos 
de teste já existentes, são outros problemas que o coordenador 
terá de encarar. Um dos motivos de se usar essa estratégia é 
quando se tem a necessidade emergente de se fazer teste e não 
se tem tempo, dinheiro e conhecimento para se formar um time 
de testes. 
http://www.alvarofpinheiro.eti.br
Equipes: Time de Qualidade 
Em algumas organizações o time de qualidade é responsável 
também pelos testes. O fato das habilidades necessárias serem 
bastante parecidas, ajuda os engenheiros de qualidade a terem 
uma maior empatia pelas atividades de teste e, 
consequentemente, desempenhá-las com sucesso. Um fator 
preocupante nessa estratégia é que testes seria uma 
responsabilidade a mais para o time o que pode dificultar 
fazer com que os testes sejam realizados com eficiência. 
http://www.alvarofpinheiro.eti.br
Equipes: Terceirização 
Terceirizar testes pode ser uma boa solução quando há falta de 
verba pra fazer teste internamente, falta de conhecimento técnico 
em testes ou falta de um ambiente propício. É importante 
salientar que apesar de estar contratando um serviço bem melhor 
do que o que possa ser oferecido de forma rápida internamente, o 
contratado possivelmente não terá o entendimento do negócio tão 
bem quanto o contratante. Além disso, o fato de se terceirizar os 
testes não elimina a responsabilidade da qualidade do produto 
que está sendo desenvolvido. Por isso, é importante que haja um 
acompanhamento do serviço que está sendo prestado. Para se 
ter sucesso nessa estratégia é recomendável que se tenha um 
bom contrato, contratar as pessoas certas, estabelecer entregas 
bem definidas, ter padrões de qualidade e ter uma boa visão do 
serviço do contratado. 
http://www.alvarofpinheiro.eti.br
Equipes: Empresa de V&V 
Normalmente, são realizados por um contratante independente e 
ao final do desenvolvimento, o que reduz maiores riscos de ter 
um produto funcionando com defeitos mas também pode elevar 
consideravelmente os custos. Por ser extremamente caro 
contratar uma empresa de Validade e Verificação (V&V), elas são 
geralmente contratadas quando se tem projetos do governo, 
quando se corre risco de vida no uso do sistema, em projetos de 
prestígio nacional, etc. 
http://www.alvarofpinheiro.eti.br
Papeis: Gerente de Testes 
São pessoas que precisam lidar com organizações que 
processam muitas linhas de comunicação formal e informal. Eles 
precisam lidar com recursos com vários níveis de habilidades, 
ferramentas, orçamentos e estimativas. O gerente é quem está à 
frente do time os representando nas mais diversas situações 
dentro e fora da empresa, o que pode afetar a percepção que as 
pessoas que estão fora do time de teste têm sobre este time. 
Deve atuar como provedor de informações, servindo de canal de 
comunicação de informações entre o trabalho realizado pela 
equipe e os stakeholders do projeto. Algumas informações 
importantes, por exemplo, seriam: status reports, planos, 
estimativas, relatórios de eficiência. 
http://www.alvarofpinheiro.eti.br
Papeis: Engenheiro de Testes 
Os requisitos para essa função são: Conhecimento do negócio da 
aplicação; Conhecimento técnico de testes; e Habilidades 
específicas. E as habilidades são: Dinamismo; Pensamento 
crítico; Comunicativo; Criatividade; Curiosidade; Maturidade; 
Trabalho em equipe; Facilidade de relacionamento interpessoal; 
Auto-motivação; Iniciativa; e Atenção aos detalhes. Fontes são: 
Desenvolvedores, excelentes para testes unitários, integração. E 
testes automáticos;Usuários, pois possuem um bom 
conhecimento do negócio do sistema, mas possuem pouco 
conhecimento técnico; Suporte, estão acostumados a descobrir 
problemas normalmente enfrentados pelos colaboradores da 
Empresa; Techinical Writers, produzem documentos técnicos e 
prestam bem atenção aos detalhes, podendo serem ótimos em 
reportar bugs, criar e organizar suites e ciclos de teste, elaborar o 
plano de testes; Engenheiros de Qualidade, dão importância a 
qualidade do software e da utilização do processo. 
http://www.alvarofpinheiro.eti.br
Quem é o testador? 
 O testador está diretamente associado a definição de teste 
de software 
 O testador 
 Encontra o bug 
 Busca encontrá-lo o mais cedo possível 
 Garante que o bug está corrigido 
 Um bug corrigido não necessariamente implementa em 
mudança no código 
 Correção de um manual 
 Correção de treinamento 
 Etc. 
 O testador deve ser responsável por verificar realmente se 
o bug foi corrigido 
http://www.alvarofpinheiro.eti.br
Quem é o testador? 
 Por que o testador é necessário? 
 Os testes feitos por desenvolvedores 
 Tendem a verificar apenas o “caminho feliz” 
 Normalmente são otimistas 
 Não são sofisticados 
 Organizações iniciais tem usualmente 5 testes de “caminho 
feliz” para cada teste de “caminho alternativo” 
 Organizações maduras usualmente tem o oposto - 5 de caminho 
alternativo para cada um de caminho feliz 
 Desenvolvedores normalmente só conseguem enxergar 50-60% 
dos casos de teste do seu código 
 O Testador tem um perfil diferente do desenvolvedor 
 São exploradores 
 Gostam de encontrar problemas 
 Criativos no uso do software 
 Visão das diferentes situações em que o software pode ser 
usado 
http://www.alvarofpinheiro.eti.br
Principais Papéis em Testes 
 Pode-se identificar 4 papéis principais para as atividades 
de testes 
 Gerente de Testes  Monta o plano de testes e faz o 
acompanhamento de todas as atividades relativas aos testes 
 Projetista de Testes  Identifica os casos de teste e escreve os 
procedimentos para cada um deles 
 Desenvolvedor de Testes  Implementa os casos de teste 
automático que foram projetados pelo projetista 
 Testador  Executa os casos de teste e preenche o resultado 
de testes 
 Estes papéis podem ou não ser realizados pela mesma 
pessoa 
 Isso depende de cada organização ou do tamanho / escopo do 
projeto 
 Existem outros termos que podem ser usados para 
descrever os papéis em atividades de teste 
 Durante o restante do módulo serão usados os termos definidos 
acima 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
CICLO DE VIDA 
DE UM BUG 
http://www.alvarofpinheiro.eti.br
Ciclo de Vida de um Bug 
 O ciclo de vida de um bug determina os vários estágios pelos 
quais o bug passa durante o desenvolvimento do software 
 Este ciclo de vida precisa ser definido nas organizações 
 O processo de controle de mudanças é responsável pode definir o ciclo 
de vida 
 O ciclo de vida pode ser bem simples 
 Aberto: bug identificado no teste 
 Resolvido: bug resolvido 
 Fechado: solução verificada 
http://www.alvarofpinheiro.eti.br
Ciclo de Vida de um Bug 
 O ciclo de vida também pode ser bem complexo 
 Aberto 
 Resolvido como não corrigir 
 Resolvido como corrigido 
 Fechado como corrigido 
http://www.alvarofpinheiro.eti.br
Ciclo de Vida de um Bug 
 Algumas organizações adotam para o bug um ciclo de vida 
similar ao de desenvolvimento de um software 
 Iniciado: bug descrito 
 Análise: bug analisado e especificado 
 Implementação: bug implementado 
 Testes: bug testado 
 Fechado: bug fechado de o teste for correto 
http://www.alvarofpinheiro.eti.br
Ciclo de Vida de um Bug 
 O ciclo de vida genérico para um bug pode ser como o 
apresentado abaixo 
 O estado importante a ressaltar e o de análise 
 Nele o bug é avaliado para identificar se é ou não para ser corrigido 
 Esse papel é executado por um CCB 
http://www.alvarofpinheiro.eti.br
Ciclo de Vida 
Revisado 
Rejeitado 
Aberto Atribuído Trabalho Fechado 
Reaberto Adiado 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
MODELOS 
http://www.alvarofpinheiro.eti.br
Engenharia de Software 
 As atividades de testes são inseridas no contexto das atividades 
de engenharia de software 
 TODO software segue um ciclo de vida 
 Existem vários modelos de ciclo de vida que podem ser adotados 
durante o desenvolvimento 
 O modelo de ciclo de vida usualmente direciona 
 Quais testes serão rodados 
 Quando os testes serão rodados 
 Os seguintes modelos serão discutidos 
 Cascata 
 V 
 Incremental 
 Codificar e testar 
http://www.alvarofpinheiro.eti.br
Modelo Cascata 
 Fases seqüências que produzem o software 
 Ao final de cada fase uma revisão interna deve validar se é 
possível passar a fase seguinte 
 A princípio só se deve passar a fase seguinte com a anterior 
finalizada 
 Foco principal é garantir que a especificação é bem feita antes de 
iniciar as fases seguintes 
http://www.alvarofpinheiro.eti.br
Modelo Cascata 
 O modelo em cascata é ideal para softwares bem conhecidos 
 Sem grandes surpresas durante a especificação 
 Tecnologia bem conhecida da equipe 
 A fase de testes é bem natural e é executada após toda a 
codificação 
 Principal vantagem para os testes 
 A especificação normalmente é bem feita e detalhada 
 Principal problema 
 Os testes só são executados no final 
 O custo de corrigir um problema é mais alto 
http://www.alvarofpinheiro.eti.br
Modelo V 
 Variação do modelo em cascata 
 Associa diferentes tipos de teste de acordo com a fase do ciclo 
de vida 
 Testes de aceitação usualmente estão associados aos requisitos 
 Testes de Integração usualmente estão associados ao design 
 Testes de componente usualmente estão associados ao código 
http://www.alvarofpinheiro.eti.br
Modelo V 
 O modelo V define diferentes estágios de testes para 
serem executados 
 Pode ser visto como uma extensão do modelo em cascata 
 Ainda existe a ênfase na especificação 
 Cada fase precisa ser finalizada antes do início da fase seguinte 
 Também é ideal para softwares com requisitos conhecidos 
 A grande vantagem do modelo é: 
 Identificar os diferentes estágios de teste que validam aspectos 
do ciclo de vida do software 
 Permite um melhor planejamento dos testes que precisam ser 
executados 
 “Quebra” os testes em diferentes focos 
 A principal desvantagem é: 
 Os testes ainda são rodados apenas após o código estar pronto 
http://www.alvarofpinheiro.eti.br
Modelo Incremental 
 Desenvolvimento é “quebrado” em várias iterações 
 Cada interação pode ser vista como uma pequena cascata 
 Cada interação passa por todas as fases do ciclo 
 Em maior ou menor escala 
 Requisitos são adicionados ao software em cada iteração 
http://www.alvarofpinheiro.eti.br
Modelo Incremental 
 O modelo incremental busca usar as vantagens do cascata 
 Focar em ter uma boa especificação 
 Mas sendo realista 
 Nem toda a especificação pode estar pronta no início do 
desenvolvimento 
 As iterações podem ser repetidas até que o software esteja 
estável 
 Ao final cada iteração é necessário 
 Determinar os objetivos da próxima iteração 
 Avaliar os riscos 
 Avaliar os testes 
 Avaliar os requisitos que já estão implementados 
 Planejar a iteração seguinte 
http://www.alvarofpinheiro.eti.br
Modelo Incremental 
 A principal vantagem para os testes é 
 Os testes são rodados várias vezes (ao final de cada iteração) 
 Os bugs podem ser antecipados 
 Os testadores usualmente podem (e devem ser) envolvidos no projeto 
desde o início 
 A principal desvantagem para os testes é 
 Algumas vezes não fica claro que testes devem ser rodados ao final de 
cada iteração 
 O esforço de planejamento de testes é maior 
 Mas esse esforço normalmente é compensado 
 É necessária uma equipe de testes mais experiente para planejar e 
executar testes neste modelo 
http://www.alvarofpinheiro.eti.br
Modelo Codificar e Testas 
 Parte de uma especificação informal 
 Ênfase em codificação 
 Não existe ênfase em outras fases do desenvolvimento 
 Como a especificação não é clara os testes também não são 
 Mas os testes são executados várias vezes 
 É ideal para projetos pequenos e com equipe pequena 
 Principal vantagem para os testes 
 Vários ciclos de testes 
 Custo de correção não é alto 
 Principal desvantagem para os testes 
 Planejamento e qualidade dos testes normalmente não é boa 
http://www.alvarofpinheiro.eti.br
Modelo Ágeis 
 Muito parecido com o codificar e testar 
 Foco em fechar várias versões do software 
 Integração continua 
 Especificação de requisitos informal 
 Mas o cliente final DEVE ficar próximo a equipe de desenvolvimento 
para validar os requisitos 
 Mas os testes 
 São mais formais 
 Devem ser automatizados 
 Garantir que sempre serão rodados 
 São executados a cada integração 
 Cliente pode participar da validação 
 Principal vantagem para os testes 
 Automatização 
 Sai a figura do testador e entra a do desenvolvedor de testes 
 Principal desvantagem 
 É necessário o uso de uma ferramenta para automatização 
http://www.alvarofpinheiro.eti.br
Modelo Ágeis: TDD 
 Test Driven Development 
 Modelo de Desenvolvimento Orientado a Testes 
 É uma das principais técnicas associadas a modelos ágeis 
 A idéia é que os testes sejam desenvolvidos antes do código 
 TFD: Test First Design 
 O passos para usar TDD são: 
 Escreve um caso de teste e executa um caso de teste 
 Falhando, implementa o código para passar no teste 
 Passando, continua o desenvolvimento e escreve um novo caso de 
testes 
 TODA a fase de implementação de um modelo ágil pode ser feita 
com TDD 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
PROCESSO 
http://www.alvarofpinheiro.eti.br
Processo de teste 
Processo de 
Desenvolvimento 
Análise 
Projeto 
Implementação 
Testes 
Produto Final 
http://www.alvarofpinheiro.eti.br
Processo de Testes 
 Os processos de teste são seqüências de ações, 
operações que são executadas com o objetivo de 
 Encontrar problemas no software 
 Encontrá-los o mais cedo possível 
 Aumentar a percepção de qualidade geral do software 
 Garantir que o usuário final tenha um software que atende as 
suas necessidades 
 De forma geral, o processo de teste pode ser separado 
em 4 grandes ações 
 Planejar  entender o que precisa ser testado e definir como 
 Preparar  selecionar e montar todo o ambiente para execução 
 Executar  executar os testes e coletar o resultado 
 Avaliar  verificar os resultados e métricas para melhorar os 
testes 
http://www.alvarofpinheiro.eti.br
Processo de Testes 
 O primeiro passo para realizar as atividades relacionadas 
a testes em uma organização é definir um processo de 
testes 
 Este processo deve: 
 Definir as principais atividades que precisam ser seguidas 
durante os testes 
 Definir papéis e responsabilidades das atividades de teste 
 Definir as ações associadas a cada atividade 
 Definir as entradas e saída de cada um das atividades 
 Associar possíveis templates de documento a cada uma das 
atividades 
 As principais atividades que podem ser identificadas em 
um processo de testes são: 
 Planejar Testes 
 Projetar Testes 
 Implementar Testes Automáticos 
 Executar Testes 
 Avaliar Resultados 
http://www.alvarofpinheiro.eti.br
Planejar Testes 
 Objetivo da Atividade 
 Planejar as atividades de testes que serão realizadas durante o ciclo de 
vida do software 
 Responsável pela atividades 
 Gerente de Testes com apóio do gerente de projetos 
 Principais Passo 
 Definir estágios de testes que serão executados 
 Definir tipos de teste que serão necessários em cada estágio 
 Entender os requisitos que precisarão ser testados 
 Definir se algum teste será ou não automatizado 
 Estimar o esforço necessário para projetar e implementar os testes 
 Estimar o esforço necessário para executar os testes 
 Definir que recursos de hardware e software serão necessário para a 
execução dos testes (definir ambiente de testes) 
 Definir riscos, dependências e premissas dos testes 
 Montar cronograma das atividades de testes 
 Associar este cronograma com o cronograma principal do projeto 
 Artefato Gerado 
 Plano de Testes 
http://www.alvarofpinheiro.eti.br
Planejar Testes 
 É importante notar que as atividades podem mudar de acordo 
com o tipo de projeto 
 O planejamento de testes DEVE ser executado 
 Após ou em paralelo com as atividades de requisitos 
 O gerente de testes deveria ser alocado junto com o gerente de 
projetos 
 Assim como o projetista de testes DEVE ser alocado no projeto junto 
com o analista de requisitos 
 Determinar que estágios e tipos de teste serão realizados é uma 
das principais atividades 
 A atividade mais difícil de executar é a estimativa 
 Durante o módulo seguinte a atividade de planejamento de testes 
será mais detalhada 
http://www.alvarofpinheiro.eti.br
Planejar Testes: Possível Estrutura de um Plano de Testes 
 Introdução 
 Estágios de Testes 
 Critérios de Entrada 
 Critérios de Saída 
 Tipos de Testes 
 Critérios de Entrada 
 Critérios de Saída 
 Ambiente de Testes 
 Recursos de Hardware 
 Recursos de Software 
 Riscos, Dependências e Premissas 
 Cronograma 
http://www.alvarofpinheiro.eti.br
Projetar Testes de Sistema 
 Objetivo 
 Identificar os casos de teste e escrever o procedimento de testes para 
cada um deles 
 Definir qual dos casos de teste vai ser automatizado 
 Responsável pela atividade 
 Projetista de Testes 
 Principais Passos 
 Avaliar os requisitos funcionais e não funcionais 
 Verificar quais os tipos de testes precisarão ser executados 
 De acordo com isso outros passos precisarão ser realizados 
 Para cada requisito definir os cenários de testes associados a eles 
 Para cada cenário definir um caso de teste 
 Para cada caso de testes definir 
 Entradas e saídas 
 Pré e pós condições 
 Passos para execução do caso de teste 
 Artefato de Saída 
 Projeto de Testes 
http://www.alvarofpinheiro.eti.br
Projetar Testes de Sistema: avaliar especificação 
 Primeiro passo para projetar os testes de sistema é avaliar a 
especificação do software 
 Essa avaliação pode ser feita 
 Durante uma revisão formal da especificação 
 Após os requisitos serem fechados e antes de se projetar os testes 
 O ideal é que o projetista de teste participe da revisão dos testes 
 Requisitos NÃO devem ser fechados sem a avaliação pela equipe de 
testes 
 Cada requisito funcional precisa ser verificado para garantir 
 Completude 
 Corretude 
 Precisão 
 Consistência 
 Relevância 
 Viabilidade 
 Testabilidade 
http://www.alvarofpinheiro.eti.br
Projetar Testes de Sistema : avaliar especificação 
 Completude 
 Existe algo faltando no requisito? Ele contém todas as informações 
necessários para o seu entendimento 
 Corretude 
 O requisito apresentado realmente resolve o problema que ele se 
propõe? 
 Precisão 
 A descrição do requisito está clara? Existe alguma parte que pode 
interpretada erradamente? 
 Consistência 
 Os requisitos são consistentes entre si? Alguma requisito é contraditório 
com outro? 
 Relevância 
 O requisito realmente é um requisito? Ou é algum aspecto de design 
que deveria ser tratado posteriormente? 
http://www.alvarofpinheiro.eti.br
Projetar Testes de Sistema : avaliar especificação 
 Viabilidade 
 É possível implementar esse requisito ? A tecnologia atual 
permite que ele seja implementado? 
 Testabilidade 
 O requisito pode ser testado ? É possível gerar um procedimento 
de testes que valide se o requisito está implementado 
corretamente? 
 Os requisitos funcionais NÃO devem ser esquecidos 
 É necessário garantir que estes estão claramente 
especificados 
 Qual o requisito de segurança? 
 Existe requisito de performance? Qual é? 
 Existe alguma restrição de ambiente? Qual o banco de dados e o 
servidor de aplicação que deve usado? 
 Existem alguma restrição de tecnologia? 
http://www.alvarofpinheiro.eti.br
Projetar Testes de Sistema : avaliar especificação 
 Outros aspecto importante a avaliar são os termos 
usados na descrição dos requisitos 
 Termos como 
 Sempre ou nunca: é necessário verificar se eles 
realmente significam isso no requisito 
 Bom, rápido, pequeno, estável: palavras assim não 
denotam requisitos testáveis e devem ser evitadas 
 Se .. Então ..: sempre que um Se.. Então for entrado e 
importante especificar o que ocorre no senão 
 Etc. : TODOS os etc. devem ser removidos da 
especificação 
http://www.alvarofpinheiro.eti.br
Projetar Testes de Sistema 
 Os casos de teste de sistema são caixa preta e são 
executados sobre todo o sistema 
 A avaliação dos requisitos é a atividade principal 
 O ideal é que o projetista de testes participe da revisão 
dos requisitos para garantir que 
 Cada requisito está claramente especificado 
 Cada requisito é testável 
 Os cenários de cada requisito são claramente definidos 
 Os requisitos funcionais estão corretamente especificados 
 Sem as informações acima não é possível projetar os 
casos de teste corretamente 
 A baixa qualidade dos testes está diretamente associada a baixa 
qualidade dos requisitos 
 A atividade de projetar testes será melhor detalhada no 
módulo seguinte 
http://www.alvarofpinheiro.eti.br
Projeto de Testes Unitário 
 Objetivo 
 Avaliar uma unidade de código antes que esta seja integrada ao 
restante do sistema 
 Responsável pela atividade 
 Desenvolvedor 
 Principais passos 
 Determinar abordagem de testes: caixa branca ou preta 
 Am ambos os casos é necessário 
 Avaliar o código 
 Identificar que stubs precisam ser implementados 
 Identificar que fluxos de execução precisam ser testados 
 Avaliar a interface da unidade a testar 
 Baseado nas informações acima, definir os casos de testes e 
definir o procedimento de testes 
 Artefato de Saída 
 Procedimentos de testes unitários 
http://www.alvarofpinheiro.eti.br
Projeto de Testes Unitário 
 Os stubs vão garantir o isolamento da unidade 
 Os testes unitários usualmente são definidos em código 
 Os casos de teste e procedimentos podem ser 
documentos em um projeto de testes unitários 
 Ou podem ficar apenas no código sob controle do desenvolvedor 
 Projetos de testes unitários são de difícil manutenção 
 Os testes unitários podem ser automatizados para facilitar a 
manutenção e a execução posterior 
 Quanto melhor os testes unitários menor o número de 
problema que serão encontrados durante a integração 
 Testes unitários fazem parte do processo de 
desenvolvimento e normalmente NÃO são tratados como 
parte do processo de testes 
http://www.alvarofpinheiro.eti.br
Projeto de Testes de Componente 
 Objetivo 
 Mesmo dos testes unitários, mas agora considerando o componente 
como unidade 
 Responsável pela atividade 
 Projetista de Testes 
 Principais passos 
 Mesmos dos testes unitários, com exceção de verificar a abordagem 
 Testes de componente usualmente são caixa preta 
 Artefato de Saída 
 Projeto de testes de componente 
 Como a interface do componente é bem definida e controlada, o 
projeto de testes de componente usualmente é feito e 
documentado 
 Testes de componente são usualmente definidos em código e 
podem ser automatizados 
http://www.alvarofpinheiro.eti.br
Projeto de Testes de Componente 
 O projeto de testes está altamente associado ao tipo 
de interface do componente 
 Este tipo pode ser 
 Web service 
 Interface de uma classe 
 HTTP ou Socket 
 Serial 
 Objeto remoto (CORBA, COM, RMI) 
 Um protocolo de comunicação é implementado em 
cima de uma dessas interfaces 
 Este protocolo é que precisa ser testado 
 Quando a interface é programática o teste se terna 
mais similar a um teste unitário de uma classe 
 Web service e objetos remotos 
http://www.alvarofpinheiro.eti.br
Projeto de Testes de Componente 
 Alguns Exemplos de componentes testáveis 
 Software POS que ler cartões de crédito 
 Um software que POS se comunica com um leitor de cartão de 
crédito via serial 
 O leitor de cartão tem um protocolo bem definido 
 Esse protocolo é implementado pelo software do POS 
 O POS precisa ser testado para suportar todos os possíveis 
dados que podem ser enviados pelo leitor 
 Software de atendimento médico. Componente que 
implementa regras de negócio para aceitar um paciente 
 Esse componente encapsula todas as regras para aceitar ou não 
um paciente 
 Ele é disponibilizado através de uma interface Java 
 TODAS as possíveis situações em que um paciente pode ser 
aceitou ou não precisam ser validadas 
 Dessa validação vai depender uma grande parte da 
funcionalidade do software 
http://www.alvarofpinheiro.eti.br
Projeto de Testes: Possível Estrutura do Projeto 
 Introdução 
 Ambiente de Testes 
 Requisito 1 
 Caso de Teste 1 
 Pre-condição 
 Pós-condição 
 Cenário 
 Procedimento 
 Entradas / Saídas 
 Caso de Teste N 
 Requisito M 
http://www.alvarofpinheiro.eti.br
Implementar Testes de Sistema e/ou Componente 
 Objetivo 
 Caso alguns dos procedimento de testes possa ser 
automatizados, eles devem ser implementados segundo o 
procedimento 
 Responsável pela atividade 
 Desenvolvedor de testes 
 Principais passos 
 Configurar a ferramenta de automação de testes 
 Determinar os dados de entrada e saída de cada caso de teste 
 Determinar o procedimento a ser executado em cada caso de 
teste 
 Implementar os scripts de teste na linguagem determinada pela 
ferramenta 
 Validar os scripts de teste unitariamente 
 Artefato de Saída 
 Scripts de teste implementados 
http://www.alvarofpinheiro.eti.br
Implementar Testes de Sistema e/ou Componente 
 A implementação dos testes é totalmente direcionada 
pela ferramenta de testes 
 É importante que cada organização defina uma ferramenta de 
testes padrão 
 Testes de componente são mais fáceis de automatizar 
 Cada componente tem uma interface bem definida 
 Essa interface é sempre programática 
 Testes de sistema são mais complexos 
 Em geral envolvem interação com o usuário 
 Existem ferramentas que permitem a automatização de 
testes com interfaces gráficas, mas 
 Mudanças de interface são mais comuns que mudanças 
 Isso torna a manutenção dos testes complicada 
 É necessário avaliar o custo benefício de automatizar os 
testes de sistemas 
 Não necessariamente todos os testes devem ser automatizados 
 Alguns testes são melhor e mais rapidamente executados por 
testadores 
http://www.alvarofpinheiro.eti.br
Implementar Testes de Sistema e/ou Componente 
 Existem várias vantagens de automatizar os testes 
 Velocidade de execução: testes automáticos são mais rápidos de 
executar 
 Eficiência: enquanto os testes estão sendo executados, os 
testadores podem ser alocados em outras atividades 
 Corretude: casos de testes automáticos nunca comentem erros 
durante a execução. Os passos sempre são repetidos da mesma 
forma 
 Simulação / emulação: ferramentas de testes podem ser usadas 
como stubs ou test drivers 
 Simplificação: alguns testes seriam tão complexos que rodar 
manualmente que a automação acaba sendo a única forma de 
executá-los 
 A corretude é uma das principais vantagens, mas também 
é uma limitação 
 Os testadores conseguem enxergar problemas que os testes 
automáticos não identificam 
 Os passos executados por um testador podem variar de uma 
execução para outra http://www.alvarofpinheiro.eti.br
Implementar Testes de Sistema e/ou Componente 
 Alguns fatos importantes em relação a automação 
 Mudanças no software 
 Os software muda e isso torna os testes falhos 
 É necessário atualizar os casos de testes automáticos da mesma forma 
que os manuais 
 Testes se sistema automatizados são complexos de implementar 
 Testes de sistema validam especialmente interação com o usuário 
 Existem ferramentas para validar essa UI, mas são complexas de usar 
 Vários bugs de UI podem escapar 
 Não se pode confiar apenas na automação 
 O olho do testador vai conseguir encontrar problemas que a ferramenta 
não 
 Algumas ferramentas são “invasivas” 
 Modificam o código sendo testado 
 O código final pode não ser correto devido a isso 
http://www.alvarofpinheiro.eti.br
Implementar Testes de Sistema e/ou Componente 
 Conclusões 
 Automatizar testes é uma excelente prática, mas deve 
ser feita com cuidado 
 A ferramenta de automatização deve ser bem escolhida 
 Deve se avaliar quais testes valem a pena serem 
automatizados 
 Avaliar o custo-benefício da automatização 
 Não se deve confiar apenas nos testes automáticos 
http://www.alvarofpinheiro.eti.br
Executar Testes 
 Objetivo 
 Executar os testes planejados e coletar os resultados 
 Responsável pela atividade 
 Testador 
 Principais passos 
 Os testes a executar devem ser definidos pelo projetista / 
gerente de testes 
 Para testes manuais, o testador deve seguir o procedimento 
de testes aplicando todas as entradas e verificando as 
saídas 
 Para testes automáticos e testados deve configurar a 
ferramenta de testes e colocar os scripts de teste para rodar 
 Os resultados de testes devem coletados 
 Artefato de Saída 
 Resultado de testes 
http://www.alvarofpinheiro.eti.br
Executar Testes 
 O setup para a execução de testes automáticos pode ser 
bem demorado 
 Essa atividade NÃO deve ser sub-estimada 
 Os testes manuais devem ser realizados com muito 
cuidado pelo testador 
 Alguns testes podem ser exploratórios 
 O testados deve se prender ao procedimento 
 Mas caso algum problema fora do procedimento seja encontrado, 
ele tem obrigação de reportar o problema 
 O testador também deve validar se o procedimento de testes está 
correto 
 Problemas no procedimento também devem ser reportados 
 Na dúvida, o testador DEVE reportar como erro 
 É melhor ter um falso positivo que deixar um bug passar 
 O testador deve na medida do possível dominar os 
requisitos que estão sendo testados 
http://www.alvarofpinheiro.eti.br
Executar Testes: passo-a-passo para executar testes 
 Selecionar que casos de testes serão executados de acordo com 
o planejamento 
 Atribuir os casos de testes para os testadores 
 Executar o caso de teste e reportar os bugs. Capturar 
informações continuamente levando em conta as execuções 
anteriores 
 Fazer o setup do ambiente de testes de acordo com o procedimento 
 Entrar os dados especificados e esperar pelas saídas determinadas 
 Avaliar os resultados, comportamentos e estado final do software. 
Pesquisar qualquer diferença com o resultado esperado 
 Caso ocorra um problema no software, reportar 
 Caso um problema seja encontrado no caso de teste, reportar 
 Capturar as informações sobre o teste que foi executado 
 Resolver possíveis issues que estejam bloqueando os testes 
 Reportar os resultados periodicamente 
http://www.alvarofpinheiro.eti.br
Executar Testes: passo-a-passo para executar testes 
 Durante a execução de um caso de teste, este pode 
está em diferentes estados 
 Em alguns software é importante identificar estes possíveis 
estados 
 Os estados algumas vezes estão associados aos resultados 
dos testes 
 Alguns possíveis estados genéricos 
 Queued 
 Block 
 Skip 
 In Progress 
 Pass 
 Warn 
 Fail 
 Closed 
http://www.alvarofpinheiro.eti.br
Executar Testes: passo-a-passo para executar testes 
 Queued 
 Caso de teste atribuído a um testador e esperando para ser executado 
 Block 
 Execução bloqueada por alguma razão 
 Skip 
 Execução não realizada por alguma razão 
 In Progress 
 Caso de teste sendo executado 
 Pass 
 Caso de teste passado 
 Warn 
 Algum comportamento não ocorreu como esperado, mas o problema 
não parece grave 
 Fail 
 Algum comportamento grave ocorrer 
 Closed 
 Após um teste Fail ou de Warn, o software foi corrigido e o problema 
fechado 
http://www.alvarofpinheiro.eti.br
Avaliar Resultados 
 Objetivo 
 Consolidar os dados gerados pela execução dos testes e avaliar os 
resultados para poder tomar decisões em relação ao projeto 
 Responsável pela atividade 
 Gerente de Testes 
 Principais passos 
 Coletar toda a informação sobre os resultados dos diferentes estágios 
 Avaliar se todos os testes que estavam planejados foram realmente 
executados 
 Caso algum problema tenha ocorrido durante a execução, isso deve ser 
avaliado 
 Reportar os resultados para o restante do projeto do software 
 Avaliar se os critérios esperados de resultados de testes foram 
atingidos. 
 Caso não tenha sido buscar identificar se ocorreu algum problema 
durante os testes 
 Artefato de Saída 
 Resultado dos testes 
http://www.alvarofpinheiro.eti.br
Avaliar Resultados 
 A avaliação dos resultados é fundamental pois é a 
conclusão de cada uma das execuções de teste 
 Ela é a base para tomadas de decisões gerenciais de 
todo o projeto 
 Caso os testes estejam falhando mais que o esperado, 
alguma ação precisará ser tomada 
 Caso os testadores estejam com problema para executar os 
testes alguma ação 
 Caso o procedimento de testes esteja com muitos problema, 
ele provavelmente deverá ser revisto 
http://www.alvarofpinheiro.eti.br
Avaliar Resultados: Informações Importantes de consolidar 
 Várias informações podem ser consolidadas na avaliação da 
execução dos testes 
 Quantidade de Testes Planejados 
 Número total de casos de testes que foram planejados para execução 
 Quantidade de Testes Executados 
 Número total de casos de testes que foram realmente executados 
 Quantidade de Testes Passados 
 Número total de casos de testes que passaram 
 Quantidade de Testes Falhos 
 Número total de casos de testes que falharam 
 Quantidade de Testes Bloqueados 
 Número total de casos de testes bloqueados 
 Quantidade de Bugs Encontrados 
 Número total de bugs encontrados durante os testes 
 Tempo total de execução dos testes 
 Tempo total de execução dos testes 
http://www.alvarofpinheiro.eti.br
Avaliar Resultados: Informações Importantes de consolidar 
 As informações listadas anteriormente podem ser 
combinadas em diferentes métricas 
 Estas métricas são usadas para 
 Acompanhar o processo de testes 
 Avaliar a eficácia dos testes 
 Avaliar a eficiência dos testes 
 Avaliar o custo dos testes 
 O módulo seguinte vai detalhar as possíveis 
métricas em testes de software 
http://www.alvarofpinheiro.eti.br
Planejamento de Testes 
Reflexão 
 Foram encontrados defeitos? Quantos? 
 Algum defeito foi corrigido? 
 Houve alguma preocupação com a classificação dos defeitos? 
 Quantos dos defeitos eram muito críticos? 
 Como os defeitos foram reportados? 
 Existe algum plano de correção dos defeitos? 
 Todos os recursos necessários para realização dos testes 
estavam presentes? 
 O ambiente estava configurado? 
 Quem participou da execução? 
 Que versão da release era essa? Ela estava estável? 
 Os testes acabaram? 
 Quais os próximos passos? 
http://www.alvarofpinheiro.eti.br
Planejamento de teste 
Planejamento: 
 Quem executará os testes? 
 Que partes serão testadas? (tempo/recurso) 
 Quando serão executados os testes (cedo) 
 Como serão realizados os testes? (especificação/implementação) 
 Quanto devemos testar? 
http://www.alvarofpinheiro.eti.br
Planejamento de teste 
Principais atividades do planejamento: 
• Determinar o escopo e os riscos e identificar o objetivo dos testes; 
• Determinar a abordagem de teste (caixa-preta/ caixa-branca); 
• Determinar os recursos necessários (pessoas, máquinas, ambiente de teste); 
• Determinar a estratégia de teste; 
• Montar cronograma das tarefas 
• Determinar critérios de entrada e saída. 
http://www.alvarofpinheiro.eti.br
Planejamento de Testes 
 Planejar os testes significa 
 Identificar que estágios de testes serão executados 
(estratégia de testes) 
 Identificar os ciclos de testes 
 Identificar o que será testado 
 Identificar os recursos necessários para os testes 
 Identificar os riscos, dependências e premissas dos testes 
 Definir um cronograma das atividades de testes 
 O gerente de testes é o responsável principal por 
realizar essas atividades 
 A principal saída da atividade de planejamento de 
testes é o 
 Plano de Testes 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
PROJETO 
http://www.alvarofpinheiro.eti.br
Projeto de Teste 
Entradas e Saídas 
Planejamento 
de Testes 
Plano de Projeto 
Cronograma do Projeto 
Informações sobre 
o sistema 
Plano de teste 
http://www.alvarofpinheiro.eti.br
Projeto de Teste 
Atividades do Projeto de Teste 
Análise dos 
requisitos 
Especificação dos 
casos de teste 
Seleção de 
casos de teste 
http://www.alvarofpinheiro.eti.br
Projeto de Teste 
Entradas e Saídas 
Projeto de Teste 
Plano de Teste 
Documento de requisitos 
Base de teste 
(plano de negócio, 
documento de marketing, 
plano de projeto, etc) 
Casos de teste 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
ABORDAGENS 
http://www.alvarofpinheiro.eti.br
Abordagem de Teste 
 Existem 2 abordagens principais na execução de 
testes 
 Caixa Preta 
 Caixa Branca 
 Testes caixa preta são aqueles nos quais o testador 
não vê o “interior” do objeto que está sendo testado 
 Usualmente executados por um testador que é diferente do 
desenvolvedor 
 Avalia todas as diferentes entradas e suas respectivas 
saídas para garantir que o software se comporta como 
especificado 
 Associado a estágios de teste como sistema ou componente 
http://www.alvarofpinheiro.eti.br
Abordagem de Teste 
 Testes caixa branca são aqueles nos quais o testador sabe como 
funciona o “interior” do objeto sendo testado 
 Usualmente são executados pelo próprio desenvolvedor 
 São fortemente associados aos testes unitários 
 Avalia TODOS os caminhos lógicos do código para garantir que TODOS 
os fluxos são executados corretamente 
 Busca encontrar bugs, mas bugs no código e não bugs na 
especificação, por exemplo 
 A grande maioria dos software realiza apenas testes caixa preta 
 Quando testes caixa branca são executados, eles não são 
formalizados 
 Não existe procedimento bem definido 
 Não existe resultado de testes documentado 
 Caso um procedimento de testes caixa branca seja escrito, existe 
grande chance dele ser descartado após a execução dos testes 
http://www.alvarofpinheiro.eti.br
Testes Positivos e Testes Negativos 
 Testes positivos verificam se o caminho feliz é executado 
corretamente 
 Testes negativos verificam as exceções 
 Testes positivos 
 Garantem que o software funciona minimamente como esperado 
 Garantem que o software não quebra para as suas operações principais 
 Não levam o software aos seus limites para identificar possíveis falhas 
 Testes negativos 
 Buscam realmente quebrar o software 
 Focam em identificar problemas 
 Garantem que o software funciona em diversas situações diferentes 
 Ambos os tipos de testes devem ser realizados 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
TÉCNICAS 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste –Análise de requisitos 
 Análise de requisitos 
 Começar a pensar na matriz de rastreabildiade: 
 Identificar quais testes serão impactados 
quando determinado requisito for modificado 
 Saber se existem teste para cada requisito 
 Avaliar grau de cobertura 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste – Seleção de casos de teste 
Técnicas de Teste 
 Baseada na especificação (caixa-preta) 
 Baseada na estrutura (caixa-branca) 
 Baseada na experiência 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste – Seleção de casos de teste 
 Técnicas de Teste 
 Baseada na especificação (caixa-preta) 
1. Partição por equivalência 
2. Análise de valores limites 
3. Tabelas de decisão / Tabela Causa-Efeito 
4. Testes derivados de casos de uso 
 Baseada na estrutura (caixa-branca) 
 Baseada na experiência 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste – Seleção de casos de teste 
 Técnicas de Teste 
 Baseada na especificação (caixa-preta) 
 Baseada na estrutura (caixa-branca) 
 Cobertura e Teste baseado em instruções 
 Cobertura e Teste baseado em laços de decisões 
 Baseada na experiência 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste – Seleção de casos de teste 
 Técnicas de Teste 
 Baseada na especificação (caixa-preta) 
 Baseada na estrutura (caixa-branca) 
 Baseada na experiência 
 Error guessing 
 Testes Exploratórios 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste – Testes vs. Inspeções 
 Inspeções dos artefatos buscam validar os artefatos antes que a 
próxima fase do desenvolvimento seja iniciada 
 Vários estudos indicam que o custo de encontrar um erro com 
inspeção é menor que o custo de encontrar com testes [Kaplan 
1995] 
 3,5 horas de esforço para encontrar um erro com inspeção 
 15-25 horas de esforço para encontrar um erro com testes 
 Isso não significa que testes não são necessários 
 Mas que outras técnicas também podem ser aplicadas 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste – Encontrar Bugs 
 Inspeção de Software 
 Processo formal de verificação do software 
 Pode ser aplicado para praticamente todos os artefatos gerados durante 
o ciclo de desenvolvimento 
 Tem o custo mais alto de aplicar, mas também é o que produz o melhor 
resultado 
 Combinação de inspeções na especificação, design e código podem 
encontrar até 85% dos bugs de um software 
 Como o processo é formal, ele é fácil de mensurar e de acompanhar 
 Prototipação 
 Ajuda no levantamento e definição dos requisitos 
 Dá uma boa visão para o cliente do que vai ser o software final 
 Reduz bastante as duvidas de usabilidade e de como as funções devem 
ser implementadas 
http://www.alvarofpinheiro.eti.br
Técnicas de Teste – Encontrar Bugs 
 Programação por pares 
 Técnica definida em XP (Extreme Programming) 
 2 desenvolvedores por computador 
 1 programador digita 
 1 programador procura por erros 
 Possui várias vantagens 
 Facilita mentoring de novos desenvolvedores 
 Dissemina a cultura da empresa 
 Pode chegar a encontrar a mesma quantidade de problemas da 
inspeção 
 É mais aplicável para a fase de codificação 
 Walkthroughs e Code Reading 
 Similar a inspeção, mas sem o formalismo de um processo 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
ESTÁGIOS 
http://www.alvarofpinheiro.eti.br
Unidade, Componente e Integração 
 Um software em geral é quebrado em diferentes componentes 
(ou módulos principais) 
 Cada componente é quebrado em unidades (sub-componentes) 
 Estes unidades precisam ser integradas em componentes 
 Os componentes precisam ser integrados no software como um 
todo 
http://www.alvarofpinheiro.eti.br
Unidade, Componente e Integração 
 Testes precisam ser executados 
 Na unidade para garantir que esta funciona separadamente 
 No componente para garantir que quando as unidades foram integradas, 
eles continuam funcionando 
 No sistema como um todo para garantir que os componentes integrados 
funcionam corretamente 
 O escopo de cada um desses testes é bem diferente 
 Todos buscam encontrar bugs 
 Mas tipos diferentes de busca usualmente são encontrados 
 Um teste não substitui o outro 
http://www.alvarofpinheiro.eti.br
Estágios de Teste 
 O termos “Estágio de Teste” é usualmente aplicado ao teste que 
está associado a uma determinada fase do ciclo de 
desenvolvimento 
 Relembrado o Modelo V, tem-se: 
 Testes Unitários 
 Testes de Componente 
 Testes de Integração 
 Testes de Sistema 
 Testes de Aceitação 
http://www.alvarofpinheiro.eti.br
Estágios de Teste 
 Testes Unitários 
 Executados pelo desenvolvedor para validar a unidade que está sendo 
implementada 
 Testes de Componente 
 Executado pelo testador para validar um componente específico do 
software 
 Testes de Integração 
 Executado pelo testador para garantir que vários componentes 
funcionam corretamente juntos 
 Testes de Sistema 
 Executados pelo testador para garantir que as funcionalidades do 
software estão de acordo com a especificação 
 Testes de Aceitação 
 Executados pelo usuário para garantir que o software faz o que foi 
inicialmente requisitos pelo usuário 
 Cada um destes estágios será melhor detalhado posteriormente 
http://www.alvarofpinheiro.eti.br
Estágios e Tipos de Testes 
 Anteriormente foi listado brevemente alguns estágios e diferentes 
tipos de testes 
 Os seguintes estágios e tipos serão abordados 
 Estágios 
 Testes Unitários 
 Testes de Componente 
 Testes de Sistema 
 Testes de Aceitação 
 Tipos de Teste 
 Testes de Carga 
 Testes de Performance 
 Testes de Uso de Memória 
 Testes de Usabilidade 
 Teste de Configuração 
 Testes de Compatibilidade 
 Testes de Documentação 
http://www.alvarofpinheiro.eti.br
Estágios – Testes Unitários 
 Testes unitários são testes isolados executados sobre uma rotina, 
classe ou pequena arte do programa 
 Esses testes são executados pelo próprio desenvolvedor para garantir 
que a sua unidade pode ser integrada com o resto do software 
 Dois aspectos fundamentais 
 Os testes são isolados 
 Os testes são implementados e executados pelo próprio desenvolvedor 
 Testes isolados 
 Stubs devem ser implementados para suprir alguma parte da 
funcionalidade ou gerar valores errados para validar a unidade 
 Os componentes externos a unidade em testes devem ser simuladas 
 Testes executados pelo desenvolvedor 
 Os testes são normalmente rodados no ambiente de desenvolvimento 
 Os casos de testes focam apenas na unidade em testes sem se 
preocupar com a interação com outras unidades 
http://www.alvarofpinheiro.eti.br
Estágios – Testes Unitários 
 Testes unitários podem ter a abordagem caixa 
branca ou caixa preta 
 Testes caixa branca são bem importantes pois ajudam a 
validar todos os fluxos de execução 
 A formalização de casos de testes unitário 
 É feita em algumas organizações 
 Principal dificuldade é dá manutenção nos casos de testes 
 Na maioria das vezes os casos de teste são jogados fora após 
os testes (especialmente os caixa branca) 
 O resultado do testes unitários algumas vezes também é 
formalizado 
 Mas a sua análise não tem tanto sentido em algumas situações 
http://www.alvarofpinheiro.eti.br
Estágios – Testes Unitários 
 Automação de testes unitários 
 É uma das principais formas de garantir que os casos de teste 
não sejam “jogados fora” 
 Existem várias ferramentas que focam na automação dos casos 
de testes 
 Gerar / implementar os scripts de testes 
 Executar os scripts de testes 
 Coletar os resultados da execução 
 Estas ferramentas rodam os testes sem intervenção do 
desenvolvedor 
 Principal vantagem 
 Facilita a manutenção dos testes 
 Os Testes podem ser rodados automaticamente para garantir que as 
unidades não quebraram 
 Principal problema 
 O custo de especificar e implementar os scripts é alto 
 É necessário avaliar o custo / benefício para cada software (ou para 
cada parte do software) 
http://www.alvarofpinheiro.eti.br
Estágios – Testes Unitários 
 Processo de desenvolvimento orientado a testes unitários 
 Atualmente existem processos de desenvolvimento orientados a testes 
unitários 
 TDD (Test Driven Development) 
 O princípio fundamental é 
 Desenvolver o teste antes do código 
 Principal vantagem 
 Casos de teste estão sempre atualizados 
 O código é feito para passar nos testes 
 O requisito é bem entendido antes de iniciar a implementação 
 Os testes são pensados com muito cuidado 
 Novos casos de testes podem ser facilmente adicionados 
 Principal desvantagem 
 Custo do desenvolvimento dos testes 
 É necessário avaliar beneficio de acordo com o projeto 
 A equipe precisa ter maturidade para entender a importância dos testes 
e saber implementar os casos de teste 
http://www.alvarofpinheiro.eti.br
Estágios – Testes Unitários 
 Passos para identificar casos de testes unitário caixa preta 
 Avaliar a interface da rotina a testas 
 Avaliar os parâmetros e seus possíveis valores 
 Avaliar TODOS os possíveis retornos de acordo com cada possível 
combinação de parâmetros 
 Encontrar os limites dos parâmetros que vão fazer com que o retorno 
mude 
 Avaliar todos os possíveis erros que podem ser gerados 
 Encontrar as combinações de parâmetros que devem gerar erro 
 Passos para identificar casos de testes unitários caixa branca 
 Avaliar todos os fluxos de execução da rotina 
 Avaliar as funções que são usadas internamente e seus retornos 
 Avaliar como vai se comportar a rotina caso as funções internas 
retornem valores diferentes do esperado 
 Avaliar se todos os possíveis fluxos de execução são tratados 
 Avaliar se todos os fluxos codificados realmente podem ser atingidos 
http://www.alvarofpinheiro.eti.br
Estágios – Testes Unitários: Exemplo 
 Considerando o código abaixo 
/** 
* Retorna a lista de contas bancarias de uma determinada pessoa 
* @param id identificar de uma pessoa 
*/ 
Vector getContas (IDPessoa id) { 
Vector resultado = new Vector (); 
for (int i = 0; i < contas.size(); i++) { 
Conta c = contas.elementAt(i); 
if (c.getIDPessoal().equals (id)) { 
resultado.addElement(c); 
} 
} 
return resultado; 
} 
Os seguintes casos de teste unitários caixa preta podem ser identificados: 
 Passar como parâmetro um ID de pessoa nulo 
 Passar como parâmetro um ID de pessoa inválido 
 Passar como parâmetro um ID de pessoa que tem apenas uma conta 
 Passar como parâmetro um ID de pessoa que não tem conta 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Componente 
 Muito parecidos com os testes unitários. Definição quase igual: 
 Esses testes são executados pelo próprio desenvolvedor para garantir 
que a sua unidade pode ser integrada com o resto do software 
 A principal diferença é que 
 Testes de componente devem ser implementados por uma equipe 
diferente da equipe de desenvolvimento 
 A equipe de desenvolvimento executa os testes de componente, mas 
uma equipe externa também pode executá-los 
 Testes de componente são aplicáveis quando o software é 
grande em vários componentes que interagem entre si 
 Os componentes 
 São compostos por diferentes unidades internas 
 Tem uma interface bem definida que é utilizado por outros componentes 
 Usam serviços providos por componentes externos 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Componente 
 A equipe de testes separada pode 
 Estudar a especificação do componente 
 Desenvolver um conjunto de testes para o componente (que 
podem ser ou não automatizados) 
 Executar esses testes para cada versão do componente que 
for fechada 
 Os testes de componente garantem que 
 Cada componente está funcionando conforme a sua 
especificação individualmente 
 Com isso os componentes podem ser integrados e o 
software completo pode ser testado 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Componente 
 A principal vantagem de se usar testes de componentes é 
 Uma equipe diferente da desenvolvimento vai pensar nos casos de teste 
 Isso garante uma melhor qualidade e cobertura dos testes (como foi 
visto anteriormente) 
 A principal desvantagem 
 É necessário definir claramente os componentes do software 
 O desenvolvimento também precisa ser “quebrado” em componentes 
 Isso pode não ser simples de fazer em alguns projetos 
 Quando testes de componente são realizados, usualmente é 
definido um estágio chamado de Testes de Integração 
 Todas as unidades são integradas e os problema de integração são 
resolvidos antes do teste de sistemas 
 Os testes de integração podem ser bem complexos de executar, casos o 
software seja muito grande 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Componente: Exemplo 
 Considerando uma interface de um componente HTTP que 
recebe parâmetros via HTTP GET 
/** 
* HTTP GET htp://servername/getConta?pessoaID=<idNumber> 
* Retorna: idConta1;idConta2;idConta3;..;idContaN 
*/ 
Os seguintes casos de teste podem ser identificados: 
 Tentar ter acesso a uma página diferente do servidor (getPessoa) 
 Tentar ter acesso a página getConta, mas sem nenhum parâmetro 
 Tentar ter acesso a página getConta, mas com um parâmetro diferente de pessoaID 
 Tentar ter acesso a página getConta, mas com mais de um parâmetro 
 Tentar ter acesso a página getConta com o parâmetro pessoaID como segundo parâmetro 
 Tentar passar o parâmetro via HTTP POST 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Sistema 
 Valida a funcionalidade principal do software 
 Tem como objetivo garantir que o software está implementando 
corretamente o que foi especificado 
 É direcionado então para especificação do software 
 Os casos de teste são definidos, especificados e executados por 
uma equipe de testes separada 
 Esta é equipe pode até ser uma organização separada da organização 
que faz o desenvolvimento 
 Aspectos subjetivos do software também devem ser avaliados 
 Qualidade geral da UI do software 
 Facilidade de uso do software 
 Performance do software 
 Facilidade instalação 
 Clareza das mensagens 
 etc 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Sistema: Exemplo 
 Considerando o seguinte caso de uso 
UC001: Listar contas 
Precondição: usuário logado no sistema no menu principal 
Fluxo Principal: 
1. O usuário seleciona a opção listar contar. O sistema apresenta uma lista de pessoas 
(pode executar fluxo alternativo 2 ou 3) 
2. O usuário seleciona uma pessoa específica. O sistema retorna um formulário com a lista 
de contas dessa pessoa (pode executar fluxo alternativo 1) 
Fluxo alternativo 
1. A pessoa não tem contas: uma mensagem é apresentando indicando que a pessoa selecionada 
não tem contas 
2. O usuário não tem permissão de acesso: uma mensagem de erro é apresentada indicando que 
o usuário não tem permissão 
3. Nenhuma pessoa cadastrada no sistemas: a lista é apresentada vazia 
Os seguintes casos de teste podem ser identificados: 
 Listar as contas de uma pessoa que não tem contas 
 Listar as contas de uma pessoa que tem várias contas 
 Entrar com um usuário que não tem permissão de listar pessoas e tentar listar pessoas 
 Entrar no sistema sem nenhuma pessoa cadastrada 
 Listar contas de uma pessoa e em seguida listar de outras pessoas 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Aceitação 
 São os testes realizados pelo usuário que contratou o 
desenvolvimento do sistema 
 Valida que a necessidade inicial do cliente quando o 
desenvolvimento do software foi contratada foi atendida 
 Foco não é na especificação, mas na necessidade do cliente 
 Por mais que especificações sejam escritas e aprovadas pelo 
cliente 
 É comum que alguma necessidade não seja totalmente atendida 
 Algumas vezes a necessidade original foi implementada de outra forma 
 Outros problemas como 
 Usabilidade, performance ou estabilidade do software também podem 
ser identificados 
 A organização que desenvolveu o software não tem muito 
controle sobre a aceitação 
 Um processo de aceitação pode ser definido, mas o cliente também 
pode ter seu processo interno 
http://www.alvarofpinheiro.eti.br
Estágios – Testes de Aceitação: Exemplo 
 Considerando o caso de uso de listar contas de uma pessoa 
 A necessidade do cliente é: 
 Ter um cadastro de pessoas 
 Ter um cadastro das contas de cada pessoa 
 Poder visualizar em uma mesma tela as pessoas e suas respectivas 
contas 
 Os seguintes casos de teste podem ser identificados: 
 Entrar no sistema e verificar se a tela de lista de pessoas apresenta 
todas as pessoas cadastradas 
 Verificar se é possível selecionar uma pessoa e ver suas contas na 
mesma tela 
 Verificar se todas as contas de uma determinada pessoa realmente são 
apresentadas 
http://www.alvarofpinheiro.eti.br
Sequência de Estágios de Testes 
Unitário 
Componente 
Integração 
Sistema 
Aceitação 
Desenvolvedores Engenheiro 
de Testes 
Cliente 
ou Usuário 
http://www.alvarofpinheiro.eti.br
Seqüência de Estágios de Testes 
 Vantagens de quebrar os testes em diferentes estágios 
 Cada estágio foca em problemas diferentes 
 Os testes estruturais garantem a estabilidade do software, antes de se 
buscar encontrar problemas comportamentais 
 Os testes comportamentais são rodados em um software estável 
 É mais fácil de fazer o acompanhamento do projeto 
 Cada estágio deve ser iniciado o mais cedo possível 
 Bugs devem ser encontrados o quanto antes 
 O momento de iniciar cada estágio deve ser determinado no plano de 
testes 
O plano de testes deve focar em quais estágios 
de teste? 
Testes de aceitação fazem parte do planejamento 
de testes? 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
TIPOS 
http://www.alvarofpinheiro.eti.br
Tipos de Testes: Unitários 
É o processo de verificação de que o código faz o que a 
especificações diz que ele deve fazer. Seu propósito é verificar se 
toda lógica necessária está presente e que funciona 
adequadamente de maneira automática. Testes unitários é uma 
atividade tipicamente realizada por desenvolvedores. É de sua 
responsabilidade provar que o software produzido faz exatamente 
o que se supõe que ele deve fazer e que não há nenhuma 
funcionalidade faltando. Testes de unitários são escritos a partir 
da perspectiva do programador. Eles asseguram que um 
determinado método de uma classe realiza com êxito a 
um conjunto de tarefas específicas. Cada teste confirma que o 
método produz os resultados esperados, quando recebe uma 
entrada conhecida. 
http://www.alvarofpinheiro.eti.br
Tipos de Testes: Funcionais 
Servem para dizer que o código deve fazer as coisas certas. São 
escritos a partir da perspectiva do usuário. Estes testes 
confirmam que o sistema deve fazer o que os usuários estão à 
espera que faça. Muitas vezes o desenvolvimento de um sistema 
computacional é relacionado à construção de uma casa. Embora 
esta analogia não seja completamente apropriada, dado as 
especificidades de cada projeto. Este modelo pode ser estendido 
e utilizado na compreensão das diferenças entre testes de 
unidade e testes funcionais. Teste de unidade se assemelha a um 
inspetor de obras visitando uma casa em construção. Ele está 
focado nos diversos sistemas internos da casa, a fundação, o 
sistema hidráulico, rede elétrica, canalização, e assim por diante. 
Por outro lado, testes funcionais neste cenário são análogos a 
visitação do dono da casa a esta mesma construção. Ele assume 
que os sistemas internos irão comportar-se adequadamente, já 
que o inspetor de construção realizou bem sua tarefa. 
http://www.alvarofpinheiro.eti.br
Tipos de Testes: TestDriver e Stub de Testes 
 Um test driver é um componente de software que simula as 
entradas reais do software 
 Por exemplo, um software de calculadora recebe números e operações 
 Um test driver para este software pode entrar um grande combinação 
diferente de números e combinações para validar a calculadora 
http://www.alvarofpinheiro.eti.br
Tipos de Testes: TestDriver e Stub de Testes 
 O stub de test é utilizado para testar o software de baixo para 
cima 
 O stub simula resultados que são retornados por um determinado 
componente que o software depende 
http://www.alvarofpinheiro.eti.br
Tipos de Teste 
 Frequentemente confundidos com os estágios de teste 
 “Tipos de Testes” identificam os diferentes testes que podem ser 
realizados em cada um dos estágios 
 Cada tipo pode estar associado a um estágio específico, ou pode ser 
realizado a partir dos testes de componente 
 Tipos também estão associados com cada domínio de aplicação 
 No desenvolvimento de jogos são realidades testes de jogabilidade (só 
aplicável a jogo) 
 Em aplicações que usam banco de dados são realizados testes de 
volume de carga no banco 
 Alguns tipos de teste comuns 
 Testes de carga 
 Testes de configuração 
 Testes de compatibilidade 
 Testes de performance 
 Testes de documentação 
 Testes de internacionalização 
 Testes de usabilidade 
http://www.alvarofpinheiro.eti.br
Tipos de Teste 
 Testes de carga 
 Foco em garantir um número específico de transações no banco de 
dados (alto volume de dados e alto número de transações) 
 É aplicável a partir dos testes de componente 
 Testes de configuração 
 Verifica se o software funciona com diferentes configurações de 
hardware e software 
 Está associado aos requisitos não-funcionais / restrições do software 
 Usualmente é aplicável a partir dos testes de integração 
 Testes de compatibilidade 
 Verifica se um determinado software está aderente a um padrão que ele 
deveria implementar 
 Usualmente é executado durante o teste de sistema 
http://www.alvarofpinheiro.eti.br
Tipos de Teste 
 Testes de performance 
 Garantir que a velocidade de execução do sistema é adequada (tempo 
para carregar uma página web por exemplo) 
 Associado aos requisitos não funcionais 
 Pode ser executado a partir dos testes de integração 
 Testes de documentação 
 Garantir que a documentação do software está do acordo com o que foi 
realmente implementado 
 Tem mais sentido ser executado durante os testes de sistema 
 Testes de internacionalização 
 Garantir que o software funciona em diferentes línguas e com 
configurações dependentes de pais (meda, timezone, etc.) 
 Testes de usabilidade 
 Verifica se as funções do sistema realmente são “fáceis” de serem 
realizadas 
 Deve ser executado durante os testes de sistema 
http://www.alvarofpinheiro.eti.br
Testes de Regressão 
 Considere o seguinte cenário 
 Durante a execução dos testes de sistema de um software 
encontra-se um erro após a execução de 70% dos testes 
 Este erro é corrigido e uma nova versão é gerada 
 Que testes devem ser executados após isso? 
 Os 30% restantes 
 E também pode-se regredir e executar todos os outros testes que 
já foram executados 
 A execução dos testes que já foram rodados é chamado de 
Testes de Regressão 
 Um testes de regressão completo significa que TODOS 
os testes serão rodados novamente 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Carga 
 Associado principalmente a softwares que usam bancos de 
dados 
 É um tipo de testes 
 Caixa preta 
 Principal objetivo é verificar como o software se comporta com 
diferentes cargas de banco de dados 
 Precisa de diferentes scripts para popular o banco 
 Está associado aos requisitos, mas também ao modelo de dados do 
software 
 Algumas vezes a implementação assume alguns 
comportamentos do modelo de dados 
 Dados dependentes da implementação do código e vice-versa 
 Isso pode causar bugs na aplicação, pois os dados do banco deveria 
estar associados e serem dependentes apenas do modelo de dados 
 Esses testes podem ser automatizados, mas o ideal é que sejam 
manuais para identificar os comportamentos diferentes do 
software 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Performance 
 Verificar a performance da aplicação em diferentes cenários 
 Esta diretamente associado aos requisitos não funcionais do 
software 
 Os requisitos devem especificar a performance esperada do software 
 Caso isso não seja feito pode gerar frustração durante a aceitação do 
software 
 A performance também está associada ao número de usuário 
utilizando o software 
 Em sistemas Web, a performance tem que ser garantida até um número 
X de usuários 
 Existem ferramentas que ajudam a implementar scripts para 
validar a performance 
 Simular vários usuários conectados a aplicação 
 Estes testes também estão associados ao ambiente de deploy do 
software 
 Este ambiente influencia diretamente no resultado dos testes 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Performance: Exemplo 
 Considerando o caso de uso listar contas de uma pessoas 
 O software pode ter um requisito não funcional 
 Mostrar as contas de um pessoa específica em no máximo 5 segundos 
 Com uma base de até 10mil pessoas e 100mil contas 
 Com até 100 usuários logados simultaneamente 
 Os seguintes casos de teste podem ser identificados: 
 Montar uma base com este número de usuários e buscar listar as contas 
destes usuários repetidamente. Calcular a média de tempo para mostrar 
as contas 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Uso de Memória 
 Pode estar associado a diferentes tipos de software 
 Alguns sistemas embarcados tem um milite de memória para uso 
 Caso se passe deste limite o software não pode ser executado ou o 
custo do hardware vai ser elevado 
 O uso da memória física do hardware precisa ser acompanhado 
nos projetos, caso este seja um recurso crítico 
 Avaliar periodicamente quanta memória o software está usando 
 Os procedimentos de testes de sistema podem ser utilizados 
 Verificar quanta memória o software está usando em cada caso de uso 
 Testes exploratórios também podem ser utilizados para verificar o uso 
de memória 
 Estes testes precisam ser realizados em alguns sistemas desde a 
fase de codificação e testes unitários 
 O uso de memória também pode estar associado a requisitos 
funcionais 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Uso de Memória: Exemplo 
 Um sistema embarcado pode estar limitado ao uso de 4 MB de 
RAM 
 As placas com essa memória já foram encomendadas e estão na 
fábrica 
 É necessário implementar no código um controle que verifique 
quanto de memória RAM está sendo utilizada 
 Semanalmente deve se acompanhar 
 quando de memória usada vs. número de casos de uso implementados 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Usabilidade 
 Que atributos definem uma boa interface com o usuário? 
 Grande investimento é feito pelas empresas para responder essa 
pergunta 
 Com os atributos definidos, a UI do software pode ser definida 
para atingi-los 
 Algumas características de um boa UI 
 Segue um padrão determinado 
 Flexível 
 Intuitiva 
 Consistente 
 Confortável 
 Útil 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Usabilidade 
 Segue um padrão determinado 
 As empresas que fazem os sistemas operacionais definem padrões de 
UI para serem seguidos pelas aplicações 
 É importante identificar se estes estão ou não sendo seguidos 
 Flexível 
 Existem diferentes formas de executar a mesma função? Estas formas 
são claras para o usuário? 
 Intuitiva 
 A interface é “limpa”? As funções do software são obvias e fáceis de 
encontrar? 
 Consistente 
 Funções similares no software estão disponíveis da mesma forma? 
 Confortável 
 Mensagens de erro são mostradas no momento correto? A performance 
das operações é ideal? 
 Útil 
 As funções realmente estão funcionando e podem ser usadas? 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Usabilidade 
 Mesma mensagem de erro apresentada 
de forma diferente 
 Cada indicação passa um “mensagem” 
diferente para o usuário 
 O teste de usabilidade precisa garantir a 
consistência entre as “mensagens” 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Usabilidade 
 Um dos testes mais importantes realizados durante os testes de 
sistema 
 É um teste caixa preta que visa identificar se os casos de uso do 
software são “fáceis” de executar pelo usuário final 
 É realizado por um design de usabilidade 
 Foca na facilidade de uso (número de passos para executar uma função 
específica do software) 
 Identificar se as opções apresentadas para o usuário são claras de 
entender 
 Os casos de teste de usabilidade são extraídos da especificação 
e do modelo navegacional do software 
 Existem diferentes técnicas para realizar esses testes 
 Filmar usuários utilizado o software e avaliar o uso com psicólogos 
 Colocar o software em um ambiente real e deixar um observador 
tomando nota do uso do software 
 Etc. 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Usabilidade: Exemplo 
 Considerando o caso de uso lista contas 
 O usuário pode esperar que as contas de uma determinada 
pessoa sejam listadas 
 Com no máximo 1 clique 
 Na mesma tela que todas as pessoas 
 Sejam apresentadas em uma lista com rolagem 
 Um possível caso de teste deve verificar se essas condições são 
atendidas no software 
 Em relação ao número de cliques, pode-se filmar vários usuários 
diferentes para verificar se eles conseguem realizar a operação 
com apenas 1 clique 
 Algumas vezes existe a opção de fazer com 1 clique, mas isso não é 
claro para o usuário final 
http://www.alvarofpinheiro.eti.br
Tipos – Teste de Configuração 
 Atualmente existem diferentes plataformas de hardware e 
software nas quais um determinado software pode executar 
 Além disso, o software desenvolvido também possui diferentes 
configurações internas 
 Resumindo, os testes de configuração buscam 
 Identificar o comportamento do software em diferentes configurações de 
hardware 
 Identificar o comportamento do software em diferentes configurações de 
software 
 Identificar o comportamento do software em diferentes configurações 
internas do software 
 As possíveis plataformas de hardware e software nas quais o 
software deve funcionar 
 DEVEM ser mapeadas durante a especificação do software 
 DEVEM ser aprovadas pelo cliente 
 Partindo destas especificações os casos de teste precisam ser 
levantados 
http://www.alvarofpinheiro.eti.br
Tipos – Teste de Configuração 
 Os resultados desses testes devem ser acompanhados 
periodicamente 
 Estes testes precisam ser executados o mais cedo possível 
 Especialmente se alguma das restrições fora essencial (ex. o software 
precisa rodar com um monitor preto e branco) 
 O planejamento dos testes precisa 
 Incluir as diferentes configurações de hardware e software com 
ambiente para execução dos testes 
 Planejar em que momento estes testes devem ser realizados 
http://www.alvarofpinheiro.eti.br
Tipos – Teste de Configuração: Exemplo 
 O software pode ter como restrição utilizar banco de dados 
Oracle ou Posgresql 
 O caso de teste então deve 
 Configurar 2 ambientes de testes: 1 com cada banco de dados 
 Executar as funcionalidades básicas do software em ambos os 
ambientes 
 Caso alguma não funciona corretamente, o teste é falho 
 Em algumas situações TODOS os testes precisarão ser executados em 
ambos os ambientes 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Compatibilidade 
 Como garantir que um editor de testes realmente consegue abrir 
um documento do padrão MS Word? 
 Como garantir de controle bancário exporta suas contas 
corretamente para uma planilha excel? 
 Como garantir que um software bancário consegue se 
comunicar com um servidor padrão do banco central? 
 Estes problemas são testados através de um teste de 
compatibilidade 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Compatibilidade 
 É aplicável para software que 
 Implementam algum padrão específico e que precisam estar 
compatíveis com este 
 Interagem com alguma aplicação que em a sua interface 
padronizada 
 No primeiro caso, o software precisa ser valido quando ao 
padrão 
 Usualmente os organismos de padronização definem conjuntos 
de testes que validam as implementações 
 A execução destes testes precisam então ser planejadas para 
validar a implementação do software 
 No segundo caso, o software precisa 
 Garantir que está usando a interface padronizada corretamente 
(por exemplo, usar um porta USB) 
 Testes precisam ser especificados para as diferentes opções 
definidas no padrão 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Compatibilidade: Exemplo 
 O software de controle de contas pode ter como requisito não 
funcional suportar um formato binário padrão para contas 
 A organização que definiu o padrão binário para um arquivo de 
várias contas possui um conjunto de testes que valida o suporte 
ao formato 
 Um caso de teste então é 
 Executar o conjunto de testes no software em um caso de uso de 
importar contas 
 Para todos as diferentes entradas, o software deve se comportar 
corretamente 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Documentação 
 Diferentes documentações podem ser geradas para o software 
 Documentação para o usuário (help) 
 EULA 
 Garantia 
 Marketing 
 É fundamental verificar se estas documentações estão corretas e 
de acordo com o esperado 
 Requisitos podem e devem ser definidos para a documentação 
 Quem vai prover o texto do help? Em que língua? Se for escrito pela 
equipe, quem vai revisá-lo? 
 Quem vai fornecer o EULA? Quando ele será incluído no software 
 Casos de testes podem e DEVEM ser definidos para validar 
esses pontos 
 Verificar a consistência do help 
 Verificar de o material de marketing está consistente 
http://www.alvarofpinheiro.eti.br
Tipos – Testes de Documentação 
 Frequentemente os casos de teste de documentação são 
esquecidos 
 Como não é código a sua importância é minimizada 
 Dependências de documentação também são esquecidas 
 Quando o texto do EULA vai ser entregue? 
 Quem vai revisá-lo? 
 Mudanças de última hora são freqüentes 
 Erros encontrados de última hora também são muito freqüentes 
 Especialmente no help 
 Erros de documentação podem 
 Gerar processos contra a empresa que fez o software 
 Dá uma idéia de baixa qualidade do produto 
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE 
AUTOMAÇÃO 
http://www.alvarofpinheiro.eti.br
Testes: Automação 
Software que automatiza qualquer aspecto da verificação de um 
sistema de aplicações. É possível incluir ainda nesta definição a 
capacidade de gerar entradas e resultados esperados dos testes, 
a execução das suítes de testes sem a intervenção manual e 
finalmente a avaliação se o teste passou ou não. 
Lista de situações onde é indicativo o teste automático: 
Quando há uma grande quantidade de testes; 
Suporte a várias GUIs, redes, sistemas operacionais ou banco; 
Testes de performance; 
Quando é necessário repetir uma complexa lista de ações; e 
Avaliar uma grande quantidade de saída repetidamente. 
http://www.alvarofpinheiro.eti.br
Testes: Manuais 
Quando os testes automáticos não são indicados: 
Quando não se tem muito tempo; 
Testadores necessitam ter ideia do comportamento da aplicação; 
Situações que se necessita de criatividade; 
Em relação a diminuição dos cursos; 
Testar novos componentes. 
http://www.alvarofpinheiro.eti.br
Automação 
 Como escrever testes funcionais automáticos 
eficientemente 
 existem algumas orientações para decidir se o determinado teste de unidade que está sendo escrito é 
na verdade um teste funcional: 
1. Se o de teste de unidade atravessa classe de fronteiras, ele pode ser um teste funcional. 
2. Se o de teste de unidade ficar muito complexo, ele pode ser um teste funcional. 
3. Se o de teste de unidade é frágil (ou seja, é um teste válido, mas é necessário atualizá-lo 
continuamente para lidar com diferentes mudanças do usuário), ele pode ser um teste funcional. 
4. Se o de teste de unidade é mais difícil de escrever do que o código que deverá ser testado, ele pode 
ser um teste funcional. 
 Existe uma sintonia entre o teste unitários e os testes funcionais, e decidir onde está a linha de 
separação entre um e outro depende de caso a caso. 
 Quanto mais confortável se estiver com os testes unitários, mais claro será perceber quando um 
determinado teste está cruzando a linha de unidade para funcional. 
slide 163 de 99 
http://www.alvarofpinheiro.eti.br
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software
Fundamentos de Testes de Software

Mais conteúdo relacionado

Mais procurados

Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
Camilo Almendra
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
Alex Camargo
 
powerpoint template for testing training
powerpoint template for testing trainingpowerpoint template for testing training
powerpoint template for testing training
John Roddy
 
Implementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel PimentelImplementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel Pimentel
Manoel Pimentel Medeiros
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
Leandro Rodrigues
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de software
Norton Guimarães
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
Joeldson Costa Damasceno
 
Tecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De SoftwareTecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De Software
marthahuback
 
Aula 3 técnicas de teste de software1
Aula 3   técnicas de teste de software1Aula 3   técnicas de teste de software1
Aula 3 técnicas de teste de software1
Tiago Vizoto
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
Juliana Maria Lopes
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
Sandy Maciel
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
Juliano Pires
 
Introdução a Testes Automatizados
Introdução a Testes AutomatizadosIntrodução a Testes Automatizados
Introdução a Testes Automatizados
elliando dias
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
Camilo Ribeiro
 
DevCamp - O papel de um testador em uma equipe ágil
DevCamp - O papel de um testador em uma equipe ágilDevCamp - O papel de um testador em uma equipe ágil
DevCamp - O papel de um testador em uma equipe ágil
Elias Nogueira
 
Conceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de softwareConceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de software
Ronney Moreira de Castro
 
Verificação e validação de software
Verificação e validação de softwareVerificação e validação de software
Verificação e validação de software
Leonardo Melo Santos
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
Kleitor Franklint Correa Araujo
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
rzauza
 

Mais procurados (20)

Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
 
powerpoint template for testing training
powerpoint template for testing trainingpowerpoint template for testing training
powerpoint template for testing training
 
Implementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel PimentelImplementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel Pimentel
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de software
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Tecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De SoftwareTecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De Software
 
Aula 3 técnicas de teste de software1
Aula 3   técnicas de teste de software1Aula 3   técnicas de teste de software1
Aula 3 técnicas de teste de software1
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
 
Introdução a Testes Automatizados
Introdução a Testes AutomatizadosIntrodução a Testes Automatizados
Introdução a Testes Automatizados
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
 
DevCamp - O papel de um testador em uma equipe ágil
DevCamp - O papel de um testador em uma equipe ágilDevCamp - O papel de um testador em uma equipe ágil
DevCamp - O papel de um testador em uma equipe ágil
 
Conceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de softwareConceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de software
 
Verificação e validação de software
Verificação e validação de softwareVerificação e validação de software
Verificação e validação de software
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
 

Destaque

Testes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de TestesTestes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de Testes
Paulo César M Jeveaux
 
Ferramentas open source para auxiliar os testes de software
Ferramentas open source para auxiliar os testes de softwareFerramentas open source para auxiliar os testes de software
Ferramentas open source para auxiliar os testes de software
Jeremias Araujo
 
Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1
Victor Hugo Germano
 
Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2
Victor Hugo Germano
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
Fernando Palma
 
Teste
TesteTeste
Teste
rssantan
 
Estudo de caso Leyson M. Santana
Estudo de caso Leyson M. SantanaEstudo de caso Leyson M. Santana
Estudo de caso Leyson M. Santana
Zaqueu Oliveira
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testes
elliando dias
 
Teste e Otimização de Interfaces Digitais - Huxley Dias
Teste e Otimização de Interfaces Digitais - Huxley DiasTeste e Otimização de Interfaces Digitais - Huxley Dias
Teste e Otimização de Interfaces Digitais - Huxley Dias
Huxley Dias
 
Palestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnitPalestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnit
Robinson Castilho
 
Teste de segurança em aplicações web ( sites )
Teste de segurança em aplicações web ( sites )Teste de segurança em aplicações web ( sites )
Teste de segurança em aplicações web ( sites )
Pablo Ribeiro
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizados
Thiago Ghisi
 
Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2
Fernando Palma
 
Métricas de estimativa de esforço em projetos de teste de software
Métricas de estimativa de esforço em projetos de teste de softwareMétricas de estimativa de esforço em projetos de teste de software
Métricas de estimativa de esforço em projetos de teste de software
Samanta Cicilia
 
Testes para dispositivos móveis
Testes para dispositivos móveisTestes para dispositivos móveis
Testes para dispositivos móveis
Qualister
 
Processo de Teste de Software - Monografia
Processo de Teste de Software - MonografiaProcesso de Teste de Software - Monografia
Processo de Teste de Software - Monografia
Rodrigo Kammers
 
Experiência e Cases com Auditorias Teste de Invasão em Redes e Sistemas
Experiência e Cases com Auditorias Teste de Invasão em Redes e SistemasExperiência e Cases com Auditorias Teste de Invasão em Redes e Sistemas
Experiência e Cases com Auditorias Teste de Invasão em Redes e Sistemas
Clavis Segurança da Informação
 
Empreendedorismo
EmpreendedorismoEmpreendedorismo
Empreendedorismo
Marcelo Willian
 
Testes de segurança
Testes de segurançaTestes de segurança
Testes de segurança
Qualister
 
2 plano de negócios dornelas
2 plano de negócios dornelas2 plano de negócios dornelas
2 plano de negócios dornelas
Mateus Monte
 

Destaque (20)

Testes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de TestesTestes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de Testes
 
Ferramentas open source para auxiliar os testes de software
Ferramentas open source para auxiliar os testes de softwareFerramentas open source para auxiliar os testes de software
Ferramentas open source para auxiliar os testes de software
 
Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1
 
Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
 
Teste
TesteTeste
Teste
 
Estudo de caso Leyson M. Santana
Estudo de caso Leyson M. SantanaEstudo de caso Leyson M. Santana
Estudo de caso Leyson M. Santana
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testes
 
Teste e Otimização de Interfaces Digitais - Huxley Dias
Teste e Otimização de Interfaces Digitais - Huxley DiasTeste e Otimização de Interfaces Digitais - Huxley Dias
Teste e Otimização de Interfaces Digitais - Huxley Dias
 
Palestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnitPalestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnit
 
Teste de segurança em aplicações web ( sites )
Teste de segurança em aplicações web ( sites )Teste de segurança em aplicações web ( sites )
Teste de segurança em aplicações web ( sites )
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizados
 
Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2
 
Métricas de estimativa de esforço em projetos de teste de software
Métricas de estimativa de esforço em projetos de teste de softwareMétricas de estimativa de esforço em projetos de teste de software
Métricas de estimativa de esforço em projetos de teste de software
 
Testes para dispositivos móveis
Testes para dispositivos móveisTestes para dispositivos móveis
Testes para dispositivos móveis
 
Processo de Teste de Software - Monografia
Processo de Teste de Software - MonografiaProcesso de Teste de Software - Monografia
Processo de Teste de Software - Monografia
 
Experiência e Cases com Auditorias Teste de Invasão em Redes e Sistemas
Experiência e Cases com Auditorias Teste de Invasão em Redes e SistemasExperiência e Cases com Auditorias Teste de Invasão em Redes e Sistemas
Experiência e Cases com Auditorias Teste de Invasão em Redes e Sistemas
 
Empreendedorismo
EmpreendedorismoEmpreendedorismo
Empreendedorismo
 
Testes de segurança
Testes de segurançaTestes de segurança
Testes de segurança
 
2 plano de negócios dornelas
2 plano de negócios dornelas2 plano de negócios dornelas
2 plano de negócios dornelas
 

Semelhante a Fundamentos de Testes de Software

Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
MichaelArrais1
 
Dba Testes Gerentes B2
Dba Testes Gerentes B2Dba Testes Gerentes B2
Dba Testes Gerentes B2
Leonardo Molinari
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
Trabalho qualidade de software sistemas de informação
Trabalho qualidade de software   sistemas de informaçãoTrabalho qualidade de software   sistemas de informação
Trabalho qualidade de software sistemas de informação
Fernando Gomes Chaves
 
Teste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e AplicandoTeste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e Aplicando
André Phillip Bertoletti
 
AULA 1 - TESTE DE SOFTWARE.pptx
AULA 1 - TESTE DE SOFTWARE.pptxAULA 1 - TESTE DE SOFTWARE.pptx
AULA 1 - TESTE DE SOFTWARE.pptx
paulocoob
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Sergio Cabral
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
AlexandreLisboadaSil
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
Roberto Nunes
 
Teste de software
Teste de software Teste de software
Teste de software
Allan Almeida de Araújo
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rodrigo Cardoso Alves Fonte
 
Introdução ao Teste de Software
Introdução ao Teste de SoftwareIntrodução ao Teste de Software
Introdução ao Teste de Software
X25 Treinamento e Consultoria
 
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline ZaninFundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
DevInPF
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
Fernando Palma
 
Introdução a testes de software
Introdução a testes de softwareIntrodução a testes de software
Introdução a testes de software
Leonardo Soares
 
Mini aula de teste de software
Mini aula de teste de softwareMini aula de teste de software
Mini aula de teste de software
Wanderlei Silva do Carmo
 
T@rget trust t-curso de ferramentas para automação de teste de software
T@rget trust   t-curso de ferramentas para automação de teste de softwareT@rget trust   t-curso de ferramentas para automação de teste de software
T@rget trust t-curso de ferramentas para automação de teste de software
Targettrust
 
T@rget trust t-curso de ferramentas para automação de teste de software
T@rget trust   t-curso de ferramentas para automação de teste de softwareT@rget trust   t-curso de ferramentas para automação de teste de software
T@rget trust t-curso de ferramentas para automação de teste de software
Targettrust
 
Eng de testes
Eng de testesEng de testes
Eng de testes
GrupoAlves - professor
 
Qualidade e Testes de Software
Qualidade e Testes de SoftwareQualidade e Testes de Software
Qualidade e Testes de Software
André Phillip Bertoletti
 

Semelhante a Fundamentos de Testes de Software (20)

Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
 
Dba Testes Gerentes B2
Dba Testes Gerentes B2Dba Testes Gerentes B2
Dba Testes Gerentes B2
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Trabalho qualidade de software sistemas de informação
Trabalho qualidade de software   sistemas de informaçãoTrabalho qualidade de software   sistemas de informação
Trabalho qualidade de software sistemas de informação
 
Teste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e AplicandoTeste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e Aplicando
 
AULA 1 - TESTE DE SOFTWARE.pptx
AULA 1 - TESTE DE SOFTWARE.pptxAULA 1 - TESTE DE SOFTWARE.pptx
AULA 1 - TESTE DE SOFTWARE.pptx
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
Teste de software
Teste de software Teste de software
Teste de software
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Introdução ao Teste de Software
Introdução ao Teste de SoftwareIntrodução ao Teste de Software
Introdução ao Teste de Software
 
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline ZaninFundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
 
Introdução a testes de software
Introdução a testes de softwareIntrodução a testes de software
Introdução a testes de software
 
Mini aula de teste de software
Mini aula de teste de softwareMini aula de teste de software
Mini aula de teste de software
 
T@rget trust t-curso de ferramentas para automação de teste de software
T@rget trust   t-curso de ferramentas para automação de teste de softwareT@rget trust   t-curso de ferramentas para automação de teste de software
T@rget trust t-curso de ferramentas para automação de teste de software
 
T@rget trust t-curso de ferramentas para automação de teste de software
T@rget trust   t-curso de ferramentas para automação de teste de softwareT@rget trust   t-curso de ferramentas para automação de teste de software
T@rget trust t-curso de ferramentas para automação de teste de software
 
Eng de testes
Eng de testesEng de testes
Eng de testes
 
Qualidade e Testes de Software
Qualidade e Testes de SoftwareQualidade e Testes de Software
Qualidade e Testes de Software
 

Mais de Álvaro Farias Pinheiro

Data science
Data scienceData science
IA
IAIA
Autômatos
AutômatosAutômatos
Paradigma Orientado a Objetos
Paradigma Orientado a ObjetosParadigma Orientado a Objetos
Paradigma Orientado a Objetos
Álvaro Farias Pinheiro
 
Padrões de Projeto (GoF)
Padrões de Projeto (GoF)Padrões de Projeto (GoF)
Padrões de Projeto (GoF)
Álvaro Farias Pinheiro
 
Linguagem de Modelagem Unificada (UML)
Linguagem de Modelagem Unificada (UML)Linguagem de Modelagem Unificada (UML)
Linguagem de Modelagem Unificada (UML)
Álvaro Farias Pinheiro
 
Introdução a Tecnologias Web
Introdução a Tecnologias WebIntrodução a Tecnologias Web
Introdução a Tecnologias Web
Álvaro Farias Pinheiro
 
Introdução ao HTML
Introdução ao HTMLIntrodução ao HTML
Introdução ao HTML
Álvaro Farias Pinheiro
 
Introdução à Sistemas de Informação
Introdução à Sistemas de InformaçãoIntrodução à Sistemas de Informação
Introdução à Sistemas de Informação
Álvaro Farias Pinheiro
 
Análise e Modelagem com UML
Análise e Modelagem com UMLAnálise e Modelagem com UML
Análise e Modelagem com UML
Álvaro Farias Pinheiro
 
Eficiência Energética
Eficiência EnergéticaEficiência Energética
Eficiência Energética
Álvaro Farias Pinheiro
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
Álvaro Farias Pinheiro
 
Medida de Esforço de Software com Análise de Ponto de Função
Medida de Esforço de Software com Análise de Ponto de FunçãoMedida de Esforço de Software com Análise de Ponto de Função
Medida de Esforço de Software com Análise de Ponto de Função
Álvaro Farias Pinheiro
 
Fundamentos de Padrões de Projeto de Software
Fundamentos de Padrões de Projeto de SoftwareFundamentos de Padrões de Projeto de Software
Fundamentos de Padrões de Projeto de Software
Álvaro Farias Pinheiro
 
Fundamentos de Banco de Dados Relacionais
Fundamentos de Banco de Dados RelacionaisFundamentos de Banco de Dados Relacionais
Fundamentos de Banco de Dados Relacionais
Álvaro Farias Pinheiro
 
Programação Orientada a Objetos com Java
Programação Orientada a Objetos com JavaProgramação Orientada a Objetos com Java
Programação Orientada a Objetos com Java
Álvaro Farias Pinheiro
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
Álvaro Farias Pinheiro
 
Redes Sociais
Redes SociaisRedes Sociais

Mais de Álvaro Farias Pinheiro (18)

Data science
Data scienceData science
Data science
 
IA
IAIA
IA
 
Autômatos
AutômatosAutômatos
Autômatos
 
Paradigma Orientado a Objetos
Paradigma Orientado a ObjetosParadigma Orientado a Objetos
Paradigma Orientado a Objetos
 
Padrões de Projeto (GoF)
Padrões de Projeto (GoF)Padrões de Projeto (GoF)
Padrões de Projeto (GoF)
 
Linguagem de Modelagem Unificada (UML)
Linguagem de Modelagem Unificada (UML)Linguagem de Modelagem Unificada (UML)
Linguagem de Modelagem Unificada (UML)
 
Introdução a Tecnologias Web
Introdução a Tecnologias WebIntrodução a Tecnologias Web
Introdução a Tecnologias Web
 
Introdução ao HTML
Introdução ao HTMLIntrodução ao HTML
Introdução ao HTML
 
Introdução à Sistemas de Informação
Introdução à Sistemas de InformaçãoIntrodução à Sistemas de Informação
Introdução à Sistemas de Informação
 
Análise e Modelagem com UML
Análise e Modelagem com UMLAnálise e Modelagem com UML
Análise e Modelagem com UML
 
Eficiência Energética
Eficiência EnergéticaEficiência Energética
Eficiência Energética
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
 
Medida de Esforço de Software com Análise de Ponto de Função
Medida de Esforço de Software com Análise de Ponto de FunçãoMedida de Esforço de Software com Análise de Ponto de Função
Medida de Esforço de Software com Análise de Ponto de Função
 
Fundamentos de Padrões de Projeto de Software
Fundamentos de Padrões de Projeto de SoftwareFundamentos de Padrões de Projeto de Software
Fundamentos de Padrões de Projeto de Software
 
Fundamentos de Banco de Dados Relacionais
Fundamentos de Banco de Dados RelacionaisFundamentos de Banco de Dados Relacionais
Fundamentos de Banco de Dados Relacionais
 
Programação Orientada a Objetos com Java
Programação Orientada a Objetos com JavaProgramação Orientada a Objetos com Java
Programação Orientada a Objetos com Java
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
 
Redes Sociais
Redes SociaisRedes Sociais
Redes Sociais
 

Fundamentos de Testes de Software

  • 2. “O objetivo do Teste de Software é encontrar bugs, encontrá-los o mais cedo possível e garantir que os bugs sejam corrigidos” (Patton, 2005) http://www.alvarofpinheiro.eti.br
  • 3. TESTES DE SOFTWARE INTRODUÇÃO http://www.alvarofpinheiro.eti.br
  • 4. O que é um bug?  Várias definições existem em cada empresa  Um bug é: um defeito, falta, problema, incidente, anomalia, CR, etc.  Empresas usualmente perdem um bom tempo discutindo isso  Mas normalmente a conclusão é que um bug é apenas um bug  Uma definição mais formal de bug pode ser feita se pensando quando um bug ocorre [Patton, 2005]  Um bug ocorre quando uma ou mais das opções abaixo for verdadeira:  O software NÃO faz algo que a especificação diz que ele deveria fazer  O software FAZ algo que a especificação diz que ele NÃO deveria fazer  O software faz algo que a especificação não menciona  O software NÃO faz algo que a especificação NÃO menciona, mas deveria mencionar  O software é difícil de usar, entender, ou na visão do testador pode ser visto pelo usuário final como não estando correto http://www.alvarofpinheiro.eti.br
  • 5. Bugs clássicos:  CD-ROM Rei Leão da Disney  Lançado em 1994  Primeiro CD-ROM da Disney (muita propaganda e grandes vendas)  Lançado antes no natal  Não foi testado em diferentes configurações de PCs e não informava a configuração mínima  Bug do ano 2000  Computadores não estavam preparados para o ano 2000  Sistema de Telefones de AT&T nos EUA  Toda a rede caiu por causa de um switch case errado  Sistema de Foguetes em Nara e Agência Européia  O foguete explodiu no lançamento pois o código feito na Nasa estavam no sistema métrico inglês e o da agência Européia no sistema internacional http://www.alvarofpinheiro.eti.br
  • 6. Qual o custo de um bug?  O custo de um bug está diretamente associado a fase do ciclo de desenvolvimento em que o bug é encontrado  Um bug encontrado durante a especificação pode custar 1 dolar. O mesmo bug encontrado no release pode custar 100x mais http://www.alvarofpinheiro.eti.br
  • 7. Por que bugs ocorrem?  Usualmente a razão de um bug ocorrer, depende do tamanho e do tipo do sistema Sistemas de Média e Grande Porte Sistemas de Pequeno Porte http://www.alvarofpinheiro.eti.br
  • 8. Por que bugs ocorrem?  Problemas de especificação são a principal causa de bugs  Mais de 50%  Em Sistemas Pequenos  Problemas no código são a principal causa de bugs: 75%  Erros durante a construção (low level design + code + unit tests + integração) correspondem por pelo menos 35% dos erros  Quanto maior o projeto menor o número de erros na construção é maior o número na especificação  Problemas se especificação são em geral o maior causador de bugs em um software  Quanto maior o software, maior o número de erros na arquitetura e design de alto níve http://www.alvarofpinheiro.eti.br
  • 9. Tipos de Bug  Vários estudos buscaram definir tipos de bug e suas porcentagens de ocorrência  Nenhum dos estudos foi muito conclusivo, mas vários pontos importantes foram levantados  O escopo dos erros é limitado: 85% dos erros podem ser corrigidos modificando apenas 1 rotina (classe) [Endres, 1975]  Maioria dos erros não está no código, mas no domínio da aplicação e não são problema do código em si  Vários erros são simples erros de digitação: 35% dos erros de código são erros de digitação [Weiss, 1975]. http://www.alvarofpinheiro.eti.br
  • 10. Tipos de Bug  Maioria dos erros são simples de corrigir  85% dos erros podem ser corrigidos em menos de 1 hora  Apenas 1% dos erros levam mais que alguns dias para corrigir  80% do esforço de manutenção é gasto em apenas 20% dos erros  Os erros são concentrados em partes específicas do código  80% dos erros está em apenas 20% do código [Endres, 1975]  50% dos erros pode ser encontrado em 5% do código [Jones, 2000]  Os testes que buscam identificar quais são essas partes específicas do código podem reduzir em muito o custo de manutenção  Algumas vezes é melhor reescrever as rotinas nos quais os erros estão concentrados http://www.alvarofpinheiro.eti.br
  • 11. Por que testes precisam se realizados?  Existem várias técnicas de encontrar bugs  Nenhuma técnica consegue garantir que TODOS os bugs sejam encontrado  Testes de software é uma das possíveis técnicas que podem ser aplicadas  Nenhuma técnica consegue encontrar mais de 85% dos bugs  Testes unitários + testes de componente + testes de sistemas atingem no máximo 60% dos bugs http://www.alvarofpinheiro.eti.br
  • 12. Por que testes precisam se realizados?  Testes precisam ser realizados, mas não são suficientes para garantir que todos os bugs sejam encontrados  O ideal é combinar diferentes técnicas para garantir que a maioria dos bugs sejam encontrados o mais cedo possível  Algumas organizações chegam a atingir 95% de bugs encontrados combinando diferentes técnicas  Vários estudos comparam eficiência de técnicas de encontrar bugs  Grupo de programadores com média de 11 anos de experiência  Avaliou um código com 15 erros conhecidos  3 técnicas foram usadas  Testes contra a especificação  Execução de testes unitários e de sistemas  Inspeções da especificação e dos testes unitários  Em média apenas 5 erros foram encontrados  Testes usualmente atingem no máximo 50-60% de cobertura [Johnson 1994] http://www.alvarofpinheiro.eti.br
  • 13. O que testar?  Definir o que testar no software é uma decisão fundamental  Essa definição deve levar em conta a “qualidade final” do software  Qualidade do produto  “satisfação final do usuário”  Satisfação do usuário  “experiência de uso” do software  Caso a “experiência de uso” seja boa a satisfação final do usuário será boa, mesmo que o software ainda apresente bugs Todas as funcionalidades que apresentam riscos para a qualidade do software DEVEM ser testadas http://www.alvarofpinheiro.eti.br
  • 14. Riscos  É importante identificar quais os possíveis problemas que podem causar dificuldades na realização das atividades de teste?  Cada possível problema é chamado de “risco”  Para cada risco deve-se avaliar pelo menos  Probabilidade de ocorrer  Plano de contingência caso o risco de torne um fato  Prioridade do risco  Outros aspectos podem ser avaliados para cada risco de acordo com o processo de gerenciamento de risco da organização http://www.alvarofpinheiro.eti.br
  • 15. O que testar? Experiência de uso Software Usuário Testes Testes Software Usuário Os testes estão cobrindo As áreas com riscos para qualidade http://www.alvarofpinheiro.eti.br
  • 16. Conceitos em Testes de Software  Processos de Testes  Estágios de Teste  Tipos de Teste  Abordagens de Teste  Procedimentos de Teste  Projetos de Testes  Técnicas de Testes  Ferramentas de Testes http://www.alvarofpinheiro.eti.br
  • 17. Foco de Teste  O foco dos testes muda de acordo com o estágio de testes sendo realizado, assim como o testador realizando a atividade  Este foco varia de  Testes de estruturais  Testes comportamentais  Testes reais Desenvolvedor Engenheiro de Testes Usuário Testes Estruturais Testes Comportamentais Testes Reais http://www.alvarofpinheiro.eti.br
  • 18. Foco de Teste – Testes Estruturais  Buscam encontrar erros internos no software.  Focam diretamente no código  Encontram erros como  Um método pode estar recebendo um inteiro de 24 bits e tentando guardá-lo em 16 bits  Um algoritmo específico pode não estar tratando todos os possíveis fluxos de execução  Testes estruturais estão associados ao estágios de teste unitários e de componente  Eles são realizados então pelo desenvolvedor de software ou por um desenvolvedor de software em testes (testes de componente) http://www.alvarofpinheiro.eti.br
  • 19. Foco de Teste – Testes Comportamentais  Encontram erros de mais alto nível no domínio da aplicação e não mais no código  Focam nas funcionalidades do sistema como um todo  Encontram erros como  Um usuário sem permissão conseguem realizadas operações sensíveis do sistemas  O sistema não implementa uma determinada regra de negócio como deveria  Testes comportamentais estão associados aos testes de sistema  Eles são realizados usualmente por engenheiros de teste http://www.alvarofpinheiro.eti.br
  • 20. Foco de Teste – Testes Reais  Encontram erros no sistema como um todo, mas agora focando nas necessidades finais do usuário  Usuários reais tendem a encontrar problemas que não são vistos pelos engenheiros de teste  Os tipos de erros encontrados podem ser parecidos com os encontrados nos testes comportamentais  Também podem ser encontrados erros como  Uma funcionalidade bem importante pode estar escondida em um sub-menu em vez de estar exposta mais claramente  A forma como o sistema foi implementado não está resolvendo o problema do usuário  Estes testes usualmente são realizados por usuários finais  Os testes reais estão associados a um teste de aceitação http://www.alvarofpinheiro.eti.br
  • 21. Procedimento de Teste  O procedimento de testes está diretamente relacionado ao conceito de caso de teste  Cada caso de teste está associado a um diferente “cenário” a ser testado  Para cada requisito existem diferentes cenários a serem testados  Para validar um caso de testes é necessário  Definir o ambiente no qual o teste será realizado  Definir a entrada deste caso de teste  Definir a saída esperada para cada entrada  Definir os passos a serem realizados para executar os testes  O conjunto de passos acima determina o que um procedimento de testes http://www.alvarofpinheiro.eti.br
  • 22. Resultado de Testes  Quando cada caso de teste é executado, o seu resultado deve ser coletado  Existem diferentes abordagens para definir o resultado de um caso de teste especifico  A mais comum define as seguintes opções  Passou  todos os passos do caso de testes foram executados com sucesso para todas as entradas  Falhou  nem todos os passos foram executados com sucesso para uma ou mais entradas  Bloqueado  o teste não pode ser executado, pois o seu ambiente não pode ser configurado, ou pode alguma dependência externa http://www.alvarofpinheiro.eti.br
  • 23. Testes: Cerificações O maior problema das certificações são a falta de padronização em seus conteúdos. Por isso, é indicado se que escolha o programa que mais se adéqua as necessidades da empresa e se incentive as pessoas a tirá-la e a experiência é insubstituível. American Society for Quality’s (ASQ) Certified Software Quality Engineer (CSQE); Quality Assurance Institute’s (QAI) Certified Software Test Engineer (CSTE) International Institute for Software Testing’s (IIST) Certified Software Test Professional (CSTP) Institute of Electrical and Electronic Engineers’ (IEEE) Certified Software Development Professional (CSDP) British Computer Society’s (BCS) Information Systems Examination Board (ISEB) http://www.alvarofpinheiro.eti.br
  • 24. Testes: Modelo de Documento Missão: <uma breve sentença sobre a missão dessa sessão> Áreas: <area1 do requisito1> <area2 do requisito2> <...etc> Início: <data e hora de início> Testador: <nome do testador> Tarefas: <descrição das atividades> Duração: <os valores são "curta", "normal", ou "longa”> Preparação da Sessão: <% da duração da sessão gasta na preparação, entre 0-100> Projeto e Execução de Testes: <% da duração da sessão gasta procurando bugs, entre 0-100> Investigação e Reportagem dos Bugs: <% da duração da sessão gasta investigando problemas, 0-100> Descrição x Oportunidade: <descrição da duração da sessão que foi gasta na missão de investigação> Arquivos de Dados: <a sintaxe é o formato do aquivo ex.: "foo.bat“ e se não houver arquivos de dados, #N/A> Notas dos Testes: <formato de texto livre> Bugs: <listar os bugs com uma tag #BUG, o formato do texto é livre e se não houverem bugs, usar #N/A> Exemplo para Bugs encontratos: #BUG Título do bug Passos para reprodução: 1 - … 2 - … Resultado: ... Esperado: ... Issues: <o mesmo formato da sessão de BUG acima, se não houverem ISSUES, use #N/A> http://www.alvarofpinheiro.eti.br
  • 25. TESTES DE SOFTWARE EQUIPES http://www.alvarofpinheiro.eti.br
  • 26. Equipes de Testes Existem várias maneiras de se organizar testes, porém a forma que se mostra mais adequada é a criação de um grupo independente de teste.E independência significa reconhecer os engenheiros de teste como especialistas, ou seja, não são desenvolvedores e respondem a uma gerência independente da gerência de desenvolvimento. É importante salientar, que engenheiros de teste possuem responsabilidades diferentes e, consequentemente, evoluem diferentemente, e que devem ser imparciais e não se influenciarem pela pressão do desenvolvimento. http://www.alvarofpinheiro.eti.br
  • 27. Equipes de Testes: Times Independentes A funcão principal desse time é fazer testes, seja para um ou vários produtos. Ele não deve estar subordinado a mesma gerência de desenvolvimento, o que faz com que esse time não sofra as pressões internas de prazo de entrega do produto. Essa maneira tem uma grande vantagem de ter profissionais especializados em testes e a garantia de que os testes podem ser realizados tão bem quanto o desenvolvimento do sistema. Sua desvantagem é que, por passarem a existir dois times onde um tem a missão de encontrar problemas no que o outro desenvolveu, pode começar a haver desentendimentos entre esses eles. Entretanto, isso pode ser minimizado a nível gerencial, lembrando sempre que ambos estão contribuindo para a qualidade do produto final que é parte do esforço de ambos; estimulando a comunicação entre os times; inicializando o processo de teste o quanto antes. http://www.alvarofpinheiro.eti.br
  • 28. Equipes de Testes: Times Integrados Os engenheiros de teste e os engenheiros de sistemas fazem parte de um mesmo time. Normalmente, é o que acontece em empresas projetizadas. Como todos fazem parte de um mesmo time, é mais fácil fazer com que os testes sejam iniciados cedo. Contudo, pelo mesmo motivo, é difícil captar bons recursos, pois, geralmente eles já estão em outras equipes. Um outro problema que ocorre com frequência é que, pelo fato do gerente ser encarregado tanto do desenvolvimento quanto do teste, ele pode se sentir mais tentado a entregar o produto no prazo acordado para não ferir seu cronograma, fazendo com que o serviço de teste seja comprometido por encurtar o tempo anteriormente planejado para o teste. http://www.alvarofpinheiro.eti.br
  • 29. Equipes: Desenvolvedores São responsáveis por desenvolver e testar os sistema os problemas de comunicação são eliminados; a priorização da correção de bugs torna-se mais fácil; o bom conhecimento do design e do código faz com que seja mais fácil de encontrar qual a razão do bug. Porém, outros problemas vêm à tona, como: a falta de um conhecimento mais aprofundado do negócio limita o nível de teste a ser feito; a falta de conhecimento técnico de tipos, estratégias, métodos, processos de teste dificulta à realização do serviço de teste; a experiência com programação faz com que eles fiquem tentados, e às vezes limitados, a testar apenas o que o sistema deve fazer, não criando cenários de teste onde se tem de fato a maior probabilidade de encontrar bugs. http://www.alvarofpinheiro.eti.br
  • 30. Equipes: Coordenadores de Testes Quando não existe grupo de testes, um coordenador de teste Deve ser escolhido para formar e liderar um time temporário de teste que poderá ser composto por desenvolvedores, engenheiros de qualidade, vendedores, usuários, etc. O coordenador escolhido deve ter um perfil pré-estabelecido para que se tenha sucesso nesse modelo, como por exemplo: experiência, credibilidade, boa comunicação e habilidades de gestão. Ainda assim, ele irá enfrentar problemas com a captação de recursos, pois como o time é temporário, os melhores recursos não serão facilmente cedidos por seus gerentes definitivos. A falta de pessoas experientes, de um ambiente de teste, de casos de teste já existentes, são outros problemas que o coordenador terá de encarar. Um dos motivos de se usar essa estratégia é quando se tem a necessidade emergente de se fazer teste e não se tem tempo, dinheiro e conhecimento para se formar um time de testes. http://www.alvarofpinheiro.eti.br
  • 31. Equipes: Time de Qualidade Em algumas organizações o time de qualidade é responsável também pelos testes. O fato das habilidades necessárias serem bastante parecidas, ajuda os engenheiros de qualidade a terem uma maior empatia pelas atividades de teste e, consequentemente, desempenhá-las com sucesso. Um fator preocupante nessa estratégia é que testes seria uma responsabilidade a mais para o time o que pode dificultar fazer com que os testes sejam realizados com eficiência. http://www.alvarofpinheiro.eti.br
  • 32. Equipes: Terceirização Terceirizar testes pode ser uma boa solução quando há falta de verba pra fazer teste internamente, falta de conhecimento técnico em testes ou falta de um ambiente propício. É importante salientar que apesar de estar contratando um serviço bem melhor do que o que possa ser oferecido de forma rápida internamente, o contratado possivelmente não terá o entendimento do negócio tão bem quanto o contratante. Além disso, o fato de se terceirizar os testes não elimina a responsabilidade da qualidade do produto que está sendo desenvolvido. Por isso, é importante que haja um acompanhamento do serviço que está sendo prestado. Para se ter sucesso nessa estratégia é recomendável que se tenha um bom contrato, contratar as pessoas certas, estabelecer entregas bem definidas, ter padrões de qualidade e ter uma boa visão do serviço do contratado. http://www.alvarofpinheiro.eti.br
  • 33. Equipes: Empresa de V&V Normalmente, são realizados por um contratante independente e ao final do desenvolvimento, o que reduz maiores riscos de ter um produto funcionando com defeitos mas também pode elevar consideravelmente os custos. Por ser extremamente caro contratar uma empresa de Validade e Verificação (V&V), elas são geralmente contratadas quando se tem projetos do governo, quando se corre risco de vida no uso do sistema, em projetos de prestígio nacional, etc. http://www.alvarofpinheiro.eti.br
  • 34. Papeis: Gerente de Testes São pessoas que precisam lidar com organizações que processam muitas linhas de comunicação formal e informal. Eles precisam lidar com recursos com vários níveis de habilidades, ferramentas, orçamentos e estimativas. O gerente é quem está à frente do time os representando nas mais diversas situações dentro e fora da empresa, o que pode afetar a percepção que as pessoas que estão fora do time de teste têm sobre este time. Deve atuar como provedor de informações, servindo de canal de comunicação de informações entre o trabalho realizado pela equipe e os stakeholders do projeto. Algumas informações importantes, por exemplo, seriam: status reports, planos, estimativas, relatórios de eficiência. http://www.alvarofpinheiro.eti.br
  • 35. Papeis: Engenheiro de Testes Os requisitos para essa função são: Conhecimento do negócio da aplicação; Conhecimento técnico de testes; e Habilidades específicas. E as habilidades são: Dinamismo; Pensamento crítico; Comunicativo; Criatividade; Curiosidade; Maturidade; Trabalho em equipe; Facilidade de relacionamento interpessoal; Auto-motivação; Iniciativa; e Atenção aos detalhes. Fontes são: Desenvolvedores, excelentes para testes unitários, integração. E testes automáticos;Usuários, pois possuem um bom conhecimento do negócio do sistema, mas possuem pouco conhecimento técnico; Suporte, estão acostumados a descobrir problemas normalmente enfrentados pelos colaboradores da Empresa; Techinical Writers, produzem documentos técnicos e prestam bem atenção aos detalhes, podendo serem ótimos em reportar bugs, criar e organizar suites e ciclos de teste, elaborar o plano de testes; Engenheiros de Qualidade, dão importância a qualidade do software e da utilização do processo. http://www.alvarofpinheiro.eti.br
  • 36. Quem é o testador?  O testador está diretamente associado a definição de teste de software  O testador  Encontra o bug  Busca encontrá-lo o mais cedo possível  Garante que o bug está corrigido  Um bug corrigido não necessariamente implementa em mudança no código  Correção de um manual  Correção de treinamento  Etc.  O testador deve ser responsável por verificar realmente se o bug foi corrigido http://www.alvarofpinheiro.eti.br
  • 37. Quem é o testador?  Por que o testador é necessário?  Os testes feitos por desenvolvedores  Tendem a verificar apenas o “caminho feliz”  Normalmente são otimistas  Não são sofisticados  Organizações iniciais tem usualmente 5 testes de “caminho feliz” para cada teste de “caminho alternativo”  Organizações maduras usualmente tem o oposto - 5 de caminho alternativo para cada um de caminho feliz  Desenvolvedores normalmente só conseguem enxergar 50-60% dos casos de teste do seu código  O Testador tem um perfil diferente do desenvolvedor  São exploradores  Gostam de encontrar problemas  Criativos no uso do software  Visão das diferentes situações em que o software pode ser usado http://www.alvarofpinheiro.eti.br
  • 38. Principais Papéis em Testes  Pode-se identificar 4 papéis principais para as atividades de testes  Gerente de Testes  Monta o plano de testes e faz o acompanhamento de todas as atividades relativas aos testes  Projetista de Testes  Identifica os casos de teste e escreve os procedimentos para cada um deles  Desenvolvedor de Testes  Implementa os casos de teste automático que foram projetados pelo projetista  Testador  Executa os casos de teste e preenche o resultado de testes  Estes papéis podem ou não ser realizados pela mesma pessoa  Isso depende de cada organização ou do tamanho / escopo do projeto  Existem outros termos que podem ser usados para descrever os papéis em atividades de teste  Durante o restante do módulo serão usados os termos definidos acima http://www.alvarofpinheiro.eti.br
  • 39. TESTES DE SOFTWARE CICLO DE VIDA DE UM BUG http://www.alvarofpinheiro.eti.br
  • 40. Ciclo de Vida de um Bug  O ciclo de vida de um bug determina os vários estágios pelos quais o bug passa durante o desenvolvimento do software  Este ciclo de vida precisa ser definido nas organizações  O processo de controle de mudanças é responsável pode definir o ciclo de vida  O ciclo de vida pode ser bem simples  Aberto: bug identificado no teste  Resolvido: bug resolvido  Fechado: solução verificada http://www.alvarofpinheiro.eti.br
  • 41. Ciclo de Vida de um Bug  O ciclo de vida também pode ser bem complexo  Aberto  Resolvido como não corrigir  Resolvido como corrigido  Fechado como corrigido http://www.alvarofpinheiro.eti.br
  • 42. Ciclo de Vida de um Bug  Algumas organizações adotam para o bug um ciclo de vida similar ao de desenvolvimento de um software  Iniciado: bug descrito  Análise: bug analisado e especificado  Implementação: bug implementado  Testes: bug testado  Fechado: bug fechado de o teste for correto http://www.alvarofpinheiro.eti.br
  • 43. Ciclo de Vida de um Bug  O ciclo de vida genérico para um bug pode ser como o apresentado abaixo  O estado importante a ressaltar e o de análise  Nele o bug é avaliado para identificar se é ou não para ser corrigido  Esse papel é executado por um CCB http://www.alvarofpinheiro.eti.br
  • 44. Ciclo de Vida Revisado Rejeitado Aberto Atribuído Trabalho Fechado Reaberto Adiado http://www.alvarofpinheiro.eti.br
  • 45. TESTES DE SOFTWARE MODELOS http://www.alvarofpinheiro.eti.br
  • 46. Engenharia de Software  As atividades de testes são inseridas no contexto das atividades de engenharia de software  TODO software segue um ciclo de vida  Existem vários modelos de ciclo de vida que podem ser adotados durante o desenvolvimento  O modelo de ciclo de vida usualmente direciona  Quais testes serão rodados  Quando os testes serão rodados  Os seguintes modelos serão discutidos  Cascata  V  Incremental  Codificar e testar http://www.alvarofpinheiro.eti.br
  • 47. Modelo Cascata  Fases seqüências que produzem o software  Ao final de cada fase uma revisão interna deve validar se é possível passar a fase seguinte  A princípio só se deve passar a fase seguinte com a anterior finalizada  Foco principal é garantir que a especificação é bem feita antes de iniciar as fases seguintes http://www.alvarofpinheiro.eti.br
  • 48. Modelo Cascata  O modelo em cascata é ideal para softwares bem conhecidos  Sem grandes surpresas durante a especificação  Tecnologia bem conhecida da equipe  A fase de testes é bem natural e é executada após toda a codificação  Principal vantagem para os testes  A especificação normalmente é bem feita e detalhada  Principal problema  Os testes só são executados no final  O custo de corrigir um problema é mais alto http://www.alvarofpinheiro.eti.br
  • 49. Modelo V  Variação do modelo em cascata  Associa diferentes tipos de teste de acordo com a fase do ciclo de vida  Testes de aceitação usualmente estão associados aos requisitos  Testes de Integração usualmente estão associados ao design  Testes de componente usualmente estão associados ao código http://www.alvarofpinheiro.eti.br
  • 50. Modelo V  O modelo V define diferentes estágios de testes para serem executados  Pode ser visto como uma extensão do modelo em cascata  Ainda existe a ênfase na especificação  Cada fase precisa ser finalizada antes do início da fase seguinte  Também é ideal para softwares com requisitos conhecidos  A grande vantagem do modelo é:  Identificar os diferentes estágios de teste que validam aspectos do ciclo de vida do software  Permite um melhor planejamento dos testes que precisam ser executados  “Quebra” os testes em diferentes focos  A principal desvantagem é:  Os testes ainda são rodados apenas após o código estar pronto http://www.alvarofpinheiro.eti.br
  • 51. Modelo Incremental  Desenvolvimento é “quebrado” em várias iterações  Cada interação pode ser vista como uma pequena cascata  Cada interação passa por todas as fases do ciclo  Em maior ou menor escala  Requisitos são adicionados ao software em cada iteração http://www.alvarofpinheiro.eti.br
  • 52. Modelo Incremental  O modelo incremental busca usar as vantagens do cascata  Focar em ter uma boa especificação  Mas sendo realista  Nem toda a especificação pode estar pronta no início do desenvolvimento  As iterações podem ser repetidas até que o software esteja estável  Ao final cada iteração é necessário  Determinar os objetivos da próxima iteração  Avaliar os riscos  Avaliar os testes  Avaliar os requisitos que já estão implementados  Planejar a iteração seguinte http://www.alvarofpinheiro.eti.br
  • 53. Modelo Incremental  A principal vantagem para os testes é  Os testes são rodados várias vezes (ao final de cada iteração)  Os bugs podem ser antecipados  Os testadores usualmente podem (e devem ser) envolvidos no projeto desde o início  A principal desvantagem para os testes é  Algumas vezes não fica claro que testes devem ser rodados ao final de cada iteração  O esforço de planejamento de testes é maior  Mas esse esforço normalmente é compensado  É necessária uma equipe de testes mais experiente para planejar e executar testes neste modelo http://www.alvarofpinheiro.eti.br
  • 54. Modelo Codificar e Testas  Parte de uma especificação informal  Ênfase em codificação  Não existe ênfase em outras fases do desenvolvimento  Como a especificação não é clara os testes também não são  Mas os testes são executados várias vezes  É ideal para projetos pequenos e com equipe pequena  Principal vantagem para os testes  Vários ciclos de testes  Custo de correção não é alto  Principal desvantagem para os testes  Planejamento e qualidade dos testes normalmente não é boa http://www.alvarofpinheiro.eti.br
  • 55. Modelo Ágeis  Muito parecido com o codificar e testar  Foco em fechar várias versões do software  Integração continua  Especificação de requisitos informal  Mas o cliente final DEVE ficar próximo a equipe de desenvolvimento para validar os requisitos  Mas os testes  São mais formais  Devem ser automatizados  Garantir que sempre serão rodados  São executados a cada integração  Cliente pode participar da validação  Principal vantagem para os testes  Automatização  Sai a figura do testador e entra a do desenvolvedor de testes  Principal desvantagem  É necessário o uso de uma ferramenta para automatização http://www.alvarofpinheiro.eti.br
  • 56. Modelo Ágeis: TDD  Test Driven Development  Modelo de Desenvolvimento Orientado a Testes  É uma das principais técnicas associadas a modelos ágeis  A idéia é que os testes sejam desenvolvidos antes do código  TFD: Test First Design  O passos para usar TDD são:  Escreve um caso de teste e executa um caso de teste  Falhando, implementa o código para passar no teste  Passando, continua o desenvolvimento e escreve um novo caso de testes  TODA a fase de implementação de um modelo ágil pode ser feita com TDD http://www.alvarofpinheiro.eti.br
  • 57. TESTES DE SOFTWARE PROCESSO http://www.alvarofpinheiro.eti.br
  • 58. Processo de teste Processo de Desenvolvimento Análise Projeto Implementação Testes Produto Final http://www.alvarofpinheiro.eti.br
  • 59. Processo de Testes  Os processos de teste são seqüências de ações, operações que são executadas com o objetivo de  Encontrar problemas no software  Encontrá-los o mais cedo possível  Aumentar a percepção de qualidade geral do software  Garantir que o usuário final tenha um software que atende as suas necessidades  De forma geral, o processo de teste pode ser separado em 4 grandes ações  Planejar  entender o que precisa ser testado e definir como  Preparar  selecionar e montar todo o ambiente para execução  Executar  executar os testes e coletar o resultado  Avaliar  verificar os resultados e métricas para melhorar os testes http://www.alvarofpinheiro.eti.br
  • 60. Processo de Testes  O primeiro passo para realizar as atividades relacionadas a testes em uma organização é definir um processo de testes  Este processo deve:  Definir as principais atividades que precisam ser seguidas durante os testes  Definir papéis e responsabilidades das atividades de teste  Definir as ações associadas a cada atividade  Definir as entradas e saída de cada um das atividades  Associar possíveis templates de documento a cada uma das atividades  As principais atividades que podem ser identificadas em um processo de testes são:  Planejar Testes  Projetar Testes  Implementar Testes Automáticos  Executar Testes  Avaliar Resultados http://www.alvarofpinheiro.eti.br
  • 61. Planejar Testes  Objetivo da Atividade  Planejar as atividades de testes que serão realizadas durante o ciclo de vida do software  Responsável pela atividades  Gerente de Testes com apóio do gerente de projetos  Principais Passo  Definir estágios de testes que serão executados  Definir tipos de teste que serão necessários em cada estágio  Entender os requisitos que precisarão ser testados  Definir se algum teste será ou não automatizado  Estimar o esforço necessário para projetar e implementar os testes  Estimar o esforço necessário para executar os testes  Definir que recursos de hardware e software serão necessário para a execução dos testes (definir ambiente de testes)  Definir riscos, dependências e premissas dos testes  Montar cronograma das atividades de testes  Associar este cronograma com o cronograma principal do projeto  Artefato Gerado  Plano de Testes http://www.alvarofpinheiro.eti.br
  • 62. Planejar Testes  É importante notar que as atividades podem mudar de acordo com o tipo de projeto  O planejamento de testes DEVE ser executado  Após ou em paralelo com as atividades de requisitos  O gerente de testes deveria ser alocado junto com o gerente de projetos  Assim como o projetista de testes DEVE ser alocado no projeto junto com o analista de requisitos  Determinar que estágios e tipos de teste serão realizados é uma das principais atividades  A atividade mais difícil de executar é a estimativa  Durante o módulo seguinte a atividade de planejamento de testes será mais detalhada http://www.alvarofpinheiro.eti.br
  • 63. Planejar Testes: Possível Estrutura de um Plano de Testes  Introdução  Estágios de Testes  Critérios de Entrada  Critérios de Saída  Tipos de Testes  Critérios de Entrada  Critérios de Saída  Ambiente de Testes  Recursos de Hardware  Recursos de Software  Riscos, Dependências e Premissas  Cronograma http://www.alvarofpinheiro.eti.br
  • 64. Projetar Testes de Sistema  Objetivo  Identificar os casos de teste e escrever o procedimento de testes para cada um deles  Definir qual dos casos de teste vai ser automatizado  Responsável pela atividade  Projetista de Testes  Principais Passos  Avaliar os requisitos funcionais e não funcionais  Verificar quais os tipos de testes precisarão ser executados  De acordo com isso outros passos precisarão ser realizados  Para cada requisito definir os cenários de testes associados a eles  Para cada cenário definir um caso de teste  Para cada caso de testes definir  Entradas e saídas  Pré e pós condições  Passos para execução do caso de teste  Artefato de Saída  Projeto de Testes http://www.alvarofpinheiro.eti.br
  • 65. Projetar Testes de Sistema: avaliar especificação  Primeiro passo para projetar os testes de sistema é avaliar a especificação do software  Essa avaliação pode ser feita  Durante uma revisão formal da especificação  Após os requisitos serem fechados e antes de se projetar os testes  O ideal é que o projetista de teste participe da revisão dos testes  Requisitos NÃO devem ser fechados sem a avaliação pela equipe de testes  Cada requisito funcional precisa ser verificado para garantir  Completude  Corretude  Precisão  Consistência  Relevância  Viabilidade  Testabilidade http://www.alvarofpinheiro.eti.br
  • 66. Projetar Testes de Sistema : avaliar especificação  Completude  Existe algo faltando no requisito? Ele contém todas as informações necessários para o seu entendimento  Corretude  O requisito apresentado realmente resolve o problema que ele se propõe?  Precisão  A descrição do requisito está clara? Existe alguma parte que pode interpretada erradamente?  Consistência  Os requisitos são consistentes entre si? Alguma requisito é contraditório com outro?  Relevância  O requisito realmente é um requisito? Ou é algum aspecto de design que deveria ser tratado posteriormente? http://www.alvarofpinheiro.eti.br
  • 67. Projetar Testes de Sistema : avaliar especificação  Viabilidade  É possível implementar esse requisito ? A tecnologia atual permite que ele seja implementado?  Testabilidade  O requisito pode ser testado ? É possível gerar um procedimento de testes que valide se o requisito está implementado corretamente?  Os requisitos funcionais NÃO devem ser esquecidos  É necessário garantir que estes estão claramente especificados  Qual o requisito de segurança?  Existe requisito de performance? Qual é?  Existe alguma restrição de ambiente? Qual o banco de dados e o servidor de aplicação que deve usado?  Existem alguma restrição de tecnologia? http://www.alvarofpinheiro.eti.br
  • 68. Projetar Testes de Sistema : avaliar especificação  Outros aspecto importante a avaliar são os termos usados na descrição dos requisitos  Termos como  Sempre ou nunca: é necessário verificar se eles realmente significam isso no requisito  Bom, rápido, pequeno, estável: palavras assim não denotam requisitos testáveis e devem ser evitadas  Se .. Então ..: sempre que um Se.. Então for entrado e importante especificar o que ocorre no senão  Etc. : TODOS os etc. devem ser removidos da especificação http://www.alvarofpinheiro.eti.br
  • 69. Projetar Testes de Sistema  Os casos de teste de sistema são caixa preta e são executados sobre todo o sistema  A avaliação dos requisitos é a atividade principal  O ideal é que o projetista de testes participe da revisão dos requisitos para garantir que  Cada requisito está claramente especificado  Cada requisito é testável  Os cenários de cada requisito são claramente definidos  Os requisitos funcionais estão corretamente especificados  Sem as informações acima não é possível projetar os casos de teste corretamente  A baixa qualidade dos testes está diretamente associada a baixa qualidade dos requisitos  A atividade de projetar testes será melhor detalhada no módulo seguinte http://www.alvarofpinheiro.eti.br
  • 70. Projeto de Testes Unitário  Objetivo  Avaliar uma unidade de código antes que esta seja integrada ao restante do sistema  Responsável pela atividade  Desenvolvedor  Principais passos  Determinar abordagem de testes: caixa branca ou preta  Am ambos os casos é necessário  Avaliar o código  Identificar que stubs precisam ser implementados  Identificar que fluxos de execução precisam ser testados  Avaliar a interface da unidade a testar  Baseado nas informações acima, definir os casos de testes e definir o procedimento de testes  Artefato de Saída  Procedimentos de testes unitários http://www.alvarofpinheiro.eti.br
  • 71. Projeto de Testes Unitário  Os stubs vão garantir o isolamento da unidade  Os testes unitários usualmente são definidos em código  Os casos de teste e procedimentos podem ser documentos em um projeto de testes unitários  Ou podem ficar apenas no código sob controle do desenvolvedor  Projetos de testes unitários são de difícil manutenção  Os testes unitários podem ser automatizados para facilitar a manutenção e a execução posterior  Quanto melhor os testes unitários menor o número de problema que serão encontrados durante a integração  Testes unitários fazem parte do processo de desenvolvimento e normalmente NÃO são tratados como parte do processo de testes http://www.alvarofpinheiro.eti.br
  • 72. Projeto de Testes de Componente  Objetivo  Mesmo dos testes unitários, mas agora considerando o componente como unidade  Responsável pela atividade  Projetista de Testes  Principais passos  Mesmos dos testes unitários, com exceção de verificar a abordagem  Testes de componente usualmente são caixa preta  Artefato de Saída  Projeto de testes de componente  Como a interface do componente é bem definida e controlada, o projeto de testes de componente usualmente é feito e documentado  Testes de componente são usualmente definidos em código e podem ser automatizados http://www.alvarofpinheiro.eti.br
  • 73. Projeto de Testes de Componente  O projeto de testes está altamente associado ao tipo de interface do componente  Este tipo pode ser  Web service  Interface de uma classe  HTTP ou Socket  Serial  Objeto remoto (CORBA, COM, RMI)  Um protocolo de comunicação é implementado em cima de uma dessas interfaces  Este protocolo é que precisa ser testado  Quando a interface é programática o teste se terna mais similar a um teste unitário de uma classe  Web service e objetos remotos http://www.alvarofpinheiro.eti.br
  • 74. Projeto de Testes de Componente  Alguns Exemplos de componentes testáveis  Software POS que ler cartões de crédito  Um software que POS se comunica com um leitor de cartão de crédito via serial  O leitor de cartão tem um protocolo bem definido  Esse protocolo é implementado pelo software do POS  O POS precisa ser testado para suportar todos os possíveis dados que podem ser enviados pelo leitor  Software de atendimento médico. Componente que implementa regras de negócio para aceitar um paciente  Esse componente encapsula todas as regras para aceitar ou não um paciente  Ele é disponibilizado através de uma interface Java  TODAS as possíveis situações em que um paciente pode ser aceitou ou não precisam ser validadas  Dessa validação vai depender uma grande parte da funcionalidade do software http://www.alvarofpinheiro.eti.br
  • 75. Projeto de Testes: Possível Estrutura do Projeto  Introdução  Ambiente de Testes  Requisito 1  Caso de Teste 1  Pre-condição  Pós-condição  Cenário  Procedimento  Entradas / Saídas  Caso de Teste N  Requisito M http://www.alvarofpinheiro.eti.br
  • 76. Implementar Testes de Sistema e/ou Componente  Objetivo  Caso alguns dos procedimento de testes possa ser automatizados, eles devem ser implementados segundo o procedimento  Responsável pela atividade  Desenvolvedor de testes  Principais passos  Configurar a ferramenta de automação de testes  Determinar os dados de entrada e saída de cada caso de teste  Determinar o procedimento a ser executado em cada caso de teste  Implementar os scripts de teste na linguagem determinada pela ferramenta  Validar os scripts de teste unitariamente  Artefato de Saída  Scripts de teste implementados http://www.alvarofpinheiro.eti.br
  • 77. Implementar Testes de Sistema e/ou Componente  A implementação dos testes é totalmente direcionada pela ferramenta de testes  É importante que cada organização defina uma ferramenta de testes padrão  Testes de componente são mais fáceis de automatizar  Cada componente tem uma interface bem definida  Essa interface é sempre programática  Testes de sistema são mais complexos  Em geral envolvem interação com o usuário  Existem ferramentas que permitem a automatização de testes com interfaces gráficas, mas  Mudanças de interface são mais comuns que mudanças  Isso torna a manutenção dos testes complicada  É necessário avaliar o custo benefício de automatizar os testes de sistemas  Não necessariamente todos os testes devem ser automatizados  Alguns testes são melhor e mais rapidamente executados por testadores http://www.alvarofpinheiro.eti.br
  • 78. Implementar Testes de Sistema e/ou Componente  Existem várias vantagens de automatizar os testes  Velocidade de execução: testes automáticos são mais rápidos de executar  Eficiência: enquanto os testes estão sendo executados, os testadores podem ser alocados em outras atividades  Corretude: casos de testes automáticos nunca comentem erros durante a execução. Os passos sempre são repetidos da mesma forma  Simulação / emulação: ferramentas de testes podem ser usadas como stubs ou test drivers  Simplificação: alguns testes seriam tão complexos que rodar manualmente que a automação acaba sendo a única forma de executá-los  A corretude é uma das principais vantagens, mas também é uma limitação  Os testadores conseguem enxergar problemas que os testes automáticos não identificam  Os passos executados por um testador podem variar de uma execução para outra http://www.alvarofpinheiro.eti.br
  • 79. Implementar Testes de Sistema e/ou Componente  Alguns fatos importantes em relação a automação  Mudanças no software  Os software muda e isso torna os testes falhos  É necessário atualizar os casos de testes automáticos da mesma forma que os manuais  Testes se sistema automatizados são complexos de implementar  Testes de sistema validam especialmente interação com o usuário  Existem ferramentas para validar essa UI, mas são complexas de usar  Vários bugs de UI podem escapar  Não se pode confiar apenas na automação  O olho do testador vai conseguir encontrar problemas que a ferramenta não  Algumas ferramentas são “invasivas”  Modificam o código sendo testado  O código final pode não ser correto devido a isso http://www.alvarofpinheiro.eti.br
  • 80. Implementar Testes de Sistema e/ou Componente  Conclusões  Automatizar testes é uma excelente prática, mas deve ser feita com cuidado  A ferramenta de automatização deve ser bem escolhida  Deve se avaliar quais testes valem a pena serem automatizados  Avaliar o custo-benefício da automatização  Não se deve confiar apenas nos testes automáticos http://www.alvarofpinheiro.eti.br
  • 81. Executar Testes  Objetivo  Executar os testes planejados e coletar os resultados  Responsável pela atividade  Testador  Principais passos  Os testes a executar devem ser definidos pelo projetista / gerente de testes  Para testes manuais, o testador deve seguir o procedimento de testes aplicando todas as entradas e verificando as saídas  Para testes automáticos e testados deve configurar a ferramenta de testes e colocar os scripts de teste para rodar  Os resultados de testes devem coletados  Artefato de Saída  Resultado de testes http://www.alvarofpinheiro.eti.br
  • 82. Executar Testes  O setup para a execução de testes automáticos pode ser bem demorado  Essa atividade NÃO deve ser sub-estimada  Os testes manuais devem ser realizados com muito cuidado pelo testador  Alguns testes podem ser exploratórios  O testados deve se prender ao procedimento  Mas caso algum problema fora do procedimento seja encontrado, ele tem obrigação de reportar o problema  O testador também deve validar se o procedimento de testes está correto  Problemas no procedimento também devem ser reportados  Na dúvida, o testador DEVE reportar como erro  É melhor ter um falso positivo que deixar um bug passar  O testador deve na medida do possível dominar os requisitos que estão sendo testados http://www.alvarofpinheiro.eti.br
  • 83. Executar Testes: passo-a-passo para executar testes  Selecionar que casos de testes serão executados de acordo com o planejamento  Atribuir os casos de testes para os testadores  Executar o caso de teste e reportar os bugs. Capturar informações continuamente levando em conta as execuções anteriores  Fazer o setup do ambiente de testes de acordo com o procedimento  Entrar os dados especificados e esperar pelas saídas determinadas  Avaliar os resultados, comportamentos e estado final do software. Pesquisar qualquer diferença com o resultado esperado  Caso ocorra um problema no software, reportar  Caso um problema seja encontrado no caso de teste, reportar  Capturar as informações sobre o teste que foi executado  Resolver possíveis issues que estejam bloqueando os testes  Reportar os resultados periodicamente http://www.alvarofpinheiro.eti.br
  • 84. Executar Testes: passo-a-passo para executar testes  Durante a execução de um caso de teste, este pode está em diferentes estados  Em alguns software é importante identificar estes possíveis estados  Os estados algumas vezes estão associados aos resultados dos testes  Alguns possíveis estados genéricos  Queued  Block  Skip  In Progress  Pass  Warn  Fail  Closed http://www.alvarofpinheiro.eti.br
  • 85. Executar Testes: passo-a-passo para executar testes  Queued  Caso de teste atribuído a um testador e esperando para ser executado  Block  Execução bloqueada por alguma razão  Skip  Execução não realizada por alguma razão  In Progress  Caso de teste sendo executado  Pass  Caso de teste passado  Warn  Algum comportamento não ocorreu como esperado, mas o problema não parece grave  Fail  Algum comportamento grave ocorrer  Closed  Após um teste Fail ou de Warn, o software foi corrigido e o problema fechado http://www.alvarofpinheiro.eti.br
  • 86. Avaliar Resultados  Objetivo  Consolidar os dados gerados pela execução dos testes e avaliar os resultados para poder tomar decisões em relação ao projeto  Responsável pela atividade  Gerente de Testes  Principais passos  Coletar toda a informação sobre os resultados dos diferentes estágios  Avaliar se todos os testes que estavam planejados foram realmente executados  Caso algum problema tenha ocorrido durante a execução, isso deve ser avaliado  Reportar os resultados para o restante do projeto do software  Avaliar se os critérios esperados de resultados de testes foram atingidos.  Caso não tenha sido buscar identificar se ocorreu algum problema durante os testes  Artefato de Saída  Resultado dos testes http://www.alvarofpinheiro.eti.br
  • 87. Avaliar Resultados  A avaliação dos resultados é fundamental pois é a conclusão de cada uma das execuções de teste  Ela é a base para tomadas de decisões gerenciais de todo o projeto  Caso os testes estejam falhando mais que o esperado, alguma ação precisará ser tomada  Caso os testadores estejam com problema para executar os testes alguma ação  Caso o procedimento de testes esteja com muitos problema, ele provavelmente deverá ser revisto http://www.alvarofpinheiro.eti.br
  • 88. Avaliar Resultados: Informações Importantes de consolidar  Várias informações podem ser consolidadas na avaliação da execução dos testes  Quantidade de Testes Planejados  Número total de casos de testes que foram planejados para execução  Quantidade de Testes Executados  Número total de casos de testes que foram realmente executados  Quantidade de Testes Passados  Número total de casos de testes que passaram  Quantidade de Testes Falhos  Número total de casos de testes que falharam  Quantidade de Testes Bloqueados  Número total de casos de testes bloqueados  Quantidade de Bugs Encontrados  Número total de bugs encontrados durante os testes  Tempo total de execução dos testes  Tempo total de execução dos testes http://www.alvarofpinheiro.eti.br
  • 89. Avaliar Resultados: Informações Importantes de consolidar  As informações listadas anteriormente podem ser combinadas em diferentes métricas  Estas métricas são usadas para  Acompanhar o processo de testes  Avaliar a eficácia dos testes  Avaliar a eficiência dos testes  Avaliar o custo dos testes  O módulo seguinte vai detalhar as possíveis métricas em testes de software http://www.alvarofpinheiro.eti.br
  • 90. Planejamento de Testes Reflexão  Foram encontrados defeitos? Quantos?  Algum defeito foi corrigido?  Houve alguma preocupação com a classificação dos defeitos?  Quantos dos defeitos eram muito críticos?  Como os defeitos foram reportados?  Existe algum plano de correção dos defeitos?  Todos os recursos necessários para realização dos testes estavam presentes?  O ambiente estava configurado?  Quem participou da execução?  Que versão da release era essa? Ela estava estável?  Os testes acabaram?  Quais os próximos passos? http://www.alvarofpinheiro.eti.br
  • 91. Planejamento de teste Planejamento:  Quem executará os testes?  Que partes serão testadas? (tempo/recurso)  Quando serão executados os testes (cedo)  Como serão realizados os testes? (especificação/implementação)  Quanto devemos testar? http://www.alvarofpinheiro.eti.br
  • 92. Planejamento de teste Principais atividades do planejamento: • Determinar o escopo e os riscos e identificar o objetivo dos testes; • Determinar a abordagem de teste (caixa-preta/ caixa-branca); • Determinar os recursos necessários (pessoas, máquinas, ambiente de teste); • Determinar a estratégia de teste; • Montar cronograma das tarefas • Determinar critérios de entrada e saída. http://www.alvarofpinheiro.eti.br
  • 93. Planejamento de Testes  Planejar os testes significa  Identificar que estágios de testes serão executados (estratégia de testes)  Identificar os ciclos de testes  Identificar o que será testado  Identificar os recursos necessários para os testes  Identificar os riscos, dependências e premissas dos testes  Definir um cronograma das atividades de testes  O gerente de testes é o responsável principal por realizar essas atividades  A principal saída da atividade de planejamento de testes é o  Plano de Testes http://www.alvarofpinheiro.eti.br
  • 94. TESTES DE SOFTWARE PROJETO http://www.alvarofpinheiro.eti.br
  • 95. Projeto de Teste Entradas e Saídas Planejamento de Testes Plano de Projeto Cronograma do Projeto Informações sobre o sistema Plano de teste http://www.alvarofpinheiro.eti.br
  • 96. Projeto de Teste Atividades do Projeto de Teste Análise dos requisitos Especificação dos casos de teste Seleção de casos de teste http://www.alvarofpinheiro.eti.br
  • 97. Projeto de Teste Entradas e Saídas Projeto de Teste Plano de Teste Documento de requisitos Base de teste (plano de negócio, documento de marketing, plano de projeto, etc) Casos de teste http://www.alvarofpinheiro.eti.br
  • 98. TESTES DE SOFTWARE ABORDAGENS http://www.alvarofpinheiro.eti.br
  • 99. Abordagem de Teste  Existem 2 abordagens principais na execução de testes  Caixa Preta  Caixa Branca  Testes caixa preta são aqueles nos quais o testador não vê o “interior” do objeto que está sendo testado  Usualmente executados por um testador que é diferente do desenvolvedor  Avalia todas as diferentes entradas e suas respectivas saídas para garantir que o software se comporta como especificado  Associado a estágios de teste como sistema ou componente http://www.alvarofpinheiro.eti.br
  • 100. Abordagem de Teste  Testes caixa branca são aqueles nos quais o testador sabe como funciona o “interior” do objeto sendo testado  Usualmente são executados pelo próprio desenvolvedor  São fortemente associados aos testes unitários  Avalia TODOS os caminhos lógicos do código para garantir que TODOS os fluxos são executados corretamente  Busca encontrar bugs, mas bugs no código e não bugs na especificação, por exemplo  A grande maioria dos software realiza apenas testes caixa preta  Quando testes caixa branca são executados, eles não são formalizados  Não existe procedimento bem definido  Não existe resultado de testes documentado  Caso um procedimento de testes caixa branca seja escrito, existe grande chance dele ser descartado após a execução dos testes http://www.alvarofpinheiro.eti.br
  • 101. Testes Positivos e Testes Negativos  Testes positivos verificam se o caminho feliz é executado corretamente  Testes negativos verificam as exceções  Testes positivos  Garantem que o software funciona minimamente como esperado  Garantem que o software não quebra para as suas operações principais  Não levam o software aos seus limites para identificar possíveis falhas  Testes negativos  Buscam realmente quebrar o software  Focam em identificar problemas  Garantem que o software funciona em diversas situações diferentes  Ambos os tipos de testes devem ser realizados http://www.alvarofpinheiro.eti.br
  • 102. TESTES DE SOFTWARE TÉCNICAS http://www.alvarofpinheiro.eti.br
  • 103. Técnicas de Teste –Análise de requisitos  Análise de requisitos  Começar a pensar na matriz de rastreabildiade:  Identificar quais testes serão impactados quando determinado requisito for modificado  Saber se existem teste para cada requisito  Avaliar grau de cobertura http://www.alvarofpinheiro.eti.br
  • 104. Técnicas de Teste – Seleção de casos de teste Técnicas de Teste  Baseada na especificação (caixa-preta)  Baseada na estrutura (caixa-branca)  Baseada na experiência http://www.alvarofpinheiro.eti.br
  • 105. Técnicas de Teste – Seleção de casos de teste  Técnicas de Teste  Baseada na especificação (caixa-preta) 1. Partição por equivalência 2. Análise de valores limites 3. Tabelas de decisão / Tabela Causa-Efeito 4. Testes derivados de casos de uso  Baseada na estrutura (caixa-branca)  Baseada na experiência http://www.alvarofpinheiro.eti.br
  • 106. Técnicas de Teste – Seleção de casos de teste  Técnicas de Teste  Baseada na especificação (caixa-preta)  Baseada na estrutura (caixa-branca)  Cobertura e Teste baseado em instruções  Cobertura e Teste baseado em laços de decisões  Baseada na experiência http://www.alvarofpinheiro.eti.br
  • 107. Técnicas de Teste – Seleção de casos de teste  Técnicas de Teste  Baseada na especificação (caixa-preta)  Baseada na estrutura (caixa-branca)  Baseada na experiência  Error guessing  Testes Exploratórios http://www.alvarofpinheiro.eti.br
  • 108. Técnicas de Teste – Testes vs. Inspeções  Inspeções dos artefatos buscam validar os artefatos antes que a próxima fase do desenvolvimento seja iniciada  Vários estudos indicam que o custo de encontrar um erro com inspeção é menor que o custo de encontrar com testes [Kaplan 1995]  3,5 horas de esforço para encontrar um erro com inspeção  15-25 horas de esforço para encontrar um erro com testes  Isso não significa que testes não são necessários  Mas que outras técnicas também podem ser aplicadas http://www.alvarofpinheiro.eti.br
  • 109. Técnicas de Teste – Encontrar Bugs  Inspeção de Software  Processo formal de verificação do software  Pode ser aplicado para praticamente todos os artefatos gerados durante o ciclo de desenvolvimento  Tem o custo mais alto de aplicar, mas também é o que produz o melhor resultado  Combinação de inspeções na especificação, design e código podem encontrar até 85% dos bugs de um software  Como o processo é formal, ele é fácil de mensurar e de acompanhar  Prototipação  Ajuda no levantamento e definição dos requisitos  Dá uma boa visão para o cliente do que vai ser o software final  Reduz bastante as duvidas de usabilidade e de como as funções devem ser implementadas http://www.alvarofpinheiro.eti.br
  • 110. Técnicas de Teste – Encontrar Bugs  Programação por pares  Técnica definida em XP (Extreme Programming)  2 desenvolvedores por computador  1 programador digita  1 programador procura por erros  Possui várias vantagens  Facilita mentoring de novos desenvolvedores  Dissemina a cultura da empresa  Pode chegar a encontrar a mesma quantidade de problemas da inspeção  É mais aplicável para a fase de codificação  Walkthroughs e Code Reading  Similar a inspeção, mas sem o formalismo de um processo http://www.alvarofpinheiro.eti.br
  • 111. TESTES DE SOFTWARE ESTÁGIOS http://www.alvarofpinheiro.eti.br
  • 112. Unidade, Componente e Integração  Um software em geral é quebrado em diferentes componentes (ou módulos principais)  Cada componente é quebrado em unidades (sub-componentes)  Estes unidades precisam ser integradas em componentes  Os componentes precisam ser integrados no software como um todo http://www.alvarofpinheiro.eti.br
  • 113. Unidade, Componente e Integração  Testes precisam ser executados  Na unidade para garantir que esta funciona separadamente  No componente para garantir que quando as unidades foram integradas, eles continuam funcionando  No sistema como um todo para garantir que os componentes integrados funcionam corretamente  O escopo de cada um desses testes é bem diferente  Todos buscam encontrar bugs  Mas tipos diferentes de busca usualmente são encontrados  Um teste não substitui o outro http://www.alvarofpinheiro.eti.br
  • 114. Estágios de Teste  O termos “Estágio de Teste” é usualmente aplicado ao teste que está associado a uma determinada fase do ciclo de desenvolvimento  Relembrado o Modelo V, tem-se:  Testes Unitários  Testes de Componente  Testes de Integração  Testes de Sistema  Testes de Aceitação http://www.alvarofpinheiro.eti.br
  • 115. Estágios de Teste  Testes Unitários  Executados pelo desenvolvedor para validar a unidade que está sendo implementada  Testes de Componente  Executado pelo testador para validar um componente específico do software  Testes de Integração  Executado pelo testador para garantir que vários componentes funcionam corretamente juntos  Testes de Sistema  Executados pelo testador para garantir que as funcionalidades do software estão de acordo com a especificação  Testes de Aceitação  Executados pelo usuário para garantir que o software faz o que foi inicialmente requisitos pelo usuário  Cada um destes estágios será melhor detalhado posteriormente http://www.alvarofpinheiro.eti.br
  • 116. Estágios e Tipos de Testes  Anteriormente foi listado brevemente alguns estágios e diferentes tipos de testes  Os seguintes estágios e tipos serão abordados  Estágios  Testes Unitários  Testes de Componente  Testes de Sistema  Testes de Aceitação  Tipos de Teste  Testes de Carga  Testes de Performance  Testes de Uso de Memória  Testes de Usabilidade  Teste de Configuração  Testes de Compatibilidade  Testes de Documentação http://www.alvarofpinheiro.eti.br
  • 117. Estágios – Testes Unitários  Testes unitários são testes isolados executados sobre uma rotina, classe ou pequena arte do programa  Esses testes são executados pelo próprio desenvolvedor para garantir que a sua unidade pode ser integrada com o resto do software  Dois aspectos fundamentais  Os testes são isolados  Os testes são implementados e executados pelo próprio desenvolvedor  Testes isolados  Stubs devem ser implementados para suprir alguma parte da funcionalidade ou gerar valores errados para validar a unidade  Os componentes externos a unidade em testes devem ser simuladas  Testes executados pelo desenvolvedor  Os testes são normalmente rodados no ambiente de desenvolvimento  Os casos de testes focam apenas na unidade em testes sem se preocupar com a interação com outras unidades http://www.alvarofpinheiro.eti.br
  • 118. Estágios – Testes Unitários  Testes unitários podem ter a abordagem caixa branca ou caixa preta  Testes caixa branca são bem importantes pois ajudam a validar todos os fluxos de execução  A formalização de casos de testes unitário  É feita em algumas organizações  Principal dificuldade é dá manutenção nos casos de testes  Na maioria das vezes os casos de teste são jogados fora após os testes (especialmente os caixa branca)  O resultado do testes unitários algumas vezes também é formalizado  Mas a sua análise não tem tanto sentido em algumas situações http://www.alvarofpinheiro.eti.br
  • 119. Estágios – Testes Unitários  Automação de testes unitários  É uma das principais formas de garantir que os casos de teste não sejam “jogados fora”  Existem várias ferramentas que focam na automação dos casos de testes  Gerar / implementar os scripts de testes  Executar os scripts de testes  Coletar os resultados da execução  Estas ferramentas rodam os testes sem intervenção do desenvolvedor  Principal vantagem  Facilita a manutenção dos testes  Os Testes podem ser rodados automaticamente para garantir que as unidades não quebraram  Principal problema  O custo de especificar e implementar os scripts é alto  É necessário avaliar o custo / benefício para cada software (ou para cada parte do software) http://www.alvarofpinheiro.eti.br
  • 120. Estágios – Testes Unitários  Processo de desenvolvimento orientado a testes unitários  Atualmente existem processos de desenvolvimento orientados a testes unitários  TDD (Test Driven Development)  O princípio fundamental é  Desenvolver o teste antes do código  Principal vantagem  Casos de teste estão sempre atualizados  O código é feito para passar nos testes  O requisito é bem entendido antes de iniciar a implementação  Os testes são pensados com muito cuidado  Novos casos de testes podem ser facilmente adicionados  Principal desvantagem  Custo do desenvolvimento dos testes  É necessário avaliar beneficio de acordo com o projeto  A equipe precisa ter maturidade para entender a importância dos testes e saber implementar os casos de teste http://www.alvarofpinheiro.eti.br
  • 121. Estágios – Testes Unitários  Passos para identificar casos de testes unitário caixa preta  Avaliar a interface da rotina a testas  Avaliar os parâmetros e seus possíveis valores  Avaliar TODOS os possíveis retornos de acordo com cada possível combinação de parâmetros  Encontrar os limites dos parâmetros que vão fazer com que o retorno mude  Avaliar todos os possíveis erros que podem ser gerados  Encontrar as combinações de parâmetros que devem gerar erro  Passos para identificar casos de testes unitários caixa branca  Avaliar todos os fluxos de execução da rotina  Avaliar as funções que são usadas internamente e seus retornos  Avaliar como vai se comportar a rotina caso as funções internas retornem valores diferentes do esperado  Avaliar se todos os possíveis fluxos de execução são tratados  Avaliar se todos os fluxos codificados realmente podem ser atingidos http://www.alvarofpinheiro.eti.br
  • 122. Estágios – Testes Unitários: Exemplo  Considerando o código abaixo /** * Retorna a lista de contas bancarias de uma determinada pessoa * @param id identificar de uma pessoa */ Vector getContas (IDPessoa id) { Vector resultado = new Vector (); for (int i = 0; i < contas.size(); i++) { Conta c = contas.elementAt(i); if (c.getIDPessoal().equals (id)) { resultado.addElement(c); } } return resultado; } Os seguintes casos de teste unitários caixa preta podem ser identificados:  Passar como parâmetro um ID de pessoa nulo  Passar como parâmetro um ID de pessoa inválido  Passar como parâmetro um ID de pessoa que tem apenas uma conta  Passar como parâmetro um ID de pessoa que não tem conta http://www.alvarofpinheiro.eti.br
  • 123. Estágios – Testes de Componente  Muito parecidos com os testes unitários. Definição quase igual:  Esses testes são executados pelo próprio desenvolvedor para garantir que a sua unidade pode ser integrada com o resto do software  A principal diferença é que  Testes de componente devem ser implementados por uma equipe diferente da equipe de desenvolvimento  A equipe de desenvolvimento executa os testes de componente, mas uma equipe externa também pode executá-los  Testes de componente são aplicáveis quando o software é grande em vários componentes que interagem entre si  Os componentes  São compostos por diferentes unidades internas  Tem uma interface bem definida que é utilizado por outros componentes  Usam serviços providos por componentes externos http://www.alvarofpinheiro.eti.br
  • 124. Estágios – Testes de Componente  A equipe de testes separada pode  Estudar a especificação do componente  Desenvolver um conjunto de testes para o componente (que podem ser ou não automatizados)  Executar esses testes para cada versão do componente que for fechada  Os testes de componente garantem que  Cada componente está funcionando conforme a sua especificação individualmente  Com isso os componentes podem ser integrados e o software completo pode ser testado http://www.alvarofpinheiro.eti.br
  • 125. Estágios – Testes de Componente  A principal vantagem de se usar testes de componentes é  Uma equipe diferente da desenvolvimento vai pensar nos casos de teste  Isso garante uma melhor qualidade e cobertura dos testes (como foi visto anteriormente)  A principal desvantagem  É necessário definir claramente os componentes do software  O desenvolvimento também precisa ser “quebrado” em componentes  Isso pode não ser simples de fazer em alguns projetos  Quando testes de componente são realizados, usualmente é definido um estágio chamado de Testes de Integração  Todas as unidades são integradas e os problema de integração são resolvidos antes do teste de sistemas  Os testes de integração podem ser bem complexos de executar, casos o software seja muito grande http://www.alvarofpinheiro.eti.br
  • 126. Estágios – Testes de Componente: Exemplo  Considerando uma interface de um componente HTTP que recebe parâmetros via HTTP GET /** * HTTP GET htp://servername/getConta?pessoaID=<idNumber> * Retorna: idConta1;idConta2;idConta3;..;idContaN */ Os seguintes casos de teste podem ser identificados:  Tentar ter acesso a uma página diferente do servidor (getPessoa)  Tentar ter acesso a página getConta, mas sem nenhum parâmetro  Tentar ter acesso a página getConta, mas com um parâmetro diferente de pessoaID  Tentar ter acesso a página getConta, mas com mais de um parâmetro  Tentar ter acesso a página getConta com o parâmetro pessoaID como segundo parâmetro  Tentar passar o parâmetro via HTTP POST http://www.alvarofpinheiro.eti.br
  • 127. Estágios – Testes de Sistema  Valida a funcionalidade principal do software  Tem como objetivo garantir que o software está implementando corretamente o que foi especificado  É direcionado então para especificação do software  Os casos de teste são definidos, especificados e executados por uma equipe de testes separada  Esta é equipe pode até ser uma organização separada da organização que faz o desenvolvimento  Aspectos subjetivos do software também devem ser avaliados  Qualidade geral da UI do software  Facilidade de uso do software  Performance do software  Facilidade instalação  Clareza das mensagens  etc http://www.alvarofpinheiro.eti.br
  • 128. Estágios – Testes de Sistema: Exemplo  Considerando o seguinte caso de uso UC001: Listar contas Precondição: usuário logado no sistema no menu principal Fluxo Principal: 1. O usuário seleciona a opção listar contar. O sistema apresenta uma lista de pessoas (pode executar fluxo alternativo 2 ou 3) 2. O usuário seleciona uma pessoa específica. O sistema retorna um formulário com a lista de contas dessa pessoa (pode executar fluxo alternativo 1) Fluxo alternativo 1. A pessoa não tem contas: uma mensagem é apresentando indicando que a pessoa selecionada não tem contas 2. O usuário não tem permissão de acesso: uma mensagem de erro é apresentada indicando que o usuário não tem permissão 3. Nenhuma pessoa cadastrada no sistemas: a lista é apresentada vazia Os seguintes casos de teste podem ser identificados:  Listar as contas de uma pessoa que não tem contas  Listar as contas de uma pessoa que tem várias contas  Entrar com um usuário que não tem permissão de listar pessoas e tentar listar pessoas  Entrar no sistema sem nenhuma pessoa cadastrada  Listar contas de uma pessoa e em seguida listar de outras pessoas http://www.alvarofpinheiro.eti.br
  • 129. Estágios – Testes de Aceitação  São os testes realizados pelo usuário que contratou o desenvolvimento do sistema  Valida que a necessidade inicial do cliente quando o desenvolvimento do software foi contratada foi atendida  Foco não é na especificação, mas na necessidade do cliente  Por mais que especificações sejam escritas e aprovadas pelo cliente  É comum que alguma necessidade não seja totalmente atendida  Algumas vezes a necessidade original foi implementada de outra forma  Outros problemas como  Usabilidade, performance ou estabilidade do software também podem ser identificados  A organização que desenvolveu o software não tem muito controle sobre a aceitação  Um processo de aceitação pode ser definido, mas o cliente também pode ter seu processo interno http://www.alvarofpinheiro.eti.br
  • 130. Estágios – Testes de Aceitação: Exemplo  Considerando o caso de uso de listar contas de uma pessoa  A necessidade do cliente é:  Ter um cadastro de pessoas  Ter um cadastro das contas de cada pessoa  Poder visualizar em uma mesma tela as pessoas e suas respectivas contas  Os seguintes casos de teste podem ser identificados:  Entrar no sistema e verificar se a tela de lista de pessoas apresenta todas as pessoas cadastradas  Verificar se é possível selecionar uma pessoa e ver suas contas na mesma tela  Verificar se todas as contas de uma determinada pessoa realmente são apresentadas http://www.alvarofpinheiro.eti.br
  • 131. Sequência de Estágios de Testes Unitário Componente Integração Sistema Aceitação Desenvolvedores Engenheiro de Testes Cliente ou Usuário http://www.alvarofpinheiro.eti.br
  • 132. Seqüência de Estágios de Testes  Vantagens de quebrar os testes em diferentes estágios  Cada estágio foca em problemas diferentes  Os testes estruturais garantem a estabilidade do software, antes de se buscar encontrar problemas comportamentais  Os testes comportamentais são rodados em um software estável  É mais fácil de fazer o acompanhamento do projeto  Cada estágio deve ser iniciado o mais cedo possível  Bugs devem ser encontrados o quanto antes  O momento de iniciar cada estágio deve ser determinado no plano de testes O plano de testes deve focar em quais estágios de teste? Testes de aceitação fazem parte do planejamento de testes? http://www.alvarofpinheiro.eti.br
  • 133. TESTES DE SOFTWARE TIPOS http://www.alvarofpinheiro.eti.br
  • 134. Tipos de Testes: Unitários É o processo de verificação de que o código faz o que a especificações diz que ele deve fazer. Seu propósito é verificar se toda lógica necessária está presente e que funciona adequadamente de maneira automática. Testes unitários é uma atividade tipicamente realizada por desenvolvedores. É de sua responsabilidade provar que o software produzido faz exatamente o que se supõe que ele deve fazer e que não há nenhuma funcionalidade faltando. Testes de unitários são escritos a partir da perspectiva do programador. Eles asseguram que um determinado método de uma classe realiza com êxito a um conjunto de tarefas específicas. Cada teste confirma que o método produz os resultados esperados, quando recebe uma entrada conhecida. http://www.alvarofpinheiro.eti.br
  • 135. Tipos de Testes: Funcionais Servem para dizer que o código deve fazer as coisas certas. São escritos a partir da perspectiva do usuário. Estes testes confirmam que o sistema deve fazer o que os usuários estão à espera que faça. Muitas vezes o desenvolvimento de um sistema computacional é relacionado à construção de uma casa. Embora esta analogia não seja completamente apropriada, dado as especificidades de cada projeto. Este modelo pode ser estendido e utilizado na compreensão das diferenças entre testes de unidade e testes funcionais. Teste de unidade se assemelha a um inspetor de obras visitando uma casa em construção. Ele está focado nos diversos sistemas internos da casa, a fundação, o sistema hidráulico, rede elétrica, canalização, e assim por diante. Por outro lado, testes funcionais neste cenário são análogos a visitação do dono da casa a esta mesma construção. Ele assume que os sistemas internos irão comportar-se adequadamente, já que o inspetor de construção realizou bem sua tarefa. http://www.alvarofpinheiro.eti.br
  • 136. Tipos de Testes: TestDriver e Stub de Testes  Um test driver é um componente de software que simula as entradas reais do software  Por exemplo, um software de calculadora recebe números e operações  Um test driver para este software pode entrar um grande combinação diferente de números e combinações para validar a calculadora http://www.alvarofpinheiro.eti.br
  • 137. Tipos de Testes: TestDriver e Stub de Testes  O stub de test é utilizado para testar o software de baixo para cima  O stub simula resultados que são retornados por um determinado componente que o software depende http://www.alvarofpinheiro.eti.br
  • 138. Tipos de Teste  Frequentemente confundidos com os estágios de teste  “Tipos de Testes” identificam os diferentes testes que podem ser realizados em cada um dos estágios  Cada tipo pode estar associado a um estágio específico, ou pode ser realizado a partir dos testes de componente  Tipos também estão associados com cada domínio de aplicação  No desenvolvimento de jogos são realidades testes de jogabilidade (só aplicável a jogo)  Em aplicações que usam banco de dados são realizados testes de volume de carga no banco  Alguns tipos de teste comuns  Testes de carga  Testes de configuração  Testes de compatibilidade  Testes de performance  Testes de documentação  Testes de internacionalização  Testes de usabilidade http://www.alvarofpinheiro.eti.br
  • 139. Tipos de Teste  Testes de carga  Foco em garantir um número específico de transações no banco de dados (alto volume de dados e alto número de transações)  É aplicável a partir dos testes de componente  Testes de configuração  Verifica se o software funciona com diferentes configurações de hardware e software  Está associado aos requisitos não-funcionais / restrições do software  Usualmente é aplicável a partir dos testes de integração  Testes de compatibilidade  Verifica se um determinado software está aderente a um padrão que ele deveria implementar  Usualmente é executado durante o teste de sistema http://www.alvarofpinheiro.eti.br
  • 140. Tipos de Teste  Testes de performance  Garantir que a velocidade de execução do sistema é adequada (tempo para carregar uma página web por exemplo)  Associado aos requisitos não funcionais  Pode ser executado a partir dos testes de integração  Testes de documentação  Garantir que a documentação do software está do acordo com o que foi realmente implementado  Tem mais sentido ser executado durante os testes de sistema  Testes de internacionalização  Garantir que o software funciona em diferentes línguas e com configurações dependentes de pais (meda, timezone, etc.)  Testes de usabilidade  Verifica se as funções do sistema realmente são “fáceis” de serem realizadas  Deve ser executado durante os testes de sistema http://www.alvarofpinheiro.eti.br
  • 141. Testes de Regressão  Considere o seguinte cenário  Durante a execução dos testes de sistema de um software encontra-se um erro após a execução de 70% dos testes  Este erro é corrigido e uma nova versão é gerada  Que testes devem ser executados após isso?  Os 30% restantes  E também pode-se regredir e executar todos os outros testes que já foram executados  A execução dos testes que já foram rodados é chamado de Testes de Regressão  Um testes de regressão completo significa que TODOS os testes serão rodados novamente http://www.alvarofpinheiro.eti.br
  • 142. Tipos – Testes de Carga  Associado principalmente a softwares que usam bancos de dados  É um tipo de testes  Caixa preta  Principal objetivo é verificar como o software se comporta com diferentes cargas de banco de dados  Precisa de diferentes scripts para popular o banco  Está associado aos requisitos, mas também ao modelo de dados do software  Algumas vezes a implementação assume alguns comportamentos do modelo de dados  Dados dependentes da implementação do código e vice-versa  Isso pode causar bugs na aplicação, pois os dados do banco deveria estar associados e serem dependentes apenas do modelo de dados  Esses testes podem ser automatizados, mas o ideal é que sejam manuais para identificar os comportamentos diferentes do software http://www.alvarofpinheiro.eti.br
  • 143. Tipos – Testes de Performance  Verificar a performance da aplicação em diferentes cenários  Esta diretamente associado aos requisitos não funcionais do software  Os requisitos devem especificar a performance esperada do software  Caso isso não seja feito pode gerar frustração durante a aceitação do software  A performance também está associada ao número de usuário utilizando o software  Em sistemas Web, a performance tem que ser garantida até um número X de usuários  Existem ferramentas que ajudam a implementar scripts para validar a performance  Simular vários usuários conectados a aplicação  Estes testes também estão associados ao ambiente de deploy do software  Este ambiente influencia diretamente no resultado dos testes http://www.alvarofpinheiro.eti.br
  • 144. Tipos – Testes de Performance: Exemplo  Considerando o caso de uso listar contas de uma pessoas  O software pode ter um requisito não funcional  Mostrar as contas de um pessoa específica em no máximo 5 segundos  Com uma base de até 10mil pessoas e 100mil contas  Com até 100 usuários logados simultaneamente  Os seguintes casos de teste podem ser identificados:  Montar uma base com este número de usuários e buscar listar as contas destes usuários repetidamente. Calcular a média de tempo para mostrar as contas http://www.alvarofpinheiro.eti.br
  • 145. Tipos – Testes de Uso de Memória  Pode estar associado a diferentes tipos de software  Alguns sistemas embarcados tem um milite de memória para uso  Caso se passe deste limite o software não pode ser executado ou o custo do hardware vai ser elevado  O uso da memória física do hardware precisa ser acompanhado nos projetos, caso este seja um recurso crítico  Avaliar periodicamente quanta memória o software está usando  Os procedimentos de testes de sistema podem ser utilizados  Verificar quanta memória o software está usando em cada caso de uso  Testes exploratórios também podem ser utilizados para verificar o uso de memória  Estes testes precisam ser realizados em alguns sistemas desde a fase de codificação e testes unitários  O uso de memória também pode estar associado a requisitos funcionais http://www.alvarofpinheiro.eti.br
  • 146. Tipos – Testes de Uso de Memória: Exemplo  Um sistema embarcado pode estar limitado ao uso de 4 MB de RAM  As placas com essa memória já foram encomendadas e estão na fábrica  É necessário implementar no código um controle que verifique quanto de memória RAM está sendo utilizada  Semanalmente deve se acompanhar  quando de memória usada vs. número de casos de uso implementados http://www.alvarofpinheiro.eti.br
  • 147. Tipos – Testes de Usabilidade  Que atributos definem uma boa interface com o usuário?  Grande investimento é feito pelas empresas para responder essa pergunta  Com os atributos definidos, a UI do software pode ser definida para atingi-los  Algumas características de um boa UI  Segue um padrão determinado  Flexível  Intuitiva  Consistente  Confortável  Útil http://www.alvarofpinheiro.eti.br
  • 148. Tipos – Testes de Usabilidade  Segue um padrão determinado  As empresas que fazem os sistemas operacionais definem padrões de UI para serem seguidos pelas aplicações  É importante identificar se estes estão ou não sendo seguidos  Flexível  Existem diferentes formas de executar a mesma função? Estas formas são claras para o usuário?  Intuitiva  A interface é “limpa”? As funções do software são obvias e fáceis de encontrar?  Consistente  Funções similares no software estão disponíveis da mesma forma?  Confortável  Mensagens de erro são mostradas no momento correto? A performance das operações é ideal?  Útil  As funções realmente estão funcionando e podem ser usadas? http://www.alvarofpinheiro.eti.br
  • 149. Tipos – Testes de Usabilidade  Mesma mensagem de erro apresentada de forma diferente  Cada indicação passa um “mensagem” diferente para o usuário  O teste de usabilidade precisa garantir a consistência entre as “mensagens” http://www.alvarofpinheiro.eti.br
  • 150. Tipos – Testes de Usabilidade  Um dos testes mais importantes realizados durante os testes de sistema  É um teste caixa preta que visa identificar se os casos de uso do software são “fáceis” de executar pelo usuário final  É realizado por um design de usabilidade  Foca na facilidade de uso (número de passos para executar uma função específica do software)  Identificar se as opções apresentadas para o usuário são claras de entender  Os casos de teste de usabilidade são extraídos da especificação e do modelo navegacional do software  Existem diferentes técnicas para realizar esses testes  Filmar usuários utilizado o software e avaliar o uso com psicólogos  Colocar o software em um ambiente real e deixar um observador tomando nota do uso do software  Etc. http://www.alvarofpinheiro.eti.br
  • 151. Tipos – Testes de Usabilidade: Exemplo  Considerando o caso de uso lista contas  O usuário pode esperar que as contas de uma determinada pessoa sejam listadas  Com no máximo 1 clique  Na mesma tela que todas as pessoas  Sejam apresentadas em uma lista com rolagem  Um possível caso de teste deve verificar se essas condições são atendidas no software  Em relação ao número de cliques, pode-se filmar vários usuários diferentes para verificar se eles conseguem realizar a operação com apenas 1 clique  Algumas vezes existe a opção de fazer com 1 clique, mas isso não é claro para o usuário final http://www.alvarofpinheiro.eti.br
  • 152. Tipos – Teste de Configuração  Atualmente existem diferentes plataformas de hardware e software nas quais um determinado software pode executar  Além disso, o software desenvolvido também possui diferentes configurações internas  Resumindo, os testes de configuração buscam  Identificar o comportamento do software em diferentes configurações de hardware  Identificar o comportamento do software em diferentes configurações de software  Identificar o comportamento do software em diferentes configurações internas do software  As possíveis plataformas de hardware e software nas quais o software deve funcionar  DEVEM ser mapeadas durante a especificação do software  DEVEM ser aprovadas pelo cliente  Partindo destas especificações os casos de teste precisam ser levantados http://www.alvarofpinheiro.eti.br
  • 153. Tipos – Teste de Configuração  Os resultados desses testes devem ser acompanhados periodicamente  Estes testes precisam ser executados o mais cedo possível  Especialmente se alguma das restrições fora essencial (ex. o software precisa rodar com um monitor preto e branco)  O planejamento dos testes precisa  Incluir as diferentes configurações de hardware e software com ambiente para execução dos testes  Planejar em que momento estes testes devem ser realizados http://www.alvarofpinheiro.eti.br
  • 154. Tipos – Teste de Configuração: Exemplo  O software pode ter como restrição utilizar banco de dados Oracle ou Posgresql  O caso de teste então deve  Configurar 2 ambientes de testes: 1 com cada banco de dados  Executar as funcionalidades básicas do software em ambos os ambientes  Caso alguma não funciona corretamente, o teste é falho  Em algumas situações TODOS os testes precisarão ser executados em ambos os ambientes http://www.alvarofpinheiro.eti.br
  • 155. Tipos – Testes de Compatibilidade  Como garantir que um editor de testes realmente consegue abrir um documento do padrão MS Word?  Como garantir de controle bancário exporta suas contas corretamente para uma planilha excel?  Como garantir que um software bancário consegue se comunicar com um servidor padrão do banco central?  Estes problemas são testados através de um teste de compatibilidade http://www.alvarofpinheiro.eti.br
  • 156. Tipos – Testes de Compatibilidade  É aplicável para software que  Implementam algum padrão específico e que precisam estar compatíveis com este  Interagem com alguma aplicação que em a sua interface padronizada  No primeiro caso, o software precisa ser valido quando ao padrão  Usualmente os organismos de padronização definem conjuntos de testes que validam as implementações  A execução destes testes precisam então ser planejadas para validar a implementação do software  No segundo caso, o software precisa  Garantir que está usando a interface padronizada corretamente (por exemplo, usar um porta USB)  Testes precisam ser especificados para as diferentes opções definidas no padrão http://www.alvarofpinheiro.eti.br
  • 157. Tipos – Testes de Compatibilidade: Exemplo  O software de controle de contas pode ter como requisito não funcional suportar um formato binário padrão para contas  A organização que definiu o padrão binário para um arquivo de várias contas possui um conjunto de testes que valida o suporte ao formato  Um caso de teste então é  Executar o conjunto de testes no software em um caso de uso de importar contas  Para todos as diferentes entradas, o software deve se comportar corretamente http://www.alvarofpinheiro.eti.br
  • 158. Tipos – Testes de Documentação  Diferentes documentações podem ser geradas para o software  Documentação para o usuário (help)  EULA  Garantia  Marketing  É fundamental verificar se estas documentações estão corretas e de acordo com o esperado  Requisitos podem e devem ser definidos para a documentação  Quem vai prover o texto do help? Em que língua? Se for escrito pela equipe, quem vai revisá-lo?  Quem vai fornecer o EULA? Quando ele será incluído no software  Casos de testes podem e DEVEM ser definidos para validar esses pontos  Verificar a consistência do help  Verificar de o material de marketing está consistente http://www.alvarofpinheiro.eti.br
  • 159. Tipos – Testes de Documentação  Frequentemente os casos de teste de documentação são esquecidos  Como não é código a sua importância é minimizada  Dependências de documentação também são esquecidas  Quando o texto do EULA vai ser entregue?  Quem vai revisá-lo?  Mudanças de última hora são freqüentes  Erros encontrados de última hora também são muito freqüentes  Especialmente no help  Erros de documentação podem  Gerar processos contra a empresa que fez o software  Dá uma idéia de baixa qualidade do produto http://www.alvarofpinheiro.eti.br
  • 160. TESTES DE SOFTWARE AUTOMAÇÃO http://www.alvarofpinheiro.eti.br
  • 161. Testes: Automação Software que automatiza qualquer aspecto da verificação de um sistema de aplicações. É possível incluir ainda nesta definição a capacidade de gerar entradas e resultados esperados dos testes, a execução das suítes de testes sem a intervenção manual e finalmente a avaliação se o teste passou ou não. Lista de situações onde é indicativo o teste automático: Quando há uma grande quantidade de testes; Suporte a várias GUIs, redes, sistemas operacionais ou banco; Testes de performance; Quando é necessário repetir uma complexa lista de ações; e Avaliar uma grande quantidade de saída repetidamente. http://www.alvarofpinheiro.eti.br
  • 162. Testes: Manuais Quando os testes automáticos não são indicados: Quando não se tem muito tempo; Testadores necessitam ter ideia do comportamento da aplicação; Situações que se necessita de criatividade; Em relação a diminuição dos cursos; Testar novos componentes. http://www.alvarofpinheiro.eti.br
  • 163. Automação  Como escrever testes funcionais automáticos eficientemente  existem algumas orientações para decidir se o determinado teste de unidade que está sendo escrito é na verdade um teste funcional: 1. Se o de teste de unidade atravessa classe de fronteiras, ele pode ser um teste funcional. 2. Se o de teste de unidade ficar muito complexo, ele pode ser um teste funcional. 3. Se o de teste de unidade é frágil (ou seja, é um teste válido, mas é necessário atualizá-lo continuamente para lidar com diferentes mudanças do usuário), ele pode ser um teste funcional. 4. Se o de teste de unidade é mais difícil de escrever do que o código que deverá ser testado, ele pode ser um teste funcional.  Existe uma sintonia entre o teste unitários e os testes funcionais, e decidir onde está a linha de separação entre um e outro depende de caso a caso.  Quanto mais confortável se estiver com os testes unitários, mais claro será perceber quando um determinado teste está cruzando a linha de unidade para funcional. slide 163 de 99 http://www.alvarofpinheiro.eti.br