• Autora

    Pós-Graduando em Especialização em Informática – Ênfase Análise de Sistemas pela UFMG, Bacharel em Sistemas de Informação (2006) pela Faculdades Pitágoras (Campus Fadom), técnica em Informática (2002) e em Contabilidade (1998). Atualmente Analista de Suporte Júnior III.

  • Direitos Autorais

    Alguns dos materiais (artigos, pdf’s, link’s) disponíveis ou utilizados na edição desse Blog, foram retirados de páginas da internet. Se acaso, algum desses itens for protegido por direitos autorais, queira o detentor do mesmo, me comunicar por email e o material será imediatamente retirado ou darei os devidos créditos!
  • Categorias

  • Arquivos

  • Análise de Sistemas

    • 13,474 hits

Testes Estratégicos

Teste em Espiral

O processo de engenharia de software pode ser visto como em uma espiral. Boehm*(1988).

Teste de Unidade => Código => Teste de Integração => Projeto => Teste de Validação => Requisitos => Teste de Sistema => Engenharia de Sistemas.

Podemos visualizar este processo como:

Um caminho de ida (entrando na espiral): Engenharia de Sistemas, seguindo pelo Levantamento e Análise de Requisitos, pelo projeto (design) do Sistema e finalmente pela Codificação dos componentes.

Um caminho de volta (saindo da espiral): Teste de Unidade (teste de componentes), passamos para o teste de Integração dos Componentes, pelo teste de Validação do Sistema junto ao usuário e, finalmente, pelo Teste do Sistema no ambiente e no contexto definitivos.

Assim cada fase no caminho de ida corresponde um teste no caminho de volta.

espiral

Uma outra forma de ver este processo associado com o enfoque de Orientação para Objetos pode ser visto no diagrama a seguir proposto por como proposto por Aßmann (2005).

diagrama_teste

Teste de Unidade – (Teste de unidade, Teste unitário ou teste de componentes)

Teste individual de cada um dos componentes (programas ou módulos), procurando garantir que funcionem adequadamente (ROUILLER et Al., 2003). Em sistemas orientados para objetos estas unidades são tipicamente métodos e classes.

unidades de teste

Filosofias de Teste

Existem duas filosofias de teste de componentes:

Caixa preta é testado pela sua funcionalidade declarada (seus objetivos e assinatura, lógica do programa).

Caixa de vidro/caixa branca o código interno é inspecionado.

Teste Caixa Preta Lógica do Programa
Teste Caixa Branca Código Interno

Teste caixa preta

Também chamada de abordagem funcional concentra-se nas interfaces do software e visa mostrar que se as entradas são válidas e podem ser aceitas então as saídas são as esperadas e, além disso, a integridade dos dados é mantida. Aplicado, principalmente, aos testes de validação, sistemas e aceitação, mas também são usados nos testes unitários. Neste teste, é preciso conhecer a função específica do componente, e o teste deve ser executado para demonstrar a sua operação correta, baseada unicamente em sua especificação sem considerar a sua lógica interna.

Casos de Teste

O teste de caixa preta nos remete à questão sobre que casos de teste devem escolher para testar o componente. Como é impossível o teste exaustivo precisamos escolher dados que sejam bons representantes de conjuntos típicos e atípicos de dados.

Partições em classes de equivalência

Particione as entradas e saídas do sistema em “conjuntos de equivalência”. Por exemplo, se seu componente recebe uma entrada um inteiro de cinco dígitos entre 10.000 e 99.000, faça partições que envolvam valores típicos dentro do intervalo e nas extremidades, isto são casos na vizinhança dos conjuntos. Considere também valores atípicos, para os quais o componente deve dar uma resposta plausível, isto é, rejeitando-os ou modificando-os.

Teste da caixa branca

Abordagem estrutural e procura mostrar que os componentes internos do software (programas) realmente funcionam. Pretendem garantir que todas as estruturas, comandos e todos os possíveis caminhos do programa sejam testados. Aplica-se, principalmente, aos testes unitários e de integração. Sendo que na prática, mesmo para pequenos programas, é geralmente impossível testar todas as possibilidades, o que exige alguma estratégia de teste baseada em alguma heurística.

