Una guia completa de proves no funcionals per a principiants

complete non functional testing guide

Una guia completa de proves no funcionals: el seu propòsit, tipus, eines i casos de prova amb exemples

Què és la prova no funcional?

Les proves no funcionals es fan per verificar el requisit no funcional de l'aplicació, com ara rendiment, usabilitat, etc.

Verifica si el comportament del sistema és o no segons el requisit. Cobreix tots els aspectes que no es tracten proves funcionals . En les nostres proves quotidianes, es presta molta atenció a les proves funcionals i als requisits funcionals.

Els clients també estan interessats a complir els requisits funcionals que estan directament relacionats amb la funcionalitat d’una aplicació. Però en la fase real, és a dir, quan se us fa una prova funcional, el programari surt al mercat i és utilitzat pels usuaris finals reals, i hi ha possibilitats d’afrontar alguns problemes relacionats amb el rendiment.

Aquests problemes no estan relacionats amb la funcionalitat del sistema, però poden afectar l'experiència de l'usuari de manera negativa. Per tant, és important que el programari o l’aplicació també es provin de requisits no funcionals per evitar l’experiència negativa del client.

Les proves es classifiquen generalment en dos tipus:

• Proves funcionals
• Proves no funcionals

Què aprendreu:

• Importància
• Propòsit
• Exemple
• Avantatges
• Com capturar requisits no funcionals?
  • # 1) Usuari / Històries tècniques
  • # 2) Criteris d'acceptació
  • # 3) A Artefactes
• Diferència en els requisits funcionals i no funcionals
• Es tracta de proves de Black Box o White Box?
• Llista de comprovació de casos de proves no funcionals
  • Llista de comprovació per a les proves de rendiment
  • Llista de comprovació de proves de seguretat
  • Llista de comprovació de proves de documentació
• Document d'aproximació
  • Abast de la prova
  • Mètriques de prova
  • Eines de prova
  • Dates clau i lliuraments
• Tipus de proves no funcionals
• Eines de prova no funcionals
  • # 1) Casos de prova de proves d’usabilitat
  • # 2) Casos de prova de proves de rendiment
  • # 3) Casos de proves de proves de seguretat
• Conclusió
• Lectura recomanada

Importància

Aquestes proves no van tenir l’atenció deguda tenint en compte que no afecta la funcionalitat del sistema.

Els requisits no funcionals tampoc no es van atendre adequadament en els cicles de prova anteriors. Ara bé, això ha canviat. Les proves no funcionals són ara més importants, ja que consideren tots els problemes de seguretat i rendiment de l’aplicació actualment.

Aquestes proves tenen un major impacte en les aplicacions pel que fa al rendiment de l'aplicació amb un elevat trànsit d'usuaris. Aquesta prova garanteix que la vostra aplicació sigui estable i sigui capaç de gestionar la càrrega en condicions extremes.

Com el seu propi nom indica, aquesta prova es concentra en l'aspecte no funcional de l'aplicació. Quins són, doncs, els aspectes no funcionals? O hauria de dir quines són les funcions que no estan relacionades amb la funcionalitat de l'aplicació?

Bé, aquí teniu les respostes a aquestes:

• Com funciona l’aplicació en circumstàncies normals?
• Com es comporta l'aplicació quan hi ha massa usuaris que inicien sessió simultàniament?
• L’aplicació pot gestionar l’estrès?
• Quina seguretat té l’aplicació?
• L'aplicació es pot recuperar d'un desastre?
• L'aplicació es pot comportar de la mateixa manera en un entorn o SO diferent?
• Què tan fàcil és portar l'aplicació en un sistema diferent?
• Els documents / manual d’usuari que s’ofereixen amb l’aplicació són fàcils d’entendre?

La llista continua. Però el punt aquí és que: aquestes funcions no contribueixen a la qualitat de l'aplicació? La resposta és SÍ. Aquestes característiques són igualment importants.

Imagineu que una aplicació compleix perfectament tots els requisits de l'usuari, però algun usuari no autoritzat va fàcilment i descifra les dades introduïdes per l'usuari a l'aplicació, o bé l'aplicació mor quan es carreguen més de 5 MB de qualsevol fitxer. Llavors diríeu que l’aplicació és de bona qualitat? Evidentment no està bé !!

