Top 25 Întrebări și răspunsuri la interviuri de testare funcțională

top 25 functional testing interview questions

Cele mai frecvente întrebări și răspunsuri la interviuri de testare funcțională:

După cum definește și numele, testarea funcțională este procesul de testare a unei aplicații în raport cu specificațiile documentului de cerință.

Testarea funcțională poate fi efectuată fie manual, fie prin automatizare, dar fiecare proces include testarea aplicației prin furnizarea unui set de intrări și determinarea sau verificarea rezultatului / ieșirii prin compararea rezultatului real cu rezultatele așteptate.

Testarea funcțională are diferite faze care trebuie luate în considerare în timpul testării. În acest articol, vom vedea mai multe întrebări și răspunsuri la interviu care vă vor ajuta să vă pregătiți bine.

Cele mai populare întrebări de interviu pentru testarea funcțională

Q # 1) Ce înțelegeți prin termenul „Testare funcțională”?

Răspuns: O tehnică de testare a cutiei negre, în care funcționalitatea unei aplicații este testată pentru a genera ieșirea dorită prin furnizarea anumitor intrări se numește „Testare funcțională”.

Rolul testării funcționale nu este doar acela de a valida comportamentul aplicației conform specificațiilor documentului de cerință, ci și de a verifica dacă aplicația este gata să fie lansată sau nu în mediul live.

Mai jos sunt prezentate câteva tehnici de testare funcționale care sunt utilizate în mod obișnuit:

• Testarea unității
• Testarea fumului
• Testarea integrării
• Testarea sistemului
• Testarea utilizabilității
• Testarea regresiei
• Testarea acceptării utilizatorului

Î # 2) Care sunt pașii importanți acoperiți în testarea funcțională?

Răspuns: Următorii pași care ar trebui să fie acoperiți ca parte a testării funcționale:

• Înțelegerea specificației documentului Cerințe și eliminarea îndoielilor și întrebărilor sub forma comentariilor de revizuire.
• Scrierea cazurilor de testare cu privire la specificația cerinței, ținând cont de toate scenariile care ar trebui luate în considerare pentru toate cazurile.
• Identificarea intrărilor de testare și solicitarea datelor de testare necesare pentru executarea cazurilor de testare, precum și pentru verificarea funcționalității aplicației.
• Determinați rezultatele reale conform valorilor de intrare care urmează să fie testate.
• Executați cazurile de testare care determină dacă comportamentul aplicației este așa cum era de așteptat sau dacă a apărut vreun defect.
• Comparați rezultatul real și rezultatul calculat pentru a afla rezultatul real.

Q # 3) Explicați diferența dintre testarea funcțională și testarea nefuncțională.

Răspuns: Diferența dintre testarea funcțională și testarea nefuncțională poate fi explicată după cum urmează:

Q # 4) În ce fel „Build” este diferit de „Release”?

Răspuns: Construiește este un fișier executabil care se referă la acea parte a aplicației care este predată unui tester pentru a testa funcționalitatea implementată a aplicației împreună cu unele remedieri de erori. Construirea poate fi respinsă de echipa de testare dacă nu trece lista de verificare critică care conține funcționalitatea majoră a aplicației.

Pot exista mai multe versiuni în ciclul de testare al unei aplicații.

Eliberare se referă la aplicația software care nu mai este în faza de testare și după finalizarea testării și dezvoltării, aplicația este predată clientului. O versiune are mai multe versiuni asociate.

Q # 5) Explicați ciclul Bug.

Răspuns: Se spune că eroarea este o eroare nedorită, o eroare, o greșeală etc. care a avut loc în cadrul aplicației și care împiedică livrarea rezultatului dorit. Atunci când se întâlnește un defect sau o eroare într-o aplicație în timpul testării, apoi de la înregistrarea unui defect până la rezolvarea acestuia, un bug se deplasează printr-un ciclu de viață definit cunoscut sub numele de Bug Lifecycle.

Figura de mai jos vă va oferi o idee despre ciclul de viață al erorilor:

(imagine sursă )

Întregul proces se desfășoară pe măsură ce apare o problemă sau o eroare. Este raportat / conectat în instrumentul de urmărire a erorilor, urmând un format considerabil. Aceste bug-uri sunt atribuite dezvoltatorului și starea acestuia este „Open”. Dezvoltatorul poate examina acum bug-ul, îl poate reproduce la sfârșitul acestuia și începe să lucreze la el.

Dacă eroarea este remediată, dezvoltatorul își schimbă starea în „Fix” sau starea poate fi mutată în „nevoie de mai multe informații”, „nu va remedia”, „nu se poate reproduce” etc., în alte cazuri. QA efectuează apoi regresia, adică verifică din nou erorile cu o acțiune specifică și răspunde în consecință.

