39 top automation testing interview questions
Најчешће постављана питања о испитивању аутоматизације за почетнике и кандидате за напредни ниво:
Аутоматизација теста игра веома важну улогу у читавом животном циклусу софтвера. Већину времена када се желимо припремити за интервју за тестирање аутоматизације, фокусирамо се само на питања специфична за алат.
Међутим, такође треба узети у обзир чињеницу да је учење и познавање алата само средство и није крајњи циљ.
Стога, кад год се припремамо за разговор са испитивачем аутоматизације, морамо узети у обзир „Аутоматизацију“ као целину и усредсредити се на оквир и кораке који су укључени.
Сви знамо да је тестирање софтвера веома важан део развоја софтвера. Али, са брзо растућим методологијама и окружењима за развој софтвера, постаје тешко ручно тестирати све за апликацију у ограниченом времену, заједно са ограничењима трошкова.
Дакле, тестирање аутоматизације брзо расте на тржишту како би убрзало развојни темпо. Овај водич укључује главна питања за интервјуе о испитивању аутоматизације. Покушао сам да наведем кратка и брза питања која су врло специфична за аутоматизацију у целини и нису специфична за било који „алат“.
Топ 39 питања за испитивање аутоматизације
Обрадили смо основна питања о аутоматизацији тестова, као и нека напредна питања за кандидате од средњег до стручног нивоа са искуством до 2 до 5 година.
П # 1) Шта је аутоматизација?
Одговор: Аутоматизација је свака радња која може смањити људске напоре.
П # 2) Шта је аутоматско тестирање?
Одговор: Процес коришћења посебних софтверских алата или скрипти за извршавање задатака тестирања, као што су унос података, извршавање корака испитивања и упоређивање резултата, итд. Познат је под називом аутоматизовано тестирање.
П # 3) Које све ствари можете аутоматизовати?
Одговор:
- Пакет за регресиони тест
- Смоке / Санити тест суите
- Изградите имплементацију
- Тестирање података
- Аутоматизација иза ГУИ попут тестирања АПИ-ја и метода.
П # 4) Када је тестирање аутоматизације корисно?
Одговор: Тестирање аутоматизације корисно је у следећим сценаријима:
а) Регресијско тестирање: У случају исправке грешке или имплементације новог модула, морамо бити сигурни да то неће утицати на већ примењену или непромењену функционалност. У овом случају, на крају ћемо покренути тест регресије више пута.
На пример: Након сваког захтева за промену или исправке грешке, након сваке итерације у случају инкременталног приступа развоју итд.
б) Нефункционално тестирање: Тестирање нефункционалних аспеката апликације.
На пример, Испитивање оптерећења или испитивање перформанси итд. Људима је веома тешко да прате и анализирају.
в) Сложени прорачун проверава или тестира сценарије који су склони људским грешкама.
д) Поновљено извођење истих тестова: Понекад морамо да покренемо исти скуп тестних примера за различити скуп података или након сваке верзије верзије или на више хардвера, софтвера или комбинације оба.
Аутоматизација тест случајева у горе наведеним сценаријима помаже у постизању брзине тестирања и минимизирању људских грешака.
П # 5) Како препознати тест случајеве који су погодни за аутоматизацију?
Одговор: Идентификовање одговарајућих тест случајева за аутоматизацију је најважнији корак ка аутоматизацији.
П # 6) Можете ли постићи 100% аутоматизацију?
Одговор: Тешко би било постићи 100% аутоматизацију, јер би било много примера ивица и неки случајеви који се ретко извршавају. Аутоматизација ових случајева који се не извршавају често неће додати вредност аутоматизованом пакету.
П # 7) Како се одлучити за алат који треба користити за тестирање аутоматизације у својим пројектима?
Одговор: Да бисте идентификовали алат за испитивање аутоматизације у вашем пројекту:
до) Темељито разумите захтеве свог пројекта и идентификујте сценарије тестирања које желите аутоматизовати.
б) Потражите листу алата који подржавају захтеве вашег пројекта.
ц) Утврдите свој буџет за алат за аутоматизацију. Изаберите алате у оквиру свог буџета.
д) Утврдите да ли већ имате квалификоване ресурсе за алате. Ако немате потребне квалификоване ресурсе, утврдите трошкове за обуку постојећих ресурса или запошљавање нових ресурса.
је) Сада упоредите сваки алат за кључне критеријуме као што су:
- Колико је лако развити и одржавати скрипте за алат?
- Може ли нетехничка особа такође да изврши тест случајеве са мало обуке?
- Да ли алат подржава различите типове платформи као што су веб, мобилни уређаји, рачунари итд. На основу захтева вашег пројекта?
- Да ли алат има функцију за извештавање са теста? Ако није, да ли је лако подесив за алат?
- Како је алат за подршку за више прегледача за апликације засноване на вебу?
- Колико различитих врста тестирања овај алат може да подржи?
- Колико језика алат подржава?
ф) Након што упоредите алате, одаберите алат који вам је у оквиру буџета и подржите пројектне захтеве и пружа вам више предности на основу горе поменутих кључних критеријума.
П # 8) Тренутно у мом пројекту нисам инсталирао аутоматизацију, али сада желим да применим аутоматизацију, који би били моји кораци?
Одговор:
- Прво одредите коју врсту тестирања / тест случајева желите да аутоматизујете.
- Идентификујте алат
- Дизајнирајте оквир
- Креирајте услужне датотеке и датотеке окружења.
- Почните скриптирање
- Идентификујте и радите на извештавању.
- Додељивање времена за побољшање и одржавање скрипти.
Кораци потребни за успостављање аутоматског тестирања за пројекат укључују:
- Разумети предности и недостатке испитивања аутоматизације и идентификовати сценарије испитивања који су погодни за аутоматизацију.
- Изаберите алат за аутоматизацију који је најприкладнији за аутоматизацију идентификованих сценарија
- Пронађите стручњака за алат који ће вам помоћи у постављању алата и потребног окружења за извршавање тест случајева помоћу алата.
- Обучите тим тако да могу писати скрипте на програмском језику који алат подржава.
- Направите оквир за тестирање или идентификујте већ постојећи који испуњава ваше захтеве.
- Напишите план извршења за ОС, прегледаче, мобилне уређаје итд.
- Напишите сценарије за програмирање ручних тест случајева да бисте их претворили у аутоматизоване тест случајеве.
- Пријавите статус тест случаја помоћу функције извештавања алата.
- Одржавајте скрипте за текуће промене или нове функције.
П # 9) Како одлучујете који алат морате користити?
Одговор: Закључно који алат је најпогоднији јер пројекат захтева пуно мозгања и дискусија.
П # 10) Једном када препознате алат, који би били ваши следећи кораци?
Одговор: Након што финализујемо алат, наш следећи корак био би дизајн оквира.
П # 11) Шта је оквир?
Одговор: Оквир је скуп структуре целокупног пакета аутоматизације. То је такође смјерница која ако се слиједи може резултирати структуром која се лако одржава и побољшава.
Ове смернице укључују:
- Стандарди кодирања
- Руковање подацима теста
- Одржавање и руковање елементима (спремиште објеката у КТП-у)
- Руковање датотекама околине и датотеком својстава
- Извештавање података
- Руковање трупцима
П # 12) Који су атрибути доброг оквира?
Одговор: Карактеристике укључују:
- Модуларни: Оквир треба да буде прилагодљив променама. Тестер би требало да буде у могућности да модификује скрипте у складу са променом окружења или података за пријаву.
- Вишекратна употреба: Методе или услужни програми који се најчешће користе требају бити написани у заједничкој датотеци која је доступна свим скриптама.
- Доследно: Пакет треба да буде написан у доследном формату пратећи све прихваћене праксе кодирања.
- Независно: Сценарији треба да буду написани на такав начин да буду независни једни од других. У случају да један тест не успе, не би требало да задржава преостале тест случајеве (осим ако се не ради о страници за пријаву)
- Евиденције: Добро је имати уграђену функцију евидентирања у оквиру. То би помогло у случају да се наше скрипте изводе дуже време (рецимо ноћни режим), ако скрипта не успе у било ком тренутку, постојање датотеке евиденције помоћи ће нам да откријемо локацију заједно са врстом грешке.
- Извештавање: Добро је имати функцију извештавања која је аутоматски уграђена у оквир. Једном када се изврши скриптирање, можемо да пошаљемо резултате и извештаје путем е-поште.
- Интеграција: Оквир за аутоматизацију треба да буде такав да га је лако интегрисати са другим апликацијама, попут континуиране интеграције или покретања аутоматизоване скрипте, чим је изградња постављена.
П # 13) Можете ли без оквира?
Одговор: Оквири су смернице, а не обавезна правила, тако да можемо и без оквира, али ако га креирамо и следимо, побољшање и одржавање било би лако применити.
П # 14) Које су различите врсте алата за аутоматизацију које сте упознати?
Одговор: Алат отвореног кода попут Селениум, ЈМетер итд.
Плаћени алати попут КТП, Лоад Руннер, Ранорек, РФТ и Ратионал Робот.
П # 15) Шта је уопште структура оквира?
Одговор: Обично би структура требало да има - (То би се разликовало од пројекта до пројекта)
- Фасцикла „срц“ (извор) са стварним скриптама за тест.
- Фасцикла „либ“ (библиотека) која садржи све библиотеке и уобичајене методе.
- Фасцикла „класа“ која садржи сву датотеку класе (у случају да користи Јава).
- Фасцикла „евиденција“ која садржи датотеке дневника.
- Датотека / директоријум који садржи све ИД-ове веб елемената.
- Датотека која садржи УРЛ, информације о окружењу и податке за пријаву.
К # 16) Где ћете чувати информације попут УРЛ-а, пријаве, лозинке?
Одговор: Ове информације увек треба чувати у посебној датотеци.
П # 17) Зашто желите да ову врсту информација сачувате у посебној датотеци, а не директно у коду?
Одговор: УРЛ, пријава и лозинке су она поља која се врло често користе и она се мењају у складу са окружењем и ауторизацијом. У случају да га чврсто кодирамо у наш код, морамо га променити у свакој датотеци која има своју референцу.
У случају да постоји више од 100 датотека, тада постаје веома тешко променити свих 100 датотека, а то, пак, може довести до грешака. Дакле, овакве информације се чувају у посебној датотеци тако да њихово ажурирање постаје лако.
П # 18) Које су различите врсте оквира?
Одговор: Различите врсте оквира укључују:
- Оквир вођен кључним речима
- Оквир на основу података
- Хибридни оквир
- Линеар Сцриптинг
К # 19) Можете ли рећи неке добре праксе кодирања током аутоматизације?
Одговор: Неке добре праксе кодирања укључују:
- Додајте одговарајуће коментаре.
- Идентификујте методе за поновну употребу и запишите их у посебну датотеку.
- Придржавајте се правила кодирања за одређени језик.
- Одржавајте податке о тесту у посебној датотеци.
- Редовно покрећите своје скрипте.
П # 20) Било која врста теста за коју мислите да не би требало да буде аутоматизована?
Одговор:
- Тестови који се ретко изводе.
- Истраживачко испитивање
- Испитивање употребљивости
- Тест који се брзо извршава ручно.
К # 21) Да ли мислите да се тестирање може вршити само на нивоу корисничког интерфејса?
преузмите мп3 музику за преузимање за андроид
Одговор: Данас, када прелазимо на агилни режим, тестирање није ограничено на слој корисничког интерфејса. Ране повратне информације су императивне за агилни пројекат. Ако се концентришемо само на УИ слој, заправо чекамо док се УИ не развије и постане доступан за тестирање.
Уместо тога, можемо да тестирамо и пре него што се УИ заиста развије. АПИ-је или методе можемо директно тестирати помоћу алата попут Цуцумбер анд ФитНессе .
На овај начин повратне информације дајемо много рано и тестирамо их и пре него што се развије кориснички интерфејс. Слеђење овог приступа помоћи ће нам да тестирамо само аспект ГУИ-ја малих козметичких промена или неке валидације на корисничком интерфејсу и помоћи ће програмерима дајући више времена да исправе грешке.
П # 22) Како одабрати који алат за аутоматизацију је најприкладнији за вас?
Одговор: Избор алата за аутоматизацију зависи од различитих фактора као што су:
- Обим апликације коју желимо аутоматизовати.
- Општи трошкови управљања попут трошкова и буџета.
- Време је за учење и примену алата.
- Врста подршке доступна за алат.
- Ограничење алата
К # 23) Шта мислите, шта спутава тестере да раде аутоматизацију? Постоји ли начин да се то превазиђе?
Одговор: Главна препрека тестерима је научити програмирање / кодирање када желе аутоматизовати. Будући да тестери не кодирају, прилагођавање кодирању је мало изазовно за тестере.
То можемо превазићи:
- Сарадња са програмерима приликом аутоматизације.
- С обзиром да је аутоматизација одговорност целог тима, а не само тестера.
- Посветите посвећено време и усредсредите се на аутоматизацију.
- Добијање одговарајуће подршке за управљање.
Ова питања о интервјуу за аутоматизацију можете сачувати у пдф и одштампати за даље читање.
П # 24) Шта је оквир за тестирање аутоматизације?
Одговор: Оквир је генерално скуп смерница. Скуп смерница, претпоставки, концепата и пракси кодирања за стварање извршног окружења у којем ће се тестови аутоматизовати познат је као оквир за аутоматизацију тестирања.
Оквир за аутоматизацију тестирања одговоран је за стварање пробног појаса са механизмом за повезивање са апликацијом која се тестира, преузимање података из датотеке, извршавање тест случајева и генерисање извештаја за извршење теста. Оквир за аутоматизацију треба да буде неовисан о апликацији и треба да буде лак за употребу, модификовање или проширивање.
П # 25) Који су важни модули оквира за тестирање аутоматизације?
Одговор: Важни модули оквира за тестирање аутоматизације су:
- Алат за тестирање тврдњи: Овај алат ће пружити изјаве за потврђивање за тестирање очекиваних вредности у апликацији која се тестира. На пример. ТестНГ, Јунит итд.
- Постављање података: Сваки тест случај мора да преузме корисничке податке или из базе података или из датотеке или уграђене у тест скрипту. Модул података Фрамеворкс треба да се брине о уносу података за тест скрипте и глобалне променљиве.
- Алат за управљање градњом: Потребно је изградити и применити оквир за креирање тест скрипти.
- Алат за континуирану интеграцију: Са успостављеним ЦИЦД (континуирана интеграција и континуирани развој) потребан је алат за континуирану интеграцију за интегрисање и примену промена урађених у оквиру на свакој итерацији.
- Алат за извештавање: Алат за извештавање потребан је за генерисање читљивог извештаја након извршавања тест случајева ради бољег прегледа корака, резултата и неуспеха.
- Алат за бележење: Алат за евидентирање у оквиру помаже у бољем отклањању грешака и грешака.
П # 26) Објасните неке алате за тестирање аутоматизације.
Одговор: У наставку су објашњени неки од познатих алата за аутоматизацију:
(и) Селен : Селен је тест оквир за тестирање аутоматизације веб апликација. Подржава више прегледача и неовисан је о ОС-у. Селениум такође подржава разне програмске језике попут Јава, Ц #, ПХП, Руби и Перл итд.
Селен је скуп библиотека отвореног кода који се може користити за развој додатних тест оквира или тест скрипти за тестирање апликација заснованих на мрежи.
(ии) УФТ : Обједињено функционално тестирање је лиценцирани алат за функционално тестирање. Пружа широк спектар функција попут АПИ-ја, веб услуга итд., А такође подржава више платформи као што су радне површине, веб и мобилне уређаје. УФТ скрипте су написане на основном визуелном скриптном језику.
(ИИ) епохе : Аппиум је алат за тестирање мобилних апликација отвореног кода. Користи се за аутоматизовање тестирања на вишеплатформним, изворним, хибридним и веб-базираним мобилним апликацијама. Аппиум аутоматизује било коју мобилну апликацију са било ког језика са потпуним приступом АПИ-има и ДБ-овима из тест кода.
Аппиум је заснован на архитектури клијент-сервер и еволуирао је од селена.
(ив) краставац : Краставац је развојни алат заснован на понашању отвореног кода. Користи се за тестирање аутоматизације апликација заснованих на Интернету и подржава језике као што су руби, јава, сцала, гроови, итд. Краставац чита извршну спецификацију написану у обичном тексту и тестира апликацију која се тестира за те спецификације.
Да би краставац разумео сценарије у обичном тексту, морамо следити нека основна синтаксна правила која су позната под називом Гхеркин.
(в) ТестЦомплете : ТестЦомплете је лиценцирани алат за аутоматско тестирање корисничког интерфејса за тестирање апликације на различитим платформама као што су радне површине, веб, мобилни уређаји итд. Пружа флексибилност за снимање пробног случаја у један прегледач и његово покретање у више прегледача и на тај начин подржава тестирање више прегледача.
ТестЦомплете има уграђени алгоритам препознавања објеката који јединствено идентификује објекат и чува га у спремишту.
П # 27) Које су различите врсте техника тестирања оквира?
Одговор: Постоје четири врсте техника аутоматског тестирања оквира.
Су:
(и) Модуларни оквир за испитивање:
Овај оквир је изграђен на концепту апстракције. У овом оквиру, тестер креира скрипте за сваки модул апликације која се тестира појединачно, а затим се те скрипте комбинују у хијерархијском редоследу да би се створили велики примери тестова.
Ствара апстрактни слој између модула, тако да било какве модификације у тест скриптама за један модул не утичу на било који други модул.
Предности овог оквира:
- Лакше одржавање и скалабилност тест случајева.
- Стварање тест случајева помоћу већ скриптираних модула је лакше и брже.
Мане:
- У тестовима су уграђени подаци. Стога је извршавање исте тест скрипте са различитим подацима велика промена на нивоу скрипте.
(ии) Оквир тестирања на основу података:
У оквиру тестирања вођеног подацима, улазни подаци и очекивани излазни подаци који одговарају улазним подацима чувају се у датотеци или бази података, а аутоматизована скрипта покреће исти скуп корака за тестирање за више скупова података. Помоћу овог оквира можемо покренути више тест случајева у којима се разликују само улазни подаци и кораци извршавања су исти.
Предности:
- Смањује број тест скрипти које су потребне за извршавање. Изводимо исту скрипту више пута са различитим подацима.
- Мање кодирања за тестирање аутоматизације.
- Већа флексибилност за одржавање и исправљање грешака или побољшање функционалности.
- Подаци о тестирању могу се створити и пре него што аутоматизовани систем за тестирање буде спреман.
Мане:
- Само се слични тест случајеви са истим низом корака извршења могу комбиновати за више скупова података. Различити скуп корака извршења захтева другачији тест случај.
(иии) Оквир тестирања на основу кључних речи:
То је оквир за тестирање независан од апликације који користи табеле података и кључне речи које само себе објашњавају. Кључне речи објашњавају радње које треба извршити на апликацији која се тестира, а табела података пружа улазне и очекиване излазне податке.
Тестирање засновано на кључним речима представља додатак тестирању на основу података.
Предности:
- Мање кодирања и иста скрипта могу се користити за више скупова података.
- Стручност за аутоматизацију није потребна за креирање тест примера користећи већ постојеће кључне речи за акције.
- Исте кључне речи могу се користити у више тест случајева.
Мане:
- Овај оквир је сложенији јер треба да води рачуна о радњама кључне речи и уносу података.
- Тест случајеви постају дужи и сложенији, што утиче на одрживост истих.
(ив) Оквир хибридног тестирања:
Овај оквир је комбинација свих горе поменутих оквира за тестирање (модуларни, на основу података и на основу кључних речи).
У овом оквиру, тестови се развијају из модуларних скрипти њиховим комбиновањем у модуларном оквиру за тестирање. Сваки од тест случајева користи скрипту управљачког програма која користи датотеку података као у оквиру вођеном подацима и датотеку акција засновану на кључним речима.
Предности:
- Модуларан и лак за одржавање.
- Мање кодирања може се побринути за више тест случајева.
- Један тест случај може се извршити са више скупова података.
Мане:
- Сложен за читање, одржавање и побољшање.
П # 28) Када више волите ручно тестирање него тестирање аутоматизације?
Одговор: У следећим случајевима преферирамо ручно тестирање од тестирања аутоматизације:
- Пројекат је краткорочни и писање скрипти ће потрајати и коштати у поређењу са ручним тестирањем.
- Потребна је флексибилност. Аутоматизовани тест случајеви су програмирани и покренути на специфичан начин конфигурација.
- Потребно је извршити испитивање употребљивости.
- Апликације / модули су ново развијени и немају претходне тестове.
- Потребно је извршити ад-хоц или истраживачка испитивања.
П # 29) Да ли је тестирање аутоматизације у агилној методологији корисно или не?
Одговор: Испитивање аутоматизације је корисно за регресију, тестирање дима или исправности здравља. Све ове врсте испитивања у традиционалном моделу водопада дешавају се на крају циклуса и понекад ако нема много побољшања у апликацији, можда не бисмо морали ни да радимо регресија тестирање .
Док, у агилна методологија , свака итерација захтева извршење случаја регресионог теста пошто се додају неке нове функционалности.
Такође, сам регресијски пакет наставља да расте након сваког спринта јер функционални тест случајеви тренутног модула спринта морају да се додају регресионом пакету за следећи спринт.
Стога је аутоматско тестирање у агилној методологији веома корисно и помаже у постизању максималне покривености тестом за мање времена спринта.
П # 30) Наведите неке предности и недостатке испитивања аутоматизације.
Одговор:
Предности:
- Мање људских ресурса
- Могућност поновне употребе
- Више покривености тестом за мање времена
- Поузданост
- Паралелно извршавање тест случајева
- Брзо
Мане:
чему служи ц ++
- Времена за развој и одржавање је више.
- Цена алата
- Потребни су квалификовани ресурси.
- Подешавање окружења
- Проблем је отклањање грешака у тест скрипти.
П # 31) Наведи неке предности и недостатке ручног тестирања.
Одговор:
Предности:
- Није потребно подешавање окружења.
- Знање програмирања није потребно.
- Препоручује се за динамички променљиве захтеве.
- Омогућите људској моћи посматрања да открије више грешака.
- Трошкови су мањи за краткорочне пројекте.
- Флексибилност
Мане:
- Тешко је извршити сложене прорачуне.
- Могућност поновне употребе
- Узимање времена
- Велики ризик од људских грешака или грешака.
- Потребно је више људских ресурса.
П # 32) Да ли можемо да извршимо аутоматско тестирање без оквира? Ако је одговор да, зашто нам онда треба оквир?
Одговор: Да, можемо да извршимо тестирање аутоматизације чак и без употребе оквира. Можемо једноставно разумети алат који користимо за аутоматизацију и програмирати кораке на програмском језику који алати подржавају.
Ако аутоматизујемо тест случајеве без оквира, тада неће бити доследности у програмским скриптама за тест случајеве.
Потребан је оквир који даје скуп смерница којих се сви морају придржавати да би одржали читљивост, поновну употребљивост и доследност у тест скриптама. Оквир такође пружа један заједнички основ за функционалност извештавања и евидентирања.
П # 33) Како ћете аутоматизовати основне тестове функционалности „пријаве“ за апликацију?
Одговор: Под претпоставком да су алат и систем за аутоматизацију већ на месту тест окружења.
Да бисте тестирали основну функционалност „Пријављивање“:
- Разумевање захтева пројекта : Функција за пријаву ће имати оквир за корисничко име, оквир за лозинку и дугме за пријаву.
- Идентификујте сценарије теста: За функционалност пријаве могући су тест сценарији:
- Празно корисничко име и лозинка
- Неважеће корисничко име и лозинка
- Важеће корисничко име и неисправна лозинка
- Важеће корисничко име и лозинка
- Припремите а Датотека за унос података са подацима који одговарају сваком сценарију.
- Покрените алат из програма.
- Идентификујте поље за корисничко име, поље за лозинку и дугме за пријаву.
- За сваки тестни сценарио узмите податке из датотеке података и унесите у одговарајућа поља. Кликните на дугме за пријаву у програм након уноса података.
- Потврди порука грешке за негативне сценарије и порука успеха за позитивне сценарије у тест скрипти уз помоћ тврдњи.
- Трцати тест пакет и генерисати извештај.
П # 34) Да ли је аутоматизација тестирање тестирања црне кутије или тестирање беле кутије?
Одговор: Испитивање аутоматизације је углавном а тестирање црне кутије пошто само програмирамо кораке које ручни тестер изводи за тестирану апликацију без познавања дизајна или кода апликације на ниском нивоу.
Понекад аутоматизованим тест скриптама треба приступ детаљима базе података који се користе у апликацији која се тестира или неким другим детаљима кодирања, што може бити врста тестирања у белој кутији.
Тако аутоматизовано тестирање може бити и црно-бело или бело поље у зависности од сценарија у којима се аутоматизација изводи.
П # 35) Колико сте тест случајева дневно аутоматизовали?
Одговор: Па, број зависи од сложености тест случајева. Када је сложеност била ограничена, успео сам да аутоматизујем 5 до 6 тест случајева дневно. Понекад сам успео да аутоматизујем само један тест за сложене сценарије.
Такође сам разложио своје тест случајеве на различите компоненте, попут узимања уноса, прорачунавања, верификације резултата итд. У случају врло сложених сценарија и требало ми је 2 или више дана.
П # 36) Који фактори одређују ефикасност тестирања аутоматизације?
Одговор: Неки од фактора који одређују ефикасност испитивања аутоматизације су:
- Уштеда времена покретањем скрипти током ручног извршавања тест случајева.
- Пронађени недостаци
- Проверите покривеност или покривеност кодом
- Време одржавања или време израде
- Стабилност скрипти
- Тестирање поновне употребљивости
- Квалитет тестираног софтвера
П # 37) Који се тест случајеви могу аутоматизовати?
Одговор: Врсте тест случајева који се могу аутоматизовати су:
(и) Случајеви за тестирање дима: Тестирање дима такође је познато и као тестирање верификације грађевине. Случајеви за тестирање дима покрећу се сваки пут када се изда нова верзија како би се проверило исправност грађевине ради прихватања да се изврши тестирање.
(ии) Случајеви регресионих тестова : Регресијско тестирање је тестирање како би се осигурало да претходно развијени модули функционишу како се очекивало након додавања новог модула или отклањања грешке.
Случајеви регресионих тестова су веома пресудни у инкременталном софтверском приступу где се нова функционалност додаје у свакој фази повећања. У овом случају, регресијско испитивање се врши у свакој инкременталној фази.
(иии) Случајеви сложеног прорачуна: Испитни случајеви који укључују неке сложене прорачуне за верификацију поља за апликацију спадају у ову категорију. Сложени резултати прорачуна склонији су људским грешкама, па стога аутоматизовани дају тачне резултате.
(ив) Тест случајеви засновани на подацима: Тест случајеви који имају исти скуп корака и изводе се више пута са променом података познати су као тест случајеви вођени подацима. Аутоматско тестирање за ове врсте тест случајева је брзо и исплативо.
(в) Нефункционални тест случајеви : Тест случајеви попут тестова оптерећења и тестова перформанси захтевају симулирано окружење са више корисника и више комбинација хардвера или софтвера.
Ручно подешавање више окружења је немогуће за сваку комбинацију или број корисника. Аутоматизовани алати могу лако створити ово окружење за лако обављање нефункционалних испитивања.
П # 38) Које су фазе у животном циклусу тестирања аутоматизације?
Одговор: Фазе у животном циклусу испитивања аутоматизације укључују:
- Одлука да се изврши испитивање аутоматизације.
- Идентификујте и научите о алату за аутоматизацију.
- Одредити обим испитивања аутоматизације.
- Дизајнирајте и развијте пакет за тестирање.
- Извршење теста
- Одржавање тест скрипти.
П # 39) Шта је Аутоматед тест сцрипт?
Одговор: Аутоматизована тестна скрипта је кратак програм који је написан на програмском језику за извођење скупа упутстава на тестираној апликацији како би се потврдило да ли је апликација у складу са захтевима.
Овај програм приликом покретања даје резултате теста као положен или не зависи од тога да ли је апликација у складу са очекивањима.
Закључак
То су главна питања која су независна од алата за аутоматизацију или програмског језика. Интервјуи за аутоматизацију такође укључују питања специфична за алат и програмски језик, у зависности од алата са којим сте радили.
Већина питања о аутоматизацији тестова усредсређена је на оквир који развијате, па се препоручује да темељито направите и разумете тест оквир. Када интервјуишем, а кандидат је одговорио на моје питање, такође преферирам постављање питања специфичног за језик (у мом случају цоре јава).
Питања почињу од основа Јава-а да би се написала логика неких основних сценарија попут:
- Како бисте из датог реда издвојили скуп текста?
- Како бисте издвојили УРЛ?
- На било којој веб страници, у било ком оквиру, број веза и њихов садржај се динамички мењају, како бисте то поднели?
- Како се бавите сликама и флеш објектима?
- Како пронаћи реч у реду?
Одговори на све ово питања за аутоматизацију теста су врло специфични за алат / језик који користите за аутоматизацију. Дакле, пре него што одете на интервју, прочистите своје вештине програмирања.
У случају да нисте добили прилику да креирате свој оквир, а неко други га је креирао, онда направите мало времена да га темељито разумете пре него што седнете за интервју.
Неки савети за интервјуе са аутоматизованим тестирањем били би:
- Добро познајте свој алат.
- Научите технике лоцирања које користи ваш алат.
- Вежбајте програмирање користећи језик који користите за тестирање аутоматизације.
- Научите свој оквир и његове компоненте.
- Увек је корисно ако сте били укључени у развој вашег оквира. Дакле, будите детаљни са модулима у оквиру на којем сте радили.
Надам се да ће вам ова питања бити корисна за припрему за интервју за аутоматизацију теста.
Препоручено читање
- Интервјуирајте питања и одговоре
- Питања и одговори за испитивање ЕТЛ-а
- Нека занимљива питања за испитивање софтверског тестирања
- 25 најбољих агилних тестова за интервју и питања и одговори
- 20 најважнијих питања и одговора за испитивање АПИ тестирања
- Питања и одговори за тестирање софтвера (1. део)
- Најбољи алати за тестирање софтвера 2021. године [КА Тест Аутоматион Тоолс]
- 30 водећих питања и одговора за испитивање безбедности