Teste de Integração

Quando todos os componentes de um software foram testados, surge uma pergunta: quando estiverem integrados, continuarão funcionando? O teste de componentes individuais antecede o teste de integração. Contribui para assegurar a correção de componentes individuais, mas não é capaz de garantir que as dependências funcionais entre componentes estejam perfeitamente implementadas. Para isso é preciso uma abordagem diferente.

Com relação a integração de componentes, existem duas vertentes principais para desenvolvimento de software: as abordagens bottom-up e top-down.

Na abordagem bottom-up, o programa é desenvolvido a partir de rotinas básicas que prestam serviços a rotinas de nível mais alto. Por exemplo, uma verificação de validade de CPF pode ser chamada em vários pontos de um programa. Será, então uma das primeiras a serem implementadas.

Na abordagem top-down, faz-se o inverso. O programador trabalha supondo que o código de baixo nível já esteja pronto. Assim, pode-se codificar chamadas à verificação de CPF, mesmo sabendo que ela ainda não existe. Em seu lugar, pode haver uma rotina “fantasma” (stub), que apenas retorna sempre um valor verdadeiro.

Para realizar testes no desenvolvimento bottom-up, deve ser escrito código que invoque as rotinas de baixo nível, testando-as com diversas combinações de parâmetros. As rotinas escritas para tais testes são conhecidas como drivers, pois sua função é acionar o código que deve ser testado. No teste up-down, a função inversa é fornecida pelos stubs que provêem dados para as rotinas de nível superior, permitindo que se realizem os testes.

Quando os dados são oriundos de arquivos, é comum que avaliadores criem bases de dados falsas contendo registros para realizar testes. Quando os dados são oriundos de arquivos, é comum que avaliadores criem bases de dados falsas contendo registros para realizar testes. Tais registros podem inclusive ser inconsistentes, contendo informação defeituosa para verificar o comportamento de rotinas.

Após o teste e correção dos componentes individuais, segue-se uma etapa de construção de novo código. Na abordagem bottom-up, os drivers são substituídos por rotinas “verdadeiras”, enquanto na abordagem top-down o mesmo se faz com os stubs. As novas rotinas devem ser novamente testadas em conjunto e o processo todo se repete até a conclusão do projeto.

Veja também:

Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Orientado a Objetos
Teste de Aceitação

QABI Consultoria

Compartilhar no Facebook:
Compartilhar no Linkedin: