what is automation testing
Повне керівництво для початку тестування автоматизації на вашому проекті:
Що таке автоматичне тестування?
Тестування автоматизації - це техніка тестування програмного забезпечення для перевірки та порівняння фактичного результату з очікуваним результатом. Цього можна досягти, написавши тестові сценарії або використовуючи будь-який інструмент автоматизації тестування. Автоматизація тестів використовується для автоматизації повторюваних завдань та інших завдань тестування, які важко виконати вручну.
Ви хочете розпочати тест автоматизації на своєму проекті, але чи боретесь ви з найосновнішими кроками, як зазначено нижче:
- Як ввести автоматизацію у свій проект?
- Як вибрати найкращий і правильний інструмент автоматизації?
- Як ефективно розробляти сценарії?
- Як виконувати та підтримувати тестові сценарії?
- І нарешті, які найкращі практики потрібно дотримуватися для успішного тестування автоматизації?
Сьогодні ми планували збагатити ваші знання серією навчальних посібників на тему “ Початок роботи з тестуванням автоматизації '. Ця серія навчальних посібників з автоматизації дасть покрокові відповіді на всі вищезазначені запитання на простих прикладах.
Давайте подивимось на серію навчальних посібників з запуску автоматизації на вашому проекті !!
Наскрізний процес автоматизації:
Підручник No1 : Кращий посібник із запуску автоматизації на вашому проекті
Підручник No2: Типи автоматизованих тестів та деякі помилки
Підручник No3: 10 кроків для впровадження автоматизації у ваш проект
Підручник No4: Посібник від A до Z щодо вибору найкращого інструменту автоматизації
Підручник No5: Структура розробки та автоматизації
Підручник No6: Виконання та звітування про автоматизацію
Підручник No7: Кращі практики та стратегії автоматизації тестів
Поради щодо автоматизації:
Підручник No8: 10 порад, які слід прочитати перед автоматизацією роботи з тестування
Підручник No9: Чим відрізняється планування тестів для проектів, що проводяться вручну та автоматизацією
Підручник No10: Коли обирати автоматизацію?
Підручник No11: Випробування автоматизації
Підручник No12: Посібник із впровадження доказової концепції (POC) в автоматизації
Підручник No 13: Як вибрати правильні тестові випадки для автоматизації
Підручник No14: Як перевести випадки ручного тестування на сценарії автоматизації
Кар'єра автоматизації:
Підручник No15: Поради, як стати кращим тестувальником автоматизації
Підручник No16: Автоматизація тестів - це спеціалізована кар’єра? Чи можуть звичайні тестери також робити автоматизацію?
Популярні засоби автоматизації:
Підручник No17: Підручники з селену 31+ Найкращі безкоштовні навчальні посібники з селену
Підручник No18: Підручники з QTP
Підручник No 19: Інструмент тестування веб-служб SoapUI
Підручник No20: HP LoadRunner для тестування продуктивності
Структури автоматизації:
Підручник No21: Навіщо нам потрібні рамки для автоматизації
Підручник No22: Найпопулярніші рамки автоматизації
Автоматизація в Agile:
Підручник No23: Як впровадити ефективну автоматизацію в Agile World
Інші засоби автоматизації:
Підручник No24: Кращі засоби автоматизації тестування
Підручник No25: Інструмент автоматизації графічного інтерфейсу Sikuli
Підручник No26: PowerShell: Автоматизація інтерфейсу настільних додатків за допомогою PowerShell
Підручник No27: Catalon Automation Recorder (селена IDE-альтернатива)
Підручник No28: Geb Tool: Автоматизація браузера за допомогою Geb Tool
Підручник No 29: AutoIt: Як обробляти спливаючі вікна Windows за допомогою AutoIt
Підручник No30: Огірок: автоматизація за допомогою інструменту огірка та селену
Підручник No31: Інструмент тестування транспортира для наскрізного тестування програм AngularJS
Тестування мобільної автоматизації:
Підручник No 32: Appium Studio Посібник
Підручник No 33: Підручник Appium для початківців
Підручник No 34: Підручник Selendroid: Android Mobile Automation Framework
Підручник No35: Підручник з Ranorex: Потужний інструмент для тестування настільних комп’ютерів, Інтернету та мобільних пристроїв
Приклади автоматизації конкретних доменів:
Підручник No 36: Автоматизація програм JAVA / J2EE
Підготовка до співбесіди для роботи з автоматизації:
Підручник # 37: Питання інтерв’ю для автоматизації тестування
Підручник No 38: Запитання щодо інтерв’ю селену
Давайте вивчимо перший підручник із серії 'Остаточний посібник з тестування автоматизації' !!
Що ви дізнаєтесь:
- Що таке автоматичне тестування?
- Автоматизація - економічно ефективний метод регресійного тестування
- Сценарії, які вимагають автоматизації
- Правильні тести для автоматизації
- Чого НЕ автоматизувати?
- Простий приклад автоматизації тестів
- Що таке твердження?
- Висновок
- Рекомендована література
Що таке автоматичне тестування?
Якщо тоді програмне забезпечення може щось зробити, чому програмне забезпечення не може протестувати програмне забезпечення?
Чи звучить для вас це твердження логічним?
Якщо так, тоді вітаємо, ви зараз думаєте про автоматизацію тестів, яка є центральним пунктом, який ми будемо обговорювати в цій серії інформативних посібників.
Уявіть себе першим днем на роботі в якості SQA. Вам представлена заявка на тестування. Це ERP-програма, що містить 100 форм і тисячі звітів. Ви починаєте своє пошукове тестування, відкриваючи форму, яка містить близько 50 різних полів.
Ви намагаєтеся ввести випадкові дані у цій формі, що зайняло близько 20 хвилин. Потім ти натискаєш подати. Волла !! З'являється повідомлення про помилку, яке виглядає як необроблений виняток. Ти стаєш дуже щасливим. Ви з гордістю записуєте кроки та повідомляєте про помилку у вашій системі управління помилками. Великі зусилля, ви почуваєтесь по-справжньому впевнено та енергійно. Ви продовжуєте тестування, поки день не закінчиться, і знайдете ще кілька помилок. “Дивовижний перший день”, - подумали ви.
Тепер настає наступний день, розробник виправив проблему та випустив нову версію збірки. Ви тестуєте ту саму форму з однаковими кроками, і виявили, що помилка виправлена. Ви позначаєте це виправленим. Велике зусилля. Ви зробили внесок у якість продукту, виявивши цю помилку, і, коли ця помилка виправлена, якість покращується.
Тепер настає третій день, розробник знову випустив нову версію. Тепер вам знову доведеться протестувати цю форму, щоб переконатися, що жодної проблеми регресії не знайдено. Ті самі 20 хвилин. Тепер ти почуваєшся трохи нудно.
А тепер уявіть, що через місяць після цього постійно виходять нові версії, і при кожному випуску вам доведеться тестувати цю тривалу форму та ще 100 таких форм, лише щоб переконатися, що регресії немає.
Тепер ти відчуваєш злість. Ви відчуваєте втому . Ви починаєте пропускати кроки. Ви заповнюєте лише 50% від загальної кількості полів. Ваша точність не однакова, енергія не однакова, і точно ваші кроки не однакові.
І одного разу клієнт повідомляє про ту ж помилку в тій же формі. Ви відчуваєте жалюгідність. Зараз ти почуваєшся невпевнено. Ви вважаєте, що недостатньо компетентні. Менеджери ставлять під сумнів ваші здібності.
У мене для вас новина; це історія 90% ручних тестувальників. Ви не різні.
Проблеми регресії - найболючіші проблеми. Ми люди. І ми не можемо робити одне і те ж з однаковою енергією, швидкістю та точністю щодня. Це те, що роблять машини. Для цього необхідна автоматизація, щоб повторити ті самі кроки з тією ж швидкістю, точністю та енергією, що і повторені вперше.
Сподіваюся, ви зрозуміли мою думку !!
Щоразу, коли виникає така ситуація, вам слід автоматизувати свій тест. Автоматизація тестів - ваш друг . Це допоможе вам зосередитись на нових функціональних можливостях, доглядаючи за регресіями. Завдяки автоматизації ви можете заповнити цю форму менш ніж за 3 хвилини.
Сценарій заповнить усі поля і повідомить вам результат разом із скріншотами. У разі відмови він може точно визначити місце, де тест не вдався, і таким чином допоможе вам легко його відтворити.
Автоматизація - економічно ефективний метод регресійного тестування
Спочатку витрати на автоматизацію дійсно вищі. Вона включає вартість інструменту, потім вартість ресурсу для автоматизації тестування та його / її навчання.
Але коли сценарії готові, їх можна виконувати сотні разів неодноразово з однаковою точністю і досить швидко. Це заощадить багато годин ручного тестування. Тож вартість поступово зменшується, і в кінцевому рахунку це стає економічно ефективним методом для Регресійне тестування .
найкращі сервери для гри на вау
Сценарії, які вимагають автоматизації
Вищевказаний сценарій - не єдиний випадок, коли вам знадобиться тестування автоматизації. Є кілька ситуацій, які неможливо перевірити вручну.
Наприклад ,
- Порівняння двох зображень піксель за пікселем.
- Порівняння двох електронних таблиць, що містять тисячі рядків і стовпців.
- Тестування програми під навантаженням 100 000 користувачів.
- Тести ефективності.
- Тестування програми в різних браузерах і паралельно на різних операційних системах.
Ці ситуації вимагають і повинні перевірятися інструментами.
Отже, коли автоматизувати?
Це епоха Росії спритна методологія в SDLC, де розробка та тестування йтимуть майже паралельно, і дуже важко вирішити, коли автоматизувати.
Розгляньте наступні ситуації, перш ніж переходити до автоматизації
- Продукт може знаходитись на початковій стадії, коли у продукту навіть немає інтерфейсу користувача, на цих етапах ми повинні чітко продумати, що ми хочемо автоматизувати. Слід пам’ятати наступні моменти.
- Тести не повинні бути застарілими.
- По мірі того, як продукт розвивається, слід легко вибрати сценарії та додати до них.
- Дуже важливо не захоплюватися і переконатися, що сценарії легко налагоджувати.
- Не намагайтеся автоматизувати інтерфейс користувача на самих початкових етапах, оскільки користувальницький інтерфейс піддається частим змінам, що призведе до відмови сценаріїв. Наскільки це можливо, вибирайте автоматизацію рівня API / Non UI, поки продукт не стабілізується. Автоматизацію API легко виправити та налагодити.
Як визначити найкращі випадки автоматизації:
Автоматизація є невід’ємною частиною тестового циклу, і дуже важливо вирішити, чого ми хочемо досягти за допомогою автоматизації, перш ніж ми вирішимо автоматизувати.
Переваги, які, схоже, забезпечує автоматизація, є дуже привабливими, але в той же час неправильно організований набір автоматизації може зіпсувати всю гру. Більшість часу тестувальники можуть закінчити налагодження та виправлення сценаріїв, що призведе до втрати часу на тестування.
Ця серія розповідає вам про те, як набір автоматизації можна зробити досить ефективним, щоб підібрати правильні кейси тестів і дати правильні результати за допомогою наявних у нас сценаріїв автоматизації.
Крім того, я розглянув відповіді на запитання, наприклад, коли автоматизувати, що автоматизувати, що не автоматизувати та як розробити стратегію автоматизації.
Правильні тести для автоматизації
Найкращий спосіб вирішити цю проблему - швидко розробити 'Стратегію автоматизації', яка відповідає нашому продукту.
Ідея полягає в тому, щоб згрупувати тестові кейси так, щоб кожна група давала нам різного роду результати. Ілюстрація, наведена нижче, показує, як ми могли б згрупувати наші подібні тестові приклади, залежно від продукту / рішення, який ми тестуємо.
Давайте зараз глибоко зануримось і зрозуміємо, чого кожна група може допомогти нам досягти:
# 1) Складіть набір тестів усіх основних функціональних можливостей Позитивні тести . Цей набір повинен бути автоматизований, і коли цей набір запускається проти будь-якої збірки, результати відображаються негайно. Будь-який сценарій, який не працює в цьому наборі, призводить до дефекту S1 або S2, і ця специфіка може бути дискваліфікована. Тож ми заощадили тут багато часу.
Як додатковий крок ми можемо додати цей автоматизований набір тестів як частину BVT (тести перевірки збірки) і перевірити сценарії автоматизації контролю якості в процесі створення продукту. Тож, коли збірка готова, тестери можуть перевірити результати тестування автоматизації та вирішити, чи підходить збірка для встановлення та подальшого процесу тестування.
Це однозначно досягає цілей автоматизації, які:
- Зменшіть зусилля для тестування.
- Знайдіть помилок на попередніх етапах.
# два) Далі у нас є група Наскрізні тести .
За великих рішень тестування наскрізної функціональності має ключове значення, особливо на критичних етапах проекту. У нас повинно бути кілька сценаріїв автоматизації, які також стосуються наскрізних тестів рішення. Коли цей пакет запущений, результат повинен вказувати, чи працює продукт у цілому належним чином чи ні.
Слід вказати набір тестів автоматизації, якщо якийсь із елементів інтеграції порушений. Цей набір не повинен охоплювати кожну дрібну функцію / функціональність рішення, але він повинен охоплювати роботу продукту в цілому. Всякий раз, коли ми маємо альфа-версію, бета-версію або будь-які інші проміжні випуски, тоді такі сценарії стають в нагоді та надають певний рівень довіри клієнту.
Щоб краще зрозуміти, припустимо, що ми тестуємо Інтернет-портал покупок , як частина наскрізних тестів ми повинні охоплювати лише ключові задіяні етапи.
Як подано нижче:
- Вхід користувача.
- Переглядайте та вибирайте елементи.
- Варіант оплати - це стосується випробувальних тестів.
- Управління внутрішніми замовленнями (включає спілкування з кількома інтегрованими партнерами, перевірку запасів, надсилання електронної пошти користувачеві тощо) - це допоможе перевірити інтеграцію окремих частин, а також суть продукту.
Отже, коли запускається один такий сценарій, це дає впевненість, що рішення в цілому працює нормально.!
# 3) Третій набір - Тести на основі функціональних можливостей / функціональності .
Для приклад , Ми можемо мати функціонал для перегляду та вибору файлу, тому, коли ми автоматизуємо це, ми можемо автоматизувати випадки, включаючи вибір різних типів файлів, розмірів файлів тощо, щоб тестування функцій було зроблено. У разі будь-яких змін / доповнень до цієї функціональності цей набір може служити набором регресії.
# 4) Наступним у списку буде Тести на основі інтерфейсу користувача. Ми можемо запропонувати інший набір, який буде перевіряти функціональні можливості, засновані на чистому інтерфейсі, такі як пагінація, обмеження символів текстового поля, кнопка календаря, спадні меню, графіки, зображення та багато таких функцій, орієнтованих лише на інтерфейс. Помилка цих сценаріїв, як правило, не дуже критична, якщо користувальницький інтерфейс повністю не працює або певні сторінки не відображаються належним чином!
# 5) Ми можемо мати ще один набір тестів, які прості, але дуже копіткі для проведення вручну. Струмливі, але прості тести є ідеальними кандидатами для автоматизації, наприклад, введення даних про 1000 клієнтів у базу даних має просту функціональність, але надзвичайно нудно проводити вручну, такі тести повинні бути автоматизовані. Якщо ні, то здебільшого їх ігнорують і не тестують.
Чого НЕ автоматизувати?
Нижче наведено декілька тестів, які не слід автоматизувати.
# 1) Негативні тести / тести на відмову
Ми не повинні намагатися автоматизувати негативні або відмовостійкі тести , оскільки для цих тестів тестувальникам потрібно думати аналітично, і негативні тести насправді не є простими, щоб дати результат успішного або невдалого результату, який може нам допомогти.
Негативні тести потребуватимуть багато ручного втручання, щоб імітувати фактичний сценарій відновлення після аварії. Тільки для прикладу ми тестуємо такі функції, як надійність веб-служб, - щоб узагальнити її тут, основною метою таких тестів було б спричинити навмисні збої та побачити, наскільки продукт вдається бути надійним.
Моделювання вищевказаних несправностей не є простим, це може включати впорскування деяких заглушок або використання деяких інструментів між ними, і автоматизація не найкращий спосіб піти сюди.
# 2) Спеціальні тести
Ці випробування можуть не бути релевантними для продукту в будь-який час, і це може бути навіть те, про що тестер міг би подумати на тому етапі ініціювання проекту, а також зусилля з автоматизації спеціального тесту повинні бути перевірені щодо критичності функції, якої торкаються тести.
Наприклад , Тестер, який тестує функцію, яка займається стисненням / шифруванням даних, міг проводити інтенсивні спеціальні тести з різноманітністю даних, типами файлів, розмірами файлів, пошкодженими даними, комбінацією даних, використовуючи різні алгоритми, у декількох платформи тощо
Коли ми плануємо автоматизація ми можемо захотіти розставити пріоритети та не виконувати вичерпну автоматизацію всіх спеціальних тестів лише для цієї функції, і в кінцевому підсумку у нас буде трохи часу для автоматизації інших ключових функцій.
# 3) Тести з масовою попередньою установкою
Існують тести, які вимагають величезних передумов.
Наприклад, Ми можемо мати продукт, який інтегрується зі стороннім програмним забезпеченням для деяких функцій, оскільки продукт інтегрується з будь-якою системою черги обміну повідомленнями, яка вимагає встановлення в системі, налаштування черг, створення черг тощо.
3рдсторонне програмне забезпечення може бути чим завгодно, і налаштування може бути складним за своєю суттю, і якщо такі сценарії автоматизуються, то вони назавжди залежатимуть від функцій / налаштувань цього стороннього програмного забезпечення.
Передумова включає:
В даний час все може виглядати просто і чисто, оскільки обидва бокові налаштування виконуються, і все в порядку. Ми неодноразово спостерігали, що коли проект входить у фазу обслуговування, проект переходить до іншої команди, і вони в кінцевому підсумку відладжують такі скрипти, де фактичний тест дуже простий, але сценарій не вдається через 3рдпроблема партійного програмного забезпечення.
Вищезазначене є лише прикладом, загалом, слідкуйте за тестами, які мають копіткі попередні налаштування для простого тестування, яке слід.
Простий приклад автоматизації тестів
Коли ви тестуєте програмне забезпечення (в Інтернеті або на робочому столі), ви зазвичай використовуєте мишу та клавіатуру для виконання своїх кроків. Засіб автоматизації імітує ті самі кроки, використовуючи сценарії або мову програмування.
Наприклад , якщо ви тестуєте калькулятор, а тестом є те, що вам потрібно додати два числа і побачити результат. Скрипт виконуватиме ті самі дії, використовуючи мишу та клавіатуру.
Приклад наведено нижче.
Кроки ручного тестування:
- Запуск калькулятора
- Натисніть 2
- Натисніть +
- Натисніть 3
- Натисніть =
- На екрані повинно відображатися 5.
- Закрити калькулятор.
Сценарій автоматизації:
//the example is written in MS Coded UI using c# language. [TestMethod] public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }
Вищезазначений сценарій - це лише копія кроків, здійснених вручну. Сценарій легко створити, а також легко зрозуміти.
Що таке твердження?
Другий останній рядок сценарію потребує додаткових пояснень.
Assert.AreEqual (“5”, txtResult.DisplayText, ”Калькулятор не відображає 5);
У кожному тестовому випадку ми маємо якийсь очікуваний або передбачуваний результат наприкінці. У наведеному вище сценарії ми сподіваємось, що на екрані має відображатися „5”. Фактичний результат - це результат, який відображається на екрані. У кожному тестовому випадку ми порівнюємо очікуваний результат із фактичним результатом.
Те саме стосується і тестування автоматизації. Єдина різниця тут полягає в тому, що коли ми робимо це порівняння в автоматизації тестів, тоді це називається дещо іншим у кожному інструменті.
Деякі інструменти називають це ' Твердження ', Деякі називають це як' контрольно-пропускний пункт ', А деякі називають це' перевірка '. Але в основному це лише порівняння. Якщо це порівняння не вдається, для Наприклад на екрані відображається 15 замість 5, тоді це твердження / контрольна точка / перевірка не вдається, і ваш тестовий випадок позначений як невдалий.
Коли тестовий випадок не вдається через твердження, це означає, що ви виявили помилку за допомогою автоматизації тесту. Ви повинні повідомити про це у свою систему управління помилками, як зазвичай це робиться при ручному тестуванні.
У наведеному вище сценарії ми виконали твердження у другому останньому рядку. 5 - очікуваний результат, txtResult . DisplayText є фактичним результатом, і якщо вони не рівні, нам покажуть повідомлення «Калькулятор не показує 5».
Висновок
Часто тестери стикаються з термінами та мандатами проектів для автоматизації всіх справ для покращення оцінок тестування.
Існує кілька поширених 'неправильних' уявлень про автоматизацію.
Вони є:
- Ми можемо автоматизувати кожен тест.
- Автоматизація тестів значно зменшить час тестування.
- Якщо сценарії автоматизації працюють безперебійно, помилок не виникає.
Ми повинні чітко усвідомлювати, що автоматизація може скоротити час тестування лише для певних типів тестів. Автоматизація всіх тестів без будь-якого плану чи послідовності призведе до масивних сценаріїв, які потребують серйозного обслуговування, часто виходять з ладу і потребують багато ручного втручання. Крім того, у продуктах, що постійно розвиваються, сценарії автоматизації можуть застаріти і потребуватимуть постійних перевірок.
Групування та автоматизація правильних кандидатів заощадить багато часу та надасть усі переваги автоматизації.
Цей чудовий підручник можна узагальнити лише за 7 пунктів.
Тестування автоматизації:
- Це тестування, яке проводиться програмно.
- Використовує інструмент для контролю виконання тестів.
- Порівнює очікувані результати з фактичними результатами (твердження).
- Може автоматизувати деякі повторювані, але необхідні завдання ( Наприклад Ваші регресійні тести).
- Може автоматизувати деякі завдання, які важко зробити вручну (НаприкладСценарії тестування навантаження).
- Скрипти можуть працювати швидко і багаторазово.
- Є економічно вигідним у довгостроковій перспективі.
Тут автоматизація пояснюється простими словами, але це не означає, що це завжди просто зробити. У цьому є проблеми, ризики та багато інших перешкод. Існує безліч способів, за допомогою яких автоматизація тестів може піти не так, але якщо все буде добре, то переваги автоматизації тестів дійсно величезні.
Найближчі в цій серії:
У наших майбутніх підручниках ми обговоримо кілька аспектів, пов'язаних з автоматизацією.
До них належать:
- Типи автоматизованих тестів та деякі помилки.
- Як запровадити автоматизацію у вашій організації та уникнути загальних підводних каменів під час автоматизації тестів.
- Процес вибору інструменту та порівняння різних засобів автоматизації.
- Структура розробки сценаріїв та автоматизації з прикладами.
- Виконання та звітування про автоматизацію тестів.
- Кращі практики та стратегії автоматизації тестів.
Ви хочете дізнатись більше про кожну концепцію автоматичного тестування? Слідкуйте і стежте за нашим списком майбутніх підручників у цій серії та сміливо висловлюйте свої думки в розділі коментарів нижче.
Рекомендована література
- 10-етапний процес тестування автоматизації: як розпочати тестування автоматизації у своїй організації
- Підручник Geb - Тестування автоматизації браузера за допомогою інструмента Geb
- Інструмент тестування автоматичного графічного інтерфейсу користувача Sikuli - Посібник для початківців, Частина 2
- Покрокове керівництво по впровадженню доказів концепції (POC) у тестуванні автоматизації
- Найкращі засоби тестування програмного забезпечення 2021 р. [Інструменти автоматизації тестування якості]
- Чи втрачають тестери контроль над тестуванням через автоматизацію?
- Проблеми, пов'язані з ручним та автоматичним тестуванням
- 10 порад, які слід прочитати перед автоматизацією роботи з тестування