Propòsit

L'únic propòsit d'aquest tipus de proves és assegurar-se que es provin els aspectes no funcionals de l'aplicació i que l'aplicació funcioni bé en el seu context.

L'objectiu és cobrir la prova de totes les característiques de l'aplicació que ajuden a proporcionar una aplicació que compleixi les expectatives del negoci.

Exemple

Aquest és un tipus de prova important.

Les proves funcionals posen a prova la funcionalitat de l’aplicació i garanteixen que funcioni com s’esperava, però la prova no funcional garanteix que l’aplicació funcioni prou bé per satisfer les expectatives del negoci.

Per comprendre la seva importància, prenem un exemple senzill:

Es desenvolupa una aplicació i es prova completament la seva funcionalitat, però les proves no funcionals no es realitzen amb la mateixa.

Mentrestant, quan l'aplicació es posa en funcionament, pot resultar en problemes crítics o importants, com quan augmenta la càrrega de l'aplicació, es torna massa lenta i triga molt a obrir-se.

El temps de resposta pot augmentar o quan la càrrega augmenta fins a un punt, l’aplicació pot fallar. Això mostra la importància de provar els aspectes no funcionals d’una aplicació.

Avantatges

A continuació, es detallen alguns dels avantatges d'una prova no funcional:

• Cobreix les proves que no es poden cobrir en les proves funcionals.
• Assegura que l’aplicació s’executa de manera eficient i prou fiable.
• Assegura la seguretat de l’aplicació.

Com capturar requisits no funcionals?

Mentre realitzem proves, el focus se centra principalment en proves funcionals que posen a prova la funcionalitat del producte. Però les proves no funcionals són tan importants com les proves funcionals i s’hauria de tenir en compte el seu requisit des dels inicis del producte.

Els requisits no funcionals s’utilitzen per realitzar proves no funcionals. Aquests requisits inclouen el rendiment de rendiment que s’espera de l’aplicació o del programari que es prova. Això inclou bàsicament el temps que ha trigat el programari a operar un sistema concret.

Els requisits no funcionals també capturen el comportament quan una gran quantitat de persones utilitza el programari alhora. La majoria de les vegades s’observa que els servidors estan ocupats o no estan disponibles a causa d’una càrrega elevada (és a dir, hi ha més gent que l’utilitza alhora). Reservar bitllets de ferrocarril en línia pot ser el millor exemple de tal situació.

Per tant, documentar correctament el requisit no funcional i realitzar les proves correctament assegurarà una gran satisfacció en termes d’usabilitat per part dels clients potencials.

Tot i que aquesta prova no té un impacte empresarial directe sobre la funcionalitat del sistema, pot augmentar l’experiència de l’usuari i la facilitat d’ús en major mesura que al seu torn tindrà un impacte més gran sobre la qualitat del programari.

Exemple:

Penseu en el mateix exemple de pàgina d'inici de sessió de Facebook. En aquest cas, l'abast de les proves no funcionals és assenyalar el temps que requereix el sistema per iniciar sessió a Facebook després d'introduir les credencials vàlides.

A més, es pot provar com quan (diguem-ne 100) que els usuaris inicien sessió al mateix temps, quant de temps triga a iniciar la sessió a Facebook.

Això garanteix que el sistema pugui gestionar la càrrega i el trànsit, que al seu torn té una bona experiència d'usuari.

En àgil, el requisit no funcional s’ha de capturar mitjançant entrades.

Un requisit no funcional s'ha de capturar com:

• Usuari / Històries tècniques
• A Criteris d’acceptació
• A Artefacte

9

# 1) Usuari / Històries tècniques

Es pot capturar un requisit no funcional mitjançant històries dels usuaris o històries tècniques. Capturar requisits no funcionals com a història de l'usuari és el mateix que capturar qualsevol altre requisit. L'única diferència entre l'usuari i una història tècnica és que la història de l'usuari requereix discussió i té visibilitat.

# 2) Criteris d'acceptació

Criteris d'acceptació és el punt que es defineix per a l'acceptació del producte pel client, és a dir, que el producte sigui acceptat als punts definits hauria d'estar en estat de passada.

S'ha d'incloure un requisit no funcional als criteris d'acceptació, però de vegades no és possible provar els requisits no funcionals amb cada història, és a dir, amb cada iteració. Per tant, els requisits s’han d’afegir o provar només amb la iteració corresponent.

