Menú

Tipus de proves de programari: diferents tipus de proves amb detalls

types software testing

Proveu El Nostre Instrument Per Eliminar Problemes

Quins són els diferents tipus de proves de programari?

Nosaltres, com a provadors, som conscients dels diversos tipus de proves de programari, com ara proves funcionals, proves no funcionals, proves d’automatització, proves àgils i els seus subtipus, etc.

Cadascun de nosaltres hauríem trobat diversos tipus de proves en el nostre viatge de proves. És possible que n’haguéssim escoltat algunes i n’haguéssim pogut treballar, però no tothom en té coneixement sobre tots els tipus de proves.

Diferents tipus de proves de programari

Cada tipus de prova també té les seves pròpies característiques, avantatges i desavantatges. No obstant això, en aquest article he tractat sobretot tots els tipus de proves de programari que solem utilitzar en el nostre dia a dia de proves.

Anem a mirar-los.

Què aprendreu:

Diferents tipus de proves de programari

A continuació es mostra la llista d'alguns tipus comuns de proves de programari:

Els tipus de proves funcionals inclouen:

  • Proves unitàries
  • Proves d’integració
  • Proves del sistema
  • Proves de seny
  • Proves de fum
  • Proves d'interfície
  • Proves de regressió
  • Prova beta / acceptació

Els tipus de proves no funcionals inclouen:

  • Proves de rendiment
  • Prova de càrrega
  • Proves d’estrès
  • Proves de volum
  • Proves de seguretat
  • Proves de compatibilitat
  • Instal·la la prova
  • Proves de recuperació
  • Proves de fiabilitat
  • Proves d’usabilitat
  • Proves de compliment
  • Proves de localització

Vegem més detalls sobre aquests tipus de proves.

Tipus de proves de programari

# 1) Prova d'alfa

És el tipus de prova més comú utilitzat a la indústria del programari. L'objectiu d'aquestes proves és identificar tots els possibles problemes o defectes abans de llançar-los al mercat o a l'usuari.

La prova alfa es realitza al final de la fase de desenvolupament de programari, però abans de la prova beta. Tot i així, es poden fer canvis de disseny menors com a resultat d’aquestes proves.

Proves alfa es realitza al lloc del desenvolupador. Es pot crear un entorn d'usuari virtual intern per a aquest tipus de proves.

# 2) Proves d'acceptació

An Prova d’acceptació el realitza el client i verifica si el flux del sistema de punta a punta és o no segons els requisits empresarials i si és segons les necessitats de l'usuari final. El client només accepta el programari quan totes les funcions i funcionalitats funcionen com s’esperava.

És l'última fase de les proves, després de la qual el programari entra en producció. Això també s’anomena Proves d’acceptació d’usuaris (UAT).

# 3) Proves ad-hoc

El propi nom suggereix que es realitzen aquestes proves un ad-hoc base, és a dir, sense cap referència al cas de la prova i també sense cap pla ni documentació en vigor per a aquest tipus de proves.

L'objectiu d'aquestes proves és trobar els defectes i trencar l'aplicació executant qualsevol flux de l'aplicació o qualsevol funcionalitat aleatòria.

Les proves ad-hoc són una forma informal de trobar defectes i poden ser realitzades per qualsevol persona del projecte. És difícil identificar defectes sense un cas de prova, però de vegades és possible que els defectes trobats durant les proves ad-hoc no s’hagin identificat mitjançant casos de prova existents.

# 4) Proves d’accessibilitat

L'objectiu de Proves d’accessibilitat consisteix a determinar si el programari o l'aplicació és accessible per a persones amb discapacitat o no.

Aquí, discapacitat significa sords, daltònics, discapacitats mentals, cecs, vellesa i altres grups amb discapacitat. Es realitzen diversos controls, com ara la mida de la lletra per a discapacitats visuals, el color i el contrast per a la daltonisme, etc.

Windows 10 la passarel·la predeterminada no està disponible

# 5) Prova beta

Prova beta és un tipus formal de proves de programari que realitza el client. Es realitza a l'entorn real abans de llançar el producte al mercat per als usuaris finals reals.

Les proves beta es realitzen per assegurar-se que no hi hagi fallades importants al programari o al producte i que compleixin els requisits empresarials des de la perspectiva de l'usuari final. La prova beta té èxit quan el client accepta el programari.

Normalment, aquesta prova la fan normalment els usuaris finals o altres. És la prova final feta abans de llançar una aplicació amb finalitats comercials. Normalment, la versió beta del programari o producte publicat es limita a un nombre determinat d’usuaris en una àrea específica.

