Top 25 de preguntes i respostes d’entrevistes de proves funcionals

top 25 functional testing interview questions

Preguntes i respostes de les entrevistes de proves funcionals més freqüents:

Com el seu propi nom defineix, les proves funcionals són el procés de provar una aplicació respecte a les especificacions del document de requisits.

Les proves funcionals es poden realitzar manualment o mitjançant automatització, però cada procés inclou provar l'aplicació proporcionant un conjunt d'entrades i determinar o verificar el resultat / sortida comparant el resultat real amb els resultats esperats.

Les proves funcionals tenen diverses fases que s'han de tenir en compte durant les proves. En aquest article, veurem diverses preguntes i respostes d’entrevistes que us ajudaran a preparar-vos bé.

Preguntes d'entrevista de proves funcionals més populars

P # 1) Què enteneu pel terme 'Proves funcionals'?

Resposta: Una tècnica de prova de caixa negra, en què es prova la funcionalitat d’una aplicació per generar la sortida desitjada proporcionant determinada entrada, s’anomena ‘Prova funcional’.

El paper de les proves funcionals no només és validar el comportament de l’aplicació segons l’especificació del document de requisits, sinó també verificar si l’aplicació està preparada per ser llançada a l’entorn actiu o no.

A continuació es detallen algunes tècniques de proves funcionals que s’utilitzen habitualment:

• Proves d’unitat
• Proves de fum
• Proves d'integració
• Proves del sistema
• Proves d’usabilitat
• Proves de regressió
• Proves d’acceptació d’usuaris

Q # 2) Quins són els passos importants que es cobreixen a les proves funcionals?

Resposta: A continuació es detallen els passos que s'han de cobrir com a part de les proves funcionals:

• Comprensió de l’especificació del document de requisits i aclariment de dubtes i consultes en forma de comentaris de revisió.
• Escriure els casos de prova respecte a l’especificació de requisits tenint en compte tots els escenaris que s’han de tenir en compte per a tots els casos.
• Identificar les entrades de prova i sol·licitar les dades de prova necessàries per executar els casos de prova, així com per comprovar la funcionalitat de l'aplicació.
• Determineu els resultats reals segons els valors d’entrada que cal provar.
• Executeu els casos de prova que determinin si el comportament de l’aplicació és l’esperat o si s’ha produït algun defecte.
• Compareu el resultat real i el resultat calculat per esbrinar el resultat real.

Q # 3) Expliqueu la diferència entre les proves funcionals i les proves no funcionals.

Resposta: La diferència entre les proves funcionals i les no funcionals es pot explicar a continuació:

Q # 4) En què es diferencia 'Construir' de 'Alliberar'?

Resposta: Construeix és un fitxer executable que fa referència a la part d'una aplicació que es lliura a un provador per provar la funcionalitat implementada de l'aplicació juntament amb algunes correccions d'errors. L'equip de proves pot rebutjar la compilació si no passa la llista de comprovació crítica que conté la funcionalitat principal de l'aplicació.

Hi pot haver diverses versions al cicle de proves d'una aplicació.

Alliberament es refereix a l’aplicació de programari que ja no es troba en fase de proves i, un cop finalitzada la prova i el desenvolupament, l’aplicació es lliura al client. Una versió té diverses versions associades.

Q # 5) Expliqueu el cicle d'errors.

Resposta: Es diu que l’error és un error, error, error, etc. no desitjat que s’ha produït dins de l’aplicació i que impedeix que emeti la sortida desitjada. Quan es produeix algun defecte o error en una aplicació durant la prova, des del registre d'un defecte fins a la seva resolució, un error es mou a través d'un cicle de vida definit conegut com a Bug Lifecycle.

La figura següent us donarà una idea del cicle de vida dels errors:

(imatge font )

Tot el procés passa quan es produeix un problema o un error. S'informa / registra a l'eina de seguiment d'errors seguint un format considerable. Aquests errors s’assignen al desenvolupador i el seu estat es defineix com a ‘Obert’. Ara el desenvolupador pot revisar l’error, reproduir-lo al final i començar a treballar-hi.

Si l'error s'ha solucionat, el desenvolupador canvia el seu estat a 'Corregit' o es pot canviar l'estat a 'necessita més informació', 'no es corregirà', 'no es pot reproduir', etc., en altres casos. A continuació, QA realitza una regressió, és a dir, torneu a verificar els errors amb una acció específica i responeu en conseqüència.

