Meny

En enkel guide til interoperabilitetstesting (med eksempler)

simple guide interoperability testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Før du forstår teknikken til “Interoperabilitetstesting” , La oss først forstå begrepet 'interoperabilitet'.

Interoperabilitet er et systems evne til å samhandle med et annet system. Denne interaksjonen er mellom 2 forskjellige systemer eller 2 forskjellige applikasjoner alt sammen.

Mange ganger er interoperabilitet forvekslet med Integrering , kompatibilitet og bærbarhet. Vel, det er forskjeller mellom disse teknikkene.

Hva er interoperabilitetstesting

La meg først begynne med å forklare forskjellene.

Integrering - Er en teknikk når komponentene i det samme systemet samhandler med hverandre. Så i testverdenen, når vi gjør integrasjonstesting, tester vi faktisk oppførselen til de to eller flere, laveste nivåene av komponenter i samme system.

Kompatibilitet - Er en teknikk der to eller flere applikasjoner samhandler i samme miljø. Så i testverdenen, når vi gjør kompatibilitetstesting; vi validerer om 2 eller flere applikasjoner eller systemer oppfører seg som forventet i samme miljø.

Hensikten her er å kontrollere at de to systemene utfører sine forventede oppgaver, uten å forstyrre hverandre i samme miljø. Som - MS Word og Calculator er to forskjellige applikasjoner, og de utfører sin forventede oppførsel uavhengig i samme operativsystem. Så vi sier at disse to applikasjonene er kompatible med hverandre.

Bærbarhet - Er en teknikk når et program eller et system oppfører seg som forventet når det flyttes til et annet miljø. Så inn Bærbarhet testing, eksporterer vi applikasjonen til et annet miljø og tester oppførselen. Som om det er et program som fungerer bra i Windows XP, bør det også fungere bra i Windows 10.

Interoperabilitet - Er en teknikk hvordan en applikasjon samhandler med en annen applikasjon. Så når vi utfører interoperabilitetstesting, sjekker vi hvordan dataene fra en applikasjon overføres til en annen applikasjon uten forutgående antydning, på en meningsfull måte, og videre behandles for å gi den aksepterte utdata.

hva er den beste programvaren for fjerning av spyware

Denne artikkelen fokuserer på interoperabilitetstesting (IOT), så la oss fortsette å fokusere på interoperabilitet. :)

Hva du vil lære:

Interoperabilitetstesting - En kort introduksjon

Interoperabilitet = Inter + operabel

Inter - betyr 'mellom oss selv', 'i hverandre', 'gjensidig'

Brukbar - betyr 'i stand til å utføre den gitte oppgaven'

Så å kombinere de to begrepene sammen - Interoperabilitet betyr 2 (eller flere) systemer, som er i stand til å utføre sin tildelte oppgave uavhengig og i stand til å kommunisere med hverandre som forventet uten å påvirke deres individuelle tildelte funksjonalitet.

Eksempel 1:Ta et eksempel på å reservere flyreisen din. Vurder at du trenger å reise fra New Delhi til New York. Nå har du ikke direktefly. Du må reise fra New Delhi til London og deretter ta en flyrute fra London til New York. Fordi du har tidsbegrensninger, reserverer du flyet ditt fra New Delhi til London i 'Jet Airways' luftveier og fra London til New York i 'Virgin Atlantic'. Så det betyr at alle passasjeropplysningene dine ble krysset fra Jet Airways til Virgin Atlantic. Så her, Jet Airways og Virgin Atlantic, begge er uavhengige applikasjoner sammen, og mens du reserverer flyreisen din, ble reservasjonsinformasjonen din byttet ut fra Jet Airways til Virgin Atlantic på en fullstendig måte uten forhåndsintimasjon.

Eksempel 2:I lignende linjer, tenk på sykehusadministrasjonssystemet, der pasientjournalene utveksles mellom 1 avdeling til annen avdeling. Så her kan avdeling knyttes til en søknad. Detaljer om pasienten blir utvekslet mellom en applikasjon til en annen applikasjon uten forvarsel.

Så hvorfor trenger vi å gjøre IOT?

