simple guide interoperability testing
Før du forstår teknikken til “Interoperabilitetstest” , Lad os først forstå udtrykket 'interoperabilitet'.
Interoperabilitet er et systems evne til at interagere med et andet system. Denne interaktion er mellem 2 forskellige systemer eller 2 forskellige applikationer sammen.
softwaretest genoptages i 1 års erfaring
Mange gange er interoperabilitet forvekslet med Integration , kompatibilitet og bærbarhed. Der er forskelle mellem disse teknikker.
Lad mig først starte med at forklare forskellene.
Integration - Er en teknik, når komponenterne i det samme system interagerer med hinanden. Så i testverdenen, når vi udfører integrationstest, tester vi faktisk adfærden for de to eller flere, laveste niveauer af komponenter i det samme system.
Kompatibilitet - Er en teknik, hvorved 2 eller flere applikationer interagerer i det samme miljø. Så i testverdenen, når vi udfører kompatibilitetstest; vi validerer, om 2 eller flere applikationer eller systemer opfører sig som forventet i det samme miljø.
Hensigten her er at kontrollere, at de to systemer udfører deres forventede opgaver uden at forstyrre hinanden i det samme miljø. Ligesom - MS Word og Calculator er 2 forskellige applikationer, og de udfører deres forventede adfærd uafhængigt af det samme operativsystem. Så vi siger, at disse 2 applikationer er kompatible med hinanden.
Bærbarhed - Er en teknik, når et program eller et system opfører sig som forventet, når det flyttes til et andet miljø. Så i Bærbarhed test eksporterer vi applikationen til et andet miljø og tester dens adfærd. Som hvis der er et program, der fungerer godt i Windows XP, skal det også fungere godt i Windows 10.
Interoperabilitet - Er en teknik, hvordan en applikation interagerer med en anden applikation. Så når vi udfører interoperabilitetstesten, kontrollerer vi, hvordan dataene fra en applikation overføres til en anden applikation uden forudgående intimation på en meningsfuld måde og behandles yderligere for at give den accepterede output.
Dette særlige papir fokuserer på interoperabilitetstest (IOT), så lad os holde vores fokus på interoperabilitet. :)
Hvad du lærer:
- Interoperabilitetstest - En kort introduktion
- Hvordan udføres interoperabilitetstest?
- De 5 ½ trin:
- Udfordringer:
- Interoperabilitetstest på mobiltelefoner:
- Konklusion:
- Anbefalet læsning
Interoperabilitetstest - En kort introduktion
Interoperabilitet = Inter + operativ
Inter - betyder 'indbyrdes', 'inden for hinanden', 'gensidig'
Betjenes - betyder 'i stand til at udføre den givne opgave'
Så at kombinere de to termer sammen - Interoperabilitet betyder 2 (eller flere) systemer, der er i stand til at udføre deres tildelte opgave uafhængigt og i stand til at kommunikere med hinanden som forventet uden at påvirke deres individuelt tildelte funktionalitet.
Eksempel 1:Tag et eksempel på at reservere din flyrejse. Overvej, at du har brug for at rejse fra New Delhi til New York. Nu har du ikke en direkte flyvning. Du skal rejse fra New Delhi til London og derefter tage tilslutningsflyvning fra London til New York. Fordi du har nogle tidsbegrænsninger, reserverer du din flyrejse fra New Delhi til London i 'Jet Airways' luftveje og fra London til New York i 'Virgin Atlantic'. Så det betyder, at alle dine passageroplysninger blev krydset fra Jet Airways til Virgin Atlantic. Så her, Jet Airways og Virgin Atlantic, begge er uafhængige applikationer alle sammen, og mens du reserverer din flyvning, blev dine oplysninger om reservationen udvekslet fra Jet Airways til Virgin Atlantic på en meningsfuld måde uden forudgående antydning.
Eksempel 2:I lignende linjer, tænk på hospitalets administrationssystem, hvor patientjournaler udveksles mellem 1 afdeling til anden afdeling. Så her kan afdeling linkes til en ansøgning. Detaljer om patienten udveksles mellem 1 ansøgning til en anden applikation uden forudgående varsel.
Så hvorfor skal vi gøre IOT?
Vi bliver nødt til at udføre interoperabilitetstesten for at sikre det
- Applikationerne i netværket udfører deres forventede adfærd uafhængigt,
- Kan udveksle oplysninger uden forudgående varsel
- Oplysningerne / dataene udveksles uden at afbryde den individuelle forventede adfærd
- De data / oplysninger, der udveksles, bliver ikke ændret eller ændret
Hvordan udføres interoperabilitetstest?
Vi kan følge Deeming-hjulet (PDCA-cyklussen) for at udføre interoperabilitetstesten.
# 1) Planlæg
Planlægning er den vigtigste fase i at bestemme strategien for at gøre næsten alt i softwareudviklingen. Før vi faktisk planlægger at bestemme proceduren for at udføre IOT, er det vigtigt, at vi forstår hver eneste applikation eller system, der er implementeret i netværket.
Vi skal vide for alle applikationer - dens funktionalitet, adfærd, input, det tager og output, det afslører.
Jeg vil også anbefale, at hver eneste applikation er fuldt funktionelt testet uden fejl, inden den forberedes til interoperabilitetstest. Så når du planlægger, skal du ikke bare tænke på 1 eller 2 applikationer, tænk på hele applikationen som en enkelt enhed. Du skal have et fugleperspektiv, når du planlægger denne testteknik. Det er overflødigt at sige det - dokumenter din plan.
Vi kan bruge vores standard testplan dokument og skræddersy det lidt efter kravet om at dokumentere planlægningen af IOT. Når din testplan er på plads, skal du gå videre for at udlede dine testbetingelser.
Fokus for at udlede din testtilstand bør ikke være begrænset til de enkelte applikationer; i stedet skal det være baseret på datastrømmen gennem alle applikationerne. Betingelserne skal designes på en sådan måde, at hvis ikke alle, men de fleste applikationer i netværket krydses.
Når dine testbetingelser er identificeret, skal du gå videre til design eller script (hvis du planlægger at automatisere) dine testsager. Du kan oprette en RTM (Krav sporbarhedsmatrix) til at kortlægge dine testcases med testbetingelser og dine testbetingelser med accept / testbetingelser / krav.
Når du arbejder på et netværk, er det igen vigtigt at planlægge også de ikke-funktionelle testaktiviteter. Dette kan ikke være skrevet eller dokumenteret hvor som helst, men det er obligatorisk at kontrollere, om de ikke-funktionelle aspekter af systemet som helhed er. Disse ikke-funktionelle områder vil omfatte ydeevne og sikkerhed. Hvis det er nødvendigt, kan du oprette en separat plan for funktionstest, performance test og sikkerhedstest; eller opret en enkelt plan og et andet dokument med testbetingelser for hver af disse testtyper.
# 2) Gør
Gør - er det tidsrum, hvor du faktisk udfører din udførelse. Planlæg din tid i overensstemmelse hermed for at udføre den funktionelle og ikke-funktionelle test. Vi følger testcyklussen i denne fase med at udføre sagerne, logge fejlene, følge op med udviklingsteamet for at få dem løst, udføre gentesten og regressionstesten af systemet som helhed, rapporterer testresultaterne og flytter det til lukning.
# 3) Kontroller
Check - Er den fase, hvor vi besøger vores testresultater og prøver at kortlægge dem med RTM'erne og validere, om alle forventede krav er opfyldt, og om alle applikationer er gennemgået. Vi kontrollerer, at dataene krydses og udveksles korrekt og problemfrit mellem applikationerne / systemerne. Vi bliver også nødt til at validere, at de data, der gennemgås, ikke bliver ændret.
Overvej også at lave et retrospektiv af hele processen med interoperabilitetstest. Identificer de områder, der fungerede godt, de, der ikke gik godt, og hvilke handlinger der skal tages hånd om.
# 4) Handler
Handling - Er at handle med tilbagevirkende kraft. De punkter, der blev identificeret som 'god praksis', fortsætter med at udføre dem og de punkter, der kan arbejdes bedre, identificerer trinene til at rette dem og handler i overensstemmelse hermed. Husk en ting i tankerne, at de områder eller trin, der ikke fungerede godt, IKKE skal gentages. Når alt kommer til alt skal vi lære af vores fejl og ikke gentage dem.
De 5 ½ trin:
- Identificer alle de applikationer, der er en del af netværket.
- Identificer deres respektive funktioner.
- For hver applikation skal du identificere det input, det tager, og det output, det returnerer.
- Identificer de data, der kører gennem alle / de fleste applikationer.
- Identificer den forventede adfærd for hver kombination af applikation og dato, der skal valideres
½ Dokumenter det.
Overvej nedenstående figur:
Baseret på figuren, lad os prøve at replikere de 5 ½ trin:
- Applikation 1, applikation 2, applikation 3 og applikation 4 er 4 forskellige systemer.
- Hvert af disse systemer har det bestemte sæt funktionalitet, der skal identificeres.
- Input og output for hvert system skal identificeres.
- I tilfælde af Application1 gengiver den 2 output. 1 output danner input fra applikation 3 og 1 output formularer input fra applikation 2. Outputtet fra applikation 2 danner input til applikation 3 og applikation 4 og så videre.
- Gyldigheden for hver af input og output kontrolleres. Det vigtigste punkt at overveje her er, at de data, der krydser i form af input og output ikke bliver ændret, OG hele applikationen er dækket.
½ Denne figur i det virkelige liv ser måske ikke ud til at være så enkel. Dette resulterer faktisk i en mere kompleks struktur med n antal input og output betingelser.
Tegning af denne form for figur ville give et bedre billede til at identificere de data og information, der ville være gennem forskellige systemer. Dette vil hjælpe os med at udlede testbetingelser og tilfælde.
Et eksempel:
Lad os overveje et eksempel på udførelse af interoperabilitetstest for et 'Hospital Management System'
Et hospital består af nedenstående afdelinger og underafdelinger;
Her er hver afdeling en applikation i sig selv. Hver afdeling (ansøgning) har sin egen underafdeling (moduler), og hvert modul har sine egne enheder.
Så nu for at overveje omfanget af IOT er der få testbetingelser:
- En patient, der mødtes med en trafikulykke (OPD-afdeling - ulykke), skal gennemgå en benoperation (ENT - generel kirurgi) og derefter gennemgå fysioterapi (supportafdeling - fysioterapi) og får derefter udskrivning (supportafdeling - lukning)
- Et barn, der er indlagt i kritisk pleje (Pediatrics - Critical Care), skal gennemgå en operation (Pediatrics / ENT - General Surgery) og udskrives derefter (Supportafdeling - Lukning / PR)
- En ekstern patient konsulterer en generel læge (OPD-afdeling); tager de ordinerede lægemidler (Supportafdeling - Apotek) og går væk.
- En forventende mor kommer til regelmæssig kontrol (Gynækologisk afdeling - Mor og børnepasning), tager den ordinerede medicin (Supportafdeling - Apotek) og går væk.
- En tandpatient gør rodkanalen (Tandlægeafdelingen), tager den ordinerede medicin (Supportafdeling - Apotek) og går væk.
- En patient kommer i OPD (overlæge), gennemgår en behandling i (Fødsels- og gynækologisk afdeling - Højrisiko-fødselslæge) tager den ordinerede medicin (Supportafdeling - Apotek) og udskrives
På denne måde identificerer vi alle testbetingelser; at huske på, at det meste af afdelingen skal dækkes.
Vi kan tegne en RTM for at vise dækningen som:
På denne måde kan vi identificere flere testbetingelser og tegne RTM for at se vores nøjagtige omfang. Vi kan også bestemme dybden af vores testindsats baseret på RTM.
Som i dette eksempel ser vi, at 'Supportafdelingen' er applikationen, der er udgangsstedet for alle (de fleste) applikationer, hvorfor testindsatsen for denne særlige applikation er lidt mere sammenlignet med andre applikationer.
hvad er et dataindsamlingsværktøj
Udfordringer:
- Vanskeligt at teste al applikation med alle permutationer og kombinationer.
- Applikationer er udviklet i forskellige hardware / softwarekombinationer og installeres i forskellige miljøer, så hvis noget af miljøet er nede, påvirker det testen.
- På grund af de forskellige softwares og miljøer er det i sig selv en stor opgave at bestemme teststrategien og udføre den.
- Stimulere miljøet til at gennemføre testen er en stor udfordring.
- I tilfælde af en defekt er det en stor udfordring at foretage analyse af rodårsagen.
- Da applikationerne er i et netværk, vil der være tidspunkter, hvor netværket er nede. På grund af dette bliver test også påvirket.
Hvordan kan jeg afbøde disse udfordringer?
1) Prøv at bruge de forudgående testteknikker som:
- OATS (Ortogonal Array testteknik)
- Statlige overgangsdiagrammer,
- Årsag og virkning grafer
- Ækvivalensfordeling og grænseværdianalyse.
Disse teknikker hjælper dig med at identificere den indbyrdes afhængighed mellem applikationen og identificere testsager / -tilstande, der vil sikre maksimal dækning.
2) Prøv at identificere nogle historiske data som - under hvilke omstændigheder systemerne var nede, hvor lang tid tager det at være tilbage i aktion. I så fald skal du prøve at udføre de scenarier, hvis applikationer ikke påvirkes, eller bruge tiden til at dokumentere scenarierne og rapportere resultater. Desuden, når du planlægger eller planlægger testen, skal du altid overveje disse historiske data som et input til din estimering og planlægge i overensstemmelse hermed.
3) PLAN - Brug historiske data, tidligere erfaringer, holdets færdigheder, miljøfaktorer til at identificere teststrategien. Jo bedre din plan, jo bedre ville din udførelse være.
4) Begynd at arbejde på at forberede miljøet meget før, end din faktiske udførelse starter. Det er overflødigt at sige - planlæg dine skridt, når du forbereder miljøet. Sørg for, at dit miljø er klar, klar og klar, når din udførelse starter.
5) Inden du starter med IOT, skal du sikre dig, at de enkelte applikationer er fuldt funktionelt testet uden fejl. Så i tilfælde af en fejl, behøver du kun at kigge efter de miljømæssige faktorer, der har resulteret i en eller anden fejl.
6) Som beskrevet i punkt 2, planlæg din aktivitet. Hvis det er en planlagt afbrydelse, skal du overveje denne nedetid, når du planlægger din test.
Interoperabilitetstest på mobiltelefoner:
I Mobiles foretager vi interoperabilitetstest, hver gang en ny app ( Mobil applikation ) lanceres. Der er mange områder, som vi skal overveje, når vi planlægger denne test på mobile enheder:
- Typer af mobile enheder, der er tilgængelige på markedet, er enorme. Du bliver nødt til at angive, hvilke typer enheder du overvejer til din test. Du bliver nødt til at parre en enhedstype sammen med det operativsystem, den understøtter.
- Alt Mobile OS er udviklet på forskellige programmeringssprog. Derfor skal appen testes mod alle variationer af OS.
- Forståelse af de juridiske faktorer og regionrelaterede kontrakter.
- Størrelse / opløsning på forskellige enheder er forskellige.
- Indvirkning på de mobile indbyggede apps skal også overvejes.
Så for at gøre IOT på mobiltelefoner, skal du planlægge og oprette en RTM ligesom vi gjorde til en computerbaseret applikationstest.
Hensigten, strategien, risiciene og udførelsen ville være den samme, men den værktøjer og teknikker ville være anderledes i tilfælde af mobiltelefoner.
Konklusion:
Interoperabilitetstest er en kæmpe opgave. Denne teknik kræver korrekt planlægning, som skal starte parallelt, når systemtestplanlægningen starter.
Der er mange faktorer, der skal overvejes, når du udfører denne teknik. Husk at have tilstrækkelig tid til fejlfinding og gentestning, da dette er en enorm indsats, der skal være mulighed for opfølgning af mangler.
Dette kan ske, at du måske ikke opnår 100% dækning , men vi skal være kloge nok til at vælge vores sager på en sådan måde, at de fleste af applikationerne er dækket i en enkelt strøm ved hjælp af gode testcase-skriveteknikker.
Håber, at denne artikel var nyttig til at forstå interoperabilitetstestteknik. Fortæl os dine spørgsmål / kommentarer.
Anbefalet læsning
- Funktionel testning mod ikke-funktionel testning
- Vejledning til test af webapplikationssikkerhed
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
- Vejledning til bærbarhedstestning med praktiske eksempler
- Alpha-test og betatestning (En komplet guide)
- Typer af softwaretest: Forskellige testtyper med detaljer
- Hvad er lokaliseringstest og internationaliseringstest (enkel guide)
- Test af Primer eBook Download