Методи та засоби тестування Web-додатків

Войтенко, Даніїл Володимирович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6516

Full metadata record

DC Field	Value	Language
dc.contributor.advisor	Уткіна, Тетяна Юріївна	-
dc.contributor.author	Войтенко, Даніїл Володимирович	-
dc.date.accessioned	2022-06-23T22:54:08Z	-
dc.date.available	2022-06-23T22:54:08Z	-
dc.date.issued	2022-06	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/6516	-
dc.description.abstract	Метою кваліфікаційної роботи бакалавра є аналіз сучасних методів та засобів тестування Web-додатків, застосування яких дозволить забезпечити підвищення якості програмного продукту й усунення помилок у коді Web-програми для фронт-офісної системи підприємства завдяки створенню наборів тестових випадків та розробці сценаріїв автоматизованого тестування Web-додатків. У результаті роботи були виконані наступні завдання: − проаналізовано предметну область та визначені основні тенеденції розвитку методів та засобів тестування Web-додатків. − визначено сутність Web-додатків та їх особливості, досліджено основи взаємодії клієнтської та серверної частин Web-додатків, структуру Web-сторінок, параметри пошуку Web-елементів; − проведено аналіз сучасних методів та засобів тестування Web-додатків у життєвому циклі розробки ПЗ та визначено їх переваги та недоліки; − визначено сутніть функціонального тестування; − проведено якісну оцінку засобів автоматизованого тестування Web-додатків за такими параметрами як ремонтопридатність, виконання та використання в системах безперервної інтеграції та надані рекомендації по їх використанню; − створені набори тестових випадків для Web-додатків; − розроблено автоматизовані Web-сценарії тестування Web-додатків. Крім того, було встановлено, що функціональне (ручне) тестування вигідніше використовувати при розробці нового бізнес-процесу, а автоматизоване рішення доцільніше використовувати для перевірки існуючого функціоналу. На основі аналізу документації та методологій тестування описано набори тестових кейсів, які дозволили перевірити працездатність нового бізнес-процесу, важливого для підприємства з отримання онлайн-пропозицій для клієнта. Проведено дослідження ефективності автоматизованого тестування Web-додатків. В результаті розроблено автоматизовані сценарії тестування вже існуючого функціоналу, що дозволило отримати позитивний економічний ефект, значно скоротивши час та витрати на ручне тестування, а також виключивши вплив людського фактору в процесі тестування. Отримані рішення спрямовані на усунення помилок для забезпечення якості програмного продукту.	uk_UA
dc.language.iso	uk	uk_UA
dc.title	Методи та засоби тестування Web-додатків	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи)

Files in This Item:

File	Description	Size	Format
Б_123_2022_Войтенко+.pdf Restricted Access		2.45 MB	Adobe PDF	View/Open Request a copy

Show simple item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ
СИСТЕМ
Пояснювальна записка
до кваліфікаційної роботи
освітнього ступеня «бакалавр»
на тему: МЕТОДИ ТА ЗАСОБИ ТЕСТУВАННЯ
WEB-ДОДАТКІВ

Виконав: студент 4 курсу, групи СКС-187
спеціальності 123 – Комп’ютерна
інженерія
Войтенко Д.В.
(прізвище та ініціали)
Керівник Уткіна Т.Ю.
(прізвище та ініціали)
Рецензент
(прізвище та ініціали)

Черкаси 2022 року

ЗМІСТ
СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ................................. 3
ВСТУП ..................................................................................................................... 5
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ................................................................. 8
1.1 Основні тенеденції розвитку методів та засобів тестування Web-додатків 8
1.2 Визначення сутності Web-додатку .............................................................. 11
1.3 Архітектура класичних Web-додатків......................................................... 12
1.4 Фреймворки Web-додатків .......................................................................... 19
2 ОГЛЯД СУЧАСНИХ МЕТОДІВ ТА ЗАСОБІВ ТЕСТУВАННЯ WEB-
ДОДАТКІВ ............................................................................................................ 24
2.1 Методи тестування Web-додатків ............................................................... 24
2.2 Методи проектування тестів ........................................................................ 28
2.3 Градація серйозності та пріоритету помилки ............................................. 30
2.4 Класифікація засобів тестування ................................................................. 31
2.5 Розвиток підходів до тестування програмного забезпечення .................... 32
2.6 Порівняння автоматизованого та ручного підходів у тестуванні
Web-додатків .......................................................................................................... 34
2.7 Методології розробки та тестування програмного забезпечення .............. 38
3 ФУНКЦІОНАЛЬНЕ ТЕСТУВАННЯ ТА СТВОРЕННЯ ТЕСТОВИХ
ЗРАЗКІВ ДЛЯ WEB-ДОДАТКІВ ....................................................................... 47
3.1 Визначення сутності функціонального тестування Web-додатків ............ 47
3.2 Створення тестових кейсів для Web-додатку ............................................. 54
4 РОЗРОБКА СЦЕНАРІЇВ АВТОМАТИЗОВАНОГО ТЕСТУВАННЯ WEB-
ДОДАТКІВ ............................................................................................................ 59
4.1 Автоматизоване тестування ......................................................................... 59
4.2 Створення сценаріїв автоматизованого тестування Web-додатків ........... 63
4.3 Аналіз результатів випробувань .................................................................. 73
ВИСНОВКИ .......................................................................................................... 78
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ........................................................... 80

ЧДТУ.222055.001 ПЗ
Змн. Лист № докум. Підпис Дата
Розроб. Войтенко Літ. Лист Листів
Методи та засоби тестування
Перевір. Утк іна н 2 83
Web-додатків

Н. Контр. Пояснювальна записка ЧДТУ СКС-187
Затверд. Лукашенко

СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
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 – шаблон проектування
архітектури програми, який відділяє модель та її
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 3

уявлення, що необхідно для їх зміни окремо одне
від одного.
PDM – Product Data Management – система управління
даними продукту
QA – Quality Assurance – забезпечення якості.
RFC – Request for Comments – запит коментарів.
WEB – Web – павутина – інтернет-простір.
XML – Extensible Markup Languаge – розширювана мова
розмітки.
ОС – Операційна система.
ПЗ – Програмне забезпечення.
ПК – Персональний комп’ютер.

Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 4

ВСТУП
З метою забезпечення користувачів якісним програмним продуктом та
прискорення виявлення дефектів у системі проводиться тестування [1].
Тестування програмного забезпечення (ПЗ) – це перевірка відповідності
між фактичною та очікуваною поведінкою програми, що виконується на
кінцевому наборі тестів, вибраних певним чином. У більш широкому сенсі
тестування – це один з методів контролю якості, який включає в себе заходи
щодо планування робіт, проектування тестів, виконання тестів та аналізу
отриманих результатів. Розробка програм не може уникнути помилок. Більше
того, вносячи будь-які зміни до складних програмних продуктів, дуже важко
зрозуміти, як це вплине на інші частини системи. Web-додатки є складними
програмними продуктами, адже логіка програми розподілена між клієнтом та
сервером. В свою чергу, компанії несуть величезні фінансові втрати через
неякісні програмні продукти.
Тестування ПЗ є важливою частиною розробки усіх програм. Однак для
корпоративних програм це взагалі неминуче. Оскільки пов’язано з тим, що
розробка корпоративних додатків є дорогою й трудомісткою, але ретельний
вибір вдосконалених методів тестування приводить до здешевлення розробки й
обслуговування [2].
Завдання тестування – дозволити уникнути більшості подібних проблем та
зробити використання продукту максимально комфортним. Для цього перед тим,
як готовий продукт потрапить до користувача, його необхідно перевірити.
Завдання тестування не є таким тривіальним, як здається, і для прискорення
процесу тестування використовується автоматизація.
В даний час все більше додатків, як корпоративних, так і стандартних,
зосереджені на запуску в браузерах, на настільних комп’ютерах і мобільних
пристроях. Це відбувається тому, що Web-додаток легше поширювати.
Найбільша перевага полягає в тому, що немає необхідності створювати окремий
додаток для кожної платформи.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 5

Метою кваліфікаціної роботи бакалавра є дослідження та аналіз
сучасних методів та засобів тестування Web-додатків шляхом визначення
основних тенденцій розвитку методів та засобів тестування Web-додатків та
якісної оцінки відповідних засобів автоматизованого тестування Web-додатків за
такими параметрами як ремонтопридатність, виконання та використання в
системах безперервної інтеграції. Це дозволить забезпечити високорівневий
інтерфейс прикладного програмування API (Application Programming Interface)
для застосування при тестуванні інтерфейсів користувача Web-додатків на
основі компонентів.
Актуальність дослідження. Одним із способів зниження витрат на
розробку та тестування додатків є автоматизоване тестування. Однак нинішня
розробка сценаріїв для автоматизованого тестування інтерфейсу користувача
має багато недоліків. Спосіб, яким пишуться тести, є занадто низьким і тому
багатослівний, а також тісно пов’язаний з конкретними деталями реалізації
додатків. Тому часто невелика зміна в програмі призводить до багатьох змін у
тестах, а отже дає більше можливостей для внесення помилок у тест. Отже,
розробка та підтримка таких тестів коштує доволі дорого.
Тому створення наборів тестових випадків та розробка сценаріїв
автоматизованого тестування Web-додатків для фронт-офісної системи
підприємства з метою забезпечення якості програмного продукту й усунення
помилок у коді Web-програми є завданням актуальним.
Для досягнення поставленої мети необхідно вирішити такі завдання:
1. Визначити основні тенеденції розвитку методів та засобів тестування
Web-додатків.
2. Визначити сутність Web-додатків та їх особливості.
3. Дослідити та провести аналіз сучасних методів та засобів тестування
Web-додатків.
4. Визначити сутніть функціонального тестування.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 6

5. Провести якісну оцінку засобів автоматизованого тестування Web-
додатків за такими параметрами як ремонтопридатність, виконання та
використання в системах безперервної інтеграції.
6. Створити набори тестових випадків для Web-додатків.
7. Розробити автоматизовані Web-сценарії тестування Web-додатків.

Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 7

1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
1.1 Основні тенеденції розвитку методів та засобів тестування Web-
додатків
Штучний інтелект дає можливість ПК самостійно проводити навчання,
спираючись на отриманий під час роботи досвід. Вони самі дотримуються всіх
заданих параметрів, можуть швидко проаналізувати ситуацію та вирішити
поставлене завдання.
Сьогодні інформаційні технології все більше пов’язують свою діяльність
із штучним інтелектом та різними нейронними мережами. Для спрощення
роботи активно застосовують машинне навчання, яке дозволяє штучному
інтелекту навчатися за рахунок використання кількох розв’язків подібних
завдань для отримання результату в основному питанні.
Штучний інтелект та машинне навчання все більше впливає на
тестування ПЗ:
1. Штучний інтелект допомагає командам забезпечення якості
QA (Quality Assurance) вибудовувати тести з нуля практично без людського
контролю. Зокрема штучний інтелект видаляє всі зайві сценарії для прискорення
процесу тестування.
2. Штучний інтелект дає можливість відбудувати нову матрицю
відстеження вимог розширення тестового покриття.
3. На основі поведінки користувачів, машинне навчання допоможе
швидше і більш точно прогнозувати потенційні проблеми та загрози.
4. Зрештою, штучний інтелект допоможе точніше відслідковувати
існуючі проблеми [5].
Таким чином, штучний інтелект спростить роботу команди тестувальників
проекту. Це дозволить доставляти якісний код та забезпечувати покращений
користувальницький досвід.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 8

Основні етапи циклу тестуваня ПЗ з штучним інтелектом
наведено на рис. 1.1.

Рисунок 1.1 – Цикл тестування з штучним інтелектом
Всі ці аспекти дозволяють проводити тестування ПЗ на новому рівні. При
цьому розробники отримують низку переваг.
1. Команди забезпечення якості QA отримують при використанні
методик застосування інструментів штучного інтелекту можливість створювати
різні тести. Перевагою цього є те, що повністю відсутня необхідність у
присутності людини при цьому процесі. Також для виключення уповільнення
процесу тестування штучний інтелект видаляє однакові випадки, щоб не
затягувати тестування.
2. Штучний інтелект може самостійно створити та опрацювати матрицю
для організації відстеження вимог. Це призводить до того, що збільшується
охоплення та область тестування, а також виходить більш розгорнутий
результат.
3. Оскільки машинне навчання дозволяє здійснювати велику обробку
даних, отриманих під час роботи від інших користувачів, штучний інтелект
зможе зробити швидкі та якісні висновки та прогнози. Завдяки цьому можна
виявити та усунути проблему до її втручання у роботу ПЗ.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 9

4. Використовуючи штучний інтелект у сукупності з машинним
навчанням, можна організувати процес більш точного та якісного виявлення
помилок. Також ця методика допоможе відслідковувати різні операції та
процеси, які надалі зможуть стати причиною виникнення порушень.
Усі ці фактори дають змогу командам тестувальників провести
повноцінний аналіз проекту. При цьому досягається найвищий рівень
продуктивності при отриманні якісного та опрацьованого коду. Також істотно
підвищується показник комфорту інтерфейсу користувача.
Завдяки тому, що розвиток штучного інтелекту та машинного навчання йде
вперед досить швидкими темпами, команди інженерів QA отримують більший
простір для дій. Вони можуть займатися проведенням низки експериментів щодо
впровадження нових ідей, а не повністю занурюватися в процес тестування та
управління цією операцією [7].
Фахівці у галузі розробки та аналітики стверджують, що у майбутньому
може статися безпрецедентне збільшення кількості автоматизованих процесів.
Це призведе до того, що команди із тестування не зможуть проводити запуск усіх
операцій. Велика кількість автоматичних тестів може зашкодити швидкості
виконання роботи та уповільнити процес випуску проекту. Тому експерти
приходять до висновку, що необхідно з усіх наявних або змін, що з’являються,
вичленювати тільки ті, які реально сприятимуть прискоренню роботи [25].
Автоматизація не зможе повністю замінити ручну перевірку деяких
елементів. Як правило, це стосується тих опцій, які мають взаємодіяти з
користувачем. Якщо тестувальник спробує зробити автоматизацію процесів, що
мають у собі помилки, це зможе призвести до максимально серйозних і
негативних наслідків.
З цього можна зробити висновок, що 2022 рік буде повністю спрямований
не на масштабну автоматизацію всіх ресурсів, а на раціональний вибір у
використанні ручних і автоматичних процесів.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 10

