Що таке тестування SOA? Підручник із прикладом

Що таке тестування SOA?

SOA (сервісно-орієнтований Architecture) Тестування — це тестування стилю архітектури SOA, у якому компоненти програми розроблено для зв’язку через протоколи зв’язку, як правило, через мережу.

Що таке SOA?

SOA — це метод інтеграції бізнес-додатків і процесів для задоволення потреб бізнесу.

У розробці програмного забезпечення SOA забезпечує спритність і гнучкість бізнес-процесів. Зміни в процесі або програмі можуть бути спрямовані на окремий компонент, не впливаючи на всю систему.

Розробники програмного забезпечення в SOA або розробляють, або купують шматки програм під назвою ПОСЛУГИ.

Що таке служба?

• Послуги можуть бути функціональною одиницею програми або бізнес-процесу, який можна повторно використовувати або повторювати будь-якою іншою програмою чи процесом. (Наприклад, на зображенні вище Payment Gateway — це служба, яку можна повторно використовувати будь-яким сайтом електронної комерції. Щоразу, коли потрібно здійснити платіж, сайт електронної комерції викликає/запитує службу Payment Gateway. Після здійснення платежу на шлюзі відповідь надсилається на веб-сайт електронної комерції)
• Сервіси легко зібрати та легко переналаштувати компоненти.
• Послуги можна порівняти з будівельними блоками. Вони можуть створювати будь-які необхідні програми. Додавати та видаляти їх із програми чи бізнес-процесу легко.
• Послуги визначаються більше бізнес-функцією, яку вони виконують, а не фрагментами коду.

Web-сервіси

Веб-сервіси — це незалежні компоненти програми, які доступні через Інтернет.

Їх можна публікувати, знаходити та використовувати в Інтернеті. Вони можуть спілкуватися через Інтернет.

1. Постачальник послуг публікує послугу в Інтернеті.
2. Клієнт шукає певну веб-службу в Реєстрі веб-служб
3. Повертається URL-адреса та WSDL для необхідної веб-служби. Використовуючи WSDL і URL, зв’язок між постачальником послуг і запитувачем відбувається через повідомлення SOAP.
4. Коли споживач викликає веб-службу, з постачальником встановлюється HTTP-з’єднання.
   Повідомлення SOAP створюється для вказівки провайдеру щодо виклику необхідної логіки веб-служби.
5. Відповідь, отримана від постачальника, є повідомленням SOAP, яке буде вбудовано у відповідь HTTP. Ця відповідь HTTP є форматом даних, зрозумілим програмі споживача.

Приклад

Домашня сторінка веб-сайту та пошукової системи відображає прогноз погоди на день. Замість повного кодування розділу звіту про погоду можна придбати службу прогнозу погоди у постачальника та інтегрувати його на сторінки.

Тестування SOA

SOA складається з різних технологій. Програми, створені з використанням SOA, мають різні служби, які слабо пов’язані між собою.

Тестування SOA має зосереджуватися на 3 рівнях системи

Рівень послуг

Цей рівень складається з служб, послуг, які надає система, похідна від бізнес-функцій.

Наприклад -

Розглянемо оздоровчий веб-сайт, який складається з

1. Вага трекер
2. Трекер рівня цукру в крові
3. Відстежувач артеріального тиску

Трекери відображають відповідні дані та дату їх введення. Сервісний рівень складається з сервісів, які отримують відповідні дані з бази даних –

• Сервіс відстеження ваги
• Служба відстеження рівня цукру в крові
• Сервіс вимірювання артеріального тиску
• Служба входу в систему

Рівень процесу

Рівень процесу складається з процесів, набору послуг, які є частиною єдиної функціональності.

Процеси можуть бути частиною інтерфейсу користувача (наприклад, пошукова система), частиною інструменту ETL (для отримання даних із бази даних).

Основна увага на цьому рівні буде зосереджена на інтерфейсах користувача та процесах.

Користувальницький інтерфейс засобу відстеження ваги та його інтеграція з базою даних — це основна увага.

Нижче наведені функції будуть розглянуті

1. Додавання нових даних
2. Редагування існуючих даних
3. Створення нового трекера
4. Видалення даних

Споживчий шар

Цей рівень в основному складається з інтерфейсів користувача.

На основі рівня тестування SOA-додатку розподіляється на три рівні.

1. Рівень обслуговування
2. Рівень інтерфейсу
3. Кінцевий рівень

• Підхід зверху вниз використовується для проектування тесту.
• Підхід «знизу вгору» використовується для виконання тесту.

Стратегія тестування SOA

Підхід до планування тестування,

