logo

Prova de rendiment

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
    Prova de càrrega Proves d'estrès Proves d'escalabilitat Prova d'estabilitat
Prova de rendiment

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.

Prova de rendiment

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.

Prova de rendiment

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 Proves d'escalabilitat a la baixa

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 .

    Escenari 1:Quan tinguem els 1000 usuaris com a càrrega desitjada, i el 2,7/s és el temps objectiu, aquests escenaris passaran mentre realitzem la prova de càrrega perquè en les proves de càrrega, ens concentrarem en el núm. d'usuaris, i segons el requisit és igual a 1000 usuaris.Escenari 2:En el següent escenari, augmentarem la càrrega desitjada en 100 usuaris i el temps objectiu augmentarà fins a 3,5s. Aquest escenari passarà si fem proves d'esforç perquè aquí, la càrrega real és superior a (1100) la càrrega desitjada (1000).Escenari 3:En això, si augmentem la càrrega desitjada tres vegades com
    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
Prova de rendiment

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
Prova de rendiment

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 Problema d'escalabilitat Coll d'ampolla Problema de velocitat

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ó.