Menú

Una guia senzilla per a les proves d’interoperabilitat (amb exemples)

simple guide interoperability testing

Proveu El Nostre Instrument Per Eliminar Problemes

Abans d 'entendre la tècnica de 'Proves d'interoperabilitat' , Primer entenem el terme 'Interoperabilitat'.

La interoperabilitat és la capacitat d’un sistema d’interactuar amb un altre sistema. Aquesta interacció es troba entre 2 sistemes diferents o 2 aplicacions diferents junts.

Moltes vegades es confon amb la interoperabilitat Integració , compatibilitat i portabilitat. Bé, hi ha diferències entre aquestes tècniques.

fitxers swf que no es reprodueixen al navegador

Què és la prova d’interoperabilitat

Començo per explicar les diferències.

Integració - És una tècnica quan els components del mateix sistema interactuen entre si. Per tant, en el món de les proves, quan fem proves d’integració, realment estem provant el comportament dels 2 o més nivells més baixos de components del mateix sistema.

Compatibilitat - És una tècnica mitjançant la qual 2 o més aplicacions interactuen en el mateix entorn. Així doncs, en el món de les proves, quan fem proves de compatibilitat; validem si dues o més aplicacions o sistemes es comporten com s’esperava en el mateix entorn.

La intenció aquí és comprovar que els dos sistemes realitzen les tasques esperades, sense interferir mútuament, en el mateix entorn. Igual que: MS Word i Calculator són 2 aplicacions diferents i realitzen el seu comportament esperat independentment en el mateix sistema operatiu. De manera que diem que aquestes 2 aplicacions són compatibles entre si.

Portabilitat - És una tècnica quan una aplicació o sistema es comporta com s’esperava quan es trasllada a un altre entorn. Així que dins Portabilitat provant, exportem l'aplicació a algun altre entorn i en provem el comportament. De la mateixa manera, si hi ha una aplicació que funciona bé a Windows XP, també hauria de funcionar bé a Windows 10.

Interoperabilitat - És una tècnica de com interactua una aplicació amb una altra aplicació. Per tant, quan fem les proves d’interoperabilitat, comprovem com les dades d’una aplicació es transfereixen a una altra aplicació sense indicació prèvia, d’una manera significativa, i es processen per donar la sortida acceptada.

Aquest article es centra en les proves d’interoperabilitat (IOT), per tant, mantenim el nostre enfocament en la interoperabilitat. :)

Què aprendreu:

Proves d’interoperabilitat: breu introducció

Interoperabilitat = Inter + operable

entre altres - significa 'entre nosaltres', 'dins de l'altre', 'mutu'

Operable - significa 'capaç de realitzar la tasca donada'

Combinant els dos termes: la interoperabilitat significa dos (o més) sistemes, capaços de realitzar la seva tasca assignada de manera independent i capaços de comunicar-se entre ells com s’esperava sense afectar la seva funcionalitat assignada individualment.

Exemple 1:Agafeu un exemple de reserva del vol. Penseu en la necessitat de viatjar de Nova Delhi a Nova York. Ara no teniu un vol directe. Cal viatjar de Nova Delhi a Londres i després agafar un vol de connexió de Londres a Nova York. Com que teniu algunes limitacions de temps, reserveu el vol de Nova Delhi a Londres a les línies aèries 'Jet Airways' i de Londres a Nova York a 'Virgin Atlantic'. Per tant, això significa que totes les dades del vostre passatger s'han recorregut des de Jet Airways fins a Virgin Atlantic. Així doncs, Jet Airways i Virgin Atlantic, tots dos són aplicacions independents juntes i, mentre es reserva el vol, les dades de la reserva s’han canviat de Jet Airways a Virgin Atlantic d’una manera significativa, sense cap tipus d’informació prèvia.

Exemple 2:En línies similars, penseu en el sistema d’administració de l’hospital, on els registres dels pacients s’intercanvien entre un departament i un altre. Per tant, aquí es pot enllaçar el departament amb una aplicació. Els detalls del pacient s’intercanvien entre una sol·licitud i una altra aplicació sense previ avís.

Llavors, per què hem de fer el IOT?

Hauríem de fer les proves d’interoperabilitat per assegurar-ho

  • Les aplicacions de la xarxa realitzen el seu comportament esperat de forma independent,
  • Pot intercanviar informació sense previ avís
  • La informació / dades s’intercanvia sense interrompre el comportament esperat individual
  • Les dades / informació que s’intercanvien no es modifiquen ni es modifiquen

Com es fan proves d’interoperabilitat?

Podem seguir la roda Deeming (el cicle PDCA) per dur a terme les proves d’interoperabilitat.

# 1) Pla

La planificació és la fase més important per determinar l'estratègia de fer gairebé qualsevol cosa en el desenvolupament de programari. Abans de planificar realment el procediment per fer el IOT, és imperatiu entendre totes les aplicacions o sistemes desplegats a la xarxa.

Hauríem de conèixer totes les aplicacions: la seva funcionalitat, comportament, entrada que necessita i sortida que revela.

També recomanaria que totes i cadascuna de les aplicacions es provessin completament de forma funcional sense defectes, abans de preparar-les per a les proves d’interoperabilitat. Per tant, quan planifiqueu, no penseu només en 1 o 2 aplicacions, penseu en totes les aplicacions com una sola unitat. Heu de tenir una vista d’ocell quan planifiqueu aquesta tècnica de proves. No cal dir-ho: documenteu el vostre pla.

Podem utilitzar el nostre document estàndard del pla de proves i adapteu-lo una mica segons el requisit de documentar la planificació de l'IOT. Un cop s'hagi establert el pla de prova, seguiu endavant per obtenir les condicions de prova.

El focus de derivació de la condició de prova no s’ha de limitar a les aplicacions individuals; en canvi, hauria de basar-se en el flux de dades a través de totes les aplicacions. Les condicions s'han de dissenyar de manera que es transmetin, si no totes, però la majoria de les aplicacions de la xarxa.

Un cop identificades les condicions de la prova, continueu amb el disseny o la seqüència de comandaments (per si teniu previst automatitzar) els casos de prova. Tu pots creeu un RTM (Matriu de traçabilitat de requisits) per assignar els casos de prova amb les condicions de prova i les condicions de prova amb les condicions / requisits de prova d’acceptació.

Quan treballeu en una xarxa, també és important planificar les activitats de proves no funcionals. És possible que això no s’escrigui ni es documenti en cap lloc, però és obligatori comprovar els aspectes no funcionals del sistema en general. Aquestes àrees no funcionals inclourien el rendiment i la seguretat. Si cal, podeu crear un pla separat per a proves funcionals, de rendiment i de seguretat; o bé creeu un pla únic i un document diferent de les condicions de la prova per a cadascun d’aquests tipus de proves.

# 2) Feu-ho

Fer: és el període de temps en què realitzeu la vostra execució. Planifiqueu el vostre temps en conseqüència per executar les proves funcionals i no funcionals. Seguim el cicle de proves en aquesta fase d’execució dels casos, registre dels defectes, seguiment amb l’equip de desenvolupament per solucionar-los, realització de la prova de regressió i de prova del sistema en general, reportant els resultats de la prova i traslladant-lo a tancament.

# 3) Comprovar

Comprova: és la fase en què tornem a revisar els resultats de les proves i intentem mapar els que tenen els RTM i validar si es compleixen tots els requisits esperats i si es recorren totes les aplicacions. Comprovem que les dades es transmeten i s’intercanvien correctament i sense problemes entre les aplicacions / sistemes. També hauríem de validar que les dades que es travessen no es modifiquin.

Penseu també en fer una retrospectiva de tot el procés de proves d’interoperabilitat. Identifiqueu les àrees que han funcionat bé, les que no han anat bé i els elements d’acció que cal tenir en compte.

# 4) Act

Act: Actua sobre els elements retrospectius. Els punts identificats com a 'bones pràctiques' continuen executant-los i els punts que es podrien treballar millor, identifiquen els passos per corregir-los i actuar en conseqüència. Tingueu en compte 1 cosa que les àrees o passos que no han funcionat bé, NO s'han de repetir. Al cap i a la fi, hauríem d’aprendre dels nostres errors i no repetir-los.

Els 5 passos i mig:

  1. Identifiqueu totes les aplicacions que formen part de la xarxa.
  2. Identifiqueu les seves respectives funcionalitats.
  3. Per a cada aplicació, identifiqueu l'entrada que necessita i la sortida que retorna.
  4. Identifiqueu les dades que travessarien totes / la majoria de les aplicacions.
  5. Identifiqueu el comportament esperat per a cada combinació d’aplicació i data que cal validar