Dacă problemele / eroarea se comportă acum așa cum era de așteptat, atunci starea sa se schimbă în Verificat / Închis altfel Redeschideți.

Q # 6) Înscrieți o anumită stare de eroare împreună cu descrierea acesteia.

implementați coada prioritară c ++

Răspuns: Mai jos sunt enumerate câteva stări de erori împreună cu descrierile lor:

• Nou: Când defectul sau eroarea este înregistrată pentru prima dată, se spune ca Nou.
• Atribuit: După ce testerul a înregistrat o eroare, eroarea sa este examinată de conducătorul testerului și apoi este atribuită echipei de dezvoltatori corespunzătoare.
• Deschis: Tester înregistrează o eroare în starea Deschis și rămâne în starea deschisă până când dezvoltatorul a efectuat o anumită sarcină cu eroarea respectivă.
• Rezolvat / remediat: Când un dezvoltator a rezolvat eroarea, adică acum aplicația produce rezultatul dorit pentru o anumită problemă, atunci dezvoltatorul își schimbă starea în Rezolvat / Remediat.
• Verificat / închis: Când un dezvoltator a schimbat starea în rezolvat / remediat, testerul testează acum problema la sfârșit și, dacă este remediat, el schimbă starea erorii în „Verificat / Închis”.
• Redeschide: Dacă un tester este capabil să reproducă din nou bug-ul, adică bug-ul există încă chiar și după remedierea de către dezvoltator, starea acestuia este marcată ca Redeschideți.
• Nu este o eroare / nevalid: O eroare poate fi marcată ca nevalidă sau nu o eroare de către dezvoltator atunci când problema raportată este conformă funcționalității, dar este înregistrată din cauza interpretării greșite.
• Amânat: De obicei, atunci când bug-ul are o prioritate minimă pentru lansare și dacă există lipsă de timp, în acest caz, acele bug-uri cu prioritate minimă sunt amânate la următoarea versiune.
• Nu poate reproduce: Dacă dezvoltatorul nu poate reproduce eroarea la sfârșitul acesteia, urmând pașii menționați în problemă.

Q # 7) Ce se numește testare bazată pe date?

Răspuns: Testarea bazată pe date este metodologia în care o serie de scripturi de testare care conțin cazuri de testare sunt executate în mod repetat folosind surse de date precum foaia de calcul Excel, fișier XML, fișier CSV, bază de date SQL pentru valorile de intrare și ieșirea reală este comparată cu cea așteptată în verificare proces.

De exemplu, un studio de testare este utilizat pentru testarea bazată pe date.

Unele avantaje ale testării bazate pe date sunt:

• Reutilizare.
• Repetabilitate.
• Separați datele de testare de logica de testare.
• Numărul de cazuri de testare este redus.

Q # 8) Care sunt punctele importante care ar trebui luate în considerare în timpul redactării cazurilor de testare?

Răspuns: Scrierea unui caz de testare este considerată a fi cea mai importantă activitate a procesului de execuție a testului, care necesită abilități de scriere, precum și cunoștințe aprofundate ale aplicației pentru a face cazuri de testare eficiente și reutilizabile.

Câteva puncte importante care ar trebui luate în considerare la redactarea cazurilor de testare includ:

• Ar trebui să existe o înțelegere clară a cerințelor clientului înainte de a începe să scrie cazurile de testare. Nimic nu trebuie presupus și orice îndoială cu privire la cerințe ar trebui eliminată.
• Fiecare cerință ar trebui să fie inclusă sub formă de cazuri de testare și nimic nu ar trebui să fie omis. De obicei, matricea de trasabilitate este menținută pentru a ține o verificare a fiecărei cerințe de implementare și finalizare a testării.
• Conform specificațiilor documentului de cerință, trebuie să fie acoperită orice cerință funcțională și nefuncțională, inclusiv interfața UI.
• Cazurile de testare trebuie verificate din când în când pentru a nu se repeta sau redunda.
• Prioritatea este un factor important care ar trebui stabilit pentru cazurile de testare în timpul scrierii. Această prioritate îl ajută pe tester să testeze aplicația mai întâi cu cazurile de testare cu prioritate ridicată care includ funcționalități de bază, apoi cu cazurile de testare cu prioritate medie și mai târziu.
• Pentru o anumită versiune, cazurile de test pot fi, de asemenea, create Sprint, astfel încât testerul, precum și dezvoltatorul, să poată analiza calitatea produsului pe baza execuției cazului de testare.
• Structura cazurilor de testare trebuie înțeleasă cu ușurință și trebuie să fie într-un limbaj simplu. Valorile datelor de intrare pentru cazurile de testare ar trebui să fie valabile, precum și într-o gamă largă.

