Motivação Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br Dependência por sistemas de software Testes e outras técnicas são fundamentais para garantir a qualidade de tais sistemas No entanto, são caros e muitas vezes deixados de lado! Um dado impressionante do NIST: Ø U$59.500.000.000,00 é o custo das falhas em software nos EUA, apenas em 2002. Ø U$22.200.000.000,00 em economia, caso a infra-estrutura para testes fosse melhor. Mars Climate Orbiter Ø Objetivo Enviar sinais a partir de marte, após seu pouso no planeta Ø Desastre Chocou-se com o planeta Ø Motivo Bug no software responsável pela conversão de medidas Ø Prejuízo» 165 milhões de dólares Importância das Atividades de Qualidade Airbus 320 Ø Desastre USS Vicennes derrubou um airbus 320 em 1988 Ø Motivo Bug no software de reconhecimento, confundindo o avião com um F-14 Ø Prejuízo 290 mortes 1
Máquina de Terapia Radiotiva Ø Desastre Overdose em pacientes sob tratamento Ø Motivo Inabilidade em gerenciar certas condições de disputa Ø Prejuízo Morte de 2 pessoas 6 outras lesionadas London Ambulance Service Ø Desastre Serviço auxiliado por computador falhou nos dias 26 e 27 de novembro de 1992, gerando várias falhas, como o envio de 2 ambulâncias para o mesmo destino, envio de uma ambulância para um local estando outras mais próximas, etc. Ø Motivo Tudo indica que o problema estava relacionado a alta carga de emergências durante o período. Ø Prejuízo Morte de 20 pessoas Airbus A300 China Air Lines Ø Desastre Avião caiu em 1994 Ø Motivo Foi feita uma investigação e dentre as recomendações, aconselharam mudanças nos softwares de controle. Ø Prejuízo 264 mortes Mais de uma centena de outras falhas... Como ficar livre disso? Expectativa Ø Podemos esperar que o software funcione corretamente? Ø Programas feitos com bastante cuidado 5 falhas / 1000 LOC Programa com 1 Milhão LOC à 5000 falhas Ø Windows P tem 45 Milhões de LOC 45 x 5000 = 225.000 2
Piada? Ø Se a indústria automobilística tivesse se desenvolvido como a indústria do software, nós teríamos carros por U $25, fazendo 5000 milhas com um galão de combustível. Ø Porém, esse carro iria quebrar duas vezes por dia, sem um motivo aparente, e quando você solicitasse assistência junto as concessionárias eles iriam dizer para você reinstalar o motor! Carros são mais confiáveis que software? Como os carros são desenvolvidos? Ø Requisitos Motor, rodas, ar-condicionado, som, espaço para bagagem... Ø Desenho detalhado Projeto arquitetônico, revisado várias vezes Ø Verificação do desenho Simulação, protótipo Ø Desenvolvimento de componentes Testa-se cada componente Componentes são reusáveis Produzidos em massa Ø Montagem do carro Testa-se o carro (teste de batidas, teste de resistência, teste de estabilidade Teste de usabilidade Como os carros são desenvolvidos? Unidades Integração Integração Produto Concluído Qualidade de Software O que é Qualidade de Software? Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer a necessidades explícitas e implícitas [NBR ISO 1994] Conformidade a: Ø requisitos funcionais e de desempenho, Ø padrões e convenções de desenvolvimento préestabelecidos, Ø atributos implícitos que todo software desenvolvido profissionalmente deve possuir. [R.S.Pressman] 3
Modelo de Qualidade de McCall et al, 1977 Características Operacionais: correção confiabilidade integridade eficiência Adaptabilidade a novos ambientes: portabilidade reusabilidade interoperabilidade Habilidade para ser alterado: manutenibilidade flexibilidade testabilidade Modelo de Qualidade de McCall et al, 1977 Com relação ao uso do produto (operação) : Ø Correção o quanto um programa satisfaz a sua especificação e cumpre os objetivos visados pelo cliente Ø Confiabilidade quanto um programa executa a função pretendida com a precisão exigida Ø Eficiência a quantidade de recursos computacionais e de código exigida para que um programa execute sua função Ø Integridade o quanto o acesso ao sw ou aos dados por pessoas não autorizadas pode ser controlado Ø Usabilidade o quanto de esforço é necessário para aprender, preparar a entrada e interpretar a saída de um programa Modelo de Qualidade de McCall et al, 1977 Com relação às alterações do produto (habilidade para ser alterado): Ø Manutenibilidade o quanto de esforço é necessário para localizar e eliminar erros em um programa Ø Flexibilidade o quanto de esforço é necessário para modificar um programa Ø Testabilidade o quanto de esforço é necessário para testar um programa a fim de garantir que ele execute a função pretendida Modelo de Qualidade de McCall et al, 1977 Com relação a transição do produto (a adaptação a novos ambientes) : Ø Portabilidade o quanto de esforço é necessário para transferir um programa de uma plataforma de hw e/ou sw para outra Ø Reusabilidade o quanto um programa (ou partes dele) pode ser reutilizado em outros programas Ø Interoperabilidade o quanto de esforço é necessário para se acoplar um programa a um outro O que é Qualidade de Software? Cada tipo de software tem seus próprios requisitos de qualidade A importância de cada característica de qualidade varia conforme o tipo de software Funcionalidade Confiabilidade Usabilidade Desempenho Manutenibilidade Portabilidade Sistema de Controle de Mercearias Sistema Embarcado de Satélite Avaliação da qualidade do produto ISO/IEC 9126 (NBR 13596) Ø define as características de qualidade de sw que devem estar presentes em todos os produtos ISO/IEC 12119 Ø estabelece os requisitos de qualidade para pacotes de sw e instruções para teste, considerando esses requisitos ISO/IEC 14598-5 Ø define um processo de avaliação da qualidade de produto de sw 4
Por quê surgem falhas? Alterações: Ø alterações degradam a estrutura do software, tornando-o cada vez mais difícil de alterar Tempo: Ø com o tempo os custos da implementação de alterações aumenta, e Ø a capacidade do sistema em prestar os serviços esperados diminui Complexidade: Ø difícil de desenvolver: um único desenvolvedor não é capaz de entender o sistema como um todo Ø difícil de usar Ø difícil de entender: código incompreensível, falta de documentação * Fatores de qualidade Ø correto, confiável Ø completo, consistente, preciso Ø eficiente, factível Técnicas de Certificação Ø Análise Estática Ø Análise Dinâmica = Teste Ø... Aplicação de métodos e ferramentas técnicas Ø uso pelos desenvolvedores de métodos e ferramentas que ajudem a conseguir especificações, projetos, etc, de maior qualidade Realização de revisões técnicas e inspeções Ø o objetivo é avaliar a qualidade do artefato de software (especificação, projeto,...) produzido ao longo do desenvolvimento Atividades de testes Ø em complemento às revisões e outras técnicas V&V Aplicação de padrões Ø padrões podem ser usados: para documentos, documentação do código e estilo de codificação (como usar linguagem de programação) Ø padrões podem ser determinados pelo cliente, por normas internacionais Ø ou pela empresa de desenvolvimento. Verificação e Validação (V&V) Ø Verificação É o processo de se avaliar um software a cada fase para determinar se o produto dessa fase satisfaz ao que foi requerido no início da fase Objetivo: Assegurar consistência, completitude e corretude do produto em cada fase e entre fases consecutivas Estamos desenvolvendo certo o produto? Ø Validação É o processo de se avaliar um software, durante ou após o desenvolvimento, para determinar se o produto satisfaz aos requisitos Objetivo: Assegurar que o produto final corresponda aos requisitos do usuário Estamos desenvolvendo o produto certo? Verificação Ø Estamos desenvolvendo certo o produto? Validação Ø Estamos desenvolvendo o produto certo? 5
VV& T Ø Fazer ou não? VV&T, fazer ou não? Ø Permite encontrar falhas mais cedo Ø Melhora a qualidade dos produtos Ø Torna os requisitos mais estáveis Ø Permite acompanhamento contínuo da qualidade e da produtividade Ø Facilita o gerenciamento VV&T, fazer ou não? Ø Aumenta os custos do desenvolvimento análise custos benefícios Iniciar o mais cedo possível enfocar partes mais críticas do sistema (análise de riscos) Ø Aumenta a interação entre equipes escolher equipe experiente envolver equipe desde cedo Ø Aumenta a documentação melhora a qualidade Ø Requer compartilhamento de recursos (e/ou dados) críticos prever no contrato com o cliente Porcentagem 80 70 60 50 40 30 20 10 0 172016 191616 10 Inspeções Formais Revisões Estruturadas Atividades de VV&T 62 67 57 484748 47 52 Testes de Aceitação Atividade Testes do Sistema Integrado 3135 2423 Testes de Unidade 1995 1997 1999 2001 PBQP Software - MCT Teste é o processo de executar um programa com o intuito de encontrar erros Glenford J. Myers (1979) Pode mostrar a presença de falhas, mas nunca a sua ausência - Dijkstra Processo de execução de um sistema ou componente sob condições especificas para detectar diferenças entre os resultados obtidos e os esperados (IEEE) Custo da Qualidade Esforço por Atividade Command-control SAGE-NTDS Command-control TRW Sapceborne OS/360 Científico TRW Comercial Raytheon Análise Projeto Codificação e Auditoria Teste e Integraçao 35 % 17 % 48 % 46 % 20 % 34 % 34 % 20 % 46 % 33 % 17 % 50 % 44 % 26 % 30 % 44 % 28 % 28 % 6
Ferramentas de Apoio Sonar Análise estática e dinâmica em projetos java Configuração centralizada de normas de qualidade a serem utilizadas (Checkstyle, PMD e Findbugs) Capacidade de ver a evolução ao longo do tempo Gestão do evento durante o ciclo de vida do projeto Consolidação do project portfolio Ferramentas de Apoio Sonar Demonstração Quando os testes devem começar? As atividades de testes devem ser integradas às atividades de desenvolvimento As atividades de teste devem ser iniciadas cedo Procedimentos de teste podem ser descritos desde a fase de especificação Fases do Teste Planejamento Desenho Objetivos do Teste O quê testar? Implementação Determinação de estratégias para delimitar os objetivos Geração de Procedimentos e Casos de Teste Execução dos Casos de Teste Determinar se os objetivos foram atendidos Execução Verificação Registrar lições aprendidas, gerando um relatório final Balanço Final Ciclo dos Testes Entradas Especificação Oráculo Saídas Obtidas Passou Não passou Inconcludente Erro Veredicto Dificuldades do Teste Detecção de falhas se dá através da ocorrência de defeitos É necessária a existência de uma especificação Falhas nos requisitos podem não ser detectadas Especificação incompleta ou ambígua pode levar a resultados incorretos ou inadequados Software 7
Dificuldades Testes não podem ser exaustivos Ø não servem para demonstrar correção de um sw Certas tarefas de testes não podem ser automatizadas Ø problemas intratáveis e indecidíveis Veredictos de testes dependem das saídas esperadas mas elaborar mecanismo que produza as saídas esperadas (oráculo) é difícil ou mesmo impossível Testar Não é Tudo! Testar não é a única forma de encontrar falhas em um software Ø testes devem complementar outras formas de V&V e não substituí-las Há falhas que dificilmente seriam reveladas através de testes As revisões e inspeções são mais efetivas na descoberta de erros! Como tornar a atividade de teste mais eficiente? Utilizar outras técnicas de V&V combinadas ao teste Uso de ferramentas e metodologias Reuso de casos de teste sempre que possível Integração das atividades de testes com as atividades de desenvolvimento Uso de estratégias com base em riscos Pequeno teste : Ø Um programa lê 3 inteiros. Os três valores são interpretados como os comprimentos dos lados de um triângulo. O programa imprime uma mensagem que mostra que o triângulo é escaleno, isósceles ou eqüilátero. Ø Em uma folha de papel, escreva um conjunto de casos de testes (ex.: especifique conjunto de dados) que você acredita ser adequado para testar esse programa. Pequeno teste : 1. Você tem um caso de teste que representa um triângulo escaleno válido? (Note que casos de testes como 1,2,3 e 2,5,10 não ganham um sim nesta pergunta, pois não existem triângulos válidos com esses lados.) 2. Você tem um caso de teste que representa um triângulo eqüilátero válido? 3. Você tem um caso de teste que representa um triângulo isósceles? (Um caso de teste com 2,2,4 não pode ser contado.) 4. Você tem no mínimo 3 casos de testes que representam um triângulo isósceles válido e que você tenha tentado as três permutações possíveis (Ex.: 3,3,4; 3,4,3;4,3,3)? 5. Você tem um caso de teste no qual um dos lados é zero? 6. Você tem um caso de teste no qual um dos lados tem o valor negativo? Pequeno teste : 7. Você tem um caso de teste com 3 inteiros maiores que zero, onde a soma de dois lados é igual ao terceiro lado? (Se o programa disser que 1,2,3 representa um triângulo escaleno, ele contém um erro.) 8. Você tem no mínimo 3 casos de teste da categoria 7 para as quais você tentou as três permutações? (Ex.: 1,2,3; 1,3,2 e 3,1,2) 9. Você tem um caso de teste com 3 inteiros maiores que zero, onde a soma de dois lados é menor que o terceiro lado (1,2,4 ou 12,15,30)? 10. Você tem um caso de teste na categoria 9 para o qual você tentou as três permutações (Ex.: 1,2,4; 1,4,2 e 4,1,2)? 11. Você tem um caso de teste no qual todos os lados são 0 (Ex. 0,0,0)? 12. Você tem um caso de teste especificando valores não-inteiros? 13. Você tem um caso de teste especificando uma quantidade errada de valores (Ex.: dois em vez de 3, inteiros)? 14. Para cada teste, você especificou a saída esperada do programa além dos valores de entrada? 8
Pequeno teste : Ø Obviamente, um conjunto de casos de testes que satisfaça as condições anteriores não garantem que todos os erros possíveis foram encontrados. Ø Como ponto de referência: Ø Programadores altamente experientes obtiveram, na média, somente 7.8 pontos no total de 14. Ø Mesmo de um programa trivial como este não é uma tarefa fácil. Ø E, se isso é verdade, considere a dificuldade de testar um sistema de controle aéreo com 100.000 linhas de código Princípios do Teste [Myers]: Ø não planeje o teste assumindo que o programa está correto Ø um bom caso de teste é aquele que tem alta probabilidade de encontrar erro ainda não descoberto Ø caso de teste bem sucedido é aquele que detecta erro ainda não descoberto Ø a probabilidade de existência de mais erros numa parte do programa é proporcional ao número de erros já descoberto na mesma Princípios do Teste [Myers]: Ø teste deve ser feito por outra pessoa que não o autor do programa Ø dados de teste devem ser definidos para dados inválidos e não-esperados Ø determinar SEMPRE os resultados esperados Ø verificar cuidadosamente os resultados de cada teste Ø nunca jogue fora casos de teste, a não ser que esteja jogando fora também seu programa Conceitos Básicos Conceitos Básicos Teste consistes na verificação dinâmica do funcionamento de um programa em um conjunto finito de casos de teste, cuidadosamente selecionado dentro de um domínio infinito de entradas, contra seu funcionamento esperado. Ø Dinâmico Execução Ø Finito Existem muitos casos de teste Ø Selecionado Técnicas diferem na seleção Ø Esperado Funcionamento deve ser verificado Conceitos Básicos Terminologia Ø Testabilidade Facilidade com que um software pode ser testado. Envolve várias características Operabilidade» Quanto melhor funciona, mais eficientemente pode ser testado.» Tem poucos defeitos, nenhum bloqueia sua execução, evolui em estágios, permitindo testes simultâneos. Observabilidade» O que você vê é o que você testa» Saída distinta para cada entrada, estados e variáveis visíveis durante a execução, todos fatores que afetam a saída são visíveis, saída incorreta é facilmente detectável, código fonte acessível 9
Conceitos Básicos Terminologia Ø Testabilidade Controlabilidade» Quanto mais se pode controlar o software, mais o teste pode ser automatizado e otimizado» Todo código é executado através da combinação de entradas, estado do software e do hardware podem ser controlados pelo testador, formatos de entrada são consistentes e estruturados, testes podem ser automatizados e reproduzidos. Decomponibilidade» Controlando o escopo do teste podemos isolar problemas rapidamente e realizar retestagem mais racionalmente» Sistema construídos através de módulos, que podem ser testado independentemente. Conceitos Básicos Terminologia Ø Testabilidade Simplicidade» Quanto menos há a testar, mais rapidamente poderá ser feito.» Simplicidade funcional, estrutural e de código. Estabilidade» Quanto menos modificações, menos interrupções no teste.» Modificações não são freqüentes, são controladas, não invalidam os testes existentes. Conceitos Básicos Terminologia Ø Testabilidade Compreensibilidade» Quanto mais informações, mais racionalmente pode ser testado.» O projeto é bem compreendido, as dependências são claras, modificações são informadas, documentação precisa, detalhada e organizada. Conceitos Básicos Terminologia Ø Elementos do Teste Procedimento de Teste» Documentação especificando uma seqüência de ações para execução de um teste. Caso de Teste» Documentação especificando entradas, resultados esperados, e um conjunto de condições de execução para um item de teste. Plano de Teste» Documento que descreve o escopo, abordagem, recursos e agenda para as atividades de teste, identificando os itens de teste, as construções a serem testadas, as tarefas envolvidas, executores e riscos associados. IEEE STD 829-1983 Níveis de Teste Alvo do Teste Ø Módulo simples Ø Um grupo de módulos Agrupado por propósito, uso, ou estrutura Ø O sistema completo 10
Ø Teste de caixa branca (estrutural) Ø Conduzido em paralelo para vários módulos Ø Diversas Características avaliadas Ø Características Avaliadas interface» dados entram e saem corretamente» número e tipo de parâmetros - compatibilidade operações sobre variáveis» cálculos incorretos» over/underflow, índices, etc. caminhos de execução» caminhos importantes» caminhos de atendimento a erros Ø Características Avaliadas atendimento a erros» rotina de erro corresponde ao erro encontrado» erro causa intervenção do sistema antes do atendimento» mensagem elucida causa do erro? condições de contorno» testes com valores máximo, mínimo, imediatamente abaixo e acima de itens de dados e de variáveis de controle de loops erros comuns» precedência de operadores incorreta» comparações de tipos de dados diferentes» terminação inexistente de ciclos» erros de precisão Ø Ambiente para Teste de Unidade Driver: chamador do módulo em teste» Inicialização das variáveis e dos parâmetros da chamada Stub: módulos chamado pelo módulos testados stub driver módulo stub Ø Planejamento do Teste de Unidade escolha de critério de cobertura lógica selecionar caminhos de teste determinar casos de teste caso de teste» dado de teste» resultado esperado Demonstração: Criando Testes de Unidade 11
Ø Analisadores estáticos Ferramentas de software p/ processar o código fonte de um programa, a fim de descobrir certos padrões de erros É uma ajuda efetiva às inspeções, mas não uma substituição Utilização da análise estática Particularmente vantajosa quando uma linguagem fracamente tipada, onde muito erros não são detectados pelo compilador Menos efetiva para linguagens com uma verificação de tipos forte e que portanto detecta muitos erros durante a compilação» Mesmo assim, ainda é uma boa ajuda! Ø Analisadores estáticos Estágios da Análise Análise do fluxo de controle» Detecção de loops, código que nunca é executado, etc. Análise da utilização dos dados» Detecta variáveis usadas antes da inicialização, variáveis declaradas e nunca usadas, variáveis não declaradas, limites violados, etc. Análise de interface» Detecta erro de ordem, tipo e número de parâmetros, funções e procedimentos não chamados, não utilização de resultados de funções Análise de fluxo da informação» Identifica as dependências das variáveis de saída. Não detecta anomalias, mas chama a atenção p/ a revisão ou inspeção de código Demonstração: Analisadores Estáticos PMD Teste de Unidade Práticas aconselhadas: Ø Todo desenvolvedor deve criar teste de unidade para o código produzido Ø Tais testes devem passar por revisões, seja por membros da equipe de teste, seja por um desenvolvedor com um pouco mais de experiência em testes Ø Considerar a possibilidade de desenvolver geradores automáticos de objetos Ø É importante o suporte de transações para evitar problemas com a repetição dos testes Ø Considerar a possibilidade de cada desenvolvedor ter seu próprio banco Ø Considerar a possibilidade de separar a implementação dos seus testes, pois podem existir muitas classes, gerando confusão Ø Importante o uso de analisadores estáticos para garantia de certas propriedades Ø Desenvolvimento Dirigido por Testes (TDD) Objetivo» Produzir "código limpo que funciona" [Beck] Vantagens» Você sabe quando terminou» Oportunidade de aprender todas as lições que o código ensina (em vez de pegar a primeira solução que aparecer e esquecer as outras)» Melhora as vidas dos usuários do seu software» Melhora as vidas dos membros da equipe Ø Desenvolvimento Dirigido por Testes (TDD) Regra Geral» Só se escreve uma nova linha de código se algum teste falhar Implicações» Código funcionando fornece feedback e orienta decisões» Desenvolvedor cria testes durante implementação» Desenho deve facilitar o teste: componentes pequenos, desacoplados, coesos. 12
Ø Desenvolvimento Dirigido por Testes (TDD) Ordem» Red: escreva um pequeno teste que não funciona (e talvez nem compile.» Green: faça o teste rodar rapidamente, cometendo todos os pecados necessário para isso.» Refactor: elimine toda a duplicação criada para fazer o teste rodar. Exemplo» Triangulo Demonstração: Desenvolvendo com o TDD Teste de Integração Ø Processo de verificar a interação entre os componentes. Ø Montagem do software com módulos já testados Ø Verificação da interface entre módulos Ø Funções parciais e global do sistema Ø Estratégias de integração topdown bottom-up mista Teste de Integração Top-Down Ø integração parte do módulo principal para os módulos que implementam funções primitivas Ø tipos: vertical: segundo o fluxo principal de controle horizontal: incorpora todos os módulos diretamente subordinados a cada nível M5 M8 M1 M2 M3 S4 M6 S7 Teste de Integração Top-Down Ø módulo principal usado como driver Ø módulos diretamente subordinados substituídos por stubs Ø stubs são substituídos um de cada vez Ø testes de regressão asseguram que não houve introdução de novos erros M5 M8 M1 M2 M3 S4 M6 S7 Teste de Integração Bottom-Up Ø módulos inferiores combinados em grupos Ø drivers são escritos para testar grupos Ø drivers são substituídos por módulos integradores de grupos M1 M8 M8 D1 D2 D3 cluster #1 cluster #2 cluster #3 13
Teste de Integração - Top-Down x Bottom-Up Ø Top-Down programa principal + alguns módulos = protótipo erros de interface são descobertos cedo erros em módulos críticos de níveis inferiores são descobertos tarde no início requer pouca mão-de-obra Ø Bottom-Up erros em módulos críticos de níveis superiores são descobertos tarde ajuste mais fácil das necessidades de mão-de-obra ao pessoal disponível erros de interface são descobertos tarde muitos módulos precisam ser integrados antes que se tenha uma idéia do programa Teste de Integração Misto Ø Top-down Modificado módulos críticos são testados com drivers em paralelo à integração top-down Ø Sandwich teste realizado a partir das extremidades drivers e stubs são necessários Ø Big-bang integração de todos os módulos ao mesmo tempo dificuldade de descobrir origem dos erros Plano de Integração Práticas Aconselhadas Ø Determine uma estratégia de integração Ø Verifique com cuidado a ordem de acoplamento Isso pode ter um impacto direto na sua estratégia Ø Determinar casos de teste Ø Gerar drivers e stubs Ø Uma boa prática Integração bottom-up facilita a integração das unidades, sem a necessidade de retrabalho Tempo para apresentação do produto final aumenta, mas a priorização dos casos de uso minimiza esse problema Demonstração: Teste de Integração Teste de Sistema Ø Teste no sistema completamente integrado, para verificar o atendimento aos requisitos. Ø Envolve o teste de todos os requisitos funcionais e não funcionais. Ø Iremos abordar isso aos poucos, a partir dos diversos objetivos ligados ao teste de um sistema completo e funcional. 14