Preguntes D'entrevista

Les 100 millors preguntes i respostes de l'entrevista de proves manuals

2 de gener de 2022

Les proves manuals es poden definir com una tècnica de prova de programari on els casos de prova s'executen manualment sense utilitzar cap eina automatitzada. Aquí, tots els casos de prova seran executats manualment pel provador segons la perspectiva de l'usuari final. S'assegurarà si l'aplicació funciona, segons el document de requisits o no.

Si esteu buscant preguntes i respostes d'entrevistes de proves manuals, sou a la pàgina correcta. Assegureu-vos de revisar totes les preguntes que s'esmenten en aquesta publicació.

Taula de continguts

Preguntes principals de l'entrevista de proves manuals

1. Definiu les proves de programari?

Les proves de programari es poden definir com la tècnica de verificació de sistemes amb el propòsit d'identificar els requisits d'errors, faltants o buits en comparació amb el requisit real. Les proves de programari es classifiquen en dos tipus:

  1. Prova funcional
  2. Proves no funcionals

2. Què és la prova exploratòria?

Prova exploratòria es pot definir com un tipus de prova de programari on no creem els casos de prova amb antelació, però els verificadors comproven el sistema sobre la marxa. Els verificadors anotaran idees sobre què provar abans de l'execució de la prova. L'enfocament principal de les proves exploratòries està més en les proves com a activitat de pensament.

3. Per què necessitem proves de programari?

Les proves de programari són necessàries a causa del següent:

  1. Per comprovar l'adaptabilitat del programari
  2. Per identificar errors
  3. Per guanyar la confiança del client
  4. Per evitar costos addicionals
  5. Per accelerar el desenvolupament de programari
  6. Per evitar riscos
  7. Per optimitzar el negoci

4. Quan hem d'acabar el procés de prova?

  1. Terminis de prova.
  2. Realització d'una cobertura funcional i de codi fins a un punt concret
  3. Finalització de l'execució del cas de prova.
  4. Quan la taxa d'error baixa d'un cert nivell i no s'identifiquen errors d'alta prioritat.
  5. Decisió de gestió

5. Definiu les proves de casos d'ús?

Prova de casos d'ús

La prova de casos d'ús es pot definir com un mecanisme que ajudarà a identificar casos de prova que cobreixen tot el sistema, de principi a fi, transacció per transacció. També és una descripció de l'ús específic del sistema per part de l'usuari. S'utilitza principalment en el desenvolupament de proves o sistemes per a alguns nivells acceptables.

6. Podeu enumerar les dues categories principals de proves de programari?

Les proves de programari es classifiquen àmpliament en dues àrees:

Prova manual – Es pot definir com el tipus més antic de proves de programari on els verificadors han d'executar manualment els casos de prova sense utilitzar cap de les eines d'automatització de proves. Significa que l'aplicació de programari és provada manualment pels verificadors de control de qualitat.

Proves d'automatització – Es pot definir com la tècnica d'utilitzar eines d'assistència, scripts i programari per realitzar els casos de prova repetint les accions predefinides. L'automatització de proves normalment se centra a substituir l'activitat humana manual per alguns sistemes o dispositius que millorin l'eficiència.

7. Definiu el control de qualitat? Són tant control de qualitat com garantia de qualitat?

En proves de programari, Control de qualitat Es pot definir com un grup sistemàtic de processos que s'utilitzen per garantir la qualitat dels productes o serveis de programari. L'objectiu del procés de control de qualitat és garantir que el producte de programari ha de complir els requisits reals mitjançant la revisió i prova dels seus requisits funcionals i no funcionals.

Garantia de qualitat generalment es relaciona amb com es realitza el procés o com es fa un producte, i el control de qualitat es defineix com l'aspecte d'inspecció de la gestió de la qualitat.

8. Quan comencen les proves estàtiques i què cobreixen?

La prova estàtica es pot definir com una tècnica de prova de programari utilitzada per comprovar defectes en aplicacions de programari sense executar codi. Es realitzen proves estàtiques per evitar errors en les primeres fases de desenvolupament perquè és fàcil identificar els errors i resoldre'ls.

9. Què és la matriu de traçabilitat de requisits?

La matriu de traçabilitat de requisits (RTM) a les proves de programari és un document que maparà i rastrejarà els requisits dels usuaris amb els casos de prova. Captarà tots els requisits que proposa el client i la traçabilitat dels requisits en un únic document que s'entrega al final del cicle de vida del desenvolupament de programari.

10. Enumereu els diferents tipus de proves manuals?

  1. Proves d'integració
  2. Prova de la caixa negra
  3. Prova de caixa blanca
  4. Proves d'unitat
  5. Prova del sistema
  6. Prova d'acceptació

Preguntes d'entrevista de proves manuals

11. Definiu les proves de caixa negra?

Les proves de caixa negra es poden definir com una tècnica de prova de programari que examinarà la funcionalitat de l'aplicació sense mirar el seu funcionament o estructures internes. Aquest mètode de prova s'aplica virtualment a tots i cadascun dels nivells de prova de programari: unitat, integració, sistema i acceptació.

12. Definiu les proves de partició d'equivalència?

La partició d'equivalència o la partició de classe d'equivalència es pot definir com un mecanisme de prova de programari que dividirà les dades d'entrada d'una unitat de programari determinada en les particions de dades equivalents de les quals es deriven els casos de prova. En principi, els casos de prova estan dissenyats de manera que cobreixin cada partició almenys una vegada.

Vegeu també Les 100 millors preguntes i respostes d'entrevista Ansible

