simple guide interoperability testing
Înainte de a înțelege tehnica „Testarea interoperabilității” , Să înțelegem mai întâi termenul „Interoperabilitate”.
Interoperabilitatea este capacitatea unui sistem de a interacționa cu un alt sistem. Această interacțiune este între 2 sisteme diferite sau 2 aplicații diferite, toate împreună.
De multe ori interoperabilitatea este confundată cu Integrare , compatibilitate și portabilitate. Ei bine, există diferențe între aceste tehnici.
Permiteți-mi să încep prin a explica diferențele.
cum se deschid fișiere binare în Windows
Integrare - Este o tehnică atunci când componentele aceluiași sistem interacționează între ele. Deci, în lumea testării, atunci când facem teste de integrare, testăm de fapt comportamentul celor 2 sau mai multe niveluri, cele mai mici, ale componentelor aceluiași sistem.
Compatibilitate - Este o tehnică prin care 2 sau mai multe aplicații interacționează în același mediu. Deci, în lumea testării, când facem teste de compatibilitate; validăm dacă 2 sau mai multe aplicații sau sisteme se comportă conform așteptărilor în același mediu.
Intenția de aici este de a verifica dacă cele două sisteme își îndeplinesc sarcinile așteptate, fără a se interfera reciproc lucrând, în același mediu. Like - MS Word și Calculator sunt 2 aplicații diferite și își îndeplinesc comportamentul așteptat independent în același sistem de operare. Deci, spunem că aceste 2 aplicații sunt compatibile între ele.
Portabilitate - Este o tehnică atunci când o aplicație sau un sistem se comportă așa cum era de așteptat atunci când este mutat într-un alt mediu. Deci în Portabilitate testând, exportăm aplicația în alt mediu și testăm comportamentul acesteia. De exemplu, dacă există o aplicație care funcționează bine în Windows XP, ar trebui să funcționeze și în Windows 10.
Interoperabilitate - Este o tehnică a modului în care o aplicație interacționează cu o altă aplicație. Deci, atunci când efectuăm testarea interoperabilității, verificăm modul în care datele dintr-o aplicație sunt transferate într-o altă aplicație fără o informație prealabilă, într-un mod semnificativ și procesate în continuare pentru a da rezultatul acceptat.
Această lucrare specială se concentrează pe testarea interoperabilității (IOT), deci să ne concentrăm asupra interoperabilității. :)
Ce veți învăța:
- Testarea interoperabilității - O scurtă introducere
- Cum se fac teste de interoperabilitate?
- Cei 5 ½ pași:
- Provocări:
- Test de interoperabilitate pe telefoane mobile:
- Concluzie:
- Lectură recomandată
Testarea interoperabilității - O scurtă introducere
Interoperabilitate = Inter + operabil
Inter - înseamnă „între noi”, „în interiorul celuilalt”, „reciproc”
Operabil - înseamnă „capabil să îndeplinească sarcina dată”
Așadar, combinarea celor 2 termeni împreună - Interoperabilitatea înseamnă 2 (sau mai multe) sisteme, capabile să își îndeplinească sarcina alocată independent și capabile să comunice între ele așa cum era de așteptat, fără a afecta funcționalitatea lor individuală atribuită.
Exemplul nr. 1:Luați un exemplu de rezervare a zborului. Luați în considerare că trebuie să călătoriți de la New Delhi la New York. Acum nu aveți un zbor direct. Trebuie să călătoriți de la New Delhi la Londra și apoi să luați un zbor de legătură de la Londra la New York. Deoarece aveți anumite constrângeri de timp, vă rezervați zborul de la New Delhi la Londra în căile aeriene „Jet Airways” și de la Londra la New York în „Virgin Atlantic”. Deci, asta înseamnă că toate detaliile pasagerilor dvs. au fost traversate de la Jet Airways la Virgin Atlantic. Deci, aici, Jet Airways și Virgin Atlantic, ambele sunt aplicații independente împreună și, în timp ce vă rezervați zborul, detaliile dvs. de rezervare au fost schimbate de la Jet Airways la Virgin Atlantic într-un mod semnificativ complet, fără a fi înștiințate în prealabil.
Exemplul nr. 2:În linii similare, gândiți-vă la sistemul de administrare a spitalului, unde înregistrările pacienților sunt schimbate între un departament și alt departament. Deci, aici departamentul poate fi legat de o aplicație. Detaliile pacientului sunt schimbate între o cerere și o altă aplicație fără o notificare prealabilă.
Deci, de ce trebuie să facem IOT?
Ar trebui să facem testele de interoperabilitate pentru a ne asigura că
- Aplicațiile din rețea își desfășoară comportamentul așteptat independent,
- Poate face schimb de informații fără notificare prealabilă
- Informațiile / datele sunt schimbate fără a întrerupe comportamentul individual așteptat
- Datele / informațiile schimbate nu sunt modificate sau modificate
Cum se fac teste de interoperabilitate?
Putem urmări roata Deeming (ciclul PDCA) pentru a efectua testele de interoperabilitate.
# 1) Planul
Planificarea este cea mai importantă fază a determinării strategiei de a face aproape orice în dezvoltarea software-ului. Înainte de a planifica efectiv determinarea procedurii de realizare a IOT, este imperios să înțelegem fiecare aplicație sau sistem implementat în rețea.
Ar trebui să știm pentru toate aplicațiile - funcționalitatea, comportamentul, intrarea necesară și ieșirea pe care o dezvăluie.
Aș recomanda, de asemenea, ca fiecare aplicație să fie testată complet funcțional, fără defecte, înainte de a o pregăti pentru testarea interoperabilității. Deci, atunci când planificați, nu vă gândiți doar la 1 sau 2 aplicații, gândiți-vă la toate aplicațiile ca la o singură unitate. Trebuie să aveți o vedere de pasăre atunci când planificați această tehnică de testare. Inutil să spun că - documentați-vă planul.
Ne putem folosi de documentul standard al planului de testare și adaptați-l puțin conform cerinței de a documenta planificarea IOT. După ce planul de testare este în vigoare, mergeți mai departe pentru a obține condițiile de testare.
Concentrarea în determinarea condiției de testare nu ar trebui să se limiteze la aplicațiile individuale; în schimb, ar trebui să se bazeze pe fluxul de date prin toate aplicațiile. Condițiile ar trebui proiectate în așa fel încât, dacă nu chiar toate, dar majoritatea aplicațiilor din rețea să fie traversate.
Odată ce condițiile de testare sunt identificate, mergeți mai departe la proiectare sau script (în cazul în care intenționați să automatizați) cazurile de testare. Poti creați un RTM (Matricea de trasabilitate a cerințelor) pentru cartografierea cazurilor de testare cu condițiile de testare și condițiile de testare cu condițiile / cerințele de testare de acceptare.
Când lucrați la o rețea, este din nou important să planificați și activitățile de testare nefuncțională. Este posibil să nu fie scris sau documentat nicăieri, dar este obligatoriu să verificați aspectele nefuncționale ale sistemului în ansamblu. Aceste zone nefuncționale ar include performanța și securitatea. Dacă este necesar, puteți crea un plan separat pentru testarea funcțională, testarea performanței și testarea securității; sau creați un singur plan și un document diferit al condițiilor de testare pentru fiecare dintre aceste tipuri de testare.
# 2) Fă
Do - este intervalul de timp în care efectuați efectiv execuția. Planificați-vă timpul în consecință pentru a efectua testarea funcțională și nefuncțională. Urmărim ciclul de testare în această fază de executare a cazurilor, înregistrarea defectelor, urmărirea cu echipa de dezvoltare pentru a rezolva problemele, efectuarea testului de re-testare și regresie a sistemului în ansamblu, raportarea rezultatelor testului și mutarea acestuia în închidere.
# 3) Verificați
Verificare - Este faza în care revizuim rezultatele testelor și încercăm să le mapăm pe cele cu RTM-uri și să validăm dacă sunt îndeplinite toate cerințele așteptate și dacă toate aplicațiile sunt traversate. Verificăm dacă datele sunt traversate și schimbate corect și fără probleme între aplicații / sisteme. De asemenea, ar trebui să validăm faptul că datele traversate nu sunt modificate.
De asemenea, luați în considerare să faceți o retrospectivă a întregului proces de testare a interoperabilității. Identificați zonele care au funcționat bine, cele care nu au mers bine și orice elemente de acțiune care trebuie îngrijite.
# 4) Act
Act - Este de a acționa asupra elementelor retrospective. Punctele care au fost identificate ca „bune practici”, continuă să le execute și punctele care ar putea fi mai bine lucrate, identifică pașii pentru corectarea acestora și acționează în consecință. Rețineți un lucru că zonele sau pașii care nu au funcționat bine NU trebuie repetați. La urma urmei, ar trebui să învățăm din greșelile noastre și să nu le repetăm.
Cei 5 ½ pași:
- Identificați toate aplicațiile care fac parte din rețea.
- Identificați funcționalitățile respective.
- Pentru fiecare aplicație, identificați intrarea necesară și ieșirea pe care o returnează.
- Identificați acele date care ar traversa toate / majoritatea aplicațiilor.
- Identificați comportamentul așteptat pentru fiecare combinație de aplicație și dată care trebuie validată
½ Documentați-l.
Luați în considerare figura de mai jos:
Pe baza cifrei, să încercăm să reproducem pașii de 5 ½:
- Aplicația 1, Aplicația 2, Aplicația 3 și Aplicația 4 sunt 4 sisteme diferite.
- Fiecare dintre aceste sisteme are setul definit de funcționalitate care trebuie identificat.
- Intrările și ieșirile fiecărui sistem trebuie identificate.
- În cazul Application1, acesta redă 2 ieșiri. 1 ieșire formează intrarea aplicației 3 și 1 ieșire formează intrarea aplicației 2. Ieșirea din aplicația 2 formează intrarea aplicației 3 și aplicației 4 și așa mai departe.
- Se verifică validitatea pentru fiecare dintre intrări și ieșiri. Punctul major de luat în considerare aici este că datele care sunt traversate sub formă de intrare și ieșire nu sunt modificate ȘI toată aplicația este acoperită.
½ Această cifră din viața reală poate să nu pară atât de simplă. Acest lucru are ca rezultat o structură mai complexă cu n numere de condiții de intrare și ieșire.
Desenarea acestui tip de figură ar oferi o imagine mai bună pentru a identifica datele și informațiile care ar fi traversate prin diferite sisteme. Acest lucru ne-ar ajuta să obținem condițiile și cazurile de testare.
Un exemplu:
Să luăm în considerare un exemplu de efectuare a testelor de interoperabilitate pentru un „sistem de management al spitalului”
Un spital este format din departamentele și subdepartamentele de mai jos;
Aici fiecare departament este o aplicație în sine. Fiecare departament (aplicație) are propriul său departament (module) și fiecare modul are propriile sale unități.
Deci, acum, pentru a lua în considerare scopul IOT, iată câteva condiții de testare:
- Un pacient care a întâmpinat un accident rutier (Departamentul OPD - Accident), trebuie să fie supus unei intervenții chirurgicale la picioare (ORL - Chirurgie generală), apoi trebuie să urmeze fizioterapia (Departamentul de asistență - Fizioterapie) și apoi să primească externarea (Departamentul de asistență - Închidere)
- Un copil internat în îngrijiri critice (Pediatrie - Îngrijire critică) trebuie să fie supus unei intervenții chirurgicale (Pediatrie / ORL - Chirurgie generală) și apoi este externat (Departamentul de asistență - Închidere / PR)
- Un pacient extern consultă un medic generalist (secția OPD); ia medicamentele prescrise (Departamentul de asistență - farmacie) și se îndepărtează.
- O mamă așteptată vine la controale regulate (secția ginecologie - îngrijirea mamei și a copilului), ia medicamentele prescrise (departamentul de asistență - farmacie) și pleacă.
- Un pacient stomatologic face canalul radicular (secția stomatologie), ia medicamentele prescrise (departamentul de asistență - farmacie) și pleacă.
- Un pacient vine în OPD (medic general), urmează un tratament în (secția de obstetrică și ginecologie - obstetrică cu risc ridicat) ia medicamentul prescris (secția de asistență - farmacie) și este externat
Astfel identificăm toate condițiile de testare; ținând cont de faptul că cea mai mare parte a departamentului trebuie acoperită.
Putem desena un RTM pentru a arăta acoperirea ca:
În acest fel putem identifica mai multe condiții de testare și putem desena RTM pentru a vedea scopul nostru exact. De asemenea, putem determina profunzimea eforturilor noastre de testare pe baza RTM.
La fel ca în acest exemplu, vedem că „Departamentul de asistență” este aplicația care este punctul de ieșire pentru toată (cea mai mare parte) a aplicației, prin urmare efortul de testare pentru această aplicație specială este puțin mai mare în comparație cu alte aplicații.
Provocări:
- Este dificil să testați toate aplicațiile cu toate permutările și combinațiile.
- Aplicațiile sunt dezvoltate în diferite combinații hardware / software și sunt instalate în medii diferite, astfel încât, dacă vreunul dintre medii nu funcționează, acesta va avea impact asupra testării.
- Datorită diferitelor software și medii, determinarea strategiei de testare și executarea acesteia este în sine o sarcină importantă.
- Stimularea mediului pentru efectuarea testului, este o mare provocare.
- În cazul oricărui defect, efectuarea analizei cauzei rădăcinii este o mare provocare.
- Deoarece aplicațiile se află într-o rețea, ar exista momente în care rețeaua nu funcționează. Din acest motiv, testarea devine afectată.
Cum pot atenua aceste provocări?
1) Încercați să utilizați tehnici de testare în avans, cum ar fi:
- OATS (tehnica de testare a matricei ortogonale)
- Diagrame de tranziție de stat,
- Graficele cauzei și efectelor
- Porționarea echivalenței și analiza valorii limită.
Aceste tehnici vă vor ajuta să identificați interdependența între aplicație și să identificați cazurile / condițiile de testare care să asigure o acoperire maximă.
ce strat al modelului osi este utilizat pentru semnale, biți, cabluri și conectori?
Două) Încercați să identificați unele date istorice, cum ar fi - în ce circumstanțe sistemele au funcționat, cât timp este necesar pentru a reveni în acțiune. În acest caz, încercați să executați acele scenarii ale căror aplicații nu sunt afectate sau utilizați timpul pentru a documenta scenariile și a raporta rezultatele. Mai mult, ori de câte ori planificați sau programați testarea, luați întotdeauna în considerare aceste date istorice ca o intrare pentru estimarea dvs. și planificați în consecință.
3) PLAN - Folosiți date istorice, experiențe anterioare, abilități ale echipei, factori de mediu pentru a identifica strategia testării. Cu cât planul tău este mai bun, cu atât ar fi mai bună execuția ta.
4) Începeți să pregătiți mediul cu mult înainte de a începe execuția efectivă. Inutil să spun - planificați-vă pașii atunci când pregătiți mediul. Asigurați-vă că mediul dvs. este gata, gata și funcționează când începe executarea.
5) Înainte de a începe cu IOT, asigurați-vă că aplicațiile individuale sunt complet testate funcțional, fără defecte. Apoi, în cazul oricărui defect, ar trebui să căutați doar factorii de mediu care au dus la o anumită eroare.
6) După cum sa discutat la punctul 2, planificați-vă activitatea. Dacă este o întrerupere programată, ar trebui să luați în considerare acest timp de nefuncționare atunci când vă planificați testarea.
Test de interoperabilitate pe telefoane mobile:
În telefoane mobile, facem test de interoperabilitate ori de câte ori o nouă aplicație ( Aplicatie de mobil ) este lansat. Există multe domenii pe care trebuie să le luăm în considerare atunci când planificăm acest test pe dispozitive mobile:
- Tipurile de dispozitive mobile disponibile pe piață sunt imense. Ar trebui să enumerați toate tipurile de dispozitive pe care le-ați lua în considerare pentru testare. Trebuie să asociați un tip de dispozitiv împreună cu sistemul de operare pe care îl acceptă.
- Toate sistemele de operare mobile sunt dezvoltate în diferite limbaje de programare. Prin urmare, aplicația trebuie testată împotriva tuturor variantelor de sistem de operare.
- Înțelegerea factorilor legali și a contractelor legate de regiune.
- Dimensiunea / rezoluția diferitelor dispozitive sunt diferite.
- Impactul asupra aplicațiilor mobile încorporate trebuie, de asemenea, luat în considerare.
Deci, pentru a face IOT pe telefoane mobile, ar trebui să planificați și să creați un RTM la fel cum am făcut pentru o testare a aplicației pe computer.
Intenția, strategia, riscurile și execuția ar fi aceleași decât cele instrumente și tehnici ar fi diferit în cazul telefoanelor mobile.
Concluzie:
Testarea interoperabilității este o sarcină uriașă. Această tehnică necesită o planificare adecvată, care ar trebui să înceapă paralel când începe planificarea testului de sistem.
Există o mulțime de factori care trebuie luați în considerare la executarea acestei tehnici. Rețineți că aveți suficient timp pentru remedierea și testarea erorilor, deoarece acesta este un efort uriaș, ar trebui să existe prevederi pentru urmărirea defectelor.
Acest lucru se poate întâmpla dacă nu puteți atinge 100% acoperire , dar ar trebui să fim suficient de inteligenți pentru a ne selecta cazurile în așa fel încât majoritatea aplicațiilor să fie acoperite într-un singur flux folosind tehnici bune de scriere a cazurilor de testare.
Sper că acest articol a fost util pentru a înțelege tehnica de testare a interoperabilității. Spuneți-ne întrebările / comentariile dvs.
Lectură recomandată
- Testarea funcțională Vs testarea non-funcțională
- Ghid de testare a securității aplicațiilor web
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Ghid de testare a portabilității cu exemple practice
- Testarea alfa și testarea beta (un ghid complet)
- Tipuri de testare software: diferite tipuri de testare cu detalii
- Ce este testarea localizării și testarea internaționalizării (ghid simplu)
- Descărcare eBook Descărcare Primer