Qualidade de Software: Teste do...

•1

Qualidade de Software:Qualidade de Software:Teste do ProdutoTeste do Produto

Guilherme Horta [email protected]

Gladys Machado Pereira Santos [email protected]

Copyright ght2004

Engenharia de Software Experimentalwww.cos.ufrj.br/~ese

Qualidade do Produto: Revisões, Qualidade do Produto: Revisões, Inspeção e Teste de SoftwareInspeção e Teste de Software

� Bibliografia Básica

MALDONADO, J.C e TRAVASSOS, G.H. 1998. 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. 135-137.

BINDER, R. 1999. 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.17-19.

LIMA, G.M.P.S. e TRAVASSOS, G.H. 2004. 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.

•2

Copyright ght2004


Qualidade do Produto: Revisões, Qualidade do Produto: Revisões, Inspeção e Teste de SoftwareInspeção e Teste de Software

� Bibliografia Básica

SHULL, F., RUS, I., BASILI, V., 2000, “How Perspective-Based Reading Can Improve Requirements Inspections”, July, IEEE Software, pp. 73-79.

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. 156-200

YOUNESSI, H. Object-Oriented Defect Management of Software. Prentice Hall. 2002.

Copyright ght2004


Verificação Validação & TestesVerificaçã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) xProgramas (pequenos e individuais)

•3

Copyright ght2004


Tipos de DefeitosTipos 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,0000012 > 0)� Relativos à Capacidade ou a limites� Sincronia ou coordenação� Desempenho� Recuperação� Criação (tipo de variáveis)

Copyright ght2004


Classificação de Defeitos Classificação de Defeitos --BenefíciosBenefí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 ouda 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 943-956, Nov, 1992.

Melhoria do produto, do processo e das pessoas.

•4

Copyright ght2004


Teste e DepuraçãoTeste 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!

Copyright ght2004


Teste de SoftwareTeste 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.

•5

Copyright ght2004


Garantindo a Qualidade do Garantindo a Qualidade do SoftwareSoftware

� 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.

Copyright ght2004



• 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 14598-5).

•6

Copyright ght2004



� 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!

Copyright ght2004



� Princípios

• Os testes devem ser rastreáveis aos requisitos do usuárioo 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

•7

Copyright ght2004



� 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!

Copyright ght2004



� 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

•8

Copyright ght2004


Testes e RequisitosTestes 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

Copyright ght2004



� 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

•9

Copyright ght2004



� 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!

Copyright ght2004


TestabilidadeTestabilidade do Softwaredo 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

•10

Copyright ght2004


TestabilidadeTestabilidade de Softwarede Software

• Decomposiçãoo Controlando o escopo do teste, podemos mais rapidamente isolar os

problemas e executar re-teste adequado

• Simplicidadeo Quanto menos existe para se testar, mais rapidamente podemos testar

o software

• Estabilidadeo Quanto menos modificações, menos problemas para testar

• Compreensãoo quanto mais informação tivermos, mais adequado será o teste

Copyright ght2004



• Inexistência de erro:o Software é de alta Qualidade?, ou;o Teste é de baixa Qualidade?

?D P

XT

•11

Copyright ght2004



� 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!

Copyright ght2004



Defeitos e erros "emboscados" no softwaree não revelados

Falhas a se manifestarem na utilização

pelos usuários e defeitos corrigidos durante a

manutenção.

CUSTOS ALTÍSSIMOS!

•12

Copyright ght2004



� 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 trazergrande 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ãosejam 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

Copyright ght2004


� 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.)


•13

Copyright ght2004



Se falhas graves se manifestam;

Modificação do projeto, se erros são encontrados com regularidade;

Qualidade e confiabilidade são suspeitas;

NOVOS TESTES!

Copyright ght2004



Defeitos de fácil correção indicam que as funções aparentemente funcionam bem.

Qualidade e confiabilidade aceitáveis, outestes inadequados para revelar a ocorrência de erros

graves.

•14

Copyright ght2004



� Estratégia para Teste

UnidadeUnidade

IntegraçãoIntegração

Alta ordemAlta ordem

código

Projeto

Requisitos� Tipos de Teste

• Unidade• Integração• Regressão• Sistema• Validação

(Aceitação)• Instalação

Copyright ght2004


Requisitos do Negócio

Especificação do Projeto

Especificação do Sistema

Especificação de Projeto

Código

Teste de Aceitação

Teste de Integração de Sistema

Teste de Sistema

Teste de Integração de Componentes

Teste de Componentes

Projeto do Teste Execução do teste

•15

Copyright ght2004


Teste de Software Teste de Software -- FasesFases

• Unidade

o Existem situações em que você não terá os recursos para realizaro 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!

Copyright ght2004


InfraInfra--EstruturaEstrutura parapara TesteTeste

Driver

Componente a ser testado

Stub Stub

Resultados

Casosde Teste

InterfaceEstruturas de Dados Locais

