En aquesta secció, aprendrem sobre les proves de rendiment, per què les necessitem, els tipus de proves de rendiment i el procés de proves de rendiment.
A continuació es mostren els temes, que entendrem en aquesta secció:
Què és la prova de rendiment?
És la part més important de les proves no funcionals.
Comprovar el comportament d'una aplicació aplicant una mica de càrrega es coneix com a prova de rendiment.
En general, aquesta prova defineix la rapidesa amb què el servidor respon a la sol·licitud de l'usuari.
Mentre fem proves de rendiment a l'aplicació, ens concentrarem en diversos factors com ara Temps de resposta, càrrega i estabilitat de l'aplicació.
Temps de resposta: El temps de resposta és el temps que triga el servidor a respondre a la sol·licitud del client.
Càrrega: Aquí, carregar vol dir que quan N-número dels usuaris que utilitzen l'aplicació simultàniament o que envien la sol·licitud al servidor alhora.
Estabilitat: Pel que fa al factor d'estabilitat, podem dir que, quan N-nombre d'usuaris utilitzen l'aplicació simultàniament durant un temps determinat.
Quan fem servir les proves de rendiment?
Farem proves de rendiment un cop el programari estigui estable i s'hagi traslladat a la producció, i diversos usuaris podran accedir-hi simultàniament, per aquest motiu, es poden produir alguns problemes de rendiment. Per evitar aquests problemes de rendiment, el verificador realitza una ronda de proves de rendiment.
Com que es tracta de proves no funcionals, la qual cosa no vol dir que utilitzem sempre proves de rendiment, només fem proves de rendiment quan l'aplicació és funcionalment estable.
Nota: les proves de rendiment no es poden fer manualment, ja que no es pot mantenir el seu resultat costós i precís.
Tipus de proves de rendiment
A continuació es mostren els tipus de proves de rendiment:
caràcter.compara java
Deixeu-nos parlar un per un per donar-vos una comprensió completa Càrrega, esforç, escalabilitat, i Estabilitat proves de rendiment.
Prova de càrrega
La prova de càrrega s'utilitza per comprovar el rendiment d'una aplicació aplicant una càrrega que sigui inferior o igual a la càrrega desitjada es coneix com a prova de càrrega.
Per exemple: A la imatge de sota, 1000 usuaris són els càrrega desitjada , que és donat pel client, i 3/segon és el objectiu que volem aconseguir mentre realitzem una prova de càrrega.
Proves d'estrès
La prova d'esforç és una prova, que comprova el comportament d'una aplicació aplicant una càrrega superior a la càrrega desitjada.
Per exemple: Si prenem l'exemple anterior i augmentem la càrrega desitjada de 1000 a 1100 usuaris, i l'objectiu és 4/segon. Mentre es realitza la prova d'estrès en aquest escenari, passarà perquè la càrrega és més gran (100 més) que la càrrega real desitjada.
Proves d'escalabilitat
Comprovar el rendiment d'una aplicació augmentant o disminuint la càrrega en escales particulars (no d'usuari) es coneix com proves d'escalabilitat . Les proves d'escalabilitat a l'alça i a la baixa s'anomenen proves d'escalabilitat.
Les proves d'escalabilitat es divideixen en dues parts que són les següents:
Proves d'escalabilitat ascendent
Està provant on estem augmentar el nombre d'usuaris a una escala determinada fins que arribem a un punt de xoc. Utilitzarem proves d'escalabilitat ascendent per trobar la capacitat màxima d'una aplicació.
Proves d'escalabilitat a la baixa
La prova d'escalabilitat a la baixa s'utilitza quan no s'aprova la prova de càrrega i, a continuació, s'inicia disminuint el núm. d'usuaris en un interval determinat fins que s'aconsegueixi l'objectiu. Perquè sigui fàcil identificar el coll d'ampolla (error).
Prova d'estabilitat
Comprovació del rendiment d'una aplicació mitjançant aplicar la càrrega durant un període de temps determinat es coneix com Prova d'estabilitat .
Exemple de proves de rendiment
Posem un exemple on ho farem prova el comportament d'una aplicació on la càrrega desitjada és inferior a 1000 o igual a 1000 usuaris .
A la imatge de sota, podem veure que el 100 amunt els usuaris augmenten contínuament per comprovar el càrrega màxima , que també s'anomena proves d'escalabilitat ascendent .
1200 → 3,5s: [no és inferior o igual a la càrrega desitjada, per això ho farà Falla ]
1300 → 4s: [no és inferior o igual a la càrrega desitjada. és a dir, Falla ]
1400 → Estavellat
Nota 1: les proves de volum i aigua són un tipus de prova, però no de rendiment.
Prova de volum
La prova de volum és una prova, que ens ajuda a comprovar el comportament d'una aplicació inserint un volum massiu de càrrega en termes de dades es coneix com a prova de volum, i aquí ens concentrarem en el nombre de taxes de dades que en el nombre d'usuaris. .
Nota 2:
El volum és una capacitat mentre que la càrrega és una quantitat, és a dir, la prova de càrrega significa que no. d'usuaris, i les proves de volum significa quantitat de dades.
Prova de remull
com saber la mida de la pantalla
En aquest tipus de proves, comprovarem el comportament d'una aplicació en l'entorn, que és incompatible durant un llarg període de temps es coneix com a prova de remull.
En general, les proves de remull és un tipus de prova negatiu, ja que ja sabem que el servidor o l'entorn no és compatible.
Procés de prova de rendiment
Les proves de rendiment no es poden fer manualment perquè:
- Necessitem molts recursos i es va convertir en un enfocament més costós.
- I la precisió no es pot mantenir quan fem un seguiment manual del temps de resposta.
El procés de prova de rendiment es completarà en els passos següents:
- Identificar escenaris de rendiment
- Planificar i dissenyar un script de prova de rendiment
- Configura l'entorn de prova i distribueix la càrrega
- Executar scripts de prova
- Resultat
- Resultat de l'anàlisi
- Identificar el coll d'ampolla
- Torna a executar la prova
Si realitzem a flux positiu del procés de prova de rendiment, podria seguir el procés següent:
Identificar escenaris de rendiment
En primer lloc, identificarem els escenaris de rendiment a partir dels següents factors:
Escenaris més habituals: Vol dir que podem trobar els escenaris de rendiment basats en els escenaris, que s'utilitzen habitualment com en el aplicació de Gmail; actuarem inicieu sessió, safata d'entrada, envieu elements i redacteu un correu i tanqueu la sessió .
Escenaris més crítics: Els escenaris crítics signifiquen que s'utilitzen habitualment i són importants per a l'empresa de l'aplicació Gmail inicieu sessió, redacteu, safata d'entrada i tanqueu la sessió .
Gran transacció de dades: Si tenim grans dades significa que n-nombre d'usuaris que utilitzen l'aplicació alhora.
Un cop identificats els escenaris de rendiment, passarem al següent pas.
Planificar i dissenyar un script de prova de rendiment
En aquest pas, instal·larem les eines a la màquina de l'enginyer de prova i accedirem al servidor de proves i després escrivim un script segons els escenaris de prova i executem l'eina.
Un cop acabem d'escriure el guió, passarem al següent pas.
Configura l'entorn de prova i distribueix la càrrega
Després d'escriure els scripts de prova, organitzarem l'entorn de prova abans de l'execució. I també, gestionar les eines, altres recursos i distribuir la càrrega segons el 'Patró d'ús' o mencionar la durada i l'estabilitat.
declaració java if else
Executar scripts de prova
Un cop acabem de distribuir la càrrega, executarem, validarem i supervisarem els scripts de prova.
Resultat
Després d'executar els scripts de prova, obtindrem el resultat de la prova. I comproveu que el resultat compleix l'objectiu en el temps de resposta donat o no, i el temps de resposta podria ser màxim, mitjà i mínim.
Si la resposta no compleix el temps de resposta requerit, anirem a buscar flux negatiu on realitzarà els passos següents:
Resultat de l'anàlisi
En primer lloc, analitzarem el resultat de la prova si compleix o no amb el temps de resposta.
Identificar el coll d'ampolla
Després d'això, identificarem el coll d'ampolla (error o problema de rendiment ). I el coll d'ampolla podria produir-se a causa d'aquests aspectes com el problema de codi, problema de maquinari (disc dur, processador RAM), problemes de xarxa, i la problema de programari (sistema operatiu) . I després de trobar el coll d'ampolla, actuarem afinació (fixació o ajust) per resoldre aquest coll d'ampolla.
Torna a executar la prova
Un cop solucionem els colls d'ampolla, torneu a executar els scripts de prova i comproveu el resultat si compleix l'objectiu requerit o no.
El problema es produeix a les proves de rendiment
Durant la realització de proves de rendiment a l'aplicació, es poden produir alguns problemes, i aquests problemes també s'anomenen problema de rendiment .
Els problemes de rendiment són els següents:
Problema de temps de resposta
El temps de resposta significa la rapidesa amb què el servidor respon a la sol·licitud del client. Si la sol·licitud de l'usuari no es completa en el temps de resposta donat, és possible que l'usuari hagi perdut el seu interès en el programari o aplicació en particular. És per això que l'aplicació o programari hauria de tenir un temps de resposta perfecte per respondre ràpidament a la sol·licitud de l'usuari.
Problema d'escalabilitat
Els problemes d'escalabilitat es produeixen quan l'aplicació no pot acceptar els n nombres d'usuaris i les sol·licituds d'usuari esperades alhora. Per això ho farem proves d'escalabilitat ascendent (comprovar la capacitat màxima de l'aplicació) i proves d'escalabilitat a la baixa (quan el temps previst no coincideix amb el temps real).
Coll d'ampolla
El coll d'ampolla és el nom informal de l'error, que es produeix quan l'aplicació està limitada per un sol component i crea un mal impacte en el rendiment del sistema.
Les principals causes del coll d'ampolla són problemes de programari (problema relacionat amb el sistema operatiu), problemes de maquinari (problemes relacionats amb el disc dur, la memòria RAM i el processador), i problema de codificació, etc.
A continuació es mostren els colls d'ampolla de rendiment més comuns:
- Ús de la memòria
- Ús del disc
- Ús de la CPU
- Limitacions del sistema operatiu
- Ús de la xarxa
Problemes de velocitat
Quan realitzem proves de rendiment a l'aplicació, l'aplicació hauria de ser més ràpida en velocitat per captar l'interès i l'atenció de l'usuari perquè si la velocitat de l'aplicació és lenta, pot perdre l'interès de l'usuari en l'aplicació.
Eines de prova de rendiment
Tenim diversos tipus d'eines de prova de rendiment disponibles al mercat, on algunes són eines comercials i eines de codi obert.
Eines comercials: LoadRunner[HP], WebLOAD, NeoLoad
Eina de codi obert: JMeter
LoadRunner
És una de les eines més potents de prova de rendiment, que s'utilitza per donar suport a les proves de rendiment per a l'ampli ventall de protocols, nombre de tecnologies i entorns d'aplicació.
Identifica ràpidament les causes més comunes dels problemes de rendiment. I també prediu amb precisió l'escalabilitat i la capacitat de l'aplicació.
JMeter
El programari Apache JMeter és una eina de codi obert, que és una aplicació totalment Java dissenyada per carregar el comportament de la prova funcional i mesurar-ne el rendiment.
què és un ubuntu essencial per a la construcció
En general, es va dissenyar per provar les aplicacions web, però ara també s'ha ampliat a altres funcions de prova.
Apache JMeter s'utilitza per provar el rendiment tant de recursos estàtics com dinàmics i d'aplicacions web dinàmiques.
Es pot utilitzar per reproduir la càrrega pesada en un servidor, xarxa o objecte, grup de servidors per provar la seva força o per analitzar el rendiment general sota diferents tipus de càrrega.
CÀRREGA web
Eina de proves WebLOAD que s'utilitza per provar les aplicacions web de proves de càrrega, proves de rendiment i proves d'estrès.
L'eina WebLOAD combina rendiment, escalabilitat i integritat com un únic procés per a la verificació d'aplicacions web i mòbils.
NeoLoad
Neotys desenvolupa una eina de prova que es diu NeoLoad. El NeoLoad s'utilitza per provar els escenaris de prova de rendiment. Amb l'ajuda de NeoLoad, podem trobar les àrees de coll d'ampolla a la web i el procés de desenvolupament d'aplicacions mòbils.
L'eina de prova NeoLoad és més ràpida en comparació amb les eines tradicionals.
A part d'ells, hi ha altres eines Càrrega elèctrica, eina d'estrès web, LoadUI Pro, StresStimulus, LoadView, LoadNinja i RedLine13, que ajuda a provar el rendiment del programari o d'una aplicació.