13. Definiu un pla de proves i què inclou?

Un pla de proves en Proves de programari inclou una descripció del producte, l'abast, el calendari, els procediments, els objectius, les estratègies de prova, els recursos de prova i els lliurables. Els plans de proves són molt importants en el desenvolupament del programari, ja que descriuen quines proves requereixen per assegurar-se que el programari compleix els estàndards i que funciona exactament com hauria de ser.

Un pla de prova inclou:

  1. Objectius de prova
  2. Àmbit de prova
  3. Prova el marc
  4. Medi ambient
  5. Motiu de la prova
  6. Criteris d'entrada i sortida
  7. Entregables
  8. Factors de risc

14. Definiu les proves de caixa blanca i enumereu els seus tipus?

La prova de caixa blanca és un mecanisme de prova que examinarà l'estructura del programa i deriva les dades de la prova del codi o la lògica del programa. Els altres noms de proves de caixes de vidre són proves clares basades en lògica o proves basades en camins o proves estructurals, o proves de caixa, proves de caixa oberta.

Tipus:

  1. Cobertura de la declaració
  2. Cobertura de decisions

15. Diferenciar entre proves alfa i proves beta?

Prova alfa Prova beta
Es realitza per identificar errors abans de llançar el producte a usuaris reals o al públic.Normalment el fan usuaris reals d'una aplicació de programari en un entorn en temps real.
El realitzen els Testers dins de l'organitzacióEl realitzen els usuaris finals.
Es realitza al lloc del desenvolupador.Es realitza a la ubicació del client.

16. Definiu la cobertura de la prova?

La cobertura de prova es pot definir com una tècnica que determina si els casos de prova cobreixen realment el codi d'aplicació donat i quant de codi s'ha d'exercir quan executem aquests casos de prova. Suposem que hi ha 10 requisits i es creen 100 proves, i si s'executen 90 proves, la cobertura de la prova és del 90%.

17. A les proves de caixa blanca, què s'ha de verificar?

  1. La prova de caixa blanca ha de verificar els camins incomplets o trencats del codi
  2. Ha de verificar el flux de l'estructura segons les especificacions del document donat.
  3. Ha de verificar les sortides esperades.
  4. Ha de verificar els forats de seguretat del codi
  5. Ha de verificar tots els bucles condicionals del codi donat per comprovar la funcionalitat completa d'una aplicació.
  6. Ha de verificar la codificació línia per línia i cobrir les proves al 100%.

18. Llista els diferents nivells de proves manuals?

Proves d'integració – És un nivell de proves de programari on es combinen les unitats individuals, i es testegen per comprovar si funcionen segons les necessitats quan s'integren. L'objectiu principal aquí és provar una interfície entre els mòduls.

Proves d'unitat – És un mecanisme de prova de la peça de codi més petita (anomenada unitat) que està lògicament aïllada en un sistema. Se centra en la correcció funcional d'un mòdul autònom.

Prova del sistema – En aquest tipus de proves, tots els components del programari es posen a prova en conjunt per garantir que el producte global compleixi els requisits especificats. Hi ha diversos tipus de proves del sistema; alguns d'ells són proves d'usabilitat, proves de regressió i proves funcionals.

Prova d'acceptació d'usuaris – És un nivell final, una prova d'acceptació o una prova d'acceptació de l'usuari, que determina si el programari està preparat per ser llançat.

19. Podem aconseguir una cobertura de proves del 100%? Com assegurar-ho?

No és possible realitzar proves al 100% de cap producte. Però podem seguir els passos per aconseguir-ho (més a prop):

  1. Es pot establir un límit dur al Percentatge de casos de prova aprovats i al Nombre d'errors trobats.
  2. Establiu una bandera vermella si s'esgota un pressupost de prova i s'incompleix els terminis.
  3. Estableix una bandera verda si tota la funcionalitat cobreix els casos de prova i Tots els errors crítics tenen l'estat 'TANCAT'.

20. Podeu enumerar les diferents tècniques de prova de la caixa negra?

  1. Partició d'equivalència
  2. Anàlisi del valor límit
  3. Gràfics causa-efecte

Preguntes d'entrevista de proves manuals

21. Definiu el banc de proves a les proves manuals?

El banc de proves sol contenir maquinari, programari, configuració de xarxa, el producte en prova, el sistema operatiu, un altre programari del sistema i el programari d'aplicació específics.

22. Podem fer proves del sistema en qualsevol moment?

La resposta és no. Les proves del sistema han de començar si tots els mòduls estan al seu lloc i funcionen correctament. Però, s'ha de realitzar abans de la UAT (prova d'acceptació d'usuari).

23. Diferenciar entre proves estàtiques i dinàmiques?

Prova estàtica Prova dinàmica
Les proves estàtiques es refereixen a la prevenció.Les proves dinàmiques es refereixen a la cura.
Les proves estàtiques són més rendibles.És menys rendible.
Les proves estàtiques es fan normalment en l'etapa de verificació.Les proves dinàmiques es fan en l'etapa de validació.

24. Pot explicar el procediment per a la prova manual?

  1. Cal analitzar els requisits del document d'especificació de requisits de programari.
  2. A continuació, creeu un pla de prova clar.
  3. A continuació, escriviu els casos de prova que cobreixen tots els requisits que es defineixen al document.
  4. A continuació, feu que el responsable del control de qualitat revisi els vostres casos de prova.
  5. Executeu els casos de prova i detecteu qualsevol error en qualsevol.
  6. A continuació, informeu d'errors i, un cop solucionats, torneu a executar les proves fallides per tornar a verificar les correccions.

