Menu

Een eenvoudige gids voor interoperabiliteitstests (met voorbeelden)

simple guide interoperability testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Voordat u de techniek van 'Interoperabiliteitstests' , Laten we eerst de term 'interoperabiliteit' begrijpen.

Interoperabiliteit is het vermogen van het ene systeem om te communiceren met een ander systeem. Deze interactie is tussen 2 verschillende systemen of 2 verschillende applicaties samen.

Vaak wordt interoperabiliteit verward met Integratie , compatibiliteit en draagbaarheid. Welnu, er zijn verschillen tussen deze technieken.

Wat is interoperabiliteitstesten

Laat ik beginnen met het uitleggen van de verschillen.

Integratie - Is een techniek waarbij de componenten van hetzelfde systeem met elkaar communiceren. Dus in de testwereld, wanneer we integratietests uitvoeren, testen we in feite het gedrag van de twee of meer, laagste niveaus van componenten van hetzelfde systeem.

Compatibiliteit - Is een techniek waarbij 2 of meer applicaties in dezelfde omgeving samenwerken. Dus in de wereld van testen, wanneer we compatibiliteitstesten doen; we valideren of 2 of meer applicaties of systemen zich gedragen zoals verwacht in dezelfde omgeving.

Het is hier de bedoeling om te controleren of de twee systemen hun verwachte taken uitvoeren, zonder elkaar in dezelfde omgeving te hinderen. Zoals - MS Word en Calculator zijn twee verschillende applicaties en ze voeren hun verwachte gedrag onafhankelijk uit in hetzelfde besturingssysteem. Dus we zeggen dat deze 2 applicaties compatibel zijn met elkaar.

Draagbaarheid - Is een techniek waarbij een applicatie of systeem zich gedraagt ​​zoals verwacht wanneer het naar een andere omgeving wordt verplaatst. Dus in Draagbaarheid testen, exporteren we de applicatie naar een andere omgeving en testen we het gedrag ervan. Zoals, als er een applicatie is die goed werkt in Windows XP, zou deze ook goed moeten werken in Windows 10.

Interoperabiliteit - Is een techniek waarmee een applicatie samenwerkt met een andere applicatie. Dus wanneer we de interoperabiliteitstest doen, controleren we hoe de gegevens van de ene applicatie zonder voorafgaande mededeling op een zinvolle manier naar een andere applicatie worden overgebracht en verder verwerkt om de geaccepteerde output te geven.

hoe vind ik een netwerkbeveiligingssleutel

Dit specifieke artikel richt zich op interoperabiliteitstests (IOT), dus laten we ons concentreren op interoperabiliteit.​

Wat je leert:

Interoperabiliteitstesten - Een korte introductie

Interoperabiliteit = Inter + bruikbaar

Onder - betekent 'tussen onszelf', 'in elkaar', 'wederzijds'

Bedienbaar - betekent 'in staat om de gegeven taak uit te voeren'

Dus het combineren van de 2 termen - Interoperabiliteit betekent 2 (of meer) systemen, in staat om hun toegewezen taak onafhankelijk uit te voeren en in staat om met elkaar te communiceren zoals verwacht zonder hun individueel toegewezen functionaliteit te beïnvloeden.

Voorbeeld 1:Neem een ​​voorbeeld van het reserveren van uw vlucht. Bedenk dat je van New Delhi naar New York moet reizen. Nu heb je geen directe vlucht. U moet van New Delhi naar Londen reizen en vervolgens een aansluitende vlucht nemen van Londen naar New York. Omdat u enige tijdgebrek heeft, reserveert u uw vlucht van New Delhi naar Londen met 'Jet Airways' airways en van Londen naar New York met 'Virgin Atlantic'. Dat betekent dus dat al uw passagiersgegevens zijn doorgestuurd van Jet Airways naar Virgin Atlantic. Dus hier, Jet Airways en Virgin Atlantic, zijn beide onafhankelijke applicaties samen en tijdens het reserveren van uw vlucht werden uw boekingsgegevens op een betekenisvolle manier uitgewisseld van Jet Airways naar Virgin Atlantic, zonder voorafgaande kennisgeving.

Voorbeeld 2:Denk in vergelijkbare lijnen aan het ziekenhuisadministratiesysteem, waarbij de dossiers van patiënten worden uitgewisseld tussen de ene afdeling en de andere afdeling. Hier kan dus een afdeling worden gekoppeld aan een applicatie. Details van de patiënt worden zonder voorafgaande kennisgeving uitgewisseld tussen de ene applicatie en een andere applicatie.

Dus waarom moeten we de IOT doen?

