Розробка методу та програмного забезпечення для підготовки даних при тестуванні складних програмних систем

Молчан, Ігор Валерійович

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

Title:	Розробка методу та програмного забезпечення для підготовки даних при тестуванні складних програмних систем
Authors:	Олексюк, Вадим Володимирович Молчан, Ігор Валерійович
Keywords:	JSON;XML;CSV;SDK
Issue Date:	2024
Abstract:	Молчан І.В, кваліфікаційна робота магістра на тему: «Розробка методу та програмного забезпечення для підготовки даних при тестуванні складних програмних систем», Спеціальність: 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2023 Дана дипломна робота присвячена розробці програмного забезпечення, спрямованого на вирішення проблеми генерації даних для тестування складних програм. Програмне забезпечення розрахована на два основних типи користувачів: тестувальників, які займаються тестуваннями програм та розробники, які ці програми розробляють. У розробників та у тестувальників отримують можливість згенерувати дані з тими типами, які їм потрібні для тестування системи, а також ці дані можна зберегти на комп’ютер та пере використовувати для подальших тестувань.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9097
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Files in This Item:

File	Description	Size	Format
Молчан Ігор.pdf Restricted Access		3.42 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем

ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень

на тему: Розробка методу та програмного забезпечення для підготовки
даних при тестуванні складних програмних систем

Виконав: студент 2 курсу, групи МПЗ-2204
Напряму підготовки
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)

Студент Молчан І.В
(прізвище та ініціали)
Керівник Олексюк В.В
(прізвище та ініціали)
Рецензент
(прізвище та ініціали)

Черкаси 2023
ЧДТУ 2216.020 ПЗ

Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення

ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С.В.
«___» _______________ 2023 року

З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Молчан Ігор Валерійович
(прізвище, ім’я, по батькові)
1.Тему проекту (роботи) Розробка методу та програмного забезпечення для підготовки даних
при тестуванні складних програмних систем
Керівник проекту (роботи) Олексюк Вадим Володимирович доктор філософії
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 06 » жовтня
2023 року №267/04
2. Строк подання студентом проекту (роботи) 15 грудня 2023 р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ризиками проекту;
управління ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ; Існуючі методи та засоби розв’язання поставлених завдань; Теоретичні та
експериментальні дослідження; Впровадження результатів досліджень у практику
проектування програмного забезпечення інформаційних систем; Розробка та тестування
програмного забезпечення; Висновки; Список використаних джерел; Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Г.1. Слайд 1, Г.2. Слайд 2, Г.3. Слайд 3, Г.4. Слайд 4, Г.5. Слайд 5, Г.6. Слайд 6, Г.7. Слайд 7, Г.8.
Слайд 8, Г.9. Слайд 9, Г.10. Слайд 10, Г.11. Слайд 11, Г.12. Слайд 12, Г.13. Слайд 13, Г.14. Слайд
14, Г.15. Слайд 15, Г.16. Слайд 17, Г.18. Слайд 18, Г.19. Слайд 19.

6
ЧДТУ 2216.020 ПЗ

6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3

7. Дата видачі завдання 04 вересня 2023 р.

КАЛЕНДАРНИЙ ПЛАН
Строк
№ виконання
Назва етапів випускної роботи Примітки
п/п етапів випускної
роботи
1 Постановка задачі 02.09.2023 виконано
2 Підготовка завдання 13.09.2023 виконано
3 Погодження завдання 16.09.2023 виконано
4 Затвердження завдання 19.09.2023 виконано
Основна стадія
1 Підбір матеріалів 27.09.2023 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.10.2023 виконано
3 Розрахунок основних параметрів роботи 10.10.2023 виконано
4 Вибір кінцевого варіанту проектного рішення 17.10.2023 виконано
5 Оформлення первісної редакції роботи 25.10.2023 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.10.2023 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.11.2023 виконано
кінцевій редакції
3 Попередній захист роботи 15.11.2023 виконано
4 Затвердження роботи 02.12.2023 виконано
5 Рецензування роботи 06.12.2023 виконано
6 Захист роботи 15.12.2023 виконано

Студент _____________________ Молчан І.В
(підпис) (прізвище та ініціали)

Керівник проекту (роботи) _____________________ Олексюк В.В
(підпис) (прізвище та ініціали)

7
ЧДТУ 2216.020 ПЗ

ЗМІСТ

ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ........................................ 8
ВСТУП ......................................................................................................................... 9
РОЗДІЛ 1 - ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................... 14
1.1 Generateddata ............................................................................................. 15
1.2 Mockaroo .................................................................................................... 18
1.3 DTM data Generator ................................................................................... 21
1.4 Порівняльна характеристика систем генерації тестових даних…….. 30
РОЗДІЛ 2 - ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ........ 34
2.1 Теоретичні дослідження ................................................................................ 34
2.1.1 Цільова функція ..................................................................................... 35
2.1.2 Підготовка тестових даних ................................................................... 37
2.2. Експериментальні дослідження ................................................................... 38
2.2.1 Тестування на основі даних ................................................................. 40
2.2.2 Аналіз методів генерації тестових даних ............................................ 43
2.2.3 Генетичний алгоритм для генерації тестових даних ......................... 48
2.2.4 Опис задачі генерації тестових даних в термінах генетичного
алгоритму ........................................................................................................ 51
2.2.5 Обмеження ............................................................................................. 51
2.2.6 Схрещування .......................................................................................... 52
2.2.7 Мутація ................................................................................................... 53
2.2.8 Алгоритм для генерації тестових даних ............................................. 54
РОЗДІЛ 3 - ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ................................................................................ 60
3.1 Моделювання предметної області ................................................................ 60
8
ЧДТУ 2216.020 ПЗ
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області ............................................................... 60
3.1.2 Елементи моделювання предметної області ...................................... 63
3.1.3 Робоча область моделювання .............................................................. 63
3.2 Формування та аналіз вимог .......................................................................... 63
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні
та нефункціональні вимоги ................................................................. 63
3.2.2 Формування вимог за допомогою діаграми прецедентів .................. 66
3.2.3 Проектування логічної структури програмного комплексу ............. 67
3.2.3.1 Діаграми класів ............................................................ 67
3.2.3.2 Діаграми пакетів .......................................................... 70
3.2.4 Архітектурне проектування .................................................................. 71
3.2.4.1 Діаграма компонентів ................................................. 72
3.2.4.2 Розгортання програмної системи на апаратних
засобах. Діаграма розгортання ............................................................ 73
3.2.5 Моделювання поведінки системи ....................................................... 75
3.2.5.1 Діаграма діяльності ..................................................... 75
3.2.5.2 Діаграма послідовності ............................................... 78
3.2.5.3 Діаграма комунікації ................................................... 79
3.2.5.4 Діаграма скінченного автомату .................................. 79
РОЗДІЛ 4 - РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ...................................................................................................... 81
4.1 Розробка програмного комплексу ................................................................. 81
4.1.1 Обґрунтування вибору засобів реалізації ........................................... 81
4.1.2 Опис структурної (функціональної) схеми ........................................ 83
4.1.3 Опис логічної схеми системи .............................................................. 85
4.1.4 Розробка бази даних ............................................................................. 87
9
ЧДТУ 2216.020 ПЗ
4.1.5 Розробка інтерфейсу користувача ....................................................... 87
4.2 Тестування системи ........................................................................................ 88
4.2.1 Модульне тестування ........................................................................... 89
4.2.2 Інтеграційне тестування ....................................................................... 90
4.2.3 Системне тестування ............................................................................ 92
4.2.4 Приймальне тестування ....................................................................... 93
4.3 Приклади впровадженого програмного комплексу .................................... 95
ВИСНОВКИ .............................................................................................................. 98
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................... 100

10
ЧДТУ 2216.020 ПЗ

ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
JSON (JavaScript Object Notation) – текстовий формат обміну даними,
заснований на основі мови JavaScript;
XML (Extensible Markup Language) – розширена мова розмітки. Текстовий
формат для обміну даними;
CSV (Comma Separated Values) – значення, розділені комою;
SDK (Software Development Kit) – комплект розробки програмного
забезпечення. Набір із засобів розробки, утиліт і документації;

11
ЧДТУ 2216.020 ПЗ

ВСТУП
Актуальність теми: Розробка методів підготовки даних для тестування
складних програм залишається актуальною. Процес розробки програмного
забезпечення стає все більш складним через зростання складності програм,
великі об’єми даних, необхідність повного тестування та стрімкий розвиток
технологій.
Деякі аспекти, які підтримують актуальність цієї теми, такі:
- швидкий прогрес технологій: Нові архітектури програм, методи
розробки та методи обробки даних створюються завдяки прогресу в
технологіях. Це вимагає постійного удосконалення інструментів і
методів тестування.
- великі об’єми даних: Оскільки обсяг і різноманітність даних
збільшуються, необхідні ефективні засоби підготовки для тестування,
щоб враховувати всі потенційні сценарії використання даних.
- автоматизація тестування: Оскільки підходи DevOps та Continuous
Integration/Continuous Deployment (CI/CD) стають все більш
поширеними, стає необхідним автоматизувати тестування, включаючи
автоматичну підготовку тестових даних[1].
- завдання якості: Гарантія якості продукту залишається однією з
основних цілей розробки програм, і ефективна підготовка даних
необхідна для досягнення високої якості програмного забезпечення.
Зв’язок роботи з науковими програмами, планами, темами
- Зв’язок із навчальними програмами: Результати цієї роботи будуть
включені до наукових програм, які спрямовані на розробку та
покращення методів тестування програмних систем. Для забезпечення
12
ЧДТУ 2216.020 ПЗ
ефективності та достовірності тестів у складних умовах методи
підготовки даних мають стратегічне значення.
- Сполучення з науковими планами: Розробка методів підготовки даних і
програмного забезпечення буде відповідати завданням та цілям
наукових планів, спрямованих на покращення процесів тестування та
забезпечення високої якості програм.
- Зв’язок із темою дослідження: У контексті тестування складних
програмних систем тема роботи прямо пов’язана з дослідженням
методів підготовки даних. Метою дослідження буде виявлення
найкращих методів і розробка програмного забезпечення, яке може
автоматизувати цей процес.
- Тематика, яка є важливою: Для покращення якості тестів у складних
умовах, де можуть виникати різні сценарії тестування, важливо
розробити ефективний метод підготовки даних і програмне
забезпечення. Це відповідає вимогам і труднощам, які виникають на
сучасному програмному ринку.
- Практичне застосування: Результати дослідження можуть бути
корисними для великих і складних програмних проектів, де підготовка
даних для тестування є трудомістким завданням. Це підвищить
ефективність тестування.
Таким чином, робота відповідає сучасним вимогам до методів і
інструментів тестування, а її висновки можуть значно вплинути на розвиток цієї
наукової галузі.
Мета і завдання дослідження: Метою дослідження є розробка
ефективної стратегії та програмного забезпечення для підготовки даних під час
тестування складних програмних систем. Основна увага приділяється
автоматизації та оптимізації процесу підготовки тестових даних відповідно до
складних умов тестування.
13
ЧДТУ 2216.020 ПЗ
Задача дослідження:
- аналіз існуючих методів: Аналізуйте поточні методи та інструменти
підготовки тестових даних для складних програмних систем. Визначте
як їхні переваги, так і їхні недоліки.
- визначення потреб: Визначте, що потрібно для підготовки тестових
даних для складних програмних систем. Зрозуміти основні труднощі, з
якими стикаються тестируючі команди.
- розробка стратегії: винайти новий підхід до підготовки тестових
даних, який враховує характеристики складних програмних систем.
Забезпечити можливість створення широкого спектру тестових
сценаріїв.
- розробка програмного забезпечення: Розробка методу визначає
реалізацію програмного забезпечення. Забезпечте зручний інтерфейс і
можливість інтеграції з інструментами для тестування, які вже
існують.
- перевірки та експерименти: Розроблені методи та програмне
забезпечення повинні бути протестовані на реальних проектах або в
контрольованих середовищах. Аналізуйте результати різних підходів.
- удосконалення та оптимізація: Зробити оптимізацію та вдосконалення
програмного забезпечення та методів на основі результатів тестування.
гарантувати високу надійність і швидкість підготовки тестових даних.
Об’єкт дослідження: Дослідження стосується процесу підготовки даних
під час тестування складних програмних систем. Ця процедура є складною та
важливою частиною процесу розробки програмного забезпечення, оскільки
правильність та якість тестових даних значною мірою впливають на
ефективність виявлення помилок і відповідність програми вимогам.
Предмет дослідження: Методи та програми для ефективної підготовки
даних під час тестування складних програм.
14
ЧДТУ 2216.020 ПЗ
Методи дослідження: Аналіз наукових статей, книг та інших джерел,
щоб отримати повне розуміння методів підготовки тестових даних і
програмного забезпечення для тестування. Дослідження вимог до тестових
даних, а також поточних практик підготовки їх для використання в реальних
проектах і програмних системах. Створення прототипу процесу та програмного
забезпечення, необхідних для підготовки тестових даних для детального
дослідження та експериментування. Проведення експериментів, щоб оцінити
ефективність і продуктивність методу, розробленого, порівняно з існуючими
рішеннями.
Наукова новизна одержаних результатів: Удосконалено метод генерації
тестових даних методом випадкової генерації шляхом розширення кількості
типів та параметрів для полів даних, що дало можливість генерувати дані
максимально подібні до реальних.
Практичне значення одержаних результатів: Удосконалений метод
дозволяє швидше та ефективніше генерувати тестові дані, що сприяє
збільшенню швидкості та ефективності виконання тестових сценаріїв, а також
збільшенню кількості типів та параметрів для полів даних, що забезпечує
максимальну подібність тестових даних до реальних умов роботи програмної
системи. Це покращує реальність тестування та дає більш точні результати.
Особистий внесок автора: Розробка та оптимізація алгоритмів для
ефективної генерації тестових даних різних типів і форматів були важливими.
Це включало вивчення сучасних методів генерації та те, як змінити їх
відповідно до вимог проекту. Розширення набору типів даних і параметрів для
полів було внеском автора, що забезпечило більшу гнучкість і універсальність
при створенні тестових даних.
Автор взяв на себе відповідальність за проведення експериментів для
оцінки ефективності, продуктивності та реальності методу, який було
15
ЧДТУ 2216.020 ПЗ
розроблено. Це включало дослідження та аналіз результатів експерименту, щоб
знайти його переваги та місця для вдосконалення.
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Система генерації тестових даних — це спеціалізований програмний
інструмент, який створює тестові дані для використання в тестуванні
програмних продуктів. Для досягнення бажаного результату дані можуть бути
як випадковими, так і спеціально обраними. Основним завданням системи є
зниження ризиків програмного продукту, зниження фінансових витрат і,
головним чином, підвищення якості продукту. Тестові дані, текстові вхідні дані
та об’єктні форми (XML, JSON, SQL) є результатами роботи системи.
Завантаження, тестування продуктивності, стрес-тестування та тестування
баз даних полегшуються системами генерації тестових даних. За допомогою
даних інструментів можна створювати дані в інших базах даних. Деякі
інструменти також можуть захистити базу даних, замінюючи конфіденційні
дані фіктивними. У той же час інструмент зберігає особисті дані. Крім того, ці
інструменти дозволяють виводити дані, які були створені, у сценарії SQL[2].
Таким чином, ці інструменти надзвичайно корисні для тестування та розробки
програм.
Тестові дані — це вхід, який надає програма. Він показує дані, які
впливають на виконання певного модуля. Позитивне тестування використовує
деякі дані, щоб переконатися, що набір вхідних даних для певної функції дає
очікуваний результат. Для негативного тестування, наприклад, для перевірки
здатності програми обробляти незвичайний, екстремальний, винятковий або
несподіваний внесок, можна використовувати додаткові дані. Проблема
генерування якості тестових даних вважається важливою швидко, ефективно та
точно, оскільки тестування є трудомістким процесом і становить майже третину
витрат на розробку системи. Неправильні дані тестування можуть не перевірити
16
ЧДТУ 2216.020 ПЗ
всі потенційні сценарії тестування, що може призвести до зниження якості
програмного забезпечення.
Без цих інструментів тестування навантаження, продуктивності та стресу
практично неможливо. Ці інструменти економлять час і прості у використанні.
Це не тільки економить час на створення сценаріїв, але й полегшує генерацію
даних. Багато даних можна створити за допомогою кількох простих кліків.
Тестовий генератор даних може створювати дані або випадкові, або
структуровані та відформатовані. Оскільки бази даних часто зберігають дані у
вигляді таблиць і стовпців, структуровані дані, як правило, більш корисні, ніж
випадкові дані.
Генератори тестових даних виконують ряд завдань, включаючи створення
графіку потоку управління програмою, вибір маршруту та генерацію тестових
даних.
Дані, призначені для проходження шляху, обраного селектором,
створюються генератором тестових даних після визначення шляху тестування.
Це досягається за допомогою математики.
Багато програм можуть виконувати складні функції, наприклад цілісність
референції, зовнішній ключ, значення Unicode та NULL. Незважаючи на те, що
безкоштовні та відкриті інструменти не надають всі функції, які вам потрібні, ці
компанії також пропонують додаткові функції за певні витрати. Тестові дані,
реальні та фіктивні, включають граничні значення, некоректні значення та
порожні дані.
У продажу є різні системи для генерації тестових даних, які доступні як
безкоштовно, так і за плату. Тим не менш, коли ви обираєте інструмент, ви
повинні враховувати такі речі, як методи генерування даних, підтримка різних
типів даних, підтримка операційної системи, вартість та інші фактори.
1.1 Generatedata
17
ЧДТУ 2216.020 ПЗ
Інструмент, який називається генерація даних, є відкритим кодом. Він
використовує PHP, JavaScript і MySQL. Він надасть вам три варіанти під час
встановлення, з яких вам потрібно буде вибрати один. Ці параметри включають
кілька облікових записів, один обліковий запис користувача з входом і один
обліковий запис користувача.
Є кілька способів створити необхідні тестові дані. Наприклад, ви можете
вибрати тип експорту файлу. Це дуже зручно, оскільки підтримує
найпоширеніші типи, такі як XML, JSON SQL і CSV (рис 1.1).

