Какие типы проверок вы выполняете с помощью автоматизированных тестов?

Тип вопроса: Автоматизация тестирования Вероятность: 10% Категория: QA Тестировщик

Ответ

Автоматизированные тесты покрывают различные уровни и аспекты приложения:

1. Функциональное тестирование

  • Позитивные сценарии: Проверка, что функция работает при корректных входных данных.
  • Негативные сценарии: Проверка обработки ошибок при неверных данных.
  • Анализ граничных значений.

2. API-тестирование (Integration)

  • Валидация статус-кодов (200, 201, 400, 404, 500).
  • Проверка схемы ответа (JSON Schema, структура данных).
  • Проверка заголовков (headers).
  • Проверка бизнес-логики и корректности возвращаемых данных.

Пример API-теста на Python с requests:

import requests

def test_get_user():
    url = 'https://api.example.com/users/1'
    response = requests.get(url)

    # Проверка статус-кода
    assert response.status_code == 200, f"Expected 200, got {response.status_code}"

    # Проверка заголовка
    assert response.headers['Content-Type'] == 'application/json'

    # Проверка тела ответа
    data = response.json()
    assert data['id'] == 1
    assert 'name' in data
    assert isinstance(data['email'], str)
    # ... дополнительные проверки

3. UI-тестирование (E2E)

  • Соответствие макетам (pixel-perfect).
  • Корректность отображения данных.
  • Работоспособность пользовательских сценариев (логин, добавление в корзину).
  • Кроссбраузерность и адаптивность (запуск в разных браузерах и разрешениях).

4. Нефункциональное тестирование (частично)

  • Нагрузочное тестирование (с помощью k6, JMeter).
  • Проверка безопасности (базовые тесты на инъекции).

5. Тестирование базы данных

  • Проверка целостности данных после операций.
  • Проверка корректности сложных SQL-запросов.

Ответ 18+ 🔞

Слушай, а вот это самое тестирование, оно ж, блядь, как слоёный пирог, понимаешь? Разные пласты, разные вкусы, а в итоге — либо вкусно, либо в рот меня чих-пых, все в говне. Сейчас разложу по полочкам, как есть.

Первое, функциональное. Тут всё просто, как три копейки. Есть два священных пути:

  1. Позитивный сценарий: Всё работает, как задумано. Подкинул функции правильные цифры — получил на выходе не хуйню, а ожидаемый результат. Красота.
  2. Негативный сценарий: А вот тут начинается магия. Подсовываешь ей всякую дичь: буквы вместо цифр, пустоту, отрицательные числа, овердохуища символов. И смотришь — не падает ли она с треском, а культурно, по-человечески, говорит: «Чувак, ты дебил? Вот тебе ошибка, иди исправляй». Если молча сдохла — пиши пропало, тест не прошла.
  3. Граничные значения. Это когда ты долбишь систему ровно на стыке. Максимум, минимум, ровно ноль. Часто именно тут она и показывает свою истинную, блядовитую натуру.

Второе, API-тесты (или интеграционные). Это когда ты ебешь не напрямую в интерфейс, а в эту самую, понимаешь, «кухню» приложения. Ты стучишься к нему в дверь (эндпоинт) и ждёшь, что оно тебе ответит.

  • Статус-коды: 200 — «всё пучком, братан, держи ответ»; 404 — «пошёл на хуй, ничего нет»; 500 — «ой, всё, у меня внутри пиздец, сам разбирайся».
  • Схема ответа: Получил JSON? А он правильной структуры? Все поля на месте, или какое-то съебало налево?
  • Заголовки: А контент-тайп тот? А кэширование как?
  • Логика: Данные-то в ответе адекватные? Запросил пользователя с ID=1, а тебе вернули бабку Глашу из 3-го подъезда? Не, так не пойдёт.

Вот, смотри, как это выглядит в коде, тут всё серьёзно, без смехуёчков:

import requests

def test_get_user():
    url = 'https://api.example.com/users/1'
    response = requests.get(url)

    # Проверка статус-кода
    assert response.status_code == 200, f"Expected 200, got {response.status_code}"

    # Проверка заголовка
    assert response.headers['Content-Type'] == 'application/json'

    # Проверка тела ответа
    data = response.json()
    assert data['id'] == 1
    assert 'name' in data
    assert isinstance(data['email'], str)
    # ... дополнительные проверки

Третье, UI-тесты (E2E). А это уже цирк с конями, ёпта! Ты заставляешь браузер, как обезьяну, тыкать в кнопки и заполнять поля. Проверяешь:

  • Внешний вид: Похоже на макет? Или криво, косо и пиздато?
  • Данные: То, что пришло с бэка, нормально отрисовалось? Или вместо имени «Иван» горит «NaN undefined»?
  • Сценарии: Весь путь пользователя: залогиниться, найти товар, сунуть в корзину, купить. Если на каком-то шаге браузер уткнулся лбом в стену и завис — тест провален, волнение ебать.
  • Браузеры: А в Хроме работает? А в Фаерфоксе? А на телефоне? Вот где начинается настоящая жесть.

Четвёртое, нефункциональное. Тут уже не «что делает», а «как делает».

  • Нагрузка: А что будет, если не один ты, а десять тысяч таких же умников одновременно начнут тыкать в кнопку «купить»? Выдержит или накроется медным тазом? Проверяется специальными тараканами-инструментами.
  • Безопасность: Нельзя же просто так, с бухты-барахты, принимать от пользователя что попало. Базовая проверка, чтобы никто не впендюрил какую-нибудь злобную хуйню в твои поля.

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

Вот такая, блядь, многослойная история. Без этого всего — это как ехать на машине, которую собрали на глазок, без инструментов. Может, повезёт, а может, и хуй с горы.

© ХакСобесов, 2026
support@hacksobesov.com