39 top automation testing interview questions
Preguntes més freqüents sobre les entrevistes de proves d'automatització per a candidats de nivell inicial i avançat:
L’automatització de proves té un paper molt important en tot el cicle de vida del programari. La majoria de les vegades, quan ens volem preparar per a una entrevista de proves d’automatització, només ens centrem en preguntes específiques d’eines.
Tot i això, també hem de tenir en compte el fet que aprendre i conèixer l’eina és només un mitjà i no és l’objectiu final.
Per tant, sempre que ens preparem per a una entrevista de verificadors d'automatització, hem de considerar 'Automatització' en el seu conjunt i centrar-nos en el marc i els passos implicats.
Tots sabem que les proves de programari són una part molt important del desenvolupament de programari. Però, amb les metodologies i entorns de desenvolupament de programari en ràpid creixement, es fa difícil provar manualment tot per a una aplicació en un temps limitat juntament amb les limitacions de costos.
Per tant, les proves d'automatització creixen ràpidament al mercat per accelerar el ritme de desenvolupament. Aquest tutorial inclou preguntes principals sobre les entrevistes sobre proves d'automatització. He intentat citar les preguntes curtes i ràpides que són molt específiques del conjunt de l'automatització i no són específiques de cap 'eina'.
Top 39 de les preguntes de l'entrevista de proves d'automatització
Hem tractat preguntes bàsiques sobre automatització de proves, així com algunes preguntes avançades per a candidats de nivell intermedi a expert amb experiència de fins a 2 a 5 anys.
P # 1) Què és l'automatització?
Resposta: L’automatització és qualsevol acció que pot reduir els esforços humans.
Q # 2) Què són les proves d'automatització?
Resposta: El procés d’utilitzar eines de programari o scripts especials per realitzar tasques de prova, com ara introduir dades, executar els passos de la prova i comparar els resultats, etc., es coneix com a prova d’automatització.
P # 3) Quines coses podeu automatitzar?
Resposta:
- Suite de proves de regressió
- Suite de proves Smoke / Sanity
- Desplegament de la construcció
- Creació de dades de prova
- Automatització darrere de la interfície gràfica d’usuari com la prova d’APIs i mètodes.
Q # 4) Quan són útils les proves d'automatització?
Resposta: Les proves d'automatització són útils en els escenaris següents:
a) Proves de regressió: En cas de correcció d'errors o d'implementació de mòduls nous, hem d'assegurar-nos que la funcionalitat ja implementada o sense canvis no es vegi afectada. En aquest cas, acabem executant el cas de la prova de regressió diverses vegades.
Per exemple: Després de cada sol·licitud de canvi o correcció d’errors, després de cada iteració en cas d’enfocament de desenvolupament incremental, etc.
b) Proves no funcionals: Prova dels aspectes no funcionals d'una aplicació.
Per exemple, Les proves de càrrega o proves de rendiment, etc. són molt difícils de rastrejar i analitzar pels humans.
c) Càlcul complex comprova o prova escenaris propensos a errors humans.
d) Execució reiterada de les mateixes proves: De vegades, hem d'executar el mateix conjunt de casos de prova per a un conjunt de dades diferent o després de cada versió de compilació o en diversos maquinari, programari o combinació d'ambdós.
L’automatització dels casos de prova en els escenaris anteriors ajuda a aconseguir la rapidesa de les proves i a minimitzar els errors humans.
P # 5) Com identifiqueu els casos de prova adequats per a l'automatització?
Resposta: Identificar els casos de prova adequats per a l'automatització és el pas més important cap a l'automatització.
P # 6) Podeu aconseguir un 100% d'automatització?
Resposta: L’automatització del 100% seria difícil d’aconseguir perquè hi hauria molts casos de proves de vora i alguns casos que s’executen poques vegades. Automatitzar aquests casos que no s’executen que sovint no aportaran valor al conjunt automatitzat.
Q # 7) Com decidir l'eina que s'ha d'utilitzar per a les proves d'automatització en els seus projectes?
Resposta: per identificar l'eina de proves d'automatització al vostre projecte:
a) Compreneu els requisits del projecte a fons i identifiqueu els escenaris de prova que voleu automatitzar.
b) Cerqueu la llista d’eines que admeten els requisits del vostre projecte.
c) Identifiqueu el pressupost de l'eina d'automatització. Seleccioneu les eines dins del vostre pressupost.
d) Identifiqueu si ja teniu recursos especialitzats per a les eines. Si no disposeu dels recursos qualificats necessaris, identifiqueu el cost de la formació dels recursos existents o la contractació de nous recursos.
és) Ara compareu cada eina amb criteris clau com:
- Què tan fàcil és desenvolupar i mantenir els scripts de l'eina?
- Una persona no tècnica també pot executar els casos de prova amb poca formació?
- L'eina admet diferents tipus de plataformes com ara web, mòbils, ordinadors, etc. segons els requisits del vostre projecte?
- L'eina té una funcionalitat d'informes de prova? Si no, és fàcil de configurar per a l'eina?
- Com és l'eina d'assistència entre navegadors per a aplicacions basades en web?
- Quants tipus de proves diferents poden admetre aquesta eina?
- Quants idiomes admet l'eina?
f) Un cop hàgiu comparat les eines, seleccioneu l'eina que estigui dins del vostre pressupost i admeti els requisits del vostre projecte i us proporcionarà més avantatges en funció dels criteris clau esmentats anteriorment.
Q # 8) Actualment no tinc cap automatització al meu projecte, però ara vull implementar-ne l'automatització, quins serien els meus passos?
Resposta:
- En primer lloc, identifiqueu quin tipus de proves / casos de prova voleu automatitzar.
- Identifiqueu l'eina
- Dissenyar el marc
- Creeu fitxers d’utilitat i fitxers d’entorn.
- Comenceu a crear scripts
- Identificar i elaborar informes.
- Temps assignat per millorar i mantenir els scripts.
Els passos necessaris per establir les proves d'automatització per a un projecte inclouen:
- Comprendre els avantatges i desavantatges de les proves d'automatització i identificar els escenaris de prova adequats per a l'automatització.
- Seleccioneu l'eina d'automatització més adequada per automatitzar els escenaris identificats
- Cerqueu l'expert en eines que us ajudi a configurar l'eina i l'entorn necessari per executar els casos de prova mitjançant l'eina.
- Entreneu l'equip perquè pugui escriure scripts en el llenguatge de programació compatible amb l'eina.
- Creeu el marc de prova o identifiqueu el ja existent que compleixi els vostres requisits.
- Escriviu un pla d'execució per a sistemes operatius, navegadors, dispositius mòbils, etc.
- Escriviu scripts de programació per a casos de proves manuals per convertir-los en casos de prova automatitzats.
- Informeu de l'estat del cas de prova mitjançant la funció d'informes de l'eina.
- Mantingueu els scripts per a canvis en curs o funcions noves.
P # 9) Com decidiu quina eina heu d'utilitzar?
Resposta: Concloent quina eina és la més adequada perquè el projecte requereix molta pluja d'idees i discussions.
P # 10) Un cop identifiqueu l'eina, quins serien els vostres passos següents?
Resposta: Un cop finalitzem l'eina, el nostre següent pas seria dissenyar el marc.
Q # 11) Què és un marc?
Resposta: Un framework és un conjunt de l'estructura de tota la suite d'automatització. També és una pauta que, si es segueix, pot resultar en una estructura fàcil de mantenir i millorar.
Aquestes directrius inclouen:
- Normes de codificació
- Manipulació de les dades de la prova
- Manteniment i gestió dels elements (dipòsit d'objectes a QTP)
- Maneig de fitxers d'entorn i fitxer de propietats
- Informes de dades
- Manipulació de troncs
P # 12) Quins són els atributs d'un bon marc?
Resposta: Les característiques inclouen:
- modular: El marc hauria de ser adaptable als canvis. Els verificadors haurien de poder modificar els scripts segons l'entorn o el canvi d'informació d'inici de sessió.
- Reutilitzable: Els mètodes o utilitats més utilitzats s’han d’escriure en un fitxer comú que sigui accessible per a tots els scripts.
- Coherent: La suite s’ha d’escriure en un format coherent seguint totes les pràctiques de codificació acceptades.
- Independent: Els guions s’han d’escriure de manera que siguin independents els uns dels altres. En cas que falli una prova, no hauria de retenir la resta de casos de prova (tret que es tracti d'una pàgina d'inici de sessió)
- Registres: És bo haver implementat la funció de registre al framework. Això ajudaria en cas que els nostres scripts s'executessin durant més hores (per exemple, en mode nocturn), si el script falla en qualsevol moment, tenir el fitxer de registre ens ajudarà a detectar la ubicació juntament amb el tipus d'error.
- Informes: És bo que la funció d'informes s'inclogui automàticament al marc. Un cop feta la seqüència de comandes, podem obtenir els resultats i els informes per correu electrònic.
- Integració: Automation Framework hauria de ser tal que sigui fàcil d’integrar amb altres aplicacions, com ara la integració contínua o l’activació de l’escript automatitzat tan aviat com es desplega la compilació.
P # 13) Es pot prescindir d'un marc?
Resposta: Els marcs són pautes i no són regles obligatòries, de manera que podem prescindir d’un marc, però si el creem i el seguim, seria fàcil implementar-ne la millora i el manteniment.
P # 14) Quins són els diferents tipus d'eines d'automatització que coneixeu?
Resposta: Eina de codi obert com Selenium, JMeter, etc.
Eines de pagament com QTP, Load Runner, Ranorex, RFT i Rational Robot.
P # 15) Quina és generalment l’estructura d’un marc?
Resposta: Normalment l'estructura hauria de tenir - (Diferiria d'un projecte a un altre)
- Una carpeta 'src' (font) amb els scripts de prova reals.
- Una carpeta 'lib' (biblioteca) amb totes les biblioteques i mètodes comuns.
- Una carpeta 'classe' que conté tot el fitxer de classe (en cas que utilitzi Java).
- Una carpeta 'registre' amb els fitxers de registre.
- Un fitxer / carpeta amb tots els identificadors d’elements web.
- Un fitxer que conté l'URL, l'entorn i la informació d'inici de sessió.
Q # 16) On mantindreu informació com ara URL, inici de sessió, contrasenya?
Resposta: Aquesta informació s'ha de conservar sempre en un fitxer separat.
P # 17) Per què voleu mantenir aquest tipus d'informació en un fitxer separat i no directament al codi?
Resposta: L'URL, l'inici de sessió i les contrasenyes són el tipus de camps que s'utilitzen molt sovint i que canvien segons l'entorn i l'autorització. En cas que el codifiquem al nostre codi, l’hem de canviar a tots els fitxers que tinguin la seva referència.
En cas que hi hagi més de 100 fitxers, es fa molt difícil canviar tots els 100 fitxers i això, al seu torn, pot provocar errors. Per tant, aquest tipus d’informació es manté en un fitxer separat per tal que l’actualització sigui més fàcil.
P # 18) Quins són els diferents tipus de marcs?
Resposta: Els diferents tipus de marcs inclouen:
- Marc basat en paraules clau
- Marc basat en dades
- Marc híbrid
- Script lineal
Q # 19) Podeu explicar algunes bones pràctiques de codificació durant l'automatització?
Resposta: Algunes de les bones pràctiques de codificació inclouen:
- Afegiu els comentaris adequats.
- Identifiqueu els mètodes reutilitzables i escriviu-los en un fitxer separat.
- Seguiu les convencions de codificació específiques de l'idioma.
- Mantingueu les dades de la prova en un fitxer separat.
- Executeu els vostres scripts regularment.
P # 20) Algun tipus de prova que creieu que no hauria de ser automatitzada?
Resposta:
- Proves que poques vegades s’executen.
- Proves exploratòries
- Proves d’usabilitat
- Prova que s'executa ràpidament quan es fa manualment.
Q # 21) Creieu que les proves només es poden fer a nivell d’interfície d’usuari?
sistemes operatius que executen programes de Windows
Resposta: Avui, a mesura que passem al mode Agile, les proves no es limiten a la capa d’interfície d’usuari. La retroalimentació primerenca és imperial per a un projecte àgil. Si només ens concentrem en la capa d’interfície d’usuari, realment esperem fins que la interfície d’usuari estigui desenvolupada i estigui disponible per provar-la.
Més aviat podem provar fins i tot abans de desenvolupar la interfície d’usuari. Podem provar directament les API o els mètodes mitjançant eines com Cogombre i FitNesse .
D’aquesta manera, donem els comentaris molt aviat i estem provant fins i tot abans que es desenvolupi la interfície d’usuari. Seguir aquest enfocament ens ajudarà a provar només l’aspecte de la interfície gràfica d’usuari de petits canvis cosmètics o algunes validacions a la IU i ajudarà els desenvolupadors donant més temps per corregir els errors.
P # 22) Com seleccioneu quina eina d'automatització us convé més?
Resposta: La selecció de l'eina d'automatització depèn de diversos factors com:
- L'abast de l'aplicació que volem automatitzar.
- Gestió general com cost i pressupost.
- És hora d'aprendre i implementar l'eina.
- Tipus de suport disponible per a l'eina.
- Limitació de l'eina
Q # 23) Què creieu que impedeix als verificadors fer l'automatització? Hi ha alguna manera de superar-ho?
Resposta: El principal obstacle per als provadors és aprendre a programar / codificar quan volen automatitzar. Com que els provadors no codifiquen, l'adaptació a la codificació és una mica difícil per als provadors.
Ho podem superar mitjançant:
- Col·laborar amb desenvolupadors en automatitzar.
- Tenint en compte que l’automatització és responsabilitat de tot l’equip i no només dels provadors.
- Dedicar un temps dedicat i centrar-se en l’automatització.
- Obtenir un suport de gestió adequat.
Podeu desar aquestes preguntes d’entrevistes de proves d’automatització en format pdf i imprimir-les per a una lectura posterior.
P # 24) Què és un marc de proves d'automatització?
Resposta: Un marc, en general, és un conjunt de pautes. Un conjunt de directrius, suposicions, conceptes i pràctiques de codificació per crear un entorn d’execució en què s’automatitzaran les proves, es coneix com a marc de proves d’automatització.
Un marc de proves d’automatització s’encarrega de crear un arnès de prova amb un mecanisme per connectar-se amb l’aplicació que s’està provant, obtenir informació d’un fitxer, executar els casos de prova i generar els informes per a l’execució de la prova. Un marc de proves d'automatització ha de ser independent de l'aplicació i ha de ser fàcil d'utilitzar, modificar o ampliar.
P # 25) Quins són els mòduls importants d'un marc de proves d'automatització?
Resposta: Els mòduls importants d'un marc de proves d'automatització són:
- Eina d'asserció de proves: Aquesta eina proporcionarà declaracions d'afirmació per provar els valors esperats a l'aplicació que es prova. Per exemple. TestNG, Junit, etc.
- Configuració de dades: Cada cas de prova ha de prendre les dades de l'usuari de la base de dades o d'un fitxer o incrustades a l'script de prova. El mòdul de dades de Frameworks s’hauria d’encarregar de la captura de dades dels scripts de prova i de les variables globals.
- Eina de gestió de compilacions: Cal crear i desplegar un framework per a l’ús de la creació de scripts de prova.
- Eina d'integració contínua: Amb CICD (Integration and Continuous Development) al seu lloc, es necessita una eina d'integració contínua per integrar i desplegar els canvis fets en el marc en cada iteració.
- Eina d'informes: Es necessita una eina d'informes per generar un informe llegible després d'executar els casos de prova per obtenir una millor visió dels passos, resultats i fallades.
- Eina de registre: L'eina de registre del framework ajuda a una millor depuració dels errors i dels errors.
P # 26) Expliqueu algunes eines de proves d'automatització.
Resposta: A continuació s’expliquen algunes de les famoses eines de proves d’automatització:
(i) Seleni : Selenium és un marc de proves per a proves d'automatització d'aplicacions web. És compatible amb diversos navegadors i és independent del sistema operatiu. Selenium també admet diversos llenguatges de programació com Java, C #, PHP, Ruby i Perl, etc.
Seleni és un conjunt de biblioteques de codi obert que es pot utilitzar per desenvolupar marcs de prova o scripts de prova addicionals per provar aplicacions basades en web.
(ii) UFT : Unified Functional Testing és una eina amb llicència per a proves funcionals. Ofereix una àmplia gamma de funcions com ara API, serveis web, etc. i també admet múltiples plataformes com a ordinadors de sobretaula, web i mòbil. Els scripts UFT s’escriuen en un llenguatge de scripts bàsic visual.
(Ii) èpoques : Appium és una eina de prova d'aplicacions mòbils de codi obert. S'utilitza per automatitzar proves en aplicacions mòbils multiplataforma, natives, híbrides i basades en web. Appium automatitza qualsevol aplicació mòbil des de qualsevol idioma amb accés complet a les API i les bases de dades des del codi de prova.
Appium es basa en l'arquitectura client-servidor i ha evolucionat a partir del seleni.
(iv) Cogombre : Cogombre és una eina de desenvolupament de comportament de codi obert. S'utilitza per fer proves d'automatització d'aplicacions basades en web i admet idiomes com el rubí, java, scala, groovy, etc. El cogombre llegeix les especificacions executables escrites en text pla i prova l'aplicació sotmesa a prova per obtenir aquestes especificacions.
Perquè el cogombre entengui els escenaris en text pla, hem de seguir algunes regles bàsiques de sintaxi que es coneixen com a Gherkin.
(v) Completar la prova : TestComplete és una eina de prova automatitzada de la interfície d'usuari amb llicència per provar l'aplicació en diferents plataformes com a ordinadors de sobretaula, web, mòbils, etc.
TestComplete té incorporat un algorisme de reconeixement d’objectes que identifica de manera única un objecte i l’emmagatzema al dipòsit.
P # 27) Quins són els diferents tipus de tècniques de marc de proves?
Resposta: Hi ha quatre tipus de tècniques de marc de proves d'automatització.
Ells són:
(i) Marc de proves modulars:
Aquest marc es basa en el concepte d’abstracció. En aquest marc, el provador crea scripts per a cada mòdul de l'aplicació que es prova individualment i, a continuació, aquests scripts es combinen en l'ordre jeràrquic per crear casos de prova grans.
Crea una capa d'abstracció entre els mòduls, de manera que qualsevol modificació en els scripts de prova d'un mòdul no afecta cap altre mòdul.
Avantatges d’aquest marc:
- Manteniment i escalabilitat més fàcils dels casos de prova.
- Crear casos de prova mitjançant mòduls amb scripts ja és més fàcil i ràpid.
Desavantatges:
- Els casos de prova contenen dades incrustades. Per tant, executar el mateix script de prova amb dades diferents és un gran canvi a nivell de script.
(ii) Marc de proves basades en dades:
Al marc de proves basades en dades, les dades d'entrada i les dades de sortida esperades corresponents a les dades d'entrada s'emmagatzemen en un fitxer o base de dades i l'script automatitzat executa el mateix conjunt de passos de prova per a diversos conjunts de dades. Amb aquest marc, podem executar diversos casos de prova on només les dades d’entrada difereixen i els passos d’execució són els mateixos.
Avantatges:
- Redueix el nombre de scripts de prova que cal executar. Executem el mateix script diverses vegades amb dades diferents.
- Menys codificació per a proves d'automatització.
- Major flexibilitat per mantenir i corregir els errors o millorar la funcionalitat.
- Es poden crear dades de prova fins i tot abans que el sistema automatitzat per a les proves estigui llest.
Desavantatges:
- Només es poden combinar casos de prova similars amb el mateix conjunt de passos d’execució per a diversos conjunts de dades. El conjunt de passos d’execució requereix un cas de prova diferent.
(iii) Marc de proves basades en paraules clau:
És un marc de proves independent de l'aplicació que utilitza taules de dades i paraules clau autoexplicatives. Les paraules clau expliquen les accions a realitzar a l’aplicació sotmesa a prova i la taula de dades proporciona les dades d’entrada i sortida esperades.
Les proves basades en paraules clau són un increment de les proves basades en dades.
Avantatges:
- Es pot utilitzar menys codificació i el mateix script per a diversos conjunts de dades.
- No es requereix experiència en automatització per crear un cas de prova utilitzant les paraules clau ja existents per a les accions.
- Es poden utilitzar les mateixes paraules clau en diversos casos de prova.
Desavantatges:
- Aquest marc és més complicat ja que ha de tenir cura de les accions de paraules clau i també de l'entrada de dades.
- Els casos de prova es fan més llargs i complexos, afectant així la mantenibilitat dels mateixos.
(iv) Marc de proves híbrides:
Aquest marc és una combinació de tots els marcs de proves esmentats anteriorment (modulars, basats en dades i basats en paraules clau).
En aquest marc, els casos de prova es desenvolupen a partir d’escriptures modulars combinant-los en el marc de proves modulars. Cadascun dels casos de prova utilitza un script de controlador que utilitza un fitxer de dades com en el marc basat en dades i un fitxer d’acció basat en paraules clau.
Avantatges:
- Modular i fàcil de mantenir.
- Menys codificació pot atendre més casos de prova.
- Es pot executar un cas de prova amb diversos conjunts de dades.
Desavantatges:
- Complex de llegir, mantenir i millorar.
P # 28) Quan preferiu les proves manuals abans que les proves d'automatització?
Resposta: Preferim les proves manuals davant les proves d'automatització en els casos següents:
- El projecte és a curt termini i escriure scripts requereix molt de temps i costa en comparació amb les proves manuals.
- Es requereix flexibilitat. Els casos de prova automatitzats es programen i s’executen de manera específica en configuracions.
- Cal fer proves d’usabilitat.
- Les aplicacions / mòduls s’han desenvolupat recentment i no tenen cap cas de prova anterior.
- Cal fer proves exploratòries o ad-hoc.
P # 29) Les proves d'automatització en metodologia àgil són útils o no?
Resposta: Les proves d'automatització són útils per a proves de regressió, fum o seny. Tots aquests tipus de proves en el model de cascada tradicional es realitzen al final del cicle i, de vegades, si no hi ha moltes millores a l’aplicació, potser ni tan sols hauríem de fer-ho. proves de regressió .
Mentre que, a metodologia àgil , cada iteració requereix executar el cas de prova de regressió a mesura que s'afegeixen algunes funcionalitats noves.
A més, la suite de regressió continua creixent després de cada sprint ja que els casos de prova funcionals del mòdul de sprint actual s’han d’afegir a la suite de regressió per al sprint següent.
Per tant, les proves d'automatització en metodologia àgil són molt útils i ajuden a aconseguir la màxima cobertura de proves en menys temps del sprint.
P # 30) Enumereu alguns avantatges i desavantatges de les proves d'automatització.
Resposta:
Avantatges:
- Menys recursos humans
- Reutilització
- Més cobertura de proves en menys temps
- Fiabilitat
- Execució paral·lela de casos de prova
- Ràpid
Desavantatges:
nom d'usuari i contrasenya per defecte per a l'encaminador
- El temps de desenvolupament i manteniment és més gran.
- Cost de l'eina
- Es requereixen recursos qualificats.
- Configuració de l'entorn
- La depuració de scripts de prova és un problema.
P # 31) Enumereu alguns avantatges i desavantatges de les proves manuals.
Resposta:
Avantatges:
- No cal configurar l'entorn.
- No es requereixen coneixements de programació.
- Es recomana per canviar dinàmicament els requisits.
- Permetre que l'observació humana detecti més errors.
- El cost és menor per als projectes a curt termini.
- Flexibilitat
Desavantatges:
- Difícil realitzar càlculs complexos.
- Reutilització
- Prendre temps
- Alt risc d’errors o errors humans.
- Es necessiten més recursos humans.
P # 32) Podem fer proves d'automatització sense un marc? Si és així, per què necessitem un marc?
Resposta: Sí, podem realitzar proves d'automatització fins i tot sense utilitzar un framework. Només podem entendre l’eina que estem utilitzant per a l’automatització i programar els passos del llenguatge de programació que admeten les eines.
Si automatitzem casos de prova sense marc, no hi haurà coherència en els scripts de programació de casos de prova.
Es requereix un marc per donar un conjunt de pautes que tothom ha de seguir per mantenir la llegibilitat, la reutilització i la coherència en els scripts de prova. Un framework també proporciona una base comuna per a la funcionalitat d'informes i registre.
P # 33) Com automatitzareu els casos bàsics de prova de funcionalitat d ''inici de sessió' d'una aplicació?
Resposta: Suposant que l'eina i el marc d'automatització ja estan al lloc de l'entorn de prova.
Per provar la funcionalitat bàsica 'Inici de sessió':
- Comprendre els requisits del projecte : La funcionalitat d'inici de sessió tindrà un quadre de text de nom d'usuari, un quadre de text de contrasenya i un botó d'inici de sessió.
- Identifiqueu els escenaris de prova: Per a la funcionalitat d'inici de sessió, els possibles escenaris de prova són:
- Nom d'usuari i contrasenya en blanc
- Nom d'usuari i contrasenya no vàlids
- Un nom d'usuari vàlid i una contrasenya no vàlida
- Nom d'usuari i contrasenya vàlids
- Prepareu un Fitxer d’entrada de dades amb les dades corresponents a cada escenari.
- Inicieu l'eina del programa.
- Identifiqueu el camp del nom d'usuari, el camp de la contrasenya i el botó d'inici de sessió.
- Per a cada escenari de prova, obteniu les dades del fitxer de dades i introduïu-los als camps corresponents. Feu clic al programa al botó d'inici de sessió després d'introduir les dades.
- Validar el missatge d'error per als escenaris negatius i el missatge d'èxit per als escenaris positius del script de prova amb l'ajut d'afirmacions.
- Correr el conjunt de proves i generar l'informe.
P # 34) Les proves d'automatització són proves de caixa negra o de caixa blanca?
Resposta: Les proves d'automatització són principalment un proves de caixa negra ja que només programem els passos que realitza un provador manual per a l'aplicació en prova sense conèixer el disseny o el codi de baix nivell de l'aplicació.
De vegades, els scripts de prova automatitzats necessiten accés als detalls de la base de dades que s’utilitzen a l’aplicació sotmesa a prova o a alguns detalls de codificació més i, per tant, poden ser un tipus de prova de caixa blanca.
Per tant, les proves automatitzades poden ser tant proves de tipus caixa negra com blanca en funció dels escenaris en què es realitzi l'automatització.
P # 35) Quants casos de prova heu automatitzat al dia?
Resposta: Bé, el nombre depèn de la complexitat dels casos de prova. Quan la complexitat era limitada, vaig poder automatitzar de 5 a 6 casos de proves al dia. De vegades, només vaig poder automatitzar un cas de prova per a escenaris complexos.
També he desglossat els meus casos de prova en diferents components, com ara, introduir dades, fer el càlcul, verificar la sortida, etc. en cas d’escenaris molt complexos i he trigat 2 o més dies.
P # 36) Quins factors determinen l'eficàcia de les proves d'automatització?
Resposta: Alguns dels factors que determinen l'eficàcia de les proves d'automatització són:
- Temps estalviat executant scripts sobre l'execució manual de casos de prova.
- Defectes trobats
- Cobertura de la prova o cobertura del codi
- Temps de manteniment o temps de desenvolupament
- Estabilitat dels guions
- Prova de reutilització
- Qualitat del programari sotmès a prova
P # 37) Quins casos de prova es poden automatitzar?
Resposta: Els tipus de casos de prova que es poden automatitzar són:
(i) Casos de proves de fum: Les proves de fum també es coneixen com a proves de verificació de la construcció. Els casos de proves de fum s’executen cada vegada que s’allibera una nova versió per comprovar la salut de la versió per acceptar-la.
(ii) Casos de proves de regressió : Les proves de regressió són les proves per assegurar-se que els mòduls desenvolupats prèviament funcionen tal com s’esperava després que s’afegís un nou mòdul o que es solucionés un error.
Els casos de proves de regressió són molt crucials en l'enfocament de programari incremental on s'afegeix una nova funcionalitat a cada fase d'increment. En aquest cas, es realitzen proves de regressió a cada fase incremental.
(iii) Casos de prova de càlcul complex: Els casos de prova que impliquen alguns càlculs complexos per verificar un camp per a una aplicació pertanyen a aquesta categoria. Els resultats de càlculs complexos són més propensos a errors humans, de manera que, quan s’automatitzen, donen resultats precisos.
(iv) Casos de proves basades en dades: Els casos de prova que tenen el mateix conjunt de passos i s’executen diverses vegades amb el canvi de dades es coneixen com a casos de prova basats en dades. Les proves automatitzades d’aquest tipus de casos de prova són ràpides i rendibles.
(v) Casos de prova no funcionals : Els casos de prova, com ara proves de càrrega i proves de rendiment, requereixen un entorn simulat amb diversos usuaris i múltiples combinacions de maquinari o programari.
Configurar diversos entorns manualment és impossible per a cada combinació o nombre d’usuaris. Les eines automatitzades poden crear fàcilment aquest entorn per realitzar proves no funcionals fàcilment.
P # 38) Quines són les fases del cicle de vida de les proves d'automatització?
Resposta: Les fases del cicle de vida de les proves d'automatització inclouen:
- La decisió de realitzar proves d'automatització.
- Identifiqueu i coneixeu l'eina d'automatització.
- Determineu l'abast de les proves d'automatització.
- Dissenyar i desenvolupar una suite de proves.
- Execució de la prova
- Manteniment de scripts de prova.
P # 39) Què és un script de prova automatitzada?
Resposta: Un script de prova automatitzat és un programa curt que s’escriu en un llenguatge de programació per dur a terme un conjunt d’instruccions en una aplicació que s’està provant per verificar si l’aplicació és conforme als requisits.
Aquest programa, quan s’executa, proporciona els resultats de la prova com a superats o no en funció de si l’aplicació és conforme a les expectatives.
Conclusió
Aquestes són les preguntes principals que són independents de l'eina d'automatització o del llenguatge de programació. Les entrevistes de proves d'automatització també inclouen preguntes específiques sobre el llenguatge de programació i l'eina en funció de l'eina amb què hàgiu treballat.
La majoria de les preguntes de les entrevistes d’automatització de proves se centren en el marc que desenvolupeu, per la qual cosa es recomana crear i comprendre el marc de proves a fons. Quan estic entrevistant i el candidat ha respost la meva pregunta sobre el marc, també prefereixo fer una pregunta específica de l’idioma (core java en el meu cas).
Les preguntes parteixen dels conceptes bàsics de Java per escriure la lògica d’alguns escenaris bàsics com:
- Com trauríeu un conjunt de text d’una línia determinada?
- Com trauríeu l'URL?
- En qualsevol pàgina web, en qualsevol marc, el nombre d’enllaços i el seu contingut canvien dinàmicament, com ho faríeu?
- Com es gestionen les imatges i els objectes flash?
- Com es troba una paraula en una línia?
Respostes a tot això preguntes d’entrevistes d’automatització de proves són molt específics de l’eina / idioma que utilitzeu per automatitzar. Per tant, abans d’anar a l’entrevista, aprofundeix en les teves habilitats de programació.
En cas que no tingueu l'oportunitat de crear el vostre marc i algú altre l'hagi creat, doneu-vos un temps per entendre'l a fons abans de seure a l'entrevista.
Alguns consells per a les entrevistes de proves d'automatització serien:
- Coneix bé la teva eina.
- Apreneu les tècniques de localització que utilitza la vostra eina.
- Practiqueu la programació utilitzant el llenguatge que utilitzeu per fer proves d'automatització.
- Apreneu el vostre marc i els seus components.
- Sempre és avantatjós si heu participat en el desenvolupament del vostre marc. Per tant, sigueu exhaustius amb els mòduls en el marc en què heu treballat.
Espero que aquestes preguntes us siguin útils per preparar-vos per a una entrevista d’automatització de proves.
Lectura recomanada
- Preguntes i respostes de l’entrevista
- Preguntes i respostes de l'entrevista de proves ETL
- Algunes preguntes d’entrevistes de proves de programari interessants
- 25 millors preguntes i respostes d’entrevista de proves àgils
- Top 20 de les preguntes i respostes de les entrevistes de proves API més importants
- Preguntes i respostes sobre proves de programari (primera part)
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Top 30 de preguntes i respostes de les entrevistes de proves de seguretat