FACULDADES METROPOLITANAS UNIDAS - FMU

3º PERÍODO- CIÊNCIA DA COMPUTAÇÃO

ENGENHARIA DE SOFWARE I

TESTE DE SISTEMAS -INTEGRAÇÃO

SÃO PAULO, 2019

BEATRIZ ARAÚJO,DANILO CREMASCO, GABRIEL ,

TESTE DE INTEGRAÇÃO

Trabalho de Curso submetido à Faculdade

Metropolitana Unida-FMU como parte dos
requisitos necessários para a obtenção do Grau
de Bacharel em Ciência da Computação. Sob a
orientação do Professor Silvio Sampaio.

São Paulo/SP, 20
 Título: Testes de Integração

Trabalho de Curso submetido à Faculdades

Metropolitanas Unidas - FMU, como parte dos
requisitos necessários para a obtenção do Grau
de bacharel de Ciência da Computação.

Beatriz Caroline da Silva Araujo

RA: 3444839
___________________________
Danilo de Almeida Cremasco
RA: 5156983
__________________________
Nome:
Ra:___________________________

Nome:

Ra:___________________________

Nome:

Ra:___________________________

São Paulo, 26 de Abril de 2019

AGRADECIMENTOS

Agradeço o desempenho de toda a equipe deste

trabalho. Que arduamente utilizaram de
ferramentas poderosas para uma pesquisa
aprofundada do tema proposto; ao Mr.Silvio
Sampaio por sua dedicação para com seus alunos da
FMU.
 RESUMO

As exigências por softwares com maior qualidade têm motivado a definição de

métodos e técnicas para o desenvolvimento de softwares que atinjam os padrões de
qualidade impostos. Com isso, o interesse pela atividade de teste de software vem
aumentando nos últimos anos. Vários pesquisadores têm investigado os diferentes
critérios de teste, buscando obter uma estratégia de teste com baixo custo de
aplicação, mas ao mesmo tempo, com grande capacidade em revelar erros. O objetivo
deste minicurso é apresentar os aspectos teóricos e práticos relacionados à atividade
de teste de software. Uma síntese das técnicas de teste funcional, estrutural e
baseada em erros, bem como de critérios de teste pertencentes a cada uma delas,
será apresentada. Fatores utilizados na comparação e avaliação de critérios de teste
de software (custo, eficácia e strength) também serão abordados, Conceitos sobre
Testes de Integração em Sistemas. O Teste de integração de sistemas é basicamente
um processo de teste de software de alto nível no qual os testadores verificam se
todos os sistemas relacionados mantêm a integridade dos dados e podem operar em
coordenação com outros sistemas no mesmo ambiente.

Palavras chaves: Teste- Integração-Software- Sistema- Unidade

 ABSTRACT

The demands for higher quality software have motivated the definition of methods and
techniques for the development of software that meet the quality standards imposed.
As a result, interest in software testing activity has been increasing in recent years.
Several researchers have investigated the different test criteria, seeking to obtain a
test strategy with low cost of application, but at the same time, with great capacity to
reveal errors. The purpose of this mini-course is to present the theoretical and practical
aspects related to the software testing activity. A synthesis of functional, structural and
error-based test techniques, as well as test criteria pertaining to each, will be
presented. Factors used in the comparison and evaluation of software test criteria
(cost, effectiveness and strength) will also be addressed, Concepts on Integration
Testing in Systems. System Integration Testing is basically a high-level software
testing process in which testers verify that all related systems maintain data integrity
and can operate in coordination with other systems in the same environment.

Keywords: Test- Integration-Software- System- Unit

 LISTA DE ILUSTRAÇÕES (OPCIONAL)

Figura 1 .........................................................................................................................................

Figura 2 .........................................................................................................................................

Figura 3 .........................................................................................................................................

Figura 4 .........................................................................................................................................

Figura 5 .........................................................................................................................................
 SUMÁRIO

INTRODUÇÃO ................................................................ Error! Bookmark not defined.

