Teste de Software: Metas, Tipos e Automação

Metas do Teste de Software

O processo de teste do software tem duas metas distintas:

1. Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos.
2. Descobrir falhas ou defeitos no software que apresenta comportamento incorreto, indesejável ou em não conformidade com sua especificação.

A primeira meta conduz ao teste de validação, no qual você espera que o sistema seja executado corretamente em um determinado conjunto de casos de teste que reflete o uso esperado do sistema. A segunda meta conduz ao teste de defeitos, no qual são projetados casos de teste para expor defeitos.

Os testes não podem demonstrar que um software é livre de defeitos ou que ele se comportará conforme especificado em todas as circunstâncias. É sempre possível que um teste ignorado possa descobrir mais problemas no sistema.

Políticas de Teste Baseadas na Experiência

De modo alternativo, as políticas de teste podem ser baseadas na experiência de uso do sistema e podem enfocar o teste das características do sistema que esteja operacional. Por exemplo:

1. Todas as funções do sistema acessadas por meio de menus devem ser testadas.
2. Combinações de funções (por exemplo, formatação de texto) acessadas por meio dos mesmos menus devem ser testadas.
3. Todas as funções devem ser testadas com entradas corretas e incorretas no local de entrada do usuário.

Teste de Sistemas

O teste de sistema envolve a integração de dois ou mais componentes que implementam funções ou características do sistema e depois o teste desse sistema integrado. Para a maioria dos sistemas complexos, existem duas fases distintas de teste do sistema:

Testes de Integração

Nos quais a equipe de teste deve acessar o código-fonte do sistema. Quando um problema é descoberto, a equipe de integração tenta encontrar a origem do problema e identificar os componentes que devem ser depurados.

Finalidade: O processo de integração do sistema envolve a construção de um sistema com base em seus componentes e o teste do sistema resultante para identificar problemas ocorridos nas interações entre componentes.

Testes de Release

Nos quais uma versão do sistema, que poderia ser liberada aos usuários, é testada. Aqui a equipe de testes concentra-se em validar se o sistema atende aos requisitos e em assegurar sua confiabilidade.

Finalidade: É o processo de teste da versão do sistema que será distribuída aos clientes. A meta principal é aumentar a confiança do fornecedor de que o sistema atende aos requisitos.

Teste de Desempenho

Após o sistema ter sido completamente integrado, é possível testá-lo em relação às propriedades emergentes, como desempenho e confiabilidade.

Teste de Componentes

Às vezes chamado de teste de unidade, é o processo de teste de componentes individuais do sistema. Este é um processo de teste de defeitos e, portanto, sua meta é expor defeitos nesses componentes. Existem diferentes tipos de componentes que podem ser testados nesse estágio:

1. Funções ou métodos individuais de um objeto.
2. Classes de objeto com vários atributos e métodos.
3. Componentes compostos que constituem diferentes objetos ou funções. Esses componentes compostos têm uma interface definida usada para acessar sua funcionalidade.

Teste de Interfaces

O teste de interfaces é particularmente importante para o desenvolvimento orientado a objetos e baseado em componentes. Os objetos e os componentes são definidos por suas interfaces e podem ser reutilizados em combinação com outros componentes em diferentes sistemas. Existem diferentes tipos de interfaces:

• Interface de Parâmetros: Estas são interfaces em que dados ou, às vezes, referências a funções são passados de um componente para outro.
• Interface de Memória Compartilhada: São interfaces em que um bloco de memória é compartilhado entre os componentes.
• Interface de Procedimentos: São interfaces em que um componente engloba um conjunto de procedimentos que podem ser chamados por outros componentes.
• Interface de Passagem de Mensagem: São interfaces em que um componente solicita um serviço de outro componente passando uma mensagem para ele.

Tipos de Erros de Interface

São uma das formas mais comuns de erros em sistemas complexos. São eles:

• Mau uso de interface: Um componente chama outro componente e comete um erro no uso de sua interface.
• Mau entendimento da interface: Um componente chamador interpreta mal a especificação da interface do componente chamado e faz suposições sobre seu comportamento.
• Erros de Timing: Esses erros ocorrem em sistemas de tempo real que usam memória compartilhada ou uma interface de passagem de mensagens.

