Técnicas para a validação de sistemas de software Ana de Alencar Price Instituto de Informática...

Técnicas para a validação de sistemas de software

Ana de Alencar Price

Instituto de Informática - UFRGS

Teste de SoftwareTeste de Software

Tópicos a serem Abordados

Certificação de Software Príncipios do TesteEstratégias de TesteTeste FuncionalTeste EstruturalTeste SimbólicoTeste de Software Orientado a Objetos Ferramentas de apoio ao Teste

Bibliografia G. Myers. The Art of Software Testing R. Pressman. Software Engineering R. Fairley: Software Engineering Concepts W. Hetzel. The Complete Guide to Software Testing Artigos de periódicos:

• Transactions on Software Engineering• IEEE Software• Comm. Of The ACM

• Fatores de qualidade

– correto, confiável

– completo, consistente, preciso

– eficiente, factível

• Técnicas de Certificação

– Análise Estática

– Análise Dinâmica = Teste

– Teste Simbólico

– Verificação Formal => Software Correto

Avaliação de Qualidade de Software

Análise Estática

análise do código fonte sem executá-lo

Inspeções • entender o programa para descobrir erros

Walkthroughs • execução simulada do programa

“Teste consiste em executar o programa com a intenção de encontrar erros” [Myers]

verificação incompleta

não garante a inexistência de erros no programa

pode ser usado para mostrar a presença de erros, mas nunca sua ausência [Dijkstra]

Teste de Software

consiste em executar o programa com dados simbólicos ao invés de dados reais

valores de variáveis resultam em fórmulas

predicados de caminho = conjunção de condições do caminho executado

predicados de caminho => deteminar dados que exercitam os caminhos lógicos do programa

Teste Simbólico

• especificação formal do programa

• provador de teoremas: demonstrar matematicamente que o programa satisfaz as especificações

• aplicações restritas, programas pequenos

• provas formais são difíceis

• programadores não treinados

• possibilita a inserção de erros na demonstração

• cara e demorada

• vantagem: quando usada corretamente garante a correção ou não do programa

Verificação Formal

Esforço por Atividade

AnáliseProjeto

Codificação eAuditoria

Teste eIntegraçao

Command-control SAGE-NTDS

35% 17% 48%

Command-control TRW

46% 20% 34%

Sapceborne34% 20% 46%

OS/36033% 17% 50%

Científico TRW

44% 26% 30%

Comercial Raytheon

44% 28% 28%

Custo do Teste

Custo do Teste

• 30-50% do custo de desenvolvimento

• causas: – falta planejamento, tempo escasso

– falta metodologia

– inserção de novos erros

• ponto crucial: seleção de dados

• dados de teste óbvios, randômicos, viciados

• seleção adhoc ou randômica: segmentos de programas não testados

• casos de teste rigorosamente selecionados

Teste Exaustivo

nodos = blocos de comandos sequenciais

arcos = fluxo de controle

número de caminhos:5 +(5x5)+...=1.0E14

1 a 20

PROBLEMA

Determinar casos de teste (dados+resultados esperados) para o seguinte programa:

O programa lê três valores inteiros que devem corresponder aos lados de um triângulo. • Caso não sejam, o programa deve emitir a mensagem:

“não é triângulo”. • Caso contrário, o programa emitirá mensagem

identificando o tipo de triângulo (“equilátero”, “isósceles”, ou “escaleno”).

Assumir que os três valores são digitados e são inteiros.

Casos de testes para o programa do Triângulo

1) 1 caso válido para triângulo equilátero “equilátero”

2) 1 caso válido para triângulo escaleno “escaleno”

3) 3 casos válidos para triângulo isósceles “isósceles”

4) 3 casos para testar Li + Lj < Lk “não é triângulo”

5) 3 casos para testar Li + Lj = Lk “não é triângulo”

6) 3 casos para testar um dos lados = 0 “não é triângulo”

7) 3 casos para testar um dos lados < 0 “não é triângulo”

não planeje o teste assumindo que o programa está correto

um bom caso de teste é aquele que tem alta probabilidade de encontrar erro ainda não descoberto

caso de teste bem sucedido é aquele que detecta erro ainda não descoberto

a probabilidade de existência de mais erros numa parte do programa é proporcional ao número de erros já descoberto na mesma

Princípios do Teste [Myers]

teste deve ser feito por outra pessoa que não o autor do programa

dados de teste devem ser definidos para dados inválidos e não-esperados

determinar SEMPRE os resultados esperadosverificar cuidadosamente os resultados de cada testenunca jogue fora casos de teste, a não ser que esteja

jogando fora também seu programa

Princípios do Teste [Myers]

• Objetivo:

“Executar o programa com a intenção de descobrir erros” [Myers]

• Suposição incorreta:

“Mostrar que o programa funciona corretamente”

• Depuração:

“Processo para identificar, localizar e corrigir erros”– custo/esforço de difícil previsão

– tempo para identificar um erro: minutos, horas, dias

Teste de Software

Fluxo de informações na Fase de Teste

TesteDepuração

Avaliação Teste

Avaliação Qualidade

Configuração do Sistema

Configuração de Teste

programafonte

correções

resultados

plano/casosde teste

resultadosesperados análise

dos erros

modificações

erros

aceitação do sistema

Análise eEspecificaçãode Requisitos

Projeto

Implementação

Teste

Manutenção

planejamento

execução

avaliação

Teste

Teste

unidadeintegraçãoaceitaçãosistema

estrututralfuncionalmutaçao

Atividades do Processo de Teste

determinar casos de teste• escolher estratégia, critério (conclusão dos testes)• selecionar dados e determinar resultados esperados

executar os testes• montar cenários (drivers e stubs)• instrumentar programa (asserções, sinalizadores)

avaliar os resultados• comparar resultados computados c/esperados• avaliar a satisfação do critério

Seleção de Dados de Teste

• atividade mais crítica do processo

• dados devem ser selecionados para encontrar erros

• teste de sucesso {Myers]

=> aquele que encontra erro

• seleção depende da estratégia de teste

• funcional (black-box)

• estrutrural (white-box)

• mutação

• Funcional ou Caixa-preta– baseado na Especificação de Requisitos

– verifica se as funções do produto são realizadas adequadamente

• Estrutural ou Caixa-aberta– baseado no código fonte

– verifica quais funções foram implementadas

• Mutação ou Teste baseado em erros– introduzir modificações num programa P, suposto

correto, criando-se mutantes, que se executados resultarem em erro, pode-se dizer que P está correto

Tipos de Teste

Teste Randômico

dados gerados randômicamente elevado número de dados de teste problema: determinar os resultados esperados certas condições podem não ser testadas trabalhos comprovam eficácia

Teste Funcional

DADOS RESULTADOS

• dependente da especificação de requisitos

• seleção de dados baseada nas condições de entrada

• avaliação de cobertura das funcionalidades

Teste Estrutural

DADOS RESULTADOS

• teste de caminho

• dependente do código fonte

• grafo de fluxo de controle

• critérios de cobertura de caminhos

Estágios de Teste

• Teste de Unidade– assegurar que cada módulo funciona apropriadademente

• Teste de Integração– montagem do software e verificação das interfaces

• Teste de Aceitação– assegurar que o software satisfaz os requisitos do usuário

• Teste de Sistema– integração do software com outros sistemas

Teste de Unidade

• teste de caixa aberta (estrutural)

• conduzido em paralelo para vários módulos

• características avaliadas– interface

– operações sobre variáveis

– caminhos de execução importantes

– caminhos de atendimento a erros

– condições de contorno

Teste de Unidade: características avaliadas

• interface– dados entram e saem corretamente

– número e tipo de parâmetros - compatibilidade

• operações sobre variáveis – cálculos incorretos

– over/underflow, índices, etc.

• caminhos de execução – caminhos importantes

– caminhos de atendimento a erros