We zouden de interoperabiliteitstests moeten uitvoeren om dat te garanderen

  • De applicaties in het netwerk voeren hun verwachte gedrag onafhankelijk uit,
  • Kan informatie uitwisselen zonder voorafgaande kennisgeving
  • De informatie / gegevens worden uitgewisseld zonder het individuele verwachte gedrag te onderbreken
  • De gegevens / informatie die wordt uitgewisseld, worden niet aangepast of gewijzigd

Hoe interoperabiliteitstests uitvoeren?

We kunnen het Deeming-wiel (de PDCA-cyclus) volgen om de interoperabiliteitstesten uit te voeren.

# 1) Plan

Planning is de belangrijkste fase bij het bepalen van de strategie om bijna alles te doen in de softwareontwikkeling. Voordat we daadwerkelijk plannen om de procedure voor het uitvoeren van de IOT te bepalen, is het absoluut noodzakelijk dat we elke toepassing of elk systeem dat in het netwerk wordt geïmplementeerd, begrijpen.

We zouden het moeten weten voor alle toepassingen: de functionaliteit, het gedrag, de invoer die nodig is en de uitvoer die het onthult.

Ik zou ook willen aanbevelen dat elke applicatie volledig functioneel wordt getest zonder defecten, voordat deze wordt voorbereid op de interoperabiliteitstests. Denk dus bij het plannen niet aan 1 of 2 applicaties, maar beschouw alle applicaties als een enkele eenheid. U moet een vogelperspectief hebben bij het plannen van deze testtechniek. Onnodig te zeggen dat u uw plan documenteert.

wat is de beste gratis video-omzetter

We kunnen onze standaard testplan document en pas het een beetje aan volgens de vereiste om de planning van IOT te documenteren. Nadat uw testplan op zijn plaats is, gaat u verder om uw testomstandigheden af ​​te leiden.

De focus van het afleiden van uw testconditie mag niet beperkt zijn tot de individuele toepassingen; in plaats daarvan zou het gebaseerd moeten zijn op de datastroom door alle applicaties. De voorwaarden moeten zo worden ontworpen dat, zo niet alle, maar de meeste toepassingen in het netwerk worden doorlopen.

Zodra uw testcondities zijn geïdentificeerd, gaat u verder met het ontwerpen of scripten (voor het geval u van plan bent om te automatiseren) uw testcases. Jij kan maak een RTM (Requirements Traceability Matrix) om uw testcases met testcondities en uw testcondities met acceptatietestcondities / eisen in kaart te brengen.

Wanneer je aan een netwerk werkt, is het weer belangrijk om ook de niet-functionele testactiviteiten te plannen. Dit is misschien nergens geschreven of gedocumenteerd, maar het is verplicht om de niet-functionele aspecten van het systeem als geheel te controleren. Deze niet-functionele gebieden omvatten prestaties en beveiliging. Indien gewenst kunt u een apart plan maken voor Functioneel testen, Prestatietesten en Security testen; of maak een enkel plan en een ander document met testomstandigheden voor elk van deze testtypen.

# 2) Doen

Doen - is de tijdspanne waarin u uw executie daadwerkelijk uitvoert. Plan uw tijd dienovereenkomstig om de functionele en niet-functionele tests uit te voeren. We volgen de testcyclus in deze fase van het uitvoeren van de cases, het loggen van de defecten, het opvolgen met het ontwikkelteam om de problemen op te lossen, de hertest en regressietest van het systeem als geheel uitvoeren, de testresultaten rapporteren en het verplaatsen naar sluiting.

# 3) Controleer

Check - Is de fase waarin we onze testresultaten opnieuw bekijken en proberen die met de RTM's in kaart te brengen en te valideren of aan alle verwachte vereisten is voldaan en of alle applicaties worden doorlopen. We controleren of de gegevens correct en soepel worden doorlopen en uitgewisseld tussen de applicaties / systemen. We zouden ook moeten valideren dat de gegevens die worden doorlopen niet worden gewijzigd.

Overweeg ook om een ​​retrospectief uit te voeren van het hele proces van interoperabiliteitstests. Identificeer de gebieden die goed hebben gewerkt, de gebieden die niet goed zijn gegaan en eventuele actiepunten die moeten worden aangepakt.

# 4) Handelen

Act - Is om te handelen op de items met terugwerkende kracht. De punten die werden geïdentificeerd als 'goede praktijken', gaan door met het uitvoeren van deze en de punten die beter zouden kunnen worden aangepakt, identificeren de stappen om deze te corrigeren en dienovereenkomstig te handelen. Houdt 1 ding in gedachten dat de gebieden of stappen die niet goed werkten, NIET herhaald mogen worden. We moeten tenslotte van onze fouten leren en ze niet herhalen.

De 5 ½ stappen:

  1. Identificeer alle applicaties die deel uitmaken van het netwerk.
  2. Identificeer hun respectievelijke functionaliteiten.
  3. Bepaal voor elke toepassing de input die nodig is en de output die het retourneert.
  4. Identificeer die gegevens die door alle / de meeste applicaties zouden gaan.
  5. Identificeer het verwachte gedrag voor elke combinatie van toepassing en datum die moet worden gevalideerd

½ Documenteer het.

Beschouw de onderstaande figuur:

5 ½ stappen

Laten we op basis van de afbeelding proberen de 5 ½ stappen te herhalen:

  1. Applicatie 1, Applicatie 2, Applicatie 3 en Applicatie 4 zijn 4 verschillende systemen.
  2. Elk van deze systemen heeft de specifieke functionaliteit die moet worden geïdentificeerd.
  3. Input en output van elk systeem moeten worden geïdentificeerd.
  4. In het geval van Application1 levert het 2 outputs op. 1 output vormt de input van Applicatie 3 en 1 output vormt input van Applicatie 2. De output van Applicatie 2 vormt de input voor Applicatie 3 en Applicatie 4 enzovoort.
  5. De geldigheid voor elk van de invoer en uitvoer wordt gecontroleerd. Het belangrijkste punt om hier rekening mee te houden is dat de gegevens die worden doorlopen in de vorm van invoer en uitvoer niet worden gewijzigd EN dat alle toepassingen worden gedekt.

½ Dit cijfer in het echte leven lijkt misschien niet zo eenvoudig. Dit resulteert eigenlijk in een meer complexe structuur met n aantallen invoer- en uitvoercondities.

Het tekenen van een dergelijke figuur zou een beter beeld geven om de gegevens en informatie te identificeren die door verschillende systemen zouden gaan. Dit zou ons helpen om de testcondities en cases af te leiden.

Een voorbeeld​

Laten we eens kijken naar een voorbeeld van het uitvoeren van interoperabiliteitstests voor een 'ziekenhuisbeheersysteem'

Een ziekenhuis bestaat uit de onderstaande afdelingen en subafdelingen;

Ziekenhuisbeheersysteem

Hier is elke afdeling een applicatie op zich. Elke afdeling (applicatie) heeft zijn eigen subafdeling (modules) en elke module heeft zijn eigen units.

Dus om nu de reikwijdte van IOT te overwegen, zijn hier enkele testomstandigheden:

  1. Een patiënt die een verkeersongeval heeft meegemaakt (OPD-afdeling - Ongeval), moet een beenoperatie ondergaan (KNO - Algemene Chirurgie), moet vervolgens de fysiotherapie ondergaan (Ondersteunende afdeling - Fysiotherapie) en krijgt vervolgens ontslag (Ondersteunende afdeling - Afsluiting)
  2. Een kind dat wordt opgenomen in de kritieke zorg (kindergeneeskunde - kritieke zorg) moet een operatie ondergaan (kindergeneeskunde / KNO - algemene chirurgie) en wordt vervolgens ontslagen (ondersteunende afdeling - afsluiting / PR)
  3. Een externe patiënt raadpleegt een huisarts (afdeling OPD); neemt de voorgeschreven medicijnen in (afdeling ondersteuning - apotheek) en loopt weg.
  4. Een aanstaande moeder komt regelmatig voor controle (afdeling gynaecologie - moeder- en kindzorg), neemt de voorgeschreven medicatie in (afdeling ondersteuning - apotheek) en loopt weg.
  5. Een tandheelkundige patiënt doet het wortelkanaal (afdeling Tandheelkunde), neemt de voorgeschreven medicatie (afdeling Ondersteuning - Apotheek) en loopt weg.
  6. Een patiënt komt in OPD (huisarts), ondergaat een behandeling bij (afdeling Verloskunde & Gynaecologie - Verloskunde Hoog Risico) neemt de voorgeschreven medicatie (afdeling Ondersteuning - Apotheek) en wordt ontslagen

Op deze manier identificeren we alle testcondities; rekening houdend met het feit dat het grootste deel van de afdeling gedekt moet worden.

We kunnen een RTM tekenen om de dekking weer te geven als:

RTM

Op deze manier kunnen we meer testomstandigheden identificeren en kunnen we de RTM tekenen om onze exacte scope te zien. Ook kunnen we de diepte van onze testinspanningen bepalen op basis van de RTM.

Net als in dit voorbeeld zien we dat de 'Support Department' de applicatie is die het uitgangspunt is voor alle (de meeste) applicaties, dus de testinspanning voor deze specifieke applicatie is iets meer in vergelijking met andere applicaties.