# 3) A Artefactes

S’hauria de preparar un artefacte separat per als requisits no funcionals, que al seu torn ajudaria a tenir una millor idea del que s’ha de provar i de com es pot fer en les iteracions.

Diferència en els requisits funcionals i no funcionals

Hi ha diverses diferències entre els requisits funcionals i els no funcionals i alguns d’ells es detallen a continuació:

Lectures addicionals => Diferències entre proves funcionals i no funcionals

Es tracta de proves de Black Box o White Box?

La prova no funcional passa per un proves de caixa negra tècnica.

Aquesta tècnica no es limita a provar només les funcionalitats, sinó que també es pot utilitzar per provar els requisits no funcionals, així com el rendiment, la usabilitat, etc. La tècnica de prova de la caixa negra no requereix cap coneixement del sistema intern, és a dir, no requereix el coneixement del codi per al provador.

Llista de comprovació de casos de proves no funcionals

S'utilitza una llista de comprovació per assegurar-se que cap aspecte important no quedi sense proves.

Generalment s’utilitza una llista de comprovació quan no hi ha temps per a la documentació i s’ha de provar el producte o quan hi ha una limitació de temps, es pot utilitzar una llista de verificació per assegurar-se que s’han cobert tots els aspectes importants.

Vegem unexemplede llista de comprovació de rendiment, seguretat i documentació.

Llista de comprovació per a les proves de rendiment

• El temps de resposta de l'aplicació s'ha de verificar, és a dir, quant de temps triga a carregar-se l'aplicació, qualsevol entrada que es doni a l'aplicació proporciona la sortida en quant de temps, actualitzant el navegador, etc.
• Rendiment s'ha de verificar el nombre de transaccions realitzades durant una prova de càrrega.
• Medi ambient la configuració hauria de ser la mateixa que l’entorn actiu o bé els resultats no serien els mateixos.
• Temps de procés - Processar activitats com la importació i exportació d’Excel, s’haurien de provar els càlculs de l’aplicació.
• Interoperabilitat s’hauria de verificar, és a dir, un programari hauria de poder interaccionar amb l’altre programari o sistemes.
• ETL s’ha de verificar el temps, és a dir, el temps que s’ha trigat a extreure, transformar i carregar les dades d’una base de dades a una altra.
• Augment de la càrrega a l'aplicació s'ha de verificar.

Llista de comprovació de proves de seguretat

• Autenticació: Només un usuari autèntic hauria de poder iniciar la sessió.
• Autoritzat: L'usuari hauria de poder iniciar sessió en aquests mòduls només per als quals estigui autoritzat o per als quals l'usuari tingui accés.
• Contrasenya: S'ha de verificar el requisit de contrasenya, és a dir, la contrasenya hauria de ser tal com defineix el requisit, és a dir, la longitud, els caràcters especials, els números, etc.
• Temps d'espera: Si l'aplicació està inactiva, s'hauria d'espera en un temps especificat.
• Còpia de seguretat de dades: La còpia de seguretat de les dades s'hauria de fer en un moment determinat i s'hauria de copiar a una ubicació segura.
• Enllaços interns a l'aplicació web no hauria de ser accessible si es col·loca directament al navegador.
• Totes les comunicacions s’han d’encriptar.

Llista de comprovació de proves de documentació

• Documentació d'usuari i sistema.
• Documents amb finalitats de formació.

Document d'aproximació

Desenvolupeu un document d’enfocament específic per a l’etapa de la prova de rendiment afinant l’estratègia global de la prova. Aquest enfocament de prova guia en la planificació i execució de totes les tasques de prova de rendiment.

SQL consulta consulta pràctica respostes pdf

• Abast de la prova
• Mètriques de prova
• Eines de prova
• Dates clau i lliuraments

Abast de la prova

Realitzeu proves de rendiment des de diferents perspectives, com ara el rendiment dels usuaris, processos empresarials, estabilitat del sistema, consum de recursos, etc. Els tipus de proves de rendiment a executar es discuteixen a la secció anterior de l'article (com ara Prova de càrrega, Prova d'esforç, etc.)

Mètriques de prova

L'enfocament de prova perfecciona les mètriques per mesurar i informar durant la prova, com ara:

• Temps de resposta (en línia)
• Finestra per lots (per lots)
• Rendiment ( Per exemple , el nombre de transaccions per unitat de temps)
• Utilització ( Per exemple , el percentatge de recursos utilitzats)

Eines de prova

La majoria de proves de rendiment requereixen l’ús d’eines adequades:

• Eines de generació de càrregues
• Eines de control de rendiment
• Eines d’anàlisi del rendiment
• Eines de perfil d'aplicacions
• Eines de revestiment de bases.

Dates clau i lliuraments

El document d’enfocament de la prova de rendiment ha de descriure el següent:

• Data i hora de cada prova de rendiment.
• Tipus de proves i combinació de funcionalitats que s’inclouran a cada conducta de la prova de rendiment.
• Dates de finalització de la prova de rendiment.

Tipus de proves no funcionals

La imatge següent mostra els tipus de proves no funcionals:

Proves de rendiment:

Avalua el rendiment global del sistema .

Els elements clau són els següents:

• Valida que el sistema compleixi el temps de resposta esperat.
• Avalua que els elements significatius de l'aplicació compleixen el temps de resposta desitjat.
• També es pot dur a terme com a part de les proves d’integració i de proves del sistema.

Prova de càrrega:

Avalua si el rendiment del sistema és l’esperat en condicions normals i esperades.

Els punts clau són:

• Valida que el sistema funciona com s'esperava quan els usuaris concurrents accedeixen a l'aplicació i obtenen el temps de resposta esperat.
• Aquesta prova es repeteix amb diversos usuaris per obtenir el temps de resposta i el rendiment.
• En el moment de fer les proves, la base de dades hauria de ser realista.
• La prova s'ha de realitzar en un servidor dedicat que estimuli l'entorn real.

Proves d’estrès:

Avalua si el rendiment del sistema és l’esperat quan es disposa de pocs recursos.

Els punts clau són:

• Proveu amb poca memòria o poc espai de disc en clients / servidors que revelin els defectes que no es poden trobar en condicions normals.
• Diversos usuaris fan les mateixes transaccions amb les mateixes dades.
• Hi ha diversos clients connectats als servidors amb càrregues de treball diferents.
• Reduïu el temps de pensament a 'zero' per estressar els servidors al màxim.

Think Time: Igual que l’interval de temps entre escriure l’usuari i la contrasenya.

Prova de volum:

Avalua el comportament del programari quan es tracta d’un gran volum de dades.

Els punts clau són:

• Quan el programari està subjecte a grans quantitats de dades, comprova el límit en què falla el programari.
• Es crea la mida màxima de la base de dades i diversos clients consulten la base de dades o creen un informe més gran.
• Exemple - Si l’aplicació està processant la base de dades per crear un informe, una prova de volum seria utilitzar un conjunt de resultats gran i comprovar si l’informe s’imprimeix correctament.

Proves d'usabilitat:

Avalua el sistema per a ús humà o comprova si és apte per al seu ús.

Els punts clau són:

• El resultat és correcte i significatiu i és el mateix que s’esperava segons el negoci?
• Els errors es diagnostiquen correctament?
• La interfície gràfica d’usuari és correcta i coherent amb l’estàndard?
• És fàcil d'utilitzar l'aplicació?

Prova de la interfície d'usuari:

Avalua la GUI.

Els punts clau són:

• La GUI hauria de proporcionar ajuda i consells d’informació per facilitar-ne l’ús.
• Coherent pel seu aspecte?
• Les dades es recorren correctament d'una pàgina a una altra?
• La interfície gràfica d’usuari no hauria de molestar l’usuari ni ser difícil d’entendre.

Proves de compatibilitat:

Avalua que l'aplicació és compatible amb altres programes i maquinari amb una configuració mínima i màxima.

Els punts clau són:

• Proveu cada maquinari amb la configuració mínima i màxima.
• Prova amb diferents navegadors.
  Els casos de prova són els mateixos que es van executar durant les proves funcionals.
• En cas que el nombre de maquinari i programari sigui massa elevat, podem utilitzar tècniques OATS per arribar als casos de prova per tenir la màxima cobertura.

Proves de recuperació:

Valora que l'aplicació finalitza amb gràcia en cas de fallada i que les dades es recuperen adequadament de qualsevol fallada de maquinari i programari.

