Teste de Unidade e Integração

Bom, tomando umas cervas aqui e pensando na vida, em como faz um ano que estudo para concursos e até agora só dedo nas ventas, resolvi dar uma estudadinha em teste de software.

Vou falar basicamente de testes de unidade, módulo e integração.

O Plano de Testes.

• Escopo dos testes
• Abordagem de testes
• Os recursos para a realização dos testes
• Cronograma das atividades a serem realizadas

Os casos de teste são as especificações das entradas para o teste e da saída esperada.

Teste de Unidade, unário ou de modo.

O objetivo desse teste é testar componentes individuais do software.
Usualmente é de responsabilidade do desenvolvedor. A exceção é para software crítico, pois nesse caso não dá para confiar em uma só pessoa.
Geralmente esses testes são derivados da experiência do desenvolvedor e também do conhecimento da estrutura de implementação do programa.

Esse teste garante que todas as declarações sejam executadas pelo menos uma vez.

Já o teste de caminho é ainda mais arrochado. Ele deve garantir que todos os caminhos individuais de um programa sejam executados pelo menos uma vez, com todos os seus ifs e elses. Alias, isso é particularmente impossível quando existem loops. Não tem como testar infinitas iterações em loops. Então a n-passagens por um loop contam como uma condicional.

Teste de Integração

Enquanto o teste de unidade é de responsabilidade do desenvolvedor, o teste de integração é de responsabilidade de uma equipe independente.  Esses testes são baseados na especificação do sistema, isto é, o objetivo do teste de integração é testar o desenho do sistema, enquanto o teste de unidades tem como objetivo testar o código do sistema.

Se esse teste de integração for de cima para baixo -  (TOP-DOWN) - usa-se stubs, se form de baixo para cima - BOTTOM UP - usa-se drivers.

Teste de Integração BOTTOM-UP

Nesse tipo de teste os componentes baixo-nível são desenvolvidos primeiro.

Teste de Integração TOP-DOWN

Nesse tipo de teste, os componentes alto-nível são desenvolvidos e testados primeiro, e criam-se os stubs que simulam os componentes em baixo nível, isto é, esses stubs têm a mesma interface que os componentes em baixo-nível a serem desenvolvidos, porém uma funcionalidade bem limitada.

Validação da Arquitetura	Os testes top-down oferecem maior probabilidade de descobrir erros na arquitetura do sistema e no projeto de alto-nível. Assim, erros estruturais podem ser corrigidos logo no começo, sem muito prejuízo. Já no Bottom-up, o projeto em alto-nível não é validade até os estágios finais ( quando estão sendo construídos os componentes em alto-nível, até então simulados por drivers)
Demonstração do Sistema	No desenvolvimento top-down o aspecto geral do projeto está mais visível.
Implementação de Teste	Implementações top-down são mais difíceis de testar porque os componentes em alto-nível são mais complexos, então todo esse comportamento tem que ser simulado. As vezes fica tão complicado fazer os stubs quando desenvolver os próprios componentes inferiores.
Observação de Teste	Isso é um problema para os dois, já que tanto em um quanto em outro, é possível que os componentes que estão sendo desenvolvidos não gerem saída, de forma que essa saída tem que ser implementada para que se possa testar o componente.

A espiral abaixo mostra uma visão geral do processo de teste.

Em um teste de defeitos, nós temos sucesso quando encontramos um defeito.

A coisa mais manjada sobre teste é você saber que um teste pode revelar a presença de defeitos, mas nunca a sua ausência.

Isso contrasta com o Teste de Validação cujo objetivo é demonstrar que um sistema atende às suas especificações.

Segundo Sommervile: "Testes exaustivos são impossíveis" , de fato, estudando Teoria da Computação esses dias, vi que o problema da parada não é Turing-Decidível, então não há nunca como saber se um software vai parar ou entrar em loop infinito.

Testar antigas capacidades é mais importante que testar capacidades antigas.

Testar situações tipicas é mais importante que testar situações nas fronteiras ( referindo-se a situações incomuns)

Teste de Caixa-preta é uma técnica de teste que não deriva da implementação, apenas da especificação do sistema. Isto é,  note que implementação é diferente de especificação.

Já o Teste em Caixa-branca é derivado da implementação, isto é, do código-fonte. O objetivo é exercitar todas as estruturas do programa.

O Teste de caminho vai além do Teste em Caixa-Branca, garantindo que todos os caminhos possíveis de um software seja exercitados pelo menos uma vez. Isso está diretamente ligado a complexidade ciclomática de um software, que é todos os possíveis caminhos que um software pode percorrer por sua estrutura de implementação.

A fórmula que nos dá essa complexidade é nada por C = P +  1 onde P é o número de nós preditivos, isto é, que podem causar desvios condicionais como if, for ...