Menú

Què és la prova de punta a punta: Marc de proves E2E amb exemples

what is end end testing

Proveu El Nostre Instrument Per Eliminar Problemes

Què és la prova de punta a punta: Marc de proves E2E amb exemples

Les proves d'extrem a extrem són una metodologia de proves de programari per provar un flux d'aplicació de principi a fi. L’objectiu de les proves d’extrem a extrem és simular l’escenari real de l’usuari i validar el sistema que es prova i els seus components per a la integració i la integritat de les dades.

Ningú vol ser conegut pels seus errors i la seva negligència, i el mateix passa amb els Testers. Quan els provadors tenen assignada una aplicació per provar, a partir d’aquest moment, assumeixen la responsabilitat i l’aplicació també actua com a plataforma per mostrar els seus coneixements de proves pràctiques i tècniques.

Per tant, per descriure-ho tècnicament, per assegurar-vos que les proves es realitzen completament, cal realitzar ' Proves d'extrem a extrem ' .

què és la prova de punta a punta

En aquest tutorial, aprendrem què és la prova d’extrem a extrem, com es fa, per què és necessari, quines són les matrius que s’utilitzen, com crear un extrem per acabar casos de proves específics i alguns altres aspectes importants també. També coneixerem la prova del sistema i la compararem amb la prova de punta a punta.

Real també => Entrenament d’extrem a extrem en un projecte en viu: formació en línia gratuïta de control de qualitat

Què aprendreu:

c ++ data i hora

Què és la prova de punta a punta?

procés de prova de punta a punta

Les proves d'extrem a extrem són una metodologia de proves de programari per provar un flux d'aplicació de principi a fi. L’objectiu d’aquestes proves és simular l’escenari real de l’usuari i validar el sistema que s’està provant i els seus components per a la integració i integritat de les dades.

Es realitza de principi a fi sota escenaris del món real com la comunicació de l’aplicació amb maquinari, xarxa, base de dades i altres aplicacions.

El motiu principal per dur a terme aquestes proves és determinar diverses dependències d'una aplicació, així com assegurar-se que es comunica informació precisa entre diversos components del sistema. Normalment es realitza després de completar les proves funcionals i del sistema de qualsevol aplicació.

Prenguem un exemple de Gmail:

exemple de prova de punta a punta

La verificació de cap a cap d’un compte de Gmail inclourà els passos següents:

  1. Llançament d'una pàgina d'inici de sessió de Gmail mitjançant URL.
  2. Iniciar sessió al compte de Gmail mitjançant credencials vàlides.
  3. Accedint a la safata d’entrada. Obertura de correus electrònics llegits i no llegits.
  4. Redactant un correu electrònic nou, responeu o reenvieu un correu electrònic.
  5. Obrir els elements enviats i comprovar els correus electrònics.
  6. Comprovació de correus electrònics a la carpeta Correu brossa
  7. Com tancar la sessió de l'aplicació Gmail fent clic a 'tancar sessió'

Eines de prova de punta a punta

Eina recomanada:

# 1) TestCraft

Logotip de TestCraft nou
Us recomanem que utilitzeu una eina d’automatització de proves de punta a punta com TestCraft.

TestCraft és una plataforma automatitzada de proves de seleni sense codi. La seva revolucionària tecnologia d’IA i el modelatge visual únic permeten la creació i execució de proves més ràpides alhora que eliminen els costos generals de manteniment de les proves.

Els provadors creen escenaris de prova totalment automatitzats sense codificar. Els clients troben els errors més ràpidament, publiquen amb més freqüència, s’integren amb l’enfocament CI / CD i milloren la qualitat general dels seus productes digitals. Tot això està creant una experiència completa de proves de punta a punta.

=> Visiteu el lloc web TestCraft

Com funciona la prova de punta a punta?

Per entendre una mica més, anem a saber-ho Com funciona?

Prengui unexemplede la indústria bancària. Pocs de nosaltres devíem haver provat Existències. Quan un titular del compte Demat compra qualsevol acció, s’ha de lliurar al corredor un percentatge particular d’una quantitat. Quan l’accionista ven aquesta acció, tant si obté guanys com si hi ha pèrdues, es torna a donar al corredor un percentatge particular de l’import. Totes aquestes transaccions es reflecteixen i es gestionen en comptes. Tot el procés implica la gestió de riscos.

Quan examinem l’exemple anterior, tenint present la prova de punta a punta, ens trobarem amb que tot el procés inclou múltiples nombres i diferents nivells de transaccions. Tot el procés implica molts sistemes que poden ser difícils de provar.

Mètodes de prova E2E

# 1) Prova horitzontal:

Aquest mètode s’utilitza amb molta freqüència. Es produeix horitzontalment en el context de múltiples aplicacions. Aquest mètode es pot produir fàcilment en una sola aplicació ERP (Enterprise Resource Planning). Preneu un exemple d'una aplicació basada en web d'un sistema de comandes en línia. Tot el procés inclourà comptes, estat d’inventari dels productes, així com detalls d’enviament.