Таким чином, тренд 2022 року – це не автоматизація тестування, а пошук
балансу між ручними та автоматичними тестами.
1.2 Визначення сутності Web-додатку
Web-додаток – це Web-сайт, що містить сторінки з частково або повністю
неоформленим контентом [9]. Остаточний контент генерується лише після того,
як користувач сайту запросить сторінку з Web-сервера. Пов’язано це з тим, що
загальний зміст сторінки залежить від запиту, створеного на основі дій
користувача.
З цього можна зробити висновок, що Web-додаток передбачає щільну
взаємодію з користувачем, отримання від нього “бізнес-даних”, їхню складну
обробку та зберігання, можливо, навіть без надання результату користувачеві.
Це означає, що користувач може взаємодіяти з матеріалами та функціями:
натискати кнопки, заповнювати форми, запитувати прайс-лист і робити покупки.
До списку Web-додатків входить практично будь-який інтернет-ресурс:
пошукові системи, відеосервіси, соціальні мережі, а також будь-які сайти з
функціями автентифікації користувачів, покупки товарів та послуг, замовлення,
бронювання квитків тощо.
Технічно Web-програма має клієнт-серверну архітектуру. Клієнт – це
браузер, а сервер – це Web-сервер. Комунікація відбувається за допомогою
методів запиту. Найпоширенішими методами запиту є запити GET та POST.
Метод GET, як і метод POST, може використовуватися як для надсилання даних,
так і для отримання інформації з Web-сервера. Метод GET відправляє всю
зібрану інформацію про форму на сервер як частину URL-адреси. Метод POST
передає дані таким чином, що користувач більше не може бачити дані, що
передаються на сервер. Зазвичай метод GET використовується для передачі
текстових та коротких запитів, у той час як метод POST використовується для
передачі великого обсягу даних.
Візуалізація методів показана на рис. 1.2.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 11

Рисунок 1.2 – Візуалізація методів GET та POST
Спочатку Web-додаток складається зі сторінок з частково або повністю
невизначеним вмістом. Остаточний вміст Web-сторінок генерується, коли
конкретний користувач надсилає запит на сервер.
1.3 Архітектура класичних Web-додатків
Web-сторінка складається з трьох частин:
1. Інформація про HTML-версію. Інформація про версію HTML
представлена у вигляді першого рядка вихідного коду Web-сторінки.
2. Заголовок Web-сторінки, що містить технічну інформацію про Web-
сторінку, таку як заголовок, ключові слова та метадані. Це набір елементів, які
не включені до графічного представлення Web-сторінки. Заголовок Web-
сторінки обмежений елементом (тегом) <head>...</head>.
3. Тіло Web-сторінки, яке містить графічне та інформаційне
представлення Web-сторінки.
Тіло Web-сторінки обмежено body елементом (тегом) <body>...</ body>.
Ця структура є стандартною для всіх Web-сторінок [4].
Сторінки, які показані у браузері, можуть бути статичними чи
динамічними. Статична Web-сторінка відображається однаково всім
користувачам. Алгоритм виглядає так:
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 12

1. Користувач вводить запит або адресу сторінки вдо адресного рядка
браузера.
2. Браузер надсилає його на Web-сервер.
3. Запит аналізується на сервері і визначається, що ніяких спеціальних
знаків або інструкцій для користувача немає.
4. Сервер надсилає Web-сторінку до браузера без зміни будь-яких даних
на ній. Наприклад, це матеріал новин, загальна стандартна інформація.
У випадку динамічних сторінок:
1. Користувач вводить запит або адресу сторінки до адресного рядка
браузера.
2. Браузер надіслав запит на Web-сервер з інформацією про те, що цей
користувач має набір атрибутів, які слід використовувати для відображення
певної інформації.
3. Web-сервер пересилає набір функцій на сервер додатків, де
застосовуються правила та інструкції щодо додавання спеціальних змінних.
Наприклад, якщо користувач увійшов до системи, він може побачити сторінку зі
своїм повним ім’ям або іншою відповідною інформацією.
4. Сервер підбирає готову Web-сторінку та відправляє її до браузера, що
показує її користувачеві, який створив запит.
Також потрібно мати на увазі те, що хоча HTML і не вважається
повноцінною мовою програмуваня, але також може бути складною за
структурою, мати великий обсяг блоку кода й модіфікуватися у процесі
виконання. Отже, щоб полегшити розробку та підтримку, в так званих “тегах”
HTML-коду були впроваджені атрибути, за допомогою яких можна
ідентифікувати та з легкістю модифікувати кожний “тег”, який є на Web-
сторінці [6].
Таким чином, мова HTML хоча і була впроваджена близько 30 років тому,
але й досі залишається основним конструкційним блоком у розробці Web-
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 13

сервісів, та будь-який інструмент чи бібліотека тим чи іншим чином
використовують її задля впровадження контенту на Web-сторінку [8].
Дуже важливо відрізняти поняття статичних та динамічних Web-сторінок,
тому що динамічна Web-сторінка надає більше можливостей в якості
функціоналу, модифікацій та мутацій в залежності від бажання користувача.
Динамічна сторінка – це така Web-сторінка, яка згенерована програмно,
найчастіше на етапі виконання програми та взаємодії з користувачем, на відміну
від статичної сторінки, яка є файлом, який знаходиться на сервері. Клієнтська
програма, або сервер, в залежності від типу рендерінгу сторінок, генерує HTML-
код динамічної сторінки для обробки браузером.
Статичний сайт – сайт, що складається зі статичних HTML-сторінок, що
становлять єдине ціле. Містить в собі текст, зображення, нерідко мультимедіа
вміст (аудіо, відео) і HTML-теги. Зазвичай статичний Web-сайт – це набір файлів
HTML, розміщених на Web-сервері [15].
Генерація вмісту на стороні клієнта. Після того, як сторінка отримана
клієнтом з сервера, програма-браузер обробляє її тай відображає користувачеві,
при цьому виконуючи скрипти клієнтської блоку, якщо вони були вказані в
сторінці й отримані. На клієнтській стороні використовується JavaScript, який
може використовуватися як для мінімальних операцій (наприклад, валідації
завдання паролів при реєстрації на сайтах), так і глобальних послідовностей і
додатків.
Але у зв’язку з реальним станом речей – пришвидення процесів розробки
Web-сайтів, покращення призначених для користувача інтерфейсів та
прискорення роботи самих Web-сайтів – на даний час у світі розробки Web-
сайтів та додатків використовується так званий метод “комбінованої генерації”,
який заснований на комбінації обох методів рендерінгу у зв’’язку з потребою
регулярно або з особливої періодичністю отримувати дані з сервера протягом
рендерінгу на боці клієнтської програми та браузера.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 14

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

Рисунок 1.3 – Приклад роботи статичних та динамічних Web-сторінок
Технічно можна динамічно оновлювати контент або окремі блоки на
сторінці без перезавантаження сторінки. З цією метою використовуються AJAX
та jQuery.
AJAX – це інструмент для створення Web-програм, які взаємодіють із
сервером у фоновому режимі. При цьому користувач отримує програму з
динамічним оновленням контенту, без перезавантаження всієї сторінки [12].
jQuery – це фреймворк JavaScript та бібліотека, яка спрощує використання
деяких функцій JavaScript, таких як створення візуальних ефектів, обробка подій,
робота з DOM та підтримка AJAX [3].
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 15

Основний принцип динамічного оновлення блоку на сторінці полягає в
наступному:
1. Створює функцію та об’єкт для браузерів. Цей об’єкт використовується
для передачі даних на сервер та отримання відповіді від нього у фоновому
режимі, без перезавантаження сторінки.
2. У тілі документа створюються два контейнери. Перший контейнер
завантажує контент безпосередньо, а другий контейнер містить контент, який
служить заставкою і з’являється під час завантаження основного необхідного
контенту.
3. Створюється додаткова функція, яка виводить вміст першого
контейнера. Функція робить це за допомогою раніше створеного об’єкта. Для
опису передачі на сервер використовується певний метод. Параметри включають
тип запиту (наприклад, GET) і рядок, що передається серверу (URL
завантажуваної сторінки).
4. Щоб отримати весь вміст, потрібно дочекатися його. Як тільки це
відбудеться, тіло контейнера відразу ж зміниться.
5. Після відкриття запиту, запит надсилається на сервер.
Основним інструментом роботи з динамічними змінами на Web-сторінці є
об’єктна модель документа DOM (Document Object Model). Він
використовується для XML/HTML-документів.
Відповідно до моделі DOM, документ – це ієрархія, дерево. Кожен HTML
тег утворює вузол дерева, типом якого є елемент. Вкладені теги стають дочірніми
вузлами. Для представлення текстової інформації створюються вузли із
типом text.
Усього існує 12 типів вузлів, але на практиці вони працюють із 4 з них:
1. Документ – це точка входу в DOM.
2. Елементи – основні будівельні блоки.
3. Текстові вузли містять фактичний текст.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 16

4. Коментарі дозволяють включити інформацію, яка не
відображатиметься, але доступна з JavaScript.
Всього DOM являє собою подання документа у вигляді дерева об’єктів, яке
можна редагувати за допомогою JavaScript. DOM необхідний для керування
сторінкою, наприклад, для читання інформації з HTML, зміна та створення
елементів. Ілюстрація з DOM дерева DOM показано на рис. 1.4.

Рисунок 1.4 – Структура дерева HTML DOM
Як правило, в реальних завданнях потрібно маніпулювати наборами
елементів (або одним), знаходячи їх імена десь глибоко у дереві БД, і, часто, ці
елементи розкидані по різних його частинах. Наприклад, потрібно відзначити
список файлів для видалення на Web-сторінці та виконати цю дію. У такій
ситуації ручний прохід по дереву буде дуже стомлюючим. Тому в цьому випадку
пошук елемента в дереві специфікації може бути виконаний за допомогою
спеціалізованих методів пошуку.
1. За ідентифікатором елемента By.id. Якщо ідентифікатору елемента
присвоєно спеціальний атрибут id, можна отримати його безпосередньо за
допомогою змінної з ім’ям значення id. Відповідно до стандарту, значення id має
бути унікальним, що означає, що документ може мати лише один елемент з цим
ідентифікатором. І його буде повернено. Якщо документ містить кілька
елементів з унікальним ідентифікатором, поведінка буде невизначеною. В цьому
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 17

випадку браузер повертає елемент випадковим чином. Тому при розробці Web-
додатків намагаються дотримуватися правила унікальності ідентифікатора.
2. На ім’я тега елемента By.tagName. Цей метод дозволяє отримати всі
елементи з певним тегом та виконати пошук у тому числі потрібного. Регістр
тега не має значення.
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. Актуальність даних у додатку. Не можна залишити без уваги цей
критерій, бо, на першу думку, наявність неактуальних або невірних даних може
бути наслідком помилкової операції, спричиненої одним з попередніх пунктів, а
у деяких випадках – одразу всіма.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 18

Але дуже часто виникають ситуації, коли бізнес-логіка працює ідеально,
користувацький інтерфейс працює вірно та протестований багато разів, протягом
виконання одного з ланцюгів усі дані були вірними, але результуючі дані
виявилися пошкодженими, або на деяких етапах виконання програми
з’являються неактуальні, або помилкові дані. Можна перераховувати
нескінченний список причин, за якими могла виникнути така ситуація, в тому
числі заповнення бази даних некоректними даними, помилка в програмному коді
стороннього сервісу, втрата з’єднання мережі та інші технічні неполадки. Але
щоб виправити несправність – спочатку її треба виявити та діагностувати, адже
невиявлена несправність, так само як і в попередніх пунктах, може призвести до
подальшої передачі неактуальних або невірних даних. Це ж у більшості випадків
призведе до завдання шкоди бізнесу чи до введення в оману користувача, що
спричинить відторгнення й негативний відгук самого користувача.
1.4 Фреймворки Web-додатків
Сьогодні більшість Web-додатків засновані на деякому фреймворку.
Фреймворки – це програмні продукти, що спрощують створення та супровід
технічно складних або завантажених проектів. Фреймворк, як правило, містить
лише базові програмні модулі, а всі інші компоненти проекту реалізуються
розробником на їх основі. В результаті досягається висока швидкість розробки
ПЗ, висока продуктивність та надійність рішень. Фреймворки також можна
використовувати для створення різних Web-сайтів, бізнес-додатків та Web-
сервісів [9].
У сфері програмування немає чіткого визначення, яким критеріям має
відповідати ПЗ, щоб достовірно вважатися фреймворком. Іноді фреймворки
плутають із бібліотеками [14].
Бібліотека, як правило, складається з попередньо написаного коду, класів,
процедур, скриптів, конфігурацій тощо. В основному бібліотеку можна легко
інтегрувати до існуючого проекту для скорочення часу розробки. Це пов’язано з
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 19

тим, що багато питань, що стосуються основних алгоритмів та функцій, вже було
вирішено іншими досвідченими програмістами. Бібліотека заощаджує час для
розробників, що дозволяє зосередитися на проблемах, пов’язаних з логікою. Але
використання сторонньої бібліотеки також може становити потенційний ризик
для програми [15].
Порівняно з бібліотеками, фреймворки пропонують повний стек корисних
функцій й беруть відповідальність за архітектурні рішення у процесі розробки.
Фреймворки можуть включати стратегії для маршрутизації URL-адрес у
додатку, управління станом, об’єднання та ін. Крім того, фреймворки
забезпечують покращення робочого процесу, які включають передові практики
для основних аспектів розробки, таких як загальна структура програми або
створення шаблонів [14].
Фреймворк відрізняється від бібліотеки тим, що бібліотека може
використовуватися у програмному продукті як сукупність підсистем подібної
функціональності, не впливаючи на архітектуру основного програмного
продукту та не накладаючи на нього жодних обмежень. Фреймворк задає
базовий дизайн архітектури програми, який необхідно буде розширити та
модифікувати відповідно до заданих вимог, формуючи стандартну поведінку на
початковому етапі розробки. Крім того, фреймворк може містити допоміжні
програми, різноманітні бібліотеки, скриптову мову та інше ПЗ, що допомагає
полегшити розробку та інтеграцію різноманітних компонентів програмного
проекту. Основною перевагою при використанні фреймворків є стандартизована
структура організації компонентів додатку. Створити таку структуру при
розробці на фреймворках досить просто. По суті, фреймворк – це набір
конкретних і абстрактних класів, а також опис того, як вони між собою
взаємодіють. Конкретні класи, як правило, реалізують взаємні відносини, у той
час як абстрактні класи є розширеннями, в яких фреймворки можуть бути
адаптовані або використані.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 20

Методи об’єктно-орієнтованого програмування використовуються для
надання розширених функцій (наприклад, частини програми можуть бути
успадковані від базових класів фреймворку).
Виділемо деякі переваги розробки Web-додатків з використанням
фреймворків:
1. Розробка на фреймворку, на відміну так званих “самописних” рішень,
дозволяє домогтися простоти ремонтоздатності проекту.
2. Відносно легко реалізувати будь-які бізнес-процеси, а не тільки ті, що
відпочатку вбудовані в систему. Проекти, засновані на фреймворках, можна
легко масштабувати та модернізувати.
3. Системи, реалізовані з використанням фреймворків, часто працюють
швидше й можуть витримувати вище навантаження у порівнянні з
“самописними” системами. Саме тому багато популярних Web-додатків
засновані на фреймворках. З погляду безпеки ці рішення також значно
перевершують “самописні” системи [22].
Більшість фреймворків Web-додатків реалізують шаблон проектування
MVC (Model – View – Controller). Модель Model надає дані та реагує на команди
контролера зміною свого стану. View – відповідає за відображення даних моделі
користувача, реагуючи на зміни моделі. Controller інтерпретує дії користувача,
повідомляючи модель про необхідність змін. Схема шаблону MVC
представлена на рис. 1.5.

Рисунок 1.5 – Схема шаблону MVC
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 21

Однак можна використовувати інші шаблони, такі як MVP (Model – View –
Presenter) або MVVM (Model – View – ViewModel). Це похідні шаблони з MVC.
Елемент Presenter у шаблоні Model – View – Presenter бере на себе
посередницьку функціональність (аналогічно Controller в MVC) і відповідає за
управління подіями інтерфейсу користувача (наприклад, за допомогою миші) так
само, як і у інших шаблонах, View зазвичай реагує. Схему шаблона MVP
показано на рис. 1.6.

Рисунок 1.6 – Діаграма шаблону MVP
ViewModel у шаблоні Model – View – ViewModel є, з одного боку,
абстракцією View, а з іншого – надає оболонку для даних, що прив’язуються з
Model. Іншими словами, він містить Model, який перетворюється на View, а
також інструкції, які View може використовувати для впливу на Model. Схему
шаблона MVVM показано на рис. 1.7.

Рисунок 1.7 – Схема шаблону MVVM
У шаблонах проектування MVC/MVP зміни в інтерфейсі користувача
безпосередньо не впливають на користувальницький досвід на Model, а потім
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 22

йдуть через Presenter або Controller. У деяких технологіях, таких як Silverlight
існує поняття “прив’язка даних”, яке дозволяє пов’язувати дані з візуальними
елементами в обох напрямках. Тому використання моделі MVC стає незручним,
оскільки прив’язка даних безпосередньо до подання не вписується в
концепцію MVC/MVP.
Проаналізовано сутність Web-програми та визначено основні поняття. В
результаті розглянуто основи взаємодії клієнтської та серверної частин Web-
додатків, структури Web-сторінок, параметри пошуку Web-елементів та
фреймворки для сучасних Web-додатків.
Виділено деякі переваги розробки Web-додатків з використанням
фреймворків, а саме:
1. Розробка на фреймворку, на відміну так званих “самописних” рішень,
дозволяє домогтися простоти ремонтопридатності проекту.
2. Відносно легко реалізувати будь-які бізнес-процеси, а не тільки ті, що
спочатку були вбудовані в систему. Проекти, засновані на фреймворках, можна
легко масштабувати та модернізувати.
3. Системи, реалізовані з використанням фреймворків, часто працюють
швидше і можуть витримувати вище навантаження у порівнянні з
“самописними” системами. Саме тому багато популярних Web-додатків
засновані на фреймворках. З погляду безпеки ці рішення також значно
перевершують “самописні” системи.

Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 23

2 ОГЛЯД СУЧАСНИХ МЕТОДІВ ТА ЗАСОБІВ ТЕСТУВАННЯ
WEB-ДОДАТКІВ
2.1 Методи тестування Web-додатків
Тестування ПЗ (Testing Testing) – перевірка відповідності між реальною та
очікуваною поведінкою програми, що виконується на кінцевій множині тестів,
вибраних певним чином. У більш широкому сенсі тестування – це один з
методів контролю якості, який включає в себе заходи щодо планування робіт,
розробки тестів, виконання тестів та аналізу отриманих результатів. Розглянемо
види тестування ПЗ [15].
Усі види тестування ПЗ, залежно від переслідуваних цілей, можна
розділити на такі групи:
1. Функціональні.
2. Нефункціональні.
3. Пов’язані зі змінами.
Розглянемо кожен окремий вид тестування, його призначення та
використання у тестуванні ПЗ.
Функціональні тести засновані на функціях та взаємодіях з іншими
системами. Тести також можуть бути представлені на всіх рівнях тестування:
компонентному або модульному, інтеграційному, системному та приймально-
здавальному. Функціональні види тестування враховують зовнішню поведінку
системи.
Розглянемо деякі з найпоширеніших типів функціональних тестів:
1. Тестування взаємодії.
2. Тестування безпеки.
3. Функціональне випробування.
Нефункціональні тести, необхідні визначення характеристик ПЗ, які
можна виміряти різними способами. Взагалі кажучи, дисфункція тестування – це
тестування того, як працює система.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 24

Основні види дисфункційних тестів:
1. Тестування продуктивності:
− навантажувальні випробування;
− стрес-тестування;
− тестування стабільності чи надійності;
− велике тестування.
2. Тестування установки.
3. Юзабіліті-тестування.
4. Тестування на відмову та відновлення.
5. Тестування конфігурації.
Після внесення необхідних змін, таких як усунення дефекту, ПЗ має бути
повторно протестовано, щоб підтвердити, що проблема справді вирішена. Після
встановлення ПЗ слід виконати такі види тестування, щоб підтвердити, що
програма працює правильно або що дефект був виправлений правильно:
1. Димові випробування.
2. Регресійне тестування.
3. Тестування збирання.
4. Санітарні випробування (перевірка відповідності).
Тепер розглянемо основні поняття та прийоми тестування Web-додатків.
Верифікація – це оцінка системи або її компонентів з метою визначення
результатів поточного етапу розвитку умов, які були сформовані на початку
цього етапу. Наприклад, чи виконуються цілі, чи дотримуються крайні терміни
чи завдання розробки проекту, визначені на початку поточного етапу [19].
Валідація – це визначення відповідності розробленого ПЗ очікуванням та
потребам бізнес-замовника, системним вимогам.
План випробувань – це документ, що описує весь обсяг робіт з
випробувань, починаючи з опису об’єкта, стратегії, графіка, критеріїв початку та
закінчення випробувань, закінчуючи обладнанням, необхідним у процесі
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 25

експлуатації, спеціальними знаннями та оцінкою ризиків з варіантами їх
вирішення.
Хороший план тестування повинен включати відповіді на такі питання:
1. Що я маю перевірити?
Відповідь на це питання має містити опис тестового об’єкта: додатки,
системи та апаратного забезпечення.
2. Що саме я маю перевірити?
Відповідь на це питання має містити опис тестованої системи та її
компонентів окремо, і навіть перелік функцій.
3. Як я маю це перевірити?
Відповідь на це питання має описувати стратегію тестування, наприклад,
види тестування та його застосування до тестового об’єкту.
4. Коли потрібно провести тест?
Відповідь на це питання має містити послідовність виконуваних робіт:
підготовка до тестування, безпосереднє тестування та аналіз результатів по
запланованим етапам розробки.
5. Які критерії потрібні для початку тестування?
− наявність випробувального стенду;
− завершення етапу розроблення необхідного функціоналу;
− повна документація.
6. Які критерії потрібні для проходження тесту?
Відповідь на це питання має містити результати випробувань, відповідні
критеріям якості продукції:
− вимоги до кількості відкритих дефектів дотримані;
− витримка певного часу без зміни вихідного коду програми;
− витримка певного проміжку часу, не без знаходження нових
помилок.
Відповівши на ці запитання у своєму плані тестування, можна впевнитись,
що в наявності чудовий проект документу планування тестування. Для того, щоб
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 26

проект перетворився на серйозний документ, потрібно додати до нього такі
пункти:
1. Середовище системи, що тестується (опис програмно-апаратних
засобів).
2. Обладнання та ПЗ, необхідні для проведення випробувань
(випробувальний стенд та його конфігурація, програми для автоматизованого
тестування та ін.);
3. Ризики та шляхи їх усунення.
Розглянемо поняття тестового прикладу. Тестовий приклад – це документ,
що описує набір кроків, конкретних умов та параметрів, необхідних для
тестування реалізації тестованої функції або її частини. Тестовий приклад
визначається як структура виду:
Деталізація тестових випадків – це рівень опису етапів тестування та
необхідного результату, що забезпечує розумне співвідношення часу
проходження та тестового покриття.
Час завершення тестового завдання – це період часу від початку тестового
завдання до отримання результату тесту.
Крім тестових випадків у тестуванні існує поняття контрольного списку.
Контрольний список – документ, який описує, що має бути перевірено
безпосередньо. На відміну від тестового прикладу контрольний список має
низький рівень деталізації. Найчастіше контрольні списки застосовуються при
тестуванні функціональності з допомогою гнучких методологій [1].
Для забезпечення оптимального тестового покриття функціональності
використовуються різні методи та стратегії проектування тестів. Під
визначенням тестового покриття розуміється нова метрика оцінки якості
тестування, що є щільністю тестового покриття вимог або виконуваного коду.
Тестовий дизайн – це етап процесу тестування ПЗ, на якому розробляються і
створюються тестові кейси (тестові випадки) відповідно до раніше визначених
критеріїв якості та цілей тестування.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 27

Більшість тестують та пишуть тестові приклади та контрольні списки, але
не всі використовують спеціальні методи проектування тестів. Поступово,
набираючись досвіду, приходить розуміння, що виконується та сама робота, яка
підпорядковується певним правилам. І тоді виявляється, що ці правила вже
описані.
2.2 Методи проектування тестів
Найбільш поширеними методами проектування тестів є:
1. Еквівалентний поділ. Це метод, який ділить функціонал (часто діапазон
можливих вхідних значень) на групи, еквівалентні за своїм впливом на систему
значень. Такий поділ допомагає перевірити правильність функціонування всієї
системи – одного класу еквівалентності, перевіривши лише один елемент цієї
групи. Цей метод полягає у поділі всього набору тестів на класи еквівалентності,
а потім зменшенні кількості тестів. Наприклад, існує діапазон допустимих
значень від 1 до 10. Необхідно вибрати одне допустиме значення в діапазоні
від 2 до 8 і одне неприпустиме значення за межами діапазону – від -1
до негативного значення, дозволеного типом даних, або від 12 до позитивного
значення, дозволеного типом даних.
2. Аналіз граничних значень. Це метод перевірки помилок меж класів
еквівалентності. Якщо методика аналізу класів еквівалентності орієнтована на
тестове покриття, то ця методика заснована на ризиках та ідеї про те, що
програма може зламатися в області граничних значень. Помічено, що у процесі
розробки виникає велика кількість проблем на межі вхідних змінних. Навіть
якщо еквівалентні класи знайдені правильно, граничні значення можуть бути
помилково призначені іншому класу. Можна вибрати мінімальну та
максимальну межі (1 і 10) для позитивного тестування, а також значення більше
і менше меж (0 та 11). Аналіз граничних значень може бути застосований до
полів, записів, файлів або будь-якого іншого об’єкта, що має обмеження на них.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 28

Графічний приклад класів еквівалентності та граничних значень
наведено на рис. 2.1.

Рисунок 2.1 – Візуалізація класів еквівалентності та граничних значень
3. Причина/наслідок. Зазвичай це введення комбінацій умов (причин) для
відповіді від системи (наслідків). Наприклад, перевіряється, чи можна додати
клієнта за допомогою певної екранної форми. Для цього потрібно ввести кілька
полів, таких як “Ім’я”, “Адреса”, “Номер телефону”, а потім натиснути кнопку
“Додати” – це “Причина”.
Після натискання кнопки “Додати” система додає клієнта в базу даних і
показує на екрані його номер – це і є “Наслідок”.
4. Predicting errors. Це коли тестовий аналітик використовує свої знання
про систему та свою здатність інтерпретувати специфікацію, щоб “передбачити”,
за яких вхідних умов система може видати помилку. Наприклад, у специфікації
говориться: “користувач повинен ввести код”. Тестовий аналітик подумає: “А
що, якщо я не введу код?”, “А що якщо я введу неправильний код?”, і т.д. Це
передбачення помилки.
5. Вичерпне тестування – це крайній випадок. У рамках цієї техніки
треба перевірити всі можливі комбінації вхідних значень, і в принципі це має
знайти всі проблеми. На практиці використання цього методу неможливе через
велику кількість вхідних значень.
Якщо помилка виявлена в системі під час тестування або експлуатації, то
перед її виправленням видається опис цієї помилки у відповідній системі
відстеження помилок або системі управління проектом.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 29

Звіт про помилку – це документ, що описує ситуацію або послідовність дій,
що призвели до неправильної роботи об’єкта, із зазначенням причин та
очікуваного результату. Прочитавши короткий опис помилки, розробник має
зрозуміти, у чому проблема. При читанні докладного опису дефекту, потрібно
знати фактичний рядок коду для редагування. Правильно оформлений звіт про
помилку заощаджує час розробника. Помилка повинна мати свій рівень
серйозності або пріоритет.
2.3 Градація серйозності та пріоритету помилки
Розглянемо градацію серйозності та пріоритету помилки:
1. Функція блокування (Blocker) – помилка блокування, що призводить до
збою програми, унеможливлюючи подальшу роботу з тестованою системою або
її ключовими функціями. Вирішення поставленої задачі необхідне для
подальшого функціонування системи. Цей дефект має найвищий пріоритет.
2. Критична (Critical). Критична помилка, ключова бізнес-логіка, яка не
працює належним чином, вразливість безпеки або проблема, яка тимчасово
виводить з ладу сервер або виводить з ладу деяку частину системи, не маючи
можливості вирішити проблему за допомогою інших вхідних точок. Вирішення
поставленого завдання необхідне для подальшої роботи з ключовими функціями
тестованої системи. Цей дефект має найвищий пріоритет.
3. Суттєва (Major). Істотна помилка. Деякі з основних бізнес-логік
працюють неправильно. Помилка не критична, або можна працювати з
функцією, що тестується, використовуючи інші вхідні точки. Пріоритет цього
дефекту є середнім [3].
4. Незначна (Minor). Помилка, що не порушує бізнес-логіку тестованого
додатка, очевидна проблема з користувацьким інтерфейсом. Цей недолік має
низький пріоритет.
5. Тривіальна (Trivial). Тривіальна помилка, що не впливає на бізнес-
логіку програми, погано відтворювана проблема, ледь помітна через інтерфейс
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 30

