functional testing vs performance testing
Proves funcionals i proves de rendiment:
Diferències entre Proves de rendiment, proves de càrrega i proves d’esforç es van explicar amb exemples al nostre últim tutorial.
Les proves de programari cobreixen una àmplia gamma d'àrees on es pot produir qualsevol verificació o validació de la funcionalitat del programari. Ocasionalment, els aspectes no funcionals esdevenen menys relatius als aspectes funcionals. No es realitzen pràcticament; simultàniament durant les proves de programari.
=> Feu clic aquí per obtenir una sèrie completa de tutorials de proves de rendiment
Aquest article explica els avantatges afegits de la qualitat del producte de programari durant diversos escenaris del cicle de vida de les proves de programari quan tant funcionals com no funcionals es prenen simultàniament.
Què aprendreu:
- Diferència ràpida entre les proves de rendiment i les proves funcionals
- Per què s’han de fer proves funcionals i de rendiment simultàniament?
- Estudi de casos
- Conclusió
- Lectura recomanada
Diferència ràpida entre les proves de rendiment i les proves funcionals
| Sl NO | Proves funcionals | Proves de rendiment |
|---|---|---|
| 1 | Per verificar la precisió del programari amb entrades definides enfront de la sortida esperada | Verificar el comportament del sistema en diverses condicions de càrrega |
| 2 | Pot ser manual o automatitzada | Es pot realitzar eficaçment si està automatitzat |
| 3 | Un usuari que realitza totes les operacions | Diversos usuaris realitzen les operacions desitjades |
| 4 | Cal implicació del client, del comprovador i del desenvolupador | Es requereix la participació de l’equip de gestió de clients, provadors, desenvolupadors, DBA i N / N |
| 5 | L’entorn de prova de mida de producció no és obligatori i els requisits H / W són mínims | Requies properes a l'entorn de proves de producció i diverses instal·lacions d'alta definició per omplir la càrrega |
Per què s’han de fer proves funcionals i de rendiment simultàniament?
Les proves funcionals esdevenen molt més importants per a qualsevol versió prèvia de programari. Basat en resultats reals verificació i validació a l'entorn de producció o de prova replicat és on solen passar les proves.
La fuga de defectes pot esdevenir un dels problemes més importants:
Els provadors tenen més responsabilitat que els desenvolupadors quant a la qualitat del producte. Bàsicament, no volen que el producte provat tingui defectes. En general, els provadors solen realitzar proves funcionals per aconseguir-ho.
El següent és una conversa entreGestor de proves i un provador :
(El gestor de proves es coneix com a 'TM' i el provador com a 'TR')
TM : Ei amic ... Com estem fent les proves del producte 'A'?
TR : Sí ... Estem avançant d'una manera més gran.
TM : És fantàstic ... I quin és el nostre abast en termes de proves de rendiment mentre les proves funcionals estan en execució?
TR : No els estem cobrint, se suposa que els nostres lliuraments només es troben a l'àrea funcional i no a l'àrea no funcional. A més, l’entorn de prova que fem servir no és una rèplica exacta de la producció.
Hi ha algunes preguntes de la conversa anterior que cal tenir en compte:
- Les proves funcionals tenen un factor dependent del rendiment?
- Què passa si el rendiment del programari es deteriora, però el lliurament del producte es produeix sense comprovar-ne el rendiment?
- Proves de rendiment: coexisteix dins del procés de proves funcionals?
S’ha convertit en una pràctica general per als verificadors que no treballin els aspectes no funcionals tret que se’ls demani que ho facin. És habitual evitar-ho proves no funcionals fins que el client hagi informat de problemes relacionats amb el rendiment del programari que es prova.
Per tant, hi ha dues preguntes que cal tenir en compte:
- Rendiment: afecta les proves funcionals?
- Mantenim les proves de rendiment com a lliurament independent, fins i tot si preocupa el client?
Les proves de rendiment són important !
com obtenir un correu electrònic fals
El programari funciona basat en diverses arquitectures i models següents, inclosos:
- Models de resposta necessaris
- Sistemes basats en transaccions
- Sistemes basats en càrrega
- Sistemes basats en la replicació de dades
El comportament de les proves funcionals del model sistemàtic esmentat anteriorment depèn del rendiment del sistema.
El punt de vista de l’automatització requereix molta atenció a les proves de rendiment.
El següent és una conversa entreclient i el gestor de proves.
(El client es coneix com a 'CL' i el gestor de proves com a 'TM')
CL : Per tant, arribant a la solució que hem demanat, espero que hi hagi diverses iteracions de les proves que s'estan realitzant actualment.
TM : Sí, això es pot fer. Com heu dit, hi haurà una probabilitat més alta de les proves iteratives, voldríem proposar una automatització per fer front a les proves funcionals (de regressió).
CL : D'acord, envieu-nos el vostre plantejament perquè puguem aprovar-ho. L’automatització tindrà una producció molt superior amb un esforç mínim.
TM : Exactament. Treballarem l’enfocament i us respondrem amb una prova de concepte.
De la conversa anterior, queda clar que la necessitat dels clients és optimitzar l’eficiència.
Estudi de casos
L'empresa ABC treballa en un projecte per al desenvolupament de programari A. L'empresa XYZ la realitza per provar el programari A.
El contracte de la companyia ABC i XYZ té algunes restriccions per a la seva col·laboració. Qualsevol discussió entre les dues empreses ha de tenir lloc una vegada a la setmana o tres cops al mes. El sistema funciona amb un model de mode de sol·licitud-resposta. L'empresa ABC ha completat la fase de desenvolupament.
Ara és el moment perquè l’empresa XYZ realitzi les proves funcionals formals del programari A. XYZ comença a treballar en les proves del programari A. Han donat una informació neta al programari i han donat el ‘Go’ per a la implementació en directe després de 2 cicles de proves.
Tot i el certificat de qualitat de l'equip de proves, la implementació en directe no ha anat bé. Hi havia molts errors de postproducció. Hi va haver un gran nombre de problemes als quals es van enfrontar els clients, inclòs un trencament de la funcionalitat per als processos comercials d'extrem a extrem.
Llavors, què és elproblema?
- És un problema amb una restricció a la col·laboració entre l'equip de desenvolupament i proves?
- És que els requisits no es van capturar al 100%?
- És que el producte no s'ha provat en un entorn de prova adequat?
- O alguna altra causa?
Després d 'una acurada investigació i anàlisi, eles van inferir els següents:
- Hi havia poques de les aplicacions dependents i interdependents que tenien problemes de rendiment mentre obtenien les respostes.
- Les entrades de prova utilitzades no eren absolutes.
- No es va tenir en compte la robustesa del programari.
- Hi ha molts problemes de sincronització entre les múltiples aplicacions independents.
- Les proves de programari havien fet diverses reelaboracions que no es van tenir en compte.
Per tant, després delaccions correctoresl'equip de planificació va intervenir, es van suggerir els següents:
- Cal augmentar la interacció entre l’equip de desenvolupament i l’equip de proves.
- Cal connectar totes les aplicacions dependents i incloure-les a la prova funcional del sistema
- Cal augmentar el valor del temps d'espera de la sol·licitud i la resposta per donar cabuda a entorns que no són de producció
- S'han d'utilitzar diverses aportacions que van des del simple fins al complex en les proves funcionals
- Les proves no funcionals, especialment les proves de rendiment i de càrrega, s’han de fer segons l’assessorament de l’equip de reparació.
- A més de les proves del sistema, també s’han de realitzar proves d’integració del sistema.
- Cal proporcionar un interval de temps mínim entre dues iteracions de prova. Es tracta de tornar a provar els errors identificats anteriorment.
- Tots els errors identificats en iteracions anteriors s’han de corregir a la iteració actual.
L'equip de proves va implementar totes les accions proposades i va haver-hi un gran nombre de defectes descoberts en poc temps.
Observacions:
- El programa d'implementació en viu del programari va millorar significativament optimitzant els temps del cicle de prova.
- Es va produir un bon progrés en l'optimització de la qualitat del programari. Per tant, hi va haver una enorme disminució dels bitllets de suport després de la implementació.
- Les re-obres es van reduir i s’estaven provant les iteracions en lloc de tornar-les a treballar. Entre les diferents iteracions, es van observar millors millores en la qualitat.
Conclusió
La realització de proves no funcionals durant l'execució de les proves funcionals és més avantatjós i afegirà més avantatges a la qualitat general del programari. Això identificarà els errors de rendiment (restringits a l'entorn de proves i la dependència) i, per tant, reduirà les situacions de supòsits de problemes funcionals.
Cal fer una planificació suficient per realitzar proves funcionals i no funcionals (fins a un nivell mínim) per mantenir una forta relació entre els altres grups d'interès del projecte.
Sobre l'autor: Aquest és un article escrit per Nagarajan. Treballa com a responsable de proves amb més de 6 anys d’experiència en proves en diverses àrees funcionals, com ara banca, línies aèries, telecomunicacions, tant en termes manuals com d’automatització.
El proper tutorial explicarà més sobre el pla de prova de rendiment i l'estratègia de prova.
=> Visiteu aquí per obtenir una sèrie completa de tutorials de proves de rendiment
Lectura recomanada
- Proves funcionals contra proves no funcionals
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Prova de rendiment vs Prova de càrrega vs Prova d’estrès (diferència)
- Georgia Tech normalitza les proves de rendiment a RadView WebLOAD
- Diferència entre la prova d'escriptori, el servidor de clients i la prova web
- Prova de descàrrega de llibres electrònics
- Les diferències entre la prova unitària, la prova d’integració i la prova funcional
- Proves de rendiment al núvol: proveïdors de serveis de proves de càrrega basades en el núvol