Post on 09-Nov-2018
•1
Qualidade de Software:Qualidade de Software:Teste do ProdutoTeste do Produto
Guilherme Horta Travassosght@cos.ufrj.br
Gladys Machado Pereira Santos Limagladysmp@cos.ufrj.br
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
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
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste 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 14598-5).
•6
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Garantindo a Qualidade do Garantindo a Qualidade do SoftwareSoftware
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Garantindo a Qualidade do Garantindo a Qualidade do SoftwareSoftware
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste 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
•8
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste 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
•9
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Garantindo a Qualidade do Garantindo a Qualidade do SoftwareSoftware
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
• Inexistência de erro:o Software é de alta Qualidade?, ou;o Teste é de baixa Qualidade?
?D P
XT
•11
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Garantindo a Qualidade do Garantindo a Qualidade do SoftwareSoftware
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Garantindo a Qualidade do Garantindo a Qualidade do SoftwareSoftware
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
� 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.)
Teste de SoftwareTeste de Software
•13
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste 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!
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de Software Teste de Software -- FasesFases
• 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de Software Teste de Software -- FasesFases
• 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de Software Teste de Software -- FasesFases
Unidade
Integração
Perspectiva dos projetistas
Funcional
Desempenho
Aceitação
Instalação
Perspectiva do Cliente
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
• Funcionalo Ignora a estrutura do sistemao Foco na funcionalidade
Gerência de Configuração(controle de versões)
Sistema = Funcional + Desempenho
•18
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de Software Teste de Software -- FasesFases
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de Software Teste de Software -- FasesFases
• 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de Software Teste de Software -- FasesFases
• 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de Software Teste de Software -- FasesFases
• 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Teste de SoftwareTeste de Software
?
?
•21
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Projeto de Casos de TesteProjeto 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 finitoo ii) o custo de aplicação deve ser razoável
•23
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Projeto de Casos de TesteProjeto 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
•24
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Projeto de Casos de TesteProjeto de Casos de Teste
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Projeto de Casos de TesteProjeto 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á-lasde forma complementar.
•25
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica Funcional: ExemploTé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
•27
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
TesteTeste FuncionalFuncional
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica Funcional: ExemploTé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);
a123456 (inválido)
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica Funcional: ExemploTécnica Funcional: Exemplo
• 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
TesteTeste FuncionalFuncional
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
TesteTeste FuncionalFuncional
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica EstruturalTé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
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
/* 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 */ }
Identifier.c
•33
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica EstruturalTécnica Estrutural
� 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, 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
...
•34
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica EstruturalTécnica Estrutural
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}
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Análise de MutantesAná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.
•36
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Análise de MutantesAnálise de Mutantes
� ∃ 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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.
Análise de MutantesAnálise de Mutantes
� Hipótese do Programador Competente
� Efeito de Acoplamento
•37
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Análise de MutantesAnálise de Mutantes
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Análise de MutantesAná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)
•38
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Análise de MutantesAná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
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Análise de MutantesAnálise de Mutantes
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Análise de MutantesAná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
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica EstruturalTé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 independenteo qualquer caminho do programa que apresenta pelo menos um novo
conjunto de comandos processáveis ou uma nova condição.
•40
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Técnica EstruturalTé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 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste 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
•42
Copyright ght2004
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste 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.
• 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
Teste de SoftwareTeste de Software
� 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
Engenharia de Software Experimentalwww.cos.ufrj.br/~ese
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.