Si els problemes / error ara es comporten com s'esperava, el seu estat es canviarà a Verificat / Tancat. Torna a obrir.

Q # 6) Indiqueu l'estat d'un error juntament amb la seva descripció.

com injectar codi a un lloc web

Resposta: A continuació, es mostren alguns estats d’errors juntament amb les seves descripcions:

• Novetat: Quan el defecte o error es registra per primera vegada, es diu com a Nou.
• Assignat: Després que el verificador hagi registrat un error, el responsable del verificador el revisarà i se l’assignarà a l’equip de desenvolupadors corresponent.
• Obert: El provador registra un error en estat obert i es manté en estat obert fins que el desenvolupador hagi realitzat alguna tasca sobre aquest error.
• Resolt / solucionat: Quan un desenvolupador ha resolt l’error, és a dir, ara l’aplicació produeix la sortida desitjada per a un problema concret, el desenvolupador canvia el seu estat a Resolució / Solució.
• Verificat / tancat: Quan un desenvolupador ha canviat l'estat a resolt / solucionat, el provador ara prova el problema al final i, si s'ha solucionat, canvia l'estat de l'error a 'Verificat / Tancat'.
• Torna a obrir: Si un provador és capaç de reproduir l’error de nou, és a dir, l’error encara existeix fins i tot després que el desenvolupador l’hagi solucionat, l’estat es marca com a Reobri.
• No és un error / no és vàlid: Un desenvolupador pot marcar-lo com a no vàlid o no com a error pel desenvolupador quan el problema informat és segons la funcionalitat, però es registra a causa d'una mala interpretació.
• Diferit: Normalment, quan l'error té una prioritat mínima per a la versió i si hi ha falta de temps, en aquest cas, aquests errors de prioritat mínima es diferixen a la versió següent.
• No es pot reproduir: Si el desenvolupador no pot reproduir l'error al final, seguiu els passos esmentats al número.

P # 7) Què es coneix com a prova basada en dades?

Resposta: Les proves basades en dades són la metodologia en què s’executen repetidament una sèrie de scripts de prova que contenen casos de prova mitjançant fonts de dades com full de càlcul Excel, fitxer XML, fitxer CSV, base de dades SQL per als valors d’entrada i la sortida real es compara amb l’esperada a la verificació procés.

Per exemple, s’utilitza un estudi de proves per fer proves basades en dades.

Alguns avantatges de les proves basades en dades són:

• Reutilització.
• Repetibilitat.
• Prova de separació de dades de la lògica de prova.
• Es redueix el nombre de casos de prova.

Q # 8) Quins són els punts importants que s'han de tenir en compte en escriure casos de prova?

Resposta: Es diu que escriure un cas de prova és l’activitat més important del procés d’execució de la prova que requereix habilitats d’escriptura, així com un coneixement profund de l’aplicació per fer casos de prova efectius i reutilitzables.

Alguns punts importants que s'han de tenir en compte en escriure casos de proves inclouen:

• Abans de començar a escriure els casos de prova, s’ha d’entendre clarament els requisits del client. No s’ha d’assumir res i s’han d’aclarir tots els dubtes sobre els requisits.
• S’ha d’incloure tots els requisits en forma de casos de prova i no s’ha de deixar de banda res. Normalment es manté la matriu de traçabilitat per comprovar cada implementació de requisits i finalització de les proves.
• Segons les especificacions del document de requisits, s'hauria de cobrir la compatibilitat de tots els requisits funcionals i no funcionals, inclosa la interfície d'UI.
• Els casos de prova s’han de revisar de tant en tant si no hi ha repetició ni redundància.
• La prioritat és un factor important que s’hauria d’establir per als casos de prova mentre escriviu. Aquesta prioritat ajuda el provador a provar l'aplicació primer amb els casos de proves d'alta prioritat que inclouen funcionalitats bàsiques, després els casos de prova de prioritat mitjana i posterior.
• Per a una versió concreta, també es poden crear casos de prova Sprint de manera que el provador, així com el desenvolupador, puguin analitzar la qualitat del producte en funció de l'execució dels casos de prova.
• L’estructura dels casos de prova s’ha d’entendre fàcilment i ha d’estar en un llenguatge senzill. Els valors de les dades d'entrada per als casos de prova han de ser vàlids i també en un ampli rang.