Condições LimitesCaminhos Independentes

Caminhos de tratamento de erros

•16

Copyright ght2004



• 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

Copyright ght2004



• Integraçãoo 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.

•17

Copyright ght2004



Unidade

Integração

Perspectiva dos projetistas

Funcional

Desempenho

Aceitação

Instalação

Perspectiva do Cliente

Copyright ght2004



• Funcionalo Ignora a estrutura do sistemao Foco na funcionalidade

Gerência de Configuração(controle de versões)

Sistema = Funcional + Desempenho

•18

Copyright ght2004



� 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çao 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

• Desempenhoo avalia o desempenho do software quando integrado ao sistema.

Normalmente está associado ao teste de stress

Copyright ght2004



Atividades deTeste

Configuraçãode software

Configuraçãode teste

Avaliação

Resultadosde teste

Resultadosesperados

Dados da taxade erros

Modelo deconfiabilidade

Erros

Depuração

Correções

Confiabilidadeprevista

•19

Copyright ght2004



• 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ção1) A funcionalidade (caso de uso) ou características de desempenho

estão de acordo com o especificado e são aceitas2) Uma variação da especificação é descoberta e uma lista de

discrepâncias (deficiências) é criada

Copyright ght2004



• 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

•20

Copyright ght2004



• 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.

Copyright ght2004


Regras e estratégias

Planejamento do Teste(em cada nível)

Identificar Condições

Projetar Casos de Teste

Construir os Testes

Executar os testes

Verificar os resultados

Verificar critério de saída, relatório de teste

Processo de teste

Melhoria do Processo


?

?

•21

Copyright ght2004


Automatização da Atividade Automatização da Atividade de Testede 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.

Copyright ght2004


Automatização da Atividade Automatização da Atividade de Testede 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!

•22

Copyright ght2004


Projeto de Casos de TesteProjeto 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!

Copyright ght2004



� 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 finitoo ii) o custo de aplicação deve ser razoável

•23

Copyright ght2004


ProjetoProjeto de de CasosCasos de de TesteTeste

� 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.

Copyright ght2004



� 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

•24

Copyright ght2004



� 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

� 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

Copyright ght2004



• 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á-lasde forma complementar.

•25

Copyright ght2004


Técnica Funcional Técnica Funcional (Caixa Preta)(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

Copyright ght2004


Técnica FuncionalTé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.

•26

Copyright ght2004


Técnica Funcional: ExemploTé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?)

Copyright ght2004



• 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

•27

Copyright ght2004


TesteTeste FuncionalFuncional

� 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.”

Copyright ght2004



� 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

•28

Copyright ght2004



• 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);

a123456 (inválido)

Copyright ght2004



• Classes de equivalência

Tamanho t do identificador

Condições de Entrada Classes Válidas Classes Inválidas

1 ≤ t ≤ 6(1)

Primeiro caractere c é uma letra

Só contém caracteres válidos

t > 6(2)

Sim(3)

Não(4)

Sim(5)

Não(6)

� Exemplo de Conjunto de Casos de Teste

� T0 = {(a1,Válido), (2B3, Inválido),

(Z-12, Inválido), (A1b2C3d, Inválido)}

•29

Copyright ght2004



� 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

Copyright ght2004



� 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

•30

Copyright ght2004


Técnica Estrutural Técnica Estrutural (Caixa Branca)(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.

Copyright ght2004


Técnica Estrutural (Grafo de Programa)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

•31

Copyright ght2004


Técnica Estrutural (Grafo de Programa)Técnica Estrutural (Grafo de Programa)

� Nós: • blocos “indivisíveis”

o não existe desvio para o meio do blocoo 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

Copyright ght2004


Técnica EstruturalTé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.

•32

Copyright ght2004



� 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

Copyright ght2004


/* 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;


/* 04 */ while (achar != '\n')

/* 05 */ {

/* 05 */ if (!(valid_follower (achar)))

/* 06 */ valid_id = 0;

/* 07 */ length++;


/* 07 */ }

/* 08 */ if (valid_id && (length >= 1) && (length < 6) )

/* 09 */ printf ("Valido\n");

/* 10 */ else

/* 10 */ printf ("Invalido\n");

/* 11 */ }

Identifier.c

•33

Copyright ght2004


Técnica Estrutural (Grafo Técnica Estrutural (Grafo DefDef--Uso)Uso)

� Detalhes considerados:• fluxo de dados:

o definição e uso de variáveis;o caminho livre de definição.

d = definição

up = uso predicativouc = uso computacional

1

3

4

5

7

8

11

2

6

910

d = {length, valid_id, achar}

d = {length}

d = {achar, length}

d = {valid_id}

d = {achar}

uc = {achar}

uc = {length}

up = {valid_id}

up = {achar}

up = {achar}

up = {achar}

up = {achar}

up = {valid_id, length}up = {valid_id, length}

up = {valid_id}

Grafo Def-Uso do identifier

