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
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
Bom dia Marcelo Lourenço
ResponderExcluirBela 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.
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.
ExcluirMeu email: ale.ucb@hotmail.com
Oi Douglas, obrigado pela visita. Que bom que o conteúdo foi útil.
ResponderExcluirQuanto 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.
Muito obrigada, por essas explicações é sempre bom ler assuntos de conteúdo nesta área.
ResponderExcluir