Vi må utføre interoperabilitetstesting for å sikre det

  • Applikasjonene i nettverket utfører sin forventede oppførsel uavhengig,
  • Kan utveksle informasjon uten forvarsel
  • Informasjonen / dataene utveksles uten å forstyrre den individuelle forventede atferden
  • Dataene / informasjonen som utveksles blir ikke endret eller endret

Hvordan gjør jeg interoperabilitetstesting?

Vi kan følge Deeming-hjulet (PDCA-syklusen) for å utføre interoperabilitetstesting.

# 1) Planlegg

Planlegging er den viktigste fasen for å bestemme strategien for å gjøre nesten hva som helst i programvareutviklingen. Før vi faktisk planlegger å bestemme prosedyren for å gjøre IOT, er det viktig at vi forstår hver applikasjon eller system distribuert i nettverket.

Vi bør vite for alle applikasjonene - dens funksjonalitet, oppførsel, input det tar og output det avslører.

Jeg vil også anbefale at hver applikasjon er fullstendig funksjonstestet uten feil før den forberedes for interoperabilitetstesting. Så når du planlegger, ikke bare tenk på 1 eller 2 applikasjoner, tenk på hele applikasjonen som en enkelt enhet. Du må ha et fugleperspektiv når du planlegger for denne testteknikken. Unødvendig å si det - dokumenter planen din.

Vi kan bruke vår standard testplan dokument og skreddersy det litt i henhold til kravet om å dokumentere planleggingen av IOT. Etter at testplanen din er på plass, kan du gå videre for å utlede testforholdene dine.

Fokuset for å utlede testtilstanden din bør ikke være begrenset til de enkelte applikasjonene; i stedet bør det være basert på datastrømmen gjennom alle applikasjonene. Forholdene bør utformes på en slik måte at, hvis ikke alle, men de fleste applikasjonene i nettverket krysses.

Når testforholdene er identifisert, kan du gå videre til design eller skript (i tilfelle du planlegger å automatisere) testsakene dine. Du kan lage en RTM (Krav sporbarhetsmatrise) for å kartlegge testsakene dine med testbetingelser og testbetingelsene dine med vilkår / krav for godkjenningstest.

Når du jobber på et nettverk, er det igjen viktig å planlegge for ikke-funksjonelle testaktiviteter. Dette kan ikke være skrevet eller dokumentert hvor som helst, men det er obligatorisk å sjekke for ikke-funksjonelle aspekter av systemet som helhet. Disse ikke-funksjonelle områdene vil omfatte ytelse og sikkerhet. Om nødvendig kan du lage en egen plan for funksjonstesting, ytelsestesting og sikkerhetstesting; eller lage en enkelt plan og et annet dokument med testbetingelser for hver av disse testtypene.

# 2) Gjør

Gjør - er tidsperioden der du faktisk utfører. Planlegg tiden din deretter for å utføre funksjonell og ikke-funksjonell testing. Vi følger testsyklusen i denne fasen av å utføre sakene, logge feilene, følge opp med utviklingsteamet for å få de løst, gjøre omprøven og regresjonstesten av systemet som helhet, rapportere testresultatene og flytte det til nedleggelse.

# 3) Sjekk

Sjekk - er fasen hvor vi går tilbake til testresultatene våre og prøver å kartlegge de med RTM-ene og validere om alle forventede krav er oppfylt, og om alle applikasjonene er krysset. Vi sjekker at dataene blir krysset og utvekslet riktig og greit mellom applikasjonene / systemene. Vi må også validere at dataene som blir krysset ikke blir endret.

Vurder også å gjøre et tilbakeblikk på hele prosessen med interoperabilitetstesting. Identifiser områdene som fungerte bra, de som ikke gikk bra, og eventuelle handlinger som må tas hånd om.

# 4) Handle

Handle - Er å handle på retrospektive gjenstander. Punktene som ble identifisert som “god praksis”, fortsetter å utføre de og punktene som kan fungere bedre, identifiserer trinnene for å rette opp disse og handle deretter. Husk én ting at områdene eller trinnene som ikke fungerte bra, IKKE skal gjentas. Vi skal tross alt lære av våre feil og ikke gjenta dem.

De 5 ½ trinnene:

  1. Identifiser alle applikasjonene som er en del av nettverket.
  2. Identifiser deres respektive funksjoner.
  3. For hvert program, identifiser inngangen den tar og utgangen den returnerer.
  4. Identifiser dataene som vil krysse gjennom alle / de fleste applikasjoner.
  5. Identifiser forventet atferd for hver kombinasjon av applikasjon og dato som må valideres

½ Dokumenter det.

Tenk på figuren nedenfor:

5 ½ trinn

Basert på figuren, la oss prøve å replikere de 5 ½ trinnene:

  1. Applikasjon 1, applikasjon 2, applikasjon 3 og applikasjon 4 er 4 forskjellige systemer.
  2. Hvert av disse systemene har det bestemte settet med funksjonalitet som må identifiseres.
  3. Inngang og utgang fra hvert system må identifiseres.
  4. I tilfelle Application1 gir den to utganger. 1 utgang danner inngangen til applikasjon 3 og 1 utgang skjemaer inngang av applikasjon 2. Utgangen fra applikasjon 2 danner inngangen til applikasjon 3 og applikasjon 4 og så videre.
  5. Gyldigheten for hver av inngangene og utgangene blir sjekket. Det viktigste poenget å vurdere her er at dataene som krysses i form av inngang og utgang ikke blir modifisert OG hele applikasjonen er dekket.

½ Denne figuren i det virkelige liv ser kanskje ikke ut til å være så enkel. Dette resulterer faktisk i mer kompleks struktur med n antall inngangs- og utgangsbetingelser.

Å tegne denne typen figur ville gi et bedre bilde for å identifisere dataene og informasjonen som vil krysse gjennom forskjellige systemer. Dette vil hjelpe oss å utlede testbetingelser og tilfeller.

Et eksempel:

La oss vurdere et eksempel på å utføre interoperabilitetstesting for et 'sykehusstyringssystem'

Et sykehus består av underavdelingene og underavdelingene;

Sykehusledelsessystem

Her er hver avdeling en applikasjon i seg selv. Hver avdeling (søknad) har sin egen underavdeling (moduler) og hver modul har sine egne enheter.

Så nå for å vurdere omfanget av IOT, er det noen få testbetingelser:

  1. En pasient som møtte en trafikkulykke (OPD-avdelingen - ulykke), må gjennomgå en benoperasjon (ENT - generell kirurgi), og må deretter gjennomgå fysioterapi (supportavdeling - fysioterapi) og får deretter utskrivning (supportavdeling - nedleggelse)
  2. Et barn innlagt i kritisk behandling (Pediatrics - Critical Care) må gjennomgå en operasjon (Pediatrics / ENT - General Surgery) og blir deretter utskrevet (Support Department - Closure / PR)
  3. En utenforstående pasient konsulterer en allmennlege (OPD-avdeling); tar de foreskrevne medisinene (Support Department - Pharmacy) og går bort.
  4. En forventende mor kommer til regelmessige kontroller (Gynekologisk avdeling - Mor og barnepass), tar den foreskrevne medisinen (Støtteavdelingen - Apotek) og går bort.
  5. En tannpasient gjør rotkanalen (Dentistry department), tar den foreskrevne medisinen (Support department - Pharmacy) og går bort.
  6. En pasient kommer i OPD (allmennlege), gjennomgår en behandling i (Obstetrics & Gynecology department - High Risk Obstetrics) tar den foreskrevne medisinen (Support avdeling - Apotek) og blir utskrevet

På denne måten identifiserer vi alle testforholdene; med tanke på at det meste av avdelingen må dekkes.

Vi kan tegne en RTM for å vise dekningen som:

RTM

På denne måten kan vi identifisere flere testforhold og kan tegne RTM for å se vårt eksakte omfang. Vi kan også bestemme dybden av testinnsatsen vår basert på RTM.

Som i dette eksemplet ser vi at 'Support Department' er applikasjonen som er utgangspunktet for alle (de fleste) applikasjonene, og derfor er testinnsatsen for denne applikasjonen litt mer sammenlignet med andre applikasjoner.

Utfordringer:

  1. Vanskelig å teste hele applikasjonen med alle permutasjoner og kombinasjoner.
  2. Applikasjoner er utviklet i forskjellige maskinvare / programvarekombinasjoner og installeres i forskjellige miljøer, så hvis noe av miljøet er nede, påvirker det testingen.
  3. På grunn av den forskjellige programvaren og miljøene, er det i seg selv en stor oppgave å bestemme teststrategien og utføre den.
  4. Å stimulere miljøet for å gjennomføre testen, er en stor utfordring.
  5. I tilfelle feil, er det en stor utfordring å gjøre Root Cause Analysis.
  6. Fordi programmene er i et nettverk, vil det være tider når nettverket er nede. På grunn av dette blir også testing påvirket.

Hvordan kan jeg dempe disse utfordringene?

1) Prøv å bruke forhåndstestingsteknikker som:

  • OATS (Ortogonal Array testing teknikk)
  • Statlige overgangsdiagrammer,
  • Årsak og virkning grafer
  • Equivalence portioning og Boundary value analysis.

Disse teknikkene vil hjelpe deg med å identifisere gjensidig avhengighet mellom applikasjonen og identifisere testsaker / forhold som vil sikre maksimal dekning.

to) Prøv å identifisere noen historiske data som - under hvilke omstendigheter systemene var nede, hvor lang tid tar det å være tilbake i aksjon. I så fall kan du prøve å utføre de scenariene hvis applikasjoner ikke påvirkes, eller bruke tiden til å dokumentere scenariene og rapportere resultatene. Videre, når du planlegger eller planlegger testingen, må du alltid vurdere disse historiske dataene som et input for din estimering og planlegge deretter.

3) PLAN - Bruk historiske data, tidligere erfaringer, teamets dyktighet, miljøfaktorer for å identifisere testingsstrategien. Jo bedre planen din er, desto bedre vil gjennomføringen din være.

4) Begynn å jobbe med å forberede miljøet mye før enn den faktiske kjøringen din starter. Unødvendig å si - planlegg trinnene dine når du forbereder miljøet. Sørg for at miljøet ditt er klart, klart og klart når kjøringen starter.

5) Før du starter med IOT, må du sørge for at de enkelte applikasjonene er fullstendig funksjonstestet uten feil. I tilfelle feil, trenger du bare å lete etter miljøfaktorene som har ført til feil.

6) Som diskutert i punkt 2, planlegg aktiviteten din. Hvis det er en planlagt avbrudd, bør du vurdere denne nedetiden når du planlegger testen.

sql utvikler intervju spørsmål for 4 års erfaring

Interoperabilitetstest på mobiler:

I Mobiles gjør vi interoperabilitetstest når en ny app ( Mobil applikasjon ) lanseres. Det er mange områder vi må vurdere når vi planlegger for denne testen på mobile enheter:

  • Typer mobile enheter tilgjengelig på markedet er enorme. Du må liste opp alle typer enheter du vil vurdere for testing. Du må koble en enhetstype sammen med operativsystemet den støtter.
  • Alt Mobile OS er utviklet på forskjellige programmeringsspråk. Derfor må appen testes mot alle variantene av OS.
  • Forstå de juridiske faktorene og regionrelaterte kontrakter.
  • Størrelse / oppløsning på forskjellige enheter er forskjellige.
  • Påvirkning på de mobile innebygde appene må også vurderes.

Så for å gjøre IOT på mobiltelefoner, vil du trenge å planlegge og lage en RTM akkurat som vi gjorde for en databasert applikasjonstesting.

Intensjonen, strategien, risikoen og utførelsen ville være den samme, men den verktøy og teknikker ville være annerledes i tilfelle mobiltelefoner.

Konklusjon:

Interoperabilitetstesting er en stor oppgave. Denne teknikken krever riktig planlegging som skal starte parallelt når planleggingen av systemtesten starter.

Det er mange faktorer som må vurderes når du utfører denne teknikken. Husk å ha tilstrekkelig tid til feilretting og omprøving, da dette er en enorm innsats, bør det være mulig å følge opp feil.

Dette kan skje at du kanskje ikke oppnår 100% dekning , men vi bør være smarte nok til å velge sakene våre på en slik måte at de fleste applikasjonene dekkes i en enkelt strøm ved å bruke gode testsaksteknikker.

Håper denne artikkelen var nyttig for å forstå teknikk for interoperabilitetstesting. Gi oss beskjed om dine spørsmål / kommentarer.

Anbefalt lesing

^