1. TÍTULO DE CAPÍTULO TEM ESTILO “TÍTULO 1” . Error! Bookmark not defined.
1.1 O segundo nível de títulos tem estilo “Título 2”............... Error! Bookmark not defined.
1.1.1 O terceiro nível tem estilo “Título 3” ............................................ Error! Bookmark not defined.
1.1.2 Nível 3 ......................................................................................... Error! Bookmark not defined.
2. Segundo Capítulo ................................................... Error! Bookmark not defined.
2.1 Mais um teste com subitem ............................................ Error! Bookmark not defined.
2.1.1 Subitem ....................................................................................... Error! Bookmark not defined.
2.1.2 Subitem ....................................................................................... Error! Bookmark not defined.
3. NÍVEL UM ................................................................. Error! Bookmark not defined.
3.1 Nível dois ....................................................................... Error! Bookmark not defined.
3.1.1 Nivel 3 .......................................................................................... Error! Bookmark not defined.
3.2 Nivel 2 ............................................................................ Error! Bookmark not defined.
3.2.1 Nivel 3 .......................................................................................... Error! Bookmark not defined.
3.2.2 Nivel 3 .......................................................................................... Error! Bookmark not defined.
ii. CONSIDERAÇÕES FINAIS ...................................... Error! Bookmark not defined.
REFERÊNCIAS ......................................................................................................... 23
GLOSSÁRIO (OPCIONAL)............................................. Error! Bookmark not defined.
APÊNDICE (OPCIONAL)................................................ Error! Bookmark not defined.
ANEXOS ......................................................................... Error! Bookmark not defined.
ÍNDICE (OPCIONAL) ...................................................... Error! Bookmark not defined.
 1. Introdução

A Engenharia de Software evoluiu significativamente nas últimas décadas procurando

estabelecer técnicas, critérios, métodos e ferramentas para a produção de software,
em consequência da crescente utilização de sistemas baseados em computação em
praticamente todas as áreas da atividade humana, o que provoca uma crescente
demanda por qualidade e produtividade, tanto do ponto de vista do processo de
produção como do ponto de vista dos produtos gerados. A Engenharia de Software
pode ser definida como uma disciplina que aplica os princípios de engenharia com o
objetivo de produzir software de alta qualidade a baixo custo. Através de um conjunto
de etapas que envolvem o desenvolvimento e aplicação de métodos, técnicas e
ferramentas, a Engenharia de Software oferece meios para que tais objetivos possam
ser alcançados. O processo de desenvolvimento de software envolve uma série de
atividades nas quais, apesar das técnicas, métodos e ferramentas empregados, erros
no produto ainda podem ocorrer. Atividades agregadas sob o nome de Garantia de
Qualidade de Software têm sido introduzidas ao longo de todo o processo de
desenvolvimento, entre elas atividades de VV&T – Verificação, Validação e Teste,
com o objetivo de minimizar a ocorrência de erros e riscos associados. Dentre as
técnicas de verificação e validação, a atividade de teste é uma das mais utilizadas,
constituindo-se em um dos elementos para fornecer evidências da confiabilidade do
software em complemento a outras atividades, como por exemplo o uso de revisões
e de técnicas formais e rigorosas de especificação e de verificação. A atividade de
teste consiste de uma análise dinâmica do produto e é uma atividade relevante para
a identificação e eliminação de erros que persistem. Do ponto de vista de qualidade
do processo, o teste sistemático é uma atividade fundamental para a ascensão ao
Nível 3 do Modelo CMM do Software Engineering Institute — SEI . Ainda, o conjunto
de informação oriundo da atividade de teste é significativo para as atividades de
depuração, manutenção e estimativa de confiabilidade de software. Salienta-se que a
atividade de teste tem sido apontada como uma das mais onerosas no
desenvolvimento de software. Apesar deste fato, observa que aparentemente
conhece-se muito menos sobre teste de software do que sobre outros aspectos e/ou
atividades do desenvolvimento de software . O teste de produtos de software envolve
basicamente quatro etapas: planejamento de testes, projeto de casos de teste,
execução e avaliação dos resultados dos testes .Essas atividades devem ser
desenvolvidas ao longo do próprio processo de desenvolvimento de software, e em
geral, concretizam-se em três fases de teste: de unidade, de integração e de sistema.
O teste de unidade concentra esforços na menor unidade do projeto de software, ou
seja, procura identificar erros de lógica e de implementação em cada módulo do
software, separadamente. O teste de integração é uma atividade sistemática aplicada
durante a integração da estrutura do programa visando a descobrir erros associados
às interfaces entre os módulos; o objetivo é, a partir dos módulos testados no nível de
unidade, construir a estrutura de programa que foi determinada pelo projeto. O teste
de Integração depende muito do teste de Unidade, desta forma, o teste de sistema,
realizado após a integração do sistema, visa a identificar erros de funções e
características de desempenho que não estejam de acordo com a especificação [3].
Um ponto crucial na atividade de teste, independentemente da fase, é o projeto e/ou
a avaliação da qualidade de um determinado conjunto de casos de teste T utilizado
para o teste de um produto P, dado que, em geral, é impraticável utilizar todo o
domínio de dados de entrada para avaliar os aspectos funcionais e operacionais de
um produto em teste. O objetivo é utilizarem-se casos de teste que tenham alta
probabilidade de encontrar a maioria dos defeitos com um mínimo de tempo e esforço,
por questões de produtividade. Segundo Myers. O principal objetivo do teste de
Integração é verificar se partes / modulo de um sistema “conversa” entre módulos
desenvolvidos separadamente e que conversam entre sí.
2.Testes de Integração

