complete performance testing guide with examples
Què són les proves de rendiment?
Les proves de rendiment també es coneixen com a 'proves de perfecció', és un tipus de proves que es realitzen per comprovar el rendiment de l'aplicació o el programari sota càrrega de treball en termes de capacitat de resposta i estabilitat. L'objectiu de la prova de rendiment és identificar i eliminar els colls d'ampolla de rendiment d'una aplicació.
Aquesta prova es realitza principalment per comprovar si el programari compleix els requisits esperats de velocitat, escalabilitat i estabilitat de les aplicacions.
bon descarregador de música gratuït per a Android
En aquesta sèrie de tutorial, tractarem des de zero detalls complets com ara: tipus de proves de perfecció, processos i estratègia de prova de rendiment d'escriptura.
Aquesta és una sèrie de tutorial detallada que és possible que vulgueu afegir a les adreces d'interès.
Explorem!
Llista de TOTS els tutorials sobre proves de rendiment d'aquesta sèrie:
Tutorial # 1: Guia completa de proves de rendiment (Aquest tutorial)
Tutorial # 2: Diferència entre les proves de rendiment, càrrega i esforç
Tutorial # 3: Proves funcionals vs proves de rendiment
Tutorial # 4: Pla de prova de rendiment i estratègia de prova
Tutorial # 5: Maneres de superar les proves de rendiment
Tutorial # 6: Guia de proves de rendiment al núvol
Tutorial # 7: Guia de proves de rendiment de les aplicacions mòbils
Tutorial # 8: Com realitzar proves de rendiment manuals
Tutorial # 9: Tutorial de proves de rendiment del lloc web
Tutorial # 10: Empreses de proves de rendiment
Tutorial # 11: Proves de rendiment amb LoadRunner (Sèrie)
Eines:
Tutorial # 12: Eines de proves de rendiment superior
Tutorial # 13: Tutorial de proves de rendiment de Neoload
Tutorial # 14: Tutorial de prova de rendiment mòbil de BlazeMeter
Tutorial # 15: Tutorial de proves de càrrega, estrès i rendiment de WAPT
Tutorial # 16: Tutorial de proves de rendiment del lloc web SmartMeter.io
Què aprendreu:
- Tipus de proves de rendiment
- Procés de prova de rendiment
- Com escriure un document d'estratègia de prova de rendiment?
- Plantilla d'estratègia de prova de rendiment de mostra
- #1. Introducció
- # 2) Abast
- # 3) Enfocament
- # 4) Dades de prova
- # 5) Criteris d'entrada i sortida
- # 6) Gestió de defectes
- # 7) Eines i tècniques de prova
- # 8) Criteris de suspensió i represa
- # 9) Prova de lliuraments
- # 10) Funcions i responsabilitats
- # 11) Riscos potencials i pla de mitigació
- # 12) Supòsits
- # 13) Dependències
- # 14) Abreviatures
- Bones pràctiques per a proves de rendiment realistes
Tipus de proves de rendiment
Prova de càrrega
La prova de càrrega és un tipus de prova de rendiment on l'aplicació es comprova el seu rendiment en un ús normal i màxim. Es comprova el rendiment d’una aplicació respecte a la seva resposta a la sol·licitud de l’usuari i la seva capacitat de respondre de manera coherent dins d’una tolerància acceptada en diferents càrregues de l’usuari.
Les consideracions clau són:
- Quina és la càrrega màxima que pot mantenir l'aplicació abans que l'aplicació comenci a comportar-se inesperadament?
- Quantes dades pot gestionar la base de dades abans que el sistema s'alenteixi o s'observi el bloqueig?
- Hi ha problemes relacionats amb la xarxa que cal abordar?
Proves d’estrès
La prova d’estrès s’utilitza per trobar maneres de trencar el sistema. La prova també proporciona l'abast de càrrega màxima que pot suportar el sistema.
En general, les proves d’esforç tenen un enfocament incremental on la càrrega augmenta gradualment. La prova s’inicia amb una càrrega per a la qual ja s’ha provat l’aplicació. Després, s’afegeix més càrrega lentament per estressar el sistema. El punt en què comencem a veure que els servidors no responen a les sol·licituds es considera el punt de ruptura.
S'han d'abordar les qüestions següents:
- Quina és la càrrega màxima que pot suportar un sistema abans que es trenqui?
- Com es descompon el sistema?
- El sistema es pot recuperar un cop s’ha bloquejat?
- De quantes maneres es pot trencar un sistema i quins són el node feble mentre maneja la càrrega inesperada?
Proves de volum
La prova de volum consisteix a verificar que el rendiment de l'aplicació no es vegi afectat pel volum de dades que gestiona l'aplicació. Per tal d'executar una prova de volum, s'introdueix un gran volum de dades a la base de dades. Aquesta prova pot ser una prova incremental o constant. A la prova incremental, el volum de dades augmenta gradualment.
Generalment, amb l'ús de l'aplicació, la mida de la base de dades creix i és necessari provar l'aplicació contra una base de dades pesada. Un bon exemple d’això podria ser un lloc web d’una escola nova o d’un col·legi que tingués petites quantitats de dades per emmagatzemar inicialment, però al cap de 5 a 10 anys, els magatzems de dades a la base de dades del lloc web són molt més.
Proves de capacitat
=> L'aplicació és capaç de satisfer el volum de negoci tant en condicions normals com de càrrega màxima?
Les proves de capacitat es fan generalment per a futurs possibles. Les proves de capacitat aborden el següent:
- L'aplicació serà capaç de suportar la futura càrrega?
- L’entorn és capaç de suportar la propera major càrrega?
- Quins són els recursos addicionals necessaris per fer el medi ambient suficientment capaç?
La prova de capacitat s’utilitza per determinar quants usuaris i / o transaccions donarà suport a una determinada aplicació web i, tot i així, compliran el rendiment. Durant aquesta prova, es consideren i s’alteren recursos com la capacitat del processador, l’amplada de banda de la xarxa, l’ús de memòria, la capacitat del disc, etc. per complir l’objectiu.
La banca en línia és un exemple perfecte d’on les proves de capacitat poden tenir un paper important.
Fiabilitat / Recuperació Proves
Prova de fiabilitat o prova de recuperació: consisteix en verificar si l'aplicació pot tornar al seu estat normal després d'un error o un comportament anormal i quant de temps triga a fer-ho (és a dir, estimació de temps).
Si un lloc de comerç en línia experimenta un error en què els usuaris no poden comprar / vendre accions en un moment determinat del dia (hores punta), però poden fer-ho al cap d’una hora o dues, podem dir que l’aplicació és fiable o recuperat del comportament anormal.
Procés de prova de rendiment
Aquí teniu totes les activitats realitzades en aquesta prova:
# 1) Anàlisi / reunió de requisits
L’equip de rendiment interactua amb el client per identificar i reunir requisits, tant tècnics com empresarials. Això inclou obtenir informació sobre l’arquitectura de l’aplicació, les tecnologies i la base de dades utilitzades, els usuaris previstos, la funcionalitat, l’ús de l’aplicació, requisit de prova , requisits de maquinari i programari, etc.
#2) POC/Tool selection
Un cop identificada la funcionalitat clau, es fa POC (Prova del concepte, que és una mena de demostració de l’activitat en temps real, però en un sentit limitat) amb les eines disponibles.
La llista d'eines disponibles depèn del cost de l'eina, del protocol que utilitza l'aplicació, de les tecnologies que s'utilitzen per crear l'aplicació, del nombre d'usuaris que simulem per a la prova, etc. Durant el POC, es creen scripts per a la clau identificada funcionalitat i executat amb 10-15 usuaris virtuals.
alguns errors de programari apunten a un problema de connectivitat física
# 3) Pla i disseny de proves de rendiment
Depenent de la informació recollida en les etapes anteriors, es realitza la planificació i el disseny de les proves.
La planificació de proves inclou informació sobre com es durà a terme la prova de rendiment: entorn de prova, càrrega de treball, maquinari, etc.
Més informació sobre el document d’Estratègia de proves a continuació.
# 4) Desenvolupament de proves de rendiment
- Es creen casos d'ús per a la funcionalitat identificada al pla de prova com a abast de PT.
- Aquests casos d’ús es comparteixen amb el client per a la seva aprovació. Es tracta d’assegurar-se que l’escriptura es gravarà amb els passos correctes.
- Un cop aprovat, el desenvolupament de seqüències comença amb un registre dels passos dels casos d’ús amb l’eina de prova de rendiment seleccionada durant el POC (Prova de conceptes) i millorada mitjançant la realització de correlacions (per a la gestió de valor dinàmic), parametrització (substitució de valor) i funcions personalitzades com segons la situació o necessitat. Obteniu més informació sobre aquestes tècniques als nostres videotutorials.
- Els scripts es validen després amb diferents usuaris.
- Paral·lelament a la creació de guions, l'equip de rendiment també continua treballant en la configuració de l'entorn de prova (programari i maquinari).
- L'equip de rendiment també s'encarregarà de les metadades (back-end) mitjançant scripts si aquesta activitat no la pren el client.
# 5) Modelització de proves de rendiment
Es crea el model de càrrega de rendiment per a l'execució de la prova. L’objectiu principal d’aquest pas és validar si les mètriques de rendiment donades (proporcionades pels clients) s’assoleixen durant la prova o no. Hi ha diferents enfocaments per crear un model de càrrega. ' Llei de Petit ”S’utilitza en la majoria dels casos.
# 6) Execució de la prova
L'escenari es dissenya segons el model de càrrega al controlador o al centre de rendiment, però les proves inicials no s'executen amb els usuaris màxims que es troben al model de càrrega.
L'execució de la prova es fa de manera incremental. Per exemple, Si el nombre màxim d’usuaris és de 100, els escenaris s’executen primer amb 10, 25, 50 usuaris, etc., passant finalment a 100 usuaris.
# 7) Anàlisi de resultats de proves
Els resultats de les proves són el producte més important per al provador de rendiment. Aquí és on podem demostrar el ROI (retorn de la inversió) i la productivitat que pot proporcionar un esforç de proves de rendiment.
Algunes de les pràctiques recomanades que ajuden al procés d'anàlisi de resultats:
- Un nom únic i significatiu per a cada resultat de la prova; això ajuda a entendre el propòsit de la prova.
- Incloeu la informació següent al resum dels resultats de la prova:
- Motiu del / s error / s
- Canvi en el rendiment de l'aplicació en comparació amb la prova anterior
- Canvis realitzats a la prova des del punt de creació d'aplicacions o entorn de prova.
- És una bona pràctica fer un resum dels resultats després de cada prova, de manera que els resultats de l’anàlisi no es compilin cada vegada que es remeten els resultats de la prova.
- PT normalment requereix moltes proves per arribar a la conclusió correcta.
- És bo tenir els punts següents al resum dels resultats:
- Finalitat de la prova
- Nombre d'usuaris virtuals
- Resum de l’escenari
- Durada de la prova
- Rendiment
- Gràfics
- Comparació de gràfics
- Temps de resposta
- S'ha produït un error
- Recomanacions
# 8) Informe
Els resultats de les proves s’han de simplificar, de manera que la conclusió és més clara i no necessita cap derivació. L’equip de desenvolupament necessita més informació sobre l’anàlisi, la comparació de resultats i els detalls de com s’han obtingut els resultats.
Es considera que l’informe de la prova és bo si és breu, descriptiu i fins al punt.
Com escriure un document d'estratègia de prova de rendiment?
Aquest tutorial explicarà com escriure una mostra d'estratègia de prova de rendiment per a una aplicació de missatgeria.
Recordeu que aquest és només un exemple i que els requisits seran diferents d'un client a un altre, també coneixerem les pràctiques recomanades per a la prova de rendiment en aquest tutorial.
Plantilla d'estratègia de prova de rendiment de mostra
Quant a l'aplicació de xat ABC: Suposem que es tracta d’un banc de treball de xat que el seu agent d’atenció al client utilitza en una empresa, aquesta aplicació de xat utilitza el protocol XMPP, és a dir, el protocol de presència i missatgeria extensible i el servidor Open Fire per enviar i rebre missatges instantanis.
S’han introduït algunes millores en aquest client de xat existent com ara control remot de PC, diagnòstic de PC, eines de reparació, xat en línia, etc., de manera que aquesta estratègia de prova de rendiment és una mostra d’aquestes aplicacions.
Per a aquesta aplicació, suposem que l'equip del projecte ha decidit utilitzar-lo JMeter per a proves de rendiment i JIRA per al seguiment de defectes.
La primera pàgina del document d’Estratègia de prova de rendiment ha de contenir el títol del document i els drets d’autor de l’empresa.
La segona pàgina ha de contenir Control de documents que inclou, historial de versions del document, llista de revisors i aprovadors i llista de col·laboradors.
La tercera pàgina hauria de contenir la taula de continguts, seguida dels temes següents.
#1. Introducció
L'objectiu d'aquest document és definir / explicar com es realitzaran les proves de rendiment a l'aplicació de xat ABC per a l'estat actual i futur.
L’aplicació de xat ABC és un banc de treball d’agent de suport remot intern. Aquest banc de treball s'utilitzarà per atendre les sol·licituds dels clients. Aquest banc de treball té funcions com ara xat en línia, identificació de clients, control remot de PC, diagnòstic de PC i eines de reparació.
Objectiu
Els objectius clau de les proves de rendiment són els següents:
- Per obtenir la confiança que els canvis a l’aplicació de xat existent compleixen l’acord de nivell de servei definit.
- Per garantir que el rendiment de l'aplicació, la disponibilitat del servei i l'estabilitat de l'aplicació no es vegin afectades com a conseqüència de les noves millores.
- Els temps de resposta a les transaccions es mantenen dins de la tolerància acceptable respecte al perfil de càrrega creixent.
- Les JVM mostren un ús de memòria estable en els perfils de càrrega creixents.
La imatge següent explica clarament el procés d’optimització i proves de rendiment:
Arquitectura
Heu d’incorporar el diagrama d’arquitectura del vostre projecte en aquesta sessió.
# 2) Abast
En Àmbit
A continuació es mostra l'abast de les proves de rendiment per al banc de treball del xat ABC:
- Adquisició de coneixement de les transaccions comercials clau i distribució de càrregues després de fer un estudi detallat del sistema.
- Identifiqueu els escenaris crítics per a les proves de rendiment amb ajuda de diferents pistes de projectes.
- Utilitzeu els resultats de la versió anterior com a base per a versions futures.
- Verifiqueu i valideu l'entorn de prova de rendiment i la infraestructura de l'eina de prova de rendiment / càrrega per a qualsevol màquina agent addicional.
- Preparació de guions de prova de rendiment mitjançant JMeter per als escenaris identificats que imiten la càrrega màxima identificada.
- Configureu la supervisió del rendiment als servidors per supervisar la prova per tal d’identificar els colls d’ampolla durant la fase d’execució de la prova.
- Publiqueu els resultats de les proves de rendiment.
- Coordineu-vos amb diverses parts interessades per resoldre els problemes de rendiment identificats.
- Feu una línia bàsica del nivell de rendiment per a futures versions.
Fora d'abast
- Proves funcionals , UAT, proves de sistemes i proves de seguretat.
- Proves / supervisió de rendiment de qualsevol interfície de tercers.
- Optimització del rendiment. (La majoria de les vegades la posada a punt la fa un equip diferent, si en cas que tingueu enginyers de rendiment per sintonitzar el sistema, podeu afegir-ho a Inscope).
- Perfils de codi / dimensionament de maquinari / planificació de la capacitat.
- Seguretat / Proves de vulnerabilitat / UAT / Proves de caixa blanca .
- Generació de dades per a proves de rendiment.
- Proves no funcionals ( Per exemple, migració per error, recuperació de desastres, còpia de seguretat, usabilitat) que no siguin les proves de rendiment.
- Proves de qualsevol solució mòbil.
- Prova i ajust de rendiment de les aplicacions de tercers.
- La realització de recomanacions de rendiment, els canvis de codi d'aplicació i els canvis de configuració de productes / servidors admesos pel proveïdor quedaran fora de l'abast des de la perspectiva de l'equip de rendiment.
- Suport a la infraestructura / Implementació de la construcció / Preparació de l’entorn / Restauració de bases de dades / Suport de xarxa, etc.
# 3) Enfocament
Les proves de rendiment del xat ABC es realitzaran mitjançant Jmeter escrivint complements XMPP personalitzats que utilitzin una biblioteca de smack per a connexions XMPP. Aquestes biblioteques s’utilitzen per configurar connexions, iniciar sessió i enviar missatges de xat al servidor XMPP.
Aquestes biblioteques s’inclouen en un fitxer jar que es desplega al Jmeter i està dissenyat en funció dels escenaris a provar. El banc de treball Jmeter s'instal·la a la màquina local que es connecta al servidor JMeter que té els generadors de càrrega per generar la càrrega necessària al sistema del servidor de xat per supervisar el comportament del sistema.
L’escenari de prova s’escriptarà mitjançant l’eina JMeter. Els scripts es personalitzarien segons es requereixi. La programació es crearà amb la pujada necessària per simular els escenaris del món real.
generació de dades de proves en proves de programari
L'escenari de prova es dividiria i es mesuraria en els aspectes següents:
a) Prova de referència: Per executar cada escenari amb 1 Vuser i diverses iteracions per tal d’identificar si el rendiment de l’aplicació compleix o no l’acord de nivell de servei empresarial.
b) Prova de càrrega base: Per complir amb el benchmark empresarial sota prova de càrrega, l’equip de proves de rendiment realitzarà una prova de càrrega base que ajudarà a identificar qualsevol problema de rendiment del sistema amb una càrrega creixent i crea la línia de base per al següent nivell de proves de rendiment.
c) Prova de càrrega màxima / escalabilitat: L’equip de proves de rendiment realitzarà múltiples proves amb Vusers creixents per satisfer la càrrega esperada i també mesurar el rendiment de l’aplicació per establir la corba de rendiment i identificar si el desplegament pot suportar els acords de nivell de servei sota la càrrega màxima de l’usuari.
Ajuda a la sintonització o planificació de la capacitat de les màquines virtuals Java (JVM) individuals, el nombre total de JVM necessàries i els processadors. Això s’aconseguirà augmentant el nombre de Vusers al 50%, 75%, 100% i 125% de la capacitat màxima.
d) Prova de resistència: L’equip de proves de rendiment realitzarà aquesta prova durant un període de 8 hores / 16 hores / 24 hores per identificar fuites de memòria, problemes de rendiment al llarg del temps i estabilitat general del sistema. Durant les proves de resistència, l’equip de proves de rendiment controla els indicadors clau de rendiment, com ara els temps de resposta de les transaccions i l’estabilitat de l’ús de la memòria.
Els recursos del sistema, com ara CPU, memòria i E / S, s'han de controlar amb l'ajut de l'equip del projecte.
Es considera que l'entorn de prova de rendiment és una rèplica de l'entorn de producció. Les proves s’executaran amb una càrrega incremental per identificar on falla l’aplicació.
Escenaris de proves de rendiment
Incloeu l’excel amb el conjunt d’escenaris.
Per exemple,
Escenari 1: Per validar el xat de l'agent i el client per X núm. de sessions simultànies.
Tipus de proves de rendiment
La taula que es mostra a continuació explica els diferents tipus de proves de rendiment juntament amb els seus objectius.
Tipus de prova | Objectiu |
---|---|
UAT | Proves d’acceptació d’usuaris |
Prova de referència | Establir el millor rendiment en volums específics que s’utilitzaran com a referència per a mesures posteriors. |
Prova de càrrega | Mesureu el rendiment del sistema sota la càrrega màxima de producció prevista. |
Prova de resistència | Mesurant l'estabilitat del sistema a un volum elevat durant un període prolongat. |
Prova d’estrès | Mesureu el rendiment del sistema en condicions desfavorables. |
Mètriques de rendiment
- Mètriques del costat del client
S.No | Mètrica | Descripció | Format |
---|---|---|---|
1 | Temps de resposta de transaccions | Temps de resposta de les pàgines durant l'estat estacionari de la prova de rendiment | Gràfic |
2 | Rendiment | La quantitat de dades que els VUsers han rebut del servidor al llarg del temps | Gràfic |
3 | Èxits / segon | El nombre de sol·licituds HTTP realitzades pels VUsers al servidor web durant l'execució de l'escenari | Gràfic |
4 | Nombre de transaccions superades / fallides | Nombre total de transaccions que han passat i han fallat durant l'execució de la prova | Excel |
5 | Percentatge d'errors de transacció | El percentatge de transaccions que han fallat durant l'execució de la prova | Gràfic |
- Mètriques de rendiment del sistema i de la xarxa
Activitats i lliuraments de proves de rendiment
# 4) Dades de prova
S'està assumint que les dades de l'entorn de rendiment seran una còpia de les dades de producció i que les dades de prova necessàries seran proporcionades per l'equip del projecte.
# 5) Criteris d'entrada i sortida
- Accés a totes les aplicacions de l’entorn.
- Preparació del medi ambient completa.
- Preparació de les dades de la prova de rendiment.
# 6) Gestió de defectes
- El mòdul de gestió de defectes de JIRA s’utilitzarà al projecte per al registre de defectes i per al seguiment fins al tancament.
- La identificació dels defectes que es trobin durant la fase d'execució de la prova es capturarà a JIRA i aquests defectes seran resolts per l'equip de desenvolupament segons les severitats següents.
- Les reunions de revisió de defectes es realitzarien diàriament amb la participació dels equips de proves, desenvolupament, analistes de qualitat i empreses.
- Els criteris per solucionar defectes serien estrictes a mesura que el projecte s’acosti a la data de publicació en directe. Les directrius per publicar els criteris de correcció de defectes a les reunions de revisió de defectes.
Definició de la gravetat del defecte
Les definicions dels codis de gravetat són les següents:
Gravetat | Descripció de problemes de desenvolupament i millora |
---|---|
Bloquejador | Error del sistema, mostra el tap, problemes de xarxa |
Crític | Errors del sistema, cap solució clara, interrupció o falta de funcionalitat empresarial |
Major | S'ha detectat un problema greu en què existeix la solució alternativa que potser no quedaria clara per a tots els usuaris, però no s'hauria de publicar el producte sense solucionar-ho |
Mitjà | Hi ha un problema amb el treball fàcil / senzill, però aquest tipus de defecte es pot alliberar després de l’aprovació de l’empresa i / o el cap de projecte |
baix | Problemes cosmètics que no interfereixen amb la funcionalitat empresarial o altres problemes intermitents que no es poden reproduir cada vegada |
# 7) Eines i tècniques de prova
Eines | Propòsit |
---|---|
Jmeter | Per verificar la càrrega i el rendiment de l'aplicació ABC Chat. |
# 8) Criteris de suspensió i represa
A continuació es detallen els criteris de suspensió i represa crítics que afectaran les activitats de prova:
Suspensió | Impacte | Represa |
---|---|---|
Entorn no configurat | Les proves no poden continuar | Preparació ambiental. |
S'ha trobat que l'aplicació és inestable | Les proves no poden continuar. | Problema resolt |
Les dades de prova no estan disponibles | Les proves no poden continuar. | Dades de prova llestes |
# 9) Prova de lliuraments
Els lliuraments de proves de rendiment inclouen:
- Estratègia de proves de rendiment
- Document de requisits de rendiment
- Document d'escenari de prova de rendiment
- Guions de prova de rendiment
- Resultats de la prova de rendiment
# 10) Funcions i responsabilitats
Els rols i les responsabilitats s’expliquen clarament a la taula que es mostra a continuació.
# 11) Riscos potencials i pla de mitigació
S.No | Risc | Probabilitat | Impacte | Pla de mitigació | Propietari |
---|---|---|---|---|---|
1 | Indisponibilitat de dades de prova per a execucions de proves de càrrega de rendiment | H | H | Les dates estimades per a les execucions de les proves de rendiment s'han de revisar i actualitzar. Es requereix suport funcional de l'equip de desenvolupament per a la recopilació de dades. | - |
2 | Qüestions ambientals | L | M | Torneu a donar prioritat als lliuraments | - |
3 | Canvi de funcionalitat / disseny durant l'execució de la prova de rendiment | M | H | Això requereix una reelaboració dels escenaris de prova de rendiment | - |
4 | S'executa un rendiment addicional per solucionar problemes de rendiment | M | H | Els horaris de proves de rendiment es modificarien i s’actualitzarien a l’equip del producte. | - |
5 | Les estimacions es preparen basant-se en una compilació de correcció d'errors per obtenir el rendiment. Diverses versions de correcció d'errors retardaran els cicles de prova i, finalment, depèn de quan estarà disponible la nova versió per tornar-la a executar. | H | H | Torneu a donar prioritat als cicles d’execució de la prova de rendiment. | - |
6 | Disponibilitat de maquinari | M | H | La data d'inici de la programació es mouria en conseqüència. | - |
# 12) Supòsits
- Performance Test Environment serà una rèplica del paisatge de l'arquitectura del producte. (és a dir, maquinari, programari, interfícies, capes d’integració, etc. correctes).
- Els scripts de rendiment es dissenyaran en funció dels fluxos crítics per als quals se’n faci un ús elevat.
- Tots els problemes d'infraestructura s'han de resoldre abans de començar les proves de rendiment. Qualsevol canvi de configuració del sistema fet posteriorment invalidarà els resultats de la prova.
- Una aplicació és estable i està preparada per utilitzar-se a l’entorn de proves de rendiment.
- Es posa a disposició dels recursos de maquinari i programari necessaris (com ara màquines generadores de càrrega / programari, màquines controlador / agent).
- Qualsevol canvi a l’abast passarà per un procés de control de canvis i l’equip de proves de rendiment avaluarà l’impacte de les línies de temps i els recursos.
- S'espera que els servidors respectius gestionin la càrrega.
- Els registres de rastreig d'aplicacions han d'estar habilitats per als sistemes de suport amb finalitats de supervisió.
# 13) Dependències
- Disponibilitat de l'entorn de prova de rendiment que és una rèplica del paisatge de l'arquitectura del producte.
- Suport necessari de diversos equips funcionals, de desenvolupament, de bases de dades i d'infraestructures durant les fases de preparació i execució de les proves.
- No s’implementen canvis de codi durant tota la fase de proves de rendiment, ja que el temps és molt limitat.
- En cas de problemes imprevistos que comportin restriccions dins dels terminis, si els terminis no permeten que es compleixin tots els àmbits de prova dins de les dates de fita originals, els gestors de versions disposen de suport per proporcionar una decisió d’abast i priorització.
- Els usuaris empresarials de la sol·licitud / Experts en matèria estaran disponibles per a aclariments funcionals i per a la finalització de les transaccions comercials.
- El gestor de programes de xat ABC revisarà i tancarà la sessió.
# 14) Abreviatures
Abreviatura | Descripció |
---|---|
DB | Base de dades |
http | Protocol de transferència d’hipertext |
JDBC | Connectivitat de bases de dades Java |
QA | Garantia de qualitat |
ENCUITES | Acord de nivell de servei |
PIME | Expert en la matèria |
A hores d'ara ja heu entès clarament com escriure una estratègia de prova de rendiment eficaç per a una aplicació de missatgeria.
Bones pràctiques per a proves de rendiment realistes
Per tal de completar amb èxit un projecte de prova de rendiment, hem d’assegurar-nos que ho fem de la manera correcta des de l’etapa de planificació, és a dir, planificació, desenvolupament, execució i anàlisi.
Fem una ullada a cada etapa amb detall per dur a terme les proves de rendiment amb eficàcia.
# 1) Planificació
- Intenteu identificar els fluxos de treball més comuns, és a dir, els escenaris empresarials que s'han de provar. Si l’aplicació ja existeix, comproveu els registres del servidor per comprendre els escenaris amb més accés. Si l'aplicació és nova, parleu amb l'equip de gestió de projectes per entendre el flux de negoci més important.
- Planifiqueu la prova de càrrega de manera que cobreixi una àmplia gamma de fluxos de treball, com ara l’ús de llum, l’ús mitjà i les càrregues màximes.
- Heu de realitzar molts cicles de la prova de càrrega, així que intenteu crear un framework per poder utilitzar els mateixos scripts una i altra vegada. A més, proveu de fer una còpia de seguretat dels scripts.
- Proveu d’analitzar quant de temps ha de dur a terme una prova, és d’una hora? 8 hores? Un dia o una setmana? Normalment, les proves de llarga durada descobriran molts defectes importants, com ara errors del sistema operatiu, fuites de memòria, etc.
- Si la vostra organització utilitza qualsevol APM (Application Monitoring Tool), podeu incloure-la durant les proves de manera que pugueu identificar fàcilment els problemes de rendiment i identificar la causa principal amb més facilitat.
# 2) Desenvolupament
- Mentre desenvolupeu els scripts, és a dir, enregistreu, intenteu donar un nom de transacció més significatiu basat en els noms del flux de negoci que s’esmenten al pla.
- No enregistreu cap aplicació de tercers i, si es registra, proveu de filtrar-la mentre milloreu els scripts.
- No tots els valors dinàmics es poden correlacionar mitjançant la funció Autocorrelació de l'eina, així que intenteu fer una correlació manual per evitar errors.
- Proveu de dissenyar les proves de rendiment de manera que colpegeu el dorsal de l'aplicació i no només el servidor de memòria cau.
# 3) Execució
- Assegureu-vos d'executar les proves en un entorn similar a la producció, inclosos factors com SSL, Load Balancer i Firewalls. Això és necessari per simular una càrrega realista al sistema.
- Proveu de crear una càrrega de treball que sigui molt realista; podeu obtenir-ho comprovant els registres del servidor si és una aplicació existent i si és una aplicació nova, heu de rebre aquesta informació de l’equip empresarial. Recordeu que la càrrega de treball és molt important per dur a terme proves de rendiment amb èxit.
- No arribeu mai a una conclusió realitzant proves amb la meitat de la mida de la producció, sempre s’aconsella realitzar proves en un entorn que sigui igual que la producció.
- Mentre executeu proves de llarga durada, intenteu veure la cursa a intervals freqüents per assegurar-vos que la prova funciona correctament.
# 4) Anàlisi
- Proveu d’analitzar l’aplicació afegint uns quants comptadors importants primer, quan es troba un coll d’ampolla, proveu d’afegir comptadors addicionals respecte al coll d’ampolla. Això, al seu torn, ajudarà a trobar el problema amb més facilitat.
- Una aplicació pot fallar per molts motius com pot respondre a una sol·licitud, respondre amb un codi d'error, fallar la lògica de validació o respondre massa lentament. Per tant, intenteu examinar tot això abans d’arribar a una conclusió.
Conclusió
Estic segur que aquest tutorial us hauria proporcionat un coneixement immens sobre les proves de rendiment i sobre com escriure un document d’estratègia de proves de rendiment amb exemples detallats.
Al nostre proper tutorial, coneixerem detalladament les diferències entre les proves de rendiment, càrrega i esforç.
A més, marqueu => Sèrie d'entrenament en profunditat LoadRunner gratuïta
Lectura recomanada
- Prova de rendiment vs Prova de càrrega vs Prova d’estrès (diferència)
- Prova de càrrega amb tutorials HP LoadRunner
- Proves de rendiment al núvol: proveïdors de serveis de proves de càrrega basades en el núvol
- Proves de càrrega, esforç i rendiment d'aplicacions web mitjançant WAPT
- Eines i serveis de proves de rendiment del lloc web
- Com es realitzen proves de rendiment manuals?
- Proves de rendiment d'aplicacions mòbils mitjançant BlazeMeter
- Proves de rendiment dels serveis web mitjançant LoadRunner VuGen Scripting