Teste da caixa cinza

Esta é uma recente abordagem de teste de software. Seria um ponto de equilíbrio virtual entre o teste de caixa-branca e o de caixa-preta. Neste tipo de teste o desenvolvedor dos testes não tem acesso ao código fonte da aplicação, porém tem conhecimento dos algoritmos que foram implementados, como também pode efetuar manipulações em arquivos de entrada e saída do tipo XML ou mesmo acessos ao banco de dados da aplicação para simples conferência de dados ou alteração de parâmetros considerados nos casos de teste (Wikipedia, 2006).

Asserções

Uma das formalizações para a verificação da correção de programas é com o conceito de asserções.

Embora tenham sido propostas como um mecanismo para a correção matemática de programas, a estratégia pode ser útil no processo de inspeção do código de um programa.

Uma asserção estabelece relações lógicas entre as variáveis de um programa

que devem ser satisfeitas em determinados pontos de execução do programa.

Para um comando (ou conjunto de comandos) em uma linguagem de programação, podemos estabelecer uma asserção de entrada e uma de saída.

A asserção de entrada – expressão lógica que indica as condições que são válidas antes da execução do comando (ou conjunto de comandos).

A asserção de saída indica as condições que passam a ser válidas depois da execução do comando (ou conjunto de comandos).

{AE} Verdadeira antes

Comando

{AS} Verdadeira depois

Se inicialmente a asserção AE é válida, após a execução do comando, vale a asserção AS.

Por que somente o teste caixa preta não é suficiente?

Por que precisaríamos inspecionar o código de um programa para criar casos de teste que levem em conta sua lógica interna.

Estratégias para o Teste Caixa Brancas

Veja algumas estratégias:

a) Cobertura de instruções

Na cobertura de instruções são gerados casos de teste para executar, pelo menos uma vez, todas as instruções do programa.

b) Cobertura de arestas

Geramos casos de teste para seguir, pelo menos uma vez, todas as arestas de transferência de controle no programa.

c) Cobertura de decisões

Procura-se gerar casos de teste para gerar todos os resultados de decisões elementares e combinações de decisões elementares do programa.

d) Cobertura de caminhos

Procura-se gerar casos de teste para percorrer, pelo uma vez, todos os caminhos  existentes na estrutura do programa.

É a única que se mostra mais completa e viável quando desejamos utilizar o menor número de casos de teste.

Dado um programa podemos transformá-lo em um grafo para encontrar os ciclos e em seguida calcular o número de casos de teste necessários para testar o programa pela cobertura de caminhos.

Convenções

a) Seqüência

Um conjunto de onde não haja mudança do fluxo podem ser agrupados e representados por um círculo ou um retângulo com os cantos arredondados. Um programa será então representado por uma seqüência destes símbolos.

sequencia

b) Alternativa
O fluxo pode seguir por dois caminhos alternativos.

sec) Repetição com teste no início
A repetição de um conjunto de instruções com um teste de permanência no início (enquanto) pode ser representado assim:

enquanto

d) ) Repetição com teste no final
A repetição de um conjunto de instruções com um teste de permanência no final (repita-até) pode ser representado por:

repita atée) Multiplas alternativas
A mudança de fluxo por diversos caminhos diferentes pode ser representado por:

caso

Número Ideal de Casos de teste

Como encontrar o número de casos de teste ideal para testar um programa como este?

a) Calcule o número de nós

nos

b) Calcule o número de arestas

arestas

c) Calcule o úmero de áreas (regiões) criadas no grafo

regioes

Complexidade Ciclomática

Métrica de software que fornece uma medida quantitativa da complexidade lógica de um programa.

É calculada por

V(G) = E – N + 2

Onde E = número de arestas (Edges) e N = número de nós

No nosso exemplo:

V(G) = 11 – 9 + 2 = 4

V(G) nos dá um limite superior para o número de caminhos independentes que formam o conjunto base. É fácil ver também que V(G) coincide com o número de regiões criadas no grafo. No nosso exemplo, V(G) = 4 e são quatro as regiões que descobrimos no grafo.

complexidade ciclomática

complexidade ciclomática1complexidade ciclomática2

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: