Види та інструменти автоматизації
Одним із найчастіших питань новачків в автоматизації є питання про те, яку мову програмування вибрати для вивчення, а також який інструмент краще. Ці питання насправді варто розглядати в іншій площині, а мова програмування є наслідком, а не причиною (а десь взагалі не потрібна).
При всій різноманітності того, що можна вважати автоматизацією, можна спробувати виділити категорії:
Функціональне чи дисфункційне тестування;
рівні: unit, integration, UI/E2E;
Метод: white box; black box;
Рівень мережної моделі: frontend, backend, database;
Платформи: desktop, мобільний, web, cross platform;
ОС: windows, macos, linux, cross platform;
Масштабованість: однопотокові, багатопотокові;
Програма, скрипт, фреймворк чи бібліотека;
Робота безпосередньо з тестами як допоміжний засіб (генератори даних), інфраструктура (CI/CD, раннери, звітність);
Якщо це створення тестів, то яким чином: нативна мова програмування, універсальна ЯП, тестова модель та ключові слова, рекордери (Capture & Playback);
і т.д. і т.п. до нескінченності.
Кожен інструмент створений і підходить для певних завдань і поєднує кілька таких критеріїв. Саме тому немає кращого інструменту та єдино правильної мови програмування для старту.
Технології автоматизації тестування
Почнемо з короткого огляду еволюції високорівневих технологій, при цьому наголосивши, що «старі» рішення, як і раніше, використовуються (або як компоненти «нових», чи самостійно в окремих випадках).
Підхід
Суть
Переваги
Недоліки
1
Приватні рішення
Для вирішення кожної
окремого завдання
пишеться окрема
програма
Швидко, просто
Немає системності,
багато часу йде на підтримку.
Майже неможливо
повторне використання
2
Тестування під
управлінням даними (DDT)
З тест-кейсу зовні
виносяться вхідні
дані та очікувані результати.
Один і той же тест кейс можна повторювати багато разів з
різними даними
Логіка тест-кейсу, як і раніше, суворо
визначається
всередині, а тому для
її зміни тест кейс треба переписувати
3
Тестування під
керуванням ключовими словами (KDT)
З тест-кейсу зовні
виноситься опис
його поведінки
Концентрація на високорівневих процесах. Дані та
особливості поведінки зберігаються назовні та
можуть бути змінені
без зміни коду
тест-кейсу
Складність виконання низькорівневих
операцій
4
Використання
фреймворків
Конструктор, що дозволяє використовувати інші підходи
Потужність та гнучкість
Відносна
складність (особливо
- у створенні
фреймворку)
5
Запис та відтворення (Record & Playback)
Засіб автоматизації записує
дії тестувальника та може відтворити їх,
керуючи тестованим додатком
Простота, висока
швидкість створення
тест-кейсів.
Вкрай низька якість, лінійність, непідтримуваність
тест-кейсів. Потрібна серйозна доробка отриманого
коду
6
Тестування під
управлінням поведінкою (BDT)
Розвиток ідей тестування під керуванням даними та
ключовими словами.
Відмінність – у концентрації на бізнес сценаріях без виконання дрібних
перевірок
Висока зручність
перевірки високорівневих користувальницьких сценаріїв
Такі тест-кейси
пропускають велике
кількість функціональних та нефункціональних дефектів,
а тому повинні
бути доповнені
класичними більш низькорівневими тест-кейсами
На поточному етапі розвитку тестування представлені у таблиці технології ієрархічно можна зобразити наступною схемою:
Технології: Приватні рішення
Іноді перед тестувальником виникає унікальна (у тому плані, що такої більше не буде) завдання, для вирішення якої немає необхідності використовувати потужні інструментальні засоби, а достатньо написати невелику програму будь-якою з високорівневих мов програмування (Java, C#, PHP тощо). ) або навіть скористатися можливостями командних файлів операційної системи або подібними до тривіальних рішень. Також сюди можна віднести завдання виду:
Підготувати базу даних, наповнивши її тестовими даними (наприклад, додати до системи мільйон користувачів із випадковими іменами).
Підготувати файлову систему (наприклад, створити структуру каталогів та набір файлів для виконання тест-кейсів).
Перезапустити набір серверів та/або привести їх у потрібний стан.
Зручність приватних рішень полягає в тому, що їх можна реалізувати швидко, просто, «ось зараз». Але у них є й величезний недолік - це «кустарні рішення», якими може скористатися лише пара людей. І при появі нового завдання, навіть дуже схожого на раніше вирішене, швидше за все, доведеться все автоматизувати заново.
Переваги:
Швидкість та простота реалізації;
Можливість використання будь-яких доступних інструментів, якими тестувальник може користуватися;
Ефект від використання настає негайно;
Можливість знаходження дуже ефективних рішень у разі, коли основні інструменти, які використовуються на проекті для автоматизації тестування, виявляються малопридатними для виконання окремого завдання;
Можливість швидкого створення та оцінки прототипів перед застосуванням більш важких рішень
Недоліки:
Відсутність універсальності і, як наслідок, неможливість чи крайня складність повторного використання (адаптації на вирішення інших завдань).
Розрізненість та неузгодженість рішень між собою (різні підходи, технології, інструменти, принципи вирішення).
Вкрай висока складність розвитку, підтримки та супроводу таких рішень (найчастіше, крім самого автора ніхто взагалі не розуміє, що і навіщо було зроблено, і як воно працює).
Є ознакою «кустарного виробництва», що не вітається у промисловій розробці програм.
Технології: Тестування під керуванням даними (DDT)
Зверніть увагу, як багато разів у командних файлах повторюються рядки, що виконують одну і ту ж дію над набором файлів (і нам ще пощастило, що файлів небагато). Адже набагато логічніше було б якимось чином підготувати список файлів і просто передати його на обробку. Це буде тестуванням під управлінням даними. Тепер нам достатньо підготувати CSV-файл з будь-якою кількістю імен файлів, що порівнюються, а код тест-кейсу не збільшиться.
До інших типових прикладів використання тестування під керуванням даними належать:
Перевірка авторизації та прав доступу на великому наборі імен користувачів та паролів;
Багаторазове заповнення полів форм різними даними та перевірка реакції програми;
Виконує тест-кейс на основі даних, отриманих за допомогою комбінаторних технік.
Дані для аналізованого підходу до організації тест-кейсів можуть надходити з файлів, баз даних та інших зовнішніх джерел або навіть генеруватися в процесі виконання тест-кейс (див. опис джерел даних для автоматизованого тестування).
Переваги:
Усунення надмірності коду тест-кейсів;
Зручне зберігання та зрозумілий людині формат даних;
Можливість доручення генерації даних співробітнику, який не має навичок програмування;
Можливість використання одного й того ж набору даних для виконання різних тест-кейсів;
можливість повторного використання набору даних для вирішення нових завдань;
Можливість використання одного і того ж набору даних в тому самому тест кейсі, але реалізованому під різними платформами.
Недоліки:
При зміні логіки поведінки тест-кейсу його код все одно доведеться переписувати;
При невдало обраному форматі представлення даних різко знижується їхня зрозумілість для непідготовленого фахівця;
Необхідність використання технологій генерації даних;
Висока складність коду тест-кейсу у разі складних неоднорідних даних;
Ризик неправильної роботи тест-кейсів у разі, коли кілька тест-кейсів працюють з одним і тим самим набором даних, і він був змінений таким чином, на який не були розраховані деякі тест-кейс;
Слабкі можливості для збору даних у разі виявлення дефектів;
Якість тест-кейсу залежить від професіоналізму співробітника, який реалізує код тест-кейс.
Технології: Тестування під керуванням ключовими словами
Логічним розвитком ідеї про винесення зовні тест-кейсу даних є винесення зовні тест-кейсу команд (опису дій). Ідею можна розвинути, додавши в CSV-файл ключові слова, які є описом перевірки, що виконується. Найяскравішим прикладом інструментального засобу автоматизації тестування, ідеально наступного ідеології тестування під керуванням ключовими словами, є Selenium IDE, у якому кожна операція тест-кейсу описується як: Дія (ключове слово) - Необов'язковий параметр 1 - Необов'язковий параметр 2.
Тестування під управлінням ключовими словами стало тим переломним моментом, з якого стало можливим залучення до автоматизації тестування нетехнічних фахівців. Погодьтеся, що немає потреби в знаннях програмування та подібних технологій, щоб наповнювати подібні тільки що показані CSV-файли або (що дуже часто практикується) файли XLSX.
Другою природною перевагою тестування під управлінням ключовими словами (хоча вона цілком характерна і для тестування під управлінням даними) стала можливість використання різних інструментів одними й тими самими наборами команд та даних. Так, наприклад, ніщо не заважає нам взяти показані CSV-файли та написати нову логіку їх обробки не на PHP, а на C#, Java, Python або навіть із використанням спеціалізованих засобів автоматизації тестування.
Переваги:
Максимальне усунення надмірності коду тест-кейсів;
Можливість побудови міні-фреймворків, які вирішують широкий спектр завдань;
Підвищення рівня абстракції тест-кейсів та можливість їх адаптації для роботи з різними технічними рішеннями;
Зручне зберігання та зрозумілий людині формат даних та команд тест-кейсу;
Можливість доручення опису логіки тест-кейсу співробітнику, який не має навичок програмування;
Можливість повторного використання для вирішення нових завдань;
Розширюваність (можливість додавання нової поведінки тест-кейсу на основі вже реалізованої поведінки)
Недоліки:
Висока складність (і, можливо, тривалість) розробки;
Висока ймовірність наявності помилок у коді тест-кейсу;
Висока складність (або неможливість) виконання низькорівневих операцій, якщо фреймворк не підтримує відповідних команд;
Ефект від використання даного підходу настає далеко не відразу (спочатку йде тривалий період розробки та налагодження самих тест-кейсів та допоміжної функціональності);
Для реалізації цього підходу потрібна наявність висококваліфікованого персоналу;
Необхідно навчити персонал мови ключових слів у тест-кейсах.
Технології: Фреймворки
Фреймворк автоматизації тестування – це інтегрована система, яка встановлює правила автоматизації конкретного продукту. Ця система поєднує бібліотеки функцій, джерела тестових даних, відомості про об'єкти та різні повторно використовувані модулі. Ці компоненти діють як невеликі будівельні блоки, які необхідно зібрати для представлення бізнес-процесу. Платформа забезпечує основу для автоматизації тестування та спрощує процес автоматизації.
Фреймворки автоматизації тестування являють собою не що інше, як успішно розвинені і популярні рішення, що об'єднують у собі кращі сторони тестування під управлінням даними, ключовими словами і можливості реалізації приватних рішень на високому рівні абстракції.
Фреймворків автоматизації тестування дуже багато, вони дуже різні, але їх поєднує кілька спільних рис:
висока абстракція коду (немає необхідності описувати кожну елементарну дію) із збереженням можливості виконання низькорівневих дій;
універсальність та переносимість використовуваних підходів;
досить висока якість реалізації (для популярних фреймворків).
Як правило, кожен фреймворк спеціалізується на своєму вигляді тестування, рівні тестування, наборі технологій. Існують фреймворки для модульного тестування (наприклад, сімейство xUnit), тестування веб-додатків (наприклад, сімейство Selenium), тестування мобільних програм, тестування продуктивності тощо.
Існують безкоштовні та платні фреймворки, оформлені у вигляді бібліотек деякою мовою програмування або у вигляді звичних додатків з графічним інтерфейсом, вузько- та широко спеціалізовані тощо.
Переваги:
Широке розповсюдження;
Універсальність у межах свого набору технологій;
Хороша документація та велика спільнота спеціалістів, з якими можна проконсультуватися;
Високий рівень абстракції;
Наявність великого набору готових рішень та описів відповідних кращих практик застосування того чи іншого фреймворку для вирішення тих чи інших завдань.
Недоліки:
Потрібен час вивчення фреймворка;
У разі написання власного фреймворку де-факто виходить новий проект розробки ПЗ;
Висока складність переходу на інший фреймворк;
У разі припинення підтримки фреймворку тест-кейси рано чи пізно доведеться переписувати з використанням нового фреймворку;
Високий ризик вибору невідповідного фреймворку.
Технології: Запис та відтворення (Record & Playback)
Технологія запису та відтворення (Record & Playback) стала актуальною з появою досить складних засобів автоматизації, що забезпечують глибоку взаємодію з додатком, що тестується, і операційною системою. Використання цієї технології, як правило, зводиться до наступних основних кроків:
Тестувальник вручну виконує тест-кейс, а засіб автоматизації записує всі його дії;
Результати запису подаються у вигляді коду високорівневою мовою програмування (у деяких засобах - спеціально розробленою);
Тестувальник редагує отриманий код;
Готовий код автоматизованого тест-кейсу виконується для тестування в автоматизованому режимі.
Сама технологія при досить високій складності внутрішньої реалізації дуже проста у використанні і по самій своїй суті, тому часто застосовується для навчання фахівців-початківців з автоматизації тестування.
Переваги:
Гранична простота освоєння (досить буквально кількох хвилин, щоб почати
використовувати цю технологію);
Швидке створення «скелета тест-кейсу» за рахунок запису ключових дій з додатком, що тестується;
Автоматичний збір технічних даних про додаток, що тестується (ідентифікаторів і локаторів елементів, написів, імен і т.д.);
Автоматизація рутинних процесів (заповнення полів, натискань на посилання, кнопки і т.д.);
У окремих випадках допускає використання тестувальниками без навичок програмування.
Недоліки:
Лінійність тест-кейсів: у записі не буде циклів, умов, викликів функцій та інших характерних для програмування та автоматизації явищ;
запис зайвих дій (як просто помилкових випадкових дій тестувальника з додатком, що тестується, так і (у багатьох випадках) перемикань на інші додатки та роботи з ними);
Так званий "хардкодінг", тобто. запис всередину коду тест-кейсу конкретних значень, що вимагатиме ручного доопрацювання для перекладу тест-кейсу на технологію тестування під керуванням даними;
незручні імена змінних, незручне оформлення коду тест-кейсу, відсутність коментарів та інші недоліки, що ускладнюють підтримку та супровід тест кейсу в майбутньому;
Низька надійність самих тест-кейсів через відсутність обробки винятків, перевірки умов тощо.
Технології: Тестування під керуванням поведінкою
Розглянуті вище технології автоматизації максимально сфокусовані на технічних аспектах поведінки програми і мають загальний недолік: з їх допомогою складно перевіряти високорівневі сценарії користувача (а саме в них і зацікавлені замовники і кінцеві користувачі). Цей недолік покликане виправити тестування під управлінням поведінкою, в якому акцент робиться не на окремих технічних деталях, а на загальній працездатності додатка при вирішенні типових завдань користувача.
Такий підхід як спрощує виконання цілого класу перевірок, а й полегшує взаємодію між розробниками, тестувальниками, бізнес-аналітиками і замовником, т.к. в основі підходу лежить дуже проста формула «given-when-then»:
Given («маючи, припускаючи, за умови») описує початкову ситуацію, у якій перебуває користувач у тих роботи з додатком;
When («коли») визначає набір дій користувача у цій ситуації;
Then («тоді») описує очікувану поведінку програми.
Такий принцип опису перевірок дозволяє навіть учасникам проекту, які мають глибокої технічної підготовки, брати участь у розробці й аналізі тест-кейсів, а фахівців з автоматизації спрощується створення коду автоматизованих тест-кейсів, т.к. така форма є стандартною, єдиною і при цьому надає достатньо інформації для написання високорівневих тест-кейсів. Існують спеціальні технічні рішення (наприклад, Behat, JBehave, NBehave, Cucumber), що спрощують реалізацію тестування під керуванням поведінкою.
Переваги:
фокусування на потребах кінцевих користувачів;
Спрощення співпраці між різними фахівцями;
Простота та швидкість створення та аналізу тест-кейсів (що, у свою чергу, підвищує корисний ефект автоматизації та знижує накладні витрати).
Недоліки:
Високорівневі поведінкові тест-кейси пропускають багато деталей, а тому можуть не виявити частину проблем у додатку або не надати потрібну для розуміння виявленої проблеми інформації;
У деяких випадках інформації, наданої у поведінковому тест-кейсі, недостатньо для його безпосередньої автоматизації
До класичних технологій автоматизації тестування можна віднести розробку під управлінням тестуванням (Test-driven Development, TDD) з її принципом «червоний, зелений, покращений» (Red-Green-Refactor), розробку під управлінням поведінкою (Behavior-driven Development), модульне тестування (Unit Testing) тощо. Але ці технології вже знаходяться на межі тестування та розробки додатків, тому виходять за межі цієї теми.
Автоматизація поза прямими завданнями тестування
Протягом цього розділу ми розглядали, як автоматизація може допомогти у створенні та виконанні тест-кейсів. Але ті самі принципи можна перенести і на решту роботи тестувальника, в якій також бувають тривалі і стомлюючі завдання, рутинні завдання або завдання, що потребують граничної уваги, але не пов'язані з інтелектуальною роботою. Все перераховане також можна автоматизувати. Так, це вимагає технічних знань та початкових витрат сил і часу на реалізацію, але в перспективі такий підхід може заощаджувати до кількох годин на день. До типових рішень з цієї галузі можна віднести:
Використання командних файлів для виконання послідовностей операцій - від копіювання кількох файлів із різних каталогів до розгортання тестового оточення. Навіть у рамках багаторазово розглянутих прикладів із тестування «Конвертера файлів» запуск програми через командний файл, в якому вказані всі необхідні параметри, позбавляє необхідності вводити їх щоразу вручну;
Генерація та оформлення даних з використанням можливостей офісних програм, баз даних, невеликих програм на високорівневих мовах програмування. Немає картини сумніше, ніж тестувальник, що руками нумерує три сотні рядків у таблиці;
Підготовка та оформлення технічних розділів для звітів. Можна витрачати години на скрупульозне вичитування журналів роботи якогось засобу автоматизації, а можна один раз написати скрипт, який за мить готуватиме документ з акуратними таблицями та графіками, і залишиться лише запускати цей скрипт і прикріплювати результати його роботи до звіту;
Керування своїм робочим місцем: створення та перевірка резервних копій, встановлення оновлень, очищення дисків від застарілих даних тощо. і т.п. Комп'ютер все це може (і має!) робити сам, без участі людини;
Сортування та обробка пошти. Навіть розкладання вхідної кореспонденції по підпапках гарантовано займає кілька хвилин на день. Якщо припустити, що налаштування спеціальних правил у вашому поштовому клієнті заощадить півгодини на тиждень, за рік економія складе приблизно добу;
Віртуалізація як спосіб позбавлення необхідності щоразу встановлювати і налаштовувати необхідний набір програм. Якщо у вас є кілька підготовлених віртуальних машин, їх запуск займе секунди. А у разі необхідності усунення збоїв розгортання віртуальної машини з резервної копії замінює весь процес встановлення та налаштування з нуля операційної системи та всього необхідного програмного забезпечення.
Драйвер. Утиліти автотестування, як і інші програми, можуть взаємодіяти з додатком лише через програмний інтерфейс – інакше вони не вміють. Для роботи через інші інтерфейси існують спеціальні програми – драйвери. Драйвер – програма, яка надає API для одного з інтерфейсів програми. Для кожного інтерфейсу, крім API, необхідний свій драйвер. Наприклад, коли ви даєте драйверу для GUI команду "Натиснути на кнопку Menu", він сприймає її через API і відсилає в додаток, де ця команда перетворюється на клік по графічній кнопці Menu. Для взаємодії з API програми драйвери не потрібні або майже не потрібні - програмна взаємодія. А ось при роботі з рештою інтерфейсів без них не обійтися. Найбільш складними зазвичай є драйвери для GUI, оскільки цей інтерфейс дуже відрізняється від звичайного для програми спілкування кодом. При цьому в автоматизованому тестуванні мобільних додатків GUI найактуальніший, тому що в інтеграційному тестуванні використовувати найчастіше доводиться саме його. Найбільш популярні драйвера для GUI в мобільному тестуванні – UIAutomator та Espresso для Android, XCUITest – для iOS.
Надбудова . Коли функціонала драйвера не вистачає або він незручний і складний, над ним з'являється ще один рівень, який я називатиму надбудовою. Надбудова - програма, яка взаємодіє з додатком через один або кілька драйверів, підвищуючи зручність їх використання або розширюючи їх можливості.
Надбудови можуть мати такі функції:
Модифікація поведінки (без зміни API). Наприклад:
додаткове протоколювання,
валідація даних,
очікування на виконання дії протягом певного часу.
Підвищення зручності та/або рівня абстракції API через:
використання синтаксичного цукру - зручних назв функцій, коротших звернень до них, уніфікованого стилю написання тестів;
неявне керування драйвером, коли, наприклад, він ініціалізується автоматично, без необхідності прописувати кожну таку дію вручну;
спрощення складних команд на кшталт вибору події з календаря або роботи з списками, що прокручуються;
реалізацію альтернативних стилів програмування, таких як процедурний стиль чи fluent.
Уніфікація драйверів API. Тут надбудова надає єдиний інтерфейс для роботи з кількома драйверами. Це дозволяє, наприклад, використовувати один і той же код для тестів на iOS та Android, як у популярній надбудові Appium.
Фреймворк . З іншого боку тестів знаходиться фреймворк запуску. У рамках цієї статті я коротко називатиму його “фреймворк”. Фреймворк – це програма для формування, запуску та збору результатів запуску набору тестів.
У завдання фреймворку входять:
формування, угруповання та впорядкування набору тестів,
розпаралелювання набору (опціонально),
створення фікстур,
запуск тестів,
збирання результатів їх виконання,
формування звітів про виконання (опціонально).
Можна помітити, що ці функції не пов'язані з тестуванням лише мобільних програм - їх можна успішно застосовувати і в тестуванні десктоп-і веб-додатків. Справа в тому, що фреймворк не повинен забезпечувати взаємодію тестів і програми - він працює тільки з тестами, і тип програми не має значення. Якщо драйвери та надбудови знаходяться між тестами та програмою, то фреймворк знаходиться над тестами, організуючи їх запуск. Тому важливо не плутати поняття "драйвер" та "фреймворк". Звичайно, в деяких фреймворках є власні драйвери для роботи з додатками, але це не обов'язкова умова. Найпомітніші фреймворки у мобільному тестуванні - xUnit та Cucumber.
Комбайни . Нарешті, ще одна група утиліт, що використовуються для автоматизації тестування мобільних додатків, - це комбайни, що поєднують у собі фреймворки, і драйвери (причому не тільки мобільні), і навіть можливості розробки. Xamarin.UITest, Squish, Ranorex – всі вони підтримують автоматизацію тестування iOS-, Android-, веб-додатків, а два останні – ще й десктоп-додатків.
Android: Інструменти для автоматизації тестування
Тести під андроїд бувають локальні та інструментальні:
Instrumented tests виконуються на пристрої Android, фізичному або емульованому. Тест збирається в APK і встановлюється разом із тестовим додатком. Instrumented tests зазвичай являють собою тести інтерфейсу користувача, запуск програми і подальшу взаємодію з ним;
Local tests виконуються на машині розробки чи сервері, тому їх також називають тестами за хоста (host-side tests). Для запуску тестів використовується віртуальна машина Java (JVM). Зазвичай вони маленькі і швидкі, ізолюючи об'єкт, що тестується, від решти програми.
Не всі модульні тести є локальними, і не всі тести Е2Е виконуються на пристрої. Наприклад:
Великий локальний тест: можна використовувати симулятор Android, який працює локально, наприклад Robolectric;
Невеликий інструментальний тест: ви можете переконатися, що ваш код добре працює з функцією платформи, такої як база даних SQLite. Цей тест можна запустити на кількох пристроях, щоб перевірити інтеграцію з кількома версіями SQLite.
Всі драйвери працюють на Android Instrumentation Framework – базовому API Android для взаємодії із системою. Найпопулярніші - Espresso та UiAutomator. Вони обидва розробляються та підтримуються компанією Google. Їх легко можна використовувати одночасно в межах одного тесту.
UiAutomator поставляється разом з Android SDK, починаючи з 16 версії API. Як GUI-драйвер він служить для пошуку елементів інтерфейсу на екрані девайса та емуляції різних дій: кліків, тачів, свайпів, введення тексту, перевірок на видимість. Рекордер для запису тестів він не надає, натомість надає утиліту для перегляду деревоподібної структури екрану – Ui Automator Viewer.
UiAutomator дозволяє писати тести за моделлю чорної скриньки (black-box). Він живе у своєму процесі та працює без доступу до вихідного коду програми. Отже, тест із його використанням може взаємодіяти практично з будь-якими програмами, зокрема системними. Це відкриває доступ до безлічі функцій, наприклад, стають можливими:
набір номера та здійснення дзвінка;
відправлення та читання смс;
взаємодія з нотифікаціями;
керування налаштуваннями мережі, геолокації;
зняття скріншотів.
Найбільш підходящим сценарієм для використання UiAutomator є не робота з продуктом, що тестується, а взаємодія зі сторонніми або системними додатками. Більше відповідним інструментом для роботи з продуктовим додатком є Espresso .
Це також офіційний фреймворк для UI-тестування від Google, але тести з його використанням працюють уже за моделлю білої скриньки (white-box). Espresso підтримує Android API з 10 версії, хоча з'явився значно пізніше. Надає рекордер для запису тестів. Фактично Espresso є лідером та навіть стандартом в індустрії. Такий успіх може бути пов'язаний з тим, що він забезпечує підвищену швидкість та стабільність тестів у порівнянні з конкурентами. Espresso вирішує низькорівневу задачу – знайти необхідний елемент на екрані за заданими параметрами (ViewMatcher), зробити з ним дії (ViewAction) або виконати перевірки (ViewAssertion). Синтаксис Espresso реалізований на основі фреймворку Hamcrest. Він побудований на використанні ієрархій вкладених матчерів – сутностей, що описують вимоги до об'єкта, у випадку Espresso – до елементів інтерфейсу. Вони використовуються при заданні параметрів пошуку елемента на екрані, а також у перевірках як опис властивостей, які елемент повинен мати. Вкладеність матчерів часто призводить до того, що код тестів стає важко читати та підтримувати. Стабільність і швидкість тестів на Espresso обумовлені його внутрішнім пристроєм - всі команди Espresso виконуються в тому ж процесі, в якому працює додаток, що сам тестується. Дії та перевірки перетворюються та кладуться в чергу повідомлень головного потоку програми. Виконуються вони тільки коли додаток готовий до цього, тобто його головний потік знаходиться в стані очікування введення користувача (idle). що код тестів стає важко читати та підтримувати. Стабільність і швидкість тестів на Espresso обумовлені його внутрішнім пристроєм - всі команди Espresso виконуються в тому ж процесі, в якому працює додаток, що сам тестується. Дії та перевірки перетворюються та кладуться в чергу повідомлень головного потоку програми. Виконуються вони тільки коли додаток готовий до цього, тобто його головний потік знаходиться в стані очікування введення користувача (idle). що код тестів стає важко читати та підтримувати. Стабільність і швидкість тестів на Espresso обумовлені його внутрішнім пристроєм - всі команди Espresso виконуються в тому ж процесі, в якому працює додаток, що сам тестується. Дії та перевірки перетворюються та кладуться в чергу повідомлень головного потоку програми. Виконуються вони тільки коли додаток готовий до цього, тобто його головний потік знаходиться в стані очікування введення користувача (idle).
Отже, з драйверами та пристроєм найпопулярніших з них ми розібралися. Ми зрозуміли, що всі вони вирішують низькорівневі завдання: пошук елемента на екрані та виконання з ним будь-якої дії. Через це вони надають невиразне API, яким незручно користуватися для вирішення більш високорівневих проблем. Наприклад, жоден із них не надає власний механізм для реалізації повторів невдалих дій чи логування. Більше того, часто існує необхідність працювати в тестах з кількома драйверами, наприклад, з Espresso і UiAutomator.
На допомогу приходять обгортки (надбудови). Саме до API обгорток ми звертатимемося в наших тестах, і саме обгортки надають кінцевий арсенал прийомів для наших тестів.
Докладніше у джерелі за першим посиланням далі.
iOS: Інструменти для автоматизації тестування
Під iOS існують такі інструменти:
Докладніше у джерелі за першим посиланням далі.
Кросплатформові обгортки
Дод. матеріал:
WEB: Інструменти для автоматизації тестування
Докладніше у джерелі за першим посиланням далі.
API: Інструменти для автоматизації тестування
По постману та соап є безліч посилань в інструментах для мануальника.
Unit
Інструменти по performance/security і всьому, що не увійшов, дивись у розділі корисних посилань з мануального тестування.
Інструменти, що стосуються інфраструктури CI/CD, винесені на наступну тему.
Дод. матеріал:
За інструментами:
Last updated