Що таке модульне тестування? Означення, приклади
Томас Гамільтон
⚡ Розумний підсумок
Модульне тестування перевіряє окремі підпрограми, підпрограми, класи та процедури, а не зібрану програму, тому дефекти проявляються всередині невеликого, добре зрозумілого блоку коду, де їх легше знайти та виправити.
Що таке модульне тестування?
Тестування модулів – це тип тестування програмного забезпечення, який перевіряє окремі підпрограми, підпрограми, класи або процедури в програмі. Замість тестування всієї програми одночасно, модульне тестування рекомендує тестувати менші структурні блоки програми.
Тестування модулів значною мірою орієнтоване на «білу скриньку». Мета тестування модулів полягає не в тому, щоб продемонструвати належне функціонування модуля, а в тому, щоб продемонструвати наявність у ньому помилки. Важлива ця інверсія: запуск, який нічого не знаходить, підтвердив дуже мало, тоді як запуск, який виявляє дефект, виконав свою роботу.
Тестування на рівні модулів також дозволяє впровадити паралелізм у процес тестування, оскільки це створює можливість тестувати кілька модулів одночасно, замість того, щоб чекати на повну збірку.
Навіщо проводити модульне тестування
Тестування модулів рекомендується, оскільки воно змінює економічні показники виявлення дефектів.
- Ймовірність виявлення помилок або багів у менших фрагментах програми стає вищою.
- Кілька модулів можна тестувати одночасно, і тому цей підхід підтримує паралельне тестування.
- Складність тестування легко контролювати, оскільки кожен модуль обмірковується окремо.
- Дефект, виявлений всередині одного модуля, tracможливо налагодити невеликий обсяг коду, тому час налагодження різко скорочується.
Як виконати модульне тестування?
Проектування a тестовий випадок є важливим сегментом модульного тестування. Під час розробки тестових випадків для модульного тестування тестувальник повинен враховувати дві речі.
- Специфікація на модуль
- Вихідний код модуля
Проаналізуйте логіку модуля, використовуючи один або декілька з біла коробка методи, а потім доповнити ці тестові випадки, застосовуючи Чорна скринька методи до специфікації модуля. Реалістичні значення мають таке ж значення, як і обрані шляхи, тому підготуйте дані тесту разом зі справами, а не після них.
Після того, як тестові випадки розроблені, наступним кроком є об'єднання модулів для тестування. Використаний метод є або зростаючий або неінкрементальний метод.
- Неінкрементний метод — усі модулі тестуються незалежно. Спочатку об'єднуються всі модулі, а потім тестується вся програма.
- Інкрементальний метод — кожен модуль спочатку тестується, а потім поступово додається до протестованої колекції. Виконується покрокове повторне тестування.
- У рамках інкрементального тестування існує два підходи, з верху до низу та знизу вгору тестування.
- Для виконання модуля з вибраними даними потрібен драйвер для постачання тестових даних, контролю виконання та фіксації результатів.
Вибір між двома методами є компромісом між зусиллями налаштування та діагностикою.
| Аспект | Інкрементальний метод | Неінкрементний метод |
| Комбінація | Один модуль за раз, доданий до перевіреної колекції | Всі модулі об'єднані, а потім протестовані разом |
| Потрібні будівельні риштування | Більше драйверів та заглушок, написаних поступово | Менше дублів тестів, оскільки присутні реальні модулі |
| Локалізація проблем | Сильний — помилка вказує на щойно доданий модуль | Слабкий — збій може виникнути будь-де |
| Найкраще підходить для | Великі збірки з багатьма взаємодіючими модулями | Невеликі програми з невеликою кількістю модулів та низьким рівнем зв'язку |
Драйвери та заглушки в тестуванні модулів
Згаданий вище драйвер є половиною пари. Оскільки модуль, що тестується, рідко знаходиться на вершині чи нижній частині ланцюжка викликів, тестувальники замінюють фіктивним кодом те, що відсутнє з обох боків.
- Водій — замінює викликаючий модуль над тим, що тестується. Він надає тестові дані, викликає модуль, контролює виконання та фіксує результати. Тестування «знизу вгору» залежить від драйверів, оскільки нижчі модулі готові раніше за вищі.
- Пень — замінює викликаний модуль під тим, що тестується. Він приймає виклик і повертає фіксовану, відому відповідь, щоб модуль, що тестується, міг завершити свій шлях. Тестування зверху вниз залежить від заглушок, оскільки модулі вищого рівня готові першими.
Опрацьований випадок робить пару конкретною. Якщо модуль розрахунку платежу завершено, а екран оформлення замовлення, який його викликає, ні, водій передає модулю набір загальних сум замовлення та записує те, що повертається. Якщо сервіс пошуку податків, який викликає модуль, також незавершений, заглушка повертає фіксовану ставку податку, тому розрахунок все ще виконується. Жоден з елементів каркасу не відправляється; обидва викидаються після надходження реальних модулів, тому помилка у тесті подвійного розуміння згадується пізніше як повторювана проблема.
Приклади порад для тестування модуля
Ось кілька порад, які слід врахувати перед проведенням тестування модулів.
- Revпереглядайте тестові випадки перед їх використанням.
- Уникайте плутанини щодо джерела розбіжностей.
- Використовуйте автоматизовані інструменти тестування.
- Перевірте змінні, які повинні залишитися незмінними.
- Обмінюйте модулі між тестерами, щоб уникнути самотестування.
- Повторно використовуйте тестові випадки.
П'ята порада має більшу вагу, ніж випливає з її довжини. Розробник, який тестує лише щойно написаний модуль, повторює ті самі припущення, що призвели до дефекту, тому ротація модулів між людьми є одним із найдешевших можливих покращень якості.
Модульне тестування проти модульного тестування
Ці два терміни використовуються як взаємозамінні в багатьох командах, проте авторство та сфера застосування відрізняються.
| Тестування модуля | Unit Testing |
| Модульні тести — це набір тестів, написаних тестувальником після написання коду розробником | Блокові тести це набір тестів, написаних розробником під час процесу розробки програмного забезпечення |
| Модульне тестування може включати об'єднання модульних тестів | Модульне тестування може тестувати модулі окремо |
Модульне тестування проти компонентного тестування проти інтеграційного тестування
Модульне тестування також розташоване поруч із двома сусідніми рівнями, які легко сплутати з ним. Таблиця розділяє їх за тим, що тестується та хто зазвичай це виконує.
| Аспект | Тестування модулів | Тестування компонентів | Інтеграційне тестування |
| Під тестуванням | Одна підпрограма, клас або процедура | Один автономний компонент з його безпосередніми залежностями | Інтерфейси між об'єднаними модулями |
| Звичайний власник | Тестер, після написання коду | Тестер | Тестер інтеграції |
| Ліси | Драйвери та заглушки | Заглушки для зовнішніх залежностей | Поступово менше дублів тестів |
| Виявлений дефект | Логічна помилка всередині модуля | Помилка поведінки в компоненті | Помилка інтерфейсу та передачі даних |
У повсякденному використанні тестування компонентів та модульне тестування часто розглядаються як одна й та сама діяльність, тоді як інтеграційне тестування починається лише після того, як окремі модулі будуть успішно складені самостійно.
Проблеми в модульному тестуванні
Це ті проблеми, з якими команди стикаються найчастіше, коли впроваджується модульне тестування.
- Неінкрементне тестування вимагає більше роботи — об’єднання всього спочатку означає, що одна помилка може призвести до того, що тестувальники будуть змушені пройти всю програму знову.
- Подвійний тест на непорозуміння — заглушка, яка повертає нереалістичне значення, створює зелений пробіг, який нічого не доводить.
- Часте налагодження тестів — код скамфолінгу має власні недоліки, а час, витрачений на виправлення драйвера, — це час, не витрачений на тестування модуля.
- Необхідно зрозуміти код — орієнтація «білого ящика» означає, що тестер, який не може прочитати модуль, не може розробити для нього змістовні випадки.
