39 top automation testing interview questions
Най-често задавани въпроси за интервю за автоматизиране на тестове за начинаещи и кандидати за напреднали:
Автоматизацията на тестовете играе много важна роля в целия жизнен цикъл на софтуера. През повечето време, когато искаме да се подготвим за интервю за автоматизация, ние се фокусираме само върху специфични за инструмента въпроси.
Трябва обаче да вземем предвид и факта, че ученето и познаването на инструмента е просто средство и не е крайната цел.
По този начин, когато се подготвяме за интервю за тестер за автоматизация, трябва да разгледаме „Автоматизация“ като цяло и да се съсредоточим върху рамката и свързаните стъпки.
Всички знаем, че тестването на софтуер е много важна част от разработването на софтуер. Но с бързо нарастващите методологии и среди за разработка на софтуер става трудно ръчно да тествате всичко за дадено приложение в рамките на ограничен период от време, заедно с ограниченията на разходите.
По този начин тестовете за автоматизация бързо нарастват на пазара, за да ускорят темпото на развитие. Този урок включва най-добрите въпроси за интервю за тестване за автоматизация. Опитах се да цитирам кратките и бързи въпроси, които са много специфични за автоматизацията като цяло и не са специфични за нито един „инструмент“.
Топ 39 въпроси за интервю за тестване на автоматизация
Обхванахме основните въпроси за автоматизация на тестовете, както и някои разширени въпроси за кандидати от средно до експертно ниво с опит до 2 до 5 години.
В # 1) Какво е автоматизация?
Отговор: Автоматизацията е всяко действие, което може да намали човешките усилия.
В # 2) Какво е тестване за автоматизация?
Отговор: Процесът на използване на специални софтуерни инструменти или скриптове за извършване на тестови задачи като въвеждане на данни, изпълнение на тестовите стъпки и сравняване на резултатите и т.н. е известен като тестване за автоматизация.
В # 3) Кои всички неща можете да автоматизирате?
Отговор:
- Тест за регресия
- Пакет за тест за дим / здрав разум
- Изграждане на внедряване
- Създаване на тестови данни
- Автоматизиране зад GUI като тестване на API и методи.
В # 4) Кога е полезно тестването за автоматизация?
Отговор: Тестването за автоматизация е полезно в следните сценарии:
а) Регресионно тестване: В случай на отстраняване на грешки или внедряване на нов модул, трябва да се уверим, че вече внедрената или непроменена функционалност не е засегната. В този случай в крайна сметка изпълняваме теста за регресия няколко пъти.
Например: След всяка заявка за промяна или корекция на грешка, след всяка итерация в случай на подход на постепенно развитие и т.н.
б) Нефункционално тестване: Тестване на нефункционални аспекти на приложение.
Например, Тестовете за натоварване или тестване на производителността и т.н. са много трудни за проследяване и анализ на хората.
в) Сложно изчисление проверки или тестови сценарии, които са склонни към човешки грешки.
г) Многократно изпълнение на същите тестове: Понякога трябва да изпълним един и същ набор от тестови случаи за различен набор от данни или след всяко издание на компилация или на множество хардуер, софтуер или комбинация от двете.
Автоматизирането на тестовите случаи в горните сценарии помага за постигане на скоростта на тестване и минимизиране на човешките грешки.
В # 5) Как разпознавате тестовите случаи, които са подходящи за автоматизация?
Отговор: Идентифицирането на подходящите тестови случаи за автоматизация е най-важната стъпка към автоматизацията.
В # 6) Можете ли да постигнете 100% автоматизация?
Отговор: Трудно е да се постигне 100% автоматизация, тъй като ще има много тестови случаи, а някои случаи се изпълняват рядко. Автоматизирането на тези случаи, които не се изпълняват, често няма да добави стойност към автоматизирания пакет.
В # 7) Как да решим инструмента, който човек трябва да използва за тестване на автоматизация в своите проекти?
Отговор: За да идентифицирате инструмента за тестване за автоматизация във вашия проект:
да се) Разберете задълбочено изискванията на проекта си и идентифицирайте сценариите за тестване, които искате да автоматизирате.
б) Потърсете списъка с инструменти, които поддържат изискванията на вашия проект.
° С) Определете бюджета си за инструмента за автоматизация. Изберете инструментите в рамките на вашия бюджет.
д) Определете дали вече разполагате с квалифицирани ресурси за инструментите. Ако нямате необходимите квалифицирани ресурси, тогава определете разходите за обучение на съществуващите ресурси или наемане на нови ресурси.
е) Сега сравнете всеки инструмент за ключови критерии като:
- Колко лесно е да се разработят и поддържат скриптове за инструмента?
- Може ли нетехническо лице също да изпълни тестовите случаи с малко обучение?
- Инструментът поддържа ли различни видове платформи като уеб, мобилни, настолни и др. Въз основа на изискванията на вашия проект?
- Инструментът има ли функционалност за тестово отчитане? Ако не, лесно ли се конфигурира за инструмента?
- Как е инструментът за поддръжка на различни браузъри за уеб-базирани приложения?
- Колко различни видове тестване може да поддържа този инструмент?
- Колко езика поддържа инструментът?
е) След като сравните инструментите, изберете инструмента, който е в рамките на вашия бюджет и подкрепи вашите проектни изисквания, и ви дава повече предимства въз основа на ключовите критерии, споменати по-горе.
В # 8) Понастоящем нямам автоматизация в проекта си, но сега искам да внедря автоматизация, какви биха били моите стъпки?
Отговор:
- Първо определете кой тип тестване / тестови случаи искате да автоматизирате.
- Идентифицирайте инструмента
- Проектирайте рамката
- Създавайте полезни файлове и файлове на околната среда.
- Започнете да скриптирате
- Идентифицирайте и работете по отчитане.
- Разпределяне на време за подобряване и поддържане на сценариите.
Необходимите стъпки за провеждане на автоматизирано тестване за проект включват:
- Разберете предимствата и недостатъците на тестовете за автоматизация и идентифицирайте тестовите сценарии, които са подходящи за автоматизация.
- Изберете инструмента за автоматизация, който е най-подходящ за автоматизиране на идентифицираните сценарии
- Намерете експерта по инструмента, който да ви помогне при настройката на инструмента и необходимата среда за изпълнение на тестовите случаи с помощта на инструмента.
- Обучете екипа, за да могат да пишат скриптове на езика за програмиране, който инструментът поддържа.
- Създайте тестовата рамка или идентифицирайте вече съществуващата, която отговаря на вашите изисквания.
- Напишете план за изпълнение за операционна система, браузъри, мобилни устройства и др.
- Напишете скриптове за програмиране за ръчни тестове, за да ги конвертирате в автоматизирани тестове.
- Отчетете състоянието на тестовия случай, като използвате функцията за отчитане на инструмента.
- Поддържайте скриптовете за текущи промени или нови функции.
В # 9) Как решавате кой инструмент трябва да използвате?
Отговор: Заключение кой инструмент е най-подходящ за проекта се изисква много мозъчна атака и дискусии.
В # 10) След като идентифицирате инструмента, какви биха били следващите ви стъпки?
Отговор: След като финализираме инструмента, следващата ни стъпка ще бъде да проектираме рамката.
В # 11) Какво е рамка?
Отговор: Рамката е набор от структурата на целия пакет за автоматизация. Това е и насока, която, ако се следва, може да доведе до структура, която е лесна за поддръжка и подобряване.
Тези насоки включват:
- Стандарти за кодиране
- Обработка на данните от теста
- Поддържане и обработка на елементите (хранилище на обекти в QTP)
- Обработка на файлове с околна среда и файл със свойства
- Отчитане на данни
- Работа с трупи
В # 12) Какви са атрибутите на една добра рамка?
Отговор: Характеристиките включват:
- Модулни: Рамката трябва да бъде приспособима за промяна. Тестерите трябва да могат да променят скриптовете според промените в средата или информацията за вход.
- Многократно: Често използваните методи или помощни програми трябва да бъдат написани в общ файл, достъпен за всички скриптове.
- Последователно: Пакетът трябва да бъде написан в последователен формат, като се следват всички приети практики за кодиране.
- Независим: Сценариите трябва да бъдат написани по такъв начин, че да са независими един от друг. В случай, че един тест не успее, той не трябва да задържа останалите тестови случаи (освен ако не е страница за вход)
- Дневници: Добре е да сте внедрили функцията за регистриране в рамката. Това би помогнало в случай, че нашите скриптове се изпълняват за по-дълги часове (да кажем нощен режим), ако скриптът се провали по всяко време, наличието на регистрационния файл ще ни помогне да открием местоположението заедно с вида на грешката.
- Отчитане: Добре е функцията за отчитане да бъде автоматично вградена в рамката. След като скриптът приключи, можем да изпратим резултатите и отчетите по имейл.
- Интеграция: Рамката за автоматизация трябва да бъде такава, че да е лесна за интегриране с други приложения като непрекъсната интеграция или задействане на автоматизирания скрипт веднага след внедряването на компилацията.
В # 13) Можете ли да се справите без рамка?
Отговор: Рамките са насоки, а не задължителни правила, така че можем да се справим без рамка, но ако я създадем и следваме, подобряването и поддържането ще бъде лесно за изпълнение.
В # 14) Какви са различните видове инструменти за автоматизация, за които сте запознати?
Отговор: Инструмент с отворен код като Selenium, JMeter и др.
Платени инструменти като QTP, Load Runner, Ranorex, RFT и Rational Robot.
Въпрос # 15) Каква е структурата на рамката?
Отговор: Обикновено структурата трябва да има - (Тя ще се различава от проект до проект)
- Папка “src” (източник), съдържаща действителните тестови скриптове.
- Папка ”lib” (библиотека), съдържаща всички библиотеки и общи методи.
- Папка „class“, съдържаща целия файл на класа (за всеки случай, използващ java).
- Папка „дневник“, съдържаща регистрационния файл (файлове).
- Файл / папка с всички идентификатори на уеб елемента.
- Файл, съдържащ URL, среда и информация за вход.
Q # 16) Къде ще поддържате информация като URL, вход, парола?
Отговор: Тази информация винаги трябва да се поддържа в отделен файл.
Въпрос # 17) Защо искате да запазите този вид информация в отделен файл, а не директно в кода?
Отговор: URL, Login и пароли са полетата, които се използват много често и се променят според средата и оторизацията. В случай, че го кодираме твърдо в нашия код, трябва да го променим във всеки файл, който има референция.
В случай, че има повече от 100 файла, тогава става много трудно да се променят всичките 100 файла и това от своя страна може да доведе до грешки. Така че този вид информация се поддържа в отделен файл, така че актуализирането става лесно.
В # 18) Кои са различните видове рамки?
Отговор: Различните видове рамки включват:
- Управлявана от ключови думи рамка
- Управлявана от данни рамка
- Хибридна рамка
- Линейни скриптове
Q # 19) Можете ли да кажете някои добри практики за кодиране по време на автоматизация?
Отговор: Някои от добрите практики за кодиране включват:
- Добавете подходящи коментари.
- Идентифицирайте методите за многократна употреба и ги запишете в отделен файл.
- Следвайте специфичните за езика конвенции за кодиране.
- Поддържайте тестовите данни в отделен файл.
- Изпълнявайте своите скриптове редовно.
Въпрос # 20) Някакъв вид тест, който според вас не трябва да бъде автоматизиран?
Отговор:
- Тестове, които се изпълняват рядко.
- Изследователско тестване
- Тестване на използваемостта
- Тест, който се изпълнява бързо, когато се извършва ръчно.
Q # 21) Смятате ли, че тестването може да се извършва само на ниво потребителски интерфейс?
безплатен софтуер за конвертиране на видео за компютър
Отговор: Днес, когато преминаваме към Agile режим, тестването не се ограничава само до потребителския интерфейс. Ранната обратна връзка е имперска за гъвкав проект. Ако се концентрираме само върху UI слоя, ние всъщност чакаме, докато UI бъде разработен и достъпен за тестване.
По-скоро можем да тестваме дори преди потребителският интерфейс да е действително разработен. Можем директно да тестваме API или методите, като използваме инструменти като Краставица и FitNesse .
По този начин ние даваме обратната връзка много по-рано и тестваме дори преди потребителският интерфейс да бъде разработен. Следването на този подход ще ни помогне да тестваме само GUI аспекта на малки козметични промени или някои проверки на потребителския интерфейс и ще помогне на разработчиците, като даде повече време за отстраняване на грешките.
В # 22) Как избирате кой инструмент за автоматизация е най-подходящ за вас?
Отговор: Изборът на инструмента за автоматизация зависи от различни фактори като:
- Обхватът на приложението, който искаме да автоматизираме.
- Режийни разходи за управление като разходи и бюджет.
- Време е да научите и внедрите инструмента.
- Тип поддръжка, налична за инструмента.
- Ограничение на инструмента
Q # 23) Какво мислите, че пречи на тестерите да правят автоматизация? Има ли начин да се преодолее?
Отговор: Основното препятствие за тестерите е да се научат да програмират / кодират, когато искат да автоматизират. Тъй като тестерите не кодират, адаптирането към кодирането е малко предизвикателство за тестерите.
Можем да го преодолеем чрез:
- Сътрудничество с разработчици при автоматизиране.
- Като се има предвид, че автоматизацията е отговорност на целия екип, а не само на тестерите.
- Отделяне на отделено време и фокус върху автоматизацията.
- Получаване на подходяща подкрепа за управление.
Можете да запишете тези въпроси за интервю за автоматизация като pdf и да ги отпечатате за по-нататъшно четене.
В # 24) Какво представлява рамката за тестване на автоматизацията?
Отговор: Като цяло рамката е набор от насоки. Набор от насоки, предположения, концепции и практики за кодиране за създаване на среда за изпълнение, в която тестовете ще бъдат автоматизирани, е известен като рамка за тестване на автоматизация.
Рамката за тестване на автоматизацията е отговорна за създаването на тестов сноп с механизъм за свързване с тестваното приложение, вземане на данни от файл, изпълнение на тестовите случаи и генериране на отчети за изпълнение на теста. Рамката за тестване на автоматизацията трябва да бъде независима от приложението и трябва да бъде лесна за използване, модифициране или разширяване.
В # 25) Кои са важните модули на рамката за тестване на автоматизацията?
Отговор: Важни модули на рамка за тестване на автоматизация са:
- Инструмент за тестване на твърдения: Този инструмент ще предостави изявления за утвърждаване за тестване на очакваните стойности в тестваното приложение. Например. TestNG, Junit и др.
- Настройка на данни: Всеки тестов случай трябва да вземе потребителските данни или от базата данни, или от файл или вграден в тестовия скрипт. Модулът за данни на Frameworks трябва да се грижи за приемането на данни за тестови скриптове и глобалните променливи.
- Инструмент за управление на изграждане: Framework трябва да бъде изграден и внедрен за използване на създаването на тестови скриптове.
- Инструмент за непрекъсната интеграция: С CICD (Непрекъсната интеграция и непрекъснато развитие) е необходим инструмент за непрекъсната интеграция за интегриране и внедряване на промените, направени в рамката при всяка итерация.
- Инструмент за отчитане: Инструмент за отчитане е необходим за генериране на четим отчет след изпълнението на тестовите случаи за по-добър изглед на стъпките, резултатите и грешките.
- Инструмент за регистриране: Инструментът за регистриране в рамките помага за по-доброто отстраняване на грешки на грешките и грешките.
В # 26) Обяснете някои инструменти за тестване на автоматизацията.
Отговор: Някои от известните инструменти за тестване на автоматизацията са обяснени по-долу:
(i) Селен : Селенът е тестова рамка за тестване на автоматизация на уеб приложения. Той поддържа множество браузъри и е независим от операционната система. Селенът също така поддържа различни езици за програмиране като Java, C #, PHP, Ruby и Perl и др.
Селен е набор от библиотеки с отворен код, който може да се използва за разработване на допълнителни тестови рамки или тестови скриптове за тестване на уеб-базирани приложения.
(ii) UFT : Унифицираното функционално тестване е лицензиран инструмент за функционално тестване. Той предоставя широка гама от функции като API, уеб услуги и др., А също така поддържа множество платформи като настолни компютри, уеб и мобилни устройства. UFT скриптовете са написани на Visual Basic скриптов език.
(Ii) епохи : Appium е инструмент за тестване на мобилни приложения с отворен код. Използва се за автоматизиране на тестване на междуплатформени, естествени, хибридни и уеб-базирани мобилни приложения. Appium автоматизира всяко мобилно приложение от всякакъв език с пълен достъп до API и DB от тестовия код.
Appium се основава на архитектурата клиент-сървър и е еволюирал от селен.
(iv) Краставица : Краставицата е инструмент за разработка, основан на поведение с отворен код. Той се използва за уеб-базирано тестване на автоматизация на приложения и поддържа езици като ruby, java, scala, groovy и др. Краставицата чете изпълнима спецификация, написана в обикновен текст, и тества приложението, което се тества за тези спецификации.
За да може краставицата да разбере сценариите в обикновен текст, трябва да следваме някои основни правила за синтаксис, които са известни като Корнишон.
(v) TestComplete : TestComplete е лицензиран инструмент за автоматизирано тестване на потребителски интерфейс за тестване на приложението на различни платформи като настолни компютри, уеб, мобилни устройства и др. Той осигурява гъвкавост за запис на тестов случай в един браузър и стартирането му в множество браузъри и по този начин поддържа тестване на различни браузъри.
TestComplete има вграден алгоритъм за разпознаване на обекти, който уникално идентифицира обект и го съхранява в хранилището.
Въпрос # 27) Какви са различните видове техники за рамково тестване?
Отговор: Има четири вида техники за рамки за автоматизиране на тестовете.
Те са:
(i) Модулна рамка за тестване:
Тази рамка е изградена върху концепцията за абстракция. В тази рамка тестерът създава скриптове за всеки модул на тестваното приложение поотделно и след това тези скриптове се комбинират в йерархичен ред, за да създадат големи тестови случаи.
Той създава абстракционен слой между модулите, поради което всички модификации в тестовите скриптове за един модул не засягат други модули.
Предимства на тази рамка:
- По-лесна поддръжка и мащабируемост на тестовите случаи.
- Създаването на тестови случаи чрез използване на вече скриптирани модули е по-лесно и по-бързо.
Недостатъци:
- Тестовите случаи имат вградени данни. По този начин изпълнението на един и същ тестов скрипт с различни данни е голяма промяна на ниво скрипт.
(ii) Рамка за тестване на данни:
В рамката за тестване, управлявана от данни, входните данни и очакваните изходни данни, съответстващи на входните данни, се съхраняват във файл или база данни и автоматизираният скрипт изпълнява същия набор от тестови стъпки за множество набори от данни. С тази рамка можем да изпълним множество тестови случаи, при които се различават само входните данни и стъпките на изпълнение са еднакви.
Предимства:
- Намалява броя на тестовите скриптове, които трябва да бъдат изпълнени. Изпълняваме един и същ скрипт няколко пъти с различни данни.
- По-малко кодиране за тестване за автоматизация.
- По-голяма гъвкавост за поддържане и отстраняване на грешки или подобряване на функционалността.
- Тестови данни могат да бъдат създадени дори преди автоматизираната система за тестване да е готова.
Недостатъци:
- Само подобни тестови случаи с един и същи набор от стъпки за изпълнение могат да се комбинират за множество набори от данни. Различният набор от стъпки за изпълнение изисква различен тестов случай.
(iii) Рамка за тестване, управлявана от ключови думи:
Това е независима от приложение рамка за тестване, която използва таблици с данни и самообяснителни ключови думи. Ключовите думи обясняват действията, които трябва да бъдат извършени върху тестваното приложение, а таблицата с данни предоставя входните и очакваните изходни данни.
Тестването, базирано на ключови думи, е увеличение към тестването, управлявано от данни.
Предимства:
- По-малко кодиране и един и същ скрипт могат да се използват за множество набори от данни.
- Опитът за автоматизация не се изисква за създаване на тестов случай, използващ вече съществуващите ключови думи за действия.
- Едни и същи ключови думи могат да се използват в множество тестови случаи.
Недостатъци:
- Тази рамка е по-сложна, тъй като трябва да се грижи за действията с ключовите думи, както и за въвеждането на данни.
- Тестовите случаи стават по-дълги и сложни, като по този начин се засяга поддържането на същите.
(iv) Рамка за хибридно тестване:
Тази рамка е комбинация от всички гореспоменати рамки за тестване (модулни, управлявани от данни и управлявани от ключови думи).
В тази рамка тестовите случаи се разработват от модулни скриптове чрез комбинирането им в модулната рамка за тестване. Всеки от тестовите случаи използва скрипт на драйвер, който използва файл с данни, както е в рамката, управлявана от данни, и файл за действие, базиран на ключови думи.
Предимства:
- Модулен и лесен за поддръжка.
- По-малкото кодиране може да се погрижи за повече тестови случаи.
- Един тестов случай може да бъде изпълнен с множество набори от данни.
Недостатъци:
- Комплекс за четене, поддържане и подобряване.
В # 28) Кога предпочитате ръчното тестване пред тестовете за автоматизация?
Отговор: Предпочитаме ръчното тестване пред тестовете за автоматизация в следните случаи:
- Проектът е краткосрочен и писането на скриптове ще отнеме много време и ще струва много в сравнение с ръчното тестване.
- Изисква се гъвкавост. Автоматизираните тестови случаи се програмират и изпълняват по специфичен начин на конфигурации.
- Трябва да се извърши тестване на използваемостта.
- Приложения / модул е новоразработен и няма предишни тестови случаи.
- Трябва да се извършат ad hoc или изследователски тестове.
Въпрос # 29) Полезно ли е тестването на автоматизацията в гъвкава методология или не?
Отговор: Тестовете за автоматизация са полезни за регресия, дим или здравословно тестване. Всички тези видове тестове в традиционния модел водопад се случват в края на цикъла и понякога, ако няма много подобрения в приложението, може дори да не се наложи да правим регресионно тестване .
Докато в пъргава методология , всяка итерация изисква изпълнение на теста за регресия, тъй като се добавят някои нови функционалности.
Също така самият пакет за регресия продължава да расте след всеки спринт, тъй като функционалните тестови случаи на текущия модул за спринт трябва да бъдат добавени към пакета за регресия за следващия спринт.
По този начин тестовете за автоматизация по пъргава методология са много полезни и помагат за постигане на максимално покритие на теста за по-малко време на спринта.
В # 30) Избройте някои предимства и недостатъци на тестовете за автоматизация.
Отговор:
Предимства:
- По-малко човешки ресурси
- Многократна употреба
- Повече покритие на теста за по-малко време
- Надеждност
- Паралелно изпълнение на тестови случаи
- Бърз
Недостатъци:
потребителско име и парола по подразбиране за рутера
- Времето за разработка и поддръжка е повече.
- Разходи за инструменти
- Изискват се квалифицирани ресурси.
- Настройка на околната среда
- Проблем е отстраняването на грешки в Test Script.
В # 31) Избройте някои предимства и недостатъци на ръчното тестване.
Отговор:
Предимства:
- Не е необходима настройка на средата.
- Не се изискват познания по програмиране.
- Препоръчва се за динамично променящи се изисквания.
- Позволете на човешката сила за наблюдение да открива повече грешки.
- Цената е по-малка за краткосрочни проекти.
- Гъвкавост
Недостатъци:
- Трудно е да се извършат сложни изчисления.
- Многократна употреба
- Отнемане на време
- Висок риск от човешки грешки или грешки.
- Изискват се повече човешки ресурси.
В # 32) Можем ли да правим тестове за автоматизация без рамка? Ако да, тогава защо се нуждаем от рамка?
Отговор: Да, можем да извършим тестване за автоматизация, дори без да използваме рамка. Можем просто да разберем инструмента, който използваме за автоматизация, и да програмираме стъпките на езика за програмиране, който инструментите поддържат.
Ако автоматизираме тестови случаи без рамка, тогава няма да има последователност в програмните скриптове за тестови случаи.
Необходима е рамка, която да дава набор от насоки, които всеки трябва да следва, за да поддържа четливост, повторност и последователност в тестовите скриптове. Рамката също така предоставя едно общо основание за функционалност за отчитане и регистриране.
Въпрос # 33) Как ще автоматизирате основни тестови случаи за функционалност на „вход“ за приложение?
Отговор: Ако приемем, че инструментът и рамката за автоматизация вече са на мястото на тестовата среда.
За да тествате основната функционалност „Вход“:
- Разберете изискванията на проекта : Функцията за вход ще има текстово поле за потребителско име, текстово поле за парола и бутон за вход.
- Идентифицирайте тестовите сценарии: За функционалност за вход възможните тестови сценарии са:
- Празни потребителско име и парола
- Невалидно потребителско име и парола
- Валидно потребителско име и невалидна парола
- Валидно потребителско име и парола
- Подгответе a Файл за въвеждане на данни с данните, съответстващи на всеки сценарий.
- Стартирайте инструмента от програмата.
- Идентифицирайте полето за потребителско име, полето за парола и бутона за влизане.
- За всеки тестов сценарий вземете данните от файла с данни и въведете в съответните полета. Кликнете върху бутона за влизане в програмата след въвеждане на данните.
- Потвърдете съобщението за грешка за отрицателни сценарии и съобщението за успех за положителни сценарии в тестовия скрипт с помощта на твърдения.
- Бягай тестовия пакет и генерирайте отчета.
Въпрос # 34) Тестването за автоматизация е тестване на черна кутия или тестване на бяла кутия?
Отговор: Тестовете за автоматизация са предимно a тестване на черна кутия тъй като ние просто програмираме стъпките, които ръчният тестер изпълнява за тествано приложение, без да знаем дизайна или кода на приложението на ниско ниво.
Понякога автоматизираните тестови скриптове се нуждаят от достъп до данните за базата данни, които се използват в тестваното приложение, или някои повече подробности за кодиране и по този начин могат да бъдат вид бяло тестване.
По този начин автоматизираното тестване може да бъде както черно, така и бяло тестване в зависимост от сценариите, в които се извършва автоматизацията.
В # 35) Колко тестови случая сте автоматизирали на ден?
Отговор: Е, броят зависи от сложността на тестовите случаи. Когато сложността беше ограничена, успях да автоматизирам 5 до 6 тестови случая на ден. Понякога успях да автоматизирам само един тестов случай за сложни сценарии.
Също така разбих моите тестови случаи на различни компоненти, като вземете вход, направете изчислението, проверете изхода и т.н. в случай на много сложни сценарии и отне 2 или повече дни.
В # 36) Кои фактори определят ефективността на тестовете за автоматизация?
Отговор: Някои от факторите, които определят ефективността на тестовете за автоматизация, са:
- Спестено време чрез стартиране на скриптове за ръчно изпълнение на тестови случаи.
- Открити дефекти
- Тестово покритие или покритие на кода
- Време за поддръжка или време за разработка
- Стабилност на скриптовете
- Тествайте повторната употреба
- Качество на тествания софтуер
В # 37) Кои тестови случаи могат да бъдат автоматизирани?
Отговор: Видове тестови случаи, които могат да бъдат автоматизирани, са:
(i) Тестове за дим: Тестовете за дим са известни също като тестове за проверка на компилация. Тестовете за дим се изпълняват всеки път, когато се пуска нова компилация, за да се провери изправността на компилацията за приемане за извършване на тестване.
(ii) Случаи на тестове за регресия : Регресионното тестване е тестването, за да се гарантира, че предварително разработените модули функционират според очакванията след добавяне на нов модул или отстраняване на грешка.
Регресионните тестови случаи са много важни при инкрементния софтуерен подход, при който се добавя нова функционалност на всяка фаза на инкремент. В този случай се извършва регресионно тестване на всяка допълнителна фаза.
(iii) Тестови случаи на сложни изчисления: Тестовите случаи, които включват някои сложни изчисления за проверка на поле за приложение, попадат в тази категория. Сложните резултати от изчисленията са по-податливи на човешки грешки, поради което, когато се автоматизират, те дават точни резултати.
(iv) Тестови случаи, основани на данни: Тестовите случаи, които имат един и същ набор от стъпки и се изпълняват многократно с промяната на данните, са известни като управлявани от данни тестови случаи. Автоматизираното тестване за тези видове тестови случаи е бързо и рентабилно.
(v) Нефункционални тестови случаи : Тестовите случаи като тестове за натоварване и тестове за производителност изискват симулирана среда с множество потребители и множество хардуерни или софтуерни комбинации.
Ръчното настройване на множество среди е невъзможно за всяка комбинация или брой потребители. Автоматизираните инструменти могат лесно да създадат тази среда, за да извършват лесно нефункционално тестване.
Въпрос # 38) Какви са фазите в Автоматизацията за тестване на жизнения цикъл?
Отговор: Фазите в жизнения цикъл на тестване на автоматизацията включват:
- Решението за извършване на тестове за автоматизация.
- Идентифицирайте и научете за инструмента за автоматизация.
- Определете обхвата на тестовете за автоматизация.
- Проектирайте и разработете тестов пакет.
- Изпълнение на теста
- Поддръжка на тестови скриптове.
В # 39) Какво представлява автоматизиран тестов скрипт?
Отговор: Автоматизиран тестов скрипт е кратка програма, която е написана на език за програмиране, за да изпълни набор от инструкции за тествано приложение, за да провери дали приложението отговаря на изискванията.
Тази програма, когато се изпълнява, дава резултатите от теста като успешно или не зависи от това дали приложението е според очакванията.
Заключение
Това са основните въпроси, които са независими от инструмента за автоматизация или езика за програмиране. Интервютата за автоматизиране на тестове също включват въпроси, специфични за инструмента и езика за програмиране, в зависимост от инструмента, с който сте работили.
Повечето от въпросите за интервю за автоматизация на тестове са съсредоточени върху рамката, която разработвате, така че се препоръчва да създадете и разберете напълно вашата тестова рамка. Когато интервюирам и кандидатът е отговорил на въпроса ми в рамката, аз също предпочитам да задам специфичен за езика въпрос (основна Java в моя случай).
Въпросите започват от основите на Java, за да напишат логиката на някои основни сценарии като:
- Как бихте извлекли набор от текст от даден ред?
- Как бихте извлекли URL адреса?
- Във всяка уеб страница, при който и да е кадър, броят на връзките и съдържанието им се променят динамично, как бихте се справили?
- Как се справяте с изображения и флаш обекти?
- Как намираш дума в ред?
Отговори на всичко това въпроси за интервю за автоматизация на тестове са много специфични за инструмента / езика, който използвате за автоматизиране. Така че, преди да отидете на интервю, изчистете уменията си за програмиране.
В случай, че не сте получили възможност да създадете вашата рамка и някой друг я е създал, тогава отделете малко време, за да я разберете добре, преди да седнете за интервюто.
Някои съвети за тестови интервюта за автоматизация ще бъдат:
- Познайте инструмента си задълбочено.
- Научете техниките за локатор, използвани от вашия инструмент.
- Практикувайте програмиране, като използвате езика, който използвате за тестване на автоматизация.
- Научете вашата рамка и нейните компоненти.
- Винаги е изгодно, ако сте участвали в разработването на вашата рамка. Така че, бъдете задълбочени с модулите в рамката, по която сте работили.
Надявам се, че тези въпроси ще бъдат полезни за вас, за да се подготвите за тестово интервю за автоматизация.
Препоръчително четене
- Въпроси и отговори за интервюта
- Въпроси и отговори за интервю за ETL тестване
- Някои интересни въпроси за интервю за тестване на софтуер
- 25 най-добри пъргави тестови интервюта Въпроси и отговори
- Топ 20 най-важни въпроси и отговори за интервю за API тестване
- Въпроси и отговори за тестване на софтуер (част 1)
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Топ 30 Въпроси и отговори за тестване на сигурността