39 ТОП запитань та відповідей на тестування з питань автоматизації

39 top automation testing interview questions

Найчастіші запитання щодо тестування на автоматизацію для співбесіди для початківців та кандидатів для просунутих рівнів:

Автоматизація тестів відіграє дуже важливу роль протягом усього життєвого циклу програмного забезпечення. Більшу частину часу, коли ми хочемо підготуватися до співбесіди з автоматизованого тестування, ми зосереджуємось лише на питаннях, що стосуються конкретних інструментів.

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

Таким чином, щоразу, коли ми готуємося до співбесіди з тестувальником автоматизації, ми повинні розглядати «Автоматизацію» в цілому і зосередитись на структурі та задіяних кроках.

Ми всі знаємо, що тестування програмного забезпечення є дуже важливою частиною розробки програмного забезпечення. Але, завдяки швидко зростаючим методологіям та середовищам розробки програмного забезпечення, стає важко вручну протестувати все для додатка протягом обмеженого часу разом із обмеженнями витрат.

Таким чином, автоматичне тестування швидко зростає на ринку, щоб пришвидшити темпи розвитку. Цей підручник містить найпопулярніші запитання щодо інтерв’ю з тестування автоматизації. Я намагався навести короткі та короткі запитання, які дуже характерні для автоматизації в цілому і не стосуються жодного 'інструменту'.

Найпопулярніші 39 питань для тестування з автоматизації

Ми розглянули основні питання автоматизації тестування, а також деякі розширені питання для кандидатів середнього та експертного рівня з досвідом роботи від 2 до 5 років.

Q # 1) Що таке автоматизація?

Відповідь: Автоматизація - це будь-яка дія, яка може зменшити зусилля людини.

Q # 2) Що таке автоматизація тестування?

Відповідь: Процес використання спеціальних програмних засобів або сценаріїв для виконання таких завдань тестування, як введення даних, виконання кроків тестування та порівняння результатів тощо, відомий як автоматизація тестування.

Q # 3) Які всі речі ви можете автоматизувати?

Відповідь:

• Набір тестів на регресію
• Тест на дим / розум
• Побудувати розгортання
• Створення даних тесту
• Автоматизація графічного інтерфейсу, як тестування API та методів.

Q # 4) Коли корисно тестування автоматизації?

Відповідь: Тестування автоматизації корисно в таких сценаріях:

а) Регресійне тестування: У разі виправлення помилки або реалізації нового модуля, ми повинні переконатися, що вже реалізована або незмінена функціональність не постраждала. У цьому випадку ми закінчуємо тестування регресії кілька разів.

Наприклад: Після кожного запиту на зміну або виправлення помилки, після кожної ітерації у випадку поступового підходу до розробки тощо.

б) Нефункціональне тестування: Тестування нефункціональних аспектів програми.

Наприклад, Тестування навантаження чи тестування продуктивності тощо для людей дуже важко відстежувати та аналізувати.

в) Комплексний розрахунок перевірки або тестові сценарії, схильні до людських помилок.

г) Повторне виконання тих самих тестів: Іноді нам доводиться запускати один і той же набір тестів для різних наборів даних або після кожного випуску збірки або на декількох апаратних засобах, програмному забезпеченні або їх поєднанні.

Автоматизація тестових випадків у вищезазначених сценаріях допомагає досягти швидкості тестування та мінімізувати людські помилки.

Q # 5) Як ви визначаєте тестові випадки, які підходять для автоматизації?

Відповідь: Визначення відповідних тестових випадків для автоматизації є найважливішим кроком до автоматизації.

Q # 6) Чи можете ви досягти 100% автоматизації?

Відповідь: 100% автоматизації було б важко досягти, оскільки було б багато крайових тестів, а деякі випадки виконувались рідко. Автоматизація цих випадків, які не виконуються, часто не додає значення автоматизованому набору.

Q # 7) Як вирішити інструмент, який слід використовувати для тестування автоматизації у своїх проектах?

