Топ 25 функционални тестови интервюта Въпроси и отговори

top 25 functional testing interview questions

Най-често задавани въпроси и отговори за интервю за функционално тестване:

Както самото име определя, функционалното тестване е процес на тестване на приложение по отношение на спецификациите на изискванията.

Функционалното тестване може да се извърши ръчно или чрез автоматизация, но всеки процес включва тестване на приложението чрез предоставяне на набор от входове и определяне или проверка на резултата / изхода чрез сравняване на действителния резултат с очакваните резултати.

Функционалното тестване има различни фази, които трябва да бъдат взети предвид при тестването. В тази статия ще видим множество въпроси за интервю и отговори, които ще ви помогнат да се подготвите добре.

Най-популярни въпроси за интервю за функционално тестване

В # 1) Какво разбирате под термина „функционално тестване“?

Отговор: Техника за тестване на черна кутия, при която функционалността на приложението се тества, за да генерира желания изход чрез предоставяне на определен вход, се нарича „Функционално тестване“.

Ролята на функционалното тестване е не само да провери поведението на приложението съгласно спецификацията на документа за изискване, но също така да провери дали приложението е готово да бъде пуснато в среда на живо или не.

По-долу са дадени няколко често използвани техники за функционално тестване:

• Единично тестване
• Тестване на дим
• Интеграционно тестване
• Тестване на системата
• Тестване на използваемостта
• Регресионно тестване
• Тест за приемане от потребителя

В # 2) Кои са важните стъпки, които са обхванати от функционалното тестване?

Отговор: Следват стъпките, които трябва да бъдат обхванати като част от функционалното тестване:

• Разбиране на спецификацията на документа за изискване и изчистване на съмненията и запитванията под формата на коментарни коментари.
• Написване на тестови случаи по отношение на спецификацията на изискванията, като се имат предвид всички сценарии, които трябва да бъдат взети предвид за всички случаи.
• Идентифициране на тестовите входове и заявяване на тестови данни, необходими за изпълнение на тестовите случаи, както и за проверка на функционалността на приложението.
• Определете действителните резултати според входните стойности, които ще бъдат тествани.
• Изпълнете тестовите случаи, които определят дали поведението на приложението е според очакванията или е възникнал дефект.
• Сравнете действителния резултат и изчисления резултат, за да разберете действителния резултат.

В # 3) Обяснете разликата между функционално тестване и нефункционално тестване.

Отговор: Разликата между функционално тестване и нефункционално тестване може да бъде обяснена по-долу:

В # 4) По какво се различава ‘Build’ от ‘Release’?

Отговор: Изграждане е изпълним файл, който се отнася до онази част от приложение, която се предава на тестер, за да тества внедрената функционалност на приложението заедно с някои корекции на грешки. Компилацията може да бъде отхвърлена от екипа за тестване, ако не премине критичния контролен списък, който съдържа основната функционалност на приложението.

В цикъла на тестване на приложение може да има множество компилации.

Пуснете се отнася до софтуерното приложение, което вече не е във фаза на тестване и след приключване на тестването и разработването, приложението се предава на клиента. Една версия има няколко компилации, свързани с нея.

В # 5) Обяснете цикъла на грешките.

Отговор: Казва се, че грешката е нежелана грешка, недостатък, грешка и т.н., която е възникнала в приложението и му пречи да достави желания резултат. Когато някакъв дефект или грешка се срещне в приложение по време на тестване, след това от регистриране на дефект до неговото разрешаване, грешка се движи през определен жизнен цикъл, известен като жизнен цикъл на грешки.

По-долу фигурата ще ви даде представа за жизнения цикъл на бъговете:

(изображение източник )

Целият процес протича както и когато се срещне проблем или грешка. Той се съобщава / регистрира в инструмент за проследяване на грешки след значителен формат. Тези грешки се възлагат на разработчика и състоянието му се прави като „Отворено“. Разработчикът вече може да прегледа грешката, да я възпроизведе в края й и да започне да работи по нея.

Ако грешката е коригирана, разработчикът променя състоянието си на „Фиксирана“ или състоянието може да бъде преместено в „нужда от повече информация“, „няма да се поправи“, „не може да се възпроизведе“ и др., В други случаи. След това QA извършва регресия, т.е. повторно проверява грешките с конкретно действие и отговаря съответно.

Ако проблемите / бъговете вече се държат според очакванията, тогава състоянието му се променя на Проверено / Затворено друго Отворете отново.

В # 6) Включете някакъв статус на грешка заедно с описанието му.

видове метаданни в хранилището на данни

Отговор: По-долу са включени няколко състояния на грешки заедно с техните описания:

• Ново: Когато дефектът или грешката се регистрират за първи път, това се казва като Ново.
• Възложено: След като тестващият регистрира грешка, неговата грешка се преглежда от ръководството на тестера и след това се възлага на съответния екип от разработчици.
• Отворено: Tester регистрира грешка в отворено състояние и тя остава в отворено състояние, докато разработчикът не изпълни някаква задача по тази грешка.
• Решен / фиксиран: Когато разработчикът е разрешил грешката, т.е. сега приложението произвежда желания изход за определен проблем, тогава разработчикът променя състоянието си на Разрешено / Поправено.
• Проверено / затворено: Когато разработчикът е променил състоянието на разрешен / фиксиран, тестерът сега тества проблема в края му и ако е отстранен, той променя състоянието на грешката на „Проверено / затворено“.
• Отворете отново: Ако тестерът е в състояние да възпроизведе грешката отново, т.е. бъгът все още съществува дори след отстраняване от разработчика, той е означен като Reopen.
• Не е грешка / невалидна: Грешка може да бъде маркирана като невалидна или не грешка от разработчика, когато докладваният проблем е съгласно функционалността, но се регистрира поради неправилно тълкуване.
• Отложено: Обикновено, когато грешката е с минимален приоритет за изданието и ако липсва време, в този случай тези грешки с минимален приоритет се отлагат за следващото издание.
• Не може да се възпроизведе: Ако разработчикът не е в състояние да възпроизведе грешката в нейния край, като следва стъпките, посочени в изданието.

В # 7) Какво е известно като тестване на данни?

Отговор: Тестването, управлявано от данни, е методологията, при която серия от тестови скриптове, съдържащи тестови случаи, се изпълняват многократно, като се използват източници на данни като електронна таблица на Excel, XML файл, CSV файл, SQL база данни за входни стойности и действителният изход се сравнява с очаквания при проверката процес.

Например, тестово студио се използва за тестване на данни.

Някои предимства на управляваното от данни тестване са:

• Многократна употреба.
• Повторяемост.
• Тестово отделяне на данните от тестовата логика.
• Броят на тестовите случаи е намален.

В # 8) Кои са важните моменти, които трябва да се имат предвид при писане на тестови случаи?

Отговор: Писането на тестов случай се казва, че е най-важната дейност в процеса на изпълнение на теста, която изисква умения за писане, както и задълбочени познания за приложението, за да се направят ефективни и многократно използвани тестови случаи.

Няколко важни точки, които трябва да се имат предвид при писане на тестови казуси, включват:

• Трябва да има ясно разбиране на изискванията на клиента, преди да започне да пише тестовите случаи. Нищо не трябва да се предполага и всяко съмнение относно изискванията трябва да бъде изчистено.
• Всяко изискване трябва да бъде включено под формата на тестови случаи и нищо не трябва да бъде пропуснато. Обикновено се поддържа матрица на проследимостта, за да се проверява всяко изпълнение на изискванията и приключване на тестването.
• Съгласно спецификациите на документа за изискванията, всяко функционално и нефункционално изискване, включително интерфейс на потребителския интерфейс, трябва да бъде обхванато.
• Тестовите случаи трябва да се проверяват от време на време за повторение или излишък.
• Приоритетът е важен фактор, който трябва да бъде зададен за тестови случаи, докато пишете. Този приоритет помага на тестера да тества приложението първо с тестове с висок приоритет, които включват основна функционалност, след това със средни и по-късно тестове с нисък приоритет.
• За конкретно издание тестовите случаи също могат да бъдат изградени с Sprint, така че тестващият, както и разработчикът, да могат да анализират качеството на продукта въз основа на изпълнението на тестовия случай.
• Структурата на тестовите случаи трябва да се разбира лесно и трябва да бъде на прост език. Стойностите на входните данни за тестовите случаи трябва да са валидни, както и в широк диапазон.

В # 9) Какво е тестване за автоматизация?

Отговор: Тестването за автоматизация е методология за тестване, при която инструмент за автоматизация се използва за изпълнение на пакета от тестови случаи, за да се увеличи покритието на теста, както и скоростта за изпълнение на теста. Тестовете за автоматизация не изискват никаква човешка намеса, тъй като изпълняват предварително написани тестове и са в състояние да отчитат и сравняват резултатите с предишни тестове.

Повторяемостта, лекотата на използване, точността и по-голямата последователност са някои от предимствата на тестовете за автоматизация.

Някои инструменти за тестване на автоматизацията са изброени по-долу:

• Селен
• Телур
• вода
• САПУН

Въпрос # 10) Обяснете понятието стрес тестване и тестване на натоварване.

Отговор:

Стресиране е форма на тестване на производителността, при която приложението е длъжно да премине през усилие или стрес, т.е. изпълнение на приложението над прага на прекъсването, за да се определи точката, в която приложението се срива. Това състояние обикновено възниква, когато има твърде много потребители и твърде много данни.

Стрес тестването също така проверява възстановяването на приложението, когато натоварването е намалено.

Тестване на товара е форма на тестване на производителността, при която приложението се изпълнява над различни нива на натоварване за проследяване на пиковата производителност на сървъра, времето за реакция, пропускателната способност на сървъра и т.н. Чрез процеса на тестване на натоварване стабилността, производителността и целостта на приложението се определят при едновременно зареждане на системата .

В # 11) Какво разбирате от тестване на обема?

Отговор: Обемното тестване е форма на тестване на производителността, която определя нивата на производителност на пропускателната способност на сървъра и времето за реакция, когато едновременни потребители, както и голямо натоварване на данни от базата данни, се поставят върху системата / приложението под тестове.

В # 12) Кои са различните тестови техники, използвани при функционалното тестване?

Отговор: Има две различни техники за тестване, които се използват при функционално тестване.

Те могат да бъдат определени по-долу:

• Изпитване въз основа на изисквания: Тази форма на функционално тестване се извършва с приоритизиране на изискванията въз основа на критерии за риск. Това също така гарантира, че всички критични тестови пътища са включени в процеса на тестване.
• Тестване на бизнес процес: Тази форма на функционално тестване се извършва от гледна точка на бизнес процеса. Сценариите включват знания за бизнес процеси за извършване на тестване.

В # 13) Какво разбирате от проучвателно тестване? Кога се изпълнява?

Отговор: Проучвателно тестване означава тестване или проучване на приложението, без да се спазват графици или процедури. Докато извършват изследователски тестове, тестерите не следват никакъв модел и използват нестандартното си мислене и разнообразни идеи, за да видят как работи приложението.

Следването на този процес обхваща дори и най-малката част от приложението и помага за намирането на повече проблеми / грешки, отколкото в нормалния процес на тестване на тестови случаи.

Изследователското тестване обикновено се извършва в случаите, когато:

• В екипа за тестване има опитен тестер, който може да използва опита си, за да приложи всички най-добри възможни сценарии.
• Всички критични пътища са покрити и основните тестови случаи са подготвени съгласно изпълнените спецификации на изискванията.
• Има критично приложение и във всеки случай не може да се пропусне възможен случай.
• Нов тестер е влязъл в екипа, проучването на приложението ще им помогне да разберат по-добре, както и ще следват собствения си ум, докато изпълняват всеки сценарий, вместо да следват пътя, както е посочено в документа за изискванията.

Въпрос # 14) Какви са възможните функции за влизане, които трябва да бъдат тествани за всяко уеб приложение?

Отговор: По-долу са изброени възможните сценарии, които могат да бъдат изпълнени за пълно тестване на функцията за влизане на всяко приложение:

• Проверете полетата за въвеждане, т.е. потребителско име и парола, както с валидни, така и с невалидни стойности.
• Опитайте да въведете валиден имейл адрес с неправилна парола и също така въведете невалиден имейл и валидна парола. Проверете дали се показва правилното съобщение за грешка.
• Въведете валидни идентификационни данни и влезте в приложението. Затворете и отворете отново браузъра, за да проверите дали все още сте влезли.
• Въведете приложението след влизане и след това отново се върнете обратно към страницата за вход, за да проверите дали потребителят е помолен отново да влезе или не.
• Влезте от един браузър и отворете приложението от друг браузър, за да проверите дали сте влезли и в друг браузър или не.
• Променете паролата след влизане в приложението и след това опитайте да влезете със старата парола.

Има и няколко други възможни сценария, които могат да бъдат тествани.

Въпрос # 15) Обяснете тестването за достъпност и неговото значение в настоящия сценарий.

Отговор: Тестването за достъпност е форма на тестване за използваемост, при което тестването се извършва, за да се гарантира, че приложението може лесно да се обработва от хора с увреждания като слух, цветна слепота, слаба видимост и т.н. В днешния сценарий мрежата е придобила основното място в нашия живот в формата на сайтове за електронна търговия, електронно обучение, електронни плащания и др.

По този начин, за да расте по-добре в живота, всеки трябва да може да бъде част от технологията, особено хората с някои увреждания.

По-долу са изброени няколко вида софтуер, които помагат и помагат на хората с увреждания да използват технологията:

• Софтуер за разпознаване на реч
• Софтуер за четец на екрана
• Софтуер за увеличение на екрана
• Специална клавиатура

В # 16) Какво представлява Adhoc тестването?

Отговор: Adhoc тестването, обикновено известно като произволно тестване, е форма на тестване, която не следва нито един тестов случай или изискване на приложението. Adhoc тестването е основно непланирана дейност, при която произволна част от приложението се проверява произволно, за да се открият дефекти.

В такива случаи възникналите дефекти са много трудни за възпроизвеждане, тъй като не се следват планирани тестови случаи. Adhoc тестването обикновено се извършва, когато има ограничено време за извършване на сложни тестове.

В # 17) Какво е разделяне на еквивалентност?

Отговор: Разделянето на еквивалентност, известно още като разделяне на клас на еквивалентност, е форма на тестване на черна кутия, при която входните данни се разделят на класове данни. Този процес се прави, за да се намали броят на тестовите случаи, но все пак да се покрият максималните изисквания.

Прилага се техника за разделяне на еквивалентност, където стойностите на входните данни могат да бъдат разделени на диапазони. Обхватът на входните стойности е дефиниран по такъв начин, че да се тества само едно условие от всеки дял на диапазона, като се приема, че всички останали условия на същия дял ще се държат по същия начин за софтуера.

Например: За да идентифицираме лихвения процент според салдото по сметката, можем да идентифицираме диапазона на салдото в сметката, който печели различен лихвен процент.

Въпрос # 18) Обяснете анализа на граничната стойност.

Отговор: Методът за анализ на гранична стойност проверява граничните стойности на дяловете на класа на еквивалентност. Анализът на граничната стойност е основно техника за тестване, която идентифицира грешките на границите, а не в рамките на стойностите на диапазона.

Например , Полето за въвеждане може да позволява минимум 8 знака и максимум 12 знака, след което 8-12 се счита за валиден диапазон, а 13 се считат за невалиден диапазон. Съответно тестовите случаи се записват за валидна стойност на дяла, точна гранична стойност и невалидна стойност на дяла.

Въпрос # 19) Обяснете разликата между сериозност и приоритет.

Отговор: Тежест на дефектите се определя от нивото или степента на въздействие от дефекта върху изпитваното приложение. Колкото по-голяма е тежестта на дефекта, толкова по-голямо е въздействието върху приложението.

Следват 4 класа, в които се категоризира тежестта на дефекта:

• Критично
• Майор
• Среден
• Ниска

Приоритет на дефектите определя реда, в който дефектът трябва да бъде разрешен първо, т.е. колкото по-висок е приоритетът на дефекта, означава, че приложението е неизползваемо или е останало в даден момент и дефектът трябва да бъде разрешен възможно най-скоро.

Следват 3 класа, в които е дефиниран приоритет на дефекта:

• Високо
• Среден
• Ниска

В # 20) Кога извършваме тестване на дим?