Рис. 1.1 – Вибір типу файлу для експорту

Використання даних визначає формат, який вони будуть
використовувати. Наприклад, ви повинні вибрати Excel, якщо ці дані
використовуються для облікових цілей, тоді як у тестах використовується
JSON, XML або SQL.У головному вікні є такі опції:
- формат даних;
- приклад заповнення;
- шаблон телефону;
- назва колонки, яка буде використана як «ключ».
18
ЧДТУ 2216.020 ПЗ
Спробуємо згенерувати тестові дані, заповнивши необхідні опції,
оскільки інтерфейс легко зрозуміти (рис. 1.2).

Рис. 1.2 – Заповнення даних для тестової генерації

Для генерації тестових даних було обрано формат JSON, а чотири поля
були заповнені: ім’я, електронна пошта, дата та місто. Крім того, є можливість
вибрати структуру типу даних JSON. Слід відмітити, що для різних полів
необхідно генерувати багато тестових даних. Наприклад, поле «ім’я» має
19
ЧДТУ 2216.020 ПЗ
багато шаблонів, які починаються з прізвища та закінчуються ім’ям, або
навпаки. Рис. 1.3 показує приклад генерації тестових даних.

Рис. 1.3 – Приклад результату генерації тестових даних у форматі JSON

Крім того, дані можна відображати в інших форматах, таких як XML
(рис. 1.5). Недоліком є те, що в даній системі опція «Назва колонки» повинна
бути тільки латиницею, коли ви вибираєте формат XML. Хоча сам формат
дозволяє використовувати будь-які символи.
1.2 Mockaroo
Mockaroo — це система, яка дозволяє створювати випадкові тестові дані.
Згідно з рис. 1.4, однією з переваг даної системи є те, що вона дозволяє
створювати певний відсоток пустих полів (NULL), якщо це необхідно. Крім
20
ЧДТУ 2216.020 ПЗ
того, на відміну від операційних систем Unix (LF) і Windows (CRLF), ця
система має можливість вибрати тип закінчення рядка.

Рис. 1.4 – Вибір кількості згенерованих пустих полів у відсотковому
відношенні

Данна система підтримує генерацію тестових даних до 1000 рядків.
Система підтримує основні формати даних, але також підтримує текстові
формати, такі як Firebase та Tab-Delimited. Крім того, система містить багато
шаблонів для різних сфер діяльності (рис. 1.5). Це зручно, оскільки можна
автоматично завантажити дані в потрібний формат, не роблячи цього вручну.

21
ЧДТУ 2216.020 ПЗ

Рис. 1.5 – Шаблони тестових даних різних сфер діяльності
Оберемо тип CSV, та згенеруємо штучні дані (рис.1.6).

22
ЧДТУ 2216.020 ПЗ
Рис. 1.6 – Результати роботи системи Mockaroo

Дані будуть створені за допомогою шаблонів, встановлених програмою.
Крім того, перед завантаженням система дозволяє переглядати створені дані в
двох різних форматах: попередній огляд і заданий формат. Слід зазначити, що
створюються якісні дані, які більше схожі на реальні.
Одним із великих переваг даної системи є те, що її можна
використовувати в коді за допомогою API. Рис. 1.7 показує приклад
документації. Це конкретний приклад системи, яку використовують сучасні
тестові програми. Однак єдиним недоліком цієї програми є те, що вона все ще
не має абстракції та прив’язки до об’єктів. Таким чином, необхідно написати
додатковий код, щоб приєднати випадкові дані до об’єктів, які будуть
використані безпосередньо в автоматизованих тестах.

Рис. 1.7 – Документація до API системи Mockaroo

1.3 DTM data Generator
23
ЧДТУ 2216.020 ПЗ
DTM data Generator генерують реалістичні та надійні великі дані, які
використовуються для тестування навантаження та працездатності об’єктів
тестування . Дані створюються за допомогою легко налаштованої моделі
метаданих і можна експортувати в плоскі файли, бази даних, XML або CSV.
Прикладна програма, добре структурована документація та набір SDK для
роботи в коді входять до цієї системи.
DTM data generator надає рядки даних і об’єкти схеми для тестування,
включаючи тестування сукупності баз даних, аналіз якості та виконання тестів
для завантаження. Генератор даних DTM був розроблений для того, щоб
інженери та розробники могли отримувати якісні, реалістичні тестові масиви.
Він автоматично генерує значення даних і непотрібні об’єкти схеми, такі як
таблиці, представлення даних, процедури та тригери.

24
ЧДТУ 2216.020 ПЗ

Рис. 1.8 – Головне вікно прикладної програми DTM data Generator

Більшість баз даних, які підтримуються системою, включають Microsoft
SQL Server, Oracle, IBM DB2, Sybase, Informix, MySQL і PostgreSQL.
Спочатку необхідно підключити необхідний сервер бази даних. Всі
драйвери, необхідні для зв’язку з базами даних, вже встановлені в програмі, як
показано на рис. 1.9.
Далі можна налаштувати свої правила (rules) для кожної таблиці та
колонки за допомогою своєрідного провайдера.
25
ЧДТУ 2216.020 ПЗ

Рис. 1.9 – Робота з підключеною базою даних

Для кожної таблиці та колонки Далі можна налаштувати свої правила
(rules), працюючи зі своєрідним провайдером (рис. 1.10). Шаблон, який
необхідно створити для генерації тестових даних, називається правилами.

26
ЧДТУ 2216.020 ПЗ

Рис. 1.10 – Створення правила за замовчуванням

Крім того, система використовується для тестування продуктивності,
включаючи:
- стрес-тестування, яке передбачає різке навантаження системи;
- тестування продуктивності, яке передбачає аналіз швидкості
відповіді в різних ситуаціях;
- тестування навантаження, яке передбачає поступове навантаження
системи.
Пропускна здатність, пам’ять і час відповіді можна аналізувати
системою.
Налаштування тесту навантаження за допомогою утиліти BLOB Loader,
утиліти даної системи, яка дає змогу робити навантаження на систему з
великою кількістю згенерованих тестових даних, показано на рис. 1.11.
27
ЧДТУ 2216.020 ПЗ

Рис. 1.11 – Налаштування BLOB Loader Utility на тестування
навантаженості

GS Data Generator — це автоматизований інструмент для генерації
тестових даних, який допомагає розробникам і тестувальникам. Компанія GS
пропонує три видання генератора даних: Standard, Pro та Enterprise.
Стандартне видання призначено для тестування продуктивності та
завантаження проектів, які є основними. Про-версія призначена для складних
проектів і підтримує ERP, CRM та інтеграцію. Розробникам програмного
забезпечення та консалтинговим компаніям допомагає Enterprise Edition.
28
ЧДТУ 2216.020 ПЗ
Генератор також може працювати в режимі відладки. Це дуже зручно,
коли потрібно поступово заповнювати тестові об’єкти та аналізувати
результати під час процесу відладки.

Рис. 1.12 – Приклад проекту у програмі GS Data Generator

Це цікаво, що інтерфейк програми досить простий. Однак у порівнянні з
вищезазначеними системами відразу помітно обмеження на генерацію даних.
Наприклад, існує обмеження щодо вибору типу тестових даних.
Основним елементом DTM Data Generator є правила, які можна задавати,
як і в системі. Одним із переваг даної системи є те, що вона може одночасно
підтримувати зв’язок для кількох об’єктів, як показано на малюнку 1.13.
29
ЧДТУ 2216.020 ПЗ

Рис. 1.13 – Підтримка декількох зв’язків програмі GS Data Generator

Шаблони генерації можна встановити для баз даних (рис. 1.14).

Рис. 1.14 – Введення шаблонів для бази даних у програмі GS Data
Generator
30
ЧДТУ 2216.020 ПЗ
Однією з можливостей програми є те, що ви можете додавати свої
шаблони до вбудованих тестових даних, які можна змінювати в майбутньому.
Ці шаблони можна включити в розділ словника(dictionary). Деревовидна
структура з тестовими даними представлена в розділі (рис. 1.15).

Рис. 1.15 – Вбудований словник у програмі GS Data Generator

Зразу слід зазначити, що ця система не є абстрактною і її слід
використовувати лише для конкретних цілей.
Крім того, є один значний недолік: деякі дані виходять за межі програми,
що ускладнює ідентифікацію верхньої та нижньої межі прийнятого діапазону
даних. Такі поняття, як «класи еквівалентності» та «граничні значення», є тими,
які зазвичай досліджуються під час тестування. Отже, коли програма обирає
діапазон граничних значень (максимально допустиме валідатне або невалідатне
число) під час певного тесту, вона іноді виходить за рамки і дає збій, що
31
ЧДТУ 2216.020 ПЗ
негативно впливає на очікувані результати. Щоб використовувати будь-яку
мову програмування для обробки даних, необхідно мати свій API. Заповнення
вручну шаблону текстових полів показано на рис. 1.16.

Рис. 1.16 – Заповнення вручну тестових полів у програмі GS Data
Generator

Крім того, є можливість одночасно підтримувати кілька підключень
(sessions) і логування дій. На рис. 1.17 показано дії, які здійснив тестувальник,
а результат дій показано в «Деталях сесії»(Session Details).

Рис. 1.17 – Заповнення вручну тестових полів у програмі GS Data Generator
32
ЧДТУ 2216.020 ПЗ
1.4 Порівняльна характеристика систем генерації тестових даних
Порівняльна таблиця була створена на основі аналізу функціональних
можливостей розглянутих систем (таблиця 1.1).
Таблиця 1.1
Порівняльна таблиця систем генерації тестових даних
Можливості Назва системи
системи Generatedata Mockaroo DTM data GS Data
Generator Generator
Генерація + + + –
реалістичних даних
тестування
Підтримка багатьох XML, JSON SQL, CSV, CSV, SQL, Access, Excel,
форматів даних SQL, CSV JSON, Excel XML, Excel SQL
Підтримка API – + – –
Комплект власного – – + –
SDK
Генерація даниx для + – + +
БД
Обмеження генерації 500 записів 1000 Необмежена Необмежена к-
тестових даних записів к-сть сть записів
записів
Шаблони для різних + + + –
сфер
Генерація тестових <5 сек <5 сек <10 сек <10 сек
даних (100 записів)

Таким чином, системи, наведені вище, об’єднані в одну ціль —
33
ЧДТУ 2216.020 ПЗ
генерацію тестових даних. У той час як деякі системи призначені для роботи з
базами даних, інші орієнтовані на роботу з різними видами діяльності. Деякі з
цих систем мають API або SDK.
Основним недоліком даних систем є те, що вони прикріплені до певних
цілей. У програмуванні добре відомо, що модулі верхнього рівня не повинні
залежати від модулів нижнього рівня; замість цього обидва повинні залежати
від абстракцій. Наприклад, потрібно вручну створювати дані та підставляти їх
у тести; інакше одну з систем не можна взяти і одразу підключити до тестів.
Це є непотрібною тратою часу для масштабів великого програмного продукту.
Навіть якщо витратити час на налаштування певних тестів, не факт, що
структура програмного продукту не зміниться з часом і тести не потрібно буде
міняти; як наслідок, необхідно повторно налаштувати тести.
Система Mockarro, яка надає API для роботи в коді, вирішує цю
проблему.

34
ЧДТУ 2216.020 ПЗ
Висновки до розділу
У першому розділі були розглянуті найпопулярніші cистеми генерації
тестових даних у різних предметних областях, включаючи Generatedata,
Mockaroo, DTM data generator і GS data generator.
Після оцінки їхніх функціональних можливостей були визначені їхні
переваги та недоліки. Порівнявши існуючі системи генерації тестових даних,
можна зробити висновок, що вони досить схожі, а відмінності лежать в
основному в сфері та предметі використання. Основні відмінності включають
можливість працювати з різними типами даних, можливість працювати з
базами даних, можливість створювати тестові дані за формулами, підтримку
певних операційних систем і наявність SDK.
Переваги існуючих систем генерації тестових даних включають те, що
майже кожна система працює з різними форматами даних; у деяких системах є
можливість прямого підключення до баз даних; у деяких системах є шаблони
тестових даних для певних країн; і в деяких системах є SDK.
Недоліками систем генерації тестових даних є такі: немає тестового
постачальника даних, який би автоматично підставляв дані в тести;
тестувальник створює надлишковий код, що вимагає написання надлишкового
коду; і генерація тестових даних не завжди є якісною, оскільки вона
наближається до реальних даних.
Було досліджено структуру систем генерації тестовиx даних, і на основі
цього було створено структурну схему та схему взаємодії модулів. У
структурній схемі показано комплекс функціональних завдань, комплекс
розв’язуваних завдань, функціональну структуру та засоби інформаційних
технологій, включаючи методичні (API), інформаційні (бази даних), програмні
(Data Provider, Test Runner, програмні платформи) та алгоритмічні (методи
генерації тестових даних).
35
ЧДТУ 2216.020 ПЗ
Було запропоновано додати постачальника даних до програмних засобів
для усунення недоліків функціонування систем генерації тестових даних. Цей
постачальник даних служить абстракцією між тестовими даними та тестовими
даними. Використовуючи його, можна автоматично створювати дані для
об’єктів, які будуть використовуватися в коді, не створюючи надлишкового
коду. Було також запропоновано додати новий спосіб створення тестових
даних до алгоритмічних засобів.
Переглянуто процес створення тестових даних. Запропоновано схему,
яка використовує постачальника даних для генерації тестових даних. Цей
постачальник даних було запропоновано включити в структурну схему. Власна
схема процесу генерації тестових даних складається з декількох рівнів:
клієнтський код, клас компоновщика Composite, клас будівельника Builder і
зв’язок з додатком.