25. Llista els diferents tipus de proves de programari?

  1. Prova unitària
  2. Proves de caixa blanca i caixa negra
  3. Proves d'integració
  4. Prova de regressió
  5. Prova de sacsejada
  6. Prova de fum
  7. Prova funcional
  8. Proves de rendiment
  9. Proves alfa i beta
  10. Prova del sistema

26. Llista els diferents nivells de prova?

  1. Proves d'unitat/component/programa/mòdul
  2. Proves d'integració
  3. Prova del sistema
  4. Prova d'acceptació

27. Què és un cas de prova?

Cas de prova

Un cas de prova en proves de programari es pot definir com un conjunt d'accions que s'executen per verificar una característica o funcionalitat determinada de l'aplicació de programari. Un cas de prova consisteix en passos de prova, condicions prèvies, condicions posteriors i dades de prova que es desenvolupen per a escenaris de prova específics per verificar qualsevol requisit.

28. Diferenciar entre un controlador de prova i un taló de prova?

Controlador de proves Tall de prova
Els controladors es troben principalment en proves d'integració de baix a dalt.Els talons s'utilitzen normalment a les proves d'integració de dalt a baix.
Els controladors són el programa de trucades.Els stubs es coneixen com a programes, són proves àgils

29. Què és la prova d'integració?

Les proves d'integració es defineixen normalment com la fase de les proves de programari on els mòduls de programari individuals es fusionen i es posen a prova com a grup. Les proves d'integració es realitzen principalment per avaluar el compliment d'un component o sistema amb els requisits funcionals especificats.

30. Què és la prova de l'API?

La prova d'API es pot definir com un tipus de prova de programari que validarà les interfícies de programació d'aplicacions (API). L'objectiu principal de les proves d'API és comprovar la fiabilitat, la funcionalitat, el rendiment i la seguretat de les interfícies de programació. Normalment es concentra en la capa de lògica empresarial de l'arquitectura del programari.

Preguntes d'entrevista de proves manuals

31. Per què són importants les proves àgils?

Les proves àgils permetran la col·laboració i les comunicacions coherents entre els equips de proves i desenvolupament. Com a resultat, s'evita problemes complexos. A més de l'equip fort, l'equip de proves pot formar part del procés de producció en lloc d'entrar abans del llançament.

32. Diferenciar entre les proves d'acceptació d'usuaris i les proves del sistema?

Prova d'acceptació d'usuaris Prova del sistema
Aquí, comprovem si el sistema s'ajusta als requisits o no.Aquí, testem el rendiment de tot el sistema.
Aquesta prova utilitza els valors d'entrada reals en temps real que proporciona l'usuari.Aquesta prova utilitza valors d'entrada de demostració seleccionats pels equips de prova.

33. Definir les proves de flux de dades?

Prova de flux de dades

Les proves de flux de dades es defineixen normalment com una família d'estratègies de prova que es basen a seleccionar camins a través del flux de control d'un programa per explorar una seqüència d'esdeveniments relacionats amb l'estat de les variables o els objectes de dades. La prova de flux de dades se centra principalment en els punts on les variables rebran valors i els punts en què s'utilitzen aquests valors.

Els casos de prova han de tenir els atributs següents:

  1. L'entrada al mòdul
  2. La ruta del flux de control per a la prova
  3. Un conjunt d'una definició de variable adequada i el seu ús
  4. El resultat esperat dels casos de prova

És un mecanisme per comprovar els errors que actuen pels equips de desenvolupament per verificar que s'han solucionat.

35. Quina és la intenció de les proves d'extrem a extrem?

Les proves d'extrem a extrem es poden definir com una tècnica que provarà tot el producte de programari, és a dir, de principi a fi, per assegurar-se que el flux de l'aplicació es comportarà com s'esperava. Defineix les dependències del sistema d'un producte i s'assegurarà que totes les peces integrades funcionin juntes com s'esperava.

36. Quins són els passos per resoldre els problemes/problemes durant la prova?

  1. Registre: és un registre i pot gestionar qualsevol problema que hagi passat.
  2. Informe: informarà dels problemes a un responsable de nivell superior.
  3. Control: Definirà el procés de gestió de problemes.

37. Diferenciar entre un error i un defecte?

ErrorDefecte
Un error es pot definir com una fallada del programari que es detecta durant el temps de prova.Normalment, un defecte es defineix com una variació entre els resultats esperats i els resultats reals que detecten els desenvolupadors després de la posada en marxa del producte.

38. Quins passos s'han de seguir quan apareix un error durant la prova?

Passos:

  1. Informeu el problema tan aviat com sigui possible.
  2. Fes una doble comprovació de l'error abans d'informar d'un error.
  3. Comproveu si es produeix el mateix error en algun altre mòdul relacionat.
  4. Escriu un bon resum d'errors:
  5. No feu servir cap llenguatge ofensiu a l'error.
  6. Abans de fer clic al botó Envia, reviseu l'informe d'error.

39. Diferenciar entre escenaris de prova, casos de prova i scripts de prova?

A Escenari de prova es pot definir com qualsevol funcionalitat que es pugui provar.

Casos de prova: Es pot definir com un document que contindrà els passos que s'executaran; s'ha planificat abans.

Script de prova: Normalment s'escriuen en un llenguatge de programació, i és un programa breu que s'utilitza per provar part de la funcionalitat del sistema de programari.

40. Podeu enumerar els avantatges i els desavantatges de les proves manuals?

Avantatges:

  1. Les proves manuals d'una aplicació identifiquen els problemes, com ara incloure els problemes d'aspecte d'una aplicació.
  2. Els components visuals com ara el disseny, el text i altres components són fàcilment accessibles pel provador i CEBA i UX es detecten problemes.
  3. Té un baix cost d'operació ja que no fem servir les eines ni les habilitats d'alt nivell.
  4. És adequat per als casos en què fem alguns canvis no planificats a una aplicació perquè és adaptable.
  5. Els humans poden observar, jutjar i proporcionar intuïció en el cas de la prova manual, i és molt útil quan es tracta de la facilitat d'ús o de l'experiència del client rica.
Vegeu també Les 100 principals preguntes i respostes de l'entrevista de JavaScript

Desavantatges:

  1. Les proves manuals requereixen molt de temps.
  2. No és fàcil trobar diferències de mida i combinacions de colors dels objectes de la GUI mitjançant una prova manual.
  3. Carrega provant i rendiment provant són impracticables en proves manuals .
  4. Quan hi ha un gran nombre de proves, manualment corrent proves és una feina que requereix temps.
  5. La regressió Prova els casos que es realitzen mitjançant proves manuals requereixen molt de temps.

Preguntes d'entrevista de proves manuals

41. Quan fer les proves manuals?

Normalment realitzem proves manuals en aquests escenaris:

Prova adhoc: Proves adhoc, proves no planificades. No té cap enfocament concret definit, ni té cap documentació que hi estigui associada. Les proves adhoc són informals i el factor important que cal tenir en compte aquí és el coneixement i la perspicacia del provador. En aquests casos, la prova manual és una bona opció.

Prova d'usabilitat: És un escenari on necessitem proves manuals; és el cas de les proves d'usabilitat. Normalment realitzem aquestes proves d'usabilitat per avaluar com d'eficaç, còmode i fàcil d'utilitzar ha resultat ser el producte per als usuaris finals. Per a aquesta avaluació, normalment necessitem la màxima intervenció manual, i no podem confiar en les eines per avaluar-la. Per tant, per avaluar el producte des de la perspectiva de l'usuari final, en general optem per les proves manuals.

Proves exploratòries: Realitzem proves manuals quan la documentació de la prova és deficient i tenim un període de temps molt curt per a l'execució; en aquest tipus de casos, aquesta prova exploratòria requerirà creativitat i habilitats analítiques del provador i el coneixement del producte del provador. Sempre que realitzem proves exploratòries, anirem a la verificació manual, ja que no podem utilitzar eines amb poca documentació i coneixements.

42. Podem provar un programa a fons?

Hi ha les dues raons principals que poden fer impossible provar un programa a fons:

  1. Les especificacions del programari es fan subjectives i donen lloc a diferents interpretacions.
  2. Un programa de programari pot requerir moltes entrades, combinacions de camins i sortides.

43. Què és un defecte latent?

El defecte latent es pot definir com un defecte que el client desconeix, tret que s'enfronti a una situació imprevista i, al mateix temps, el promotor o venedor tingui coneixement d'un defecte.

44. Quin és el paper de la documentació en les proves manuals?

La documentació de prova es pot definir com una documentació d'artefactes que es creen abans o durant la prova del programari. Ajuda als equips de prova a estimar l'esforç de prova que es necessita, la cobertura de la prova, el progrés de l'execució, el seguiment dels recursos, etc.

45. Com provareu un producte si els requisits encara no s'han encrespat?

Si les especificacions requerides no estan disponibles per a un producte determinat, s'ha de crear un pla de prova basat en els supòsits que es fan sobre el producte. Però cal que tots els supòsits estiguin ben documentats en un pla de prova.

46. Pots enumerar els dos paràmetres que són útils per conèixer la qualitat de l'execució de la prova?

Els paràmetres són:

  1. Relació de rebuig de defecte
  2. Relació de fuites de defecte

47. Enumereu les fases implicades en el cicle de vida de les proves de programari?

Fases:

Anàlisi de requisits : Sol ser el primer pas implicat en el cicle de vida de les proves de programari. Aquí, en aquest pas, l'equip d'assegurament de la qualitat (QA) ha d'entendre el requisit com el que provarem i han d'esbrinar els requisits comprovables. Durant aquesta fase, l'equip de prova estudiarà els requisits des de la perspectiva de les proves per identificar els requisits comprovables.

Els diferents tipus de requisits inclouen:

  1. Requisits empresarials
  2. Requisits arquitectònics i de disseny
  3. Requisits del sistema i integració

Planificació de proves : És una fase important del cicle de vida de les proves de programari on aquí es defineixen totes les estratègies de prova. Aquesta fase també es coneix com a fase d'estratègia de prova. En aquesta fase, el responsable de proves sol participar en la determinació de les estimacions de costos i esforços per a tot el projecte. Definirà l'objectiu i l'abast del projecte.

Els tipus de proves més utilitzats són:

  1. Test unitari
  2. Proves d'API
  3. Prova d'integració
  4. Prova del sistema
  5. Instal·lació/desinstal·lació de proves
  6. Proves àgils

Desenvolupament de casos de prova: Això començarà un cop finalitzada la fase de planificació de la prova. Aquesta és una fase del STLC on l'equip de proves anotarà els casos de prova detallats. Juntament amb els casos de prova, l'equip de proves també prepara les dades de prova per a la prova. Un cop preparats els casos de prova, el responsable del control de qualitat els revisa.

Configuració de l'entorn de prova : La configuració d'un entorn de prova és una part vital del cicle de vida de les proves de programari. Un entorn de proves es pot definir com una configuració de programari i maquinari perquè els equips de proves executin els seus casos de prova. Admetrà l'execució de proves amb programari, maquinari i xarxa configurats.

Execució de la prova : La següent fase del cicle de vida de les proves de programari és l'execució de la prova. L'execució de proves és un mecanisme per executar codi i comparar els resultats reals i esperats. Quan comenci l'execució de la prova, els analistes de proves començaran a executar scripts de prova que es basen en l'estratègia de prova permesa al projecte.

Tancament del cicle de prova: És la fase final d'un cicle de vida de proves de programari. Implica trucar als membres de l'equip de prova que compleixin i avaluïn els criteris de finalització del cicle basats en la cobertura de la prova, el cost, el temps, els objectius empresarials crítics, la qualitat i el programari.

48. Com superar els reptes que s'enfronten a causa de la falta de documentació adequada per a les proves?

Si el document de requisits no està disponible, seguiu aquests passos:

  1. En primer lloc, assegureu-vos de llegir correctament els documents, referits pels desenvolupadors, per desenvolupar el producte i assegureu-vos de compartir els casos de prova amb ells. D'aquesta manera, el provador coneixerà com els desenvolupadors estan desenvolupant el programari, i els provadors podran dissenyar els casos de prova basant-s'hi.
  2. En cas d'ambigüitat, aclareix les coses el més aviat possible. Involucreu els equips, és a dir, provadors, desenvolupadors de clients i analistes empresarials. Assegureu-vos que després de la reunió i tots els equips estiguin al mateix nivell de comprensió perquè pugueu continuar amb el procés.
  3. Feu la documentació adequada del flux de treball. Això ajuda a entendre millor l'enfocament. Utilitzeu diagrames de flux i diagrames perquè sigui fàcil d'entendre.
  4. Assegureu-vos de preparar una llista d'elements dins i fora de l'àmbit i compartir-los amb tots els membres de l'equip i obtenir l'aprovació del responsable respectiu. Aleshores, el verificador pot actualitzar la llista en qualsevol moment després de la discussió amb els membres de l'equip.

49. Defineix fantasma a les proves de programari?

Phantom es pot definir com a programari gratuït i s'utilitza principalment per al llenguatge de programació d'automatització de la GUI de Windows. Ens permetrà prendre el control de les finestres i les seves funcions de manera automàtica. Simularà qualsevol combinació de pulsacions de tecles i clics del ratolí i també menús, llistes i molt més.

Preguntes d'entrevista de proves manuals

50. Pots enumerar els reptes clau de les proves de programari?

Desafiaments:

  1. Prova de l'aplicació completa
  2. Relació amb els desenvolupadors,
  3. Prova de regressió.
  4. Sempre estem provant amb limitacions de temps.
  5. Quines proves cal executar primer?
  6. Comprensió dels requisits
  7. La decisió d'aturar la prova

51. Explicar els resultats de la prova?

Els productes de prova es poden definir com a artefactes de prova que es donen a les parts interessades del projecte de programari durant el Cicle de Vida de Desenvolupament de Programari (SDLC). Aquests documents també s'anomenen proves de lliurament perquè s'entreguen al client juntament amb el producte final de l'aplicació de programari.

Hi ha diversos productes de prova en cada fase del cicle de vida del desenvolupament de programari

  1. Abans de la prova
  2. Durant la prova
  3. Després de les proves

52. Enumereu els diferents tipus de proves funcionals?

  1. UAT
  2. Proves de seny
  3. Prova d'interfície
  4. Proves d'integració
  5. Prova del sistema
  6. Prova de regressió
  7. Prova unitària
  8. Prova de fum

53. Què és la prova de mutació?

Les proves de mutació es poden definir com un tipus de proves de programari on es canvien o muten determinades declaracions del codi font per comprovar si els casos de prova són capaços de trobar errors en el codi font. L'objectiu principal de les proves de mutació és garantir la qualitat dels casos de prova en termes de robustesa que ha de fallar el codi font mutat.

54. Quines són les bones habilitats d'un enginyer de proves?

  1. Coneixement de tècniques de disseny de proves.
  2. Cal conèixer el procés de gestió de defectes.
  3. Coneixement del domini empresarial.
  4. Ha de tenir experiència en diversos esforços de prova.
  5. Haurien d'entendre els errors i errors comuns del programari.
  6. Han de tenir coneixements del sistema o de l'aplicació en prova.
  7. Haurien d'entendre el concepte del procés d'automatització de proves.

Preguntes d'entrevista de proves manuals

55. Definiu casos de prova funcionals i casos de prova no funcionals?

Casos de prova funcionals es defineixen com el que escriuen els gestors de control de qualitat per assignar proves dels requisits funcionals a altres membres de l'equip. Penseu en un cas de prova com una tasca. Una prova funcional assignarà la prova d'una funció o característica per veure si produeix el resultat esperat.

Proves no funcionals es pot definir com un tipus de prova de programari que s'utilitza per comprovar els aspectes no funcionals com ara la fiabilitat, la usabilitat, el rendiment, etc., d'una aplicació de programari. Està dissenyat de tal manera per provar la preparació d'un sistema segons els paràmetres no funcionals que mai s'aborden amb les proves funcionals.

56. Quines són les coses que cal tenir en compte abans de seleccionar Eines d'automatització per a l'AUT?

Punts a tenir en compte:

  1. Plataformes, tecnologia i tipus
  2. Competències del Tester
  3. Busqueu eines de prova automatitzades que admetin la creació de proves de gravació i reproducció i les opcions de creació manual.
  4. Gestió del canvi
  5. S'ha de poder veure clarament els resultats de les proves. Els taulers de control, els registres i altres instruments que registren i registren automàticament els resultats de l'informe faran que la gestió del procés de prova sigui més fluida i eficaç des del principi fins al final.
  6. Col·laboració
