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
Top Related