Qualidade de Software: Teste do Produto

Transcrição

1 Qualidade de Software: Teste do Produto Guilherme Horta Travassos Gladys Machado Pereira Santos Lima Bibliografia Básica Qualidade do Produto: Revisões, Inspeção e Teste de Software MALDONADO, J.C e TRAVASSOS, G.H Curso de Teste de Software, Conferência Internacional de Tecnologia de Software. CITS, Curitiba. BOEHM, B. & BASILI, V., 2001, Software Defect Reduction Top 10 List, Janeiro, IEEE Software, pp BINDER, R Testing Object-Oriented Systems: Models, Patterns, and Tools (The Addison-Wesley Object Technology Series) Addison-Wesley Pub Co; 1st edition. CHRISTIENSEN, M. & THAYER, R., 2001, The Project Manager s Guide to Software Engineering s Best Practices, IEEE Computer Society Press. DAVIS, A., 1990, Software Requirements Analysis and Specification, Prentice Hall, Englewood Cliffs, NJ. GLASS, R., 1999, Inspections Some Surprising Findings, Communications of the ACM, April, pp LIMA, G.M.P.S. e TRAVASSOS, G.H.. Testes de integração Aplicados a Software Orientado a Objetos: Heurísticas para Ordenação de Classes. III Simpósio Brasileiro de Qualidade de Software (SBQS). Brasília DF. Best SBQS Paper Award. 1

2 Bibliografia Básica Qualidade do Produto: Revisões, Inspeção e Teste de Software SHULL, F., RUS, I., BASILI, V., 2000, How Perspective-Based Reading Can Improve Requirements Inspections, July, IEEE Software, pp SHULL, F., BASILI, V., BOEHM, B., BROWN, A., COSTA, P., LINDVALL, M., PORT, D., RUS, I., TESORIERO, R., ZELKOWITZ, M., 2002, What We Have Learned About Fighting Defects, Eighth IEEE Symposium on Software Metrics, June 04-07, 2002, Ottawa, Canada TRAVASSOS, G.H., SHULL, F. and CARVER, J.; Working with UML: A Software Design Process Based on Inspections for the Unified Modeling Language, in Advances in Computers, vol. 54, Academic Press, 2001 TRAVASSOS, Guilherme Horta; VIEIRA, Marlon Erthal R. Testes em Softwares Orientados a Objetos. In: EDITORES, Andre Monat E Adriano Altoe,. (Org.). LIVRO DA I ESCOLA REGIONAL DE INFORMATICA DA SBC - REGIONAL ES/RJ. RIO DE JANEIRO, 1998, p YOUNESSI, H. Object-Oriented Defect Management of Software. Prentice Hall Verificação Validação & Testes Verificação e Validação Revisões de requisitos e projeto ajudam a encontrar problemas no começo do desenvolvimento. Teste: Foco na detecção de defeitos Identificação e correção dos defeitos. Falha = defeito + condição Sistemas (grandes, complexos e equipes) x Programas (pequenos e individuais) 2

3 Tipos de Defeitos Algoritmo Desvios (antecipados ou tardios); condição errada; inicialização de variáveis; esquecer condições; comparar variáveis de tipos de dados inadequados. Sintaxe (geralmente identificados pelos compiladores) Precisão (ex.: 0, > 0) Relativos à Capacidade ou a limites Sincronia ou coordenação Desempenho Recuperação Criação (tipo de variáveis) Classificação de Defeitos - Benefícios Classificação ortogonal de defeitos (IBM): Função -> defeito que afeta a capacidade, as interfaces com o usuário final, as interfaces do produto, a interface com a arquitetura de hardware ou as estruturas globais de dados; Verificação -> defeito na lógica do programa, que falha ao validar dados e valores apropriadamente, antes de utilizá-los; Atribuição -> defeito na estrutura de dados ou na inicialização do bloco de código; Sincronia/seqüência -> defeito que envolve a sincronia de recursos compartilhados e em tempo real; Algoritmo -> defeito que envolve a eficiência ou a correção do algoritmo ou da estrutura de dados, mas não do projeto... Chillarege, Ram et al. Orthogonal defect classification: a concept for in-process measurements. IEEE Transactions on SE, v.18, n. 11, pp , Nov, Melhoria do produto, do processo e das pessoas. 3