O SIT (System Integration Testing - Teste de Integração do Sistema) é o teste geral

de todo o sistema, que é composto de muitos subsistemas. O principal objetivo do SIT
é garantir que todas as dependências do módulo de software estejam funcionando
adequadamente e que a integridade dos dados seja preservada entre os módulos
distintos de todo o sistema. O SIT é feito principalmente para verificar como os
módulos individuais interagem uns com os outros, quando integrados em um sistema
como um todo. Ele é conduzido após o teste da unidade e preciso que seja feito toda
vez que um novo módulo for adicionado ao sistema. É reconhecido como um teste de
baixo nível. Os casos de teste do SIT se concentram na interface entre os
componentes do sistema. Esse teste é da perspectiva da interface entre os módulos.
Ele é feito por desenvolvedores e testadores.Geralmente, os problemas encontrados
no SIT estariam relacionados ao fluxo de dados, fluxo de controle e afins.
O SUT (System Under Test) pode ser composto de hardware, banco de dados,
software, uma combinação de hardware e software ou um sistema que requer
interação humana (HITL - Human in the Loop Testing).
A partir do contexto da engenharia de software e do teste de software, o SIT pode ser
considerado como um processo de teste que verifica a co-ocorrência do sistema de
software com outros.
O SIT(como é tecnicamente conhecido ) tem um pré-requisito no qual vários
sistemas integrados subjacentes já foram submetidos e passaram no teste do
sistema. O SIT então testa as interações necessárias entre esses sistemas como um
todo. As entregas do SIT são passadas para o UAT (teste de aceitação do usuário).

2.1 Necessidade de teste de integração do sistema

A principal função do SIT é testar dependências entre diferentes componentes do

sistema e, portanto, o teste de regressão é uma parte importante do SIT.
Para projetos colaborativos, o SIT faz parte do STLC (ciclo de vida de teste de
software). Geralmente, uma rodada pré-SIT é conduzida pelo provedor de software
antes que o cliente execute seus próprios casos de teste SIT.
Na maioria das organizações que trabalham em projetos de TI seguindo o modelo
Agile Sprint, uma rodada de SIT é conduzida pela equipe de controle de qualidade
antes de cada lançamento. Os defeitos encontrados no SIT são enviados de volta para
a equipe de desenvolvimento e eles trabalham nas correções.
O release MVP (Minimum Viable Product) da sprint só ocorre quando é passado pelo
SIT.Nesse processo de teste necessário para expor as falhas que ocorrem quando a
interação acontece entre os subsistemas integrados.
Existem vários componentes usados no sistema e eles não podem ser testados
individualmente. Mesmo que a unidade seja testada individualmente, também existe
a possibilidade de que ela possa falhar quando combinada no sistema, pois há muitos
problemas que surgem quando os subsistemas interagem uns com os outros. Assim,
o SIT é muito necessário para expor e corrigir as falhas antes de implantar o sistema
no final do usuário. O SIT detecta os defeitos em um estágio inicial e, portanto,
economiza tempo e custo para corrigi-los posteriormente. Ele também ajuda você a
obter um feedback mais rápido sobre a aceitabilidade do módulo.
1.Figura A imagem abaixo nos níveis de teste tornaria o fluxo do teste de
unidade para o UAT claro para você:2.A granularidade do SIT

