O que é SIT? Teste de Integração de Sistemas com Exemplo
Thomas Hamilton
⚡ Resumo Inteligente
Os testes de integração de sistemas verificam se os módulos de hardware e software construídos independentemente se comportam corretamente quando combinados em um sistema completo. Eles expõem defeitos de interface, fluxo de dados, temporização e memória que os testes unitários, por si só, não conseguem detectar antes do lançamento.
O que é teste de integração de sistema?
System Teste de integração é definido como um tipo de teste de software realizado em um ambiente integrado de hardware e software para verificar o comportamento do sistema completo. São testes realizados em um sistema completo e integrado para avaliar a conformidade do sistema com seus requisitos especificados.
O Teste de Integração de Sistemas (SIT, na sigla em inglês) é realizado para verificar as interações entre os módulos de um sistema de software. Ele trata da verificação dos requisitos de software de alto e baixo nível especificados na Especificação de Requisitos de Software/Dados e no Documento de Projeto de Software.
O SIT também verifica a coexistência de um sistema de software com outros e testa a interface entre os módulos da aplicação. Nesse tipo de teste, os módulos são testados individualmente e, em seguida, combinados para formar um sistema. Por exemplo, componentes de software e/ou hardware são combinados e testados progressivamente até que todo o sistema esteja integrado.
O diagrama acima mostra a progressão que define o SIT: módulos verificados separadamente são mesclados passo a passo até que um único sistema integrado permaneça em teste.
Por que fazer testes de integração de sistemas?
Na Engenharia de Software, o Teste de Integração de Sistemas é feito porque,
- Ajuda a detectar Defeito cedo
- Feedback anterior sobre a aceitabilidade do módulo individual estará disponível
- O agendamento de correções de defeitos é flexível e pode ser sobreposto ao desenvolvimento
- Fluxo de dados correto
- Fluxo de controle correto
- Tempo correto
- Uso correto de memória
- Correto com os requisitos de software
Testes de integração de sistemas vs. testes de sistema vs. testes de aceitação do usuário
Como esses três níveis são consecutivos, eles são frequentemente confundidos. Teste do sistema A SIT examina uma construção finalizada em relação aos seus requisitos, enquanto a SIT examina as junções entre as construções. Teste de Aceitação Analisa a adequação da empresa do ponto de vista do cliente. A tabela abaixo as separa.
| Parâmetro | Teste de integração de sistema | Teste do sistema | Teste de Aceitação |
|---|---|---|---|
| Foco primário | Interfaces e fluxo de dados entre módulos integrados | Comportamento do conjunto montado como um todo | Fitness empresarial para uso real |
| Nível de teste | Nível dois | Nível três | Nível final antes do lançamento |
| Técnica | Caixa preta | Caixa preta, caixa branca ou caixa cinza | Caixa preta |
| Executado por | Testadores de integração e desenvolvedores | Equipe de testes independente | Cliente ou usuários finais |
| Defeitos típicos | Interface, temporização, memória e mapeamento de dadosping erros | Erros funcionais e não funcionais do sistema | Incompatibilidade entre usabilidade e requisitos |
| Executa quando | Depois de Teste de Unidade | Após o SIT | Após os testes do sistema |
A sequência é importante. Os módulos passam por testes unitários, o teste de integração de sistemas (SIT) comprova as interfaces, o teste de sistema comprova o produto montado e o teste de aceitação do usuário (UAT) confirma se o produto atende às expectativas do negócio.ping O sistema de integração de sistemas (SIT) empurra os defeitos de interface para o teste de aceitação do usuário (UAT), onde cada correção custa muito mais para ser feita.
Como fazer testes de integração de sistemas
Trata-se de uma técnica sistemática para construir a estrutura do programa enquanto se realizam testes para descobrir erros associados à interface.
Todos os módulos são integrados antecipadamente e todo o programa é testado como um todo. Mas durante esse processo, é provável que um conjunto de erros seja encontrado.
A correção de tais erros é difícil porque o isolamento das causas é complicado pela vasta expansão de todo o programa. Assim que esses erros forem corrigidos e corrigidos, um novo aparecerá e o processo continuará perfeitamente em um loop infinito.. Para evitar essa situação, utiliza-se outra abordagem, a Integração Incremental. A abordagem incremental é explicada em detalhes na próxima seção.
Existem alguns métodos incrementais, como os testes de integração conduzidos em um sistema baseado no processador de destino. A metodologia utilizada é Preto Box Testes. Tanto a integração de baixo para cima quanto de cima para baixo podem ser usadas.
Os casos de teste são definidos usando apenas requisitos de software de alto nível.
A integração de software também pode ser alcançada em grande parte no ambiente host, com unidades específicas do ambiente alvo continuando a ser simuladas no host. Será novamente necessário repetir os testes no ambiente de destino para confirmação.
Os testes de confirmação neste nível identificarão problemas específicos do ambiente, como erros na alocação e desalocação de memória. A viabilidade de realizar a integração de software no ambiente hospedeiro dependerá da quantidade de funcionalidades específicas do alvo presentes. Para alguns sistemas embarcados, o acoplamento com o ambiente alvo será muito forte, tornando impraticável a realização da integração de software no ambiente hospedeiro.
Grandes desenvolvimentos de software dividirão a integração de software em vários níveis. Os níveis mais baixos de integração de software poderiam ser baseados predominantemente no ambiente host, com níveis posteriores de integração de software tornando-se mais dependentes do ambiente de destino.
Observação: Se apenas o software estiver sendo testado, ele será chamado de Teste de Integração de Software de Software [SSIT] e se tanto o hardware quanto o software estiverem sendo testados, será chamado de Teste de Integração de Software de Hardware [HSIT].
Abordagem Incremental
Como a integração de tudo de uma só vez dificulta o isolamento de defeitos, a maioria das equipes segue a abordagem incremental descrita aqui.
O teste incremental é uma forma de teste de integração. Neste tipo de método de teste, você primeiro testa cada módulo do software individualmente e depois continua o teste anexando outros módulos a ele, depois outro e assim por diante.
A integração incremental contrasta com a abordagem do big bang. O programa é construído e testado em pequenos segmentos, onde os erros são mais fáceis de isolar e corrigir. É mais provável que as interfaces sejam testadas completamente e uma abordagem de teste sistemático pode ser aplicada.
Existem dois tipos de teste incremental
- Abordagem de cima para baixo
- Abordagem de baixo para cima
Abordagem de cima para baixo
Nesse tipo de abordagem, o indivíduo começa testando apenas a interface do usuário, com a funcionalidade subjacente simulada por stubs, depois avança para baixo integrando as camadas cada vez mais baixas, conforme mostrado na imagem abaixo.
- Começando com o módulo de controle principal, os módulos são integrados movendo-se para baixo na hierarquia de controle
- Os submódulos do módulo de controle principal são incorporados à estrutura, seja em largura ou em profundidade.
- A integração em profundidade integra todos os módulos em um caminho de controle principal da estrutura, conforme exibido no diagrama a seguir:
O processo de integração do módulo é feito da seguinte maneira:
- O módulo de controle principal é usado como driver de teste e os stubs são substituídos por todos os módulos diretamente subordinados ao módulo de controle principal.
- Os stubs subordinados são substituídos um de cada vez por módulos reais, dependendo da abordagem selecionada (largura primeiro ou profundidade primeiro).
- Os testes são executados à medida que cada módulo é integrado.
- Após a conclusão de cada conjunto de testes, outro stub é substituído por um módulo real na conclusão de cada conjunto de testes.
- Para garantir que novos erros não foram introduzidos Teste de regressão pode ser executado.
O processo continua da etapa 2 até que toda a estrutura do programa seja construída. A estratégia de cima para baixo parece relativamente simples, mas na prática surgem problemas logísticos.
O mais comum desses problemas ocorre quando o processamento em níveis inferiores na hierarquia é necessário para testar adequadamente os níveis superiores.
Os stubs substituem os módulos de baixo nível no início do teste descendente e, portanto, nenhum dado significativo pode fluir para cima na estrutura do programa.
Desafios que o testador pode enfrentar:
- Atrase muitos testes até que os stubs sejam substituídos por módulos reais.
- Desenvolva stubs que executem funções limitadas que simulem o módulo real.
- Integre o software da parte inferior da hierarquia para cima.
Observação: A primeira abordagem faz com que percamos algum controle sobre a correspondência entre testes específicos e a incorporação de módulos específicos. Isto pode resultar em dificuldade em determinar a causa dos erros, o que tende a violar a natureza altamente restrita da abordagem de cima para baixo.
A segunda abordagem é viável, mas pode levar a uma sobrecarga significativa, à medida que os stubs se tornam cada vez mais complexos.
Abordagem de baixo para cima
A integração ascendente inicia a construção e os testes com módulos no nível mais baixo da estrutura do programa. Neste processo, os módulos são integrados de baixo para cima.
Nesta abordagem o processamento necessário para os módulos subordinados a um determinado nível está sempre disponível e a necessidade de stubs é eliminada.
Este processo de teste de integração é realizado em uma série de quatro etapas
- Módulos de baixo nível são combinados em clusters que executam uma subfunção específica de software.
- Um driver é escrito para coordenar a entrada e a saída do caso de teste.
- O cluster ou build é testado.
- Os drivers são removidos e os clusters são combinados subindo na estrutura do programa.
À medida que a integração avança para níveis superiores, aumenta a necessidade de lições separadas para os drivers de teste. De fato, se os dois níveis superiores da estrutura do programa forem integrados de cima para baixo, o número de drivers pode ser reduzido substancialmente e a integração de clusters é bastante simplificada. A integração segue o padrão ilustrado abaixo.
Observação: Se os dois níveis superiores da estrutura do programa forem integrados de cima para baixo, o número de impulsionadores pode ser reduzido substancialmente e a integração das compilações é bastante simplificada.
Abordagem do Big Bang
Nesta abordagem, todos os módulos não são integrados até e a menos que todos os módulos estejam prontos. Depois de prontos, todos os módulos são integrados e então executados para saber se todos os módulos integrados estão funcionando ou não.
Nesta abordagem, é difícil saber a causa raiz da falha devido à integração de tudo de uma vez.
Além disso, haverá uma grande chance de ocorrência de bugs críticos no ambiente de produção.
Esta abordagem é adotada apenas quando o teste de integração precisa ser feito imediatamente.
Teste de integração de software de hardware
Teste de integração de software de hardware é um processo de teste de componentes de software de computador (CSC) para funcionalidades de alto nível no ambiente de hardware de destino. O objetivo dos testes de integração hardware/software é testar o comportamento do software desenvolvido integrado no componente de hardware.
Teste de integração hardware-software baseado em requisitos
O objetivo dos testes de integração de hardware/software baseados em requisitos é garantir que o software no computador de destino satisfaça os requisitos de alto nível. Erros típicos revelados por este método de teste incluem:
- Erros de interfaces de hardware/software
- Violações de particionamento de software.
- Incapacidade de detectar falhas por teste integrado
- Resposta incorreta a falhas de hardware
- Erro devido ao sequenciamento, cargas de entrada transitórias e transientes de potência de entrada
- Feedback faz loops de comportamento incorreto
- Controle incorreto ou impróprio do hardware de gerenciamento de memória
- Problema de contenção de barramento de dados
- Operação incorreta do mecanismo para verificar a compatibilidade e correção do software carregável em campo
A integração de software de hardware trata da verificação dos requisitos de alto nível. Todos os testes neste nível são realizados no hardware alvo.
- O teste de caixa preta é a principal metodologia de teste usada neste nível de teste.
- Definir casos de teste apenas dos requisitos de alto nível
- Um teste deve ser executado em hardware padrão de produção (no alvo)
Coisas a considerar ao projetar casos de teste para integração HW/SW
- Aquisição correta de todos os dados pelo software
- Dimensionamento e variedade de dados conforme esperado de hardware para software
- Saída correta de dados de software para hardware
- Dados dentro das especificações (faixa normal)
- Dados fora das especificações (faixa anormal)
- Dados de limite
- Interrompe o processamento
- Cronometragem
- Uso correto da memória (endereçamento, sobreposições, etc.)
- Transições de estado
Observação: Para testes de interrupção, todas as interrupções serão verificadas independentemente da solicitação inicial, passando pelo serviço completo e até a conclusão. Os casos de teste serão projetados especificamente para testar adequadamente as interrupções.
Teste de integração de software para software
Trata-se do teste do componente de software do computador operando dentro do ambiente do computador host/alvo, simulando todo o sistema [outros CSCs] e sua funcionalidade de alto nível.
O foco está no comportamento de um CSC em um ambiente host/alvo simulado. A abordagem utilizada para a integração de software pode ser incremental (de cima para baixo, de baixo para cima ou uma combinação de ambas, também chamada de abordagem sanduíche ou híbrida).
Critérios de entrada e saída para testes de integração
Uma vez definidas a abordagem e as duas variantes de integração, resta saber quando a equipe pode começar e quando pode terminar. Normalmente, ao realizar testes de integração, utiliza-se a estratégia ETVX (Critérios de Entrada, Tarefa, Validação e Critérios de Saída).
Critério de entrada:
- Conclusão de Teste de Unidade
Entradas:
- Dados de requisitos de software
- Documento de Projeto de Software
- Plano de Verificação de Software
- Documentos de integração de software
Atividades:
- Com base nos requisitos de alto e baixo nível, crie casos de teste e procedimentos
- Combine compilações de módulos de baixo nível que implementam uma funcionalidade comum
- Desenvolva um equipamento de teste
- Teste a compilação
- Depois que o teste é aprovado, a compilação é combinada com outras compilações e testada até que o sistema seja integrado como um todo.
- Execute novamente todos os testes na plataforma baseada no processador de destino e obtenha os resultados
Critérios de Saída:
- Conclusão bem sucedida da integração do módulo de Software no Hardware alvo
- Desempenho correto do software de acordo com os requisitos especificados
Saídas
- Relatórios de teste de integração
- Casos e procedimentos de teste de software [SVCP].
Desafios comuns em testes de integração de sistemas
Mesmo com uma abordagem sólida e critérios de saída claros, ambientes integrados criam problemas que nunca vêm à tona durante os testes unitários. Identificá-los precocemente mantém o cronograma realista.
- Incompatibilidade ambiental: o integrado ambiente de teste Raramente espelha a produção, portanto, defeitos de sincronização e configuração passam despercebidos até muito tarde.
- Preparação para dependência: Interfaces de terceiros e legadas frequentemente estão incompletas, forçando os testadores a depender de protótipos e simuladores por muito mais tempo do que o planejado.
- Inconsistência de dados: Dois módulos podem representar o mesmo registro de maneiras diferentes, produzindo incompatibilidades silenciosas em vez de falhas visíveis.
- Responsabilidade pelo defeito: Quando uma falha afeta duas equipes, a análise da causa raiz e gerenciamento de defeitos diminuir a velocidade visivelmente.
- Custo de regressão: cada nova interface amplia a teste de regressão suíte, portanto, a reexecução manual rapidamente se torna insustentável.
A maioria desses problemas são riscos de cronograma, e não becos sem saída técnicos. Definir datas de prontidão da interface, escopo do simulador e responsável pela triagem de defeitos antes da integração da primeira versão elimina a maioria deles. Para interfaces de propriedade do fornecedor, registre também o formato de mensagem acordado e um contato para escalonamento, pois a ausência de um responsável atrasa a correção por mais tempo do que o defeito justifica.
Melhores Práticas para Testes de Integração de Sistemas
Um ciclo de SIT (Teste de Integração de Sistemas) repetível depende menos de ferramentas do que da disciplina em relação a interfaces, dados e evidências. As cinco práticas abaixo se adequam tanto a um pequeno projeto embarcado quanto a um grande ambiente com múltiplos fornecedores, e cada uma delas reduz o retrabalho necessário para atingir os níveis de teste posteriores.
- Mapeie primeiro todas as interfaces. Antes de escrever um único caso de teste, liste cada troca de dados, sua direção, protocolo e proprietário.
- Priorize por risco. Verifique as interfaces que transportam dinheiro, identidade ou dados regulamentados antes das interfaces meramente ilustrativas.
- Elabore dados de teste realistas. Abrange intervalos normais, limites e anormais para que erros de escala e arredondamento sejam detectados precocemente.
- Automatize os caminhos estáveis. A interface de fio verifica um integração contínua pipeline para que cada compilação os verifique novamente.
- Manter evidências tracpossível. Vincule cada resultado a um requisito por meio de um tracmatriz de habilidade Assim, os critérios de saída podem ser comprovados, e não apenas afirmados.
⚠ Dica: Congele as especificações da interface antes do início da integração. Uma alteração tardia no formato de uma mensagem invalida os casos de teste em ambos os lados da interface e é a causa mais comum de retrabalho durante o teste de integração de sistemas (SIT).