P # 9) Què són les proves d'automatització?

Resposta: Les proves d'automatització són una metodologia de proves en què s'utilitza una eina d'automatització per executar el conjunt de casos de prova amb la finalitat d'augmentar la cobertura de la prova i la velocitat d'execució de la prova. Les proves d’automatització no requereixen cap intervenció humana, ja que realitzen proves preescripturades i són capaces d’informar i comparar els resultats amb proves anteriors.

La repetibilitat, la facilitat d'ús, la precisió i una major consistència són alguns dels avantatges de les proves d'automatització.

A continuació s’enumeren algunes eines de proves d’automatització:

• Seleni
• Tel·luri
• aigua
• SABÓ

Q # 10) Expliqueu el terme Prova d’esforç i Prova de càrrega.

Resposta:

Proves d’estrès és una forma de proves de rendiment en què l’aplicació haurà de passar per esforç o esforç, és a dir, l’execució de l’aplicació per sobre del llindar del descans per determinar el punt en què l’aplicació es bloqueja. Aquesta condició sol sorgir quan hi ha massa usuaris i massa dades.

Les proves d’estrès també verificen la recuperació de l’aplicació quan es redueix la càrrega de treball.

Prova de càrrega és una forma de proves de rendiment en què l'aplicació s'executa per sobre de diversos nivells de càrrega per controlar el rendiment màxim del servidor, el temps de resposta, el rendiment del servidor, etc. Mitjançant la prova de càrrega, l'estabilitat del procés, el rendiment i la integritat de l'aplicació es determinen sota la càrrega simultània del sistema .

P # 11) Què enteneu per proves de volum?

Resposta: La prova de volum és una forma de prova de rendiment que determina els nivells de rendiment del rendiment i el temps de resposta del servidor quan els usuaris concurrents, així com una gran càrrega de dades de la base de dades, es posen al sistema / aplicació sota proves.

P # 12) Quines són les diferents tècniques de prova utilitzades en les proves funcionals?

Resposta: Hi ha dues tècniques de prova diferents que s’utilitzen en proves funcionals.

Es poden definir a continuació:

• Proves basades en requisits: Aquesta forma de proves funcionals es realitza prioritzant els requisits sobre la base de criteris de risc. Això també assegura que tots els camins crítics de prova s'han inclòs en el procés de prova.
• Proves basades en processos empresarials: Aquesta forma de proves funcionals es realitza des de la perspectiva del procés empresarial. Els escenaris inclouen el coneixement dels processos empresarials per realitzar proves.

P # 13) Què enteneu per proves exploratòries? Quan es realitza?

Resposta: La prova exploratòria significa provar o explorar l'aplicació sense seguir cap programa ni procediment. Mentre realitzen proves exploratòries, els verificadors no segueixen cap patró i utilitzen el seu pensament i idees diverses per veure com funciona l'aplicació.

Seguir aquest procés cobreix fins i tot la part més petita de l’aplicació i ajuda a trobar més problemes / errors que en el procés normal de proves de casos.

Les proves exploratòries se solen realitzar en casos en què:

• Hi ha un provador experimentat a l’equip de proves que pot utilitzar la seva experiència de proves per aplicar tots els millors escenaris possibles.
• S'han cobert tots els camins crítics i es preparen els principals casos de prova segons les especificacions de requisits que s'han executat.
• Hi ha una aplicació crítica i no es pot perdre cap cas possible.
• Un nou provador ha entrat a l’equip, explorant l’aplicació els ajudarà a entendre millor i seguirà la seva pròpia ment mentre executen qualsevol escenari en lloc de seguir el camí tal com s’esmenta al document de requisits.

P # 14) Per a qualsevol aplicació web, quines són les possibles funcions d'inici de sessió que s'han de provar?

Resposta: A continuació es detallen els possibles escenaris que es poden realitzar per provar completament la funció d’inici de sessió de qualsevol aplicació:

• Comproveu els camps d’entrada, és a dir, nom d’usuari i contrasenya amb valors vàlids i no vàlids.
• Proveu d'introduir un identificador de correu electrònic vàlid amb una contrasenya incorrecta i també introduïu un correu electrònic i una contrasenya vàlids no vàlids. Comproveu que aparegui el missatge d’error adequat.
• Introduïu credencials vàlides i inicieu la sessió a l'aplicació. Tanqueu i torneu a obrir el navegador per comprovar si encara heu iniciat la sessió.
• Introduïu l'aplicació després d'iniciar la sessió i torneu a tornar a la pàgina d'inici de sessió per comprovar si es demana a l'usuari que torni a iniciar la sessió o no.
• Inicieu la sessió des d'un navegador i obriu l'aplicació des d'un altre navegador per verificar si també heu iniciat sessió en un altre navegador.
• Canvieu la contrasenya després d'iniciar sessió a l'aplicació i, a continuació, proveu d'iniciar la sessió amb aquesta contrasenya antiga.

Hi ha pocs altres escenaris possibles que es puguin provar.

Q # 15) Expliqueu les proves d'accessibilitat i la seva importància en l'escenari actual.

Resposta: Les proves d’accessibilitat són una forma de proves d’usabilitat en què es realitzen proves per assegurar que les persones amb discapacitat puguin manejar fàcilment l’aplicació, com ara audició, daltonisme, poca visibilitat, etc. En l’escenari actual, la web ha adquirit el lloc més important a la nostra vida a la forma de llocs de comerç electrònic, e-learning, pagaments electrònics, etc.

Per tant, per créixer millor a la vida, tothom hauria de ser capaç de formar part de la tecnologia, especialment les persones amb algunes discapacitats.

A continuació es detallen alguns tipus de programari que ajuden i ajuden les persones amb discapacitat a utilitzar la tecnologia:

• Programari de reconeixement de veu
• Programari lector de pantalla
• Programari d’ampliació de pantalla
• Teclat especial

P # 16) Què són les proves Adhoc?

Resposta: Les proves adhoc, normalment conegudes com a proves aleatòries, són una forma de prova que no segueix cap cas de prova o requisit de l'aplicació. Les proves adhoc són bàsicament una activitat no planificada en què es comprova a l’atzar qualsevol part de l’aplicació per trobar defectes.

En aquests casos, els defectes trobats són molt difícils de reproduir, ja que no se segueixen casos de prova previstos. Les proves adhoc solen realitzar-se quan hi ha un temps limitat per realitzar proves elaboratives.

P # 17) Què és el particionament d'equivalència?

Resposta: El particionament d'equivalències també conegut com a particionament de classes d'equivalència és una forma de prova de caixa negra on les dades d'entrada es divideixen en classes de dades. Aquest procés es realitza per reduir el nombre de casos de prova, però tot i així cobrir el màxim requisit.

S’aplica la tècnica de particionat d’equivalència on els valors de les dades d’entrada es poden dividir en intervals. L'interval dels valors d'entrada es defineix de manera que només s'ha de provar una condició de cada partició d'interval suposant que totes les altres condicions de la mateixa partició tindran el mateix comportament per al programari.

Per exemple: Per identificar la taxa d'interès segons el saldo del compte, podem identificar l'interval de l'import del saldo del compte que obtingui una taxa d'interès diferent.

P # 18) Expliqueu l'anàlisi del valor límit.

Resposta: El mètode d’anàlisi del valor límit comprova els valors límit de les particions de classe Equivalència. L'anàlisi del valor límit és bàsicament una tècnica de prova que identifica els errors als límits en lloc de dins dels valors de l'interval.

Per exemple , Un camp d'entrada pot permetre un mínim de 8 caràcters i un màxim de 12 caràcters, de manera que 8-12 es consideren l'interval vàlid i 13 es consideren l'interval no vàlid. En conseqüència, els casos de prova s’escriuen per obtenir un valor de partició vàlid, un valor de límit exacte i un valor de partició no vàlid.

P # 19) Expliqueu la diferència entre la gravetat i la prioritat.

Resposta: Gravetat del defecte es defineix pel nivell o el grau d’impacte del defecte sobre l’aplicació sotmesa a prova. Com més gran sigui la gravetat del defecte, més serà l'impacte sobre l'aplicació.

A continuació es mostren les 4 classes en què es classifica una gravetat del defecte:

• Crític
• Major
• Mitjà
• baix

Prioritat de defecte defineix l’ordre en què s’ha de resoldre primer el defecte, és a dir, com més alta sigui la prioritat del defecte, implica que l’aplicació és inutilitzable o s’enganxa en algun moment i el defecte s’ha de resoldre el més aviat possible.

A continuació es mostren les 3 classes en què es defineix una prioritat de defecte:

• Alt
• Mitjà
• baix

