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

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

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

У цьому підручнику ви дізнаєтесь-

• Що таке SOA?
• Що таке сервіс?
• Тестування SOA
• Стратегія тестування SOA
• Методи тестування SOA
• Проблеми при тестуванні SOA
• Засоби тестування SOA
• Випадки використання тестування SOA

Що таке SOA?

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

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

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

Що таке сервіс?

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

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

Веб-сервіси

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

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

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.
• Додаток потрібно розбити на незалежні служби (Служба, яка має власну структуру запитів та відповідей і не залежить від будь-якої іншої служби для формування відповіді).
• Структуру додатків потрібно реорганізувати у три компоненти - дані, послуги та інтерфейсні програми.
• Усі компоненти повинні бути ретельно проаналізовані, а бізнес-сценарії слід позначити.
• Бізнес-сценарії слід класифікувати як загальні сценарії та конкретні сценарії застосування.
• Слід підготувати Матрицю простежуваності, а всі тестові випадки слід відстежувати за бізнес-сценаріями.

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

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

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

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

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

2) Заглушки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Засоби тестування SOA

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

1) Інтерфейс SOAP

"SOAP UI" - це інструмент функціонального тестування з відкритим кодом для тестування служб та API.

• Настільна програма
• Підтримує кілька протоколів - SOAP, REST, HTTP, JMS, AMF, JDBC
• Веб-сервіси можна розробляти, перевіряти та використовувати їх.
• Можна також використовувати для тестування на навантаження, автоматичного тестування та тестування безпеки
• Заглушки можуть створюватися MockServices
• Запити та тести веб-сервісу можна автоматично генерувати за допомогою клієнта веб-служби.
• Вбудовані інструменти звітування
• Розроблено SmartBear

2) iTKO LISA

"LISA" - це набір продуктів, який забезпечує функціональне рішення для тестування розподілених систем, таких як SOA.

• Можна також використовувати для регресії, інтеграції, навантаження та тестування продуктивності.
• Розроблено iTKO (CA Technologies)
• Може використовуватися для проектування та виконання тестів.

3) Тест на обслуговування HP

"Сервісний тест" - це функціональний інструмент тестування, який підтримує тестування як інтерфейсу користувача, так і спільних служб

• Як перевірка функціональності, так і продуктивності послуг може проводитися за допомогою одного сценарію.
• Інтегровано з HP QC.
• Великим обсягом послуг та даних можна керувати.
• Підтримує тестування на сумісність, імітуючи клієнтські середовища JEE, AXIS та DotNet.
• Розроблено компанією HP.

4) Тест Parasoft SOA

SOA Test - це набір інструментів для тестування та аналізу, розроблений для тестування API та додатків API.

• Підтримує веб-служби, REST, JSON, MQ, JMS, TIBCO, HTTP, XML.
• Тестування функціональних можливостей, модулів, інтеграції, регресії, безпеки, сумісності, відповідності та продуктивності.
• Заглушки можна створювати за допомогою Parasoft Virtualize, які розумніші, ніж SOAP UI.
• Розроблено компанією ParaSoft

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

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

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

ЕТАП 1

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

Давайте розглянемо нижче Послуги в додатку.

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

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

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

ЕТАП 2

Етап планування тесту. Тестові кейси пишуться для кожного рівня.

1. Кінець до кінця рівень. Тестові приклади написані для кожного випадку використання та потоку бізнесу.

   Нижче наведено приклади тестових кейсів

   • Створіть замовлення з активним користувачем.
   • Створіть замовлення з неактивним користувачем.
   • Створіть замовлення з наявним товаром із кількістю замовлення <доступна кількість.
   • Створіть замовлення з наявним товаром із кількістю замовлення> доступною кількістю.
   • Створіть замовлення з кількома елементами
   • Скасувати замовлення повністю.
   • Скасувати замовлення частково.
2. Рівень інтеграції. Тестові кейси написані для інтеграції бази даних та інтерфейсу користувача.

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

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

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

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

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

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

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

Давайте розглянемо, що інструмент Soapui розглядається для тестування програми.

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

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

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

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

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

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

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

3) Рівень від кінця до кінця

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

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

Висновок:

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