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
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9108| Title: | Фреймворк для автоматизації тестування WEB-сайту |
| Authors: | Заспа, Григорій Олександрович Кисліченко, Яна Віталіївна |
| Issue Date: | 16-Dec-2023 |
| Abstract: | АНОТАЦІЯ
Кисліченко Я.В., кваліфікаційна робота магістра на тему: “Фреймворк для
автоматизації тестування WEB-сайту”. Напрям підготовки 121 “Інженерія
програмного забезпечення”, ЧДТУ, Черкаси 2023.
В даній кваліфікаційній роботі магістра проводиться д0ослідженню та
аналізу фреймворків для автоматизації тестування веб-сайтів. Робота охоплює
обгрунтування важливості автоматизації в тестуванні, літературний огляд
сучасних фреймворків, порівняльний аналіз їхніх можливостей та
ефективності. Детально розглянуто використання обраного фреймворку на
практиці, є приклади впровадження та обгрунтування доцільності вибору
даного інструменту. Робота магістра спрямована на виявлення оптимальних
рішень у сфері автоматизації тестування веб-сайту.
Обсяг сторінки – 88 сторінки, вона містить 4 розділи, 22 ілюстрацій, 22
джерел в переліку посилань, 4 додатки.
Використані програмні засоби – Visual Studio, Draw.lo, Selenium IDA. ABSTRACT Ya.V. Kyslichenko, master's qualification thesis on the topic: "Framework for automation of WEB-site testing". Field of training 121 "Software engineering", ChSTU, Cherkasy 2023. In this Master's thesis, research and analysis of frameworks for automating website testing is carried out. The work covers the justification of the importance of automation in testing, a literature review of modern frameworks, a comparative analysis of their capabilities and effectiveness. The use of the selected framework in practice is considered in detail, there are examples of implementation and justification of the expediency of choosing this tool. The master's work is aimed at identifying optimal solutions in the field of automation of website testing. The volume of the page is 72 pages, it contains 4 chapters, 00 illustrations, 22 sources in the list of references, 4 appendices. The software tools used are Visual Studio, Draw.lo, Selenium IDA. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9108 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра-Кисліченко Яна Віталіївна.pdf Restricted Access | 2.7 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень
на тему: Фреймворк для автоматизації тестування WEB-сайту
Виконав: студент 2 курсу, групи МПЗ-2204
Напряму підготовки
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Кисліченко Я.В.
(прізвище та ініціали)
Керівник Заспа Г.О.
(прізвище та ініціали)
Рецензент Тулуб В.О.
Черкаси 2023
Черкаський державний технологічний університет
(повне найменування вищого навчального закладу)
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
________________ Голуб С.М.
«___» ____________ 2023 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Кисліченко Яна Віталіївна
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи): Фреймворк для автоматизації тестування WEB-сайту
Керівник проекту (роботи): Заспа Григорій Олександрович, доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «06» жовтня
2023 року №267/04
2. Строк подання студентом проекту (роботи): 15 грудня 2023 року
3. Вхідні дані до проекту (роботи): стандарти програмного забезпечення; моделювання
системи; вимоги до проект;
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити):
Вступ;
Існуючі методи і засоби розв’язання поставлених задач;
Теоретичні та експериментальні дослідження;
Проектування програмного комплексу;
Розробка та тестування програмного комплексу;
Висновки;
Список використаних джерел;
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):
слайд 1, слайд 2, слайд3, слайд 4, слайд 5, слайд 6, слайд 8, слайд 9, слайд11, слайд 12.__ ___ _
6. Консультанти розділів проекту (роботи):
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання: 04 вересня 2023 року
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п
випускної
роботи
1 Постановка задачі 06.09.2023 виконано
2 Підготовка завдання 13.09.2023 виконано
3 Погодження завдання 20.09.2023 виконано
4 Затвердження завдання 27.09.2023 виконано
Основна стадія
1 Підбір матеріалів 04.10.2023 виконано
2 Аналіз шляхів вирішення поставленої задачі 11.10.2023 виконано
3 Розрахунок основних параметрів роботи 18.10.2023 виконано
4 Вибір кінцевого варіанту проектного рішення 25.10.2023 виконано
5 Оформлення первісної редакції роботи 01.11.2023 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з керівником 08.11.2023 виконано
2 Оформлення пояснювальної записки роботи в кінцевій редакції 15.11.2023 виконано
3 Попередній захист роботи 22.11.2023 виконано
4 Затвердження роботи 29.11.2023 виконано
5 Рецензування роботи 06.12.2023 виконано
6 Захист роботи 15.12.2023 виконано
Студент: Кисліченко Я.В,
(підпис) (прізвище та ініціали)
Керівник проекту (роботи): Заспа Г.О.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Кисліченко Я.В., кваліфікаційна робота магістра на тему: “Фреймворк для
автоматизації тестування WEB-сайту”. Напрям підготовки 121 “Інженерія
програмного забезпечення”, ЧДТУ, Черкаси 2023.
В даній кваліфікаційній роботі магістра проводиться д0ослідженню та
аналізу фреймворків для автоматизації тестування веб-сайтів. Робота охоплює
обгрунтування важливості автоматизації в тестуванні, літературний огляд
сучасних фреймворків, порівняльний аналіз їхніх можливостей та
ефективності. Детально розглянуто використання обраного фреймворку на
практиці, є приклади впровадження та обгрунтування доцільності вибору
даного інструменту. Робота магістра спрямована на виявлення оптимальних
рішень у сфері автоматизації тестування веб-сайту.
Обсяг сторінки – 88 сторінки, вона містить 4 розділи, 22 ілюстрацій, 22
джерел в переліку посилань, 4 додатки.
Використані програмні засоби – Visual Studio, Draw.lo, Selenium IDA.
ЧДТУ 232208.011 ПЗ
ABSTRACT
Ya.V. Kyslichenko, master's qualification thesis on the topic: "Framework for
automation of WEB-site testing". Field of training 121 "Software engineering",
ChSTU, Cherkasy 2023.
In this Master's thesis, research and analysis of frameworks for automating
website testing is carried out. The work covers the justification of the importance of
automation in testing, a literature review of modern frameworks, a comparative
analysis of their capabilities and effectiveness. The use of the selected framework in
practice is considered in detail, there are examples of implementation and
justification of the expediency of choosing this tool. The master's work is aimed at
identifying optimal solutions in the field of automation of website testing.
The volume of the page is 72 pages, it contains 4 chapters, 00 illustrations, 22
sources in the list of references, 4 appendices.
The software tools used are Visual Studio, Draw.lo, Selenium IDA.
5
ЧДТУ 232208.011 ПЗ
ЗМІСТ
ВСТУП ................................................................................................................... 11
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ .............................................................................................................. 13
1.1 Опис предметного середовища…………………………………………...13
1.1.1 Історія розвитку тестування програмного забезпечення…………13
1.1.2 Тестування програмного забезпечення та його основна мета…...14
1.1.3 Життєвий цикл тестування програмного забезпечення…………15
1.2 Рівні і види тестування…………………………………………………….16
1.2.1 Класифікація видів тестування за ознаками………………………16
1.2.2 Опис видів тестування……………………………………………..18
1.2.3 Техніка тестування………………………………………………….19
1.2.4 Особливості вимог програмного забезпечення…………………...20
1.2.5 Методи тестування………………………………………………….21
1.2.6 Класифікація тестування…………………………………………..24
1.2.7 Робота з базою даних в процесі тестування………………………27
1.3 Постановка задачі…………………………………………………………..28
Висновки до першого розділу ………………………………………………...29
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ………..31
2.1 Теоретичні дослідження……………………………………..………….31
2.2 Експериментальні дослідження…………………………….………….33
Висновки до другого розділу…………………...............................................39
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ......................................................................... 40
3.1 Моделювання предметної області.......................................................... 40
3.1.1 Предметна область моделювання. Модель предметної області
Словник предметної області .......................................................................... 41
3.1.2 Елементи моделювання предметної області ....................................... 43
3.1.3 Робоча область моделювання ............................................................... 44
3.2 Формування та аналіз вимог .................................................................. 46
6
ЧДТУ 232208.011 ПЗ
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та не
функціональні вимоги. ................................................................................... 46
3.2.2 Формування вимог за допомогою діаграми прецедентів .................. 47
3.2.3 Проектування логічної структури програмного комплексу .............. 48
3.2.3.1 Діаграма класів ................................................................................ 49
3.2.3.2 Діаграма пакетів .............................................................................. 51
3.2.4 Архітектурне проектування ................................................................. 53
3.2.4.1 Діаграма компонентів ......................................................................... 53
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ...................................................................................................... 54
3.2.5 Моделювання поведінки системи ..................................................... 55
7
ЧДТУ 232208.011 ПЗ
3.2.5.1 Діаграма діяльності ................................................................................. 55
3.2.3.2 Діаграма послідовності ................................................................... 57
3.2.5.3 Діаграма комунікації ....................................................................... 58
3.2.5.4 Діаграма скінченного автомату ..................................................... 59
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ . 62
4.1 Розробка програмного комплексу ......................................................... 62
4.1.1 Обґрунтування вибору засобів реалізації ............................................ 62
4.1.2 Опис структурної (функціональної) схеми ......................................... 63
4.1.3 Опис логічної схеми системи ................................................................ 66
4.1.4 Розробка бази даних ............................................................................... 67
4.1.5 Розробка інтерфейсу користувача ........................................................ 68
4.1.6 Опис розробки програмних компонентів ............................................ 69
4.1.6.1 Опис компонентів…………………………………………………...69
4.1.6.2 Опис методів………………………………………………………...71
4.2 Тестування системи .................................................................................. 72
4.2.1 Модульне тестування. ............................................................................ 73
4.2.2 Інтеграційне тестування ........................................................................ 74
4.2.3 Системне тестування ............................................................................. 75
4.2.4 Приймальне тестування ......................................................................... 76
4.3.Приклади впровадженого програмного комплексу........................... 77
ВИСНОВКИ ......................................................................................................... 84
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ........................................................ 85
8
ЧДТУ 232208.011 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
ПЗ програмне забезпечення
ДТ дослідницьке тестування
ТБТК тестування базованого на тест-кейсах
UML уніфікована мова моделювання (unifeid modelling languege)
UI інтерфейс користувача (user interface)
9
ЧДТУ 232208.011 ПЗ
ВСТУП
Актуальність теми. У сучасному світі, де розвиток технологій набуває
нестримного темпу, актуальність розробки фреймворку для автоматизації
тестування web-сайтів визначається зростаючою потребою бізнесів у швидкому та
ефективному виявленні помилок, забезпеченні високої якості продукту та
оптимізації витрат часу та ресурсів на тестування.
Мета і завдання досліджень. Метою даної роботи є удосконалення методу
тестування базованого на тест-кейсах шляхом вибору найкращого способу
виявлення для певного типу помилок і, на основі цього, розробка фреймворку для
автоматизації тестування web-сайтів.
Завдання включають в себе: вивчення підходів до автоматизації тестування;
удосконалення методу тестування базованого на тест-кейсах; проектування та
розробку фреймворку для автоматизації тестування web-сайтів; апробацію
розробленого фреймворку на реальному web-сервісі.
Об’єкт дослідження. Об’єктом є процес автоматизованого тестування web-
сайтів.
Предмет дослідження. Предмет - процес оцінки ефективності виявлення
помилок кодування при автоматизації тестування web-сайтів.
Методи досліджень. Для досягнення поставлених мети і завдань
використовувалися методи емпіричного аналізу, моделювання, системного
підходу, дослідницького експерименту.
Наукова новизна отриманих результатів. Удосконалено метод
тестування базованого на тест-кейсах шляхом вибору найкращого способу
виявлення для певного типу помилок, що дає можливість зменшити витрати на
тестування web-сайтів зі збереженням його якості.
Практичне значення отриманих результатів. На основі удосконаленого
методу тестування базованого на тест-кейсах розроблено фреймворк для
автоматизації тестування web-сайтів, який враховує сучасні патерни
програмування та забезпечує ефективне виявлення помилок у роботі веб-сервісів.
Розроблений фреймворк може бути використаний розробниками та
10
ЧДТУ 232208.011 ПЗ
тестувальниками для автоматизованого тестування web-сайтів, що сприятиме
підвищенню якості продукту та ефективності розробки.
Особистий внесок автора. Усі наукові результати, описані в даній роботі.
Одержані здобувачем особисто.
11
ЧДТУ 232208.011 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Опис предметного середовища
1.1.1 Історія розвитку тестування програмного забезпечення
Тестування програмного забезпечення — техніка контролю якості, що
перевіряє відповідність між реальною і очікуваною поведінкою програми
завдякикінцевому набору тестів, які обираються певним чином.
Якість не є абсолютною, це суб'єктивне поняття. Тому тестування, як процес
своєчасного виявлення помилок та дефектів, не може повністю забезпечити
коректність програмного забезпечення. Воно тільки порівнює стан іповедінку
продукту зі специфікацією. При цьому треба розрізняти тестуванняпрограмного
забезпечення й забезпечення якості програмного забезпечення, доякого належать
всі складові ділового процесу, а не тільки тестування.
У 1960-х багато уваги приділялося «вичерпному» тестуванню, яке
повиннопроводитися з використанням усіх шляхів у коді або всіх можливих
вхіднихданих. Було відзначено, що в цих умовах повне тестування ПЗ неможливе,
томущо, по-перше, кількість можливих вхідних даних дуже велика, по-друге,
існує безліч шляхів, по-третє, складно знайти проблеми в архітектурі та
специфікаціях. З цих причин «вичерпне» тестування було відхилено й визнано
теоретичнонеможливим [1].
На початку 1970-х тестування ПЗ розглядалося як «процес, спрямований
надемонстрацію коректності продукту» або як «діяльність з
підтвердженняправильності роботи ПЗ». У програмній інженерії, яка в той час
зароджувалася,верифікація ПЗ визначалася як «доказ правильності». Хоча
концепція булатеоретично перспективною, на практиці вона вимагала багато часу
й неохоплювала всі аспекти тестування. Було вирішено, що доказ правильності —
неефективний метод тестування ПЗ. Однак, у деяких випадках демонстрація
правильної роботи використовується і в наші дні, наприклад,
приймальноздавальні випробування.
12
ЧДТУ 232208.011 ПЗ
У другій половині 1970-х тестування представлялося як виконання програми
з наміром знайти помилки, а не довести, що вона працює [2]. Успішнийтест — це
тест, який виявляє раніше невідомі проблеми. Даний підхід цілкомпротилежний
попередньому.
Зазначені два визначення являють собою «парадокс тестування», в основі
якого лежать два протилежних твердження: з одного боку, тестування
дозволяєпереконатися, що продукт працює добре, а з іншого — виявляє помилки
у ПЗ, показуючи, що продукт не працює. Друга мета тестування є більш
продуктивною з точки зору поліпшення якості, оскільки не дозволяє ігнорувати
недоліки ПЗ.
У 1980-х тестування розширилося таким поняттям як запобіганням
дефектам. Проектування тестів — найбільш ефективний з відомих методів
запобігання помилок. В цей же час почали висловлюватися думки, що необхідна
методологія тестування, зокрема, що тестування повинно включати перевірки
впродовж усього циклу розроблення, при цьому це має бути керований процес. В
ході тестування треба перевірити не тільки зібрану програму, але й вимоги, код,
архітектуру, самі тести. «Традиційне» тестування, яке існувало до початку 1980-
х, відносилося тільки до скомпілювати, готової системі (зараз це зазвичай
називається системне тестування), але надалі тестувальники стали залучатися в усі
аспекти життєвого циклу розроблення [3]. Це дозволяло раніше знаходити
проблеми у вимогах та архітектурі й тим самим скорочувати терміни та бюджет
розроблення.
1.1.2 Тестування програмного забезпечення та його основна мета
У кожного фахівця і експерта у конкретній галузі своє унікальне пояснення
цього терміну. Інколи такий різний зміст вражає! Не потрібно стверджувати що це
неправильно, й так не повинно бути! Це навпаки позитивне явище, свідчення того,
що Software Testing розвивається як індустрія та наука [4]. Відбуваються поділи,
викристалізовуються течії, напрямки, їх філософія. Зокрема інакшості в
трактуванні зумовлено різними цілями, котрі переслідує тестування у тій чи іншій
компанії або організації. Нерідко пов’язується із особливостями тестування різних
13
ЧДТУ 232208.011 ПЗ
категорій продуктів (медицина, освіта, фінанси, туризм, e-commerce тощо). Всіма
застосовуються відмінні техніки, методики, практики тестування програмного
забезпечення. Оскільки у процесі тестування кожен має право вибирати, те що
йому потрібно в даний момент, для вирішення конкретної проблеми, задачі в
роботі [5].
Звідси основна мета Тестування Програмного Забезпечення, яка полягає у
намаганні виміряти рівень якості програмного забезпечення вцілому з точки зору
основних вимог —(Quality Assurance).
Тестувальники не виконують жодні дії, які безпосередньо змінюють якість.
Виконавши тест, тестувальники не впливають на базовий код, тому якість
програмного забезпечення залишається незмінною. Якість програмного продукту
може будь-яким чином змінюватися тільки подальшими діями розробників [6].
Якість продукту — це не є лише відповідальныстю тестувальників. Це
відповідальність та ціль усіх членів команди.
1.1.3 Життєвий цикл тестування програмного забезпечення
Життєвий цикл тестування програмного забезпечення) — це всі дії, що
виконуються під час тестування програмного продукту.
Життєвий цикл програмного забезпечення (SDLC – Software Development
Life Cycle) – період часу, який починається з моменту прийняття рішення про
необхідність створення програмного продукту і закінчується в момент його
повного вилучення з експлуатації. Цей цикл – процес побудови і розвитку
програмного забезпечення [7].
Етап 1 – Планування (Planning). На цій фазі клієнт пояснює основні деталі
і концепції проекту, оговорюється необхідний ресурс, час і бюджет, що
необхідний для розробки.
Етап 2 – Аналіз вимог (Requirements analysis). Ця фаза розрахована для
підготовки набору вимог. Потім йде етап узгодження вимог. Як результат ми
маємо отримати узгоджений документ з вимогами.
14
ЧДТУ 232208.011 ПЗ
Етап 3 – Дизайн і розробка (Design & Development). На цій фазі
визначаються основні концепції дизайну програмного забезпечення. Після
узгодження дизайну починається безпосередньо розроблення продукту.
Етап 4 – Впровадження (Implementation). Включає в себе програмування
і отримання кінцевого продукту (бібліотеки, білди, документація).
Етап 5 – Тестування (Testing). На цій фазі проводиться перевірка на
відповідність вимогам і підтвердження того, що продукт розроблений згідно з
ними.
Етап 6 – Оцінка (Evaluation). На фазі оцінки (або пререлізу) продукт
оцінюється замовником і вносяться останні уточнення.
Етап 7 – Реліз (Release). Заключна фаза розробки, враховуються уточнення,
що зроблені замовником на фазі оцінки. Підготовка продукту в «коробці».
Етап 8 – Підтримка (Support). Фаза технічної підтримки продукту.
Тестоване програмне забезпечення повинно проходити кожен з етапів тестування,
обумовлених продакт овнерами, менеджментом компанії розробника та тест-
дизайнерами для того, щоб вважати програмний продукт відносно якісним або
придатним до використання.
1.2 Рівні і види тестування
1.2.1 Класифікація видів тестування за ознаками
Ручне тестування (manual testing) - це процес ручної перевірки
програмного забезпечення на помилки. Тестувальник має відігравати роль
користувача програми й використовувати властивості програми для знаходження
помилок у роботі програми. Для професійного тестування тестувальник часто
користується написаним планом тестування з варіантами тестування (test cases).
Автоматизоване тестування (automated testing) - частина процесу
тестування на етапі контролю якості в процесі розробки програмного
забезпечення. Воно використовує програмні засоби для виконання тестів і
перевірки результатів виконання, що допомагає скоротити час тестування і
спростити його процес.
15
ЧДТУ 232208.011 ПЗ
Перші спроби «автоматизації» з'явилися в епоху операційних систем DOS і
CP/M. Тоді вона полягала у видачі додатком команд через командний рядок і
аналізі результатів [8]. Трохи пізніше додалися віддалені виклики через API для
роботи з мережі. Вперше про автоматизоване тестування згадується в книзі
Фредеріка Брукса «Міфічний людино-місяць», де йдеться про перспективи
використання модульного тестування. Але по-справжньому автоматизація
тестування стала розвиватися тільки в 1980-х роках.
Існує два основних підходи до автоматизації тестування: тестування на рівні
коду і GUI-тестування. До першого типу належить, зокрема, модульне тестування.
До другого — імітація дій користувача за допомогою спеціальних тестових
фреймворків. Найпоширенішою формою автоматизації є тестування додатків
через графічний інтерфейс користувача [9]. Популярність такого виду тестування
пояснюється двома факторами: по-перше, додаток тестується тим же способом,
яким його буде використовувати людина, по-друге, можна тестувати додаток, не
маючи при цьому доступу до вихідного коду.
GUI-автоматизація розвивалася протягом 4 поколінь інструментів і технік:
– утиліти запису і відтворення (capture/playback tools) — записують дії
тестувальника під час ручного тестування. Вони дозволяють виконувати
тести без прямої участі людини протягом тривалого часу, значно
збільшуючи продуктивність і усуваючи «безглузде» повторення
одноманітних дій під час ручного тестування. У той же час, будь-яка мала
зміна ПЗ, що тестується вимагає перезапису ручних тестів. Тому це
перше покоління інструментів не ефективне і не масштабоване.
– сценарії (Scripting) — форма програмування на мовах, спеціально
розроблених для автоматизації тестування ПЗ — пом'якшує багато
проблем capture/playback tools. Але розробкою займаються програмісти
високого рівня, які працюють окремо від тестувальників, що
безпосередньо запускають тести. До того ж скрипти найбільше підходять
для тестування GUI і не можуть бути впровадженими, пакетними або
взагалі будь-яким чином об'єднані в систему. Нарешті, зміни в ПЗ, яке
16
ЧДТУ 232208.011 ПЗ
тестується вимагають складних змін у відповідних скриптах, і підтримка
все більше зростаючої бібліотеки тестуючих скриптів стає зрештою
непереборним завданням.
1.2.2 Опис видів тестування
Інсталяційне тестування запевняє, що система встановлена правильно і
коректно працює на апаратному забезпеченні конкретного клієнта.
Тестування сумісності
Основною метою якого є перевірка коректної роботи продукту в певному
середовищі. Середовище може включати в себе наступні елементи:
– апаратна платформа;
– мережеві пристрої;
– периферія (принтери, CD/DVD-приводи, веб-камери та ін.);
– операційна система (Unix, Windows, MacOS, …)
– бази даних (Oracle, MS SQL, MySQL, …);
– системне програмне забезпечення (веб-сервер, фаєрвол, антивірус, …);
– браузери (Internet Explorer, Firefox, Opera, Chrome, Safari).
Смоук тестування (Smoke testing)
Мінімальний набір тестів на явні помилки. Цей тест зазвичай виконується
самим програмістом [10]. Програму, що не пройшла такий тест, не має сенсу
передавати на глибше тестування.
Регресивне тестування
Виявляє помилки у вже протестованих ділянках початкового коду. Такі
помилки — коли після внесення змін до програми перестає працювати те, що мало
б працювати, — називають регресивними помилками.
Регресивне тестування (за деякими джерелами) включає:
– new bug-fix — перевірка виправлення знайдених дефектів;
– old bug-fix — перевірка, що виявлені раніше й виправлені дефекти не
відтворюються в системі знову;
17
ЧДТУ 232208.011 ПЗ
– side-effect — перевірка того, що не порушилася працездатність
працюючої раніше функціональності, якщо її код міг бути зачеплений під
час виправлення деяких дефектів в іншій функціональності.
Функціональне тестування. Перевіряє, чи реалізовані функціональні
вимоги, тобто можливості ПЗ в певних умовах вирішувати завдання, потрібні
користувачам. Функціональні вимоги визначають, що саме робить продукт, які
завдання вирішує.
Функціональні вимоги включають в себе:
– функціональна придатність;
– точність;
– можливість до взаємодії;
– відповідність стандартам та правилам;
– захищеність.
1.2.3 Техніка тестування
Існує багато прийомів тестування ПЗ. Деякі з них перевершують інші, деякі
можна використовувати сукупно з іншими для кращих результатів. Нижче
представлений список основних прийомів тестування:
Ручне тестування – тести виконуються людьми з наперед складеними, або
визначеними для кожного випробування тестовими даними.
Автоматизоване тестування – тести виконуються спеціальними
інструментами або самостійними процесами і можуть повторюватися багато раз.
Тестові дані попередньо вводяться або генеруються.
Регресивне тестування – тести, зазвичай автоматизовані, мають на меті
виявлення негативного впливу змін в програмі на функції, що пройшли попередні
перевірки.
Димове тестування – тести, спрямовані на швидку перевірку базової
функціональності, з метою виявлення, чи новий білд (версія програми чи її
певного модуля) вартий тестування.
Дослідницьке тестування – тести, що виконуються за відсутністю
18
ЧДТУ 232208.011 ПЗ
специфікацій. Тестер розроблює власну систему тестування, яка базується на
накопиченому їм досвіді та оцінює ризики, створюючи сценарії тестування.
1.2.4 Особливості вимог програмного забезпечення
Вимоги (Requirements) до програмного забезпечення – сукупність
тверджень щодо атрибутів, властивостей, або якостей програмної системи, що
підлягає реалізації:
– одиничність – Вимога описує одну і тільки одну річ.
– завершеність – Вимога повністю визначена в одному місці і вся необхідна
інформація присутня.
– послідовність – Вимога не суперечить іншим вимогам і повністю
відповідає зовнішній документації.
– атомарність – Вимога не може бути розбита на ряд більш детальних
вимог без втрати завершеності.
– відстежування – Вимога повністю або частково відповідає діловим
потребам як заявлено зацікавленими особами і задокументовано.
– актуальність – Вимога не стала застарілою з часом.
– здійснимість – Вимога може бути реалізовано в межах проекту.
– недвозначність – Вимога коротко визначена без звернення до технічного
жаргону та інших прихованих формулювань. Вона виражає об’єктивні
факти, можлива одна і тільки одна інтерпретація. Визначення не містить
нечітких фраз. Використання негативних тверджень заборонено.
– обов’язковість – Вимога представляє певну характеристику, відсутність
якої призведе до неповноцінності рішення, яка не може бути
проігнорована.
– верифікованість – Реалізованість вимоги може бути визначена через один
з чотирьох можливих методів: огляд, демонстрація, тест чи аналіз.
Методи тетування:
Білий ящик (WhiteBox) – цей метод заснований на тому, що розробник
тесту має доступ до коду програм і може писати код, який пов’язаний з
бібліотеками ПЗ, що тестується [11].
19
ЧДТУ 232208.011 ПЗ
Чорний ящик (Black Box) – цей метод заснований на тому, що
тестувальник має доступ до ПЗ тільки через ті ж інтерфейси, що і замовник або
користувач, або зовнішні інтерфейси, що дозволяють іншому комп’ютеру або
іншому процесу підключитися до системи для тестування.
Сірий ящик (Grey Box) – поєднує елементи двох попередніх підходів.
1.2.5 Методи тестування
Статичне та динамічне тестування.
Тестова діяльність, що пов'язана з аналізом результатів розробки
програмного забезпечення, називається статичним тестуванням. Воно передбачає
перевірку програмних кодів, контроль та перевірку програми без запуску на
комп'ютері. Тестова діяльність, що передбачає експлуатацію програмного
продукту, називається динамічним тестуванням. Динамічне та статичне
тестування доповнюють одне одного.
На етапі статичного тестування перевіряється вся документація, отримана
як результат життєвого циклу програми. Це і технічне завдання, і специфікація, і
вихідний текст програми на мові програмування [12]. Вся документація
аналізується на предмет дотримання стандартів програмування. У результаті
статичної перевірки встановлюється, наскільки програма відповідає заданим
критеріям та вимогам замовника. Усунення неточностей та помилок у
документації — запорука того, що створюваний програмний засіб має високу
якість.
Динамічні методи застосовуються в процесі безпосереднього виконання
програми. Коректність програмного засобу перевіряється на безлічі тестів або
наборів підготовлених вхідних даних [13]. При прогоні кожного тесту збираються
та аналізуються дані про відмови та збої в роботі програми.
Тестування «білої скриньки»
Об'єктом тестування тут є не зовнішня, а внутрішня поведінка програми.
Перевіряється коректність побудови всіх елементів програми та правильність
їхньої взаємодії один з одним. Зазвичай аналізуються керуючі зв'язки елементів,
рідше — інформаційні зв'язки. Тестування за принципом «білої скриньки»
20
ЧДТУ 232208.011 ПЗ
характеризується ступенем, в якому тести виконують або покривають логіку
(вихідний текст) програми.
Особливості тестування «білої скриньки»
Зазвичай тестування «білої скриньки» засноване на аналізі керуючої
структури програми. Програма вважається повністю перевіреною, якщо
проведено вичерпне тестування маршрутів (шляхів) її графа управління.
У цьому випадку формуються тестові варіанти, в яких:
– гарантується перевірка всіх незалежних маршрутів програми.
– знаходяться гілки True, False для всіх логічних рішень.
– виконуються всі цикли (у межах їхніх кордонів та діапазонів).
– аналізується правильність внутрішніх структур даних.
Недоліки тестування «білої скриньки»:
– кількість незалежних маршрутів може бути дуже велика.
– повне тестування маршрутів не гарантує відповідності програми
вихідним вимогам до неї.
– у програмі можуть бути пропущені деякі маршрути.
– не можна виявити помилки, поява яких залежить від даних.
Переваги тестування «білої скриньки» пов'язані з тим, що принцип «білої
скриньки» дозволяє врахувати особливості програмних помилок:
– кількість помилок мінімально в «центрі» і максимально на «периферії»
програми.
– попередні припущення про ймовірність потоку керування або даних у
програмі часто бувають некоректними. У результаті типовим може стати
маршрут, модель обчислень за яким опрацьована слабо.
– при записі алгоритму програмного забезпечення у вигляді тексту на мові
програмування можливе внесення типових помилок трансляції
(синтаксичних та семантичних).
– деякі результати в програмі залежать не від вихідних даних, а від
внутрішніх станів програми.
21
ЧДТУ 232208.011 ПЗ
Кожна з цих причин є аргументом для проведення тестування за принципом
«білої скриньки» [14]. Тести «чорної скриньки» не зможуть реагувати на помилки
таких типів.
Тестування «чорної скриньки»
Основне місце програми тестів «чорної скриньки» — інтерфейс ПЗ.
Ці тести демонструють:
– як виконуються функції програми;
– як приймаються вихідні дані;
– як виробляються результати;
– як зберігається цілісність зовнішньої інформації.
При тестуванні «чорної скриньки» розглядаються системні характеристики
програм, ігнорується їхня внутрішня логічна структура. Вичерпне тестування, як
правило, неможливе. Наприклад, якщо в програмі 10 вхідних величин і кожна
приймає по 10 значень, то кількість тестових варіантів становитиме 1010 .
Тестування «чорної скриньки» не реагує на багато особливостей програмних
помилок [15].
Тестування «чорної скриньки» (функціональне тестування) дозволяє
отримати комбінації вхідних даних, які забезпечують повну перевірку всіх
функціональних вимог до програми. Програмний виріб тут розглядається як
«чорна скринька», чию поведінку можна визначити тільки дослідженням його
входів та відповідних виходів. При такому підході бажано мати:
– набір, утворений такими вхідними даними, які призводять до аномалій у
поведінці програми (назвемо його IT);
– набір, утворений такими вхідними даними, які демонструють дефекти
програми (назвемо його OT). Будь-який спосіб тестування «чорної
скриньки» повинен:
– виявити такі вхідні дані, які з високою ймовірністю належать набору IT;
– сформулювати такі очікувані результати, які з високою імовірністю є
елементами набору OT.
22
ЧДТУ 232208.011 ПЗ
Принцип «чорної скриньки» не альтернативний принципу «білої скриньки».
Скоріше це доповнює підхід, який виявляє інший клас помилок.
Тестування «чорної скриньки» забезпечує пошук наступних категорій
помилок:
– некоректних чи відсутніх функцій;
– помилок інтерфейсу;
– помилок у зовнішніх структурах даних або в доступі до зовнішньої бази
даних;
– помилок характеристик (необхідна ємність пам'яті і т. д.);
– помилок ініціалізації та завершення. Подібні категорії помилок
способами «білої скриньки» не виявляються
1.2.6 Класифікація тестування
Всі види тестування програмного забезпечення, залежно від переслідуваних
цілей, можна умовно розділити на наступні групи:
– функціональні (Functional testing)
– нефункціональні (Non-functional testing)
– пов’язані зі змінами (Regression testing)
Функціональні види тестування
Функціональні тести базуються на функціях і особливостях, а також
взаємодії з іншими системами, і можуть бути представлені на всіх
рівняхтестування: компонентному або модульному (Component / Unit testing),
інтеграційному (Integration testing), системному (System testing) і приймальному
(Acceptance testing) [16].
Функціональні види тестування розглядають зовнішню поведінку системи.
Далі перераховані одні з найпоширеніших видів функціональних тестів:
– функціональне тестування (Functional testing).
– тестування безпеки (Security and Access Control Testing).
– тестування взаємодії (Interoperability Testing).
Нефункціональні види тестування
23
ЧДТУ 232208.011 ПЗ
Нефункціональне тестування описує тести, необхідні для визначення
характеристик програмного забезпечення, які можуть бути виміряні різними
величинами. В цілому, це тестування того, “Як” система працює. Далі
перераховані основні види нефункціональних тестів:
Всі види тестування продуктивності:
– тестування навантаження (Performance and Load Testing)
– стресове тестування (Stress Testing)
– тестування стабільності або надійності (Stability / Reliability Testing)
– об’ємне тестування (Volume Testing)
– тестування установки (Installation testing)
– тестування зручності користування (Usability Testing)
– тестування на відмову і відновлення (Failover and Recovery Testing)
– конфігураційне тестування (Configuration Testing)
Тестування, пов’язане зі змінами
Після проведення необхідних змін, таких як виправлення бага / дефекту,
програмне забезпечення повинне бути перетестоване для підтвердження того
факту, що проблема була дійсно вирішена. Нижче перераховані види тестування,
які необхідно проводити після установки програмного забезпечення, для
підтвердження працездатності програми або правильності здійсненого
виправлення дефекту:
– димове тестування (Smoke Testing)
– регресійне тестування (Regression Testing)
– тестування збірки (Build Verification Test)
– санітарне ткстування або перевірка узгодженості / справності (Sanity
Testing)
Функціональне тестування (Functional testing)
Тестування функціональності може проводиться у двох аспектах:
– вимоги
– бізнес-процеси
Тестування в аспекті «вимоги» використовує специфікацію функціональ
24
ЧДТУ 232208.011 ПЗ
них вимог до системи як основу для дизайну тестових випадків (Test Cases). У
цьому випадку необхідно зробити список того, що буде тестуватися, а що ні,
пріоритезувати вимоги на основі ризиків (якщо це не зроблено в документі з
вимогами), а на основі цього пріоритезувати тестові сценарії (test cases). Це
дозволить сфокусуватися і не упустити при тестуванні найбільш важливий
функціонал [17].
Тестування в сенсі «бізнес-процеси» використовує знання цих самих
бізнеспроцесів, які описують сценарії щоденного використання системи. У цьому
випадку тестові сценарії (test scripts), як правило, ґрунтуються на випадках
використання системи (use cases).
Переваги функціонального тестування: імітує фактичне використання
системи;
Недоліки функціонального тестування: можливість упущення логічних
помилок у програмному забезпеченні; ймовірність надмірного тестування.
Досить поширеною є автоматизація функціонального тестування.
Тестування безпеки (Security and Access Control Testing) – це стратегія
тестування, що використовується для перевірки безпеки системи, а також для
аналізу ризиків, пов’язаних із забезпеченням цілісного підходу до захисту
додатків, атак хакерів, вірусів, несанкціонованого доступу до конфіденційних
даних. Загальна стратегія безпеки ґрунтується на трьох основних принципах:
конфіденційність, цілісність, доступність.
Конфіденційність – це приховування певних ресурсів або інформації. Під
конфіденційністю можна розуміти обмеження доступу до ресурсу деякої категорії
користувачів, або іншими словами, за яких умов користувач авторизований
отримати доступ до даного ресурсу.
Цілісність – Існує два основних критерії при визначенні поняття цілісності:
Довіра – Очікується, що ресурс буде змінений тільки відповідним способом
певною групою користувачів.
Пошкодження і відновлення – у разі коли дані пошкоджуються або
25
ЧДТУ 232208.011 ПЗ
неправильно змінюються авторизованим або авторизованим користувачем,
потрібновизначити наскільки важливою є процедура відновлення даних.
Доступність являє собою вимоги про те, що ресурси повинні бути доступні
авторизованому користувачеві, внутрішньому об’єкту або пристрою. Як правило,
чим більш критичний ресурс тим вище рівень доступності.
Тестування взаємодії (Interoperability Testing) – це функціональне
тестування, що перевіряє здатність програми взаємодіяти з одним і більше
компонентами або системами і включає в себе тестування сумісності (compatibility
testing) і інтеграційне тестування (integration testing).
1.2.7 Робота з базою даних в процесі тестування
У наші дні База Даних є однією з невід’ємних частин майже кожної
програми. Не має значення чи це веб-додаток, десктопна програма, мобільний
додаток, клієнт-серверна аплікація або якесь індивідуальне бізнес-ріщення.
Механізм Бази Даних працює усюди на Backend -і. Однаково не має значення, яка
це життєва сфера: охорона здоров’я, фінанси, навчання, торгівля, автоматизація
email розсилок чи керування космічним кораблем.
Більше того, якщо аплікація велика або з плином часу розростається прямо
пропорційно відбувається ускладнення її Бази Даних, виникає необхідність
підтримувати безпеку та надійність Бази Даних.
Те саме стосується додатків з високою частотою транзакцій (наприклад,
банківські або фінансові програми), тут потрібне використання
повнофункціональних інструментів — DB Tool. З можливостями працювати з
великими та складними даними, з якими традиційні Бази Даних не завжди можуть
справитися, щоб їх обробляти такі великі обсяги даних — застосовуються більш
сучасніші інструменти Big Data [18].
Коли аплікація виконується, кінцевий користувач здебільшого виконує
CRUD операції, що надаються інструментарієм Бази Даних.
C: Create (Створити) — операція ‘Create’ виконується, коли користувач
зберігає будь-яку нову інформацію у Базі Даних.
R: Retrieve (Отримати) — операція ‘Retrieve’ виконується, коли користувач
26
ЧДТУ 232208.011 ПЗ
виконує пошук або перегляд вже збереженої інформації.
U: Update (Обновити) — операція ‘Update’ виконується, коли користувач
редагує або змінює існуючий запис.
D: Delete (Видалити) — операція ‘Delete’ виконується, коли користувач
видаляє запис із системи Бази Даних.
Не має значення, яка База Даних та інструментарій використовується і яка
операція попередньо виконувалася з Базою Даних (з’єднання, запит або
збереження).
Усі операції з БД, виконувані користувачем, з користувацького інтерфейсу
будь-якого додатку, є CRUD операціями.
Тестуючи Базу Даних тест-інженеру слід зосереджувати увагу на
наступному:
– відображення даних: тестувальнику потрібно перевірити, чи
відображаються дані правильно у відповідь на дію, і чи дійсно викликана
дія сама по собі є успішною чи ні;
– переконатися, що зв’язки в Базі Даних між даними відповідають
проектній документації (колонками, рядками, комірками) для всіх
операцій CRUD;
– перевірити, що відповідні таблиці та записи оновлюються-
заповнюються успішно для усіх що треба користувачів, коли користувач
натискає «Зберегти», «Оновити», «Пошук» або «Видалити» з графічного
інтерфейсу програми.
1.3 Постановка задачі
Постановка задачі включатиме в себе наступні пункти:
– проведення аналізу існуючих методів автоматизації тестування
webсайтів, їх переваг та недоліків;
– перегляд існуючих альтернатив серед інструментів автоматизації
тестування інтерфейсу та вибір найбільш підходящих;
– визначення вимог до фреймворку для автоматизації тестування
27
ЧДТУ 232208.011 ПЗ
webсайту;
– розробка такої архітектури фреймворку, що забезпечить зручний та
ефективний спосіб написання, виконання і управління тестами;
– розробка основних функцій фреймворку, таких як взаємодія з браузером,
маніпуляції з елементами сторінки, перевірка стану елементів, робота з
тестовими даними, тощо;
– тестування і валідація фреймворку на реальних web-сайтах для перевірки
його функціональності та ефективності.
Вимоги до програмної реалізації, що буде зроблено:
– фреймворк має бути простим, зрозумілим та лаконічним;
– у фреймворку мають використовуватися сучасні підходи до
автоматизації;
– вхідні дані є статичними, але можуть змінюватися тестувальником або
будь-якою зацікавленою особою в самому тесті.
Висновки до першого розділу
Тестування — це структурована технічна діяльність, це робота, котра
дається не легко. З часом потрібно навчитися щось автоматизувати, а це узагалі
далеко не просте завдання. Це розуміння рамок автоматизації, визначення
моментів, коли слід автоматизовувати, знання коду.
Визначення:
План Тестування (Test Plan) – це документ, що описує весь обсяг робіт з
тестування, починаючи з опису об’єкта, стратегії, розкладу, критеріїв початку і
закінченнятестування, до необхідного в процесі роботи обладнання, спеціальних
знань, а також оцінки ризиків з варіантами їх дозволу .
Тестовий випадок (Test Case) – це артефакт, що описує сукупність кроків,
конкретних умов і параметрів, необхідних для перевірки реалізації функції, що
тестується або її частини.
Основні атрибути Test Case:
– ID (номер),
28
ЧДТУ 232208.011 ПЗ
– Name (ім’я),
– Preconditions (умови і параметри),
– Steps (кроки до відтворення),
– Expectedresult (очікуваний результат),
– Actualresult (фактичний результат),
– Postconditions (постумови).
Тест дизайн (Test Design) – це етап процесутестування ПЗ, на якому
проектуються і створюються тестові випадки (тест кейси), відповідно з
визначеними раніше критеріями якості і цілями тестування.
Баг / Дефект Репорт (Bug Report) – це документ, що описує ситуацію або
послідовність дій, що призвела до некоректної роботи об’єкта тестування, із
зазначенням причин і очікуваного результату.
Тестове Покриття (Test Coverage) – це одна з метрик оцінки якості
тестування, що представляє із себе щільність покриття тестами.
Специфікація Тест Кейсів (Test Case Specification) – це рівень деталізації
опису тестових кроків і необхідного результату, при якому забезпечується
розумне співвідношення часу проходження до тестового покриття.
Час Проходження Тест Кейса (Test Case Pass Time) – це час від початку
проходження кроків тест кейса до отримання результату тесту.
29
ЧДТУ 232208.011 ПЗ
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРЕМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1 Теоретичні дослідження
Оскільки тестування веб-сайтів в основному пов'язане із функціональністю
та властивостями програмного забезпечення, математичні моделі можуть
включати такі елементи, як ймовірність помилок, час виконання тестів,
ефективність тестування та інші [19].
Гіпотеза. Удосконаливши метод тестування базованого на тест-кейсах
шляхом вибору найкращого способу виявлення для певного типу помилок,можна
зменшити витрати на тестування web-сайтів зі збереженням його якості.
Підрахунок помилок в рамках даного дослідження включав усі
зареєстровані помилки, які можна було інтерпретувати, зрозуміти і відтворювати
(тобто справжні помилки). Помилкові виявлення помилок (дублікати,
невідтворювані, незрозумілі) не було включено до числа помилок.
Ймовірність помилок в тестових сценаріях. Нехай P - ймовірність
помилки в одному тестовому сценарії.
Тоді ймовірність виявлення помилки в процесі тестування можна виразити
як 1−P.
Наприклад, якщо ймовірність помилки у тестовому сценарії дорівнює 0.2, то
ймовірність успішного виявлення помилки буде 1−0.2=0.8 або 80%.
Час виконання тестів. Нехай T - час виконання одного тестового сценарію.
Загальний час виконання тестового набору можна виразити як
N×T, де N - кількість тестових сценаріїв у наборі.
Наприклад, якщо час виконання одного сценарію T дорівнює 10 хвилин, і
ми маємо 20 тестових сценаріїв (N=20), то загальний час виконання буде
20×10=200 хвилин або 3 години і 20 хвилин.
Ефективність тестування. Ефективність тестування можна визначити за
допомогою формули для покриття коду. Одним з основних показників
ефективності тестування є визначення того, який відсоток коду програми був
протестований.
30
ЧДТУ 232208.011 ПЗ
Формула для визначення покриття коду (C) може виглядати наступним
чином:
C=(Nзагальний код/Nпротестований код)×100% (2.1)
де:
Nпротестований код - кількість коду, який був протестований.
Nзагальний код - загальна кількість коду в програмі.
Ця формула вимірює відсоток коду, який був протестований відносно
загальної кількості коду. Чим вище цей показник, тим більше коду було визначено
та використано в процесі тестування.
Спрощені математичні моделі продуктивності тестування. Спрощена
математична модель продуктивності тестування може включати у себе середній
час виконання тестів та середній час виявлення помилок. Давайте визначимо такі
терміни та надамо спрощені формули
1 Середній час виконання тестів (Tвик ):
Це може бути середній час, який витрачається на виконання одного
тестового сценарію. Нехай Nтести - кількість тестів, а Ti - час виконання і-го тесту.
Формула: Tвик = Nтести1∑ i=1NтестиTi (2.2)
де:
Tвик - середній час виконання тестів,
Nтести - загальна кількість тестів,
Ti - час виконання і-го тесту.
Такі формули визначають середній час виконання тестів та середній час
виявлення помилок, що може бути важливим для оцінки продуктивності
тестування.
Середня кількість помилок для підходів дослідницького тестування (ДТ) і
тестування базованого на тест-кейсах (ТБТК) становить за результатом
31
ЧДТУ 232208.011 ПЗ
досліджень 8,342 і 1,828 відповідно; ДТ виявлено в середньому на 6,514 більше
помилок, ніж ТБТК. Фактична кількість помилок, виявлених двома підходами,
становила 292 (ДТ) проти 64 (ТБТК). Кількість помилок, виявлених обома
групами, була з нормального розподілу. Таким чином, кількість виявлених
помилок була порівняна за допомогою t-тесту. Використовуючи двобічний t-тест,
було отримано p = 1,159х10-10, отже, помилки отримані за допомогою двох
підходів, статистично відрізнялися на α = 0,05. Розмір ефекту, розрахований за
допомогою також свідчить про практичне значення, тобто d = 2,0657.
На кількість помилок, виявлених за заданий час, було в рамках
експериментів даної роботи виявлено 172 справжніх дефектів при використанні
ДТ з медіаною 68. Професійні тестувальники виявили 120 справжніх дефектів при
використанні ДТ із медіаною 9. Це показує що для студентів і практиків, які
застосовують ДТ, практики виявили в середньому більше помилок. Однак різниця
не є статистично значущою (p = 0,07) при застосуванні U-тест Манна-Уітні = 0,05
(дані мали ненормальний розподіл).
Застосовуючи ТБТК, в рамках роботи було виявлено загалом 33 справжні
помилки з медіаною 1. Професійні тестувальники, з іншого боку, виявили загалом
31 помилку під час застосування ТБТК із медіаною 2,5. Це показує що професійні
тестувальники виявили в середньому більше справжніх дефектів, ніж було
виявлено в експериментах даної роботи під час використання ТБТК. Однак,
різниця не є статистично значущою (p = 0,15, ��= 0,35) при застосуванні U-
критерію Манна-Уітні при = 0,05 (дані мали ненормальний розподіл).
2.2 Експериментальні дослідження
Експериментальний план даного дослідження ґрунтується на одному
факторі з двома методами тестування. Фактором у нашому дослідженні є підхід
до тестування, тоді як методами є ДТ (дослідницьке тестування) і ТБТК
(тестування базованого на тест-кейсах). Є дві цікаві змінні відповіді: ефективність
виявлення помилок і час виконання всіх необхідних дій [22]. Експеримент
складався з двох окремих сесій, по одній для групи ДТ і ТБТК. На етапі сесії
32
ЧДТУ 232208.011 ПЗ
тестування група ТБТК розробляла та виконувала тестові випадки для заданих
функцій. Для оцінки ефективності з точки зору часу на виконання всіх необхідних
дій використовувалася вимірювальна метрика.
На початку кожної сесії групі ТБТК надавався шаблон для розробки
тестових випадків і звітування про виявлення помилок. Обидві групи отримали
однакові матеріали та інформацію щодо тестованого додатка та його
особливостей. Крім того, обом групам було надано той самий посібник
користувача jEdit для досягнення очікуваних результатів.
Усі суб'єкти отримали інструкції з застосування тих самих методів
проектування тестів: розподіл еквівалентності, аналіз граничних значень і методи
комбінованого тестування. Ці методи застосовувалися як для ТБТК, так і для ДТ.
Під час експерименту ця інформація була надана перед початком тестування.
Кожен сеанс розпочинався з 15-хвилинної фази "початку сеансу", під час
якої суб'єктам було представлено мету експерименту та отримані вказівки щодо
проведення експерименту. Фактичне тестування проводилося протягом 90-
хвилинної сесії.
Щоб зробити тестування ефективнішим, важливо знати, які типи помилок
можна знайти в тестовому програмному забезпеченні та відносна частота, з якою
ці помилки виникали.
З метою цього дослідження, класифікувались помилки на основі зовнішніх
видимих симптомів. Важається, що для порівняння підходів до ручного
тестування є важливими факторами, що впливають на виявлення помилок.
Залежно від симптомів помилки поділяють на такі види: продуктивність,
документація, графічний інтерфейс користувача, невідповідність, відсутність
функції, технічні помилки, зручність використання та неправильна функція.
У всіх чотирьох режимах складності виявлення ДТ виявлино більше
помилок. Різниця між кількістю помилок, виявлених на кожному рівні складності,
також є статистично значущою при α = 0,05 за допомогою t-критерію
(p = 0,021, d = 2,91).
33
ЧДТУ 232208.011 ПЗ
У процентному розподілі, представленому в таблиці 2.1, можна побачити
відмінності між ДТ і ДБТК з точки зору складності виявлення. Дані показують, що
для помилок, які виявило ДТ, частка на помилки, які було важко виявити, була
вищою. У виявлених за допомогою ДБТК помилок частка в явних і прямих
помилок було вище.
Таблиця 2.1
Розподіл помилок за складністю виявлення
№ ДТ ДБТК ДТ% ДБТК% Всього
0 73 22 25% 35% 95
1 117 27 40% 44% 144
2 72 11 25% 18% 83
3 30 2 10% 3% 32
Всього 292 62 100% 100% 354
Для застосовування ДТ, чотири режими складності виявлення помилок
істотно відрізнялися з використанням одностороннього аналізу дисперсії (p = 4,5e
− 7, α = 0,05). Розмір ефекту, розрахований за допомогою ета-квадрату (η 2 ) також
передбачає практичне значення, тобто η2 = 0,3110. Проведений тест на кілька
порівнянь (α = 0,05)11, щоб з’ясувати, які пари відрізняються. Результати показали,
що помилки режиму 0 і 1 значно відрізнялися від помилки режиму 3. У
відсотковий розподіл, представлений у таблиці 2.2., дає змогу побачити
відмінності у режимах виявлених помилок, які використовують ДТ.
Таблиця 2.2
Відсотки режимів помилок, виявлених при застосуванні ДТ
№ 1 2 1% 2%
0 46 27 26.74% 22.69%
1 68 48 39.53% 40.34%
2 39 31 22.67% 26.05%
34
ЧДТУ 232208.011 ПЗ
3 19 13 11.04% 10.92%
Відсотковий розподіл різних видів помилок наведено в таблиці 2.3. З неї
видно, що жодної помилкив режимі 3 при застосовуванні ДБТК не було виявлено,
тоді як більшість виявлених помилок були порівняльно легко знайти (режим 0 і 1).
ДБТК не було виявлено значних відмінностей між різними режимами
помилок, виявленими за допомогою одностороннього дисперсійного аналізу (p =
0,15, η2 = 0,11, α = 0,05). Також наведено відсотковий розподіл різних видів
помилок, виявлених за допомогою ДБТК в таблиці 2.3. Як і у випадку зі ДТ, також
не виявили недоліків у режимі 3, проте більшість знайдених помилок були
легкими (режим 0 і 1).
Таблиця 2.3
Відсоток різних типів помилок, під час застосування ДБТК
№ 1 2 1% 2%
0 7 11 25.92% 45.83%
1 15 7 55.55% 29.17%
2 5 6 18.52% 25%
3 0 0 0.00% 0.00%
Крім того, було застосувано багатовимірний аналіз дисперсійного тесту для
виявлення будь-яких відмінностей щодо режимів складності виявлення помилок
при використанні ДБТК.
Таблиця 2.4 показує класифікацію помилок на основі їх технічного типу.
Підхід ДТ виявив більше помилок у кожній категорії типу помилок порівняно з
ДБТК (виняток становить "документація", де обидва підходи виявили однакову
кількість помилок). Тим не менш, відмінності є дуже великими для таких типів, як
відсутність функції, продуктивність, технічна помилкак і неправильна функція.
Використовуючи t-тест, різниця між кількістю виявлених дефектів для кожного
35
ЧДТУ 232208.011 ПЗ
технічного типу для двох підходів є статистично значущою при α = 0,05 (p = 0,012,
d = 2,26).
Таблиця 2.4
Розподіл помилок за технічним видом
Тип ДТ ДБТК ДТ% ДБТК% Всього
Документація 5 5 1.71% 8.06% 10
GUI 19 8 6.51% 12.90% 27
Непослідовність 8 4 2.74% 6.45% 12
Відсутня 65 5 22.26% 8.06% 70
функція
Продуктивність 62 5 21.23% 8.06% 67
Технічна 44 2 15.07% 3.22% 46
помилка
Зручність 17 11 5.82% 17.74% 28
використання
Неправильна 72 22 24.66% 35.48% 94
функція
Всього 292 62 100% 100% 354
Відсотковий розподіл, представлений у таблиці 2.4, чітко вказує на те, що
стосовно помилок ДТ виявлено, що частка відсутніх функцій, продуктивності та
технічних помилок була явно вищою. З іншого боку, частка помилок графічного
інтерфейсу та зручності використання, а також помилок неправильних типів
функцій, була вищою в помилках, виявлених за допомогою ДБТК.
Результати однофакторного дисперсійного аналізу (p = 7,8e − 16, η2 = 0,38)
також показали, коли використовували ДТ, відрізнялись за технічними видами
помилок. Тест багаторазового порівняння (α = 0,05) показав, що помилки типу
документація, GUI, невідповідність і зручність використання суттєво відрізнялися
від помилок типу відсутні функції, продуктивність і неправильна функція.
36
ЧДТУ 232208.011 ПЗ
Відсотковий розподіл, представлений у таблиці 2.5, чітко показує, що стосується
помилок ДТ, виявилось більшу частку відсутніх функцій, продуктивності та
неправильних функціональних помилок порівняно з іншими типами помилок.
Таблиця 2.5
Відсоток типів помилок, при застосуванні ДТ
Тип 1 2 1% 2% Всього
Документація 2 3 1.71% 8.06% 10
GUI 12 7 6.51% 12.90% 27
Непослідовність 4 4 2.74% 6.45% 12
Відсутня 39 26 22.26% 8.06% 70
функція
Продуктиність 38 24 21.23% 8.06% 67
Технічна 26 18 15.07% 3.22% 46
помилка
Зручність 10 7 5.82% 17.74% 28
використання
Неправильна 43 29 24.66% 35.48% 94
функція
Також виявили суттєві різниці в типах помилок при використанні ДТ, як
показано результатами одностороннього дисперсійного аналізу (p = 4,1e − 10, η2 =
0,47). Тест множинного порівняння (α = 0,05) показав схожі результати, які
використовують ДТ, тобто помилок типу: документація, графічний інтерфейс
користувача, невідповідність і зручність використання суттєво відрізнялися від
помилок типу: відсутня функція, продуктивність і неправильна функція.
Відсотковий розподіл типів знайдених помилок, які використовують ДТ (таблиця
2.5), демонструє подібну картину, коли застосовуюється ДТ, а саме, виявили
більшу частку недоліків функції, продуктивності та неправильних функцій
порівняно з залишковим типом помилок.
37
ЧДТУ 232208.011 ПЗ
Також застосовано багатовимірний аналіз дисперсійного тесту для
виявлення будь-яких відмінностей за типом помилок при використанні ДТ.
Висновки до другого розділу
У цьому дослідженні було проведено кілька ітерацій експерименту для
порівняння ефективності та результативності дослідницького тестування (ДТ) з
тестовим випадковим тестуванням (ДБТК). Ефективність вимірювалася
загальною кількістю виявлених помилок за допомогою обох методів, тож
результативність аналізувалася за складністю виявлення помилок, технічним
типом помилок, рівнями серйозності та кількістю неправдивих повідомлень про
помилки. Експериментальні дані свідчать про те, що ДТ був ефективнішим, ніж
ДБТК, у виявленні більшої кількості помилок за певний час. Також було
встановлено, що ДТ є більш ефективним з точки зору складності виявлення
помилок, технічних типів виявлених помилок та їх ступені тяжкості. Проте
значущих відмінностей між ними щодо кількості неправдивих повідомлень про
помилок не виявлено.
Експериментальні дані також демонструють, що з точки зору типів об'єктів
тестування немає відмінностей у ефективності та результативності як для ДТ, так
і для ДБТК.
Результати дослідження підкреслюють, що кількість тестових випадків не
завжди пропорційна загальній кількості виявлених помилок. Тому можна
стверджувати, що продуктивніше витрачати час на тестування та пошук помилок,
а не на деталізацію тестових випадків. Дані результати покладено в основу
розробки фреймворку для автоматизації тестування WEB-сайту.
38
ЧДТУ 232208.011 ПЗ
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
Основною задачею є розробка методики впровадження результатів
досліджень у практику проектування програмного забезпечення інформаційних
систем, з фокусом на фреймворку для автоматизації тестування WEB-сайтів,
визначення оптимальних стратегій та процедур для успішного і ефективного
впровадження цього інноваційного рішення[31]. Задачі включають в себе аналіз
організаційних аспектів, розробку технічних процедур інтеграції, створення
програми навчання та підтримки, а також визначення критеріїв успішності та
методів оцінки ефективності впровадження. Результатом вирішення цієї задачі
буде розроблена та описана системна методика, яка допоможе команді проекту
ефективно і безперешкодно впроваджувати розроблені результати у практику.
3.1 Моделювання предметної області
Моделювання предметної області включає в себе визначення ключових
аспектів та елементів, які взаємодіють у цьому контексті. Перш за все,
визначаються основні складові WEB-сайтів, такі як сторінки, елементи
інтерфейсу, взаємодія з користувачем та сервером[32]. Зокрема, враховуються
різноманітні типи тестування, такі як функціональне, візуальне, відмовостійке, та
інші, які можуть бути виконані фреймворком. Далі визначається структура
тестових сценаріїв, об'єкти, які підлягають тестуванню, та взаємодія з різними
технологіями, такими як HTML, CSS, JavaScript.
Зокрема, у моделюванні враховуються різноманітні сценарії
введення/виведення даних, навігація по сайту, та інші дії, які можуть бути
автоматизовані фреймворком. Також, ураховуються потенційні проблеми, що
можуть виникнути при тестуванні, такі як адаптація до різних браузерів, розміри
екранів, та взаємодія з різними ОС.
Моделювання предметної області допомагає чітко визначити всі аспекти,
39
ЧДТУ 232208.011 ПЗ
які мають бути враховані при розробці фреймворку, сприяючи оптимізації його
функціоналу та забезпечуючи високу ефективність в автоматизації тестування
WEB-сайтів.
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область в цьому випадку - це всі аспекти тестування WEB-сайтів,
такі як функціональність, користувацький інтерфейс, продуктивність, безпека і
т.д. Моделювання предметної області допомагає визначити ключові елементи та
їх взаємодії в процесі автоматизованого тестування[33].
Модель предметної області для автоматизації тестування WEB-сайту:
– Елементи інтерфейсу:
– сторінки: Основні складові WEB-сайту;
– елементи управління (кнопки, поля введення, чекбокси і т.д.);
– елементи, які взаємодіють з користувачем.
– Функціональність:
– сценарії тестування: Послідовності дій, які виконує користувач;
– очікувані результати: Очікувані відповіді системи на конкретні
вхідні дані чи дії.
– Тестові дані:
– вхідні дані: Дані, які використовуються для тестування конкретної
функціональності;
– очікувані вихідні дані: Очікувані результати для порівняння з
фактичними результатами.
– Продуктивність:
– навантаження: Об'єми даних та кількість користувачів для
тестування продуктивності;
– часові обмеження: Часові рамки для виконання конкретних операцій.
– Безпека:
– управління доступом: Рівні доступу для різних типів користувачів;
40
ЧДТУ 232208.011 ПЗ
– аутентифікація та авторизація: Перевірка правильності введених
даних і обрані ролі користувачів.
Словник предметної області
Фреймворк для автоматизації тестування WEB-сайту (Web Testing
Framework): Загальна назва для програмного забезпечення, призначеного для
автоматизованого виконання тестів WEB-сайтів[34]. Метою є полегшення
розробки, виконання та аналізу результатів тестів в інтернет-проектах.
Тестовий Сценарій (Test Scenario): Опис послідовності дій, які виконуються
для перевірки конкретного аспекту WEB-сайту. Включає в себе введення даних,
взаємодію з елементами інтерфейсу та очікувані результати.
Елемент Інтерфейсу (UI Element): Компонент WEB-сторінки, з яким може
взаємодіяти користувач, такий як кнопки, текстові поля, чекбокси та інші.
Автоматизований Тест (Automated Test): Тест, який виконується
автоматично за допомогою фреймворку для тестування. Включає в себе
визначення очікуваних результатів і порівняння їх із фактичними результатами.
Тестовий Випадок (Test Case): Конкретна одиниця тестування, яка включає
в себе один або декілька тестових сценаріїв. Це може бути функціональний,
навантажувальний, або інший вид тесту.
Браузерна Сумісність (Browser Compatibility): Можливість веб-сайту
адекватно відображатися та працювати на різних веб-браузерах, таких як Chrome,
Firefox, Safari, та інші.
Модульне Тестування (Unit Testing): Вид тестування, який виконується для
перевірки правильності роботи окремих модулів або функцій коду.
Тестування Візуальної Загальної Вигляду (Visual Regression Testing):
Автоматизоване тестування для виявлення змін у візуальному вигляді веб-сайту
між різними версіями або різними браузерами.
API Тестування (API Testing): Тестування інтерфейсів програмування
застосунків (API) для перевірки взаємодії між різними компонентами веб-системи.
Результат Тестування (Test Result): Вивід або звіт, який містить інформа
41
ЧДТУ 232208.011 ПЗ
цію про те, чи пройшов тестовий випадок чи тестовий сценарій, і які проблеми
(якщо такі є) були виявлені під час тестування.
Тестовий Набір Даних (Test Data Set): Заздалегідь визначені вхідні дані, що
використовуються для виконання автоматизованих тестів, спроектовані для
різних сценаріїв та умов тестування.
3.1.2 Елементи моделювання предметної області
Для моделювання предметної області було вирішено використати мову
UML, як широко поширену та, в результаті, зрозумілою широкому колу
користувачів[35].
В мові UML для використання в діаграмах існують 3 види умовних,
візуальних позначень: різноманітні графічні символи, зв`язки (стрілки та лінії),
текст.
Найчастіше вживані елементи діаграм виглядають наступним чином:
Рисунок 3.1 – Елементи мови UML
42
ЧДТУ 232208.011 ПЗ
Найчастіше вживані типи зв`язків, що використовуються у діаграмах
виглядають наступним чином:
Рисунок 3.2 – Зв`язки мови UML
Варто зауважити, що деякі діаграми мають свій перелік унікальних
елементів, що вживаються в тому чи іншому типі діаграм.
3.1.3 Робоча область моделювання
Робоча області моделювання фреймворку для автоматизації тестування веб-
сайту - це завдання, яке вимагає ретельного проектування та врахування ключових
аспектів[36]. Нижче представлено основні компоненти та аспекти, які слід
врахувати при розробці фреймворку для автоматизації тестування веб-сайту:
Драйвери та конектори:
Інтегруйте вибір драйверів для різних браузерів (Chrome, Firefox, etc.) та
можливість роботи з різними платформами. Забезпечте конектори для взаємодії з
базами даних, API та іншими залежностями веб-додатка.
Мова програмування:
43
ЧДТУ 232208.011 ПЗ
Виберіть мову програмування, яка найбільше підходить для потреб вашого
проекту. Зазвичай для автоматизації тестування використовують мови, такі як
Python, Java, або JavaScript.
Фреймворк для тестування:
Оберіть та інтегруйте популярний фреймворк для тестування, наприклад,
Selenium WebDriver для взаємодії з елементами веб-сторінок.
Звіти та логування:
Додайте засоби для генерації звітів про прогони тестів та детального
логування. Це полегшить аналіз результатів та виявлення помилок.
Інтеграція з CI/CD:
Забезпечте можливість легкої інтеграції фреймворку з системами Continuous
Integration та Continuous Deployment (CI/CD), щоб автоматизувати тестування на
етапі розробки.
Тестові дані:
Розгляньте механізми для ефективного керування тестовими даніми,
забезпечуючи їхню конфіденційність та консистентність під час прогонів
тестів[37].
Рисунок 3.3 - Модель предметної області
Розробка робочої області моделювання фреймворку для автоматизації
тестування веб-сайту вимагає уважного увідомлення про вимоги проекту та
врахування принципів ефективного тестування.
44
ЧДТУ 232208.011 ПЗ
3.2 Формування та аналіз вимог
Формування та аналіз вимог для фреймворку для автоматизації тестування
WEB-сайту є важливим етапом розробки, спрямованим на визначення основних
характеристик і функціональності цього інструменту. Процес розпочинається з
уважного збору вимог, що включає в себе активну взаємодію з різними
зацікавленими сторонами, такими як розробники, тестувальники та менеджери
проекту[38]. Основною метою є визначення очікувань та потреб користувачів для
подальшої ідентифікації функціональних та нефункціональних вимог. Визначення
функціональних вимог включає в себе опис конкретної функціональності, яку має
надавати фреймворк, з урахуванням взаємодії з елементами інтерфейсу та іншими
аспектами тестування WEB-сайтів. Нефункціональні вимоги, такі як
продуктивність, масштабованість та стійкість до помилок, також визначаються
для забезпечення високої якості та ефективності фреймворку. Процес включає
створення прототипів для візуалізації функціоналу та аналіз та перевірку вимог,
включаючи внутрішній аналіз та зустрічі з зацікавленими сторонами для
узгодження вимог та усунення можливих недорозумінь[39]. Завершальним етапом
є документування вимог у вигляді специфікацій, сценаріїв використання та інших
матеріалів, які служитимуть основою для подальшого проектування та розробки
фреймворку.
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги
Формування вимог до програмного забезпечення (ПЗ) - це критичний етап в
процесі розробки, який передбачає визначення потреб та очікувань щодо
функціональності та характеристик майбутнього продукту. Цей процес включає в
себе розробку як первинних, так і детальних вимог, які можуть бути розділені на
вимоги замовника та розробника[40]. Вимоги поділяються на функціональні та
нефункціональні, кожен з цих типів відображає різні аспекти вимог до
програмного забезпечення.
45
ЧДТУ 232208.011 ПЗ
1 Первинні вимоги - це високорівневі, загальні вимоги, що визначаються
на початковому етапі розробки і надають загальний контекст для роботи. Вони
визначають основні цілі та функціональність системи.
2 Детальні вимоги - це конкретні, докладні вимоги, що розширюють та
конкретизують первинні вимоги. Вони визначають, як саме буде реалізована
функціональність та які характеристики має мати програмне забезпечення.
3 Вимоги замовника визначаються на основі потреб та очікувань
замовника. Вони містять вимоги щодо функціональності, інтерфейсу користувача,
вимог до продуктивності та інші вимоги, які є ключовими для клієнта.
4 Вимоги розробника визначаються з огляду на технічні можливості та
ресурси, що доступні розробничій команді. Це може включати технічні стандарти,
архітектурні обмеження, вимоги до безпеки та інші технічні аспекти.
5 Функціональні вимоги визначають конкретні функції та операції, які
програмне забезпечення повинно виконувати[41]. Це може включати функції
користувача, операції обробки даних та інші аспекти.
6 Нефункціональні вимоги визначають нефункціональні аспекти системи,
такі як продуктивність, надійність, безпека, масштабованість та інші параметри,
які не є безпосередньо пов'язаними з функціональністю, але критичні для якості
системи.
3.2.2 Формування вимог за допомогою діаграми прецедентів
Опис:
1 Framework (Фреймворк):
– містить тестовий скрипт (TestScript).
– використовує браузер (Browser) для взаємодії з веб-сайтом.
2 TestScript (Тестовий скрипт):
– використовує об'єкт фреймворка (Framework).
– викликає методи тестової сторінки (TestPage) для тестування.
3 TestPage (Тестова сторінка):
– містить елементи веб-сторінки (WebElement).
46
ЧДТУ 232208.011 ПЗ
– взаємодіє з елементами для виконання дій (наприклад, натискання
кнопок).
4 WebElement (Елемент веб-сторінки):
– має методи для взаємодії з веб-елементами (наприклад, click,
sendKeys).
5 Browser (Браузер):
– відкриває веб-сторінку за вказаною URL-адресою.
– знаходить елементи на сторінці.
Ця діаграма прецедентів ілюструє взаємодію між основними компонентами,
що входять до процесу автоматизації тестування веб-сайту через фреймворк[42].
Рисунок 3.4 - Діаграма прецедентів фреймворку автоматизації тестування
Наведемо проміжний висновок до варіанів використання: представляють
основні етапи тестування у фреймворку автоматизованого тестування та
охоплюють процес розробки, виконання, підтримки та аналізу результатів
тестування програмного забезпечення.
3.2.3 Проектування логічної структури програмного комплексу
Якщо формування та аналіз вимог проектування – це розробка відповідної
47
ЧДТУ 232208.011 ПЗ
концептуальної моделі, яка описує усі можливі та прийнятні варіанти розв’язання
задач, які вказують, що повинна робити система, то проектування логічної
структури системи – це розроблення логічної моделі системи у вигляді моделі
класів і пакетів, які вказують з чого складається система[43]. Логічне
проектування ще називають детальним проектуванням класів.
3.2.3.1 Діаграма класів
На діаграмі класів для фреймворку автоматизації тестування веб-сайтів
представлені основні класи та їх взаємозв'язки.
Опис діаграми класів:
1 Клас TestFramework:
– Опис: Основний клас фреймворку, який відповідає за управління
тестовими випробуваннями та їх виконання.
– Атрибути:
– testCases: List<TestCase> - список тестових випробувань, що
належать до фреймворку.
– testSuites: List<TestSuite> - список тестових наборів, які також є
частиною фреймворку.
– Методи:
– + runAllTests(): void - виконує всі тестові випробування та тестові
набори.
– + addTestCase(testCase: TestCase): void - додає тестове випробування
до фреймворку.
– + addTestSuite(testSuite: TestSuite): void - додає тестовий набір до
фреймворку.
2 Клас TestCase:
– Опис: Клас, який представляє окреме тестове випробування.
– Атрибути:
– testName: String - назва тестового випробування.
– testSteps: List<String> - список кроків, які включаються до тесту.
– Методи:
48
ЧДТУ 232208.011 ПЗ
– + executeTest(): void - виконує тестове випробування.
3 Клас TestSuite:
– Опис: Клас, який представляє набір тестових випробувань.
– Атрибути:
– suiteName: String - назва тестового набору.
– testCases: List<TestCase> - список тестових випробувань, які
включені до набору.
– Методи:
– + addTestCase(testCase: TestCase): void - додає тестове
випробування до набору.
– + runSuite(): void - виконує всі тестові випробування в наборі.
4 Клас TestResult:
– Опис: Клас, який представляє результат тестового випробування.
– Атрибути:
– testCase: TestCase - тестове випробування, результат якого
представлено.
– status: String - статус виконання тестового випробування
(наприклад, "Passed" або "Failed").
5 Клас TestReporter:
– Опис: Клас, відповідальний за створення звітів про результати
тестового випробування.
– Методи:
– + generateReport(testResults: List<TestResult>): void - генерує звіт
на основі результатів тестових випробувань.
Взаємозв'язки:
Клас TestFramework містить тестові випробування (TestCase) і тестові
набори (TestSuite).
Клас TestSuite включає тестові випробування (TestCase) та використовує їх
під час виконання.
Клас TestFramework генерує результати тестових випробувань (TestResult).
49
ЧДТУ 232208.011 ПЗ
Клас TestReporter використовує результати тестових випробувань для
створення звітів.
Рисунок 3.5 - Діаграма класів
3.2.3.2 Діаграми пакетів
Опис пакетів:
1 TestFramework (головний пакет):
– Включає всі інші пакети, представляючи загальну структуру
фреймворку.
2 Core (основний функціонал):
– Включає класи, які відповідають за основний функціонал
фреймворку:
– TestExecutor: Виконує тестові сценарії.
– TestManager: Управління тестовими випробуваннями та
наборами.
3 Reporting (звітність):
– Містить класи, пов'язані з генерацією звітів та аналізом результатів
тестування:
– ReportGenerator: Створює звіти про результати виконання
тестових сценаріїв.
– TestReporter: Відповідає за створення та представлення звітів
50
ЧДТУ 232208.011 ПЗ
про тестування.
4 TestCases (тестові сценарії):
– Включає класи, які визначають тестові випробування та їх групи:
– TestCase: Клас, який представляє окремий тестовий сценарій.
– TestSuite: Група тестових випробувань.
5 Utilities (допоміжні утиліти):
– Містить класи, які забезпечують допоміжний функціонал для
фреймворку:
– BrowserController: Управління браузером для веб-тестування.
– TestDataLoader: Завантаження тестових даних.
Взаємозв'язки:
Core взаємодіє з усіма іншими пакетами, щоб виконати тестові сценарії,
генерувати звіти та взаємодіяти з тестовими випробуваннями та допоміжними
утилітами[44].
Ця діаграма пакетів надає вам візуальне уявлення про організацію
фреймворку автоматизації тестування та взаємозв'язки між його ключовими
компонентами.
Рисунок 3.6 - Діаграми пакетів
51
ЧДТУ 232208.011 ПЗ
3.2.4 Архітектурне проектування
3.2.4.1 Діаграма компонентів
Опис компонентів:
1 Test Executor (Виконавець тестів):
– Відповідає за виконання тестових сценаріїв та управління
виконанням.
2 Test Manager (Менеджер тестів):
– Використовується для управління тестовими випробуваннями та
взаємодії з Test Executor.
3 Test Reporter (Звітник тестів):
– Генерує звіти про результати тестування та взаємодіє з Test Executor
для отримання результатів.
4 Test Cases (Тестові сценарії):
– Група компонентів, які представляють окремі тестові випробування
та тестові набори.
5 Utilities (Допоміжні утиліти):
– Містить допоміжні компоненти, такі як Browser Controller для
управління браузером та Data Loader для завантаження тестових
даних.
Взаємозв'язки:
1 Test Executor взаємодіє з Test Manager для управління виконанням
тестових сценаріїв та отримання інструкцій для виконання.
2 Test Manager взаємодіє з Test Cases для управління тестовими
випробуваннями та наборами.
3 Test Reporter взаємодіє з Test Executor для отримання результатів
тестування та генерації звітів.
4 Utilities містить допоміжні компоненти, які використовуються в тестових
сценаріях.
Ця діаграма компонентів надає вам візуальне уявлення про структуру та
взаємозв'язки компонентів фреймворку автоматизації тестування.
52
ЧДТУ 232208.011 ПЗ
Рисунок 3.7 - Діаграма компонентів
3.2.4.2 Розгортання програмної системи на апаратних засобах.Діаграма
розгортання
Опис компонентів:
1 Test Machine (Тестова машина):
– Представляє фізичний апарат, на якому виконуються тести.
2 Test Framework (Тестовий фреймворк):
– Фреймворк для автоматизації тестування, який запускає тести на Test
Machine.
3 Web Server (Веб-сервер):
– Сервер, який взаємодіє з тестовим фреймворком та веб-застосунком.
4 Tested Application (Тестований застосунок):
– Веб-застосунок, який тестується.
Взаємозв'язки:
1 Test Machine використовує Test Framework для запуску тестів.
2 Test Framework автоматизує тести, комунікує з Web Server та взаємодіє з
Tested Application.
53
ЧДТУ 232208.011 ПЗ
3 Tested Application розгортана на Web Server та може бути доступна через
Інтернет.
Ця діаграма розгортання дозволяє вам візуально зрозуміти, як фізичні
компоненти системи взаємодіють між собою, як тести виконуються на тестовій
машині, та як веб-застосунок тестується на веб-сервері.
Рисунок 3.8 - Діаграма розгортання
3.2.5 Моделювання поведінки системи
3.2.5.1 Діаграма діяльності
Діаграм діяльності інтеграція з існуючими тестовими фреймворками
1 Початок процесу:
– Стартовий вузол, що позначає початок процесу інтеграції.
2 Аналіз потреб:
– Етап аналізу та збору вимог щодо інтеграції з існуючими тестовими
фреймворками. Це може включати визначення основних
функціональних вимог, специфікацію форматів вхідних та вихідних
даних.
3 Проектування інтеграції:
– Розроблення плану інтеграції, включаючи розробку внутрішніх
інтерфейсів, які спілкуються з тестовими фреймворками.
54
ЧДТУ 232208.011 ПЗ
4 Реалізація та тестування:
– Фаза розробки, де відбувається фактична інтеграція, налаштування
зв'язку з фреймворками, створення механізмів обміну даними.
5 Тестування і відлагодження:
– Фаза тестування, перевірка працездатності інтеграції, виявлення та
виправлення помилок.
6 Завершення процесу:
– Фінальний вузол, що позначає завершення процесу інтеграції.
– Кожен крок має відповідні дії, що виконуються в рамках цього етапу.
Будучи графічним представленням послідовності дій, діаграма діяльності
допомагає візуалізувати процес інтеграції з існуючими тестовими фреймворками
та розуміти послідовність подій, що відбуваються під час цього процесу.
Рисунок 3.9 – Діаграм діяльності
3.2.5.2 Діаграм послідовності
Фреймворк для автоматизованого тестування розроблюється для тестування
бізнес логіки додатку та виконання певних тестів спеціалістом. Діяльність
55
ЧДТУ 232208.011 ПЗ
тестувальника у межах фреймворку направлене на створення тестових наборів
даних, які подаються до системи у вигляді параметрів, описаних у текстовому
документі та розширення тестових наборів у тих випадках, коли необхідно
перевірити нову функціональність або додати нову валідацію, якщо попередня
логіка була змінена. Класично тестувальнику необхідно виконати також ряд дій
для виконання тестів: локально запустити тести та витрачати певний час на
виконання нібито автоматизованого процесу і вже після цього при отриманні
результатів або йти далі до наступних тестів, або лагодити тести, які не пройшли
та аналізувати причину. Схематично цей процес можна відобразити на діаграмі
послідовності, який зображено на рисунку 5. Звісно, такий процес не дуже
спрощує сам процес тестування, а спеціаліст витрачає майже стільки ж часу,
скільки б було витрачено на ручне тестування. Даний проект дозволяє вирішити
цю проблему за допомогою введення у процес тестування безперервної інтеграції
та паралелізації виконання тестів. Це спрощує саме тестування та зменшує
кількість витраченого часу, а також вартість виконання роботи. Користувач такої
системи буде аналізувати пройдені тести за результатами, які подаються як
вихідні дані процесу у вигляді звіту з параметрами пройдених тестів та тестів, які
не пройшли.
Рисунок 3.10 – Діаграм послідовності
3.2.5.3 Діаграма комунікації
Ця діаграма комунікації дозволяє вам показати взаємодію між різними
частинами системи під час тестування.
56
ЧДТУ 232208.011 ПЗ
Опис:
– Tester визначає тестовий набір та отримує результати тестування.
– Test Framework виконує тестовий випадок, отримує доступ до тестових
даних та повертає результати тестування.
– Test Case взаємодіє з тестовими даними та повідомляє результати
тестування фреймворку.
– Test Data містить тестові дані, які використовуються тестовим випадком.
– Web Application представляє тестирувану веб-застосунок, з яким може
взаємодіяти тестувальник.
Рисунок 3.11 – Діаграм комунікації.
3.2.5.4 Діаграма скінченного автомату
Таблиця 3.1
Опис діаграми скінченного автомату
57
ЧДТУ 232208.011 ПЗ
Назва тест-вимоги Опис тест-вимоги
Створення нового тестового сценарія Перевірити, що при внесенні скрипту
для тестового сценарію з анотацією
@Test з’являється можливість запуску
тестового сценарію
Додавання нових тестових даних Перевірити, що при створенні нового
файлу з тестовими даними, дані можуть
бути викликані за допомогою атрибутів
анотації @Test
Актуалізація тестового сценарію Перевірити, що при внесенні змін в
скрипт тестового сценарію залишається
можливість запуску тестового сценарію
Внесення змін в тестові набори Перевірити, що при зміні кількості
тестових сценаріїв в тестовому наборі,
запуск тестового набору відбудеться без
змін
Формування звіту проходження Перевірити, що після завершення
тестового набору виконання тестового набору і виконання
команди Site буде згенеровано звіт про
проходження останнього тестового
набору
Внесення змін в тестові дані Перевірити, що при внесенні змін в
тестові дані під час виконання
відповідного тестового сценарію будуть
використані нові тестові дані
Продовження таблиці 3.1
Запуск тестових наборів Перевірити, що при запуску тестового
набору через xml-файл всі тестові
58
ЧДТУ 232208.011 ПЗ
сценарії, що входять в тестовий набір
будуть запущені
Збереження інформації про запуск Перевірити, що після завершення
тестових наборі до бази даних виконання сценаріїв із тестового набору
в базі даних буде збережено інформацію
про тестові сценарії, набори та останню
сесію
Створення нового тестового набору Перевірити, що після формування xml-
файлу з посиланнями на тестові сценарії
під час запуску тестового набору будуть
запущені всі тестові сценарії
Рисунок 3.12 – Діаграма скінченного автомат
Висновки до третього розділу
59
ЧДТУ 232208.011 ПЗ
Проектуючи програму з використанням UML, використання різноманітних
діаграм дозволило зробити концепції та функціональності програмного продукту
більш доступними та зрозумілими. Діаграми використання послужили для чіткого
визначення того, як різні актори будуть взаємодіяти з системою, надаючи ясний
огляд її функцій. Діаграми класів визначили ключові класи, їхні властивості та
методи, встановлюючи основи програми. Діаграми послідовності відобразили
взаємодії та порядок операцій між об'єктами в часі, визначаючи виконання
системи на різних етапах. Діаграми діяльності дозволили ілюструвати етапи
виконання програми та визначити можливі альтернативи. Діаграми розгортання
зосередили увагу на апаратних засобах та конфігураціях, що сприяло ефективному
розгортанню програми. В цілому, використання діаграм UML стало невід'ємною
частиною процесу проектування, сприяючи кращому розумінню, моделюванню та
аналізу системи перед фактичною реалізацією програмного продукту.
60
ЧДТУ 232208.011 ПЗ
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
Для розробки архітектури власного фреймворку для автоматизації
тестування слід систематично ознайомитись із різноманітними інструментами,
підходами та патернами проектування, що використовуються у сфері
автоматизації тестування. Вибір конкретних інструментів і підходів повинен
відповідати конкретним потребам бізнесу, особливостям проекту, технічним
можливостям команди та майбутнім перспективам.
Важливо ретельно вивчити потреби бізнесу та особливості web-продукту,
для якого розробляється фреймворк, врахувати технічні можливості команди та
майбутні перспективи проекту. Дослідження різних мов програмування та
інструментів для автоматизації тестування, таких як Selenium, Appium, JUnit та
TestNG, дозволяє визначити оптимальний технологічний стек.
Ознайомлення з різними патернами проектування, такими як Page Object,
Singleton, Factory, сприяє полегшенню розробки та утримання коду фреймворку.
Розгляд принципів написання автотестів, таких як Arrange-Act-Assert (AAA) та
правило "DRY" (Don't Repeat Yourself), допомагає створити стійкі до змін та
надійні тести.
Також важливо розглядати можливості інтеграції фреймворку з системами
Continuous Integration / Continuous Deployment (CI/CD), щоб автоматизувати
тестування та розгортання. Цей стратегічний підхід дозволяє розробникам не
лише враховувати конкретні потреби проекту, але й гнучко реагувати на зміни в
життєвому циклі розробки, створюючи ефективний та адаптивний фреймворк для
автоматизації тестування web-продукту, в даному розділі розглядатимуться
основні принципи написання автотестів, а саме: на базі чого вони створюються,
які бувають, та інше.
4.1 Розробка програмного комплексу
4.1.1 Обґрунтування вибору засобів реалізації
61
ЧДТУ 232208.011 ПЗ
Вибір C# як мови програмування для реалізації фреймворку для тестування
UI з використанням Selenium WebDriver є обґрунтованим вибором. C# є однією з
основних мов програмування для веб-розробки, тому його використання полегшує
інтеграцію тестів з веб-технологіями та забезпечує єдність мови між тестами та
браузером за допомогою Selenium WebDriver.
Крім того, C# є асинхронною мовою, що дозволяє ефективно обробляти
асинхронні події на веб-сторінках, що є ключовим аспектом для тестування
динамічних елементів UI, таких як AJAX-запити.
Установка Maven є важливим етапом, оскільки Maven є потужним
інструментом для управління залежностями та збиранням проекту. Використання
Maven спрощує управління бібліотеками, такими як Selenium WebDriver, та
забезпечує консистентність та легкість управління проектом.
TestNG обрано для ефективного організовування та виконання тестів.
TestNG дозволяє визначати та виконувати тести згідно з необхідними сценаріями,
а також забезпечує гнучкість у конфігурації тестових сценаріїв та їх паралельне
виконання.
Загальна інтеграція C#, Selenium WebDriver, Maven та TestNG створює
потужний інструментарій для розробки та виконання автоматизованих тестів UI
для веб-сайтів, забезпечуючи зручність у реалізації, легкість управління та
ефективність виконання.
4.1.2 Опис структурної (функціональної) схеми
Фреймворк для автоматизації тестування веб-сайтів є комплексною
системою, яка включає ряд ключових компонентів, спрямованих на ефективне та
надійне тестування користувацького інтерфейсу. Структурна та функціональна
схема цього фреймворку може бути описана як ієрархічна система, що включає в
себе драйвер, клас для роботи з опціями браузера, клас для взаємодії з елементами
веб-сторінки, та безпосередньо сторінку, що тестується.
Драйвер виступає як центральна частина системи, взаємодіючи із веб-
браузером та забезпечуючи інтерфейс для виконання різноманітних дій на веб-
сторінцях. Клас для роботи з опціями браузера дозволяє управляти
62
ЧДТУ 232208.011 ПЗ
налаштуваннями браузера, забезпечуючи гнучкість та налаштовуваність для
різних умов тестування.
Клас для взаємодії з елементами веб-сторінки відповідає за роботу з
конкретними елементами, такими як кнопки, текстові поля, чекбокси тощо. Цей
клас дозволяє зручно взаємодіяти з кожним елементом сторінки та виконувати
різні дії, що є ключовим аспектом автоматизованого тестування.
Безпосередньо сторінка, яку тестує фреймворк, визначає конкретну
структуру та групування елементів, а також визначає їхню взаємодію. Це дозволяє
визначити тестові сценарії для конкретних сторінок веб-сайту та реалізувати їхнє
автоматизоване тестування. Загалом, структурна та функціональна організація
цього фреймворку створює базу для ефективного та пристосованого до потреб
тестування веб-сайтів.
Структурна схема для розроблюваної системи виглядає наступним чином:
Рисунок 4.1 ‒ Структурна схема
63
ЧДТУ 232208.011 ПЗ
Функціональна схема для розроблюваної системи виглядає наступним
чином:
Рисунок 4.2 ‒ Функціональна схема
Розглядаючи структурну та функціональну схему фреймворку для
автоматизації тестування веб-сайтів, можна визначити його гнучку та добре
організовану архітектуру. Драйвер, що виступає як центральний компонент,
забезпечує ефективну взаємодію з браузером та виконання різноманітних
тестових сценаріїв. Клас для роботи з опціями браузера надає можливість
налаштовувати параметри браузера, що робить фреймворк адаптованим до різних
умов тестування.
Клас для взаємодії з елементами сторінки спрощує роботу з конкретними
елементами веб-сторінки та дозволяє ефективно виконувати тестові сценарії.
Систематичне групування та визначення сторінок, які тестуються, визначає
якісний підхід до автоматизованого тестування.
В цілому, фреймворк для автоматизації тестування веб-сайтів виявляється
добре структурованим та готовим до використання у реальних умовах. Він
дозволяє забезпечити якісне та ефективне тестування веб-додатків, зменшуючи
трудомісткість та покращуючи стабільність тестових сценаріїв.
64
ЧДТУ 232208.011 ПЗ
4.1.3 Опис логічної схеми системи
Логічна схема системи розглядає послідовність дій та взаємодію її ключових
компонентів. У відповідності з описом алгоритму функціонування системи. Опис
логічної схеми буде подано у текстовому форматі, а також буде надана графічна
інтерпретація у вигляді блок-схеми алгоритму.
Опис логічної схеми:
1 Ініціалізація:
– старт програми автоматизованого тестування.
– ініціалізація драйвера та необхідних налаштувань.
2 Завантаження сторінки:
– відкриття веб-браузера з вказаною адресою веб-сайту.
– очікування завантаження сторінки.
3 Виконання тестового сценарію:
– зчитування тестового сценарію з файлу або іншого джерела.
– ініціація виконання послідовності тестових дій.
4 Взаємодія з елементами сторінки:
– використання класу для роботи з елементами сторінки для взаємодії
з веб-елементами (клік, заповнення форм, перевірка тексту тощо).
5 Збір результатів тестування:
– запис результатів тестового сценарію (пройдено, не пройдено,
помилки).
– збір статистики та іншої інформації про виконання тестування.
6 Завершення тестування:
– закриття веб-браузера.
– завершення програми автоматизованого тестування.
65
ЧДТУ 232208.011 ПЗ
Рисунок 4.3 ‒ Логічна схема
Ця логічна схема та блок-схема алгоритму відображають основні етапи
функціонування системи автоматизованого тестування веб-сайту. Кожен крок
послідовно виконується, створюючи ефективний та структурований процес
тестування.
4.1.4 Розробка бази даних
Вирішенням не використовувати базу даних у фреймворку для автоматизації
тестування є кілька ключових факторів. По-перше, простота тестових сценаріїв
визначається їхньою обмеженою складністю, такими як кліки, заповнення форм і
перевірка тексту на веб-сторінках. У такому випадку зберігання тестових даних
безпосередньо у коді фреймворку є зручним та ефективним рішенням.
Додатково, якщо в проекті не потрібно зберігати історію тестування та
аналізувати результати тестування протягом тривалого періоду, то можна
уникнути використання бази даних. Результати тестування можуть легко
зберігатися локально або у файлих без залучення додаткових інфраструктурних
компонентів. Такий підхід спрощує архітектуру фреймворку та полегшує
66
ЧДТУ 232208.011 ПЗ
управління тестовими ресурсами, зменшуючи витрати на розгортання та
обслуговування.
4.1.5 Розробка інтерфейсу користувача
Selenium — це переносна платформа для тестування програмного
забезпечення веб-додатків. Selenium надає засіб запису для автоматизації тестів
без необхідності вивчення мови сценаріїв, наприклад, Selenium IDE. Selenium
складається з різноманітних програмних інструментів, кожен із яких має свій
підхід до автоматизації тестування. Багатство доступних інструментів дозволяє
інженерам обирати ті, що найбільше відповідають їх завданням, проте вивчення
всіх інструментів надасть різні підходи до автоматизації тестування.
Інженери, зазвичай, зосереджуються на одному чи двох інструментах, що
найбільше відповідають їх завданням, але вивчення всіх цих інструментів
дозволяє отримати різноманітні підходи до вирішення різних завдань
автоматизації тестування. Повний набір інструментів для тестування забезпечує
багатий функціонал, спеціально розроблений для тестування веб-додатків.
Операції повністю адаптовані, що надає багато можливостей для пошуку
елементів інтерфейсу користувача та порівняння очікуваних результатів
тестування з фактичною поведінкою додатка.
Однією з важливих функцій Selenium є підтримка виконання тестів на різних
платформах браузерів. Selenium використовується в основному для
функціонального тестування веб-додатків і може бути ефективним у середовищі
безперервної інтеграції та гнучкого тестування. Це безкоштовне програмне
забезпечення, яке підтримує операційні системи Windows, Mac і Linux. Selenium
підтримує широкий спектр мов програмування, таких як Java, Ruby, Perl, PHP, C#
і Python.
67
ЧДТУ 232208.011 ПЗ
Рисунок 4.1 – Тестування сторінки документації Selenium
Selenium IDE - це інтегроване середовище розробки для створення та
виконання тестових сценаріїв. Цей компонент дозволяє легко записувати,
редагувати та відтворювати тести без потреби в програмуванні скриптів.
4.1.6 Опис розробки програмних компонентів
1 Selenium IDE:
Selenium IDE - це інтегроване середовище розробки для створення та
виконання тестових сценаріїв. Цей компонент дозволяє легко записувати,
редагувати та відтворювати тести без потреби в програмуванні скриптів.
2 Селен РЦ (Selenium RC):
Selenium RC - це застарілий компонент фреймворку, який забезпечує
можливість виконання тестових сценаріїв на різних браузерах. Проте, оскільки
Selenium RC більше не рекомендується для використання, розробники перейшли
на використання Selenium WebDriver.
3 Веб-драйвер Selenium:
Selenium WebDriver - це ключовий компонент, що надає програмний
інтерфейс для взаємодії з різними браузерами. Використовуючи WebDriver,
68
ЧДТУ 232208.011 ПЗ
можна автоматизувати взаємодію з елементами веб-сторінок, виконувати дії
користувача та перевіряти стан веб-додатків.
4 Сітка селену:
Сітка селену (Selenium Grid) - це інструмент, який дозволяє розподілити
виконання тестових сценаріїв на кількох машинах або пристроях одночасно. Це
дозволяє прискорити виконання тестів та перевіряти додатки на різних
конфігураціях.
Ці компоненти утворюють комплексний інструментарій для ефективної
автоматизації тестування веб-додатків за допомогою Selenium.
4.1.6.1 Опис компонентів
1 Recorder (Записувач): Selenium IDE починає свою роботу як записувач,
який дозволяє інженерам тестування записувати свої взаємодії з веб-сторінкою.
Користувачі можуть виконувати різні дії (натискання, заповнення форм,
переміщення мишею і т. д.), а Selenium IDE автоматично записує ці дії в тестовий
сценарій.
2 Playback (Відтворення): Selenium IDE дозволяє відтворювати записані
тестові сценарії. Під час відтворення IDE автоматично взаємодіє з браузером,
виконуючи ті самі дії, які були записані під час створення тесту.
3 Test Case Panel (Панель тестового сценарію): Компонент, який
дозволяє користувачам створювати, редагувати і організовувати свої тестові
сценарії. Тут вони можуть змінювати порядок виконання команд, додавати або
видаляти етапи тестування, а також використовувати умови та цикли.
4 Command Menu (Меню команд): Selenium IDE містить меню команд,
яке містить широкий спектр доступних команд для введення в тестовий сценарій.
Користувачі можуть вибирати необхідні команди для виконання різних дій.
5 Log Panel (Панель журналу): Відображає вивід тестового виконання та
будь-які помилки чи повідомлення, які можуть виникнути під час відтворення
тесту.
6 Reference and Documentation (Довідка та документація): Selenium IDE
має вбудовану довідку та документацію, яка надає інформацію про різн
69
ЧДТУ 232208.011 ПЗ
і команди та можливості фреймворку.
7 Export Options (Опції експорту): Компонент, що дозволяє
експортувати записані тестові сценарії у різні мови програмування, такі як Java,
Python, C#, щоб вони могли бути використані з Selenium WebDriver для
складніших автоматизованих тестів.
4.1.6.2 Опис методів
Методи у контексті Selenium IDE — це вбудовані команди або дії, які можна
використовувати для запису та відтворення тестових сценаріїв. Ось кілька
основних методів, доступних в Selenium IDE:
1 Open: driver.get("https://example.com");
Команда "Open" використовується для відкриття вказаної URL-адреси в
браузері. Вона записується під час взаємодії зі сторінкою в процесі запису.
2 Click: driver.findElement(By.id("buttonId")).click();
Метод "Click" використовується для натискання на вказаному елементі
сторінки, такому як кнопка, посилання чи інший взаємодіючий елемент.
3 Type: driver.findElement(By.name("username")).sendKeys("exampleuser");
Команда "Type" використовується для введення тексту в текстове поле або
інший елемент форми.
4 Verify/Assert: assert.equal(actualText, expectedText, "Text on the page.");
Методи "Verify" і "Assert" використовуються для перевірки різних умов або
станів елементів на сторінці. "Verify" продовжує виконання тесту навіть у випадку
невдалої перевірки, тоді як "Assert" завершить тест у випадку невдачі.
5 Wait: wait = new WebDriverWait(driver, 10);
Elementwait.until(ExpectedConditions.presenceOfElementLocated(By.id("elem
entId")));
Команда "Wait" дозволяє вставити паузу у виконання тестового сценарію на
певний період часу. Використовується для очікування завантаження елементів чи
інших асинхронних подій.
6 Store: pageTitle = driver.getTitle();
70
ЧДТУ 232208.011 ПЗ
Метод "Store" використовується для збереження значень або тексту в
змінній, яке можна використовувати пізніше в тестовому сценарії.
7 Echo: console.log("Page Title: " + pageTitle);
Команда "Echo" виводить повідомлення чи значення на консоль, що
допомагає при відлагодженні тестових сценаріїв.
8 Run Script:
Команда "Run Script" дозволяє вставити власний код C# безпосередньо в
тестовий сценарій.
9 MouseOver/MouseOut:
Команди "MouseOver" і "MouseOut" використовуються для наведення та
зняття фокусу миші від певного елемента веб-сторінки.
Ці методи використовуються для визначення дій та перевірок у тестових
сценаріях і надають користувачам зручний спосіб автоматизувати взаємодію з
веб-сторінками через інтерфейс Selenium IDE
4.2 Тестування системи
Системне тестування – основним завданням є перевірка як функціональних
так і не функціональних вимог у системі в цілому. При цьому виявляються
дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації
даних рівня користувача, несумісність з оточенням, непередбачені сценарії
використання, відсутня або невірна функціональність, незручність використання і
т.д. Для мінімізації ризиків, пов’язаних з особливостями поведінки системи в тому
чи іншому середовищі [19].
(requirements based) – Для кожної вимоги пишуться тестові випадки (test cases),
перевіряючі виконання даної вимоги.
(use case based) – На основі уявлення про способи використання продукту
створюються випадки використання системи (Use Cases). По конкретному
випадку використання можна визначити один або більше сценаріїв. На перевірку
кожного сценарію пишуться тест кейси (test cases), які повинні бути протестовані.
4.2.1 Модульне тестування
71
ЧДТУ 232208.011 ПЗ
Юніт-тести - це частина тестування програмного забезпечення, яка перевіряє
окремі компоненти програми на коректність їх роботи. В даному випадку, клас
Calculator протестований за допомогою юніт-тестів для переконання, що його
методи вірно виконують математичні операції та обробляють винятки, якщо це
необхідно.
Юніт-тести допомагають забезпечити, що окремі частини програми працюють
вірно, і вони часто використовуються в процесі розробки для автоматизованої
перевірки функціоналу.
Рисунок 4.6 ‒ Приклад модульного тесту
У даному коді створено клас Calculator у межах простору імен ClassLibrary1,
який містить статичні методи для виконання простих математичних операцій.
Клас містить чотири основні методи: Add для додавання двох чисел, Remove для
віднімання одного числа від іншого, Multiply для множення чисел та Divide для
ділення першого числа на друге. Особливість методу Divide полягає в перевірці на
можливість ділення на нуль, і в разі виявлення спроби ділення на 0 генерується
виняток DivideByZeroException з відповідним повідомленням.
72
ЧДТУ 232208.011 ПЗ
4.2.2 Інтеграційне тестування
Інтеграційне тестування - це вид тестування, при якому перевіряється
відповідність вимог інтеграції модулів, їх взаємодія між собою, а також інтеграція
підсистем у єдину загальну систему. Для проведення інтеграційного тестування
використовувались компоненти, які вже були перевірені за допомогою
модульного тестування і групуються у множини. Ці множини перевіряються
відповідно до складеного для них плану тестування, а їх об'єднання здійснюється
через визначені інтерфейси.
Рисунок 4.7 – Приклад інтеграційного тесту
Цей код представляє набір тестів за допомогою фреймворку для тестування
NUnit. Кожен тест має три основні частини: Arrange, Act та Assert.
Ці тести допомагають гарантувати, що методи класу Calculator працюють
правильно та обробляють виняткові ситуації, такі як ділення на нуль.
4.2.3 Системне тестування
73
ЧДТУ 232208.011 ПЗ
Системне тестування (System Testing) — це етап тестування програмного
забезпечення, під час якого перевіряється весь інтегрований продукт для
підтвердження того, що він відповідає вимогам та специфікаціям. Системне
тестування проводиться після завершення усіх інших етапів тестування, таких як
модульне тестування та інтеграційне тестування.
Рисунок 4.8 – загальне тестування
Повідомленя засвідчує, що процес збирання (build) в даному проекту
виконався успішно.
Загальний підсумок проекту успішно зібраний (1 succeeded), немає помилок
(0 failed), всі файли актуальні (0 up-to-date), і нічого не пропущено (0 skipped).
Отже, процес збирання пройшов успішно, і можна використовувати
зібраний файл classlibrary1.dll для подальшого використання.
4.2.4 Приймальне тестування
Приймальне тестування користувача - це тип тестування, що здійснюється
клієнтом для сертифікації системи відносно вимог, узгодженням заздалегідь.
Проводиться тестування на заключному етапі тестування, перш ніж переносити
74
ЧДТУ 232208.011 ПЗ
програмне забезпечення в ринкову або виробниче середовище. Клієнт виконує цей
тип тестування в окремому середовищі (аналогічної виробничому середовищі) и
підтверджує, чи відповідає система технічним вимогам.
Таблиця 4.1
Тестування
Тест Тест
№ Тест Опис тесту
пройдено провалено
1 Додавання Юніт-тест +
2 Ділення Юніт-тест +
3 Ділення на нуль Юніт-тест +
Ділення числа на
4 Юніт-тест +
нуль
Інтеграція з
5 іншими Системне тестування +
компонентами
6 Продуктивність Системне тестування +
7 Сумісність з Системне тестування +
іншими
системами
4.3 Приклади впровадженого програмного комплексу
75
ЧДТУ 232208.011 ПЗ
Цей калькулятор, реалізовано у вигляді бібліотеки на мови програмування
C#, надає основні математичні операції, такі як додавання, віднімання, множення
та ділення. Бібліотека містить статичний клас Calculator, який надає методи для
виконання цих операцій. При цьому реалізована обробка винятків для випадку
ділення на нуль.
Також, код тестів, використовує фреймворк для автоматизованого
тестування Selenium. Ці тести перевіряють правильність роботи методів
калькулятора через його веб-інтерфейс. Вони включають тест на додавання, тест
на ділення, тест на ділення на нуль та тест на ділення числа на нуль. Тестовий код
допомагає впевнитися, що функції калькулятора працюють коректно та
взаємодіють із зовнішнім інтерфейсом, яким керує Selenium.
Рисунок 4.3-Список файлів каталогу
На рисунку 4.3 представляє собою список файлів та каталоги, які
створюються інтегрованим середовищем розробки (IDE) Visual Studio на мові
програмування C#.
76
ЧДТУ 232208.011 ПЗ
1 idea: Цей каталог, містить конфігураційні файли для редактора чи
інструментів розробки.
2 vs: Цей каталог, містити файли налаштувань для Visual Studio, такі як
файли відображення та налаштування розробки.
3 vscode: Каталог, який використовується для зберігання налаштувань для
Visual Studio Code, альтернативного редактора коду від Microsoft.
4 ClassLibrary1: каталог "ClassLibrary1". Тут, розміщені файли проекту,
такі як код, ресурси та інші складові.
5 ClassLibrary1.sln: файл рішення проекту містить інформацію про всі
компоненти. Він містить відомості про всі проекти, які входять до рішення, У
ньому вказані налаштування розробки для проекту, а також залежності та
взаємозв'язки між компонентами.
Лістинг 4.3 конфігураційний файл проекту для платформи .NET,
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.4.1" />
<PackageReference Include="NUnit" Version="3.13.3" />
<PackageReference Include="NUnit.ConsoleRunner" Version="3.16.2" />
<PackageReference Include="NUnit3TestAdapter" Version="4.3.1" />
<PackageReference Include="Selenium.Support" Version="4.7.0" />
<PackageReference Include="Selenium.WebDriver" Version="4.7.0" />
<PackageReference Include="Selenium.WebDriver.ChromeDriver"
Version="109.0.5414.7400" />
</ItemGroup>
77
ЧДТУ 232208.011 ПЗ
</Project>
Цей файл представляє собою конфігураційний файл проекту для платформи
.NET, написаний за допомогою формату SDK від Microsoft. Дозволяє визначити
параметри та залежності проекту, що є важливим для його збірки та виконання.
Важливі елементи цього файлу включають:
<TargetFramework>: Вказує цільовий фреймворк для проекту, в даному
випадку, .NET Core версії 3.1. Це визначає середовище, для якого призначений цей
проект.
<ItemGroup>: Група елементів проекту, де оголошуються залежності від
пакетів NuGet, які використовуються у проекті. Зокрема, вказані пакети для
тестування (NUnit), автоматизованого тестування веб-додатків (Selenium), а також
пакет для взаємодії з браузером Chrome через Selenium.
Цей файл є важливим елементом розробки на платформі .NET, визначаючи
параметри та залежності проекту, необхідні для забезпечення його коректного
функціонування та взаємодії з іншими складовими системи.
Рисунок 4.4 - опис структури рішення
78
ЧДТУ 232208.011 ПЗ
Опис Рішення та Проекту "Class library 1":
Рішення ("Solution classlibrary1"): Рішення є контейнером для організації та
управління одним або кількома проектами в середовищі Visual Studio. Є рішення
з назвою "Solution classlibrary1", яке, об'єднує пов'язані проекти для спільної
розробки та управління залежностями між ними.
Проект ("Class library 1"): Проект "Class library 1" представляє собою
бібліотеку класів, написану на мові програмування C#. Бібліотеки класів
використовуються для організації та групування коду для подальшого
використання у інших проектах. У цьому проекті знаходяться код, ресурси та інші
складові, необхідні для реалізації функціональності.
Залежності та Пакети: Проект використовує пакети NuGet для додавання
додаткового функціоналу та бібліотек до коду. Серед цих пакетів вказані
Microsoft.NET.Test.Sdk для тестування, NUnit для підтримки тестів, Selenium для
автоматизованого тестування веб-додатків, а також пакети, пов'язані з браузером
Chrome.
Файли проекту: Вказані два файли, "C# calculator.cs" та "C# class1.cs", які,
містять код для проекту. Файл "C# calculator.cs" містить реалізацію калькулятора
та інші обчислювальні функції, тоді як "C# class1.cs" містить інші класи та код,
необхідних для роботи бібліотеки класів.
В цьому проекті використовується .NET, NUnit для тестування, Selenium для
автоматизованого тестування веб-додатків та містять код для класів і
калькулятора.
Код представляє собою набір тестів, реалізованих за допомогою
фреймворку для тестування NUnit у мові програмування C#.
Розглянемо кожен тест та його призначення:
1 AddTest:
Опис: Тест перевіряє правильність роботи методу Add з класу Calculator.
Arrange: Задає початкові значення a та b.
Act: Викликає метод Add для обчислення суми a + b.
79
ЧДТУ 232208.011 ПЗ
Assert: Перевіряє, отримане значення відповідає очікуваному результату чи
ні a + b.
2 DivisionTest:
Опис: Тест перевіряє правильність роботи методу Divide з класу Calculator.
Arrange: Задає початкові значення a та b для ділення.
Act: Викликає метод Divide для обчислення a / b.
Assert: Перевіряє, отримане значення відповідає очікуваному результату чи
ні a / b.
3 DivisionTestByZero:
Опис: Тест перевіряє, чи метод Divide викидає виняток
DivideByZeroException при діленні на нуль.
Arrange: Задає значення a і b так, що b = 0.
Act: Викликає метод Divide для спроби ділення на нуль.
Assert: Використовує блок try-catch для перевірки винятку. Якщо виняток є
DivideByZeroException, тест успішний.
4 DivisionTestDivideZero:
Опис: Тест перевіряє правильність роботи методу Divide з класу Calculator
при діленні нуля.
Arrange: Задає значення a і b так, що a = 0.
Act: Викликає метод Divide для обчислення a / b.
Assert: Перевіряє, отримане значення відповідає очікуваному результату a /
b.
Лістинг 4.4 Фреймворк для тестування NUnit,
using NUnit.Framework;
using System;
namespace ClassLibrary1
public class Class1
{
[Test]
80
ЧДТУ 232208.011 ПЗ
public void AddTest()
{
//Arrange
double a=2, b=3;
//Act
double result = Calculator.Add(a, b);
//Assert
Assert.AreEqual(a + b, result);
}
[Test]
public void DivisionTest()
{
//Arrange
double a = 4, b = 4;
//Act
double result = Calculator.Divide(a, b);
//Assert
Assert.AreEqual(a / b, result);
}
[Test]
public void DivisionTestByZero()
{
try
{
//Arrange
double a = 6, b = 0;
//Act
double result = Calculator.Divide(a, b);
}
catch (DivideByZeroException)
81
ЧДТУ 232208.011 ПЗ
{
Assert.Pass("Expected Divide by zero exception cought");
}
catch (Exception)
{
Assert.Fail("Wrong exception cought");
}
}
[Test]
public void DivisionTestDivideZero()
{
//Arrange
double a = 0, b = 4;
//Act
double result = Calculator.Divide(a, b);
Console.WriteLine(result);
//Assert
Assert.AreEqual(a / b, result);
}
}
}
Ці тести служать для перевірки правильності роботи функцій класу
Calculator, забезпечуючи визначення очікуваних результатів та виявлення
неправильної поведінки за допомогою фреймворку для тестування NUnit.
82
ЧДТУ 232208.011 ПЗ
Висновки до четвертого розділу
У процесі виконання магістерської роботи було вивчено та випробувано
інструменти автоматизації тестування, зокрема використано фреймворк для
тестування NUnit на платформі C# в середовищі Visual Studio з використанням
Selenium. Розроблений тестовий фреймворк дозволив демонструвати
ефективність автоматизованого тестування взаємодії з елементами веб-сторінок та
різними браузерами.
В результаті проведеного дослідження технологій та практик автоматизації
тестування було розглянуто та випробувано різні інструменти та підходи до
написання тестових скриптів. Створений приклад фреймворку для автоматизації
був використаний для демонстрації тестування взаємодії з базовими
компонентами веб-сторінок, вкладками, вікнами браузера та модальними вікнами.
Використання NUnit як фреймворку для тестування забезпечило зручний і
ефективний спосіб написання та виконання тестових сценаріїв, а мова
програмування C# разом з Selenium надали потужний інструментарій для
взаємодії з веб-елементами та керування браузерами. Результати тестів були
відображені у вигляді високоякісних перевірок функціоналу, а також виявлення
можливих помилоку веб-додатка.
Важливим висновком є те, що, незважаючи на переваги автоматизації, вона
не є універсальним рішенням, і перед її впровадженням потрібно уважно
оцінювати проблеми, які вона допомагає вирішити. Проаналізований час
виконання тестів, що в окремих випадках автоматизація може бути неефективною
та призводити до додаткових витрат.
Отримані результати можуть бути використані як навчальний матеріал для
тестувальників різного рівня досвіду та в якості основи для подальших досліджень
у напрямку автоматизації тестування на рівні API.
83
ЧДТУ 232208.011 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю
Основы инженерии качества программных систем. – 2-е изд., перераб. и доп.
– К.: Академпериодика, 2007. – 672 с.
2 Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование
программного обеспечения: Пер.с англ.-М.: Изд-во: Лори, 2003. – 592 с.
3 Тестування программного забезпечення: [Електрон. ресурс]. / Режим
доступу:http://moodle.chdu.edu.ua/course/view.php?id=1021
4 Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю
Основы инженерии качества программных систем. – 2-е изд., перераб. и доп.
– К.: Академпериодика, 2007. – 672 с.
5 Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование
программного обеспечения: Пер.с англ.-М.: Изд-во: Лори, 2003. – 592 с.
6 Тестування програмного забезпечення: [Електрон. ресурс]. / Режим
доступу:http://moodle.chdu.edu.ua/course/view.php?id=1021
7 Laplante, Phil (2009). Requirements Engineering for Software and Systems (вид.
1st). Redmond, WA: CRC Press. ISBN 1-42006-467-3. Архів оригіналу за 8
липень 2011. Процитовано 28 жовтень 2010.
8 McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules
(вид. 1st). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
9 Wiegers, Karl E. (2003). Software Requirements (вид. 2nd). Redmond, WA:
Microsoft Press. ISBN 0-7356-1879-8.
10 Andrew Stellman and Jennifer Greene (2005). Applied Software Project
Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
11 Brian Berenbach, Daniel Paulish, Juergen Katzmeier, Arnold Rudorfer (2009).
Software & Systems Requirements Engineering: In Practice. New York:
McGraw-Hill Professional. ISBN 0-07-1605479.
12 Walter Sobkiw (2008). Sustainable Development Possible with Creative System
Engineering. New Jersey: CassBeth. ISBN 0615216307
84
ЧДТУ 232208.011 ПЗ
13 Автоматизоване тестування. База знань. QaLight: Центр підготовки IT
фахівців: вебсайт. URL: https://qalight.ua/baza-
znaniy/avtomatizovanetestuvannya/.
14 IEEE. Guide to the Software Engineering Body of Knowledge. SWEBOK, 2004.
335
15 Ручне та автоматизоване тестування. База знань. QaLight: Центр підготовки
IT
16 фахівців: вебсайт. URL: https://qalight.ua/baza-znaniy/ruchne-ta-
avtomatizovanetestuvannya.
17 International Software Testing Qualifications Board. ISTQB Certification –
Foundation Level syllabus, ISTQB. 2023. 74 p.
18 Ляшенко Дарʼя. Автоматизоване тестування UI: стисло про головне.
2021.Codeguida: вебсайт. URL: https://codeguida.com/post/2881.
19 Тестування UI (інтерфейсу користувача). Блог. 2021. Wezom: вебсайт. URL:
https://wezom.com.ua/ua/blog/testing-ui-user-interface.
20 Рівні тестування URL:
https://qalearning.com.ua/theory/lectures/material/testing-levels/
21 Bach J (2003) Exploratory testing explained. http://www.satisfice.com/articles/et-
article.pdf
22 Ahonen J, Junttila T, Sakkinen M (2004) Impacts of the organizational model on
testing: Three industrial cases. Empirical Software Engineering 9(4):275–296
23 Hartman A (2002) Is issta research relevant to industry? SIGSOFT Software
Engineering Notes 27(4):205–206
24 Goodenough JB, Gerhart SL (1975) Toward a theory of test data selection.
SIGPLAN Notes 10(6):493– 510
25 Briand LC (2007) A critical analysis of empirical research in software testing. In:
Proceedings of the 1st International Symposium on Empirical Software
Engineering and Measurement (ESEM’07), IEEE Computer Society,
Washington, DC, USA
85
ЧДТУ 232208.011 ПЗ
26 Електронний ресурс. Groovy Language Documentation http://docs.groovy-
lang.org/latest/html/documentation/
27 Java SE Specifications. [Електронний ресурс]. — URL:
https://docs.oracle.com/javase/specs/
28 Каллан Р., Основные концепции нейронных сетей / М. [и др.] : Вильямс —
2001. — 287 с.
29 Фомин Я. А. Распознавание образов: теория и применения / 2-е изд. М.:
ФАЗИС, — 2012. — 429 с.
30 Галушкин А.И., Теория нейронных сетей / М.: Горячая линия-Телеком, —
2010. — 496 с.
31 Гленфорд Майерс, Том Баджетт, Кори Сандлер. Искусство тестирования
программ, 3-е издание = The Art of Software Testing, 3rd Edition. — М.:
Диалектика, — 2012. — 272 с.
32 Бейзер Б. Тестирование чёрного ящика. Технологии функционального
тестирования программного обеспечения и систем / СПб.: Питер, — 2004.
— 320 с.
33 Automated GUI Testing: A Step by Step Guide. [Електронний ресурс]. —
URL: https://www.ukad-group.com/blog/automated-gui-testing-a-step-by-step-guide/
34 Python’s standard documentation. [Електронний ресурс]. — URL:
https://www.python.org/about/
35 Марк Лутц. Программирование на Python / Пер. с англ. 4-е изд. СПб.:
Символ-Плюс, — 2011. — 992 с.
36 MySQL 5.6 Reference Manual. [Електронний ресурс]. — URL:
https://dev.mysql.com/doc/refman/5.6/en/what-is-mysql.html
37 Мэтт Зандстра. PHP: объекты, шаблоны и методики программирования =
PHP Objects, Patterns and Practice, Third Edition / 3-е издание. М.: «Вильямс»,
— 2010. — 560 с.
38 Alexei White. Major JavaScript Engines // JavaScript Programmer's Reference.
Indianapolis. — 2009. — 998 с.
86
ЧДТУ 232208.011 ПЗ
39 An open source machine learning framework for everyone. [Електронний
ресурс]. — URL: https://www.tensorflow.org/
40 Коэльё Л. П., Ричерт В. Построение систем машинного обучения на языке
Python / 2-е изд. - М.: ДМК Пресс, — 2016. — 302 с.
41 Selenium IDE. [Електронний ресурс]. — URL:
https://www.seleniumhq.org/projects/ide/
42 Katalon Automation Recorder Quickstart. [Електронний ресурс]. — URL:
https://www.katalon.com/resources-center/blog/katalon-automation-recorder/
43 Automated testing with Selenium and Cucumber. [Електронний ресурс]. —
URL: https://www.ibm.com/developerworks/library/a-automating-ria/
44 F Houdek DE T Schwinn (2002) Defect detection for executable specifications –
An experiment. International Journal of Software Engineering and Knowledge
Engineering 12(6):637–655
45 Hartman A (2002) Is issta research relevant to industry? SIGSOFT Software
Engineering Notes 27(4):205–206
46 Itkonen J, M¨antyl¨a M, Lassenius C (2013) The role of the tester’s knowledge in
exploratory software testing. IEEE Transactions on Software Engineering
39(5):707–724
47 Juristo N, Moreno A, Vegas S (2004) Reviewing 25 years of testing technique
experiments. Empirical Software Engineering 9(1):7–44
48 Kamsties E, Lott CM (1995) An empirical evaluation of three defect detection
techniques. In: Proceedings of the 5th European Software Engineering Conference
(ESEC’95), Springer-Verlag, London, UK, pp 362–383
87
ЧДТУ 232208.011 ПЗ
Додаток А
Затверджено:
Зав. кафедрою ПЗАС, д.т.н., проф.
__________________ Голуб С.В.
Фреймворк для автоматизації тестування WEB-сайту
Специфікація
482.ЧДТУ 232208-01
Листів 2
Розробник: __________ Кисліченко Я.В.
Керівник: ___________ Заспа Г.О.
Черкаси 2023
88
ЧДТУ 232208.011 ПЗ
Позначення Найменування Примітки
482.ЧДТУ 232208-12 01 Лістинг програми
482.ЧДТУ 232208-34 01 Інструкція користувача
482.ЧДТУ 232208-90 01 Презентація
89
ЧДТУ 232208.011 ПЗ
Додаток Б
Фреймворк для автоматизації тестування WEB-сайту
Лістинг програми
482.ЧДТУ 232208-12-01
Листів 3
Розробник: __________ Кисліченко Я.В.
Черкаси 2023
90
ЧДТУ 232208.011 ПЗ
using NUnit.Framework;
using System;
namespace ClassLibrary1
{
public class Class1
{
[Test]
public void AddTest()
{
//Arrange
double a=2, b=3;
//Act
double result = Calculator.Add(a, b);
//Assert
Assert.AreEqual(a + b, result);
}
[Test]
public void DivisionTest()
{
//Arrange
double a = 4, b = 4;
//Act
double result = Calculator.Divide(a, b);
//Assert
Assert.AreEqual(a / b, result);
}
91
ЧДТУ 232208.011 ПЗ
[Test]
public void DivisionTestByZero()
{
try
{
//Arrange
double a = 6, b = 0;
//Act
double result = Calculator.Divide(a, b);
}
catch (DivideByZeroException)
{
Assert.Pass("Expected Divide by zero exception cought");
}
catch (Exception)
{
Assert.Fail("Wrong exception cought");
}
}
[Test]
public void DivisionTestDivideZero()
{
//Arrange
double a = 0, b = 4;
//Act
double result = Calculator.Divide(a, b);
92
ЧДТУ 232208.011 ПЗ
Console.WriteLine(result);
//Assert
Assert.AreEqual(a / b, result);
}
}
}
93
ЧДТУ 232208.011 ПЗ
Додаток В
Фреймворк для автоматизації тестування WEB-сайту
Інструкція користувача
482.ЧДТУ 232208-34 01
Листів 2
Розробник: __________ Кисліченко Я.В,
Черкаси 2023
94
ЧДТУ 232208.011 ПЗ
Для автоматизації тестування веб-сайтів на C#, потрібно використовувати
бібліотеку Selenium з .NET. Нижче подано коротку інструкцію:
Крок 1: Створення проекту
Створіть новий проект C# в інтегрованій середовищі розробки (IDE), такій
як Visual Studio або Visual Studio Code.
Крок 2: Встановлення Selenium
Встановіть пакет Selenium.WebDriver за допомогою менеджера пакетів
NuGet. Використовуйте Package Manager Console або додайте пакет через
менеджер пакетів вашої IDE. Введіть у консолі або додайте в файл проекту:
bashCopy code
Install-Package Selenium.WebDriver
Крок 3: Завантаження та встановлення драйвера браузера
Завантажте драйвер для браузера, (наприклад, ChromeDriver, geckodriver для
Firefox, або EdgeDriver для Microsoft Edge). Розпакуйте його і додайте шлях до
виконуваного файлу драйвера до системної змінної PATH.
Крок 4: Написання тестового коду
Введіть код тесту в основний файл. Наприклад, якщо я використовула
Chrome:
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
class Program {
static void Main() {
// Ініціалізація драйвера браузера (в даному випадку - Chrome)
IWebDriver driver = new ChromeDriver();
// Відкриття веб-сайту
driver.Navigate().GoToUrl("https://www.example.com");
// Додайте тестові сценарії тут
// Закриття браузера
driver.Quit();
95
ЧДТУ 232208.011 ПЗ
}
}
Крок 5: Додавання тестових сценаріїв
Вставте тестові сценарії між
driver.Navigate().GoToUrl("https://www.example.com"); та driver.Quit();.
Наприклад:
// Знаходження елемента за ідентифікатором і введення тексту IWebElement
searchBox = driver.FindElement(By.Id("searchInput"));
searchBox.SendKeys("Selenium Tutorial");
// Клацання на кнопку пошуку
searchBox.Submit();
Крок 6: Запуск тестів
Запустити проект. Він має відкрити браузер, відкрити веб-сайт та виконати
тестові сценарії.
96
ЧДТУ 232208.011 ПЗ
Додаток Г
Фреймворк для автоматизації тестування WEB-сайту
Презентація
482.ЧДТУ 232208-90-01
Листів 6
Розробник: ____________ Кисліченко Я.В.
Черкаси 2023
97
ЧДТУ 232208.011 ПЗ
Рисунок Г.1 Слайд 1 ‒ Тема роботи
Рисунок Г.2 Слайд 2 ‒ Вступ
98
ЧДТУ 232208.011 ПЗ
Рисунок Г.3 Слайд 3 ‒ Дослідження
Рисунок Г.4 Слайд 4 ‒ Архітектурне проектування
99
ЧДТУ 232208.011 ПЗ
Рисунок Г.5 Слайд 5 ‒ Діаграма прецедентів
Рисунок Г.6 Слайд 6 ‒ Засоби реалізації
100
ЧДТУ 232208.011 ПЗ
Рисунок Г.7 Слайд 7 ‒ Тестування системи
Рисунок Г.8 Слайд 8 ‒ Модульне тестування
101
ЧДТУ 232208.011 ПЗ
Рисунок Г.9 Слайд 9 ‒ Висновки
Рисунок Г.10 Слайд 10 ‒ Дякую за увагу
102