Ответ
Прогнозирование ошибок (Error Guessing) — это эвристическая техника тест-дизайна, основанная на опыте тестировщика, интуиции и знании типичных уязвимостей системы. Она применяется для быстрого поиска критических дефектов, особенно когда формальные методы (например, анализ граничных значений) недоступны или требуют много времени.
Как применять:
- Анализ истории дефектов — выявление повторяющихся паттернов ошибок в проекте.
- Понимание слабых мест технологии — например, проблемы с кодировкой, обработкой NULL-значений или утечками памяти.
- Проверка неочевидных сценариев — ввод некорректных данных, пропуск обязательных полей, одновременные операции.
Пример для функции деления:
# Тестируемая функция
def divide(a: float, b: float) -> float:
return a / b
# Прогнозируемые ошибки и тест-кейсы:
# 1. Деление на ноль (ZeroDivisionError)
# 2. Передача строк вместо чисел (TypeError)
# 3. Очень большие числа (переполнение)
# 4. Передача None или пустых значенийПочему это работает: Техника использует знание распространённых ошибок разработки и прошлых сбоев системы, что делает её эффективным дополнением к формальным методам тестирования.
Ответ 18+ 🔞
А, слушай, вот есть такая штука — прогнозирование ошибок. По-умному это «Error Guessing», а по-нашему — «ну я чую жопой, где тут сейчас всё посыпется, ёпта». Это когда ты, как опытный шаман, просто смотришь на систему и говоришь: «Сюда сейчас плюнуть — и всё, пиздец».
Ну серьёзно, это не про таблицы, не про граничные значения. Это когда твой внутренний голос орёт: «Бля, а вот тут же на ноль поделить можно! А тут строку впихнут! А тут китайские иероглифы введут — и всё, накрылось всё медным тазом!»
Как это делается, если по-простому:
- Глянь, что уже ломалось. Открой баг-трекер и посмотри, где раньше всё горело. Обычно эти пидарасы-ошибки любят возвращаться, как бумеранг в жопу.
- Знай, где система хромает. Каждая технология — своя ахиллесова пята. У веба — кодировки и куки, у мобилок — память и повороты экрана, у баз данных — NULL-значения, от которых всё встаёт колом.
- Будь долбоёбом от пользователя. Представь самого распиздяйского юзера. Он будет жать все кнопки разом, вводить «-0», оставлять поля пустыми, копировать хуйню из Word’а. Вот и делай так.
Вот, смотри, простейший пример. Есть функция деления:
def divide(a: float, b: float) -> float:
return a / bНормальный человек подумает: «О, деление. Ну окей». А ты, как тестировщик с прокачанной интуицией, сразу видишь перед глазами четыре сценария ебли:
divide(5, 0)— классика жанра, деление на ноль. Ждём, когда интерпретатор выплюнет нам в рожуZeroDivisionError.divide("десять", "два")— а если передать строки? Да похуй, что пользователь — идиот. Система должна не сдохнуть, а красиво сказать «иди нахуй с такими данными».divide(1e308, 0.001)— очень большие числа. А не переполнится ли там что-нибудь? Не превратится ли всё вinf?divide(None, 5)— а если передатьNone? Или пустой список? Что будет, блядь? Упадёт? Молча проглотит? Вот это и надо проверить!
А почему эта хитрость вообще работает? Да потому что все мы, включая разработчиков (ничего личного), — люди. И все мы наступаем на одни и те же грабли. Где-то забыли проверить входные данные, где-то не подумали про крайний случай. Твоя задача — быть этой самой хитрой жопой, которая эти грабли заранее видит и на них указывает. Это как дополнение ко всем умным методикам. Иногда один такой «угаданный» тест стоит десятка формальных.