• atendimento a erros– rotina de erro corresponde ao erro encontrado– erro causa intervenção do sistema antes do atendimento– mensagem elucida causa do erro?

• condições de contorno– testes com valores máximo, mínimo, imediatamente

abaixo e acima de itens de dados e de variáveis de controle de “loops”

• erros comuns– precedência de operadores incorreta– comparações de tipos de dados diferentes– terminação inexistente de ciclos– erros de precisão

Teste de Unidade: características avaliadas

Ambiente para Teste de Unidade

driver

módulo

stubstub

Cenários de Teste driver

• módulo que chama o módulo em teste • contém inicializações das variáveis globais e dos parâmetros reais da

chamada

stubs• módulos chamados pelo módulo testado

• contém comandos para recebimento de parâmetros de entrada e devolução de valores de saída

Planejamento do Teste de Unidade

• escolha de critério de cobertura lógica

• selecionar caminhos de teste

• determinar casos de teste

• caso de teste– dado de teste

– resultado esperado

Teste de Integração

• montagem do software com módulos já testados

• verificação da interface entre módulos

• funções parciais e global do sistema

• estratégias de integração– topdown

– bottom-up

– mista

Integração Topdown

• integração parte do módulo principal para os módulos que implementam funções primitivas

• tipos:– vertical: segundo o fluxo principal de controle

– horizontal: incorpora todos os módulos diretamente subordinados a cada nível

M1

M2 M3 S4

S7M5 M6

M8

• módulo principal usado como driver

• módulos diretamente subordinados substituídos por stubs

• stubs são substituídos um de cada vez

• testes de regressão asseguram que não houve introdução de novos erros

Integração Top-down

• módulos inferiores combinados em grupos• drivers são escritos para testar grupos• drivers são substituídos por módulos integradores de

grupos

Integração Bottom-up

M1

D1 D2 D3

M8

M8

cluster #1 cluster #2 cluster #3

top-down• programa principal + alguns módulos = protótipo• erros de interface são descobertos cedo• erros em módulos critícos de níveis inferiores são

descobertos tarde• no início requer pouca mão-de-obra

bottom-up• erros em módulos critícos de níveis inferiores são

descobertos tarde• ajuste mais fácil das necessidades de mão-de-obra ao

pessoal disponível• erros de interface são descobertos tarde• muitos módulos precisam ser integrados antes que se

tenha uma idéia do programa

Topdown X Bottom-up

Teste de Integração

seleção de estratégia• características do software• cronograma do projeto• enfoque combinado

Teste Misto• Topdown modificado• Sandwich• Big-bang

Teste de Integração MistoTop-down Modificado

• módulos críticos são testados com drivers em paralelo à integração topdown

Sandwich• teste realizado a partir das extremidades• drivers e stubs são necessários

Big-bang• integração de todos os módulos ao mesmo tempo• dificuldade de descobrir origem dos erros

Plano de Integração

• fluxo de controle do sistema

• estratégia de integração

• ordem de acoplamento

• determinar casos de teste

• gerar drivers e stubs

Testes de Aceitação e de Sistema

• Teste de Aceitação– demonstrar conformidade com a Especificação de

Requisitos

– testes funcional e de desempenho

• Teste de Sistema– teste de integração com outros sistemas (software

e hardware)

– teste de aceitação conduzido pelo usuário final

Plano de Teste do Software

• Conteúdo– Plano de Teste de cada unidade

– Plano de Integração

– Plano para o Teste de Aceitação e de Sistema

• Benefícios do Plano de Teste– indução ao teste sistemático

– facilita testes de regressão

– facilita manutenção

– facilita teste de integração quando da evolução do sistema

Teste: fase fundamental no desenvolvimento de software.

Teste e manutenção consomem 60% dos recursos de desenvolvimento

Escassez ferramentas CASE para suporte destas fases Desenvolvimento de métodos e ferramentas Avaliação de Qualidade - parte da rotina, ao invés de

procedimento especial.

Considerações Finais