Baixe o app para aproveitar ainda mais
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
Compartilhar