Copyright ght2004



� Critérios de Fluxo de Dados:• Rapps e Weyuker:

o Todas-Definiçõeso Todos-Usos(1,2, length)(1,3, achar)(1,(1,3), valid_id)

d = definição

up = uso predicativouc = uso computacional

1

3

4

5

7

8

11

2

6

910


d = {length}

d = {achar, length}

d = {valid_id}

d = {achar}

uc = {achar}

uc = {length}

up = {valid_id}

up = {achar}

up = {achar}

up = {achar}

up = {achar}

up = {valid_id, length}up = {valid_id, length}

up = {valid_id}

Grafo Def-Uso do identifier

...

•34

Copyright ght2004



1

3

4

5

7

8

11

2

6

910


d = {length}

d = {achar, length}

d = {valid_id}

d = {achar}

d = definição

Grafo Def do identifier

� 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}>

...

Copyright ght2004


Técnica Baseada em ErrosTé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).

•35

Copyright ght2004


P Q

T

P(t) ≠ Q(t)

t ∈ T

Análise de MutantesAná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.

Copyright ght2004



� É 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.

•36

Copyright ght2004



� ∃ t ∈ T | ∀ Q, P(t) ≠ Q(t) ⇒ que P não contém os tipos de defeitos representados pelos programas Q.

Q...

Q...P

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Qn

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q02

Q...

Q01

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Q...

Φ(P)

Copyright ght2004


Programadores experientes escrevem programas corretos ou muito

próximos do correto.

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.


� Hipótese do Programador Competente

� Efeito de Acoplamento

•37

Copyright ght2004



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 m ≠≠≠≠≠≠≠≠ yy

m := y

if m < z

m := z

print m

read x, y, z

m := y

if m > z

m := z

print m

X = 4

Y = 2

z = 1

4 2

1

Copyright ght2004



� 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)

•38

Copyright ght2004



� 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

Copyright ght2004



� Exemplo de Operadores de Mutação

Mutante Gerado pelo Operador ORRN

/* 08 */ if (valid_id && (length >= 1) && (length <= 6) )/* 09 */ printf ("Valido\n");/* 10 */ else/* 10 */ printf ("Invalido\n");

Mutante Gerado pelo Operador OLAN

/* 08 */ if (valid_id * (length >= 1) && (length < 6) )/* 09 */ printf ("Valido\n");/* 10 */ else/* 10 */ printf ("Invalido\n");

•39

Copyright ght2004



� 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

Copyright ght2004



� 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 independenteo qualquer caminho do programa que apresenta pelo menos um novo

conjunto de comandos processáveis ou uma nova condição.

•40

Copyright ght2004



� Complexidade Ciclomática:• Equivalente ao número de regiões do grafo

de fluxo• V(G)=E-N+2

o E: número de arcoso N: número de nós

• ou, V(G) = P +1o P: número de nós predicados (decisões)

• Para o grafo de programa ao lado:o V(G)=14-11+2=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,...

Copyright ght2004


Comparação de CritériosComparação de Critérios

� Estudos Teóricos e Experimentais avaliam:• Custo

o esforço necessário para que o critério seja utilizadoo no. de casos de teste para satisfazer o critério

• Strength

o Dificuldade de satisfaçãoo Dificuldade de satisfazer um critério, tendo satisfeito outro.

• Eficáciao Capacidade que um critéiro possui de detectar erros

� Estratégia Incremental de Teste� Ambiente de Teste, Depuração e Manutenção de Software

•41

Copyright ght2004


Testes e RequisitosTestes 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)

Copyright ght2004



� 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

•42

Copyright ght2004



� Plano de Teste

• Especificação do teste de unidadeo 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 testadaso 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 testeo 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)

Copyright ght2004



� 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.

• Cronogramao especifica o montante de tempo e esforço a ser gasto nas diferentes

atividades de teste, e o teste das diferentes unidades que foramidentificadas

• Alocação de pessoalo identifica as pessoas responsáveis pela execução das diferentes atividades.

•43

Copyright ght2004



� Plano de Teste

• EXEMPLO DE UM PLANO DE TESTE

o http://members.tripod.com/~bazman/frame.html

“por favor, perdoem os comerciais de entrada… ☺”

Copyright ght2004


ReferênciasReferências

� Beizer, B., “Software testing techniques”, 2nd ed., Van NostrandReinhold Co., New York, 1990.

� IEEE Computer Society; IEEE Std 829: Standard for Software Test Documentation; September, 1998.

� 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 Multi-organizational Knowledge”,LSO 2004.

� O’Neill, D., “What happens when you don’t have a test plan”, IV&V Australia, 1997, available at http://www.ivvaust.com.au/TestPlanning.pdf

� Pfleeger, S.L., Software Engineering; Theory and Practice.Prentice Hall 2001.

� 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 2004.

Qualidade de Software: Teste do...

Documents

Transcript of Qualidade de Software: Teste do...