Відповідь: Для того, щоб визначити інструмент тестування автоматизації у вашому проекті:

до) Ретельно зрозумійте вимоги проекту та визначте сценарії тестування, які ви хочете автоматизувати.

б) Шукайте список інструментів, які підтримують вимоги вашого проекту.

в) Визначте свій бюджет на інструмент автоматизації. Виберіть інструменти в межах свого бюджету.

г) Визначте, чи вже маєте кваліфіковані ресурси для інструментів. Якщо у вас немає необхідних кваліфікованих ресурсів, визначте витрати на навчання наявних ресурсів або найм нових ресурсів.

є) Тепер порівняйте кожен інструмент за такими ключовими критеріями, як:

• Наскільки легко розробити та підтримувати сценарії для інструменту?
• Чи може нетехнічна особа також виконати тестові кейси з незначною підготовкою?
• Чи підтримує інструмент різні типи платформ, таких як Інтернет, мобільні пристрої, настільні комп'ютери тощо на основі вимог вашого проекту?
• Чи має інструмент функціональність тестової звітності? Якщо ні, чи легко це можна налаштувати для інструменту?
• Як працює інструмент для крос-браузерної підтримки веб-програм?
• Скільки різних типів тестування може підтримувати цей інструмент?
• Скільки мов підтримує інструмент?

f) Порівнявши інструменти, виберіть інструмент, який відповідає вашому кошторису та підтримайте вимоги вашого проекту, та надасть вам більше переваг на основі ключових критеріїв, згаданих вище.

Запитання №8) Наразі в моєму проекті немає автоматизованої автоматики, але зараз я хочу впровадити автоматизацію, якими будуть мої кроки?

Відповідь:

• Спочатку визначте, який тип тестування / тестових випадків ви хочете автоматизувати.
• Визначте інструмент
• Сконструюйте каркас
• Створюйте утилітні файли та файли середовища.
• Почніть виконувати сценарії
• Визначте та працюйте над звітуванням.
• Виділення часу на вдосконалення та підтримку сценаріїв.

Кроки, необхідні для забезпечення автоматизованого тестування для проекту, включають:

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

Q # 9) Як ви вирішуєте, який інструмент вам доведеться використовувати?

Відповідь: Висновок який інструмент найкраще підходить для проекту потрібно багато мозкових штурмів та обговорень.

Q # 10) Після того, як ви визначите інструмент, якими будуть ваші наступні кроки?

Відповідь: Після того, як ми доопрацюємо інструмент, наступним кроком буде розробка рамки.

Q # 11) Що таке фреймворк?

Відповідь: Фреймворк - це сукупність структури всього комплексу автоматизації. Це також настанова, яка при дотриманні може призвести до структури, яку легко підтримувати та вдосконалювати.

Ці вказівки включають:

• Стандарти кодування
• Обробка даних тесту
• Ведення та обробка елементів (сховище об’єктів у QTP)
• Обробка файлів середовища та файлу властивостей
• Звітність даних
• Обробка колод

Q # 12) Які атрибути хорошого фреймворку?

Відповідь: До характеристик належать:

• Модульний: Структура повинна бути пристосованою до змін. Тестери повинні мати можливість змінювати сценарії відповідно до середовища або зміни інформації для входу.
• Багаторазовий: Загальновживані методи та утиліти слід писати у загальному файлі, доступному для всіх сценаріїв.
• Послідовні: Набір повинен бути написаний у послідовному форматі, дотримуючись усіх прийнятих практик кодування.
• Незалежний: Сценарії повинні бути написані таким чином, щоб вони не залежали один від одного. Якщо один тест не вдається, він не повинен стримувати решту тестових випадків (якщо це не сторінка входу)
• Журнали: Добре, якщо у фреймворк була реалізована функція журналювання. Це допомогло б у випадку, якщо наші сценарії працюють довше годин (скажімо, нічний режим), якщо сценарій не вдається у будь-який момент часу, наявність журналу допоможе нам виявити місце розташування разом із типом помилки.
• Звітність: Добре, щоб функція звітування була автоматично вбудована у фреймворк. Після завершення сценарію ми зможемо отримувати результати та звіти по електронній пошті.
• Інтеграція: Framework Automation повинен бути таким, щоб його було легко інтегрувати з іншими програмами, такими як безперервна інтеграція або активація автоматизованого сценарію, як тільки розгортається збірка.