4 Teste e Depuração Teste: Processo de executar um programa ou sistema com o objetivo de revelar a presença de erros; ou, falhando nesse objetivo, aumentar a confiança sobre o programa. Depuração: é uma conseqüência não previsível do teste. Após revelada a presença do erro, o defeito deve ser encontrado e corrigido. Depuração não é teste! Teste de Software Principal Objetivo: refutar a assertiva de que o produto está correto o Determinar entradas que façam as saídas obtidas diferirem das saídas esperadas segundo a especificação (busca de um contra-exemplo). o É um processo destrutivo, sob o ponto de vista psicológico, contrariamente às demais fases da Engenharia de Software, onde constrói-se um produto. 4

5 Garantindo a Qualidade do Software Mito: Não é possível testar até que o sistema exista... o FATOS: Testar é muito mais do que apenas ver o que vai acontecer E muito mais que apenas executar casos de teste! Documentos de requisitos podem e devem ser testados em relação aos objetivos do negócio ou projeto para assegurar completude e correção. Teste de Software Uma das atividades mais onerosas do desenvolvimento de software. Atividade essencial para ascensão ao nível 3 do Modelo CMMI/SEI e para o nível E:Parcialmente Gerenciado do mps BR. Atividade relevante para avaliação de produtos de software (ISO 9126, ISO ). 5

6 Garantindo a Qualidade do Software Mito: Os testadores não precisam dos requisitos o FATOS: O sistema deve apoiar o negócio a atingir um objetivo, então o que o sistema realmente faz deve ser comparado com este objetivo. Uma especificação de requisitos representa o oráculo para o teste! Sim, testadores precisam dos requisitos, caso contrário, você poderia argumentar que o que vem sendo executado não é realmente um teste! Teste de Software Princípios Os testes devem ser rastreáveis aos requisitos do usuário o devem ser realizados para testar os requisitos do usuário Deve ser completamente planejado antes de seu início. o O planejamento é primordial para sua execução O princípio de Paretto se aplica: o 80% de todos os erros encontrados estarão concentrados em 20% dos componentes do software 6

7 Garantindo a Qualidade do Software Mito: Desenvolvedores devem pensar nos requisitos apenas no início do desenvolvimento, e se preocupar com testes apenas no final... o FATOS: ter os testadores envolvidos durante a análise de requisitos é uma das melhores formas de se assegurar requisitos de boa qualidade Trocas tardias nos requisitos causam impacto nos testes Ter os usuários envolvidos nos requisitos e nos testes é fundamental! Teste de Software Princípios Devem ser aplicados inicialmente em pequena escala e depois expandidos Não é possível aplicá-los exaustivamente Para aumentar sua eficácia deve ser executado por equipes independentes 7

8 Testes e Requisitos Mito: Os testadores não podem testar sem os requisitos o FATOS: Este é também um mal entendido comum Algumas vezes modificações são realizadas nos sistemas onde requisitos são inadequados ou não existentes. Isto faz o teste ser mais difícil, mas não é possível dizer que não pode ser feito. Aplicar teste exploratório é uma saída Teste de Software O que identifica um bom teste? Possui alta probabilidade de revelar um erro Não é redundante É abrangente o suficiente Possui um nível adequado de complexidade 8

9 Garantindo a Qualidade do Software Mito: Se escrever testes é difícil, isto é somente um problema dos testadores... o FATOS: Nem todos os requisitos são criados de acordo com a mesma perspectiva do testador. Para alguns dos requisitos fica fácil definir o teste, para outros um verdadeiro pesadelo! Especificar requisitos não funcionais testáveis tais como usabilidade ou desempenho é difícil Frases como fácil de usar, interface amigável, muito confiável ou desempenho aceitável não são especificações! Testabilidade do Software Simplesmente tenta mostrar a facilidade com que um software pode ser testado Operação o quanto melhor funciona, mais eficientemente pode ser testado Observação o o que você vê é o que você testa Controle o quanto melhor podemos controlar o software, mais podemos automatizar e melhorar o teste 9

