Què és la prova d'integració (Tutorial amb exemple de prova d'integració)

what is integration testing

Què és la prova d'integració: apreneu amb exemples de proves d'integració

Les proves d’integració es fan per provar els mòduls / components quan s’integren per verificar que funcionin com s’esperava, és a dir, provar els mòduls que funcionen bé individualment no té problemes quan s’integren.

Quan es parla de proves de gran aplicació mitjançant la tècnica de proves de caixa negra, es tracta de la combinació de molts mòduls que estan fortament acoblats entre si. Podem aplicar els conceptes de tècnica de proves d’integració per provar aquest tipus d’escenaris.

Llista de tutorials coberts en aquesta sèrie:

Tutorial # 1: Què és la prova d'integració? (Aquest tutorial)
Tutorial # 2: Què és la prova incremental?
Tutorial # 3: Què és la prova de components
Tutorial # 4: Integració contínua
Tutorial # 5 Diferència entre la prova unitària i la integració
Tutorial # 6: Top 10 d'eines de proves d'integració

Què aprendreu:

• Què són les proves d'integració?
• Per què la prova d’integració?
• Avantatges
• Desafiaments
• Tipus de proves d’integració
  • Enfocament del Big Bang:
• Enfocaments d’integració de proves
  • Enfocament ascendent:
  • Enfocament de dalt a baix
• Prova d’integració de l’aplicació GUI
  • Exemple de proves d'integració:
• Passos per iniciar les proves d'integració
• Criteris d’entrada / sortida per a proves d’integració
• Casos de prova d’integració
• La integració és una tècnica de caixa blanca o caixa negra?
• Eines de proves d’integració
• Proves d’integració de sistemes
• Diferència entre proves d’integració i proves de sistemes
• Conclusió
• Lectura recomanada

Què són les proves d'integració?

El significat de les proves d’integració és bastant senzill. Integrar / combinar el mòdul provat unitat per un i provar el comportament com a unitat combinada.

La funció o objectiu principal d’aquestes proves és provar les interfícies entre les unitats / mòduls.

Normalment realitzem proves d’integració després de la “prova unitària”. Un cop creades i provades totes les unitats individuals, comencem a combinar aquests mòduls 'Unit Tested' i comencem a fer les proves integrades.

La funció o objectiu principal d’aquestes proves és provar les interfícies entre les unitats / mòduls.

Els mòduls individuals es proven primer de forma aïllada. Un cop provats els mòduls, s’integren un a un, fins que s’integren tots els mòduls, per comprovar el comportament combinacional i validar si els requisits s’implementen correctament o no.

Aquí hem d’entendre que les proves d’integració no tenen lloc al final del cicle, sinó que es duen a terme simultàniament amb el desenvolupament. Per tant, en la majoria de les ocasions, tots els mòduls no estan disponibles per provar i això és el que suposa el repte de provar alguna cosa que no existeix.

Per què la prova d’integració?

Creiem que les proves d’integració són complexes i requereixen una certa capacitat de desenvolupament i lògica. Això és cert! Aleshores, quin és el propòsit d’integrar aquestes proves a la nostra estratègia de proves?

Aquí hi ha alguns motius:

1. Al món real, quan es desenvolupen aplicacions, es divideix en mòduls més petits i als desenvolupadors individuals se’ls assigna 1 mòdul. La lògica implementada per un desenvolupador és bastant diferent a la d’un altre desenvolupador, per la qual cosa és important comprovar si la lògica implementada per un desenvolupador és d’acord amb les expectatives i donar el valor correcte d’acord amb els estàndards prescrits.
2. Moltes vegades la cara o l'estructura de les dades canvia quan viatja d'un mòdul a un altre. Alguns valors s’afegeixen o s’eliminen, cosa que provoca problemes als mòduls posteriors.
3. Els mòduls també interactuen amb algunes eines o API de tercers que també han de comprovar-se que les dades acceptades per aquesta API / eina són correctes i que la resposta generada també és l’esperada.
4. Un problema molt comú a les proves: canvis freqüents de requisits. :) Molts desenvolupadors de vegades implementen els canvis sense provar-los per cap unitat. Les proves d’integració esdevenen importants en aquest moment.

Avantatges

Hi ha diversos avantatges d’aquestes proves i poques d’elles es detallen a continuació.

• Aquesta prova assegura que els mòduls / components integrats funcionin correctament.
• Les proves d’integració es poden iniciar un cop estiguin disponibles els mòduls a provar. No requereix que es completi l'altre mòdul per fer proves, ja que es poden utilitzar Stubs i Drivers per al mateix.
• Detecta els errors relacionats amb la interfície.