Отговор: Тестването на дим се извършва върху приложението след получаване на компилацията. Тестерът обикновено тества критичния път, а не функционалността в дълбочина, за да се увери дали компилацията ще бъде приета за допълнително тестване или ще бъде отхвърлена в случай на счупено приложение.

Контролният списък за дим обикновено съдържа критичния път на приложението, без който приложението е блокирано.

Въпрос # 21) Какво разбирате от тестването на Sanity?

Отговор: Тестването за здравословно състояние се извършва след получаване на компилацията, за да се провери новата функционалност / дефекти, които трябва да бъдат отстранени. При тази форма на тестване целта е да се провери функционалността приблизително според очакванията и да се определи дали грешката е коригирана, както и ефекта от фиксираната грешка върху тестваното приложение.

Няма смисъл да приемате компилацията от тестера и да губите време, ако тестването на Sanity не успее.

В # 22) Какво разбирате от матрицата за проследяване на изискванията?

Отговор: Матрицата за проследяване на изискванията (RTM) е инструмент за проследяване на покритието на изискванията в процеса на тестване.

В RTM всички изисквания са категоризирани като тяхното развитие по време на спринта и съответните им идентификатори (внедряване / подобряване на нови функции / предишни издания и т.н.) се поддържат, за да се следи, че всичко, споменато в документа за изискванията, е изпълнено преди пускането на продуктът.

RTM се създава веднага след получаване на документа с изискванията и се поддържа до пускането на продукта.

В # 23) Кои са факторите, които трябва да се вземат предвид при тестовете, основани на риска?

Отговор: Чрез тестване на даден проект на базата на риска не е просто да се осигури проект без риск, но основната цел на тестовете, базирани на риска, е да се постигнат резултатите от проекта чрез прилагане на най-добрите практики за управление на риска.

Основните фактори, които трябва да се вземат предвид при тестовете, базирани на риска, са както следва:

• Да се ​​идентифицира кога и как да се приложи тестване въз основа на риска на подходящо приложение.
• Да се ​​идентифицират мерките, които действат добре при намирането, както и справянето с риска в критични области на приложението.
• За постигане на резултата от проекта, който балансира риска с качеството и характеристиките на приложението.

В # 24) Разграничете регресионното тестване от повторното тестване.

Отговор: Разликата между регресионното тестване и повторното тестване може да се обясни по следния начин:

В # 25) Обяснете теста за приемане от потребителя.

Отговор: Тестовете за приемане от потребителите обикновено се извършват след цялостен тест на продукта. При тази форма на тестване, потребителите на софтуер или да речем, клиент, сам използва приложението, за да се увери дали всичко работи според изискването и перфектно в реалния свят.

Въпроси и отговори за тестове за автоматизация на селен

UAT е известен също като тестване на крайния потребител.

Заключение

Чрез тази статия се опитах да обясня всяка тема на функционалното тестване, така че всеки човек, който се подготвя за интервюто, лесно да разбере темата и да ги запомни.

Тези въпроси и отговори за интервю за функционално тестване ще ви насочат да изчистите успешно всяко интервю с пълно доверие.

Пожелаваме на всички успех.

Надявам се, че тези въпроси и отговори за интервю за функционално тестване ще ви помогнат в даден момент от вашата кариера.

Препоръчително четене

• Функционално тестване срещу нефункционално тестване
• 16 нови функции на инструмента Micro Focus UFT (Унифицирано функционално тестване) - QTP срещу UFT
• 5 най-добри алтернативни инструменти за унифицирано функционално тестване на HP (UFT)
• Пълно ръководство за нефункционално тестване за начинаещи
• Ръководство стъпка по стъпка за Jubula - инструмент за автоматизирано функционално тестване с отворен код
• Функционално тестване срещу тестване на производителността: Трябва ли да се прави едновременно?
• Пълно ръководство за функционално тестване с неговите типове и пример
• Урок за QA на Parrot: Преглед на инструмента за функционално тестване на различни браузъри
• Spock за интеграция и функционални тестове със селен
• Разликите между модулното тестване, интегрираното тестване и функционалното тестване
• Топ 25 функционални тестови интервюта Въпроси и отговори
• Топ 30 на инструментите за функционално тестване през 2021 г.