Pular para o conteúdo principal

Níveis de Testes - Parte 2: Testes de Integração

Seguindo com os quatro principais níveis de testes do ciclo de vida de um software, abordaremos agora o segundo nível, Testes de Integração:

1. Testes Unitários
2. Testes de Integração
3. Testes de Sistema
4. Testes de Aceitação

Nos próximos posts abordaremos os itens seguintes.

Testes de Integração

Testes de Integração representam o nível de testes no qual módulos individuais de um software são combinados e testados como um grupo. Tais testes encontram-se em um nível intermediário aos Testes Unitários e aos Testes de Sistema.

Testes de integração recebem como entrada os módulos que já passaram por testes unitários, agrupam tais módulos e aplicam testes nos mesmos. Geralmente as diretrizes para tais testes encontram-se no Plano de Testes de Integração. A saída gerada é passada pro próximo nível de testes: os Testes de Sistema.



O objetivo dos testes de integração é verificar requerimentos funcionais, de performance e de confiabilidade de um projeto de software. A idéia principal é testar blocos, compostos por módulos, que foram anteriormente testados no nível Unitário. Tais blocos são chamados de componentes.

Através dos Testes de Integração pode-se detectar erros de interface entre os componentes do sistema. Há dois tipos de Integração, a não-incremental e a incremental.

Não Incremental

Abordagem chamada de "big-bang". O conjunto de erros são difíceis de serem detectados, logo difíceis de serem corrigidos, pois devido ao tamanho e complexidade do programa, é difícil isolar as causas de tais erros.

Incremental

Um software é contruído e testado em pequenos segmentos, tornando a correção de erros mais fácil. A probabilidade de testar completamente a interface do sistema também aumenta.

Integração Top-down

Como o nome já diz, a integração dos módulos acontece de cima para baixo, o que facilita a verificação antecipada dos pontos de decisão e controle no processo de teste.

Integração Bottom-up

A integração dos módulos ocorre de baixo para cima.

Para maiores e mais detalhadas informações sobre os tipos de testes de integração, consulte:

Apresentação UFPE

Apresentação Unicamp

Como exemplos de ferramentas para auxílio em Testes de Integração, podemos citar Selenium e Asgard. Porém, você deve encontrar diversos outros tipos, de acordo com o tipo de teste de integração que será executado.

Aqui você pode consultar, baixar e utilizar ferramentas de testes gratuitas, para todo tipo de testes, não só de integração: Open Source Testing

Obrigado, até a próxima!

Comentários

Postagens mais visitadas deste blog

FURPS

Olá! Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software : Vamos começar pela sigla FURPS: o que significa cada uma dessas letras? Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema. Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário. Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema. Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema. Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema. As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não ante...

O + do FURPS+

Segue a continuação do assunto FURPS: Posteriormente à definição do modelo FURPS, notou-se a necessidade da inclusão de mais atributos para encorpar e aumentar a cobertura do modelo. A partir dessa extensão, o acrônimo passou a ser mais comumente chamado de FURPS+ . Quais são os atributos do “+”? O + do FURPS refere-se a especificação de restrições que definirão determinados limites que deverão ser atendidos quando construímos um sistema. O + é composto dos seguintes requisitos não-funcionais: Design constraints – restrições de design: design nesse caso refere-se ao projeto, diretrizes e não a layout. A definição da utilização um banco de dados relacional no projeto é uma restrição de design, por exemplo. Implementation constraints – restrições de implementação: relacionado a limites impostos a código e construções. Como exemplo podemos citar a linguagem de programação que será utilizada para a codificação de um sistema. Interface constraints – restrições de interface: diretamente l...