Hva er integrasjonstesting
Med fremskritt innen informasjonsteknologi blir tingene mye lettere for oss, mennesker, og bokstavelig talt kan alt gjøres på et øyeblikk. Men før dette kan alt gjøres mye hardt arbeid, og det viktigste av alt "LOGIKK" legges bak det. Noen ganger har vi sett at noen funksjoner ikke akkurat fungerer i henhold til forventningene eller resultatene som er hentet ut av programvaren, ikke samsvarer med forventningene våre, det er der programvaretesting spiller en viktig rolle. For å rette opp feilene i systemene, for å oppnå de riktige / forventede resultatene, er programvaretesting.
For å forstå hva integrasjonstesting betyr, må vi først forstå hva programvaretesting betyr! Testing av programvare er en aktivitet for å sjekke om resultatet / resultatet av en test tilsvarer det forventede resultatet / resultatet, noe som betyr at programvaren kjører korrekt. Resultatet som oppnås etter at bestemt programvare / system er kjørt, må samsvare med resultatet som forventes som output fra programvaren / systemet; hvis den ikke klarer det, må programvaren skrives på nytt, eller det må gjøres visse endringer i kodekoden.
Programvaretesting av et programvaresystem gjøres på forskjellige nivåer. Testnivåene er avbildet som følger:
Kronologisk utføres integrasjonstesting etter det første trinnet, "Unit Testing". Når navnet integrering går, er den tekstlige definisjonen av Integration Testing "Individuelle programvaremoduler kombineres og testes sammen, som en gruppe". Det betyr at i programvare er det mange komponenter. Disse mange komponentene sammen, danner et programvaresystem. Dette programvaresystemet er testet sammen, og testnivået som det testes er kjent som integrasjonstesting. Så når disse modulene er kombinert, må resultatet som er oppnådd av det tilsvarer resultatet som forventes, det er der integrasjonstesting inngår i en del. Hovedformålet med integrasjonstesting er å sjekke om enkeltmoduler fungerer riktig når de kombineres.
Også kjent som I & T (Integrering og testing) kan hjelpe til med testing av en individuell så vel som full modultesting. Det er inkludert i både Black Box og White Box Testing. De fleste av organisasjonene tester kun programvarene sine ved å bruke enhetstesting og funksjonelle testmetoder.
Typer og tilnærminger
Det er fire typer og tilnærminger til integrasjonstesting, nevnt nedenfor:
- Big bang-tilnærming
- Bottom-Up tilnærming
- Topp-ned tilnærming
- Hybrid / Sandwich
1. Big Bang-tilnærming:
De utviklede modulene / komponentene i programvaresystemene er koblet sammen. Disse individuelle modulene testes sammen når de er koblet. Etter enhetstesting blir disse modulene testet sammen som danner et programvaresystem. Men noen av oss kan ha dette spørsmålet som, hvordan er programvaresystemtesting som helhet og integrasjonstesting annerledes? Det viktigste vi forstår her er at i integrasjonstesting utføres testingen for de enkelte modulene sammen, etter at enhetstester er utført; og i programvaresystemtesting testes hele systemet med alle parametere tatt i betraktning.
Følgende diagram viser nøyaktig hva Big Bang-tilnærmingen til integrasjonstesting betyr:
Med Big Bang Approach er det noen fordeler og ulemper forbundet:
Fordeler:
- Det er veldig praktisk å nærme seg hvis systemene er små. Ettersom tiden det tar for denne tilnærmingen er mer, kan store systemer føre til mer tidsforbruk.
- Feilsøking er veldig enkelt med dette, med tanke på små systemer
ulemper:
- Siden alle moduler er koblet, hvis det oppstår en feil i systemene, er det vanskelig å få øye på den.
- Noen moduler er veldig viktige og de må testes. Disse modulene må testes før de brukes i systemet. Men under integrasjonstesting kan det hende at disse modulene ikke testes effektivt, siden alle modulene er koblet sammen.
- Tiden som hele programvaresystemet tar er mye mer enn andre tilnærminger til testing av integrasjon.
- Det kan ta litt tid å koble modulene, noe som kan føre til at den totale prosesstiden for programvaresystemet tar opp.
- Det tar mer tid for denne tilnærmingen, ettersom mange moduler er koblet sammen og det vil ta mer tid å teste hver modul.
2. Bunn-opp tilnærming
I denne tilnærmingen testes modulene på lavt nivå først, sammen og individuelt. Alle bunnnivåmodulene er integrert som inkluderer, funksjoner og prosedyrer, og alt er koblet og testet. Dette hjelper med å teste modulene på høyere nivå, da det danner en base for det. Denne prosedyren gjentas for at alle modulene fra bunnnivå til toppnivåmodul blir testet grundig. Enkelt sagt begynner testingen fra de indre og de aller nederste modulene og går gradvis oppover. Som det fremgår av diagrammet, blir hjelpen fra en sjåfør hentet mens du gjør det. Så hva er en driver, og hvordan hjelper det? Som flyten antyder, kan ikke toppnivåmodulene integreres i systemet før og med mindre testing av bunnnivåmodul er utført og koblet. Så driveren her hjelper til med å koble bunnnivåene og toppnivåmodulene og fungerer som et medium eller i et teknisk begrep som en samtalefunksjon.
Fordeler:
- Utvikling av individuelle moduler kan gjøres mens integreringstesting bottom-up-tilnærmingen blir brukt, da koblings- og integrasjonstesting blir gjort etter at bunnnivåmodulene først er testet.
- Hvis det oppstår / oppstår en eller annen feil, kan den løses på samme tid og på samme nivå. Feilidentifiseringen og korreksjonen er mye enklere enn andre tilnærminger.
- Tiden som kreves for feilidentifikasjon og feilretting er mye mindre sammenlignet med andre tilnærminger.
- Feil kan løses i samme forekomst bunnenivå eller på øverste nivå.
ulemper:
- Det tar mer tid for hele prosessen, testingen avsluttes ikke før alle modulene til begge, topp- og bunnnivået er inkludert og testet.
- Drivere er nødvendige for å ringe modulen på høyt nivå
- Hvis programvaresystemet inneholder flere og flere små, men komplekse moduler, kan det ta mer tid å fullføre programvaretesting.
3. Opp-ned-tilnærming
Denne tilnærmingen er akkurat det motsatte av bottom-up-tilnærmingen. Toppnivåmodulene testes i utgangspunktet, og deretter testes andre lavere nivåmoduler. De øverste modulene blir først testet individuelt, slik at spesialiserte enhetstesting kjøres for den øverste modulen og etter hvert blir andre moduler tatt i betraktning og testet. Den ovenfra og ned tilnærmingen krever en samtale funksjon akkurat som en bottom-up tilnærming kalt Stubs. Stubbene er kortkodelogiske setninger som brukes til å akseptere innganger fra toppnivåmodulene og til slutt kaller moduler for bunnnivå for integrasjon og testing.
Fordeler:
- Enkelt feil eller feil kan oppdages i denne tilnærmingen.
- Avgjørende moduler testes grundig og før andre moduler.
- Testing av programvaresystemintegrering kan gjøres på kortere tid som sammenlignet med andre tilnærminger.
ulemper:
- Moduler på bunnnivå er kanskje ikke testet til det forventede nivået, eller kanskje ikke testet til kravene.
- Stubber er nødvendig og er nødvendige for at testprosessen kan komme videre.
4. Hybrid / Sandwich-tilnærming
Også kjent som Mixed Integration Testing. Bottom-Up Approach og Top-Down Approach begge er kombinert i denne tilnærmingen. Derfor kjent som hybrid eller Sandwich eller Mixed Integration testing tilnærming. Denne tilnærmingen blir brukt til å dekke opp fall outs for begge de henvendte individuelt. Den øverste modulen er enhetstestet og samtidig integreres og testes bunnnivåmodulene med toppnivåmodulene.
Fordeler:
- Brukes mest til store prosjekter og som krever mye tid for gjennomføring.
ulemper:
- Kostnadene for denne typen testing er ganske høye fordi begge tilnærmingene brukes i fullføringen av testingen.
Fordeler med integrasjonstesting
- Integrasjonstesting for forskjellige moduler samtidig er enkelt.
- Kan brukes i både tidlige og senere faser av testprosessen.
- Kodelengdedekning er mer sammenlignet med andre programvaretestingsteknikker, da begge deler kan benyttes.
- I henhold til endringene i kravene, varierer utviklingen, så testing av moduler på forskjellige nivåer blir viktig, som integrasjonstesting enkelt kan brukes til.
Hvorfor integrasjonstesting brukes
- Folk som har vært i IT-bransjen, vil kanskje vite om de stadige endringene som skjer. Hver dag, i samsvar med kravene, endres behovet for å utvikle et visst programvaresystem, så hver dag blir nye kodelapper utviklet. Nå når disse oppdateringene er koblet sammen for å danne en programvare. Så for å sjekke dette er integrasjonstesting og fremgangsmåter et must.
- Når en kompleks eller enorm programvare blir kodet eller bygget, blir den klassifisert i separate moduler. Mange mennesker jobber med disse modulene samtidig, men når disse modulene er integrert, utføres testing. I de fleste tilfeller krever integrasjon av moduler integrasjonstesting for å bli utført på den, før den behandles videre.
- De fleste av programvarene krever at noen støtter biblioteker for å fungere. Integrasjonstesting utføres når disse bibliotekene brukes sammen med koden som er utviklet.
- Integrasjon blir et must når programvaren utvikles, da feilene kan rettes på det fastsatte nivået. Som vi vet om tilnærmingene, kan en av tilnærmingene brukes til det.
Tilfeller av integrasjonstesting
Tenk på at vi bygger en ansattes styringsprogramvare. Denne programvaren har tre hovedaspekter:
- Ansattes pålogging
- Ansattes rapport
- Ansattes lønnsbetegnelsesside og lønnsnivå
Nå, med tanke på ovennevnte tilfelle, er programvaren først utviklet og flyten skal være Registrering av ansatte (Angi verdiene, eks: ansattes ID, navn, telefonnummer osv.). Etter de riktige innspillene, bør den omdirigere til netttsiden til den ansattes rapportside. Hvis den ansatte her ikke blir ledet til rapportsiden og direkte til lønnsinformasjonssiden, og da er det en feil. Så for å rette opp i dette, blir flyt, rekkefølgen av aktiviteter, integrasjonstesting gjort.
Et annet eksempel på integrasjonstesting vil være:
Vi sjekker daglig e-postene våre. Alle e-posttjenesteleverandører gir oss den samme funksjonaliteten.
Login-> Inbox->Send / Delete Mail-> Logout
Nå, her når vi logger på serverne deres, kontrolleres først verdiene for korrektheten, det vil si enhetstesting. Så nå, når legitimasjonsopplysningene samsvarer, skal innloggingssiden overføre oss til innbokssiden. Det er det forventede resultatet. Hvis den ikke overfører oss til Innboks-siden i stedet overfører oss til en eller annen søppelmappe, blir det et tilfelle av integrasjonstestingstilfelle. Det samme gjelder sending og sletting av e-postene.
Andre tilfeller kan være:
- Etter vellykket registrering på en hvilken som helst online / offline applikasjon, skal en visningsmelding vises foran brukeren.
- Banksøknader bør henvise brukere til kontosammendragssiden som kreves.
- Etter vellykket innlogging i apper på sosiale medier, skal standardsiden for eks: Hjem / Profil for Facebook vises.
Konklusjon
Med så mange fremskritt innen IT, dag for dag, og så mange utviklere som sitter på forskjellige steder og jobber med den samme programvaren, har integrasjonstesting blitt et must. Med sine tilnærminger kan integrasjonstesting brukes både med små og store programvare. Integrasjonstesting, å være i midten av programvaretestingnivåene og ha så mange fordeler, blir mer og mer viktig for kommersielle klienter og regelmessig kontroll hjelper med å holde programvaren intakt.
Anbefalte artikler
Dette har vært en guide til integrasjonstesting. Her diskuterte vi noen grunnleggende begreper, definisjon, typer og tilnærming med fordeler og ulemper. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -
- Karrierer innen programvaretesting
- Karrierer for programvareutviklere
- Hva er Black Box Testing
- Nyttige karrierer som programvareingeniør