½ Documenta'l.

Penseu en la figura següent:

5 passos i mig

Basant-nos en la figura, intentem replicar els passos de 5 ½:

  1. L'aplicació 1, l'aplicació 2, l'aplicació 3 i l'aplicació 4 són 4 sistemes diferents.
  2. Cadascun d'aquests sistemes té un conjunt definit de funcionalitats que cal identificar.
  3. Cal identificar les entrades i les sortides de cada sistema.
  4. En el cas de Application1, proporciona 2 sortides. La sortida 1 forma l'entrada de l'aplicació 3 i la sortida 1 forma l'entrada de l'aplicació 2. La sortida de l'aplicació 2 forma l'entrada de l'aplicació 3 i l'aplicació 4, etc.
  5. Es comprova la validesa de cadascuna de les entrades i sortides. El punt principal a considerar aquí és que les dades que es transiten en forma d’entrada i sortida no es modifiquen i es cobreix tota l’aplicació.

½ Aquesta xifra de la vida real pot no semblar tan senzilla. Això en realitat resulta en una estructura més complexa amb n nombres de condicions d’entrada i sortida.

Dibuixar aquest tipus de xifres donaria una imatge millor per identificar les dades i la informació que travessarien diferents sistemes. Això ens ajudaria a derivar les condicions i casos de la prova.

Un exemple:

Considerem un exemple de realització de proves d'interoperabilitat per a un 'sistema de gestió hospitalari'

Un hospital està format pels següents departaments i subdepartaments;

Sistema de gestió hospitalària

Aquí cada departament és una aplicació en si mateixa. Cada departament (aplicació) té el seu propi sub departament (mòduls) i cada mòdul té les seves pròpies unitats.

Així que ara, per considerar l’abast de l’IOT, aquí teniu algunes condicions de prova:

  1. Un pacient que es va trobar amb un accident de trànsit (Departament OPD - Accident), ha de sotmetre's a una cirurgia de cames (ORL - Cirurgia General), ha de sotmetre's a la fisioteràpia (Departament de suport - Fisioteràpia) i després es dóna d'alta (Departament de suport - Tancament)
  2. Un nen ingressat en atenció crítica (Pediatria - Atenció crítica) ha de passar per una cirurgia (Pediatria / ORL - Cirurgia general) i després és donat d’alta (Departament de Suport - Tancament / RP)
  3. Un pacient extern consulta un metge general (departament OPD); pren els medicaments prescrits (Departament de Suport - Farmàcia) i s’allunya.
  4. Una mare esperada ve a fer revisions periòdiques (Servei de ginecologia - Atenció a la mare i als fills), pren la medicació prescrita (Servei de suport - Farmàcia) i marxa.
  5. Un pacient dental fa el conducte radicular (departament d’odontologia), pren els medicaments prescrits (departament de suport - farmàcia) i s’allunya.
  6. Un pacient entra a l’OPD (metge general), se sotmet a un tractament a (Servei d’Obstetrícia i Ginecologia - Obstetrícia d’alt risc), pren la medicació prescrita (Servei d’assistència - Farmàcia) i és donat d’alta.

Així identifiquem totes les condicions de la prova; tenint en compte que cal cobrir la majoria del departament.

Podem dibuixar un RTM per mostrar la cobertura com:

RTM

D'aquesta manera, podem identificar més condicions de prova i dibuixar el RTM per veure el nostre abast exacte. També podem determinar la profunditat dels nostres esforços de prova basant-nos en el RTM.

Igual que en aquest exemple, veiem que el 'Departament d'assistència' és l'aplicació que és el punt de sortida de tota (la majoria) de l'aplicació, de manera que l'esforç de prova d'aquesta aplicació en particular és una mica més en comparació amb altres aplicacions.

Desafiaments:

  1. És difícil provar tota l'aplicació amb totes les permutacions i combinacions.
  2. Les aplicacions es desenvolupen en diferents combinacions de maquinari i programari i s’instal·len en entorns diferents, de manera que si algun entorn no funciona, afecta la prova.
  3. A causa dels diferents entorns i programari, determinar una estratègia de prova i executar-la és una tasca important.
  4. Estimular l’entorn per dur a terme la prova és un gran repte.
  5. En cas d’algun defecte, fer l’anàlisi de la causa arrel és un gran repte.
  6. Com que les aplicacions estan en xarxa, hi hauria moments en què la xarxa està inactiva. Per això, les proves també es veuen afectades.