36
ЧДТУ 2216.020 ПЗ
Розділ 2. Теоретичні та експериментальні дослідження
Розгляд основних етапів і особливостей кожного методу є частиною
аналізу основних процесів методів генерації тестових даних.
Ми плануємо порівняти різні підходи до генерації тестових даних. Ці
підходи включають ручне введення, випадкову генерацію, генерацію на основі
обраного варіанту, використання реальних даних, генерацію на основі дерева
вирішень, генерацію на основі синтетичних даних і використання мовних
моделей. Ми шукаємо метод, який може оптимально поєднати автоматизацію і
реалістичність.
Ми будемо оцінювати ефективність кожного підходу за допомогою таких
параметрів:
- покриття коду: Тестові дані зазвичай включають різні гілки та шляхи в
програмному коді.
- реалістичність: визначається яким чином синтетичні чи згенеровані
дані відрізняються від реальних вхідних даних.
Це дослідження може допомогти в оптимізації процесу тестування та
виборі найкращого методу генерації тестових даних для конкретних умов і
завдань.
Гіпотеза: ефективність тестування програмного забезпечення значною
мірою залежить від методу генерації тестових даних, який було обрано. Наше
основне припущення полягає в тому, що застосування певних стратегій може
призвести до покращення якості тестування, виявлення більшої кількості
дефектів і забезпечення вищого покриття коду.
2.1 Теоретичні дослідження
Генерація та підтримка тестових даних займають 30–60% часу
тестувальників. Фаза підготовки даних під час тестування програмного
забезпечення є складною. Що стосується повноти та повного охоплення
37
ЧДТУ 2216.020 ПЗ
тестування, це в першу чергу залежить від якості даних. Тестові дані є
ключовою частиною процесу тестування, оскільки тестування є основою для
досягнення якості програмного забезпечення.
Якщо знайдено очікувану кількість дефектів для встановлення
мінімального розміру даних, тестові дані можна вважати якісними.
Незважаючи на те, що тестування може виявити наявність дефектів, воно не
може підтвердити їх відсутність. Таким чином, тестування може показати,
наскільки впевненим є програмний продукт[3].
Для отримання тестових даних зазвичай використовуються різні підходи.
На рис. 2.1 показано основні з них.

Рис. 2.1 – Стратегії генерації тестових даних

Слід зазначити, що дані виробничого середовища рідко використовують,
оскільки це справжні дані і робота з ними може призвести до небажаних
наслідків.
2.1.1 Цільова функція
Значення цільової функції використовується для оцінки рішення щодо
особини. Це означає, що особина оцінюється як придатна для подальшого
38
ЧДТУ 2216.020 ПЗ
використання. Стандартний генетичний алгоритм також використовує цю
функцію. Фітнес-функція або функція придатності — це терміни, які часто
використовують для опису цієї функції. Значення цієї функції оцінюється
окремо для кожної особини популяції, і це визначає, чи використовувати цю
хромосому чи перейти до етапу схрещування та мутації, щоб покращити
особини популяції. Наприклад, уявімо, що функцію потрібно оптимізувати, де
одиниця тестових даних (особина) є цільовою функцією популяції, а загальна
кількість особин в одиниці популяції є цільовою функцією популяції. Було
розроблено цільову функцію, яка враховуватиме м’які обмеження для здачі.
Невиконання м’якого обмеження призводить до штрафу. У кожного
обмеження є штрафний коефіцієнт і ступінь невиконуваності. Мною обрано
кількість порушень i-го обмеження як ступінь невиконуваності. Наприклад, у
випадку м’якого обмеження тестові дані не виявили дефекту за одну ітерацію,
ступінь невиконуваності визначається номером ітерації[4]. Як визначити
штраф за одне обмеження?
У такий спосіб визначається штраф для одного обмеження:

��! = ��! ∗ ��! , (2.1)1)

де, ��! – це ступінь невиконуваності i-го обмеження;
��! – штрафний коефіцієнт для i-го обмеження;
��! – штраф за невиконання i-го обмеження.
Значення штрафу можна підставити у формулу цільової функції:

% $$& #
"
= ! →!"! , (2.2)
"+∑ #&
&="

39
ЧДТУ 2216.020 ПЗ
де, ��! – це досліджувана особина;
�� – кількість м’яких обмежень;
��!– штраф за невиконання i-го обмеження.
Отже, більше значення цільової функції, а отже краща оcобина, залежить
від того, наскільки менше буде штрафу за невиконання м’яких обмежень.
Якщо цільова функція менша за 1, це означає, що якесь із м’яких обмежень не
виконано, і досліджувана особа є непридатною і потребує покращення своїх
характеристик.
2.1.2 Підготовка тестових даних
Коли ви створюєте тестові дані, ви повинні враховувати наступні
категорії, які залежать від цілі тесту[5]:
- значення NULL або default. Створюються тести, у яких навмисне
підставляються пусті поля або умовні дані;
- валідатний набір даних. Створюються «позитивні» тести з хорошими
значеннями, щоб переконатися, що ціль тесту справді досягається;
- невалідатний набір даних. Створюються «негативні тести», щоб
перевірити, як програма реагує на неприйнятні значення;
- пошкоджені файли. Пошкоджені файли, наприклад, JSON-файли
мають навмисну помилку об’єкта. Основна мета полягає в тому, щоб
перевірити, чи програма адекватно зреагує, видасть помилку,
продовжить працювати чи припинить роботу негайно.
- максимальні значення Це значення знаходиться в межах дозволеного
діапазону. Наприклад, якщо абстрактна програма отримує значення
від нуля до десяти, її граничні значення будуть 0, 1, 10, 11; ці
значення відносяться до класів еквівалентності.
- класи еквівалентності. Якщо є прийнятний діапазон, наприклад від
нуля до десяти, то логічно, що всі значення мають бути однаковими в
40
ЧДТУ 2216.020 ПЗ
межах цього діапазону. Зазвичай класи еквівалентності
використовують разом з граничними значеннями, якщо цей діапазон
становить від нуля до тисячі.
- таблиця для прийому рішень. Це двовимірна матрична таблиця, яка
генерує різні очікувані результати шляхом поєднання вхідних
тестових даних;
- таблиця переходів станів. має форму графа. Коли систему можна
привести в певний очікуваний стан за допомогою певного набору
тестових даних;
- Use-case. Тестові дані складаються у вигляді сценарію, який
відображає позицію користувача. Тести створюються за допомогою
підходу розвитку, керованого поведінкою (BDD).
2.2 Експериментальні дослідження
Дані тестів повинні бути підібрані відповідно до цілі тесту. Зазвичай
говорять про чотири характеристики тестових даних.
Реалістичні тестові результати. Дані повинні бути точними в реальному
світі. Наприклад, щоб перевірити поле «Вік», кожне значення повинно бути
позитивним і мати значення 18 або більше. Кандидатам на вступ до
університету очевидно 18 років, хоча це може бути визначено по-різному
залежно від бізнес-вимог. Якщо тестування проводиться за допомогою
реалістичних тестових даних, додаток стане більш надійним, оскільки
реалістичні дані можуть запобігти більшості потенційних помилок[6].
Реалістичні дані також можна повторно використовувати, що дозволяє нам
економити час і енергію, створюючи нові дані знову і знову. Я хотів би
ознайомити вас з ідеєю золотого набору даних, коли ми говоримо про
реалістичні дані. Золотий набір даних охоплює майже всі потенційні сценарії,
які можуть відбутися в реальному проекті.
41
ЧДТУ 2216.020 ПЗ
Практично валідатні результати тестів. Хоча це схоже на реалістичні
дані, вони не ідентичні. Це властивість більше пов’язано з тестуванням бізнес-
логіки системи; наприклад, значення 60 є реальним у віковій групі, але воно
практично недійсне для студентів, які вступають до університету або навіть
отримують ступінь магістра. У цьому випадку допустимий діапазон віку
становить 18-25 років, який може бути встановлений відповідно до вимог.
Загальні тестові дані. Дані підбираються таким чином, щоб отримати
найкращі вихідні очікувані результати з найменшою кількістю даних. Таким
чином, певний набір вхідних даних покриває багато вимог, що економить час
на тестування. Цей метод, однак, не дуже популярний, оскільки, створюючи
універсальні дані, ми забуваємо про модульність. Зазвичай краще
протестувати кожен очікуваний результат окремо, а потім поєднати. Витрати
на тестування та якість повинні співпадати. Відсутні дані. Це дані, отримані
виключними обставинами. Крім того, тут потрібно враховувати баланс
кількості виключних даних і очікувану поведінку.
Модель генерації тестових даних[7]
Модель генерації тестових даних зображено на рис. 2.2.

='%5#6>0''2 !0"06%?%*<"06(8%.:*
!"06(8%.,4*9+25,4 !"#$"%&'()* 4*.03.#4()*&0.#6
%'%+,-%.#"
70+08.#"*9+25: /0'0"%1,2*
!0"06%?%*9+25,4 .03.#4(5*6%'(5
;#6%.8#4,*&0.%6%',*<"#*9+25(
Рис. 2.2 – Модель генерації тестових даних
42
ЧДТУ 2216.020 ПЗ
Селектор «Шляху» визначає шляхи, які у нашому випадку є регулярними
виразами. Дані для кожного «шляху», який призводить до виконання
вибраного шляху, надсилаються генератору тестових даних після визначення
тестового набору. Наша основна мета полягає в тому, щоб знайти вхідний
набір даних, який буде проходити шлях, обраний селектором шляху.
Система рівнянь, яка описує тип вхідних тестових даних, щоб пройти
шлях, є ідеальним рішенням. У деяких випадках генератор надає селектору
зворотний зв’язок щодо шляхів, які є нездійсненними, тобто додаткові
метадані.
Коли програмний аналізатор складає тестові сьюти, він аналізує такі
дані, як кількість ітерацій, тип, який повертається з типом параметру в методі,
які тести потрібно пропустити, тощо.
Ви можете використовувати ці функціональні інтерфейси, щоб
перевірити, чи виконується певна умова. Значення типу true повертається,
коли воно виконується. Дуже зручно використовувати цю парадигму, оскільки
параметр методу може зберігати інтерфейс попереднього предикату, а ми
можемо передавати умову кожного шляху в тестовий метод кожен раз нову,
залежно від шляху. Наприклад, у Java існує інтерфейс Predicate<T>[8]. У
нашому випадку генетичний алгоритм буде закладено в основу програмного
аналізатора.
2.2.1 Тестування на основі даних
Тестування на основі даних (DDT) — це метод тестування програмного
забезпечення, який використовується при тестуванні комп’ютерного
програмного забезпечення. DDT описує тестування, яке проводиться
безпосередньо за допомогою таблиці умов, включаючи перевірені входи та
перевірені виходи, а також процес, коли налаштування та контроль тестового
середовища не були твердо кодовані. Все, що має здатність змінюватися, або
43
ЧДТУ 2216.020 ПЗ
«мінливість», включає такі елементи, як оточення, кінцеві точки, дані тесту,
місця розташування тощо, і відокремлюється від логіки тестування (сценарії) і
переміщується в «зовнішній актив». Це може бути набір даних для тестування
або конфігурація. Значення даних визначають логіку сценарію. Це можуть
бути файли JSON, XML або Excel. У нашому випадку з майбутнім
постачальником даних це будуть класифіковані як об’єкти.
Найпростіший підхід передбачає створення одного сценарію тесту —
одного інтерфейсу; однак вхідні дані та очікувані результати є змінними
даного тесту, і ці змінні отримують нові значення при кожній ітерації.
Переваги цього методу включають:
- скорочення часу, необхідного для проходження тестів. Тест один
виконується n разів, тому час на всі перед і після умов не
витрачається, і, звичайно, немає зайвих тестів, що дозволяє
компілювати та запускати один тест швидше;
- дані тесту зберігаються в іншому місці, ніж у самому тесті. Особливо
зручно зберігати тестові дані окремо, які можна використовувати в
інших цілях;
- код тестів стає набагато «чистішим» і легшим для читання;
- використовується бізнес-мова Gherkin, яка дозволяє кожному, хто
розробляє та тестує продукт, писати тестові сценарії;
- тестові сценарії пишуться паралельно з бізнес-вимогами, і в процесі
можуть брати участь усі, хто розуміє мову Gherkin.
Можливий недолік підходу — це метод реалізації, який може зберегти
ресурси, час або гроші та підвищити ефективність виявлення дефектів. Знання
цього методу є важливими, оскільки він зазвичай використовується для
майбутнього модуля генерації тестових даних. На рис. 2.3 показано візуально
цей метод.

44
ЧДТУ 2216.020 ПЗ

Рис. 2.3 – Тестування на основі даних

У заяві буде статичний очікуваний результат, якщо очікуваний результат
є єдиним для різних наборів тестових даних. Якщо тест більш універсальний,
очікуваний результат повинен бути записаний у наборі вхідних даних.
Наведений нижче псевдокод найкраще демонструє це:
public void ExampleTestMethod(ExampleModel model)
{
// Змінюємо щось у моделі
model.ChangeSomething();
// Викликаємо метод click та отримуємо результат
WebElement actualElement = model.Click();
// Порівнюємо очікуваний елемент з отриманим
Assert.AreEqual(model.ExpectedElement, actualElement);
}
Передається в метод тестування моделі. Вона має свої тестові дані разом
із вхідними даними та прогнозованим результатом на кожній ітерації. Тест
містить один сценарій. Очікуваний результат порівнюється з реальним після
виконання певних операцій з об’єктом моделі. Це видно з коду, який
зберігається в самому об’єкті моделі.
45
ЧДТУ 2216.020 ПЗ
Тестові дані зберігаються в об’єкті моделі в цьому випадку. Однак
доступні інші інструменти, які дозволяють зберігати тестові дані в різних
форматах.
2.2.2 Аналіз методів генерації тестових даних
Найпростіший спосіб створення тестових даних – використання
«рандомних» генераторів. Перевага цього полягає в тому, що він може
отримувати введення для будь-якої програми. Ми можемо випадково створити
бітовий потік, щоб створити тестові дані, і дозволити йому представляти
потрібний тип даних. Оскільки це неефективно в плані покриття, генерація
випадкових тестових даних не дає якісних тестових даних. Високе охоплення
не можна отримати з генерованих даних, оскільки вони базуються виключно
на ймовірності[9]. Це тому, що ймовірність виявлення семантично малих
помилок дуже мала. Проблема вважається семантично малою помилкою, якщо
вона виявляється лише в частині введення програми. Наприклад, розгляньте
наступний код, щоб врахувати семантично малу помилку:
void test(char x,char y) {
if (x==y)
printf("Equal");
else
printf("Not Equal");
}
У більшості випадків перше висловлювання виконується частіше, ніж
друге. Ймовірність його виконання збільшується зі зростанням структури в
ньому. Таким чином, важко знайти такі семантично малі помилки,
використовуючи випадкові тестові дані. Оскільки вона має найменшу
прийнятну швидкість формування тестових даних, генерація «рандомних»
тестових даних зазвичай використовується як орієнтир.
46
ЧДТУ 2216.020 ПЗ
Даний метод також використовує фізичні явища, які відбуваються в
тестовому середовищі, але це не допомагає створити тестові дані, які
наближаються до реальних. Таким чином, «рандомні» генератори мають
високу швидкість генерації та простий у використанні, але вони зазвичай
використовуються в невеликих програмах, у яких не потрібно перевіряти
складні об’єкти.
«Цільові» генератори. Цільовий підхід пропонує орієнтацію на певну
кількість шляхів. У цьому методі генератори тестових даних генерують вхід
для будь-якого шляху u замість традиційного методу, який генерує вхід від
входу до виходу блоку коду. Таким чином, генератор має здатність знайти
будь-який вхід, який є підмножиною шляху. Це значно знижує ймовірність
створення відносно нездійсненних шляхів і забезпечує метод спрямування
пошуку. Цей підхід використовує два підходи:
- підхід «ланцюга»
- підхід «орієнтований на твердження»
Підхід «ланцюга» — це продовження цілеспрямованого підходу.
Основним обмеженням методів генерування тестових даних є те, що для
створення тестових даних доступний лише графік потоку управління. Ми
можемо мати проблеми з прийняттям рішень через це обмежене знання. Таким
чином, очевидно, що орієнтований на підхід звичайно повинен створити
багато шляхів, перш ніж знайти «правильний» шлях. Це тому, що немає
вибору. Підхід ланцюга має на меті визначити ланцюжок вузлів, які необхідні
для виконання вузла цілі. Процес ланцюга починається з виконання будь-якого
вводу x. Під час виконання кожної гілки програма пошуку вирішує, чи
продовжувати виконання через цю гілку, чи використовувати іншу гілку,
оскільки поточна гілка не веде до вузла цілі. Алгоритми пошуку автоматично
знаходять новий вхід, коли помічено небажаний потік виконання. З іншого
боку, якщо процес пошуку також не може знайти вхід X, який може змінити
47
ЧДТУ 2216.020 ПЗ
потік виконання, ланцюговий підхід намагається змінити потік у вузлі. Це
дозволяє виконати альтернативну гілку в p.
Підхід «орієнтований на твердження» є розширенням «ланцюгового»
методу[10]. Цей метод включає твердження, або обмежувальні умови. Це
можна зробити вручну або за допомогою автоматичного пристрою. Якщо
програма не витримує виконання, це означає, що є помилка в програмі або в
твердженні.
Коли твердження виконується, воно повинно бути виконано, інакше буде
помилка в програмі або твердженні. Для прикладу:
void test(int a) {
int b,c
b = a-1;
assertion(b != 0);
c = (1/b);
}
Програма повинна містити твердження про твердження в наведеному
вище коді. Якщо твердження не виконується, наступний шлях призведе до
помилки. Отже, мета цієї стратегії полягає в тому, щоб знайти будь-який
спосіб довести твердження, яке не дотримується. Цей метод також має велику
перевагу, оскільки всі інші методи очікують, що значення виконання тестових
даних буде обчислено з іншого джерела, ніж код. Оскільки очікуване значення
забезпечується твердженням, цей метод не вимагає цього.
«Шляхові» стратегії генерації Одним із найкращих методів генерації
тестових даних є тестовий шлях. Такий метод надає генератору лише один
шлях, а не кілька. Таким чином, цей метод досить схожий на «цільове»
формування тестових даних, за винятком того, що він використовує конкретні
шляхи. Краще знання та прогнозування покриття досягаються за допомогою
використання конкретних шляхів. Тим не менш, це також ускладнює
48
ЧДТУ 2216.020 ПЗ
отримання необхідних тестових даних. Такі генератори потребують двох
входів для тестувальника. Вони включають програму тестування та критерії
тестування, такі як покриття шляхів і умови.
Системи, які використовують лише графік керуючого потоку для вибору
конкретних шляхів, зазвичай виявляють нездатні шляхи. З цієї причини були
запропоновані методи формування тестових даних, які базуються на
обмеженнях.
«Шляхові» методи також дозволяють перевіряти твердження та умови.
Загалом, не завжди 100% тверджень виконуються 100% умов; однак, якщо є
повне покриття умов, то і повне покриття тверджень[11]. Таким чином, все
залежить від використання методу відповідно до цілі тесту.
«Інтелектуальні» генератори даних для тестування. Дані генератори
використовують складний аналіз коду, щоб контролювати пошук тестових
даних. «Інтелектуальні» генератори в основному використовують один із
методів генерації тестових даних разом із детальним аналізом коду. Тестові
дані можна отримати швидше за допомогою цього методу, ніж за допомогою
інших методів. Однак аналіз, необхідний для використання цього методу для
широкого спектру програм, є досить складним і вимагає великого розуміння,
щоб передбачити різні ситуації, які можуть виникнути. Чотири основні
частини складають даний генератор: сканер, генератор тестових випадків,
аналізатор тестових випадків і генератор звітів. Мета аналізатора полягає в
тому, щоб обробляти вхідний вихідний код і створювати файл, який містить
інформацію про структуру вхідного коду. Тестовий аналізатор використовує
інструментальний код для аналізу покриття коду. Код генератора тестових
випадків містить інформацію в структурному файлі.
Дані створюються хаотичними генераторами даних за допомогою
хаотичного аттрактора. Дані, які створюються хаотичним аттрактором, є
неповторюваними, і навіть невелика зміна в умовах аттрактора може
49
ЧДТУ 2216.020 ПЗ
призвести до значних змін у даних, які потім створюються. Множина точок у
фазовому просторі, до якого збігаються фазові траєкторії дисипативної
системи, називається трактором. Аттрактори можуть бути поверхнями, лініями
(граничні цикли), точками (точки рівноваги) або навіть складними
багатовимірними фрактальними структурами[12]. У фазовому просторі існує
«басейн притягання» навколо аттрактора. Аттрактори класифікуються за
такими критеріями:
- формалізація ідеї прагнення: існує максимальний аттрактор,
аттрактор Мілнора, центр Біркгофа, статистичний і мінімальний
аттрактор.
- регулярність самого аттрактора: атрактори поділяються на регулярні
(притягує нерухому точку, яка притягує різноманіття) і дивні
(влаштовані як канторова безліч у будь-якому перетині; їх динаміка
зазвичай хаотична). Порівняльна таблиця була створена на основі
аналізу методів для генерації тестових даних (таблиця 2.1).
Таблиця 2.1
Порівняльна таблиця систем генерації тестових даних
Назва методу Переваги Недоліки
«Рандомні» Можна отримати вхід для Неякісні тестові дані
методи будь-якої програми; Швидка (наближені до реальниx),
генерація обмежене покриття
(охоплення), використання
в невеликих програмах.
«Цільові» методи Твердження в коді Перш ніж знайти
забезпечують правильний «правильний шлях»,
вибір шляху під час потрібно створити багато
тестування. різних шляхів.

50
ЧДТУ 2216.020 ПЗ
Продовження таблиці 2.1
«Інтелектуальні» методи якісні тестові дані аналіз тестів є досить
(наближені до реальних). складним та вимагає
більшого часу.

Отже, після аналізу систем даниx було виявлено, з якими проблемами
вони зіткнулися. Ці проблеми включали тривалий аналіз тестів, збір усіх
шляхів, розробку початкових умов і рішення вивчити альтернативні методи
генерації тестових даних.
Генетичний алгоритм був обраний для генерації тестових даних.
Алгоритм може покращити роботу систем генерації тестових даних, оскільки
процес генерації тестових даних має багато спільного з алгоритмом і його
характеристики змінюються під час виконання.
2.2.3 Генетичний алгоритм для генерації тестових даних
Еволюційний алгоритм пошуку, відомий як генетичний алгоритм,
використовує механізми, подібні до біологічної еволюції, для вирішення задач
моделювання та оптимізації шляхом послідовного підбору, комбінування та
зміни параметрів, які шукаються.
В основі цього алгоритму лежить порівняння з природними
еволюційними процесами. Його перевагою є те, що на кожній ітерації він
працює з множиною рішень, що дозволяє аналізувати простір пошуку більш
детально в порівнянні з градієнтними методами багатовимірної нелінійної
безумовної оптимізації. Це означає, що не потрібні додаткові вимоги до виду
цільової функції.
Генетичний алгоритм відрізняється використанням оператора
«схрещування», який виконує функцію рекомбінації рішень-кандидатів, яка
подібна до функції схрещування в живій природі. Цей метод моделювання
51
ЧДТУ 2216.020 ПЗ
активно використовує понятійний апарат генетики. Таким чином, слід дати
пояснення наступним ідеям:
- ген — це реальна, незалежна одиниця спадковості, яка комбінується
та розщеплюється під час схрещування.
- хромосома — це структурний елемент клітинного ядра біологічних
організмів, який несе гени в клітинному ядрі особини. Генетичні
методи використовують терміни «хромосома» та «особина».
- популяція — це велика популяція схрещених організмів. Генофонд
популяції визначається сукупністю ланцюжків генів кожного об’єкта.
Генетичний алгоритм має наступні переваги:
- він не вимагає специфічних знань про вирішувану задачу. Це означає,
що процес пошуку може бути використаний, якщо існує додаткова
інформація про систему, об’єкт або процес, який досліджується;
- концептуальна простота та прозорість реалізації ;
- простота кодування вхідної та вихідної інформації. Некритичність
щодо типу параметрів систем, які досліджувалися (можливість
використання експертної, емпіричної, довідкової та іншої інформації
про об’єкт, яка представлена різними типами даних);
- можливість застосування до широкого спектру завдань без значних
змін у структурі методу;
- можливість адаптувати параметри генетичного пошуку до
особливостей конкретної задачі, наприклад тестування програмного
забезпечення;
Генетичний алгоритм демонструє особливі переваги та ефективність як
ефективний алгоритм оптимізації на основі пошуку, коли йдеться про
вирішення завдань з високою складністю, таких як проблеми великого
простору та нелінійності. Таким чином, це стало місцем, де проводяться
52
ЧДТУ 2216.020 ПЗ
дослідження щодо автоматичного створення тестових даних за допомогою
генетичних алгоритмів, і вони показали хороші результати.
Тестові дані були створені за допомогою генетичного алгоритму для
покриття висловлювань на основі трансформації доказів. Було запропоновано
метод зменшення цільових тверджень відповідно до їх домінуючих відносин, і
був створений тестовий набір із зменшеними цільовими твердженнями.
Тестові дані, що відповідають критерію покриття галузей, також можна
отримати за допомогою генетичного алгоритму. Результати експерименту
показують, що генетичний алгоритм може створити тестовий набір, який
досягає або дуже близько до покриття гілки коду. При спробі отримати
достатні дані тесту для галузей генетичний алгоритм був представлений для
створення функцій «пристосованості», які підвищують ефективність
тестування на основі пошуку. Для підвищення ефективності тестування
запропонував мультипопуляційний алгоритм з декількома сукупностями.
Результати експерименту показали, що запропонований підхід значно
перевершує алгоритм однієї сукупності.
Тестові дані, що відповідають критерію покриття умови, також були
створені за допомогою генетичного алгоритму. Мінімізація функцій є
проблемою генерації тестових даних; це досягається за допомогою одного з
двох генетичних алгоритмів, а не локальних методів мінімізації. Це дає
кращий розв’язок для системи рівнянь пошуку мінімуму.
Для функціонального тестування також використовувався
«еволюційний» алгоритм, який включав два генетичні алгоритми для
створення пари тестових даних, а потім використовувався для навчання дерева
рішень, щоб отримати модель агента, яка відрізняє достовірність даних тесту.
Крім того, було представлено метод автоматичного генерування тестових
даних шляхом врахування двох цілей: максимізація покриття та мінімізація
витрат.
53
ЧДТУ 2216.020 ПЗ
2.2.4 Опис задачі генерації тестових даних в термінах генетичного
алгоритму
Хромосома складається з генів. У нашому випадку це набір тестових
даних. Кожен елемент хромосоми представляє масив даникса з тестовими
значеннями.
Тестові дані будуть представлені у вигляді двомірного масиву хромосом,
оскільки особистість – це набір хромосом.
Популяція складається з групи схрещених тварин. В нашому випадку це
буде набір тестових даних, які були створені.
Початкова популяція створюється випадковим чином. Генетичний
алгоритм все одно швидко створить придатну для життя популяцію, навіть
якщо популяція виявиться абсолютно не конкурентоздатною. Однак потрібно
більше часу, щоб популяція стала конкурентоспроможною.
Таким чином, на цьому етапі не варто намагатися зробити людей надто
пристосованими; достатньо, щоб вони відповідали формату популяції та мали
цільову функцію (функцію пристосованості). У нашому випадку форматом
повинні бути початкові регулярні вирази, шаблони з рандомними значеннями
або тестові дані, які успішно виявили дефекти на попередніх етапах.
2.2.5 Обмеження
Проблема, з якою стикаються під час процесу складання алгоритму,
полягає в тому, що тестові дані повинні відповідати певним обмеженням, які
будуть використовуватися під час відборі та схрещування. Усі обмеження
класифікують як м’які, так і жорсткі. Жорсткі – це обмеження, які фізично не
можна порушити; вони повинні обов’язково виконуватися. М’які обмеження
можна порушити, але це повинно бути мінімальним. Жорсткі не такі
обов’язкові, як ці.
Під час генерації даних необхідно враховувати деякі жорсткі обмеження:
54
ЧДТУ 2216.020 ПЗ
- кількість символів у тестових даних не повинна перевищувати
початкові умови;
- тестові дані не можуть наслідувати одне й те саме значення від своїх
предків.
Для одиниці тестових даних є деякі невеликі обмеження:
- кількість символів може бути збільшена до максимального
дозволеного значення;
- тестові дані мають бути відправлені на мутацію, якщо вони не
виявили дефекту за одну ітерацію;
2.2.6 Схрещування
Однією з різновидів оператора рекомбінації генетичного алгоритму є
схрещування. Наукова література також називає його кросовером або
кросинговером.
Мета оператора схрещування полягає в тому, щоб створити нову
множину рішень із наявної. У цьому сценарії кожна хромосома буде нащадком
двох елементів попередньої популяції, наприклад, нести частину інформації
кожного батька. Допустимо, що обидва батька належать до однієї і тієї ж групи
людей.
Кросинговери рівномірного, двоточкового та одноточкового типів
існують. У нашому випадку ми вибрали одноточковий метод[13].
Одноточковий кросинговер — це коли одна з точок розриву (ділянок між
сусідніми бітами в рядку) випадково обирається. В цьому моменті батьківська
сторона ділиться на дві частини. Після цього відповідні частини від різних
батьків обмінюються відтятими частинами, склеюються та створюються дві
нові особи. У нашому проекті кросинговер відбудеться між двома предками,
один з яких успадкує гени іншого батька.
- обираємо дві найкращі особини з батьківської популяції;
55
ЧДТУ 2216.020 ПЗ
- знаходимо випадково точку розриву (в програмному розумінні це
буде рандомний індекс масиву символів одиниці тестових даних);
- беремо одного з батьків і рандомно міняємо символи з іншим
батьком до точки розриву. Змінений предок буде переноситися на
місце для створення нового покоління.
Якщо символи вже були виявлені з порушеннями, успадкування їх немає
сенсу. Відповідно до принципу тестування, відомого як «кластеризація
дефектів» якщо дефект виявлено в класі або модулі, існує висока ймовірність
того, що цей дефект спричинив зброю в модулях, які знаходяться поруч. Інші
методи схрещування, такі як точкове схрещування, не будуть ефективними в
цьому випадку, оскільки через порушення жорстких обмежень більшість
створених нащадків буде відкинуто.
2.2.7 Мутація
Зміна генів у випадково вибраних місцях називається операцією мутації.
Метою оператора мутації є диверсифікація, що означає збільшення
різноманітності пошуку та додавання нових хромосом до популяції для більш
детального дослідження простору пошуку. Це відрізняє оператора
схрещування, який використовується для покращення структури хромосом.
Зміни в популяції створюють різноманітність, оскільки вони дозволяють
досліджувати більше місць під час пошуку та долати локальні екстремуми.
Будемо використовувати просту мутацію для бінарних, гомологічних,
числових і векторних хромосом, щоб вирішити нашу задачу.
У випадку тестової генерації даних кожна ітерація викличе мутацію.
Якщо дефекти не виявлено, проганяти тест з тими самими даними немає сенсу.
Таким чином, індекси, які будуть змінювати символи, будуть обрані рандомно
для кожної ітерації з масиву символів. Схрещування відбудеться, якщо тестові
дані виявиться неправильними.
56
ЧДТУ 2216.020 ПЗ
2.2.8 Алгоритм для генерації тестових даних
Процес еволюції тестових даних генетичним алгоритмом зображено в
геометричній інтерпретації на рис. 2.4.

Рис. 2.4 – Геометрична інтерпретація процесу еволюції тестових даних
генетичним алгоритмом

На малюнку показані безпосередньо особини тестових даних для
кожного тесту. Ця популяція починалася з цих особин. Еволюційні процеси
селекції (відбору), схрещування та мутації використовують тестові дані. В
даній інтерпретації кожна популяція особин, а також тести, є окремими, тому
процеси схрещування, мутації та селекції відбуваються окремо.
57
ЧДТУ 2216.020 ПЗ
Крім того, під час дослідження генетичного алгоритму було виявлено
концепцію «субпопуляції», яка по суті поділяє популяцію на підпопуляції,
кожна з яких виробляє свої власні потомки. У нашому випадку субпопуляції
можуть бути окремими тестовими популяціями. Перевага цього методу
полягає в тому, що алгоритм не тільки визначає, чи є індивід оптимальним
рішенням для своєї субпопуляції, але й робить це для інших субпопуляцій
після завершення еволюційних операцій покоління. Таким чином, особини
однієї субпопуляції діляться на всі інші субпопуляції, що збільшує ймовірність
найкращих рішень. На рис. 2.5 показано геометричну інтерпретацію, яка
демонструє реалізацію індивідуального обміну.

Рис. 2.5 – Геометрична інтерпретація процесу індивідуального обміну
особин (тестових даних) між суб-популяціями

Схема генетичного алгоритму для генерації тестових даних була
розроблена після визначення необхідних об’єктів, як показано на малюнку 2.6.
58
ЧДТУ 2216.020 ПЗ
!"#$%"&
;"<=,>$HH)-
?"#$%&">"@-
?"?,9)53@
ABCD-BEDFFFDB1GD-
/0HD-1
7$&
'"()*H,%"-./01!
:3
f$?,(&-/J"@- fi4<4M4HH)-
3%4<$53@-%4(%, "(%$HH3N-%4(%">ON-
P$HON
n53H&$-5396">"@-
.?<OP$%H"(%3R-
S,H&53@
T.B/RD-/0/UC
8494&53)
8N<4V,>$HH)
K,%$53)
23H456

Рис. 2.6 – Схема генетичного алгоритму для генерації тестових даних
59
ЧДТУ 2216.020 ПЗ
Наступні кроки та детальний опис генетичного алгоритму генерації
тестових даних наведені нижче:
1 Критерій закінчення алгоритму також є формуванням початкової
популяції, де тестові дані (особини) тесту є кінцевою кількістю
майбутніх популяцій ітерацій тесту.
2 Перевірте результат; якщо він позитивний, ми переходимо до кроку
7, а якщо він негативний, ми переходимо до кроку 3.
3 Оцінка цільової функції, детально описана у пункті 2.2.6.
4 Сортування.
5 Перетворення. Процес схрещування описано в параграфі 2.2.7.
6 Метаморфоз Пункт 2.3.8 описує процес мутації, переходячи до кроку
2.
7 Збереження найновіших результатів тестування.
У контексті автоматизованого тестування слід пояснити алгоритм y. На
першому етапі тестувальник може задати початкові значення за допомогою
регулярних виразів. або просто статичні значення, або значення, отримані під
час попереднього тестування з кроку 7.
На цьому етапі проводиться перевірка того, чи досягнуто результату.
Необхідно оцінити результат. Якщо виявлено дефекти під час тестування,
можна сказати, що результат досягнуто. Але ймовірність того, що вони
знайдуть помилки під час кожного тестування, дуже мала. Це може означати,
що програмне забезпечення дуже погане. Таким чином, результатом буде
виконання кількості ітерацій, а саме створення і-ої кількості популяцій для
тестового об’єкту.
Коли створюються ітераційні тести, створюється один інтерфейс, який
містить очікуваний результат. У нашому випадку постачальник даних генерує
нові тестові дані для об’єкта за допомогою параметру методу (тести пишуться
у вигляді методів). В кінці кожного тесту є певна перевірка, або твердження,
60
ЧДТУ 2216.020 ПЗ
що тест був успішним. Крім того, якщо тест «позитивний», але ми бачимо, що
він впав на певній ітерації, це означає, що тест виявив помилку, і особа є
хорошою. Якщо тест «негативний», ми спочатку знаємо, що система має в
помилці; однак, якщо система реагує належним чином, це також дефект, і його
слід однозначно відвести на операцію схрещування. Дані з дефектами будуть
відправлятися однозначно на схрещування, а дані без дефектів будуть
відправлятися на мутацію[14]. Хоча блоки розташовані послідовно, це процес,
який необхідний. Таким чином, нові тестові дані для кожної ітерації є
потомками схрещування або мутації для кожної ітерації.

61
ЧДТУ 2216.020 ПЗ
Висновки до розділу
У другому розділі розглядаються основні принципи, методи та стратегії
генерації тестових даних. Було визначено, які категорії даних слід
використовувати під час підготовки. Встановлено основні характеристики
якісних даних. Була розроблена структура модуля для генерації тестових
даних.
Було досліджено два підходи до тестування даних: тестування на основі
даних і тестування, кероване поведінкою. Майбутній програмний модуль може
використовувати кожен із цих методів.
Було вивчено основні методи генерації тестових даних: «рандомні»,
«цільові», «шляхові» та «інтелектуальні».
Після дослідження алгоритмів, представлених вище, було виявлено, що
деякі методи, такі як «рандомні», просто генерують дані, не ефективні в
пошуку дефектів. в життєвому циклі тестів, не прив’язаних до конкретних
завдань, тому вони неефективні. Наприклад, «шляхові» методи витрачають
багато часу через проблему «вичерпного» тестування. Було проведено аналіз
їхніх переваг і недоліків, а потім було прийнято рішення використовувати
новий спосіб генерації тестових даних.
Новим методом генерації тестових даних був генетичний алгоритм. Було
проведено дослідження основних концепцій і принципів, за допомогою яких
працює алгоритм. Було розглянуто процес генерації тестових даних для
генетичного алгоритму, а також обмеження, які будуть застосовані під час
цього процесу. Розроблено цільову функцію для критерію відбору. Було
розглянуто принцип селекції, а також формули, за допомогою яких
відбуватиметься цей еволюційний процес. Наступним кроком було описано
процес схрещування, який створює нащадків з тестових даних. І процес
мутації, коли тестові дані змінюються.
62
ЧДТУ 2216.020 ПЗ
Розділ 3. Впровадження результатів досліджень у практику проектування
програмного забезпечення інформаційних систем
3.1 Моделювання предметної області
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання
У своїй роботі я виділяю кілька кроків у процесі моделювання:
1 Формулювання розуміння ідеї.
Проект спрямований на розробку методу та програмного забезпечення
для ефективної підготовки даних при тестуванні складних програм.
2 Формулювання проблеми, яку проблему система вирішує.
Основна проблема, яку вирішує проект, полягає в підготовці великих
об’ємів даних для тестування програмного забезпечення.
3 Перерахувати основних користувачів системи.
- тестувальники програмного забезпечення
- розробники програмного забезпечення
4 Продумати ключові сценарії використання.
- отримання даних: користувачі можуть вводити тестові дані у
різних форматах;
- інтеграція з іншими інструментами: можливість застосувати
алгоритми системи до іншого програмного забезпечення.
- вивантаження даних у різних форматах: користувач може отримати
згенеровані дані, у зручному для нього форматі.
5 Визначити процеси, які потрібні для забезпечення діяльності продукту
на стороні замовника.
63
ЧДТУ 2216.020 ПЗ
- аналіз вимог: ретельний аналіз вимог користувачів та розробка
відповідного функціоналу для підготовки даних.
- розробка методу: розробка ефективного методу підготовки
тестових даних, який враховує різноманітність форматів та
особливостей даних.
- створення інтерфейсу користувача: створення зручного інтерфейсу
для завантаження та обробки даних.
- тестування та вдосконалення: проведення тестування розробленого
методу та програмного забезпечення, виправлення помилок та
вдосконалення продукту.
- документація: створення повної та зрозумілої документації для
користувачів та розробників.
Модель предметної області
Перш за все, перед початком розробки системи потрібно сформувати
цілісне уявлення про неї, як модель, яка відображає усі аспекти функціонування
потенційної інформаційної системи. Цей процес ми називаємо процесом
моделювання предметної області, метою якого є імітація структури та функцій,
які ця система повинна виконувати.
Щоб зобразити модель предметної області зазвичай застосовуються
графічні методи, які дозволяють візуалізувати інформацію про складові
компоненти, досліджуваної системи. Графічні методи мають забезпечити
ймовірність декомпозиції системи, забезпечивши розробників максимальним
рівнем детальної інформації про неї.
Словник предметної області
Тестові дані — це вихідні дані, які використовуються для проведення
тестування програмного забезпечення.
Метод підготовки даних — це алгоритм або процес підготовки тестових
даних до процесу тестування.
64
ЧДТУ 2216.020 ПЗ
Інтеграція даних — це об’єднання даних із різних джерел, щоб створити
повну тестову ситуацію.
Автоматизація – використання програмного забезпечення для
автоматичного виконання певних завдань з підготовки даних.
Формати даних — це стандарти, які регулюють формат і представлення
тестових даних.
Інтерфейс користувача — це інтерфейс, який дозволяє користувачам
взаємодіяти з програмою для підготовки даних.
Моніторинг якості даних — це процес спостереження та контролю якості
підготовлених тестових даних.
Генерація тестових сценаріїв — це процес автоматичного створення
сценаріїв тестування на основі даних, які вводяться.
Завантаження даних — це процес перенесення тестових даних у
програмне середовище для обробки.
Документація (документація): інформація, яка описує функції,
використання та технічні аспекти розроблених методів і програмного
забезпечення.
Підтримка користувачів (User Support): допомагає користувачам і
відповідає на їхні запитання щодо використання програмного продукту.
Тестування продукту: використання власних методів і програмного
забезпечення для тестування та виявлення помилок.
Сутність - матеріальні чи інформаційні об’єкти предметної області.
Атрибути – характеристики кожної сутності.
Зв’язки – те, як сутності асоціюються між собою.
Клас – це множина об'єктів, пов'язаних спільністю структури й поведінки.
Процес – опис кроків, які необхідно виконати під час розробки проекту,
називається процесом.
Уніфікована мова моделювання UML є мовою моделювання об’єктного
65
ЧДТУ 2216.020 ПЗ
підходу, яка містить стандартний набір діаграм для моделювання.
Діаграма — це зображення множини елементів на графіку. Вона
найчастіше представляє себе у вигляді зв’язного графа, який має вершини
(сутності) і ребра (відносини), щоб створити певну проекцію системи.
3.1.2 Елементи моделювання предметної області
У своїй роботі я розбиваю створення моделі на етапи, на кожному з яких
працюю з окремими елементами майбутньої моделі:
1 Визначаю всі можливі сутності або об’єкти нашої системи.
2 Під сутностями розуміємо матеріальні чи інформаційні об’єкти, які
нам знадобляться у майбутньому.
3 Далі визначаю атрибути – характеристики кожної сутності.
4 Додаю зв’язки, зв’язки – те, як сутності асоціюються між собою.
3.1.3 Робоча область моделювання
Інформаційна система підготовки даних для тестування складних програм
створена для автоматизації підготовки та управління тестовими даними. Ця
система має багато функцій, щоб гарантувати ефективність і надійність
тестування як на промислових, так і на непромислових об’єктах. Основні
завдання включають: завантаження тестових даних, інтеграція з іншими
інструментами, створення інтерфейсу користувача, вивантаження даних.
3.2 Формулювання та аналіз вимог
3.2.1 Формулювання вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги.
Аналізуючи причини успіху та невдач різних інформаційних систем, я
дійшов висновку, що визначення та управління вимогами під час розробки
проектів є необхідними. У цьому пункті розкрию основні поняття, необхідні для
66
ЧДТУ 2216.020 ПЗ
деталізації вимог. Також опишу вимоги, які є важливими для створення
інформаційної системи даної роботи.
Формулювання вимог до програмного забепечення.
Вимоги до ПЗ — це опис того, що має бути реалізовано[15]. Це описує
поведінку системи, її характеристики. Процес розробки системи може
обмежити їх.
ПЗ складається з трьох рівнів: функціональні вимоги, вимоги бізнесу та
вимоги користувачів.
Первинні вимоги:
1 Функціональність:
- автоматизація процесу підготовки, перетворення та очищення
тестових даних.
- використання разом з іншими програмами тестування та розробки.
- автоматично створювати тестові сценарії на основі підготовлених
даних.
- перевірка якості підготовлених тестових даних і аналітичних
інструментів, щоб виявити аномалії.
2 Продуктивність:
- масштабованість: здатність системи працювати ефективно, коли
обсяг і складність даних збільшуються.
- надійність: система працює добре і може відновлюватися після
можливих збоїв.
Детальні вимоги до програмного забезпечення:
- завантаження тестових даних: Можливість завантаження даних у
формати, такі як Excel, CSV, і JSON, серед інших.
67
ЧДТУ 2216.020 ПЗ
- включені функції для обробки числових, текстових та даних даних.
- генерація тестових сценаріїв: генерація тестових сценаріїв за
допомогою шаблонів і параметрів автоматично.
Функціональні вимоги
Функціoнальні вимоги – функціонал ПЗ, який розробники повинні
забезпечити користувачам своєї системи.
Функціональні вимоги поточної інформаційної системи:
- завантаження тестових даних;
- інтерфейс користувача;
- вибір типу, згенерованих даних;
- можливість завантажити згенеровані дані;
- вибір формату, завантажених даних;
Нефункціональні вимоги
Нефункціональні вимоги пояснюють обмеження системи, що
проектується. Ці вимоги не впливають на те, як працює програма.
Нефункціональні вимоги поточної інформаційної системи:
- продуктивність;
- забезпечення швидкого завантаження даних
- сумісність;
- сумісність з різними операційними системами
- масштабованість;
- здатність системи працювати при збільшеному об’єму даних
- зручність використання;
Вимоги замовника і розробника
68
ЧДТУ 2216.020 ПЗ
Вимоги користувачів – цілі та завдання, які дозволяють користувачам
використовувати систему.
Вимоги замовника поточної інформаційної системи:
- завантаження тестових даних;
- генерація тестових даних;
- інтеграція з іншими інструментами;
- користувацький інтерфейс;
- вимоги розробника поточної інформаційної системи:
- вибір технологій(мови програмування);
- доступ до вимог замовника;
- технічна документація;
- дослідження технологій;
3.2.2 Формування вимог за допомогою діаграми прецедентів
Множина акторів, прецеденти, які є варіантами використання, які
обмежені прямокутником системи, асоціаціями між акторами та прецедентами,
відношеннями між прецедентами та узагальненнями між акторами, і
взаємозв’язки між прецедентами є складовими діаграми прецедентів. Елементи
моделі варіантів використання представлені на діаграмах прецедентів.
У діаграмі прецедентів проєктована система представлена у вигляді
кількох сутностей чи акторів, які взаємодіють із системою за допомогою
варіантів використання[16]. Термін «варіант використання» стосується послуг,
які система надає актору. Іншими словами, кожен варіант використання
дозволяє системі виконувати певний набір дій під час спілкування з актором.
При цьому нічого не говориться про те, як взаємодія акторів із системою буде
реалізована.
69
ЧДТУ 2216.020 ПЗ

Рисунок 3.1 – Діаграма прецедентів програмного забезпечення генерації даних

