-
Teste de Integração (Teste de caixa Cinza):
Uma técnica sistemática para construir a estrutura do programa enquanto, ao mesmo tempo, conduz testes para descobrir erros associados às interfaces. O objetivo é tomar componentes testados em nível de unidade e construir a estrutura de programa determinada pelo projeto.
É realizado depois que as unidades do software estão prontas tem o objetivo de verificar se essas unidades podem ser incorporadas em uma nova versão do sistema em desenvolvimento.
Constrói a arquitetura de software em paralelo faz teste para descobrir erros associados com a interfaces
Não é um tipo de teste de sistema
Sucede o teste de Unidade
Testados em grupo ou individualmente
Verifica a integridade do sistema após a junção dos componentes testados individualmente.
Evita efeitos colaterais
Módulos combinados
Exemplos
Teste de fumaça
Teste de regressão
Bottom-up
Top-down
Certo
-
Testes de Integração:
Top-Down: Desenvolve o esqueleto do sistema e o preenche com os componentes do sistema
Bottom-Up: Integra os componentes da infraestrutura e depois adiciona os componentes funcionais
-
Gabarito Certo
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.
"Retroceder Nunca Render-se Jamais !"
Força e Fé !
Fortuna Audaces Sequitur !
-
São as seguintes as fase dos testes:
1. Teste de unidade: São testadas as menores unidades do software desenvolvido.
2. Teste de integração: Módulos são combinados e testados juntos.
3. Teste de validação: Procura demostrar conformidade com os requisitos.
4. Teste de sistema: è executado o sistema sob o ponto de vista do usuário final, varrendo as funcionalidades em busca de falhas em relação aos objetivos originais.
Fonte: Concurseiro de TI