Хтось може чітко визначити ці рівні тестування, оскільки мені важко диференціювати, виконуючи TDD або модульне тестування. Будь ласка, якщо хтось може пояснити, як, коли їх застосовувати?
Відповіді:
Коротко:
Модульне тестування - Ви модульне тестування кожного окремого фрагмента коду. Подумайте над кожним файлом або класом.
Інтеграційне тестування - При складанні декількох блоків, що взаємодіють, потрібно провести інтеграційне тестування, щоб переконатися, що інтеграція цих модулів разом не призвела до помилок.
Регресійне тестування - після інтеграції (і, можливо, виправлення) вам слід запустити свої модульні тести знову. Це регресійне тестування, щоб переконатись, що подальші зміни не зламали жодних вже перевірених одиниць. Вже проведене вами модульне тестування створило модульні тести, які можна запускати знову і знову для регресійного тестування.
Приймальні випробування - коли користувач / замовник / компанія отримують функціональні можливості, вони (або ваш тестовий відділ) проводять прийомні випробування, щоб переконатися, що функціональність відповідає їхнім вимогам.
Ви також можете дослідити тестування білої та чорної скриньок. Є також тестування продуктивності та навантаження, а також тестування "ідентичностей", які слід врахувати.
Юніт-тест: коли він не вдається, він повідомляє, який фрагмент коду потрібно виправити.
Тест інтеграції: коли він не вдається, він повідомляє вам, що частини програми не працюють разом, як очікувалося.
Приймальний тест: коли він не вдається, він повідомляє вам, що програма не робить того, що очікує замовник.
Тест на регресію: коли він не вдається, він повідомляє, що програма більше не поводиться так, як раніше.
Ось просте пояснення кожного із згаданих тестів і того, коли вони застосовні:
Тест одиниці Тест одиниці проводиться на автономному блоці (як правило, класі або методі) і повинен проводитися щоразу, коли одиниця впроваджена або оновлення одиниці завершено.
Це означає, що він запускається, коли ви пишете клас / метод, виправляєте помилку, змінюєте функціональність ...
Тест інтеграції Тест інтеграції має на меті перевірити, наскільки кілька одиниць взаємодіють між собою. Цей тип випробувань слід проводити щоразу, коли між підрозділами встановлюється нова форма зв'язку або змінюється характер їх взаємодії.
Це означає, що він запускається, коли нещодавно записаний блок інтегрується в решту системи або коли оновлюється блок, який взаємодіє з іншими системами (і успішно завершує свої модульні тести).
Тест на регресію Тести на регресію проводяться щоразу, коли що-небудь змінювалося в системі, щоб перевірити, чи не було введено нових помилок.
Це означає, що він запускається після всіх виправлень, оновлень, виправлень помилок. Регресійне тестування можна розглядати як окремий випадок комбінованого модульного тесту та інтеграційного тесту.
Приймальні випробування Приймальні випробування проводяться, коли важливо перевірити, чи підсистема (можливо, вся система) відповідає всім своїм специфікаціям.
Це означає, що він в основному запускається перед завершенням нового результату або оголошенням про завершення більшого завдання. Дивіться на це як на останню перевірку, щоб переконатися, що ви дійсно виконали свої цілі, перш ніж бігти до клієнта / боса та оголошувати перемогу.
Так я принаймні дізнався, хоча я впевнений, що існують і інші протилежні погляди. У будь-якому випадку, я сподіваюся, що це допоможе.
Я спробую:
Unit Test: чи правильно працює мій єдиний метод? (НІ залежностей, ні залежностей, які висміюються)
Тест інтеграції: чи працюють мої два окремо розроблені модулі в точності, коли їх складати?
Тест на регресію: чи я щось зламав, змінивши / написавши новий код? (запуск модульних / інтеграційних тестів з кожним комітом - це технічно (автоматизоване) регресійне тестування). Частіше використовується в контексті контролю якості - ручний або автоматизований.
Приймальний тест : тестування, проведене клієнтом, що він "приймає" доставлений SW
Не можу коментувати (репутація низька: - |), тому ...
@Andrejs вказує на відмінності між середовищами, пов'язаними з кожним видом тестування.
Модульні тести виконуються, як правило, на машині розробників (і, можливо, під час побудови CI) з висміюванням залежностей від інших ресурсів / систем.
Інтеграційні тести за визначенням повинні мати (певною мірою) доступність залежностей; інші ресурси та системи називаються так, щоб довкілля було більш репрезентативним. Дані для тестування можуть бути знущанням чи невеликим заплутаним підмножином реальних виробничих даних.
Тестування UAT / приймання повинно представляти реальний досвід для контролю якості та бізнес-команд, які приймають програмне забезпечення. Тому потрібна повна інтеграція та реалістичні обсяги даних та повні замасковані / затуманені набори даних, щоб забезпечити реалістичну продуктивність та зручність роботи з кінцевими користувачами.
Іншим "ілюзіям" також потрібно навколишнє середовище бути максимально наближеним до реальності для імітації виробничого досвіду, наприклад, тестування продуктивності, безпеки, ...