Ответ
Тестирование черного ящика проверяет функциональность системы без доступа к ее коду. Основные техники и примеры:
| Техника | Суть | Пример тест-кейса |
|---|---|---|
| Эквивалентное разделение | Группировка входных данных, где одно значение репрезентует класс. | Поле «Возраст» (допустимо: 0-120). Классы: недопустимый (<0), допустимый (0-120), недопустимый (>120). Тестируем: -1, 30, 150. |
| Анализ граничных значений | Тестирование на границах разделов. | Для диапазона 1-100 тестируем: 0, 1, 2, 99, 100, 101. |
| Таблица решений | Комбинации условий и действий. | Условия: Пользователь активен? / Пароль верен? Действия: Вход разрешен, Показать ошибку, Заблокировать аккаунт. |
| Тестирование состояний и переходов | Проверка реакции на события в разных состояниях системы. | Состояние корзины: Пустая -> (Добавить товар) -> Непустая -> (Очистить) -> Пустая. |
| Сценарий использования | Проверка типичного пользовательского сценария (User Story). | Как зарегистрированный пользователь, я хочу добавить товар в корзину и оформить заказ, чтобы его получить. Проверяем полный поток: поиск -> карточка -> корзина -> оформление. |
Ключевой принцип: Тестировщик фокусируется на входах, выходах и спецификации, а не на внутренней реализации.
Ответ 18+ 🔞
О, слушай, вот это тема! Тестирование чёрного ящика — это как пытаться понять, что за хуйня внутри подарка, когда тебе его нахуй запечатали в три слоя обёрточной бумаги и скотча. Ты его трясёшь, слушаешь, нюхаешь, но внутрь заглянуть нихуя нельзя. Вот и вся суть.
Основные приёмы, которыми мы тыкаем эту загадочную коробку, чтобы понять, не сломается ли она, если пнуть.
Эквивалентное разделение (Equivalence Partitioning) Вот представь: есть поле «Возраст». Допустим, от 0 до 120 лет. Ну, ясно же, что вводить -10 или 999 — это пиздец, а 30 — норм. Так зачем проверять все 30, 31, 32? Мы же не ебланы! Мы берём по одному значению из каждой кучки: одно из «невалидных долбоёбов» (например, -1), одно из «валидных нормальных» (30), и одно из «других невалидных долбоёбов» (150). Если система на -1 и 150 сказала «иди нахуй», а на 30 — «проходи, дружок», значит, скорее всего, и весь класс значений она обработает правильно. Хитро, блядь!
Анализ граничных значений (Boundary Value Analysis)
А вот это уже для перфекционистов, которые верят, что вся хуйня ломается именно на стыках. Диапазон 1-100? Окей. Но мы-то знаем, что баг, как дерьмо, всплывает на границах. Поэтому тыкаем не просто 1 и 100, а 0, 1, 2, 99, 100, 101. Потому что программист мог написать if age >= 1 and age <= 100, и забыть, что >= и <= — это проеб, который ждёт тебя на границе. Вот тут-то его и ловим, этого пидораса шерстяного!
Таблица решений (Decision Table) Это когда условий дохуя, и комбинаций нихуя не сосчитать в уме. Например: пользователь активен? пароль верен? аккаунт заблокирован? Вместо того чтобы ебать мозг, рисуем табличку. Все условия — сверху, все действия — снизу. И смотрим: если «активен = да», «пароль верен = нет», «заблокирован = нет» -> действие «Показать ошибку пароля». Это чтобы не получилось, что система при неверном пароле вдруг говорит «Добро пожаловать, ёпта!». Такое бывает, я тебе скажу, волнение ебать.
Тестирование состояний и переходов (State Transition Testing) Система — она как мартышка: может быть в разных состояниях. Корзина пустая, корзина непустая, заказ оформлен, заказ оплачен. И между этими состояниями есть переходы. Добавил товар — перешла из «Пустая» в «Непустая». Очистил корзину — обратно в «Пустая». А теперь представь, что ты в состоянии «Оплачено» пытаешься нажать «Добавить товар». Должно, блядь, либо не давать, либо охуеть и выдать ошибку. Вот мы эти все переходы и проверяем, чтобы не было таких пиздопроебибенных сценариев, когда из оплаченного заказа можно вернуться в «Пустая корзина», потеряв все деньги. Хуй с горы, да?
Сценарий использования (Use Case Testing) А это самое человеческое. Берём историю пользователя: «Как зарегистрированный юзер, я хочу найти хуйню, добавить её в корзину и купить, чтобы эта хуйня приехала ко мне домой». И мы не просто тыкаем кнопки, а проходим весь этот путь от и до: поиск -> карточка товара -> корзина -> оформление -> оплата -> подтверждение. Проверяем, чтобы на всём протяжении пользователь не захотел повеситься от безысходности. Это проверка на вшивость всей системы в сборе.
А главный принцип, ёпта, какой? Мы, тестировщики, смотрим только на то, что входит, что выходит, и что должно быть по документации (спецификации). А что там внутри творится, какой там код, какие переменные — это нас, блядь, не ебёт. Наша задача — дать по рукам, если на выходе получилась не та хуйня, которую обещали. Всё просто, как три копейки. Чихать-пыхтеть на внутреннюю реализацию!