Допустим, что у нас есть система, в которую можно загружать файлы:
И вот мы загрузили файл, а система упала. Отчего? Из-за названия, расширения, данных внутри или размеров? Найдите проблему и уберите лишнее:
То есть минимальный файл — это в котором ничего лишнего. Минимум:
Но, разумеется, на этом минимальном файле баг должен воспроизводиться. Упадет на одной ячейке? Ок, оставляем только ее. А если система первую строку игнорирует / считывает как «шапку», то нам понадобится уже две строки — одна для шапки, а вторая с «падающим» значением.
Поиск минимального файла особенно актуален, когда баг приходит от пользователя. Пользователь не будет локализовывать баг, у него просто падает, и всё. При этом падать может на одном конкретном значении, а сам файл будет весить сотни мегабайт. Зачем же нам такой огромный файл пихать в баг-трекер??
Можно, конечно, спихнуть локализацию на разработчика. Мол, пусть сам думает, что плохого в файле. Но часто можно найти причину и самому, а потом более точно описать проблему. Лично я считаю, что локализация — работа тестировщика. Который потом поставит осмысленный баг, не «Что-то где-то не работает», а «На обработке високосного года в файле система падает».
Если найти минимальные данные для воспроизведения, то:
Для начала посмотрите в логи, на клиенте и на сервере. Если разработчики не поленились хорошо логировать эксепшены (ошибки в программе), вы легко поймете, в чем беда. Или хотя бы сузите область поиска — при загрузке данных в систему хорошо бы логировать успешную обработку N записей. И вот мы читаем лог:
Да, сообщение об ошибке плохое. Мы не понимаем, из-за чего именно сломалось. Но зато мы знаем, что обрабатываются пачки по 100 записей и сломалось где-то между 200 и 300.
Дальше можем просмотреть файл глазками — может быть, проблема бросится в глаза. Мы ведь тестировали функционал, проверяли разные значения. Поэтому примерно представляем, что «Это работает, это тоже... О, стоп, тут дата 01.01.1900, я такую не проверял. Может быть, в ней дело?».
Строим теорию и проверяем — удаляем всё, кроме подозрительной даты и грузим файл. Упало? Ура, мы нашли баг! Оформляем его. Не упало? Ищем подозрительные места дальше.
Если файл просмотрели и идей нет, или файл очень большой, глазками просмотреть займет много времени, используйте метод бисекционного деления (также известный как метод «деления пополам» или «дихотомия»).
Сначала с помощью бисекционного деления мы находим «проблемную» строку. А потом точно также удаляем столбцы. В итоге получаем конкретное падающее значение.
Итого, для поиска проблемы:
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь моим студентам, в частности курса по логам (там мы с помощью логов учимся искать минимальный файл)
 |
| Пример функционала с загрузкой файла |
И вот мы загрузили файл, а система упала. Отчего? Из-за названия, расширения, данных внутри или размеров? Найдите проблему и уберите лишнее:
- Падает из-за названия? Внутри пусть будет 1 ячейка (одна колонка, одна строка)
- Нельзя загрузить больше 10 столбцов? Пусть столбцов будет 10, но лишь 1 строка
- Слишком много строк? Строки оставляем, а колонку делаем одну
- Проблема в конкретном значении? Например, система не может обработать високосный год? Снова оставляем одну ячейку — с этим годом. А еще лучше — пробуем воспроизвести без файла (если система предоставляет альтернативу).
То есть минимальный файл — это в котором ничего лишнего. Минимум:
- строк
- колонок
- данных внутри
- длины имени файла
Но, разумеется, на этом минимальном файле баг должен воспроизводиться. Упадет на одной ячейке? Ок, оставляем только ее. А если система первую строку игнорирует / считывает как «шапку», то нам понадобится уже две строки — одна для шапки, а вторая с «падающим» значением.
Зачем искать минимальный файл
Поиск минимального файла особенно актуален, когда баг приходит от пользователя. Пользователь не будет локализовывать баг, у него просто падает, и всё. При этом падать может на одном конкретном значении, а сам файл будет весить сотни мегабайт. Зачем же нам такой огромный файл пихать в баг-трекер??
Можно, конечно, спихнуть локализацию на разработчика. Мол, пусть сам думает, что плохого в файле. Но часто можно найти причину и самому, а потом более точно описать проблему. Лично я считаю, что локализация — работа тестировщика. Который потом поставит осмысленный баг, не «Что-то где-то не работает», а «На обработке високосного года в файле система падает».
Если найти минимальные данные для воспроизведения, то:
- Вы сэкономите время разработчику — ему не придется подключаться к тестовому стенду, самому грузить файл и дебажить.
- Менеджер сможет легко оценить приоритет задачи — это нужно срочно исправлять, или баг может подождать? Пока название «некоторые файлы падают, хз почему» — это сделать сложно...
- Описание бага от понимания причины падения тоже только выиграет.
Как найти минимальные данные
Для начала посмотрите в логи, на клиенте и на сервере. Если разработчики не поленились хорошо логировать эксепшены (ошибки в программе), вы легко поймете, в чем беда. Или хотя бы сузите область поиска — при загрузке данных в систему хорошо бы логировать успешную обработку N записей. И вот мы читаем лог:
Обработано 100 записей
Обработано 200 записей
Ой, что-то пошло не так!
Да, сообщение об ошибке плохое. Мы не понимаем, из-за чего именно сломалось. Но зато мы знаем, что обрабатываются пачки по 100 записей и сломалось где-то между 200 и 300.
Дальше можем просмотреть файл глазками — может быть, проблема бросится в глаза. Мы ведь тестировали функционал, проверяли разные значения. Поэтому примерно представляем, что «Это работает, это тоже... О, стоп, тут дата 01.01.1900, я такую не проверял. Может быть, в ней дело?».
Строим теорию и проверяем — удаляем всё, кроме подозрительной даты и грузим файл. Упало? Ура, мы нашли баг! Оформляем его. Не упало? Ищем подозрительные места дальше.
Если файл просмотрели и идей нет, или файл очень большой, глазками просмотреть займет много времени, используйте метод бисекционного деления (также известный как метод «деления пополам» или «дихотомия»).
Сначала с помощью бисекционного деления мы находим «проблемную» строку. А потом точно также удаляем столбцы. В итоге получаем конкретное падающее значение.
Итого, для поиска проблемы:
- Читаем лог — там может быть написано, где именно проблема, в каком значении. Или хотя бы наводка «Не смог обработать дату? Значит, дело в какой-то дате!». Плюс можно примерно понять, в каком интервале строк падает.
- Методом бисекционного деления находим падающую строку.
- Методом бисекционного деления находим падающий столбец.
Выкидываем все лишнее, оставляя только «плохую» ячейку, загружаем файл — чтобы убедиться, что на нем падает. Профит! Можно оформлять баг!
Комментариев нет:
Отправить комментарий