Q # 13) Чи можете ви обійтися без фреймворку?

Відповідь: Фреймворки - це керівні принципи, а не обов’язкові правила, тому ми можемо обійтися без фреймворку, але якщо ми створимо його та дотримуватимемось його, вдосконалення та підтримка буде легким у реалізації.

Q # 14) Які різні типи інструменту автоматизації вам відомі?

Відповідь: Інструмент з відкритим кодом, такий як Selenium, JMeter тощо.

Платні інструменти, такі як QTP, Load Runner, Ranorex, RFT та Rational Robot.

Q # 15) Якою є взагалі структура фреймворку?

Відповідь: Зазвичай структура повинна мати - (Це буде відрізнятися від проекту до проекту)

• Папка “src” (джерело), ​​що містить фактичні тестові сценарії.
• Папка ”lib” (бібліотека), що містить усі бібліотеки та загальні методи.
• Папка “class”, що містить весь файл класу (у випадку використання Java).
• Папка 'журнал', що містить файли журналу.
• Файл / папка, що містить усі ідентифікатори веб-елемента.
• Файл, що містить URL-адресу, середовище та дані для входу.

Q # 16) Де ви будете зберігати таку інформацію, як URL-адреса, логін, пароль?

Відповідь: Ця інформація завжди повинна зберігатися в окремому файлі.

Q # 17) Чому ви хочете зберігати подібну інформацію в окремому файлі, а не безпосередньо в коді?

Відповідь: URL-адреси, логін та паролі - це ті поля, які використовуються дуже часто, і вони змінюються відповідно до середовища та авторизації. У випадку, якщо ми жорстко закодуємо його в наш код, ми повинні змінити його у кожному файлі, на який є посилання.

Якщо файлів більше 100, то змінити всі 100 файлів стає дуже важко, а це, в свою чергу, може призвести до помилок. Отже, такий вид інформації зберігається в окремому файлі, щоб оновлення стало простим.

Q # 18) Які існують різні типи фреймворків?

Відповідь: Різні типи фреймворків включають:

• Фреймворк, керований ключовими словами
• Управління даними
• Гібридні рамки
• Лінійні сценарії

Q # 19) Чи можете ви розповісти кілька хороших практик кодування під час автоматизації?

Відповідь: Деякі хороші практики кодування включають:

• Додайте відповідні коментарі.
• Визначте методи багаторазового використання та запишіть їх в окремий файл.
• Дотримуйтесь мовних норм кодування.
• Зберігайте дані тесту в окремому файлі.
• Регулярно запускайте свої сценарії.

Q # 20) Будь-який тест, який, на вашу думку, не слід автоматизувати?

Відповідь:

• Тести, які виконуються рідко.
• Пошукові випробування
• Тестування юзабіліті
• Тест, який виконується швидко при ручному виконанні.

Q # 21) Ви вважаєте, що тестування можна проводити лише на рівні інтерфейсу користувача?

найкращий інструмент для створення блок-схеми

Відповідь: Сьогодні, коли ми переходимо до режиму Agile, тестування не обмежується рівнем інтерфейсу користувача. Ранні відгуки є імперськими для гнучкого проекту. Якщо ми концентруємось лише на рівні інтерфейсу користувача, ми фактично чекаємо, поки інтерфейс не буде розроблений і доступний для тестування.

Швидше ми можемо протестувати ще до того, як користувальницький інтерфейс насправді розроблений. Ми можемо безпосередньо протестувати API або методи, використовуючи такі інструменти, як Огірок та FitNesse .