# 2) Prova vertical:

En aquest mètode, totes les transaccions de qualsevol aplicació es verificen i avaluen des del principi fins al final. Cada capa individual de l'aplicació es prova començant de dalt a baix. Preneu un exemple d’una aplicació basada en web que utilitza codis HTML per arribar als servidors web. En aquests casos, cal API per generar codis SQL contra la base de dades. Tots aquests escenaris informàtics complexos requeriran una validació adequada i proves dedicades. Per tant, aquest mètode és molt més difícil.

' Proves de caixa blanca ' així com ' Proves de caixa negra ' tots dos estan associats amb aquesta prova. O en altres paraules, podem dir, aquesta és la combinació de beneficis tant de les proves de caixa blanca com de les proves de caixa negra. Depenent del tipus de programari que es desenvolupi, a diferents nivells, tant les tècniques de prova, és a dir, les proves de caixa blanca com de caixa negra s’utilitzen quan i quan es requereixin. Bàsicament, la prova End to End realitza un enfocament funcional i arquitectònic per a qualsevol programari o programa per validar les funcions del sistema.

Els provadors com la verificació d’extrem a extrem perquè escriure casos de prova des de l’usuari ' La perspectiva i, en un escenari del món real, pot evitar els dos errors comuns, és a dir. ' falta un error ' i ' escrivint casos de prova que no verificen escenaris del món real ' . Això proporciona als provadors un immens sentit de la realització.

A continuació, es detallen algunes de les directrius que cal tenir en compte durant el disseny dels casos de prova per realitzar aquest tipus de proves:

  • Els casos de prova s’han de dissenyar des de la perspectiva de l’usuari final.
  • Hauria de centrar-se en provar algunes funcions existents del sistema.
  • S'han de tenir en compte diversos escenaris per crear diversos casos de prova.
  • S’han de crear diferents conjunts de casos de prova per centrar-se en múltiples escenaris del sistema.

A mesura que executem qualsevol cas de prova, és similar el cas d’aquestes proves. Si els casos de prova són 'Passa', és a dir, obtenim la sortida esperada, es diu que el sistema ha superat amb èxit la prova de final a final. De la mateixa manera, si el sistema no produeix la sortida desitjada, caldrà tornar a provar un cas de prova tenint en compte les zones de fallada.

Per què realitzem proves E2E?

En l’escenari actual, com també es mostra al diagrama anterior, un sistema de programari modern comprèn la seva interconnexió amb diversos subsistemes. Això ha fet que els sistemes de programari moderns siguin molt complicats.

Aquests subsistemes dels quals parlem poden estar dins de la mateixa organització o, en molts casos, també poden pertànyer a organitzacions diferents. A més, aquests subsistemes poden ser una mica similars o diferents del sistema actual. Com a resultat, si hi ha algun error o fallada en qualsevol subsistema, pot afectar negativament tot el sistema de programari i provocar el seu col·lapse.

Aquests principals riscos es poden evitar i es poden controlar mitjançant aquest tipus de proves:

  • Feu una comprovació i realitzeu la verificació del flux del sistema.
  • Augmenteu les àrees de cobertura de proves de tots els subsistemes implicats amb el sistema de programari.
  • Detecta problemes, si n’hi ha, amb els subsistemes i, per tant, augmenten la productivitat de tot el sistema de programari.

A continuació s'esmenten els fitxers poques activitats que s'inclouen al final del procés:

  • Un estudi exhaustiu dels requisits per realitzar aquesta prova.
  • Propi configuració d’entorns de prova.
  • Un estudi exhaustiu dels requisits de maquinari i programari.
  • Descripcions de tots els subsistemes, així com del sistema de programari principal implicat.
  • Indiqueu les funcions i responsabilitats de tots els sistemes i subsistemes implicats.
  • Els mètodes de prova utilitzats en aquesta prova, així com les normes que se segueixen, la seva descripció.
  • Disseny de casos de prova, així com el seguiment de la matriu de requisits.
  • Enregistreu o deseu les dades d'entrada i sortida de cada sistema.

Marc de disseny de proves E2E

Prova de punta a punta-4

Analitzarem les tres categories una per una:

# 1) Funcions de l'usuari: Les accions següents s'han de realitzar com a part de la creació de funcions d'usuari:

  • Característiques del llistat dels sistemes de programari i dels seus subsistemes interconnectats.
  • Per a qualsevol funció, feu un seguiment de les accions realitzades, així com de les dades d’entrada i sortida.
  • Cerqueu les relacions, si hi ha, entre diferents funcions dels usuaris.
  • Esbrineu la naturalesa de les diferents funcions de l'usuari, és a dir. si són independents o són reutilitzables.