Diretrizes para Teste de Interfaces

Algumas diretrizes gerais para teste de interfaces são:

• Examine o código a ser testado e liste explicitamente cada chamada a componentes externos.
• Teste sempre a interface com ponteiros nulos onde os ponteiros são passados por meio da interface.
• Projete testes que causem a falha do componente onde este é chamado por meio de uma interface de procedimento.
• Use o teste de estresse em sistemas de passagem de mensagens.
• Quando vários componentes interagem por meio de memória compartilhada, projete testes que variem a ordem na qual esses componentes são ativados.

Projeto de Casos de Teste

O projeto de casos de teste é parte do teste de sistemas e componentes, no qual você projeta os casos (entradas e saídas esperadas) que testam o sistema. Existem várias abordagens que você pode usar para projetar casos de teste:

• Teste Baseado em Requisitos: No qual os casos de teste são projetados para testar os requisitos do sistema.
• Teste de Partições: No qual são identificadas partições de entrada e de saída e projetados testes de modo que o sistema processe as entradas de todas as partições e gere as saídas em todas as partições.
• Teste Estrutural: No qual é usado o conhecimento da estrutura do programa para projetar testes que exercitem todas as partes do programa.

Teste de Caminho

É uma estratégia de teste estrutural cujo objetivo é exercitar cada caminho independente na execução de um componente ou de um programa. Se cada caminho independente for executado, todas as declarações dos componentes terão sido executadas pelo menos uma vez.

Automação de Teste

O teste é uma fase dispendiosa e trabalhosa do processo de software. Sendo assim, as ferramentas de teste estão entre as primeiras ferramentas de software a serem desenvolvidas. Um workbench de teste de software é um conjunto integrado de ferramentas para apoiar o processo de teste. Exemplos de algumas ferramentas de teste incluídas no workbench de teste:

1. Gerenciador de Teste: Gerencia a execução de testes de programas. O gerenciador de teste mantém o acompanhamento dos dados de teste, resultados esperados e os recursos dos programas testados.
2. Gerador de Dados de Teste: Gera os dados de teste para o programa a ser testado.
3. Oráculo: Gera previsões de resultados de testes esperados.
4. Comparador de Arquivos: Compara os resultados dos testes de programas com os testes anteriores e relata as diferenças entre eles.
5. Gerador de Relatórios: Fornece recursos de definição e de geração de relatórios para resultados de teste.
6. Analisador Dinâmico: Adiciona código ao programa para contar o número de vezes que cada declaração foi executada. Depois do teste, um perfil de execução é gerado para mostrar a frequência com que cada declaração de programa foi executada.
7. Simulador: Diferentes tipos de simuladores podem ser fornecidos. Simuladores de alvo simulam a máquina na qual o programa será executado.

Teste de Software: Pontos Chave

• Os testes podem mostrar somente a presença de erros em um programa. Eles não podem demonstrar que não existam defeitos remanescentes.
• O teste de componentes é de responsabilidade do desenvolvedor de componentes. Outra equipe de testes geralmente executa os testes do sistema.
• O teste de integração é a atividade inicial de teste de sistema, na qual são testados os componentes integrados para detectar defeitos. O teste de release concentra-se em testar as versões do cliente e em validar se o sistema a ser liberado atende aos requisitos.
• Ao testar sistemas, você deve tentar ‘quebrar’ o sistema usando sua experiência e diretrizes para escolher os tipos de casos de teste eficazes na descoberta de defeitos em outros sistemas.
• O teste de interfaces tenta descobrir defeitos nas interfaces dos componentes compostos. Defeitos de interface podem surgir devido a erros de leitura da especificação, má interpretação da especificação ou erros ou suposições inválidas de timing.
• O particionamento de equivalência é uma maneira de derivar casos de teste. Ele depende da descoberta de partições nos conjuntos de dados de entrada e de saída e do exercício do programa com valores dessas partições. Frequentemente, o valor mais provável de conduzir a um teste bem-sucedido é um valor no limite da partição.
• O teste estrutural baseia-se na análise de um programa para determinar seus caminhos e no uso dessa análise para ajudar na seleção dos casos de teste.
• A automação reduz os custos de teste pelo apoio ao processo com uma variedade de ferramentas de software.