• 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

    • 14,496 hits

Teste de Sw

Processo de Depuração e Teste

Teste de Sw

Importância

Ao teste de SW não se deve está enfatizado sua importância em relação a qualidade de Sw, mas sim sua importância no processo de desenvolvimento.

Uma vez que o código fonte foi gerado, o software deve ser testado para permitir que os erros sejam identificados e removidos antes da entrega ao cliente. Não é possível remover todos os erros em um pacote grande de software, dessa forma o objetivo do Engenheiro de Software deve ser o de remover o erro o mais cedo possível, no ciclo de desenvolvimento do software (Wasserman, 1996).Teste pode apenas encontrar erros, ele não pode provar que um programa é livre de erros.

Para (Pressman,2002), o teste deve ser planejado e projetado.

As revisões técnicas formais (walkthrough), por si só, não permitem encontrar defeitos do software, dados de teste devem também ser usados. Em se tratando em projetos grandes de software, as equipes separadas de teste devem ser usadas para desenvolver e executar o conjunto de casos de teste usados processo de teste.

Objetivos

Testar é um processo de executar um programa com a intenção de encontrar erros. Um bom caso de teste é o que tem alta probabilidade de encontrar um erro ainda não descoberto.

Testar x Depurar

Como foi falado em post anterior,

Depurar não é uma atividade de teste. A depuração mostra a natureza da falha e a corrige. [Myers]

O teste apenas indica que há uma falha.

Os testes devem ser verificados em relação às exigências do cliente. Estes devem ser planejados bem antes de se começar a testar. Seu planejamento faz parte do processo de teste.

O princípio de Pareto

(80% de todos os erros será encontrado provavelmente em 20% do código) aplica-se ao teste de software.

O teste deve começar no pequeno e ir progressivamente ao grande. Testar exaustivamente não é possível. Para ser mais eficaz, o teste deve ser conduzido por um terceiro de forma independente.

Checklist da testabilidade de software

Item

O que é

Status (S-Sim/N-Não)

Operabilidade Quanto melhor o software funciona, melhor ele pode

ser testado.

Observabilidade O que você vê é o que você testa.
Controlabilidade Quanto mais o software pode ser controlado, mais o teste pode ser automatizado e otimizado);
Decomponibilidade Controlando o escopo do teste, mais rapidamente

os problemas podem ser isolados e re-examinados inteligentemente.

Simplicidade Quanto menos há para testar, mais rapidamente o teste pode ser feito.
Estabilidade Quanto menor o número de mudanças, menor a

descontinuidade do teste).

Compreensibilidade Quanto mais informação, mais fácil de testar.

Atributos de um bom Teste

Um teste bom tem uma alta probabilidade de encontrar um erro, não é redundante, não deve ser nem demasiado simples nem demasiado complexo. Um caso de teste deve ser o melhor de um conjunto de testes possíveis. Um programa pode passar com sucesso em muitos testes, mas basta falhar em um teste para dizermos que ele está incorreto.

Tipos de Teste

Tipo

Descrição

Caixa Preta – sem lógica Envolve apenas as entradas e saídas de um componente de software. É um teste comportamental. Sabendo-se a função específica de um produto, o teste deve ser executado para demonstrar a operação correta, baseada unicamente em sua especificação sem considerar a sua lógica interna.
Caixa Branca – Lógica Procura exercitar a lógica interna de um

componente de software. No teste caixa-branca (ou caixa de vidro como às vezes é chamado), conhecendo-se o funcionamento interno de um produto, os testes são executados para verificar o funcionamento de todos os trajetos lógicos independentes.

É preciso tomar muito cuidado para não Corrigir o erro errado, o que é muito comum, devido a “fatores psicológicos”, quando o programador “Vê o que espera ver” e não o que realmente está registrado.

“O processo de testes é normalmente prejudicado pela universal relutância humana em admitir falhas “ [Gries]

É preciso cuidado também para não ter pressa em corrigir o erro, não documentar o erro ou não documentar a correção do erro. É preciso Testar o programa após a correção, por menor que ela seja. Uma vez testado o programa e verificado que ele tem erro, devemos partir para o processo de depuração, vistos nos quatro passos a seguir.