Per tant, l’usuari final utilitza el programari i comparteix els comentaris amb l’empresa. Llavors, l'empresa pren les mesures necessàries abans de llançar el programari a tot el món.

# 6) Prova de fons

Sempre que s'introdueix una entrada o dades a l'aplicació frontal, s'emmagatzema a la base de dades i la prova d'aquesta base de dades es coneix com a Prova de base de dades o Prova de fons.

Hi ha diferents bases de dades com SQL Server, MySQL i Oracle, etc. La prova de bases de dades consisteix a provar l'estructura de la taula, l'esquema, el procediment emmagatzemat, l'estructura de dades, etc.

A la GUI de prova de fons no hi participa, els provadors estan connectats directament a la base de dades amb un accés adequat i els verificadors poden verificar les dades fàcilment executant algunes consultes a la base de dades.

Hi pot haver problemes identificats com la pèrdua de dades, el bloqueig, la corrupció de dades, etc. durant aquesta prova de fons, i aquests problemes són fonamentals per solucionar-los abans que el sistema passi a l’entorn de producció.

# 7) Prova de compatibilitat del navegador

És un subtipus de proves de compatibilitat (que s’explica a continuació) i el realitza l’equip de proves.

Proves de compatibilitat del navegador es realitza per a aplicacions web i garanteix que el programari es pot executar amb la combinació de diferents navegadors i sistemes operatius. Aquest tipus de proves també valida si l'aplicació web s'executa en totes les versions de tots els navegadors o no.

# 8) Proves de compatibilitat cap enrere

És un tipus de proves que valida si el programari recentment desenvolupat o el programari actualitzat funciona bé amb la versió anterior de l’entorn o no.

La prova de compatibilitat cap enrere comprova si la nova versió del programari funciona correctament amb el format de fitxer creat per una versió anterior del programari; també funciona bé amb taules de dades, fitxers de dades, estructura de dades creada per la versió anterior d'aquest programari.

Si algun dels programes s’actualitza, hauria de funcionar bé a la versió anterior d’aquest programari.

# 9) Prova de Black Box

El disseny intern del sistema no es té en compte en aquest tipus de proves. Les proves es basen en els requisits i la funcionalitat.

Informació detallada sobre els avantatges, desavantatges i tipus de proves de caixa negra es pot veure aquí .

# 10) Prova de valor límit

Aquest tipus de proves comprova el comportament de l'aplicació a nivell de límit.

Proves de valor límit es realitza per comprovar si existeixen defectes als valors límit. La prova del valor límit s’utilitza per provar un rang diferent de nombres. Hi ha un límit superior i inferior per a cada rang i es fan proves sobre aquests valors de límit.

Si la prova requereix un interval de proves de nombres d’1 a 500, la prova de valor límit es realitza amb valors de 0, 1, 2, 499, 500 i 501.

# 11) Prova de sucursal

És un tipus de prova de caixa blanca i es realitza durant la prova unitària. Proves de sucursals, el propi nom suggereix que el codi es prova a fons recorrent totes les branques.

# 12) Proves de comparació

La comparació de la fortalesa i els punts febles d’un producte amb les seves versions anteriors o altres productes similars s’anomena prova de comparació.

# 13) Proves de compatibilitat

És un tipus de prova en què valida el comportament i l'execució del programari en un entorn, servidors web, maquinari i entorn de xarxa diferents.

Proves de compatibilitat assegura que el programari es pot executar en una configuració diferent, una base de dades diferent, diferents navegadors i les seves versions. Les proves de compatibilitat les realitza l’equip de proves.

# 14) Prova de components

La realitzen principalment els desenvolupadors després de finalitzar les proves d’unitats. Proves de components implica la comprovació de múltiples funcionalitats com un únic codi i el seu objectiu és identificar si existeix algun defecte després de connectar aquestes múltiples funcionalitats entre si.

# 15) Proves d'extrem a extrem

Similar a les proves del sistema, Proves de punta a punta implica provar un entorn d’aplicació complet en una situació que imita l’ús del món real, com ara interactuar amb una base de dades, utilitzar comunicacions de xarxa o interactuar amb altres maquinari, aplicacions o sistemes, si s’escau.

# 16) Particionament d'equivalència

És una tècnica de prova i un tipus de Black Box Testing. Durant això Particionament d'equivalències , se selecciona un conjunt del grup i es recullen uns quants valors o números per provar-los. S'entén que tots els valors d'aquest grup generen la mateixa sortida.

L'objectiu d'aquestes proves és eliminar casos de proves redundants dins d'un grup específic que genera la mateixa sortida però no cap defecte.

Suposem que l’aplicació accepta valors entre -10 a +10, de manera que mitjançant la partició d’equivalència els valors recollits per a la prova són zero, un valor positiu i un valor negatiu. Per tant, el particionat d’equivalència per a aquesta prova és de -10 a -1, 0 i 1 a 10.

# 17) Exemple de proves

Vol dir proves en temps real. La prova d’exemple inclou l’escenari en temps real, també inclou escenaris basats en l’experiència dels verificadors.

# 18) Proves exploratòries

Les proves exploratòries són proves informals realitzades per l'equip de proves. L'objectiu d'aquesta prova és explorar l'aplicació i buscar defectes que hi hagi a l'aplicació.

De vegades pot passar que durant aquesta prova, un defecte important descobert pugui causar fins i tot un error del sistema.

Durant les proves exploratòries, és recomanable fer un seguiment del flux que heu provat i de l'activitat que heu fet abans de l'inici del flux específic.

Una tècnica de proves exploratòries es realitza sense documentació ni casos de prova.

# 20) Proves funcionals

Aquest tipus de proves ignora les parts internes i se centra només en la sortida per comprovar si és segons el requisit o no. És una prova de tipus Black-box orientada als requisits funcionals d’una aplicació. Per obtenir informació detallada sobre les proves funcionals, feu clic a aquí .

# 21) Prova de la interfície gràfica d'usuari (GUI)

L'objectiu d'aquestes proves GUI és validar la GUI segons el requisit empresarial. La GUI esperada de l’aplicació s’esmenta a les pantalles de maquetes del Document de disseny detallat i de la GUI.

La prova de la GUI inclou la mida dels botons i el camp d'entrada presents a la pantalla, l'alineació de tot el text, les taules i el contingut de les taules.

millor lloc de descàrrega de música per a Android

També valida el menú de l’aplicació, després de seleccionar diferents elements de menú i menú, valida que la pàgina no fluctuï i l’alineació continua sent la mateixa després de passar el ratolí al menú o al submenú.

# 22) Proves de goril·les

La prova de goril·les és un tipus de prova que realitza un provador i, de vegades, també el desenvolupador. A Gorilla Testing, un mòdul o la funcionalitat del mòdul es comprova exhaustivament i a fons. L'objectiu d'aquestes proves és comprovar la robustesa de l'aplicació.

# 23) Prova de camí feliç

L'objectiu de Happy Path Testing és provar amb èxit una aplicació en un flux positiu. No busca condicions negatives ni d'error. L'enfocament només es posa en les entrades vàlides i positives a través de les quals l'aplicació genera el resultat esperat.

# 24) Proves d’integració incremental

Proves d’integració incremental és un enfocament ascendent per provar, és a dir, la prova contínua d’una aplicació quan s’afegeix una nova funcionalitat. La funcionalitat i els mòduls de l’aplicació han de ser prou independents per provar-los per separat. Ho fan els programadors o els provadors.

# 25) Instal·lar / desinstal·lar proves

Proves d'instal·lació i desinstal·lació es realitza en processos d’instal·lació / desinstal·lació completa, parcial o d’actualització de diferents sistemes operatius en entorns de maquinari o programari diferents.

# 26) Proves d'integració

La prova de tots els mòduls integrats per verificar la funcionalitat combinada després de la integració s'anomena Proves d’integració .

Els mòduls solen ser mòduls de codi, aplicacions individuals, aplicacions de client i servidor en una xarxa, etc. Aquest tipus de proves és especialment rellevant per als sistemes client / servidor i distribuïts.

# 27) Prova de càrrega

És un tipus de proves no funcionals i l'objectiu de les proves de càrrega és comprovar la quantitat de càrrega o càrrega de treball màxima que pot suportar un sistema sense cap degradació del rendiment.

Les proves de càrrega ajuden per trobar la capacitat màxima del sistema sota càrrega específica i qualsevol problema que causi una degradació del rendiment del programari. Les proves de càrrega es realitzen mitjançant eines com JMeter , LoadRunner, WebLoad, Silk performer, etc.

# 28) Prova de mico

Proves de mico es duu a terme per un provador assumint que si el mico utilitza l'aplicació, de quina manera s'introdueixi aleatòriament, els valors seran introduïts pel mico sense cap coneixement ni comprensió de l'aplicació.

L'objectiu de Monkey Testing és comprovar si una aplicació o sistema es bloqueja proporcionant dades / valors d'entrada aleatoris. La prova de mico es realitza de manera aleatòria i no s’escriptura cap cas de prova i no cal fer-ho

La prova de mico es realitza aleatòriament i no s’escriuen cap cas de prova i no cal ser conscient de la plena funcionalitat del sistema.

# 29) Prova de mutació

Proves de mutació és un tipus de prova de caixa blanca en què es canvia el codi font d’un dels programes i es verifica si els casos de prova existents poden identificar aquests defectes al sistema.

El canvi en el codi font del programa és molt mínim perquè no afecti tota l'aplicació, només l'àrea afectada i els casos de prova relacionats haurien de poder identificar aquests errors al sistema.

# 30) Proves negatives

Els verificadors que tenen la mentalitat d ''actitud de trencar' i que utilitzen proves negatives ho validen si el sistema o l'aplicació es trenquen. Una tècnica de proves negatives es realitza amb dades incorrectes, dades o dades no vàlides. Valida que si el sistema genera un error d'entrada no vàlida i es comporta com s'esperava.

# 31) Proves no funcionals

És un tipus de proves per a les quals totes les organitzacions tenen un equip separat que normalment es denomina equip de prova no funcional (NFT) o equip de rendiment.

Proves no funcionals implica proves de requisits no funcionals, com ara proves de càrrega, proves d’estrès, seguretat, volum, proves de recuperació, etc.

No hauria de trigar molt a carregar cap pàgina o sistema i hauria de mantenir-se durant la càrrega màxima.

# 32) Prova de rendiment

Aquest terme s'utilitza sovint indistintament amb proves de 'tensió' i 'càrrega'. Proves de rendiment es fa per comprovar si el sistema compleix els requisits de rendiment. Per fer aquesta prova s’utilitzen diferents eines de rendiment i càrrega.

# 33) Proves de recuperació

És un tipus de proves que valida el grau de recuperació de l’aplicació o del sistema de bloqueigs o desastres.

La prova de recuperació determina si el sistema pot continuar l'operació després d'un desastre. Suposem que l’aplicació està rebent dades a través del cable de xarxa i que de sobte s’ha desconnectat el cable de xarxa.

Un temps després, connecteu el cable de xarxa; llavors el sistema hauria de començar a rebre dades des d'on va perdre la connexió a causa del desconnectament del cable de xarxa.

# 34) Proves de regressió

La prova d'una aplicació en conjunt per a la modificació de qualsevol mòdul o funcionalitat s'anomena Prova de regressió. És difícil cobrir tot el sistema Proves de regressió , tan típicament Eines de proves d'automatització s’utilitzen per a aquest tipus de proves.

# 35) Proves basades en el risc (RBT)

En Proves basades en el risc , es proven les funcionalitats o els requisits en funció de la seva prioritat. Les proves basades en el risc inclouen proves de funcionalitats altament crítiques, que tenen el major impacte en el negoci i en què la probabilitat de fracàs és molt alta.

La decisió de prioritat es basa en les necessitats empresarials, de manera que, un cop establerta la prioritat per a totes les funcionalitats, s’executen les funcions d’alta prioritat o els casos de prova primer seguits de les funcions de prioritat mitjana i baixa.

La funcionalitat de baixa prioritat es pot provar o no en funció del temps disponible.

Les proves basades en el risc es realitzen si no hi ha prou temps disponible per provar tot el programari i cal implementar-lo a temps sense demora. Aquest enfocament només és seguit pel debat i l’aprovació del client i de l’alta direcció de l’organització.

# 36) Proves de seny

Proves de seny es fa per determinar si una nova versió de programari funciona prou bé com per acceptar-la per a un esforç de prova important o no. Si una aplicació es bloqueja per al seu ús inicial, el sistema no és prou estable per fer proves posteriors. Per tant, s’assigna una compilació o una aplicació per solucionar-la.

# 37) Proves de seguretat

És un tipus de proves realitzades per un equip especial de verificadors. Un sistema es pot penetrar per qualsevol forma de pirateria.

Proves de seguretat es fa per comprovar com el programari, l’aplicació o el lloc web estan protegits contra amenaces internes i externes. Aquesta prova inclou la quantitat de programari protegit del programa maliciós, els virus i la seguretat i la seguretat dels processos d'autorització i d'autorització.

També comprova com es comporta el programari per a qualsevol atac de pirates informàtics i programes maliciosos i com es manté el programari per a la seguretat de les dades després d’aquest atac de pirates informàtics.

# 38) Prova de fum

