system testing vs end end testing
Una visió general de Proves del sistema i proves de punta a punta:
Les proves de punta a punta i les proves del sistema sempre van de la mà, però fins i tot un professional experimentat de les proves pot confondre’s sobre els enormes avantatges que ofereixen cadascun i triar-ne només un.
En aquest article, intentarem debatre entre les proves de punta a punta i les de sistema. Per comprendre la diferència entre això, primer entendrem quines són les diferents etapes que travessa qualsevol producte en desenvolupament.
A la indústria del programari, sempre estem en el dilema d’escollir entre una versió més ràpida i una versió de qualitat, però sempre hi ha un bon equilibri entre elles. Tots esperem velocitat i qualitat alhora, que és força més dura.
Què aprendreu:
- Vida d'un producte de programari en prova
- Què és la prova del sistema?
- Per què és important la prova del sistema?
- Quan iniciar les proves del sistema?
- Què són les proves de punta a punta?
- Per què és important la prova de punta a punta?
- Quan iniciar les proves de final a final?
- Diferència entre la prova del sistema i la prova de punta a punta
- Proves del sistema o proves de punta a punta o ambdues coses?
- Conclusió
- Lectura recomanada
Vida d'un producte de programari en prova
El cicle de vida d’un producte s’inicia un cop s’obtenen els requisits empresarials del client. L’equip en qüestió que n’és responsable en farà una anàlisi exhaustiva i en dissenyarà les especificacions tècniques.
Aquestes especificacions ajudaran els tècnics o desenvolupadors a iniciar el seu treball en el desenvolupament de programari. A continuació s’expliquen els passos que s’inclouen aquí per facilitar-ne la comprensió.
Pas 1: Basat en la descripció del producte d’alt nivell, un producte de programari es classifica en diferents mòduls i després en components o unitats. Aquestes unitats es desenvolupen de forma independent perquè el seu desenvolupament pugui continuar en paral·lel mitjançant la participació de diversos desenvolupadors.
Un cop desenvolupades, aquestes unitats es posen a prova individualment, que passaran a la prova unitària.
Pas 2: La validació individual garanteix que totes les unitats d’un sistema funcionin com s’esperava tant per motius funcionals com de viabilitat. Aquests components, mòduls o subsistemes s’integren amb el següent nivell i després es posen a prova com a unitat integrada a les proves d’integració.
Pas 3: Les proves del sistema apareixen en aquest pas en què el producte integrat es provaria per primera vegada en un entorn de pseudo-producció. Aquest nivell de proves es realitza per comprovar el compliment de requisits empresarials tant funcionals com no funcionals.
Pas 4: Es tracta d’un nivell de proves que es realitza per a l’acceptabilitat del client i, per tant, anomenat Prova d’acceptació. Això es realitzarà just abans de gestionar el programari al client, que és l'entorn de producció.
Què és la prova del sistema?
Proves del sistema és una cosa que es fa després de la prova d’integració i abans de la prova d’acceptació de qualsevol maquinari o programari disponible.
Les proves del sistema es realitzen per analitzar la coordinació dels components adjunts com un sol sistema per tal de garantir si compleix o no els estàndards de qualitat. L’objectiu principal és detectar els defectes dins dels muntatges mitjançant la realització de proves funcionals i no funcionals al producte integrat.
Es realitzen proves no funcionals per assegurar si el producte en desenvolupament s’adaptarà o no a les expectatives del negoci. Es realitzen per determinar el temps de resposta d’una aplicació o per comprovar la compatibilitat o manipulació de la instal·lació, el rendiment, la regressió, l’escalabilitat, la seguretat i algunes altres àrees.
Per tant, una aplicació ha d’esborrar tant els nivells funcionals com els no funcionals per assegurar-se que si compleix els estàndards del mercat, pot espatllar la reputació de l’empresa.
Permeteu-me explicar amb l'ajut d'un exemple d'una aplicació mòbil de reserva de taxi com Uber:
Uber ofereix la possibilitat de reservar cabines en línia i disposa de diversos mòduls com el seguiment de la ubicació, passarel·les de pagament, tarifa de la cabina i perfils de conductor que es poden provar independentment com a part de les proves d’unitats .
Un cop aquests mòduls funcionen de forma independent, s’integren per provar i assegurar-se si treballen entre si Proves d'integració.
A més, els requisits del client es començaran a validar només a les proves del sistema, com si el client pot trobar un taxi més proper a la seva ubicació o si pot fer el pagament a Uber mitjançant les seves formes de pagament, etc.
La validació d’aquests escenaris es descriu a Proves del sistema .
Per què és important la prova del sistema?
Cal fer proves del sistema, ja que els desenvolupadors / verificadors han de comprovar els pocs aspectes abans de passar al següent nivell.
Pocs aspectes inclouen:
- Cal estar segur del funcionament del programari com a unitat.
- Cal comprovar si un producte no omet cap requisit funcional i no funcional.
- Necessita provar el producte en un entorn similar a la producció.
- Cal comprovar el producte amb dades similars a la producció.
Les proves del sistema inclouen escenaris basats en riscos empresarials, casos d’ús o descripció d’alt nivell del comportament del producte. Els casos relacionats amb interaccions amb diferents recursos del sistema també haurien de formar part de les proves del sistema.
Per tant, hauria de ser conduït per algú que tingui un coneixement complet del producte requerit, tant a nivell d’arquitectura com de negoci. No es requereixen coneixements interns a nivell de codificació, però el coneixement del sistema és obligatori per al verificador.
En general, s’assignaria un equip separat amb la tasca de proves de sistema i l’equip dissenyarà els seus propis plans de proves del sistema i casos de proves del sistema, que seran diferents dels realitzats anteriorment en termes de cobertura de les proves. Si cal, es poden realitzar diverses iteracions de proves del sistema en diversos entorns.
Quan iniciar les proves del sistema?
Les proves del sistema es poden iniciar quan:
- Les proves d’unitats s’han tancat amb èxit per a totes les unitats sense cap defecte obert.
- Tots els components provats per unitat s’integren bé i les proves d’integració s’han realitzat amb èxit.
- Hi ha disponible un entorn de pseudo-producció per provar el producte del sistema.
- System Tester és conscient de totes les entrades / sortides del sistema i està preparat amb els artefactes de prova.
Què són les proves de punta a punta?
La prova d’un programari és un paràmetre important de la garantia de qualitat del programari. Un producte de bona qualitat sempre proporciona un nivell de satisfacció més elevat tant als inventors com al comprador. Dit d'una altra manera, un producte qualificat o premium és el resultat d'una regressió completa i l'eliminació del defecte a tots els nivells.
Com s’explica pel propi nom, proves de punta a punta és un dels nivells de prova en què es prova un flux d'aplicació juntament amb els sistemes dependents. Això es fa per garantir una interacció fluida amb les aplicacions de backend i front-end com ara bases de dades o interfície gràfica d’usuari que utilitzen canals de xarxa i, per tant, s’anomena Prova de cadena també.
A diferència de la prova del sistema, la prova de la interfície d'usuari no té cap paper significatiu aquí, però la comprovació es basa en les dades subjacents que posen la interfície en mode de funcionament. Les proves de punta a punta se solen realitzar una vegada que el producte compleix les proves de sistema.
Continuant amb el nostre exemple d’Uber en la fase de proves d’extrem a extrem, validarem el viatge complet del client
Obrir l’aplicació al mòbil de l’usuari -> trobar una cabina per a la destinació introduïda -> Fer un seguiment de la cabina abans o durant el viatge -> completar el trajecte i pagar mitjançant una de les opcions de pagament -> finalment ingressar el compte del conductor
Executar aquest flux d’extrem a extrem garanteix que el client pugui satisfer les seves necessitats. Aquestes proves són importants per identificar els problemes d’experiència del client, especialment relacionats amb la combinació de múltiples sistemes.
Per què és important la prova de punta a punta?
Les proves d’extrem a extrem juguen un paper important quan el producte desenvolupat ha de ser un sistema distribuït i ha de funcionar col·lectivament amb els altres sistemes en diversos entorns. En aquests casos, es requereix una comprovació de 360 graus per garantir una interacció precisa entre diferents plataformes i entorns.
Els principals objectius de les proves extremes inclouen:
que és el millor proveïdor de correu electrònic
- Per assegurar-nos que el producte desenvolupat estigui ben coordinat amb qualsevol dels seus subsistemes, que poden ser propietat o no de nosaltres.
- Per comprovar tots els fluxos de sistemes des dels sistemes origen als sistemes de destinació.
- Per validar els requisits des de la perspectiva de l'usuari final.
- Identificar problemes en entorns heterogenis.
Si cal, s'han de fer proves repetibles per comprovar la salut de l'aplicació. De vegades es pot produir una situació en què veiem un conflicte entre el desenvolupador i el comprovador perquè entenem les àrees d'aplicació afectades a causa de canvis menors de codi.
Els desenvolupadors podrien pensar que el canvi és mínim, però aquesta evolució és prou significativa per tornar a executar els escenaris de prova de punta a punta per a un sistema complet. Tanmateix, això pot augmentar les dates de lliurament i també pot augmentar els costos.
Quan iniciar les proves de final a final?
Normalment es realitzen proves de punta a punta.
- Un cop un producte compleixi les proves de sistema, es tractaran tots els aspectes funcionals.
- Quan els entorns dependents estan identificats i disponibles per dur a terme l'execució del nivell de flux.
- Quan un provador està equipat amb els coneixements necessaris i els artefactes de prova.
- Quan el provador disposa de les eines adequades per analitzar el flux de dades.
Diferència entre la prova del sistema i la prova de punta a punta
A continuació, es mostren algunes diferències entre la prova del sistema i la prova completa:
| Proves del sistema | Prova de punta a punta |
|---|---|
| El producte desenvolupat es prova amb els requisits tècnics específics del producte identificats en funció dels requisits empresarials. | El producte desenvolupat es prova juntament amb sistemes dependents segons els requisits empresarials. |
| Cobreix aspectes funcionals i no funcionals de les proves. | Cobreix els nivells d'interfície de proves tenint en compte tots els sistemes d'origen i de destinació. |
| Realitzat cap al final del cicle de vida del desenvolupament de programari. | Es realitza un cop el producte compleix les proves d'integració. |
| Es revisarien totes les funcions implementades per al producte per descobrir resultats inesperats. | Es comprovaran els fluxos de procés juntament amb els sistemes de portada i backend i de nivell mitjà. |
| El comprovador hauria de comprendre bé la funcionalitat del producte desenvolupat. | El comprovador hauria de comprendre bé els fluxos de dades i els fluxos de treball dins del sistema. |
| El comprovador de sistemes no necessita preocupar-se per les etapes del cicle de vida del desenvolupament del producte. | El comprovador complet ha de comprendre totes les etapes. |
Proves del sistema o proves de punta a punta o ambdues coses?
Sovint es considera que les proves de sistema i les proves de punta a punta són iguals, però això no és cert. Tots dos són diferents formes de proves amb una cobertura de prova diferent.
Mentre que les proves d’extrem a extrem comproven un flux d’activitats des de zero fins al final del sistema que cobreix tots els sistemes dependents, les proves de sistema comprovaran la mateixa funcionalitat amb un conjunt d’entrades diferent per avaluar la resposta.
Per tant, el cobertura de la prova per a tots dos, els tipus de proves seran diferents.
Conclusió
Un provador de sistemes ha de tenir la mentalitat d’usuaris reals, mentre que un provador de punta a punta ha d’entendre per igual els sistemes de pujada i de pujada.
Com s'ha explicat anteriorment, els dos tipus de proves tenen la mateixa importància en el cicle de desenvolupament de productes i, per tant, són necessaris per descobrir els defectes de diferents categories.
Espero que tingueu una idea clara de quines proves opteu? Mentrestant, no dubteu a compartir les vostres experiències a la secció de comentaris següent.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Prova de descàrrega de llibres electrònics
- Proves alfa i proves beta (guia completa)
- Proves funcionals contra proves no funcionals
- Prova de càrrega amb tutorials HP LoadRunner
- Diferència entre la prova d'escriptori, el servidor de clients i la prova web
- Què és la prova de gamma? Fase de proves finals
- Guia completa de proves de verificació de compilació (proves BVT)