Виды и уровни тестирования

Виды и уровни тестирования

Тестирование классифицируют по разным осям. В этом уроке разберём две главные: уровни (на каком уровне детализации мы проверяем систему) и виды (что именно мы проверяем).

Уровни тестирования

Уровни обычно выстраивают «снизу вверх» — от мельчайших единиц к продукту целиком.

1. Unit testing (модульное)

Проверяется самая маленькая единица кода — функция, класс, метод. Запускается на этапе разработки, обычно автоматически. Этим уровнем чаще всего занимаются разработчики.

Пример: функция calculateDiscount(price, percent) возвращает корректное значение для типовых входов и для крайних случаев (0%, 100%, отрицательные значения).

2. Integration testing (интеграционное)

Проверяется взаимодействие нескольких модулей. Корректно ли модуль авторизации передаёт данные модулю профиля? Правильно ли API общается с базой?

Тестировщик-вручную здесь часто играет роль на уровне «компонент + соседи»: проверить, что после регистрации появляется письмо и пользователь может залогиниться.

3. System testing (системное)

Проверяется продукт целиком — со всеми его подсистемами, интеграциями и ограничениями. Здесь работают QA-инженеры с end-to-end сценариями: «пользователь регистрируется, кладёт товар в корзину, оформляет заказ, получает письмо».

4. Acceptance testing (приёмочное)

Финальная проверка перед передачей продукта заказчику или пользователю. Цель — подтвердить, что бизнес-цели достигнуты. Часто включает:

• UAT (User Acceptance Testing) — проверяет заказчик или представители пользователей.
• OAT (Operational Acceptance Testing) — проверка эксплуатационных аспектов: бэкапы, мониторинг, восстановление.

Пирамида тестирования

Уровни визуализируют в виде пирамиды (мы детально разберём её в модуле 2):

        ┌───────────────┐
        │  E2E / UAT    │   ← мало, дорого, ловят целостные сценарии
        ├───────────────┤
        │  Integration  │   ← среднее количество
        ├───────────────┤
        │     Unit      │   ← много, дёшево, быстро
        └───────────────┘

Чем выше уровень — тем дороже тест и тем медленнее он выполняется. Поэтому здоровый баланс: много unit-тестов снизу и небольшое количество E2E сверху.

Виды тестирования

Это ортогональная ось — что именно мы проверяем.

Функциональное

Проверяет, что система делает: соответствует ли поведение требованиям. Самая типовая работа QA: «вход → действия → ожидаемый выход».

Нефункциональное

Проверяет, как система это делает:

• Performance — производительность, скорость отклика.
• Load / Stress — поведение под нагрузкой и за её пределами.
• Security — уязвимости, защита данных, авторизация.
• Usability — удобство для пользователя.
• Compatibility — работа на разных устройствах, ОС, браузерах.
• Localization — корректность переводов, форматов дат, валют.
• Accessibility — доступность для людей с особыми потребностями.

Структурное (white-box)

Проверяет внутреннюю структуру кода. Например, что все ветвления if/else хотя бы раз исполнились. В чистом виде ручным QA редко делается — это скорее автоматизация и code coverage.

Тестирование изменений

Особый класс, связанный с уже существующим продуктом:

• Confirmation testing (retest) — проверяем, что конкретный баг исправлен.
• Regression testing — проверяем, что после фикса не сломалось то, что работало раньше.

Этому будет отдельный урок в модуле 2.

Виды и уровни вместе

Эти оси независимы. Можно делать функциональное тестирование на уровне unit, integration и system. Можно делать нагрузочное (нефункциональное) тестирование только на уровне system. Например:

Что мы запомним

• Уровни: unit → integration → system → acceptance.
• Виды: функциональное (что делает) vs нефункциональное (как делает).
• Уровни и виды — независимые оси: одно и то же поведение можно проверять на разных уровнях.
• Confirmation и regression — два специальных вида, важных для уже существующих продуктов.