Sempre que l’equip de desenvolupament proporciona una nova versió, l’equip de proves de programari valida la construcció i assegura que no existeix cap problema important.

L’equip de proves s’assegura que la compilació és estable i es realitza un nivell detallat de proves. Proves de fum comprova que no hi hagi cap defecte de tap en la construcció que impedeixi a l'equip de proves provar l'aplicació en detall.

Si els provadors troben que la principal funcionalitat crítica es desglossa en la pròpia etapa inicial, l'equip de proves pot rebutjar la compilació i informar en conseqüència a l'equip de desenvolupament. Les proves de fum es realitzen a un nivell detallat de qualsevol prova funcional o de regressió.

# 39) Proves estàtiques

La prova estàtica és un tipus de prova que s’executa sense cap codi. L'execució es realitza a la documentació durant la fase de proves.

Inclou revisions, recorreguts i inspecció dels resultats del projecte. La prova estàtica no executa el codi en lloc de la sintaxi del codi, es comproven les convencions de denominació.

Proves estàtiques també és aplicable per a casos de prova, pla de prova i document de disseny. És necessari realitzar proves estàtiques per part de l'equip de proves, ja que els defectes identificats durant aquest tipus de proves són rendibles des de la perspectiva del projecte.

# 40) Proves d’estrès

Aquesta prova es realitza quan un sistema està estressat més enllà de les seves especificacions per comprovar com i quan falla. Això es realitza amb càrregues elevades, com ara situar un gran nombre més enllà de la capacitat d’emmagatzematge, consultes complexes de bases de dades, entrada contínua al sistema o càrrega de base de dades.

# 41) Prova del sistema

Sota Tècnica de proves de sistemes , es prova tot el sistema segons els requisits. Es tracta d'un assaig tipus Black-box que es basa en les especificacions generals de requisits i cobreix totes les parts combinades d'un sistema.

# 42) Proves d’unitats

Les proves d’un component o mòdul de programari individual s’anomenen Proves unitàries . Normalment el fa el programador i no els provadors, ja que requereix un coneixement detallat del disseny i el codi intern del programa. També pot requerir el desenvolupament de mòduls de control de prova o arnesos de prova.

# 43) Proves d’usabilitat

Sota Proves d’usabilitat Es realitza la comprovació de la facilitat d'ús. El flux de l'aplicació es prova per saber si un usuari nou pot entendre l'aplicació fàcilment o no; es documenta una ajuda adequada si un usuari es queda atrapat en algun moment. Bàsicament, la navegació del sistema es comprova en aquesta prova.

# 44) Proves de vulnerabilitat

Les proves que consisteixen a identificar la debilitat del programari, el maquinari i la xarxa es coneixen com a proves de vulnerabilitat. En els programes maliciosos, el pirata informàtic pot prendre el control del sistema si és vulnerable a aquest tipus d’atacs, virus i cucs.

Per tant, cal comprovar si aquests sistemes se sotmeten a proves de vulnerabilitat abans de la producció. Pot identificar defectes crítics, defectes en la seguretat.

# 45) Prova de volum

Proves de volum és un tipus de proves no funcionals realitzades per l'equip de proves de rendiment.

El programari o l’aplicació experimenta una gran quantitat de dades i les proves de volum comproven el comportament del sistema i el temps de resposta de l’aplicació quan el sistema es va trobar amb un volum de dades tan elevat. Aquest alt volum de dades pot afectar el rendiment del sistema i la velocitat del temps de processament.

# 46) Prova de caixes blanques

Proves de caixa blanca es basa en el coneixement sobre la lògica interna del codi d’una aplicació.

També es coneix com a Prova de caixes de vidre. El programari intern i el funcionament del codi han de ser coneguts per realitzar aquest tipus de proves. Sota aquestes proves, es basen en la cobertura dels extractes de codi, sucursals, camins, condicions, etc.

Conclusió

Els tipus de proves de programari esmentats anteriorment són només una part de les proves. Tot i això, encara hi ha una llista de més de 100 tipus de proves, però no s’utilitzen tots els tipus de proves en tots els tipus de projectes. Per tant, he tractat alguns tipus comuns de proves de programari que s’utilitzen principalment en el cicle de vida de les proves.

quin és el millor compte de correu electrònic

A més, hi ha definicions o processos alternatius utilitzats en diferents organitzacions, però el concepte bàsic és el mateix a tot arreu. Aquests tipus de proves, processos i els seus mètodes d’implementació continuen canviant a mesura que canvien el projecte, els requisits i l’abast.

Lectura recomanada

^