Desafiaments

A continuació s’enumeren alguns reptes relacionats amb la prova d’integració.

# 1) La prova d’integració significa provar dos o més sistemes integrats per assegurar-se que el sistema funciona correctament. No només s’haurien de provar els enllaços d’integració, sinó que s’haurien de fer proves exhaustives tenint en compte l’entorn per garantir que el sistema integrat funcioni correctament.

És possible que hi hagi diferents camins i permutacions que es puguin aplicar per provar el sistema integrat.

# 2) La gestió de les proves d’integració es fa complexa a causa dels pocs factors que hi intervenen, com ara la base de dades, la plataforma, l’entorn, etc.

# 3) Tot i integrar qualsevol sistema nou amb el sistema heretat, requereix molts canvis i esforços de prova. El mateix s'aplica en integrar dos sistemes heretats.

# 4) La integració de dos sistemes diferents desenvolupats per dues empreses diferents és un gran repte quant a la incidència d’un dels sistemes sobre l’altre sistema si es fa algun canvi en algun dels sistemes, no està segur.

Per minimitzar l’impacte durant el desenvolupament d’un sistema, s’haurien de tenir en compte poques coses, com la possible integració amb altres sistemes, etc.

Tipus de proves d’integració

A continuació es mostra un tipus d’integració de proves juntament amb els seus avantatges i desavantatges.

Enfocament del Big Bang:

L’enfocament del Big Bang integra tots els mòduls d’una sola vegada, és a dir, no serveix per integrar els mòduls d’un en un. Verifica si el sistema funciona com s’esperava o no un cop integrat. Si es detecta algun problema al mòdul completament integrat, es fa difícil saber quin mòdul ha causat el problema.

L’enfocament del Big Bang és un procés que requereix molt de temps per trobar un mòdul que tingui un defecte en si mateix, ja que trigaria temps i, un cop detectat el defecte, solucionar-lo costaria molt a mesura que es detectés el defecte en la fase posterior.

Avantatges de l'enfocament del Big Bang:

• És un bon enfocament per a sistemes petits.

Desavantatges de l'enfocament del Big Bang:

• És difícil detectar el mòdul que causa un problema.
• L'enfocament del Big Bang requereix tots els mòduls junts per provar-los, la qual cosa, al seu torn, comporta menys temps per provar-los, ja que el disseny, el desenvolupament i la integració trigarien la major part del temps.
• Les proves només es realitzen alhora, cosa que no deixa temps per a la prova de mòduls crítics de forma aïllada.

Passos de proves d'integració:

1. Prepareu la integració Pla de proves.
2. Prepareu escenaris de proves d’integració i casos de proves.
3. Prepareu scripts d'automatització de proves.
4. Executeu casos de proves.
5. Notifiqueu els defectes.
6. Feu un seguiment i torneu a provar els defectes.
7. Les proves i proves continuen fins que es completen les proves d'integració.

Enfocaments d’integració de proves

Hi ha fonamentalment dos enfocaments per fer la integració de proves:

1. Enfocament de baix a dalt
2. Enfocament de dalt a baix.

Considerem la figura següent per provar els enfocaments:

Enfocament ascendent:

Les proves de baix a dalt, com el seu nom indica, comencen des de la unitat més baixa o la més interna de l'aplicació i es mou cap amunt. Les proves d’integració comencen des del mòdul més baix i progressen progressivament cap als mòduls superiors de l’aplicació. Aquesta integració continua fins que tots els mòduls s’integren i tota l’aplicació es prova com una sola unitat.

En aquest cas, els mòduls B1C1, B1C2 i B2C1, B2C2 són el mòdul més baix que es prova a la unitat. Els mòduls B1 i B2 encara no estan desenvolupats. La funcionalitat dels mòduls B1 i B2 és que crida als mòduls B1C1, B1C2 i B2C1, B2C2. Com que B1 i B2 encara no estan desenvolupats, necessitaríem algun programa o un 'estimulador' que anomeni mòduls B1C1, B1C2 i B2C1, B2C2. Aquests programes estimuladors s’anomenen CONDUCTORS .

En paraules simples, CONDUCTORS són els programes ficticis que s'utilitzen per trucar a les funcions del mòdul més baix en un cas quan la funció de trucada no existeix. La tècnica ascendent requereix que el controlador del mòdul alimenti l'entrada de casos de prova a la interfície del mòdul que s'està provant.

L’avantatge d’aquest enfocament és que, si hi ha un error important a la unitat més baixa del programa, és més fàcil detectar-lo i es poden prendre mesures correctores.

L’inconvenient és que el programa principal no existeix fins que l’últim mòdul no s’integra i es prova. Com a resultat, els defectes de disseny de nivell superior només es detectaran al final.

Enfocament de dalt a baix

Aquesta tècnica parteix del mòdul superior i progressivament cap als mòduls inferiors. Només el mòdul superior es prova aïlladament. Després, els mòduls inferiors s’integren un per un. El procés es repeteix fins que tots els mòduls s’integrin i es provin.

com obrir un fitxer eps en un PC

En el context de la nostra figura, les proves comencen des del mòdul A i els mòduls inferiors B1 i B2 s’integren un per un. Ara els mòduls inferiors B1 i B2 no estan disponibles per a la integració. Per tant, per provar els mòduls A més alts, desenvolupem “ ROBUS '.

Es pot referir a 'Stubs' com a codi un fragment que accepta les entrades / sol·licituds del mòdul superior i retorna els resultats / resposta. D’aquesta manera, malgrat que no existeixen els mòduls inferiors, podem provar el mòdul superior.

En escenaris pràctics, el comportament dels troncs no és tan senzill com sembla. En aquesta era de mòduls i arquitectura complexos, el mòdul anomenat, la majoria de les vegades implica una lògica empresarial complexa com connectar-se a una base de dades. Com a resultat, crear Stubs es converteix en un procés tan complex i que requereix temps com el mòdul real. En alguns casos, el mòdul Stub pot resultar més gran que el mòdul estimulat.

Tant Stubs com drivers són un fragment de codi fals que s’utilitza per provar els mòduls “inexistents”. Desencadenen les funcions / mètode i retornen la resposta, que es compara amb el comportament esperat

Concloem alguna diferència entre Butllos i conductor :

L’únic canvi és constant en aquest món, de manera que tenim un altre enfocament anomenat “ Proves de sandvitx ”Que combina les característiques de l’enfocament de dalt a baix i de baix a dalt. Quan provem programes enormes com els sistemes operatius, hem de tenir algunes tècniques més que siguin eficients i augmentin la confiança. Les proves de sandvitx tenen un paper molt important aquí, on es comencen simultàniament les proves de dalt a baix i de baix a dalt.

La integració comença amb la capa mitjana i es mou simultàniament cap amunt i cap avall. En el cas de la nostra figura, les nostres proves començaran des de B1 i B2, on un braç provarà el mòdul superior A i un altre braç provarà els mòduls inferiors B1C1, B1C2 i B2C1, B2C2.

Com que tant l'enfocament comença simultàniament, aquesta tècnica és una mica complexa i requereix més gent juntament amb conjunts d'habilitats específics i, per tant, s'afegeix al cost.

Prova d’integració de l’aplicació GUI

Ara parlem de com podem implicar proves d’integració en la tècnica Black Box.

Tots entenem que una aplicació web és una aplicació de diversos nivells. Tenim un frontal que és visible per a l’usuari, tenim una capa mitjana que té lògica empresarial, tenim una capa més que fa algunes validacions, integra algunes API de tercers, etc., llavors tenim la capa posterior que és la base de dades.

Exemple de proves d'integració:

Consulteu l'exemple següent:

Sóc el propietari d’una empresa publicitària i publico anuncis en diferents llocs web. A finals de mes, vull veure quantes persones han vist els meus anuncis i quantes persones han fet clic als meus anuncis. Necessito un informe per als meus anuncis que es mostren i cobro en conseqüència als meus clients.

Programari GenNext vaig desenvolupar aquest producte per a mi i a continuació hi havia l'arquitectura:

Ceba - Mòdul d’interfície d’usuari, visible per a l’usuari final, on es donen totes les entrades.
BL - És el mòdul Business Logic, que inclou tots els càlculs i mètodes específics de l'empresa.
VAL - És el mòdul de validació, que té totes les validacions de la correcció de l'entrada.
CNT - És el mòdul de contingut que conté tots els continguts estàtics, específics per a les entrades introduïdes per l'usuari. Aquests continguts es mostren als informes.
A - És el mòdul Engine, aquest mòdul llegeix totes les dades que provenen del mòdul BL, VAL i CNT i extreu la consulta SQL i la activa a la base de dades.
Programador - És un mòdul que programa tots els informes en funció de la selecció de l'usuari (mensual, trimestral, semestral i anual)
DB - És la base de dades.

Ara, després d’haver vist l’arquitectura de tota l’aplicació web, com una sola unitat, les proves d’integració, en aquest cas, se centraran en el flux de dades entre els mòduls.

Les preguntes aquí són:

1. Com llegiran i interpretaran les dades introduïdes al mòdul d’interfície d’usuari el mòdul BL, VAL i CNT?
2. El mòdul BL, VAL i CNT està rebent les dades correctes de la IU?
3. En quin format es transfereixen les dades de BL, VAL i CNT al mòdul EQ?
4. Com llegirà l’equalitzador les dades i extreurà la consulta?
5. La consulta s'ha extret correctament?
6. El programador obté les dades correctes per als informes?
7. El conjunt de resultats rebut per l'EN, de la base de dades, és correcte i com s'esperava?
8. És EN capaç d'enviar la resposta als mòduls BL, VAL i CNT?
9. El mòdul d’interfície d’usuari és capaç de llegir les dades i mostrar-les adequadament a la interfície?

Al món real, la comunicació de dades es realitza en format XML. Per tant, qualsevol informació que l'usuari introdueixi a la IU, es converteix en un format XML.

En el nostre escenari, les dades introduïdes al mòdul d’interfície d’usuari es converteixen en un fitxer XML que és interpretat pels 3 mòduls BL, VAL i CNT. El mòdul EN llegeix el fitxer XML resultant generat pels 3 mòduls i n'extreu l'SQL i consulta a la base de dades. El mòdul EN també rep el conjunt de resultats i el converteix en un fitxer XML i el torna al mòdul d’interfície d’usuari que converteix els resultats en forma llegible per l’usuari i el mostra.

Al centre tenim el mòdul de planificació que rep el conjunt de resultats del mòdul EN, crea i programa els informes.

Llavors, on apareixen les proves d’integració?

Bé, provar si la informació / dades flueix correctament o no serà la vostra prova d'integració, que en aquest cas validaria els fitxers XML. Els fitxers XML es generen correctament? Tenen les dades correctes? S'estan transferint les dades correctament d'un mòdul a un altre? Totes aquestes coses es provaran com a part de les proves d’integració.

Proveu de generar o obtenir fitxers XML i actualitzeu les etiquetes i comproveu el comportament. Això és molt diferent de les proves habituals que solen fer els verificadors, però això afegirà valor al coneixement i comprensió de l'aplicació dels verificadors.

Poques altres condicions de prova de mostra poden ser les següents:

• Les opcions del menú generen la finestra correcta?
• Les finestres poden invocar la finestra en proves?
• Per a cada finestra, identifiqueu les trucades de funció de la finestra que l'aplicació hauria de permetre.
• Identifiqueu totes les trucades de la finestra a altres funcions que l'aplicació hauria de permetre
• Identifiqueu les trucades reversibles: el tancament d’una finestra trucada hauria de tornar a la finestra de trucades.
• Identifiqueu les trucades irreversibles: la finestra de trucades es tanca abans que aparegui la finestra trucada.
• Proveu les diferents maneres d'executar trucades a una altra finestra, per exemple. - menús, botons, paraules clau.

Passos per iniciar les proves d'integració

1. Compreneu l'arquitectura de la vostra aplicació.
2. Identifiqueu els mòduls
3. Comprendre el que fa cada mòdul
4. Compreneu com es transfereixen les dades d’un mòdul a un altre.
5. Comprendre com s’introdueixen i es reben les dades al sistema (punt d’entrada i punt de sortida de l’aplicació)
6. Segregueu l’aplicació per adaptar-la a les vostres necessitats de proves.
7. Identifiqueu i creeu les condicions de prova
8. Prengui una condició a la vegada i anoti els casos de prova.

Criteris d’entrada / sortida per a proves d’integració

Criteris d'entrada:

• El document del pla de proves d’integració es tanca i s’aprova.
• S’han preparat casos de proves d’integració.
• S'han creat dades de prova.
• Proves d’unitat dels mòduls / components desenvolupats està complet.
• Tots els defectes crítics i d’alta prioritat estan tancats.
• L'entorn de prova està configurat per a la integració.

Criteris de sortida:

• S'han executat tots els casos de prova d'integració.
• No s’obren defectes crítics i de prioritat P1 i P2.
• S'ha preparat l'informe de proves.

Casos de prova d’integració