користувача, проблема зі сторонніми бібліотеками або сервісами або проблема,
що не впливає на загальну якість продукту. Цей недолік має низький пріоритет.
Правильне розміщення серйозності та пріоритету помилки дозволяє, в
першу чергу, усунути найкритичніші системні дефекти, оскільки вони можуть
повністю заблокувати роботу користувачів системи.
Отже, компанії, що не використовують цю систему, можуть зазнати
великих фінансових втрат через неякісний програмний продукт.
2.4 Класифікація засобів тестування
Ще зовсім недавно тестування програм проводилося вручну або самими
програмістами, або користувачами, що навряд чи можна було назвати системним
підходом і ще не дозволяло оцінювати якість коду. Трохи пізніше тестування
виділилося в окрему галузь знань у складі розробки ПЗ, але швидко прийшло
розуміння того, що тестування вручну неефективне, оскільки потребує великих
трудових ресурсів та багато часу. Перші засоби автоматизації тестування
практично являли собою бібліотеки, які можна було використовувати для
написання тестів, що вимагало від тестувальника вміння програмувати лише на
рівні розробника. Сучасні засоби автоматизованого тестування дозволяють
створювати автоматизовані тести за мінімальної участі людини [24].
Якщо провести поверхневу класифікацію, то засоби автоматизації
тестування можна розділити на дві групи:
− засоби функціонального навантаження;
− засоби тесту навантаження.
До першої групи відносяться інструменти, призначені для перевірки
відповідності додатків, що пред’являються бізнес-вимогам.
Другу групу утворюють інструменти для перевірки та оцінки
продуктивності додатків.
Перші програмні системи розроблялися у межах програм наукових
досліджень чи програм потреб міністерств оборони. Тестування таких продуктів
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 31

проводилося строго формалізовано із записом всіх тестових процедур, тестових
даних, отриманих результатів. Тестування виділялося в окремий процес, який
починався після завершення кодування, але при цьому зазвичай виконувалося
тим же персоналом.
2.5 Розвиток підходів до тестування програмного забезпечення
У 1960-х багато уваги приділялося “вичерпному” тестуванню, яке має
проводитись з використанням усіх шляхів у коді або всіх можливих вхідних
даних. Було зазначено, що в цих умовах повне тестування ПЗ неможливе, тому
що, по-перше, кількість можливих вхідних даних дуже велика, по-друге, існує
множина шляхів, по-третє, складно знайти проблеми в архітектурі та
специфікаціях. З цих причин “вичерпне” тестування було відхилено та визнано
теоретично неможливим.
На початку 1970-х тестування ПЗ позначалося як “процес, спрямований
демонстрацію коректності продукту” чи як “діяльність з підтвердження
правильності роботи ПЗ”. У програмній інженерії, що зароджувалася,
верифікація ПЗ значилася як “доказ правильності”. Хоча концепція була
теоретично перспективною, на практиці вона вимагала багато часу і була
недостатньо всеосяжною. Вирішили, що доказ правильності – неефективний
метод тестування ПЗ. Однак, у деяких випадках демонстрація правильної роботи
використовується і в наші дні, наприклад, приймально-здавальні випробування.
У другій половині 1970-х тестування представлялося як виконання
програми із наміром знайти помилки, а не довести, що вона працює. Успішний
тест – це тест, який виявляє раніше невідомі проблеми. Цей підхід прямо
протилежний попередньому. Зазначені два визначення є “парадоксом
тестування”, в основі якого лежать два протилежні твердження: з одного боку,
тестування дозволяє переконатися, що продукт працює добре, а з іншого –
виявляє помилки в ПЗ, показуючи, що продукт не працює. Друга мета тестування
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 32

є продуктивнішою з погляду поліпшення якості, оскільки дозволяє ігнорувати
недоліки ПЗ.
У 1980-х тестування розширилося таким поняттям як попередження
дефектів. Проектування тестів – найефективніший із відомих методів
попередження помилок. У цей час стали висловлюватися думки, що необхідна
методологія тестування, зокрема, що тестування має включати перевірки
протягом циклу розробки, і це має бути керований процес. У ході тестування
треба перевірити не лише зібрану програму, а й вимоги, код, архітектуру, тести.
“Традиційне” тестування, що існувало до початку 1980-х, стосувалося
тільки скомпільованої, готової системи (зараз це зазвичай називається системне
тестування), але надалі тестувальники стали залучатися до всіх аспектів
життєвого циклу розробки. Це дозволяло раніше знаходити проблеми у вимогах
та архітектурі і тим самим скорочувати терміни та бюджет розробки [23].
В середині 1980-х з’явилися перші інструменти автоматизованого
тестування. Передбачалося, що ПК зможе виконати більше тестів, ніж людина, і
це зробить надійніше. Спочатку ці інструменти були вкрай простими й не мали
можливості написання сценаріїв скриптовими мовами.
На початку 1990-х до поняття “тестування” стали включати планування,
проектування, створення, підтримку та виконання тестів та тестових оточень. Це
означало перехід від тестування до забезпечення якості, що охоплює весь цикл
розробки ПЗ. У цей час починають з’являтися різні програмні інструменти для
підтримки процесу тестування: більш просунуті середовища для автоматизації з
можливістю створення скриптів та генерації звітів, системи управління тестами,
програмного забезпечення для проведення навантажувального тестування.
В середині 1990-х з розвитком інтернету та розробкою великої кількості
Web-додатків особливу популярність стало набувати “гнучке тестування” (за
аналогією з гнучкими методологіями програмування).
У 2000-х з’явилося ще ширше визначення тестування, коли до нього було
додано поняття “оптимізація бізнес-технологій” BTO (Business Technology
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 33

Optimization). BTO спрямовує розвиток інформаційних технологій відповідно до
цілей бізнесу. Основний підхід полягає в оцінці та максимізації значущості всіх
етапів життєвого циклу розробки ПЗ для досягнення необхідного рівня якості,
продуктивності, доступності.
При тестуванні Web-додатків застосовуються ті ж класичні методи й
техніки проектування тестів. Web-програми, як правило, мають більш простий
інтерфейс, ніж “десктопні” програми, так як для користування браузером не
потрібні якісь спеціальні навички.
Але існує ряд нюансів, пов’язаних із соціальними та технологічними
особливостями Web-додатків, що відрізняють їх від інших видів додатків, і які
обов’язково потрібно враховувати під час тестування, щоб виконати його
професійно:
− фантастичне різноманіття технологій, які ховаються за простим
фасадом браузера – фактично кожен Web-додаток є не самостійною програмою,
а частиною всесвітньої павутини, і до роботи Web-додатку залучено дуже багато
різнорідних компонентів;
− неймовірна швидкість Web-розробки як у вузькому, так і в широкому
сенсі – короткі релізи, вимоги, що швидко змінюються, постійне вдосконалення
існуючих технологій й виникнення нових, приголомшлива різноманітність
користувачів, від випадкових відвідувачів до постійних клієнтів, від немовлят до
людей похилого віку, від новачків до хакерів, повна відкритість технологій,
протоколів передачі даних, стандартів, і водночас необхідність особливо
ретельного захисту [11].
2.6 Порівняння автоматизованого та ручного підходів у тестуванні
Web-додатків
Однією з основних відмінностей у ручному та автоматизованому підходах
до тестування ПЗ є суб’єкт, який виконує тести. Ручний підхід до тестування
може бути описаний як процес, в якому людина починає виконання кожного
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 34

тесту, взаємодіє з ним, а також інтерпретує, аналізує та надає результати тесту.
Тестування ПЗ автоматизовано у разі, якщо є можливість виконати дані операції
без участі людини [2].
Повністю автоматизоване тестування має бути в змозі запускати вибраний
набір тестів або його частину без необхідності втручання людини після запуску
цих тестів. Повинна існувати можливість зняти потрібні показники та результати
тестів, порівняти їх з очікуваним результатом, виявити відмінності та відзначити
статус усіх тестів, які були пройдені успішно або провалені.
Ручне тестування підходить більше для використання в тих випадках, коли
потрібне виконання та оцінка складних завдань.
На противагу цьому, коли потрібно виконати велику кількість завдань, що
повторюються, або згенерувати тестами велику кількість даних, то краще
використовувати засоби автоматизації тестування, щоб їх виконати.
Таким чином можна сказати, що автоматизоване тестування доречно в
тому випадку, де ручне тестування є рутинною задачею, що повторюється. З
іншого боку, необхідно пам’ятати, що автоматизовані тести не можуть повністю
замінити ручного тестування, оскільки навіть дуже схожі тести, виконані вручну
та автоматично мають різну цінність для тестування.
Відтак, дуже важливо автоматизувати ті тести, які прості й зрозумілі. Зайве
складні тести можуть бути досить неефективними, а вартість їхньої підтримки
може перекрити всі переваги від їх використання [21].
Тести, які призначені для автоматизації конкретного тестового сценарію
складаються не просто з кроків, що автоматично виконуються, але також і з
інших етапів. Ці етапи дозволяють ефективно використовувати тести повторно.
В роботі “Як автоматизувати тестування” Кейт Стобі та Марк Бергман
виділяють наступні етапи [3]:
1. Налаштування – приведення ПЗ до стану, коли воно готове до
виконання тесту.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 35

2. Виконання – основний етап випробування. Конкретні кроки, необхідні
для перевірки функціональності, обробки помилок та інших схожих завдань.
3. Аналіз – це процес визначення, проходить тест чи ні. Це
найважливіший і найскладніший етап тесту.
4. Звітність – включає відображення та доставку аналізу результатів
тесту, наприклад, файли журналів, базу даних або інші файли, згенеровані в ході
або після виконання тесту.
5. Очищення – етап, який повертає ПЗ до початкового стану так, що
наступний тест може бути виконаний незалежно від виконання пройденого
раніше тесту.
6. Допомога – включає підтримку та забезпечення надійності тесту
протягом всього його життя.
Слід зазначити, що ручне та автоматизоване тестування можуть бути
використані спільно на кожному з описаних етапів тестування.
Можливо, наприклад, мати автоматизовані кроки для встановлення та
налаштування програми, проходження тесту, розсилки результатів та очищення
при необхідності виконання ручного аналізу результатів тесту або забезпечення
надійності виконання тестів протягом часу.
Як було згадано раніше ручне та автоматизоване тестування – це два
різних підходи тестування і вони не можуть замінити один одний. Для того, щоб
збільшити корисний ефект, що випливає з переваг кожного підходу,
автоматизовані тести повинні бути використані разом з ручними тестами.
Розглянемо якісне порівняння ручного та автоматизованого тестування
у вигляді переліку переваг та недоліків автоматизованих тестів. Отже,
основними перевагами автоматизованого тестування є [4]:
− точність та повнота виконання. Автоматизоване тестування гарантує,
що тести проводяться повністю і точно так, як описано в сценарії тесту. Ручне
тестування може бути схильне до людського фактора (втоми або низької
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 36

концентрації спеціаліста тестування), який викликає упущення та помилки у
виконанні тесту;
− точність результатів, що надаються у файлах журналів та звітах зі
звітами та інших результатів тестування;
− повнота інформації по тестах. Дані, зібрані за результатами роботи
автоматичних випробувань, і що зберігаються в базі даних більш доступні, ніж
результати після ручних тестів;
− для виконання тестів потрібно менше людських ресурсів. Ручне
тестування, порівняно з автоматизованим, є основним споживачем трудових
ресурсів. Автоматизація звільняє людей, щоб вони могли зробити важливішу
роботу;
− швидкість виконання та можливість повторного використання
тестів. Тривалість випробувань при використанні автоматизації, як правило,
коротша, ніж під час проведення ручних тестів. Крім того, автоматичні тести, на
відміну від ручних тестів, можуть виконуватись 24 години на добу 7 днів на
тиждень. Тому автоматизовані тести можуть надавати результати випробувань
швидко і часто;
− продуктивність повного регресійного тестування. Автоматизація
дозволяє розширити діапазон регресійних тестів й збільшує шанс виявлення
помилок, внесених при виправленні раніше знайдених проблем;
− виконання видів тестів, що виходять за рамки ручного тестування.
Автоматизація дозволяє фахівцям тестування виконувати тести продуктивності
для середніх або великих систем. Виконати такі тести вручну неможливо.
Основні недоліки автоматизованого тестування:
− потрібні великі початкові фінансові вкладення при придбанні,
впровадженні інструментів та навчанні фахівців автоматизації тестування;
− високі вимоги до спеціалістів для проведення автоматизованих тестів;
− неможливість повного покриття автоматизованими тестами.
Засоби автоматизованого тестування не охоплюють весь спектр засобів розробки
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 37

та інших додатків, внаслідок чого залишається необхідність у ручному
тестуванні.
Розглянувши два підходи до тестування, можна зробити висновок, що ні
автоматизоване, ні ручне тестування не може повністю замінити одне одне.
Незважаючи на недоліки кожного з підходів, вони мають ряд унікальних
переваг, при грамотному поєднанні яких можна досягти якісного поліпшення
процесу тестування та розробки ПЗ в цілому.
2.7 Методології розробки та тестування програмного забезпечення
Як і процес розробки, процес тестування ПЗ також слідує певної
методології. В даному випадку під методологію розуміється різноманітність
комбінацій принципів, ідей, методів та концепцій, які використовуються під час
роботи над проектом. У той же час існує досить велика кількість різних підходів
до тестування, кожен з яких має свої відправні точки, час виконання та методи,
що використовуються на кожному етапі. І вибір того чи іншого з них може бути
досить складним завданням [17].
Розглянемо різні існуючі підходи до тестування ПЗ та їх основні
особливості.
Каскадна модель (Модель водоспаду) – одна з найстаріших моделей, яку
можна використовувати не тільки для розробки ПЗ або тестування, але і
практично для будь-якого іншого проекту. Її основний принцип – послідовний
порядок виконання завдань. Це означає, що можна перейти до наступного етапу
розробки чи тестування лише після успішного завершення попереднього. Ця
модель підходить для невеликих проектів і застосовна лише в тому випадку,
якщо всі вимоги точно визначені.
Основними перевагами цієї методології є економічна ефективність,
простота використання та управління документацією.
Процес тестування ПЗ починається після завершення процесу розробки. На
цьому етапі всі необхідні випробування передаються від агрегатів до системних
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 38

випробувань з метою контролю роботи компонентів як окремо, так і в комплексі.
Схема каскадної моделі показана на рис. 2.2.
Затвердження вимог
Проектування
Розробка
Тестування
Підтримка

Рисунок 2.2 – Схема каскадної моделі
Крім переваг, згаданих вище, такий підхід до тестування має свої недоліки.
Завжди є можливість виявлення критичних помилок у процесі тестування. Це
може призвести до необхідності повністю змінити одну із складових екосистеми
або навіть усю логіку проекту. Однак це завдання неможливе у випадку
каскадної моделі, тому що в цій методології заборонено повертатися до
попереднього кроку.
Метод V-моделі, як і каскадна модель, ґрунтується на прямій
послідовності кроків. Основна різниця між цими двома методологіями у тому,
що тестування планується паралельно з відповідним етапом розробки.
Відповідно до цієї методології тестування ПЗ, процес починається, як тільки
вимоги визначені та стає можливим розпочати статичне тестування, тобто
перевірку, що дозволяє уникнути можливих дефектів ПЗ на пізнішому етапі.
Для кожного рівня розробки ПЗ створюється відповідний план тестування,
який визначає очікувані результати, а також критерії входу та виходу даного
продукту.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 39

