Сообщений в теме: 2

[baranceva]

Автор: Назина (Киселева) Ольга (автор тренинга Школа для начинающих тестировщиков)

Иногда баги сами нас находят. Вот мы впихали большую строку данных — и система подвисла. Это она из-за 1 млн символов упала? Или ей какой-то конкретный не понравился?

Или файл загрузили в систему и он упал. Отчего? Из-за названия, расширения, данных внутри или размеров? Можно спихнуть локализацию на разработчика, пусть сам думает, что плохого в файле. Но часто можно найти причину и самому, а потом более точно описать проблему.

Если найти минимальные данные для воспроизведения, то:

• Вы сэкономите время разработчику — ему не придется подключаться к тестовому стенду, самому грузить файл и дебажить
• Менеджер сможет легко оценить приоритет задачи — это нужно срочно исправлять, или баг может подождать? Пока название «некоторые файлы падают, хз почему» — это сделать сложно...
• Описание бага от понимания причины падения тоже только выиграет.

Как найти минимальные данные для воспроизведения бага? Если есть какие-то подсказки в логах, применяем их. Если подсказок нет, то самый оптимальный метод — метод бисекционного деления (также известный как метод «деления пополам» или «дихотомия»).

 

Читать статью полностью...

[TemirlanU]

Очень интересно. Спасибо!
Применимо ли такое к полям, например, регистрации?

Условно полей 100 и ошибка неизвестна.
В соответствии с этим методом, берем вернхюю половину строк, затем нижнюю половину строк. Проверяем и повторяем. Правильно?

[Molechka]

Очень интересно. Спасибо!
Применимо ли такое к полям, например, регистрации?

Условно полей 100 и ошибка неизвестна.
В соответствии с этим методом, берем вернхюю половину строк, затем нижнюю половину строк. Проверяем и повторяем. Правильно?

Да, именно так!

 

Только если баг в верхней половине, не забудьте проверить после нижнюю, а то вдруг у вас было 2 проблемы?))