Модульне/юніт/компонентне тестування (Module/Unit/Component testing)
З цими термінами часто відбувається плутанина. Якщо посилатися на глосарій ISTQB, то всі вони – синоніми:
Модуль, юніт (module, unit): Див.
Модульне, юніт тестування (module testing, unit testing): Див. компонентне тестування.
Компонент: Найменший елемент програмного забезпечення, який можна протестувати окремо.
Компонентне тестування: Тестування окремих компонентів програмного забезпечення (IEEE 610).
Тим не менш, деякі джерела описують ситуацію трохи інакше, і я вирішив виписати іншу точку зору.
Модульне тестування (воно ж юніт-тестування)використовується для тестування будь-якого одного логічно виділеного та ізольованого елемента системи (окремі методи класу або проста функція, subprograms, subroutines, класи чи процедури) у коді. Очевидно, що це тестування методом білої скриньки і найчастіше воно проводиться самими розробниками. Метою тестування модуля є не демонстрація правильного функціонування модуля, а демонстрація наявності помилки у модулі, а також у визначенні ступеня готовності системи до переходу на наступний рівень розробки та тестування. На рівні модульного тестування найпростіше виявити дефекти, пов'язані з алгоритмічними помилками та помилками кодування алгоритмів, типу роботи з умовами та лічильниками циклів, а також з використанням локальних змінних та ресурсів. Помилки, пов'язані з неправильним трактуванням даних, некоректною реалізацією інтерфейсів, сумісністю, продуктивністю тощо. зазвичай пропускаються лише на рівні модульного тестування і виявляються більш пізніх стадіях тестування. Ізоляція тестованого блоку досягається за допомогою заглушок (stubs), манекенів (dummies) та макетів (mockups).
Компонентне тестування - тип тестування, при якому тестування виконується для кожного окремого компонента окремо, без інтеграції з іншими компонентами. Його також називають модульним тестуванням (Module testing), якщо його з погляду архітектури. Як правило, будь-яке програмне забезпечення загалом складається з кількох компонентів. Тестування на рівні компонентів (Component Level testing) має справу із тестуванням цих компонентів індивідуально. Це один із найчастіших типів тестування чорної скриньки, який проводиться командою QA. Для кожного з цих компонентів буде визначено сценарій тестування, який потім буде наведено до Test case високого рівня -> детальним Test case низького рівня з попередніми умовами.
Виходячи з глибини рівнів тестування, компонентне тестування можна класифікувати як:
Тестування компонентів у малому (CTIS - Component testing In Small): тестування компонентів може проводитися з або без ізоляції інших компонентів у програмному забезпеченні або додатку. Якщо це виконується з ізоляцією іншого компонента, це називається CTIS;
Тестування компонентів в цілому (CTIL - Component testing In Large) - тестування компонентів, виконане без ізоляції інших компонентів у програмному забезпеченні або додатку;
Module/Unit testing
Component testing
Тестування окремих класів, функцій для демонстрації того, що програма виконується згідно специфікації
Тестування кожного об'єкта або частин програмного забезпечення окремо з або без ізоляції інших об'єктів
Перевірка відповідно до design documents
Перевірка відповідно до test requirements, use case
Пишуться та виконуються розробниками
Тестувальниками
Виконується першим
Виконується після Unit
Інше джерело:
По-суті ці рівні тестування представляють одне й теж, різниця лише в тому, що в компонентному тестуванні як параметри функцій використовують реальні об'єкти та драйвери, а в модульному/unit тестуванні - конкретні значення.
*У контексті юніт-тестування ще можна зустріти поняття golden testing . Воно означає ті ж юніт тести, але з очікуваними результатами, що зберігаються в окремому файлі. Таким чином, після прогону вихідні значення тестів порівнюються з golden (еталонним) файлом.
*Іноді юніт-тести називають одинокими (solitary) у разі тотального застосування імітацій та заглушок або товариськими (sociable) у разі реальних комунікацій з іншими учасниками.
*Правило трьох А(AAA) (arrange, act, assert) чи тріада «дано, коли, тоді» - хороша мнемоніка, щоб підтримувати хорошу структуру тестів.
Джерела:
Дод. матеріал:
ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 “D.11 Підпроцес покомпонентного тестування”
Last updated