На схемі цієї моделі показаний принцип поділу задач на дві частини. Ті, що
пов’язані з проектуванням та розробкою, розміщені ліворуч. Завдання, пов’язані
з тестуванням ПЗ, показані у правій частині (рис. 2.3).

Рисунок 2.3 – Модель верифікації та валідації
Основні етапи цієї методології можуть змінюватись, але зазвичай вони
включають наступне:
1. Етап визначення вимог. До цього етапу відносяться приймальні
випробування. Його головне завдання – оцінити, чи готова система до кінцевого
використання.
2. Стадія, на якій відбувається високорівневие проектування (High-Level
Design). Цей етап пов’язаний із тестуванням системи і включає оцінку
відповідності вимогам, що пред’являються до інтегрованих систем.
3. Етап Detailed Design паралельний фазі інтеграційного тестування, яка
перевіряє взаємодію між різними компонентами системи.
4. Етап написання коду. На цьому етапі система вже безпосередньо
розробляється.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 40

5. Після етапу написання коду починається ще один важливий етап –
тестування: модульне тестування, інтеграційне тестування та приймальне
тестування. Дуже важливо переконатися, що поведінка окремих частин і
компонентів ПЗ коректна й відповідає вимогам, що висуваються.
Єдиним недоліком розглянутого підходу тестування є відсутність готових
рішень, які могли б бути застосовані для позбавлення від дефектів ПЗ, виявлених
на етапі тестування.
Методологія мультикаскадної моделі (Multi-Stage Software Testing Model).
Робочий процес поділено на кілька циклів, кожен з яких також поділений на
модулі. Кожна ітерація додає ПЗ певну функціональність. Інкремент складається
із трьох циклів:
1. Проектування та розробка.
2. Тестування.
3. Реалізація.
Ця модель дозволяє одночасно розробляти різноманітні версії продукту.
Наприклад, перша версія може проходити тестування, тоді як друга версія все
ще перебуває на стадії розробки. Третя версія може пройти стадію проектування
одночасно. Цей процес може продовжуватися доти, доки проект не буде
завершено.
Очевидно, що ця методологія вимагає якнайшвидше виявити якомога
більше помилок у ПЗ для того, щоб зробити підтвердження готовності продукту
до доставки до кінцевого користувача.
Всі ці фактори значно збільшують вагу вимог до тестування. Схема
інкрементної моделі представлена на рис. 2.4.
Порівняно з попередніми методологіями, інкрементна модель має низку
важливих переваг. Вона більш гнучка, зміни вимог призводять до зниження
витрат, а процес тестування ПЗ ефективніший, оскільки набагато простіше
проводити тестування та налагодження за допомогою невеликих ітерацій. Однак
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 41

варто відзначити, що загальна вартість все ж таки вища, ніж у випадку каскадної
моделі.

Рисунок 2.4 – Інкрементна модель
Спіральна модель – це методологія тестування ПЗ, заснована на
інкрементному підході та прототипуванні. Вона складається з чотирьох етапів:
1. Планування;
2. Аналіз ризиків;
4. Розвиток;
5. Оцінка.
Відразу після завершення першого циклу починається другий цикл.
Тестування ПЗ починається на стадії планування та продовжується до стадії
оцінки. Головна перевага спіральної моделі полягає в тому, що перші результати
випробувань з’являються відразу після того, як результати випробувань
з’являються на третьому етапі кожного циклу, що допомагає гарантувати
правильну оцінку якості.
Однак важливо мати на увазі, що ця модель може бути досить дорогою та
не підходить для невеликих проектів. Схема спіральної моделі
показана на рис. 2.5.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 42

Рисунок 2.5 – Спіральна модель
Незважаючи на те, що ця модель є досить старою, вона залишається
корисною як для тестування, так і для розробки.
Крім того, останнім часом змінилася основна мета багатьох методологій
тестування ПЗ, включаючи спіральну модель. Вона використовує їх не тільки для
пошуку дефектів у додатках, але і для з’ясування причин, що їх спричинили.
Такий підхід допомагає розробникам працювати більш ефективно та швидко
виправляти помилки.
Методологію розробки та тестування ПЗ Agile можна описати як
сукупність підходів, орієнтованих на використання інтерактивної розробки,
динамічне формування вимог та забезпечення їх реалізації в результаті постійної
взаємодії в рамках робочої групи, що самоорганізується.
Більшість гнучких методологій розробки ПЗ спрямовано на мінімізацію
ризиків за рахунок розробки короткими ітераціями. Одним із головних
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 43

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

Рисунок 2.6 – Схема Agile
Екстремальне програмування – один із прикладів гнучкої розробки ПЗ.
Відмінною особливістю цієї методології є парне програмування, ситуація, коли
один розробник працює над кодом, тоді як його колега постійно переглядає
написаний код.
Процес тестування ПЗ дуже важливий, оскільки він починається ще до
того, як написано перший рядок коду. Кожен модуль програми повинен мати
модульний тест, щоб більшість помилок можна було виправити на етапі
написання коду. Ще однією відмінністю є те, що тест визначає код, а не навпаки.
Це означає, що певна частина коду може вважатися завершеною лише в тому
випадку, якщо всі тести успішно завершені. В іншому випадку – код буде
відхилено.
Основними перевагами цієї методології є безперервне тестування та
короткі релізи, що допомагає забезпечити високу якість коду.
Scrum – це частина методології Agile, ітеративної інкрементної структури,
призначеної для управління процесом розробки ПЗ (рис. 2.7).
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 44

Рисунок 2.7 – Схема Scrum
Згідно з принципами Scrum, команда тестувальників повинна брати участь
у наступних етапах:
1. Участь у Scrum-плануванні.
2. Підтримка модульного випробування.
3. Тестування історій користувача.
4. Співпраця із замовником та власником продукту для визначення
критеріїв достатності;
5. Забезпечення автоматичного тестування.
Крім того, члени команди QA (Quality Assurance Team Members) повинні
бути присутніми на всіх щоденних зборах, а також інші члени команди, щоб
обговорити, що було протестовано та зроблено вчора, що буде протестовано
сьогодні та загальний прогрес тестування.
У той же час принципи гнучкої методології у Scrum призводять до появи
специфічних особливостей:
1. Оцінка зусиль, необхідних для кожної історії користувача, обов’язкова.
2. Тестувальник повинен звертати увагу на вимоги, оскільки вони можуть
постійно змінюватися.
3. Ризик регресії зростає разом із частими змінами коду.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 45

4. Одночасне планування та виконання тестів.
5. Непорозуміння між членами команди, якщо вимоги замовника не до
кінця зрозумілі.
У цьому розділі досліджено та проаналізовано методи та засоби тестування
програмного продукту, зокрема Web-додатків, у життєвому циклі розробки ПЗ,
а також визначено переваги та недоліки відповідних методів і засобів.
Крім того, було встановлено, що функціональне (ручне) тестування
вигідніше використовувати при розробці нового бізнес-процесу, а
автоматизоване рішення доцільніше використовуватиме для перевірки
існуючого функціоналу.

Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 46

3 ФУНКЦІОНАЛЬНЕ ТЕСТУВАННЯ ТА СТВОРЕННЯ
ТЕСТОВИХ ЗРАЗКІВ ДЛЯ WEB-ДОДАТКІВ
3.1 Визначення сутності функціонального тестування Web-додатків
Сьогодні (за даними 2022 року) в Інтернеті налічується понад
1.9 млрд. сайтів, і ними користуються понад 5,1 млрд. людей у всьому світі.
Дивлячись на ці дані, стає зрозумілим, чому у світі розробляється так багато
нових Web-додатків.
Розробка Web-додатків призводить до необхідності залучення великої
кількості різних ІТ-фахівців. Той факт, що Всесвітня павутина продовжить
нарощувати темпи свого розвитку, підтверджується використанням
комп’ютерних хмарних технологій. Хмарні технології стають новою реальністю
сучасного Інтернету: навіть колись звичні настільні Word та Excel тепер
представлені як Web-альтернативи від Microsoft. Виходячи з цього, можна
стверджувати, що потреба в хороших інженерах із забезпечення якості, що
спеціалізуються на Web-продуктах, тільки зростатиме.
Як уже згадувалося раніше, Web-додатки засновані на клієнт-серверній
архітектурі. Тестування Web-додатків також має свої особливості. Клієнт
згаданий як перший компонент архітектури. У класичній ситуації клієнт
представлений браузером, тому питання тестування кросбраузерної сумісності
(через різноманітність браузерів) є дуже актуальним.
Кросбраузерне тестування – це тестування на відповідність вимогам та
стандартам відображення та функціонування Web-програми в різних браузерах
та на різних операційних системах (ОС). У сучасному світі стандартизація
набуває глобальних масштабів, тому більшість популярних браузерів
обробляють код однаково. Проте потреба у кросбраузерному тестуванні не
зникає, оскільки всі проблеми вирішуються стандартизацією.
Перед початком роботи рекомендується ознайомитися необхідним
набором браузерів для ПЗ. Таким чином, можна зібрати статистику з цільової
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 47

аудиторії продукту та обмежити кросбраузерне тестування набором
найпопулярніших браузерів у цій аудиторії.
В контексті регресійного тестування, коли час та людські ресурси
обмежені, можна також застосувати практику розподілу браузерів: призначити
кожному спеціалісту з тестування певний браузер. Це допоможе покрити
великий відсоток кросбраузерних дефектів. Однак цей метод має свої недоліки.
Він найбільш ефективний у великій команді тестування, але стає незастосовним,
коли є лише один фахівець з якості.
Для кросбраузерного тестування потрібно перевірити:
1. Функціональність продукту, що реалізується на стороні клієнта.
2. Коректне відображення графічних елементів.
3. Шрифти та розміри текстових символів.
4. Доступність та функціональність різних форм, у тому числі їх
інтерактивність.
Всі основні браузери серед аудиторії потребують тестування, але особливу
увагу слід приділити Internet Explorer. Саме тут часто виникають проблеми, яких
немає в інших браузерах. В Internet Explorer також потрібно звернути особливу
увагу на масштабованість та продуктивність JavaScript.
Існують спеціальні інструменти для тестування Web-інтерфейсу додатків –
валідатори. Валідатори – програми, які перевіряють, чи відповідає документ,
потік даних або фрагмент коду певному формату. Якщо знань для оцінки
відповідності макета стандартам недостатньо, можна використати для цього
автоматичні інструменти та проаналізувати результат, щоб вказати розробникам
найбільш серйозні помилки.
Не слід забувати, що іноді валідатори звертають увагу на найменші
помилки, які, швидше за все, ніхто не виправить. Якщо запустити звіти про
помилки цих типів дефектів, то буде зручніше зібрати їх до одного документу й
прикріпити до звіту. До таких “дрібниць” можна віднести всілякі рекомендації,
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 48

які не впливають на відображення та функціонування контенту. Приклад роботи
валідатора наведено на рис. 3.1.

Рисунок 3.1 – Приклад роботи валідатора W3C
Як видно з рис. 3.1., у першому прикладі, у тега img немає атрибута Alt.
Alt – це параметр, що визначає який текст буде написаний, якщо, наприклад,
відключено зображення або картинки не завантажилися через повільне
підключення до Інтернету. Це необхідно, наприклад, якщо люди мають
проблеми із зором. Люди з порушеннями зору часто використовують спеціальні
програми читання з екрану скринрідери. Програми читання з екрана дозволяють
ідентифікувати та інтерпретувати події, що відбуваються на екрані. Якщо
програма читає на екрані, вона не може прочитати зображення, а тільки сам
текст. А якщо цей текст не заданий, то людина ніколи не дізнається, що там було.
Одним з найважливіших компонентів Web-додатків є форми для
заповнення, з якими користувач взаємодіє за допомогою клієнта. Однак ці форми
часто є джерелом дефектів, які можуть завдати компанії великі фінансові та
репутаційні втрати.
Щоб уникнути пропущених помилок у формах для продуктивного
середовища, необхідно:
1. Уважно перевірити, чи поля заповнені й позначені відповідним чином.
2. Після того, як форма заповнена і відправлена, необхідно переконатися,
що з даними відбувається саме те, що очікується. Наприклад, якщо дані мають
бути введені в базу даних, необхідно перевірити, чи правильно заповнені усі поля
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 49

у необхідних таблицях. Для цього необхідно мати доступ до баз даних, схем і
таблиць, а також знання мови структурованих запитів SQL.
3. Використання чат-листів для тестових форм. Чат-листи – це набір
повторних перевірок. Чат-листи складаються з їх подальшого багаторазового
використання. Прикладом чат-листів є введення можливих і неможливих
значень типів даних, спеціальних символів або символів в іншому кодуванні.
4. Необхідно перевірити, чи відображаються інформаційні повідомлення,
зрозумілі користувачеві про необхідність заповнення порожніх полів після
спроби надсилання форми.
5. Зверніть увагу на реалізацію екрануючих символів у полях форми, які
є потенційним джерелом вразливостей для програми та користувачів.
Екранування має виконуватися не тільки на рівні клієнта, але й на рівні сервера,
що досить легко відключити в клієнті (наприклад, за допомогою спеціальних
плагінів, що знімають всі можливі обмеження в кілька кліків, таких як Web
Developer Toolbar – Forms).
6. Варто переконатися, що після заповнення форми користувач отримує
підтверджуючий лист із зазначенням відповідного відправника, а тіло листа
відповідає вимогам, наприклад, робочі посилання.
7. Використння спеціальних допоміжних інструментів для тестування
форм (наприклад, Web Developer Toolbar).
Особлива цінність Інтернету у тому, що він є практично безмежним
джерелом інформації. Частина цієї інформації представлена текстами, із якими
користувач взаємодіє через клієнта. Більшість Web-ресурсів вимагають
перевірки текстів на наявність граматичних помилок та друкарських помилок.
Звичайно, значимість цього тестування не така велика у порівнянні з
функціональним напрямком, але нехтувати ним не варто. Є програми для
перевірки орфографії. Вони доступні онлайн або у вигляді плагінів для браузера.
Хороший інструмент може бути наданий українською компанією за
допомогою технології OnlineCorrector. OnlineCorrector допоможе знайти та
Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 50

виправити орфографічні помилки в українських або англійських текстах. Мовні
моделі OnlineCorrector включають велику кількість слів і фраз. Для виявлення
помилок та пошуку замін OnlineCorrector використовує бібліотеку машинного
навчання. Завдяки їй, він може розшифровувати слова, спотворені до
невпізнання, і враховувати контекст під час пошуку друкарських помилок. Крім
того, технологія орфографії не чіпляється за нові слова, які ще не увійшли до
словників. Для вбудовування OnlineCorrector в додаток достатньо
використовувати його API (набір готових класів, процедур, функцій, структур та
констант, що надаються додатком або операційною системою для використання
у зовнішніх програмних продуктах). Обмеження на використання сервісу
викладені в угоді користувача.
Тестування частини Web-додатка, розміщеного на Web-сервері, також
може бути виконане без графічного (клієнтського) і Web-інтерфейсу, але для
цього потрібно, щоб фахівець володів певним рівнем технічних знань і навичок,
а також використовував додаткові інструменти.
Усі компоненти Web-програми повинні взаємодіяти один з одним, і це
робиться завдяки HTTP(s). Без HTTP наша система не функціонувала б у
принципі, оскільки HTTP – це протокол передачі даних, що займає одне з
головних місць у нашій клієнт-серверній архітектурі.
Взаємодія здійснюється через повідомлення (запити та відповіді):
відповідь сервера має бути надіслано на відправлений запит від клієнта. Приклад
відповіді від сервера показано на рис. 3.2.
Класичний запит/відповідь складається з 3 компонентів:
1. Початковий рядок.
2. Назва.
3. Тіло повідомлення.
При роботі з відповідями фахівець із тестування повинен насамперед
звернути увагу на методи та коди стану, які присутні у стартовому рядку.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 51

Рисунок 3.2 – Приклад відповіді від сервера
Найбільш популярними методами, описані у першому розділі роботи, є
GET та POST. Також наявні й інші методи: PUT, DELETE, CONNECT і т.д.
Однак вони використовуються рідше, ніж методи GET та POST.
Класичними програмами, які можна використовувати для створення
запитів, є Fiddler або Postman. Використовуючи дані програми, можна легко
відслідковувати всі запити від клієнта та відповіді, переглядати їх деталі,
вносити власні зміни та надсилати змінені запити на сервер, оцінюючи поведінку
системи у цьому випадку.
При тестуванні запитів необхідно:
1. Зрозуміти, чи правильний метод використовується для конкретного
запиту.
2. Розуміти запити. Їх досить легко зрозуміти, особливо якщо йдеться про
GET – вони логічно доступні навіть звичайному користувачеві. Аналіз запитів –
це можливість виявити прихований дефект набагато швидше, ніж пошук його в
інтерфейсі.
3. Відстежувати трафік для запитів до інших серверів.
4. При відстеженні трафіку потрібно звертати пильную увагу на коди
стану.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 52

Кожна відповідь на будь-який запит містить багато корисної інформації
для розробників та фахівців з тестування ПЗ. Одним із джерел такої інформації
може бути код стану. Використовуючи цей код, клієнт дізнається про результати
свого запиту та визначає, які дії він має зробити далі.
Набір кодів стану є стандартним та описаний у відповідних документах
RFC (Request for Comments, запит коментарів). Щоразу, коли потрібно створити
повідомлення про помилку щодо непрацюючих посилань, інших елементів Web-
сторінки або системних помилок, слід вказати відповіді сервера. Це заощадить
розробнику час для визначення причини дефекту.
Усі коди можна розділити на групи (соті, двохсоті, трисоті, чотирисоті і
п’ятисоті). Кожна група має власний тип інформації. Таблиця з групами кодів
стану представлена табл. 3.1.
Таблиця 3.1 – Групи кодів стану для відповідей із сервера
Тип інформації
Код Призначення
коду
Інформація про передачу повідомлення.
Самі повідомлення від сервера містять лише
lxx Інформуючі
стартовий рядок відповіді та, якщо потрібно, кілька
специфічних для відповіді полів заголовка.
Повідомляють про Інформування про успішну обробку запиту клієнта.
2хх
успішну операцію Найкласичнішим і найпоширенішим є «200 ОК».
Повідомляє, що для успішного виконання операції
необхідно зробити інший запит.
З цього типу п’ять кодів: 301, 302, 303, 305 і 307,
Зхх Перенаправляючі
відносяться безпосередньо до перенаправлення.
Адреса, за якою клієнту потрібно зробити запит,
сервер вказує в заголовку Location.
Вказівки на помилки з боку клієнта. При
Помилка на стороні
4хх використанні всіх методів, крім HEAD, сервер
клієнта (запит)
повертає пояснення причин.
Помилка на стороні Говорить про помилки виконання операції з вини
5хх
сервера (відповідь) Web-сервера.

Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 53

На практиці, використовуючи спеціальні програми для тестування, можна
легко сортувати запити та відповіді за кодом стану та вибирати, наприклад, всі
400-і та 500-і з подальшим їх аналізом. Таким чином, можна швидко знайти
дефекти з неправильними стилями, скриптами, файлами, функціями програм
тощо.
Будь-яке тестування вимагає осмисленого підходу з використанням
методів аналізу та проектування тестів. Інакше є ризик назавжди пропустити
велику кількість помилок. І вартість праці під час тестування буде мінімальною.
Без розуміння прийомів та методів застосування аналізу тестів та проектування
тестів практично неможливо протестувати якісне ПЗ. Загалом ключові концепції
аналізу тестів та проектування тестів застосовні як до тестування настільних, так
і до Web-додатків. Однак зі значним застереженням необхідно враховувати всі
згадані нюанси тестування Web-додатків.
3.2 Створення тестових кейсів для Web-додатку
Тест-кейс – це опис того, як працює система, що може виконати будь-яка
людина з команди, чи то спеціаліст з тестування, розробник, аналітик або навіть
бізнес-підрядник. Тестові приклади складаються фахівцями тестування, а
точніше, аналітиками тестів або розробниками тестів.
У світі немає однозначної думки про необхідність виділення тестового
аналітика в окрему проектну одиницю. Відмінності між функціями аналітика
тестів, дизайнера тестів та тестувальника очевидні не всім. І якщо з обов’язками
тестувальника все більш-менш зрозуміло, то проектуванням тестів та аналізом
тестів найчастіше займаються ті самі люди. Тільки деякі організації ці ролі чітко
розділяють.
Test Analyst (test designer) – це член команди тестування, основне завдання
якого – визначити, що і як потрібно тестувати.
Для цього він виконує такі дії:
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 54

1. Досліджує продукт. Необхідно вивчити всю документацію,
намагаючись зрозуміти, які бізнес-цілі виконує даний продукт і що хоче бачити
замовник.
2. Створює логічну карту продукту за допомогою “mind map”-техніки
(побудова ментальної карти) представлення будь-якого процесу чи події у
систематизованій візуальній формі.
3. Розбиває програмний продукт на складові. Процес побудови
ментальної карти нерозривно пов’язаний з виконанням декомпозиції продукту.
Глибина декомпозиції визначається легкістю сприйняття отриманої ієрархічної
структури. При декомпозиції слід дотримуватися балансу між повнотою і
простотою опису системи.
4. Описує тестові приклади (test cases) для тестування функціональності
за допомогою методів проектування тестів (класи еквівалентності, граничні
значення тощо).
5. Розставляє пріоритети тестування. Пріоритети повинні бути
встановлені, виходячи з вимог клієнта, рівня ризику, складності системи та
тимчасових обмежень.
6. Координує тестові кейси з бізнес-замовником та системними
аналітиками.
Розглянемо тестові приклади. Тестові випадки поділяються за очікуваним
результатом на:
1. Позитивні тести. Використовуються лише правильні дані та
переконуються, що ПЗ правильно виконало функцію, що викликається.
2. Негативні тести. Кейси працюють як із правильними, так і з
невірними даними (не менше одного неприпустимого параметра).
Мета полягає в тому, щоб перевірити наявність виняткових ситуацій
(спрацьовують валідатори), а також перевірити, що функція, яка викликається
додатком, не виконується при спрацьовуванні валідатора.
Кожен тестовий випадок може складатися з трьох частин:
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 55

1. Попередні умови. Список дій, що приводять систему до відповідного
стану, для виконання основних кроків верифікації. Або це може бути перелік
умов, за яких система знаходиться в стані, придатному для виконання основного
тесту.
2. Тестові кроки. Список дій, які переміщують систему з одного стану до
іншого, з метою отримання результату. Виходячи з отриманого результату,
можна зробити висновок, що реалізація відповідає зазначеним вимогам.
3. Постумови. Список дій, що повертають тестовану систему у
початковий стан перед виконанням тесту. Постумови не є обов’язковою
частиною, але вони вважаються правилом гарного тону. Ця частина може бути
актуальна для автоматизованого тестування, коли за один автотест можна
заповнити базу даних великою кількістю невірних документів в одному
автотесті.
Найкращі методи автоматизованого тестування в гнучкій розробці ПЗ – це
спосіб підвищити ефективність автоматизованого засобу тестування, що
призводить до скорочення часу тестування ПЗ. За словами Стокдейла,
автоматизація тестових випадків значно скорочує час ручного тестування
повторюваних завдань тестувальником ПЗ. Автоматизоване тестування робить
процеси розробки ПЗ гнучкими та економними. Найкращі методи
автоматизованого тестування для скорочення часу тестування ПЗ включають
вибір правильних тестових випадків для автоматизації [28].
Для автоматизації слід розглядати тестові випадки, які займають велику
кількість часу, наприклад повторювані тести, тести з великими наборами даних
і тестові випадки, що потрібно виконувати в різних Web-браузерах.
Автоматизоване тестування має проводитися протягом спринту, тобто
виконання тестових випадків до, під час та після спринту.
Крім того, розробляючи автоматизовані тести, які триватимуть довше,
тобто тестувальники повинні зосередитися на написанні невеликих тестових
випадків, що зосереджені на програмних блоках. Тому пишуться такі тестові
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 56

випадки, які не залежать від інтерфейсу користувача і, таким чином, є такими,
що не впливають на зміни інтерфейсу користувача.
SmartBear Software стверджує, що наступні найкращі методи
автоматизованого тестування забезпечують повне тестування ПЗ: вибирайте
тестові випадки для автоматизації, часто тестуйте та тестуйте завчасно,
вибирайте правильний інструмент автоматичного тестування, створіть тестові
дані хорошої якості та створіть автоматичні тести, які не впливають на зміни в
інтерфейсі користувача [4].
Шривастава пояснює, що час тестування скорочується за рахунок
впровадження автоматизації і, таким чином, впливає на швидке збільшення часу
виходу на ринок розробленого програмного додатка. Без втручання людини
автоматизовані тестові кейси можуть працювати без нагляду 24 години, і таким
чином тестування може бути завершено швидше, ніж тестування вручну [18].
Motwani пояснює, що перед початком автоматизованого тестування
тестувальник повинен переконатися, що інтерфейс, який буде тестуватися, був
ідентифікований, область автоматизації визначена, окремі тестові випадки, які
підлягають автоматизації, були визначені [20].
Бах рекомендує проводити різницю між автоматизацією та процесом, який
вона автоматизує. Засіб для тестування повинен бути ретельно відібраний і
забезпечувати зрілість продукту, щоб зменшити витрати на технічне
обслуговування. Правильний вибір засобів автоматизації залежить від програми,
яка буде тестуватися [19].
Поло та ін. надають перелік рекомендацій щодо автоматизованого
тестування, стверджуючи, що для конкретного проекту при виборі засобу
автоматизації тестування слід враховувати масштабованість. Крім того, для
кожної тестової діяльності повинні бути визначені умови входу та виходу, а
тестові випадки мають бути максимально конкретними. Також вхід і вихід для
кожного тестового випадку повинні бути зрозумілими [13].
Atlassian рекомендує паралельно виконувати автоматичні тести [16].
Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 57

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

Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 58

4 РОЗРОБКА СЦЕНАРІЇВ АВТОМАТИЗОВАНОГО
ТЕСТУВАННЯ WEB-ДОДАТКІВ
4.1 Автоматизоване тестування
Автоматизоване тестування ПЗ – це процес верифікації ПЗ, в якому
основні функції та етапи тесту, такі як запуск, ініціалізація, виконання, аналіз та
видача результатів, виконуються автоматично з використанням автоматизованих
інструментів тестування.
Можна тестувати програму на різних рівнях: код (модульні тести та
інтеграційне тестування), API та графічний інтерфейс. Різні типи тестів краще
підходять у різних ситуаціях. Розглянемо види автоматизованого тестування.
Ідентифікатори автоматизованого тестування поділяються на:
1. Модульне тестування (або unit testing):
− що тестується: чи правильно працюють класи та методи;
− хто тестує: розробник, який написав код;
− навіщо: щоб зловити найбільш очевидні помилки на етапі написання
коду.
2. Teasing-тестування API:
− що тестується: REST або SOAP послуги.
− хто тестує: розробники сервісів чи спеціалісти з автоматизації
тестування.
− навіщо: виявлення помилок на етапі тестування компонентів.
3. UI Тестування інтерфейсу користувача:
− що тестується: функціональність графічного інтерфейсу;
− хто проводить тестування: спеціалісти з автоматизації тестування;
− навіщо: полегшити роботу ручних (функціональних) тестувальників
та максимально швидко виявити помилки на етапі приймальних випробувань.
Модульні тести – це тестування одного модуля коду (зазвичай однієї
функції або класу у випадку об’єктно-орієнтованого коду) в ізольованому
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 59

середовищі. Це означає, що якщо код не використовує будь-які сторонні класи,
а замість них підставлені класи-заглушки (stubs та mock), код не повинен
працювати з мережею, файлами баз даних (інакше, тестується не сама функція
або клас, а також диск, бази і т.д.).
Stubs – це класи-заглушки, які повертають деякі дані замість виконання дії.
Наприклад, замість фактичного доступу до бази даних екземпляр класу бази
даних може повернути повідомлення про успішне завершення запиту. І при
спробі щось прочитати з нього, він повертає заздалегідь підготовлений масив із
даними.
Mock – це класи-заглушки, які використовуються для перевірки виклику
певної функції.
Зазвичай модульний тест передає різні вхідні дані функції та перевіряє, чи
вона повертає очікуваний результат. Наприклад, якщо є функція, яка перевіряє
правильність телефонного номера, їй заздалегідь надають підготовлені номери
та перевіряють, чи вона правильно їх розпізнає. Якщо є функція для вирішення
квадратного рівняння, перевіряємо, що вона повертає правильні значення (для
цього заздалегідь складаємо список рівнянь з відповідями).
Модульні тести хороші для тестування коду, який містить якусь логіку.
Якщо код не має великої логіки, але переважно містить виклики інших класів, то
писати модульні тести може бути важко.
API – це набір функцій, які можна викликати для отримання даних.
Наприклад, сервіс має Google.Maps має власний geocoder API. Відправивши на
нього запит з географічною адресою, можна отримати координати точки (і
навпаки), а НБУ має API, який повертає офіційний курс валюти на даний день.
Якщо будь-яка програма має API, можна протестувати її, відправивши
попередньо підготовлені запити й порівнявши отриману відповідь з очікуваною.
GUI (Graphical User Interface) – це графічний інтерфейс користувача, тобто
те, що користувач бачить на екрані. Це найважчий вид для тестування. Якщо
йдеться про тестування роботи сайту, то потрібно емулювати роботу браузера,
Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 60