10 Testabilidade de Software Decomposição o Controlando o escopo do teste, podemos mais rapidamente isolar os problemas e executar re-teste adequado Simplicidade o Quanto menos existe para se testar, mais rapidamente podemos testar o software Estabilidade o Quanto menos modificações, menos problemas para testar Compreensão o quanto mais informação tivermos, mais adequado será o teste Teste de Software D P? T X Inexistência de erro: o Software é de alta Qualidade?, ou; o Teste é de baixa Qualidade? 10

11 Garantindo a Qualidade do Software Mito: Requisitos são utilizados no teste, mas não o contrário... o FATOS: Você não testa requisitos, mas testa a partir deles! É fácil escrever requisitos vagos ou ambíguos, que parecem estar ok. Quando bons testadores observam a especificação de requisitos, eles aconselham casos de teste específicos para acertar os requisitos vagos, ambíguos ou não muito explícitos. Boa engenharia de requisitos produz melhores testes; boa análise de testes melhora os requisitos! Teste de Software Defeitos e erros "emboscados" no software e não revelados Falhas a se manifestarem na utilização pelos usuários e defeitos corrigidos durante a manutenção. CUSTOS ALTÍSSIMOS! 11

12 Garantindo a Qualidade do Software Mito: Não se preocupe, pequenas modificações nos requisitos não afetarão os testes o FATOS: Uma modificação aparentemente pequena nos requisitos pode trazer grande impacto para os testes Você deve testar todas as modificações para confirmar que o sistema está executando corretamente. É possível que testes de regressão sejam necessários O esforço do teste face a modificação vai depender dos riscos associados à modificação e dos impactos conhecidos (e desconhecidos!) no sistema Teste de Software Custos resultantes de testes insuficientes: US$ 22.2 a 59.5 bi (NIST, National Institute of Standards and Technology,Maio 2002) Atividade que tipicamente envolve: Execução do software com entradas representativas para as futuras condições de operação; Comparação entre saídas produzidas e esperadas; Comparação entre estados resultantes e esperados; Mensuração de características de execução (memória e tempo consumidos,etc.) 12

13 Teste de Software Se falhas graves se manifestam; Modificação do projeto, se erros são encontrados com regularidade; Qualidade e confiabilidade são suspeitas; NOVOS TESTES! Teste de Software Defeitos de fácil correção indicam que as funções aparentemente funcionam bem. Qualidade e confiabilidade aceitáveis, ou testes inadequados para revelar a ocorrência de erros graves. 13

14 Teste de Software Estratégia para Teste código Projeto Requisitos Alta ordem Unidade Integração Tipos de Teste Unidade Integração Regressão Sistema Validação (Aceitação) Instalação Requisitos do Negócio Teste de Aceitação Especificação do Projeto Teste de Integração de Sistema Especificação do Sistema Teste de Sistema Especificação de Projeto Teste de Integração de Componentes Código Teste de Componentes Projeto do Teste Execução do teste 14

15 Teste de Software - Fases Unidade o Existem situações em que você não terá os recursos para realizar o teste completo das unidades. Selecione os módulos críticos e aqueles com alta complexidade e apenas teste estes módulos o Utilize inspeções de código Integração o Aplicar a abordagem big bang para integração é uma estratégia ingênua que está fadada ao fracasso. Teste de integração deve ser conduzido de forma incremental e organizadamente! Infra-Estrutura para Teste Driver Componente a ser testado Interface Estruturas de Dados Locais Condições Limites Caminhos Independentes Caminhos de tratamento de erros Stub Stub Casos de Teste Resultados 15

16 Teste de Software - Fases Integração o Top-Down Quando você desenvolve um cronograma detalhado para o projeto você tem que considerar a maneira na qual a integração de componentes ocorrerá de forma que os componentes estejam disponíveis quando necessários o Bottom-up Integração bottom-up elimina a necessidade de stubs complexos Teste de Software - Fases Integração o Regressão Teste de regressão é uma estratégia importante para redução de efeitos colaterais. Execute testes de regressão toda vez que uma modificação maior é realizada no software (incluindo a integração de novos módulos) Efetue a gerência de configuração o Fumaça (smoke testing) Teste fumaça pode ser caracterizado como estratégia de integração por enrolamento. O software é reconstruído (com novos componentes incorporados) e exercitado diariamente. 16

