Introdução
O desenvolvimento de sistemas de software envolve uma série de atividades de produção em que as oportunidades de injeção de falhas humanas são enormes. Erros podem começar a acontecer logo no começo do processo, onde os objetivos podem estar errônea ou imperfeitamente especificados, além de erros que venham a ocorrer em fases de projeto e desenvolvimento posteriores. Por causa da incapacidade que os seres humanos têm de executar e comunicar com perfeição, o desenvolvimento de software é acompanhado por uma atividade de garantia de qualidade.
Objetivos da Atividade de Teste
A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto. Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.
Os objetivos mencionados anteriormente implicam em uma mudança drástica de ponto de vista. Eles apontam contrariamente ao ponto de vista comumente defendido de que um teste bem-sucedido é aquele em que nenhum erro é encontrado. O objetivo da atividade de teste é projetar testes que descubram sistematicamente diferentes classes de erros e façam-no com uma quantidade de tempo e esforço mínimos.
O objetivo do teste é encontrar erros. Após o teste se faz necessário a depuração, depurar é encontrar a causa do erro detectado no teste, e projetar e implementar as modificações no programa para correção do erro.
Técnicas de Testes
Teste Estrutural (Caixa Branca)
O teste de caixa branca é um método de projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos de teste.
Usando métodos de teste de caixa, o engenheiro de software pode derivar os casos de teste que:
- Garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez.
- Exercitem todas as decisões lógicas para valores falsos ou verdadeiros.
- Executem todos os laços em suas fronteiras e dentro de seus limites operacionais.
- Exercitem as estruturas de dados internas para garantir a sua validade.
- Erros lógicos e pressuposições incorretas são inversamente proporcionais à probabilidade de que um caminho (path) de programa seja executado. Erros tendem a se infiltrar no código quando implementamos funções que não são cotidianas.
- Muitas vezes acreditamos que um caminho lógico não tem a probabilidade de ser executado quando, de fato, ele pode ser executado regularmente. O fluxo lógico de um programa às vezes é contra-intuitivo, querendo isso dizer que nossas pressuposições inconscientes sobre o fluxo de controle e de dados podem levar-nos a cometer erros de projeto que são descobertos somente quando se inicia a atividade de teste do caminho.
- Erros tipográficos são aleatórios. Quando um programa é traduzido para código-fonte de linguagem de programação, é provável que alguns erros de digitação ocorram. Esses erros só serão detectados com mecanismos de verificação de sintaxe, outros só serão detectados quando se iniciarem os testes. É provável que exista um erro tipográfico tanto num caminho lógico obscuro como num caminho da corrente principal.
Cada uma dessas razões oferece um argumento para a realização de testes de caixa branca. Conforme Beizer: Os bugs escondem-se pelos cantos e congregam-se nas fronteiras. Os testes de caixa branca têm maior probabilidade de descobri-los.
Teste Funcional (Caixa Preta)
Os métodos de teste de caixa preta concentram-se nos requisitos funcionais do software. Ou seja, esse teste possibilidade que o engenheiro de software derive conjuntos de condições de entrada que exercitem completamente todos os requisitos funcionais para um programa. O teste de caixa preta não é uma alternativa para as técnicas de caixa branca. Ao contrário, trata-se de uma abordagem complementar que tem a probabilidade de descobrir uma classe de erros diferente daquela dos métodos de caixa branca.
O teste de caixa preta procura descobrir erros nas seguintes categorias:
- Funções incorretas ou ausentes.
- Erros de interface.
- Erros nas estruturas de dados ou no acesso a bancos de dados externos.
- Erros de desempenho.
- Erros de inicialização e término.
Ao contrário do teste de caixa branca, que é executado cedo no processo de teste, o teste caixa preta tende a ser aplicado durante as últimas etapas da atividade de teste. Uma vez que o teste de caixa deliberadamente desconsidera a estrutura de controle, a atenção se concentra no domínio de informação.
Testes são projetados para responder às seguintes perguntas:
- Como a validade funcional é testada?
- Quais classes de entrada constituirão bons casos de teste?
- O sistema é particularmente sensível a certos valores de entrada?
- Como as fronteiras de uma classe de dados são isoladas?
- Quais índices de dados e volumes de dados o sistema pode tolerar?
- Que efeito terão combinações específicas de dados sobre a operação do sistema?
Ao aplicar técnicas de caixa preta, derivamos um conjunto de casos de teste que satisfaz aos seguintes critérios:
- Casos de teste que reduzem, numa contagem que seja maior que 1, o número de casos de teste adicionais que devem ser projetados para se conseguir testes razoáveis.
- Casos de teste que nos dizem algo sobre a presença ou ausência de classes de erros em vez de um erro associado somente ao teste específico que se tem em mãos. Também existem outros tipos de teste.
Fases de Teste
Teste de Unidade
O teste de unidade concentra-se no esforço de verificação da menor unidade do projeto de software - módulo. Usando a descrição do projeto detalhado como guia, caminhos de controle importantes são testados para descobrirem erros dentro das fronteiras do módulo. A complexidade relativa dos testes e os erros detectados como resultado deles são limitados pelo campo de ação restrito estabelecido para o teste de unidade. O teste de unidade baseia-se sempre na caixa branca, e esse passo pode ser realizado em paralelo para múltiplos módulos.
Teste de Integração
O teste de integração é uma técnica sistemática o para a construção da estrutura de programa, realizando-se, ao mesmo tempo, testes para descobrir erros associados a interfaces. O objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi determinada pelo projeto.
Frequentemente, existe uma tendência para tentar a integração não-incremental: ou seja, construir o programa usando uma abordagem “big bang”. Todos os módulos são combinados antecipadamente. O programa completo é testado como um todo. E o caos normalmente é resultado! Um conjunto de erros é encontrado. A correção é difícil por que o isolamento das causas é complicado pela vasta amplitude do programa inteiro. Assim que esses erros são corrigidos, surgem novos erros e o continua de um modo aparentemente infindável.
A integração incremental é a antítese da abordagem big bang. O programa é construído e testado em pequenos segmentos, onde os erros são mais fáceis de ser isolados e corrigidos; as interfaces têm maior probabilidade de ser testados completamente; e uma abordagem sistemática ao teste pode ser aplicada.
Na fase de teste de integração o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema. Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.
- Deve ser escrito pelo mesmo programador que desenvolveu o código a ser testado.
- Serve como documentação do sistema
- Essencial para análise de desempenho
Teste de Sistema
Na fase de Teste de Sistema o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas. Os testes são executados em condições similares - de ambiente, interfaces sistêmicas e massas de dados - àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de uma organização podem ser utilizadas condições reais de ambiente, interfaces sistêmicas e massas de dados.
- Comparar o sistema com seus objetivos originais
- Enfatizar a análise do comportamento da estrutura hierárquica de chamadas de módulos
- Fase mais complexa, devido à quantidade de informações envolvidas
Teste de Regressão
É uma fase de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que ja foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação de testes, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser re-executados com maior agilidade.
- Teste necessário para assegurar que modificações no programa não causaram novos erros
- baseado em arquivo de log
Teste de Aceitação
Fase de Teste em que o teste é conduzido por usuários finais do sistema. Os testes são realizados, geralmente, por um grupo restrito de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.
- A validação é bem sucedida quando o software funciona de uma maneira razoavelmente esperada pelo cliente . Pressman , 1995
- Expectativas dos clientes documentadas
- Uso da documentação do usuário
Bibliografia
- Pressman, Roger S. (1995), Engenharia de Software, 4º edição
