Testes de Sistema

3,723 views

Published on

Baixe mais arquivos em http://pastadomau.wikidot.com.
Este trabalho tem como objetivo mostrar a importância dos testes no desenvolvimento estruturado de software, passando pelas fases desta etapa e os tipos de teste utilizados em cada fase. Aborda também os métodos para uma correta aplicação dos testes de forma eficiente, visando a produção de um sistema com qualidade.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,723
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
74
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Testes de Sistema

  1. 1. UNIVERSIDADE LUTERANA DO BRASILCENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO TESTES DE SISTEMA MAURICIO VOLKWEIS ASTIAZARA IGOR CASA NOVA DOS SANTOS Engenharia de Software I Torres, Junho de 2001
  2. 2. Introdução Este trabalho tem como objetivo mostrar a importância dos testes no desenvolvimentoestruturado de software, passando pelas fases desta etapa e os tipos de teste utilizados em cadafase. Aborda também os métodos para uma correta aplicação dos testes de forma eficiente,visando a produção de um sistema com qualidade.
  3. 3. Testes1 Objetivo O propósito dos testes é evitar “surpresas desagradáveis” depois que o sistema entra emfuncionamento. O propósito da análise estruturada é evitar surpresas desagradáveis nos testes.Os dois estão intimamente relacionados.2 Tipos de Teste Durante as quatro fases de teste de um projeto são aplicados testes que podem serclassificados em duas categorias: Testes Estruturais e Testes Funcionais. Antes de entrarmosnas fases do teste veremos como são caracterizados estes dois tipos de teste. 2.1 Testes Estruturais São também chamados de testes de Caixa Branca. Preocupam-se em verificar como asfunções são implementadas. Assim além de detectarem o erro, podem ajudar de modosignificativo na sua correção. São constituídos de atividades de verificação que normalmenteincluem a análise da especificação do projeto, do código do programa e do fluxo de dados.Esse tipo de análise é classificada como estática, pois o programa não ou módulo nãonecessita necessariamente estar em execução para que ela sejam efetuadas. Os testes estruturais procuram analisar como as funções são implementadas Os testes estruturais podem ajudar a descobrir funções ausentes no programa, erro nasexpressões aritméticas, declaração de tipos necessária, diferenças entre áreas de dadoscompartilhadas, erro nas interfaces de módulos (parâmetros) e não cumprimento de padrões. Exemplos de técnicas aplicadas no testes estruturados:• Análise da estrutura de controle;• Técnicas baseadas em lógica matemática;• Inspeções;• Testes de mesa;• Programas verificadores de estrutura;• Teste baseado na cobertura: é aquele em cada comando do módulo é executado ao menos uma vez;• Teste baseado na cobertura de desvios: testa cada decisão e segue todos os desvios da decisão;• Teste da cobertura dos caminhos DD: um caminho DD é a seqüência de comandos que se inicia no resultado de uma decisão e termina na próxima decisão;• Teste baseado na complexidade: procura orientar o esforço do teste para as partes mais complexas do código, onde é mais provável a existência de erros. Para métrica da
  4. 4. complexidade utiliza-se uma das diversas técnicas existentes como a métrica de Halstead, número ciclomático de complexidade de McCabe e a complexidade da variável de controle de McClure. 2.2 Testes Funcionais São também chamados de testes Caixa Preta. Preocupam-se em testar se as funçõesrealizam as tarefas corretamente independente do modo como o façam (só interessa se asrespostas estão corretas ou não). Estes testes são executados depois do teste de estrutura e temcomo objetivo validar o que foi feito na etapa anterior, aprovando ou não. Os testes funcionaissão realizados com o programa ou módulo em execução, por isso é chamado de análisedinâmica. O processo de um teste funcional envolve os seguintes passos:1 Selecionar um conjunto de dados de entrada com os quais se executará o programa;2 Determinar a saída que se espera ser produzida;3 Executar o programa;4 Comparar os resultados produzidos pelo programa com o que era esperado. Passos para a realização de um teste funcional. Diferentes aspectos da funcionalidade do programa devem ser testados nesta fase e paracada um deles existe uma metodologia para a produção de dados de teste (primeiro passo,acima). Por isso os testes funcionais se dividem nas seguintes etapas:1 Teste de Via Normal (ou Caminho Normal)2 Teste de Via de Erro (ou Caminho de Exceção)3 Teste de Estado Transiente4 Teste de Desempenho (ou Performance)5 Testes Especiais 2.2.1 Teste de Via Normal Este teste é derivado do Dicionário de Dados. Consiste em gerar um grupo de entradasválidas para verificar se o sistema executa o que foi exigido na especificação estruturada. Casos de teste devem ser derivados para cada item no dicionário de dados e para cadafluxo de dados composto seguindo o que foi especificado no dicionário de dados. Gerar todasas possibilidades de dados para cada item é impossível, ao invés disso devemos concentrar ostestes nas chamadas situações limite, que pode ocasionar a maior parte dos erros. Pode-seainda acrescentar um valor intermediário, com a objetivo de abranger todas as faixas devalores (inferior, médio e superior). Em geral as situações limite devem ser testadas nosseguintes aspectos: • Limites de Entrada: limites superiores, inferiores e outros associados com as entradas do sistema. A finalidade destes testes é verificar se o sistema aceitará
  5. 5. entradas dentro dos limites da especificação. Por exemplo: se a especificação indica que uma entrada do sistema deve ser uma string de 1 a 40 caracteres devemos testar se o sistema funcionará com strings de 1, 20, 39 e 40 caracteres. • Limites de Saída: limites superiores, inferiores e outros associados com as saídas do sistema. Por exemplo: se um sistema de folha de pagamento que supostamente deve ser capaz de produzir contracheques de seis dígitos, obviamente é uma boa idéia construir-se casos de teste que produzam este tipo de contracheque. • Limites Funcionais: para assegurar que as funções descritas na especificação do processo sejam executadas corretamente em situações limite. Por exemplo, um módulo OrdenaTab que ordena uma tabela de itens. Os limites funcionais seriam testados utilizando-se uma tabela vazia, uma tabela com somente um item, uma com itens já ordenados, uma com itens iguais e outra com o limite máximo de itens (se houver). Uma vez definidos os conjuntos de valores válidos para cada item do dicionário dedados, eles devem ser combinados gerando uma gama de valores de entrada para o teste devia normal. Isso poderia ser feito utilizando-se um banco de dados com os conjuntosescolhidos e aplicando-se a operação de produto cartesiano sobre eles. Em alguns casos otamanho deste banco de dados pode tornar-se um transtorno, não sendo viável realizar o testecom todos os valores obtidos ou até mesmo não sendo possível completar o banco de dados.Mesmo nesses casos a equipe deve estar ciente que o sistema deve ser capaz de manipularqualquer uma dessas entradas. Tomemos agora um exemplo prático de teste de via normal para entrada a partir de umdicionário de dados simples, que segue a seguinte notação: Símbolo Significado= É composto de+ E<min>{ }<max> Iteração (mínimo, tipo de dado, máximo)<valor1> – <valor2> Intervalo de valores[<valor1>|<valor2>|<valorN>] Escolha Múltipla Dicionário Exemplo:Cod_quarto = 1 – 1000Status = [ “vago” | “ocupado” ] A partir do que está especificado neste dicionário podemos derivar os seguintesconjuntos de dados válidos:Cod_quarto =(1, 500, 1000)Status = (“vago”; “ocupado”) Combinando-se os valores obtemos as seguintes entradas válidas: Cod_quarto Status1 “vago”500 “vago”1000 “vago”
  6. 6. 1 “ocupado”500 “ocupado”1000 “ocupado” 2.2.2 Testes de Via de Erro Semelhante ao de via normal, porém entra com dados inválidos no sistema para avaliarseus tratamentos de erros, que deve ser recusá-los, evitando a produção de saídas inválidas ouaté mesmo o travamento do sistema. Esses dados inválidos são geralmente de dois tipos: 1 Casos que infrinjam os limites de entrada (citados nos testes de via normal) como porexemplo, para uma entrada de valor numérico que deve ser um valor de 1 a 10, um conjuntode dados inválidos para teste poderia ser –1,0,11,15. 2 Valores incompatíveis com o tipo de dado esperado, como por exemplo, para a mesmaentrada numérica acima o conjunto de dados poderia ser 1A, w, #?, (vazio). Cada conjunto de dados inválidos substituirá o seu respectivo conjunto de valoresnormais de cada vez, que foram usados no teste anterior (via normal). Efetua-se a combinação(produto cartesiano) nesse novo arranjo de conjuntos obtendo-se um conjunto de entradasinválidas, que contém um único erro (que está no item que teve seu conjunto normalsubstituído pelo inválido). Somente um conjunto de dados inválidos será combinado com o devias normais de cada vez, produzindo um único erro por entrada. Não se deve produzirentradas com combinações de erros ou entradas com um dado com múltiplos erros. Seguindo o mesmo dicionário do exemplo anterior, podemos estabelecer os seguintesconjuntos de dados inválidos:Cod_quarto = (0, 1001, “M#”)Status = (“vag1”, 2) Iniciamos a substituição pelo do primeiro item de dado (Cod_quarto) e efetuamos acombinação com os dados válidos. Assim se seguirá com o resto dos conjuntos. Cod_quarto Status0 “vago”1001 “vago”“M#” “vago”0 “ocupado”1001 “ocupado”“M#” “ocupado” 2.2.3 Teste de Estado Transiente Os testes derivados até agora seriam suficientes para testar um sistema que não tivessenenhuma memória, que tratasse cada entrada de modo independente do que tivesse acontecidoantes. Porém para sistemas com vários estados transientes será necessário agrupar os testesem seqüências. A seqüência de testes pode ser organizada para forçar o sistema em cada umdos estados possíveis e testar o seu desempenho nesse estado. Para derivar um conjunto
  7. 7. completo de seqüências de teste deve-se listar os estados em memória para cada fluxo dedados de entrada e realizar uma seqüência de teste para cada estado. 2.2.4 Teste de Desempenho Visa verificar se os requisitos de tempo e volume especificados na análise foramrealmente atendidos. Este tipo de teste é essencial para grandes sistemas em-linha, mas podeser desnecessário para pequenos sistemas em lote ou para qualquer tipo de sistema em que ohardware seja uma pequena parte do custo geral do sistema, e que seja facilmente expansível(por exemplo adicionando mais memória ou atualizando o processador). Na maioria dos casos de teste de desempenho preocupa-se com o rendimento, tempo deresposta e capacidade de banco de dados. Pode não ser prático ou mesmo possível criarentradas reais suficientes e carga suficiente no novo sistema para verificar se o seudesempenho é satisfatório, porém pode-se utilizar uma série de técnicas de simulação. Pode-se enganar o sistema em operação como se ele tivesse um pesado volumereduzindo o hardware disponível. Por exemplo rodar o sistema em máquina com somente8MB de memória ao invés de 64MB. Outra maneira é a partir de um pequeno volume de dados efetuar centenas de cópias ouaté milhares para se obter o volume necessário. Naturalmente essas simulações são subterfúgios não garantem a geração de resultadosperfeitos. 2.2.5 Teste Especiais Seria ingenuidade pensar que qualquer sistema, independente de sua complexidade,poderia ser completamente testado na sua funcionalidade pelos testes descritos anteriormenteque são derivados da especificação estruturada. Alguns precisam claramente de testesadicionais para lidarem com suas naturezas particulares. Já que estes testes não podem serderivados da especificação estruturada eles devem ser colocados explicitamente naespecificação estruturada antes que ela seja considerada completa. Isto manterá o conceito deque todos os testes têm como base a especificação estruturada.3 Fases do teste A abordagem estruturada teve grande influência na etapa de teste, assim como nasoutras fases de desenvolvimento de software. O teste tem sido formalizado como umprocedimento de quatro fases como descrito abaixo. 3.1 Teste de Unidade O teste de unidade consiste em se aplicar o teste estruturado e o teste funcional paracada função, sub-rotina ou módulo. O teste de unidade normalmente é realizado peloprogramador como parte da etapa de codificação. O teste de unidade sozinho não garante que ao unirmos os módulos testados teremos umsistema funcionando com sucesso, mas garante que módulo testado chegue a fase deintegração cumprindo o seu objetivo lógico, a sua função.
  8. 8. No teste de Unidade cada módulo é testado individualmente quanto a estrutura e funcionalidade 3.2 Teste de Integração O teste de integração consiste em se aplicar o teste estruturado e o teste funcional sobreuma hierarquia de módulos, como um subsistema ou o sistema completo. O objetivo do testede integração é verificar se cada módulo funciona corretamente dentro da estrutura decontrole e checar se as interfaces dos módulos (a comunicação entre eles) estão corretas. Nos teste de integração é checada a comunicação (dados, controles) entre módulos. O teste de integração tem diferentes abordagens: bottom-up, a top-down, e a middle-outsão as básicas, mas existem outras variações. A seguir veremos mais detalhadamente cadauma delas. 3.2.1 Bottom-up O nome desta estratégia significa do fundo para cima e segue este princípio naintegração dos módulos, iniciando pelos módulos de nível mais baixo de forma ascendente atéchegar aos níveis mais alto. Direção da integração na abordagem Bottom-up Esta estratégia de integração requer a construção de acionadores, que é um módulotemporário responsável pelo teste. O acionador chamará o módulo que esta sendo testadopassando-lhe como parâmetro os dados do teste e recebendo o que o módulo retorna (se omódulo testado precisa de parâmetros ou retorna valores). A estratégia Bottom-up tem apresentado vários problemas à fase de integração: • acionadores podem exigir grande esforço pra serem desenvolvidos de modo a simularem de modo fiel o sistema, além disso podem ser uma fonte adicional de erros; • as funções de alto nível do programa são testados por último, retardando a descoberta de erros que podem ser cruciais; • erros de interface podem aparecer muito tarde, aumento de forma proporcional a dificuldade de correção. 3.2.2 Top-down
  9. 9. Na estratégia top-down (do topo para baixo) os módulos de alto nível são integrados etestados em primeiro lugar. Desse modo o teste segue de modo descendente na estruturahierárquica. O teste top-down requer a criação de módulos temporários chamados stubs. Omódulo stub representa o módulo de nível logo abaixo do módulo que está sendo testado. Amedida que o teste continua e se desce na estrutura, cada stub é substituído pelo módulo real enovos stubs para esse módulo são criados. Direção da integração na abordagem Top-down Os módulos stubs podem ser de diversos tipos, cada tipo pode auxiliar de mododiferente no teste do sistema:• Não executar nada. Não é muito útil mas fácil de implementar;• Exibir uma mensagem indicando que foi chamado. Útil para verificação do fluxo de controle do sistema;• Exibir um terminal, permitindo que o responsável pelo teste passe dados e tempo de execução para o módulo superior;• Retornar um valor constante, um número aleatório ou um número de uma tabela de teste.• Ser uma versão simplificada do módulo real;• Testar ou exibir os dados com os quais foi chamado;• Aguardar certo tempo. Esse tipo de stub é útil em sistemas de tempo real ou sistemas operacionais nos quais é preciso assegurar-se de que o sistema funcionará corretamente com um módulo que consumirá, por exemplo, 19 milésimos de segundo. Também pode ser utilizado para simular o acesso a um hardware que demorou tantos milésimos de segundo para estar pronto. Substituição dos stubs pelos módulos a medida que segue o teste. A estratégia top-down oferece importantes vantagens sobre a bottom-up:• As funções de alto nível são testadas em primeiro lugar;• O teste de integração pode começar mais cedo porque os módulos de alto nível podem ser codificados em primeiro lugar e podem ser testados com stubs;
  10. 10. • Os stubs são mais fáceis de serem construídos que os acionadores. Problemas com a abordagem top-down:• Importantes funções de alto nível são testadas bem tarde no processo de desenvolvimento. Problemas nessas funções podem forçar a um tardio reprojeto de funções de alto nível;• Às vezes pode ser difícil construir os stubs simulando efetivamente o modo real. 3.2.3 Middle-out Em pequenos programas, faz pouca diferença qual abordagem de integração é usada.Neste caso, teste de unidade e teste e integração são freqüentemente combinados em umaetapa. Em grandes projetos porém, prefere-se mais formalidade na separação das etapas deteste. Prefere-se, também uma abordagem que combine as técnicas top-down e middle-out afim de minimizar seus problemas e aproveitar melhor suas vantagens. Middle-out significa domeio para fora, neste caso o meio não significa exatamente a metade da estrutura, mas sim aparte principal do projeto, que pode estar localizada em qualquer região. Abordagem Middle-out: partindo do módulo principal. Inicia-se a integração a partir dessa parte crucial e pode-se seguir tanto para cima oupara baixo, de acordo com a importância dos módulos. Dessa maneira têm-se a garantia deerros em partes importantes sejam descobertas tardiamente, forçando a uma reprojeção dosoutros módulos. Esta estratégia tem sido a que produz os melhores resultados, sendo a adotada pelamaior parte dos desenvolvedores. Existem variações sobre esta estratégia sobre comopercorrer a estrutura. 3.3 Teste de Sistema É executado após o teste de integração e é basicamente um teste funcional aplicadosobre a estrutura já integrada na fase anterior. O objetivo é descobrir implementaçõesincorretas ou falta de implementação das especificações dos requisitos e corrigi-las. As partesmais importantes do sistema e mais freqüentemente usadas devem ser testadas maisexaustivamente. 3.4 Teste de Aceitação A fases anteriores de teste serviam para detectar erros afim de corrigi-los. Mas no testede aceitação não é mais uma etapa de correção. O teste de aceitação é a mais pura forma deteste funcional, determinando se o projeto atingiu seu alvo ou não, pois o teste de aceitação éo que foi exigido na especificação (requisitos do usuário) estruturada produzida pela atividadede análise .
  11. 11. Análise  Especificação Estruturada  Geração do Teste de Aceitação O teste de aceitação é efetuado elaborando-se um plano de teste e aplicando-se o testefuncional, visto em tipos de teste, no programa, como visto abaixo:1 Elaborar Plano de Teste2 Aplicar Teste Funcional 2.1 Teste de Via Normal (ou Caminho Normal) 2.2 Teste de Via de Erro (ou Caminho de Exceção) 2.3 Teste de Estado Transiente 2.4 Teste de Desempenho (ou Performance) 2.4 Testes Especiais 3.4.1 Elaborar Plano de Teste É o passo mais importante, pois uma vez desenvolvido é usado por todas as atividadessubseqüentes. O plano de teste deve cobrir o estabelecimento do pessoal para testar o sistema,um esboço das normas de teste e um relatório de tempo estimado e recursos necessários aatividade de teste. O objetivo inicial do plano deve ser a definição de uma pessoa ou grupo de pessoasresponsável por testar o sistema. Esta pessoa (ou grupo) deve ser alguém diferente das pessoasque desenvolveram os sistema. Na verdade quanto mais afastada do projeto a pessoaresponsável, mais objetivo e profundo será o procedimento do teste. Pode-se até mesmocontratar uma organização externa (como uma firma de consultoria de software) para realizaro teste. De qualquer forma, o teste deve ser feito por alguém que entenda que o processopossui a finalidade expressa de encontrar erros e revelar falhas do sistema. Precisam ser desenvolvidos procedimentos e padrões para a construção de casos deteste, documentação de resultados, convenção de nomeação, armazenamento e recuperaçãopara grupos (ou arquivos) de dados de teste. 3.4.2 Aplicar Teste Funcional O teste funcional é aquele visto na parte de Tipos de Teste, que agora deve ser aplicadode modo global no programa de modo a validá-lo, resultando na sua aprovação ou reprovação.
  12. 12. Conclusão Durante a realização deste trabalho concluímos que a análise estruturada possibilita odesenvolvimento de software de qualidade, mas a etapa de teste é a que fornece maior retornoao desenvolvedor, tanto em relação ao atendimento dos requisitos do usuário quanto aoprogresso do projeto. Devendo portanto, receber a mesma dedicação e provimento de recursosque as outras etapas da análise estruturada.
  13. 13. Bibliografia1. YOURDON, Edward. Administrando o Ciclo de Vida do Sistema. Rio de Janeiro: Campus, 1989.2. PAGE-JONES, Meilir. Projeto Estruturado de Sistemas. São Paulo: McGraw-Hill, 1988.3. MARTIN, James; MC CLURE, Carma. Técnicas Estruturadas e Case. São Paulo: Makron, 1991.

×