# 2) Condicions: Les activitats següents s'han de realitzar com a part de les condicions de construcció basades en les funcions de l'usuari:

  • Per a totes i cadascuna de les funcions de l'usuari, s'hauria de preparar un conjunt de condicions.
  • El temps, les condicions de les dades i altres factors que afecten les funcions de l'usuari es poden considerar com a paràmetres.

# 3) Casos de prova: S’han de tenir en compte els següents factors per construir casos de proves:

  • Per a cada escenari, s'haurien de crear un o més casos de prova per provar totes i cadascuna de les funcions de les funcions de l'usuari.
  • Totes les afeccions haurien de figurar com un cas de prova independent.

Mètriques implicades

Passar a les properes activitats o mètriques importants implicades en aquesta prova :

  1. Estat de la preparació del cas de prova: Es pot fer un seguiment en forma de gràfic per representar el progrés dels casos de prova previstos que estan en preparació.
  2. Seguiment setmanal del progrés de la prova: Això inclou la representació setmanal del progrés de l'execució dels casos de prova. Es pot reflectir a través de la representació percentual de casos passats, fallats, executats, no executats, no vàlids, etc.
  3. Estat i informe detallat dels defectes: L'informe d'estat s'hauria de preparar diàriament per mostrar l'estat d'execució del cas de prova, així com els defectes trobats i registrats segons la seva gravetat. Setmanalment s’ha de calcular el percentatge de defectes oberts i tancats. A més, segons la gravetat i la prioritat dels defectes, s’hauria de fer un seguiment setmanal de l’estat dels defectes.
  4. Entorn de prova: D’aquesta manera es fa un seguiment de la durada del temps de l’entorn de prova assignat, així com del temps de l’entorn de prova realment utilitzat durant la realització d’aquestes proves.

Quasi hem vist tots els aspectes d’aquestes proves. Ara deixem-ho diferenciar ' Proves del sistema ' i ' Proves d'extrem a extrem ' . Abans, però, deixeu-me fer-vos una idea bàsica de 'Prova del sistema' per tal de diferenciar fàcilment les dues formes de proves de programari .

Proves del sistema és la forma de proves que inclou una sèrie de proves diferents que tenen com a finalitat realitzar les proves completes del sistema integrat. La prova de sistemes és bàsicament una forma de prova de caixa negra on es centra el funcionament extern dels sistemes de programari des del punt de vista de l'usuari, tenint en compte les condicions del món real.

La prova del sistema implica:

  • Prova d'una aplicació totalment integrada que inclou el sistema principal.
  • Determineu que els components interactuen entre si i dins del sistema.
  • Verifiqueu la sortida desitjada sobre la base de l'entrada proporcionada.
  • Analitzar l’experiència de l’usuari mentre s’utilitzen diversos aspectes de l’aplicació.

Més amunt hem vist la descripció bàsica de les proves del sistema per entendre-la. Ara, analitzarem les diferències entre 'Prova del sistema' i 'Prova de punta a punta'.

S.No.Prova de punta a puntaProves del sistema
1Valida tant el sistema principal de programari com tots els subsistemes interconnectats.Segons les especificacions proporcionades al document de requisits, només valida el sistema de programari.
2El principal èmfasi és verificar el flux del procés de proves de punta a punta.L'èmfasi principal està en la verificació i comprovació de les funcions i funcionalitats del sistema de programari.
3Mentre es realitzen les proves, es tenen en compte totes les interfícies, inclosos els processos d’interfície del sistema de programari.Mentre es realitzen les proves, només es tenen en compte les àrees funcionals i no funcionals i les seves característiques.
4La prova de punta a punta s'executa / realitza després de completar la prova del sistema de qualsevol sistema de programari.Les proves del sistema es realitzen bàsicament després de completar les proves d’integració del sistema de programari.
5Les proves manuals són preferides principalment per realitzar proves finals, ja que aquestes formes de prova també impliquen proves d’interfícies externes, que a vegades poden ser molt difícils d’automatitzar. I farà que tot el procés sigui molt complex.Tant les proves manuals com les d’automatització es poden realitzar com a part de les proves del sistema.

Conclusió

Espero que hagueu après diversos aspectes de les proves d’extrem a extrem, com ara els seus processos, mètriques i la diferència entre les proves del sistema i les proves d’extrem a extrem.

Per a qualsevol versió comercial del programari, la verificació d’extrem a extrem juga un paper important ja que prova tota l’aplicació en un entorn que imita exactament els usuaris del món real com la comunicació de xarxa, la interacció amb bases de dades, etc.

Majoritàriament, la prova final a la finalització es realitza manualment, ja que el cost d’automatitzar aquests casos de prova és massa elevat per poder ser assumit per totes les organitzacions. Això no només és beneficiós per a la validació del sistema, sinó que també es pot considerar útil per provar la integració externa.

Feu-nos saber si teniu cap pregunta sobre la prova completa.

Lectura recomanada

^