simple guide interoperability testing
Innan du förstår tekniken för “Test av interoperabilitet” , Låt oss först förstå termen 'interoperabilitet'.
Interoperabilitet är ett systems förmåga att interagera med ett annat system. Denna interaktion är mellan två olika system eller två olika applikationer tillsammans.
Många gånger interoperabilitet förväxlas med Integration , kompatibilitet och bärbarhet. Det finns skillnader mellan dessa tekniker.
Låt mig först börja med att förklara skillnaderna.
Integration - Är en teknik när komponenterna i samma system interagerar med varandra. Så i testvärlden, när vi gör integrationstester, testar vi faktiskt beteendet hos de två eller flera, lägsta nivåerna av komponenter i samma system.
Kompatibilitet - Är en teknik genom vilken två eller flera applikationer interagerar i samma miljö. Så i testvärlden, när vi gör kompatibilitetstester; vi validerar om två eller flera applikationer eller system beter sig som förväntat i samma miljö.
Avsikten här är att kontrollera att de två systemen utför sina förväntade uppgifter utan att störa varandra i samma miljö. Liksom - MS Word och Calculator är två olika applikationer och de utför sitt förväntade beteende oberoende i samma operativsystem. Så vi säger att dessa två applikationer är kompatibla med varandra.
Bärbarhet - Är en teknik när ett program eller ett system beter sig som förväntat när det flyttas till en annan miljö. Så in Bärbarhet testar vi applikationen till någon annan miljö och testar dess beteende. Som om det finns ett program som fungerar bra i Windows XP, bör det också fungera bra i Windows 10.
Interoperabilitet - Är en teknik hur en applikation interagerar med en annan applikation. Så när vi gör interoperabilitetstestningen kontrollerar vi hur data från en applikation överförs till en annan applikation utan föregående antydan, på ett meningsfullt sätt och bearbetas vidare för att ge den accepterade utdata.
Det här dokumentet fokuserar på interoperabilitetstest (IOT), så låt oss hålla vårt fokus på interoperabilitet. :)
Vad du kommer att lära dig:
- Interoperabilitetstest - En kort introduktion
- Hur gör jag interoperabilitetstest?
- De 5 ½ stegen:
- Utmaningar:
- Interoperabilitetstest på mobiler:
- Slutsats:
- Rekommenderad läsning
Interoperabilitetstest - En kort introduktion
Interoperabilitet = Inter + operativ
Inter - betyder 'mellan oss själva', 'inom varandra', 'ömsesidig'
Manövrerbar - betyder 'kapabel att utföra den givna uppgiften'
Så att kombinera de två termerna tillsammans - Interoperabilitet betyder 2 (eller fler) system, som kan utföra sin tilldelade uppgift oberoende och kunna kommunicera med varandra som förväntat utan att påverka deras individuella tilldelade funktionalitet.
vad är en xml-fil och hur öppnar jag den
Exempel 1:Ta ett exempel på att boka ditt flyg. Tänk på att du måste resa från New Delhi till New York. Nu har du inte direktflyg. Du måste resa från New Delhi till London och sedan ta anslutningsflyg från London till New York. Eftersom du har några tidsbegränsningar, reserverar du ditt flyg från New Delhi till London i 'Jet Airways' luftvägar och från London till New York i 'Virgin Atlantic'. Så det betyder att alla dina passagerardetaljer har passerat från Jet Airways till Virgin Atlantic. Så här, Jet Airways och Virgin Atlantic, båda är oberoende applikationer tillsammans och medan du bokar ditt flyg, byttes dina bokningsuppgifter från Jet Airways till Virgin Atlantic på ett meningsfullt sätt, utan föregående antydan.
Exempel 2:Tänk på sjukhusadministrationssystemet i liknande linjer, där patientjournalerna utbyts mellan en avdelning till en annan avdelning. Så här kan avdelningen länkas till en ansökan. Detaljer om patienten byts mellan en ansökan till en annan ansökan utan föregående meddelande.
Så varför behöver vi göra IOT?
Vi skulle behöva göra interoperabilitetstestningen för att säkerställa det
- Applikationerna i nätverket utför sitt förväntade beteende oberoende,
- Kan utbyta information utan föregående meddelande
- Informationen / data utbyts utan att det individuella förväntade beteendet avbryts
- Data / information som utbyts ändras inte eller ändras inte
Hur gör jag interoperabilitetstest?
Vi kan följa hjulet Deeming (PDCA-cykeln) för att utföra interoperabilitetstestningen.
# 1) Planera
Planering är den viktigaste fasen för att bestämma strategin för att göra nästan vad som helst i programvaruutvecklingen. Innan vi faktiskt planerar för att bestämma proceduren för att göra IOT är det viktigt att vi förstår varje applikation eller system som distribueras i nätverket.
Vi borde veta för alla applikationer - dess funktionalitet, beteende, input det tar och output det avslöjar.
Jag rekommenderar också att varje applikation testas fullständigt utan defekter innan den förbereds för interoperabilitetstestning. Så när du planerar, tänk inte bara på en eller två applikationer, tänk på alla applikationer som en enda enhet. Du måste ha en fågelperspektiv när du planerar för denna testteknik. Det behöver inte sägas att - dokumentera din plan.
Vi kan använda vår standard testplan dokument och skräddarsy det enligt kraven på att dokumentera planeringen av IOT. När din testplan är på plats, gå vidare för att få fram dina testförhållanden.
Fokus för att få ditt testvillkor bör inte begränsas till de enskilda applikationerna; istället bör det baseras på dataflöde genom alla applikationer. Villkoren bör utformas på ett sådant sätt att, om inte alla, men de flesta applikationer i nätverket går igenom.
När dina testvillkor har identifierats, gå vidare till design eller skript (om du planerar att automatisera) dina testfall. Du kan skapa en RTM (Krav Spårbarhetsmatris) för att kartlägga dina testfall med testvillkor och dina testvillkor med godkännande testvillkor / krav.
När du arbetar på ett nätverk är det återigen viktigt att också planera för icke-funktionella testaktiviteter. Detta kanske inte skrivs eller dokumenteras någonstans, men det är obligatoriskt att kontrollera om de icke-funktionella aspekterna av systemet som helhet. Dessa icke-funktionella områden inkluderar prestanda och säkerhet. Om det behövs kan du skapa en separat plan för funktionstestning, prestandatestning och säkerhetstestning; eller skapa en enda plan och ett annat dokument med testvillkor för var och en av dessa testtyper.
# 2) Gör
Gör - är tidsperioden där du faktiskt utför din körning. Planera din tid i enlighet med detta för att utföra funktionell och icke-funktionell testning. Vi följer testcykeln i denna fas för att utföra ärenden, logga defekterna, följa upp med utvecklingsgruppen för att få de lösta, göra omprovet och regressionstestet av systemet som helhet, rapportera testresultaten och flytta det till stängning.
# 3) Kontrollera
Kontrollera - Är den fas där vi granskar våra testresultat och försöker kartlägga dem med RTM och validera om alla förväntade krav är uppfyllda och om alla applikationer passeras. Vi kontrollerar att data passeras och utbyts korrekt och smidigt mellan applikationerna / systemen. Vi skulle också behöva verifiera att de data som passeras inte ändras.
Tänk också på att göra en retrospektiv på hela processen för interoperabilitetstestning. Identifiera de områden som fungerade bra, de som inte gick bra och eventuella åtgärder som måste tas om hand.
# 4) Lag
Act - Är att agera på retrospektiva föremål. De punkter som identifierades som ”god praxis”, fortsätter att utföra dessa och de punkter som kan fungera bättre, identifierar stegen för att rätta till dem och agerar därefter. Tänk på en sak att områdena eller stegen som inte fungerade bra, INTE ska upprepas. När allt kommer omkring borde vi lära oss av våra misstag och inte upprepa dem.
De 5 ½ stegen:
- Identifiera alla applikationer som ingår i nätverket.
- Identifiera deras respektive funktioner.
- Identifiera den ingång som krävs för varje applikation och den utmatning den returnerar.
- Identifiera de data som skulle passera genom alla / de flesta applikationer.
- Identifiera det förväntade beteendet för varje kombination av applikation och datum som måste valideras
½ Dokumentera det.
Tänk på nedanstående bild:
Baserat på figuren, låt oss försöka replikera de 5 ½ stegen:
- Applikation 1, applikation 2, applikation 3 och applikation 4 är fyra olika system.
- Var och en av dessa system har den bestämda uppsättningen funktionalitet som behöver identifieras.
- In- och utgångar för varje system måste identifieras.
- I fallet med Application1 ger den två utgångar. 1 utgång bildar ingången för applikation 3 och 1 utgångsformat ingång för applikation 2. Utgången från applikation 2 bildar ingången till applikation 3 och applikation 4 och så vidare.
- Giltigheten för varje ingång och utgång kontrolleras. Den viktigaste punkten att tänka på här är att data som passerar i form av in- och utdata inte ändras OCH all applikation täcks.
½ Denna siffra i verkliga livet kanske inte verkar vara så enkel. Detta resulterar faktiskt i mer komplex struktur med n antal in- och utgångsförhållanden.
Att rita denna typ av figur skulle ge en bättre bild för att identifiera data och information som skulle passera genom olika system. Detta skulle hjälpa oss att härleda testvillkoren och fallen.
Ett exempel:
Låt oss överväga ett exempel på att utföra driftskompatibilitetstester för ett 'sjukhushanteringssystem'
Ett sjukhus består av nedanstående avdelningar och underavdelningar;
Här är varje avdelning en applikation i sig. Varje avdelning (ansökan) har sin egen underavdelning (moduler) och varje modul har sina egna enheter.
Så nu för att överväga omfattningen av IOT, här är några testvillkor:
- En patient som träffade en trafikolycka (OPD-avdelningen - olycka), måste genomgå en benoperation (ENT - Allmän kirurgi), måste sedan genomgå sjukgymnastik (supportavdelningen - sjukgymnastik) och får sedan urladdning (supportavdelningen - stängning)
- Ett barn som antagits till kritisk vård (Pediatrics - Critical Care) måste genomgå en operation (Pediatrics / ENT - General Surgery) och sedan skrivs ut (Supportavdelningen - Stängning / PR)
- En extern patient konsulterar en allmänläkare (OPD-avdelningen); tar de ordinerade läkemedlen (supportavdelningen - apotek) och går iväg.
- En väntande mamma kommer för regelbundna kontroller (Gynekologiska avdelningen - Moder- och barnomsorg), tar ordinerad medicin (Supportavdelningen - Apotek) och går iväg.
- En tandpatient gör rotkanalen (Tandvårdsavdelningen), tar den förskrivna medicinen (Supportavdelningen - Apotek) och går iväg.
- En patient kommer i OPD (allmänläkare), genomgår en behandling i (Obstetrics & Gynecology department - High Risk Obstetrics) tar den ordinerade medicinen (Supportavdelningen - Apotek) och är urladdad
På så sätt identifierar vi alla testförhållanden; med tanke på att större delen av avdelningen måste täckas.
Vi kan rita en RTM för att visa täckningen som:
På så sätt kan vi identifiera fler testförhållanden och kan rita RTM för att se vårt exakta omfång. Vi kan också bestämma djupet av våra testinsatser baserat på RTM.
Som i det här exemplet ser vi att 'Supportavdelningen' är applikationen som är utgångspunkten för alla (de flesta) applikationerna, därför är testansträngningen för denna specifika applikation lite mer jämfört med andra applikationer.
Utmaningar:
- Svårt att testa alla applikationer med alla permutationer och kombinationer.
- Applikationer är utvecklade i olika hårdvaru / mjukvarukombinationer och installeras i olika miljöer, så om någon av miljön är nere påverkar den testningen.
- På grund av olika programvaror och miljöer är det i sig själv en stor uppgift att bestämma teststrategin och utföra den.
- Stimulera miljön för att genomföra testet, är en stor utmaning.
- I händelse av defekter är det en stor utmaning att göra Root Cause Analysis.
- Eftersom applikationerna finns i ett nätverk kan det hända att nätverket är nere. På grund av detta påverkas också testningen.
Hur kan jag mildra dessa utmaningar?
1) Försök att använda avancerade testtekniker som:
- OATS (Ortogonal Array testteknik)
- Statliga övergångsdiagram,
- Orsak och effektdiagram
- Portion av ekvivalens och analys av gränsvärden.
Dessa tekniker hjälper dig att identifiera det ömsesidiga beroendet mellan applikationen och identifiera testfall / förhållanden som skulle säkerställa maximal täckning.
två) Försök att identifiera några historiska data som - under vilka omständigheter systemen var nere, hur mycket tid det tar att vara tillbaka i aktion. Försök i så fall att utföra de scenarier vars applikationer inte påverkas, eller utnyttja tiden för att dokumentera scenarierna och rapportera resultat. Dessutom, när du planerar eller schemalägger testningen, betrakta alltid dessa historiska data som en input för din uppskattning och planera därefter.
3) PLANEN - Använd historisk data, tidigare erfarenheter, teamets skicklighet, miljöfaktorer för att identifiera teststrategin. Ju bättre din plan, desto bättre skulle ditt utförande vara.
4) Börja arbeta med att förbereda miljön mycket tidigare än ditt verkliga utförande börjar. Det behöver inte sägas att planera dina steg när du förbereder miljön. Se till att din miljö är klar, redo och igång när din körning börjar.
5) Innan du börjar med IOT, se till att de enskilda applikationerna testas helt funktionellt utan fel. Vid eventuella fel skulle du bara behöva leta efter de miljöfaktorer som har resulterat i något fel.
6) Som diskuterats i punkt 2, planera din aktivitet. Om det är ett planerat avbrott bör du överväga den här stilleståndstiden när du planerar din testning.
Interoperabilitetstest på mobiler:
I mobiler gör vi interoperabilitetstest när en ny app ( Mobil-app ) lanseras. Det finns många områden som vi måste tänka på när vi planerar för denna testning på mobila enheter:
- Typer av mobila enheter som finns på marknaden är enorma. Du måste lista upp vilka alla typer av enheter du skulle tänka på för din testning. Du måste para ihop en enhetstyp tillsammans med operativsystemet den stöder.
- Alla Mobile OS är utvecklade på olika programmeringsspråk. Därför måste appen testas mot alla variationer av OS.
- Förstå de juridiska faktorerna och regionrelaterade kontrakt.
- Storlek / upplösning på olika enheter är olika.
- Påverkan på de mobila inbyggda apparna måste också övervägas.
Så för att göra IOT på mobiler behöver du planera och skapa en RTM precis som vi gjorde för en datorbaserad applikationstestning.
Avsikten, strategin, riskerna och genomförandet skulle vara detsamma men verktyg och tekniker skulle vara annorlunda när det gäller mobiler.
Slutsats:
Interoperabilitetstestning är en enorm uppgift. Denna teknik kräver korrekt planering som bör börja parallellt när systemtestplaneringen startar.
Det finns många faktorer som måste övervägas när du använder denna teknik. Tänk på att ha tillräckligt med tid för felkorrigering och omprövning, eftersom detta är en enorm ansträngning det bör finnas möjlighet att följa upp defekter.
Det kan hända att du kanske inte uppnår 100% rapportering , men vi borde vara tillräckligt smarta för att välja våra ärenden på ett sådant sätt att de flesta applikationerna täcks i ett enda flöde med bra testfallstekniker.
nätintervjufrågor och svar för erfarna
Hoppas den här artikeln var användbar för att förstå interoperabilitetstestteknik. Låt oss veta dina frågor / kommentarer.
Rekommenderad läsning
- Funktionell testning mot icke-funktionell testning
- Guide för testning av webbapplikationssäkerhet
- Bästa verktyg för testning av programvara 2021 [QA Test Automation Tools]
- Handbok för testbarhet med praktiska exempel
- Alfatestning och betatestning (En komplett guide)
- Typer av programvarutestning: Olika testtyper med detaljer
- Vad är lokaliseringstestning och internationaliseringstestning (enkel guide)
- Testing Primer eBook Download