• Тестери SOA повинні розуміти повну архітектуру програми.
• Додаток потрібно розбити на незалежні сервіси (сервіс, який має власну структуру запиту та відповіді та не залежить від жодного іншого сервісу для формування відповіді).
• Структуру програми необхідно реорганізувати на три компоненти – дані, служби та зовнішні програми.
• Треба ретельно проаналізувати всі складові та накреслити бізнес-сценарії.
• Бізнес-сценарії слід класифікувати як звичайні сценарії та сценарії для конкретних програм.
• A Матриця простежуваності повинні бути підготовлені, і всі тестові випадки повинні бути відстежені до бізнес-сценаріїв.

Підхід до виконання тесту

• Кожен компонент служби повинен бути протестований.
• Інтеграційне тестування компонентів служби, щоб перевірити потік даних через служби та цілісність даних.
• Тестування системи повної моделі, щоб перевірити потік даних між зовнішнім додатком і базою даних.
• Тестування продуктивності слід зробити для точного налаштування та оптимальної продуктивності.

Методи тестування SOA

1) Тестування даних на основі бізнес-сценарію,

• Необхідно проаналізувати різні бізнес-аспекти, пов’язані з системою.
• Сценарії слід розробляти на основі інтеграції
• Різний Веб-сервіси програми
• Веб-сервіси та програми.
• Налаштування даних слід виконувати на основі наведених вище сценаріїв.
• Налаштування даних має здійснюватися так, щоб також охоплювати наскрізні сценарії.

2) Заглушки

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

3) Регресійне тестування

• Регресійне тестування для програми слід виконувати, коли є кілька випусків, щоб забезпечити стабільність і доступність систем.
• Буде створено комплексний набір регресійних тестів, який охоплюватиме служби, які є важливою частиною програми.
• Цей набір тестів можна повторно використовувати в кількох випусках проекту.

4) Тестування рівня обслуговування

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

Кожну послугу потрібно спочатку протестувати незалежно.

5) Функціональне тестування

Функціональне тестування слід проводити на кожній службі

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

6) Тестування безпеки

Тестування безпеки веб-сервісу є важливим аспектом під час тестування рівня обслуговування програми SOA; це забезпечує безпеку програми.

Під час тестування необхідно враховувати такі фактори:

• Веб-служба повинна дотримуватися галузевого стандарту, визначеного тестуванням WS-Security.
• Заходи безпеки повинні працювати бездоганно.
• Шифрування даних і Digiтальні підписи на документах
• Аутентифікація та авторизація
• Впровадження SQL, зловмисне програмне забезпечення, XSS, CSRF та інші вразливості повинні бути перевірені на XML.
• Атаки відмови в обслуговуванні

7) Тестування продуктивності

Необхідно провести тестування продуктивності служби, оскільки служби можна використовувати багаторазово, і кілька програм можуть використовувати ту саму службу.

Під час тестування враховуються такі фактори:

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

8) Тестування рівня інтеграції

• Тестування рівня обслуговування забезпечує належну роботу лише окремих служб, воно не гарантує роботу пов’язаних компонентів.
• Інтеграційне тестування зосереджується переважно на інтерфейсах.
• Цей етап охоплює всі можливі бізнес-сценарії.
• Нефункціональне тестування програми слід виконати ще раз на цьому етапі. Безпека, відповідність і тестування продуктивності забезпечують доступність і стабільність системи в усіх аспектах.
• Комунікаційні та мережеві протоколи слід протестувати, щоб перевірити узгодженість передачі даних між службами.

9) Наскрізне тестування

Цей етап гарантує, що додаток відповідає бізнес-вимогам як функціонально, так і нефункціонально.

Наведені нижче елементи перевіряються під час наскрізного тестування

• Усі служби працюють належним чином після інтеграції
• Обробка винятків
• Інтерфейс користувача програми
• Належний потік даних через усі компоненти
• Бізнес-процес

Проблеми в тестуванні SOA

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

Випадки використання тестування SOA

Розглянемо веб-сайт електронної комерції, який містить наведені нижче функції та підфункції:

Обробка замовлень

ФАЗА 1

На першому етапі тестування SOA, тобто на етапі стратегії тестування, програма розбивається на Сервіси та бізнес-функції.

Давайте розглянемо нижче Сервіси в програмі.

• Створити замовлення
• Перевірте статус клієнта
• Змінити статус замовлення
• Перевірте статус замовлення
• Перевірте інвентар

Бізнес-функції такі ж, як і функції веб-сайту.

Примітка: Документ стратегії тестування міститиме перелік послуг і функцій, які необхідно протестувати.

ФАЗА 2

Фаза планування тесту. Для кожного рівня написані тести.

1. Наскрізний рівень. Тестові випадки написані для кожного бізнес-випадку використання та потоку. Нижче наведено приклад тестів
   • Створіть замовлення з активним користувачем.
   • Створіть замовлення з неактивним користувачем.
   • Створіть замовлення з наявним продуктом із кількістю замовлення < доступної кількості.
   • Створіть замовлення з наявним продуктом, указавши кількість замовлення > доступна кількість.
   • Створіть замовлення з кількома товарами
   • Повністю скасувати замовлення.
   • Скасувати замовлення частково.
2. Рівень інтеграції. Тестові приклади написані для інтеграції бази даних та інтерфейсу користувача. Нижче наведено приклади тестів.
   • Створіть нове замовлення з одним товаром. Переконайтеся, що замовлення створено в базі даних.
   • Створіть нове замовлення з одним товаром. Переконайтеся, що розрахована ціна для замовлення правильна.
   • Створіть нове замовлення з одним товаром. Переконайтеся, що кількість доступного товару менше на суму замовлення.
   • Переконайтеся, що статус замовлення, який відображається в інтерфейсі користувача, такий самий, як і в базі даних.
   • Скасуйте замовлення та переконайтеся, що статус замовлення в базі даних змінено.
   • Під час першого платежу переконайтеся, що відомості про платіж, введені в інтерфейсі користувача, збережено в базі даних.
   • Для повернення платежів переконайтеся, що відомості про платіж у базі даних відображаються в інтерфейсі користувача.
3. Рівень обслуговування. Кожен сервіс тестується на всі умови даних.

Нижче наведено кілька прикладів.

Ні.	Подробиці замовлення	Умова замовлення
1	Створити замовлення. Кількість предметів = 1	Кількість за замовленням < Кількість за базою даних
2	Створити замовлення. Кількість елементів > 1	Кількість у замовленні < кількість у базі даних.
3	Створіть замовлення № елементів = 1	Кількість у замовленні > Кількість у базі даних
4	Перевірте статус замовлення	Статус у базі даних = Активний
5	Перевірте статус замовлення	Статус у базі даних = Відправлено
6	Перевірте статус замовлення	Статус у базі даних = Скасовано
7	Перевірте статус замовлення	ID замовлення = недійсний
8	Перевірити наявність товару	Кількість продукту >0
9	Перевірити наявність товару	Кількість продукту =0
10	Перевірити наявність товару	ID продукту = недійсний

ЕТАП 3 – Виконання тесту

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

1) Рівень обслуговування

Давайте розглянемо це Соапуї інструмент розглядається для тестування програми.

Команда WSDL і URL переглядаються в тестовому вікні SOAP.

Запит на кожну послугу буде відображено у вікні запиту.

Змінюючи дані відповідно до тестів рівня обслуговування, запити створюються для кожного тесту.

Тестовий випадок	Запит	Очікувана відповідь
Створити замовлення. Кількість позицій = 1Кількість на замовлення < Кількість на базі	x2 2	o3251 Успішний
Створити номер замовлення предметів > 1Кількість у замовленні <Кількість у дб	y1 1 y2 3	o3251 Успішний
Створити номер замовлення елементів = 1Кількість у замовленні > Кількість у дб	x23 200	нуль Невдалий
Перевірити статус замовлення в базі даних = Активний	o9876	Активний Успішний
Перевірте статус замовлення в базі даних = Відправлено	o9656	Відправлено Успішний
Перевірте статус замовлення. Ідентифікатор замовлення = недійсний	y5686	нуль Невдалий
Перевірити наявність товаруКількість товару >0	d34	34 так Успішний
Перевірити наявність товаруКількість товару =0	y34	0 немає Успішний
Перевірте наявність продукту. Ідентифікатор товару = недійсний	sder	Невдалий

2) Рівень інтеграції

Тестові випадки рівня інтеграції виконуються в інтерфейсі користувача та базі даних.

• Створіть замовлення з одним товаром –
• Користувач відкриває веб-сайт.
• Йде робити замовлення.
• Вибирає дійсний продукт і кількість і зберігає замовлення.
• Має відобразитися повідомлення про успішне розміщення замовлення.
• Користувач відкриває базу даних і перевіряє, чи збігаються дані замовлення з тими, що введені на веб-сайті.

3) Наскрізний рівень

Бізнес-потоки та варіанти використання виконуються в інтерфейсі користувача.

• Створення замовлення з кількома елементами –
• Користувач відкриває веб-сайт.
• Йде робити замовлення.
• Запитує про дійсний продукт і кількість, додає їх у кошик.
• Інші дійсні продукти додаються з дійсною кількістю, і замовлення зберігається. Оплата здійснюється за допомогою нового способу оплати та розміщення замовлення.
• Має відобразитися повідомлення «Замовлення успішно розміщено».
• Тестер повинен підтвердити, що весь потік виконується без викривлення даних.

Висновок

Накидавши правильну стратегію тестування, ресурси, інструменти та відповідність для надання якісних послуг, тестування SOA може забезпечити повністю й ідеально перевірену програму.