Com puc mitigar aquests reptes?

1) Proveu d’utilitzar tècniques de proves avançades com:

  • OATS (tècnica de proves de matriu ortogonal)
  • Diagrames de transició estatal,
  • Gràfics de causa i efecte
  • Porcionament d'equivalència i anàlisi del valor límit.

Aquestes tècniques us ajudaran a identificar la interdependència entre l’aplicació i a identificar els casos / condicions de prova que assegurarien la màxima cobertura.

2) Intenteu identificar algunes dades històriques, com ara: en quines circumstàncies els sistemes no funcionaven, quant de temps es necessita per tornar a l’acció. En aquest cas, intenteu executar aquells escenaris que no afecten les aplicacions o utilitzeu el temps per documentar els escenaris i informar dels resultats. A més, sempre que planifiqueu o planifiqueu les proves, tingueu sempre en compte aquestes dades històriques com a aportació per a la vostra estimació i planifiqueu-les en conseqüència.

3) PLA - Utilitzeu dades històriques, experiències passades, habilitat de l’equip, factors ambientals per identificar l’estratègia de les proves. Com millor sigui el vostre pla, millor seria la vostra execució.

4) Comenceu a treballar per preparar l'entorn molt abans que comenci la vostra execució real. No cal dir: planifiqueu els passos quan esteu preparant l’entorn. Assegureu-vos que el vostre entorn estigui tot preparat, llest i en marxa quan comenci la vostra execució.

5) Abans de començar amb el IOT, assegureu-vos que les aplicacions individuals siguin completament provades funcionalment sense defectes. Aleshores, en cas de defecte, només haureu de buscar els factors ambientals que han provocat algun error.

6) Tal com es comenta al punt 2, planifiqueu la vostra activitat. Si es tracta d’una interrupció programada, hauríeu de tenir en compte aquest temps d’aturada quan planifiqueu la prova.

Prova d'interoperabilitat en mòbils:

A Mòbils, fem proves d’interoperabilitat sempre que una nova aplicació ( Aplicació mòbil ) es llança. Hi ha moltes àrees que hem de tenir en compte a l’hora de planificar aquesta prova en dispositius mòbils:

  • Els tipus de dispositius mòbils disponibles al mercat són enormes. Hauríeu d’enumerar quins tipus de dispositius teniu en compte per a les proves. Haureu d’aparellar un tipus de dispositiu juntament amb el SO que admet.
  • Tots els sistemes operatius mòbils es desenvolupen en diferents llenguatges de programació. Per tant, cal provar l’aplicació amb totes les variacions del sistema operatiu.
  • Conèixer els factors legals i els contractes relacionats amb la regió.
  • La mida / resolució dels diferents dispositius són diferents.
  • També cal tenir en compte l’impacte en les aplicacions integrades per a mòbils.

Per tant, per fer IOT en mòbils, necessitareu planificar i crear un RTM tal com ho vam fer per a una prova d'aplicació basada en ordinador.

La intenció, l'estratègia, els riscos i l'execució serien la mateixa, però la mateixa eines i tècniques seria diferent en el cas dels mòbils.

Conclusió:

Les proves d’interoperabilitat són una tasca enorme. Aquesta tècnica requereix una planificació adequada que hauria de començar en paral·lel quan s’iniciï la planificació de les proves del sistema.

Hi ha molts factors que cal tenir en compte a l’hora d’executar aquesta tècnica. Tingueu en compte que disposeu de temps suficient per corregir i tornar a provar els errors, ja que es tracta d’un esforç enorme que s’hauria de preveure per fer un seguiment dels defectes.

Això pot passar si no pot assolir el 100% cobertura , però hauríem de ser prou intel·ligents per seleccionar els nostres casos de manera que la majoria de les aplicacions es cobreixin en un sol flux mitjançant l'ús de bones tècniques d'escriptura de casos.

Espero que aquest article sigui útil per entendre la tècnica de proves d’interoperabilitat. Feu-nos saber les vostres consultes / comentaris.

Lectura recomanada

^