Processo para Depuração (1 Debug)

Passo

Processo

Descrição

Entendimento do problema Tentar entender o problema. Os dados disponíveis são  uficientes para

o entendimento? Se não, obtenha mais dados.

Planejamento Entendidos os sintomas do erro, tente criar “teorias sobre a sua

origem”, escolha a melhor teoria e desenvolva um plano para provar

sua teoria.

Aplicação do Plano Aplique o plano com critério. Verifique se e a teoria foi provada, isto é,

o erro foi detectado ou se será necessário usar outro plano. Mesmo que

o erro tenha sido localizado e explicado, tome cuidado. Pode ser que o plano não foi aplicado com o rigor necessário. Reveja o plano e sua implementação.

Rever as correções Se os planos foram aplicados com critério Faça as correções no

programa, reveja com cuidado as correções feitas e termine o processo de depuração. Teste o programa novamente.

Nota: 1) A palavra debug (vem de de-bug) significa, em inglês, retirar um bug e vem da época

dos primeiros computadores que deixavam de funcionar devido ao fato de insetos (bugs) comerem as capas dos fios e provocarem defeitos na máquina.

Esta tarefa deve ser feita com muito cuidado para não introduzir novos erros no componente que está sendo depurado.

Heurística

O processo de teste de software deve ser conduzido usando uma série de heurísticas:

• Um bom caso de teste é o que tem alta probabilidade de detectar um erro.

• Um dos pontos difíceis do processo de teste é saber quando parar.

• É muito difícil para um programador testar seu próprio programa.

• É necessário escrever os resultados esperados de um caso de teste.

• Evite testes não reproduzíveis, ou projetados sem critério, sem documentação, que não permitam sua reprodução.

• Os programadores mais criativos devem ser escalados para o teste de programas.

• Nunca altere o programa para facilitar o teste.

• O teste deve começar com os objetivos.

• Escreva casos de teste tanto para as condições válidas quanto inválidas.

A medida que cresce o número de erros detectados, a probabilidade de serem encontrados mais erros aumenta.

Níveis de correção de um componente de software

Podemos estabelecer uma escala de qualidade de um componente de software em relação a sua qualidade em responder corretamente, quando executados:

1.Sem erros de sintaxe (compilação).

2.Sem operações inválidas.

3.Existem conjuntos de dados de casos de teste para os quais há resposta correta.

4.Para conjuntos típicos de casos de teste ( razoáveis ou aleatórios) há resposta correta.

5.Para conjunto de dados deliberadamente difíceis há resposta correta.

6.Para todos os conjuntos de dados (possíveis) que são válidos com relação à especificação há resposta correta.

7. Para todos os possíveis conjuntos de dados e igualmente, para condições de entrada erradas, a resposta é correta ou razoável.

É claro que atingir os níveis 6 e 7 não é tarefa fácil.

O Teste na prática

O teste caixa-preta de um componente de software pode ser melhor entendido com uma analogia com o hardware. Quando compramos uma lâmpada em um supermercado, fazemos o teste da lâmpada, colocando-a em um bocal devidamente alimentado com a corrente elétrica. Se ela acender, passou no teste. Se não acender falhou no teste.

Análogamente um módulo de programa pode ser testado se tivermos um driver para acioná-lo, entregar os dados que ele precisa e receber a(s) resposta(s) produzida(s). Na figura abaixo vemos uma analogia do teste da lâmpada com o teste do módulo função ABS.

O módulo retorna o valor absoluto de um número real fornecido.

Assim , ABS(-5) retorna 5 e ABS de (5) também retorna 5.

Podemos planejar os casos de teste deste módulo, indicando casos típicos e atípicos para verificar a consistência do módulo de programa e a sua robustez.

códigocasos de teste

É importante definir, com antecedência, antes de rodar o programa, quais são os resultados esperados, para depois confrontá-los com os resultados obtidos.

No “driver” escrito para testar o programa podemos fazer as chamadas dos casos de teste e, adicionalmente deixar o próprio programa driver testar os resultados.

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: