Виды тестирования: полная классификация с примерами

Видов тестирования много, но они не свалены в кучу: это несколько независимых классификаций, наложенных друг на друга. Один и тот же тест одновременно относится к нескольким.

Главное, что стоит понять сразу: виды тестирования не исключают друг друга. Один прогон бывает одновременно системным, чёрного ящика, функциональным и ручным. Это как описывать человека: рост, возраст и профессия — независимые характеристики.

По уровням: насколько крупный кусок проверяем

Уровень	Что проверяем	Кто обычно делает
Модульное (unit)	Отдельную функцию в отрыве от остального	Разработчик
Интеграционное	Совместную работу модулей и сервисов	Разработчик или тестировщик
Системное	Продукт целиком со стороны пользователя	Тестировщик
Приёмочное	Соответствие тому, ради чего всё делалось	Заказчик, бизнес, иногда пользователи

Чем ниже уровень, тем дешевле и быстрее тест и тем точнее он показывает место поломки. Чем выше — тем ближе к реальному использованию. Отсюда идея пирамиды: много быстрых модульных тестов внизу, немного медленных сквозных наверху.

По знанию внутреннего устройства

• Чёрный ящик. Проверяем поведение, не заглядывая в код. Так работает большинство ручных проверок.
• Белый ящик. Знаем код и строим проверки по его структуре: ветвления, условия, пути.
• Серый ящик. Знаем часть внутреннего устройства: схему базы, контракт API, архитектуру. На практике тестировщик чаще всего именно здесь.

По цели: функциональное и всё остальное

Функциональное отвечает на вопрос «делает ли система то, что должна». Всё остальное принято называть нефункциональным — оно про то, как она это делает.

Вид	Вопрос, на который отвечает
Производительность	Выдержит ли нагрузку и как быстро отвечает
Нагрузочное	Что будет при ожидаемом числе пользователей
Стрессовое	Где ломается и как восстанавливается после
Безопасность	Можно ли получить чужие данные или права
Удобство (UX)	Поймёт ли человек, что делать, без инструкции
Доступность	Сможет ли пользоваться человек с ограничениями
Совместимость	Работает ли в разных браузерах, ОС, на разных экранах
Локализация	Не ломается ли вёрстка и смысл на другом языке

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

• Дымовое (smoke). Быстрая проверка, что сборку вообще имеет смысл тестировать. Готовый список — в чек-листе smoke-теста.
• Санитарное (sanity). Узкая проверка конкретного исправления.
• Регрессионное. Проверка, что новое не сломало старое. Самый объёмный прогон, первый кандидат на автоматизацию.
• Повторное (ретест). Проверка ровно того дефекта, который починили.

По способу исполнения и по подходу

Ручное — человек проходит сценарий сам. Автоматизированное — тот же сценарий выполняет программа. Автоматизация окупается на том, что повторяется часто и стабильно; на редких и постоянно меняющихся сценариях она дороже, чем польза от неё.

Отдельно стоит исследовательское тестирование: тестировщик изучает продукт и одновременно придумывает проверки, а не идёт по готовому списку. Именно так находят то, чего нет ни в одном чек-листе, — и именно это ИИ пока не умеет.

Как это выглядит на реальном проекте

Классификации полезны для понимания, но в работе никто не говорит «сейчас проведу системное функциональное тестирование методом чёрного ящика». Говорят проще: «прогоню смоук», «проверю регресс по оплате», «посмотрю на мобилке».

Обычный цикл вокруг одной задачи выглядит так:

1. Разработчик выкатил сборку на тестовый стенд — тестировщик прогоняет смоук, чтобы понять, есть ли смысл продолжать.
2. Проверяет новую функцию по чек-листу — это функциональное системное тестирование, хотя так его никто не называет.
3. Заводит дефекты, разработчик чинит — тестировщик делает ретест каждого исправления.
4. Перед релизом гоняется регресс: то, что раньше работало, должно работать и сейчас.
5. После выката на прод — короткая проверка ключевых сценариев уже на боевом.

Нефункциональные виды подключаются точечно: нагрузочное — перед распродажей, безопасность — когда появляются платежи или персональные данные, доступность — если этого требует заказчик или закон.

Как выбрать, что применять на своей задаче

Полный список видов бесполезен, пока не понятно, что взять сегодня. Ориентируйтесь на риск: чем дороже ошибка в этом месте, тем больше видов подключается.

Что меняли	Что применить
Текст на кнопке	Проверка соответствия макету, локализация если языков несколько
Логика расчёта скидки	Функциональное, границы, проверка данных в базе
Форма оплаты	Функциональное, негативное, безопасность, проверка на мобильных
Переезд на новый сервер	Smoke, регресс, производительность, совместимость
Новый раздел целиком	Всё перечисленное плюс исследовательское — там больше всего неизвестного

Что чаще всего путают

• Интеграционное и системное. Первое — про стык двух частей, второе — про продукт целиком глазами пользователя.
• Нагрузочное и стрессовое. Первое проверяет ожидаемую нагрузку, второе намеренно ищет точку слома.
• Приёмочное и системное. Приёмочное проводит сторона заказчика и отвечает на вопрос «берём или нет», а не «есть ли дефекты».
• Исследовательское и «потыкать наугад». В первом есть цель, хартия и фиксация результата; во втором — только клики.