Таким чином, ми надаємо зворотній зв’язок набагато раніше і тестуємо ще до того, як буде розроблений інтерфейс. Дотримання цього підходу допоможе нам протестувати лише аспект графічного інтерфейсу невеликих косметичних змін або деяких перевірок інтерфейсу користувача та допоможе розробникам, надавши більше часу на виправлення помилок.

Q # 22) Як вибрати, який інструмент автоматизації найкраще підходить для вас?

Відповідь: Вибір засобу автоматизації залежить від різних факторів, таких як:

• Сфера застосування, яку ми хочемо автоматизувати.
• Накладні витрати на управління, такі як витрати та бюджет.
• Час вивчити та впровадити інструмент.
• Тип опори, доступної для інструменту.
• Обмеження інструменту

Q # 23) Як ви думаєте, що стримує тестерів для автоматизації? Чи є спосіб її подолати?

Відповідь: Основна перешкода для тестувальників - навчитися програмуванню / кодуванню, коли вони хочуть автоматизувати. Оскільки тестери не кодують, адаптація до кодування є складною справою для тестувальників.

Ми можемо подолати це, виконавши:

• Співпраця з розробниками при автоматизації.
• Враховуючи, що за автоматизацію відповідає вся команда, а не лише тестувальники.
• Приділяючи присвячений час та зосередження на автоматизації.
• Отримання належної підтримки управління.

Ви можете зберегти ці запитання щодо тестування на автоматизацію у форматі PDF та роздрукувати для подальшого читання.

Питання # 24) Що таке структура тестування автоматизації?

Відповідь: Структура, загалом, є набором настанов. Набір керівних принципів, припущень, концепцій та практик кодування для створення середовища виконання, в якому тести будуть автоматизовані, відомий як система тестування автоматизації.

Структура автоматизації тестування відповідає за створення тестового джгута з механізмом для підключення до тестованої програми, отримання вхідних даних із файлу, виконання тестових випадків та формування звітів для виконання тесту. Структура автоматизації тестування повинна бути незалежною від програми, вона повинна бути простою у використанні, модифікації або розширенні.

Q # 25) Які важливі модулі системи тестування автоматизації?

Відповідь: Важливими модулями системи тестування автоматизації є:

1. Засіб перевірки твердження: Цей інструмент забезпечить твердження твердження для тестування очікуваних значень у додатку, що тестується. Наприклад. TestNG, Junit тощо.
2. Налаштування даних: Кожен тестовий випадок повинен брати дані користувача або з бази даних, або з файлу, або вбудований у тестовий скрипт. Модуль даних Frameworks повинен дбати про надходження даних для тестових скриптів та глобальних змінних.
3. Інструмент управління збіркою: Фреймворк потрібно створити та розгорнути для використання для створення тестових скриптів.
4. Інструмент безперервної інтеграції: З наявністю CICD (безперервна інтеграція та постійний розвиток) необхідний інструмент безперервної інтеграції для інтеграції та впровадження змін, внесених у структуру на кожній ітерації.
5. Інструмент звітування: Інструмент звітування потрібен для створення читабельного звіту після виконання тестових випадків для кращого огляду кроків, результатів та помилок.
6. Інструмент реєстрації: Інструмент реєстрації у фреймворку допомагає покращити налагодження помилок та помилок.

Q # 26) Поясніть деякі засоби автоматизації тестування.

Відповідь: Деякі з відомих засобів тестування автоматизації пояснюються нижче:

(i) Селен : Селен - це тестова основа для тестування автоматизації веб-додатків. Він підтримує кілька браузерів і не залежить від ОС. Селен також підтримує різні мови програмування, такі як Java, C #, PHP, Ruby та Perl тощо.

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

(ii) UFT : Єдине функціональне тестування - це ліцензований інструмент для функціонального тестування. Він надає широкий спектр функцій, таких як API, веб-сервіси тощо, а також підтримує безліч платформ, таких як настільні, веб- та мобільні. UFT-сценарії написані базовою мовою сценаріїв.

(Ii) епохи : Appium - це інструмент тестування мобільних додатків з відкритим кодом. Він використовується для автоматизації тестування на міжплатформенних, власних, гібридних та веб-мобільних додатках. Appium автоматизує будь-який мобільний додаток з будь-якої мови з повним доступом до API та БД із тестового коду.

Appium заснований на архітектурі клієнт-сервер і перетворився на селен.

(iv) Огірок : Огірок - це інструмент розробки, що керується поведінкою з відкритим кодом. Він використовується для веб-тестування автоматизації додатків і підтримує такі мови, як ruby, java, scala, groovy тощо. Огірок читає виконувану специфікацію, написану простим текстом, і тестує тестоване додаток на відповідність цим специфікаціям.

Щоб огірок розумів сценарії у простому тексті, ми повинні дотримуватися деяких основних правил синтаксису, які відомі як Геркін.

(v) TestComplete : TestComplete - це ліцензований автоматизований засіб тестування інтерфейсу користувача для тестування програми на різних платформах, таких як настільні комп'ютери, Інтернет, мобільні пристрої тощо. Він забезпечує гнучкість запису тестового кейсу в одному браузері та його запуску в декількох браузерах, і таким чином підтримує тестування між браузерами.

TestComplete має вбудований алгоритм розпізнавання об’єктів, який однозначно ідентифікує об’єкт і зберігає його у сховищі.

Q # 27) Які існують різні типи методів тестування?

Відповідь: Існує чотири типи методів автоматизації тестування.

Вони є:

(i) Модульна система тестування:

Ця основа побудована на концепції абстракції. У цій структурі тестер створює сценарії для кожного модуля програми, що тестується, окремо, а потім ці сценарії об'єднують в ієрархічному порядку для створення великих тестових кейсів.

Це створює абстракційний рівень між модулями, таким чином, будь-які зміни в тестових сценаріях для одного модуля не впливають на інші модулі.

Переваги цього фреймворку:

• Простіше обслуговування та масштабованість тестових кейсів.
• Створення тестових кейсів за допомогою вже скриптованих модулів простіше і швидше.

Недоліки:

• Тестові кейси мають вбудовані дані. Таким чином, виконання одного і того ж тестового сценарію з різними даними є великою зміною на рівні сценарію.

(ii) Структура тестування на основі даних:

У рамках тестування, керованого даними, вхідні дані та очікувані вихідні дані, що відповідають вхідним даним, зберігаються у файлі або базі даних, а автоматизований сценарій виконує однаковий набір тестових кроків для декількох наборів даних. За допомогою цього фреймворку ми можемо запускати кілька тестових випадків, коли відрізняються лише вхідні дані, а кроки виконання однакові.

Переваги:

• Зменшує кількість тестових сценаріїв, які потрібно виконати. Ми виконуємо один і той же сценарій кілька разів з різними даними.
• Менше кодування для автоматичного тестування.
• Більша гнучкість для утримання та виправлення помилок або розширення функціональних можливостей.
• Дані тесту можна створити ще до того, як автоматизована система для тестування буде готова.

Недоліки:

• Тільки подібні тестові випадки з однаковим набором кроків виконання можна комбінувати для декількох наборів даних. Різний набір кроків виконання вимагає іншого тесту.

(iii) Структура тестування на основі ключових слів:

Це незалежна від програми тестування, яка використовує таблиці даних та зрозумілі ключові слова. Ключові слова пояснюють дії, які слід виконати з тестованою програмою, а таблиця даних містить вхідні та очікувані вихідні дані.

Тестування на основі ключових слів - це збільшення тестування на основі даних.

Переваги:

• Менше кодування та один і той же сценарій можна використовувати для декількох наборів даних.
• Експертиза з автоматизації не потрібна для створення тестового кейсу з використанням уже існуючих ключових слів для дій.
• Ті самі ключові слова можна використовувати в декількох тестових випадках.

Недоліки:

• Цей фреймворк є більш складним, оскільки він повинен подбати про дії з ключовими словами, а також про введення даних.
• Тестові кейси стають довшими та складнішими, що впливає на ремонтопридатність.