Fonte:

3.Técnicas SIT:

Principalmente, existem quatro abordagens para fazer o SIT:

1. Abordagem de cima para baixo
2. Abordagem de baixo para cima
3. Abordagem sanduíche
4. Abordagem do Big Bang

A abordagem de cima para baixo e abordagem de baixo para cima é um tipo de

abordagem incremental. Vamos começar a discussão com a abordagem Top-down
primeiro.

3.1 Abordagem Top-Down:

Sob este aspecto, o teste começa com apenas o módulo mais alto de uma aplicação,
ou seja, a interface do usuário que chamamos como um driver de teste.
A funcionalidade dos módulos subjacentes é simulada com stubs. O módulo superior
é integrado com o stub de módulo de nível inferior um por um e, posteriormente, a
funcionalidade é testada.
Quando cada teste é concluído, o stub é substituído pelo módulo real. Os módulos
podem ser integrados de maneira ampla ou de primeira profundidade. O teste
continua até que todo o aplicativo seja construído.
A vantagem dessa abordagem é que não há necessidade de drivers e os casos de
teste podem ser especificados em termos da funcionalidade do sistema.
O principal desafio neste tipo de abordagem é a dependência da disponibilidade da
funcionalidade do módulo de nível inferior. Pode haver um atraso nos testes até que
os módulos reais sejam substituídos por stubs, e escrever o mesmo também é difícil.
Figura 2. Modelo Teste De integração Top Down

Fonte:

3.2 Abordagem de baixo para cima:

Esta técnica começa a partir do módulo superior e progride gradualmente para os

módulos inferiores. Somente o módulo superior é testado em unidade isoladamente.
Depois disso, os módulos inferiores são integrados um por um. O processo é repetido
até que todos os módulos sejam integrados e testados. Elimina as limitações da
abordagem de cima para baixo.
Nesse método, primeiro, os módulos de nível mais baixo são montados para formar
clusters. Esses clusters servem como uma subfunção do aplicativo. Em seguida, um
driver é criado para gerenciar a entrada e a saída do caso de teste. Depois disso, o
cluster é testado.
Depois que o cluster é testado, o driver é removido e o cluster é combinado com o
próximo nível superior. Este processo continua até que toda a estrutura da aplicação
seja alcançada.
Não há necessidade de stubs nessa abordagem. Ele se torna simplificado à medida
que o processamento se move para cima e a necessidade de drivers é reduzida. Essa
abordagem é aconselhável para fazer o SIT para sistemas orientados a objetos,
sistemas em tempo real e sistemas com necessidades de desempenho rigorosas.
No entanto, a limitação dessa abordagem é o subsistema mais importante, ou seja, a
interface do usuário é testada no último.

3.3 Abordagem Sanduíche:

Aqui, as abordagens top down e bottom up discutidas acima são combinadas juntas.
O sistema é percebido como tendo três camadas - a camada do meio que é a camada
de destino, uma camada acima do alvo e uma camada abaixo do alvo. O teste é feito
nas duas direções e se reúne na camada de destino que está no meio e isso é ilustrado
na imagem abaixo.
Figura 3. Estratégia de Testes Sandwich

Fonte:

Uma vantagem dessa abordagem é que a camada superior e a camada inferior do

sistema podem ser testadas em paralelo. No entanto, a limitação dessa abordagem é
que ela não testa exaustivamente os subsistemas individuais antes da integração.
Para eliminar essa limitação, modificamos o teste de sanduíche em que a integração
das camadas superior, intermediária e inferior é testada em paralelo usando stubs e
drivers.
4. Abordagem do Big Bang:

A abordagem Big Bang integra todos os módulos de uma só vez, ou seja, não integra os
módulos um por um. Verifica se o sistema funciona como esperado ou não, uma vez
integrado. Se algum problema for detectado no módulo completamente integrado, será
difícil descobrir qual módulo causou o problema. É um processo demorado de encontrar
um módulo que possui um defeito em si, já que isso levaria tempo e uma vez que o
defeito fosse detectado, a fixação do mesmo custaria mais alto do que o defeito é
detectado no estágio posterior.
Nesta abordagem, a integração é feita quando todos os módulos do aplicativo estão
completamente prontos. O teste é feito após a integração de todos os módulos para
verificar se o SIT está funcionando ou não.
É um desafio encontrar a causa raiz do problema nessa abordagem, já que tudo é
integrado de uma só vez, ao contrário dos testes incrementais. Sendo geralmente
adotada quando apenas uma rodada de SIT é necessária. Uma das desvantagens, é
que é difícil detectar o módulo que está causando um problema, requer todos os
módulos todos juntos para testes, o que, por sua vez, leva a menos tempo para testes,
como design, desenvolvimento, integração levaria a maior parte do tempo.
O teste é realizado de uma só vez, o que, portanto, não deixa tempo para o teste
crítico do módulo isoladamente.Sendo assim, perfeito para uso de sistema pequenos.

Figura. 4. Abordagem Teste de Big Bang

Fonte:
 5. Abordagem bottom-up

O teste bottom-up, como o nome sugere, começa na unidade mais baixa ou mais
interna do aplicativo e, gradualmente, sobe. O teste de Integração começa no módulo
mais baixo e progride gradualmente em direção aos módulos superiores do aplicativo.
Essa integração continua até que todos os módulos sejam integrados e todo o
aplicativo seja testado como uma única unidade.
Neste caso, os módulos B1C1, B1C2 e B2C1, B2C2 são o módulo mais baixo que é
testado em unidade. Os módulos B1 e B2 ainda não estão desenvolvidos. A
funcionalidade do Módulo B1 e B2 é que ele chama os módulos B1C1, B1C2 e B2C1,
B2C2. Como B1 e B2 ainda não estão desenvolvidos, precisaríamos de algum
programa ou de um “estimulador” que chamará os módulos B1C1, B1C2 e B2C1,
B2C2. Esses programas estimuladores são chamados DRIVERS .
Em palavras simples, os DRIVERS são os programas fictícios que são usados para
chamar as funções do módulo mais baixo em um caso em que a função de chamada
não existe. A técnica de baixo para cima requer que o driver do módulo alimente a
entrada do caso de teste para a interface do módulo que está sendo testado.
A vantagem dessa abordagem é que, se houver uma falha grave na unidade mais
baixa do programa, é mais fácil detectá-la e medidas corretivas podem ser tomadas.
A desvantagem é que o programa principal realmente não existe até que o último
módulo seja integrado e testado. Como resultado, as falhas de design de nível mais
alto serão detectadas apenas no final.

6. Como fazer o teste de integração do Sistema

É uma técnica sistemática para construir a estrutura do programa durante a realização de

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 as causas de isolamento são complicadas pela
vasta expansão de todo o programa. Uma vez que esses erros sejam corrigidos e
corrigidos, um novo aparecerá, e o processo continuará continuamente em um loop
infinito . Para evitar essa situação, outra abordagem é usada, Integração Incremental.
Veremos mais detalhes sobre uma abordagem incremental mais adiante no tutorial.
Existem alguns métodos incrementais, como os testes de integração são conduzidos em
um sistema baseado no processador de destino. A metodologia utilizada é o Black Box
Testing . A integração de baixo para cima ou de cima para baixo pode ser usada.
Os casos de teste são definidos usando apenas os requisitos de software de alto nível.
A integração de software também pode ser obtida em grande parte no ambiente host, com
unidades específicas para o ambiente de destino continuando a ser simuladas no host.
Testes repetidos no ambiente de destino para confirmação serão novamente necessários.
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 praticidade de conduzir a integração
de software no ambiente host dependerá da quantidade de funcionalidade específica de
destino existente. Para alguns sistemas embarcados, o acoplamento com o ambiente de
destino será muito forte, tornando impraticável a realização de integração de software no
ambiente host.Os 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 podem ser
baseados predominantemente no ambiente host, com os níveis posteriores de integração
de software se tornando mais dependentes do ambiente de destino.