Q # 9) Ce este testarea automatizării?

Răspuns: Testarea automatizării este o metodologie de testare în care se folosește un instrument de automatizare pentru a executa suita de cazuri de testare pentru a crește acoperirea testelor, precum și viteza de execuție a testelor. Testarea automatizării nu necesită nicio intervenție umană, deoarece execută teste pre-scriptate și este capabilă să raporteze și să compare rezultatele cu testele anterioare.

Repetabilitatea, ușurința utilizării, precizia și o mai mare consistență sunt câteva dintre avantajele testării automatizării.

Unele instrumente de testare a automatizării sunt enumerate mai jos:

• Seleniu
• Telurul
• apă
• SoapUI

Q # 10) Explicați termenul Testarea la stres și Testarea sarcinii.

Răspuns:

Testare stresanta este o formă de testare a performanței în care aplicația este obligată să treacă prin efort sau stres, adică executarea aplicației peste pragul pauzei pentru a determina punctul în care aplicația se blochează. Această condiție apare de obicei atunci când există prea mulți utilizatori și prea multe date.

Testarea la stres verifică și recuperarea aplicației atunci când volumul de lucru este redus.

Testarea sarcinii este o formă de testare a performanței în care aplicația este executată deasupra diferitelor niveluri de încărcare pentru a monitoriza performanțele maxime ale serverului, timpul de răspuns, randamentul serverului etc. Prin testarea sarcinii, stabilitatea procesului, performanța și integritatea aplicației sunt determinate sub sarcină simultană a sistemului .

Q # 11) Ce înțelegeți prin testarea volumului?

Răspuns: Testarea volumului este o formă de testare a performanței care determină nivelurile de performanță ale randamentului serverului și timpul de răspuns atunci când utilizatorii concurenți, precum și încărcarea mare de date din baza de date, sunt puse în sistem / aplicație sub teste.

Q # 12) Care sunt diferitele tehnici de testare utilizate în testarea funcțională?

Răspuns: Există două tehnici de testare diferite care sunt utilizate în testarea funcțională.

Acestea pot fi definite după cum urmează:

• Testarea bazată pe cerințe: Această formă de testare funcțională se realizează prioritizând cerințele pe baza criteriilor de risc. Acest lucru asigură, de asemenea, că toate căile de testare critice au fost incluse în procesul de testare.
• Testarea bazată pe proces de afaceri: Această formă de testare funcțională este realizată din perspectiva procesului de afaceri. Scenariile includ cunoașterea proceselor de afaceri pentru efectuarea testelor.

Q # 13) Ce înțelegeți prin testarea exploratorie? Când se efectuează?

Răspuns: Testarea exploratorie înseamnă testarea sau explorarea aplicației fără respectarea oricăror programe sau proceduri. În timp ce efectuează teste exploratorii, testerii nu urmează niciun tipar și își folosesc gândirea simplă și ideile diverse pentru a vedea cum funcționează aplicația.

Urmarea acestui proces acoperă chiar și cea mai mică parte a aplicației și ajută la găsirea mai multor probleme / erori decât în ​​procesul normal de testare a cazurilor de testare.

Testarea exploratorie se efectuează de obicei în cazurile în care:

• Există un tester cu experiență în echipa de testare care își poate folosi experiența de testare pentru a aplica toate cele mai bune scenarii posibile.
• Toate căile critice au fost acoperite și cazurile de testare majore sunt pregătite conform specificațiilor cerințelor care au fost executate.
• Există o aplicație critică și niciun caz posibil nu poate fi ratat.
• Un nou tester a intrat în echipă, explorarea aplicației îi va ajuta să înțeleagă mai bine și să-și urmeze propria minte în timp ce execută orice scenariu, mai degrabă decât să urmeze calea, așa cum este menționat în documentul de cerință.

Q # 14) Pentru orice aplicație web, care sunt funcțiile de conectare posibile care ar trebui testate?

Răspuns: Mai jos sunt enumerate scenariile posibile care pot fi efectuate pentru a testa complet caracteristica de conectare a oricărei aplicații:

• Verificați câmpurile de introducere, adică numele de utilizator și parola, atât cu valori valide, cât și cu valori nevalide.
• Încercați să introduceți un e-mail valid cu o parolă incorectă și, de asemenea, introduceți un e-mail nevalid și o parolă validă. Verificați dacă apare mesajul de eroare corect.
• Introduceți acreditări valide și conectați-vă la aplicație. Închideți și redeschideți browserul pentru a verifica dacă sunteți încă conectat.
• Introduceți aplicația după conectare și apoi navigați din nou la pagina de autentificare pentru a verifica dacă utilizatorului i se cere din nou să se conecteze sau nu.
• Conectați-vă de la un browser și deschideți aplicația din alt browser pentru a verifica dacă sunteți conectat sau nu la alt browser.
• Schimbați parola după conectarea la aplicație și apoi încercați să vă autentificați cu acea parolă veche.

Există și alte câteva scenarii posibile care pot fi testate.

Q # 15) Explicați testarea accesibilității și importanța acesteia în scenariul actual.

Răspuns: Testarea accesibilității este o formă de testare a utilizabilității în care testele sunt efectuate pentru a se asigura că aplicația poate fi ușor manipulată de persoanele cu dizabilități, cum ar fi auzul, orbirea culorii, vizibilitatea redusă etc. În scenariul de astăzi, web-ul a dobândit locul major în viața noastră în forma site-urilor de comerț electronic, e-learning, plăți electronice etc.

Astfel, pentru a crește mai bine în viață, toată lumea ar trebui să poată face parte din tehnologie, în special persoanele cu unele dizabilități.

Mai jos sunt enumerate câteva tipuri de software care ajută și ajută persoanele cu dizabilități să utilizeze tehnologia:

• Software de recunoaștere a vorbirii
• Software pentru citirea ecranului
• Software de mărire a ecranului
• Tastatură specială

Q # 16) Ce este testarea Adhoc?

Răspuns: Testarea adhoc, cunoscută de obicei sub numele de testare aleatorie, este o formă de testare care nu urmează niciun caz de testare sau cerințelor cererii. Testarea adhoc este practic o activitate neplanificată în care orice parte a aplicației este verificată aleatoriu pentru a găsi defecte.

În astfel de cazuri, defectele întâlnite sunt foarte greu de reprodus, deoarece nu sunt urmărite cazuri de testare planificate. Testarea adhoc se efectuează de obicei atunci când există un timp limitat pentru efectuarea testelor elaborative.

Q # 17) Ce este partiționarea echivalenței?

Răspuns: Partiționarea echivalenței, cunoscută și sub numele de partiționare a clasei de echivalență, este o formă de testare a cutiei negre în care datele de intrare sunt împărțite în clase de date. Acest proces se face pentru a reduce numărul de cazuri de testare, dar acoperind totuși cerința maximă.

Se aplică tehnica de partiționare a echivalenței unde valorile datelor de intrare pot fi împărțite în intervale. Gama valorilor de intrare este definită în așa fel încât să fie testată doar o condiție din fiecare partiție de gamă, presupunând că toate celelalte condiții ale aceleiași partiții se vor comporta la fel pentru software.

De exemplu: Pentru a identifica rata dobânzii conform soldului din cont, putem identifica intervalul valorii soldului din cont care câștigă o rată diferită a dobânzii.

Q # 18) Explicați analiza valorii limită.

Răspuns: Metoda de analiză a valorilor limită verifică valorile limită ale partițiilor din clasa de echivalență. Analiza valorii limită este în esență o tehnică de testare care identifică erorile la limite mai degrabă decât în ​​cadrul valorilor intervalului.

De exemplu , Un câmp de intrare poate permite un minim de 8 caractere și un maxim de 12 caractere, apoi 8-12 sunt considerate ca interval valid și 13 sunt considerate ca interval nevalid. În consecință, cazurile de testare sunt scrise pentru valoarea de partiție validă, valoarea exactă la limită și valoarea de partiție nevalidă.

Q # 19) Explicați diferența dintre severitate și prioritate.

Răspuns: Severitatea defectului este definit de nivelul sau gradul de impact al defectului asupra aplicației supuse testului. Cu cât severitatea defectului este mai mare, cu atât impactul asupra aplicației este mai mare.

Următoarele sunt cele 4 clase în care este clasificată severitatea defectului:

• Critic
• Major
• Mediu
• Scăzut

Prioritate defect definește ordinea în care defectul ar trebui rezolvat mai întâi, adică cu cât prioritatea defectului este mai mare implică faptul că aplicația este inutilizabilă sau blocată la un moment dat și defectul ar trebui rezolvat cât mai curând posibil.

Următoarele sunt cele 3 clase în care este definită o prioritate de defect:

• Înalt
• Mediu
• Scăzut

Q # 20) Când efectuăm testarea fumului?

întrebări și răspunsuri la interviul informatica powercenter

Răspuns: Testarea fumului se efectuează pe aplicație după primirea construcției. Testerul testează de obicei calea critică și nu funcționalitatea în profunzime pentru a se asigura, dacă construcția urmează să fie acceptată pentru testare ulterioară sau să fie respinsă în cazul unei aplicații defecte.

O listă de verificare a fumului conține de obicei calea critică a aplicației fără de care o aplicație este blocată.

Q # 21) Ce înțelegeți prin testarea Sanity?

Răspuns: Testarea sănătății se efectuează după primirea versiunii pentru a verifica noua funcționalitate / defecte care urmează să fie remediate. În această formă de testare, obiectivul este de a verifica funcționalitatea aproximativ așa cum era de așteptat și de a determina dacă bug-ul este remediat, precum și efectul bug-ului remediat asupra aplicației supuse testului.

Nu are rost să accepți construcția de către tester și să pierzi timp dacă testarea Sanity eșuează.

Q # 22) Ce înțelegeți prin Matricea de trasabilitate a cerințelor?

Răspuns: Matricea de trasabilitate a cerințelor (RTM) este un instrument pentru a ține evidența acoperirii cerințelor în procesul de testare.

În RTM, toate cerințele sunt clasificate ca fiind dezvoltate în cursul sprintului și ID-urile respective (implementarea / îmbunătățirea noilor caracteristici / problemele anterioare etc.) sunt menținute pentru a ține evidența faptului că tot ceea ce este menționat în documentul de cerință a fost implementat înainte de lansarea produsul.

RTM este creat imediat ce documentul de cerință este primit și este menținut până la lansarea produsului.

Q # 23) Care sunt factorii care trebuie luați în considerare în testarea bazată pe risc?

Răspuns: Prin testarea bazată pe risc a unui proiect, nu este vorba doar de a furniza un proiect fără riscuri, ci principalul scop al testării bazate pe risc este de a obține rezultatul proiectului prin realizarea celor mai bune practici de gestionare a riscurilor.

Principalii factori care trebuie luați în considerare în testarea bazată pe risc sunt următorii:

• Pentru a identifica când și cum să implementeze testarea bazată pe riscuri pe o aplicație adecvată.
• Pentru a identifica măsurile care acționează bine în găsirea și gestionarea riscurilor în zonele critice ale aplicației.
• Pentru a obține rezultatul proiectului care echilibrează riscul cu calitatea și caracteristica aplicației.

Q # 24) Diferențiați între testarea de regresie și re-testarea.

Răspuns: Diferența dintre testarea de regresie și re-testarea poate fi explicată după cum urmează:

Q # 25) Explicați testarea acceptării utilizatorului.

Răspuns: Testarea acceptării utilizatorilor se efectuează de obicei după ce produsul este testat temeinic. În această formă de testare, utilizatorii de software sau, de exemplu, clientul, utilizează aplicația pentru a se asigura că totul funcționează conform cerințelor și perfect în scenariul din lumea reală.

UAT este, de asemenea, cunoscut sub numele de testarea utilizatorului final.

Concluzie

Prin acest articol, am încercat să explic fiecare subiect al testării funcționale, astfel încât orice persoană care se pregătește pentru interviu să poată înțelege cu ușurință subiectul și să-și amintească și ele.

Aceste întrebări și răspunsuri ale interviului de testare funcțională vă vor ghida să ștergeți cu succes orice interviu cu încredere deplină.

Vă dorim tuturor succes.

Sper că aceste întrebări și răspunsuri la interviuri de testare funcțională vă vor ajuta la un moment dat în carieră.

Lectură recomandată

• Testarea funcțională Vs testarea non-funcțională
• 16 caracteristici noi ale instrumentului Micro Focus UFT (test funcțional unificat) - QTP vs UFT
• 5 Cele mai bune instrumente alternative de testare funcțională unificată HP (UFT)
• Un ghid complet de testare nefuncțională pentru începători
• Un ghid pas cu pas pentru Jubula - Instrumentul de testare funcțională automată Open Source
• Testarea funcțională vs. Testarea performanței: ar trebui să se facă simultan?
• Ghid complet de testare funcțională cu tipurile și exemplul său
• Tutorial Parrot QA: Revizuirea instrumentului de testare funcțională a browserului încrucișat
• Spock pentru integrare și testare funcțională cu seleniu
• Diferențele dintre testarea unitară, testarea integrării și testarea funcțională
• Top 25 Întrebări și răspunsuri la interviuri de testare funcțională
• Top 30 instrumente de testare funcțională în 2021