P # 20) Quan realitzem proves de fum?

Resposta: Les proves de fum es realitzen a l'aplicació després de rebre la compilació. El provador sol provar el camí crític i no la funcionalitat en profunditat per assegurar-se si la compilació s’ha d’acceptar per a proves posteriors o si s’ha de rebutjar en cas d’aplicació fallida.

Una llista de verificació de fum sol contenir el camí crític de l’aplicació sense el qual es bloqueja una aplicació.

P # 21) Què enteneu per les proves de Sanity?

Resposta: Les proves de seny es realitzen després de rebre la compilació per comprovar la nova funcionalitat / defectes que s'han de corregir. En aquesta forma de prova l'objectiu és comprovar la funcionalitat aproximadament com s'esperava i determinar si l'error s'ha solucionat i també l'efecte de l'error solucionat a l'aplicació que es prova.

No té cap sentit acceptar la compilació pel provador i perdre el temps si falla la prova de Sanity.

P # 22) Què enteneu per Matriu de traçabilitat de requisits?

Resposta: La matriu de traçabilitat de requisits (RTM) és una eina per fer un seguiment de la cobertura de requisits durant el procés de prova.

A RTM, tots els requisits es classifiquen com el seu desenvolupament durant el sprint i es mantenen els seus respectius identificadors (implementació de noves funcions / millores / problemes anteriors, etc.) per fer un seguiment de tot el que s’ha esmentat al document de requisits abans de la publicació de el producte.

RTM es crea tan aviat com es rep el document de requisits i es manté fins al llançament del producte.

P # 23) Quins són els factors a tenir en compte a les proves basades en el risc?

Resposta: Mitjançant les proves basades en el risc d’un projecte, no es tracta només de lliurar un projecte sense risc, sinó que l’objectiu principal de les proves basades en el risc és aconseguir el resultat del projecte mitjançant la realització de les millors pràctiques de gestió de riscos.

Els principals factors a tenir en compte en les proves basades en el risc són els següents:

• Identificar quan i com implementar proves basades en el risc en una aplicació adequada.
• Identificar les mesures que actuen bé per trobar i gestionar els riscos en àrees crítiques de l'aplicació.
• Per aconseguir el resultat del projecte que equilibri el risc amb la qualitat i la característica de l'aplicació.

Q # 24) Diferencieu entre proves de regressió i proves de nou.

Resposta: La diferència entre la prova de regressió i la prova nova es pot explicar de la següent manera:

Q # 25) Expliqueu les proves d'acceptació de l'usuari.

Resposta: Les proves d’acceptació de l’usuari normalment es realitzen després de provar a fons el producte. En aquesta forma de prova, els usuaris de programari o, per exemple, el client, utilitzen l'aplicació per assegurar-se que tot funciona segons els requisits i perfectament en l'escenari del món real.

UAT també es coneix com a prova d’usuari final.

Conclusió

A través d’aquest article, he intentat explicar tots els temes de les proves funcionals, de manera que qualsevol persona que es prepari per a l’entrevista pugui entendre el tema fàcilment i recordar-los també.

Preguntes i respostes d’entrevistes de proves d’automatització de seleni

Aquestes preguntes i respostes de les entrevistes de proves funcionals us guiaran per esborrar qualsevol entrevista amb tota confiança.

Us desitgem a tots èxit.

Espero que aquestes preguntes i respostes de les entrevistes de proves funcionals us ajudin en algun moment de la vostra carrera.

Lectura recomanada

• Proves funcionals contra proves no funcionals
• 16 Noves funcions de l'eina Micro Focus UFT (Unified Functional Testing): QTP vs UFT
• 5 millors eines alternatives de proves unificades funcionals (UFT) d'HP
• Una guia completa de proves no funcionals per a principiants
• Una guia pas a pas de Jubula: l'eina de proves funcionals automatitzades de codi obert
• Proves funcionals i proves de rendiment: s'hauria de fer simultàniament?
• Guia completa de proves funcionals amb els seus tipus i exemples
• Tutorial de Parrot QA: revisió de l'eina de proves funcionals de diversos navegadors
• Spock per a la integració i proves funcionals amb seleni
• Les diferències entre la prova unitària, la prova d’integració i la prova funcional
• Top 25 de preguntes i respostes d’entrevistes de proves funcionals
• Top 30 eines de proves funcionals del 2021