Vegeu també Les 100 millors preguntes i respostes d'entrevista Ansible

57. Defineix STLC?

El cicle de vida de les proves de programari (STLC) es pot definir com una estratègia de prova que us ajudarà a complir amb eficàcia els estàndards de qualitat del programari. STLC farà complir les proves sistemàtiques que es realitzen per fases.

58. Com realitzar l'anàlisi de riscos?

Passos a seguir:

  1. Trobeu la puntuació del risc.
  2. Fes un perfil del risc.
  3. Canviar les propietats de risc.
  4. Desplega els recursos del risc de prova.
  5. Fer una base de dades de riscos.

59. Explica el cicle de vida del defecte?

Preguntes de l'entrevista de proves manuals - Cicle de vida de defecte

A les proves de programari, el cicle de vida del defecte, també anomenat cicle de vida d'error, es pot definir com un conjunt específic d'estats pels quals passa un defecte o error al llarg de la seva vida. L'objectiu principal del cicle de vida del defecte és coordinar i comunicar l'estat actual del defecte, que canvia als diferents cessionaris i farà que el procés de reparació del defecte sigui eficient i sistemàtic.

Preguntes d'entrevista de proves manuals

60. Definiu la gravetat i la prioritat?

La gravetat significa el grau d'impacte que tindrà un defecte en el desenvolupament o el funcionament del component o del sistema.

Prioritat significa el nivell d'importància comercial que s'assigna a un article, per exemple, un defecte.

61. Llista les categories de depuració?

Categories:

  1. Depuració de força bruta
  2. Fer marxa enrere
  3. Causa eliminació
  4. Programa de tall
  5. Anàlisi de l'arbre de falles

62. Definiu l'arnès de prova?

Pel que fa a les proves de programari, un arnès de prova o un marc de prova automatitzat es pot definir com una col·lecció de programari i dades de prova que es configura per provar una unitat de programa executant-la en diverses/diferents condicions i supervisant-ne les sortides i el comportament. Té dues parts principals, a saber,

  1. El motor d'execució de proves
  2. El dipòsit de scripts de prova

63. Pots enumerar els diferents tipus de gravetat?

  1. Control de defectes de flux – Alt
  2. Condicions de càrrega - Alta
  3. Defectes de la interfície d'usuari – Baix
  4. Defectes relacionats amb els límits – Mitjans
  5. Errors de maneig de defectes - Mitjà
  6. Defectes de càlcul – Alts
  7. Dades mal interpretades - Alta
  8. Errors de maquinari: alt
  9. Problemes de compatibilitat: alt

Preguntes d'entrevista de proves manuals

64. Què és l'emmascarament d'errors?

L'emmascarament d'errors es pot indicar com quan la presència d'un defecte ocultarà la presència d'un altre defecte). Exemple: si el valor negatiu provoca l'activació d'excepcions del sistema no gestionades, el desenvolupador ha d'impedir l'entrada de valors negatius. Això resol el problema i amagarà el defecte de l'excepció no gestionada.

65. Diferenciar entre proves positives i negatives?

Prova positiva Prova negativa
Les proves positives es defineixen com la comprovació de les respostes de l'aplicació amb l'ajuda de dades d'entrada vàlides.Les proves negatives es poden definir com la comprovació de la resposta de l'aplicació fent ús del conjunt de dades d'entrada no vàlids.
Aquesta prova no garanteix una bona qualitat del producte de programari.Aquesta prova garanteix oferir un producte de programari de bona qualitat.
Aquesta prova no engloba totes les causes possibles.Aquesta prova engloba totes les causes possibles.

66. Definiu el percentatge de detecció de defecte a les proves de programari?

Una de les mètriques que mesurarà la qualitat de les proves de l'empresa és el percentatge de detecció de defecte. La fórmula és calcular el nombre de defectes que es troben durant les proves i després dividir aquest nombre pel nombre de defectes totals.

67. Què és un error crític?

És possible que un error crític no requereixi cap acció, per exemple, Sí, m'he sentit totalment. Ja està arreglat en una font i desapareixerà en la propera compilació.

68. Definir el significat de l'eficiència de l'eliminació de defectes a les proves de programari?

L'eficiència de l'eliminació de defectes es relaciona normalment amb la capacitat d'eliminar els defectes que el projecte introdueix en un sistema durant el cicle de vida del projecte.

69. Quin és el risc comú que pot provocar el fracàs del projecte?

  1. No tenim prou recursos humans.
  2. És possible que l'entorn de prova no estigui configurat correctament.
  3. És possible que tinguem un pressupost limitat.
  4. Restriccions de temps

70. Definiu la paradoxa dels pesticides? Com superar-ho?

En termes simples, la paradoxa dels pesticides es pot explicar com si es repeteixen les mateixes proves (és a dir, una i altra vegada), el mateix conjunt de casos de prova no trobarà cap error nou.

Els mètodes per prevenir la paradoxa dels pesticides es donen a continuació:

  1. Podeu preparar nous casos de prova i afegir-los a un cas de prova existent.
  2. Podeu escriure un conjunt complet de casos de prova per exercir diverses parts del programari.

Preguntes d'entrevista de proves manuals

71. Definiu l'edat mitjana d'un defecte en les proves de programari?

L'edat del defecte normalment es defineix com el temps transcorregut entre el dia que el provador va descobrir el defecte i el dia que el desenvolupador el va solucionar.

