Guia completa de proves de càrrega per a principiants

load testing complete guide

Una guia completa de proves de càrrega per a principiants:

En aquest tutorial, aprendrem per què realitzem proves de càrrega, què s’aconsegueix amb ella, arquitectura, quin és l’enfocament que cal seguir per executar amb èxit una prova de càrrega, com configurar un entorn de prova de càrrega, les millors pràctiques, juntament amb les millors eines de prova de càrrega disponibles al mercat.

Hem sentit parlar de tipus de proves funcionals i no funcionals. A les proves no funcionals, tenim diferents tipus de proves, com ara proves de rendiment, proves de seguretat, proves d’interfície d’usuari, etc.

Per tant, la prova de càrrega és un tipus de prova no funcional que és un subconjunt de proves de rendiment.

Per tant, quan diem que estem provant una aplicació de rendiment, què estem provant aquí? Estem provant l'aplicació de càrrega, volum, capacitat, esforç, etc.

Què aprendreu:

• Què és la prova de càrrega?
• Arquitectura de prova de càrrega
• Per què carregar les proves?
• Medi ambient
• Aproximació
• Millors pràctiques
• Conclusió
• Lectura recomanada

Què és la prova de càrrega?

La prova de càrrega és un subconjunt de proves de rendiment, en què provem la resposta del sistema en diferents condicions de càrrega simulant que diversos usuaris accedeixen simultàniament a l’aplicació. Aquesta prova sol mesurar la velocitat i la capacitat de l'aplicació.

Per tant, sempre que modifiquem la càrrega, controlem el comportament del sistema en diverses condicions.

Exemple :Suposem que el requisit del nostre client per a una pàgina d'inici de sessió és de 2-5 segons i que aquests 2-5 segons haurien de ser coherents durant tot el temps fins que la càrrega sigui de 5.000 usuaris. Llavors, què hem d'observar escoltar? És només la capacitat de gestió de càrrega del sistema o només és el temps de resposta requerit?

La resposta és ambdues coses. Volem que el sistema pugui gestionar una càrrega de 5.000 usuaris amb un temps de resposta de 2 a 5 segons per a tots els usuaris concurrents.

Llavors, què s’entén per usuari simultani i usuari virtual?

Els usuaris simultanis són aquells que inicien sessió a l'aplicació i, alhora, realitzen un conjunt d'activitats i tanquen l'aplicació al mateix temps. D'altra banda, els usuaris virtuals només entren i surten del sistema, independentment de les altres activitats dels usuaris.

Arquitectura de prova de càrrega

Al diagrama següent podem veure com diferents usuaris accedeixen a l’aplicació. Aquí cada usuari fa una sol·licitud per Internet, que posteriorment es transmet a través d’un tallafoc.

Després del tallafoc, tenim un equilibrador de càrrega que distribueix la càrrega a qualsevol dels servidors web i, posteriorment, passa al servidor d’aplicacions i, posteriorment, al servidor de base de dades, on obté la informació necessària en funció de la sol·licitud de l’usuari.

Les proves de càrrega es poden fer manualment i mitjançant una eina. Però no es recomana fer proves manuals de càrrega, ja que no provem que l'aplicació tingui una càrrega inferior.

Exemple: Suposem que volem provar una aplicació de compra en línia per veure el temps de resposta de l'aplicació per a cada usuari, feu clic a Pas 1: llançament de l'URL, el temps de resposta, inicieu sessió a l'aplicació i anoteu el temps de resposta, etc., com seleccionar un producte, afegint-se al carretó, efectuant pagaments i tancant la sessió. Tot això s’ha de fer per a 10 usuaris.

Per tant, ara, quan hem de provar la càrrega de l’aplicació per a 10 usuaris, podem aconseguir-ho posant manualment la càrrega de 10 usuaris físics de diferents màquines en lloc d’utilitzar una eina. En aquest escenari, és recomanable fer una prova de càrrega manual en lloc d'invertir en una eina i configurar un entorn per a l'eina.

Si bé imaginem si hem de carregar la prova per a 1500 usuaris, hem d’automatitzar la prova de càrrega mitjançant qualsevol de les eines disponibles basades en les tecnologies en què es construeix l’aplicació i també en funció del pressupost que tenim per al projecte.

Si tenim un pressupost, podem optar per eines comercials com Load Runner, però si no tenim un pressupost elevat, podem optar per eines de codi obert com JMeter, etc.

converteix diversos vídeos de youtube a mp3

Tant si es tracta d’una eina comercial com d’una eina de codi obert, els detalls s’han de compartir amb el client abans de finalitzar l’eina. Normalment, es prepara una prova de concepte, on generem un exemple de script amb l’eina i mostrem els informes de mostra al client per a l’aprovació de l’eina abans de finalitzar-la.

