Чим відрізняється тестування інтеграції компонентів від цього?

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

Що таке тестування компонентів? Методи, приклади тестів

⚡ Розумний підсумок

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

🧩 Сфера застосування: Один компонент за раз, ізольований від компонентів навколо нього.
👥 власник: Тестери запускають його після того, як розробники завершать модульне тестування.
🔬 КТІС: Тестування компонентів у малому масштабі повністю ізолює компонент.
🔗 CTIL: Тестування компонентів у великих масштабах зберігає залежності, реальні чи змодельовані.
🧱 Doubles: Драйвер викликає компонент; він викликає заглушку.
✅ Вихід: У журналі не залишається відкритих жодних дефектів критичного, високого або середнього рівня.

Детальніше

Що таке тестування компонентів?

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

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

Варто заздалегідь зробити зауваження щодо найменування. Глосарій ISTQB розглядає тестування компонентів та одиничне тестування як синоніми одного й того ж рівня тестування. Багато команд розробників, і ця стаття, на практиці розрізняють ці два поняття: розробники проводять модульні тести власного коду, а тестувальники потім проводять компонентні тести наданої збірки. Порівняльна таблиця в кінці цієї статті показує цю практичну відмінність.

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

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

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

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

Хто проводить тестування компонентів

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

Коли проводити тестування компонентів

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

Вхідні критерії для тестування компонентів

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

Критерії виходу для тестування компонентів

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

Методи тестування компонентів

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

CTIS — тестування компонентів у малому
CTIL — Тестування компонентів у великих масштабах

CTIS — тестування компонентів у малому

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

Приклад 1: На веб-сайті з п'ятьма різними веб-сторінками тестування кожної веб-сторінки окремо та ізольовано від інших компонентів – це тестування компонентів у малому масштабі.

Приклад 2: Головна сторінка guru99.com, показана нижче, містить багато компонентів, таких як Головна, Тестування, SAP, Веб, Обов'язково вчимося!, Великі дані, Живі проекти та Блог.

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

Відкриття випадаючого меню «Тестування» відображає підкомпоненти компонента «Тестування»: Ручне тестування, SOAPUI, QTP, JUnit, Selenium, Управління тестуванням та Мобільне тестуванняНа знімку нижче ці підкомпоненти виділені червоним кольором.

CTIL — Тестування компонентів у великих масштабах

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

Приклад пояснює різницю. Припустимо, що застосунок складається з трьох компонентів: Компонент A, Компонент B та Компонент C.

Розробник створив Компонент B і хоче його протестувати. Щоб повністю протестувати Компонент B, деякі його функції залежать від Компонента A, а деякі — від Компонента C, як показано на діаграмі нижче.

Потік функціональності такий: A → B → C, що означає, що компонент B залежить як від A, так і від C. У цьому потоці заглушка є викликаною функцією, а драйвер – функцією, що викликає.

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

Заглушка: Тестований компонент викликає заглушку. Компонент C не готовий, тому його замінює заглушка, яка повертає відповіді, очікувані B.
водій: Драйвер викликає тестований компонент. Компонент A не готовий, тому драйвер замінює його та викликає B з необхідними вхідними даними.

Приклади тестів для тестування компонентів

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

Веб-сторінка 1 – це сторінка входу на демо-сайт банкінгу.

Коли користувач вводить дійсний ідентифікатор користувача та пароль і натискає кнопку «Надіслати», сторінка переходить на головну сторінку веб-сайту демо-банку, показану далі.

Тут сторінка входу є одним компонентом, а головна сторінка — іншим. Тестування функціональності кожної сторінки окремо — це тестування компонентів.

Сценарії тестування компонентів на веб-сторінці 1:

Введіть недійсний ідентифікатор користувача та перевірте, чи кінцевому користувачеві відображається зручне для користувача попередження.
Введіть недійсний ідентифікатор користувача та пароль, натисніть «Скинути» та перевірте, чи поля ідентифікатора користувача та пароля очищені.
Введіть дійсне ім'я користувача та пароль і натисніть кнопку «Увійти».

Сценарії тестування компонентів на веб-сторінці 2:

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

Модульне тестування проти тестування компонентів

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

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

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

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

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

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

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

Codeфреймворки рівня, такі як JUnit, TestNG, NUnit та pytest, а також запускачі компонентів інтерфейсу користувача, такі як Cypress Тестування компонентів, Storybook та Jest. Усі вони вписуються в автоматизація трубопровід.

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

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

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