3.2.3 Проектування логічної структури програмного комплексу
3.2.3.1 Діаграма класів
Для побудови та візуалізації об’єктно-орієнтованих систем
використовується візуальна нотація, відома як діаграма класів UML. В
уніфікованій мові моделювання діаграма класів — це статична структурна
діаграма, яка показує властивості, класи, операції та зв’язки між об’єктами для
опису структури системи. Уніфікована мова моделювання (UML) є
70
ЧДТУ 2216.020 ПЗ
інструментом, який дозволяє моделювати системи різних типів. Диаграма класів
є одним із найвідоміших типів UML. Інженери програмного забезпечення
використовують його для документування архітектури програмного
забезпечення. Оскільки вони визначають компоненти, які мають бути включені
до модельованої системи, діаграми класів є структурною діаграмою.
Наше програмне забезпечення UML розроблено таким чином, щоб воно
було простим для використання, незважаючи на ваш досвід роботи з діаграмами
класів або UML. Крім того, була розроблена стандартизована модель UML для
пояснення методу об’єктно-орієнтованого програмування. Оскільки кожен клас
є будівельним блоком об’єктів, діаграми класів є основою UML. Багато
елементів діаграми класів можуть бути первинними об’єктами, фактичними
класами, які будуть запрограмовані, або зв’язками між класами та об’єктами.

Рисунок 3.2 – Діаграма класів програмного забезпечення генерації даних

71
ЧДТУ 2216.020 ПЗ
У даній діаграмі:
¾ PropertyConfig class: об’єкт, який описує поле для генерації даних,
містить в собі об’єкт Options, який вказує параметри, які мають бути
застосовані при генерації, даний клас має зв’язок композиції із класом
PropertyConfig. Клас Options має в собі 2 властивості, які реалізовані за
допомогою класів PropertyDateOptions та PropertyNumberOptions, які
мають властивості для початкового та кінцевого значення, ці два класи
мають зв’язок композиції разом з Options, оскільки вони не можуть
існувати без даного класу.
¾ ObjectGeneration class: даний клас пов’язаний із класом PropertyConfig
зв’язком залежності, оскільки він використовує список із об’єктами
даного класу для генерації даних. Також, цей клас для генерації
використовує клас GenerateDataService і має зв’язок з ним типу
асоціації.
¾ Status class: клас, який є результатом виконання функції із класу
ObjectGeneration та з’єднаний з ним зв’язком типу композиції.
¾ TypeConverter class: клас, який використовує властивість Result із
класу Status для конвертації його в конкретний формат даних(JSON,
XML, CSV) і має з даним класом тип зв’язку залежності.
¾ FileInstallerHelper class: даний клас використовує результат роботи
функцій із класу TypeConverter, тому він має з даним класом тип
зв’язку залежності.
На основі даної моделі, її сутностей, атрибутів та зв’язків я буду
створювати інформаційну систему.
3.2.3.2 Діаграма пакетів
Незважаючи на те, що моделі з невеликою кількістю класів можуть бути
легко керованими, більшість систем мають велику кількість класів, тому
72
ЧДТУ 2216.020 ПЗ
необхідний механізм для групування класів і спрощення їх повторного
використання. Таким механізмом є пакети в UML.
Діаграми, варіанти використання, класи та інші елементи мови UML
можна групувати в пакети. Пакети групують класи за певними ознаками, щоб
розділити великі моделі на менші частини[17]. Це значно полегшує підтримку
та розуміння проектованої моделі.
Для великих проектів пакети необхідні. Коли діаграма класів, яка охоплює
всю систему в цілому, розміщена на одному аркуші паперу формату А4, стає
нечитабельною, їх слід використовувати.
Існує багато різних методів групування.
групування на основі стереотипів. Стереотипи дозволяють розділяти
класи на категорії. У UML визначені три основні стереотипи: управління, об’єкт
і межа.
На межі проектованої системи знаходяться межові класи. Вони
охоплюють будь-яку форму взаємодії з довкіллям, включаючи звіти, документи,
форми, інтерфейси апаратури та користувачів, а також інші системи.
Класи-сутності містять інформацію про класи внутрішнього устрою
системи, які є її суттю.
Начальники класів відповідають за організацію дій інших класів і їх
взаємодії. Упорядкування відповідно до їхньої функціональності. Окрім
згаданих вище стереотипів, можна також створювати теми для пакетів; отже,
тема пакету може бути досить довільною. Нею можуть бути основні класи,
зв’язки та функції.
На основі даних стверджень було розроблено діаграму пакетів до
програмного забезпечення даної дипломної роботи, дивитись результат на
Рисунку 3.3
73
ЧДТУ 2216.020 ПЗ

Рис. 3.3 – Діаграма пакетів програмного забезпечення генерації даних

3.2.4 Архітектурне проектування
Аналіз структурних і функціональних відношень між елементами моделі
системи є основним призначенням логічного представлення.
Однак для створення конкретної фізичної системи необхідно деяким
чином реалізувати всі елементи логічного представлення в певні матеріальні
сутності. Фізичне представлення моделі — це ще один аспект модельного
представлення, який призначений для опису таких реальних сутностей.
Створення архітектури – це найвищий рівень проектування. Логічна
архітектура описує систему за допомогою принципової організації її
компонентів, таких як пакети, програмні класи та підсистеми[18]. Оскільки вона
не визначає способи розгортання цих елементів у різних операційних системах
або на фізичних комп’ютерах у мережі, вона називається логічною.
Архітектуру генерації даних до даної роботи можна подивитись на
Рисунку 3.4.
74
ЧДТУ 2216.020 ПЗ

Рис. 3.4 – Архітектура генерації даних

3.2.4.1 Діаграма компонентів
Програмне забезпечення включає лише один будівельний блок для
створення фізичної архітектури об’єктноорієнтованої системи. Визначення,
внутрішня структура та залежності набору компонентів представлені діаграмою
компонентів. Файли, бази даних, бібліотеки, модулі, пакети, інтерфейси
інтелектуальних систем тощо можуть бути фізичними компонентами.
Елемент моделі, який представляє певну модульну частину системи з
інкапсульованим вмістом, називається компонентом. У мові UML компонентом
може бути будь-який автономний елемент системи або підсистеми.
Внутрішні частини компонентів приховані та недоступні ззовні, за
винятком тих, які доступні за допомогою його інтерфейсів. Компоненти можуть
бути пов’язані між собою за допомогою певних зв’язків. Розгляд компонентів як
можна незалежнішими від свого оточення визначає ці зв’язки.
75
ЧДТУ 2216.020 ПЗ

Рис. 3.5 – Діаграма компонентів програмного забезпечення генерації даних

3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Фізичне представлення програмної системи не може бути повним, якщо
немає інформації про платформу та обчислювальні засоби, на яких вона працює.
Розробка звичайної програми, яка працює локально на комп’ютері користувача
без використання периферійних пристроїв і ресурсів, не вимагає розробки
додаткових діаграм[34]. Тим не менш, ситуація виглядає зовсім інакше, коли
мова йде про розробку корпоративних додатків.
По-перше, складні програмні системи можуть працювати в мережі за
допомогою різних обчислювальних платформ і технологій доступу до
розподілених баз даних. У випадку, якщо є локальна корпоративна мережа,
необхідно вирішити низку додаткових завдань щодо оптимального розміщення
компонентів по вузлах цієї мережі, що визначає загальну продуктивність
програмної системи.
По-друге, у зв’язку з інтеграцією програмної системи з мережею Інтернет
необхідно вирішити додаткові завдання, пов’язані з проектуванням системи. Ці
завдання включають забезпечення безпеки, криптозахищеності та безпеки
доступу до інформації корпоративних клієнтів[33]. Ці елементи залежать від
того, щоб проект був реалізований у формі вузлів системи, які вже є в системі,
таких як сервери, робочі станції, брандмауери, канали зв’язку та сховища даних.
76
ЧДТУ 2216.020 ПЗ
Нарешті, технології доступу та маніпулювання даними, які
використовуються в загальній схемі «клієнт-сервер», вимагають розміщення
значних баз даних у різних частинах корпоративної мережі, а також резервне
копіювання, архівування та кешування цих баз даних для забезпечення
необхідної продуктивності системи в цілому. Крім того, для специфікації
технологічних і програмних характеристик реалізації розподілених архітектур
необхідно візуальне представлення цих елементів.
Діаграми розгортання зручні для демонстрації розподілу елементів
(результатів розробки) програмного додатку за апаратними вузлами
комп’ютерної системи. У українській літературі їх також називають діаграмами
розміщення.
Проектована система складається з компонентів (зображених на діаграмах
компонентів), які розташовані по обчислювальним вузлам (зображених на
діаграмах розміщення)[19].
За допомогою діаграми розгортання можна показати «фізичну» структуру
програмної системи. На етапі проектування фізична сукупність вузлів
представлена як основа для реалізації системи в діаграмі розгортання. Діаграма
розгортання складається з трьох основних компонентів: артефактів, вузлів і
їхніх відносин.
Діаграма розгортання показує, як певні програмні артефакти, такі як
виконувані файли, відповідають обчислювальним вузлам, які виконують
обробку. Вони демонструють розміщення програмних елементів у фізичній
архітектурі системи та взаємодію між фізичними елементами, як правило,
мережеву. Діаграма розгортання допомагає краще зрозуміти фізичну
архітектуру[32].
77
ЧДТУ 2216.020 ПЗ
Таким чином, діаграма розгортання містить лише елементи фізичного
представлення моделі, які існують під час роботи програмної системи. На
діаграмі розгортання зазвичай не показуються елементи, які не
використовуються на етапі виконання. Наприклад, компоненти з текстовими
програмами можуть бути показані на діаграмі компонентів, але не показані на
діаграмі розгортання.
На відміну від діаграм логічного представлення та компонентів, діаграми
розгортання, як правило, створюються в одному екземплярі, оскільки вони
повинні повністю відобразити всі особливості реалізації та топології системи.
3.2.5 Моделювання поведінки системи
При розробці програмної системи не достатньо відповісти на питання, що
робить система? і з чого вона складається; необхідно відповісти на питання, як
вона працює. Модель поведінки дає відповідь на це питання.
Як програма складається, так і як вона працює, повністю залежать від її
коду[31]. Незважаючи на це, програма є просто записом алгоритму. Таким
чином, модель поведінки — це опис алгоритму, який керує роботою системи.
Діаграми діяльності, взаємодії та кінцевого автомата показують поведінку
системи.
Діаграма діяльності зручна для опису потоку управління, наприклад,
послідовності елементарних кроків, які виконуються під час виконання окремої
операції або реалізації складного варіанта використання.
Діаграми взаємодії, також відомі як діаграми послідовності або діаграми
комунікації, використовуються для опису взаємодії декількох програмних
об’єктів між собою.
78
ЧДТУ 2216.020 ПЗ
У UML є багато інструментів для опису поведінки. Вибір засобу залежить
від типу поведінки, яку потрібно описати.
Кінцевий автомат може бути представлений як діаграма станів, щоб
показати життєвий цикл певного об’єкта, поведінка якого залежить від його
історії або обробки асинхронних стимулів. Це означає, що стани кінцевого
автомата відповідають станам об’єкта, тобто різноманітним значенням
атрибутів, а переходи відповідають виконанню операцій.
3.2.5.1 Діаграма діяльності
Немає сумніву, що опис функціональних вимог у вигляді варіантів
використання є критично важливою частиною процесу розробки програмного
забезпечення. На цьому етапі відбувається узгодження з замовником дизайну та
функціонування системи.
Тепер необхідно спроектувати та реалізувати систему відповідно до
встановлених стандартів. На цьому етапі завдання аналітика полягає в тому,
щоб опис варіантів використання перетворився на технічно грамотний опис
структури та поводження системи, який буде зрозумілим архітекторам і
розробникам. Таким чином, уточнення, деталізація та конкретизація варіантів
використання є важливою частиною переходу від моделювання використання
до інших типів моделювання.
Діаграма діяльності дозволяє детально показати кожен варіант
використання та його сценарії. З іншого боку, діаграма варіантів використання
дає «вид зверху» на функціональність системи.
Блок-схеми та діаграми діяльності є універсальними засобами опису
алгоритмів. Їх також можна успішно використовувати для імітації поведінки
людей, пристроїв і організацій під час виконання бізнес-процесів[30].
79
ЧДТУ 2216.020 ПЗ
В цьому випадку «діяльність» — це завдання, які потрібно виконати
вручну або за допомогою засобів автоматизації. Діаграма діяльності – це
теоретично узагальнене представлення алгоритму, який реалізує варіант
використання, який був аналізований. В основному діяльність є окремим
компонентом поведінки, який може включати інші діяльності або окремі дії.
Результат розробки діаграми діяльності можна побачити на Рисунку 3.9.

Рис. 3.9 – Діаграма діяльності програмного забезпечення генерації даних
80
ЧДТУ 2216.020 ПЗ
3.2.5.2 Діаграма послідовності
Діаграми взаємодії використовуються для моделювання поведінки,
описуючи, як об’єкти взаємодіють один з одним для виконання певного
завдання або досягнення певної мети. Об’єкти програмної системи повинні
взаємодіяти один з одним через передачу повідомлень. Поведінка, яка базується
на обміні повідомленнями між групою об’єктів, відома як взаємодія[29].
Діаграми взаємодії використовуються на різних рівнях моделювання для
опису поведінки конкретних операцій і варіантів використання в цілому[20].
У цьому типі діаграм можна показувати взаємодію програмних об’єктів,
також відомих як примірники класів, а також взаємодію примірників інших
класифікаторів, таких як дійові особи, варіанти використання, компоненти
тощо.
Діаграми послідовності та комунікації є двома найпоширенішими типами
діаграм взаємодії.
Діаграми комунікації та діаграми послідовності не схожі з точки зору
зображення, але вони мають однаковий сенс. Ці діаграми описують одне і те ж:
послідовність передачі повідомлень між об’єктами під час їх взаємодії.
Діаграми комунікації віддають перевагу структурі зв’язків між об’єктами,
за якими передаються повідомлення, тоді як діаграми послідовності
підкреслюють впорядкованість повідомлень у часі.
Діаграма послідовності розроблена для моделювання поведінки шляхом
опису протоколу обміну повідомленнями між екземплярами класифікаторів, які
взаємодіють під час виконання одного з можливих сценаріїв.
На діаграмі послідовності вважається, що є окремий напрямок у течії
часу. Хоча більшість людей вважають, що час тече зверху вниз, іноді це не так.
Наприклад, можна вважати, що час тече зліва направо, якщо є спеціальний
коментар, що пояснює це.

81
ЧДТУ 2216.020 ПЗ
3.2.5.3 Діаграма комунікації
Діаграма комунікації, також відома як діаграма кооперації в UML , описує
поведінку як взаємодію, наприклад протокол обміну повідомленнями між
об’єктами. Один і той же об’єкт може виконувати різні функції. Таким чином,
взаємодія завжди відбувається в певному контексті, який визначається
множиною учасників взаємодії об’єктів і зв’язків.
Комунікаційні діаграми допускають довільне розміщення великої
кількості об’єктів, що дозволяє малювати зв’язки, що показують відношення
між об’єктами, і використовувати нумерацію для представлення послідовності
повідомлень, замість того, щоб малювати кожного учасника у вигляді лінії
життя і показувати послідовність повідомлень, розташовуючи їх по вертикалі,
як це робиться в діаграмах послідовності.
Двома характеристиками відрізняють діаграми комунікації від діаграм
послідовностей: шляхом, або зв’язком, і порядковим номером повідомлення.
Числа після імен повідомлень показують відносну послідовність.
3.2.5.4 Діаграма скінченного автомату
Діаграма станів, яка також називається діаграмою кінцевого автомата,
показує кінцевий автомат, виділяючи потік управління, наступний від стану до
стану. Завершений автомат — це процес, який визначає послідовність станів
протягом усього існування об’єкта[28]. Набагато точніше, діаграма показує
кожен стан об’єкта, тобто те, що він робить, коли отримує сигнал про подію. В
залежності від стану об’єкта він може реагувати на одну і ту ж подію різними
способами. Зміна стану зазвичай відбувається в результаті виконання дії. Таким
чином, поняття «подія» і «стан» є основою моделювання станів.
Кожен клас може мати кілька діаграм станів, кожна з яких відповідає за
поведінку в часі для проектованого додатку. Клас з кількома станами має
важливу поведінку в часі. Можна ігнорувати поведінку класу в часі, якщо він
має лише один стан.
82
ЧДТУ 2216.020 ПЗ
У порівнянні з класичними уявленнями автоматів діаграми станів UML
більш прості та зрозумілі, але їх використання вимагає більшої підготовки
користувача та вимагає більшої «кмітливості» та «уважності» інструментів
моделювання.
Діаграма кінцевого автомата моделює життєвий цикл одного об’єкта і
визначає, що поведінка системи є єдиним цілим. Таким чином, автоматичний
метод зручно використовувати для формалізації динаміки окремого, важкого
для розуміння, блоку системи.
У більшості випадків кінцевий автомат представляє динамічні елементи
модельованої системи у формі орієнтованого графа, вершини якого
відповідають станам, а дуги відповідають переходам. У цьому випадку
поведінка моделюється як послідовне переміщення від вершини до вершини по
дугах, які з’єднують їх за орієнтацією.

Рис. 3.10 Діаграма скінченного автомату програмного забезпечення генерації
даних
83
ЧДТУ 2216.020 ПЗ
Розділ 4. Розробка та тестування програмного забезпечення
4.1 Розробка програмного комплексу
4.1.1 Обґрунтування вибору засобів реалізації
Для реалізації програмного забезпечення генерації даних для тестування
складних програмних систем, було обрано зробити веб-додаток, який на основі
назв полів та їх типів даних генеруватиме рандомні дані у визначеному
користувачем форматі. Також, дані можна буде завантажити у тому ж самому
форматі. Програмна реалізація виконана за допомогою мови програмування С#
та бібліотека Bogus для бек-енд частини та фреймворк Blazor для фронт-енд
частини. Наведемо основні функції та переваги обраних інструментів.
C# — об’єктно-орієнтована мова програмування, яка використовує
безпечну систему типізації для платформи.NET. Розроблено Андерсом
Гейлсбергом, Скотом Вілтамутом і Пітером Гольде під егідою дослідницького
відділу Microsoft Research (належить Microsoft)[27].
C# має синтаксис, схожий на C++ і Java. Мовний формат XML підтримує
строгу статичну типізацію, поліморфізм, перевантаження операторів,
вказівники на функції-члени класів, атрибути, події, властивості, винятки та
коментарі[21]. С# перейняв багато від своїх попередників, таких як C++, Object
Pascal, Модула та Smalltalk, але виключає деякі моделі, які зарекомендували
себе як проблемні при розробці програмних систем. Наприклад, мова С#, на
відміну від C++, не підтримує множинне успадкування класів.
Платформа .NET. .NET Framework — програмна технологія, розроблена
Microsoft для створення звичайних програм і веб-застосунків[22]. Багато в
чому є розвитком ідей і принципів, які використовуються в Java. .NET
передбачає сумісність служб, написаних різними мовами. Незважаючи на те,
84
ЧДТУ 2216.020 ПЗ
що Microsoft стверджує, що це перевага.NET, платформа Java також має таку ж
можливість.
.NET — це технологія, яка працює на різних платформах. Зараз існує
версія для Windows, FreeBSD від Microsoft і варіант технології для Linux в
проекті Mono, який є частиною угоди між Microsoft і Novell, DotGNU[en][23].
Створення середовищ виконання (CLR — Common Language Runtime)
для програм.NET включає захист авторських прав. Багато компаній створюють
компілятори.NET, які працюють на різних мовах безкоштовно.
Поточна стабільна версія мови C# 11.0, яка була випущена як компонент
платформи в 2022 році, діє станом на вересень 2023 року.NET7.0
.NET складається з двох основних компонентів: середовища виконання,
яке є віртуальною машиною, і інструментарію розробки[24].
Середовище розробки.NET також створює байт-код, призначений для
виконання віртуальною машиною, як і технологія Java. Цей комп’ютер.NET
використовує вхідну мову Common Intermediate Language (CIL), яка також
називається MSIL (Microsoft Intermediate Language) або просто IL[25].
Кроссплатформність можна досягти на рівні скомпільованого проєкту (в
термінах.NET: збірка), а не на рівні початкового тексту, як це можна зробити з
кодом C. Перед запуском збірки в середовищі виконання (CLR) вбудований в
середовище JIT-компілятор перетворює байт-код в машинні коди цільового
процесора за допомогою швидкої компіляції на льоту[26].
Blazor — безкоштовна веб-платформа з відкритим вихідним кодом, яка
дозволяє розробникам розробляти веб-додатки, які використовують C# і
HTML. Це продукт корпорації Microsoft.
Додаток Blazor має можливість взаємодіяти з JavaScript, оскільки обидва
85
ЧДТУ 2216.020 ПЗ
вони працюють на стороні клієнта. Наприклад, він може викликати JavaScript-
функції за допомогою методів.NET.
З’явилися п’ять різних редакцій Blazor.
- Blazor-сервер: ці програми встановлюються в ASP.NET Razor поверх
ASP.NET Core. У зв’язку з тим, що віддалені клієнти функціонують
як тонкі клієнти, сервер виконує значну частину обробки. Через
з'єднання SignalR веб-браузер клієнта завантажує невелику сторінку
та оновлює свій користувальницький інтерфейс. .NET Core 3 включає
Blazor Server.
- Blazor WebAssembly — це односторінковий додаток, який
завантажується у веб-браузер клієнта перед запуском. Залежно від
додатка, розмір завантаження більший, ніж Blazor Server, і обробка
повністю виконується на клієнтському обладнанні. Тим не менш, цей
тип програм відрізняється швидким часом відгуку. Як випливає з
назви, цей клієнтський фреймворк базується на WebAssembly, а не на
JavaScript, хоча вони можуть працювати разом. 19 травня 2020 року
було випущено Blazor WebAssembly 3.2.0.
Microsoft планує випустити Blazor PWA і Blazor Hybrid у найближчому
майбутньому. Він підтримує прогресивні веб-додатки (PWA). Незважаючи на
те, що останній є платформним фреймворком, він відображає користувацький
інтерфейс за допомогою веб-технологій, таких як HTML і CSS. Третій, Blazor
Native, платформний фреймворк, який створює власний користувальницький
інтерфейс для платформи, також розглядається, але поки що його планування
ще не завершено.
Bogus є простим генератором фейкових даних для мов.NET, таких як C#,
86
ЧДТУ 2216.020 ПЗ
F# і VB.NET. По суті, Bogus — це порт faker.js у C#, натхненний синтаксичним
цукром FluentValidation.
4.1.2 Опис структурної (функціональної) схеми
На основі поставлених завдань, які повинен виконувати програмний
модуль було розроблено структуру модуля, на якій зображено його основні
блоки, інтерфейси та взаємодію між ними (рис. 4.1).

Bogus Платформа SDK
.NET
Інтерфейс для Клієнт
генерації

Рис. 4.1 – Структура програмного модуля генерації тестових даних