що досить складно, та аналізувати інформацію, яка відображається на сторінці.
Але цей тип тестування дуже важливий, тому що він взаємодіє з програмою так
само, як і користувач. Тести GUI також називаються End-to-End або
приймальними (acceptance) тестами.
Відтак, зробимо проміжний висновок про те, що необхідно
автоматизувати:
1. Важкодоступні місця у системі (бекенд-процеси, протоколювання
файлів, запис до бази даних).
2. Часто використовуваний функціонал, ризики від помилок у якому
досить високі. Автоматизуючи перевірку критичних функціональних
можливостей, можна гарантувати, що помилки будуть швидко знайдені, а отже,
вони можуть бути швидко усунуті.
3. Рутинні операції, такі як пошук за даними (форми з великою кількістю
полів для введення. Автоматизувати заповнення полів різними даними та
перевірку їх після збереження).
4. Повідомлення валідації (автоматизувати заповнення полів невірними
даними та перевірку появи тієї чи іншої валідації).
5. Довгі End-to-End сценарії.
6. Перевірка даних, які вимагають складних математичних розрахунків.
7. Перевірити правильність пошуку даних.
При тестуванні не варто впадати у крайності. Наприклад, не можна
сказати, що 100 % Web-додатку має бути покрито автотестами. Автоматизовані
тести повинні насамперед підвищувати якість коду, а також перевіряти роботу
найкритичніших функціональних можливостей. Для їх написання, налагодження
та обслуговування потрібно досить багато часу. Якщо ці витрати перевищують
вигоди, які вони приносять, вони можуть не знадобитися.
Наприклад, при розробці невеликого Web-сайту, який згодом не потрібно
буде підтримувати, простіше перевірити його вручну, аніж витрачати час на
написання автоматичних скриптів.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 61

З іншого боку, якщо над складним Web-додатком працює велика команда,
то автотести необхідні, інакше більшість часу буде витрачено на пошук через
ручне (функціональне) тестування та виправлення порушеного функціоналу. На
жаль, автоматизоване тестування не скрізь реалізовано для розробки складного
функціоналу. Десь програма тестується людьми. Не можна ігнорувати людський
фактор. Люди можуть бути втомленими, лінивими або неуважними, у той час як
“машина” готова виконувати одну і ту ж послідовність дій щодня.
Важливо пам’ятати:
1. Автотести мають бути повторюваними. Не можна отримати вихідні
дані за допомогою генератора випадкових чисел, тому що в цьому випадку не
буде змоги повторити тест.
2. Автотести повинні виконуватись у контрольованому середовищі.
3. Автотест не повинен використовувати той же алгоритм, що і
тестований код (функціонал), оскільки в цьому випадку в них може бути
допущена та сама помилка. В цьому випадку помилкові результати будуть
співпадати.
4. Необхідно протестувати позитивні та негативні сценарії. Наприклад,
при тестуванні реєстраційної форми потрібно перевірити не тільки те, як вона
працює при введенні правильних даних, але і те, як вона працює з неправильними
даними. Якщо сценарій негативний, з’явиться повідомлення про помилку.
5. При виконанні автотестів необхідно відстежувати виникаючі помилки.
Якщо при виникненні помилки просто виводиться повідомлення про те, що
автотест не обробляється, а програма продовжує працювати, це марний тест.
6. Автотести повинні бути простими у запуску, в кращому випадку за
допомогою однієї команди. Якщо потрібно виконати багато дій, щоб запустити
його, то людям буде лінь це робити. Компанії зазвичай настроюють CI-
сервер (Continuous Integration, неперервна інтеграція окремих частин коду
додатка між собою), який отримує оновлення з репозиторію, запускає тести й
відправляє повідомлення про помилки розробникам.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 62

4.2 Створення сценаріїв автоматизованого тестування Web-додатків
Практична частина роботи полягає не тільки у написанні тестових
сценаріїв та завдань вручну, але й у вивченні основ автоматизованого тестування
та засобів, що використовуються для створення, налагодження, виконання та
аналізу результатів тестових сценаріїв, а також безпосередньо у написанні
автотестів для вже існуючого ПЗ.
Мова програмування Java використовувалася для написання
автоматизованих тестових сценаріїв Java. Перш ніж писати автоматичні скрипти,
необхідно ознайомитись із шаблоном PageObject і мовою сценаріїв Gherkin.
PageObject – це шаблон проектування, який відокремлює логіку високого
рівня від логіки низького рівня для пошуку та використання елементів
інтерфейсу, одночасно покращуючи читабельність та підтримку коду. Це
приводить до створення окремого класу, який визначає конкретну сторінку з її
Web-елементами, а також способи взаємодії з ними. Структура цього шаблону
проектування наведена на рис. 4.1.

Рисунок 4.1 – Структура шаблону PageObject
Gherkin створений редагування прецедентів як наратив, тобто майже
людською мовою в простій, стислій формі і у доступному форматі. Приклад
Gherkin сценарію показаний на рис. 4.2.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 63

Рисунок 4.2 – Приклад сценарію Gherkin
Проаналізуємо засоби, що використовуються на практиці для написання
тестових скриптів.
Будь-який розвиток потребує особливого середовища. Для цього
застосовується інтегроване середовище розробки IDE (Integrated Development
Environment), що являє собою набір програмних засобів, які використовуються
програмістами для розробки ПЗ і для автоматизації тестування.
Середовище розробки включає:
1. Текстовий редактор.
2. Компілятор чи інтерпретатор.
3. Інструменти автоматизації зборки.
4. Відладчик.
У світі існує велика кількість IDE від різних відомих компаній. Вивчаючи
досвід колег та особливості мови програмування Java для написання автотестів,
обрано середовище розробки IntelliJ IDEA.
IntelliJ IDEA має широкий спектр інтегрованих інструментів
рефакторингу, які дозволяють програмістам та спеціалістам з автоматизованого
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 64

тестування швидко трансформувати вихідний код програм. Дизайн
інтегрованого середовища розробки орієнтований на продуктивність, що
дозволяє зосередитися на функціональних завданнях, у той час як IntelliJ IDEA
дбає про рутинні операції. Крім того, середовище добре сумісне з багатьма
популярними безкоштовними інструментами розробника, такими як CVS,
Subversion, Apache Ant, Maven та JUnit.
Середовище доступне у двох версіях: Community Edition та Ultimate
Edition. Community Edition – це повністю безкоштовна версія, доступна під
ліцензією Apache 2.0 та забезпечує повну підтримку Java SE, Groovy, і Scala, а
також інтеграцію з найпопулярнішими системами контролю версій. Ultimate
Edition – доступна за комерційною ліцензією, забезпечує підтримку Java EE,
UML діаграм, розрахунку покриття коду та підтримку інших систем управління
версіями, мов та фреймворків [27].
Інтерфейс IntelliJ IDEA відображено на рис. 4.3.

Рисунок 4.3 – Інтерфейс IntelliJ IDEA з темною темою
Крім IDE, системи контролю версій використовуються в сучасній розробці,
а також при написанні автоматизованих скриптів.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 65

Version Control System – ПЗ для полегшення роботи з інформацією, що
змінюється. Система контролю версій дозволяє зберігати кілька версій одного й
того ж документа, за необхідності повертатися до ранніх версій та визначати, хто
і коли вніс ті чи інші зміни.
Ці системи найбільш широко використовуються при розробці ПЗ для
зберігання вихідних кодів програми, що розробляється. Однак вони можуть бути
успішно застосовані і у інших областях, де обробляється велика кількість
електронних документів, що постійно змінюються. Зокрема, системи контролю
версій використовуються в САПР, як правило, як частина систем управління
даними продукту PDM (Product Data Management). Керування версіями
використовується в програмі Configuration, засобами управління конфігурацією
виступає ПЗ Tools.
Git – є однією з найпопулярніших систем контролю версій. Програма
вільно поширюється та випускається за ліцензією GNU GPLv 2. Система
спроектована як набір програм, спеціально призначених для використання у
сценаріях. Це ПЗ дозволяє зручно створювати спеціалізовані системи контролю
версій на основі Git або інтерфейсів користувача. Git підтримує швидкий поділ і
злиття версій й включає засоби для візуалізації та навігації по нелінійній історії
розробки. Git надає кожному розробнику або фахівцю з автоматизованого
тестування локальну копію всієї історії розробки, а зміни копіюються з одного
репозиторію до іншого.
Віддалений доступ до репозиторію Git забезпечується Git- daemon, SSH-
або HTTP-сервером. TCP-сервіс Git-daemon входить до дистрибутиву Git і є
поряд з SSH найбільш поширеним та надійним методом доступу. Метод HTTP-
доступу, незважаючи на ряд обмежень, дуже популярний у контрольованих
мережах, оскільки дозволяє використовувати наявні конфігурації мережевих
фільтрів. Приклад візуалізації Git гілок показано на рис. 4.4.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 66

Рисунок 4.4 – Візуалізація злиття версій у основну гілку версій
Основним репозиторієм системи є GitHub. Git та GitHub використовуються
більш ніж 1,8 млн. підприємств та організацій. Серед них найвідоміші: IBM,
Google, PayPal, Facebook, Spotify, Bloomberg та інші компанії з різних соціальних
сфер.
Щоб вирішити проблему зі швидкістю завантаження проектів, вирішено
використовувати the Apache Maven Framework Apache Software Foundation для
побудови проектів Maven. Ця платформа фреймворку Project Build Automation
Framework заснована на описі структури у файлах мовою POM (Project Object
Model), яка є підмножиною XML. Прості проекти можуть бути побудовані у
командному рядку. При створенні великих проектів з командного рядка, команда
build буде дуже довгою, тому іноді її пишуть у скрипті bat або bash. Але такі
скрипти залежать від конкретної платформи.
Для того, щоб позбавитися цієї залежності та спростити написання
скрипта, слід використовувати засоби для побудови проекту. Приклад інтеграції
Maven до IntelliJ IDEA наведений на рис. 4.5.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 67

Рисунок 4.5 – Інтеграція Maven в IntelliJ IDEA
Переходячи безпосередньо до автоматизованого тестування, бібліотека
JUnit є незамінним компонентом модульного тестування програми. Тип тесту
допомагає тестувати окремі розділи коду, такі як методи чи класи. Досвід,
отриманий в результаті роботи з JUnit, важливий для розробки концепцій
тестування ПЗ.
JUnit дозволяє швидко перевірити правильність роботи коду у будь-який
час. Якщо програма не дуже проста й включає множину класів і методів, то її
тестування може зайняти значну кількість часу. Звичайно, цей процес краще
автоматизувати. Використання JUnit дозволяє перевірити кеш програми без
значних зусиль та не займає багато часу.
Модульні тести класів і функцій – це своєрідна документація про те, що
очікується в результаті їх виконання. І не просто документація, а документація,
яка може автоматично перевіряти код на відповідність представленим функціям.
Це зручно і часто тести розробляються як разом, так і до реалізації класів.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 68

Тестова розробка – надзвичайно популярна технологія створення серйозного ПЗ.
Приклад використовуваного JUnit представлений тегом @Test на рис. 4.6.

Рисунок 4.6 – Модульний тест методу, який знаходить число Фібоначчі
Для тестування Web-додатків та емуляції навичок в браузері обраний
популярний засіб Selenium, а саме Selenium WebDriver. За призначенням
Selenium WebDriver використовується як драйвер браузера, тобто бібліотека ПЗ,
яка дозволяє розробляти програми, що управляють поведінкою браузера [26].
Найбільш популярною сферою застосування Selenium є автоматизація
тестування Web-додатків. Однак, використовуючи Selenium, є можливість і нею
варто скористатись для автоматизації будь-яких інших рутинних дій, що
виконуються через браузер.
Розробка Selenium підтримується виробниками популярних браузерів:
Chrome, Opera, Safari, Mozilla та Internet Explorer. Постачальники браузерів
адаптують їх для більш тісної інтеграції з Selenium, а іноді навіть впроваджують
вбудовану підтримку Selenium у сам браузер. Selenium – є центральним
компонентом низки інших інструментів автоматизації та фреймворків.
Selenium підтримує настільні та мобільні браузери. Selenium дозволяє
розробляти сценарії автоматизації практично будь-якою мовою програмування.
За допомогою Selenium можна організовувати розподілені стенди, що
складаються з сотень машин з різними операційними системами та браузерами,
і навіть запускати скрипти у хмарі. Приклад використання Selenium WebDriver
представлено на рис. 4.7.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 69

Рисунок 4.7 – Пошук компанії та виведення результатів в консоль
Пошук елементів на Web-сторінці здійснюється за допомогою спеціальних
пошукових локаторів, описаних у першому розділі роботи. Знайти ці локатори
для конкретного Web-елемента нескладно. Сучасні браузери, такі як Google
Chrome і Mozilla Firefox мають вбудовані засоби, які дозволяють Web-
розробникам відслідковувати помилки. Ці інструменти показують HTML, CSS
та JavaScript-код сторінки, а також те, як браузер працює з цим кодом.
Приклад роботи вбудованого інструменту розробника у браузері Chrome
відображено на рис. 4.8.

Рисунок 4.8 – Вбудовані засоби розробника в Chrome
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 70

Пошук локатора елементів здійснюється безпосередньо у дереві DOM.
Приклад копіювання локатора XPath показано на рис. 4.9.

Рисунок 4.9 – Копіювання елемента XPath element рядка пошуку
На додаток до Selenium WebDriver, існують інші засоби, такі як Selenium
Grid та Selenium Server.
Selenium Server – це сервер, який дозволяє керувати браузером віддаленого
комп’ютера. Для цього на машині, де повинен працювати браузер,
встановлюється та запускається сервер. Потім на іншій машині запускається
програма, яка за допомогою спеціального драйвера RemoteWebDriver
підключається до сервера і відправляє на нього команди. Він, у свою чергу,
запускає браузер й виконує в ньому ці команди, використовуючи драйвер, що
відповідає цьому браузеру.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 71

Схематичне уявлення про те, як працює Selenium Server,
наведено на рис. 4.10.

