Transcript
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Engenharia de software Lu´ıs A. Alexandre
UBI, 20 de Maio de 2008
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Conte´udo
I
Valida¸c˜ao e verifica¸c˜ao de software
I
Teste de software
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
V&V
I
Valida¸c˜ao: determinar se o que est´a a ser constru´ıdo est´a de acordo com os requisitos (Are we building the right product ?).
I
Verifica¸c˜ao: determinar se o que est´a a ser constru´ıdo est´a correcto (Are we building the product right ?).
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Que tempo dedicar `a V & V ?
I
O tempo a dedicar a esta fase depende de v´arios factores: I
I
I
Qu˜ao cr´ıtico ´e o software ? Quanto mais delicada a sua tarefa (sistemas m´edicos, energia, militares) mais tempo deve ser dedicado `a V & V. Existe concorrˆencia ? Se existir concorrˆencia pode ser tentador vender o software sem gastar muito tempo em V & V para ser o primeiro a chegar ao mercado. Quanto custa o software ? A software muito barato ou mesmo gratuito n˜ao se pode exigir o mesmo grau de V & V que a software caro.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Duas abordagens complementares I
Inspec¸c˜ao de software: abordagem est´atica em que se examina o c´odigo e a sua documenta¸c˜ao (requisitos, modelos, manuais).
I
A inspec¸c˜ao pode ser feita durante o ciclo de desenvolvimento em qualquer fase.
I
Teste do software: abordagem dinˆamica em que se examina o comportamento e resultados do software.
I
O teste s´o pode ser feito ap´ os a fase de implementa¸c˜ao. No caso de um desenvolvimento iterativo podem ser efectuados testes ap´os a implementa¸c˜ao de cada nova caracter´ıstica.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Tipos de teste
I
H´a dois tipos de teste que podem ser efectuados (embora a fronteira entre eles possa ser difusa): I
I
I
Teste de valida¸c˜ao: mostrar que o software cumpre os requisitos. Pode-se ainda avaliar o desempenho, a fiabilidade e o comportamento em condi¸c˜ oes operacionais. Teste de defeitos: detectar eventuais defeitos (inconsistˆencia entre o que se encontra codificado e o que foi desenhado) e n˜ao simular o comportamento real do produto.
Ap´os a detec¸c˜ao de defeitos deve ser feito o debug que ´e o processo de localiza¸c˜ao e correc¸c˜ao dos defeitos.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Vantagens da inspec¸c˜ao I
Existem 3 grandes vantagens da inspec¸c˜ao quando comparada com o teste: I
I
I
Durante o teste, alguns erros podem esconder outros erros. Quando um erro ´e encontrado nunca se tem a certeza se outros erros se ficam a dever ao processo de correc¸c˜ao de um erro ou se j´a existiam originalmente. Como a inspec¸c˜ao ´e um processo est´atico, nunca existe o problema da interac¸c˜ao entre erros. Podem ser efectuadas inspec¸c˜ oes a vers˜ oes incompletas dum sistema. Para fazer testes ´e necess´ario substituir de alguma forma as partes ainda n˜ao desenvolvidas (custo adicional). Durante a inspec¸c˜ao pode-se ainda verificar a portabilidade, a forma como est´a documentado o c´ odigo, se obedece ou n˜ao a determinados padr˜ oes ou mesmo se ser´a f´acil de efectuar a sua manuten¸c˜ao. Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Outros factos relativos `a inspec¸c˜ao I
Existem estudos que afirmam que a inspec¸c˜ao ´e melhor a detectar erros que o teste: uma inspec¸c˜ao informal pode atingir os 60% de detec¸c˜ao enquanto que uma baseada em m´etodos formais pode chegar aos 90%.
I
As inspec¸c˜oes devem come¸car cedo no processo de desenvolvimento: devem ser usadas em todas as fases desde a an´alise de requisitos.
I
Mesmo dadas estas vantagens, os gestores de projecto s˜ao muitas vezes relutantes em aplicar as inspec¸co˜es durante o desenvolvimento pois estas exigem uma sobrecarga adicional em termos de horas de trabalho. Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Equipa de inspec¸c˜ao I
A inspec¸c˜ao ´e normalmente levada a cabo por uma equipa.
I
Cada elemento da equipa tem um papel diferente (embora por vezes um elemento possa desempenhar mais de um papel). Os pap´eis t´ıpicos duma equipa de inspec¸c˜ao s˜ao:
I
I
I
I
I
Autor: aquele que escreveu o c´ odigo ou documento a inspeccionar; Leitor: apresenta o c´ odigo ou documento aos restantes membros (por vezes atrav´es da leitura do mesmo); Inspector: encontra erros, omiss˜ oes e inconsistˆencias no c´odigo ou documento em an´alise; Moderador: Gere o processo e facilita a inspec¸c˜ao. Elabora um relat´ orio da inspec¸c˜ao. Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Requisitos para a inspec¸c˜ao
I
Antes da equipa de inspec¸c˜ao come¸car a trabalhar devem estar reunidos os seguintes requisitos: I
I
I
Deve existir e estar dispon´ıvel uma especifica¸c˜ao do c´odigo em an´alise; Os membros da equipa devem estar familiarizados com os padr˜ oes a analisar; A vers˜ao do c´ odigo a analisar deve estar actualizada e ser compilavel.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
O processo de inspec¸c˜ao
I
O autor deve come¸car por descrever o que ´e suposto que o programa fa¸ca.
I
De seguida, cada membro da equipa deve estudar a especifica¸c˜ao e o respectivo c´ odigo procurando defeitos.
I
A inspec¸c˜ao conjunta, com a apresenta¸c˜ao por parte do leitor, n˜ao deve demorar mais de 2 horas.
I
A equipa n˜ao deve apresentar sugest˜ oes de como corrigir os defeitos ou sugerir altera¸c˜ oes, deve apenas indicar os defeitos numa lista.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
O processo de inspec¸c˜ao (cont.)
I
Muitas vezes os erros s˜ao atribu´ıdos a diferentes categorias constantes duma tabela pr´e-definida e que muitas vezes ´e dependente da linguagem de programa¸c˜ao.
I
Ap´os a inspec¸c˜ao o autor deve corrigir os defeitos detectados.
I
O Moderador da equipa deve ent˜ao avaliar se ser´a ou n˜ao necess´aria uma re-inspec¸c˜ao. Deve elaborar o relat´orio da inspec¸c˜ao.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Tabela de inspec¸c˜ao I
Os defeitos podem ser classificados num dos seguintes grupos (com alguns exemplos): I
I
I
I
I
Dados: vari´aveis usadas antes da inicializa¸c˜ao; possibilidade de exceder os limites dos arrays; buffer overflows; Controlo: c´ odigo n˜ao alcan¸c´avel; condi¸c˜ oes de paragem dos ciclos; Entrada/sa´ıda: as vari´aveis de sa´ıda tˆem os valores correctos ?; poder˜ao alguns dados de entrada causar falhas ? Interface: todos os m´etodos tˆem o n´ umero certo de parˆametros ?; os parˆametros surgem pela ordem correcta ? Armazenamento: quando s˜ao usadas estruturas ligadas e existem inser¸c˜ oes ou remo¸c˜ oes, as liga¸c˜ oes s˜ao correctamente alteradas ?; a mem´ oria dinˆamica foi previamente reservada ?; a mem´ oria dinˆamica est´a a ser libertada ap´ os o seu uso ? Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
N´umeros relativos ao processo de inspec¸c˜ao
I
Num estudo de 1994, baseado em processos de inspec¸c˜ao de c´odigo para telecomunica¸c˜ oes concluiu-se que: I
I
I
O autor consegue apresentar cerca de 500 linhas de c´odigo por hora. Durante o estudo individual s˜ao examinadas cerca de 125 linhas por hora. Durante a inspec¸c˜ao conjunta s˜ao inspeccionadas entre 90 a 125 linhas por hora.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
V&V Que tempo dedicar ` aV&V? Inspec¸c˜ ao e teste Tipos de teste Inspec¸c˜ ao Outras formas de inspec¸c˜ ao
Outras formas de inspec¸c˜ao
I
Al´em da inspec¸c˜ao referida anteriormente, podemos ter outras duas variantes que n˜ao iremos aprofundar mas apenas referir: I
I
Inspec¸c˜ao autom´atica: neste caso s˜ao usados programas que detectam automaticamente alguns dos tipos mais comuns de defeitos. Exemplo: lint para a linguagem C. M´etodos formais: a ideia ´e representar de forma matem´atica (formal) a especifica¸c˜ao do c´ odigo e efectuar, tamb´em usando matem´atica, a verifica¸c˜ao da consistˆencia entre o c´odigo desenvolvido e a respectiva especifica¸c˜ao. Processo muito demorado e complexo usado apenas para sistemas cr´ıticos.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Teste
I
O teste de software pode dividir-se em duas actividades: o teste de componentes e o teste do sistema.
I
O objectivo do teste de componentes ´e detectar defeitos em componentes, que podem ir desde fun¸c˜ oes individuais at´e m´odulos, passando por objectos.
I
O teste do sistema ´e feito para determinar se o sistema cumpre os requisitos e se n˜ao se comporta de formas inesperadas. Os defeitos que escapam ao teste de componentes surgem normalmente nesta fase.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Teste (cont.) I
O teste de software pode tamb´em dividir-se nas vertentes de: teste de valida¸c˜ao e teste de defeitos.
I
Um teste de valida¸c˜ao com sucesso ´e um em que o sistema se tenha comportado correctamente.
I
Um teste de defeitos com sucesso ´e um em que seja detectado um defeito no sistema.
I
A actividade de teste ´e muito importante mas n˜ao pode dar garantias (n˜ao ´e uma demonstra¸c˜ao): assim, o teste pode apenas mostrar a existˆencia de erros, nunca a sua ausˆencia.
I
A fun¸c˜ao do teste ´e dar mais confian¸ca quer aos produtores quer aos clientes do software. Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Teste de componentes I I
´ normalmente feito pelo pr´ E oprio programador. Alguns erros comuns em termos de componentes: I
I
I
Mau uso do interface dum componente: n´ umero, tipo ou ordem dos parˆametros usados n˜ao ´e o correcto; M´a interpreta¸c˜ao do interface dum componente: o componente que usa outro n˜ao passa os parˆametros de acordo com o que seria de esperar. Ex.: um objecto que fa¸ca pesquisa bin´aria necessita dum vector ordenado; se lhe for passado um vector n˜ao ordenado a pesquisa n˜ao ser´a executada. Erros de temporiza¸c˜ao: podem ocorrer em sistemas de tempo-real. Ex.: o componente produtor de informa¸c˜ao n˜ao trabalha `a mesma velocidade que o que a recebe.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Sugest˜oes para teste de componentes
I
Listar explicitamente todas as chamadas externas que o componente efectua. Desenhar testes em que os parˆametros para essas chamadas assumam os valores extremos dos seus limites.
I
Quando s˜ao passados apontadores como parˆametros, testar sempre os casos em que os apontadores s˜ao nulos.
I
Desenhar testes que simulem a falha de um componente.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Sugest˜oes para teste de componentes (cont.)
I
Usar teste de stress. Ex.: submeter o componente a uma carga muito maior que aquela que enfrentar´a na aplica¸c˜ao real.
I
Quando v´arios componentes partilham mem´ oria, desenhar testes em que os diferentes componentes s˜ao activados por ordem diferente. Isto permite encontrar hip´ oteses impl´ıcitas efectuadas pelo programador sobre a ordem pela qual os dados seriam produzidos e consumidos pelos componentes.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Teste de sistema I
I
´ normalmente realizado por uma equipa independente E daquela que fez o c´ odigo. ´ E baseada numa especifica¸c˜ao escrita do sistema.
I
Quando o sistema ´e constru´ıdo a partir de componentes pr´e-existentes e da configura¸c˜ao de software j´a existente n˜ao existe teste de componentes: apenas teste de sistema.
I
Este tipo de teste ´e apenas funcional: apenas se avalia se o comportamento do sistema corresponde ao que est´a especificado. O sistema ´e tratado como uma caixa negra (´e irrelevante nesta fase a forma como foi implementado).
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Sugest˜oes para teste de sistema
I
Usar entradas que permitam activar todas as mensagens de erro do sistema.
I
Usar entradas que poderiam causar buffer overflows.
I
Repetir a mesma entrada ou conjunto de entradas muitas vezes.
I
For¸car a gera¸c˜ao de sa´ıdas inv´alidas.
I
For¸car c´alculos com valores muito pequenos e muito grandes.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Desenho de casos de teste I
I
O objectivo do desenho de casos de teste ´e a constru¸c˜ao de pares entrada/sa´ıda que permitam detectar defeitos e mostrar que o sistema cumpre os requisitos. Existem 3 abordagens `a constru¸c˜ao de casos de teste: I
I
Teste baseado em requisitos: os casos de teste s˜ao desenhados para testar o cumprimento dos requisitos. Teste de parti¸c˜ oes: s˜ao identificadas parti¸c˜ oes de entrada e de sa´ıda e desenvolvidos os testes para que o sistema receba dados de todas as parti¸c˜ oes e gere resultados em todas as parti¸c˜ oes. Uma parti¸c˜ao ´e um grupo de dados com caracter´ısticas comuns como todos os n´ umeros negativos, ou todos os nomes com menos de 40 caracteres. Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Teste de Teste de Teste de Desenho Desenho
software componentes sistema de casos de teste de casos de teste
Desenho de casos de teste (cont.)
I I
Teste estrutural: ´e usado conhecimento da estrutura do programa para criar testes que fa¸cam executar todos os componentes do sistema. Idealmente todas as instru¸c˜oes deviam ser executadas.
Lu´ıs A. Alexandre
Engenharia de software
Valida¸c˜ ao e verifica¸c˜ ao de software Teste de software Conclus˜ ao
Leituras complementares
Leituras complementares
I
Sommerville: cap. 22 (valida¸c˜ao e verifica¸c˜ao), cap. 23 (teste)
Lu´ıs A. Alexandre
Engenharia de software