Les proves no es limiten als punts següents:

• Interrupció de corrent, al client mentre realitza activitats CURD.
• Punteres i claus de base de dades no vàlides.
• El procés de la base de dades s’interromp o s’acaba prematurament.
• Els indicadors, els camps i les claus de la base de dades es corrompen manualment i directament a la base de dades.
• Desconnecteu físicament la comunicació, apagueu-la, apagueu els encaminadors i els servidors de xarxa.

Proves d’inestabilitat:

Avalua i confirma si el programari s’instal·la i desinstal·la correctament.

els 5 millors descarregadors mp3 per a Android

Els punts clau són:

• Valida que els components del sistema s’instal·lin correctament al maquinari designat.
• Valida que la navegació a la nova màquina actualitzi la instal·lació existent i les versions anteriors.
• Valida que si no hi ha prou espai al disc, no hi ha cap comportament inacceptable.

Proves de documentació:

Avalua els documents i altres manuals d'usuari.

Els punts clau inclouen:

• Valida que els documents indicats estiguin disponibles al producte.
• Valida totes les guies de l'usuari, instruccions de configuració, llegiu-me fitxers, llançament de notes i ajuda en línia.

Proves de relleu:

Les proves de commutació per error es fan per comprovar que en cas de fallada del sistema, el sistema és prou capaç de manejar recursos addicionals com els servidors.

Per evitar aquesta situació, les proves de còpia de seguretat tenen un paper important. El procés consisteix en crear un sistema de còpia de seguretat. Si la còpia de seguretat està disponible, us ajudarà a recuperar el sistema.

Proves de seguretat:

Proves de seguretat es fa per garantir que l'aplicació no tingui escletxes que puguin comportar pèrdues de dades o amenaces. És un dels aspectes importants de les proves no funcionals i, si no es realitza correctament, pot comportar amenaces a la seguretat.

Inclou proves d'autenticació, autorització, integritat i disponibilitat.

Proves d’escalabilitat:

Es fan proves d’escalabilitat per verificar si l’aplicació és prou capaç de gestionar l’augment del trànsit, del nombre de transaccions, del volum de dades, etc.

Proves de compliment:

Es fan proves de conformitat per verificar si s’estan seguint o no els estàndards definits. Es fan auditories per verificar-ho.

Per a Exemple , Es fan auditories per verificar el procés de creació de casos de prova / plans de prova i situar-los a la ubicació compartida amb el nom estàndard que s'està fent o no. A QC, mentre es nomena els casos de prova, es segueix o no el nom de cas de prova estàndard. La documentació és completa o aprovada o no.

Aquests són els pocs indicadors que es tracten durant l'auditoria.

Proves de resistència:

Proves de resistència es fa per verificar el comportament del sistema quan la càrrega augmenta fins a un cert punt durant molt de temps.

També s’anomena prova de remull i prova de capacitat. Ajuda a verificar si hi ha fuites de memòria al sistema. Les proves de resistència són un subconjunt de les proves de càrrega.

Proves de localització:

Proves de localització es fa per verificar l'aplicació en diferents idiomes, és a dir, en diferents configuracions regionals. L'aplicació s'ha de verificar per a una cultura o una configuració regional determinada. L’objectiu principal és provar el contingut, la GUI de l’aplicació.

Proves d’internacionalització:

Proves d’internacionalització també es coneix com a prova i18n.

I18n representa I –dehuit lletres- N. Es fa per verificar si l'aplicació funciona com s'esperava en tots els paràmetres d'idioma. Verifica que qualsevol funcionalitat o aplicació en si no es trenqui, és a dir, l’aplicació hauria de ser prou capaç de gestionar tots els paràmetres internacionals.

També verifica que l'aplicació s'instal·la sense problemes.

Proves de fiabilitat:

Es fan proves de fiabilitat per verificar si l'aplicació és fiable i es prova durant un període de temps específic a l'entorn definit. Una aplicació ha de donar la mateixa sortida que s’esperava cada vegada, només llavors es pot considerar fiable.

Proves de portabilitat:

Les proves de portabilitat es fan per verificar si en cas que s’instal·li un programari / aplicació en un sistema diferent o en una plataforma diferent, s’hauria de poder executar com s’esperava, és a dir, no s’hauria d’afectar cap funcionalitat a causa d’un canvi en l’entorn.

