Що таке тестування інтерфейсу? Типи та приклад

Що таке тестування інтерфейсу?

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

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

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

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

Як виконати тестування інтерфейсу

Тестування інтерфейсу включає тестування двох основних сегментів:

1. Інтерфейс веб-сервера та сервера додатків
2. Сервер додатків і інтерфейс сервера бази даних.

Для вищезазначених сценаріїв тестування інтерфейсу виконується для

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

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

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

Приклад тестування інтерфейсу

Припустимо, що для будь-якої програми xyz інтерфейс приймає XML файл як вхідні дані та доставляє JSON файл як вивід. Щоб протестувати інтерфейс цієї програми, потрібні лише специфікації формату XML-файлу та формату JSON-файлу.

За допомогою цих специфікацій ми можемо створити зразки вхідних XML-файлів та передати їх інтерфейсу. А потім перевірити вхідний (XML) та вихідний (JSON) файли на відповідність вимогам – це тестування інтерфейсу.

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

Навіщо тестувати інтерфейс

Тестування інтерфейсу виконано

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

Існує також аргумент щодо вартості. Дефект у форматі запиту дешево виправити, поки дві системи ще з'єднуються, і дорого, коли наступна система вже зберегла спотворені дані.

Типи тестування інтерфейсу

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

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

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

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

Стратегія тестування інтерфейсів – це метод, який використовується для тестування інтерфейсів за допомогою загальних тестів незалежно від реалізації. Ми можемо використовувати abstract тестові випадки та створювати конкретні екземпляри тестового випадку для кожної реалізації стратегії тестування інтерфейсу. База/абсtracТестові випадки виконують нейтральні до реалізації тести, тоді як конкретні тести піклуються про створення екземплярів об'єктів для тестування та виконання тестів, специфічних для реалізації.

Вигодою від такої структури є повторне використання. Коли з'являється третя реалізація того ж інтерфейсу, abstract suite працює з ним без змін, і потрібно написати лише код створення екземпляра. Та сама ідея застосовується в більшому масштабі в тестування компонентів, де спільна конtract suite запускається для кожного компонента, який претендує на його задоволення.

Інструменти для тестування інтерфейсів

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

• Клієнти API та конструктори запитів: Такі інструменти, як Postman, SoapUI, Insomnia та Hoppscotch надсилають виклики REST, SOAP або GraphQL, зберігають їх як колекції повторного використання та стверджують (assert) коди стану, заголовки та тіла відповідей.
• Codeбібліотеки тестів рівня: Бібліотеки, що працюють всередині існуючого набору тестів, дозволяють перевіркам інтерфейсу працювати поруч із модульними тестами та виконуватися на кожній збірці, що запобігає їх застаріванню.
• Інструменти завантаження та протоколювання: Такий інструмент, як JMeter керує тим самим інтерфейсом на рівні тома, що перетворює функціональну перевірку на тестування працездатності з'єднання.
• Віртуалізація сервісів та макети: Заглушка, що замінює дальній кінець, дозволяє протестувати одну сторону, поки інша недоступна, незавершена або занадто дорога для повторного виклику.

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

Контрольний список тестування інтерфейсу та найкращі практики

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

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

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

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

Тестування інтерфейсу проти інтеграційного тестування

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

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

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