(iv) Структура гібридного тестування:

Цей фреймворк є комбінацією всіх вищезазначених тестових фреймворків (модульних, керованих даними та керованих ключовими словами).

У цій структурі тестові кейси розробляються з модульних сценаріїв шляхом їх об'єднання в модульну структуру тестування. У кожному з тестових випадків використовується сценарій драйвера, який використовує файл даних, як у структурі, керованій даними, та файл дій на основі ключових слів.

Переваги:

• Модульний і простий в обслуговуванні.
• Менше кодування може подбати про більшу кількість тестів.
• Один тест може бути виконаний з кількома наборами даних.

Недоліки:

• Складний для читання, обслуговування та вдосконалення.

Q # 28) Коли ви віддаєте перевагу тестуванню вручну перед тестуванням автоматизації?

Відповідь: Ми надаємо перевагу ручному тестуванню перед автоматичним у наступних випадках:

• Проект короткотерміновий, і написання сценаріїв буде трудомістким та дорогим порівняно з ручним тестуванням.
• Потрібна гнучкість. Автоматизовані тестові кейси програмуються та виконуються у певний спосіб конфігурацій.
• Потрібно провести перевірку юзабіліті.
• Додаток / модуль нещодавно розроблений і не мав попередніх тестових кейсів.
• Потрібно провести спеціальне або дослідне випробування.

Q # 29) Корисне чи ні тестування автоматизації за допомогою гнучкої методології?

Відповідь: Тестування на автоматизацію корисно для тестування на регресію, задимлення чи осудність. Усі ці типи тестування в традиційній моделі водоспаду відбуваються в кінці циклу, і іноді, якщо в додатку не так багато вдосконалень, нам, можливо, навіть не доведеться робити регресійне тестування .

Тоді як, в спритна методологія , кожна ітерація вимагає виконання тесту регресії, оскільки додаються деякі нові функціональні можливості.

Крім того, сам пакет регресії продовжує зростати після кожного спринту, оскільки функціональні тестові приклади поточного модуля спринту потрібно додавати до пакету регресії для наступного спринту.

Таким чином, автоматичне тестування за гнучкою методологією є дуже корисним і допомагає досягти максимального охоплення тестом за менший час спринту.

Q # 30) Перелічіть деякі переваги та недоліки автоматичного тестування.

Відповідь:

Переваги:

• Менше людських ресурсів
• Багаторазове використання
• Більше тестового покриття за менший час
• Надійність
• Паралельне виконання тестових кейсів
• Швидко

Недоліки:

Як відкрити файл jar за допомогою Java у Windows 10

• Часу на розробку та обслуговування більше.
• Вартість інструменту
• Потрібні кваліфіковані ресурси.
• Налаштування середовища
• Проблема налагодження тестового сценарію.

Q # 31) Перелічіть деякі переваги та недоліки тестування вручну.

Відповідь:

Переваги:

• Налаштування середовища не потрібне.
• Знання програмування не потрібні.
• Рекомендовано для динамічно мінливих вимог.
• Дозвольте людині спостерігати, щоб виявляти більше помилок.
• Вартість менша для короткострокових проектів.
• Гнучкість

Недоліки:

• Важко виконати складні розрахунки.
• Багаторазове використання
• Зайняття часу
• Високий ризик людських помилок або помилок.
• Потрібно більше людських ресурсів.

Q # 32) Чи можемо ми провести тестування на автоматизацію без фреймворку? Якщо так, то навіщо нам потрібна структура?

Відповідь: Так, ми можемо проводити тестування автоматизації навіть без використання фреймворку. Ми можемо просто зрозуміти інструмент, який ми використовуємо для автоматизації, і програмувати кроки мовою програмування, яку підтримують інструменти.

Якщо ми автоматизуємо тестові кейси без фреймворку, то в сценаріях програмування тестових кейсів не буде жодної послідовності.

Структура необхідна, щоб дати набір настанов, яким повинен дотримуватися кожен, щоб зберегти читабельність, повторність та послідовність у тестових сценаріях. Структура також забезпечує одну загальну основу для функціонування звітності та реєстрації.

Q # 33) Як ви автоматизуєте основні тестові випадки функціональності 'входу' для програми?

Відповідь: Припускаючи, що інструмент автоматизації та фреймворк вже є на місці тестового середовища.

Щоб перевірити базову функціональність «Вхід»:

• Зрозумійте вимоги проекту : Функція входу матиме текстове поле для імені користувача, текстове поле для пароля та кнопку входу.
• Визначте сценарії тесту: Що стосується функцій входу, можливими сценаріями тестування є:
  • Пусті ім’я користувача та пароль
  • Недійсні ім’я користувача та пароль
  • Дійсне ім’я користувача та недійсний пароль
  • Дійсні ім’я користувача та пароль
• Підготуйте a Файл введення даних з даними, що відповідають кожному сценарію.
• Запустіть інструмент з програми.
• Визначте поле імені користувача, поле пароля та кнопку входу.
• Для кожного тестового сценарію отримайте дані з файлу даних і введіть у відповідні поля. Натисніть на кнопку входу в програму після введення даних.
• Перевірити повідомлення про помилку для негативних сценаріїв та повідомлення про успіх для позитивних сценаріїв у тестовому сценарії за допомогою тверджень.
• Біжи набір тестів і сформувати звіт.

Q # 34) Тестування автоматизації - тестування Black Box чи White-box?

Відповідь: Тестування автоматизації в основному є тестування чорної скриньки оскільки ми просто програмуємо кроки, які виконує ручний тестер для тестованого додатка, не знаючи низькорівневого дизайну або коду програми.

Іноді автоматизовані тестові сценарії потребують доступу до деталей бази даних, які використовуються в тестованому додатку, або деяких інших деталей кодування, і, отже, можуть бути різновидом тестування білих скриньок.

Таким чином, автоматизоване тестування може бути як чорним, так і білим тестом залежно від сценаріїв, в яких виконується автоматизація.

Q # 35) Скільки тестів ви автоматизували на день?

Відповідь: Ну, кількість залежить від складності тестів. Коли складність була обмеженою, я зміг автоматизувати від 5 до 6 тестових випадків на день. Іноді мені вдавалося автоматизувати лише один тест для складних сценаріїв.

Я також розбив свої тестові приклади на різні компоненти, такі як, беруть введення, роблять обчислення, перевіряють результати тощо у випадку дуже складних сценаріїв і займають 2 і більше днів.

Q # 36) Які фактори визначають ефективність тестування автоматизації?

Відповідь: Деякі фактори, що визначають ефективність автоматичного тестування:

• Заощаджений час, запускаючи скрипти за допомогою ручного виконання тестових кейсів.
• Виявлені дефекти
• Тест покриття або покриття коду
• Час обслуговування або час розробки
• Стійкість сценаріїв
• Тест багаторазового використання
• Якість програмного забезпечення, що тестується

Q # 37) Які тестові кейси можна автоматизувати?

Відповідь: Типи тестових кейсів, які можна автоматизувати:

(i) Випробування на дим: Тестування на дим також відоме як тестування на перевірку конструкції. Тести на дим запускаються кожного разу, коли випускається нова збірка, щоб перевірити працездатність збірки на прийняття для проведення тестування.

(ii) Випробування на регресію : Регресійне тестування - це тестування для забезпечення того, щоб раніше розроблені модулі працювали належним чином після додавання нового модуля або виправлення помилки.

Регресійні тестові випадки дуже важливі при поступовому програмному підході, коли на кожній фазі збільшення додається нова функціональність. У цьому випадку регресійне тестування проводиться на кожній додатковій фазі.

(iii) Складні обчислювальні тести: Тестові випадки, що передбачають складні обчислення для перевірки поля для програми, належать до цієї категорії. Складні результати розрахунків більш схильні до людських помилок, отже, коли вони автоматизовані, вони дають точні результати.

