CC BY
13
УДК 004.150
Тихонов Г.А. студент 4 курса
факультет «Информационных систем и технологий»
научный руководитель: Тучкова А. С.
старший преподаватель кафедра Информационные системы и технологии
ФГБОУ ВО ПГУТИ Россия г. Самара СИСТЕМА ОТСЛЕЖИВАНИЯ ОШИБОК
Аннотация: Отслеживание ошибок, найденных для исправления, является интересной областью исследований в программном обеспечении. Многие открытые, бесплатные и коммерческие инструменты отслеживания ошибок были разработаны и находятся на стадии разработки. Организациям нужны критерии для выбора лучшего инструмента среди доступных наборов инструментов, которые помогут исправлять и отслеживать ход исправления ошибок. В этой статье я использую BugZilla, Jira, Trac, Mantis, BugTracker.Net, Gnats и Fossil для сравнительного изучения. Я представляю исчерпывающие критерии классификации отсканированных инструментов, которые будут использоваться в будущем для оценки и получения результата.
Ключевые слова: система, ошибка, проблема, решение ошибок.
Tikhonov G.A. 4rd year student
Faculty of "Information systems and technologies" Volga State University of Telecommunications and Informatics
Russia, Samara Research supervisor: Tuchkova A.S.
Senior Lecturer, Departament of Informarion systems and technologies Volga State University of Telecommunications and Informatics
Russia, Samara
BUG TRACKING SYSTEM
Abstract: Tracking the errors found for correction is an exciting area of research in the software. Many open, free and commercial error tracking tools have been developed and are being developed. Organizations need criteria for selecting the best tool among the available toolkits that will help in fixing and tracking the progress of bug fixes. In this article, I use BugZilla, Jira, Trac, Mantis, BugTracker.Net, Gnats and Fossil for comparative study. I present exhaustive classification criteria for the scanned tools that will be used in future to evaluate and obtain the result.
Keywords: System, Error, Problem, Error solving
Программное обеспечение не является совершенным, это означает, что для программного обеспечения может потребоваться дополнительный модуль или усовершенствование существующего модуля, после чего он может содержать некоторые незаметные или непроверенные ошибки, которые время от времени остаются в программном обеспечении. Ошибка может появляться на любой стадии разработки программного обеспечения, то есть анализа требований (RA), проектирования (SD), кодирования (SC), тестирования (ST), реализации (SI) и обслуживания системы (SM). С быстрым увеличением разработчиков в проектах с открытым исходным кодом, которые постоянно вносят свой вклад в разработку и совершенствование проекта, есть возможность введения новых ошибок в проект. На веб-сайт проекта ежедневно отправляется несколько ошибок, которые могут использовать некоторые инструменты управления конфигурацией (SCM) для управления версиями и выпуском программного обеспечения. Инструменты SCM могут не предоставлять никакого представления об отчетах об ошибках, а также о ходе исправления ошибок. Существует настоятельная необходимость в планировании и внедрении наилучшей системы отслеживания ошибок и отчетности. В среде с открытым исходным кодом обычно, когда ошибка отправляется, любой человек может начать работу по ее исправлению. Но в то же время другие люди могут также начать работу по исправлению той же ошибки. Поэтому владелец или модератор проекта будет путать, какое решение реализовать в системе. Business software провело исследование, целью которого было сравнение лучших поставщиков программного обеспечения для выявления дефектов и ошибок. Не существует ни определенного графика времени для исправления ошибки, ни человека / команды, ответственного за своевременную фиксацию ошибки.
В патентированом программном обеспечении исправление ошибки происходит поэтапно, поскольку на каждом этапе есть отдельная группа, ответственная за работу, выполняемую на этом этапе. В то же время в проекте с открытым исходным кодом любой может найти ошибку и начать работать над этим. Зависимость может стать основной проблемой при вычислении времени для исправления ошибки. Если ошибка обнаружена до фазы реализации, она может быть качественно разрешена командой разработчиков или владельцем модуля. Но как только программное обеспечение выпущено и внедрено, становится очень сложно исправить ошибку. Стало громоздкой задачей для модератора найти подходящего разработчика, который может исправить конкретную ошибку, потому что описание сообщения об ошибке может вообще не предоставлять полной информации. Многие организации обычно полагаются на электронную почту с или без системы сообщений об ошибках с привязкой / обратной связью, и эти ошибки будут поддерживаться в электронной таблице или в любом программном обеспечении для редактирования документов. Владельцу или разработчику снова становится очень сложно отслеживать
ошибку и ход ее исправления. Существует множество инструментов, разработанных и используемых в настоящее время в промышленности для отчетности и отслеживания прогресса сообщений об ошибках как в небольших, так и в крупных проектах. Множество инструментов было разработано сообществом с открытым исходным кодом, а также частными компаниями, занимающимися разработкой программного обеспечения. Очень сложно выбрать определенную систему отчетности об ошибках и отслеживания, которая может предоставить нам эффективный, целесообразный, полезный и экономически эффективный инструмент для мониторинга хода выполнения графика исправления ошибок. Опрос проводился с целью выявления часто возникающих проблем в системе отчетности об ошибках разработчиками и пользователями. Также были предприняты усилия по моделированию в поисках качества отчета об ошибках в прошлом. Недавно был проведен опрос по инструментам отслеживания ошибок на основе представления, анализа и тенденций. Марко и Александар построили дерево решений на основе некоторых характеристик. Остальная часть статьи организована следующим образом: в разделе 2 документа описывается система отслеживания ошибок и жизненный цикл ошибок. Раздел 3 описывает различные критерии классификации системы отслеживания ошибок. В разделе 4 представлен подробный сравнительный анализ различных систем отслеживания ошибок на основе различных критериев сравнения. В 5 разделе выводы.
Система отчетности / отслеживания ошибок должна предоставлять интерактивную веб-платформу для отчетности об ошибках и отслеживания прогресса. Система может включать в себя общий процесс или конкретный график обработки сообщений об ошибках. Процесс внесения информации об ошибке может, как правило, содержать следующую пункты:
• Title (Название)- Название ошибки.
• Descriptюn(Описание) - подробное описание ошибки, включая, что, где, почему, как и когда возникает ошибка. Фактическое сообщение, которое появляется во время операции, может быть включено с фактическим набором входных данных и ожидаемым выходом.
• Versюn(Версия) - версия проекта.
• Component(Компонент) - модуль программы где найден баг.
• Screenshot/Attachment(Скриншот/приложение) - соответствующий снимок экрана также может быть загружен как .jpg или .gif файл, захватив фактическую операцию / вывод / сообщение.
• Priority(Приоритет) - приоритет может быть отнесен к его срочности.
• Severity(Серьезность) - степень влияния на систему.
• Status(Статус)- текущий статус ошибки (новый, открытый, подтвержденный, закрытый и т. д.).
• Created ьу(автор) - Имя человека или идентификатор, уже
зарегистрированного в системе, который сообщает об ошибке.
• Assigned to(Назначен) - тестировщик может назначить ошибку конкретному человеку, если известно о конкретном человеке, который может решить эту проблему, иначе назначает менеджер.
• Revision History(История изменения) - история изменения отчета.
• Estimated time(расчет времени) - время на исправление. Как правило, используется в случае закрытой рабочей команды, а не в среде с открытым исходным кодом.
• Comments(Комментарий) - любая другая информация, которая будет полезна при идентификации ошибки.
Как только ошибка будет отправлена в систему, менеджер увидит ее статус и посмотрит детали отчета и его различные параметры. Менеджер также может сбросить или обновить некоторые параметры и соответственно обновить значения статуса и обладателя бага. В крупных проектах с открытым исходным кодом средняя скорость передачи сообщений об ошибках достаточно высока. Например, в проекте средняя скорость передачи сообщений об ошибках составляет 50 выпусков в день. Таким образом, менеджеру очень сложно просматривать каждую ошибку, а затем обновлять ее статус и присваивать ошибку определенному человеку. Хотя каждая система / инструмент имеет свой собственный жизненный цикл ошибки, здесь общий жизненный цикл ошибки (рис.1).
Есть много систем отслеживания ошибок, доступных в отрасли для использования. Системы отслеживания ошибок также называются системой отслеживания проблем или багтрекером или системой отслеживания дефектов и т. Д. Системы отслеживания ошибок разрабатываются сообществом с открытым исходным кодом, а также организациями с закрытым кодом в качестве проприетарного программного обеспечения. Открытый исходный код означает, что исходный код предоставляется всем в соответствии с политикой GPL. Любой может внести свой вклад в код добровольно. В сообществах с закрытым исходным кодом исходный код является собственностью организации, и люди, которые не входят в проект, возможно, не смогут увидеть / просмотреть код. Некоторые из инструментов отслеживания ошибок принадлежат сообществам с открытым исходным кодом, а некоторые из них - сообществам с закрытым кодом или коммерческим организациям. Существуют организации, которые также могут предоставлять поддержку решений с открытым исходным кодом. Например, Redhat Inc. предоставляет Red Hat Enterprise Linux (RHEL) и поддерживает сообщества проектов с открытым исходным кодом Fedora. Fedora подпадает под категорию open source, в то время как RHEL - это коммерческая версия, которую поддерживает и спонсирует Redhat.
Рис.1- жизненный цикл ошибки Использованные источники:
1. Национальная библиотека им. Н.Э. Баумана [Электронный ресурс] -Режим доступа: https://ru.bmstu.wiki/Система отслеживания ошибок (дата обращения: 17.03.2019)
2. Программы систем отслеживания ошибок [Электронный ресурс] - Режим доступа: https://ru.atlassian.com/software/jira/bug-tracking (дата обращения: 17.03.2019)
3. Научная библиотека [Электронный ресурс] - Режим доступа: http://sernam.ru/index.php (дата обращения: 17.03.2019)
