Система отслеживания ошибок

Материал из Википедии — свободной энциклопедии
(перенаправлено с «Баг-трекинг»)
Перейти к навигации Перейти к поиску

Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.

Состав информации о дефекте[править | править код]

Главный компонент такой системы — база данных, содержащая сведения об обнаруженных дефектах. Эти сведения могут включать в себя:

  • номер (идентификатор) дефекта;
  • короткое описание дефекта;
  • кто сообщил о дефекте;
  • дата и время, когда был обнаружен дефект;
  • версия продукта, в которой обнаружен дефект;
  • серьёзность (критичность) дефекта и приоритет решения[1];
  • описание шагов для выявления дефекта (воспроизведения непреднамеренного поведения программы);
  • ожидаемый результат и фактический результат;
  • кто ответственен за устранение дефекта;
  • обсуждение возможных решений и их последствий;
  • текущее состояние (статус) дефекта;
  • версия продукта, в которой дефект исправлен.

Кроме того, развитые системы предоставляют возможность прикреплять файлы, помогающие описать проблему (например, дамп памяти или скриншот).

Жизненный цикл дефекта[править | править код]

Как правило, система отслеживания ошибок использует тот или иной вариант «жизненного цикла» ошибки, стадия которого определяется текущим состоянием, или статусом, в котором находится ошибка.

Типичный жизненный цикл дефекта:

  1. новый — дефект зарегистрирован тестировщиком
  2. назначен — назначен ответственный за исправление дефекта
  3. разрешён — дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например:
    • исправлено (исправления включены в версию такую-то)
    • дубль (повторяет дефект, уже находящийся в работе).
    • не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т. п.)
    • невоспроизводимо (запрос дополнительной информации об условиях, в которых дефект проявляется).
  4. далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус назначен (если он описан как исправленный, но не исправлен), либо в статус закрыт.
  5. открыт повторно — дефект вновь найден в другой версии.

Система может предоставлять администратору возможность настроить, какие пользователи могут просматривать и редактировать ошибки в зависимости от их состояния, переводить их в другое состояние или удалять.

В корпоративной среде система отслеживания ошибок может использоваться для получения отчётов, показывающих продуктивность программистов при исправлении ошибок. Однако, часто такой подход не даёт достаточно точных результатов, потому что разные ошибки имеют различную степень серьёзности и сложности. При этом серьёзность проблемы не имеет прямого отношения к сложности устранения ошибки.

См. также[править | править код]

Примечания[править | править код]

  1. «Бейзер, например, предлагает шкалу от 1 (незначительная ошибка, например, грамматическая) до 10 (фатальная, вызывающая сбои в других системах, войны, убийства и т. д.)». «Тестирование программного обеспечения», Канер, Фолк, Нгуен. Гл. 5, с. 105. ISBN 9667393879