Durant les proves, també cal provar el canvi amb la configuració de maquinari, com ara l’espai del disc dur, el processador i també amb diferents sistemes operatius, per garantir que el comportament correcte de l’aplicació i la funcionalitat esperada estiguin intactes.

Proves de referència:

Les proves de referència també es coneixen com proves de referència ja que crea una base per provar qualsevol aplicació nova.

Per exemple: A la primera iteració, el temps de resposta d’una aplicació era de 3 segons. Ara s’ha definit com a referència per a la següent iteració i, en la següent, el temps de resposta canvia a 2 segons. Bàsicament és un document de validació que s’utilitza com a base per a futures referències.

Proves d'eficiència:

Es fan proves d’eficiència per verificar si l’aplicació funciona de manera eficient i el nombre de recursos necessaris, eines necessàries, complexitat, requisits del client, entorn requerit, temps, quin tipus de projecte es tracta, etc.

Aquests són alguns dels indicadors que ajudarien a definir l'eficàcia d'una aplicació si tots els paràmetres considerats funcionin com s'esperava.

Proves de recuperació de desastres:

Aquesta prova es realitza per verificar la taxa d’èxit de recuperació d’una aplicació o sistema si es produeix algun error crític i si el sistema és capaç de restaurar les dades i l’aplicació o si el sistema podria fer front fàcilment per tornar la forma en què funcionava abans, és a dir, de el front operatiu.

Proves de manteniment:

Un cop l'aplicació / el producte es publiqui, hi ha probabilitats que aparegui un problema a l'entorn actiu o el client pugui desitjar una millora per a l'aplicació que ja està publicada.

En aquest cas, l'equip de proves de manteniment està disponible per provar els escenaris esmentats anteriorment. Un cop l'aplicació es posi en funcionament, encara necessita manteniment per al qual treballa l'equip de proves de manteniment.

Eines de prova no funcionals

Hi ha diverses eines disponibles al mercat per fer proves de rendiment (càrrega i esforç).

Poques d'elles es detallen a continuació:

• JMeter
• Loadster
• Loadrunner
• Tempesta de càrrega
• Neoload
• Previsió
• Càrrega completa
• Eina d'estrès del servidor web
• WebLoad Professional
• Loadtracer
• vPerformer

Les proves no funcionals es duen a terme sempre sense documentació ni casos de proves? Per què?

“Sempre ens ensenyen a escriure casos de proves funcionals. Per què això? Les proves no funcionals es duen a terme sense documentació (és a dir, de manera ad hoc) o és un procés independent que és molt més difícil d’entendre? Com s’escriuen casos de prova per a diferents tipus de proves que es produeixen en una aplicació? '

Aquesta és una de les preguntes més originals, distintives i senzilles, que m’han fet en els darrers temps. Anem a trobar la resposta.

Com és que mai no podem veure i practicar l’escriptura de casos de prova no funcionals?

Comencem pel que sabem i com sempre un escenari pràctic.

Exemple: A continuació es detallen els passos que cal fer en una aplicació de banca en línia per realitzar una transferència. Utilitzem això com a prova de referència.

1. Inicieu la sessió al lloc.
2. Trieu el compte bancari.
3. Trieu el beneficiari (aquest beneficiari podria pertànyer al mateix banc o a un altre), depèn de la vostra tria de dades per executar aquest pas. En qualsevol cas, trieu-ne un. A més, assumirem que el beneficiari ja està afegit.) .
4. Introduïu l'import a transferir (valor positiu, dins del límit, format correcte, etc.).
5. Feu clic a Transferència i comproveu si es rep la confirmació, si s’ha actualitzat el saldo del compte i tot això.

Aquest és el cas de la prova funcional, oi?

A la mateixa aplicació, a la mateixa pàgina de transferències, diguem que estem rendint Proves de rendiment, seguretat i usabilitat . Són tipus no funcionals, oi?

Com escriuríem els casos de prova?

# 1) Casos de prova de proves d’usabilitat

Les proves d’usabilitat són un gènere de proves de programari que tracta l’experiència de l’usuari. Aquestes són algunes de les preguntes a les que intentem respondre.

