но «Select nodes» наведено на рис. 4.8
Малюнок 4.8 Вид вікна «Select nodes»
Вікно «Log» наведено на рис. 4.9, є передплатником на поновлення завдання пошуку повідомлень у журналах СГД, при нотифікації про зміну задачі відбувається аналіз нових результатів (нових знайдених повідомлень) і додавання їх до списку.
Малюнок 4.9 Вид вікна «Log»
Вікно «Custom logging» наведено на рис. 4.10
Малюнок 4.10 Вид вікна «Custom logging»
Вікно «Create new custom log» наведено на рис. 4.11
Малюнок 4.11 Вид вікна «Create new custom log»
Вікно «TCP dumping» наведено на рис. 4.12
Малюнок 4.12 Вид вікна «TCP dumping»
Вікно «Create new TCP dump» наведено на рис. 4.13
Малюнок 4.13 Вид вікна «Create new TCP dump»
Вікно «Download» наведено на рис. 4.14, у списку «Existing data» відображається результат виконання завдання пошуку файлів з заданими параметрами.
Малюнок 4.14 Вид вікна «Download»
Вікно «Download progress» наведено на рис. 4.15, вікно є передплатником на поновлення завдання копіювання файлів.
Малюнок 4.15 Вид вікна «Download progress»
Вікно «Base64 encode/decode» наведено на рис. 4.16
Малюнок 4.16 Вид вікна «Base64 encode/decode»
Вікно «SmartPacket decode» наведено на рис. 4.17
Малюнок 4.17 Вид вікна «SmartPacket decode»
Вікно «ZLIB compress/decompress» наведено на рис. 4.18
Малюнок 4.18 Вид вікна «ZLIB compress/decompress»
5. ТЕСТУВАННЯ ПРОГРАМНОГО КОМПЛЕКСУ
.1 Вибір методик тестування
Для забезпечення перевірки якості реалізації програмного комплексу, а також для перевірки відповідності отриманого результату очікуваному слід вибрати різні методики тестування.
Для перевірки якості реалізації сутностей на рівні класів слід застосувати методику компонентного тестування, що забезпечує автоматизоване виконання тестів, що скорочує швидкість перевірки; а також оперативне визначення дефектів при внесенні змін в програмний продукт. Для створення компонентних тестів в проекті іспользуетс?? бібліотека JUnit 4.8.2 [9].
Для перевірки відповідності отриманого продукту пред'явленим вимогам, обмеженням і очікуванням, а також для системного тестування програмного комплексу слід застосувати ручне тестування з використанням підготовлених наборів даних і описом очікуваних результатів роботи програмного комплексу.
.2 Компонентне тестування
При компонентному тестуванні тестованої одиницею був обраний клас. При компонентному тестуванні набір тестів складається таким чином, щоб різноманітність вихідних даних для компонента забезпечувало виконання певної частки коду класу - ступінь покриття вихідного коду класу тестами.
У реалізованому програмному комплексі критичні з погляду ціни помилки функціональності виконані в серверній і клієнтської бібліотеках, що знижує необхідну ступінь покриття. Однак робота серверного компонента впливає на заповнення дискового простору, таким чином в результаті помилки може відбутися заповнення всього доступного дискового простору. У той же час клієнтський компонент може завдати шкоди (через заповнення дискового простору) тільки користувачеві робочої станції, що менш критично, ніж аналогічний факт на серверному мережевому вузлі, обслуговуючому велика кількість користувачів.
Таким чином мінімальна ступінь покриття розподілена таким чином залежно від серйозності наслідків виникнення помилки (вказано середнє значення по класах зазначеної структурної одиниці програмного комплексу):
Серверний компонент - 90%
Шар «Модель» клієнтського компонента - 90%
Шар «Контролер» клієнтського компонента - 75%
Шар «Вид» клієнтського компонента (класи не реалізують віконні елекменти) - 50%
Загальний модуль клієнтського і серверного компонентів - 90%
Рішення про ступінь покриття по кожному класу приймається розробником індивідуально виходячи з критичності виникнення помилки у функціональності.
При реалізації серверного компонента і загального модуля протоколу використовувалася методика «Розробка через тестування» (Test-driven development) [10], коли спочатку для класу пишеться набір тестів, що описують всі варіанти вихідних даних, які можуть виникати в процесі роботи класу, а також кінцеві результати; потім пишеться мінімальна реалізація класу, що забезпечує стовідсоткове проходження тесту. У результаті такого підходу до реалізації у вихідному коді практично немає невикористовуваних фрагментів коду, які тільки займають системні ресурси і жодним чином не впливають на результат роботи програми.
Завдяки хорошій декомпозиції задачі, інкапсуляції і використанню інтерфейсів покриття р...
