Какие классификации задач тестирования вы знаете?

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

1. По уровню, где мы тыкаем палкой (уровень изоляции):

• Модульное (Unit) — это когда ты берёшь одну мелкую функцию, отсаживаешь её от всех соседей и начинаешь мучать: «А ну-ка, сука, посчитай мне скидку! А если я тебе ноль подам? А если отрицательное число?». Никого вокруг, только она и ты.
• Интеграционное — а вот тут уже начинается веселье. Ты соединяешь две этих функции, которые по отдельности работали, и смотришь, как они друг друга ебут. Одна данные шлёт, другая их жрёт, а в итоге — пиздец, null pointer exception на ровном месте.
• Системное (End-to-End) — это уже полный цирк с конями. Запускаешь всю систему, как будто реальный пользователь: нажал кнопку, пошёл запрос на сервер, там база данных, там ещё какая-то хуйня, и в конце должен прийти правильный ответ. Если что-то сломалось — ищи иголку в стоге сена, блядь.
• Приемочное (UAT) — это когда ты уже всё проверил, а потом приходит какой-нибудь менеджер Петрович, тыкает в интерфейс пальцем и говорит: «А я хотел не так. Это нихуя не работает». И всё, приехали.

2. По тому, ЧТО именно мы проверяем (цели):

• Функциональное — самая понятная хуйня. Требования говорят: «При нажатии на кнопку «Купить» должен создаться заказ». Мы нажимаем. Создался? Молодец. Не создался? Иди нахуй, чини.
• Нефункциональное — это уже про то, КАК оно работает. Быстро ли? Не упадёт ли, если 1000 человек одновременно начнут тыкать? Удобно ли? Безопасно ли? Можно ли туда впендюрить SQL-инъекцию? Вот это всё.
• Регрессионное — святое дело. Пофиксили баг с оплатой. А мы теперь должны проверить, что эта фикса не разъебала вдруг корзину, каталог и личный кабинет. Потому что бывает так — один чинишь, десять ломаешь.
• Дымовое (Smoke) — это быстрая проверка на вшивость после каждой новой сборки. Запустился ли вообще сервер? Открывается ли главная страница? Можно ли залогиниться? Если даже это не работает — дальше можно не проверять, всё, пизда сборке, несите следующую.

3. Кто это делает — человек или железный раб (автоматизация):

• Ручное — это когда ты, бедолага-тестировщик, сидишь и вручную тыкаешь в интерфейс, заполняешь формы, сверяешь результаты. Скучно, долго, но для первого раза или сложных кейсов — необходимо.
• Автоматизированное — это когда ты написал скрипт, и теперь этот скрипт — твой верный пёс. Нажал кнопку «Пуск», и он сам всё проверит за тебя, быстрее и без перекуров. Красота.
• Полуавтоматизированное — обычно какая-то хитрая жопа, где часть шагов делает скрипт, а потом тебе говорит: «А теперь, хозяин, посмотри вот на этот экран и скажи, всё ли правильно?». И ты смотришь.

4. Когда и сколько мы это делаем (время и объём):

• Дымовое (Smoke) — мы уже говорили, быстро и по верхам. Сразу после сборки.
• Санитарное (Sanity) — это когда пофиксили конкретный баг. Мы не проверяем всю систему, а только ту самую фичу и то, что с ней напрямую связано. Узко, но точно.
• Полное регрессионное (Full Regression) — это пиздец и апокалипсис. Берёшь ВСЕ тест-кейсы, которые у тебя есть, и гоняешь их по всей системе. Делается это обычно перед крупным релизом. Долго, нудно, но необходимо.

А вот пример того самого модульного теста, где мы мучаем одну функцию:

def test_calculate_discount():
    # Unit-тест для проверки логики расчета скидки
    from shop import calculate_discount
    assert calculate_discount(100, 10) == 90  # 10% скидка
    assert calculate_discount(50, 0) == 50    # Без скидки

Смотри, что тут происходит: мы импортируем одну функцию calculate_discount и начинаем её дрочить вопросами. «На 100 рублей дай 10% скидки!» — должна вернуть 90. Возвращает? Отлично. «А теперь дай 0% скидки на 50!» — должна вернуть 50. Если оба утверждения (assert) не взрываются — значит, функция в рамках этих условий работает. Если взорвалось — значит, где-то в логике просчёт, иди разбирайся, мудак.

Вот и вся магия. Не так страшен чёрт, как его малюют в этих заумных статьях. Главное — понимать, для чего каждая штука нужна, а не просто зубрить классификации.