Дослідження автоматизації тестування у Web та мобільних технологіях

Калінчук, Дем'ян Васильович
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/6477
Назва:	Дослідження автоматизації тестування у Web та мобільних технологіях
Автори:	Міценко, Сергій Анатолійович Калінчук, Дем'ян Васильович
Дата публікації:	січ-2024
Короткий огляд (реферат):	Кваліфікаційна робота полягала у розробці та дослідженні сутності підходу до автоматизації тестування мобільних та Web-додатків на основі алгоритму вибірки вільного потоку для розпаралелювання робочих потоків під час прогону автоматизованих скриптів. Алгоритм на якому базується метод вибірки працює за рахунок визначення середовища в якому запускаються тести та після його визначення використовуються відповідні користувачі які виконують певні тестові скріпти. Проведено аналіз рентабельності даного підходу, методом визначенні КПД після запуску тестових с’ютів, за результатом прогонів, використання алгоритму скоротило час проходження тестів в 2-3 рази, в залежності від проекту та кількості тестових сценаріїв. Проведені науково-дослідницькі роботи з розроблення та аналізу можливих реалізацій подібної логіки, але в своїй сутності вони не здатні до динамічних змін багатопоточності як то реалізовано в представленому в роботі алгоритмі.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/6477
Розташовується у зібраннях:	174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)
Файли цього матеріалу:
Файл	Опис	Розмір	Формат
М_151_2023_Калінчук.pdf Restricted Access		1.73 MB	Adobe PDF	Переглянути/Відкрити Запит копії
Показати повний опис матеріалу Перегляд статистики
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ СИСТЕМ 
 
 
 
 
 
Пояснювальна записка 
до кваліфікаційної роботи 
освітнього ступеню «магістр» 
 
на тему: Дослідження автоматизації тестування в WEB та мобільних технологіях 
 
 
 
 
Виконав: здобувач 2 курсу, групи МАКІТ-2209 
спеціальності 151 Автоматизація та 
комп’ютерно-інтегровані технології, 
освітня програма «Автоматизація 
комп’ютерно-інтегровані системи та 
компоненти» 
         Калінчук Д.В.   
(Прізвище ім’я по-батькові) 
 
Керівник                Міценко С.А.   
(Прізвище ім’я по-батькові)   
Рецензент        
    (Прізвище ім’я по-батькові) 
 
 
Черкаси 2023 року  
2 
 
ЗМІСТ 
 
 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ………………………………….. 3 
ВСТУП……………………………………………………………………. 4 
РОЗДІЛ 1 АНАЛІЗ МЕТОДІВ, ЗАСОБІВ, ЗАВДАНЬ ТА НАПРЯМКІВ 
7 
ДІЯЛЬНОСТІ КОНТРОЛЮ ЯКОСТІ…………………………………… 
    1.1 Сутність та завдання контролю якості…………………………… 7 
    1.2 Принципи та відмінності в сутності роботи мануального та 
9 
автоматизованого тестування…………………………………………… 
1.3 Типи, техніки та види «стратегій» в тестуванні………………… 12 
    1.4 Рівні автоматизації тестування відповідно до 
18 
користувальницького інтерфейсу……………………………………….. 
    1.5  Підходи до автоматизації тестування. Патерни для побудови 
20 
структури автоматизаційних фреймворків тестування……………….. 
1.6 Аналіз фреймворків для управління тестовими сценаріями……. 27 
    1.7 Аналіз процесу діяльності автоматизованого тестування……… 28 
Висновок до розділу 1…………………………………………………… 31 
РОЗДІЛ 2 МОДЕЛІ АВТОМАТИЗОВАНОГО ТЕСТУВАННЯ 
32 
МОБІЛЬНИХ ТА ВЕБ-ДОДАТКІВ……………………………………... 
    2.1 Модель тестування мобільних додатків………………………….. 32 
    2.2 Модель тестування Web-додатків та Web-сайтів………………... 43 
    2.3 Порівняльний аналіз мобільної та Web-моделей автоматизації 
49 
тестування………………………………………………………………… 
Висновки до розділу 2……………………………………………………. 51 
РОЗДІЛ 3 РЕАЛІЗАЦІЯ РОЗРОБКИ ТА АНАЛІЗ ФРЕЙМВОРКІВ 
52 
ДЛЯ АВТОМАТИЗАЦІЇ ТЕСТУВАННЯ ……………………………… 
3 
 
    3.1 Розробка фреймворку автоматизації тестування для Web-
52 
додатку…………………………………………………………………….. 
    3.2  Розробка фреймворку для мобільних додатків 58 
    3.3  Порівняльний аналіз підходів до тестування мобільних та Web-
66 
додатків……………………………………………………………………. 
Висновки до розділу 3……………………………………………………. 66 
ВИСНОВКИ………………………………………………………………. 67 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ………………………………… 69 
ДОДАТКИ………………………………………………………………….  73 
 
  
4 
 
СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ 
 
 
QA Quality assurance 
AQA Automation quality assurance 
IT Information technologies 
API Application programming interface  
ПЗ Програмне забезпечення 
ПП Програмний продукт 
GUI Graphical user interface 
CI Continuous Integration 
 
  
5 
 
ВСТУП 
 
 
Актуальність. Сьогодні важко уявити сучасний світ без інформаційних 
технологій (ІТ), саме стрімкий розвиток ІТ подарував людству широкий спектр 
використання різноманітних програмних продуктів. 
З кожним роком кількість створених програмних продуктів та систем стрімко 
зростає, з'являються нові ІТ-компанії, які пропонують свої програмні продукти, і, 
відповідно, виникає конкуренція у сферах впровадження програмного 
забезпечення, і чим якіснішим є програмний продукт, тим більша ймовірність, що 
він знайде свого споживача. 
Саме якість та актуальність програмних продуктів впливає на їх популярність 
серед кінцевого користувача, тому зосередимо увагу на якості реалізації 
програмного продукту та ролі, яку вона відіграє в життєвому циклі будь-якого 
програмного продукту. 
Контроль та оцінка будь-якого аспекту проекту, обладнання або виду послуг 
з метою підвищення ймовірності відповідності встановленим мінімальним 
стандартам якості дозволяє мінімізувати фактор того, що кінцевий результат 
виконаної роботи буде негативним. 
Забезпечення якості визначено в стандарті ISO 9000:2005 "Системи 
управління якістю. Основні принципи та глосарій" як "частина управління якістю, 
спрямована на створення впевненості в тому, що вимоги до якості будуть виконані". 
Управління якістю в цьому ж стандарті представлено як "скоординована 
діяльність керівництва та управління організацією щодо якості", а в примітці 
зазначено, що воно "зазвичай включає розроблення політики та цілей у сфері якості, 
планування якості, управління якістю, забезпечення якості та поліпшення якості". 
6 
 
Забезпечення якості не дає повних гарантій того, що кінцевий продукт буде 
якісним, але воно дає нам розуміння того, що він буде максимально адаптований 
для прийнятного використання. 
У зв'язку з вищезазначеним, темою даної роботи є розробка та дослідження 
проектів автоматизації контролю якості, які будуть побудовані на основі 
класичного підходу до контролю якості. У цій роботі автоматизовані фреймворки 
будуть базуватися на контролі якості мобільних та веб-додатків. 
Мета роботи – дослідження та реалізація автоматизованих фреймворків  
контролю якості на основі розбіжності тестування мобільних та веб-додатків. 
Завдання дослідження, що реалізують мету дослідження: 
• проведення огляду та аналіз існуючих підходів до автоматизації 
контролю якості мобільних та веб-додатків; 
• розробка фреймворків для забезпечення автоматизації контролю якості 
мобільних та веб-додатків; 
• створення проектів з автоматизаційними сценаріями на базі 
розроблених фреймворків які реалізовують процес автоматизаційного контролю 
якості для мобільних платформ на базі Android та веб-додатків на базі Google 
Chrome. 
Об’єкт дослідження – процес автоматизованого контролю якості базованого 
на розуміннях та практиках класичних підходів контролю якості. 
Предмет дослідження – автоматизація контролю якості для мобільних та 
веб-платформ. 
Методи дослідження. Методи дослідження включають: алгоритми 
генерування тестових сценаріїв, класичний підхід до генерування тестових 
сценаріїв обчислювального характеру, задачі дискретної математики які підлягають 
автоматизації. 
 
7 
 
Наукова новизна проведених досліджень та отриманих в роботі результатів: 
• отримали подальший розвиток методи та підходи до формування 
автоматизованих фреймворків контролю якості; 
• отримали подальший розвиток моделі Page Object та Page Factory які 
відрізняються від тих які запропоновані в класичному підході тим, що мають більш 
детальну декомпозицію та використання проперті файлів для обміну даним з 
логічними операціями, фреймворк сам адаптується до середовища для якого він 
буде запускатись та в якому буде функціонувати за допомогою системних проперті 
файлів які будуть використовуватись як інформаційно-ресурсні; 
• запропоновано розроблені автоматизовані фреймворки контролю 
якості з використанням мобільної платформи Android та веб-орієнтованих 
програмних продуктів. 
Практичне значення одержаних результатів. Розроблено архітектуру 
автоматизованих фреймворків контролю якості на основі особистої логіки 
функціонування патернів та фреймворків управління тесовими сценаріями.  
Проведено чисельні дослідження з актуальності та якісності розробленого 
підходу до формування автоматизованих фреймворків. 
Розроблено архітектуру клієнт-серверної системи для зв’язку мобільного 
фреймворку з девайсами різних типів та платформ. 
Апробація результатів роботи. Тези в ІІ Всеукраїнській науково-практичній 
конференції з міжнародною участю «Наука України – погляд молодих учених крізь 
призму сучасності», 26 вересня 2019 року, Черкаси, ЧДТУ. 
Структура та обсяг кваліфікаційної роботи. Кваліфікаційна робота 
складається із списку умовних скорочень, вступу, трьох розділів, висновку та 
списку використаних джерел. Загальний обсяг роботи складає 72 сторінки, 39 
рисунків, 6 таблиць, список використаних джерел містить 32 найменування. 
  
8 
 
РОЗДІЛ 1 
АНАЛІЗ МЕТОДІВ, ЗАСОБІВ, ЗАВДАНЬ ТА НАПРЯМКІВ 
ДІЯЛЬНОСТІ КОНТРОЛЮ ЯКОСТІ 
 
 
1.1 Сутність та завдання контролю якості  
На сьогоднішній день, сучасний світ тяжко уявити без інформаційних 
технологій (ІТ), саме стрімкий розвиток ІТ дав людству великий спектр 
використання різноманітних програмних продуктів. 
З кожним роком кількість створених програмних продуктів та систем стрімко 
росте, з’являються нові ІТ компанії які  пропонують свої програмні продукти, 
відповідно з’являється конкуренція в областях реалізації відповідного ПЗ, і чим 
якіснішим буде програмний продукт тим більша вірогідність того, що він знайде 
свого споживача. 
Саме якість та актуальність програмних продуктів впливає на їх популярність 
в кінцевого споживача, зупинимось на саме на якості реалізації програмного 
продукту, та яку роль вона відіграє в життєвому циклі будь-якого програмного 
продукту. 
Тож що таке контроль та забезпечення якості (Quality assurance, QA) –  
контроль і оцінка будь-яких аспектів проекту, обладнання чи виду послуг з метою 
збільшення вірогідності забезпечення встановлених мінімальних стандартів якості, 
а також –  підтримку цих характеристик при зберіганні, транспортуванні та 
експлуатації продукції. 
Забезпечення якості визначено в стандарті ISO 9000:2005 «Системи 
менеджменту якості. Основні положення та словник» як «частина менеджменту 
якості, спрямована на створення впевненості в тому, що вимоги до якості будуть 
виконані»[1]. 
9 
 
Менеджмент якості в цьому ж стандарті представлений як «скоординована 
діяльність з керівництва та управління організацією стосовно до якості», а в 
примітці сказано, що він «звичайно включає розробку політики та цілей у сфері 
якості, планування якості, управління якістю, забезпечення якості та покращення 
якості»[1]. 
Забезпечення якості не дає повних гарантій того, що кінцевий продукт буде 
якісним. 
Існує 2 основних принципу забезпечення якості: 
• фактичний результат має відповідати очікуваному; 
• у ньому не повинно бути похибок. 
Забезпечення якості включає в себе регулювання якості сировини та 
напівфабрикатів, зборки, виробництва та розробки, менеджменту, перевірки на 
брак. Якість визначається задоволеністю користувача або споживача. Результатом 
забезпечення якості як постійного процесу є поліпшення якості. 
Забезпечення якості програмного забезпечення складається з засобів 
моніторингу програмного забезпечення технологічних процесів і методів, 
використовуваних для забезпечення якості. Методи, за допомогою яких це 
досягається, численні і різноманітні, і можуть містити в собі забезпечення 
відповідності одному або декільком стандартам, таким як ISO 9000 або моделі, такі 
як CMMI модель.  
Визначення «QA» іноді використовується неофіційно 
як синонім для тестування програмного забезпечення. В розумінні інформаційних 
технологій є 3 основні напрями контролю якості. 
Забезпечення якості (Quality Assurance) – найширше з усіх понять, яке являє 
собою сукупність заходів, охоплюючи абсолютно усі етапи розробки, випуску та 
експлуатації програмного забезпечення. Це активності на усіх етапах життєвого 
циклу ПЗ, які вживаються для забезпечення необхідного рівня якості продукту[2]. 
10 
 
Контроль якості (Quality Control) – це дії, які проводять над продуктом у 
процесі розробки, для отримання інформації про його актуальний стан: наскільки 
продукт готовий та чи відповідає він вимогам якості у кожний конкретний 
проміжок часу. 
Тестування програмного забезпечення (Software Testing) – це одна з технік 
контролю якості, яка включає в себе активності по плануванню тестових дій, 
дизайну тестових сценаріїв, виконанню цих тестів та аналізу отриманих даних[2]. 
 
1.2 Принципи та відмінності в сутності роботи мануального та 
автоматизованого тестування 
Оскільки тестування ПЗ має два основні напрямки це – мануальне(ручне) та 
автоматизоване тестування при правильному підході до планування тестування це 
допомагає спеціалісту заощадити ресурси які використовуються для його роботи. 
Обидва підходи мають свої переваги та недоліки під час їхньої реалізації, а саме: 
Ручне тестування. Може зайняти багато часу у спеціалістів, але в 
короткостроковій перспективі воно заощадить більше ресурсів у довгостроковій 
перспективі реалізації цього підходу. Вартість такого тестування залежить тільки 
від самого спеціаліста і його навиків і не залежить від інструментів які він 
використовує. Ручне тестування можна розглядати як взаємодію між QA-
спеціалістом і безпосередньо командою розробників програмного забезпечення для 
пошуку розбіжностей між вимогами та дефектами в системі. Працюючи з додатком 
або сервісом безпосередньо, інженер з якості може порівняти очікуваний результат 
з реальним і залишити рекомендації для команди розробників програмного 
забезпечення[3]. До основних переваг ручного тестування можна віднести: 
•  дешевизна робочого процесу - в короткостроковій перспективі ручне 
тестування дешевше, ніж автоматизовані інструменти та системи для розробки 
фреймворків тестування; 
11 
 
• Тестування програмних продуктів в реальному часі – зміни різного 
ступеня та логіки  в  можна дослідити відразу після зміни, без написання коду та 
його виконання; 
• можливість дослідницького тестування - його метою є перевірка різних 
можливостей програми, важливо, щоб ви використовували не заздалегідь 
сформовані тестові сценарії, а придумані під час користування програмним 
продуктом. 
Недоліками ручного тестування є: 
• людський фактор - люди іноді схильні до неефективності, відповідно 
деякі помилки можуть залишитися випадково невиявленими або проігнорованими 
спеціалістом з урахуванням якихось факторів розуміння; 
• трудомісткість повторного використання – ефективніше розробити 
один раз та запустити серію стандартних автоматичних тестів, ніж тестувати проект 
мануально після внесення змін різного змісту та логіки; 
• неможливість навантажувального тестування - неможливість вручну 
змоделювати велику кількість користувачів. 
Автоматизоване тестування.  Використовує програмні інструменти та 
додатки для виконання автоматизованих тестових скриптів і перевірки результатів 
проходження тестових с’ютів, що допомагає скоротити час тестування і спростити 
процес перевірки процесу розробки програмного продукту або забезпечення. 
Відбувається порівняння очікуваних сценаріїв що розробник вказує заздалегідь, які 
можуть бути як статичними так і динамічними з тими які може відтворювати 
користувач, і вказує на відмінності між очікуваним та фактичним результатами. 
Автоматизоване тестування відіграє важливу роль у великих проектах з великою 
кількістю функцій[3].  
 
 
12 
 
Переваги автоматизованого тестування включають в себе: 
• можливість перевірити рівень навантаження на інформаційну систему 
(ІС), програмний продукт(ПП) або базу даних; 
• економія часу під час процесу тестування розробленої логіки; 
• можливість багаторазового використання – автоматизований тестовий 
скрипт, написаний один раз, може бути використаний не один раз при наступному 
оновленні проекту.  
Недоліками автоматизованого тестування є: 
• висока вартість використання програмного софту та спеціалістів - 
інструменти автоматизованого тестування є невід’ємними в роботі спеціаліста, а 
також навчання їх використанню відносно дорогі, тому потрібно ретельно 
оцінювати можливості бюджет проекту; 
•  автоматизоване тестування не може повністю покрити всі вимоги до 
користувацького інтерфейсу тому як специфічний функціонал перевіряти може 
лише людина; 
• відсутність "людського погляду" - у програмному забезпеченні можуть 
бути помилки, які може виявити лише людина. 
Автоматизація тестування не дає змогу повністю відмовитися від 
використання ручного тестування при розробці програмного забезпечення, але 
дозволяє суттєво знизити його частку, допомагає уникнути довготривалих ручних 
перевірок в процесі тестування, зменшує вартість і суттєво покращує якість 
програмного забезпечення, що розроблюється. Тестування є одним з 
найважливіших та трудомістких етапів життєвого циклу розробки програмного 
забезпечення, що забирає на себе велику кількість часу. При цьому вартість 
виправлення помилки, не тільки матеріальна, а й фізична, як правило, 
безпосередньо залежить від часу, який проходить з моменту її виникнення до 
моменту виявлення[4]. Вважається, що автоматизації процесу тестування ПП 
13 
 
дозволяє вирішити питання зі скороченням часу для здійснення якісного 
тестування, стає все більш актуальним та важливим елементом в розробці 
програмних продуктів по скільки досить стрімко зростають вимоги до їх якості. 
На сьогоднішній день досить важко уявити собі розробку великого 
комерційного проекту без залучення в його життєвий цикл автоматизації 
тестування, зі стрімким розвитком технологій та конкуренції між цими 
технологіями, кожен великий комерційний проект хоче увійти в ринок користувача 
з максимально якісним продуктом[5]. 
 
1.3 Типи, техніки та види «стратегій» в тестуванні 
Кожна сутність підходу до тестування програмного забезпечення повинна 
базуватись на певній логіці цього тестування, розглянемо одні із основних, які 
дають нам можливість працювати з мануальним та автоматизованим тестуванням 
як з доступом до коду так і без, та в яких випадках ми можемо їх використовувати. 
Стратегії чорної та білої скриньок. Стратегії чорної та білої скриньок 
належать до динамічних технік тестування ПЗ. Тестування з використанням 
стратегії білої скриньки (white-box testing) або структурне тестування полягає у 
детальному та пошаговому дослідженні вихідного коду ПП та ПЗ – внутрішньої 
логіки їх структури. При реалізації стратегії білої скриньки спеціаліст має доступ 
до вихідного коду програмного продукту і може писати авто-скрипт, який 
пов'язаний з логікою ПЗ з якою проводиться тестування. Цей підхід 
використовують при юніт-тестуванні (unit testing), при якому тестуються лише 
окремі частини системи які були тільки розроблені або ж це точковий функціонал 
який є важливий і його потрібно відразу протестувати після внесення змін, зазвичай 
юніт-тести пишуть самі ж розробники[6].  
Існує три методи тестування за стратегією білої скриньки: тестування на 
основі потоку керування програми який здійснюється зі сторони користувача, на 
14 
 
основі потоку даних якими маніпулює користувач або сама система генерує їх та 
мутаційне тестування пов’язане зі змінами в системі.  
Тестування з використанням стратегії чорної скриньки (black-box testing) або 
функціональне тестування системи та її основних функцій не вимагає знань про 
внутрішню роботу ПЗ. При тестуванні за цією стратегією, інженер має доступ до 
ПЗ лише через ті ж інтерфейси, що і замовник або користувач, або через зовнішні 
інтерфейси, що дозволяють іншому комп'ютеру або іншому процесу підключитися 
до системи для тестування.  
Найпоширенішими техніками функціонального тестування є техніка 
випадкового тестування, еквівалентних класів та аналізу граничних значень 
зображено на (рис. 1.1). Техніка еквівалентних класів полягає у розбитті множини 
значень вхідних даних на скінченну кількість класів еквівалентності так, щоб 
кожний тест, що є представником певного класу, був еквівалентним будь-якому 
іншому тесту цього класу. Два тести вважають еквівалентними тоді коли вони 
виявляють однакові помилки в логіці, техніка еквівалентних класів (рис. 1.2)[6]. 
 
Рис. 1.1.  Граничні значення 
 
 
Рис. 1.2.  Класи еквівалентності 
 
15 
 
Проектування автоматизованих тестів за цим методом має два етапи: 
побудова класів еквівалентності та побудова множини тестів. Цей метод тестування 
дозволяє зменшити кількість тестових сценаріїв та унеможливить дублювання їх 
дублювання в майбутньому у порівнянні з методом випадкового тестування[7]. 
Щодо використання наступних технік тест-дизайну то вони не є такими 
популярними під час автоматизації тестування, але все ж таки також є валідними та 
використовуються при потребі, наприклад: 
Таблиця прийняття рішень. 
Інша назва методу – матриця ухвалення рішень. Ця техніка підходить для 
складніших систем, наприклад – двухфакторної автентифікації. Припустимо, щоб 
увійти в систему, користувачеві потрібно ввести спочатку логін і пароль, а потім 
підтвердити свою особу надісланим в смс кодом.  
Які можливі сценарії: 
• Правильний логін та правильний пароль. 
• Правильний логін, неправильний пароль. 
• Неправильний логін, правильний пароль. 
• Неправильний логін, неправильний пароль.  
Перший із цих сценаріїв супроводжується або правильним, або неправильним 
введенням смс-коду, разом у нас виходить 5 тестів. При цьому лише один із 
сценаріїв призведе до позитивного результату (користувач успішно авторизується), 
а решта закінчиться невдачею[8].  
Однак, може бути так, що система видає різні повідомлення в залежності від 
того, 
на якому етапі була допущена помилка, скажімо: invalid login, invalid password.  
Відповідно, груп знадобиться більше, а таблиця стане більшою.  
Цей метод хороший тим, що він показує відразу всі можливі сценарії у формі, 
зрозумілій навіть не фахівцям.  
16 
 
 
Рис. 1.3. Таблиця прийняття рішень (Перша форма) 
 
 
Рис. 1.4. Таблиця прийняття рішень (Друга форма) 
 
Попарне тестування. 
Суть цього методу, також відомого як Pairwise testing, у тому, що кожне 
значення кожного параметра, що перевіряється, має бути протестоване на 
взаємодію з кожним значенням всіх інших параметрів. Після складання такої 
матриці ми прибираємо тести, які дублюють один одного, залишаючи максимальне 
покриття за мінімального необхідного набору сценаріїв[9].   
Попарне тестування дозволяє виявити максимум помилок без надмірних 
перевірок.  
Для Pairwise достатньо, щоб кожне значення всіх параметрів хоча б один раз 
поєднувалося з іншими значеннями інших параметрів. Таким чином, матрицю 
можна значно зменшити (рис.1.5). 
17 
 
 
Рис. 1.5. Pairwise матриця 
 
Причина і наслідок. 
Проста перевірка базових дій та їх результату. Наприклад, якщо натиснути 
хрестик у верхньому правому куті вікна (причина), воно закриється (наслідок), і 
т.д. Цей метод дозволяє перевірити всі можливості системи, а також виявити баги 
та покращити технічну документацію продукту. 
Зразковий алгоритм використання техніки:    
• Виділяємо причини та наслідки у специфікаціях.    
• Пов'язуємо причини та наслідки.    
• Враховуємо «неможливі» поєднання причин та наслідків.    
• Складаємо «таблицю рішень», де у кожному стовпці зазначено 
комбінація входів і виходів, тобто. кожен стовпець – це готовий тестовий 
сценарій.    
• Розставляємо пріоритети. 
Ця техніка допомагає:  
Визначити мінімальну кількість тестів знаходження максимуму помилок.  
З'ясувати всі причини та наслідки – таким чином ми переконаємося, що на 
будь-які маніпуляції із системою у системи буде відповідь.  
Знайти можливі недоліки в логіці опису програми (що, своєю чергою, 
допоможе поліпшити документацію)[9]. 
18 
 
Наприклад, QA-фахівець тестує додаток типу "записник". Після введення всіх 
даних нового контакту та натискання кнопки Створити (причина) програма 
повинна автоматично створити картку з номером телефону, фотографією та ПІБ 
людини (наслідок). Тести покажуть, чи можна залишати одне або кілька полів 
порожніми, чи розпізнає система кирилицю, латиницю або обидва алфавіти, а також 
інші параметри. 
Передбачення помилок. 
Використовуючи свої знання про систему, QA-фахівець може «передбачити», 
за яких умов є ризик помилок. Для цього важливо мати досвід, добре знати продукт 
та вміти побудувати комунікації з колегами[9].  
Наприклад, у специфікації зазначено, що поле має приймати код із чотирьох 
цифр. Серед можливих тестів: 
• Що станеться, якщо код? 
• Що станеться, якщо не запровадити спецсимволи? 
• Що станеться, якщо не ввести цифри, а інші символи? 
• Що станеться, якщо запровадити не чотири цифри, а іншу кількість? 
Переваги: 
• Ця перевірка ефективна як доповнення до інших технік. 
• Виявляє тестові випадки, які ніколи не повинні трапитися.  
Недоліки:  
• Техніка значною мірою ґрунтується на інтуїції.  
• Необхідний досвід у тестуванні подібних систем.  
• Мале покриття тестами.  
Цей список далеко не повний і дає тільки найзагальніше уявлення про 
принципи тестування та техніки тест-дизайну. Наприклад, вичерпне тестування, що 
покриває всі можливі сценарії та виявляє всі помилки, існує лише теоретично. Це 
пов'язано з тим, що перевірка всіх параметрів та станів займе надто багато 
19 
 
часу. Однак, чим досвідченіший QA-фахівець, тим кращих результатів він може 
досягти, і для цього важливо вміти правильно підбирати та комбінувати техніки. 
Вибір стратегії білого або чорного ящика залежить від того, чи має спеціаліст 
із контролю якості доступ до вихідного коду програмного забезпечення або іншого 
типу ПП та чи виконується тестування через інтерфейс користувача або інтерфейс 
прикладної програми. Існує також метод сірої скриньки, який поєднує обидва 
попередні підходи. У роботі розглядається питання побудови фреймворків для 
мобільного додатку та веб-проекту використовуючи стратегію "чорного ящика", 
тобто внутрішня логіка продукту не буде враховуватись. Метою даних фреймворків 
є модернізація та удосконалення класичного підходу до розробки фреймворків 
автоматизації процесу перевірки тестових сценаріїв. Цей фреймворк є 
модернізованою системою з можливостями адаптації під всі види тестових логік, 
які можуть розроблятись для автоматизації тестування. Вся логіка тестування за 
допомогою даного фреймворку розподілена на окремі логічні блоки які пов’язані 
між собою ресурсними файлами, що є досить зручним для швидкого покриття 
логіки ПП та економить часові ресурси порівняно з класичним підходом до 
автоматизованого тестуванням[10]. 
 
1.4 Рівні автоматизації тестування відповідно до 
користувальницького інтерфейсу 
На сьогоднішній день існують різні підходи до автоматизації тестування. 
Загальна стратегія тестування програмного продукту охоплює 3 основні рівні 
автоматизації:  
• рівень модульного тестування (Unit Tests Layer) - компонентні тести, 
зазвичай пишуться розробниками, тестується певна функціональність на етапі 
розробки перед впровадженням до працюючого коду; 
20 
 
• рівень функціонального тестування (Functional Test Layer, or Service / 
API Tests Layer) - тестування через доступ до функціонального прошарку, минаючи 
призначений для користувача інтерфейс; 
• рівень тестування користувальницького інтерфейсу, або через 
призначений для користувача інтерфейс (GUI Test Layer) - дає можливість 
тестувати не тільки інтерфейс користувача, а й реалізовувати функціональне 
тестування, тобто виконувати операції, що використовують бізнес логіку програми. 
Оскільки тестування в своїй суті поділяється на певні рівні тож 
рекомендується автоматизовувати тестові сценарії на всіх цих рівнях (рис.1.6)[13]. 
 
 
Рис. 1.6. Піраміда тестування 
  
21 
 
