complete functional testing guide with its types
Un tutorial exhaustiu de proves funcionals completes amb tipus, tècniques i exemples:
Què és la prova funcional?
La prova funcional és un tipus de prova de caixa negra que es realitza per confirmar que la funcionalitat d’una aplicació o sistema es comporta com s’esperava.
Es fa per verificar totes les funcionalitats d'una aplicació.
LLISTA dels tutorials tractats en aquesta sèrie:
Tutorial # 1: Què és la prova funcional? (aquest tutorial)
Tutorial # 2: Preguntes d’entrevistes de proves de funcionalitat
Tutorial # 3: Principals eines de proves d'automatització funcional
Tutorial # 4: Què és la prova no funcional?
Tutorial # 5: Diferència entre unitat, funcional i Integració Proves
Tutorial # 6 : Per què s’haurien de fer proves de rendiment i de rendiment simultàniament?
Eines:
Tutorial # 7: Automatització de proves funcionals amb Ranorex Studio
Tutorial # 8: Noves funcions de l'eina funcional UFT
Tutorial # 9: Automatització funcional de diversos navegadors mitjançant l'eina Parrot QA
Tutorial # 10: Tutorial de l'eina de codi obert Jubula per provar la funcionalitat
Què aprendreu:
- Introducció a les proves funcionals
Introducció a les proves funcionals
Hi ha d’haver alguna cosa que defineixi què és un comportament acceptable i què no.
Això s’especifica en una especificació funcional o de requisits. És un document que descriu allò que un usuari pot fer-ho, que pot determinar la conformitat de l'aplicació o del sistema. A més, de vegades això també pot comportar la validació dels escenaris empresarials reals.
Per tant, es poden realitzar proves de funcionalitat mitjançant dues tècniques populars :
- Proves basades en els requisits: Conté totes les especificacions funcionals que constitueixen la base per a totes les proves a realitzar.
- Proves basades en escenaris empresarials: Conté informació sobre com es percebrà el sistema des d’una perspectiva de procés empresarial.
Les proves i l’assegurament de la qualitat són una part important del procés SDLC. Com a provador, hem de ser conscients de tots els tipus de proves, encara que no hi participem directament diàriament.
Com que les proves són un oceà, l'abast de la mateixa és tan ampli, i tenim provadors dedicats que funcionen diferents tipus de proves . Probablement, tots hem de conèixer la majoria dels conceptes, però no estarà mal organitzar-ho tot aquí.
Tipus de proves funcionals
Les proves funcionals tenen moltes categories i es poden utilitzar en funció de l’escenari.
A continuació es comenten breument els tipus més destacats:
Les proves d’unitats normalment les realitza un desenvolupador que escriu diferents unitats de codi que podrien estar relacionades o no relacionades per aconseguir una funcionalitat concreta. En general, això implica escriure proves d'unitats que criden els mètodes de cada unitat i els validen quan es passen els paràmetres requerits i el seu valor de retorn és l'esperat.
La cobertura del codi és una part important de les proves d’unitats, en què cal que existeixin els casos de prova per cobrir els tres següents:
i) Cobertura de línia
ii) Cobertura del camí del codi
iii) Cobertura del mètode
Proves de seny : Prova que es fa per assegurar-se que totes les funcions principals i vitals de l'aplicació / sistema funcionen correctament. Això es fa generalment després d’una prova de fum.
Proves de fum : Les proves que es fan després de llançar cada versió per provar-les per garantir l'estabilitat de la construcció. També s’anomena prova de verificació de compilació.
Proves de regressió : Les proves realitzades per assegurar-se que afegir nou codi, millores, corregir errors no trenca la funcionalitat existent ni provoca cap inestabilitat i encara funciona d'acord amb les especificacions.
Les proves de regressió no han de ser tan extenses com les proves funcionals reals, sinó que han de garantir només la quantitat de cobertura per certificar que la funcionalitat és estable.
Proves d’integració : Quan el sistema es basa en diversos mòduls funcionals que poden funcionar perfectament individualment, però que han de funcionar de manera coherent quan es combinen per aconseguir un escenari extrem a extrem, la validació d’aquests escenaris s’anomena proves d’integració.
Prova beta / usabilitat : El producte està exposat al client real en una producció com un entorn i prova el producte. D’això se’n deriva la comoditat de l’usuari i es prenen els comentaris. Això és similar al de les proves d’acceptació d’usuaris.
Representem-ho en un diagrama de flux fàcil:
Prova funcional del sistema:
Proves del sistema és una prova que es realitza en un sistema complet per verificar si funciona com s’esperava un cop s’integrin tots els mòduls o components.
Proves de punta a punta es realitza per verificar la funcionalitat del producte. Aquesta prova només es realitza quan les proves d'integració del sistema estan completes, incloent tant els requisits funcionals com els no funcionals.
=> Diferència entre proves d’unitat, funcionals i d’integració
Procés
Aquest procés de prova té tres passos principals:
Enfocament, tècniques i exemples
Les proves funcionals o de comportament generen una sortida basada en les entrades donades i determina si el sistema funciona correctament segons les especificacions.
Per tant, la representació pictòrica es veurà com es mostra a continuació:
Criteris d’entrada / sortida
Criteris d'entrada:
- El document d’especificacions de requisits es defineix i s’aprova.
- S'han preparat casos de prova.
- S'han creat dades de prova.
- L'entorn per a les proves està preparat, totes les eines necessàries estan disponibles i llestes.
- L'aplicació completa o parcial es desenvolupa i es prova la unitat i està preparada per a la prova.
Criteris de sortida:
- S'ha completat l'execució de tots els casos de proves funcionals.
- No hi ha errors crítics ni P1, P2 oberts.
- S'han reconegut els errors notificats.
Passos implicats
A continuació, s’esmenten els diversos passos implicats en aquesta prova:
- El primer pas implicat és determinar la funcionalitat del producte que cal provar i inclou provar les principals funcionalitats, la condició d’error i els missatges, proves d’usabilitat, és a dir, si el producte és fàcil d’utilitzar o no, etc.
- El següent pas és crear les dades d'entrada per a la funcionalitat a provar segons l'especificació de requisits.
- Més endavant, a partir de l'especificació de requisits, es determina la sortida per a la funcionalitat que es prova.
- S’executen casos de proves preparats.
- Es compara la sortida real, és a dir, la sortida després d’executar el cas de prova i la sortida esperada (determinada a partir de l’especificació del requisit) per determinar si la funcionalitat funciona o no com s’esperava.
Aproximació
Es poden pensar i escriure diferents tipus d’escenaris en forma de “casos de prova”. Com a gent de QA, tots sabem com es veu l’esquelet d’un cas de prova.
La majoria té quatre parts:
- Resum de la prova
- Requisits previs
- Passos de prova i
- Resultats esperats.
Intentar escriure tot tipus de proves no només és impossible, sinó que també requereix molt de temps i és car.
Normalment, voldríem descobrir el màxim d’errors sense fugides amb les proves existents. Per tant, el control de qualitat ha d’utilitzar tècniques d’optimització i elaborar estratègies de com abordarien les proves.
Expliquem això amb un exemple.
Exemples de casos d'ús de proves funcionals:
Pren un portal HRMS en línia on l’empleat inicia la sessió amb el seu compte d’usuari i la seva contrasenya. A la pàgina d'inici de sessió, hi ha dos camps de text per al nom d'usuari i la contrasenya, i dos botons: Inici de sessió i Cancel·la. L'inici de sessió correcte porta l'usuari a la pàgina d'inici de HRMS i cancel·la la cancel·lació.
Les especificacions es mostren a continuació:
# 1) El camp d'identificació d'usuari té un mínim de 6 caràcters, un màxim de 10 caràcters, números (0-9), lletres (a-z, A-z), caràcters especials (només subratllat, punt, guionet permès) i no es pot deixar en blanc. L'identificador d'usuari ha de començar amb un caràcter o un número i no amb caràcters especials.
# 2) El camp de contrasenya té un mínim de 6 caràcters, un màxim de 8 caràcters, números (0-9), lletres (a-z, A-Z), caràcters especials (tots) i no pot quedar en blanc.
L’enfocament bàsic per provar aquest escenari es pot classificar en dues grans categories:
- Proves positives i
- Proves negatives
Per descomptat, cadascuna d’aquestes categories té la seva subsecció de proves que es duran a terme.
Proves positives són proves de camí feliç que es fan per assegurar-se que el producte compleix, com a mínim, els requisits bàsics que són vitals per a l'ús del client.
Escenaris negatius assegureu-vos que el producte es comporta correctament fins i tot quan està sotmès a dades inesperades.
Lectura suggerida => Què són les proves negatives i com escriure casos de proves negatives
Ara, deixeu-me provar d’estructurar les tècniques de prova mitjançant un diagrama de flux següent. Entrarem en els detalls de cadascuna d’aquestes proves.
Tècniques de proves funcionals
# 1) Proves del sistema basades en l'usuari final
El sistema que es prova pot tenir molts components que quan s’acoblen aconsegueixen l’escenari de l’usuari.
A la Exemple , un escenari de client inclouria tasques com carregar l'aplicació HRMS, introduir les credencials correctes, anar a la pàgina inicial, realitzar algunes accions i tancar la sessió del sistema. Aquest flux concret ha de funcionar sense cap error en un escenari bàsic de negoci.
com escriure casos de prova uat
A continuació, es mostren algunes mostres:
Sl núm | Resum | Requisit previ | Cas de prova | Resultats esperats. |
---|---|---|---|---|
1. | Un usuari totalment privilegiat pot fer canvis al compte | 1) El compte d'usuari ha d'existir 2) L'usuari ha de tenir els privilegis necessaris | 1) L'usuari introdueix l'identificador d'usuari i la contrasenya 2) L'usuari veu permisos d'edició per modificar el compte 3) L'usuari modifica i desa la informació del compte. 4) L'usuari tanca la sessió. | 1) L'usuari ha iniciat la sessió a la pàgina d'inici 2) La pantalla d'edició es presenta a l'usuari. 3) Es desa la informació del compte 4) L'usuari es torna a la pàgina d'inici de sessió |
2. | Un altre usuari vàlid sense privilegis complets | 1) El compte d'usuari ha d'existir 2) L'usuari ha de tenir els privilegis mínims | 1) L'usuari introdueix l'identificador d'usuari i la contrasenya 2) L'usuari veu permisos d'edició per modificar només determinats camps. 3) L'usuari només modifica aquests camps i desa. 4) L'usuari tanca la sessió. | 1) L'usuari ha iniciat la sessió a la pàgina d'inici 2) La pantalla d'edició es presenta a l'usuari només en determinats camps. Els camps del compte estan atenuats. 3) Es desen els camps modificats 4) L'usuari es torna a la pàgina d'inici de sessió |
Aquest és un exemple bàsic de com s’autoritzen els casos de prova per a situacions. El format anterior també s'aplicarà a totes les proves següents. Per tal de tenir una forta base conceptual, només he posat algunes proves simples per sobre i per sota.
# 2) Proves d'equivalència
En Particionament d'equivalència , les dades de prova es divideixen en diverses particions anomenades classes de dades d'equivalència. Les dades de cada partició s'han de comportar de la mateixa manera, per tant, només cal provar una condició. De la mateixa manera, si una condició en una partició no funciona, cap de les altres no funcionarà.
Per exemple , a l'escenari anterior, el camp d'identificació d'usuari pot tenir un màxim de 10 caràcters, de manera que introduir dades> 10 hauria de comportar-se de la mateixa manera.
# 3) Proves de valor límit
Les proves de frontera impliquen límits de dades a l’aplicació i validen el seu comportament.
Per tant, si les entrades es subministren més enllà dels valors límit, es considera que són proves negatives. Per tant, un mínim de 6 caràcters per a l'usuari estableix el límit límit. Proves escrites amb identificador d'usuari<6 characters are boundary analysis tests.
# 4) Proves basades en decisions
Les proves basades en decisions es centren en la ideologia dels possibles resultats del sistema quan es compleix una condició particular.
En l’escenari anterior, es poden obtenir immediatament les proves basades en decisions següents:
- Si s'introdueixen les credencials incorrectes, hauria d'indicar-ho a l'usuari i tornar a carregar la pàgina d'inici de sessió.
- Si l'usuari introdueix les credencials correctes, hauria de portar-lo a la següent interfície d'usuari.
- Si l'usuari introdueix les credencials correctes però vol cancel·lar l'inici de sessió, no hauria de portar l'usuari a la següent interfície d'usuari i tornar a carregar la pàgina d'inici de sessió.
# 5) Proves de flux alternatives
S’executen proves de camí alternatiu per validar totes les formes possibles que existeixen, a part del flux principal per complir una funció.
# 6) Proves ad-hoc
Quan es descobreixen la majoria dels errors mitjançant les tècniques anteriors, proves ad-hoc són una bona manera de descobrir discrepàncies que no s’han observat anteriorment. Aquests es realitzen amb la mentalitat de trencar el sistema i veure si respon amb gràcia.
Per exemple , un cas de prova de mostra seria:
- Un usuari té la sessió iniciada, però l’administrador suprimeix el compte d’usuari mentre realitza algunes operacions. Seria interessant veure com l’aplicació gestiona això amb gràcia.
Proves funcionals i no funcionals:
Proves no funcionals se centren en la qualitat de l'aplicació / sistema en general. Per tant, intenta deduir el rendiment del sistema segons els requisits del client, en contrast amb la funció que realitza.
=> Llegiu aquí la diferència exacta
Automatització de proves funcionals
Podem automatitzar proves funcionals?
Amb Automation es pot reduir l’esforç manual, es pot estalviar temps, evitar el lliscament d’errors i augmentar l’eficiència.
Tot i això, no és possible automatitzar totes i cadascuna d’elles. Aquesta prova es pot automatitzar, però l’usuari ha d’esbrinar els casos de prova per fer l’automatització. És important trobar els casos de prova adequats per automatitzar juntament amb una eina adequada.
L’automatització de casos funcionals pot tenir inconvenients, com si el nombre de casos de prova sigui molt més gran i es retrocedeixi una vegada i una altra (cosa que s’ha de fer), és possible que el desenvolupador s’encarregui de comprometre canvis al codi.
Moltes vegades, mentre es realitza l’anàlisi d’escapament de defectes, la causa important i perenne d’escapaments sembla tenir una manca de cobertura de proves en una funció concreta.
De nou, hi ha diverses causes perquè això passi com la manca d'entorns, la manca de verificadors, l'execució de massa funcions, menys temps per cobrir tots els aspectes de les proves i, de vegades, simplement passar-ho per alt.
Tot i que els equips de proves dedicats poden fer proves detallades a cada sprint o cada cicle de prova, sempre existiran defectes i sempre hi haurà defectes que es podrien perdre. Aquesta és una de les necessitats fonamentals per tenir automatitzada la prova, de manera que es millora notablement l’eficiència del procés global de prova i la cobertura dels casos de prova.
Tot i que les proves automàtiques mai no poden substituir les proves manuals, tenir una combinació ideal de les dues resultarà vital per tenir la qualitat desitjada en els projectes de programari.
Consideracions sobre l'automatització:
# 1) Seleccioneu l'eina d'automatització correcta : Hi ha diverses eines disponibles al mercat, triar una eina d’automatització és una tasca descoratjadora. Tanmateix, podeu fer una llista de requisits en funció de la qual podeu seleccionar quina eina d'automatització utilitzar.
Alguns aspectes principals a considerar són:
- Seleccioneu una eina que sigui fàcil d'utilitzar per a tots els membres de l'equip de control de qualitat, si encara no tenen les habilitats necessàries.
- L'eina es pot utilitzar en diferents entorns. Per a Exemple : Es poden crear els scripts en una plataforma de SO i executar-se en una altra? Necessiteu automatització CLI, automatització de la IU, automatització d'aplicacions mòbils o tot?
- L'eina ha de tenir totes les funcions que necessiteu. Per a Exemple : Si alguns provadors no estan ben versats amb un llenguatge de seqüència, l'eina hauria de tenir una funció de gravació i reproducció i, a continuació, és compatible amb la conversió de l'script gravat al llenguatge de seqüència desitjat. De la mateixa manera, si també necessiteu l'eina per donar suport a proves de construcció automatitzades, informes específics i registre, també ho ha de poder fer.
- L'eina ha de ser capaç de donar suport a la reutilització de casos de prova en cas de canvis en la interfície d'usuari.
Eines d'automatització : Hi ha força eines disponibles per a l'automatització funcional. El seleni és probablement un dels favorits més populars, però també hi ha algunes eines de codi obert com Sahi, Watir, Robotium, AutoIt, etc.
Hi ha diverses eines d'automatització de proves disponibles al mercat. Però l'elecció de l'eina adequada és molt important per a l'organització. Pot dependre del requisit, la facilitat d'ús i el cost que hi tingui un paper important.
A continuació es detallen algunes de les millors eines de prova funcionals:
- Seleni
- QTP
- Junit
- Loadrunner
- SABÓ
- Completar la prova
=> Consulteu aquesta llista completa de les millors eines d'automatització funcionals
# 2) Trieu els casos de prova adequats per automatitzar : Si voleu treure el màxim profit de l’automatització, és vital ser intel·ligent quant al tipus de proves que trieu per automatitzar. Si hi ha proves que requereixen algunes configuracions i configuracions activades i desactivades durant l'execució de la prova, és millor deixar-les sense automatitzar.
Per tant, podeu automatitzar proves que:
- Cal executar-lo repetidament.
- Executeu-vos amb diferents tipus de dades.
- Alguns casos de proves P1, P2 requereixen molt d’esforç i temps.
- Proves propenses a errors.
- Conjunt de proves que cal executar en diferents entorns, navegadors, etc.
# 3) Equip d'automatització dedicat : Això és probablement passat per alt en la majoria de les organitzacions i l'automatització s'imposa a tots els membres de l'equip de control de qualitat.
Cada membre de l’equip té diversos nivells d’experiència, conjunts d’habilitats, nivells d’interès, amplada de banda per donar suport a l’automatització, etc. Algunes persones són possiblement més expertes en l’execució de proves manuals, mentre que d’altres poden conèixer eines d’escriptura i automatització.
En situacions com aquesta, és una bona pràctica analitzar tots els membres de l’equip i tenir alguns membres dedicats a fer només automatització.
L'activitat d'automatització requereix temps, esforç, coneixement i un equip dedicat que ajudarà a assolir els resultats necessaris en lloc de sobrecarregar tots els membres de l'equip amb proves manuals i d'automatització.
# 4) Proves basades en dades: Els casos de prova automatitzats que requereixen diversos conjunts de dades s’han d’escriure bé perquè puguin ser reutilitzables. Les dades es podrien escriure en fonts com ara fitxers de text o de propietats, fitxers XML o llegir-se des d’una base de dades.
Sigui quina sigui la font de dades, crear dades d'automatització ben estructurades facilita el manteniment del marc i fa que els scripts de prova existents s'utilitzin al màxim.
# 5) Els canvis de la IU no han de trencar les proves: Els casos de prova que creeu amb l'eina seleccionada han de poder fer front als possibles canvis de la IU. Per exemple, les versions anteriors de seleni utilitzaven una ubicació per identificar els elements de la pàgina.
Per tant, si la interfície d’usuari canviava, aquests elements ja no es trobaven en aquestes ubicacions i, al seu torn, conduirien al fracàs massiu de les proves.
Per tant, és important entendre prèviament les deficiències de l’eina i crear els casos de prova de manera que només calgui fer canvis mínims en cas de canvis en la interfície d’usuari.
# 6) Proves freqüents: Un cop tingueu a punt el dipòsit bàsic de proves d'automatització, planifiqueu una execució més freqüent d'aquest dipòsit. Això té un avantatge bidireccional: un és que podeu millorar el marc d’automatització i fer-lo més robust i el segon és que detectareu més errors durant el procés.
Avantatges
A continuació es detallen els diversos avantatges de les proves funcionals:
- Aquestes proves reprodueixen o són una rèplica del que és el sistema real, és a dir, és una rèplica del que és el producte a l’entorn actiu. Les proves se centren en les especificacions segons l’ús del client, és a dir, especificacions del sistema, sistema operatiu, navegadors, etc.
- No funciona en cap cas i perjudici ni en cap suposició sobre l'estructura del sistema.
- Aquestes proves garanteixen el lliurament d’un producte d’alta qualitat que compleix els requisits del client i assegura que el client estigui satisfet amb els resultats finals.
- Assegura lliurar un producte sense errors que tingui totes les funcionalitats que funcionin segons les necessitats del client.
- Les proves basades en el risc es fan per disminuir les possibilitats de qualsevol tipus de risc al producte.
Limitacions
Aquestes proves es realitzen per assegurar-se que el producte funciona tal com s’esperava i que s’implementa tot el requisit i que el producte és exactament conforme al requeriment del client.
Tanmateix, no té en compte els altres factors, com ara el rendiment del producte, és a dir, la capacitat de resposta, el temps de producció, etc., que són importants i que són molt necessaris per formar part de les proves abans de llançar el producte.
Desavantatges
- Hi ha moltes possibilitats de realitzar proves redundants.
- Es poden perdre errors lògics al producte.
- Aquestes proves es basen en el requisit, si en cas que el requisit no sigui complet o sigui complicat o no estigui clar, realitzar aquestes proves en aquest escenari es fa difícil i també pot trigar molt de temps.
Per tant, bàsicament, aquests dos tipus de proves són necessaris per a un producte de qualitat.
Conclusió
Aquest tutorial ha analitzat exhaustivament tot el que heu de saber sobre les proves funcionals, des dels conceptes bàsics.
Les proves funcionals són un dels processos de proves importants, ja que verifica la funcionalitat d’un producte que és el més requerit i, de fet, l’aspecte important de qualsevol producte o aplicació.
Sobre l'autor: Sanjay Zalavadia: com a vicepresident del servei al client de Zèfir , aporta més de 15 anys d’experiència en lideratge en serveis de suport tècnic i informàtic.
Espero que algunes de les tècniques que hem suggerit siguin útils per a tots els lectors. Feu-nos saber els vostres pensaments als comentaris següents.
Lectura suggerida => Tutorial de proves de funcions
Lectura recomanada
- Proves funcionals contra proves no funcionals
- Proves alfa i proves beta (guia completa)
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Les diferències entre la prova unitària, la prova d’integració i la prova funcional
- Tipus de proves de programari: diferents tipus de proves amb detalls
- Spock per a la integració i proves funcionals amb seleni
- Guia completa de proves de verificació de compilació (proves BVT)
- Una guia completa de proves no funcionals per a principiants