Hvad er integrationstest

Med de fremskridt, der sker inden for informationsteknologi, bliver tingene meget lettere for os, mennesker, og bogstaveligt talt kan alt gøres på et øjeblik af vores fingre. Men inden dette kan alt gøres meget hårdt arbejde, og vigtigst af alt lægges “LOGIC” bag det. Nogle gange har vi set, at nogle funktioner ikke nøjagtigt fungerer i henhold til forventningerne, eller at resultaterne afledt af softwaren ikke svarer til vores forventninger, det er her softwaretestingen spiller en vigtig rolle. For at rette fejlene i systemerne er softwaretest for at opnå de korrekte / forventede resultater.

For at forstå, hvad integrationstesting betyder, skal vi først forstå, hvad softwaretest betyder! Softwaretest er en aktivitet for at kontrollere, om output / resultat af en test svarer til det forventede output / resultat, hvilket betyder, at softwaren kører korrekt. Det resultat, der opnås, efter at visse software / system er kørt, skal matche det resultat, der forventes som output fra softwaren / systemet; hvis det ikke lykkes, skal softwaren omskrives, eller der skal udføres visse ændringer inden for kode, der er skrevet.

Softwaretest af et softwaresystem udføres på forskellige niveauer. Testniveauer er afbildet som følger:

Kronologisk udføres integrationstest efter det første trin, "Enhedstestning". Når navnet integration integreres, er den tekstmæssige definition af Integration Testing "Individuelle softwaremoduler kombineres og testes sammen, som en gruppe". Det betyder, at i software er der mange komponenter. Disse mange komponenter sammen, når de kombineres, danner et softwaresystem. Dette softwaresystem testes sammen, og det testniveau, hvorpå det testes, kaldes integrationstest. Så når disse moduler kombineres, skal resultatet, der opnås ud af det, svare til det forventede resultat, det er her integrationstest kommer ind i en del. Hovedformålet med integrationstest er at kontrollere, om de enkelte moduler fungerer korrekt, når de kombineres.

Også kendt som I & T (Integration and Testing) kan hjælpe med til testning af et individ såvel som fuldt modultest. Det er inkluderet i både Black Box og White Box Testing. De fleste af organisationerne tester kun deres software ved hjælp af enhedsprøvning og funktionelle testmetoder.

Typer og tilgange

Der er fire typer og tilgange til integrationstest, nævnt nedenfor:

  1. Big Bang-tilgang
  2. Bund-op-tilgang
  3. Top-Down tilgang
  4. Hybrid / Sandwich

1. Big Bang-tilgang:

De udviklede moduler / komponenter i softwaresystemerne er koblet sammen. Disse individuelle moduler testes sammen, når de er koblet. Efter enhedstest testes disse moduler sammen, som danner et softwaresystem. Men nogle af os har måske dette spørgsmål om, hvordan er softwaresystemtestning som helhed og integrationstest forskellige? Den vigtigste ting, vi forstår her, er, at testen udføres i integrationstest for de enkelte moduler kombineres sammen, efter at enhedstest er udført; og ved softwaresystemtestning testes hele systemet med alle de parametre, der er taget i betragtning.

Følgende diagram viser nøjagtigt, hvad Big Bang-tilgang til integrationstest betyder:

Med Big Bang-tilgang er der nogle fordele og ulemper forbundet:

Fordele:

  • Det er meget praktisk at nærme sig, hvis systemerne er små. Efterhånden som den tid, det tager for denne tilgang, er mere, kan store systemer føre til mere tidsforbrug.
  • Fejlregistrering er meget let med dette i betragtning af små systemer

Ulemper:

  • Da alle moduler er koblet, hvis der opstår en fejl i systemerne, er det vanskeligt at få øje på det.
  • Nogle moduler er meget vigtige, og de skal testes. Disse moduler skal testes, før de bruges i systemet. Men under integrationstest testes disse moduler muligvis ikke effektivt, da alle moduler er koblet sammen.
  • Det tager hele softwaresystemet meget mere end andre metoder til integrationstest.
  • Koblingen af ​​modulerne kan tage noget tid, hvilket kan resultere i, at det tager tiden for den samlede procestid for softwaresystemet.
  • Det tager mere tid for denne tilgang, da mange moduler er koblet sammen, og at teste hvert modul vil tage mere tid.

