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