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

ACSC Informática e Oz InSite - Desenvolvimento Web
Compartilhar no Facebook:
Compartilhar no Linkedin:

3 comentários:

  1. Bom dia Marcelo Lourenço
    Bela explicação de testes de software, é isso ai
    simples mais útil muito útil, estou estudando análise e desenvolvimento de sistema, já estou no 4º semestre na parte de projetos e estas informações foram muito boa para o meu aprendizado. Obrigado boa sorte nesta carreira.

    Douglas, dgs.jf@bol.com.br, sobre o livro e-book nos comentários abaixo eu tenho ele em PDF precisando estamos ai.

    ResponderExcluir
    Respostas
    1. Caro internauta, fiquei interessado em seu comentário a respeito do livro, eu estou a estudar para certificação CTFL (testes), seria de grande ajuda ter o livro, se pudesse me disponibilizar o livro, ficaria muito grato.
      Meu email: ale.ucb@hotmail.com

      Excluir
  2. Oi Douglas, obrigado pela visita. Que bom que o conteúdo foi útil.
    Quanto ao e-book do livro "Base de Conhecimento em Teste de Software" se você puder compartilhar ficarei muito agradecido. Estou te enviando um e-mail solicitando.
    Abraços e sucesso nos estudos.

    ResponderExcluir

Indique ou comente o post. Obrigado pela visita!