Виды тестирования ПО
1. Unit Testing (Юнит-тестирование)
Ты написал функцию calculateDiscount(price, promo), которая считает итоговую цену со скидкой. Ты тестируешь только её в изоляции: подаёшь на вход разные числа и проверяешь, что результат правильный. Остальное приложение тебя не интересует.
Когда: логика вычислений, утилиты, хуки, фильтры, валидаторы. Инструменты: Jest, Vitest
2. Integration Testing (Интеграционное тестирование)
Форма регистрации отрисовывается и поля работают — но правильно ли при сабмите вызывается API и корректно ли ответ сервера попадает в стейт? Ты проверяешь связку нескольких модулей вместе.
Когда: взаимодействие компонентов, работа с API, формы, роутинг. Инструменты: React Testing Library, Vue Test Utils
3. Functional Testing (Функциональное тестирование)
В приложение добавили новую фичу: фильтрацию товаров по цене. Ты садишься и проверяешь именно её: работает ли ползунок, применяется ли фильтр, обновляется ли список. Только эта фича, только по ТЗ.
Когда: приёмка новой функциональности, проверка соответствия ТЗ. Инструменты: Cypress, Playwright, ручное тестирование
4. Smoke Testing (Смоук-тестирование)
Вышла новая сборка. Ты за 2 минуты проверяешь самое критичное: открывается ли главная страница, работает ли авторизация, загружается ли каталог. Если нет — сборка сразу возвращается на доработку без дальнейших проверок.
Когда: после каждого деплоя или сборки в CI/CD. Инструменты: Playwright, Cypress, ручной прогон
5. Sanity Testing (Санитарное тестирование)
Разработчик починил баг: кнопка «Оформить заказ» не срабатывала при пустом поле. Ты проверяешь только это: вводишь данные, кликаешь кнопку, смотришь результат. Остальное не трогаешь.
Когда: после точечного фикса, перед передачей в QA. Инструменты: ручное тестирование, Cypress
6. System Testing (Системное тестирование)
Приложение полностью готово. Ты прогоняешь все сценарии в тестовой среде: регистрацию, поиск, оформление заказа, личный кабинет, уведомления. Проверяешь соответствие всем пунктам ТЗ. До прода ещё не выходим.
Когда: перед релизом, в тестовом окружении. Инструменты: Playwright, Cypress, ручное тестирование
7. Regression Testing (Регрессионное тестирование)
После того как добавили фильтрацию товаров, ты прогоняешь все старые тесты: авторизацию, корзину, оформление заказа. Нужно убедиться, что новая фича не сломала то, что работало раньше.
Когда: после любых изменений в коде, особенно в общих модулях. Инструменты: Jest, Vitest, Playwright, Cypress (в связке с CI)
8. Screenshot Testing (Скриншот-тестирование)
Ты сохранил эталонный скриншот кнопки «Добавить в корзину». После очередного PR робот рендерит ту же кнопку и сравнивает попиксельно. Кнопка технически кликается — но если шрифт съехал или цвет фона изменился, тест это поймает.
Когда: проверка UI-компонентов на визуальные регрессии после изменений в CSS. Инструменты: Playwright (встроенный), Storybook + Chromatic, Percy
9. E2E Testing (Сквозное тестирование)
Ты запускаешь браузер и проходишь полный путь пользователя: зашёл на сайт → нашёл товар → добавил в корзину → ввёл данные карты → получил письмо с подтверждением. Реальный браузер, реальный бэкенд, реальное окружение.
Когда: критические бизнес-сценарии (покупка, регистрация, оплата). Инструменты: Playwright, Cypress
10. Acceptance Testing / UAT (Приёмочное тестирование)
Приложение готово. Его передают заказчику или реальным пользователям. Они сами проходят по сценариям и решают: соответствует ли продукт их ожиданиям и тому, что было прописано в договоре. Если да — подписывают акт приёмки.
Когда: финальный этап перед релизом, с участием заказчика. Инструменты: ручное тестирование, бета-тестирование
Сравнительная таблица
| Вид тестирования | Цель | Изоляция |
|---|---|---|
| Unit | Проверить одну функцию/компонент | Полная (всё замокано) |
| Integration | Проверить связку 2+ модулей | Частичная |
| Functional | Проверить новую фичу по ТЗ | Зависит от уровня |
| Smoke | Убедиться, что сборка не «мертва» | Нет |
| Sanity | Убедиться, что конкретный фикс работает | Нет |
| System | Соответствие ТЗ всей системы | Тестовое окружение |
| Regression | Старое не сломалось после изменений | Нет |
| Screenshot | Визуальная регрессия не появилась | Нет (реальный рендер) |
| E2E | Пользовательский путь целиком | Нет (реальное окружение) |
| Acceptance (UAT) | Бизнес-требования выполнены | Нет |
Кто и как проводит
| Вид тестирования | Developer | QA | Авторежим |
|---|---|---|---|
| Unit | ✅ | ➖ | ✅ всегда |
| Integration | ✅ | ✅ | ✅ часто |
| Functional | ✅ | ✅ | ⚠️ частично |
| Smoke | ➖ | ✅ | ✅ в CI/CD |
| Sanity | ✅ | ✅ | ⚠️ редко |
| System | ➖ | ✅ | ⚠️ частично |
| Regression | ➖ | ✅ | ✅ рекомендуется |
| Screenshot | ✅ | ✅ | ✅ всегда |
| E2E | ➖ | ✅ | ✅ для критичных |
| Acceptance (UAT) | ➖ | ➖ | ❌ только ручное |
✅ — да, ⚠️ — зависит от проекта, ➖ — не типично, ❌ — не применимо
Пирамида тестирования
Классическая пирамида упорядочена по гранулярности/изоляции, а ширина уровня — рекомендуемое количество тестов:
/ E2E / UAT \ ← мало, медленно, дорого
/ Integration \
/ Component / System \
/ Unit Tests \ ← много, быстро, дёшево
Smoke, Sanity, Screenshot (визуальная регрессия) — это ортогональные категории (стратегии запуска и техники), а не уровни пирамиды: их не располагают «этажами» по количеству.