1.5 Підходи до автоматизації тестування. Патерни для побудови 
структури автоматизаційних фреймворків тестування 
На сьогоднішній день автоматизація тестування веб-інтерфейсу 
користувачем налічує 4 основні солід підходи: 
• Capture / Playback – запис і відтворення сценаріїв використання. Даний 
підхід передбачає використання специфічних утиліт та ПП запису і відтворення дій 
користувача, записуючих певну послідовність дій і потім її відтворюють вже без 
участі користувача. Такі тести створюються легко і швидко, але за будь-яких змін 
функціональності чи інтерфейсу вимагають постійного відтворення згідно зі 
змінами; 
• Scripting – написання тестового сценарію. Методологія полягає у 
написанні тестових сценаріїв на мовах програмування, розроблених спеціально для 
автоматизації тестування. Даний підхід вирішує проблеми з масштабуванням і 
підтримкою тестів, відкриває великі можливості. Але при цьому є більш дорогим, 
що вимагає більшої кількості ресурсів, оскільки розробкою займаються спеціалісти 
більш високого рівня; 
• Data-driven testing – управління даними для тестових сценаріїв. 
Методологія створення тестових скриптів і верифікація їх на основі даних, що 
зберігаються на будь-якому хості або БД. Використовується у випадках, якщо 
необхідно реалізовувати однотипні види перевірок для множинних варіантів 
вхідних даних; 
• Keyword-based – Тестування функціональності за ключовими словами. 
Тест являє собою не програмний код, а послідовність дій з їх параметрами, описану 
за допомогою ключових слів. Це дає можливість людям, які не мають відношення 
до специфіки програмування створювати тестові скріпти та сценарії[13].  
Для проектів які розраховані на довгострокову підтримку найбільш 
ефективними підходами є другий та третій. 
22 
 
Отже патерн-проектування – це певний, загальний спосіб вирішення певного 
ряду проблем які можуть виникнути при проектуванні програмного продукту або 
забезпечення. Якби то не було зручно для розробки, але патерн-проектування не є 
готовим рішенням для роботи який можна відразу скопіювати та інтегрувати у свій 
проект. Кожен патерн має в своїй структурі узагальнений опис вирішення певної 
проблеми з якою може зіштовхнутись розробник під час роботи але кожен патерн 
можна адаптувати під свій робочий проект та зробити свою, специфічну реалізацію 
(рис.1.7)[14]. 
 
 
Рис. 1.7. Логіка роботи патерна-проектування 
 
Важливо не просто приносити дизайн-патерни в свій проект тільки тому, що 
вони є і їх можна використовувати, важливо розуміти їх призначення для вашого 
проекту, їх проблематику, як і чим вони можуть вам допомогти в розробці. 
Основними драйверами практично всіх патернів в автоматизації тестування є 
такі фактори: надійність, зрозумілість, гнучкість, адаптивність, стабільність та інші 
подібні фактори, які важливі у ваших тестах (рис.1.8). 
23 
 
 
Рис. 1.8. Патерн драйвери 
 
Більшість цих факторів перебуває під впливом поділу концепції: у будь-якому 
тесті – функціональному, інтеграційному, unit-тесті – завжди є три компоненти: 
тестова логіка, тестові дані та application driver, або technical details, technical parts – 
частина, що відповідає за безпосередню взаємодію з додатком, кодом (виклик 
функцій, кліки на екран тощо).   
Якщо ці частини добре розділені, ваші тести починають добре потрапляти до 
вищезазначених факторів, тому що в цьому випадку ними набагато простіше 
маніпулювати, набагато простіше їх розуміти та підтримувати. 
Патерн Page Object. Патерн Page Object був розроблений для тестування веб-
додатків, але його ідеї сьогодні використовуються у всіх інших видах автоматизації 
тестування, і існують різні способи реалізації цього патерну оскільки він дає 
можливості використовувати його в різних інтерпретаціях (рис. 1.9).  
Основна перевага в його використанні є те, що при зміні інтерфейсу 
достатньо модифікувати код тесту лише в одному місці, де були ініціалізовані 
локатори (методи які виконують роль зв’язкових з GUI)[15].  
24 
 
На даний момент патерн проектування Page Object є один з найбільш відомих 
патернів проектування. Його організація структури проекту дозволяє значно 
спростити тестову підтримку та зменшити дублювання коду. 
Основними ідеями цього патерну проектування є: 
• чіткий розподіл між власне тестовими сценаріями і кодом, який 
направлений на роботу з локаторами і веб-елементами; 
• наявність єдиного місця зберігання для всіх сервісів та логічних 
операцій, представлених в середовищі розробки, а не хаотично розкидані куски 
логіки. 
 
 
Рис. 1.9. Модель роботи патерна Page Object 
 
Патерн Page Factory. Створення великої кількості однакових тестових 
сценаріїв може призвести до нагромадження коду в проекті та повторення логічних 
операцій що може призвести до складнощів у підтримці проекту. 
25 
 
Однією з основних причин є надмірне дублювання коду. Дублювання коду 
може бути спричинене повторенням логічних операцій в роботі з GUI та його 
функціональності, а це може призвести до повторного використання локаторів та 
логічних функцій.  
Недоліком повторюваного коду є те, що проект є менш зручним для 
супроводу та підтримки якщо, наприклад з проектом працюють декілька інженерів 
то вірогідність дублювання є великою. Якщо змінюється логіка відповідно і може 
змінитись локатор який працює з елементами цієї логіки, в цьому випадку потрібно 
буде пройтись по всьому проекту, щоб відкоригувати локатори там, де це 
необхідно. 
Використовуючи патерн Page Object з Page Factory, ми можемо зробити 
тестовий проект гнучким і зменшити або усунути дублікати тестового коду.  
Реалізація об'єктної моделі сторінки може бути досягнута шляхом розділення 
абстракції тестового об'єкта і тестових скриптів. 
Патерн Page Factory у фреймворках Selenium/Selenide є розширенням патерну 
Page Object у проектуванні тестових сценаріїв. Він використовується для 
ініціалізації елементів об'єкта сторінки або для створення самого об'єкта сторінки.  
Також можна створювати анотації елементів, оскільки описові властивості не 
завжди можуть бути достатньо змістовними, щоб була можливість викликати один 
об'єкт з іншого (рис.1.10)[15]. 
 
26 
 
 
Рис. 1.10. Патерн Page Factory 
 
Патерн проектування Builder. Патерн проектування, який дозволяє 
поетапно створювати складні об'єкти за допомогою чітко визначеної послідовності 
дій. Будівництво контролюється об'єктом-розпорядником (director), якому потрібно 
знати лише тип об'єкта, що створюється (рис. 1.11)[16]. 
 
Рис. 1.11. Builder патерн 
27 
 
• Патерн проектування Builder розроблено для забезпечення гнучкого 
вирішення різних завдань створення об'єктів в об'єктно-орієнтованому 
програмуванні. 
• Патерн проектування Builder дозволяє відокремити побудову 
складного об'єкта від його уявлення. 
• Патерн Builder створює складні об'єкти, використовуючи прості об'єкти 
та поетапний підхід. 
• Патерн надає один із найкращих способів створення складних об'єктів. 
• Це один з патернів проектування банди чотирьох (GoF), які описують, 
як вирішувати завдання проектування, що періодично виникають, в об'єктно-
орієнтованому програмному забезпеченні. 
Якщо звернутись до (рис. 1.11) то можна розділити патерн Builder на такі 
компоненти: 
• Product (продукт) – Клас, який визначає складний об'єкт, який ми 
намагаємося крок за кроком сконструювати, використовуючи прості об'єкти. 
• Builder (будівельник) - абстрактний клас/інтерфейс, який визначає всі 
етапи, необхідні для виробництва складного об'єкта- продукту . Зазвичай, тут 
оголошуються (абстрактно) всі етапи (buildPart), які реалізація належить до класам 
конкретних будівельників (ConcreteBuilder). 
• ConcreteBuilder (конкретний будівельник) - клас-будівельник, який 
надає фактичний код для створення об'єкта- продукту . У нас може бути кілька 
різних ConcreteBuilder -класів, кожен з яких реалізує різний різновид або спосіб 
створення об'єкта- продукту . 
• Director (розпорядник) – супервізійний клас, під контролем якого 
будівельник виконує скоординовані етапи створення об'єкта-продукту[16].  
 
 
28 
 
1.6 Аналіз фреймворків для управління тестовими сценаріями 
TestNG. Тестовий фреймворк, створений Cédric Beust, допомагає 
задовольнити значну кількість потреб AQA & Dev у тестуванні. А саме, TestNG дає 
розробнику можливість створювати більш гнучкі та потужні тести. TestNG широко 
використовується разом з Selenium. 
Що ж означає абревіатура NG? Вона означає “Next Generation” ( “Наступне 
покоління”). TestNG схожий на JUnit, але він більш продуктивний, коли справа 
стосується управління потоком виконання програми. Архітектура фреймворку 
допомагає нам зробити тести більш структурованими та забезпечити кращі точки 
валідації[20]. 
Декілька моментів, якими TestNG допоможе вам якісно управляти 
автотестами в проекті: 
• Потужні і різноманітні анотації для підтримки тест-кейсів. 
• TestNG використовує більше можливостей Java і OOП 
• Розділяє тестовий код часу компіляції і інформацію про конфігурацію 
даних часу виконання. 
• Паралельне виконання тестів, використання залежностей між тестами. 
Скажімо тестування навантаження і часткової відмови. 
• Гнучкість виконання тестів з різними наборами даних, через файл 
TestNG.xml або через концепцію постачальників даних (data-provider). 
• Угруповання і пріоритизація тест-кейсів. 
• Генерація HTML-звітів, встановлення додаткового ПЗ з різних плагінів. 
• Особливо важливо гнучкий плагін API. 
• Генерація логів виконання тестів. 
• Легка інтеграція з Eclipse, IntellijIdea, Maven, Jenkins і ін. 
Наступним фреймворком для управління автоматизованими тестами 
розглянемо фреймворк JUnit. 
29 
 
- Junit. Фреймворк з відкритим кодом, який використовується для 
написання та виконання модульних тестів мовою програмування Java. Це одна з 
найвідоміших платформ модульного тестування[20]. 
JUnit має на своєму борту такі функції: 
• Має величезний перелік анотацій для виявлення, виконання та 
підтримки багатьох функцій методів тестування. 
• Є твердження для перевірки очікуваних результатів. 
• Забезпечує Test Runner для виконання тестів. 
• Надає базовий вбудований шаблон, щоб ви могли швидко писати 
невеликі, прості тестові кейси. 
• Тести JUnit допомагають писати незалежні модулі, тим самим 
покращуючи охоплення тестом та якість програми. Це не тільки дозволяє легко 
створювати та виконувати тести, але також надає розробнику чіткий та  явний звіт, 
який позбавляє потреби розробника шукати шлях до звітів та результатів тесту. 
• Поки виконання тесту не проходить плавно, ви можете розслабитися, 
дивлячись на зелену панель прогресу тесту, яка відображається під час виконання, 
тоді як вона попереджає вас червоним, як тільки тест не проходить контрольний 
пункт перевірки. 
Набори тестів можуть бути створені для того, щоб скласти послідовність або 
пов'язаний набір тестів. 
 
1.7 Аналіз процесу діяльності автоматизованого тестування 
Фреймворк автоматизованого тестування розроблений для тестування бізнес-
логіки додатку та виконання певних тестів інженером з автоматизованого 
тестування. Діяльність інженера тестувальника в рамках фреймворку спрямована 
на створення тестових наборів даних, які подаються в систему у вигляді параметрів 
описаних у текстовому документі, та розширення тестових наборів у тих випадках, 
30 
 
коли необхідно протестувати новий функціонал або додати нову валідацію, якщо 
попередня логіка була змінена.  
Класично, інженер з тестування також повинен виконати ряд дій для 
виконання тестових сценаріїв, а саме: запустити тести локально або 
використовуючи якусь СІ і витратити деякий час на виконання автоматизованого 
процесу, а після цього, отримавши результати у вигляді певного репорту 
переходити до наступних тестів, або виправляємо тести, які не пройшли, і 
аналізувати причину їх збою. Візуально цей процес можна зобразити у вигляді 
діаграми послідовності, зображеної на (рис. 1.12)[20].  
Звичайно, такий процес не сильно спрощує процес тестування, а фахівець 
витрачає майже стільки ж часу, скільки і при ручному тестуванні. Даний проект 
вирішує цю проблему шляхом впровадження безперервної інтеграції тестування та 
безперервної інтеграції та розпаралелювання виконання тестів. Це спрощує саме 
тестування і зменшує кількість витраченого часу, а також вартість робіт.  
Користувач такої системи буде аналізувати пройдені тести за результатами, 
які представляються на виході у вигляді звіту з результатами пройдених і не 
пройдених тестів. Процес автоматизації тестування також можна відобразити за 
допомогою діаграми послідовності, але в цій діаграмі з’являються вже поінти які 
відсутні в повній мірі в класичному підході до тестування мануальними 
тестувальниками (рис.1.13)[21]. 
 
31 
 
 
Рис. 1.12. Класична послідовність дій QA інженера на проекті 
 
 
Рис. 1.13. Діаграма послідовності роботи AQA інженера 
32 
 
 
Висновки до розділу 1 
У цьому розділі досліджено загальні методи, процеси, сутності та засоби 
автоматизації тестування. Розглянуто найпопулярніші патерни які використовують 
в автоматизації тестування. Описані переваги та недоліки мунального та 
автоматизованого тестувань. Описана логіка дій робочого процесу мануального 
тестувальника та автоматизатора тестування. Розглянуто основні техніки тест-
дизайну які допомагають прискорити тестування функціональності. 
33 
 
РОЗДІЛ 2 
МОДЕЛІ АВТОМАТИЗОВАНОГО ТЕСТУВАННЯ МОБІЛЬНИХ ТА ВЕБ-
ДОДАТКІВ 
 
  
2.1 Модель тестування мобільних додатків 
Тестування мобільних додатків на сьогоднішній день відіграє важливу і 
досить вагому роль в індустрії розробки додатків на різні мобільні платформи, 
оскільки користувачі все частіше вибирають мобільність в побуті.  
Відносно до структури взаємодії мобільного додатку з його інформаційним 
потоком, наприклад сервер, база даних, то тут на сьогоднішній день це є класична 
система клієнт-серверної архітектури та обмін даними між клієнтом та БД (рис. 
2.1)[22]. 
 
 
Рис. 2.1. Взаємодія клієнта з сервером та БД 
34 
 
В своїй сутності, мобільні додатки поділяються на два основні види, а саме: 
гібридні та нативні. 
  Нативні мобільні додатки. Мобільні додатки називаються нативними, тому 
що вони написані спорідненою мовою програмування для певної специфічної 
платформи. Для Android додатків такою мовою є Java, а для iOS - Objective-C або 
Swift. 
Нативні додатки знаходяться в самому мобільному пристрої, і почати їх 
використовувати можна просто запустивши їх. Вони встановлюються через магазин 
додатків (Play Market на Android, App Store на iOS)[28]. 
Нативні мобільні додатки розроблені спеціально для конкретної платформи і 
можуть використовувати всі можливості пристрою, наприклад:  
• камеру; 
• GPS-датчик; 
• акселерометр; 
• компас; 
• контакти; 
• мікрофон; 
 Вони також можуть розпізнавати стандартні жести, встановлені операційною 
системою, або специфічні жести, що використовуються в конкретному додатку. 
При розробці нативного додатку як і в усій ІТ індустрії є своє специфічні 
плюси та мінуси які можуть впливати на подальший процес автоматизації тестів, 
написаних під певний додаток (табл. 2.1)[28].  
  
35 
 
Таблиця 2.1 
Позитивні та негативні сторони розробки нативних додатків 
Позитивні сторони  Негативні сторони 
Швидкість роботи і продуктивність, що Не є кросплатформними що може приносити 
впливає безпосередньо на адекватність та незручності користувачам.   
стабільність роботи тестів. 
Високий ступінь безпеки, що не дасть Вимагають тривалого періоду розробки тому 
можливості автотестам нашкодити структурі як розробляються під щось окремо та 
даних.  використовують специфічні підходи до 
реалізації. 
Розширений інтерфейс, який дає можливість При внесенні мінімальних змін потребують 
охватити весь спектр взаємодії додатку з оновлення на стороні клієнта. 
девайсом. 
Можливість повною мірою використати весь  
функціонал. 
Здатність працювати без підключення до  
інтернет мережі. 
Максимальна адаптивність до користувача.  
 
Для більшого розуміння специфіки розробки нативних додатків слід звернути 
увагу на дві, основні платформи які позиціонують себе монополістами в цій сфері 
(табл. 2.2). 
Нативні додатки в більшій мірі рекомендується тестувати автоматизованими 
скриптами тою ж мовою, якою вони розроблені для максимального споріднення 
логічних дій.  
  
36 
 
Таблиця 2.2 
Особливості розробки нативних додатків 
 Мова Інструменти Приклади додатків 
програмування розробки 
Android Studio, 
Android Kotlin, Java Android IDE, Intellij 
Google Maps, App 
Idea 
Store, Google Play… 
X-Code, AppCode, 
iOS Swift, Objective-C 
Atom 
 
Гібридні додатки. Гібридні додатки - це поєднання Web та нативних 
додатків. Зокрема, вони розроблені для декількох платформ (кросплатформенні) і 
мають доступ до функціоналу девайса. Такі додатки можна завантажити виключно 
з таких платформ, як Google Play та App Store. При цьому вони мають можливість 
оновлення інформації в режимі офлайн, а для їхньої роботи необхідне підключення 
до інтернету. Без підключення до мережі інтернет веб-функції просто не будуть 
працювати[28]. 
Серед багатьох компаній які приймають рішення розмістити свій продукт на 
мобільному девайсі вибір найчастіше падає на розробку гібридного додатку. Це 
можна пояснити тим, що гібридні додатки здатні поєднувати переваги нативних 
додатків з технологічною актуальністю, яку забезпечують сучасні веб-технології. 
Однак, на відміну від нативних додатків, вартість створення гібридних додатків на 
порядок нижча, а швидкість їхньої роботи вища, але це також може впливати на 
якість додатку який розроблюється. Спорідненість гібридних додатків з веб-
додатками, в свою чергу, дає перевагу в можливості легко і швидко вносити в них 
зміни. Тобто розробникам не потрібно повторно розміщувати додаток у магазині, 
щоб виправити помилки в попередній версії, як це відбувається у випадку з 
нативними додатками.  
37 
 
Розробка гібридного додатку напряму впливає і на фінансові затрати 
компанії, тому як оплата праці розробників є нижчою і розробка ведеться відразу 
для декількох платформ що дає можливість охопити більшу кількість користувачів. 
Але як і в нативних додатках, в гібридних також є свої переваги та недоліки 
(табл. 2.3). 
Таблиця 2.3 
Переваги та недоліки гібридних додатків 
Переваги Недоліки 
При відсутності мережі інтернет можлива не 
Вартість і швидкість розробки додатку 
коректна робота застосунку  
Швидкість роботи значно нижча ніж у 
Розробкою можу займатись мінімальна 
нативних додатків що в свою чергу впливає 
кількість інженерів 
на взаємодію із користувачем 
Використання застосунків на різних 
Мінімалізм в реалізації GUI 
платформах 
Можливість автономно оновлювати додаток   
 
Оскільки гібридні додатки в свою чергу, залежні від наявності мережі 
інтернет і можуть бути також Web-орієнтованими то і розробляються вони мовами 
які частково є також  Web-орієнтованими (табл. 2.4). 
 
Таблиця 2.4 
Особливості підходу реалізації гібридних додатків 
Мови програмування Інструменти розробки Приклади 
HTML, CSS, Java, JavaScript React Native, Xamarin, Flutter, Alibaba, Facebook, 
PhoneGap Slack… 
 
38 
 
Тож основною відмінністю між гібридними та нативними додатками полягає 
в тому, що гібридні додатки створюються під всі можливі платформи, тоді як 
нативний додаток розробляється для певної, одної операційної системи (рис. 2.2). 
 
 
Рис. 2.2. Відмінність в розробці та тестуванні нативного та гібридного додатків 
  
 Після аналізу підходів до розробки мобільних додатків та їх відмінностей, 
перейдемо безпосередньо до підходів автоматизації тестування  цих додатків. 
Автоматизоване тестування мобільних додатків включає в собі певний набір 
інструментів та підходів, які притаманні лише йому, а отже в своїй сутності є 
специфічними. 
 Оскільки всі логічні операції базуються на певній логіці, тестування 
мобільних додатків також не є виключенням. Розглянемо основні підходи до 
тестування мобільних додатків а саме: 
• Функціональне тестування - це найпростіший вид тестування для 
перевірки відповідності вимогам будь-якого додатка. Оскільки більшість додатків, 
засновані на користувацькому інтерфейсі, мобільні додатки вимагають низки 
людських взаємодій з додатком у користувацьких сценаріях[31]; 
39 
 
• Тестування сумісності. Найбільш пріоритетний вид, коли мова йде про 
тестування мобільних додатків. Мета тестування сумісності мобільних додатків 
полягає в тому, щоб переконатися, що ключові функції програми працюють 
належним чином на конкретному пристрої. Сам тест на сумісність не повинен 
займати багато часу і повинен виконуватись одним із перших, і може бути 
спланований заздалегідь. Вирішити, які саме тести на сумісність з мобільними 
пристроями проводити є одним із основних завдань інженера (оскільки 
протестувати додаток на всіх існуючих пристроях неможливо). Тому необхідно 
підготувати матрицю тестів або певний чек-лист з набором можливих комбінацій 
тестів або ідей та визначити їх пріоритетність для клієнта[31]. 
• Тестування локалізації. Сьогодні більшість розроблених додатків є 
глобального використання, і тому дуже важливо враховувати регіональні 
особливості кожної країни, такі як мова регіону, часові пояси місцевості тощо. 
Важливо протестувати функціональність програми при зміні користувачем 
часового поясу. Варто враховувати, що іноді західний дизайн може не підходити  
користувачам зі східних країн і навпаки. 
• Лабораторне тестування. Зазвичай проводять оператори зв'язку, 
виконується шляхом моделювання всієї бездротової мережі. Цей тест проводиться 
для виявлення будь-яких збоїв в системі, коли мобільний додаток використовує 
голос користувача та/або дані для виконання певних специфічних функцій. 
• Тестування продуктивності. Охоплює продуктивність клієнтського 
додатку, сервера та мережі. За допомогою тестування продуктивності можна 
визначити вразливі місця існуючих мереж, серверів і серверних додатків при 
заданому навантаженні і різного типу комбінацій. 
• Навантажувальне тестування - це обов'язковий тест для виявлення 
винятків, зависань і взаємних блокувань, які можуть залишитися непоміченими під 
час тестування функціональності та користувацького інтерфейсу. 
40 
 
• Тестування безпеки. Допомагає виявити всі можливі вразливості щодо 
політик злому, автентифікації та авторизації, безпека даних, управління сеансами 
та інших стандартів безпеки. Програми повинні шифрувати імена користувачів і 
паролі під час автентифікації користувачів у мережі. Один із способів перевірити 
сценарії, пов'язані з безпекою, - це спрямувати дані мобільного пристрою через 
проксі-сервер, наприклад, OWASP Zed Attack Proxy, і шукати можливі винятки в 
роботі безпеки додатку. 
• Юзабіліті-тестування. Оцінює додаток на основі трьох критеріїв для 
певної юзерської аудиторії, а саме: ефективність, точність і повнота, задоволеність 
використання. Дуже важливо проводити юзабіліті-тестування на ранній стадії 
розробки додатку якщо брати до уваги життєвий цикл розробки то тестування 
юзабіліті повинно розпочинатись відразу коли додаток починає нам 
наповнюватись. Цей вид тестування вимагає активної участі тестувальників або 
навіть реальних користувачів, а його результати можуть вплинути на дизайн 
додатку, який буде дуже важко та затратно змінювати на пізніших етапах 
проекту[31]. 
Існує ще безліч різновидів та технік тестування які також можна включити в 
цей список, але відокремимо ще декілька які можуть впливати безпосередньо на хід 
розробки: 
• Installation/Uninstallation testing; 
• Updates Testing; 
• Certification Testing; 
• Screen Orientation / Resolution; 
• Memory Leakage Testing; 
• Available Tools; 
• Touch Screens; 
• Soft & Hard Keys. 
41 
 
 
 Проведемо аналіз стеку інструментів, які використовуються для 
автоматизації тестування, оскільки наш додаток, який ми будемо тестувати є 
гібридного типу тому використаємо для скриптів мову програмування Java. 
Загальна модель автоматизованого тестування  мобільних додатків з 
використанням Appium Server може бути примінена як до нативного так і до 
гібридного типу (рис.2.3). 
 
 
Рис. 2.3. Загальна модель автоматизованого тестування мобільних додатків 
 
Основною відмінністю в тестуванні мобільних додатків це наявність такого 
інструмента як Appium Server, який відіграє роль інтерфейсу між тестовим 
фреймворком та девайсами на яких проводиться тестування додатку. 
Appium Server. Вільно розповсюджуваний фреймворк з відкритим вихідним 
кодом для тестування користувацького інтерфейсу мобільних додатків. Він 
допомагає тестувати нативні, гібридні та веб-додатки і виконувати автоматизоване 
тестування на фізичних пристроях, а також за допомогою емулятора андроїд 
девайса та симулятора iOS девайса. Він пропонує крос-платформне тестування 
42 
 
додатків - єдиний API працює для сценаріїв тестування платформ Android та iOS 
(рис.2.4)[33].  
 
 
Рис. 2.4. Головна сторінка інструмента Appium Server 
 
На (рис.2.4) помічені два основних поля без яких інструмент не зможе 
взаємодіяти з девайсом і тестовими сценаріями, а саме: хост та порт по якому 
формується зв’язок всіх елементів. Стандартно, значення хосту є 127.0.0.1, а порт 
4723, але за бажання ці значення можна міняти на любі інші, головне щоб вони були 
також вказані в усіх інших елементах. 
Оскільки сам по собі Appium Server є лише зв’язуючим елементом між 
тестами та девайсом, то з різновидом детальної взаємодії можна ознайомитись на 
(рис. 2.5).  
43 
 
 
Рис. 2.5. Внутрішня логіка роботи Appium Server з усіма елементами при 
тестуванні 
 
Selendroid. Selendroid - фреймворк для автоматизованого тестування 
мобільних додатків на базі Android. Використовується на ранніх версіях Android - 
до 17-го рівня api (Android 4.2). Але не вище, тому на даний момент вважається 
застарілим (рис. 2.6)[33]. 
 
Рис. 2.6. Логіка роботи фреймворку Selendroid для автоматизації тестування 
мобільних додатків на базі платформи Android  
 
 
44 
 
2.2 Модель тестування Web-додатків та Web-сайтів 
Важливість автоматизації тестування Web-орієнтованих додатків з кожним 
роком набирає все більших оборотів, тому як постійно з’являються нові великі 
проекти яким потрібно витримувати конкуренцію сучасного ринку ІТ індустрії. 
Автоматизація якості вважається досить важливим елементом для 
забезпечення рівня якості що очікується користувачами. Проаналізуємо більш 
детально відмінності між цими сутностями та підходи до їх тестування. 
Веб-додаток - це програмне забезпечення або програма, яку можна відкрити 
за допомогою будь-якого браузера. Зовнішній інтерфейс веб-додатку розробляється 
за допомогою наступних мов програмування та верстки: HTML, CSS, Javascript, які 
підтримуються будь-яким браузером (Opera, Chrome, Mozilla, Safari). У той же час, 
для написання внутрішньої частини програми може бути використана будь-яка 
інша мова програмування або фреймворк, наприклад, Python, PHP, Ruby, Java. 
Як і в мобільних додатках, Web-додаток також має свою, певну логіку дій під 
час його використання (рис. 2.7)[33]. 
 
 
Рис. 2.7. Робота Web-додатку 
45 
 
Основними перевагами Web-додатку є: 
• веб-додатки можна використовувати на будь-якій операційній системі 
(Linux/Unix, MacOS та Windows), оскільки всі вони підтримують сучасні браузери; 
• веб-додатки розробляються та можуть використовувати один і той 
самий код, що й десктопні додатки, їх набагато легше підтримувати в майбутньому; 
• Web-додаток легше розроблювати, оскільки він не передбачає 
задіювання великої кількості елементів ПК (наприклад ядро, процесор або 
відеокарта); 
• на відміну від мобільних додатків, веб-додатки не потребують 
схвалення від будь-яких платформ для випуску свого додатку тобто вони не 
проходять того етапу верифікації як мобільні додатки; 
• Web-додатки є більш економічним варіантом в розробці для будь-якого 
підприємства оскільки вони не потребують підписки чи ліцензій від платформи на 
якій розміщуються, а можуть використовуватися як SaaS-сервіс, що значно 
дешевше[33]. 
Проаналізуємо головні відмінності між Web-додатком та Web-сайтом для 
розуміння розбіжностей автоматизації тестування цих об’єктів (табл.2.5). 
Таблиця 2.5 
Порівняльний аналіз Web-додатку та Web-сайту 
Параметр елемента Web-додаток Web-сайт 
Відображає лише певний ряд 
Створюється для взаємодії з 
Основне призначення  даних без можливості впливу 
користувачем 
на користувача 
В користувача є обмежений Не має можливостей до 
Взаємодія з користувачем 
доступ до даних динамічних змін в логіці 
Обов’язкова автентифікація Не обов’язкова 
Автентифікація для можливості використання автентифікація, або ж її 
ряду функцій взагалі немає 
46 
 
Продовження таблиці 2.5 
Параметр елемента Web-додаток Web-сайт 
Має на борту великий 
Лише статичні дані на 
Завдання та складність функціонал та закриває 
сторінці 
багато потреб користувача 
При спробі змінити щось в 
структурі потрібно робити 
рев’ю всього проекту та Простото в зміні контенту за 
Зміна проекту 
перевіряти чи зміни не який відповідає лише HTML 
вплинули на інший 
функціонал 
 
Після аналізу відмінностей, зрозуміло що Web-сайт є лише певною 
інформаційною сторінкою, для якої запроваджувати автоматизоване тестування 
недоцільно тому зупинимось на Web-додатку. 
Оскільки розробка додатків напряму залежить від контексту, то і самі додатки 
мають певні відмінності в своїй структурі побудови та функціонування, проведемо 
аналіз різновидності додатків для розуміння того, який із підійде найкраще для 
автоматизованого покриття: 
• (Single Page Application) - це односторінковий інтерактивний додаток. 
Основний нюанс того, щоб він не тільки розташовувався на одній сторінці, але і, як 
повноцінний додаток, був інтерактивним при взаємодії з користувачем. Таким 
чином, інформаційний сайт може складатися з однієї сторінки, але, по суті, він не є 
SPA. В односторінковому додатку користувач залишається на одній сторінці, 
перемикаючись між вкладками але не роблячи логічні переходи між сторінками. 
Крім того, завантажуються та оновлюються лише необхідні частини контенту, що 
робить його більш швидкодійним. 
47 
 
Найбільш явним прикладом односторінкового додатку можна розглянути 
систему Gmail. Можна замітити що при перемиканні між списками повідомлень 
адреса сторінки не змінюється. Це відмінна риса SPA. 
Основною мовою для створення SPA є мова програмування JavaScript вона 
дає можливість створити невеликий односторінковий додаток за допомогою 
бібліотеки jQuery. Однак цей варіант не є перспективним для великих комерційних 
проектів в цьому випадку більш валідним буде вибір використовувати фреймворки 
Vue, React або Angular. 
• MPA (Multi Page Applications) - це всім нам відомі з повсякдення 
багатосторінкові веб-додатки. Коли користувач взаємодіє з веб-сайтом, 
завантажуються нові ресурсні сторінки. Тому обмін даними відбувається 
повільніше, ніж у SPA. Особливо, якщо є проблеми з інтернет-з'єднанням або 
хостингом сайту. Як приклад реалізації MPA є більшість реалізованих інтернет-
магазині до прикладу такі як Rozetka та Alibaba. 
• PWA. Прогресивна програма близька за своїми можливостями, 
функціями та якістю користувацького розуміння до нативних комп’ютерних та 
мобільних додатків. Чіткого розподілу розуміння між не-PWA та PWA додатком 
немає. Але можна виділити низку характеристик. Зокрема PWA має містити проксі-
шар (Service Worker) та Web App маніфест. По суті, браузер виступає віртуальною 
машиною для запуску веб-додатків, подібно до того, як операційна система 
запускає додатки які на ній базуються. 
• Service Worker – це проксі-шар між серверною та клієнтською 
частиною. Він знаходиться у браузері та через нього проходять усі запити. Таким 
чином, є два логічних шара фронтенда – в одному прописується інтерфейс 
користувача, в іншому – логіка для певного ряду операцій. Це дозволяє виконувати 
повноцінні програми для мережі інтернет. Service Worker зазвичай пишеться на 
чистому JS[33]. 
48 
 
Отже підведемо певні підсумки, для нашого проекту найбільше підійде Web-
додаток типу MPA, тому як він реалізовує в собі всі основні властивості та 
реалізовує максимальний потік функціональної логіки.  
Проведемо аналіз логіки роботи автоматизованих фреймворків тестування 
для Web-додатків. Оскільки для розробки автоматизований тестів буде 
використовуватись мова програмування Java то з нею працюють два основних 
фреймворки, а саме Selenium WebDriver та Selenide. 
Для початку проаналізуємо підхід з використанням Selenium WebDriver. 
Розглянемо сутність роботи даного фреймворку на практичних розуміннях та 
принципах реалізації. 
Selenium WebDriver. Гнучкий інструмент(Драйвер) для автоматизованого 
тестування мобільних та Web-проектів на основі набору бібліотек для різних мов 
програмування, таких як Java, .Net (C#), Python, Ruby, PHP, Perl, JavaScript (рис.2.8). 
Цей інструмент підтримує основні операційні системи, такі як Windows, 
macOS і Linux/Unix, а також найпоширеніші браузери, такі як Google Chrome, 
Firefox, Safari, Edge і навіть браузери без графічного інтерфейсу. Selenium 
WebDriver найчастіше використовується для об’ємних типів тестування, наприклад 
регресійне та функціональне[33]. 
Архітектура Selenium WebDriver доволі проста та складається з 4-х основних 
елементів: 
• драйвер для конкретного браузера; 
• клієнтська бібліотека Selenium; 
• браузер; 
• протокол JSON Wire (JavaScript Object Notation). 
 
 
49 
 
 
Рис. 2.8. Архітектура Selenium WebDriver 
Selenide. Являється автоматизованою системою тестування програмного 
забезпечення, яка використовується для написання програмного коду, що 
допомагає створювати та надсилати HTTP-запити до сервера/мережі. Крім того, 
однією з основних цілей використання Selenide є створення скриптів, які 
полегшують тестування роботи веб-продуктів. 
Крім того, він допомагає ідентифікувати необхідні веб-об'єкти, перевіряє 
виконання подій і фокусується на роботі з користувацьким інтерфейсом (UI). 
Загалом, можна вважати що Selenide це є певна обгортка над Selenium WebDriver 
яка є більш оптимізованою для користувача, оскільки в ній, користувач оперує 
лише логічними командами по взаємодії з фронтендом, а вся логіка фреймворку 
відпрацьовує під капотом, в  Selenium WebDriver навпаки, користувач бачить всі 
підкапотні дії, тому як він, безпосередньо їх налаштовує перед стартом роботи[33]. 
50 
 
Selenide забезпечує стабільність тестування, вирішуючи проблеми з Ajax 
технологіями та очікуванням появи елемента. Він надає наступні API:  
• підтримка Ajax; 
• інтелектуальне очікування; 
• зручні методи; 
• автоматичні скріншоти; 
• прозорий веб-драйвер. 
При дослідженні інструментів для реалізації автоматизованого тестування, 
для майбутнього фреймворку, по ряду причин було обрано інструмент Selenide, 
через його більш обширну адаптивність то використання та легкий підхід в 
реалізації.  
 
2.3 Порівняльний аналіз мобільної та Web-моделей автоматизації 
тестування 
Під час дослідження моделей та підходів до тестування мобільних та Web-
додатків, було виявлено певний ряд конструктивних відмінностей, як в 
мануальному тестуванні так і в автоматизованому. Основна відмінність в тому, в 
що мобільні додатки встановлюються на девайс, а Web-додатки можна переглядати 
за допомогою браузера. 
В плані автоматизації тестування, основною відмінністю в налаштуванні 
фреймворку є те, що для тестування мобільного додатку потрібно використовувати 
Appium Server який є інтерфейсом між тестовими сценаріями і девайсом, при цьому 
в тестуванні Web-додатку нам потрібен лише інструмент який допоможе нам 
взаємодіяти з логікою фронтенду або бекенду, тож очевидно що реалізація 
фреймворку для автоматизації тестування мобільного додатку є більш складною та 
багатофакторною.  
51 
 
Оскільки тестування мобільних додатків є певною мірою більш специфічним, 
і потребує великої кількості різноманітних девайсів, в цьому випадку, щоб вийти з 
ситуації в якій потрібно багато девайсів, і якщо їх немає в наявності то, на допомогу 
приходять емулятор або симулятор, але вони не є повноцінними девайсами то і 
функціонал в них також обмежений, що ж з приводу Web-застосунків то тут все 
набагато простіше, для тестування потрібно лише ПК та наявність відповідного 
браузера для тестування що дає нам розуміння більш простого підходу в тестуванні. 
 
 
Висновки до розділу 2 
У цьому розділі розглянуто відмінності в сутності тестування мобільних та 
Web-додатків для реалізації автоматизованого тестового фреймворку. Проведено 
детальний аналіз різновидності мобільних додатків та їх розбіжності в реалізації 
тестування. Проведено аналіз сутностей Web-додатку та Web-сайту. Проведено 
аналіз та обрано інструмент завдяки якому буде здійснюватися розробка 
фреймворку. Проведено аналіз розбіжностей в розробці автоматизованого 
фреймворку для мобільних та Web-проектів. 
  
52 
 
РОЗДІЛ 3 
РЕАЛІЗАЦІЯ РОЗРОБКИ ТА АНАЛІЗ ФРЕЙМВОРКІВ ДЛЯ 
АВТОМАТИЗАЦІЇ ТЕСТУВАННЯ  
 
 
3.1 Розробка фреймворку автоматизації тестування для Web-додатку 
Для програмної реалізацію проекту фреймворку було підібрано такі 
інструменти як: 
• інструмент для ініціалізації драйвера Selenoid; 
• фреймворк для збірки проекту Apache Maven; 
• фреймворк для управління тестовими сценаріями TestNG; 
• мова програмування Java 8/11; 
• інструмент для репортування по результату прогону Allure. 
Розробку фреймворку будемо реалізовувати в IDE IntellijIdea, розпочнемо зі 
створення та ініціалізації проекту та всіх фреймворків. 
 
Рис. 3.1. Головне вікно створення нового проекту в IDE 
53 
 
Після створення проекту ініціалізуємо всі залежності для роботи фреймворку, 
основними з яких є: 
• Selenium/Selenide; 
• TestNG; 
• WebDriver; 
• Allure Report; 
• Maven surefire plugin. 
 
 
Рис. 3.2. Ініціалізація залежностей та плагінів для фреймворку 
 
Після ініціалізації всіх елементів що нам потрібні для розробки фреймворку 
в IDE повинна відобразитись вкладка Maven в якій будуть відображатись ці всі 
елементи, завдяки яким з’являється можливість запускати тестові скріпти та 
переглядати репорти по закінченню прогону тестів.  
54 
 
 
Рис. 3.3. Відображення всіх залежностей, плагінів та життєвого циклу Maven 
 
Оскільки ми використовуємо патер Page Object то він відразу формує зручну 
структуру для реалізації всіх функцій та залежностей фреймворку. Відповідно 
розділивши логіку фреймворку на об’єкти які будуть тестуватись та тестові 
сценарії. 
55 
 
 
Рис. 3.4. Структура проекту з використанням Page Object патерна  
 
Основним завданням після налаштування середовища розробки, це 
налаштувати логіку для ініціалізації драйвера  селеноїдом та визначити, на якому 
саме етапі буде відбуватись ця ініціалізація.  
Для визначення етапу ініціалізації драйвера використовується фреймворк 
управління тестовими сценаріями TestNG, а саме анотація до ініт методу  
«BeforeClass» яка буде вказувати тестовому фреймворку коли саме потрібно 
запускати нову сесію драйвера. 
Основними командами методу ініціалізації є конфігурації безпосередньо 
самого Selenium WebDriver який зчитує ці значення та запускає відповідно 
потрібний браузер (рис.3.5). 
В методі setBrowser розписані конфігурації під всі найпопулярніші браузери, 
які в свою чергу також звертаються до налаштувань браузера який буде запускатись 
з тими параметрами які нам потрібні і які можна змінювати за потреби (рис.3.6). 
 
56 
 
 
Рис. 3.5. Конфігурації Web Driver 
 
 
Рис. 3.6. Конфігурації браузера 
 
Після налаштування ініціалізації драйвера, потрібно розробити методи які 
будуть відповідати за алгоритм багаторазової вибірки, який зробить можливим те 
57 
 
щоб фреймворк самостійно зміг підбирати  відповідні налаштування під браузер 
який буде викликано автотестом. 
 Відповідно до задуманої логіки потрібно розробити певні методи які 
допоможуть витягувати  значення з системних файлів та передавати їх методі 
ініціалізатору безпосередньо. 
 Для забору конфігураційного значення було розроблено метод який 
звертається до значення ключа яке лежить в файлі налаштувань та зчитує його 
значення яке потім передає драйверу (рис. 3.7). 
 
 
Рис. 3.7. Метод забору значення конфігурації 
  
Цей метод безпосередньо забирає значення яке йому передає 
конфігураційний файл і вже в тестовому сценарії підбирається відповідний юзер 
який відповідає за дану конфігурацію (рис. 3.8). 
 
 
Рис. 3.8. Змінні які перебирають вхідне значення та направляють його драйверу 
58 
 
3.2 Розробка фреймворку для мобільних додатків  
Для програмної реалізацію проекту фреймворку було підібрано такі 
інструменти як: 
• інструмент для ініціалізації драйвера Selenoid; 
• фреймворк для збірки проекту Apache Maven; 
• фреймворк для управління тестовими сценаріями TestNG; 
• мова програмування Java 8/11; 
• інструмент для репортування по результату прогону Allure; 
• HTTP-сервер Appium;  
• Інструмент запису та відтворення поведінки мобільних додатків Appium 
Inspector.  
Вже навіть зі стеку видно що розробка фреймворку під мобільні додатки 
відрізняються від фреймворку для веб-додатків. 
Перш за все потрібно проініціалізувати Appium Server для того щоб була 
можливість запускати тестові сценарії на мобільних девайсах.  
Перед початком роботи з апіумом потрібно налаштувати системну змінну для 
нього, щоб він між забрати ресурсні дані безпосередньо з файлів налаштувань (рис. 
3.9). 
 
 
Рис. 3.9. Налаштування системних змінних для Appium Server 
59 
 
 Після налаштування змінних запускаємо Appium Server та перевіряємо чи 
змінні відображають (рис.3.10). 
 
 
Рис. 3.10. Конфігураційне вікно Appium Server 
 
 Для старту та логічного зв’язку з девайсами потрібно вказати хост та порт на 
головному вікні, по яким будемо викликати девайси (рис. 3.11). Хост змінюємо на 
«127.0.0.1», а порт залишаємо в дефолтному значенні. 
 
 
Рис. 3.11. Налаштування хосту та потру для Appium 
60 
 
Після цього перевіряємо налаштування в вкладці «Advanced» за потреби 
можемо вказати потрібні нам дані відразу там та конфігурувати Appium більш 
детальніше, але зазвичай, всі значення залишаються дефолтними (рис. 3.12). 
 
 
Рис. 3.12. Додаткові налаштування Appium Server 
 
Після всіх налаштувань запускаємо сесію Appium Server та перевіряємо чи 
все коректо створилось. При успішному налаштуванні  повинно відкритись 
консольне вікно з відомостями по створену сесію (рис. 3.13). 
 
61 
 
 
Рис. 3.13. Створення сесія для Appium Server  
 
Наступний етап це розробка фреймворку для автоматизації мобільного 
додатку. Розробка буде вестись в IDE Intellij Idea. Створення початкового проекту 
має таку ж логіку як і в веб-застосунка. 
 Налаштування роботи фреймворка для збірки трішки відрізняється, для 
мобільних додатків недостатньо стандартного набору плагінів та залежностей. Для 
запуску автотестів для мобільного додатку потрібно додати до проекту залежності 
Appium Server (Рис.3.14). Дані залежності напряму впливають на те чи запуститься 
взагалі драйвер який підтримує тестування мобільних додатків, оскільки для 
тестування не підходить класичний WebDriver, в Appium Server є свої власні 
драйвера які розроблені під платформи Android і iOS. 
  
 
62 
 
 
Рис. 3.14. Системні налаштування Apache maven build framework 
 
Для запуску драйвера розроблено метод який містить в собі певну логічну 
умову, даний метод схожий по своїй суті з алгоритмом вибору середовища який 
реалізований в Web-проекті але з певною специфічною логікою зображено на (рис. 
3.15).  
Метод відпрацьовує таким чином, що при передачі йому значення платформи 
він методом вибірки підбирає метод ініціалізації відповідного платформі драйвера 
і потім через Appium Server викликає зв’язується через порт з девайсом, це може 
бути як реальний девайс так і віртуальний.   
 
63 
 
 
Рис 3.15. Алгоритмічний метод вибірки платформи 
 
В статичному значенні метод буде викликати локальний Appium Server, але 
якщо використовувати для роботи СІ, і через системні ключі передавати відповідне 
значення, або перезаписувати його в файлі конфігурації то один і той же проект 
можна запускати одночасно на різних платформах. 
Дана конструкція показує максимальну динамічність в різних можливих 
ситуаціях, навіть якщо використовувати декілька потоків то всі тести будуть 
займати вільний девайс не перешкоджаючи іншим тестовим скриптам. 
64 
 
Під використання локального дефолтного значення апіума розписано 
кастомний енум з характеристиками які не будуть змінюватись, тому локальні 
прогони не зможуть відобразити даний алгоритм тому як сам по собі мобільний 
драйвер не підтримує багатопоточність. 
Однією із основних переваг розробки автотестів для мобільних платформ, 
локатори можна використовувати як і від мобільного драйвера та і від Selenide, дана 
можливість дає змогу використовувати обширний потенціал. 
При роботі з мобільними додатками, останні не дають можливості 
переглянути їх фронтенд, як це можна зробити, наприклад з Web-додатком, тому 
для цього було розроблено спеціальний інструмент, Appium inspector, який відіграє 
роль зчитувача та записувача (рис.3.16). 
 
 
Рис. 3.16. GUI Appium Inspector 
 
65 
 
 Appium Inspector напряму зв’язується з девайсом який є активний, за 
допомогою adb інтерфейсу та зчитує фронтенд, це може бути як робочий стіл так і 
відкритий додаток. 
 Для того щоб зчитати девайс, потрібно налаштувати зв’язок з драйвером, 
який в свою чергу зв’язується з девайсом, для того щоб налаштувати зв’язок з 
драйвером потрібно вказати шлях до драйвера у відповідному полі (рис. 3.17). 
 
 
Рис. 3.17. Поле введення шляху знаходження WebDriver 
 
 Після того як шлях буде вказано, потрібно вказати параметри девайса який 
буде підключено до зчитувача (рис. 3.18). 
 
 
Рис. 3.18. Ініціалізація девайса в зчитувачі 
 
Після ініціалізації девайса, зчитувач запускає сесію та відкриває фронтенд додатку 
для того щоб можна було формувати локатори, які вже потім в проекті можна 
підв’язувати під логічні операції. 
 
66 
 
 3.3 Порівняльний аналіз підходів до тестування мобільних та Web-
додатків 
 Виходячи з практичного дослідження можливостей реалізації автоматизації 
тестування в роботі із мобільними та Web-додатками, наявним фатом є те, що підхід 
до автоматизації мобільних додатків є більш громістким ніж  тестування інтерфейсу 
Web-додатків оскільки, самі по собі, мобільні додатки не можуть бути учасниками 
автономного тестування тому як вони збираються в ожин файл (білд) та не дають 
можливість того щоб звичайний користувач зміг добратись в середину, або навіть 
побачити фронтенд, все що ми можемо бачити використовуючи мобільні додатки 
це їхні GUI, тобто те, що нам дали побачити розробники. 
  В свою ж чергу, Web-додатки не є файлами які потрібно встановлювати, 
єдине що нам потрібно це Web-браузер завдяки якому ми і можемо споглядати 
додатки або сайти, різного виду та насичення і безпосередньо бачити їх фронтенд 
та без перешкод взаємодіяти із ними. 
 В підсумку можна сказати, мобільні додатки вимагають в спеціалістів більш 
обширних знань та використання різного виду технологій та інструментів, що в 
свою чергу, робить автоматизацію тестування мобільних додатків більш ємкою в 
своїй суті.  
 
Висновки до розділу 3 
Розроблено два фреймворки які використовують модернізовані алгоритми 
багаторазової вибірки. Сформовано динамічну логіку зв’язку із зчитувачами та 
можливість запускати тести в декілька потоків для мобільних додатків. 
 Зроблено порівняльний аналіз для реалізованих фреймворків, виділено їх 
основні та специфічні аспекти в реалізації які є унікальними для кожного підходу. 
 Охарактеризовано вибір стеку для розробки який є в топ 3 розробки для 
автоматизованих фреймворків тестування.  
67 
 
ВИСНОВКИ 
 Основні результати отримані у кваліфікаційній роботі. 
 Кваліфікаційна робота полягала у розробці та дослідженні сутності підходу 
до автоматизації тестування мобільних та Web-додатків на основі алгоритму 
вибірки вільного потоку для розпаралелювання робочих потоків під час прогону 
автоматизованих скриптів.  
 Алгоритм на якому базується метод вибірки працює за рахунок визначення 
середовища в якому запускаються тести та після його визначення 
використовуються відповідні користувачі які виконують певні тестові скріпти. 
 Проведено аналіз рентабельності даного підходу, методом визначенні КПД 
після запуску тестових с’ютів, за результатом прогонів, використання алгоритму 
скоротило час проходження тестів в 2-3 рази, в залежності від проекту та кількості 
тестових сценаріїв. 
 Оскільки мобільні тестові сценарії по своїй суті проходять довше, в 
залежності від середовища (локальне / віддалено на сервері) то використання 
алгоритму дає нам можливість запускати тестові сценарії відразу в декілька потоків, 
дивлячись скільки в нас є девайсів, тому як один девайс це один потік, а один потік 
це один тестовий кейс що в свою чергу досить сильно впливає на час проходження 
всіх кейсів. Під час тестування алгоритму та проведеного аналізу можливостей 
інших подібних підходів, які є в свою чергу занадто громісткими та не завжди дають 
той результат який би хотілось отримати під час тестуванні мобільних  та Web-
додатків, запропонований алгоритм надає можливість динамічно використовувати 
потоки проходження  для тестових сценаріїв та надавати їм можливість не 
конкурувати між собою, якщо запуск буде відбуватись одночасно на декількох 
платформах, що дає нам стабільність та точність отриманих даних в кінці. 
 Запропонований алгоритм вже впроваджений в робочу систему 
функціонування автоматизаційного тестування, відпрацювання виконуються як 
68 
 
локально так і за допомогою СІ, результати можна вирівнювати та оптимізувати в 
реальному часі та виправляти певного роду конфлікти в потоках, якщо такі 
з’являються. 
 Проведені науково-дослідницькі роботи з розроблення та аналізу можливих 
реалізацій подібної логіки, але в своїй сутності вони не здатні до динамічних змін 
багатопоточності як то реалізовано в представленому в роботі алгоритмі.  
     
69 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Marselis, R. & Roodenrijs, E. «the PointZERO vision», 2012, ISBN 978-90-
75414-55-4 
2. Accreditation and Quality Assurance: Journal for Quality, Comparability and 
Reliability in Chemical Measurement [Архівовано 21 вересня 2020 у Wayback 
Machine.], ISSN 0949-1775 Print, ISSN 1432-0517 
3. Praxiom Research Group Limited (16 August 2017). "ISO 9001 Translated 
Into Plain English". Praxiom Research Group Limited. Retrieved 29 November 2017. 
4.  "ISO 13485:2016". ISO. Retrieved 2020-12-26. 
5.  "Electronic Code of Federal Regulations (eCFR)". Electronic Code of 
Federal Regulations (eCFR). Retrieved 2020-12-26. 
6.  "Managing Quality Across the Enterprise: Enterprise Quality Management 
Solution for Medical Device Companies". Sparta Systems. 2015-02-02. 
7.  "Leslie E. Simon 1924". West Point Association of Graduates. Archived 
from the original on 29 November 2017. Retrieved 29 November 2017. 
8. Woods, Anthony J. (June 5, 2015). "Operational Acceptance – an application 
of the ISO 29119 Software Testing standard" (Whitepaper). Capgemini Australia. 
Retrieved January 9, 2018. 
9. Auerbach, Adam (August 3, 2015). "Part of the Pipeline: Why Continuous 
Testing Is Essential". TechWell Insights. TechWell Corp. Retrieved January 12, 2018. 
10. "Test-Driven Development and Continuous Integration for Mobile 
Applications". msdn.microsoft.com. January 14, 2009. Retrieved March 17, 2018. 
11. Saieva, Anthony; Singh, Shirish; Kaiser, Gail (September 2020). "Ad hoc 
Test Generation Through Binary Rewriting". 2020 IEEE 20th International Working 
Conference on Source Code Analysis and Manipulation (SCAM). Adelaide, Australia: 
IEEE. pp. 115–126. doi:10.1109/SCAM51674.2020.00018. ISBN 978-1-7281-9248-
2. S2CID 219618921. 
70 
 
12. Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "A General 
Testability Theory: Classes, properties, complexity, and testing reductions". IEEE 
Transactions on Software Engineering. 40 (9): 862–
894. doi:10.1109/TSE.2014.2331690. ISSN 0098-5589. S2CID 6015996. 
13. Bossavit, Laurent (November 20, 2013). "The cost of defects: an illustrated 
history". The Leprechauns of Software Engineering: How folklore turns into fact and what 
to do about it. leanpub. 
14. Sharma, Bharadwaj (April 2016). "Ardentia Technologies: Providing 
Cutting Edge Software Solutions and Comprehensive Testing Services". CIO 
Review (India ed.). Retrieved December 20, 2017. 
15. Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand; Fiva, Arno 
(September 2007). Contract Driven Development = Test Driven Development – Writing 
Test Cases (PDF). ESEC/FSE'07: European Software Engineering Conference and the 
ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007. 
Dubrovnik, Croatia. Retrieved December 8, 2017. 
16. Bourque, P.; Fairley, R.D., eds. (2014). "Chapter 4: Software 
Testing" (PDF). SWEBOK v3.0: Guide to the Software Engineering Body of Knowledge. 
IEEE. pp. 4–1–4–17. ISBN 978-0-7695-5166-1. Archived from the original (PDF) on 
June 19, 2018. Retrieved July 13, 2018. 
17. Lewis, W.E. (2016). Software Testing and Continuous Quality 
Improvement (3rd ed.). CRC Press. pp. 92–6. ISBN 978-1-4398-3436-7. 
18. ^ Machado, P.; Vincenzi, A.; Maldonado, J.C. (2010). "Chapter 1: Software 
Testing: An Overview". In Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcook, J. 
(eds.). Testing Techniques in Software Engineering. Springer Science & Business Media. 
pp. 13–14. ISBN 978-3-642-14334-2. 
19. O’Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, 
Murat; Poth, Alexander; Messnarz, Richard (2015-10-15). Systems, Software and 
71 
 
Services Process Improvement: 22nd European Conference, EuroSPI 2015, Ankara, 
Turkey, September 30 -- October 2, 2015. Proceedings. Springer. ISBN 978-3-319-
24647-5. 
20. Кодола Г. М. Автоматизоване тестування веб-додатків з різнорівневою 
архітектурою / Г. М. Кодола, Н. С. Волинець, І. В. Сербулова // Вісник 
Національного технічного університету "ХПІ". Сер. : Нові рішення в сучасних 
технологіях = Bulletin of the National Technical University "KhPI". Ser. : New solutions 
in modern technology : зб. наук. пр. – Харків : НТУ "ХПІ", 2019. – № 5 (1330). – С. 
91-100. 
21. Troyan, A. M, Modenov, Yu. B. Dotsilʹnistʹ avtomatyzovanoho testuvannya 
dlya zabezpechennya yakosti prohramnykh produktiv [The expediency of automated 
testing to ensure the quality of software products]. Problemy informatyzatsiyi ta 
upravlinnya [Problems of informatization and management]. – Kyiv: Research Institute 
of ITT NAU, 2 
22. Lakshmi, D. Rajya. A Review on Web Application Testing and its Current 
Research Directions / D. Rajya Lakshmi, S. Suguna Mallika // International Journal of 
Electrical and Computer Engineering (IJECE). – 2017. – Vol. 7, No. 4. – Р. 2132-2141. – 
doi: 10.11591/ijece.v7i4.pp2132-2141. 
23. Comparing Automated Testing Tools: Selenium, TestComplete, Ranorex, 
and more. URL: https://www.altexsoft.com/blog/engineering/comparingautomated-
testing-tools-selenium-testcomplete-ranorex-andmore/ 04.02.2019. 
24. Silva, R. A. A Systematic Review on Search Based Mutation Testing / 
Rodolfo Adamshuk Silva, Simone do Rocio Senger de Souza,Paulo Sergio Lopes de 
Souza // Information and Software Technology. – 2017. – Vol. 81, Issue С. – Р. 19-35. – 
doi: 10.1016/j.infsof.2016.01.017. 
72 
 
25. Arora, A., Sinha, M. Web Application Testing: A Review on Techniques, 
Tools and State of Art. International Journal of Scientific & Engineering Research, 2012, 
3(2), 1- 5. 
26. Girgis, M. R., Mahmoud, T. M., Abdullatif, B. A., Zaki, A. M. An Automated 
Web Application Testing System. International Journal of Computer Applications (0975 
– 8887), 2014, 99(7), 37-44, doi: 10.5120/17387- 7926. 
27. Zhivotova, A. A., Modenov, Yu. B. Metody ta zasoby testuvannya web-
dodatkiv [Methods and tools for testing web-applications] Problemy informatyzatsiyi ta 
upravlinnya [Problems of informatization and management]. – Kyiv: Research Institute 
of ITT NAU, 2014, 2(46), 27-30, doi: 10.18372/2073-4751.2.7711. 
28. The Art of Software Testing / Glenford J. Myers, Revised and Updated by 
Tom Badgett, Todd M.Thomas, Corey Sandler. - 2nd ed. - Hoboken, New Jersey.: John 
Wiley & Sons, Inc., 2004 - 234 p. 
29. . Farrell, C. Harrison N. Under the Hood of .NET Memory Management. 
Simple Talk Publishing. 2011. 213 с. ISBN 978-1-906434-74-8. 
30. M. E. Khan. A Comparative Study of White Box, Black Box and Grey Box 
Testing Techniques / M. E. Khan, F. Khan // IJACSA. – 2012. – Vol. 3, No.6. – pp. 12-
15. 
31. Д. В. Федасюк. Метод побудови сценаріїв тестування програмного 
забезпечення на основі аналізу його змінних / Д. В. Федасюк, В. С. Яковина, П. В. 
Сердюк, О. О. Нитребич // Інформаційні технології та комп'ютерна інженерія. – 
2014. – № 2. – С. 50–58. 
32. D. Kovalenko. Selenium Design Patterns and Best Practices. – Packt 
Publishing Limited. – 2014. – 270 p. 
33. D. Kumar. The Impacts of Test Automation on Software’s Cost, Quality and 
Time to Market / D. Kumar, K. K. Mishra // Procedia Computer Science. – 2016. – No 
79. – 8-15. 
73 
 
ДОДАТОК А 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
 
 
 
 
 
 
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ РОЗРОБЛЕНИХ ФРЕЙМВОРКІВ 
АВТОМАТИЗАЦІЇ ТЕСТУВАННЯ З ВИКОРИСТАННЯМ АЛГОРИТМУ 
БАГАТОПОТОЧНОСТІ  
 
Текст програми 
 
 
 
 
Листів 6 
 
 
 
 
 
 
 
2023 
 
74 
 
 
    private static final AndroidApplication application = new AndroidApplication(); 
    protected AppiumDriver appiumDriver; 
    protected BaseUser testUser; 
    @BeforeSuite(alwaysRun = true) 
    protected void setUpListeners() { 
        Configuration.timeout = 8000; 
        Configuration.holdBrowserOpen = true; 
        setSelenideListener(); 
        setReportPortalListener();} 
    @BeforeMethod 
    protected void startApp(Method method, ITestResult iTestResult) throws Exception { 
        logPreConditionStep("Start the app"); 
        appiumDriver = application.startApp(); 
        waitForAppLoaded(); } 
    @AfterClass(alwaysRun = true) 
    protected void tearDown() { 
        if (appiumDriver != null) { 
            appiumDriver.quit(); 
        }} 
    private void setSelenideListener() { 
        SelenideLogger.addListener("AllureSelenide", new AllureSelenide() 
                .screenshots(true) 
                .savePageSource(false) 
                .includeSelenideSteps(true));} 
    private void setReportPortalListener() { 
        SelenideLogger.addListener( 
                Base.testProperties.reportPortalListener(), 
                new ReportPortalSelenideEventListener(). 
                        logScreenshots(true). 
                        logPageSources(false)  ); }} 
<?xml version="1.0" encoding="UTF-8"?> 
75 
 
<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-
4.0.0.xsd"> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>org.example</groupId> 
    <artifactId>TikSchool_mobile</artifactId> 
    <version>1.0-SNAPSHOT</version> 
    <properties> 
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
        <maven-surefire-plugin.version>3.0.0</maven-surefire-plugin.version> 
        <junit-platform-surefire-provider.version>1.3.1</junit-platform-surefire-provider.version> 
        <aspectj.version>1.9.19</aspectj.version> 
        <maven.compiler.source>11</maven.compiler.source> 
        <maven.compiler.target>11</maven.compiler.target> 
    </properties> 
    <dependencies> 
        <dependency> 
            <groupId>org.aspectj</groupId> 
            <artifactId>aspectjweaver</artifactId> 
            <version>${aspectj.version}</version> 
        </dependency> 
        <dependency> 
            <groupId>io.rest-assured</groupId> 
            <artifactId>rest-assured</artifactId> 
            <version>5.3.0</version> 
        </dependency> 
        <dependency> 
            <groupId>com.codeborne</groupId> 
            <artifactId>selenide</artifactId> 
            <version>6.19.1</version> 
        </dependency> 
76 
 
        <!-- https://mvnrepository.com/artifact/commons-io/commons-io --> 
        <dependency> 
            <groupId>commons-io</groupId> 
            <artifactId>commons-io</artifactId> 
            <version>2.15.0</version> 
        </dependency> 
        <dependency> 
            <groupId>org.assertj</groupId> 
            <artifactId>assertj-core</artifactId> 
            <version>3.24.2</version> 
            <scope>compile</scope> 
        </dependency> 
        <dependency> 
            <groupId>io.qameta.allure</groupId> 
            <artifactId>allure-testng</artifactId> 
            <version>2.23.0</version> 
            <scope>test</scope> 
        </dependency> 
        <dependency> 
            <groupId>io.qameta.allure</groupId> 
            <artifactId>allure-selenide</artifactId> 
            <version>2.23.0</version> 
        </dependency> 
        <dependency> 
            <groupId>org.aeonbits.owner</groupId> 
            <artifactId>owner</artifactId> 
            <version>1.0.12</version> 
        </dependency> 
        <dependency> 
            <groupId>org.awaitility</groupId> 
            <artifactId>awaitility</artifactId> 
            <version>4.2.0</version> 
77 
 
        </dependency> 
        <dependency> 
            <groupId>org.testng</groupId> 
            <artifactId>testng</artifactId> 
            <version>7.8.0</version> 
            <scope>compile</scope> 
        </dependency> 
        <dependency> 
            <groupId>io.qameta.allure</groupId> 
            <artifactId>allure-rest-assured</artifactId> 
            <version>2.23.0</version> 
        </dependency> 
        <dependency> 
            <groupId>com.codeborne</groupId> 
            <artifactId>selenide-appium</artifactId> 
            <version>6.19.1</version> 
        </dependency> 
        <dependency> 
            <groupId>org.slf4j</groupId> 
            <artifactId>slf4j-api</artifactId> 
            <version>2.0.9</version> 
        </dependency> 
        <dependency> 
            <groupId>org.slf4j</groupId> 
            <artifactId>slf4j-log4j12</artifactId> 
            <version>2.0.9</version> 
        </dependency> 
        <!--                https://mvnrepository.com/artifact/io.testerra/selenoid-connector--> 
        <dependency> 
            <groupId>io.testerra</groupId> 
            <artifactId>selenoid-connector</artifactId> 
            <version>2.0</version> 
78 
 
        </dependency> 
        <dependency> 
            <groupId>com.github.javafaker</groupId> 
            <artifactId>javafaker</artifactId> 
            <version>1.0.2</version> 
        </dependency> 
        <dependency> 
            <groupId>com.epam.reportportal</groupId> 
            <artifactId>agent-java-testng</artifactId> 
            <version>5.3.1</version> 
        </dependency> 
        <dependency> 
            <groupId>com.epam.reportportal</groupId> 
            <artifactId>logger-java-log4j</artifactId> 
            <version>5.1.5</version> 
        </dependency> 
        <dependency> 
            <groupId>com.epam.reportportal</groupId> 
            <artifactId>logger-java-selenide</artifactId> 
            <version>5.1.4</version> 
        </dependency> 
        <dependency> 
            <groupId>com.epam.reportportal</groupId> 
            <artifactId>logger-java-logback</artifactId> 
            <version>5.1.6</version> 
        </dependency> 
        <dependency> 
            <groupId>com.googlecode.json-simple</groupId> 
            <artifactId>json-simple</artifactId> 
            <version>1.1.1</version> 
        </dependency> 
 
79 
 
        <dependency> 
            <groupId>org.projectlombok</groupId> 
            <artifactId>lombok</artifactId> 
            <version>1.18.28</version> 
            <scope>provided</scope> 
        </dependency> 
        <dependency> 
            <groupId>log4j</groupId> 
            <artifactId>log4j</artifactId> 
            <version>1.2.17</version> 
        </dependency> 
        <dependency> 
            <groupId>org.selenide</groupId> 
            <artifactId>selenide-selenoid</artifactId> 
            <version>6.15.0</version> 
        </dependency> 
        <!-- https://mvnrepository.com/artifact/com.codeborne/selenide-core --> 
        <dependency> 
            <groupId>com.codeborne</groupId> 
            <artifactId>selenide-core</artifactId> 
            <version>6.19.1</version> 
        </dependency> 
        <!-- https://mvnrepository.com/artifact/io.appium/java-client --> 
        <dependency> 
            <groupId>io.appium</groupId> 
            <artifactId>java-client</artifactId> 
            <version>8.6.0</version> 
        </dependency> 
        <dependency> 
            <groupId>commons-configuration</groupId> 
            <artifactId>commons-configuration</artifactId> 
            <version>1.10</version> 
80 
 
        </dependency> 
        <!-- https://mvnrepository.com/artifact/org.apache.commons/commons-configuration2 --> 
        <dependency> 
            <groupId>org.apache.commons</groupId> 
            <artifactId>commons-configuration2</artifactId> 
            <version>2.9.0</version> 
        </dependency> 
        <dependency> 
            <groupId>org.duraspace</groupId> 
            <artifactId>codestyle</artifactId> 
            <version>1.1.0</version> 
        </dependency> 
        <dependency> 
            <groupId>com.puppycrawl.tools</groupId> 
            <artifactId>checkstyle</artifactId> 
            <version>10.9.1</version> 
        </dependency> 
        <!-- https://mvnrepository.com/artifact/ch.qos.logback/logback-classic --> 
        <dependency> 
            <groupId>ch.qos.logback</groupId> 
            <artifactId>logback-classic</artifactId> 
            <version>1.4.11</version> 
            <scope>test</scope> 
        </dependency> 
    </dependencies> 
    <build> 
        <plugins> 
            <plugin> 
                <groupId>org.apache.maven.plugins</groupId> 
                <artifactId>maven-dependency-plugin</artifactId> 
                <version>3.6.0</version> 
                <executions> 
81 
 
                    <execution> 
                        <id>getClasspathFilenames</id> 
                        <goals> 
                            <goal>properties</goal> 
                        </goals> 
                    </execution> 
                </executions> 
            </plugin> 
            <plugin> 
                <groupId>org.apache.maven.plugins</groupId> 
                <artifactId>maven-compiler-plugin</artifactId> 
                <version>3.11.0</version> 
                <configuration> 
                    <source>11</source> 
                    <target>11</target> 
                </configuration> 
            </plugin> 
            <plugin> 
                <groupId>io.qameta.allure</groupId> 
                <artifactId>allure-maven</artifactId> 
                <version>2.12.0</version> 
                <configuration> 
                    <!--                    <allureDownloadUrl>https://github.com/allure-
framework/allure2/releases/allure-2.21.0.zip</allureDownloadUrl>--> 
                    <reportVersion>2.21.0</reportVersion> 
                    <resultsDirectory>allure-results</resultsDirectory> 
                </configuration> 
            </plugin> 
            <plugin> 
                <groupId>org.apache.maven.plugins</groupId> 
                <artifactId>maven-surefire-plugin</artifactId> 
                <version>3.1.2</version> 
82 
 
                <configuration> 
                    <argLine>                    
javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-
${aspectj.version}.jar" 
                    </argLine> 
                    <systemPropertyVariables> 
                        <name>allure.results.directory</name> 
                        <value>${project.build.directory}/allure-results</value> 
                        <allure.results.directory>target/allure-results</allure.results.directory> 
                    </systemPropertyVariables> 
                    <suiteXmlFiles> 
                        <suiteXmlFile>PropertiesTestNG.xml</suiteXmlFile> 
                    </suiteXmlFiles> 
                </configuration> 
                <dependencies> 
                    <dependency> 
                        <groupId>org.aspectj</groupId> 
                        <artifactId>aspectjweaver</artifactId> 
                        <version>1.9.20.1</version> 
                    </dependency> 
                </dependencies> 
            </plugin> 
        </plugins> 
    </build> 
} 
package webDriver; 
import com.codeborne.selenide.WebDriverProvider; 
import com.codeborne.selenide.WebDriverRunner; 
import io.appium.java_client.AppiumDriver; 
import io.appium.java_client.android.AndroidDriver; 
import io.appium.java_client.ios.IOSDriver; 
import io.appium.java_client.remote.AutomationName; 
83 
 
import io.appium.java_client.remote.MobileCapabilityType; 
import io.qameta.allure.Step; 
import lombok.Getter; 
import lombok.extern.slf4j.Slf4j; 
import org.openqa.selenium.Platform; 
import org.openqa.selenium.WebDriver; 
import org.openqa.selenium.remote.DesiredCapabilities; 
import utils.enums.Application; 
import java.io.File; 
import java.io.IOException; 
import java.net.URL; 
import java.util.ArrayList; 
import java.util.HashMap; 
import java.util.List; 
import java.util.Map; 
import java.util.concurrent.ExecutionException; 
import static core.ConfigReader.emulatorConfig; 
import static helpers.DeviceHelper.executeSh; 
import static io.appium.java_client.remote.AndroidMobileCapabilityType.*; 
import static io.appium.java_client.remote.MobileCapabilityType.*; 
import static org.testng.Assert.assertTrue; 
@Slf4j 
@Getter 
public class AndroidApplication { 
    private final WebDriverProvider webDriverProvider; 
    private AppiumDriver appiumDriver; 
    private final Application application; 
    private static final List<WebDriver> RUNNING_WEBDRIVER_LIST = new ArrayList<>(); 
    private static final String DEVICE_NAME = emulatorConfig.deviceName(); 
    private static final String PLATFORM_NAME = emulatorConfig.platformName(); 
    private static final String APP_PACKAGE = emulatorConfig.appPackage(); 
    private static final String APP_ACTIVITY = emulatorConfig.appActivity(); 
84 
 
    private static final String APP = emulatorConfig.app(); 
    private static final String SELENOID_URL = emulatorConfig.selenoidRemoteURL(); 
    private static final String BROWSER_NAME = emulatorConfig.browserName(); 
    private static final String BROWSER_VERSION = emulatorConfig.browserVersion(); 
    public AndroidApplication() { 
        this.application = Application.getApplicationByType(); 
        this.webDriverProvider = webDriver.WebDriverManager.getWebDriverProvider(application); 
    } 
    public static String getAbsolutePath(String filePath) { 
        File file = new File(filePath); 
        assertTrue(file.exists(), APP + " not found"); 
        return file.getAbsolutePath(); 
    } 
    @Step("Start the remote session") 
    public AppiumDriver startApp() throws Exception { 
        final boolean isRemoteRun = emulatorConfig.selenoidRemoteRun(); 
        if (isRemoteRun) { 
            switch (emulatorConfig.browserName()) { 
                case "android": 
                    appiumDriver = (AppiumDriver) createRemoteSession(); 
                    WebDriverRunner.setWebDriver(appiumDriver); 
                    return appiumDriver; 
                case "iPhone14": 
                    appiumDriver = (AppiumDriver) createIosRemoteSession(); 
                    WebDriverRunner.setWebDriver(appiumDriver); 
                    return appiumDriver; 
            } 
        } else { 
            appiumDriver = (AppiumDriver) createLocalSession(); 
            WebDriverRunner.setWebDriver(appiumDriver); 
            RUNNING_WEBDRIVER_LIST.add(appiumDriver); 
        }return appiumDriver; } 
85 
 
    @Step("Creating local new session") 
    private WebDriver createLocalSession() throws IOException, ExecutionException, 
InterruptedException { 
        log.info("Starting Local Appium Session and off animations for {}", application.getApkName()); 
        disableAnimationEmulator(); 
        return webDriverProvider.createDriver(createLocalSessionCapabilities()); 
    } 
    @Step("Creating new session for android Selenoid") 
    private WebDriver createRemoteSession() throws Exception { 
        log.info("Starting Selenoid Appium Android Session"); 
        return createNewSelenoidSessionCapabilities(); 
    } 
 
    @Step("Creating new session for IOS Selenoid") 
    private WebDriver createIosRemoteSession() throws Exception { 
        log.info("Starting Selenoid Appium IOS Session"); 
        return createNewSelenoidSessionCapabilitiesForIOS(); 
    } 
    private DesiredCapabilities createLocalSessionCapabilities() { 
        DesiredCapabilities desiredCapabilities = new 
DesiredCapabilities(getLocalPlatformCapabilities()); 
        desiredCapabilities.setCapability(APP_ACTIVITY, application.getAppLaunchActivity()); 
        desiredCapabilities.setCapability(APP_PACKAGE, application.getAppPackage()); 
        desiredCapabilities.setCapability(MobileCapabilityType.DEVICE_NAME, DEVICE_NAME); 
        desiredCapabilities.setCapability(MobileCapabilityType.PLATFORM_NAME, 
PLATFORM_NAME); 
        //desiredCapabilities.setCapability("chromedriverExecutable", 
getAbsolutePath(CHROME_DRIVER_EXE)); 
        desiredCapabilities.setCapability(MobileCapabilityType.APP, getAbsolutePath(APP)); 
        desiredCapabilities.setCapability(AUTO_GRANT_PERMISSIONS, true); //doesn't work if noreset 
        return desiredCapabilities; 
    } 
86 
 
    private static AndroidDriver createNewSelenoidSessionCapabilities() throws Exception { 
        DesiredCapabilities desiredCapabilities = new DesiredCapabilities(); 
        desiredCapabilities.setCapability(MobileCapabilityType.BROWSER_NAME, 
BROWSER_NAME); 
        desiredCapabilities.setCapability(MobileCapabilityType.BROWSER_VERSION, 
BROWSER_VERSION); 
        desiredCapabilities.setCapability(MobileCapabilityType.APP, 
"https://apkarchive.itsrv.xyz/tikschool.zip"); 
        Map<String, Object> selenoidOptions = new HashMap<>(); 
        selenoidOptions.put("enableVNC", true); 
        desiredCapabilities.setCapability("selenoid:options", selenoidOptions); 
        return new AndroidDriver(new URL(SELENOID_URL), desiredCapabilities); 
    } 
    private static IOSDriver createNewSelenoidSessionCapabilitiesForIOS() throws Exception { 
        DesiredCapabilities desiredCapabilities = new DesiredCapabilities(); 
        desiredCapabilities.setPlatform(Platform.IOS); 
        desiredCapabilities.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest"); 
        desiredCapabilities.setCapability("useNewWDA", false); 
        desiredCapabilities.setCapability(MobileCapabilityType.NO_RESET, true); 
        desiredCapabilities.setCapability(MobileCapabilityType.BROWSER_NAME, "iPhone14"); 
        desiredCapabilities.setCapability(MobileCapabilityType.BROWSER_VERSION, "16.2"); 
        desiredCapabilities.setCapability("deviceReadyTimeout", "150000"); 
        desiredCapabilities.setCapability("simulatorStartupTimeout", "150000"); 
        desiredCapabilities.setCapability(MobileCapabilityType.APP, 
"https://apkarchive.itsrv.xyz/ios/tikschool.zip"); 
        desiredCapabilities.setCapability(IS_HEADLESS, false); 
        desiredCapabilities.setCapability(NEW_COMMAND_TIMEOUT, "10000"); 
        return new IOSDriver(new URL(SELENOID_URL), desiredCapabilities); 
    } 
 
    private static DesiredCapabilities getLocalPlatformCapabilities() { 
        DesiredCapabilities desiredCapabilities = new DesiredCapabilities(); 
87 
 
        desiredCapabilities.setPlatform(Platform.ANDROID); 
        desiredCapabilities.setCapability(MobileCapabilityType.DEVICE_NAME, DEVICE_NAME); 
        desiredCapabilities.setCapability(MobileCapabilityType.APP, 
"https://apkarchive.itsrv.xyz/tikschool.zip"); 
        desiredCapabilities.setCapability(AUTOMATION_NAME, 
AutomationName.ANDROID_UIAUTOMATOR2); 
        desiredCapabilities.setCapability(GPS_ENABLED, true); 
        desiredCapabilities.setCapability(NEW_COMMAND_TIMEOUT, 300); 
 
        return desiredCapabilities; 
    } 
    private static void disableAnimationEmulator() throws IOException, ExecutionException, 
InterruptedException { 
        executeSh("adb -s shell settings put global transition_animation_scale 0.0"); 
        executeSh("adb -s shell settings put global window_animation_scale 0.0"); 
        executeSh("adb -s shell settings put global animator_duration_scale 0.0"); 
    } 
} 
package webDriver; 
import lombok.Getter; 
@Getter 
public enum AndroidEmulator { 
    TEST_AVD("emulator-5554", "http://127.0.0.1:4723/wd/hub"); 
    private final String avdName; 
    private final String appiumUrl; 
    AndroidEmulator(String avdName, String appiumUrl) { 
        this.avdName = avdName; 
        this.appiumUrl = appiumUrl; }} 
package utils; 
 
import com.codeborne.selenide.SelenideElement; 
import com.codeborne.selenide.WebDriverRunner; 
88 
 
import io.appium.java_client.TouchAction; 
import io.appium.java_client.android.AndroidDriver; 
import io.appium.java_client.android.nativekey.AndroidKey; 
import io.appium.java_client.android.nativekey.KeyEvent; 
import io.appium.java_client.touch.WaitOptions; 
import io.appium.java_client.touch.offset.PointOption; 
import lombok.extern.slf4j.Slf4j; 
import org.openqa.selenium.*; 
import org.openqa.selenium.interactions.PointerInput; 
import org.openqa.selenium.interactions.Sequence; 
import org.openqa.selenium.support.ui.ExpectedConditions; 
import org.openqa.selenium.support.ui.WebDriverWait; 
import ui.common.CommonElements; 
import utils.enums.Application; 
import utils.enums.Swipe; 
import java.io.IOException; 
import java.time.Duration; 
import java.time.Instant; 
import java.time.temporal.ChronoUnit; 
import java.time.temporal.TemporalUnit; 
import java.util.List; 
import java.util.Set; 
import java.util.concurrent.ExecutionException; 
import java.util.function.Function; 
import static com.codeborne.selenide.Selenide.$; 
import static com.codeborne.selenide.WebDriverRunner.getWebDriver; 
import static helpers.DeviceHelper.executeSh; 
import static io.appium.java_client.touch.offset.PointOption.point; 
import static java.time.Duration.ofMillis; 
import static java.time.Duration.ofSeconds; 
import static org.openqa.selenium.By.xpath; 
import static org.openqa.selenium.interactions.PointerInput.MouseButton.LEFT; 
89 
 
import static utils.BaseStep.waitForPageToLoad; 
import static utils.BaseStep.waitUntilElementIsNotDisplayed; 
@Slf4j 
public class AndroidActions { 
    public static void reloadApp() { 
        getAndroidDriver().closeApp(); 
        getAndroidDriver().activateApp(Application.TIK_SCHOOL_APP.getAppPackage()); 
    } 
    private static AndroidDriver getAndroidDriver() { 
        return (AndroidDriver) WebDriverRunner.getWebDriver(); 
    } 
    public enum Direction { 
        UP, DOWN, RIGHT, LEFT 
    } 
 
    public static SelenideElement scrollToElementWithTextContains(String elementText, Swipe 
swipeDistance) { 
        By selector = xpath("//android.widget.TextView[contains(@text, '" + elementText + "')]"); 
        return scrollToElementWithText( 
                selector, 
                swipeDistance.getValue(), // swipe distance in pixel 
                0.5, // 50% from left side of a screen 
                0.7, // 70% from top of the screen 
                10, // timeout 
                ChronoUnit.SECONDS, 
                AndroidActions::findElementNoException); 
    } 
    public static void verticalScrollAction(AndroidActions.Direction direction, 
                                            int swipeDistanceInPixel, 
                                            double startX, 
                                            double startY) { 
        Dimension screenSize = getWindowDimension(); 
90 
 
        if (startX <= 0 || startX >= 1 && startY <= 0 || startY >= 1) { 
            throw new IllegalArgumentException("Starting touch values must be within 0 and 1 range 
(exclusive)"); 
        } 
        int touchStartX = (int) (screenSize.getWidth() * startX); 
        int touchStartY = (int) (screenSize.getHeight() * startY); 
        swipeDistanceInPixel *= direction.equals(AndroidActions.Direction.DOWN) ? 1 : -1; 
        PointerInput finger = new PointerInput(PointerInput.Kind.TOUCH, "finger"); 
        Sequence scrollSequence = new Sequence(finger, 4); 
        scrollSequence.addAction(finger.createPointerMove( 
                ofMillis(0), 
                PointerInput.Origin.viewport(), 
                touchStartX, 
                touchStartY)); 
        scrollSequence.addAction(finger.createPointerDown( 
                LEFT.asArg())); 
        scrollSequence.addAction(finger.createPointerMove( 
                ofMillis(300), 
                PointerInput.Origin.viewport(), 
                touchStartX, 
                touchStartY - swipeDistanceInPixel)); 
        scrollSequence.addAction(finger.createPointerUp( 
                LEFT.asArg())); 
        getAndroidDriver().perform(List.of(scrollSequence)); 
    } 
    public static SelenideElement scrollToElementWithText(By selector, 
                                                          int swipeDistanceInPixel, 
                                                          double startX, 
                                                          double startY, 
                                                          int timeout, 
                                                          TemporalUnit unit, 
                                                          Function<By, WebElement> condition) { 
91 
 
        WebElement el = null; 
        boolean isWait = true; 
        long start = Instant.now().toEpochMilli(); 
        long maxTimeWait = Duration.ZERO.plus(timeout, unit).toMillis(); 
        int bottomNavHeight = 150; // approximation for bottom navigation panel height 
        int screenHeight = getWindowDimension().getHeight(); 
        while (isWait) { 
            el = condition.apply(selector); 
            if (el != null && screenHeight - bottomNavHeight > el.getRect().getY() + 
el.getRect().getHeight()) 
               break; 
            verticalScrollAction( 
                    Direction.DOWN, 
                    swipeDistanceInPixel, 
                    startX, 
                    startY); 
            isWait = start + maxTimeWait > Instant.now().toEpochMilli(); 
        } 
        return el != null ? $(el) : $(selector); 
    } 
    public static void scroll(int startx, int starty, int endx, int endy) { 
        TouchAction touchAction = new TouchAction(getAndroidDriver()); 
        touchAction.press(point(startx, starty)) 
                .waitAction(WaitOptions.waitOptions(ofSeconds(1))) 
                .moveTo(point(endx, endy)) 
                .release() 
                .perform(); 
    } 
    public static void horizontalScrollActions(Direction direction, int swipeDistanceInPixel, double 
startX, 
                                               double startY) { 
        Dimension screenSize = getAndroidDriver().manage().window().getSize(); 
92 
 
        swipeDistanceInPixel *= direction.equals(Direction.LEFT) ? 1 : -1; 
 
        int startx = (int) (screenSize.getWidth() * startX); 
        int starty = (int) (screenSize.getHeight() * startY); 
        int endx = (startx - swipeDistanceInPixel); 
        scroll(startx, starty, endx, starty); 
    } 
    public static void swipeToRefreshPage() { 
        int swipeDistanceInPixel = 600; 
        double startX = 0.5; 
        double startY = 0.3; 
        do { 
            verticalScrollAction( 
                    Direction.UP, 
                    swipeDistanceInPixel, 
                    startX, 
                    startY); 
        } while (!CommonElements.refreshPageIcon.exists()); 
    } 
    public static Dimension getWindowDimension() { 
        return getAndroidDriver().manage().window().getSize(); 
    } 
    private static WebElement findElementNoException(By by) { 
        WebElement el = null; 
        try { 
            el = new WebDriverWait(getWebDriver(), ofSeconds(0)) 
                    .until(ExpectedConditions.presenceOfElementLocated(by)); 
        } catch (NoSuchElementException | TimeoutException ignore) { 
        } 
        return el; 
    } 
    public static void clickOnCoordinates(int x, int y) { 
93 
 
        TouchAction action = new TouchAction(getAndroidDriver()); 
        PointOption point = new PointOption(); 
        action.press(point.withCoordinates(x, y)).release().perform(); 
    } 
    public static void clickOnBackButton() { 
        getAndroidDriver().pressKey(new KeyEvent(AndroidKey.BACK)); 
    } 
    public static void openNotifications() { 
        verticalScrollAction(Direction.UP, 1000, 0.5, 0.05); 
    } 
    public static void clickOnHomeButton() { 
        getAndroidDriver().pressKey(new KeyEvent(AndroidKey.HOME)); 
    } 
    public static void setContextToWebView() { 
        Set<String> availableContexts = getAndroidDriver().getContextHandles(); 
        availableContexts.stream() 
                .filter(context -> context.toLowerCase().contains("webview")) 
                .forEach(newcontext -> getAndroidDriver().context(newcontext)); 
    } 
    public static void setContextToNativeApp() { 
        Set<String> availableContexts = getAndroidDriver().getContextHandles(); 
        availableContexts.stream() 
                .filter(context -> context.toLowerCase().contains("native_app")) 
                .forEach(newcontext -> getAndroidDriver().context(newcontext)); 
    } 
    public static void openChromeApp() { 
        getAndroidDriver().activateApp("com.android.chrome");} 
    public static void openChromeNavigatedTo(String URL) { 
        try { 
            terminateChrome(); 
            executeSh(String.format("adb shell am start -n 
com.android.chrome/com.google.android.apps.chrome.Main -d '%s'", URL)); 
94 
 
            waitForPageToLoad(); 
        } catch (IOException | ExecutionException | InterruptedException e) { 
            throw new RuntimeException(e);  } } 
    public static void terminateChrome() { 
        try { 
            executeSh("adb shell pm clear com.android.chrome"); 
        } catch (IOException | InterruptedException | ExecutionException e) { 
            throw new RuntimeException(e); } } 
    public static void terminateNativeApp() { 
        try { 
            executeSh("adb shell pm clear com.sintegrum"); 
        } catch (IOException | InterruptedException | ExecutionException e) { 
            throw new RuntimeException(e);} } 
    public static void openNativeApp() { 
        getAndroidDriver().activateApp("com.sintegrum"); 
        waitForAppLoaded(); } 
    private void refreshPage() { 
        WebDriverRunner.getWebDriver().navigate().refresh();} 
    public static void waitForAppLoaded() { 
        waitUntilElementIsNotDisplayed(CommonElements.progressBar); }}
Репозиторій ЧДТУ
