Interoperabilitetstest i softwaretest

Hvad er interoperabilitetstest?

Interoperabilitetstest er en type softwaretest, der kontrollerer, om softwaren kan interagere med andre softwarekomponenter og systemer. Formålet med interoperabilitetstests er at sikre, at softwareproduktet er i stand til at kommunikere med andre komponenter eller enheder uden kompatibilitetsproblemer.

Med andre ord betyder interoperabilitetstest at bevise, at end-to-end-funktionaliteten mellem to kommunikerende systemer er som specificeret i kravene. For eksempel udføres interoperabilitetstest mellem smartphones og tablets for at kontrollere dataoverførsel via Bluetooth.

Det er klassificeret som en form for funktionstest, fordi det spørgsmål, den besvarer, er adfærdsmæssigt: ankommer den udvekslede information intakt, og handler det modtagende system korrekt på den?

Forskellige niveauer af softwareinteroperabilitet

To systemer kan stemme overens på flere dybder. Hvert niveau nedenunder antager, at det ovenstående allerede fungerer.

• Fysisk interoperabilitet — selve forbindelsen etableres, for eksempel via Bluetooth, Wi-Fi, USB eller et kabelbaseret netværksforbindelse.
• Datatype interoperabilitet — begge sider koder og afkoder de samme primitive typer, tegnsæt og byterækkefølge.
• Specifikationsniveau Interoperabilitet — begge sider implementerer de samme meddelelsesformater og protokolregler, der er offentliggjort i specifikationen.
• Semantisk interoperabilitet — begge sider tillægger de udvekslede data den samme betydning, så et felt som "temperatur" fortolkes i den samme enhed og kontekst.

Hvorfor udføre interoperabilitetstest

Interoperabilitetstest udføres fordi,

• Det sikrer end-to-end servicelevering på tværs af to eller flere produkter fra forskellige leverandører
• Softwareproduktet skal kunne kommunikere med andre komponenter eller enheder uden kompatibilitetsproblemer.

Risiciene forbundet med manglende interoperabilitetstest er

• Tab af data
• Upålidelig ydeevne
• Upålidelig drift
• Forkert betjening
• Lav vedligeholdelse

Sådan laver du interoperabilitetstest

Testprocessen for interoperabilitetstest omfatter følgende trin.

Trin 1: Start projekt.

• Definer og formaliser arbejdsbeskrivelsen og opsæt en infrastruktur til projektledelsen.

Trin 2: Opret testlaboratorium

• Sørg for, at alle nødvendige færdigheder og automatiseringsværktøjer er konfigureret til testaktiviteter
• Brug automatiseringsværktøjer til at minimere testcases og genbruge testcases
• Vedligeholde en database med konfigurationsfiler
• Registrer og analyser metrikker for projektet
• Registrer konfiguration fra mislykkede test til reference og analyse

Trin 3: Udvikle testplan

• Skriv Testplan
• Definer testcases og procedurer
• Opsæt nødvendigt overvågningsudstyr til vedligeholdelse af testlogs.

Trin 4: Udfør testplan

• Udfør testsager
• Arbejd sammen med testteamet for at analysere den grundlæggende årsag til fejlen

Trin 5: Dokumentresultater

• Brug testlogfiler til at registrere implementeringsnoterne

Trin 6: Frigør ressourcer og evaluer ydeevnen på projektet,

• Analyser testresultaterne ved hjælp af automatiseringsværktøjer

Eksempel på testsager til interoperabilitetstest

Diagrammet nedenfor viser en typisk opsætning med to leverandører: Enheder fra forskellige producenter er forbundet, og enhver udveksling mellem dem bliver en testcase.

Teststrategien for interoperabilitetstest omfatter

• Tilslut to eller flere enheder fra forskellige leverandører
• Tjek forbindelsen mellem enheder
• Tjek om en enhed kan sende og modtage pakker eller rammer fra hinanden
• Tjek om data håndteres korrekt i netværket og facilitetslagene
• Tjek om implementerede algoritmer fungerer korrekt
• Resultat ok: Tjek næste resultat
• Resultatet er ikke ok: Brug overvågningsværktøjer til at finde fejlkilden
• Rapportér resultat i Testrapporteringsværktøj.

Værktøjer og teknikker til interoperabilitetstest

Intet enkelt produkt dækker en interoperabilitetsmatrix fra ende til anden. De fleste teams kombinerer en pakkeniveauvisning, en funktionel visning og en måde at træde i for partnersystemer, der ikke er tilgængelige i laboratoriet.

Udover værktøjerne gentages tre teknikker: parvis testning for at holde leverandørkombinationsmatricen håndterbar, negativ testning med misdannede eller versionsløse meddelelser og logning på protokolniveau, så en fejl kan identificeres. tractil præcis den ramme, der knækkede.

Bedste praksis for interoperabilitetstestning

Interoperabilitetsfejl er dyre, fordi de opstår sent i en andens miljø. Fremgangsmåderne nedenfor holder matricen under kontrol.

• Vedligehold en kompatibilitetsmatrix der viser alle enhedsmodeller, firmwareversioner og protokolversioner i omfanget, og opdaterer den ved hver udgivelse.
• Test bagud- og fremadkompatibilitet, ikke kun den seneste parring. Ældre jævnaldrende bliver i marken i årevis.
• Anchor testtilfælde i henhold til en offentliggjort standard såsom en IEEE-, ISO-, IETF- eller brancheprofil, så "bestået" betyder noget, som begge leverandører accepterer.
• Automatiser og kør kontinuerligt inde i CI-pipelinen, fordi en partneropdatering kan afbryde en parring, der blev gennemført i går.
• Simuler før du køber — emulatorer dækker bredden billigt, og fysiske laboratorier bekræfter derefter de kombinationer med den højeste risiko.
• Versionskontrol af hver konfiguration så en fejlende kørsel kan reproduceres nøjagtigt.
• Test af forringede forhold inklusive timeouts, mistede pakker, delvise beskeder og versionsfejl, ikke kun den lykkelige vej.
• Bliv enige om rapporteringsformatet tidligt med partnerleverandøren, så mangler kan retsforfølges på begge sider.

Interoperabilitetstest vs overensstemmelsestest

Interoperabilitet, overensstemmelse og kompatibilitetstest bruges ofte i flæng, men hver især besvarer et forskelligt spørgsmål.

Ulemper ved interoperabilitetstest

De største vanskeligheder ved interoperabilitetstest er

• Bestemmelse af grundlæggende årsager til defekter — en fejl kan sidde i begge systemer eller i netværket mellem dem.
• Præcis måling — resultaterne afhænger af timing og belastning, så den samme test kan bestå og fejle i på hinanden følgende kørsler.
• Skalerbarhed af test — hver ny leverandør multiplicerer kombinationsmatricen.
• Netværks kompleksitet — virkelige topologier matcher sjældent den forenklede laboratorieopsætning.
• Test af testudstyr — Analysatorer og simulatorer skal valideres, før resultaterne kan stoles på.
• Dokumentation af testresultater og læring — Resultaterne skal kunne læses af en ekstern partner, ikke kun det lokale team.
• Utilstrækkelige krav — vage specifikationer gør, at begge leverandører er teknisk kompatible, men alligevel ude af stand til at kommunikere.

Ofte Stillede Spørgsmål