rest_documentconversion_latest_conversion_thumbnail_32309484_1 ЗМІСТ
1      ВИЗНАЧЕННЯ, СКОРОЧЕННЯ ТА АБРЕВІАТУРИ.. 4 2      ОБ’ЄКТ І МЕТА ВИПРОБУВАНЬ. 8 2.1        Найменування Сервісу. 8 2.2        Призначення Сервісу. 8 2.3        Мета випробувань. 8 3      ЗАГАЛЬНІ ПОЛОЖЕННЯ. 9 3.1        Перелік документів, якими необхідно керуватися під час проведення випробувань. 9 3.2        Організації, що беруть участь у випробуваннях. 9 3.3        Обсяг випробувань. 9 3.4        Умови і порядок проведення випробувань. 10 3.4.1    Умови проведення випробувань. 10 3.4.2    Умови початку та завершення окремих етапів випробувань. 10 3.4.3    Вимоги до технічного обслуговування Сервісу. 10 3.4.4    Заходи безпеки при проведенні випробувань. 11 3.4.5    Вимоги до персоналу, що проводить випробування. 11 3.5        Забезпечення випробувань і звітність. 11 3.5.1    Матеріально-технічне забезпечення випробувань. 11 3.5.2    Метрологічне забезпечення випробувань. 11 3.5.3    Звітність. 11 4      ВИМОГИ ДО СЕРВІСУ.. 12 4.1        Вимоги до функцій. 12 4.1.1    Вимоги до функцій інтерфейсу адміністратора. 12 4.1.1.1       Функції управління користувачами. 12 4.1.1.2       Функції управління організаціями(Структурні підрозділи КМДА) 12 4.1.2    Вимоги до функцій користувача. 13 4.1.2.1       Функції формування звітів. 13 5      МЕТОДИКА ВИПРОБУВАНЬ. 15 5.1        Тестування функціональності ролі користувач. 15 5.1.1    Тестові дані з посиланнями та доступами згідно ролевої моделі…………………………………………..……………………………….15 5.1.2    Авторизація до сервісу. 15 5.1.3    Створення зведеної таблиці у розрізах наявних даних. 16 5.2        Тестування функціональності у ролі адміністратора. 36 5.2.1    Авторизація до сервісу. 36 5.2.2    Надання прав доступу для користувачів до звітів. 37 5.3        Тестування АРІ 38 5.4        Тестування навантаження на систему. 41 6      Список Рисунків. 42 7      Лист Реєстрації змін. 43  

Повне найменування Сервісу: Програмний сервіс для отримання даних з  , а також даних про утримувачів муніципальної картки «Картка киянина».

 Програмний сервіс АСОП створюється як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботиі у розрізі даних про утримувачів муніципальної картки «Картка киянина». Програмний сервіс АСОП дозволяє:

• Формувати аналітичні та статистичні звіти щодо виду транспортних продуктів.
• Формувати аналітичні та статистичні звіти щодо перевізників.
• Формувати аналітичні та статистичні звіти щодо у тому числі в розрізі пільгових категорій
• Відображати достовірну аналітичну та оперативну інформацію,

Метою випробувань є встановлення відповідності режимів функціонування Сервісу т завданню та експлуатаційній документації. При проведенні випробувань Сервісу забезпечується перевірка:

• відповідності Сервісу Технічному завданню;
• комплектності Сервісу;
• комплектності та якості технічної документації;
• комплектності, достатності складу та якості програмних засобів та програмної документації;
• кількості персоналу та кваліфікації персоналу, що обслуговує Сервіс;
• придатності Сервісу до контролю за коректністю опрацювання даних;
• виконання вимог охорони праці, ергономіки, промислових санітарних норм та правил;

- ГОСТ 34.603-92. Інформаційна технологія. Види випробувань автоматизованих систем; - РД 50-34.698-90. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів.

Замовник:   Комунальне підприємство «Головний інформаційно-обчислювальний центр» Місцезнаходження: вул. Космічна, буд. 12а, м. Київ, 02192, Україна. п/р 35442136091290 ГУ ДКСУ в м. Києві, Код банку 820019, ЄДРПОУ 04013755, Свідоцтво пл. ПДВ №100093243, ІПН 040137526538. Розробник:   Товариство з обмеженою відповідальністю «СІВІС». Місцезнаходження: вул. Амосова, буд. 4, офіс 8, м. Київ, 03141, Україна. ЄДРПОУ 39194632, п/р 26003052709939 в «Філія Розрах. центр» АТ КБ «ПРИВАТБАНК», Код банку 320649, ІПН 391946326582.

Перелік етапів випробувань та перевірок:

• Етап № 1. Перевірка комплектності та якості технічної документації.
• Етап № 2. Перевірка комплектності, достатності складу та якості програмних засобів та програмної документації.

Послідовність проведення випробувань:

1. Перевірка комплектності та якості технічної документації забезпечується візуальним переглядом наявності технічної документації ПС АСОП.
2. Перевірка програмних засобів та програмної документації:

• перевірка комплектності та якості програмної документації забезпечується візуальним переглядом;
• перевірка працездатності функцій ПС АСОП, та ступеня виконання  Сервісом вимог Технічного завдання за тестовими наборами даних.

Умовами проведення випробувань є наявність працездатних програмно-апаратних засобів та відповідного операційного середовища.

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

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

Проведення випробувань повинно передбачати заходи та процедури з експлуатації, які узгоджуються з документом «Вимоги щодо безпеки та захисту здоров’я працівників під час роботи з екранними пристроями», затвердженим наказом Міністерством соціальної політики України від 14.02.2018 № 207. Загальні вимоги електричної і механічної безпеки мають бути забезпечені відповідно до ГОСТ 12.2.007.0-75 і ГОСТ 25861-83.

Користувачі Сервісу повинні володіти навичками роботи використання яких необхідно для виконання їх посадових обов’язків, що пов’язані з коригуванням електронних форм, оформленням документів, веденням обліку тощо.

Випробування забезпечуються тестовими наборами даних (див. Додаток 1

Випробування Сервісу проводяться шляхом перевірки на контрольних прикладах, що входять до складу програмних засобів, а також на прикладах та реальних об’єктах, запропонованих комісією. Всі перевірки виконуються в режимі взаємодії користувачів Сервісу (а саме – працездатність користувача та адміністратора) з програмними засобами Сервісу та базами даних у відповідності до документації на Сервіс, зокрема з Програмою та методикою попередніх випробувань. Попередні випробування будуть проводитися у домені http://dashboard-dkv.kyivcity.gov.ua/

У процесі випробувань Сервісу оформлюється Протокол попередніх випробувань, який погоджується та затверджуються Сторонами, що беруть участь у випробуваннях.

«Адміністрування» – модуль за допомогою якого користувач з роллю адміністратор матиме змогу надавати та керувати доступом користувачів до функціональних можливостей Сервісу .

Таблиця 1. Функції керування обліковими записами користувачів

Таблиця 2 Функції управління організаціями

Користувач у своєму обліковому записі повинен мати доступ до окремих звітів з обмеженням по набору доступних даних.

У відповідності до Технічного завдання і Звіту аналізу бізнес процесів, методика випробувань інтерфейсу користувача в ПС АСОП буде складатись із 5 етапів:

1. Авторизація до сервісу
2. Створення зведеної таблиці у розрізах:
   • Агенти;
   • Перевізники;
   • Пасажири.
3. Використання аналітичних розрахунків через інтерфейс користувача.
4. Формування Графіків/Гістограм/Діаграм.
5. Вивантаження отриманих звітів на пристрій користувача.

Для здійснення тестування системи, необхідно використовувати наступні тестові дані (див. Таблицю 1) Таблиця 1

Тестування відбувається за попередньо завантаженими в Систему тестовими даними. Для тестування необхідно увійти в Систему як користувач. Для цього переходимо на проходимо авторизацію і натискаємо на кнопку в особистому кабінеті і переходимо до компоненту ПС АСОП,
Рисунок. 1 Форма авторизації Платформи Kyiv Smart City

* Здійснюємо вибір через навігаційне меню  

Рисунок 2. Навігаційне меню ПС АСОП.

• Інформація відображається у зведеній таблиці зі базовими параметрами у відповідності д. (див. Рисунок 4)

Рисунок. 3. Відображення початкової звітності в ПС АСОП.

• Створення зведеної таблиці у розрізі Агенти. Для формуванні звітності по Агентам натискаємо на кнопку «Поля» .Здійснюється відображення Таблиці Вимірів (Рисунок 5)

Рисунок 4. Таблиці Вимірів. У лівому списку «Всі поля» перевірити наявність Атрибутів інформації по Агентам:

• Місце оплати.
• Назва банку.
• Назва каси.
• Тип картки (картка метрополітену, Kyiv Smart City).
• Іd картки ( картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток, учнівський квиток).
• Дата.
• Метод оплати.
• Назва продукту (купівля катки, QR, поповнення і т.д).
• Сума.

          Таблиця формується на підставі перемішення відповідних Атрибутів до списку:

1. «Фільтри» - відображення окремої кнопки через яку можно здійcнувати фільтрацію даних
2. Рядки – горизонтальне відображення атрибутів даних у зведеній таблиці.
3. Колонки – вертикальне відображення атрибутів даних у зведеній таблиці.
4. Міри – вертикальне відображення даних у зведеній таблиці має логічний зв’язок зі рядками формує відображення інформації у клітинці зведеної таблиці (числове значення).

По результату повинна бути сформована таблиця зі зазначеними атр (див. Рисунок 6). Рисунок 5. Заповнені таблиці вимірів у розрізі Агентів.

• Натискаємо на клавішу «Застосувати» після чого має відбутись формування звіту:

|||

Рисунок 6. Відображення отриманого звіту по Агентам
Перевірка функціонування роботи фільтрації даних у відповідності до потреби користувача, у верхній частині основного вікна натискаємо на кнопку «Назва продукту» і відображається вікно фільтрації з можливістю вибрати необхідний атрибут. (див Рисунок 7).
Рисунок 8.Відображення фільтрації у звіті Агентів

• Сам. Для формуванні звітності по Перевізники натискаємо на кнопку «Поля» .Здійснюється відображення Таблиці Вимірів (див Рисунок 9)

Рисунок 9. Таблиці Вимірів

• Вартість валідованого продукту.
• Дата валідації.
• Депо.
• Іd картки ( картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток, учнівський квиток).
• Лінія станцій.
• Назва станції.
• Номер маршруту.
• Тип картки (картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток QR, учнівський квиток)
• Тип транспорту.
• Час/дата валідації.

аналогічно пункту 3 . Hjp По результату має сформуватись таблиця зі зазначеними Атрибутами:

Рисунок 10. Приклад налаштування звіту у розрізі по перевізникам . Натискаємо на клавішу «Застосувати»  після чого має відбутись формування звіту: Рисунок 11. Зведена таблиця у розрізі по перевізникам  . :

• Натискаємо на зображення шестерні;
• В діалоговому вікні у відповідних чекбоксах вибираємо необхідні атрибути по яким буде виконуватись фільтрація даних у відповідності до запиту.
• Натискаємо на кнопку «ЗАСТОСУВАТИ» і фільтрація застосовується до даних.

Рисунок 12. Відображення фільтрації у звіті по Перевізникам.

• Створення зведеної таблиці у розрізі Пасажирів

Рисунок 13.Таблиці Вимірів. У лівому списку «Всі поля» перевірити наявність Атрибутів інформації по Пасажирам:

• Ідентифікатор транспортного продукту.
• Категорія пільговика (перша по якій дійсна пільга на проїзд).
• Район проживання пільговика.
• Стать.
• Іd картки ( картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток, учнівський квиток).
• Назва банку що сплачує за пільговика.
• Статус картки.

Таблиця формується на підставі перемішені відповідних Атрибутів до списку «Фільтри», «Колонки», «Рядки», «Міри» (застосовується внутрішня логіка роботи с даними). По результату має сформуватись таблиця зі зазначеними  параметрами:
Рисунок 14. Заповнені таблиці вимірів по Пасажирам. Натискаємо на клавішу «Застосувати» , після чого має відбутись формування звіту: Рисунок 15. Відображення отриманого звіту по Пасажирам.
Перевірка функціонування роботи фільтрації даних у відповідності до потреби користувача: Рисунок 16. Відображення фільтрації у звіті по Пасажирам.

• Використання аналітичних розрахунків через інтерфейс користувача.

Аналітичні розрахунки – можливість опрацьовувати дані додавати у зведеній таблиці. Розрахунки необхідні для проведення аналізу даних, визначення тенденцій перевезення, накладання на дані коефіцієнти для подальшого представлення аналітичного звіту. Налаштування здійснюється на етапі заповнення таблиці вимірів. Для початку роботи,  необхідно перейти до таблиці Вимірів вікна натискаємо на кнопку «Поля»  після чого натискаємо на кнопку  Відображається вікно Обрахована міра через яку можливо прописати логіку: Рисунок 17. Вікно Обрахована міра Випробування проводитимуться по наступних задачах:

• Знайти максимальне, мінімальне кількість поїздок на маршруті №22, в т.ч. за обраний період, визначити кількість платних (в т.ч по картах і по разовими квитками) кількість пільгових проїздів.

Реалізація виконується через фільтри:

Рисунок 18 Заповненя таблиці вимірів по Пасажирам Рисунок 19 Отримані результати

• Відстежити активність карти - визначити кількість використаних поїздок за обраний період і в розрізі перевізників

Приклад реалізації: Рисунок 20. Заповнення таблиці вимірів по Пасажирам. Рисунок 21. Розкриваємо фільтр Транспорт Автобус для перевірки кількості проїздів. Рисунок 22. Опрацьовуємо отримані результати

• Порахувати кількість продажів, поїздок по агентам, за допомогою чого були проведені оплати цих поїздок.

Приклад реалізації:

Рисунок 23

Опрацювання таблиці вимірів Агентів відповідно до запиту Рисунок 24 Відображення отриманого результату Рисунок 25 Опрацювання таблиці вимірів Пасажирів відповідно до запиту Рисунок 26 Відображення отриманого результату
:

1. Перейдемо на вкладку «Звіти по перевізникам»
2. Натискаємо на кнопку «Поля»
3. В таблиці «Виміри» натискаємо на кнопку «Додати міру»

1. Вказуємо назву параметру обрахунку.

Рисунок 27. Заповнене вікно «Обрахована міра»

1. Заповнюємо таблиці вимірів у відповідності до задачі.

Надано О. Писаною чек лист по перевірці, прохання додати та переробити тест-кейси згідно чек-листа:  Примерные запросы, которые должны выполняться самостоятельно пользователем с помощью конструктора АСОП

• Найти максимальное, минимальное количество поездок на маршруте №22, в т.ч. по платным поездкам, по QR, по Карте Киянина за период.
• Количество прездов в этот период, из них платные, бесплатные
• Посмотреть по карточкам, какие тарифы были наиболее популярными в заданный период – по 8, 7.70, 6.50, в каком виде транспорта.
• Почасовые нагрузки на транспорт, в разрезе маршрутов, видов транспорта
• Отследить активность карты – сколько используется поездок, оплаченных картой.
• Рассчитать количество приобретенных карт, которые не используются в течение полугода.
• Посчитать количество продаж, поездок по агентам, с помощью чего были произведены оплаты этих поездок.
• Сравнить количество поездок в метрополитене и в другом транспорте.

Период позразумевается такой: день, 3 дня, месяц и другие, выбранные из календаря.

Треба ж спочатку вибрати конкретний звіт, в нього додати вимір Міра, чи як? не зрозуміла послідовність дій, необхыдно описати [Гі45] Рисунок 28. Заповнені таблиці вимірів

1. Здійснюємо фільтрацію даних у відповідності до запиту і отримуємо звіт із аналітичними розрахунками.

  Рисунок 29. Отриманий звіт у розрізі балансу по станції метрополітену.

• Формування Графіків/Гістограм/Діаграм

Для представлення отриманого звіту у вигляді графіків, необхідно натикнути на кнопку  «Графіки» . Як результат має бути наявність наступних пунктів Гістограм, Діаграм. Після вказання необхідних пунктів має відобразитись побудований графік Рисунок 30. Графік по валідації продукту у розрізі маршруту

• Вивантаження отриманих звітів на пристрій користувача. Сервіс дозволяє вивантажити звіти у формати HTML, CVS, Excel, PDF, Зображення.

Порядок вивантаження звіту:

• Сформували необхідний тестовий зіт
• на сторінці формування зведеної таблиці.
• Відкривається перелік для експорту документів у відповідних форматів (див. Рисунок 22).

Рисунок 31. Меню вибору формату вивантаження звіту

• Натискаємо на кнопку Excel
• Документ зберігається на комп’ютері користувача у фоматі XLS.
• Відкриємо отриманий документ. (див Рисунок 23)

Рисунок 32. Приклад вивантаженого звіту XLS Порядок вивантаження графіку:

• Вивантаження звітів відбувається шляхом  на сторінці відображення графіку.
• Відкривається перелік для експорту документів у відповідних форматів (див. Рисунок 22).

Рисунок 334. Меню вибору формату вивантаження графіку.

• Натискаємо на кнопку PDF
• Документ зберігається на комп’ютері користувача у фоматі PDF.(див. Рисунок 25)

Рисунок 34. Приклад вивантаженої діаграми у PDF

Для тестування необхідно увійти в систему як адміністратор за посиланням https://dashboard.kyivcity.gov.ua/admin/users. Для цього у вікні авторизації необхідно ввести логін та пароль адміністратора.

Рисунок 35. Форма авторизації ПС АСОП.

Для надання прав доступу необхідно увійти до розділу «Налаштування»  і відкриваємо вкладку  «Організаційна структура» і проводимо відповідні налаштування. Рисунок 36 Вкладка організаційна структура

Здійснення тестування API буде здійснено через SoapUI. Для здійснення тесту відкриємо програму і створюємо новий SOAP проєкт:
Рисунок 377 Створення SOAP проєкту Прописуємо наступний лінк на Web Services вDescription Language — http://dashboard-dkv.kyivcity.gov.ua/soap/WrapperSoapServer.php?wsdl Відкривається проєкт: Рисунок 387 Проєкт dashboard-dkv.kyivcity.gov.ua

1. В лівому навігаційному меню доступні можливі функції АPI. Проведемо тестування передачі даних користувача до платформи KyivSmartCity

|||

*
Вибираємо функцію doRegisrt і прописуємо тестові дані Рисунок 398 Вказання параметрів запиту

1. Результат виконання запиту відображається у правому блоці

|||

Рисунок 409 Виконання запиту

Тестування буде проводитись Apache Bench:

1. Запускаємо програму і в консолі вказуємо параметри тестування «ab -c 50 -n 10000 -f TLS1.2 -H “Accept-Encoding: gzip,deflate” http://dashboard-dkv.kyivcity.gov.ua /» натискаємо клавішу «Enter» і отримуємо інформацію про проведеному тестуванні

Рисунок 30. Відображення результату тестування

Рисунок. 1 Форма авторизації Платформи Kyiv Smart City. 16 Рисунок 2 Форма авторизації ПС АСОП. 17 Рисунок 3 Навігаційне меню ПС АСОП. 17 Рисунок. 4 Відображення початкової звітності в ПС АСОП. 18 Рисунок 5. Таблиці Вимірів. 18 Рисунок 6. Заповнені таблиці вимірів у розрізі Агентів. 19 Рисунок 7. Відображення отриманого звіту по Агентам. 20 Рисунок 8.Відображення фільтрації у звіті Агентів. 20 Рисунок 9. Таблиці Вимірів. 21 Рисунок 10. Заповнені таблиці вимірів по Перевізників. 22 Рисунок 11. Відображення отриманого звіту по Перевізниках. 23 Рисунок 12. Відображення фільтрації у звіті по Перевізникам. 24 Рисунок 13.Таблиці Вимірів. 24 Рисунок 14. Заповнені таблиці вимірів по Пасажирам. 25 Рисунок 15. Відображення отриманого звіту по Пасажирам. 26 Рисунок 16. Відображення фільтрації у звіті по Пасажирам. 26 Рисунок 17. Вікно Обрахована міра. 27 Рисунок 18. Заповнене вікно «Обрахована міра». 28 Рисунок 19. Заповнені таблиці вимірів. 29 Рисунок 20. Отриманий звіт у розрізі балансу по станції метрополітену. 29 Рисунок 21. Графік по валідації продукту у розрізі маршруту. 30 Рисунок 22. Меню вибору формату вивантаження звіту. 30 Рисунок 23. Приклад вивантаженого звіту XLS. 31 Рисунок 24. Приклад вивантаженої діаграми у PDF. 31 Рисунок 25. Форма авторизації ПС АСОП. 32 Рисунок 26 Вкладка організаційна структура. 33