72. Quins punts s'ha de tenir en compte a l'hora d'estimar el vostre projecte?

  1. Heu de dividir tot el projecte en petites tasques.
  2. A continuació, assigneu cada tasca als membres de l'equip.
  3. Ara, calculeu l'esforç necessari per completar cada tasca.
  4. Finalment, valideu l'estimació.

73. Com realitzar proves automatitzades a l'entorn?

  1. Primer, decideixes quins casos de prova automatitzar.
  2. Aleshores, heu de seleccionar l'eina de prova automatitzada adequada.
  3. A continuació, dividiu els vostres esforços de proves automatitzades.
  4. A continuació, creeu dades de proves bones i de qualitat.
  5. Aleshores, heu de crear proves automatitzades que siguin resistents als canvis a la interfície d'usuari (interfície d'usuari).

74. Com assignar una tasca als membres de l'equip?

  1. Analitzar les especificacions de requisits de programari (tots els membres de l'equip).
  2. A continuació, creeu les especificacions de la prova (analista de proves o verificador).
  3. A continuació, creeu l'entorn de prova (Administrador de proves).
  4. Executeu els casos de prova (Testet/Administrador de proves).
  5. Finalment, informa dels defectes (Tester).

75. Llista algunes de les qualitats essencials que ha de tenir un responsable de control de qualitat o un líder de prova amb experiència?

  1. Han d'aportar idees per perfeccionar els processos de control de qualitat.
  2. Han de tenir excel·lents habilitats de comunicació escrita i interpersonal.
  3. Capacitat per accelerar el treball en equip per augmentar la productivitat
  4. Capacitat per aprendre ràpidament i preparar els membres de l'equip.

76. Quines són les coses a considerar mentre feu el seguiment del vostre projecte?

  1. Estàs per sobre del pressupost?
  2. Estem treballant per al mateix objectiu professional?
  3. El projecte està dins del calendari previst
  4. Tenim prou recursos?
  5. Hi ha senyals d'alerta de problemes imminents?
  6. Hi ha pressió de gestió per completar el projecte abans?

77. Defineix Defectes en cascada a les proves de programari?

Pel que fa a les proves de programari, Defect Cascading significa l'activació d'altres defectes en una aplicació sempre que un defecte no s'identifica o passa desapercebut durant la prova, invocarà altres defectes, de manera que apareixeran múltiples defectes en les etapes posteriors.

78. Què és una prova de seda?

Silk Test es pot definir com una eina per a les proves de regressió i la funció automatitzada de les aplicacions empresarials. Va ser desenvolupat per Segue Software, que després va ser adquirit per Borland el 2006. Silk Test Workbench permetrà fer proves d'automatització a nivell visual, així com utilitzar VB.Net com a llenguatge de script.

79. Què significa el terme 'qualitat' a l'hora de provar?

La qualitat en les proves es pot definir com el grau en què un component, sistema o procés compleix els requisits donats i les necessitats i expectatives del client. Qualitat del programari: És la totalitat de les característiques i funcionalitats d'un producte de programari que influiran en la seva capacitat de satisfer implícita.

80. En quins escenaris us plantejaríeu triar les proves automatitzades en lloc de les proves manuals?

  1. Les proves inclouen passos repetitius
  2. S'espera que l'automatització trigui menys temps
  3. Els informes d'automatització estan disponibles per a cada execució
  4. L'automatització augmenta la reutilització
  5. Si les proves requereixen una execució periòdica

Preguntes d'entrevista de proves manuals

81. Pots enumerar els errors habituals en crear problemes?

  1. Pobra programació
  2. No seguir el procés
  3. No escoltar els altres
  4. Relacionar recursos amb projectes equivocats.
  5. Ignorant els petits problemes
  6. Subestimant

82. Pots enumerar les diferents tècniques de les proves de la caixa blanca?

  1. Cobertura de la declaració
  2. Cobertura de decisions
  3. Cobertura de condicions
  4. Cobertura de múltiples condicions

83. Llista els elements clau que cal tenir en compte a l'hora d'escriure un informe d'error?

  1. Descripció del defecte: és una breu descripció de l'error
  2. Un identificador únic
  3. Entorn: podeu afegir qualsevol configuració del sistema que us ajudi a reproduir el problema.
  4. Captures de pantalla
  5. Severitat
  6. Passos per reproduir: inclourà els passos detallats de la prova per tal d'emular el problema. També proporcionarà les dades de la prova i també l'hora en què s'ha produït l'error.

84. Defineix Tècniques de prova basades en l'experiència?

La tècnica de prova basada en l'experiència es basa bàsicament en l'experiència i l'habilitat del provador. Aquí els provadors utilitzaran la seva experiència amb la mateixa tecnologia, ja que no hi ha prou temps i especificacions inadequades disponibles per provar una aplicació.

Preguntes d'entrevista de proves manuals

85. Diferenciar entre fuga d'errors i llançament d'errors?

Fuga d'errors Alliberament d'errors
La fuga d'errors significa que els clients o usuaris finals descobreixen l'error i l'equip de proves no els detecta durant la prova del programari.L'alliberament d'errors és quan el programari o l'aplicació es lliura a l'equip de proves sabent que el defecte estarà present en una versió.

86. Diferenciar entre la prova de fum i la prova de seny?

Prova de fum Prova de seny
Aquí, les proves s'executen a les versions inicials d'un producte de programari.Aquí, les proves es realitzen en construccions que han superat les proves de fum i les proves de regressió.
És un subconjunt de proves d'acceptació.És un subconjunt de proves de regressió.
Són executats per desenvolupadors o provadors.Són executats per provadors.

87. Diferenciar entre les proves de rendiment i les proves de mico?

Prova de rendiment Prova de mico
Les proves de rendiment s'utilitzen per comprovar les característiques de velocitat, escalabilitat i estabilitat d'un sistema.La prova de mico es pot definir com una tècnica de prova de programari on l'usuari provarà l'aplicació proporcionant algunes entrades aleatòries per comprovar el comportament de l'aplicació.

88. Què és la 'Gestió de la configuració'?

A les proves de programari, la gestió de la configuració es pot definir com un mecanisme per mantenir i establir el rendiment, els atributs físics i funcionals d'un producte amb els seus requisits, funcionalitats i disseny al llarg de la seva vida útil. Permetrà al verificador de programari gestionar les seves sortides de prova i el seu programari de prova utilitzant els mateixos mecanismes de gestió de configuració.

89. Definir les proves del sistema?

La prova del sistema es pot definir com la prova del producte de programari complet i totalment integrat. Aquest tipus de proves es troben en les proves de caixa negra, on el coneixement del disseny intern d'un codi no es considera un requisit previ, i ho fa l'equip de proves.

Preguntes d'entrevista de proves manuals

90. Les proves d'automatització poden substituir les proves manuals?

L'automatització de proves no té la capacitat de substituir les proves manuals. No podem suposar que l'automatització de proves està robant la feina dels provadors de programari que hi ha, i no podeu esperar que l'automatització de proves faci tot el treball fet manualment per un provador.

91. Què és una revisió de gestió de proves?

La gestió de proves es pot definir com un procés de gestió de totes les activitats de prova per garantir una alta qualitat i proves de gamma alta d'una aplicació de programari. El mètode conté l'organització, la garantia de la traçabilitat, el control i la visibilitat del procés de prova per oferir una aplicació de programari d'alta qualitat.

92. Quan preparem RTM (Requirement Traceability Matrix)?

Normalment, RTM es prepara abans del procés d'execució de la prova per garantir que tots els requisits es cobreixen en forma de casos de prova perquè no ens perdem cap prova. En aquest document RTM, normalment mapem tots els requisits i els casos de prova respectius per assegurar-nos que els casos de prova s'escriuen a cada condició.

93. Enumereu les millors pràctiques per garantir la qualitat del programari?

  1. Ús d'eines
  2. Mètriques
  3. Auditors SQA amb experiència
  4. Millora contínua
  5. Documentació
  6. Responsabilitat dels membres de l'equip

94. Definiu el mètode de prova basat en el pla de proves o basat en paraules clau?

És una tècnica que utilitza el document de cas de prova real desenvolupat pels provadors mitjançant un full de càlcul que conté paraules clau especials. Les paraules clau controlen el processament.

95. Diferenciar entre matriu de prova i matriu de traçabilitat?

Matriu de prova Matriu de traçabilitat
La matriu de prova s'utilitza normalment per capturar la qualitat real, l'esforç, el pla, els recursos i el temps necessaris per capturar totes les fases de la prova del programari.Traceability Matrix no és més que el mapeig entre casos de prova i requisits del client.

96. Definiu DFD (diagrama de flux de dades)?

Els diagrames de flux de dades s'utilitzen bàsicament per representar gràficament un flux de dades en el sistema d'informació empresarial. DFD descriurà els processos implicats en un sistema per tal de transferir dades d'una entrada a un fitxer d'emmagatzematge i generació d'informes.

97. Explicar les proves N+1?

La prova N+1 és una variació de la prova de regressió. La prova es realitza amb múltiples cicles on es resolen els errors trobats en el cicle de prova N i la solució es torna a provar en el cicle de prova N+1. Aquí, els cicles es repeteixen fins que la solució arriba a un estat estacionari i hi ha més errors.

98. Explicar LCSAJ?

LCSAJ significa Seqüència de codi lineal i salt, i és un mecanisme de prova de caixa blanca per identificar la cobertura del codi, que començarà a l'inici del programa i finalitzarà al final d'un programa. LCSAJ conté proves que són equivalents a la cobertura de declaracions.

99. Expliqueu els termes verificació i validació en proves de programari?

Verificació es pot definir com el procés de comprovar si un programari assoleix el seu objectiu sense cap error. És la tècnica que assegura si el producte desenvolupat és correcte o no.

Validació es pot definir com el procés de comprovar si el producte de programari dissenyat està a l'alçada o, en paraules senzilles, si el producte té requisits d'alt nivell.

100. Diferenciar entre el cicle de vida de les proves de programari i el cicle de vida del desenvolupament de programari?

STLCSDLC
És un cicle de vida de provaÉs un cicle de vida de desenvolupament.
L'objectiu de la fase STLC és provar/L'objectiu del cicle de vida de SDLC és completar el desenvolupament exitós del programari, incloent proves i altres fases.
Aquí, l'analista de proves crearà el pla de proves d'integració.Aquí, l'equip de desenvolupament crearà plans de disseny d'alt i baix nivell.
Aquí, l'equip de proves prepararà l'entorn de prova i les executarà.Aquí, es desenvoluparà el codi real i el treball real es farà segons els documents de disseny.

Molta sort amb la vostra entrevista de prova manual i esperem que les nostres preguntes i respostes de l'entrevista de prova manual us siguin d'ajuda. També podeu consultar el nostre Preguntes d'entrevista de Java 8 i Preguntes d'entrevista PHP que et pot ser d'alguna ajuda.