Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/6492| Назва: | Дослідження методів та засобів автоматизованого тестування Web-додатків |
| Автори: | Уткіна, Тетяна Юріївна Войтенко, Даніїл Володимирович |
| Дата публікації: | січ-2024 |
| Короткий огляд (реферат): | Метою кваліфікаційної роботи магістра є підвищення ефективності засобів автоматизованого тестування Web-додатків за рахунок проведення системного аналізу існуючих методів та програмних засобів тестування корпоративних Web-додатків, спрямованого на вибір сучасних інструментів для автоматизованого тестування таких додатків з урахуванням нових тенденцій, їх порівняння з точки зору ремонтопридатності та використання в системах безперервної інтеграції, розробки узагальненої моделі функціонування системи автоматизованого тестування Web-додатків та розробки алгоритму проведення автоматизованого тестування корпоративних Web-додатків. Використання таких інструментів дозволить забезпечити високорівневий інтерфейс прикладного програмування (API) для використання при тестуванні інтерфейсів користувача Web-додатків, моніторинг відсотку дефектів при його динамічній зміні, підвищити незалежність від тестувальника, отримати позитивний економічний ефект, збільшити швидкість виконання тестів, скоротивши час на виконання однотипних тестових наборів, ручне тестування, а також виключивши вплив людського фактору в процесі тестування. Об’єкт дослідження – процеси автоматизованого тестування Web-додатків. Предмет дослідження – методи та засоби автоматизованого тестування Web-додатків.У результаті виконання досліджень отримано наступні наукові і практичні результати: − систематизована інформація про методи та засоби автоматизованого тестування Web-додатків за рахунок проведеного системного аналізу світового досвіду використання, визначені переваги і недоліки їх застосування; − систематизована інформація про існуючих методів та методології функціонального тестування Web-додатків за рахунок проведеного системного аналізу, приведені якісні характеристики існуючих аналогів предмету дослідження; − проведено якісну оцінку засобів автоматизованого тестування Web-додатків за такими параметрами як ремонтопридатність, виконання та використання в системах безперервної інтеграції та надані рекомендації по їх використанню; − розроблено узагальнену модель функціонування системи автоматизованого тестування Web-додатків, що забезпечує підвищення якості програмного продукту й усунення помилок у коді Web-програми для фронт-офісної системи підприємства; − запропоновано алгоритм проведення автоматизованого тестування корпоративних Web-додатків, що дозволило отримати позитивний економічний ефект, значно скоротивши час та витрати на ручне тестування, а також виключивши вплив людського фактору в процесі тестування; − створено тестові випадки та автоматизовані Web-сценарії тестування Web-додатків, які дозволили перевірити працездатність нового бізнес-процесу, важливого для підприємства з отримання онлайн-пропозицій для клієнта; − досліджено впровадження автоматизації тестування на прикладі Booking.com: проведено аналіз попереднього процесу тестування, обґрунтовано вибір артефакту та інструменту його розробки, проведено реалізацію набору тестів та визначено ефективність. В результаті проведеного дослідження встановлено, що функціональне (ручне) тестування вигідніше використовувати при розробці нового бізнес-процесу, а автоматизоване рішення доцільніше використовувати для перевірки існуючого функціоналу. Отримані рішення спрямовані на усунення помилок для забезпечення якості програмного продукту. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/6492 |
| Розташовується у зібраннях: | 174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| М_151_2023_Войтенко+.pdf Restricted Access | 3.17 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ СИСТЕМ Пояснювальна записка до кваліфікаційної роботи освітнього ступеню «магістр» на тему: Дослідження методів та засобів автоматизованого тестування Web-додатків Виконав: здобувач вищої освіти 2 курсу, групи МАКІТ-2209 спеціальності 151 «Автоматизація та комп’ютерно-інтегровані технології» (освітня програма «Комп’ютерно-інтегровані системи та компоненти») Даніїл ВОЙТЕНКО (ім’я та прізвище) Керівник Тетяна УТКІНА (ім’я та прізвище) Рецензент (ім’я та прізвище) Черкаси 2023 року 2 ЗМІСТ ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ................................. 4 ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ ..................................................... 6 РОЗДІЛ 1. СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУЛЮВАННЯ ЗАВДАНЬ ........................................................................................................... 11 1.1. Огляд світового досвіду використання методів та засобів автоматизованого тестування ............................................................................................................... 11 1.2. Визначення сутності Web-додатку .............................................................. 14 1.3. Архітектура класичних Web-додатків......................................................... 15 1.4. Фреймворки Web-додатків .......................................................................... 22 1.5. Формулювання проблемних завдань дослідження ..................................... 26 Висновки ............................................................................................................... 27 РОЗДІЛ 2. СИСТЕМНИЙ АНАЛІЗ СУЧАСНИХ МЕТОДІВ ТА ЗАСОБІВ ТЕСТУВАННЯ WEB-ДОДАТКІВ ..................................................................... 28 2.1. Методи тестування Web-додатків ............................................................... 28 2.2. Методи проектування тестів ........................................................................ 32 2.3. Рівні серйозності та пріоритету дефектів ................................................... 34 2.4. Класифікація засобів тестування ................................................................. 35 2.5. Розвиток підходів до тестування програмного забезпечення .................... 35 2.6. Порівняння автоматизованого та ручного підходів у тестуванні Web-додатків .......................................................................................................... 38 2.7. Методології розробки та тестування програмного забезпечення .............. 41 Висновки ............................................................................................................... 49 РОЗДІЛ 3. ОСОБЛИВОСТІ ФУНКЦІОНАЛЬНОГО ТЕСТУВАННЯ ТА СТВОРЕННЯ ТЕСТОВИХ ЗРАЗКІВ ДЛЯ WEB-ДОДАТКІВ ...................... 50 3.1. Визначення сутності функціонального тестування Web-додатків ............ 50 3.2. Створення тестових кейсів для Web-додатку ............................................. 57 3 3.3. Розробка узагальненої моделі функціонування системи автоматизованого тестування Web-додатків ....................................................................................... 60 3.4. Розробка алгоритму проведення автоматизованого тестування Web- додатків ................................................................................................................... 62 Висновки ............................................................................................................... 64 РОЗДІЛ 4. СИСТЕМНИЙ АНАЛІЗ ЗАСОБІВ РОЗРОБКИ СЦЕНАРІЇВ АВТОМАТИЗОВАНОГО ТЕСТУВАННЯ WEB-ДОДАТКІВ ....................... 65 4.1. Автоматизоване тестування ......................................................................... 65 4.2. Створення сценаріїв автоматизованого тестування Web-додатків ........... 68 4.3. Аналіз результатів випробувань .................................................................. 78 Висновки ............................................................................................................... 83 РОЗДІЛ 5. ДОСЛІДЖЕННЯ ВПРОВАДЖЕННЯ АВТОМАТИЗАЦІЇ ТЕСТУВАННЯ НА ПРИКЛАДІ BOOKING.COM .......................................... 84 5.1. Аналіз попереднього процесу тестування .................................................. 85 5.2. Обґрунтування вибору артефакту та інструменту його розробки ............. 87 5.3. Реалізація набору тестів ............................................................................... 91 5.4. Визначення ефективності ............................................................................ 99 Висновки ............................................................................................................. 101 ВИСНОВКИ ........................................................................................................ 102 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ......................................................... 104 4 ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ API – Application Programming Interface – прикладний програмний інтерфейс. BTO – Business Technology Optimization – оптимізація бізнес- технологій. CSS – Cascading Style Sheets – каскадні таблиці стилів. DOM – Document Object Model – об’єктна модель документа. GUI – Graphical User Interface – графічний інтерфейс користувача. HTTP – Hypertext Transfer Protocol – протокол прикладного рівня передачі даних. HTTPS – HyperText Transfer Protocol Secure – розширення протоколу HTTP для підтримки шифрування з метою підвищення безпеки. IDE – Integrated Development Environment – єдине середовище розробки. MVC – Model View Controller – схема поділу даних програми та керуючої логіки на незалежні компоненти: модель, уявлення та контролер. MVP – Model View Presenter – шаблон проектування, похідний від MVC, який відділяє візуальне відображення та поведінку обробки подій у різні класи: представлення (View) та пред’явник (Presenter) відповідно. MVVM – Model View ViewModel – шаблон проектування архітектури програми, який відділяє модель та її уявлення, що необхідно для їх зміни окремо одне від одного. PDM – Product Data Management – система управління даними продукту QA – Quality Assurance – забезпечення якості. RFC – Request for Comments – запит коментарів. 5 WEB – Web – павутина – інтернет-простір. XML – Extensible Markup Language – розширювана мова розмітки. ОС – Операційна система. ПЗ – Програмне забезпечення. ПК – Персональний комп’ютер. ШІ – Штучний інтелект. 6 ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ Тестування програмного забезпечення представляє собою визначення відповідності між фактичною та очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, вибраних певним чином. У широкому контексті тестування виступає як один з методів контролю якості, що включає заходи з планування робіт, проектування тестів, виконання тестів та аналізу отриманих результатів. Оскільки при розробці програм не можна уникнути помилок, а внесення будь-яких змін до складних програм може суттєво вплинути на інші їхні частини, важливо проводити тестування. Web-програми, зокрема, є складними програмними продуктами, оскільки логіка програми розподілена між клієнтом та сервером. Компанії стикаються з великими фінансовими втратами через низьку якість програмних продуктів Тестування проводиться з метою швидкого виявлення дефектів у системі та забезпечення користувачів якісним програмним продуктом. Тестування програмного забезпечення є необхідною частиною розробки будь-яких програм, особливо для корпоративних програм, де витрати на розробку та тестування є значними. Важливим є вибір ефективних методів тестування, що призводить до зменшення витрат на розробку та обслуговування. Мета тестування полягає в уникненні проблем та забезпеченні комфортного використання продукту. Для досягнення цієї мети, перед введенням продукту на ринок, його обов’язково піддають перевірці. Процес тестування є складним, і для його прискорення часто використовується автоматизація. У сучасному світі все більше додатків, незалежно від того, чи це корпоративні, чи стандартні, зорієнтовані на запуск у браузерах настільних комп’ютерів та мобільних пристроях. Це стало можливим завдяки легкості поширення Web-додатків, при цьому головною перевагою є відсутність необхідності розробки окремого додатку для кожної платформи. Актуальність теми. Одним із способів зниження витрат на розробку та тестування додатків є автоматизоване тестування. Проте існують численні 7 недоліки в розробці сценаріїв для автоматизованого тестування інтерфейсу користувача. Методика написання тестів надто складна та значно пов’язана з конкретними деталями реалізації додатків, що призводить до труднощів у випадку навіть невеликої зміни у програмі, яка може викликати значні зміни в тестах та підвищує ймовірність помилок. Це викликає високі витрати на розробку та підтримку таких тестів. Актуальність теми обумовлена декількома факторами, а саме: − перспективами застосування сучасних програмних засобів автоматизації тестування Web-додатків; − розвитком та поширенням нових методів та засобів автоматизації тестування Web-додатків; − необхідністю розробки нових та вдосконалення існуючих програмних засобів автоматизації тестування Web-додатків. Питанням дослідження та розробки сучасних методів та засобів автоматизованого тестування Web-додатків присвячені праці багатьох науковців. Значний внесок в розвиток даних питань внесли вчені: Бєлозьорова Д. О., Бондар В. О., Бондаренко О. В., Єгорова О., Жирова Т. О., Калин М. В., Клушин Ю. С., Кодола Г. М., Котенко Н. О., Криворучко О. В., Нагаєв Р. А., Слободян Р. В., Филиппов В. А., Цюцюра М. І., Kalmo M., Mao K., Qi X. F., Zhou Y. та ін., але в цих роботах недостатньо висвітлені рішення, що дозволять забезпечити належне функціонування засобів автоматизованого тестування Web-додатків. Мета і задачі дослідження. Метою кваліфікаційної роботи магістра є підвищення ефективності засобів автоматизованого тестування Web-додатків за рахунок проведення системного аналізу існуючих методів та програмних засобів тестування корпоративних Web-додатків, спрямованого на вибір сучасних інструментів для автоматизованого тестування таких додатків з урахуванням нових тенденцій, їх порівняння з точки зору ремонтопридатності та використання в системах безперервної інтеграції, розробки узагальненої моделі функціонування системи автоматизованого тестування Web-додатків та 8 розробки алгоритму проведення автоматизованого тестування корпоративних Web-додатків. Використання таких інструментів дозволить забезпечити високорівневий інтерфейс прикладного програмування (API) для використання при тестуванні інтерфейсів користувача Web-додатків, моніторинг відсотку дефектів при його динамічній зміні, підвищити незалежність від тестувальника, отримати позитивний економічний ефект, збільшити швидкість виконання тестів, скоротивши час на виконання однотипних тестових наборів, ручне тестування, а також виключивши вплив людського фактору в процесі тестування. Для досягнення цієї мети необхідно вирішити наступні задачі: − проаналізувати світовий досвід використання методів та засобів автоматизованого тестування Web-додатків, визначити переваги і недоліки їх застосування; − проаналізувати існуючі методи та методології функціонального тестування Web-додатків та привести якісні характеристики існуючих аналогів предмету дослідження; − провести якісну оцінку засобів автоматизованого тестування Web- додатків за такими параметрами як ремонтопридатність, виконання та використання в системах безперервної інтеграції та надати рекомендації по їх використанню; − розробити узагальнену модель функціонування системи автоматизованого тестування Web-додатків; − запропонувати алгоритм проведення автоматизованого тестування корпоративних Web-додатків; − створити тестові випадки та автоматизовані Web-сценарії тестування Web-додатків; − дослідити впровадження автоматизації тестування на прикладі Booking.com: провести аналіз попереднього процесу тестування, зробити обґрунтування вибору артефакту та інструменту його розробки, провести реалізацію набору тестів та провести визначення ефективності. 9 Об’єкт дослідження – процеси автоматизованого тестування Web- додатків. Предмет дослідження – методи та засоби автоматизованого тестування Web-додатків. Методи дослідження. Для розв’язання поставлених завдань були використані теорії аналізу та синтезу, методи тестування програмного забезпечення, визначення якості продукту та автоматизації тест-кейсів. Наукова новизна одержаних результатів: − систематизована інформація про методи та засоби автоматизованого тестування Web-додатків за рахунок проведеного системного аналізу світового досвіду використання, визначені переваги і недоліки їх застосування; − систематизована інформація про існуючі методи та методології функціонального тестування Web-додатків за рахунок проведеного системного аналізу, приведені якісні характеристики існуючих аналогів предмету дослідження; − проведена якісна оцінка засобів автоматизованого тестування Web- додатків за такими параметрами як ремонтопридатність, виконання та використання в системах безперервної інтеграції та надано рекомендації по їх використанню; − розроблено узагальнену модель функціонування системи автоматизованого тестування Web-додатків. Практичне значення одержаних результатів полягає в тому, що на основі проведеного дослідження методів та засобів автоматизованого тестування Web-додатків: − запропоновано алгоритм проведення автоматизованого тестування корпоративних Web-додатків; − створено тестові випадки та автоматизовані Web-сценарії тестування Web-додатків; − досліджено впровадження автоматизації тестування на прикладі Booking.com: проведено аналіз попереднього процесу тестування, обґрунтовано 10 вибір артефакту та інструменту його розробки, проведено реалізацію набору тестів та визначено ефективність. Апробація результатів роботи. Результати роботи доповідалися й обговорювалися на студентських наукових конференціях: − дні студентської науки ЧДТУ, 19-22 квітня, м. Черкаси, Україна, 2022; − дні студентської науки ЧДТУ, 18-20 квітня, м. Черкаси, Україна, 2023. Публікації. Результати досліджень опубліковані у тезах доповідей: 1. Войтенко Д. В., Уткіна Т. Ю. Дослідження методів та засобів автоматизованого тестування Web-додатків [Електронний ресурс] / [упоряд. : Єгорова О. В., Захарова О. В., Кисельов В. Б. та ін.]. Студентська науково- практична конференція ЧДТУ : зб. тез доповідей, 18–20 квітня 2023 р. М-во освіти і науки України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2023. С. 20-21. 2. Войтенко Д. В., Уткіна Т. Ю. Методи та засоби тестування Web- додатків [Електронний ресурс] / [упоряд. : Батраченко О. В., Бєляєва С. С., Захарова О. В. та ін.]. Студентська науково-практична конференція ЧДТУ : зб. тез доповідей, 19–22 квітня 2022 р. М-во освіти і науки України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2022. С. 54-55. Структура та обсяг кваліфікаційної роботи. Кваліфікаційна робота складається з вступу, 5 розділів, висновків та списку використаних джерел. Робота викладена на 108 сторінках. Ілюстрована 48 рисунками. Список використаних джерел містить 30 найменувань. 11 РОЗДІЛ 1. СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУЛЮВАННЯ ЗАВДАНЬ 1.1. Огляд світового досвіду використання методів та засобів автоматизованого тестування Штучний інтелект (ШІ) дозволяє ПК самостійно проводити навчання та вирішувати завдання, спираючись на отриманий під час роботи досвід. Він також використовується для автоматизації тестування програмного забезпечення (ПЗ), що дає низку переваг. Сьогодні інформаційні технології все більше пов’язують свою діяльність із ШІ та різними нейронними мережами. Для спрощення роботи активно застосовують машинне навчання, яке дозволяє ШІ навчатися за рахунок використання кількох розв’язків подібних завдань для отримання результату в основному питанні. Одна з переваг ШІ в тестуванні ПЗ полягає в тому, що він може самостійно генерувати тестові випадки. Це економить час і зусилля тестувальників, які можуть зосередитися на більш складних завданнях. ШІ також може автоматизувати виконання тестових випадків, що ще більше підвищує ефективність процесу тестування. Крім того, ШІ може використовуватися для виявлення помилок у ПЗ на ранніх етапах розробки. Це дозволяє розробникам усунути помилки швидше і з меншими витратами. ШІ також може допомогти тестувальникам відстежувати вимоги до ПЗ і гарантувати, що всі вимоги виконуються. В цілому, ШІ має значний потенціал для покращення якості і ефективності тестування ПЗ. Він вже використовується багатьма компаніями, і його використання, швидше за все, буде зростати в майбутньому. ШІ та машинне навчання все більше впливає на тестування ПЗ: 1. ШІ допомагає командам забезпечення якості QA (Quality Assurance) вибудовувати тести з нуля практично без людського контролю. Зокрема ШІ видаляє всі зайві сценарії для прискорення процесу тестування. 12 2. ШІ дає можливість відбудувати нову матрицю відстеження вимог розширення тестового покриття. 3. На основі поведінки користувачів, машинне навчання допоможе швидше і більш точно прогнозувати потенційні проблеми та загрози. 4. Зрештою, ШІ допоможе точніше відслідковувати існуючі проблеми [5]. Таким чином, ШІ спростить роботу команди тестувальників проекту. Це дозволить доставляти якісний код та забезпечувати покращений користувальницький досвід. Основні етапи циклу тестування ПЗ з штучним інтелектом наведено на рис. 1.1. Рисунок 1.1 – Цикл тестування з штучним інтелектом Всі ці аспекти дозволяють проводити тестування ПЗ на новому рівні. При цьому розробники отримують низку переваг. 1. Команди забезпечення якості QA отримують при використанні методик застосування інструментів штучного інтелекту можливість створювати різні тести. Перевагою цього є те, що повністю відсутня необхідність у присутності людини при цьому процесі. Також для виключення уповільнення процесу тестування ШІ видаляє однакові випадки, щоб не затягувати тестування. 13 2. ШІ може самостійно створити та опрацювати матрицю для організації відстеження вимог. Це призводить до того, що збільшується охоплення та область тестування, а також виходить більш розгорнутий результат. 3. Оскільки машинне навчання дозволяє здійснювати велику обробку даних, отриманих під час роботи від інших користувачів, ШІ зможе зробити швидкі та якісні висновки та прогнози. Завдяки цьому можна виявити та усунути проблему до її втручання у роботу ПЗ. 4. Використовуючи ШІ у сукупності з машинним навчанням, можна організувати процес більш точного та якісного виявлення помилок. Також ця методика допоможе відслідковувати різні операції та процеси, які надалі зможуть стати причиною виникнення порушень. Усі ці фактори дають змогу командам тестувальників провести повноцінний аналіз проекту. При цьому досягається найвищий рівень продуктивності при отриманні якісного та опрацьованого коду. Також істотно підвищується показник комфорту інтерфейсу користувача. Завдяки тому, що розвиток штучного інтелекту та машинного навчання йде вперед досить швидкими темпами, команди інженерів QA отримують більший простір для дій. Вони можуть займатися проведенням низки експериментів щодо впровадження нових ідей, а не повністю занурюватися в процес тестування та управління цією операцією [7]. Фахівці у галузі розробки та аналітики стверджують, що у майбутньому може статися безпрецедентне збільшення кількості автоматизованих процесів. Це призведе до того, що команди із тестування не зможуть проводити запуск усіх операцій. Велика кількість автоматичних тестів може зашкодити швидкості виконання роботи та уповільнити процес випуску проекту. Тому експерти приходять до висновку, що необхідно з усіх наявних або змін, що з’являються, вичленювати тільки ті, які реально сприятимуть прискоренню роботи [25]. Автоматизація не зможе повністю замінити ручну перевірку деяких елементів. Як правило, це стосується тих опцій, які мають взаємодіяти з користувачем. Якщо тестувальник спробує зробити автоматизацію процесів, що 14 мають у собі помилки, це зможе призвести до максимально серйозних і негативних наслідків. Отже, трендом 2023 року є не виключна автоматизація тестування, а пошук балансу між ручними та автоматичними тестами. Всі ці аспекти сприяють підняттю тестування ПЗ на новий рівень і при цьому надають розробникам ряд переваг. 1.2. Визначення сутності Web-додатку Web-додаток представляє собою Web-сайт, що містить сторінки з частково або повністю неоформленим контентом [9]. Остаточний вміст сторінки генерується лише відповідно до запиту користувача до Web-сервера. Це пов’язано з тим, що зміст сторінки залежить від конкретного запиту, створеного на основі дій користувача. З цього можна зробити висновок, що Web-додаток передбачає тісну взаємодію з користувачем, отримання від нього “бізнес-даних”, їхню складну обробку та зберігання, можливо, навіть без надання результату користувачеві. Це означає, що користувач може взаємодіяти з матеріалами та функціями: натискати кнопки, заповнювати форми, запитувати прайс-лист і робити покупки. Всі інтернет-ресурси, такі як пошукові системи, відеосервіси, соціальні мережі, а також будь-які сайти з функціями автентифікації користувачів, покупок товарів та послуг, замовлення, бронювання квитків тощо, включаються до цього переліку Web-додатків. Технічно Web-додаток має клієнт-серверну архітектуру. Клієнтом є браузер, а сервер – Web-сервер. Взаємодія відбувається за допомогою методів запиту, причому найпоширеніші з них – це запити GET та POST. Метод GET, так само як і метод POST, може використовуватися як для відправлення даних, так і для отримання інформації з Web-сервера. Метод GET надсилає всю зібрану інформацію про форму на сервер як частину URL-адреси. Метод POST передає дані таким чином, що користувач більше не може бачити передані на сервер дані. 15 Зазвичай метод GET використовується для текстових та коротких запитів, тоді як час як метод POST використовується для передачі великого обсягу даних. Візуалізація методів показана на рис. 1.2. Рисунок 1.2 – Візуалізація методів GET та POST Спочатку Web-додаток складається зі сторінок, що містять частково або повністю невизначений вміст. Остаточний вміст Web-сторінок генерується лише тоді, коли конкретний користувач надсилає запит на сервер. 1.3. Архітектура класичних Web-додатків Web-сторінка складається з трьох частин: 1. Інформація про HTML-версію, представлена у вигляді першого рядка вихідного коду Web-сторінки. 2. Заголовок Web-сторінки, що включає технічну інформацію про Web- сторінку, таку як заголовок, ключові слова та метадані. Ці елементи не включені до графічного представлення Web-сторінки. Заголовок Web-сторінки обмежений елементом (тегом) <head>...</head>. 3. Тіло Web-сторінки, яке містить графічне та інформаційне представлення Web-сторінки. Тіло Web-сторінки обмежено body елементом (тегом) <body>...</ body>. Ця структура є стандартною для всіх Web-сторінок [4]. 16 Сторінки, які відображаються у браузері, можуть бути статичними чи динамічними. Статична Web-сторінка показується однаково всім користувачам. Алгоритм виглядає наступним чином: 1. Коли користувач вводить запит або адресу сторінки до адресного рядка браузера. 2. Браузер надсилає його на Web-сервер. 3. Сервер аналізує запит і визначає, що відсутні спеціальні знаки або інструкції для користувача. 4. Сервер надсилає Web-сторінку до браузера, не змінюючи будь-яких даних на ній, таких як матеріали новин, загальна стандартна інформація. У випадку динамічних сторінок: 1. Користувач вводить запит або адресу сторінки до адресного рядка браузера. 2. Браузер відправляє запит на Web-сервер з інформацією про те, що конкретний користувач має набір атрибутів, які слід використовувати для відображення відповідної інформації. 3. Web-сервер передає набір функцій на сервер додатків, де застосовуються правила та інструкції щодо додавання спеціальних змінних. Наприклад, якщо користувач увійшов до системи, він може побачити сторінку зі своїм повним ім’ям або іншою відповідною інформацією. 4. Сервер вибирає готову Web-сторінку та відправляє її до браузера, що показує її користувачеві, який створив запит. Також важливо враховувати, що хоча HTML не вважається повноцінною мовою програмування, але вона також може бути складною за структурою, мати великий обсяг блоку коду і модифікуватися у процесі виконання. Тому з метою полегшення розробки та підтримки, в так званих “тегах” HTML-коду введені атрибути, за допомогою яких можна ідентифікувати й з легкістю модифікувати кожний “тег”, який є на Web-сторінці [6]. Таким чином, мова HTML хоча і була впроваджена близько 30 років тому, все одно залишається основним конструкційним блоком у розробці Web- 17 сервісів, та будь-який інструмент чи бібліотека використовують її задля впровадження контенту на Web-сторінку [8]. Дуже важливо відрізняти поняття статичних та динамічних Web-сторінок, тому що динамічна Web-сторінка надає більше можливостей як функціоналу, модифікацій та мутацій в залежності від бажання користувача. Динамічна сторінка – це така Web-сторінка, яка згенерована програмно, найчастіше на етапі виконання програми і взаємодії з користувачем, на відміну від статичної сторінки, яка є файлом, який знаходиться на сервері. Клієнтська програма, або сервер, в залежності від типу рендерінгу сторінок, генерує HTML-код динамічної сторінки для обробки браузером. Статичний сайт представляє собою сайт, що складається з фіксованих HTML-сторінок, що являють єдине ціле. Він містить текст, зображення, часто мультимедійний контент, такий як аудіо, відео, і HTML-теги. Зазвичай статичний Web-сайт представляє собою набір файлів HTML, розміщених на Web-сервері [15]. Генерація вмісту на стороні клієнта відбувається після того, як клієнт з сервера отримав сторінку, браузер обробляє й відображає її користувачеві. При цьому виконуються скрипти клієнтської блоку, якщо вони включені на сторінці. На клієнтській стороні використовується JavaScript для здійсненння мінімальних операцій (наприклад, валідації завдання паролів при реєстрації на сайтах), так і глобальних послідовностей та додатків. Але у зв’язку з реальним станом речей – з метою пришвидення процесів розробки Web-сайтів, покращення призначених для користувача інтерфейсів та прискорення роботи самих Web-сайтів – на сьогодні у світі розробки Web-сайтів та додатків використовується так званий метод “комбінованої генерації”. Цей метод поєднує обидва цих підходи до рендерінгу у зв’язку з потребою регулярно або з особливої періодичністю отримувати дані з сервера протягом рендерінгу на боці клієнтської програми та браузера. Цей метод дозволяє ефективно працювати з віджетами, такими як “розумний” рядок пошуку з підказкою доступних варіантів, спливаючі меню, 18 спливаючі повідомлення, будь-які чат-сервіси, редактори на сайтах-форумах тощо. Отже, у багатьох випадках Web-додаток або сайт має базується на динамічно генерованих сторінках, які переважно використовують метод комбінованої генерації сторінки. Це обумовлено конкуренцією серед різних Web-сервісів за унікальність, функціональність та увагу користувача, чого можна досягти лише за допомогою передових технологій, інструментів та фреймворків. Приклад рендерингу статичних та динамічних Web-сторінок показано на рис. 1.3. Рисунок 1.3 – Приклад роботи статичних та динамічних Web-сторінок Технічно можливо динамічно оновлювати контент або окремі блоки на сторінці без перезавантаження всієї сторінки, для чого використовуються AJAX та jQuery. AJAX є інструментом для створення Web-програм, які комунікують із сервером у фоновому режимі, надаючи користувачеві програму з динамічним оновленням контенту, без перезавантаження всієї сторінки [12]. jQuery є це фреймворком JavaScript та бібліотекою, що спрощує використання деяких функцій JavaScript, таких як створення візуальних ефектів, обробка подій, робота з DOM та підтримка AJAX [3]. Основний принцип динамічного оновлення блоку на сторінці включає такі етапи: 1. Створення функції та об’єкта для взаємодії з сервером у фоновому режимі без перезавантаження сторінки. 19 2. Створення у тілі документа двох контейнерів: перший завантажує контент безпосередньо, а другий містить контент-заставку, що з’являється під час завантаження основного необхідного контенту. 3. Створення додаткової функції, яка виводить вміст першого контейнера, використовуючи раніше створений об’єкт. Для взаємодії з сервером використовується певний метод. Параметри включають тип запиту (наприклад, GET) і рядок, що передається серверу (URL завантажуваної сторінки). 4. Очікування завершення завантаження контенту, після чого тіло контейнера миттєво змінюється. 5. Відправлення запиту на сервер після його відкриття. Основний інструмент роботи з динамічними змінами на Web-сторінці − це об’єктна модель документа DOM (Document Object Model), що використовується для представлення XML/HTML-документів. За зразком моделі DOM документ подається у вигляді ієрархічного дерева, де кожен HTML тег є вузлом дерева, типом якого є елемент, а вкладені теги − дочірніми вузлами. Для представлення текстової інформації створюються вузли типу text. Існує 12 типів вузлів, але на практиці використовуються головним чином 4 з них: 1. Документ – точка входу в DOM. 2. Елементи – основні будівельні блоки. 3. Текстові вузли, які містять фактичний текст. 4. Коментарі містять інформацію, невидиму для відображення, але доступну в JavaScript. DOM представляє документ у вигляді ієрархії об’єктів, яку можна редагувати за допомогою JavaScript. Використання DOM дозволяє керувати сторінкою, читати інформацію з HTML, змінювати та створювати елементи. Ілюстрацію дерева DOM показано на рис. 1.4. 20 Рисунок 1.4 – Структура дерева HTML DOM Зазвичай на практиці потрібно маніпулювати наборами елементів (або одним), знаходячи їх імена десь глибоко у дереві БД. Ці елементи часто розташовані у різних частинах дерева. Наприклад, потрібно відзначити список файлів для видалення на Web-сторінці та виконати таку дію. У таких ситуаціях ручний прохід по дереву буде дуже стомлюючим. Тому в цьому випадку пошук елемента в дереві специфікації може бути виконаний за допомогою спеціалізованих методів пошуку. 1. За ідентифікатором елемента By.id. Якщо елементу присвоєно унікальний ідентифікатор, спеціальний атрибут id, тоді його можна отримати безпосередньо за допомогою змінної з ім’ям значення id. Згідно з стандартом, значення id має бути унікальним, і якщо цей ідентифікатор призначено, відбувається повернення відповідного елементу. У випадку, коли документ містить декілька елементів з унікальним ідентифікатором, поведінка буде невизначеною. В цьому випадку браузер повертає елемент випадковим чином. Тому при розробці Web-додатків намагаються дотримуватися правила унікальності ідентифікатора. 2. На ім’я тегу елемента By.tagName. Цей метод дозволяє отримати всі елементи з певним тегом та виконати пошук у тому числі потрібного. Регістр тегу не має значення. 21 3. За ім’ям елемента By.Name. Виклик цього методу дозволяє отримати всі елементи з атрибутом Name. Як правило, метод використовується рідко, оскільки імена часто не є унікальними в дереві-DOM. 4. За ім’ям класу By.className. Цей метод повертає колекцію елементів із класом className. Також знаходить елемент, якщо він має кілька класів і шуканий клас є одним із них. 5. За селектором таблиць стилів By.cssSelector. CSS (Cascading Style Sheets) – це формальна мова для опису зовнішнього вигляду документа, написаного з використанням мови розмітки. Метод повертає елементи, що відповідають селектору CSS. Є одним з найчастіше використовуваних і корисних методів при роботі з DOM. Структура CSS-селектора враховує ієрархію об’єктів у дереві DOM, а також критерії, засновані на тегах та атрибутах. Напрямки руху в DOM дереві DOM тільки в глибину. 6. Використання мови запитів XML-елементів (eXtensible Markup Language) By.xpath. Xpath (XML Path Language) – мова запитів для XML- елементів документа, що реалізує навігацію по DOM дереву. Метод популярний як в CSS пошук CSS-селектора. Xpath враховує ієрархію об’єктів в дереві DOM, а також критерії, засновані на тегах і атрибутах. Однак напрямок руху в DOM- дереві, на відміну від CSS-селектора, може бути в будь-якому напрямку. 7. Актуальність даних у додатку. Є важливим критерієм, оскільки наявність неактуальних або невірних даних може призвести до помилкових операцій, спричинених одним з попередніх пунктів, а у деяких випадках – одразу всіма. Але дуже часто виникають ситуації, коли бізнес-логіка працює ідеально, користувацький інтерфейс працює вірно та протестований багато разів, протягом виконання одного з ланцюгів усі дані були вірними, але результуючі дані виявилися пошкодженими, або на деяких етапах виконання програми з’являються неактуальні, або помилкові дані. Можна перераховувати нескінченний список причин, за якими виникає така ситуація, в тому числі заповнення БД некоректними даними, помилка в програмному коді стороннього 22 сервісу, втрата з’єднання мережі та інші технічні неполадки. Але для того, щоб виправити таку несправність – спочатку її треба виявити та діагностувати, адже невиявлена несправність, так само як і в попередніх пунктах, може призвести до подальшої передачі неактуальних або невірних даних. Це ж у більшості випадків призведе до завдання шкоди бізнесу чи до введення в оману користувача, що спричинить відторгнення й негативний відгук самого користувача. 1.4. Фреймворки Web-додатків В сучасний період більшість Web-додатків базуються на певних фреймворках. Фреймворки є програмними продуктами, спрямованими на полегшення розробки та супроводу технічно складних або масштабних проектів. Зазвичай фреймворк містить лише базові програмні модулі, залишаючи розробникові відповідальність за реалізацію всіх інших компонентів проекту. Це надає можливості досягати високої швидкості розробки ПЗ, високої продуктивності та надійності рішень. Крім того, фреймворки можна використовувати для створення різних Web-сайтів, бізнес-додатків та Web- сервісів [9]. В області програмування відсутнє чітке визначення критеріїв, яким має відповідати ПЗ, для достовірного визнання його фреймворком. Часом фреймворки плутають з бібліотеками [14]. Бібліотека, як правило, складається з попередньо написаного коду, класів, процедур, скриптів, конфігурацій і таке інше. Головною перевагою використання бібліотеки полягає в тому, що її можна легко інтегрувати до існуючого проекту з метою скорочення часу розробки. Це стосується значної кількості питань, пов’язаних з основними алгоритмами та функціями, які вже були вирішені іншими досвідченими програмістами. Бібліотека заощаджує час розробників, дозволяючи сконцентрувати увагу на проблемах, пов’язаних з логікою. Проте використання сторонньої бібліотеки також може мати потенційний ризик для програми [15]. 23 У порівнянні з бібліотеками, фреймворки пропонують повний набір корисних функцій й беруть на себе відповідальність за архітектурні рішення у процесі розробки. Фреймворки можуть включати стратегії для маршрутизації URL-адрес у додатку, управління станом, об’єднання та ін. аспекти. Крім того, фреймворки забезпечують поліпшення робочого процесу, такі як передові практики для основних аспектів розробки, включаючи загальну структуру програми або створення шаблонів [14]. Різниця між фреймворком і бібліотекою у тому, що бібліотека може використовуватися у програмному продукті як сукупність підсистем подібної функціональності, не впливаючи на архітектуру основного програмного продукту та не накладаючи на нього жодних обмежень. Фреймворки задають базовий дизайн архітектури програми, який необхідно розширяти та модифікувати відповідно до заданих вимог, формуючи стандартну поведінку на початковому етапі розробки. Також фреймворк може містити допоміжні програми, різноманітні бібліотеки, скриптову мову та інше ПЗ, що допомагає полегшити розробку та інтеграцію різноманітних компонентів програмного проекту. Головною перевагою використання фреймворків є стандартизована структура організації компонентів додатку. Створити таку структуру при розробці на фреймворках досить просто. Фреймворк, в сутності, представляє собою набір конкретних і абстрактних класів, та опис того, як вони між собою взаємодіють. Конкретні класи зазвичай реалізуються для взаємодії, у той час як абстрактні класи є розширеннями, які можуть бути адаптовані або використані фреймворками. Методи об’єктно-орієнтованого програмування часто використовуються для надання розширених функцій, таких як успадкування частин програми від базових класів фреймворку. Виокремимо деякі переваги розробки Web-додатків з використанням фреймворків: 1. Розробка на фреймворку, на відміну так званих “самописних” рішень, сприяє досягненню простоти ремонтоздатності проекту. 24 2. Відносно легко реалізувати будь-які бізнес-процеси, а не лише ті, що спочатку вбудовані в систему. Проекти, що базуються на фреймворках, можна легко масштабувати та модернізувати. 3. Системи, реалізовані з використанням фреймворків, часто працюють швидше й можуть витримувати вище навантаження порівнянно з “самописними” системами. Тому багато популярних Web-додатків базуються на фреймворках. З точки зору безпеки ці рішення також значно перевершують “самописні” системи [22]. Більшість фреймворків для Web-додатків використовують шаблон проектування MVC (Model – View – Controller). Модель Model надає дані та реагує на команди контролера, змінюючи свій стан. Представлення View відповідає за відображення даних моделі користувачу, реагуючи на зміни моделі. Контролер Controller інтерпретує дії користувача, повідомляючи модель про необхідність змін. Схема шаблону MVC представлена на рис. 1.5. Рисунок 1.5 – Схема шаблону MVC Однак можна використовувати інші шаблони, такі як MVP (Model – View – Presenter) або MVVM (Model – View – ViewModel). Це похідні шаблони з MVC. Елемент Presenter у шаблоні Model – View – Presenter бере на себе посередницьку функціональність (аналогічно Controller в MVC) і відповідає за управління подіями інтерфейсу користувача (наприклад, за допомогою миші) так само, як і у інших шаблонах, View зазвичай реагує. Схему шаблона MVP показано на рис. 1.6. 25 Рисунок 1.6 – Діаграма шаблону MVP ViewModel у шаблоні Model – View – ViewModel є, з одного боку, абстракцією View, а з іншого – надає оболонку для даних, які зв’язані з Model. Інакше, він включає в себе Model, який перетворюється у View, і також інструкції, які View може використовувати для впливу на Model. Схему шаблона MVVM показано на рис. 1.7. Рисунок 1.7 – Схема шаблону MVVM У шаблонах проектування MVC/MVP зміни в інтерфейсі користувача безпосередньо не впливають на користувальницький досвід на Model. Вони проходять через Presenter або Controller. У деяких технологіях, таких як Silverlight існує концепція “прив’язка даних”, що дозволяє пов’язувати дані з візуальними елементами в обох напрямках. Відтак, використання моделі MVC стає не зовсім зручним, так як прив’язка даних безпосередньо до представлення не вписується в концепцію MVC/MVP. Проаналізовано сутність Web-програми та визначено основні поняття. В результаті розглянуто основи взаємодії клієнтської та серверної частин Web- 26 додатків, структури Web-сторінок, параметри пошуку Web-елементів та фреймворки для сучасних Web-додатків. Виділено деякі переваги розробки Web-додатків з використанням фреймворків, а саме: 1. Розробка на фреймворку, на відміну так званих “самописних” рішень, дозволяє домогтися простоти ремонтопридатності проекту. 2. Відносно легко реалізувати будь-які бізнес-процеси, а не тільки ті, що спочатку були вбудовані в систему. Проекти, засновані на фреймворках, можна легко масштабувати та модернізувати. 3. Системи, реалізовані з використанням фреймворків, часто працюють швидше і можуть витримувати вище навантаження у порівнянні з “самописними” системами. Тому багато популярних Web-додатків базуються на фреймворках. З погляду безпеки ці рішення також значно перевершують “самописні” системи. 1.5. Формулювання проблемних завдань дослідження − проаналізувати світовий досвід використання методів та засобів автоматизованого тестування Web-додатків, визначити переваги і недоліки їх застосування; − проаналізувати існуючі методи та методології функціонального тестування Web-додатків та привести якісні характеристики існуючих аналогів предмету дослідження; − розробити узагальнену модель функціонування системи автоматизованого тестування Web-додатків; − запропонувати алгоритм проведення автоматизованого тестування корпоративних Web-додатків; − створити тестові випадки та автоматизовані Web-сценарії тестування Web-додатків; − дослідити впровадження автоматизації тестування на прикладі Booking.com: провести аналіз попереднього процесу тестування, зробити 27 обґрунтування вибору артефакту та інструменту його розробки, провести реалізацію набору тестів та провести визначення ефективності. Висновки 1. Систематизована інформація про методи та засоби автоматизованого тестування Web-додатків за рахунок проведеного системного аналізу світового досвіду використання, визначені переваги і недоліки їх застосування. 2. Визначено сутність Web-додатків та їх особливості, досліджено основи взаємодії клієнтської та серверної частин Web-додатків, структуру Web- сторінок, параметри пошуку Web-елементів. 3. Проаналізовано предметну область та визначені основні тенденції розвитку методів та засобів тестування Web-додатків. 4. Сформовано завдання дослідження. 28 РОЗДІЛ 2. СИСТЕМНИЙ АНАЛІЗ СУЧАСНИХ МЕТОДІВ ТА ЗАСОБІВ ТЕСТУВАННЯ WEB-ДОДАТКІВ 2.1. Методи тестування Web-додатків Тестування ПЗ (Software testing) – це процес перевірки відповідності між фактичною та очікуваною поведінкою програми, що виконується на кінцевій множині тестів, які обрані заздалегідь. У більш широкому контексті тестування є одним з методів контролю якості, що охоплює заходи щодо планування робіт, розробки тестів, виконання тестів та аналізу результатів. Розглянемо різновиди тестування ПЗ [15]. Усі види тестування ПЗ, в залежності від поставлених завдань, можна класифікувати за такими групами: 1. Функціональні. 2. Нефункціональні. 3. Пов’язані зі змінами. Розглянемо кожен окремий різновид тестування, його призначення та використання у тестуванні ПЗ. Функціональні тести базуються на функціях та взаємодіях з іншими системами. Такі тести можуть бути представлені на всіх рівнях тестування: компонентному або модульному, інтеграційному, системному та приймально- здавальному. Функціональні види тестування враховують зовнішню поведінку системи. Розглянемо деякі з найпоширеніших типів функціональних тестів: 1. Тестування взаємодії. 2. Тестування безпеки. 3. Функціональне випробування. Нефункціональні тести, необхідні визначення характеристик ПЗ, які можна виміряти різними способами. Дисфункція тестування – це тестування того, як працює система. Основні види дисфункційних тестів: 29 1. Тестування продуктивності: − навантажувальні випробування; − стрес-тестування; − тестування стабільності чи надійності; − велике тестування. 2. Тестування установки. 3. Юзабіліті-тестування. 4. Тестування на відмову та відновлення. 5. Тестування конфігурації. Після внесення необхідних змін, таких як усунення дефекту, необхідно провести повторне тестування ПЗ, щоб переконатися, що проблема дійсно вирішена. Після встановлення ПЗ рекомендується виконати ряд видів тестувань для підтвердження коректної роботи програми або що дефект був виправлений правильно: 1. Димові випробування. 2. Регресійне тестування. 3. Тестування збирання. 4. Санітарні випробування (перевірка відповідності). Тепер розглянемо основні поняття та прийоми тестування Web-додатків. Верифікація – це оцінка системи або її компонентів з метою визначення результатів поточного етапу розвитку, відповідно до умов, сформованих на початку цього етапу. Оцінюється виконання цілей, дотримання крайніх термінів та завдань розробки проекту, визначених на початку поточного етапу [19]. Валідація – це визначення відповідності розробленого ПЗ очікуванням та потребам бізнес-замовника, а також системним вимогам. План випробувань – це документ, що описує весь обсяг робіт з випробувань, починаючи з опису об’єкта, стратегії тестування, графіка тестування, критеріїв початку та закінчення, обладнання, необхідного для експлуатації, спеціальних знань та оцінки ризиків з варіантами їх вирішення. 30 Грамотно складений план тестування повинен включати відповіді на такі питання: 1. Що має бути перевірено? Відповідь на це питання має містити опис об’єкта тестування, такого як додатки, системи та апаратного забезпечення. 2. Що саме слід перевірити? Відповідь на це питання має містити опис тестованої системи та її окремих компонентів, а також можливий перелік функцій. 3. Як саме це слід перевірити? Відповідь на це питання повинна включати стратегію тестування, описуючи види тестів та їх використання для даного об’єкта тестування. 4. Коли слід провести тест? Відповідь на це питання має містити послідовність виконуваних робіт: підготовка до тестування, безпосереднє тестування та аналіз результатів відповідно до запланованих етапів розробки. 5. Які критерії потрібні для початку тестування? − наявність випробувального стенду; − завершення етапу розроблення необхідного функціоналу; − повна документація. 6. Які критерії потрібні для проходження тесту? Відповідь на це питання має містити результати випробувань, відповідні критеріям якості продукції: − вимоги до кількості відкритих дефектів дотримані; − витримка певного часу без зміни вихідного коду програми; − витримка певного проміжку часу, не без знаходження нових помилок. Відповівши на ці запитання у плані тестування, можна бути впевненим, що в наявності чудовий проект документу планування тестування. Для того, щоб проект перетворився на серйозний документ, потрібно додати до нього такі пункти: 31 1. Середовище системи, що тестується (опис програмно-апаратних засобів). 2. Обладнання та ПЗ, необхідні для проведення випробувань (випробувальний стенд та його конфігурація, програми для автоматизованого тестування тощо); 3. Ризики та шляхи їх усунення. Розглянемо поняття тестового прикладу. Тестовий приклад представляє собою документ, який детально описує послідовність кроків, конкретні умови та параметри, необхідні для виконання тестування реалізації тестованої функції або її складової частини. Структура тестового прикладу визначається як: Деталізація тестових випадків представляє собою рівень опису етапів тестування та необхідного результату, забезпечуючи раціональне співвідношення між часом виконання та тестовим охопленням. Час завершення тестового завдання визначається як період часу від початку тестового завдання до отримання результату тестування. Крім тестових випадків, в тестуванні існує концепція контрольного списку. Контрольний список є документом, який визначає, що має бути перевірено безпосередньо. На відміну від тестового прикладу, контрольний список має менший рівень деталізації і часто застосовується при тестуванні функціональності з використанням гнучких методологій [1]. Для забезпечення оптимального тестового покриття функціональності використовуються різні методи та стратегії проектування тестів. Тестове покриття розглядається як нова метрика оцінки якості тестування, що визначає щільність тестового покриття вимог або виконуваного коду. Тестовий дизайн представляє собою етап процесу тестування ПЗ, під час якого розробляються та створюються тестові кейси (тестові випадки) відповідно до раніше визначених критеріїв якості та цілей тестування. Більшість проводить тестування та створюють тестові приклади і контрольні списки, але не всі користуються спеціальними методами проектування тестів. Поступово, з досвідом, приходить розуміння, що 32 виконується та сама робота, яка підпорядковується певним правилам. І тоді виявляється, що ці правила є вже описаними. 2.2. Методи проектування тестів Найбільш поширеними методами проектування тестів є: 1. Еквівалентний поділ. Цей метод розбиває функціонал (часто діапазон можливих вхідних значень) на групи, еквівалентні за своїм впливом на систему значень. Такий підхід допомагає перевірити правильність функціонування всієї системи – одного класу еквівалентності, перевіривши лише один елемент групи. Метод полягає у розділенні всього набору тестів на класи еквівалентності, а потім зменшенні кількості тестів. Наприклад, якщо є діапазон допустимих значень від 1 до 10, то необхідно вибрати одне допустиме значення в діапазоні від 2 до 8 і одне неприпустиме значення за межами діапазону – від -1 до негативного значення, дозволеного типом даних, або від 12 до позитивного значення, дозволеного типом даних. 2. Аналіз граничних значень. Цей метод спрямований на виявлення помилок на межі класів еквівалентності. Якщо методика аналізу класів еквівалентності орієнтована на тестове покриття, то ця методика ґрунтується на ризиках та ідеї, що програма може зламатися в області граничних значень. Велика кількість проблем може виникнути на межі вхідних змінних, навіть після правильного визначення еквівалентних класів, граничні значення можуть бути помилково призначені іншому класу. Наприклад, можна вибрати мінімальну та максимальну межі (1 і 10) для позитивного тестування, а також значення більше і менше меж (0 та 11). Метод аналізу граничних значень може бути застосований до полів, записів, файлів чи будь-якого іншого об’єкта з обмеженнями. Графічний приклад класів еквівалентності та граничних значень наведено на рис. 2.1. 33 Рисунок 2.1 – Візуалізація класів еквівалентності та граничних значень 3. Причина/наслідок. Зазвичай включає введення комбінацій умов (причин) для відповіді від системи (наслідків). Наприклад, можна перевірити можливість додавання клієнта через певну екранну форму. Для цього потрібно ввести декілька полів, таких як “Ім’я”, “Адреса”, “Номер телефону”, а потім натиснути кнопку “Додати” – це “Причина”. Після натискання кнопки “Додати” система додає клієнта до БД і виводить на екрані його номер – це і є “Наслідок”. 4. Predicting errors. Відбувається, коли тестовий аналітик використовує свої знання про систему та інтерпретує специфікацію, щоб “передбачити”, при яких вхідних умовах система може видати помилку. Наприклад, якщо специфікації говорить: “користувач повинен ввести код”. Тестовий аналітик подумає: “А що, якщо я не введу код?”, “А що якщо я введу неправильний код?” тощо. Це є передбаченням помилки. 5. Вичерпне тестування – це крайній випадок. За цією технікою потрібно перевірити всі можливі комбінації вхідних значень, що, в принципі, має виявити всі проблеми. Проте на практиці цей метод непрактичний через велику кількість вхідних значень. Якщо помилка виявлена в системі під час тестування або експлуатації, то перед її виправленням створюється опис цієї помилки у відповідній системі відстеження помилок або системі управління проектом. Звіт про помилку – це документ, що описує ситуацію або послідовність дій, що призвели до неправильної роботи об’єкта, що призвели до неправильної роботи об’єкта, із зазначенням причин та очікуваного результату. Ознайомившись з коротким описом помилки, розробник повинен зрозуміти, у чому полягає проблема. При ознайомленні з докладним описом дефекту, варто 34 знати фактичний рядок коду для виправлення. Правильно оформлений звіт про помилку економить час розробника, а також повинен мати визначений рівень серйозності або пріоритет. 2.3. Рівні серйозності та пріоритету дефектів Розглянемо рівні серйозності та пріоритету дефектів: 1. Функція блокування (Blocker) – це помилка блокування, що призводить до збою програми і заважає подальшій роботі з тестованою системою або її ключовими функціями. Вирішення цього дефекту є необхідним для продовження роботи системи і має найвищий пріоритет. 2. Критична (Critical). Критична помилка, яка впливає на ключову бізнес-логіку, що не працює належним чином, вразливість безпеки або проблема тимчасового виведення з ладу сервера або деякої частини системи, не маючи можливості вирішити проблему за допомогою інших вхідних точок. Вирішення цього завдання необхідне для подальшої роботи з ключовими функціями тестованої системи, і цей дефект також має найвищий пріоритет. 3. Суттєва (Major). Істотна помилка, яка впливає на деякі з основних бізнес-логік. Помилка не критична, і можна працювати з тестованою функцією, використовуючи інші вхідні точки. Пріоритет цього дефекту є середнім [3]. 4. Незначна (Minor). Помилка, яка не порушує бізнес-логіку тестованого додатка, але стосується очевидної проблеми інтерфейсу користувача. Цей дефект має низький пріоритет. 5. Тривіальна (Trivial). Тривіальна помилка, яка не впливає на бізнес- логіку програми, малопомітна через інтерфейс користувача чи стосується сторонніх бібліотек або сервісів або проблема, що не впливає на загальну якість продукту. Цей дефект також має низький пріоритет. Правильне визначення серйозності та пріоритету допомагає, в першу чергу, виправляти найкритичніші системні дефекти, які можуть повністю блокувати роботу користувачів системи. 35 Отже, компанії, що не використовують цю систему, можуть зазнати значних фінансових втрат через низьку якість програмного продукту. 2.4. Класифікація засобів тестування Не так давно, тестування програм здійснювалось вручну або самими програмістами, або користувачами, що навряд чи можна вважати системним підходом й не давало змоги оцінити якість коду. Пізніше тестування відокремилося до іншої галузі знань у складі розробки ПЗ, але виявилося, що тестування вручну є неефективним, оскільки вимагає значних трудових і часових витрат. Перші засоби автоматизації тестування фактично були бібліотеками, які використовувалися для написання тестів і вимагали від тестувальника вміння програмувати на рівні розробника. Сучасні засоби автоматизованого тестування дозволяють створювати автоматизовані тести за мінімальної участі людини [24]. Якщо розглядати поверхневу класифікацію, то засоби автоматизації тестування можна розділити на дві категорії: − інструменти функціонального тестування; − інструменти тестування навантаження. До першої категорії відносяться інструменти, призначені для перевірки того, наскільки додатки відповідають бізнес-вимогам. Другу категорію утворюють інструменти, які призначені для оцінки та перевірки продуктивності додатків. На початковому етапі розвитку програмних систем їх розробка відбувалася в межах програм наукових досліджень чи для задоволення потреб міністерств оборони. Тестування таких продуктів проводилося строго формалізовано із записом всіх тестових процедур, тестових даних, отриманих результатів. Тестування виділялося в окремий процес, який починався після завершення кодування, але часто виконувалося тим же персоналом. 2.5. Розвиток підходів до тестування програмного забезпечення У 1960-х роках велика увага приділялася “вичерпному” тестуванню, яке має мало включати усі можливі шляхи у коді або всі можливі вхідні дані. Однак 36 було визнано, що в таких умовах повне тестування ПЗ неможливе. По-перше, через велику кількість можливих вхідних даних. По-друге, через множину шляхів у коді. По-третє, складно виявити проблеми в архітектурі та специфікаціях. З цих причин “вичерпне” тестування було відхилено та визнано теоретично неможливим. На початку 1970-х тестування ПЗ описувалось як “процес, спрямований демонстрацію коректності продукту” чи як “діяльність з підтвердження правильності роботи ПЗ”. У час зародження програмної інженерії, верифікація ПЗ тлумачилася як “доказ правильності”. Незважаючи на теоретичну перспективність концепції, на практиці виявилось, що вона вимагала значного часу і не була всеосяжною. Було визнано, що “доказ правильності” є неефективним методом тестування ПЗ. Проте в сучасних умовах іноді застосовується демонстрація коректної роботи, наприклад, під час приймально- здавальних випробувань. У другій половині 1970-х тестування визначалося як виконання програми з метою виявлення помилок, а не доведення її працездатності. Успішним тест тепер вважався за умови виявлення раніше невідомих проблем. Цей підхід є прямо протилежним попередньому. Зазначені два визначення утворюють “парадокс тестування”, який базується на двох протилежних твердженнях: з одного боку, тестування дозволяє впевнитися, що продукт працює належним чином, а з іншого – виявляє помилки у ПЗ, показуючи, що продукт не є ідеальним. Друга мета тестування виявляється більш продуктивнішою в плані покращення якості, оскільки дозволяє виявити та усунути недоліки ПЗ. У 1980-х тестування значно розширило свій зміст, введеною концепцією попередження дефектів. Проектування тестів визначалося як найефективніший із відомих методів уникнення помилок. В цей період стали висловлюватися ідеї, що необхідна систематична методологія тестування, включаючи перевірки протягом усього циклу розробки, який має бути керованим процесом. У ході тестування потрібно перевіряти не лише зібрану програму, а й вимоги, код, архітектуру, тести. 37 Термін “традиційне” тестування, що існувало до початку 1980-х, стосувалося виключно скомпільованої готової системи (зазвичай це називається системним тестуванням), однак тестувальники почали залучатися до всіх етапів життєвого циклу розробки. Це дозволяло виявляти проблеми у вимогах та архітектурі на ранніх етапах, сприяючи тим самим скороченню термінів та бюджету розробки [23]. В середині 1980-х з’явилися перші інструменти автоматизованого тестування. Передбачалося, що ПК зможе виконати більше тестів, ніж людина, і це зробить процес більш надійним. Спочатку ці інструменти були простими і не мали можливості написання сценаріїв на скриптових мовах. На початку 1990-х термін “тестування” включав в себе планування, проектування, створення, підтримку та виконання тестів і тестових оточень. Це позначило перехід від терміну тестування до забезпечення якості, охоплюючи весь цикл розробки ПЗ. З цього часу з’являються різноманітні програмні інструменти підтримки процесу тестування: розширені автоматизовані середовища з можливістю створення скриптів та генерації звітів, системи управління тестами, ПЗ для проведення тестування навантаження. З розвитком Інтернету в середині 1990-х і великою кількістю Web-додатків особливу популярність набуло “гнучке тестування” (за аналогією з гнучкими методологіями програмування). У 2000-х роках тестування отримало ще ширший контекст, коли було введено поняття “оптимізація бізнес-технологій” BTO (Business Technology Optimization). BTO націлює розвиток інформаційних технологій відповідно до бізнес-цілей. Основна стратегія полягає в оцінці та максимізації значущості всіх етапів життєвого циклу розробки ПЗ для досягнення необхідного рівня якості, продуктивності та доступності. Відрізняються між собою тестування Web-додатків від тестування інших програм тим, що при тестуванні Web-додатків застосовуються ті самі класичні методи та техніки проектування тестів, коли Web-програми мають простіший 38 інтерфейс порівняно з “десктопними” програмами, і користувачі можуть легко застосовувати браузер без будь-яких спеціальних навичок. Проте існують особливості, пов’язані з соціальними та технологічними аспектами Web-додатків, що відрізняють їх від інших видів програм, і які необхідно враховувати під час тестування для його професійного виконання: − велике різноманіття технологій, які застосовуються за фасадом браузера, оскільки кожен Web-додаток є складовою всесвітньої павутини, включаючи різні компоненти; − швидкість розвитку Web-розробки в усіх аспектах – короткі релізи, вимоги, що швидко змінюються, постійне вдосконалення технологій, розробка нових, різноманітність користувачів, від випадкових відвідувачів до постійних клієнтів різного віку та досвіду, а також потреба у високому рівні безпеки [11]. 2.6. Порівняння автоматизованого та ручного підходів у тестуванні Web-додатків Одна з головних відмінностей між ручним та автоматизованим тестуванням ПЗ − це суб’єкт, який виконує тести. При ручному тестуванні людина виконує кожен тест, взаємодіє з ним, аналізує та надає результати, тоді як автоматизоване тестування можливе без прямого втручання людини. Повна автоматизація вимагає можливості запускати тести без участі людини та автоматично аналізувати результати, порівнюючи їх з очікуваними показниками [2]. Має існувати можливість зняти потрібні показники та результати тестів, порівняти їх з очікуваним результатом, виявити відмінності та відзначити статус усіх тестів, які були пройдені успішно або провалені. Ручне тестування підходить для випадків оцінки та виконання складних рутинних завдань. В той же час, автоматизоване тестування стає ефективним при великій кількості повторюваних завдань або генерації великої кількості даних. Таким чином, автоматизоване тестування виправдане для випадку, де ручне тестування є рутинною повторюваною задачею, але при цьому варто 39 пам’ятати, що автоматизовані тести не можуть повністю замінити ручного тестування, так як навіть дуже схожі тести, виконані вручну та автоматично мають різну цінність для тестування. Отже, важливо автоматизувати ті тести, які є простими і зрозумілими. Надто складні тести можуть виявитися неефективними, а їх підтримка збільшить вартість використання, перекриваючи усі можливі переваги [21]. Тести, призначені для автоматизації конкретного сценарію тестування, складаються не лише з автоматизованих кроків, але також і інших етапів, що сприяють ефективному повторному використанню тестів. У праці “Як автоматизувати тестування” Кейт Стобі та Марк Бергман виокремлюють наступні етапи [3]: 1. Налаштування – підготовка ПЗ до стану, коли воно готове до виконання тесту. 2. Виконання – основний етап випробування, включаючи конкретні кроки для перевірки функціональності та обробки помилок тощо. 3. Аналіз – складний процес визначення успішності тесту та його результатів. 4. Звітність – відображення та доставка аналізу результатів тесту, таких як файли журналів, БД або інші файли, згенеровані в ході або після виконання тесту. 5. Очищення – відновлення ПЗ до початкового стану для незалежного виконання пройденого раніше тесту. 6. Допомога – підтримка та забезпечення надійності тесту протягом його життєвого циклу. Важливо відзначити, що як ручне, так і автоматизоване тестування можуть бути використані спільно на кожному з описаних етапів тестування. Можливо використовувати автоматизовані кроки для встановлення та налаштування програми, виконання тестів, розсилки результатів та очищення за необхідності виконання ручного аналізу результатів тесту або забезпечення надійності виконання тестів протягом часу. 40 Як було зазначено, ручне та автоматизоване тестування представляють собою два різних підходи тестування, що не можуть замінити один одного. Для підвищення корисного ефекту, який випливає з переваг кожного підходу, автоматизовані тести слід застосовувати разом з ручними тестами. Здійснимо якісне порівняння ручного та автоматизованого тестування у формі переліку переваг та недоліків автоматизованих тестів. Основні переваги автоматизованого тестування включають [4]: − точність та повнота виконання. Автоматизоване тестування гарантує, що тести проводяться повністю і точно відповідно до сценарію. В той час як ручне тестування схильне до людського фактору (втоми або низької концентрації спеціаліста тестування), який викликає упущення та помилки при виконанні тесту; − точність результатів та звітності. Результати автоматизованих тестів, представлені у файлах журналів та звітах, відзначаються високою точністю. Ці дані легше аналізувати порівняно із результатами ручних тестів; − повнота інформації по тестах. Автоматизовані тести забезпечують більш доступні дані, зібрані під час випробувань, порівняно з результатами ручного тестування; − економія людських ресурсів. Використання автоматизованого тестування заощаджує людські ресурси, так як менше залежить від участі співробітників. Це важливо для залучення людей при виконанні більш важливих завдань; − швидкість виконання та можливість повторного використання тестів. Автоматизовані тести, як правило, виконуються швидше й можуть бути запущені безперервно, надаючи швидкі та часті результати тестування. Отже, автоматизоване тестування є ефективним методом для покращення точності, швидкості та ефективності випробувань ПЗ; − продуктивність повного регресійного тестування. Автоматизація дозволяє розширити діапазон регресійних тестів і збільшує шанс виявлення помилок, внесених при виправленні раніше знайдених проблем; 41 − виконання видів тестів, що виходять за рамки ручного тестування. Автоматизація тестування дозволяє спеціалістам проводити тести продуктивності для середніх або великих систем, що є неможливим виконати вручну. Проте існують і основні недоліки автоматизованого тестування: − вимагає значних початкових фінансових витрат на придбання, впровадження інструментів та навчання фахівців автоматизації тестування; − потребує високої кваліфікації спеціалістів для ефективного проведення автоматизованих тестів; − не може забезпечити повне покриття автоматизованими тестами. Так як інструменти автоматизованого тестування не охоплюють всіх аспектів засобів розробки та інших додатків, залишається необхідність у ручному тестуванні. Розглянувши обидва підходи до тестування, можна зробити висновок, що ні автоматизоване, ні ручне тестування не може повністю замінити одне одного. Незважаючи на недоліки кожного підходу, вони мають сої унікальні переваги, і грамотне поєднання цих методів дозволить досягти якісного поліпшення процесу тестування та розробки ПЗ в цілому. 2.7. Методології розробки та тестування програмного забезпечення Як і процес розробки, процес тестування ПЗ відповідає певній методології. В цьому випадку під методологію розглядається різноманіття комбінацій принципів, ідей, методів та концепцій, які використовуються під час роботи над проектом. З іншого боку, існує значна кількість різних підходів до тестування, кожен з яких має свої відправні точки, час виконання та методи, що використовуються на кожному етапі. Вибір конкретного підходу може бути досить складним завданням [17]. Розглянемо різні існуючі підходи до тестування ПЗ та їх основні особливості. 42 Каскадна модель (Модель водоспаду) є однією з найстаріших моделей, яку можна використовувати не лише для розробки ПЗ чи тестування, але практично для будь-якого проекту. Основний принцип полягає в послідовному виконанні завдань, тобто перехід до наступного етапу розробки чи тестування відбувається лише після успішного завершення попереднього. Ця модель підходить для невеликих проектів і застосовна лише в тоді, якщо всі вимоги чітко визначені. Основні переваги цієї методології включають економічну ефективність, простоту використання та управління документацією. Сам процес тестування ПЗ розпочинається після завершення процесу розробки. На цьому етапі всі необхідні випробування передаються від компонентів до системних випробувань з метою контролю роботи компонентів як окремих елементів, так і у комплексі. Схема каскадної моделі показана на рис. 2.2. Затвердження вимог Проектування Розробка Тестування Підтримка Рисунок 2.2 – Схема каскадної моделі Окрім переваг, які були згадані вище, такий підхід до тестування має свої недоліки. Завжди є можливість виявлення критичних помилок у процесі тестування. У будь-який момент може виникнути ситуація, де тестування виявить критичні помилки. Це може призвести до необхідності радикально змінити один із компонентів екосистеми або навіть переглянути всю логіку проекту. Однак це завдання є неможливим у випадку каскадної моделі, оскільки ця методологія забороняє повертатися до попереднього кроку. 43 Метод V-моделі, так само як і каскадна модель, ґрунтується на прямій послідовності кроків. Основна відмінність між цими двома методологіями полягає в тому, що тестування планується паралельно з відповідним етапом розробки. Згідно з цією методологією, тестування ПЗ розпочинається, як тільки вимоги визначені і є можливість розпочати статичне тестування. Це включає в себе перевірку і аналіз, що дозволяє уникнути потенційних дефектів на пізніх етапах розробки. Для кожного рівня розробки ПЗ будується відповідний план тестування, який визначає очікувані результати, а також критерії входу та виходу даного продукту. На схемі цієї моделі відображено принцип поділу завдань на дві частини: ліворуч розташовані ті, що стосуються проектування та розробки; тоді як завдання, пов’язані з тестуванням ПЗ, показані праворуч (рис. 2.3). Рисунок 2.3 – Модель верифікації та валідації Основні етапи цієї методології можуть варіюватися, але, як правило, вони включають наступне: 44 1. Етап визначення вимог, який включає приймальні випробування. Основне завдання цього етапу полягає в оцінці готовності системи до кінцевого використання. 2. Стадія високорівневого проектування (High-Level Design) пов’язана із тестуванням системи та включає оцінку відповідності вимогам, які пред’являються до інтегрованих систем. 3. Етап Detailed Design, що відбувається паралельно з фазою інтеграційного тестування, перевіряє взаємодію між різними компонентами системи. 4. Етап написання коду, коли система вже безпосередньо розробляється. 5. Після етапу написання коду починається ще один важливий етап – тестування, включаючи модульне тестування, інтеграційне тестування та приймальне тестування. Дуже важливо переконатися, що поведінка окремих частин і компонентів ПЗ коректна й відповідає вимогам. Єдиним недоліком розглянутої методології тестування є відсутність готових рішень, які можна застосовувати для усунення виявлених дефектів ПЗ на етапі тестування. Методологія мультикаскадної моделі (Multi-Stage Software Testing Model). Робочий процес поділено на декілька циклів, кожен з яких також поділено на модулі. Кожна ітерація додає до ПЗ конкретну функціональність. Інкремент складається із трьох циклів: 1. Проектування та розробка. 2. Тестування. 3. Реалізація. Ця модель дозволяє одночасно розробляти різні версії продукту. Наприклад, перша версія може проходити тестування, тоді як друга версія все ще перебуває на стадії розробки. Третя версія може пройти стадію проектування одночасно. Цей процес може продовжуватися до завершення проеку. 45 Очевидно, що ця методологія передбачає найшвидше виявлення якомога більшої кількості помилок у ПЗ. Це необхідно для підтвердження готовності продукту до відправлення кінцевому користувачу. Всі ці фактори значно збільшують вимоги до процесу тестування. Схема інкрементної моделі представлена на рис. 2.4. У порівнянні з попередніми методологіями, інкрементна модель має низку ряд вагомих переваг. Вона проявляє більшу гнучкість, так як зміни у вимогах призводять до зниження витрат, а процес тестування ПЗ є ефективнішим, завдяки простоті проведення тестування та налагодження за допомогою невеликих ітерацій. Однак слід відзначити, що загальна вартість все ж таки вища, ніж у випадку каскадної моделі. Рисунок 2.4 – Інкрементна модель Спіральна модель є методологією тестування ПЗ, побудованою на інкрементному підході та прототипуванні. Вона складається з чотирьох етапів: 1. Планування; 2. Аналіз ризиків; 4. Розвиток; 5. Оцінка. Відразу після завершення першого циклу починається другий цикл. Тестування ПЗ розпочинається на етапі планування та триває до етапу оцінки. 46 Основною перевагою спіральної моделі є те, що результати тестувань стають доступними вже на третьому етапі кожного циклу, що сприяє правильній оцінці якості. Однак важливо враховувати, що ця модель може бути досить дорогою і не є оптимальною для невеликих проектів. Схема спіральної моделі показана на рис. 2.5. Рисунок 2.5 – Спіральна модель Навіть не дивлячись на те, що ця модель є досить старою, вона залишається корисною як для тестування, так і для розробки. Більше того, останнім часом змінилася основна мета багатьох методологій тестування ПЗ, включаючи спіральну модель. Вона використовує їх не лише для пошуку дефектів у додатках, але й для визначення причин, що їх викликали. Такий підхід допомагає розробникам працювати більш ефективно та оперативно виправляти помилки. Методологію розробки та тестування ПЗ Agile − це сукупність підходів, орієнтованих на використання інтерактивного процесу розробки, динамічне формування вимог та забезпечення їх реалізації в результаті постійної взаємодії в межах самоорганізованої робочої групи. 47 Більшість гнучких методологій розробки ПЗ спрямовано на мінімізацію ризиків за допомогою розробки короткими ітераціями. Одним із ключових принципів цієї гнучкої стратегії є можливість швидко реагувати на можливі зміни, а не залежати від довгострокового планування. Схема гнучкої методології наведена на рис. 2.6 Рисунок 2.6 – Схема Agile Екстремальне програмування – це приклад гнучкого методу розробки ПЗ, де особливий акцент робиться на парному програмуванні. В цьому випадку один розробник активно працює над кодом, а інший постійно здійснює перегляд написаного коду. Процес тестування ПЗ відіграє важливу роль, розпочинаючись ще до написання першого рядка коду. Кожен модуль програми повинен включати модульний тест, щоб виявити більшість помилок на етапі написання коду. Ще однією особливістю є те, що тест визначає код, а не навпаки. Це означає, що певна частина коду може вважатися завершеною лише у разі успішного проходження всіх тестів. В протилежному випадку код відхиляється. Основні переваги цієї методології включають безперервне тестування та короткі релізи, що сприяє високій якості коду. Scrum є частиною методології Agile, ітеративної інкрементної структури, призначеної для управління процесом розробки ПЗ (рис. 2.7). 48 Рисунок 2.7 – Схема Scrum Згідно з принципами Scrum, команда тестувальників повинна брати участь у таких етапах: 1. Участь у Scrum-плануванні. 2. Підтримка модульного випробування. 3. Тестування історій користувача. 4. Співпраця із замовником та власником продукту для визначення критеріїв достатності. 5. Забезпечення автоматичного тестування. Крім того, члени команди QA (Quality Assurance Team Members) повинні бути присутніми на щоденних зборах разом із іншими членами команди для обговорення вже випробуваного та просування загального прогресу тестування. Тим часом, принципи гнучкої методології в Scrum призводять до виникнення конкретних особливостей: 1. Обов’язкова оцінка зусиль, необхідних для кожної історії користувача. 2. Тестувальник повинен приділяти увагу вимогам, оскільки вони можуть постійно змінюватися. 3. Зростає ризик регресії разом із частими змінами коду. 4. Одночасне планування та виконання тестів. 49 5. Виникають непорозуміння між членами команди, якщо вимоги замовника не до кінця зрозумілі. У цьому розділі досліджено та проаналізовано методи та засоби тестування програмного продукту, зокрема Web-додатків, у життєвому циклі розробки ПЗ, а також визначено переваги та недоліки відповідних методів і засобів. Крім того, встановлено, що функціональне (ручне) тестування вигідніше використовувати при розробці нового бізнес-процесу, а автоматизоване рішення доцільніше використовуватиме для перевірки існуючого функціоналу. Висновки 1. Систематизована інформація про існуючі методи та методології функціонального тестування Web-додатків за рахунок проведеного системного аналізу, приведені якісні характеристики існуючих аналогів предмету дослідження. 2. Проведена якісна оцінка засобів автоматизованого тестування Web- додатків за такими параметрами як ремонтопридатність, виконання та використання в системах безперервної інтеграції та надано рекомендації по їх використанню. 50 РОЗДІЛ 3. ОСОБЛИВОСТІ ФУНКЦІОНАЛЬНОГО ТЕСТУВАННЯ ТА СТВОРЕННЯ ТЕСТОВИХ ЗРАЗКІВ ДЛЯ WEB-ДОДАТКІВ 3.1. Визначення сутності функціонального тестування Web-додатків Компанія Netcraft, яка проводить щомісячні дослідження Web-простору, оцінює кількість активних сайтів у світі станом на грудень 2023 року в 2,9 млрд. Це на 14 % більше, ніж у попередньому році. Розглядаючи ці дані, стає зрозумілим, чому в світі активно розробляється велика кількість нових Web- додатків. Процес розробки Web-додатків викликає потребу залучення різноманітних ІТ-фахівців. Зростання Всесвітньої павутини підтверджується застосуванням хмарних технологій, що відображається навіть у відомих настільних програмах, таких як Word і Excel, представлених тепер як Web- альтернативи від Microsoft. Враховуючи це, можна припустити, що потреба в висококваліфікованих інженерах із забезпечення якості, які спеціалізуються на Web-продуктах, тільки зростатиме. Як вже зазначалося вище, Web-додатки ґрунтуються на клієнт-серверній архітектурі, й тестування таких додатків має свої відмінності. Клієнт є першим компонентом архітектури. Зазвичай клієнтом є Web-браузер, що робить актуальним питання тестування кросбраузерної сумісності через різноманіття браузерів. Кросбраузерне тестування – це перевірки на відповідність вимогам та стандартам відображення та функціонування Web-програми в різних браузерах та на різних операційних системах (ОС). Хоча стандартизація в сучасному світі набуває глобального розмаху, більшість популярних браузерів обробляють код однаково. Тим не менш, необхідність у кросбраузерному тестуванні залишається, оскільки стандартизація не вирішує всі можливі проблеми. Перед початком роботи варто ознайомитися з необхідною низкою браузерів для ПЗ. Це дозволяє збирати статистику з цільової аудиторії продукту та обмежувати перевірку кросбраузерної сумісності лише найпопулярнішими браузерами в цій цільовій аудиторії. 51 У випадку регресійного тестування, коли є обмеження часу та людських ресурсів, корисним є застосування розподілу браузерів: призначити кожному тестувальнику конкретний браузер, що допомагає охопити значну кількість кросбраузерних дефектів. Тим не менше, цей підхід найбільш ефективний великим тестувальним командам і може бути непрактичним, коли у команді є лише один фахівець із якості. Критеріями для кросбраузерного тестування є: 1. Функціональність продукту, що реалізується на стороні клієнта. 2. Правильне відображення графічних елементів. 3. Шрифти та розміри текстових символів. 4. Доступність та функціональність різних форм, включаючи їх інтерактивність. Тестування всіх основних браузерів цільової аудиторії є необхідністю. Крім того, варто звернути особливу увагу на Internet Explorer через його високий ризик виникнення проблем, яких може і не бути у інших браузерах. Також рекомендується в Internet Explorer вдосконалити масштабованість та продуктивність JavaScript. Для тестування Web-інтерфейсу додатків існують спеціальні інструменти – валідатори. Вони перевіряють відповідність документу, потоку даних або фрагмента коду певному формату. Якщо не вистачає знань для оцінки відповідності макета стандартам, можна використовувати автоматичні інструменти та проаналізувати результати, щоб вказати розробникам найбільш серйозні помилки. Важливо пам’ятати, що валідатори іноді виявляють навіть найменші помилки, які, швидше за все, залишаться без уваги. Запустивши звіти про дефекти цього типу, з’явиться можливість зручно об’єднати їх в один документ і включити до звіту. До цієї категорії “дрібниць” можна віднести різноманітні рекомендації, які не мають впливу на відображення та функціонування контенту. Приклад роботи валідатора наведено на рис. 3.1. 52 Рисунок 3.1 – Приклад роботи валідатора W3C Як видно з рис. 3.1., у першому прикладі, тегу img не вказаний атрибут Alt. Атрибут Alt визначає текст, що буде виведено, якщо, наприклад, зображення вимкнено або його не вдалося завантажити через повільне Інтернет-з’єднання. Це особливо важливо для людей із проблемами зору, які часто користуються спеціальними програмами читання екрану, такими як скринрідери. Ці програми ідентифікують та інтерпретують події на екрані, і, якщо текст для зображення не наданий, людина не отримає інформації про його вміст. Одним з важливих елементів Web-додатків є форми заповнення, через які користувач взаємодіє з клієнтом. Однак ці форми часто є джерелом дефектів, які можуть призвести до значних фінансових та репутаційних втрат для компанії. Щоб уникнути пропуску помилок у формах в продуктивному середовищі, необхідно: 1. Ретельно перевіряти, чи всі поля форми заповнені й чи правильно вони позначені. 2. Після заповнення і відправки форми, слід переконатися, що дані відповідають очікуванням. Наприклад, при введені даних до БД, слід перевірити правильність заповнення полів у всіх необхідних таблицях, користуючись знанням мови структурованих запитів SQL та доступом до БД, схем та таблиць. 3. Використовувати чат-листи для тестування форм. Це означає використовувати повторні перевірки використовувати у різних тестових сценаріях з їх подальшим багаторазовим використанням. Наприклад, до таких 53 перевірок можна віднести введення можливих і неможливих значень типів даних, спеціальних символів або символів в іншому кодуванні. 4. Перевіряти відображення інформаційних повідомлень, що зрозумілі користувачу, щодо необхідності заповнення порожніх полів після спроби відправлення форми. 5. Звертати увагу на екрануючі символи у полях форми, які можуть стати джерелом вразливостей для програми та користувачів. Важливо, щоб екранування здійснювалося не тільки на рівні клієнта, але й на рівні сервера, що досить легко відключити в клієнті (наприклад, за допомогою спеціальних плагінів, що знімають всі можливі обмеження). 6. Переконатися, що користувач отримує підтверджуючий лист після заповнення форми, який вказує відправника та відповідає вимогам, наприклад, щодо робочих посилань. 7. Використовуйте спеціальні інструменти для тестування форм, наприклад, Web Developer Toolbar, щоб забезпечити ефективніше та точніше тестування. Інтернет має особливу цінність як практично безмежне джерело інформації, яка часто представлена у формі текстів, що взаємодіють з користувачем через клієнтський інтерфейс. Більшість Web-ресурсів потребує перевірки текстів на граматичні та друкарські помилки. Значимість такого тестування менш важливе порівняно з функціональним тестуванням, але ігнорувати його не варто. Для перевірки орфографії існують програми, які доступні онлайн або у вигляді плагінів для браузера. Одним із ефективних інструментів перевірки орфографії, що надається українською компанією – є OnlineCorrector. Він допомагає виявляти та виправляти орфографічні помилки в українських та англійських текстах, використовуючи власні мовні моделі, що складаються з великої кількості слів і фраз, та бібліотеки машинного навчання для ефективного пошуку друкарських помилок та адаптації до контексту. Ця бібліотека дозволяє розшифровувати слова, спотворені до невпізнання, враховуючи контекст під час 54 пошуку друкарських помилок. Крім того, технологія орфографії не чіпляється за нові слова, які ще не увійшли до словників. Для вбудовування OnlineCorrector в додаток достатньо користуватися його API (набір готових класів, процедур, функцій, структур та констант, що надаються додатком або ОС для використання у зовнішніх програмних продуктах). Обмеження на використання сервісу зазначено в угоді з користувачем. Тестування Web-додатка, який знаходиться на Web-сервері, також може виконуватися без графічного (клієнтського) і Web-інтерфейсу, але це вимагає від фахівця високого рівня технічних знань і навичок використання додаткових інструментів. Усі компоненти Web-програми взаємодіють через HTTP(s), що є ключовим для її функціонування. HTTP використовується для передачі даних, що є необхідним у клієнт-серверній архітектурі. Взаємодія здійснюється через повідомлення, де відповідь сервера надсилається на запит клієнта. Приклад відповіді сервера показано на рис. 3.2. Стандартний запит/відповідь має 3 складові: 1. Початковий рядок. 2. Назва. 3. Тіло повідомлення. У процесі аналізу відповідей фахівець з тестування повинен перевірити методи та коди стану, які вказані в початковому рядку. Рисунок 3.2 – Приклад відповіді від сервера 55 Найпоширенішими методами, які описані у першому розділі роботи, є GET та POST, хоча існують й інші методи, такі як PUT, DELETE, CONNECT і т.д. Проте вони використовуються не так часто, ніж методи GET та POST. Для створення запитів часто використовуються класичні програмами, такі як Fiddler або Postman. За допомогою цих інструментів можна легко відстежувати всі запити від клієнта та відповіді, переглядати їх деталі, вносити власні зміни та надсилати змінені запити на сервер, аналізуючи поведінку системи у даному випадку. Під час тестування запитів важливо: 1. Переконатися, що використовується правильний метод для конкретного запиту. 2. Розібратися у змісті запитів, особливо логічно зрозумілих звичайному користувачеві, таки як GET. Аналіз запитів може виявити приховані дефекти швидше, ніж їх пошук у інтерфейсі. 3. Відслідковувати трафік для запитів до інших серверів. 4. Уважно спостерігати за кодами стану під час відстеження трафіку. Кожна відповідь на запит містить значущу інформацію для розробників та фахівців з тестування ПЗ. Одним з ключових джерел такої інформації є код стану. Клієнт може отримати результати свого запиту та визначити подальші кроки, використовуючи цей код. Набір кодів стану є стандартним і описаним у відповідних документах RFC (Request for Comments, запит коментарів). Кожного разу, коли створюється повідомлення про помилку щодо неробочих посилань, елементів Web-сторінки або системних неполадок, потрібно вказувати коди відповідей сервера. Це допомагає розробникам ефективно визначати причини дефекту, що сприяє заощадженню їх часу. Всі коди класифікують за групами (соті, двохсоті, трисоті, чотирисоті і п’ятисоті), кожна з яких має свій тип інформації. Детальна таблиця з групами кодів стану наведена табл. 3.1. 56 Таблиця 3.1 – Групи кодів стану для відповідей із сервера Тип інформації Код Призначення коду Інформація про передачу повідомлення. Самі повідомлення від сервера містять лише lxx Інформуючі стартовий рядок відповіді та, якщо потрібно, декілька специфічних для відповіді полів заголовку. Повідомляють про Інформування про успішну обробку запиту клієнта. 2хх успішну операцію Найкласичнішим і найпоширенішим є «200 ОК». Повідомляє, що для успішного виконання операції необхідно зробити інший запит. З цього типу п’ять кодів: 301, 302, 303, 305 і 307, Зхх Перенаправляючі відносяться безпосередньо до перенаправлення. Адреса, за якою клієнту потрібно зробити запит, сервер вказує в заголовку Location. Вказівки на помилки з боку клієнта. При Помилка на стороні 4хх використанні всіх методів, крім HEAD, сервер клієнта (запит) повертає пояснення причин. Помилка на стороні Інформує про помилки виконання операції з вини 5хх сервера (відповідь) Web-сервера. На практиці, за допомогою спеціальних програм тестування, можна ефективно відсортовувати запити та відповіді за кодами стану. Наприклад, вибирати всі запити та відповіді з кодами 400-і та 500-і для подальшого аналізу. Це дозволяє швидко виявляти дефекти, такі як невірні стилі, скрипти, файли, функції програм і т.д. Все тестування вимагає обґрунтованого підходу, використовуючи методи аналізу та проектування тестів. В іншому випадку існує ризик пропустити значну кількість помилок, а витрати праці під час тестування будуть мінімізовані. Без розуміння стратегій і методів аналізу та проектування тестів практично неможливо забезпечити якісне тестування ПЗ. Загалом, ключові принципи аналізу та проектування тестів є застосовними як для тестування настільних, так і до Web-додатків. Однак важливо уважно враховувати всі особливості тестування Web-додатків. 57 3.2. Створення тестових кейсів для Web-додатку Як зазначено у другому розділі роботи, тест-кейс – це опис того, як працює система, придатний для виконання будь-яким членом команди, будь-то фахівець з тестування, розробник, аналітик або навіть бізнес-підрядник. Тестові приклади готуються фахівцями з тестування, а саме аналітиками тестів або розробниками тестів. В світі існують різні думки щодо потреби виділення тестового аналітика в окрему проектну одиницю. Різниця між функціями аналітика тестів, дизайнера тестів та тестувальника не завжди є очевидною для всіх. І якщо обов’язки тестувальника зрозумілі в цілому, то проектування тестів та аналіз тестів часто виконують ті ж самі люди. Тільки деякі організації чітко розділяють ці ролі. Test Analyst (test designer) – це член тестової команди, головне завдання якого – визначити, що і як потрібно тестувати. Для цього він виконує наступні кроки: 1. Досліджує продукт, вивчаючи весь пакет документації та намагаючись зрозуміти бізнес-цілі продукту та очікування замовника. 2. Створює логічну карту продукту за допомогою “mind map”-техніки (побудова ментальної карти), що дозволяє систематизувати будь-який процес чи подію у візуальній формі. 3. Розбиває програмний продукт на складові, використовуючи процес декомпозиції для створення ієрархічної структури продукту. Глибина декомпозиції визначає легкість розуміння отриманої ієрархічної структури, тому варто дотримуватися балансу між повнотою і простотою опису системи. 4. Описує тестові приклади (test cases) для тестування функціональності, використовуючи методи проектування тестів, такі як класи еквівалентності, граничні значення. 5. Встановлює пріоритети тестування, враховуючи вимоги клієнта, рівень ризику, складність системи та тимчасові обмеження. 6. Координує тестові кейси з бізнес-замовником та системними аналітиками. 58 Розглянемо тестові приклади. Тестові випадки поділяються за очікуваним результатом на: 1. Позитивні тести використовують лише коректні дані і переконуються, що ПЗ правильно виконало функцію, яка викликана. 2. Негативні тести працюють як із коректними, так і з некоректними даними (з використанням принаймні одного неприпустимого параметра). Мета цих тестів полягає в перевірці виняткових ситуацій (де викликаються валідатори) та в переконанні, що функція, викликана додатком, не виконується у випадку спрацьовування валідатора. Кожен тестовий випадок поділяється на три частини: 1. Попередні умови. Це перелік дій, які приводять систему до необхідного стану для виконання основних кроків верифікації. Також це може бути перелік умов, за яких система знаходиться у стані, придатному для виконання основного тесту. 2. Тестові кроки. Перелік дій, які переводять систему з одного стану у інший, з метою отримання результату. Аналізуючи отриманий результат, можна зробити висновок, чи відповідає реалізація вказаним вимогам. 3. Постумови. Перелік дій, які повертають систему до початкового стану перед проведенням тестування. Ця частина не є обов’язковою, але вважається добрим тоном. Вона може бути актуальною для автоматизованого тестування, коли за один автотест можна заповнити БД великою кількістю некоректних документів. Ефективність автоматизованого тестування в гнучкій розробці ПЗ можна значно підвищити, що дозволить скоротити час, необхідний для тестування програмного продукту. Згідно з висловлюванням Стокдейла [28], автоматизація тестових випадків суттєво зменшує час, який витрачається тестувальниками на ручне виконання повторюваних завдань. Автоматизоване тестування робить процеси розробки ПЗ більш гнучкими та ефективними. Серед оптимальних методів автоматизованого тестування для скорочення часу тестування програмного продукту виокремлюють такі: 59 1. Вибір правильних тестових випадків для автоматизації. Слід розглядати тести, які забирають значний час, такі як повторювані тести, тести з обширними наборами даних та тести, які потрібно виконувати в різних Web- браузерах. 2. Час виконання автоматизованого тестування в межах спринту. Автоматизоване тестування повинно відбуватися протягом спринту – від початку до кінця. Це включає виконання тестових випадків до, під час і після спринту. 3. Концентрація на написанні невеликих тестових випадків для тривалого тестування. Розробники тестів повинні акцентувати увагу на створенні невеликих тестових випадків, які фокусуються на конкретних програмних блоках. 4. Створення тестових випадків, незалежних від інтерфейсу користувача. Спрямовані на написання тестових випадків, які не залежать від інтерфейсу користувача і, отже, не впливають на зміни інтерфейсу користувача. SmartBear Software [44] рекомендує використовувати наступні оптимальні методи автоматизованого тестування для гарантії повного тестування програмного продукту: вибір тестових випадків для автоматизації, часте та раннє тестування, вибір відповідного інструменту автоматизованого тестування, створення високоякісних тестових даних й розробка автоматизованих тестів, які не залежать від змін інтерфейса користувача. Шривастава [18] наголошує, що використання автоматизації при тестуванні призводить до значного зменшення часу, а це впливає на прискорення виведення розробленого програмного продукту на ринок. Завдяки автоматизованим тестовим кейсам, які можуть працювати без участі людини, тестування може бути завершено набагато швидше, ніж у випадку ручного тестування. Motwani [20] розглядає, що перед початком автоматизованого тестування важливо переконатися, що ідентифіковано інтерфейс для тестування, визначено 60 область автоматизації та визначено конкретні тестові випадки, які підлягають автоматизації. Baah [19] рекомендує відділяти автоматизацію та процес, що автоматизується. Вибір інструменту для тестування повинен бути обдуманим, забезпечуючи високу зрілість продукту та зменшуючи витрати на технічне обслуговування. Вірний вибір інструментів автоматизації залежить від конкретності програми, яку будуть тестувати. Pollo та ін. [13] пропонують рекомендації щодо автоматизованого тестування, вказуючи, що при виборі інструменту для автоматизації тестування слід враховувати масштабованість проекту. Також вони стверджують, що для кожної тестової діяльності повинні бути чітко визначені умови входу та виходу, а тестові випадки повинні бути максимально конкретними. Важливим є також зрозумілість входів і виходів для кожного тестового випадку. Atlassian [16] рекомендує виконувати автоматичні тести паралельно з іншими процесами. На сучасному етапі розвитку Web-додатків спостерігається їх постійний прогрес, що супроводжується зростанням різноманітності використовуваних технологій та розмаїтістю виявлених дефектів. Важливо усвідомити, що завдання, які ставить перед собою тестування ПЗ для Web-додатків, не мають однозначного рішення та не можуть бути вирішені за допомогою жорсткого алгоритму. Ефективне тестування вимагає урахування нюансів, що властиві Web-додаткам, а також застосування різноманітних методів проектування тестів. 3.3. Розробка узагальненої моделі функціонування системи автоматизованого тестування Web-додатків На рис. 3.3 представлена запропонована узагальнена модель функціонування системи автоматизованого тестування Web-додатків. Розроблена модель функціонування системи автоматизованого тестування Web-додатків складається з основних складових, таких як підсистема інтерфейсу 61 NUnit, підсистеми розробки списку тестів, підсистеми автоматичного виконання тестів, підсистеми підключення драйвера браузера, підсистеми тест-блоків, підсистеми формування звітів, підсистема аналізу результатів тестування та БД тестованого проекту. Програмний продукт Підсистема Підсистема інтерфейсу NUnit автоматичного виконання тестів Підсистема розробки Збереження списку тестів протоколів Підсистема тестування підключення драйвера браузера Збереження тестових наборів Підсистема тест- блоків БД тестованого Підсистема проекту формування звітів Збереження статистики Підсистема аналізу прогонів результатів тестування Рисунок 3.3 – Узагальнена модель функціонування системи автоматизованого тестування Web-додатків Вище зазначені підсистеми оброблюють наступні дані: − тестові набори, достатні для покриття тестованого програмного продукту згідно з визначеним критерієм тестування; − результати прогонів тестових наборів, зафіксовані в Log-файлі. Log- файл містить протоколи, що є реалізованими послідовностями деяких подій 62 (значень окремих змінних або їх сукупностей) і точок реалізації цих подій на керуючому графі програмного продукту. Дані протоколів містять послідовності явно і неявно заданих міток, що задають шлях реалізації протоколу на графі програмного продукту, сукупності значень змінних на цих позначках, величини проміжних результатів, які досягнуті на деяких мітках тощо; − статистику тестових циклів, яка включає: результати проходження кожного тесту з набору тестів та їх порівняння з еталонними величинами; − факти, які слугують підставою для прийняття рішення про продовження або завершення тестування; − критерій покриття та ступінь його задоволення, досягнуті в циклі тестування. Після кожного прогону аналізується список проблем, у вигляді помилок і дефектів, що заносяться до БД тестованого проекту. Відбувається робота над помилками, що включає ідентифікацію проблеми, щоб зрозуміти до якого саме конкретного модуля вона відноситься, визначення розробника, який має забезпечувати гарантію її рішення (виправлення або віднесення до списку вже відомих проблем, рішення яких за тої чи іншої обставини відкладається) в наступних збірках програмного продукту. Виправлена збірка програмного продукту відправляється на наступний цикл тестування, і цикл повторюється доти, поки не буде забезпечено задану якість програмного продукту. В цьому ітераційному процесі засоби автоматизації тестування Web-додатків дозволяють забезпечити швидкий контроль результатів тестування, виправлення помилок та верифікацію рівня якості, досягнутого в програмному продукті. 3.4. Розробка алгоритму проведення автоматизованого тестування Web-додатків На рис. 3.4 наведено запропонований алгоритм проведення автоматизованого тестування Web-додатків. 63 Підсистема Підсистема Користувач автоматичного інтерфейсу NUnit виконання тестів Вибір браузера Обробка запитів для тестування Вибір тестового Формування сценарію звіту Виведення звіту Тестування елементів Підсистема БД тестованого автоматичного проекту виконання тестів Рисунок 3.3 – Алгоритм проведення автоматизованого тестування Web-додатків Поетапний алгоритм проведення автоматизованого тестування Web- додатків складається з таких кроків: 1. Підготовча до тестування Web-додатку. Тестувальник складає тест- план на основі отриманої документації. 2. Функціональне тестування. Тестуються всі функціональні вимоги програмного продукту, робота посилань, пошук неробочих гіперпосилань тощо. Йде перевірка завантаження файлів на сервер, роботи лічильників на Web- сторінках, користувацьких форм, таких як контакти, зворотний зв’язок, підписка, тощо. Перевіряється відповідність вміст сторінок. Це найбільш трудомісткий етап випробування ресурсів. 3. Тестування верстки. При випробуванні жорстко виконується послідовність: − розташування елементів, їх відповідність макету; − оптимізація графічних зображень; 64 − валідація коду; − кросбраузерість. 4. Перевірка зручності використування (Usability Testing). Ґрунтується на залученні в ролі тестувальників користувачів, для аналізу різних результатів та думок. 5. Тестування безпеки. Відбувається перевірка захисту. 6. Перевірка продуктивності. Головним завдання цього етапу є визначення швидкості роботи при заданому навантаженні. Застосовується навантажувальне тестування (Load Testing) та тестування швидкодії. 7. Робота над помилками. Звіт про знайдені дефекти тестувальник надає розробникам. Складається графік виправлення виявлених дефектів та здійснюється повторне тестування. Висновки 1. Визначено особливості функціонального тестування Web-додатків. Проаналізовані вимоги до функціонального тестування ПЗ для подальшої реалізації. 2. Запропоновано тестові випадки для виконання тестування Web- додатків, які дозволили перевірити працездатність нового бізнес-процесу, важливого для підприємства з отримання онлайн-пропозицій для клієнта. 3. Розроблено узагальнену модель функціонування системи автоматизованого тестування Web-додатків, що забезпечує підвищення якості програмного продукту й усунення помилок у коді Web-програми для фронт- офісної системи підприємства. 4. Запропоновано алгоритм проведення автоматизованого тестування корпоративних Web-додатків, що дозволило отримати позитивний економічний ефект, значно скоротивши час та витрати на ручне тестування, а також виключивши вплив людського фактору в процесі тестування. 65 РОЗДІЛ 4. СИСТЕМНИЙ АНАЛІЗ ЗАСОБІВ РОЗРОБКИ СЦЕНАРІЇВ АВТОМАТИЗОВАНОГО ТЕСТУВАННЯ WEB-ДОДАТКІВ 4.1. Автоматизоване тестування Автоматизоване тестування ПЗ – це процес перевірки ПЗ, під час якого основні функції та етапи тесту, такі як запуск, ініціалізація, виконання, аналіз та виведення результатів, виконуються автоматично за допомогою автоматизованих інструментів тестування. Можливе тестування програми на різних рівнях: код (модульне та інтеграційне тестування), API та графічний інтерфейс. Різні види тестів підходять для різних ситуацій. Розглянемо різновиди автоматизованого тестування. Ідентифікатори автоматизованого тестування класифікуються на: 1. Модульне тестування (або unit testing): − тестування чого: перевірка правильності роботи класів та методів; − хто тестує: розробник, який написав код; − мета: виявлення очевидних помилок на етапі написання коду. 2. Teasing-тестування API: − тестування чого: перевірка роботи REST або SOAP-сервісів. − хто тестує: розробники сервісів чи спеціалісти з автоматизації тестування. − мета: виявлення помилок на етапі тестування компонентів. 3. UI Тестування інтерфейсу користувача: − тестування чого: перевірка функціональності графічного інтерфейсу; − хто тестує: спеціалісти з автоматизації тестування; − мета: спростити роботу ручних (функціональних) тестувальників та швидко виявити помилки на етапі приймальних випробувань. Модульні тести перевіряють один модуль коду (як правило, одну функцію або клас у випадку об’єктно-орієнтованого коду) в ізольованому середовищі. Якщо код не використовує сторонні класи, а замість них підставлені класи- 66 заглушки (stubs та mock), код не має працювати з мережею, файлами БД (інакше, тестується не сама функція або клас, а також диск, бази тощо). Stubs – це класи-заглушки, які повертають деякі дані замість виконання дії. Наприклад, екземпляр класу БД може повертати повідомлення про успішне завершення запиту замість фактичного доступу до БД. При спробі читання даних з нього, він повертає заздалегідь підготовлений масив даних. Mock – це класи-заглушки, що використовуються для перевірки виклику конкретної функції. Як правило, модульний тест передає різні вхідні дані функції та перевіряє, чи повертає вона очікуваний результат. Наприклад, якщо в наявна функція для перевірки правильності телефонного номера, їй попередньо надають підготовлені номери та перевіряють, чи розпізнає вона їх правильно. Для функції рішення квадратного рівняння, перевіряється, чи повертає вона правильні значення, використовуючи заздалегідь складений список рівнянь з відповідями. Модульні тести є ефективним методом тестування коду, що містить деяку логіку. Проте якщо код не включає значну логіку і переважно викликає інші класи, то написання модульних тестів може бути викликом. API – це набір функцій, які можна викликати для отримання даних. Наприклад, у сервіса Google.Maps є власне API геокодування. Відправивши запит з географічною адресою, можна отримати координати точки (і навпаки). Також Національний банк України (НБУ) має API, що повертає офіційний курс валюти на певний день. Якщо програма має API, його можна протестувати, відправивши передбачувані запити та порівнявши отримані відповіді з очікуваними. GUI (Graphical User Interface) – це графічний інтерфейс, який користувач бачить на екрані. Це найскладніший тип тестування. При тестуванні роботи Web- сайту, наприклад, потрібно емулювати роботу браузера, що є досить складним, та аналізувати інформацію, яка відображається на сторінці. Однак цей тип тестування важливий, оскільки він взаємодіє з програмою так само, як і користувач. Тести GUI також називаються End-to-End або тестами приймання (acceptance tests). 67 Отже, зробимо проміжний висновок про те, що саме необхідно автоматизувати: 1. Важкодоступні місця у системі (бекенд-процеси, протоколювання файлів, запис до БД). 2. Функціонал, який часто використовується і пов’язаний із високим ризиком помилок. Автоматизація перевірки критичних функцій гарантує швидке виявлення, а отже, дає змогу швидкого виправлення помилок. 3. Рутинні операції, такі як пошук за даними (форми з великою кількістю полів для введення). Автоматизація заповнення полів різними даними та їх перевірка після збереження є ефективним підходом. 4. Повідомлення процесу валідації (автоматизація заповнення полів невірними даними та перевірка валідації). 5. Довгі сценарії End-to-End. 6. Перевірка даних, які потребують складних математичних розрахунків. 7. Перевірка правильності пошуку даних. При тестуванні важливо уникати крайнощів. Наприклад, не обов’язково, що 100 % Web-програми повинно бути покрито автоматизованими тестами. Автоматизовані тести повинні перш за все покращувати якість коду і перевіряти роботу найкритичніших функцій. Їх написання, налагодження та підтримка вимагають значних зусиль. Якщо витрати на це перевищують отримані переваги, автоматизація може виявитися неефективною. Наприклад, при розробці невеликого Web-сайту, який не вимагає подальшої підтримки, може бути простіше провести його ручне тестування, ніж витрачати час на створення автоматичних скриптів. З іншого боку, у випадку, коли велика команда працює над складним Web- додатком, автотести стають необхідні, оскільки інакше більшість часу буде витрачено на ручне (функціональне) тестування та усунення виявлених проблем. На жаль, не всюди розробники використовують автоматизоване тестування для перевірки складного функціоналу. Деякі частини програми залишаються під відповідальністю людей. Необхідно враховувати людський фактор, оскільки 68 люди можуть бути втомленими, лінивими або неуважними, у той час як автоматизована система готова виконувати одну і ту ж послідовність дій щодня. Важливо мати на увазі наступне: 1. Автотести повинні бути повторюваними, і не слід використовувати генератор випадкових чисел, для отримання вхідних даних, оскільки це ускладнює повторення тесту. 2. Автотести мають виконуватись в контрольованому середовищі. 3. Автотест не повинен використовувати той самий алгоритм, що і тестований код (функціонал), оскільки це може призвести до тих самих помилок. У цьому випадку результати тесту та функціоналу будуть ідентичними. 4. Необхідно проводити тестування як позитивних, так і негативних сценаріїв, включаючи перевірку функціонування при введенні неправильних даних. Наприклад, при тестуванні реєстраційної форми важливо перевірити її реакцію як на правильні дані, так і на неправильні дані, включаючи обробку помилок. 5. Під час виконання автотестів необхідно відстежувати виникаючі помилки. Якщо при виникненні помилки тест просто виводить повідомлення про невдачу, а програма продовжує виконувати інші дії, цей тест втрачає свою ефертвність, це марний тест. 6. Автотести мають бути простими у запуску, в кращому випадку за допомогою однієї команди. Якщо для їх запуску потрібно виконати багато дій, це може призвести до втрати інтересу з боку користувачів. Зазвичай компанії налаштовують CI-сервер (Continuous Integration, неперервна інтеграція окремих частин коду додатка між собою), який автоматично отримує оновлення з репозиторію, запускає тести і повідомляє розробникам про виявлені помилки. 4.2. Створення сценаріїв автоматизованого тестування Web-додатків Практичний етап дослідження включає не лише вручну написані тестові сценарії та завдання, але також освоєння основ автоматизованого тестування та 69 використання інструментів, які застосовуються для розробки, налаштування, виконання та аналізу результатів тестових сценаріїв. Для написання автоматизованих тестових сценаріїв існуючого ПЗ використовувалася мова програмування Java. Перед тим як розпочати створення автоматичних скриптів варто ознайомитись із шаблоном PageObject і мовою сценаріїв Gherkin. PageObject – це шаблон проектування, який розділяє логіку високого рівня від логіки низького рівня для знаходження та використання елементів інтерфейсу. Одночасно він покращує читабельність та підтримку коду. Цей шаблон приводить до створення окремого класу, який визначає конкретну сторінку з її Web-елементами, а також методи взаємодії з ними. Структуру цього шаблону проектування показано на рис. 4.1. Рисунок 4.1 – Структура шаблону PageObject Мова Gherkin була розроблена для можливості редагування сценаріїв як наратив, тобто практично на людській мові, в простій, лаконічній формі і доступному форматі. На рис. 4.2 наведено приклад сценарію мовою Gherkin. Виконаємо аналіз засобів, які використовуються для написання тестових скриптів на практиці. Будь-який проект вимагає особливого середовища, і для цього існує інтегроване середовище розробки IDE (Integrated Development Environment). Це 70 набір програмних інструментів, які програмісти використовують для розробки ПЗ та для автоматизації тестування. Рисунок 4.2 – Приклад сценарію мовою Gherkin Середовище розробки включає наступне: 1. Текстовий редактор. 2. Компілятор чи інтерпретатор. 3. Інструменти автоматизації збірки. 4. Відладчик. В наш час існує множина IDE від різних відомих компаній. Аналізуючи досвід колег та особливості мови програмування Java для написання автоматизованих тестів, обрано середовище розробки IntelliJ IDEA. IntelliJ IDEA пропонує широкий спектр інтегрованих інструментів рефакторингу, що дозволяє програмістам та фахівцям з автоматизованого тестування швидко оптимізувати вихідний код програм. Дизайн інтегрованого середовища розробки спрямований на підвищення продуктивності, дозволяючи зосередитися на функціональних задачах, поки IntelliJ IDEA відповідає за рутинні операції. Крім того, середовище ефективно поєднується з численними 71 безкоштовними інструментами розробника, такими як CVS, Subversion, Apache Ant, Maven та JUnit. IntelliJ IDEA доступна у двох версіях: Community Edition та Ultimate Edition. Community Edition – це повністю безкоштовна версія, яка надає підтримку Java SE, Groovy та Scala, а також інтеграцію з популярними системами контролю версій. Ultimate Edition доступна за комерційною ліцензією, розширює підтримку Java EE, UML-діаграм, обчислення покриття коду та інші можливості [27]. Інтерфейс IDEA представлено на рис. 4.3. Рисунок 4.3 – Інтерфейс IntelliJ IDEA з темною темою Окрім IDE, сучасна розробка застосовує системи контролю версій для полегшення роботи зі змінюваною інформацією. Version Control System – ПЗ для полегшення роботи з інформацією, що змінюється. Система контролю версій сприяє збереженню декількох версій одного документа, відновленню попередніх версій та визначенню, хто саме та коли вносив зміни. Ці системи широко використовуються при розробці ПЗ для зберігання вихідних кодів. Також вони можуть застосовуватись у сферах, де обробляється велика кількість змінюваних електронних документів. Наприклад, системи 72 контролю версій використовуються в системах автоматизованого проектування (САПР) як частина систем управління даними продукту PDM (Product Data Management). Керування версіями здійснюється в програмі Configuration, засобами управління конфігурацією виступає ПЗ Tools. Однією з найпопулярніших систем контролю версій є програма Git, що вільно розповсюджується та видається за ліцензією GNU GPLv 2. Ця система спроектована як набір програм для використання в сценаріях. Вона дозволяє створювати спеціалізовані системи контролю версій на основі Git або інтерфейсів користувача. Git підтримує швидке розділення та злиття версій, а також надає інструменти для візуалізації та навігації за нелінійною історією розробки. Кожному розробнику надається локальна копія історії розробки, і зміни копіюються з одного репозиторію до іншого. Віддалений доступ до репозиторію Git забезпечується Git- daemon, SSH- або HTTP-сервером. TCP-сервіс Git-daemon входить до дистрибутиву Git і є поряд з SSH найбільш поширеним та надійним методом доступу. Метод HTTP- доступу, незважаючи на ряд обмежень, дуже популярний у контрольованих мережах, оскільки дозволяє використовувати наявні конфігурації мережевих фільтрів. Приклад візуалізації Git гілок показано на рис. 4.4. Основним місцем зберігання для системи є GitHub, яким користується понад 1,8 млн. підприємств і організацій, зокрема відомі компанії, такі як IBM, Google, PayPal, Facebook, Spotify, Bloomberg та інші представники різних галузей. Для вирішення проблеми повільного завантаження проектів вирішено використовувати фреймворк Apache Maven від Apache Software Foundation для побудови проектів. Цей фреймворк для автоматизації збирання проектів базується на описі структури файлів, використовуючи мовуPOM (Project Object Model),що є підмножиною XML. У випадку створення великих проектів з командного рядка, команда “build” може стати дуже довгою, іноді її включають у скрипт bat або bash. Проте такі скрипти залежать від конкретної платформи. 73 Рисунок 4.4 – Візуалізація злиття версій у основну гілку версій Щоб уникнути цієї залежності і спростити написання скрипта, використовують інструменти для автоматизації збірки проекту. На рис. 4.5 Приклад інтеграції показано приклад інтеграції Maven до IntelliJ IDEA. Рисунок 4.5 – Інтеграція Maven в IntelliJ IDEA Перехід до автоматизованого тестування неможливий без використання бібліотеки JUnit, що є невід’ємною частиною модульного тестування програм. 74 Цей тип тестування дозволяє перевіряти окремі компоненти коду, такі як методи чи класи. Набуття досвіду роботи з JUnit є важливим для формування концепцій тестування ПЗ. JUnit забезпечує швидку перевірку правильності виконання коду у будь- який момент. Якщо програма складна та включає множину класів і методів, її тестування може займати тривалий час. Звісно, цей процес ефективніше автоматизувати. Використання JUnit дозволить ефективно перевірити коректність роботи кожного елемента програми без великих зусиль та витрат часу. Модульні тести для класів і функцій слугують своєрідною документацією щодо очікуваного результату їх виконання. Це не лише документація, але і засіб, який автоматично перевіряє відповідність коду визначеним функціям. Це дуже зручно, тому досить часто тести розробляються як частина процесу перед реалізацією класів. Тестова розробка є надзвичайно популярною технологією створення серйозного ПЗ. Приклад застосування JUnit наведено за допомогою тегу @Test на рис. 4.6. Рисунок 4.6 – Модульний тест методу, який знаходить число Фібоначчі Для тестування Web-додатків та емуляції взаємодії в браузері вибрано популярний інструмент Selenium, зокрема Selenium WebDriver. За призначенням Selenium WebDriver використовується як драйвер браузера, тобто бібліотека ПЗ, яка дозволяє розробляти програми, що управляють поведінкою браузера [26]. Найбільш розповсюдженою областю використання Selenium є автоматизація тестування Web-додатків. Проте, використовуючи Selenium, 75 можна і навіть слід автоматизувати будь-які інші рутинні дії, які виконуються через браузер. Розробка Selenium підтримується виробниками популярних браузерів: Chrome, Opera, Safari, Mozilla та Internet Explorer. Вони адаптують свої браузери для більш глибокої інтеграції з Selenium, іноді вбудовуючи підтримку Selenium безпосередньо у браузер. Selenium є ключовим елементом багатьох інших інструментів автоматизації та фреймворків. Selenium підтримує як настільні, так і мобільні браузери, і надає можливість розробляти сценарії автоматизації практично будь-якою мовою програмування. За допомогою Selenium можна організувати розподілені стенди, що складаються з сотень машин з різними операційними системами та браузерами, а також виконувати скрипти у хмарному середовищі. Приклад використання Selenium WebDriver подано на рис. 4.7. Рисунок 4.7 – Пошук компанії та виведення результатів в консоль Пошук Web-елементів на сторінці здійснюється за допомогою спеціальних пошукових локаторів, які описані у першому розділі роботи. Відшукати ці локатори для конкретних Web-елементів не представляє значних складнощів. Сучасні браузери, такі як Google Chrome і Mozilla Firefox, обладнані вбудованими інструментами, які дозволяють Web-розробникам відстежувати 76 помилки. Ці інструменти відображають HTML, CSS та JavaScript-код сторінки, а також процес взаємодії браузера з цим кодом. На рис. 4.8 наведено приклад роботи вбудованого інструменту розробника у браузері Chrome. Рисунок 4.8 – Вбудовані засоби розробника в Chrome Пошук локатора елементів здійснюється безпосередньо у дереві DOM. Приклад копіювання локатора XPath показано на рис. 4.9. Selenium Server є сервером, який дозволяє управляти браузером на віддаленому ПК. Для цього встановлюється та запускається сервер на машині, де має працювати браузер. Далі на іншій машині запускається програма, яка, використовуючи спеціальний драйвер RemoteWebDriver, підключається до сервера та відправляє йому команди. Сервер, у свою чергу, запускає браузер та виконує ці команди, використовуючи драйвер, що відповідає даному браузеру. Крім Selenium WebDriver, існують й інші інструменти, такі як Selenium Grid та Selenium Server. 77 Рисунок 4.9 – Копіювання елемента XPath element рядка пошуку Схематичне уявлення про те, як працює Selenium Server, наведено на рис. 4.10. Selenium Grid – це кластер, що складається з декількох Selenium Server. Він призначений для організації розподіленої мережі, що дозволяє паралельно запускати багато браузерів на великій кількості машин. Рисунок 4.10 – Схематичне уявлення роботи сервера Selenium 78 Selenium Grid – це кластер, що складається з декількох Selenium Server. Він створений для організації розподіленої мережі, яка дозволяє паралельно запускати багато браузерів на великій кількості машин. Архітектура Selenium Grid має “зіркову” топологію, що означає, що вона складається з окремого сервера, відомого як “концентратор” або “коммутатор”, і інших серверів, відомих як “вузли”. Мережа може бути гетерогенною, що означає, що комутатор і вузли можуть працювати під управлінням різних ОС, мати різні браузери, встановлені на них. Однією з важливих функцій Selenium Grid є вибір відповідного вузла при запуску браузера, враховуючи вимоги до нього, такі як тип браузера, версія, ОС, архітектура процесора та інші атрибути. Раніше Selenium Grid був самостійним продуктом. На сьогоднішній день існує тільки один фізичний продукт – Selenium Server, проте він може працювати в декількох режимах запуску, таких як незалежний сервер, комутатор кластера або вузол кластера, залежно від параметрів запуску. Всі розглянуті підходи та засоби, які можуть бути використані для проведення автоматизованого тестування, ідеально підходять для завдань, поставлених в кваліфікаційній роботі. 4.3. Аналіз результатів випробувань Несправності, виявлені під час тестування, переважно виникають через дефекти та помилки, які існують у програмній системі, яку тестують. Ці несправності можуть бути результатом взаємодії операційного чи тестового середовища. Потрібно детально проаналізувати такі дефекти, визначити, коли і де вперше виникла проблема, які конкретні типи помилок викликали ці несправності та коли їх вперше виявлено. Наприклад, це може бути внаслідок невірно сформульованих вимог, некоректного дизайну, витоку пам’яті тощо. Уся ця інформація використовується для вдосконалення процесу тестування та оцінки важливості таких вдосконалень. Оцінка результатів тестування базується на зборі статистики за конкретними показниками. Вибір метрик проводиться після визначення цілей 79 проекту по відношенню до очікувань від тестування та виявлення основної проблеми проекту в контексті очікувань від тестування та ідентифікації основних проблем проекту на даному етапі. Очікування формуються різними учасниками циклу розробки, такими як керівник проекту, розробники, аналітики та фахівці з підтримки. Наприклад, якщо є скарги на відсутність дефектів, ці скарги слід детально зафіксувати для подальшого аналізу причин відсутності дефектів. Припустимо, після кількох ітерацій стає очевидним, що причина полягає в недостатньому покритті функціоналу тестами. У цьому випадку важливо розпочати зазначати відсоток функціонального покриття тестами. Якщо виявиться, що тестів недостатньо, потрібно розібратися, з яких причин це сталося. Причини можуть бути різноманітними: від неуважності тестувальників до того, що обмежено час на підготовку та тестування, а терміни занадто короткі, і фахівці не встигають створювати необхідну кількість тестів для повного охоплення. Оцінка часових рамок може бути адекватною, але випуск версії для тестування відбувається пізніше запланованої дати, і термін випуску не може бути перенесений. Можливо, що розробники не встигають завершити свої завдання – бюджет на розробку завжди на 2-3 дні коротший, ніж фактичний час реалізації. Також можливо, що менеджер дає розробникам несподівані завдання під час ітерації. Це робиться за бажанням клієнта, який, наприклад, не розрізняє між собою розробку сайту- каталогу та сайту-магазину. Рішення цієї проблеми, звісно ж, не лежить виключно на плечах відділу тестування. Проте для керівника проекту буде набагато простіше пояснити замовнику важливість стабілізації завдань версій, маючи наявні таблиці, статистику та графіки, які відображають вплив несподіваних завдань на якість вихідного продукту. У цьому випадку замовник і менеджер можуть прийти до рішення: чи продовжувати ітеративний розвиток продукту, вибираючи компроміс з замовником, або будь-яка зміна у складі версії повинна супроводжуватися переоцінкою і перенесенням дати випуску. 80 Найважливіше правило для впровадження поліпшень – спочатку сформулювати мету і виявити проблеми в досягненні цієї мети, а потім вирішити, які параметри треба вимірювати для оцінки змін. І, звісно, без єдності всіх членів команди та загального інтересу до успіху проекту, збір метрик залишається марним, оскільки зібрані результати не будуть враховані для подальшого використання. Розглянемо переваги та недоліки автоматизованого тестування порівняно з ручним (функціональним) тестуванням: 1. Швидкість виконання тестових випадків може значно перевищувати людські можливості. Якщо уявити, що для порівняння декількох файлів розміром у кілька десятків мегабайт кожен потрібно використовувати ручні зусилля, то оцінка часу на таку дію стає приголомшливою: місяці або навіть роки. При цьому 36 тестів, впроваджених у рамках Smoke Testing із застосуванням командних скриптів, можуть бути завершені менше, ніж за п’ять секунд і вимагають від фахівця з автоматизованого тестування лише однієї дії – запуску скрипту. 2. Відсутній вплив людського фактору в ході виконання тестових завдань, що забезпечує об’єктивність автоматизованого тестування навіть у випадку втоми, невірності та інших факторів, які можуть впливати на ручний процес. Якщо оцінювати ймовірність того, що людина помилиться при порівнянні двох звичайних текстів по 100 сторінок, кожен ієрогліф за ієрогліфом або якщо таких текстів, наприклад, буде 20, то можна впевнено стверджувати, що людина гарантовано припуститься помилки. Автоматика не робить помилок. 3. Засоби автоматизації здатні виконувати тестові випадки, неможливі для людини через їх складність, швидкість або інші фактори. 4. Системи автоматизації здатні обробляти і представляти величезні обсяги даних у зручній для сприйняття людиною формі. Журнали автоматизованих систем тестування можуть досягати десятків гігабайт на ітерацію. Розуміючи, що людина не може проаналізувати такі обсяги даних вручну, правильно сконфігуроване середовище автоматизації створить точні 81 звіти обсягом 2-3 сторінки, зручні графіки та таблиці, а також дасть змогу проводити детальний аналіз від агрегованих даних до конкретних деталей, якщо це необхідно. 5. Засоби автоматизації можуть виконувати низькорівневі дії з додатком, ОС, каналами передачі тощо. Класичним прикладом є виконання завдання зі збору інформації про ресурси, використовувані програмою. Проте інструменти автоматизації можуть не лише збирати цю інформацію, а і впливати на середовище виконання програми або саму програму, емулюючи типові події, такі як брак оперативної пам’яті або процесорного часу, реєструючи реакцію програми [10]. Отже, використання автоматизації надає можливість розширити охоплення тестуванням за рахунок: 1. Запуску тестових сценаріїв, на які не потрібно витрачати значних зусиль. 2. Багатократне повторення тестових випадків із різними вхідними даними. 3. Заощадження часу для створення нових тестових сценаріїв. Однак впровадження автоматизованого тестування включає в себе також і набір серйозних недоліків та ризиків: 1. Необхідність висококваліфікованих кадрів. Автоматизація вимагає технічно обізнаних фахівців, оскільки це проект з власними вимогами, планами, кодом тощо. Технічний рівень працівників, які займаються автоматизацією, зазвичай повинен бути значно вищим, ніж у тих їх колег, хто займається ручним (функціональним) тестуванням. 2. Часові витрати на розробку та супровід. Не лише розробка автоматизованих тестів, але й створення необхідної інфраструктури вимагає значної кількості часу. В деяких випадках, особливо при серйозних змінах у проекті або помилці в стратегії, може знадобитися перезапуск процесу розробки автоматизації з нуля. 82 3. Необхідність ретельного планування та управління ризиками. Автоматизація потребує вдосконаленого планування і управління ризиками, оскільки в іншому випадку проект може зазнати серйозних ушкоджень. 4. Засоби комерційної автоматизації мають значно вищу вартість, а наявні безкоштовні аналоги поставлені завдання не завжди дозволяють ефективно вирішувати. Тому варто повернутися до питання помилок планування: якщо вибір початкового набору технологій та інструментів автоматизації невірний, то доведеться не лише переробляти всю роботу, а й інвестувати у нові інструменти автоматизації. 5. Наявність великої кількості засобів автоматизації ускладнює вибір конкретного інструменту, а також обтяжує планування та визначення стратегії тестування. Це може призвести до додаткових тимчасових фінансових витрат, а також до необхідності навчання персоналу або залучення відповідних фахівців. Автоматизоване тестування вимагає значних інвестицій і може суттєво підвищити ризики проекту, тому існують спеціальні підходи до оцінки ефективності та застосовності автоматизованого тестування до проекту. Якщо намагатись висловити їх суть досить коротко, то насамперед варто взяти до уваги наступне: 1. Час виконання тестових випадків. Порівняння часу виконання тестів вручну та автоматизовано. Чим більша різниця, тим вигідніша автоматизація. 2. Кількість повторень виконання тестових завдань. Що більше повторень, то більше ресурсів можна зекономити за допомогою засобів автоматизації. 3. Час на оновлення, налагодження та підтримку автоматизованих сценаріїв. Це найскладніший параметр для оцінки, що може становити загрозу успіху автоматизації. Тому до оцінки мають бути залучені досвідчені фахівці. 4. Наявність кваліфікованих фахівців у команді та їх навантаження. Автоматизовані сценарії часто пишуться більш кваліфіковані співробітники, які можуть одночасно вирішувати інші завдання. 83 Слід розуміти, що позитивний ефект від автоматизації не завжди настає миттєво. Автоматизація, як і будь-який коштовний інструмент, може принести відчутну користь при коректному застосуванні, але при некоректному застосуванні принесе лише великі витрати. Оцінка результатів тестування базується на очікуваних результатах роботи системи та аналізі статистики за виявленими помилками. На середовище програмного продукту не повинні впливати блокування та критичні помилки в системі, інакше компанії ризикують втратити клієнтів і прибуток. Доцільність використання автоматизованого тестування оцінюється заздалегідь, оскільки у деяких випадках ефект від функціонального (ручного) тестування може бути вищим. Висновки 1. Визначено сутність автоматизованого тестування та його основні поняття. Описані підходи до створення автоматизованих тестових сценаріїв та розглянуто сучасні інструменти, які використовуються для вирішення практичних завдань тестування. 2. Запропоновано автоматизовані Web-сценарії для виконання тестування Web-додатків, які дозволили перевірити працездатність нового бізнес-процесу, важливого для підприємства з отримання онлайн-пропозицій для клієнта. 84 РОЗДІЛ 5. ДОСЛІДЖЕННЯ ВПРОВАДЖЕННЯ АВТОМАТИЗАЦІЇ ТЕСТУВАННЯ НА ПРИКЛАДІ BOOKING.COM Розглянемо впровадження автоматизації для системи інтернет- бронювання житла Booking.com, яка є прикладною компанією для цього дослідження. Booking.com, заснована в 1996 р. в Амстердамі, виросла з невеликого голландського стартапу в одну з найбільших у світі компаній, що займаються он- лайн бронюванням у сфері подорожей. У Booking.com, що входить до складу Booking Holdings Inc. (NASDAQ: BKNG), працюють понад 17 тис. співробітників у 198 офісах в 70 країнах світу. Зовнішній вигляд головної сторінки Web-сайту системи інтернет- бронювання житла Booking.com представлено на рис. 5.1. Рисунок 5.1 – Зовнішній вигляд головної сторінки Web-сайту системи інтернет-бронювання житла Booking.com 85 5.1. Аналіз попереднього процесу тестування Гнучка методологія розробки ПЗ, зокрема Scrum, використовується командою з двотижневими ітераціями. Перед кожним спринтом власник продукту збирає бізнес-ідеї, які він обговорює з зацікавленими сторонами. Вони також включають повідомлення про помилки та необхідні зміни й додають до резервних елементів продукту. Протягом кожного спринту команда проводить нараду для визначення пріоритетів та розподіляє невиконані завдання. Планування тестування та критерії завершення історій розробляються на початку кожного спринту, після чого розробники і власник продукту їх узгоджують. Після того, як розробник завершує кожне завдання, воно переходить зі статусу “Не розпочато” до “Виконується”, а потім “Виконано”. Розробник перевіряє, що нова функціональність працює правильно й не містить помилок в своєму середовищі. Потім призначений розробник або власник продукту виконує приймальне користувацьке тестування (User Acceptance Testing, UAT) і виявляє будь-які помилки або неправильні вимоги, розгортаючи нову історію в проміжному середовищі, схожому на робоче. На цьому етапі тестувальники перевіряють нову історію та виконують регресійне тестування. Якщо серйозних проблем не виявлено, історія відзначається як успішна і готується до розгортання в робочому середовищі. Вкінці, історія проходить останню перевірку від зацікавлених сторін для оцінки її успішності. Якщо на цьому етапі виявляються проблеми, розробники вносять відповідні зміни до коду і перезапускають процес. Графічне представлення цього алгоритму наведено на рис. 5.2. У кожному спринті розробники призначаються на роль тестувальників після завершення розробки. Зважаючи на обмежені часові межі спринту (два тижні), стає очевидним, що завдання тестування стає складною задачею. Ще однією можливою причиною є відсутність необхідних навичок в команді розробників, що призводить до збільшення часу на розробку та виправлення помилок. 86 Рисунок 5.2 – Алгоритм процесу функціонування конвеєра розробки Для аналізу цієї ситуації з обґрунтованими висновками, необхідно провести докладний SWOT-аналіз. В табл. 5.1 показано сильні сторони, слабкі сторони (внутрішні фактори) та можливості, загрози (зовнішні фактори). Ці чотири сили дають чудове розуміння ситуації та визначають проблемні питання: Таблиця 5.1 − SWOT-аналіз Сильні сторони Слабкі сторони ▪ велика кількість функцій; ▪ короткий спринт; ▪ сильна команда розробників; ▪ складне програмне забезпечення з ▪ практика Agile-метод розробки; величезним UAT; ▪ хороше командне ▪ ручне тестування; співробітництво. ▪ розробники є тестувальниками. Можливості Загрози ▪ швидкий випуск; ▪ виправлені помилки завдають ▪ краща якість; серйозної шкоди після розгортання; ▪ менше регресу; ▪ неефективне тестування. ▪ впевненість у розгортанні. Зокрема, розробники часто не можуть повністю присвятити себе процесу тестування через свою завантаженість, можливо, працюючи над декількома історіями одночасно. Додатково, іноді виникають непередбачені блокувальники, 87 такі як баги, помилки або відмови в роботі живого продукту, і розробники вимушені спочатку вирішувати їх, що призводить до подальшого затягнення робочого часу. По-друге, через відсутність належних практик тестування UAT, які не обслуговуються та застарівають, виникає надмірна складність процесу тестування. По мірі того, як розробка продовжується, і список виявлених помилок росте експоненційно, вся команда змушена призупинити роботу, переглянути та змінити пріоритети залишених завдань. В результаті, час, необхідний для завершення розробки, виходить за межі виділеного часового інтервалу, що суперечить принципам Agile-методології розробки ПЗ. З проведеного аналізу очевидно, що процес тестування потребує покращень. За допомогою належних підходів команда може скоротити час, витрачений на тестування, та підвищити якість продукту. Використовуючи переваги Agile-методології розробки ПЗ та тісної співпраці в команді, можна впровадити автоматизоване тестування для автоматизації процесу UAT, що сприяєтиме прискоренню виявлення та виправлення помилок. Ці покращення не лише зменшать очевидні загрози, які постійно наступають на команду, але й сприятимуть можливості для “меншої регресії − кращого розвитку”. 5.2. Обґрунтування вибору артефакту та інструменту його розробки Звісно існує множина доступних фреймворків та інструментів для автоматизації тестування. Вибір цих інструментів вкрай важливий з точки зору їх придатності для впровадження та ефективності витрат. Вибір інструменту має бути здійснений, враховуючи конкретну ситуацію та ресурси компанії. Для визначення структури автоматизованого тестування необхідно враховувати деякі умови, що залежать від конкретної ситуації та вимог компанії: − інструмент має бути ідеальним вибором для тестування графічного інтерфейсу користувача, оскільки компанія працює з настільною Web- програмою, і ефективне тестування інтерфейсу має велике значення для взаємодії з користувачами; 88 − інструмент повинен підтримувати функціональне тестування, інтерфейс POM для продукту компанії повинен бути реалізованим без зайвих складнощів; − інструмент має підтримувати кросбраузерне тестування; − інструмент повинен бути легко адаптованим без значного завантаження ресурсів, що передбачає незалежну розробку інструменту окремо від командного вихідного коду; − інструмент має бути економічно ефективним, ідеально − це фреймворк з відкритим вихідним кодом; − інструмент повинен мати докладний звіт про випробування з детальною статистикою, що може бути збережений для подальшого використання. На основі цих умов визначено список потенційних автоматизованих тестових інструментів і здійснено їх порівняння в табл. 5.2. За умови ретельної оцінки ситуації в компанії тестовий інструмент Selenium Framework, стане найкращим варіантом для автоматизації тестування. В якості мови програмування обрано Java через її здатність підтримувати дизайн POM та її стабільність. Основною метою набору тестів є заміна поточного функціонального тестування, що проводиться на машині з операційною системою macOS та використовується в компанії. Компоненти, які включаються до набору тестів, визначено такі: − Java Development Kit (JDK) і Java Runtime Environment (JRE); − Інтегроване середовище розробки Eclipse; − Selenium WebDriver - інструмент для автоматизації тестування; − ChromeDriver і браузер Google Chrome: Оскільки Selenium підтримує різні Web-браузери, вибір Chrome як тестового браузера є найкращим варіантом. Розробник може легко завантажити інші Web-драйвери та відповідний браузер для виконання тесту. Важливо зберігати веб-драйвери в тій же папці, що і набір тестів, для уникнення порушень шляхів, пов’язаних із Web-драйвером; 89 − Apache Maven і файл конфігурації pom.xml. Для встановлення “Maven”, необхідно ввести команду “brew install mvn” у терміналі, що дозволить терміналу завантажити та встановити “Maven” на ПК. “Maven” дозволяє автоматично завантажувати всі необхідні бібліотеки для виконання Java-файлів, якщо вони визначені у файлі конфігурації pom.xml. − плагін “Maven Surefire” для генерації звітів про тестування. Таблиця 5.2 – Порівняння автоматизованих тестових інструментів Robot Selenium Appium AutoIT Framework Популярність велика середня середня середня Дизайн POM так ні ні ні Веб-тестування графічного інтерфейсу так так ні ні настільного комп’ютера Кросбраузерне тестування так так ні ні Ресурси низький середній середній високий Ціноутворення безкоштовно безкоштовно безкоштовно безкоштовно Звіти тестів так так так ні Мови, що підтримуються багато багато багато багато Детальні вимоги до набору тестів наведені в табл. 5.3. 90 Таблиця 5.3 − Системні вимоги для запуску набору тестів Ім’я Версія Опис Selenium-Java 4.14.1 Версія Selenium для Java. Java JDK 21.0.1 Середовище Java. Браузер Chrome 118.0.5993.120 Браузер Chrome для створення екземпляра. Драйвер для автоматизації та керування ChromeDriver 76.0.3809.25 браузером. JUnit 4.12 Фреймворк модульного тестування Java. Maven 1.8 Інструмент керування збіркою Java. Плагін Surefire 2.20 Плагін звітів про тестування Maven. Архітектура набору тестів демонструється на рис. 5.3: Рисунок 5.3 – Архітектура набору тестів Бачимо, що дизайн POM добре інтегрований у набір тестів. Для кожної сторінки Web-сайту в наборі тестів є відповідна сторінка .java (рис. 5.4). 91 Рисунок 5.4 – Архітектура сторінок Тестові випадки розділені на різні тестові сценарії на основі функціональності Web-сайту. Для виконання тесту кожен файл має закінчуватися ключовим словом Test(s) (рис. 5.5). Рисунок 5.5 – Архітектура тестів Файл pom.xml і Chrome Drive для Linux поміщаються в одну папку (ціль) разом зі звітами про тестування, які можна знайти пізніше після виконання набору тестів. 5.3. Реалізація набору тестів За умовами конфіденційної політики компанії, вміст набору тестів не може бути включений в дану роботу. Однак, для цілей цього дослідження, нижче наведено приклад простого тесту та його виконання. Тестовий сценарій: Користувач успішно виконує вхід з правильними обліковими даними на Web-сайті Booking.com. 92 Попередні умови: Користувач використовує Web-браузер Chrome. Кроки: − крок 1. Перейдіть на Web-сайт Booking.com; − крок 2. Перейдіть на сторінку для входу (рис. 5.6); − крок 3. Введіть облікові дані користувача; − крок 4: Натисніть кнопку входу. Рисунок 5.6 – Сторінка входу Booking.com Реалізація тестового випадку починається зі створення сторінки “Login”, сторінка входу імпортує всі необхідні бібліотеки, такі як JavaScriptExecutor, WebDriver і WebElement від Selenium (рис. 5.7). Рисунок 5.7 – Необхідні пакети Після цього розробник знаходить локатор інтерфейсу користувача з його ідентифікатором у DOM і передає його до змінних. На практиці рекомендовано перевіряти поточну сторінку кожного разу, коли вона завантажується, перевіряючи відповідність URL-адреси (рис. 5.8). 93 Рисунок 5.8 – Сторінка входу в Selenium Нарешті, реалізована функція. Драйвер знаходить текстове поле імені користувача та пароля за допомогою локатора інтерфейсу користувача та надсилає потрібні облікові дані за допомогою функції “sendKeys” із Selenium. Розробник може перевірити елемент у браузері Chrome, щоб отримати локатор інтерфейсу користувача (рис. 5.9). Рисунок 5.9 – Перевірка елементу в браузері Chrome Потім виконується дія “Натиснути” на кнопці відправки. Функція поверне сторінку інформаційної панелі користувача, який увійшов у систему, якщо ні, система повідомить, що “Це не сторінка входу” як результат тесту (рис. 5.10). 94 Рисунок 5.10 – Результат тесту після дії “Натиснути” У тестовому випадку функція “Перед” вказує, що повинен зробити драйвер перед виконанням будь-яких тестів. Тут драйвер повинен відкрити драйвер, змінити розмір і перейти на домашню сторінку Booking.com. Невиконання цього призведе до помилки під час реалізації (рис. 5.11). Рисунок 5.11 – Тест входу в Selenium Потім створюється тестовий сценарій. У Java обов’язково мати позначення @Test, щоб вказати, що це тестовий сценарій. Кроки чітко визначені назвою функції (goToLoginPage, loginAs). Твердження − це спосіб повідомлення результату. Після натискання кнопки входу в систему, якщо поточна URL- адреса, яку отримує драйвер, містить слово “/dashboard”, assertionTrue є правильним, тобто тест пройдено. Якщо в поточній URL-адресі немає “/dashboard”, assertTrue має значення False, що означає, що тест не вдався (рис. 5.12). Рисунок 5.12 – Тест входу в Selenium. Функція “goToLoginPage” 95 Набір тестів можна виконати за допомогою “Maven” або “JUnit” в залежності від обсягу тесту. Розглянемо один тестовий приклад: потрібно клацнути правою кнопкою миші на тестовому прикладі, обрати “Запустити як” і “Тест Junit” (рис. 5.13). Рисунок 5.13 – Тест “JUnit” Після виконання програма запускає тестовий приклад із повідомленням з консолі (рис. 5.14). Рисунок 5.14 – Тестовий приклад із повідомленням з консолі Створюється новий екземпляр браузера Chrome, і тест виконується відповідно до заданого тестового сценарію. Програма надає інформацію про запуск та активну роботу драйвера через повідомлення “Chrome керується автоматизованим тестовим ПЗ”. Декілька тестових випадків можуть бути об’єднані в один тестовий сценарій. Щоб запустити тестовий сценарій, достатньо клацнути правою кнопкою миші на ньому і вибрати опцію “Запустити як” з подальшим вибором “Junit” для запуску тестового сценарію. Усі тестові випадки виконуються по черзі (рис. 5.15). 96 Рисунок 5.15 – Опція “Запустити як” з подальшим вибором “JUnit” для запуску тестового сценарію Для запуску набору тестів слід перейти до кореневої папки проекту у терміналі та ввести команду “mvn test”. В результаті ця команда виконує набір тестів, компілюючи та запускаючи їх починаючи з першого тестового сценарію. Після цього результати тестування будуть доступні у папці “Target”. Ще одним способом запуску набору тестів є клацання правою кнопкою миші на файлі pom.xml, вибір опції “Запустити як” та вибір “Maven Test” (рис. 5.16). Плагін “Maven Surefire” використовується для створення докладних звітів про тестування HTML та CSS. Після завершення набору тестів потрібно виконати наступні кроки: перейти до командного терміналу та ввести команду “mvn surefire-report:report-only” для створення HTML-звіту. Для додавання стилів CSS до цього звіту використовується команда: “mvn site-DgenerateReports=False”. 97 Рисунок 5.16 – Набір тестів Selenium У результаті звіт про тестування буде доступний за адресою <папка проекту>/target/site/surefire-report.html>. Цей звіт надає інформацію про кількість запущених тестів, виявлені помилки, невдачі та час, який було витрачено на їх виконання (рис. 5.17). Рисунок 5.17 – Протокол випробувань 98 Крім того, у списку пакетів розробник також може спостерігати продуктивність кожного тестового сценарію (рис. 5.18). Рисунок 5.18 – Звіт про випробування Розділ тестового випадку розкриває деталі невдач або помилок. Крім того, під час запуску одного тесту або сценарію без використання “Maven”, результат можна спостерігати з консолі “JUnit” (рис. 5.19). Рисунок 5.19 – Результат в консолі “JUnit” Відстеження помилок допомагає розробнику зрозуміти проблему, клацнувши правою кнопкою миші можна легко перейти до проблемного коду. Система видає повідомлення про помилку та друкує повідомлення, а вже потім усі пов’язані файли. 99 5.4. Визначення ефективності Для оцінки користі від впровадження артефакту необхідно зібрати дані до і після впровадження та порівняти витрати часу в однакових умовах. Результати аналізу визначають, наскільки ефективним є артефакт для компанії. Запропоновані методи збору даних та розрахунку продуктивності. Загалом компанія UAT включає 50 випадків використання. У середньому кожен випадок використання містить 5 тестів, і для виконання одного тесту розробник потребує 5 хвилин. Проте приблизно 20 % випадків використання визначаються як складні і потребують щонайменше 10 тестових випадків для покриття. Крім того, час обслуговування для UAT становить 10 % від часу тестування для кожного раунду, і час розробки становить три робочі дні (24 години). Дані збираються за допомогою приміток на місцях як методу збору даних для максимізації точності зібраних даних, оскільки це дозволяє фіксувати поточну поведінку. В результаті обчислень виявляється, що при виконанні виключно UAT-тестування один розробник повинен витратити (у годинах): Час ручного тестування = (50 * 0,2 * 10 * 5) + (50 * 0,8 * 5 * 5) = 500 + 1000 = 1500 (хвилин) /60 = 25 годин Це означає, що одному розробнику довелося б витратити більше половини повного робочого тижня лише на тестування через наявність двох раундів тестування в різних середовищах, і це необхідно було б робити протягом двох тижнів спринту. Очевидно, що такий обсяг ручного тестування неможливо було б виконати протягом обмеженого часу. В результаті проведеного дослідження зібрані дані про час, необхідний для виконання набору тестів. З 50 варіантів використання було виділено 44 автоматизовані тести, оскільки кожен тест може містити більше одного твердження, що призводить до однакових початкових умов. Час виконання набору тестів в секундах показано нижче на рис. 5.20. 100 Рисунок 5.20 – Звіт про випробування Після проведення перетворення, триває приблизно 40 хвилин (0,67 години), щоб запустити набір тестів та отримати результати. Проте слід також враховувати час, необхідний для розробки та підтримки набора тестів. Введення набору тестів в процес займає два тижні (37,5 робочих годин на тиждень), включаючи час на його обслуговування, який може становити 30 % від часу тестування для кожного раунду. Після врахування вищезазначених витрат часу на виконання функціонального тестування автором роботи було вирішено виокремити одну умову для порівняння між двома сценаріями: враховуючи, що за два місяці розробки (чотири спринти) один розробник повинен виконати повне функціональне тестування чотири рази в кожному спринті. Рівняння 1 визначає метод розрахунку часу, який розробник має витратити на: Загальний час (у годинах) = Час розробки + (час на 1 раунд тестування + час обслуговування) * кількість раундів тестування * кількість спринтів. Результати аналізу даних відповідно до формули показано в табл. 5.4. Таблиця 5.4 − Формула та обчислення Перед артефактом Після артефакту Розбір даних до рівняння 1 3 + (25 + 25*10%) * 4 * 4 37,5*2 + (0,67 + 0,67*30%) * 4* 4 Загальні витрати часу 443 (годин) 126,43 (годин) У результаті артефакт скорочує час = (443 – 126,43) /443 * 100% = 71,46%. 101 У результаті артефакту вдалося скоротити час на 71,46 %, що свідчить про значний вплив набору тестів на результати тестування. Незважаючи на початкові зусилля для впровадження цього набору тестів, пізніше розробник може вільно зосередитися на інших завданнях під час його роботи. Таким чином, безумовно, глибше впровадження розробки та попит на тестування призводять до збільшення користі від цього артефакту. Завершуючи, артефакт визнається ефективним рішенням для компанії-кейсу. Висновки Проведено якісну оцінку впровадження автоматизації тестування на прикладі Booking.com: − проведено аналіз попереднього процесу тестування; − виконано обґрунтування вибору артефакту та інструменту його розробки; − проведено реалізацію набору тестів та здійснено визначення ефективності. 102 ВИСНОВКИ В кваліфікаційній роботі магістра вирішена науково-технічна задача підвищення ефективності засобів автоматизованого тестування Web-додатків за рахунок проведення системного аналізу існуючих методів та програмних засобів тестування корпоративних Web-додатків, спрямованого на вибір сучасних інструментів для автоматизованого тестування таких додатків з урахуванням нових тенденцій, їх порівняння з точки зору ремонтопридатності та використання в системах безперервної інтеграції, розробки узагальненої моделі функціонування системи автоматизованого тестування Web-додатків та розробки алгоритму проведення автоматизованого тестування корпоративних Web-додатків. Використання таких інструментів дозволить забезпечити високорівневий інтерфейс прикладного програмування (API) для використання при тестуванні інтерфейсів користувача Web-додатків, моніторинг відсотку дефектів при його динамічній зміні, підвищити незалежність від тестувальника, отримати позитивний економічний ефект, збільшити швидкість виконання тестів, скоротивши час на виконання однотипних тестових наборів, ручне тестування, а також виключивши вплив людського фактору в процесі тестування. У результаті виконання досліджень отримано наступні наукові і практичні результати: − систематизована інформація про методи та засоби автоматизованого тестування Web-додатків за рахунок проведеного системного аналізу світового досвіду використання, визначені переваги і недоліки їх застосування; − систематизована інформація про існуючих методів та методології функціонального тестування Web-додатків за рахунок проведеного системного аналізу, приведені якісні характеристики існуючих аналогів предмету дослідження; − проведено якісну оцінку засобів автоматизованого тестування Web- додатків за такими параметрами як ремонтопридатність, виконання та 103 використання в системах безперервної інтеграції та надані рекомендації по їх використанню; − розроблено узагальнену модель функціонування системи автоматизованого тестування Web-додатків, що забезпечує підвищення якості програмного продукту й усунення помилок у коді Web-програми для фронт- офісної системи підприємства; − запропоновано алгоритм проведення автоматизованого тестування корпоративних Web-додатків, що дозволило отримати позитивний економічний ефект, значно скоротивши час та витрати на ручне тестування, а також виключивши вплив людського фактору в процесі тестування; − створено тестові випадки та автоматизовані Web-сценарії тестування Web-додатків, які дозволили перевірити працездатність нового бізнес-процесу, важливого для підприємства з отримання онлайн-пропозицій для клієнта; − досліджено впровадження автоматизації тестування на прикладі Booking.com: проведено аналіз попереднього процесу тестування, обґрунтовано вибір артефакту та інструменту його розробки, проведено реалізацію набору тестів та визначено ефективність. В результаті проведеного дослідження встановлено, що функціональне (ручне) тестування вигідніше використовувати при розробці нового бізнес- процесу, а автоматизоване рішення доцільніше використовувати для перевірки існуючого функціоналу. Отримані рішення спрямовані на усунення помилок для забезпечення якості програмного продукту. 104 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 1. Бєлозьорова Д. О. Система автоматизованого тестування Web- додатків : робота на здобуття освітнього ступеня бакалавра; спец.: 123 – комп’ютерна інженерія / Д. О. Бєлозьорова ; наук. керівник С. В. Журавель. Київ: Національний авіаційний університет, 2021. 57 с. 2. Слободян Р. В. Автоматизоване тестування Web-додатків шляхом взаємодії з користувацьким інтерфейсом / Р. В. Слободян. Зб. матеріалів XLVI науково-технічної конференції підрозділів Вінницького національного технічного університету (НТКП ВНТУ–2017) [Електронне мережне наукове видання]. Вінниця : ВНТУ, 2017. C. 1291–1292. 3. Бондар В. О. Актуальні проблеми безпеки веб-додатків / В. О. Бондар // Multidisziplinäre Forschung: Perspektiven, Probleme und Muster der Sammlung wissenschaftlicher Arbeiten «ΛΌГOΣ» zu den Materialien der I Internationalen wissenschaftlich-praktischen Konferenz (B. 1), Wien, 9 April, 2021. Wien-Vinnytsia: List Verlag. in Ullstein Buchverlage GmbH & Europäische Wissenschaftsplattform, 2021. pp. 139–140. doi: 10.36074/logos-09.04.2021.v1 4. Бондаренко О. В. Дослідження інструментів тестування веб додатків : пояснювальна записка до атестаційної роботи здобувача вищої освіти на другому (магістерському) рівні, спец.: 186 – видавництво та поліграфія / О. В. Бондаренко ; М-во освіти і науки України, Харків. нац. ун-т радіоелектроніки. Харків, 2020. 59 с. 5. Бондаренко О. Безпека Web-додатків: актуальні проблеми та їх аналіз / О. Бондаренко, І. Ушкаленко // Формування ринкової економіки в Україні. Львів. 2017. С. 28–36. 6. Євсюков В. В. Методи і засоби тестування Web-додатків : пояснювальна записка до атестаційної роботи здобувача вищої освіти на другому (магістерському) рівні, спец.: 123 – комп’ютерна інженерія / В. В. Євсюков ; М- во освіти і науки України, Харків. нац. ун-т радіоелектроніки. Харків, 2020. 102 с. 105 7. Єгорова О. Програмні засоби для тестування програмного забезпечення / О. Єгорова, В. Бичок // Молодий вчений. 2019. № 11 (75). С. 680– 684. 8. Жирова Т. О. Проблеми тестування інтерфейсу Web-додатків / Т. О. Жирова, Н. О. Котенко // «Молоді вчені 2018 – від теорії до практики» : зб. матеріалів ІХ Міжнародної конференції молодих вчених. Дніпро-Варна : «Дике Поле», 2018. Т. 188. С. 184. 9. Казьміна Д. Р. Модель та методи моніторингу систем керування за допомогою елементів штучного інтелекту : пояснювальна записка до атестаційної роботи здобувача вищої освіти на другому (магістерському) рівні, спец.: 123 – комп’ютерна інженерія / Д. Р. Казьміна ; М-во освіти і науки України, Харків. нац. ун-т радіоелектроніки. Харків, 2020. 73 с. 10. Клушин Ю. С. Підвищення швидкості роботи Web-додатків / Ю. С. Клушин, Ю. Б. Захарчин // Комп’ютерні системи та мережі. 2020. Т. 2. № 1. С. 33–43. 11. Кодола Г. М. Автоматизоване тестування Web-додатків з різнорівневою архітектурою / Г. М. Кодола, Н. С. Волинець, І. В. Сербулова // Вісник Національного технічного університету ХПІ. Серія: Нові рішення в сучасних технологіях. 2019. № 5. С. 91–100. 12. Костромицький В. А. Аналіз підходів до тестування Web-додатку : пояснювальна записка до атестаційної роботи здобувача вищої освіти на другому (магістерському) рівні, спец.: 172 – телекомунікації та радіотехніка / В. А. Костромицький ; М-во освіти і науки України, Харків. нац. ун-т радіоелектроніки. Харків, 2020. 71 с. 13. Лановий О. Ф. Про один підхід до функціонального тестування Web- додатків / О. Ф. Лановий // Полиграфические, мультимедийные и Web- технологии : тез. докл. 2-й Международ. науч.-техн. конф., 16-22 мая 2017 г. Харьков : ХНУРЭ, 2017. Т. 1. С. 135. 14. Ляшко С. Ю. Автоматизоване тестування веб-додатків : робота на здобуття кваліфікаційного ступеня магістра; спец.: 051 – економіка 106 / С. Ю. Ляшко ; наук. керівник К. Г. Гриценко. Суми: Сумський державний університет, 2019. 61 с. 15. Піддубняк П. В. Дослідження систем автоматизованого тестування безпеки Web-додатків : дипломна робота на здобуття кваліфікаційного ступеня магістра; спец. 123 – комп’ютерна інженерія / П. В. Піддубняк ; наук. керівник І. В. Жуковицький ; Укр. держ. ун-т науки і техногогій. Дніпро, 2021. 88 с. 16. Плющ Л. В. Система автоматизованого тестування програмного забезпечення : дипломний проект бакалавра : 6.050201 Системна інженерія / Л. В. Плющ. Київ, 2019. 70 с. 17. Попович Х. Розробка стратегії тестування для Web-додатків / Х. Попович // «Природничі та гуманітарні науки. Актуальні питання» : зб. тез Ⅷ Всеукраїнської студентської науково-технічної конференції. 2015. Т. 1. С. 40. 18. Филиппов В. А. Автоматизация процессов тестирования программного обеспечения мобильных приложений – нерешённые проблемные вопросы / В. А. Филиппов // Science and World. 2013. С. 40. 19. Сучасні технології тестування і захисту веб-сторінок / М. І. Цюцюра, О. В. Криворучко, Т. О. Жирова, Н. О. Котенко // Управління розвитком складних систем. 2019. Вип. 39. С. 100-105. Режим доступу : http://nbuv.gov.ua/UJRN/Urss_2019_39_17 20. Шульга Є. К. Система автоматичного тестування Web-застосунків: клієнтська частина : робота на здобуття ступеня бакалавра за освітньо- професійною програмою “Комп’ютерні системи та мережі” спеціальності 123 “Комп’ютерна інженерія” / Є. К. Шульга ; наук. керівник О. І. Алєнін. Київ : Національний технічний університет України “КПІ імені Ігоря Сікорського”, 2021. 57 с. 21. Kalmo M. Automated Testing of Java Web Applications : Master of Science Thesis in Software Engineering and Technology. Department of Computer Science and Engineering, Chalmers University of Technology University of Gothenburg Göteborg, Sweden, 2009. 50 p. 107 22. Mao K. Sapienz: Multi-Objective Automated Testing for Android Applications / K. Mao, M. Harman, Y. Jia // Proceedings of the 25th International Symposium on Software Testing and Analysis (ISSTA 2016). Association for Computing Machinery, New York, NY, USA, 2016. pp. 94–105. doi: 10.1145/2931037.2931054 23. Qi X. F. et al. Automated Testing of Web Applications using Combinatorial Strategies // Journal of Computer Science and Technology. 2017. Vol. 32. №. 1. pp. 199–210. 24. Selenium with Java : Getting Started to Run Automated Tests [Електронний ресурс]. Режим доступу: https://www.browserstack.com/guide/selenium-with-java- for-automated-test 25. Welcome to Apache Maven [Електронний ресурс]. Режим доступу: https://maven.apache.org/ 26. Zhou Y. Automated Testing of Web Applications for Single Vulnerabilities / Y. Zhou, D. Evans // Proceedings of the 23rd USENIX Security Symposium (USENIX Security 14). 2014. pp. 495–510. 27. Войтенко Д. В., Уткіна Т. Ю. Дослідження методів та засобів автоматизованого тестування Web-додатків [Електронний ресурс] / [упоряд. : Єгорова О. В., Захарова О. В., Кисельов В. Б. та ін.]. Студентська науково- практична конференція ЧДТУ : зб. тез доповідей, 18–20 квітня 2023 р. М-во освіти і науки України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2023. С. 20-21. 28. Войтенко Д. В., Уткіна Т. Ю. Методи та засоби тестування Web- додатків [Електронний ресурс] / [упоряд. : Батраченко О. В., Бєляєва С. С., Захарова О. В. та ін.]. Студентська науково-практична конференція ЧДТУ : зб. тез доповідей, 19–22 квітня 2022 р. М-во освіти і науки України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2022. С. 54-55.