En les proves de càrrega automàtiques, substituïm els usuaris amb l'ajuda d'una eina d'automatització, que imita les accions de l'usuari en temps real. Automatitzant la càrrega, podem estalviar recursos i temps.

A continuació es mostra el diagrama que mostra com es substitueixen els usuaris mitjançant una eina.

Per què carregar les proves?

Suposem que hi ha un lloc web de compres en línia que funciona força bé durant els dies laborals normals, és a dir, els usuaris poden iniciar sessió a l’aplicació, navegar per les diferents categories de productes, seleccionar productes, afegir articles al carretó, sortir i tancar la sessió dins un interval acceptable i no hi ha errors de pàgina ni grans temps de resposta.

Mentrestant, arriba el dia màxim, és a dir, diguem el dia de gràcies i hi ha milers d'usuaris que han iniciat la sessió al sistema, el sistema es bloqueja de cop i els usuaris experimenten una resposta molt lenta, alguns ni tan sols podrien inicieu sessió al lloc, alguns no s’han pogut afegir al carretó i alguns no han pogut sortir.

Per tant, en aquest gran dia, la companyia va haver d’afrontar una gran pèrdua, ja que va perdre molts clients i també molts negocis. Tot això va passar pel fet que no van predir la càrrega de l'usuari durant els dies punta, fins i tot si haguessin predit que no es va fer cap prova de càrrega al lloc web de l'empresa, de manera que no saben quina càrrega podrà gestionar l'aplicació. els dies de màxima intensitat.

Per tant, per gestionar aquestes situacions i per superar enormes ingressos, és recomanable realitzar proves de càrrega per a aquest tipus d’aplicacions.

• Les proves de càrrega ajuden a construir sistemes robustos i fiables.
• El coll d'ampolla del sistema s'identifica amb molta antelació abans que l'aplicació es publiqui.
• Ajuda a identificar la capacitat de l’aplicació.

Què s’aconsegueix durant una prova de càrrega?

Amb una prova de càrrega adequada, podem entendre exactament el següent:

1. El nombre d’usuaris que el sistema pot gestionar o és capaç d’escalar.
2. El temps de resposta de cada transacció.
3. Com es comporta cada component de tot el sistema a Carregar, és a dir, components del servidor d'aplicacions, components del servidor web, components de la base de dades, etc.
4. Quina configuració de servidor és millor per gestionar la càrrega?
5. Si el maquinari existent és suficient o hi ha necessitat de maquinari addicional.
6. S'identifiquen colls d'ampolla com la utilització de la CPU, l'ús de la memòria, els retards de la xarxa, etc.

Medi ambient

Necessitem un entorn de proves de càrrega dedicat per dur a terme les nostres proves. Com que la majoria de les vegades l’entorn de prova de càrrega serà el mateix que l’entorn de producció i les dades disponibles a l’entorn de prova de càrrega seran iguals que la producció, tot i que no són les mateixes dades.

Hi haurà múltiples entorns de prova, com ara l’entorn SIT, l’entorn de control de qualitat, etc., aquests entorns no són la mateixa producció, perquè a diferència de les proves de càrrega no necessiten tants servidors ni tantes dades de prova per dur a terme proves funcionals o proves d’integració.

Exemple:

En un entorn de producció, tenim 3 servidors d'aplicacions, 2 servidors web i 2 servidors de bases de dades. A QA, només tenim 1 servidor d'aplicacions, 1 servidor web i 1 servidor de bases de dades. Per tant, si realitzem una prova de càrrega a l’entorn QA que no és igual a la producció, les nostres proves no són vàlides i tampoc són incorrectes i, per tant, no podem seguir aquests resultats.

Per tant, intenteu sempre tenir un entorn dedicat per a les proves de càrrega que sigui similar al d'un entorn de producció.

A més, de vegades tenim aplicacions de tercers a les que el nostre sistema cridarà, de manera que, en aquests casos, podem utilitzar registres ja que no sempre podem treballar amb proveïdors externs per actualitzar les dades o qualsevol altre problema o assistència.

Proveu de fer una captura de pantalla de l’entorn un cop estigui a punt, de manera que, sempre que vulgueu reconstruir l’entorn, pugueu utilitzar aquesta captura de pantalla, cosa que us ajudaria amb la gestió del temps. Hi ha algunes eines disponibles al mercat per configurar l’entorn, com Puppet, Docker, etc.

Aproximació

Abans de començar la prova de càrrega, hem d’entendre si alguna prova de càrrega ja es fa al sistema o no. Si es van fer proves de càrrega abans, hem de saber quin va ser el temps de resposta, les mètriques de client i servidor recollides, quant va ser la capacitat de càrrega de l'usuari, etc.

A més, necessitem informació sobre quant és la capacitat actual de gestió de l'aplicació. Si es tracta d’una aplicació nova, hem d’entendre els requisits, quina és la càrrega objectiva, quin és el temps de resposta esperat i si és realment realitzable o no.

Si es tracta d'una aplicació existent, podeu obtenir els requisits de càrrega i els patrons d'accés de l'usuari als registres del servidor. Però si es tracta d’una aplicació nova, cal que us poseu en contacte amb l’equip empresarial per obtenir tota la informació.

Un cop tenim els requisits, hem d’identificar com executarem la prova de càrrega. Es fa manualment o mitjançant eines? Fer una prova de càrrega manualment necessita molts recursos i també és molt car. Repetir la prova, una i altra vegada, també serà difícil.

Per tant, per superar-ho, podem utilitzar eines de codi obert o eines comercials. Les eines de codi obert estan disponibles de forma gratuïta, és possible que aquestes eines no tinguin totes les funcions com les altres eines comercials, però si el projecte té una limitació pressupostària, podem optar per eines de codi obert.

Tot i que les eines comercials tenen moltes funcions, admeten molts protocols i són molt fàcils d’utilitzar.

El nostre enfocament de la Prova de càrrega serà el següent:

# 1) Identifiqueu els criteris d'acceptació de la prova de càrrega

Per exemple:

1. El temps de resposta de la pàgina d’inici de sessió no ha de ser superior a 5 segons, fins i tot durant les condicions de càrrega màxima.
2. La utilització de la CPU no hauria de ser superior al 80%.
3. El rendiment del sistema ha de ser de 100 transaccions per segon.

# 2) Identifiqueu els escenaris empresarials que cal provar.

No proveu tots els fluxos, proveu d’entendre els principals fluxos empresarials que s’espera que passin a la producció. Si es tracta d’una aplicació existent, podem obtenir la seva informació dels registres del servidor de l’entorn de producció.

Si es tracta d'una aplicació de nova creació, hem de treballar amb els equips empresarials per entendre els patrons de flux, l'ús de l'aplicació, etc. De vegades, l'equip del projecte realitzarà tallers per donar una visió general o detalls sobre cada component de l'aplicació.

Hem d’assistir al taller d’aplicacions i tenir en compte tota la informació necessària per dur a terme la prova de càrrega.

# 3) Modelatge de càrrega de treball

Un cop tinguem els detalls sobre els fluxos empresarials, els patrons d’accés dels usuaris i el nombre d’usuaris, hem de dissenyar la càrrega de treball de manera que imiti la navegació real de l’usuari en producció o com s’espera que sigui en el futur un cop l’aplicació s’hagi realitzat. estarà en producció.

Els punts clau que cal recordar durant el disseny d’un model de càrrega de treball és veure quant de temps trigarà un determinat flux empresarial a completar-se. Aquí hem d'assignar el temps de reflexió de manera que l'usuari pugui navegar per l'aplicació d'una manera més realista.

El patró de càrrega de treball sol ser amb una rampa cap amunt, una rampa cap avall i un estat estacionari. Hauríem de carregar lentament el sistema i, per tant, s’utilitzen rampa amunt i avall. L’estat estacionari sol ser una prova de càrrega d’una hora amb Ramp up de 15 min i Ram down de 15 min.

Prenguem un exemple del model de càrrega de treball:

Visió general de l’aplicació: suposem una compra en línia, on els usuaris iniciaran la sessió a l’aplicació i tindran una gran varietat de vestits per comprar i podran navegar per cada producte.

Per veure els detalls sobre cada producte, han de fer clic al producte. Si els agrada el cost i la marca del producte, poden afegir al carretó i comprar el producte comprovant i efectuant el pagament.

A continuació es mostra una llista d’escenaris:

1. Navega - Aquí l'usuari llança l'aplicació, inicia sessió a l'aplicació, navega per diferents categories i tanca la sessió de l'aplicació.
2. Navega, visualitza el producte, afegeix a la cistella - Aquí l'usuari inicia sessió a l'aplicació, navega per diferents categories, visualitza els detalls del producte, afegeix el producte al carretó i tanca la sessió.
3. Navega, visualitza el producte, afegeix a la cistella i fes una ullada - En aquest escenari, l'usuari inicia sessió a l'aplicació, navega per diferents categories, visualitza els detalls del producte, afegeix el producte al carretó, fa la sortida i tanca la sessió.
4. Navega, visualitza el producte, afegeix a la cistella Comanda i efectua el pagament - Aquí l’usuari inicia sessió a l’aplicació, navega per diferents categories, visualitza els detalls del producte, afegeix el producte al carretó, fa la sortida, efectua el pagament i tanca la sessió.

Els valors anteriors es van obtenir a partir dels càlculs següents:

• Transaccions per hora = Nombre d'usuaris * Transaccions fetes per un sol usuari en una hora.
• El nombre d'usuaris = 1600.
• El nombre total de transaccions a l'escenari Examinar = 17.
• Temps de resposta per a cada transacció = 3.
• Temps total perquè un sol usuari completi 17 transaccions = 17 * 3 = 51 arrodonit a 60 segons (1 min).
• Transaccions per hora = 1600 * 60 = 96000 Transaccions.

# 4) Dissenyeu les proves de càrrega- La prova de càrrega s’ha de dissenyar amb les dades que hem recopilat fins ara, és a dir, els fluxos empresarials, el nombre d’usuaris, els patrons d’usuaris, les mètriques que s’han de recopilar i analitzar. A més, les proves s’han de dissenyar d’una manera molt realista.

# 5) Executeu la prova de càrrega - Abans d'executar la prova de càrrega, assegureu-vos que l'aplicació està en funcionament. L'entorn de prova de càrrega està llest. L'aplicació està provada funcionalment i és estable.

Comproveu la configuració de l'entorn de prova de càrrega. Ha de ser el mateix que l’entorn de producció. Assegureu-vos que totes les dades de la prova estiguin disponibles. Assegureu-vos d’afegir comptadors necessaris per supervisar el rendiment del sistema durant l’execució de la prova.

Comenceu sempre amb una càrrega baixa i aneu augmentant la càrrega gradualment. No comenceu mai amb la càrrega completa i trenqueu el sistema.

# 6) Analitzeu els resultats de la prova de càrrega - Feu una prova de referència per comparar-la sempre amb la resta de proves. Recopileu les mètriques i els registres del servidor després de la prova per trobar els colls d'ampolla.

Alguns projectes utilitzen eines de control de rendiment de l'aplicació per supervisar el sistema durant l'execució de la prova; aquestes eines APM ajuden a identificar la causa arrel més fàcilment i a estalviar molt de temps. Aquestes eines són molt fàcils de trobar la causa principal del coll d'ampolla, ja que tenen una visió àmplia per determinar on es troba el problema.

Algunes de les eines APM del mercat inclouen DynaTrace, Wily Introscope, App Dynamics, etc.

# 7) Informes - Un cop finalitzada la prova de prova, recopileu totes les mètriques i envieu l'informe resum de la prova a l'equip interessat amb les vostres observacions i recomanacions.

Millors pràctiques

A continuació, es detallen algunes de les pràctiques recomanades per a la prova de càrrega:

# 1) Comproveu sempre l'estabilitat de l'aplicació abans de començar una prova de càrrega. L'equip de proves funcionals ha de signar l'aplicació funcionalment estable i s'ha de corregir i provar tots els defectes importants abans de copiar la compilació a l'entorn de prova de càrrega.

# 2) Assegureu-vos que l’entorn de prova de càrrega sigui una rèplica o sigui a prop de l’entorn de producció, inclòs el nombre de servidors, equilibradors de càrrega, configuracions de servidor i tallafocs.

# 3) Comproveu si les dades de la prova són úniques i tenim totes les dades de la prova copiades a l’entorn de càrrega abans de realitzar una prova de càrrega.

# 4) Dissenyeu els escenaris de prova de manera que imitin l'acció de l'usuari en temps real a la producció.

# 5) Dissenyeu la càrrega de treball en funció de les càrregues d'usuari de producció i dels fluxos empresarials i, en cas d'una aplicació antiga, consulteu si es tracta d'una nova conversa amb l'equip de negocis sobre els fluxos empresarials i la càrrega de l'usuari.

# 6) Recopileu totes les mètriques importants, com ara el temps de resposta, les peticions de fitxer per segon, el rendiment, la CPU, la memòria, la xarxa i els Vusers en execució.

Lectura recomanada => Llista d’eines de proves de rendiment disponibles al mercat per realitzar proves de càrrega exclusives.

Conclusió

En aquest tutorial, hem après com les proves de càrrega tenen un paper important en les proves de rendiment d'una aplicació, com ajuda a entendre l'eficiència i la capacitat de l'aplicació, etc.

També vam conèixer com ajuda a predir si es requereix maquinari, programari o sintonització addicionals en una aplicació.

Bona lectura !!

Lectura recomanada

• Prova de càrrega amb tutorials HP LoadRunner
• Proves alfa i proves beta (guia completa)
• Guia de proves de seguretat d'aplicacions web
• Guia de proves d’estrès per a principiants
• Guia per a principiants sobre proves de penetració d'aplicacions web
• Una guia completa de proves no funcionals per a principiants
• Guia completa de proves de verificació de compilació (proves BVT)
• Prova de rendiment vs Prova de càrrega vs Prova d’estrès (diferència)