2. Bund-op-tilgang

I denne tilgang testes modulerne på lavt niveau først, sammen og individuelt. Alle bundniveau-moduler er integreret, som inkluderer, funktioner og procedurer, og alt kobles og testes. Dette hjælper med at teste moduler på højere niveau, da det danner en base for det. Denne procedure gentages for at alle moduler fra bundniveau til topniveaumodul testes grundigt. Enkelt set begynder testning fra de indre og de nederste moduler og går gradvist op. Som det fremgår af diagrammet, tages en chaufførs hjælp, mens han gør det. Så hvad er en driver, og hvordan hjælper det? Som strømningen antyder, kan topniveaumodulerne ikke integreres i systemet, før og medmindre test af bundniveaumodul er udført og koblet. Så hjælper chaufføren her med at tilslutte bundniveau- og topniveaumoduler og fungerer som et medium eller i en teknisk betegnelse som en opkaldsfunktion.

Fordele:

  • Udvikling af individuelle moduler kan udføres, mens integrationstest-bottom-up-fremgangsmåden bruges, da koblings- og integrationstesten udføres, efter at bundniveaumodulerne først er testet.
  • Hvis der opstår / opstår en fejl, kan den rettes på samme tid og på samme niveau. Fejlidentifikation og korrektion er meget lettere end andre tilgange.
  • Tiden, der kræves til fejlidentifikation og fejlkorrektion er meget mindre sammenlignet med andre tilgange.
  • Fejl kan løses i samme instans bundniveau eller på øverste niveau.

Ulemper:

  • Tiden der tages for hele processen er mere, testprocessen afsluttes ikke, før alle moduler af begge, det øverste og det nederste niveau er inkluderet og testet.
  • Drivere er nødvendige for at kalde modulerne på højt niveau
  • Hvis softwaresystemet indeholder flere og flere små, men komplekse moduler, kan det tage længere tid at gennemføre softwaretestprocessen.

3. Top-Down-tilgang

Denne tilgang er nøjagtig det modsatte af bottom-up-metoden. Topmodulet / modulerne testes oprindeligt, og derefter testes andre moduler på lavere niveau. De øverste moduler testes først individuelt, ligesom specialiseret enhedstest køres til det øverste modul, og til sidst tages andre moduler i betragtning og testes. Top-down-metoden kræver en opkaldsfunktion ligesom en bottom-up-tilgang, der kaldes Stubs. Stubberne er kortkodelogiske udsagn, der bruges til at acceptere input fra det øverste niveau moduler og til sidst kalde bundniveau moduler til integration og test.

Fordele:

  • Det er nemt at opdage fejl eller fejl i denne fremgangsmåde.
  • Afgørende moduler testes grundigt og inden andre moduler.
  • Test af softwaresystemintegration kan udføres på kortere tid som i sammenligning med andre tilgange.

Ulemper:

  • Moduler på bundniveau testes muligvis ikke til det forventede niveau eller testes muligvis ikke efter kravene.
  • Stubbe er nødvendige og er nødvendige for, at testprocessen kan skride videre.

4. Hybrid / sandwich tilgang

Også kendt som Mixed Integration Testing. Begge bottom-up-tilgang og top-down-tilgang kombineres i denne tilgang. Derfor kendt som hybrid- eller sandwich- eller blandet integrationstestmetode. Denne fremgangsmåde bruges til at dække falder outs for begge de individuelt henvendte. Det øverste modul er enhedstestet, og på samme tid er bundniveaumoduler integreret og testet med topniveaumodulerne.

Fordele:

  • Bruges mest til store projekter, og som kræver masser af tid til færdiggørelse.

Ulemper:

  • Omkostningerne ved denne type test er ganske høje, da begge fremgangsmåder bruges til afslutningen af ​​testen.

Fordele ved integrationstest

  1. Integrationstest for forskellige moduler på samme tid er let.
  2. Kan bruges i både tidlige og senere faser af testprocessen.
  3. Dækning af kodelængde er mere sammenlignet med andre softwaretestteknikker, da begge kan benyttes ovenfra og ovenfra og ned.
  4. I henhold til ændringerne i kravene varierer udviklingen, så test af moduler på forskellige niveauer bliver vigtige, til hvilke integrationstest let kan bruges.

Hvorfor Integration Testing bruges

  • Folk, der har været i it-branchen, kan måske vide om de konstante ændringer, der sker. Hver dag, i henhold til kravene, ændres behovet for at udvikle et bestemt softwaresystem, så hver dag udvikles nye programrettelser. Nu, når disse programrettelser kobles sammen til en software. Så for at kontrollere dette er integrationstest og dets tilgange et must.
  • Når en kompleks eller enorm software kodes eller bygges, klassificeres den i separate moduler. Mange mennesker arbejder på disse moduler på samme tid, men når disse moduler er integreret, udføres testning. I det meste af tilfældet kræver integration af moduler integrationstest på det, inden det behandles videre.
  • De fleste af softwareprogrammerne kræver, at nogle biblioteker understøtter arbejde. Integrationstest udføres, når disse biblioteker bruges sammen med den udviklede kode.
  • Integration bliver et must, når softwaren udvikles, da fejlene kan afhjælpes på det fastsatte niveau. Som vi ved om tilgange, kan en af ​​fremgangsmåderne bruges til det.

Integration Testing Cases

Overvej at vi bygger en medarbejderadministrationssoftware. Denne software har tre hovedaspekter:

  1. Medarbejder login
  2. Medarbejderrapport
  3. Ansattes lønbetegnelsesside og løniveau

I betragtning af ovenstående sag skal softwaren først udvikles, og flowet skal være medarbejderregistrering (Indtastning af værdier, eks: medarbejder-id, navn, telefonnummer osv.). Efter de korrekte input skal det omdirigere til nettsiden til den medarbejderrapportside. Nu, hvis medarbejderen her ikke ledes til rapportsiden og direkte direkte til løninformationssiden, og så er det en fejl. Så for at rette op på dette er flowet, aktivitetssekvensen, integrationstesten udført.

Et andet eksempel på integrationstestning ville være:

Vi tjekker dagligt vores e-mails. Alle e-mail-tjenesteudbydere giver os den samme funktionalitet.

Login-> Inbox->Send / Delete Mail-> Logout

Nu, når vi logger på deres servere, kontrolleres først værdierne for rigtigheden, det vil sige enhedstest. Så nu, når legitimationsoplysningerne matcher, skal login-siden overføre os til indbakke-siden. Det er det forventede resultat. Hvis det ikke overfører os til Inbox-siden i stedet overfører os til en eller anden uønsket mappe, bliver det et tilfælde af integrationstesttilfælde. Det samme gælder for afsendelse og sletning af e-mails.

Andre tilfælde kan være:

  • Efter vellykket registrering på enhver online / offline applikation, skal der vises en displaymeddelelse foran brugeren.
  • Bankapplikationer skal lede brugerne til den kontosammendragsside, der er påkrævet.
  • Efter vellykket login på sociale medie-apps, skal standardsiden for eks: Hjem / Profil til Facebook vises.

Konklusion

Med så mange fremskridt inden for IT, dag for dag og så mange udviklere, der sidder forskellige steder og arbejder på den samme software, er integrationstest blevet et must. Med dens fremgangsmåder kan integrationstest bruges sammen med små og store softwareapplikationer. Integrationstestning, der er i midten af ​​softwaretestniveauerne og har så mange fordele, bliver mere og mere vigtig for klienter på kommercielt niveau, og regelmæssig kontrol hjælper med at holde softwaren intakt.

Anbefalede artikler

Dette har været en guide til integrationstest. Her diskuterede vi nogle grundlæggende begreber, definition, typer og tilgang med der fordele og ulemper. Du kan også gennemgå vores andre foreslåede artikler for at lære mere -

  1. Karrierer inden for softwaretestning
  2. Karrierer for softwareudviklere
  3. Hvad er Black Box Testing
  4. Nyttige karrierer som softwareingeniør

Kategori: