Aula 1 Teste de Software

Prévia do material em texto

1 
Testes de Software 
2 
Importância do teste de software 
André Luís Belmiro 
 
 
 
 
 
 
A Disciplina 
3 
Qual a expectativa dos alunos? 
O que vocês esperam aprender na disciplina? 
 
 
“O objetivo do Teste de Software é encontrar bugs 
o mais cedo possível e garantir que eles sejam 
corrigidos” 
 
 
Introdução 
 
 
“A atividade de teste é o processo de executar um 
programa com a intenção de descobrir um erro.” 
 Pressman 
 
 
Introdução 
 
“Os testes são destinados a mostrar o que um 
programa faz, o que pretende fazer e para 
descobrir os defeitos do programa antes desse 
ser colocado em uso” 
 Sommerville 
 
 
 
Introdução 
• Mas o que é um bug? 
– Várias definições: Um bug é um defeito, falta, problema, 
incidente, anomalia, etc. 
 
Introdução 
7 
• Mas o que é um bug? 
– Um bug ocorre quando uma ou mais das opções abaixo for 
verdadeira: 
 
Introdução 
8 
 
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 
 
 
Bugs clássicos 
 
 
Apagão de U$ 6 bilhões 
Em 2003, os EUA enfrentaram um super apagão no nordeste do país. O incidente foi causado por uma falha no 
sistema de alarme. Incrível, mas foi o suficiente para deixar 50 milhões de pessoas sem energia e provocar 11 
mortes. O prejuízo chegou a US$6 bilhões para o governo americano. 
 
 
 
 Recall da Honda 
 
Por causa de um defeito de programação no sistema dos carros, a Honda teve que realizar um recall de mais de 2 
milhões de automóveis. O fato, ocorrido em 2011, custou alguns milhões de dólares à empresa japonesa. O 
airbag era ativado com muita força e pelo componente errado. 
 
 
 
Google como malware 
 
Em 2009, uma barra invertida adicionada por um programador às URLs que eram direcionadas para o buscador do 
Google provocou a identificação do site como sendo um malware no mundo inteiro por cerca de 1 hora. Prejuízo 
de quase US$ 3 milhões. 
 
 
Bugs clássicos 
 
 
Trânsito ruim 
 
A justiça da Califórnia convocou 1,2 mil pessoas para trabalharem como júri no mesmo horário e no mesmo dia. O 
incidente ocorrido em 2012 foi fruto de uma falha no sistema da justiça da Califórnia. O trânsito nas estradas 
que davam acesso à região do júri ficou engarrafado e provocou a ira de muitos motoristas. 
 
 
 
Promoção da Pepsi 
 
A promoção da Pepsi em 1992 era a seguinte : quem tirasse a tampinha com o número 349 impresso, ganharia uma 
premiação em dinheiro. Um problema no sistema das máquinas de impressão resultou na distribuição de 800 
mil tampinhas com a numeração premiada nas Filipinas. Na época, a empresa não entregou os prêmios, o que 
provocou bastante revolta. 
 
 
 
Epidemia no World of Warcraft 
 
Há quase 10 anos , os desenvolvedores do game World of Warcraft espalharam um vírus dentro do jogo, chamado de 
“Corrupted Blodd”. A doença “de brincadeira” se espalhou no jogo de maneira incontrolada e imprevista, o que 
provocou a morte de vários personagens no mundo inteiro. Os jogadores ficaram muito irritados com o jogo. 
 
 
Bugs clássicos 
 
 
Mortos vivos 
Um hospital dos EUA, chamado St. Mary’s Mercy, apresentou erros no sistema e declarou a morte de 8,5 mil 
pacientes em 2002. O sistema disparou o envio de contas com o atestado de óbito para os parentes e 
notificações para o governo e empresas. 
 
 
 
 
Radiação excessiva 
 
Entre os anos de 1985 e 1987, os hospitais dos EUA utilizavam um aparelho chamado Therac-25 para o tratamento 
com radiação contra o câncer. Havia um erro de programação no software que aplicava uma radiação 100 vezes 
maior do que a recomendada nos pacientes. Foram registradas 6 mortes nesse período. 
 
 
 
 
Quase faliu 
 
A KCG (Knight Capital Group) trabalha há anos com investimentos. Em 2012, quase foi à falência devido a uma falha 
em um novo software que a empresa comprou. O Software gerou milhares de negociações que não poderiam ser 
feitas. Em meia hora, a KCG perdeu US$440 milhões e ficou em situação crítica. 
 
 
 Fonte: http://crowdtest.me/10-falhas-software-marcaram-historia/ 
• Falando em processo de desenvolvimento... 
 
 
Introdução 
12 
Levantamento 
de Requisitos 
Análise Projeto 
Implementação Testes Manutenção 
• Como garantir que o software está de acordo com as 
especificações e atende às expectativas do cliente? 
– Através dos processos de Verificação e Validação (V & V); 
– Testes de software é uma das técnicas de V&V. 
 
 
Motivação 
13 
• Denominação dada aos processos que certificam se o 
software atende à especificação e à expectativas dos 
clientes/usuários. 
 
• Inicia com as revisões de requisitos, passa pelas 
revisões de projeto e inspeções de código até os 
testes do produto. 
 
Verificação e Validação 
14 
• Verificação ≠ Validação 
– Verificação: 
• Estamos construindo o produto correto? 
• Objetiva verificar se o software está de acordo com as 
especificações, ou seja, se atende aos requisitos 
funcionais e não-funcionais especificados. 
 
– Validação: 
• Estamos construindo o produto corretamente? 
• Objetiva assegurar que o software atenda às 
expectativas do cliente. Vai além da verificação de 
conformidade com a especificação. 
 
Verificação e Validação 
15 
• Objetivos principais: 
– Descobrir defeitos em um sistema; 
– Avaliar se o sistema é útil e usável ou não em uma situação 
operacional. 
 
• Isto NÃO significa dizer que o software está 
completamente livre de defeitos. 
 
Verificação e Validação 
16 
• As técnicas de verificação e validação podem ser 
estáticas ou dinâmicas. 
• Estáticas 
– Não é preciso executar o software em um computador. 
– Exemplos: 
• Inspeção de software; 
• Revisão por pares. 
– Analisam e verificam modelos do sistema como 
documento de requisitos, diagramas de análise e projeto, 
código-fonte do programa. 
 
Verificação e Validação 
17 
• As técnicas de verificação e validação podem ser 
estáticas ou dinâmicas. 
• Dinâmicas 
– É preciso executar o software com dados de teste. 
– Exemplo: 
• Testes. 
– Compreende examinar as saídas do software e o seu 
comportamento operacional. 
 
Verificação e Validação 
18 
• Inspeção de software e testes são complementares. 
 
Verificação e Validação 
19 
• Inspeção de software 
– Processo de V & V estático; 
– Em geral, focaliza-se no código fonte, mas qualquer 
representação legível do software pode ser inspecionado 
• Exemplos: requisitos, modelos de projeto. 
– São frequentemente guiadas por checklists de erros e/ou 
heurísticas; 
 
– Para alguns erros e heurísticas é possível automatizar o 
processo de inspeção... 
 
Verificação e Validação 
20 
• O que é teste de software? 
– Técnica dinâmica de verificação e validação (V & V); 
– Compreende a execução de uma implementação do 
software com dados de teste; 
– Objetivo de verificar se as saídas e o comportamento 
operacional está conforme o especificado e necessário;– Considerada como a técnica principal de V & V. 
 
Verificação e Validação 
21 
• Meta dos Testes de Software 
– Convencer desenvolvedores e clientes do sistema que 
o software é bom o suficiente para entrar em 
operação. 
– Pode revelar a presença de defeitos, NÃO a ausência. 
 