У програмному модулі представлено інтерпретацію генетичного
алгоритму генерації тестових даних, який було описано у другому розділі. Рис.
4.2 показує схему алгоритму програмного модуля генерації тестових даних.
87
ЧДТУ 2216.020 ПЗ
!"#$%"& D
!"#$%&"'$(
)")*+,-.,/( ?$&
)"#$%&"'.( =.3-0'$(
%01%"'.(2$3.(*( )")*+,-.,
4"56$%.(!"#
@.
71%$3"'+033,(
$3"%$-.8( A$)*1&(AB"C( AN050R033,(
960%$2$3:;< .%05$-.C(%01%* GL0305"'$3"C(
)")*+,-.C(*(
4"56$%.(!"#(
K3$+.G(
50G*+>%$%*(%BL"(
A$)*1&(%01%.' %01%*(
)5"1+*;"'*'$#06(
&'#A()G+G,
E04+0&1.,F( M-.3&$(
.3.-.$+.G$-.,( )5:2$%3"1%.(
)")*+,-.C(%$( "1"N:3(
%01%"'"C(6"20+. 95"G5$;*3"&(
-.+>"'"C(4*3&-.C<
H0105:$+.G$-.,(
)"#$%&"':;( O0+0&-.,/
%01%"':;(2$3:;(%$( O;50P*'$33,/
).21%$3"'&$(*(DB Q*%$-.,
I*()")*+,-.J
D
=.30->

Рис. 4.2 – Схема алгоритму роботи програмного модуля генерації тестових
даних

4.1.3 Опис логічної схеми системи
Для реалізації даної задачу, я почав зі створення тестового Console
Application, щоб визначити можливості бібліотеки Bogus.
88
ЧДТУ 2216.020 ПЗ
В ході створення цього додатку було вирішено генерувати дані за
допомогою моделі, яка має поле Name – назва поля, PropertyType – тип поля та
Options – значення для задання певного форматування. Дана модель має
наступний вигляд:
public class PropertyConfig
{
public string Name {get; set;} = string.Empty;
public string Type {get; set;} = string.Empty;
public Options? ConfigOptions {get; set;} = null;
}
Використовючи цю модель, створюється об’єкт з набором даних пар
{ключ: значення}.
Також було розроблено клас TypeConverter, який має в собі набір
методів для конвертації списку об’єктів у відповідний формат файлу, який
обрав користувач. Ось один із прикладів такого методу:
public static string ConvertToJson(List<Dictionary<string, object>> dataList)
{
return JsonConvert.SerializeObject(dataList);
}
Останній елемент, який було додано до тестового проєкту це метод, який
надає можливість встановлювати отримані дані у папку Downloads у форматі,
який вказав користувач. Ось приклад методу завантаження JSON файлу:
static void SaveDataToJsonFile(object data, string filePath)
{
try
{
// Serialize the data to JSON
string jsonData = JsonSerializer.Serialize(data);
89
ЧДТУ 2216.020 ПЗ
// Write the JSON data to the file
File.WriteAllText(filePath, jsonData);
}
catch (Exception ex)
{
Console.WriteLine($"Error saving data to file: {ex.Message}");
} }
Після отримання усіх бажаних результатів, було створено Blazor проєкт,
де було створено компоненти для роботи з нашою програмою, а також на основі
тестового Console Application додано логіку для генерації, форматування та
завантаження даних.
4.1.4 Розробка бази даних
У даній роботі не було використано інтеграцію додатка із базою даних,
оскільки суть завдання полягає в генерації даних, які можна було би
використати у тестуванні програмного забезпечення. Моя програма генерує дані
та надає можливість скопіювати ці дані із виводу на сторінці генерації або ж
завантажити дані на комп’ютер та використовувати у своїх проектах та цілях з
можливістю змінити дані, якщо у цьому є потреба.
4.1.5 Розробка інтерфейсу користувача
Для розробки інтерфейсу, як це вже було зазначено раніше було
використано фреймворк Blazor. Завдяки цьому фреймворку можна дуже легко
створювати елементи та компоненти які можуть пере використовуватися на
інших сторінках.
Таким чином, використовуючи дану технології було досягнено наступних
результатів інтерфейсу користувача:
90
ЧДТУ 2216.020 ПЗ

Рисунок 4.3 – Інтерфейс програмного забезпечення генерації даних

4.2 Тестування системи
Тестування програмного забезпечення — це процес технічного
дослідження, призначений для виявлення інформації про якість продукту
відповідно до ситуації, в якій його мають використовувати. Термін «тестування
програмного забезпечення» походить від англійської мови. Техніка тестування
також включає випробування програмних складових для оцінки та процес
пошуку помилок або інших дефектів.
Тестування програмного забезпечення — це процес перевірки
відповідності заявлених до продукту вимог і його реальної функціональності
шляхом спостереження за його роботою в штучно створених ситуаціях і на
обмеженому наборі тестів, обраних спеціально.
Мають здатність оцінювати:
- відповідність вимогам проєктувальників і розробників,
- швидкість виконання функцій,
- практичність,
91
ЧДТУ 2216.020 ПЗ
- сумісність із програмним забезпеченням та операційними системами,
відповідність завданням замовника
Стратегія тестування полягає в тому, щоб провести всі можливі тести з
урахуванням наявного часу та ресурсів, оскільки кількість можливих тестів
навіть для простих програмних компонентів практично нескінченна. З цієї
причини програмне забезпечення (ПЗ) тестує стандартне виконання програми,
щоб знайти баги або помилки.
Тестування програмного забезпечення може надати незалежну,
об’єктивну інформацію про якість програмного забезпечення та ризики відмови
як для користувачів, так і для замовників.
Як тільки створено виконуваний код (навіть частково готовий), можна
розпочати тестування. Коли та як буде проводитися тестування, зазвичай
визначається в процесі розробки. Наприклад, під час поетапного процесу
більшість тестів відбувається після визначення системних вимог, а потім вони
реалізуються в тестових програмах. Однак програмування та тестування часто
відбуваються одночасно через вимоги гнучкої розробки ПЗ.
4.2.1 Модульне тестування
Модульне тестування — це спосіб ізоляції та тестування окремих одиниць
коду для визначення того, наскільки добре працює кожен компонент. Цей метод
використовується замість того, щоб тестувати програмне забезпечення,
розділяючи його на менші частини, щоб переконатися в коректності окремих
компонентів.
Для реалізації модульного тестування програмного забезпечення генерації
даних, нам потрібно перевірити як працює 4 основних модуля, які відповідають
за генерацію та роботу з даними. Перед тим як вивести результати опишемо
кожен модуль та за що він відповідає:
92
ЧДТУ 2216.020 ПЗ
ObjectGenerator – даний модуль відповідає за створення списку об’єктів з
тою кількістю яку вказав користувач, а також використовує інший модуль для
заповнення цих об’єктів даними.
GenerateValueService – даний сервіс має набір функцій для генерації даних
різних типів.
TypeConverter – цей модуль відповідає за конвертацію списку з отриманих
об’єктів у формат, який вказав користувач(JSON, XML, CSV).
FileInstaller – як це випливає із назви даний модуль надає функції для
завантаження даних на комп’ютер коритсувача.
Результати модульного тестування зображено в таблиці 4.1
Таблиця 4.1
Модуль Опис Результат
ObjectGenerator Модуль працює коректно Виконано
GenerateValueService Модуль працює коректно Виконано
TypeConverter Модуль працює коректно Виконано
FileInstaller Модуль працює коректно Виконано

4.2.2 Інтеграційне тестування
Інтеграційне тестування є важливою частиною тестування програмного
забезпечення, мета якого полягає в тому, щоб визначити, наскільки добре
інтегруються різні програми.
Більшість сучасних компаній щодня покладаються на кілька програмних
модулів; інтеграція цих програм дозволяє їм працювати разом, щоб
оптимізувати та підвищити ефективність.
Повна інтеграція робить програмні модулі ефективними, тому
інтеграційне тестування є важливим. Коли кожен програмний модуль розробляє
інший розробник за допомогою зовсім іншої логіки програмування, немає
93
ЧДТУ 2216.020 ПЗ
причин сподіватися, що інтеграція кожного модуля буде гладкою з самого
початку.
Тестування інтеграції дозволяє ІТ-спеціалістам оцінити, наскільки добре
різні модулі працюють разом, і внести зміни, щоб покращити їх ефективність.
Для реалізації даного тестування потрібно перевірити роботу різних
модулів один з одним. Результати тестування можна дивитись в таблиці 4.2
Таблиця 4.2
Модуль Взаємодія Результат
ObjectGenerator Даний модуль взаємодіє разом із View Виконано
програми, яка передає йому шаблон об’єкту
поля якого потрібно заповнити даними, а
також кількість яку потрібно згенерувати
TypeConverter Даний модуль взаємодіє із ObjectGenerator та Виконано
View, оскільки його задача полягає в тому,
щоб отримати згенерований список з
об’єктами і конвертувати його в той формат,
який вказав користувач на клієнті(View)
FileInstaller Даний модуль взаємодіє із View, оскільки він Виконано
бере згенеровані дані, які відображені на
сторінці клієнта та надає можливість
завантажити їх у визначеному форматі

4.2.3 Системне тестування
Тестування програмного забезпечення на повній, інтегрованій системі
називається системним тестуванням. Його мета полягає в тому, щоб
переконатися, що система відповідає вихідним функціональним і
нефункціональним вимогам.
94
ЧДТУ 2216.020 ПЗ
Об’єкт перевірки виділяється червоним кольором.
За допомогою системного тестування можна виявити наступні дефекти:
- неправильне використання можливостей системи
- непередбачені суми даних користувача
- проблеми з гармонією з оточенням
- непередбачені випадки використання
- невиконання функціональних вимог
- незручний для використання
Метод «Чорного ящика» перевіряє лише «зовнішні» елементи, які не
потребують взаємодії з внутрішнім складом програми. Рекомендується також
виконувати його в середовищі, яке найближче до середовища кінцевого
користувача.
Що стосується системного тестування, можна виділити два підходи:
- на основі вимог. Тестування проводиться відповідно до
функціональних або нефункціональних вимог, для яких є тестові
прецеденти.
- на основі прикладів використання Тестування ґрунтується на
варіантах використання продукту, які є основою для користувачів-
прецедентів. Тестові прецеденти створюються для кожного з даних
користувальницьких прецедентів.
Для проведення даного тестування було розглянуті усі функціональні та
нефункціональні вимоги і створено таблицю з результатами цього тесту, який
можна побачити в таблиці 4.3.
95
ЧДТУ 2216.020 ПЗ
Таблиця 4.3
Вимоги Результат
Завантаження тестових даних; Виконано
Інтерфейс користувача; Виконано
Вибір типу, згенерованих даних; Виконано
Можливість завантажити Виконано
згенеровані дані;
Вибір формату, завантажених даних Виконано
Виконано
Продуктивність Виконано
Сумісність Виконано
Масштабованість Виконано

4.2.4 Приймальне тестування
Тестування, відоме як прийняття, проводиться на етапі здачі готового
продукту (або готової частини продукту) клієнту. Мета цього тестування
полягає в тому, щоб визначити готовність продукту шляхом проходження
тестових сценаріїв і випадків, які побудовані на основі специфікації вимог до
ПЗ, що розробляється.
Можливі результати приймального тестування:
- проект відправлено на доопрацювання.
- прийняття його замовником як виконаної роботи.
Це останній етап тестування продукту перед його оприлюдненням. При
цьому він не надто ретельно, всеохоплюючим і повним, оскільки тестується
лише основні функції.
96
ЧДТУ 2216.020 ПЗ
Приймальне тестування проводиться або тестувальниками компанії-
розробника, або групою тестувальників, які представляють інтереси замовника.
Залежить від бажань замовника.
Основним функціоналом моєї програми є:
- можливість вказати конкретний тип для поля, а не загальний(рядок,
число і т.д)
- видалити поле, яке не потрібно генерувати
- мати здатність згенерувати число або дату у певному діапазоні, який
вказав користувач
- згенерувати дані на основі об’єкту і вказаної кількості
- можливість завантажити згенеровані дані
Результати тестування зображено на таблиці 4.4.
Таблиця 4.4
Дія Результат
можливість вказати конкретний тип Виконано
для поля, а не загальний(рядок, число
і т.д)
видалити поле, яке не потрібно Виконано
генерувати
мати здатність згенерувати число або Виконано
дату у певному діапазоні, який вказав
користувач
згенерувати дані на основі об’єкту і Виконано
вказаної кількості
можливість завантажити згенеровані Виконано
дані

97
ЧДТУ 2216.020 ПЗ
4.3 Приклади впровадженого програмного комплексу
Перейшовши на сайт розробленого програмного забезпечення перше що
побачить користувач це форму, яку зображено на рис. 4.4. За допомогою даної
форми користувач може створити шаблон об’єкту, який йому потрібно
створити, на сторінці за замовчуванням вже показано приклад поля. Для того
щоб додати поле, потрібно натиснути на кнопку “Add another field”, яку також
можна побачити на рис. 4.4, дана кнопка додасть ще одне поле у шаблон
об’єкту.
У поля можна змінити його назву, а також тип який потрібно
згенерувати(рис. 4.5). При цьому потрібно, щоб назва кожного поля була
унікальною, тому що у разі якшо імена будуть повторюватись, то користувачу
повернеться помилка про те, що поле з такою назвою вже існує (рис. 4.6).
Після того як усі поля були створені, вказано формат і кількість можна
натиснути на кнопку «Generate», щоб згенерувати дані(рис. 4.7).

Рис. 4.4 – Початковий екран при запуску програми
98
ЧДТУ 2216.020 ПЗ

Рис. 4.5 – Список типів, які можна згенерувати для поля

Рис. 4.6 – Виведення помилки у разі однакових ключів у полей
99
ЧДТУ 2216.020 ПЗ

Рис. 4.7 – Результат генерації даних

100
ЧДТУ 2216.020 ПЗ
ВИСНОВКИ
У дипломній роботі були розглянуті основні функціональні можливості
різних систем генерації тестових даних, проведено їх порівняльний аналіз і
визначено їхні переваги та недоліки. Можливість генерації тестових даних у
різних форматах є однією з переваг таких систем. Недоліками даних систем є
наступні: немає можливості автоматично прив’язати тестові дані до самих
тестів, що збільшує час тестування; немає можливості вводити свої регулярні
вирази як початковий шаблон; Для створення тестових даних було вивчено
структуру та техніку типових систем. Структурна схема показує, де будуть
впроваджені покращення: алгоритми та програмні засоби. Пропонується
створити свій автоматичний постачальник даних, щоб покращити процес
генерації тестових даних. Було розроблено унікальну структурну схему, яка
включає постачальника тестових даних. Було розкрито, як буде працювати
постачальник даних, використовуючи два рівні абстракції builder і compose.
Для створення тестових даних були розглянуті основні принципи та
підxоди. Визначено, якими характеристиками мають володіти тестові дані.
Модель генерації тестових даних представлена тут. Існує два способи
написання тестів з генерацією тестових даних: тестування на основі даних
(DDT) і керована поведінка розробки (BDD). Було проведено аналіз основних
методів генерації тестових даних, виявлено недоліки цих методів і було
прийнято рішення використовувати більш новий підхід до генерації тестових
даних.
Генетичний алгоритм був обраний для створення тестових даних.
Досліджено характеристики алгоритму, а також процес генерації тестових
даних. Було створено обмеження, які визначають правила, за якими алгоритм
повинен діяти. Існує цільова функція, яка дозволить оцінити придатність
одиниці тестових даних до їх використання. Етапи селекції (відбору),
101
ЧДТУ 2216.020 ПЗ
схрещування та мутації також описані. Опис кожного етапу генетичного
алгоритму дозволив створити як сам алгоритм, так і геометричну
інтерпретацію для генерації тестових даних.
Було створено веб-додаток генерації тестових даних на основі
структурної схеми з використанням постачальника даних та алгоритму. Веб-
додаток працює із збірником проекту .NET і мовою програмування C#. У
кінцевому варіанті є веб-додаток, який можна використовувати до різних
клієнтських автоматизованих програм.
Уникаючи «парадоксу пестицида», програмний модуль дозволяє
тестувальнику легко використовувати елементи веб додатку для автоматичної
генерації тестових даних. Автоматичний постачальник даних позбавляє
тестувальника від необхідності робити ручне втручання, щоб прив’язати нові
тестові дані та надлишковий код до тестів.
Веб-додаток базується на .NET і програмній платформі SDK.
Тестувальники, які розробляють свої фреймворки на цій платформі, а також
тестувальники, які працюють з будь-якими тестовими «ранерами», які сумісні
з цією платформою, мають можливість використовувати цей веб-додаток.
Рекомендується використовувати матеріали дипломної роботи під час
проведення наукових досліджень, навчання фахівців з системного
програмування, тестування та використання автоматизованих інструментів для
автоматизованого тестування програмного забезпечення.
Прогнозні припущення про розвиток об’єкту та предмету дослідження
— це простий веб-додаток, який можна використовувати для впровадження в
автоматизовані тестові програмні продукти в різних сферах автоматизованого
тестування програмного забезпечення.

102
ЧДТУ 2216.020 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Гломозда Д.К. Координація в асинхронних обчислювальних мережах:
автореф. дис. на здобуття наук. ступеня канд. тех. наук : спец. 01.05.03
"Математичне та програмне забезпечення обчислювальних машин і
систем" / Д. К. Гломозда. – Київ, 2011. – 20 с.
2 Титенко С.В. Програмне забезпечення онтологічно-орієнтованої
системи керування інформаційно-навчальним Web-контентом :
автореф. дис. на здобуття наук. ступеня канд. тех. наук : спец. 01.05.03
"Математичне та програмне забезпечення обчислювальних машин і
систем" / С. В. Титенко. — Київ, 2011. — 20 с.
3 Рибчак З.Л. Методи та засоби підтримки прийняття рішень
формування та розвитку територіальних громад: автореф. дис. на
здобуття наук. ступеня канд. тех. наук : спец. 01.05.03 "Математичне
та програмне забезпечення обчислювальних машин і систем" / С.В.
Титенко. — Львів, 2019. — 23 с.
4 Методологія та організація наукових досліджень: навч. посібник
/В.М. Михайлов [та ін.]. – Х.: ХДУХТ, 2014 – 220 с.
5 Методика та організація наукових досліджень: Навч. посіб. /С.Е.
Важинський, Т І. Щербак. – Суми: СумДПУ імені А. С. Макаренка,
2016. – 260 с.
6 Методологія наукових досліджень: навч. посіб. / В.І. Зацерковний, І.В.
Тішаєв, В. К. Демидов. – Ніжин: НДУ ім. М. Гоголя, 2017. – 236 с.
7 Методологія та організація наукових досліджень: навч. посіб. /І.С.
Добронравова, О.В. Руденко, Л.І. Сидоренко та ін.; за ред. І.С.
Добронравової (ч. 1), О.В. Руденко (ч. 2). – К.: ВПЦ "Київський
університет", 2018. – 607 с.
103
ЧДТУ 2216.020 ПЗ
8 Імітаційне моделювання систем та процесів: Електронне навчальне
видання. Конспект лекцій / В. Б. Неруш, В. В. Курдеча. – К.: НН ІТС
НТУУ «КПІ», 2012. – 115 с.
9 Стеценко, І.В. Моделювання систем: навч. посіб. [Електронний ресурс,
94 текст] / І.В. Стеценко; М-во освіти і науки України, Черкас. держ.
технол. ун-т. – Черкаси : ЧДТУ, 2010. – 399 с.
10 Математичне моделювання: навчальний посібник /В.Г. Маценко. –
Чернівці: Чернівецький національний університет, 2014.–519 c.
11 Чуйко Г. П. Математичне моделювання систем і процесів :
[навчальний посібник] / Г. П. Чуйко, О. В. Дворник, О. М. Яремчук. –
Миколаїв : Вид-во ЧДУ імені Петра Могили, 2015. – 244 с.
12 Моделі й методи прийняття рішень: навч. посіб. /С.А. Ус, Л.С.
Коряшкіна; М-во освіти і науки України, Нац. гірн. ун-т. – Д. : НГУ,
2014. – 300 с.
13 Теорія прийняття рішень [текст] підручник. /За заг. ред. Бутка М. П.
[М. П. Бутко, І. М. Бутко, В. П. Мащенко та ін.] – К.: «Центр учбової
літератури», 2015. – 360 с.
14 Згуровський М.З., Панкратов Н.Д. Основи системного аналізу. – К.:
Видавнича група BHV, 2007. – 544 с.: іл.
15 Методи аналізу даних: навчальний посібник для студентів /В.Є.
Бахрушин. – Запоріжжя: КПУ, 2011. – 268 с.
16 Марченко О.О., Россада Т.В. Актуальні проблеми Data Mining:
Навчальний посібник для студентів факультету комп’ютерних наук та
кібернетики. – Київ. – 2017. – 150 с.
17 Інтелектуальний аналіз даних: Комп’ютерний практикум
[Електронний ресурс]: навч. посіб. для студ. спеціальності 122
«Комп’ютерні науки та інформаційні технології», спеціалізацій
«Інформаційні системи та технології проектування», «Системне
104
ЧДТУ 2216.020 ПЗ
проектування сервісів» /О.О. Сергеєв-Горчинський, Г. В. Іщенко; КПІ
ім. Ігоря Сікорського. – Електронні текстові данні (1 файл: 1,72
Мбайт). – Київ : КПІ ім. Ігоря Сікорського, 2018. – 73 с.: Іл.
18 Геоінформаційні системи : навчальний посібник /Л.А. Павленко. – Х.:
Вид. ХНЕУ, 2013. – 260 с.
19 Авраменко В. С., Голуб С. В., Салапатов В. І. Дипломне
проектування. Освітній ступінь «Магістр» : Навчально-методичний
посібник / В. С. Авраменко, С. В. Голуб, В. І. Салапатов. – Черкаси :
Черкаський національний університет ім. Б. Хмельницького, 2018. –
213 с.: 76 іл.
20 Rosenberg D., Scott K. Application of object modeling using UML and
case analysis / D. Rosenberg, K. Scott. - Per. from English. – M.: DMK
Press, 2002. – 160 p. Publisher: Addison Wesley First Edition June 14,
2001 ISBN: 0-201-73039-1, 176 pages
21 Авраменко В. С. Авраменко С. А. Проектування інформаційних
систем / В. С. Авраменко, А. С. Авраменко. – Черкаси: Чабаненко Ю.
А, 2017. – 434 с.
22 Нильсен Я. Веб-дизайн. Книга Якоби Нильсена / Якоб Нильсен. – К.:
Символ-Плюс, 2006. – 512 с.
23 Leonenkov A. V. UML 2 ISBN-10 : 5941578784
24 Extreme Programming: Statement of the Process. From the first steps to the
victorious end. K. Auer, R. Miller. Addison-Wesley Professional; 1st
edition 95 (October 1, 2001) Language : English Paperback : 376 pages
ISBN-10 : 0201616408 ISBN-13 : 978-0201616408 28. Schwaber, Ken,
and Mike Beedle. "Agile Software Development with Scrum." (2001).
25 Kent Beck Extreme programming: development through testing. Extreme
Programming Explained Publisher: First Edition September 29, 1999 ISBN:
0201616416, 224 pages
105
ЧДТУ 2216.020 ПЗ
26 Ambler S. Agile Modeling. Effective Practices for Extreme Programming
and the Unified Process. Wiley & Sons, New York, 2002.
27 Облачные технологии и образование: под общ. ред. З.С.
Сейдаметовой. – Симферополь: «ДИАЙПИ», 2012. – 204 с.
28 Хмарні технології [Електронний ресурс]. – Точка доступу: URL:
http://j.parus.ua/ua/358/ – Хмарні технології.
29 Google Cloud Computing [Електронний ресурс]. – Точка доступу: URL:
https://cloud.google.com – How Google Cloud Platform works.
30 Neil A. B. Gray Server Web Programming: Wiley; 1st edition (June 2,
2003) English 576 pages ISBN-10 0470850973 35. Vincent W. Django for
Beginners Learn Web Development With Django 2.0, 2018 – 324p.
31 Eve Astrid Andersson, Philip Greenspun, Andrew Grumet Software
Engineering for Internet Applications
32 Ландэ Д.В. Основы интеграции информационных потоков:
Монография. – К.: Инжиниринг, 2006. – 240 с.
33 Методичні вказівки до оформлення та виконання магістерської
випускної роботи для студентів спеціальності 8.080403 "Програмне
забезпечення автоматизованих систем" освітньо-кваліфікаційного
рівня "магістр" [Текст] /Укл.: А.А. Рідкокаша, О.Б. Півень ; М-во
освіти і науки України, Черкас, держ. технол. ун-т. - Черкаси : ЧДТУ,
2010. - 27 с.
34 О.Б. Данченко, О.С. Шарова Методичні вказівки до виконання
магістерської кваліфікаційної роботи. - К.: Університет економіки та
права "КРОК", 2017. – 30 с.

106

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