Рисунок 4.10 – Схематичне уявлення роботи сервера Selenium
Selenium Grid – це кластер, що складається з декількох Selenium Server. Він
призначений для організації розподіленої мережі, що дозволяє паралельно
запускати багато браузерів на великій кількості машин.
Selenium Grid має “зоряну” топологію, тобто складається з виділеного
сервера, який називається “концентратором” або “коммутатором”, а інші сервери
називаються “вузлами”. Мережа може бути гетерогенною. Це означає, що
комутатор і вузли можуть працювати під управлінням різних операційних систем
мати різні браузери, встановлені на них. Одним із завдань Selenium Grid є вибір
відповідного вузла, коли при запуску браузера задаються вимоги до нього – тип
браузера, версія, операційна система, архітектура процесора та ряд інших
атрибутів.
Раніше Selenium Grid була самостійним продуктом. В даний час існує
тільки один фізичний продукт – Selenium Server, але має декілька режимів
запуску: може працювати як незалежний сервер, як комутатор кластера чи як
вузол кластера, що визначається параметрами запуску.
Всі розглянуті підходи та засоби, які можуть бути використані для
проведення автоматизованого тестування, ідеально підходили для виконання
завдань, поставлених в кваліфікаційній роботі.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 72

4.3 Аналіз результатів випробувань
Збої, виявлені в ході тестування, найчастіше викликані дефектами та
помилками, присутніми в програмній тестованій системі. Вони можуть бути
наслідком поведінки операційного чи тестового середовища. Такі дефекти
можуть і найчастіше повинні бути проаналізовані, щоб визначити, коли і де цей
дефект вперше з’явився в системі, які типи помилок спричинили ці дефекти і
коли вони були вперше виявлені. Наприклад, це можуть бути погано
сформульовані вимоги, неправильний дизайн, витік пам’яті тощо. Вся ця
інформація використовується для визначення того, як можна поліпшити процес
тестування і наскільки важливі такі поліпшення.
Оцінка результатів тестування ґрунтується на зборі статистики за
конкретними показниками. Вибір метрик проводиться після визначення цілей
проекту по відношенню до очікувань від тестування та виявлення основної
проблеми проекту на даний момент. Безперечно, очікування формуються
кожним учасником циклу розробки: керівником проекту, розробниками,
аналітиками, спеціалістами підтримки.
Наприклад, якщо є скарги на відсутні дефекти, потрібно записати їх, щоб
проаналізувати причини відсутніх дефектів. Припустимо, після пари ітерацій
стає ясно, що причина у недостатньому охопленні функціоналу тестами.
У цьому випадку потрібно розпочати записувати відсоток
функціонального покриття тестами. Якщо виявиться, що наявних тестів
недостатньо, то потрібно з’ясувати, чому це сталося. Причини можуть бути
різними: від недбалості фахівців із тестування до того, що терміни підготовки та
тестування занадто короткі, й фахівці не встигають писати тести в обсязі,
необхідному для повного охоплення. Оцінка часових меж може бути
адекватною, але передача версії для тестування відбувається пізніше
запланованої дати, і дата випуску не може бути перенесена. Цілком можливо, що
розробники не встигають – їхній кошторис на розробку завжди на 2-3 дні
менший від фактичного часу на реалізацію. Можливо, менеджер дає
Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 73

розробникам незаплановані завдання у середині ітерації. Він робить це тому, що
цього вимагає клієнт – він не бачить різниці, наприклад, між розробкою сайту
каталогу та сайту магазину.
Звичайно, вирішення цієї проблеми не ляже на плечі відділу тестування,
але керівнику проекту буде набагато простіше пояснити клієнту важливість
стабілізації версійних завдань, маючи гарні таблиці, статистику та графіки
впливу незапланованих завдань на якість продукту на виході. У цьому випадку
замовник і менеджер можуть дійти рішення: або варто розробляти продукт
ітеративно, намагаючись вкластися у встановлені терміни й тоді доведеться
модерувати побажання замовника, або будь-яка зміна складу версії
супроводжуватиметься переоцінкою та перенесенням дати релізу.
Найважливіше правило для впровадження поліпшень спочатку
сформулювати мету і виявити проблеми в її досягненні, а потім вирішити, що
необхідно виміряти для оцінки змін. І, звичайно ж, без єдності всіх членів
команди та без загальної зацікавленості в успіху проекту збір метрик буде
марний – зібрані результати не будуть оцінюватися для того, щоб
використовувати їх надалі.
Проаналізуємо переваги та недоліки автоматизованого тестування
порівняно з ручним (функціональним) тестуванням:
1. Швидкість виконання тестових випадків може бути в кілька разів і на
порядки вищі за людські можливості. Якщо уявити, що людині доведеться
вручну порівнювати кілька файлів розміром кілька десятків мегабайт кожен, то
оцінка часу ручного виконання стає лякаючим: місяці чи навіть роки. При цьому
36 тестів, реалізованих у рамках Smoke Testing з використанням командних
скриптів, виконуються менш ніж за п’ять секунд і вимагають від фахівця з
автоматизованого тестування лише однієї дії – запуску скрипту.
2. Відсутній вплив людського фактору в процесі виконання тестових
завдань (втома, неуважність та ін.). Оцініть ймовірність того, що людина
помилиться при порівнянні двох звичайних текстів по 100 сторінок, кожен
Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 74

ієрогліф за ієрогліфом або якщо таких текстів, наприклад, буде 20. Можна
сміливо сказати, що людина гарантовано припуститься помилки. Автоматика не
помилиться.
3. Засоби автоматизації здатні виконувати тестові випадки, які в принципі
неможливі для людини через їхню складність, швидкість або інші фактори.
4. Системи автоматизації здатні збирати, зберігати, аналізувати,
агрегувати і представляти величезні обсяги даних у зручній для сприйняття
людиною формі. Журнали автоматизованих систем тестування можуть займати
десятки гігабайт за ітерацію. Логічно, що людина не здатна вручну
проаналізувати такі обсяги даних, але правильно налаштоване середовище
автоматизації зробить це саме, надавши точні звіти обсягом 2-3 сторінки, зручні
графіки та таблиці, а також можливість занурення в деталі, при необхідності
переходячи від агрегованих даних до деталей.
5. Засоби автоматизації можуть виконувати низькорівневі дії з додатком,
операційною системою, каналами передачі і т.д.
Завдання збору інформації про ресурси, що використовуються програмою,
є класичним прикладом. Однак засоби автоматизації можуть не тільки збирати
таку інформацію, але й впливати на середовище виконання програми або саму
програму, емулюючи типові події (наприклад, брак оперативної пам’яті або
процесорного часу) й записуючи відповідь програми [10].
Таким чином, з використанням автоматизації з’являється можливість
збільшити охоплення тестуванням за рахунок:
1. Запуску тестових прикладів, про які не слід думати.
2. Багаторазове повторення тестових випадків із різними вхідними
даними.
3. Вивільнення часу створення нових тестових прикладів.
Проте впровадження автоматизованого тестування також пов’язане з
низкою серйозних недоліків та ризиків:
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 75

1. Потреба у висококваліфікованих кадрах обумовлена тим, що
автоматизація – це проект зі своїми вимогами, планами, кодом тощо. Технічна
кваліфікація працівників, які займаються автоматизацією, як правило, має бути
значно вищою, ніж у їхніх колег, що займаються ручним (функціональним)
тестуванням.
2. Розробка та супровід як самих автоматизованих тестових кейсів, так і
всієї необхідної інфраструктури займає дуже багато часу. Ситуація посилюється
тим, що в деяких випадках (при серйозних змінах у проекті, або, у разі помилки
в стратегії) розробка повинна бути перезапущена з нуля: у разі суттєвих змін
вимог, зміни технологічних доменів, переробки інтерфейсів (як користувачів, так
і ПЗ) багато тестових випадків застарівають і вимагають створення знову.
3. Автоматизація вимагає більш ретельного планування та управління
ризиками, тому що в іншому випадку проект може бути серйозно пошкоджений.
4. Засоби комерційної автоматизації значно дорожчі, а наявні
безкоштовні аналоги не завжди дозволяють ефективно вирішувати поставлені
завдання. І тут знову необхідно повернутися до питання помилок планування:
якщо початковий набір технологій та засобів автоматизації був обраний
неправильно, доведеться не тільки переробляти всю роботу, але й купувати нові
засоби автоматизації.
5. Існує множина засобів автоматизації, що ускладнює проблему вибору
того чи іншого інструменту, ускладнює планування та визначення стратегії
тестування, а також може спричинити додаткові тимчасові та фінансові витрати,
а також необхідність навчання персоналу або найму відповідних фахівців.
Автоматизоване тестування вимагає великих інвестицій й може значно
збільшити ризики проекту, тому існують спеціальні підходи до оцінки
ефективності та застосовності автоматизованого тестування до проекту. Якщо
висловити всю їх суть дуже коротко, то насамперед слід взяти до уваги:
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 76

1. Час, що витрачається на виконання тестових випадків вручну та
виконання тих самих перевірок, тільки вже автоматизованих. Чим більша
різниця, тим вигідніша автоматизація.
2. Кількість повторень виконання тих самих тестових завдань. Що більше
повторень, то більше ресурсів можна заощадити за допомогою засобів
автоматизації.
3. Час, що витрачається на оновлення, налагодження та підтримку
автоматизованих сценаріїв. Цей параметр є найскладнішим для оцінки. Він може
становити найбільшу загрозу для успіху автоматизації. Тому до оцінки мають
бути залучені найдосвідченіші фахівці.
4. Наявність відповідних фахівців у команді та їхнє робоче навантаження.
Автоматизовані сценарії зазвичай пишуться більш кваліфікованими
співробітниками, які можуть одночасно вирішувати інші завдання.
Слід розуміти, що позитивний ефект від автоматизації не завжди настає
відразу. Автоматизація, як і будь-який дорогий засіб, може принести відчутну
користь при правильному використанні, але при неправильному використанні
вона принесе лише великі витрати.
Розглянуто сутність автоматизованого тестування та визначено основні
поняття. Описані підходи до написання автоматизованих тестових сценаріїв і
розглянуті інструменти, використовувані для вирішення практичних завдань у
компанії.
Оцінка результатів тестування ґрунтується на очікуваних результатах
роботи системи та збору статистики за виявленими помилками. На середовище
програмного продукту не повинні впливати блокування та критичні помилки в
системі, інакше компанії ризикують втратити клієнтів і прибуток. Доцільність
використання автоматизованого тестування оцінюється заздалегідь, оскільки у
деяких випадках ефект від функціонального (ручного) тестування може бути
вищим.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 77

ВИСНОВКИ
Сьогодні Web-додатки продовжують розвиватися, і кількість
використовуваних технологій, а також різноманітність дефектів тільки
збільшуються.
Результатом даної кваліфікаційної роботи бакалавра є аналіз сучасних
методів та засобів тестування Web-додатків, застосування яких дозволить
забезпечити підвищення якості програмного продукту й усунення помилок у коді
Web-програми для фронт-офісної системи підприємства завдяки створенню
наборів тестових випадків та розробці сценаріїв автоматизованого тестування
Web-додатків.
У результаті роботи були виконані наступні завдання:
− проаналізовано предметну область та визначені основні тенеденції
розвитку методів та засобів тестування Web-додатків.
− визначено сутність Web-додатків та їх особливості, досліджено основи
взаємодії клієнтської та серверної частин Web-додатків, структуру Web-
сторінок, параметри пошуку Web-елементів;
− проведено аналіз сучасних методів та засобів тестування Web-додатків
у життєвому циклі розробки ПЗ та визначено їх переваги та недоліки;
− визначено сутніть функціонального тестування;
− проведено якісну оцінку засобів автоматизованого тестування Web-
додатків за такими параметрами як ремонтопридатність, виконання та
використання в системах безперервної інтеграції та надані рекомендації по їх
використанню;
− створені набори тестових випадків для Web-додатків;
− розроблено автоматизовані Web-сценарії тестування Web-додатків.
Крім того, було встановлено, що функціональне (ручне) тестування
вигідніше використовувати при розробці нового бізнес-процесу, а
автоматизоване рішення доцільніше використовувати для перевірки існуючого
функціоналу.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 78

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

Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 79

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
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 с.
Арк.
ЧДТУ.222055.001 ПЗ

Змн. Арк. № докум. Підпис Дата 80

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 с.

Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 81

13. Лановий О. Ф. Про один підхід до функціонального тестування Web-

додатків / О. Ф. Лановий // Полиграфические, мультимедийные и Web-

технологии : тез. докл. 2-й Международ. науч.-техн. конф., 16-22 мая 2017 г.
Харьков : ХНУРЭ, 2017. Т. 1. С. 135.

14. Ляшко С. Ю. Автоматизоване тестування веб-додатків : робота на

здобуття кваліфікаційного ступеня магістра; спец.: 051 – економіка

/ С. Ю. Ляшко ; наук. керівник К. Г. Гриценко. Суми: Сумський державний

університет, 2019. 61 с.

15. Піддубняк П. В. Дослідження систем автоматизованого тестування

безпеки Web-додатків : дипломна робота на здобуття кваліфікаційного ступеня

магістра; спец. 123 – комп’ютерна інженерія / П. В. Піддубняк ; наук. керівник

І. В. Жуковицький ; Укр. держ. ун-т науки і техногогій. Дніпро, 2021. 88 с.

16. Плющ Л. В. Система автоматизованого тестування програмного

забезпечення : дипломний проект бакалавра : 6.050201 Системна інженерія

/ Л. В. Плющ. Київ, 2019. 70 с.

17. Попович Х. Розробка стратегії тестування для Web-додатків
/ Х. Попович // «Природничі та гуманітарні науки. Актуальні питання» : зб. тез

Ⅷ Всеукраїнської студентської науково-технічної конференції. 2015. Т. 1.

С. 40.

18. Сучасні технології тестування і захисту веб-сторінок / М. І. Цюцюра,
О. В. Криворучко, Т. О. Жирова, Н. О. Котенко // Управління

розвитком складних систем. 2019. Вип. 39. С. 100-105. Режим

доступу : http://nbuv.gov.ua/UJRN/Urss_2019_39_17

Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 82

19. Шульга Є. К. Система автоматичного тестування Web-застосунків:

клієнтська частина : робота на здобуття ступеня бакалавра за освітньо-

професійною програмою “Комп’ютерні системи та мережі” спеціальності 123
“Комп’ютерна інженерія” / Є. К. Шульга ; наук. керівник О. І. Алєнін. Київ :

Національний технічний університет України “КПІ імені Ігоря Сікорського”,

2021. 57 с.

20. 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.

21. 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

22. 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.

23. Selenium with Java : Getting Started to Run Automated Tests [Електронний

ресурс]. Режим доступу: https://www.browserstack.com/guide/selenium-with-java-
for-automated-test

24. Welcome to Apache Maven [Електронний ресурс]. Режим доступу:

https://maven.apache.org/

25. 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.

Арк.
ЧДТУ.222055.001 ПЗ
Змн. Арк. № докум. Підпис Дата 83

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets