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

Размещено на http://www.allbest.ru/

Национальный аэрокосмический университет им. Н.Е. Жуковского «Харьковский авиационный институт»

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

Давыденко Александр Анатольевич

Отслеживание найденных ошибок для исправления является увлекательной областью исследований в программном обеспечении. Многие открытые, бесплатные и коммерческие инструменты для отслеживания ошибок были разработаны и в настоящее время разрабатываются. Для организаций нужны критерии для выбора лучшего инструмента среди доступных наборов инструментов, которые помогут в фиксации и отслеживании прогресса исправления ошибок. В этой статье я использую BugZilla, Jira, Trac, Mantis, BugTracker.Net, Gnats и Fossil для сравнительного изучения. Я представляю исчерпывающие критерии классификации для просмотренных инструментов которые в дальнейшем будет использованы для оценивания и получения результата.

Ключевые слова: система отслеживания ошибок / проблем; разрешение ошибок; оценка.

Программное обеспечение не является совершенным, это означает, что для программного обеспечения может потребоваться дополнительный модуль или усовершенствование существующего модуля, после чего он может содержать некоторые незаметные или непроверенные ошибки, которые время от времени остаются в программном обеспечении. Ошибка может появляться на любой стадии разработки программного обеспечения, то есть анализа требований (RA), проектирования (SD), кодирования (SC), тестирования (ST), реализации (SI) и обслуживания системы (SM). С быстрым увеличением разработчиков в проектах с открытым исходным кодом, которые постоянно вносят свой вклад в разработку и совершенствование проекта, есть возможность введения новых ошибок в проект. На веб-сайт проекта ежедневно отправляется несколько ошибок, которые могут использовать некоторые инструменты управления конфигурацией (SCM) для управления версиями и выпуском программного обеспечения. Инструменты SCM могут не предоставлять никакого представления об отчетах об ошибках, а также о ходе исправления ошибок. Существует настоятельная необходимость в планировании и внедрении наилучшей системы отслеживания ошибок и отчетности. В среде с открытым исходным кодом обычно, когда ошибка отправляется, любой человек может начать работу по ее исправлению. Но в то же время другие люди могут также начать работу по исправлению той же ошибки. Поэтому владелец или модератор проекта будет путать, какое решение реализовать в системе. Business software провело исследование, целью которого было сравнение лучших поставщиков программного обеспечения для выявления дефектов и ошибок. Не существует ни определенного графика времени для исправления ошибки, ни человека / команды, ответственного за своевременную фиксацию ошибки.

В патентированом программном обеспечении исправление ошибки происходит поэтапно, поскольку на каждом этапе есть отдельная группа, ответственная за работу, выполняемую на этом этапе. В то же время в проекте с открытым исходным кодом любой может найти ошибку и начать работать над этим. Зависимость может стать основной проблемой при вычислении времени для исправления ошибки. Если ошибка обнаружена до фазы реализации, она может быть качественно разрешена командой разработчиков или владельцем модуля. Но как только программное обеспечение выпущено и внедрено, становится очень сложно исправить ошибку. Стало громоздкой задачей для модератора найти подходящего разработчика, который может исправить конкретную ошибку, потому что описание сообщения об ошибке может вообще не предоставлять полной информации [6]. Многие организации обычно полагаются на электронную почту с или без системы сообщений об ошибках с привязкой / обратной связью [1], [5], и эти ошибки будут поддерживаться в электронной таблице или в любом программном обеспечении для редактирования документов. Владельцу или разработчику снова становится очень сложно отслеживать ошибку и ход ее исправления. Существует множество инструментов, разработанных и используемых в настоящее время в промышленности для отчетности и отслеживания прогресса сообщений об ошибках как в небольших, так и в крупных проектах. Множество инструментов было разработано сообществом с открытым исходным кодом, а также частными компаниями, занимающимися разработкой программного обеспечения. Очень сложно выбрать определенную систему отчетности об ошибках и отслеживания, которая может предоставить нам эффективный, целесообразный, полезный и экономически эффективный инструмент для мониторинга хода выполнения графика исправления ошибок [2], [3]. Опрос проводился с целью выявления часто возникающих проблем в системе отчетности об ошибках разработчиками и пользователями [8]. Также были предприняты усилия по моделированию в поисках качества отчета об ошибках в прошлом [7]. Недавно был проведен опрос по инструментам отслеживания ошибок на основе представления, анализа и тенденций [10]. Марко и Александар [10] построили дерево решений на основе некоторых характеристик. Остальная часть статьи организована следующим образом: в разделе 2 документа описывается система отслеживания ошибок и жизненный цикл ошибок. Раздел 3 описывает различные критерии классификации системы отслеживания ошибок. В разделе 4 представлен подробный сравнительный анализ различных систем отслеживания ошибок на основе различных критериев сравнения. В 5 разделе выводы.

Система отслеживания ошибок (Багтрекер)

Система отчетности / отслеживания ошибок должна предоставлять интерактивную веб-платформу для отчетности об ошибках и отслеживания прогресса. Система может включать в себя общий процесс или конкретный график обработки сообщений об ошибках. Процесс внесения информации об ошибке может, как правило, содержать следующую пункты:

· Title (Название)- Название ошибки.

· Description(Описание) - подробное описание ошибки, включая, что, где, почему, как и когда возникает ошибка. Фактическое сообщение, которое появляется во время операции, может быть включено с фактическим набором входных данных и ожидаемым выходом.

· Version(Версия) - версия проекта.

· Component(Компонент) - модуль программы где найден баг.

· Screenshot/Attachment(Скриншот/приложение) - соответствующий снимок экрана также может быть загружен как.jpg или.gif файл, захватив фактическую операцию / вывод / сообщение.

· Priority(Приоритет) - приоритет может быть отнесен к его срочности.

· Severity(Серьезность) - степень влияния на систему.

· Status(Статус)- текущий статус ошибки (новый, открытый, подтвержденный, закрытый и т. д.).

· Created by(Автор) - Имя человека или идентификатор, уже зарегистрированного в системе, который сообщает об ошибке.

· Assigned to(Назначен) - тестировщик может назначить ошибку конкретному человеку, если известно о конкретном человеке, который может решить эту проблему, иначе назначает менеджер.

· Revision History(История изменения) - история изменения отчета.

· Estimated time(расчет времени) - время на исправление. Как правило, используется в случае закрытой рабочей команды, а не в среде с открытым исходным кодом.

· Comments(Комментарий) - любая другая информация, которая будет полезна при идентификации ошибки.

Как только ошибка будет отправлена в систему, менеджер увидит ее статус и посмотрит детали отчета и его различные параметры. Менеджер также может сбросить или обновить некоторые параметры и соответственно обновить значения статуса и обладателя бага. В крупных проектах с открытым исходным кодом средняя скорость передачи сообщений об ошибках достаточно высока. Например, в проекте [23] средняя скорость передачи сообщений об ошибках составляет 50 выпусков в день [24]. Таким образом, менеджеру очень сложно просматривать каждую ошибку, а затем обновлять ее статус и присваивать ошибку определенному человеку. Хотя каждая система / инструмент имеет свой собственный жизненный цикл ошибки, здесь общий жизненный цикл ошибки (рисунок 1).

Есть много систем отслеживания ошибок, доступных в отрасли для использования. Системы отслеживания ошибок также называются системой отслеживания проблем или багтрекером или системой отслеживания дефектов и т. Д. Системы отслеживания ошибок разрабатываются сообществом с открытым исходным кодом, а также организациями с закрытым кодом в качестве проприетарного программного обеспечения. Открытый исходный код означает, что исходный код предоставляется всем в соответствии с политикой GPL. Любой может внести свой вклад в код добровольно. В сообществах с закрытым исходным кодом исходный код является собственностью организации, и люди, которые не входят в проект, возможно, не смогут увидеть / просмотреть код. Некоторые из инструментов отслеживания ошибок принадлежат сообществам с открытым исходным кодом, а некоторые из них - сообществам с закрытым кодом или коммерческим организациям. Существуют организации, которые также могут предоставлять поддержку решений с открытым исходным кодом. Например, Redhat Inc. [21] предоставляет Red Hat Enterprise Linux (RHEL) и поддерживает сообщества проектов с открытым исходным кодом Fedora [22]. Fedora подпадает под категорию open source, в то время как RHEL - это коммерческая версия, которую поддерживает и спонсирует Redhat.

Рисунок 1 Жизненный цикл ошибки/бага

Критерии классификации

Система отслеживания ошибок варьируется от общего назначения до конкретной цели. Общая система будет иметь множество функций, в то время как системы целевого назначения могут иметь ограниченные возможности. Подходящий инструмент может быть выбран на основе требований пользователя. Это требование обычно отличается от платформы, поддержки, размера, отчетности, отслеживания и других особенностей проекта. Эти широкие критерии могут быть далее классифицированы или классифицированы в три или более подкатегорий, как указано в таблице 1.

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

Таблица 1

Классификация критериев в различных категориях

Сравнительный анализ систем отслеживания ошибок(багтрекинговой системой)

Имеется множество систем отслеживания ошибок. Я выбрал наиболее популярное, наиболее используемое и все еще в процессе усовершенствования, то есть чей релиз продолжается, и ведутся работы по совершенствованию его функции и включению новых функций. В обзоре рассмотрены следующие инструменты: BugZilla [11], Jira [12], Trac [13], Mantis [14], GNats [15], BugTracker.Net [16] и Fossil [17].

Классификация на основе характеристик платформы

Критерии сравнения, основанные на характеристиках платформы, показаны в таблице 2. В этой таблице большинство этих инструментов доступны в среде с открытым исходным кодом. Mantis является приложением с открытым исходным кодом и его бесплатная версия доступна для загрузки и использования. Некоторые из инструментов доступны в качестве лицензионной версии, для которой поддержку можно получить у владельца. Платная версия Jira поставляется в трех разных вариантах: Standard, Professional и Enterprise, исходя из размера проекта и поддержки.

Большинство этих инструментов работают в веб-среде, в то время как их ранние версии были доступны как клиент-серверная среда. Trac разработан на вики-архитектуре, то есть любой может видеть ошибки, исправлять ошибки и редактировать любую его часть. Рабочая среда для большинства проектов является кросс-платформенной, то есть они могут быть установлены на любом компьютере. BugZilla и GNats доступны в Linux, в то время как BugTracker.Net доступен в среде Windows. Клиенты основаны на браузере, поэтому они не зависят от платформы. Для веб-сервера большинство инструментов требовали apache / tomcat, за исключением BugTracker.Net, для которого требуется MS-IIS. Большинство этих инструментов поддерживают MySQL как базу данных, за исключением BugTracker.net, для которой требуется MS-SQL Server, а Fossil требует SQLLite. Эти инструменты могут варьироваться в зависимости от языка программирования, используемого в кодировании. Инструменты разработаны на языках программирования C, Python, PHP, Perl, Java и C #.Net.

ошибка программный обеспечение платформа

Таблица 2

Сравнительный анализ функций, основанных на характеристиках платформ

Классификация на основе характеристик поддержки

Важным компонентом для сравнения инструментов являются функции поддержки, которые показаны в таблице 3. Общие характеристики для функций поддержки - это язык, веб-интерфейс, поддержка обслуживания, уведомление по электронной почте и локализация. Большинство инструментов поддерживают несколько языков на основе системы Unicode. Только Fossil и GNats не поддерживают несколько языков. Опять же в той же строке, большинство инструментов поддерживают веб-интерфейс. Люди более заинтересованы в использовании интерфейса на основе браузера, поскольку он не зависит от среды операционной системы. Fossil не имеет полного веб-интерфейса. Техническая поддержка также предоставляется бесплатно или с платной услугой с номинальной оплатой. Всякий раз, когда сообщается о новой ошибке или обновлении, электронное письмо автоматически отправляется всем пользователям, которые находятся в зарегистрированном списке рассылки с проектом. Это письмо также будет отправлено всем зарегистрированным пользователям, даже если есть небольшое обновление. Локализация ошибок, то есть поиск наиболее релевантной части иерархии исходных файлов программного обеспечения в базе данных хранилища ошибок, является еще одной важной функцией, предоставляемой BugZilla, Trac и Mantis, в то время как другие не имеют.

Таблица 3

Сравнительный анализ на основе характеристик поддержки

Классификация по видам отчетности

Другим важным компонентом является сообщение об ошибке в проекте. Это может быть сделано любым из этих методов, например, основанной на форме, электронной почтой, вложениями, веб (онлайн) и обратной связью. Это показано в таблице 4.

Таблица 4

Классификация на основе характеристик отчетности

BugZilla, Jira, Mantis и BugTraccker.Net имеют почти все средства отчетности, но Trac и Fossil отстают в приложениях и отчетах по электронной почте.

Классификация по признакам отслеживания