Uitdagingen:

  1. Moeilijk om alle toepassingen te testen met alle permutaties en combinaties.
  2. Applicaties worden ontwikkeld in verschillende hardware / softwarecombinaties en worden in verschillende omgevingen geïnstalleerd, dus als een van de omgevingen uitvalt, heeft dit invloed op het testen.
  3. Vanwege de verschillende software’s en omgevingen is het bepalen van de teststrategie en het uitvoeren ervan op zich al een hele opgave.
  4. Stimuleer de omgeving voor het uitvoeren van de test, is een grote uitdaging.
  5. In geval van een defect is het uitvoeren van de Root Cause Analysis een grote uitdaging.
  6. Omdat de applicaties zich in een netwerk bevinden, kunnen er momenten zijn dat het netwerk niet beschikbaar is. Hierdoor wordt ook het testen beïnvloed.

Hoe kan ik deze uitdagingen het hoofd bieden?

1) Probeer de geavanceerde testtechnieken te gebruiken, zoals:

  • OATS (Orthogonal Array-testtechniek)
  • State Transition Diagrams,
  • Oorzaak en gevolg grafieken
  • Equivalentie-portionering en grenswaardeanalyse.

Deze technieken zouden u helpen om de onderlinge afhankelijkheid tussen de applicaties te identificeren en de testgevallen / condities te identificeren die een maximale dekking zouden garanderen.

Veilige VPN voor Amazon Fire TV Stick

twee) Probeer enkele historische gegevens te identificeren, zoals - onder welke omstandigheden de systemen uitvielen, hoeveel tijd kost het om weer in actie te komen. Probeer in dat geval de scenario's uit te voeren waarvan de toepassingen niet worden beïnvloed, of gebruik de tijd om de scenario's te documenteren en de resultaten te rapporteren. Bovendien, wanneer u het testen plant of plant, moet u deze historische gegevens altijd beschouwen als input voor uw schatting en dienovereenkomstig plannen.

3) PLAN ​ Gebruik historische gegevens, ervaringen uit het verleden, vaardigheid van het team, omgevingsfactoren om de strategie van de tests te identificeren. Hoe beter je plan, hoe beter je uitvoering zou zijn.

4) Begin met het voorbereiden van de omgeving veel voordat uw daadwerkelijke uitvoering begint. Plan natuurlijk uw stappen wanneer u de omgeving voorbereidt. Zorg ervoor dat uw omgeving helemaal klaar, klaar en actief is wanneer uw uitvoering begint.

5) Voordat u met de IOT begint, moet u ervoor zorgen dat de afzonderlijke toepassingen volledig functioneel worden getest zonder defecten. In het geval van een defect hoeft u alleen te zoeken naar de omgevingsfactoren die tot een fout hebben geleid.

6) Zoals besproken in punt 2, Plan uw activiteit. Als het een geplande storing is, moet u deze uitvaltijd overwegen bij het plannen van uw tests.

Interoperabiliteitstest op mobiele telefoons:

In Mobiles doen we interoperabiliteitstests telkens wanneer een nieuwe app ( Mobiele applicatie ) wordt gelanceerd. Er zijn veel gebieden waarmee we rekening moeten houden bij het plannen van deze tests op mobiele apparaten:

  • De soorten mobiele apparaten die op de markt verkrijgbaar zijn, zijn enorm. U moet een lijst maken van alle soorten apparaten die u zou overwegen voor uw tests. U moet een apparaattype koppelen aan het besturingssysteem dat het ondersteunt.
  • Alle mobiele besturingssystemen zijn ontwikkeld in verschillende programmeertalen. Daarom moet de app worden getest op alle variaties van het besturingssysteem.
  • Inzicht in de juridische factoren en regiogerelateerde contracten.
  • Grootte / resolutie van verschillende apparaten zijn verschillend.
  • De impact op de mobiele ingebouwde apps moet ook worden overwogen.

Dus om IOT op mobiele telefoons te doen, moet u een RTM plannen en maken, net zoals we deden voor het testen van computergebaseerde applicaties.

De intentie, strategie, risico's en uitvoering zouden hetzelfde zijn, maar de tools en technieken zou anders zijn in het geval van mobiele telefoons.

Gevolgtrekking:

Het testen van interoperabiliteit is een enorme taak. Deze techniek vereist een goede planning die parallel zou moeten starten wanneer de planning van de systeemtest begint.

Er zijn veel factoren waarmee u rekening moet houden bij het uitvoeren van deze techniek. Houd er rekening mee dat u voldoende tijd heeft om bugs te verhelpen en opnieuw te testen, aangezien dit een enorme inspanning is en er voorzieningen moeten zijn voor het opvolgen van defecten.

Dit kan gebeuren dat u de 100% niet haalt Dekking , maar we moeten slim genoeg zijn om onze cases zo te selecteren dat de meeste toepassingen in één keer worden afgedekt door goede schrijftechnieken voor testcases te gebruiken.

Ik hoop dat dit artikel nuttig was om de testtechniek voor interoperabiliteit te begrijpen. Laat ons uw vragen / opmerkingen weten.

Aanbevolen literatuur

^