Els casos de proves d 'integració se centren principalment en el interfície entre mòduls, enllaços integrats, transferència de dades entre els mòduls com a mòduls / components que ja estan provats per unitats, és a dir, ja s’han tractat la funcionalitat i els altres aspectes de prova.

Per tant, la idea principal és provar si la integració de dos mòduls de treball funciona com s’esperava quan s’integra.

Per a exemples de casos de prova d'integració per a l'aplicació Linkedin, s'inclouran:

• Verificar l’enllaç de la interfície entre la pàgina d’inici de sessió i la pàgina d’inici, és a dir, quan un usuari introdueix les credencials i registra, s’hauria de dirigir a la pàgina inicial.
• Verificar l'enllaç de la interfície entre la pàgina d'inici i la pàgina de perfil, és a dir, s'hauria d'obrir.
• Verifiqueu l’enllaç de la interfície entre la pàgina de xarxa i les vostres pàgines de connexió, és a dir, si feu clic al botó Accepta a Invitacions de la pàgina de xarxa, apareixerà la invitació acceptada a la pàgina de connexió un cop feta clic.
• Verifiqueu l’enllaç de la interfície entre les pàgines de notificacions i digueu el botó Felicitats, és a dir, si feu clic al botó Digues felicitacions hauria d’anar directament a la finestra del missatge nou.

Es poden escriure molts casos de proves d’integració per a aquest lloc específic. Els quatre punts anteriors són només un exemple per entendre quins casos de prova d’integració s’inclouen a les proves.

La integració és una tècnica de caixa blanca o caixa negra?

La tècnica de proves d’integració es pot comptar tant en caixes negres com en tècnica de caixa blanca . Tècnica de caixa negra és on un provador no necessita tenir cap coneixement intern del sistema, és a dir, no es requereix coneixement de codificació, mentre que la tècnica de caixa blanca necessita coneixement intern de l’aplicació.

Ara, mentre realitzeu proves d’integració, podria incloure la prova dels dos serveis web integrats que recuperaran les dades de la base de dades i proporcionaran les dades segons sigui necessari, cosa que significa que es podrien provar mitjançant la tècnica de proves de caixa blanca, mentre que es pot provar la integració d’una nova característica al lloc web. mitjançant la tècnica de la caixa negra.

Per tant, no és específic que les proves d’integració siguin una tècnica de caixa negra o caixa blanca.

Eines de proves d’integració

Hi ha diverses eines disponibles per a aquesta prova.

A continuació es mostra una llista d’eines:

• Tester d’integració racional
• Transportador
• Vapor
• TESSY

Per obtenir més informació sobre les eines anteriors, consulteu aquest tutorial:

Top 10 d'eines de proves d'integració per escriure proves d'integració

Proves d’integració de sistemes

Es fa la prova d'integració del sistema per provar el fitxer sistema integrat complet .

Els mòduls o components es proven individualment en proves unitàries abans d’integrar els components.

Un cop provats tots els mòduls, es realitzen les proves d’integració del sistema integrant tots els mòduls i es prova el sistema en general.

Diferència entre proves d’integració i proves de sistemes

Les proves d’integració són proves en què s’integren un o dos mòduls provats per unitat per provar i es fa la verificació per verificar si els mòduls integrats funcionen tal com s’esperava o no.

La prova del sistema és una prova on el fitxer el sistema en general es prova, és a dir, tots els mòduls / components s’integren junts per verificar si el sistema funciona com s’esperava i no es produeixen problemes a causa dels mòduls integrats.

Conclusió

Es tracta de proves d’integració i la seva implementació tant en tècniques de caixa blanca com de caixa negra. Espero que ho expliquem clarament amb exemples rellevants.

La integració de proves és una part important del cicle de proves, ja que facilita la cerca del defecte quan s’integren dos o més mòduls per tal d’integrar tots els mòduls junts en el primer pas.

Ajuda a trobar els defectes en una etapa inicial, cosa que al seu torn permet estalviar esforços i costos. Assegura que els mòduls integrats funcionin correctament com s’esperava.

Espero que aquest tutorial informatiu sobre proves d’integració us hagi enriquit el coneixement del concepte.

Lectura recomanada

• Què és la prova de components o la prova de mòduls (apreneu amb exemples)
• Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
• Spock per a la integració i proves funcionals amb seleni
• Les diferències entre la prova unitària, la prova d’integració i la prova funcional
• Integració de seleni amb JMeter
• Prova de descàrrega de llibres electrònics
• Proves funcionals contra proves no funcionals
• Prova de parelles o Tutorial de proves de tots els parells amb eines i exemples