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

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

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

Що таке SOA?

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

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

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

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

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

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

Web-сервіси

Більшість SOA-сервісів представлені як веб-сервіси, тому механіку виклику веб-сервісу варто ознайомити перед тестуванням.

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

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

• Постачальник послуг публікує послугу в Інтернеті.
• Клієнт шукає певний веб-сервіс у реєстрі веб-сервісів.
• A URL і WSDL для потрібного веб-сервісу повертаються. Використання WSDL та URL, зв'язок між постачальником послуг та запитувачем відбувається через SOAP-повідомлення.
• Коли споживач викликає веб-сервіс, встановлюється HTTP-з'єднання з постачальником.
• SOAP-повідомлення створюється для того, щоб доручити постачальнику викликати необхідну логіку веб-сервісу.
• Відповідь, отримана від постачальника, — це SOAP-повідомлення, вбудоване у HTTP-відповідь. Ця HTTP-відповідь має формат даних, зрозумілий для застосунку користувача.

Приклад

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

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

Шари тестування SOA

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

SOA-тестування повинно зосереджуватися на 3 системних рівнях.

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

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

Наприклад, розглянемо веб-сайт про здоровий спосіб життя, який складається з:

• Маса TracКер
• Рівень цукру в крові TracКер
• Кров'яний тиск TracКер

Trackers відображають відповідні дані та дату їх введення. Рівень сервісів складається з сервісів, які отримують відповідні дані з бази даних:

• Маса Tracкер сервіс
• Рівень цукру в крові Tracкер сервіс
• Кров'яний тиск Tracкер сервіс
• Служба входу в систему

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

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

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

Основна увага на цьому рівні приділяється користувацьким інтерфейсам та процесам. Користувацький інтерфейс ваги tracker та його інтеграція з базою даних є основною метою.

Враховуються такі функції:

• Додавання нових даних
• Редагування існуючих даних
• Створення нового tracКер
• Видалення даних

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

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

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

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

Два напрямки руху відрізняються: для розробки тестів використовується підхід «зверху вниз», а для виконання тестів — підхід «знизу вгору».

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

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

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

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

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

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

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

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

2) Заглушки

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

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

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

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

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

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

Функціональне тестування слід виконувати для кожної послуги, щоб:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) SoapUI

SoapUI це інструмент функціонального тестування з відкритим кодом для сервісів та Тестування API.

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

2) Віртуалізація сервісів Broadcom (раніше iTKO LISA)

LISA — це пакет продуктів, який надає рішення для функціонального тестування розподілених систем, таких як SOA. Продукт перейшов від iTKO до CA Technologies і сьогодні продається під назвою Broadcom Service Virtualization.

• Також може використовуватися для регресійного, інтеграційного, навантажувального та продуктивного тестування.
• Може використовуватися для розробки та виконання тестів.

3) UFT Один (раніше HP Service Test)

Service Test – це інструмент функціонального тестування, який підтримує тестування як інтерфейсу користувача, так і спільних сервісів. Його можливості тестування API були включені до Unified Functional Testing, який тепер продається компанією... OpenText as UFT Один.

• Як функціональні, так і продуктивні тести сервісів можуть бути виконані одним скриптом.
• Інтегровано з Центром якості, тепер продається як OpenText ALM / Центр якості.
• Можна керувати величезною кількістю послуг і даних.
• Підтримує тестування сумісності шляхом імітації клієнтських середовищ JEE, AXIS і DotNet.

4) Parasoft SOAtest

Parasoft SOAtest — це набір інструментів для тестування та аналізу, розроблений для тестування API та API-орієнтованих додатків.

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

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

У наведеному нижче прикладі наведено застосування вищезазначеної стратегії, методів та інструментів до одного сайту електронної комерції, поетапно.

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

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

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

ФАЗА 1

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

Розглянемо послуги, наведені нижче у заявці.

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

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

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

ФАЗА 2

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

Рівень від кінця до кінця. Тестові випадки написані для кожного бізнес-випадку використання та потоку. Нижче наведено приклади тестових випадків.

• Створіть замовлення з активним користувачем.
• Створіть замовлення з неактивним користувачем.
• Створіть замовлення з доступним товаром, кількість якого < доступної кількості.
• Створіть замовлення з доступним товаром, кількість якого перевищує доступну кількість.
• Створіть замовлення з кількома товарами.
• Повністю скасувати замовлення.
• Частково скасувати замовлення.

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

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

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

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

ФАЗА 3 — Виконання тесту

Виконання тестів використовує підхід «знизу вгору»: спочатку проводиться тестування рівня сервісу, потім рівня інтеграції, і нарешті — наскрізне тестування.

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

Давайте врахуємо, що SoapUI інструмент використовується для тестування програми. WSDL та URL переглядаються у вікні тестування SoapUI, а запит для кожної послуги відображається у вікні запиту. Шляхом зміни даних відповідно до тестових випадків рівня послуги створюються запити для кожного тестового випадку.

Тестовий випадок	Запит	Очікувана відповідь
Створити замовлення. Кількість товарів = 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) Наскрізний рівень

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

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

Поширені запитання