• Què tan fàcil és l’aplicació?
• Quina satisfacció té l’experiència d’utilitzar el sistema?
• Si no és tan familiar de seguida, què tan fàcil és aprendre?

Aquí hi ha més informació: Guia de proves d’usabilitat

Com determinaria un usuari les respostes a les preguntes anteriors en el context de les proves d’usabilitat?

L'usuari realitzaria els mateixos passos que fer en el cas de la prova funcional. Tinc raó?

# 2) Casos de prova de proves de rendiment

Hi ha diverses variacions en les proves de rendiment, però, bàsicament, s’utilitza per obtenir estadístiques sobre el sistema, la seva utilització de recursos, el temps de resposta, el consum de xarxa, etc. en diversos punts de càrrega.

Consulteu el nostre Tutorials de proves de rendiment per saber-ne més.

Ara, si hagués de provar el rendiment de la transacció de les transferències, tindria 10, 20, 30, 100 ... 1000 ... etc. usuaris que realitzessin l'operació de transferència simultàniament o incrementalment, segons el que vull orientar i recopilar dades.

Quins passos realitzaria cada usuari per utilitzar la transferència mentre es realitza la prova de rendiment?

Els mateixos passos exactes que la prova funcional, oi?

# 3) Casos de proves de proves de seguretat

Les proves de seguretat són una branca de control de qualitat que ajuda a fer que els sistemes de programari siguin a prova de pirates. Identifica les vulnerabilitats (possibles àrees problemàtiques del sistema de programari), les explota mitjançant la tècnica de prova de penetració o barret blanc i, quan es troben bucles, es treballen.

Quan vull comprovar si les transferències són a prova de pirates i estan dirigides correctament als destinataris previstos i que no hi ha punts negres en tot el procés? Realitzaria la transferència mentre el procés de supervisió de les fuites de seguretat continua en paral·lel.

Per tant, efectivament, estic realitzant exactament els mateixos passos que faria normalment en cas d’un cas de prova funcional.

Suposo que en tenim prou per establir que els passos de totes les situacions són els mateixos. El mètode i la intenció darrere del procés són els diferents.

Fem una mirada comparativa:

El que és interessant de remarcar és que independentment de la forma de prova que vulguem fer, tots els passos són els mateixos .

La diferència real és que:

1. Qui realitza aquests passos?
2. Quina intenció, o dit d’una altra manera, què intento aconseguir mitjançant aquesta prova?
3. Les eines i tècniques utilitzades.

Tornant a la nostra pregunta, per què no aprenem mai a escriure casos de prova no funcionals amb tots els passos detallats que hi ha?

És perquè ,bàsicament, els passos de prova per a una variació dels tipus de prova en una determinada funció són iguals, funcionals o no. És la intenció la que marca la diferència i potser el mètode.

Conclusió

Abans de realitzar proves no funcionals, és fonamental planificar correctament l’estratègia de prova per assegurar-ne la correcta. Hi ha diferents eines disponibles al mercat per realitzar aquest tipus de proves com Load Runner, RPT, etc.

Aquestes proves tenen un paper important en l'èxit d'una aplicació i en la bona relació amb el client i, per tant, no s'ha de descuidar. Aquesta és una de les parts importants de les proves de programari i les proves no es poden considerar completes sense això.

Podem incloure detalls de proves no funcionals al pla de prova o bé podem crear-ne una estratègia independent. En qualsevol cas, l'objectiu és tenir una cobertura adequada d'aspectes no funcionals del programari.

Esperem que aquest procés d’aprofundiment en aquest tema us hagi estat tan divertit com s’ha presentat a tots vosaltres. Ens encantaria escoltar els vostres comentaris i opinions sobre aquest tema.

Com gestiona les proves no funcionals als vostres equips? I, com sempre, feu-nos saber si esteu d’acord o en desacord o teniu alguna cosa que afegir al que estem passant aquí.

Lectura recomanada

• Proves funcionals contra proves no funcionals
• Proves alfa i proves beta (guia completa)
• Guia de proves de seguretat d'aplicacions web
• Guia completa de proves funcionals amb els seus tipus i exemples
• Guia completa de proves de verificació de compilació (proves BVT)
• Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
• Guia per a principiants sobre proves de penetració d'aplicacions web
• Guia completa de proves de càrrega per a principiants