7.Critérios de Entrada e Saída do Teste de Integração

Critérios de entrada e saída para a fase de teste de integração em qualquer modelo de

desenvolvimento de software

7.1 Critério de entrada:

1.Componentes / Módulos Testados Unitários

2.3Todos os erros de alta prioridade fixados e fechados
3.Todos os módulos a serem preenchidos e integrados com sucesso.
4.Testes de integração Planejar, testar caso, cenários a serem assinados e documentados.
5.Ambiente de teste necessário a ser configurado para teste de integração

7.2 Critério de saída:

1.Teste bem-sucedido de aplicativo integrado.

2.Casos de teste executados são documentados
3.Todos os erros de alta prioridade fixados e fechados
4.Documentos técnicos a serem apresentados, seguidos de notas de lançamento.
5.Melhores práticas / diretrizes para testes de integração
6.Primeiro, determine a Estratégia de Teste de Integração que pode ser adotada e depois
7.prepare os casos de teste e teste os dados de acordo.
8.Estude o projeto de arquitetura do aplicativo e identifique os módulos críticos. Estes
precisam ser testados em prioridade.
9.Obtenha os designs de interface da equipe do Architectural e crie casos de teste para
10.verificar todas as interfaces em detalhes. A interface com o aplicativo de banco de
dados / hardware / software externo deve ser testada em detalhes.
4.Conclusão

Conclusão Neste texto foram apresentados alguns critérios de teste de software e conceitos
pertinentes, com ênfase naqueles considerados mais promissores a curto e médio prazo: os
critérios 45 OAAA OAAN OABA OABN OAEA OBAA OBAN OBBA OBBN OBEA OBNG
OCNG OEAA OEBA OLLN OLNG OMMO OPPO ORRN SBRC SBRn SCRB SCRn SDWD
SMTC SMTT SSDL SSWM STRI STRP SWDD CGCR CLCR OALN OARN OASA OASN
OBLN OBRN OBSA OBSN OESA OIPM OLAN OLBN OLRN OLSN ORAN ORBN ORLN
ORSN OSAA OSAN OSBA OSBN OSEA OSLN OSRN OSSA OSSN SGLR SRSR VASM
VDTR VTWD CGSR CLSR CRCR OCOR SMVB SSOM VGAR VGPR VGSR VGTR VLAR
VLPR VLSR VLTR VSCR CGSR CLSR CRCR OCOR SMVB SSOM VGAR VGPR VGSR
VGTR VLAR VLPR VLSR VLTR VSCR CGCR CGSR CLCR CLSR CRCR OASA OASN
OBSA OBSN OCOR OESA OSAA OSAN OSBA OSBN OSEA OSSA OSSN SMVB SRSR
SSOM VASM VDTR VGAR VGSR VLAR VLSR VTWD C C++ Java Figura 19:
Classificação Operadores × Linguagem. baseados em fluxo de dados, o critério Análise de
Mutantes e o critério Mutação de Interface. Foram também apresentadas as ferramentas de teste
PokeTool, Proteum e PROTEUM/IM, assim como identificadas várias outras iniciativas e
esforços de automatização desses critérios, dada a relevância desse aspecto para a qualidade e
produtividade da própria atividade de teste. Procurou-se ressaltar o aspecto complementar das
diversas técnicas e critérios de teste e a relevância de se conduzir estudos empíricos para a
formação de um corpo de conhecimento que favoreça o estabelecimento de estratégias de teste
incrementais que explorem as diversas características dos critérios. Nessas estratégias seriam
aplicados inicialmente critérios “mais fracos” e talvez menos eficazes para a avaliação da
adequação do conjunto de casos de teste, e em função da disponibilidade de orçamento e de
tempo, incrementalmente, poderiam ser utilizados critérios mais “fortes” e eventualmente mais
eficazes, porém, em geral, mais caros. Estudos empíricos são conduzidos no sentindo de avaliar
os aspectos de custo, strength e eficácia dos critérios de teste, buscando contribuir para o
estabelecimento de estratégias de teste eficazes, de baixo custo e para a transformação do estado
da prática, no que tange ao uso de critérios e ferramentas de teste. Discutiu-se a definição de
critério de teste para a aplicação no contexto de especificações baseadas em Redes de Petri,
Máquinas de Estado Finito, Statecharts, Estelle e SDL. Mecanismos e ferramentas de teste para
apoiar a aplicação desse critério no contexto de especificações têm sido desenvolvidas, com por
exemplo as ferramentas Proteum-RS/FSM, Proteum-RS/ST, Proteum-RS/PN e CATSDL que
apóiam o teste de especificações em MEFs, Statecharts, Redes de Petri e SDL, respectivamente.
É importante observar que o conjunto de casos de teste obtido para testar e validar a
especificação pode ser utilizado durante o teste de conformidade da 46 implementação em teste.
A relação existente entre esses níveis de abstração: especificação e implementação estão sendo
investigados. Mostrou-se também que os conceitos e mecanismos desenvolvidos originalmente
para o teste de programas procedimentais podem ser utilizados no contexto do paradigma de
desenvolvimento de software orientado a objeto, com as devidas adaptações. Extensões de
critérios de teste baseados em fluxo de controle, fluxo de dados e de mutação foram propostas
para o teste de programas OO. Além disso, ferramentas de apoio a esses critérios também foram
desenvolvidas, como por exemplo as ferramentas X Suds e JaBUTi. De uma maneira geral,
pode-se dizer que a atividade de teste tem forte relação com a atividade de Qualidade do
Software, sendo que testes bem conduzidos procuram aumentar a confiabilidade do software.
Além disso, o conjunto de informações obtidos na atividade de teste é significativo para as
atividades de depuração, estimativa de confiabilidade e de manutenção. Referências [1] M. E.
Delamaro and J. C. Maldonado. Uma visão sobre a aplicação da análise
REFERÊNCIAS