Функция отслеживания будет содержать подкатегории: своевременные обновления, графический дисплей и средство поиска. Большинство систем имеют эти функциональные возможности, как показано в таблице 5. Это может быть далее отнесено к еще одному уровню. Каждый раз, когда будут получены новые обновления, зарегистрированные участники получат по электронной почте уведомление об обновлениях, а также о новой версии системы. Графическое отображение - одна из очень важных функций, которые сообщают пользователю количество отложенных ошибок, количество открытых ошибок, количество закрытых ошибок, время, затраченное каждой ошибкой в форме интерактивных диаграмм, и расчетное время для устранения ошибки. Чтобы отслеживать ошибку, у инструментов есть средство для поиска ошибки, которая уже отправлена в систему. Это будет полезно при идентификации дублирующихся ошибок [4]. Продукт текущего дня должен иметь все эти объекты с динамическими графическими и графическими параметрами. Поисковый механизм также является одним из важных факторов. Как правило, системы имеют полнотекстовый поиск по названию, описанию и кратким отчетам об ошибках.

Таблица 5

Классификация по признакам отслеживания

Большинство систем могут предоставить средство поиска по любому из параметров, таких как идентификатор ошибки, степень серьезности, приоритет, время подачи, автор, кому назначена ошибка, номер назначения / истории назначения и т. д. Существует несколько параметров, на которых может быть обеспечено средство поиска. Jira имеет ограниченные параметры поиска параметров, но мощный. Mantis выводит результаты поиска в столбчатой диаграмме, чтобы показать прогресс конкретной ошибки.

Классификация по другим признакам

Любая другая функция может включать в себя гораздо больше функций, которые очень важны, но могут не иметь одну специальную категорию. Это локализация ошибок, предсказание изменений, просмотр репозитория исходного кода, контроль версий и средство Subversion. Некоторые из этих систем обладают возможностями этих функций, но они не являются развитыми.

В целом вышеупомянутые подкатегории могут быть дополнительно подразделены на отдельные подгруппы. Это позволит лучше представить систему отчетности и отслеживания ошибок. Это становится очень полезным при выборе инструмента, который будет соответствовать указанным пользователем критериям.

Выводы

В данной статье рассмотрены наиболее важные функции багтрекинговых систем и распределены по критериям. Знание основных и дополнительных функций позволит более подробно и главное безошибочно выбрать подходящую систему для определенного проекта или непосредственно для работы в группе разработчиков. В будущем, будет проведена работа над возможностью присвоения приоритета и числовой оценки к каждой функции, что позволит аргументировать выбор конкретными цифрами. Так же есть возможность автоматизировать оценивания и с помощью программы, и вывода информации в виде таблицы или диаграммы. Это позволит наглядно доказать выбор системы.

Библиографический список

1. J. Aranda and G. Venolia, “The secret life of bugs: Going past the errors and omissions in software repositories”, In ICSE'09 Proceedings of the 31st International Conference on Software Engineering, 2009.

2. N. Bettenburg, S. Just, A. Schrцter, C. Weiss, R. Premraj, and T. Zimmermann, “Quality of bug reports in Eclipse”, In eclipse'07, Proceedings of the 2007 OOPSLA workshop on eclipse technology eXchange, pages 21-25, 2007.

3. N. Bettenburg, S. Just, A. Schroter, C. Weiss, R. Premraj, and T. Zimmermann, “What makes a good bug report?”, In FSE'08: Proceedings of the 16th International Symposium on Foundations of Software Engineering, pages 308-318, November 2008.

4. N. Bettenburg, R. Premraj, T. Zimmermann, and S. Kim, “Duplicate bug reports considered harmful... really?”, In ICSM'08 Proceedings of the 24th IEEE International Conference on Software Maintenance, pages 337-345, 2008.

5. S. Breu, J. Sillito, R. Premraj, and T. Zimmermann, “Frequently asked questions in bug reports”, Technical report, University of Calgary, March 2009.

6. J. Anvik, L. Hiew, and G. C. Murphy, “Who should fix this bug?”, In ICSE'06 Proceedings of the 28th International Conference on Software engineering, pages 361-370, 2006.

7. P. Hooimeijer and W. Weimer, “Modeling bug report quality”, In ASE'07: Proceedings of the 22nd International Conference on Automated Software Engineering, pages 34-43, 2007.

8. S. Just, R. Premraj, and T. Zimmermann, “Towards the next generation of bug tracking systems”, In VL/HCC'08 Proceedings of the 2008 IEEE Symposium on Visual Languages and Human-Centric Computing, pages 82-85, September 2008.

9. “The Best Bug Tracking Software for 2015”, http://www.business-software.com/blog/best-bug-tracking-software/.

10. Trajkov Marko, Smiljkovic Aleksandar, “A Survey of Bug Tracking Tools: Presentation, Analysis and Trends”, aleksland.com/wp-content/uploads/2011/01/Survey.pdf, 2011.

Размещено на Allbest.ru