(iv) Тестові випадки, керовані даними: Тестові кейси, що мають однаковий набір кроків і виконуються кілька разів із зміною даних, відомі як тестові кейси, керовані даними. Автоматизоване тестування для таких видів тестів є швидким та економічним.

(v) Нефункціональні кейси : Тестові випадки, такі як навантаження та тести продуктивності, вимагають змодельованого середовища з кількома користувачами та кількома комбінаціями апаратного чи програмного забезпечення.

Налаштування декількох середовищ вручну неможливе для кожної комбінації або кількості користувачів. Автоматизовані інструменти можуть легко створити це середовище для простого проведення нефункціонального тестування.

Q # 38) Назвіть етапи життєвого циклу автоматичного тестування?

Відповідь: Фази життєвого циклу тестування автоматизації включають:

1. Рішення про тестування автоматизації.
2. Визначте та дізнайтеся про інструмент автоматизації.
3. Визначте обсяг автоматизованого тестування.
4. Спроектуйте та розробіть набір тестів.
5. Виконання тесту
6. Обслуговування тестових скриптів.

Q # 39) Що таке автоматизований тестовий скрипт?

Відповідь: Автоматизований тестовий сценарій - це коротка програма, яка написана мовою програмування для виконання набору інструкцій у тестованій програмі, щоб перевірити, чи відповідає заявка вимогам.

Ця програма під час запуску надає результати тесту як успішні або не залежать від того, чи відповідає програма очікуванням.

Висновок

Це основні питання, які не залежать від інструменту автоматизації або мови програмування. Інтерв’ю для автоматичного тестування також включає запитання щодо інструментів та мови програмування залежно від інструменту, з яким ви працювали.

Більшість запитань щодо автоматизації тестування зосереджені на структурі, яку ви розробляєте, тому рекомендується створити та зрозуміти свою тестову структуру. Коли я беру інтерв’ю, і кандидат відповідає на моє запитання в рамках, я також вважаю за краще задавати мовне запитання (основна Java у моєму випадку).

Запитання починаються з основ Java, щоб написати логіку деяких базових сценаріїв, таких як:

• Як би ви видобули набір тексту із заданого рядка?
• Як би ви видобули URL-адресу?
• На будь-якій веб-сторінці в будь-якому кадрі кількість посилань та їх вміст динамічно змінюються, як би ви з цим впоралися?
• Як ви обробляєте зображення та об'єкти, що спалахують?
• Як знайти слово в рядку?

Відповіді на все це питання автоматизації тестування інтерв’ю дуже характерні для інструменту / мови, який ви використовуєте для автоматизації. Тож перед тим, як піти на співбесіду, підробіть свої навички програмування.

Якщо у вас не було можливості створити свій фреймворк, а хтось інший створив його, то виділіть трохи часу, щоб добре його зрозуміти, перш ніж сідати на співбесіду.

Декілька порад для автоматичного тестування співбесід:

• Досконально знай свій інструмент.
• Вивчіть методи локатора, що використовуються вашим інструментом.
• Практикуйте програмування, використовуючи мову, яку ви використовуєте для тестування автоматизації.
• Вивчіть свій фреймворк та його компоненти.
• Завжди вигідно, якщо ви брали участь у розробці вашого фреймворку. Тож будьте ретельні з модулями в рамках, над якими ви працювали.

Сподіваюся, ці питання будуть корисними для вас для підготовки до співбесіди з автоматизації тестів.

Рекомендована література

• Запитання та відповіді на інтерв’ю
• Запитання та відповіді на інтерв’ю для тестування ETL
• Деякі цікаві запитання щодо тестування програмного забезпечення
• 25 найкращих запитань та відповідей на інтерв’ю для спритного тестування
• 20 найважливіших запитань та відповідей на тестування API
• Запитання та відповіді на тестування програмного забезпечення (Частина 1)
• Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
• 30 найкращих запитань та відповідей на тестування безпеки