Ruslan Desyatnikov. blog do Software Testing Help. 1. Ed. Petrópolis: Dezembro, 2018.
Martin Fowler; MartinsFowler.com. Testes de sistemas Integração. 2. Ed. Dourados:
Evangraf, 16,janeiro,2018.
Sem Autor.Software Testing. 2.in Link: http://softwaretestingfundamentals.com/integration-
testing/, Acesso: 00:40- 14.abril 2019
R. S. Pressman. Software Engineering – A Practitioner’s Approach. McGraw-Hill, 4
edition, 1997.
J. C. Maldonado. Critérios Potenciais Usos: Uma Contribuição ao Teste Estrutural de
Software. PhD thesis, DCA/FEE/UNICAMP, Campinas, SP, July 1991.
M. C. Paulk. Capability maturity model for software – version 1.1. Technical ReportTR-24,
CMU/SEI, February 1993. T. J. Ostrand and E. J. Weyuker. Using data flow analysis for
regression testing. In Sixth
Annual Pacific Northwest Software Quality Conference, Portland – Oregon, September
1988.
J. Hartmann and D. J. Robson. Techniques for selective revalidation. IEEE Software,
7(1):31–36, January/February 1990.
A. Veevers and A. Marshall. A relationship between software coverage metrics and
reliability. Software Testing, Verification and Reliability, 4(1):3–8, 1994.
G. S. Varadan. Trends in reliability and test strategies. IEEE Software, 12(3):10, May
1995.
G. J. Myers. The Art of Software Testing. Wiley, New York, 1979.
_________________________________________________________________________
A sociedade brasileira. São Paulo: Timétis, 1997.
Techtopidia: Link to : https://www.techopedia.com/definition/24590/system-integration-
testing-sit -Acesso: 15:12- 03.2019
GeekForgeek link:
https://www.geeksforgeeks.org/software-engineering-integration-testing/
Acesso: 14/04/2019- 00:40