Verificação e Validação 
22 
• Técnicas de Teste - Dois tipos: 
– Teste Caixa Preta (black box) 
• Também chamado de teste funcional; 
• Teste executado nas interfaces do 
software/componente; 
• Teste executado sem o conhecimento interno “da 
caixa”; 
– Sem conhecimento da estrutura lógica interna. 
• Testa que o software é operacional: 
– entradas são adequadamente aceitas e saídas são 
corretamente produzidas. 
 
Verificação e Validação 
23 
• Técnicas de Teste - Dois tipos: 
– Teste Caixa Branca (white box) 
• Também chamado de teste estrutural; 
• Teste executado com o conhecimento interno “da 
caixa”; 
– Com conhecimento dos detalhes procedimentais, caminhos 
lógicos, condições, laços. 
 
Verificação e Validação 
24 
25 
Plano de Ensino 
Plano de Ensino 
26 
OBJETIVOS GERAIS: 
 
Conhecer as técnicas de teste de software para aplicação no ambiente de 
desenvolvimento e produção de sistemas. 
Plano de Ensino 
27 
OBJETIVOS ESPECÍFICOS: 
 
1. Identificar necessidade de uso de teste de software nas diversas fases de 
vida e de construção do software. 
2. Selecionar os testes adequados para cada situação 
3. Criar e escolher estratégias de teste de software 
4. Aplicar e analisar teste de software. 
 
 
 
Plano de Ensino 
Unidade I – Importância do teste de software 
O teste nas fases de vida e de desenvolvimento de um software. 
O teste na engenharia de sistemas e na engenharia de programas 
 
 
 
Plano de Ensino 
Unidade II – Teste no projeto de sistema 
Revisões Técnicas Formais 
Validação pelo usuário 
 
 
 
Plano de Ensino 
Unidade III – Teste no programa 
Depuração 
Teste de caixa branca 
Teste de caixa preta 
Teste de ambiente Web 
 
 
 
Plano de Ensino 
Unidade IV – Teste na implantação do sistema 
Teste de Unidade 
Teste de Integração 
Teste de Validação 
Teste de Sistema 
Teste na Migração 
 
 
 
Plano de Ensino 
Unidade V – Teste de software em sistema em produção 
Teste de software nos diversos tipos de manutenção 
Confiabilidade 
Disponibilidade 
 
 
 
Plano de Ensino 
Unidade VI – Ferramentas de teste de software 
Ferramentas de teste no desenvolvimento de sistema 
Ferramentas de teste para o programa 
Ferramentas de teste para o ambiente Web 
Ferramentas de teste para sistemas em produção 
 
 
 
Mapa Conceitual 
• PRESSMAN, R. S.. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 
2006. 
 
• DELAMARO, M.; MALDONADO, J. C.; JINO, M.. Introdução ao Teste de 
Software. 1. ed. Rio de Janeiro: Elsevier, 2007. 
 
• PEZZÉ, M.; YOUNG, M.. Teste e análise de software: Processos, princípios 
e técnicas. 1. ed. Porto Alegre: Bookman, 2008. 
 
Bibliografia Básica 
35 
• MOLINARI, L.. Inovação e automação de testes de software. 1. ed. São 
Paulo: Editora 
• Érica, 2010. RIOS, E.. Análise de riscos e projetos de teste de software. 1. 
ed. Rio de Janeiro: Alta Books, 2005. 
• BARTIÉ, A.. Garantia da qualidade de software: adquirindo maturidade 
organizacional. 8. ed. Rio de Janeiro: Elsevier, 2002. 
• RIOS, E.; MOREIRA FILHO, T. R.. Teste de software. 2. ed. Rio de Janeiro: 
Alta Books, 2006. 
• MOLINARI, L.. Testes de software: produzindo sistemas melhores e mais 
confiáveis. 1. ed. São Paulo: Editora Érica, 2003. 
 
Bibliografia Complementar 
36 
• Na próxima aula ... 
37 
Dúvidas ? 
38