суббота, 14 марта 2020 г.

Что такое минимальный файл для воспроизведения бага

Допустим, что у нас есть система, в которую можно загружать файлы:

Пример функционала с загрузкой файла

И вот мы загрузили файл, а система упала. Отчего? Из-за названия, расширения, данных внутри или размеров? Найдите проблему и уберите лишнее:
  • Падает из-за названия? Внутри пусть будет 1 ячейка (одна колонка, одна строка)
  • Нельзя загрузить больше 10 столбцов? Пусть столбцов будет 10, но лишь 1 строка
  • Слишком много строк? Строки оставляем, а колонку делаем одну
  • Проблема в конкретном значении? Например, система не может обработать високосный год? Снова оставляем одну ячейку — с этим годом. А еще лучше — пробуем воспроизвести без файла (если система предоставляет альтернативу).

То есть минимальный файл — это в котором ничего лишнего. Минимум:
  • строк
  • колонок
  • данных внутри
  • длины имени файла

Но, разумеется, на этом минимальном файле баг должен воспроизводиться. Упадет на одной ячейке? Ок, оставляем только ее. А если система первую строку игнорирует / считывает как «шапку», то нам понадобится уже две строки — одна для шапки, а вторая с «падающим» значением.


Зачем искать минимальный файл


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

Можно, конечно, спихнуть локализацию на разработчика. Мол, пусть сам думает, что плохого в файле. Но часто можно найти причину и самому, а потом более точно описать проблему. Лично я считаю, что локализация — работа тестировщика. Который потом поставит осмысленный баг, не «Что-то где-то не работает», а «На обработке високосного года в файле система падает».

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


Как найти минимальные данные


Для начала посмотрите в логи, на клиенте и на сервере. Если разработчики не поленились хорошо логировать эксепшены (ошибки в программе), вы легко поймете, в чем беда. Или хотя бы сузите область поиска — при загрузке данных в систему хорошо бы логировать успешную обработку N записей. И вот мы читаем лог:

Обработано 100 записей  
Обработано 200 записей 
Ой, что-то пошло не так!

Да, сообщение об ошибке плохое. Мы не понимаем, из-за чего именно сломалось. Но зато мы знаем, что обрабатываются пачки по 100 записей и сломалось где-то между 200 и 300.

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

Строим теорию и проверяем — удаляем всё, кроме подозрительной даты и грузим файл. Упало? Ура, мы нашли баг! Оформляем его. Не упало? Ищем подозрительные места дальше.

Если файл просмотрели и идей нет, или файл очень большой, глазками просмотреть займет много времени, используйте метод бисекционного деления (также известный как метод «деления пополам» или «дихотомия»).

Сначала с помощью бисекционного деления мы находим «проблемную» строку. А потом точно также удаляем столбцы. В итоге получаем конкретное падающее значение.

Итого, для поиска проблемы:

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


PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь моим студентам, в частности курса по логам (там мы с помощью логов учимся искать минимальный файл)

Комментариев нет:

Отправить комментарий