17 Teste de Software - Fases Unidade Integração Perspectiva dos projetistas Funcional Desempenho Aceitação Perspectiva do Cliente Instalação Teste de Software Sistema = Funcional + Desempenho Funcional o Ignora a estrutura do sistema o Foco na funcionalidade Gerência de Configuração (controle de versões) 17

18 Teste de Software - Fases Sistema (continuação) Recuperação o força o software a falhar numa variedade de situações e verifica a capacidade de recuperação do produto Segurança o verifica se os mecanismos de proteção construídos para o sistema irão de fato protegê-lo de alguma utilização ou intrusão imprópria. Stress o executa o sistema de forma a exigir recursos em quantidade, freqüência ou volume anormais Desempenho o avalia o desempenho do software quando integrado ao sistema. Normalmente está associado ao teste de stress Teste de Software Configuração de software Configuração de teste Atividades de Teste Resultados de teste Resultados esperados Avaliação Dados da taxa de erros Erros Modelo de confiabilidade Depuração Correções Confiabilidade prevista 18

19 Teste de Software - Fases Validação (Aceitação) o Assim como os outros tipos de teste, validação tenta descobrir erros, mas o foco está nos requisitos - nas características que estarão imediatamente aparentes para o usuário final o Critérios para Teste de Validação 1) A funcionalidade (caso de uso) ou características de desempenho estão de acordo com o especificado e são aceitas 2) Uma variação da especificação é descoberta e uma lista de discrepâncias (deficiências) é criada Teste de Software - Fases Validação (Aceitação) o Revisão da Configuração assegura que todos os elementos da configuração de software foram propriamente desenvolvidos, estão catalogados e possuem o nível de detalhe suficiente para serem utilizados durante o ciclo de vida do software. Algumas vezes identificada como auditoria. o Teste Alfa e Beta Alfa: executado na instalação do desenvolvedor pelo cliente Beta: executado na instalação de um ou mais clientes pelo usuário final do software 19

20 Teste de Software - Fases Instalação o Consiste em instalar o sistema nos locais em que estão os usuários Dispensado no caso do teste de aceitação tiver sido no ambiente do usuário o Focam: A integridade do sistema instalado; e A verificação quanto a se alguma característica funcional ou não funcional foi afetada pelas condições do local de operação. Teste de Software Regras e estratégias Planejamento do Teste (em cada nível) Identificar Condições Projetar Casos de Teste Construir os Testes Processo de teste? Melhoria do Processo Executar os testes Verificar os resultados? Verificar critério de saída, relatório de teste 20

21 Automatização da Atividade de Teste Ferramentas de Teste Seleção de Ferramentas o que atividades de teste estão previstas no processo do software? Contribuem para reduzir as falhas produzidas pela intervenção humana o aumento da qualidade e produtividade da atividade de teste; o aumento da confiabilidade do software. Facilitam a condução de estudos experimentais. Automatização da Atividade de Teste Ferramentas de Teste Possibilidades: o Geração; o Execução; o Gerenciamento de testes Razões: o Testes são altamente repetitivos; o Tempo destinado aos testes é curto Uma execução automática completa pressupõe: Fornecer as entradas; Executar os casos de teste; Coletar e verificar os resultados; O uso de ferramentas não é trivial! 21

22 Projeto de Casos de Teste Projeto de teste pode ser tão difícil quanto o projeto do próprio produto a ser testado. Poucos programadores/analistas gostam de teste; menos ainda de projeto de casos de teste. Projeto de teste é um dos melhores mecanismos para prevenção de defeitos. O projeto de casos de teste é tão eficaz em identificar erros quanto a execução dos casos de teste projetados. Funciona como uma forma de revisão! Projeto de Casos de Teste Técnicas de Projeto de Casos de Teste Maneira sistemática e planejada para conduzir os testes. Conjunto de Casos de Teste T características desejáveis: o i ) deve ser finito o ii) o custo de aplicação deve ser razoável 22

23 Projeto de Casos de Teste Esteja certo que você projeta testes para executar todo caminho de tratamento de erro. Senão, o caminho pode falhar quando ativado, revelando uma situação nem sempre agradável do sistema Existem algumas situações nas quais você não terá todos os recursos para realizar um teste completo das unidades. Selecione os componentes mais críticos e aqueles com alta complexidade ciclomática e teste somente estes. Projeto de Casos de Teste Critério de Teste C Objetivo: o... obter, de maneira sistemática um conjunto T de casos de teste efetivo quanto à meta principal de teste - revelar a presença de erros no programa o Propriedades: i) incluir todos os desvios de fluxo de execução (fluxo de controle) ii) incluir pelo menos um uso de todo resultado computacional (fluxo de dados) iii) T mínimo e finito 23

24 Projeto de Casos de Teste Critério de teste serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de revelar a presença de defeitos. Caso de teste = dado entrada (domínio) + saída esperada Critério de Seleção de Casos de Teste Critério de Adequação T é C-adequado todo elemento requerido por C é exercitado por pelo menos um t, t T Projeto de Casos de Teste Técnicas: o Funcional (ou caixa preta); o Estrutural (ou caixa branca); o Baseada em Erros. A questão não está em qual delas utilizar e sim como utilizá-las de forma complementar. 24

25 Técnica Funcional (Caixa Preta) Baseia-se na especificação do software para derivar os requisitos de teste. Aborda o software de um ponto de vista macroscópico. Envolve dois passos principais: identificar as funções que o software deve realizar (especificação dos requisitos, casos de uso) criar casos de teste capazes de verificar se essas funções estão sendo executadas corretamente Técnica Funcional Problema: Dificuldade em quantificar a atividade de teste - não se pode garantir que partes essenciais ou críticas do software foram executadas. Critérios da Técnica Funcional: o Particionamento em Classes de Equivalência; o Análise do Valor Limite; o Grafo de Causa-Efeito. 25

26 Técnica Funcional: Exemplo Particionamento em Classes de Equivalência Divide o domínio de entrada do programa em classes de dados (classes de equivalências) o os dados de teste são derivados a partir das classes de equivalência o (domínio de saída deve ser considerado?) Técnica Funcional: Exemplo Dois Passos: o Identificar classes de equivalência (é um processo heurístico) condição de entrada válidas e inválidas o Definir os casos de teste enumeram-se as classes de equivalência casos de teste para as classes válidas casos de teste para as classes inválidas 26

27 Teste Funcional Classe de Equivalência Método caixa-preta que divide o domínio de entrada de um sistema em classes (categorias) de dados das quais casos de teste podem ser derivados Força a definição um caso de teste que revela categorias de erros, desta forma reduzindo o número total de casos de teste que devem ser desenvolvidos Baseado na avaliação de classes de equivalência para uma condição de entrada Se um conjunto de objetos podem ser ligados por relacionamentos que são simétricos, transitivos e reflexivos, uma classe de equivalência está presente. Teste Funcional Classe de Equivalência Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada. Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica. Diretrizes Se uma condição de entrada especifica uma faixa de valores ou requer um valor específico, uma classe de equivalência válida e duas inválidas são definidas; Se uma condição de entrada especifica um membro de um conjunto ou é lógica, uma classe de equivalência válida e uma inválida são definidas 27

28 Técnica Funcional: Exemplo Especificação do programa Identifier: O programa deve determinar se um identificador é válido ou não em Silly Pascal (uma estranha variante do Pascal). Um identificador válido deve começar com uma letra e conter apenas letras ou dígitos. Além disso, deve ter no mínimo 1 caractere e no máximo 6 caracteres de comprimento. Exemplo: abc12 (válido); cont*1 (inválido); 1soma (inválido); a (inválido) Técnica Funcional: Exemplo Classes de equivalência Condições de Entrada Classes Válidas Classes Inválidas Tamanho t do identificador Primeiro caractere c é uma letra Só contém caracteres válidos 1 t 6 (1) Sim (3) Sim (5) t > 6 (2) Não (4) Não (6) Exemplo de Conjunto de Casos de Teste T 0 = {(a1,válido), (2B3, Inválido), (Z-12, Inválido), (A1b2C3d, Inválido)} 28

29 Teste Funcional Análise do Valor Limite Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no centro Análise do Valor Limite é uma técnica de teste que explora os limites dos valores para preparar os casos de teste Está técnica complementa o particionamento em classes de equivalência Teste Funcional Análise do Valor Limite Diretrizes o Se uma condição de entrada especifica uma faixa de valores limitadas em a e b, casos de teste devem ser projetados com valores a e b imediatamente acima e abaixo de a e b; o Se uma condição especifica um número de valores, casos de teste deveriam ser desenvolvidos para exercitar os números mínimo e máximo. Valores imediatamente acima e abaixo do mínimo e máximo são também testados o Aplique as diretrizes 1 e 2 para as condições de saída. Por exemplo, assuma que uma tabela de temperatura x pressão é necessária como saída de um programa de análise de engenharia. Casos de teste deveriam ser projetados para criar um relatório de saída que produza o máximo (e mínimo) número possível de entradas na tabela; o Se uma estrutura de dados interna do programa tem identificados seus limites (ex. Um array com 100 posições), esteja certo de projetar um caso de teste para exercitar a estrutura de dados em seu limite 29

30 Técnica Estrutural (Caixa Branca) É baseada no conhecimento da estrutura interna da implementação. Teste dos detalhes procedimentais. A maioria dos critérios dessa técnica utiliza uma representação de programa conhecida como grafo de programa ou grafo de fluxo de controle. Técnica Estrutural (Grafo de Programa) Detalhes considerados: nó; arco; caminho: o simples; o completo; o livre de laço. fluxo de controle; Grafo de Programa do identifier Gerado pela View-Graph 30

31 Técnica Estrutural (Grafo de Programa) Nós: blocos indivisíveis o não existe desvio para o meio do bloco o uma vez que o primeiro comando do bloco é executado, os demais comandos são executados seqüencialmente Arestas ou Arcos: representam o fluxo de controle entre os nós Técnica Estrutural Critérios da Técnica Estrutural: Baseados em Fluxo de Controle o Todos-Nós, Todas-Arestas e Todos-Caminhos Baseados em Fluxo de Dados: o Critérios de Rapps e Weyuker Todas-Defs, Todos-Usos, Todos-P-Usos e outros o Critérios Potenciais-Usos (Maldonado) Todos-Potenciais-Usos, Todos-Potenciais-Usos/DU e outros Baseados em Complexidade: o Critério de McCabe. 31

32 Técnica Estrutural Critérios de Fluxo de Controle Todos-Nós: 1,2,3,4,5,6,7,8,9,10,11 Todos-Arcos: o arcos primitivos: <1,2>,<1,3>,<5,6>,<5,7>, <8,9>,<8,10> Todos-Caminhos. Grafo de Programa do identifier Gerado pela View-Graph Identifier.c /* 01 */ { /* 01 */ char achar; /* 01 */ int length, valid_id; /* 01 */ length = 0; /* 01 */ printf ("Digite um possível identificador\n"); /* 01 */ printf ("seguido por <ENTER>: "); /* 01 */ achar = fgetc (stdin); /* 01 */ valid_id = valid_starter (achar); /* 01 */ if (valid_id) /* 02 */ length = 1; /* 03 */ achar = fgetc (stdin); /* 04 */ while (achar!= '\n') /* 05 */ { /* 05 */ if (!(valid_follower (achar))) /* 06 */ valid_id = 0; /* 07 */ length++; /* 07 */ achar = fgetc (stdin); /* 07 */ } /* 08 */ if (valid_id && (length >= 1) && (length < 6) ) /* 09 */ printf ("Valido\n"); /* 10 */ else /* 10 */ printf ("Invalido\n"); /* 11 */ } 32

33 Técnica Estrutural (Grafo Def-Uso) uc = {achar} up = {valid_id} d = {length, valid_id, achar} up = {valid_id} 1 2 d = {length} 3 d = {achar} Detalhes considerados: fluxo de dados: o definição e uso de variáveis; o caminho livre de definição. 4 up = {achar} up = {achar} 5 7 up = {achar} 6 d = {valid_id} d = {achar, length} uc = {length} up = {achar} up = {valid_id, length} 10 8 up = {valid_id, length} 9 11 Grafo Def-Uso do identifier d = definição up = uso predicativo uc = uso computacional Técnica Estrutural uc = {achar} up = {valid_id} up = {achar} up = {achar} d = {length, valid_id, achar} up = {valid_id} 2 d = {length} d = {achar} up = {achar} 6 d = {valid_id} d = {achar, length} uc = {length} Critérios de Fluxo de Dados: Rapps e Weyuker: o Todas-Definições o Todos-Usos (1,2, length) (1,3, achar) (1,(1,3), valid_id) up = {achar}... up = {valid_id, length} 10 8 up = {valid_id, length} 9 11 Grafo Def-Uso do identifier d = definição up = uso predicativo uc = uso computacional 33

34 Técnica Estrutural d = {length, valid_id, achar} d = {length} d = {achar} 6 d = {valid_id} d = {achar, length} Critérios de Fluxo de Dados: Potenciais-Usos o Todas-Potenciais-Usos <1,2,{length}> <1,3,{achar}> <1,(1,3),{valid_id}> <2,(8,10),{length}> <3,(8,10),{achar}> d = definição... Grafo Def do identifier Técnica Baseada em Erros Os requisitos de teste são derivados a partir dos erros mais freqüentes cometidos durante o processo de desenvolvimento do software. Critérios da Técnica Baseada em Erros: Semeadura de Erros; Análise de Mutantes (teste de unidade); Mutação de Interface (teste de integração). 34

35 Análise de Mutantes Garantir a ausência de determinados tipos de defeitos. Considerando todos os programas Q, é possível provar a correção de P. T P Q t T P(t) Q(t) Análise de Mutantes É impraticável executar e comparar todos os programas Q. Estabelece-se então uma vizinhança Φ(P) que contém apenas um conjunto finito de programas. Esses programas contêm pequenos desvios sintáticos que representam defeitos simples. 35

36 Análise de Mutantes Q 01 Q 02 P Φ(P) Q n t T Q, P(t) Q(t) que P não contém os tipos de defeitos representados pelos programas Q. Análise de Mutantes Hipótese do Programador Competente Programadores experientes escrevem programas corretos ou muito próximos do correto. Efeito de Acoplamento Casos de teste capazes de revelar erros simples são tão sensíveis que, implicitamente, também são capazes de revelar erros mais complexos. 36

37 Análise de Mutantes X = 4 Y = 2 z = 1 read x, y, z m := x if m < y m := y if m < z m := z print m read x, y, z m := x if m y m := y if m < z m := z print m read x, y, z m := y if m > z m := z print m Análise de Mutantes Os operadores de mutação determinam o tipo de alteração sintática que deve ser feita para a criação dos mutantes Introduzir pequenas alterações semânticas através de pequenas alterações sintáticas que representam defeitos típicos Operadores dependem da linguagem alvo FORTRAN (22 operadores) C (71 operadores) 37

38 Análise de Mutantes Conjunto Essencial de Operadores SSDL: ORRN: VTWD: Ccsr: SWDD: SMTC: OLBN: Cccr: VDTR: Retira um comando de cada vez do programa. Troca operador relacional por operador relacional. Troca referência escalar pelo sucessor e predecessor. Troca referências escalares por constantes. Troca o comando while por do-while. Interrompe a execução do laço após duas execuções. Troca operador lógico por operador bitwise. Troca constante por constante. Requer valor negativo, positivo e zero para cada referência escalar Análise de Mutantes Exemplo de Operadores de Mutação Mutante Gerado pelo Operador OLAN /* 08 */ if (valid_id * (length >= 1) && (length < 6) ) /* 09 */ printf ("Valido\n"); /* 10 */ else /* 10 */ printf ("Invalido\n"); Mutante Gerado pelo Operador ORRN /* 08 */ if (valid_id && (length >= 1) && (length <= 6) ) /* 09 */ printf ("Valido\n"); /* 10 */ else /* 10 */ printf ("Invalido\n"); 38

39 Análise de Mutantes Dados P e T Passos para a Aplicação da Análise de Mutantes P é executado com os casos de teste de T Mutantes são gerados Mutantes são executados com os casos de teste de T Mutantes são analisados Técnica Estrutural Complexidade Ciclomática (McCabe): métrica que fornece uma medida quantitativa da complexidade lógica de um programa. No contexto do teste estrutural, seu valor define o número de caminhos independentes e nos fornece o número máximo de casos de teste que garantem que todos os comandos tenham sido executados pelo menos 1 vez Caminho independente o qualquer caminho do programa que apresenta pelo menos um novo conjunto de comandos processáveis ou uma nova condição. 39

40 Técnica Estrutural Complexidade Ciclomática: Equivalente ao número de regiões do grafo de fluxo V(G)=E-N+2 o E: número de arcos o N: número de nós ou, V(G) = P +1 o P: número de nós predicados (decisões) Para o grafo de programa ao lado: o V(G)= =5 1,3,4,8,9,11 1,2,3,4,8,10,11 1,2,3,4,5,7,4,8,... 1,2,3,4,5,6,7, 1,3,4,5,... Comparação de Critérios Estudos Teóricos e Experimentais avaliam: Custo o esforço necessário para que o critério seja utilizado o no. de casos de teste para satisfazer o critério Strength o Dificuldade de satisfação o Dificuldade de satisfazer um critério, tendo satisfeito outro. Eficácia o Capacidade que um critéiro possui de detectar erros Estratégia Incremental de Teste Ambiente de Teste, Depuração e Manutenção de Software 40

41 Testes e Requisitos Recomendações: Convide os testadores a participar das revisões dos requisitos e inspeções Comece o planejamento do teste em paralelo com a análise de requisitos Inclua sugestões de condições de teste e casos de teste para utilizar como exemplos na especificação de requisitos Inclua no documento de requisitos qualquer caso específico que vier a mente quando estiver analisando os requisitos Utilize cenários de negócios e casos de uso para dar exemplos específicos de como o sistema deveria funcionar Identifique critérios mensuráveis para ambos os tipos de requisitos (funcionais e não funcionais) Teste de Software Plano de Teste É um documento geral para o projeto como um todo que define o escopo, a abordagem a ser utilizada, e o cronograma para o teste assim como identifica os items de teste para o processo de teste inteiro e o pessoal responsável pelas diferentes atividades de teste Entradas: plano do projeto, documentos de requisitos, documentos de projeto do sistema o Conteúdo: Especificação de Teste de Unidades Características a serem testadas Abordagem para o teste Material a ser produzido Cronograma Alocação de pessoal 41

42 Teste de Software Plano de Teste Especificação do teste de unidade o conjunto de um ou mais módulos (componentes), em conjunto com os dados associados, pertencentes a um simples programa de computador representando os objetos para teste [IEEE87] Características a serem testadas o Representam todas as características do software e suas combinações que deveriam ser testadas. Isto pode incluir funcionalidade, desempenho, restrições de projeto e atributos. Abordagem para o teste o Especifica a abordagem geral a ser seguida no projeto corrente. Isto algumas vezes é chamado de critério de teste ou critério para avaliação do conjunto de casos de teste utilizados para o teste (ex. particionamento equivalente) Teste de Software Plano de Teste Material a ser produzido o deve ser especificado no plano de teste antes do início dos testes. Estes materiais (ou artefatos) podem ser uma lista de casos de teste utilizados, resultados detalhados do teste, relatório sumário do teste, histórico do teste e dados sobre a cobertura de código. Em geral, um relatório de especificação de caso de teste e um histórico de teste deveriam ser sempre especificados como material a ser produzido. Cronograma o especifica o montante de tempo e esforço a ser gasto nas diferentes atividades de teste, e o teste das diferentes unidades que foram identificadas Alocação de pessoal o identifica as pessoas responsáveis pela execução das diferentes atividades. 42

43 Teste de Software Plano de Teste EXEMPLO DE UM PLANO DE TESTE o por favor, perdoem os comerciais de entrada Referências Beizer, B., Software testing techniques, 2nd ed., Van Nostrand Reinhold Co., New York, IEEE Computer Society; IEEE Std 829: Standard for Software Test Documentation; September, Mats, L., The top five software-testing problems and how to avoid them, EDN Europe, Feb2001, Vol. 46 Issue 2, p37, 3p. Montoni, M., Miranda, R., Rocha, A.R., Travassos, G.H., Knowledge Acquisition and Communities of Practice: An Approach to Convert Individual Knowledge into Multiorganizational Knowledge,LSO. O Neill, D., What happens when you don t have a test plan, IV&V Australia, 1997, available at Pfleeger, S.L., Software Engineering; Theory and Practice. Prentice Hall Villela, K., Definição e Construção de Ambientes de Desenvolvimento de Software Orientados à Organização, Tese de D. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, maio. 43