Системное программирование на тему: Системы отслеживания ошибок

Введение

Задача регистрации и обработки данных об ошибках, возникших при работе ПО, кажется простой лишь на первый взгляд. Дело в том, что еще до запуска сам программист может находить пачками ошибки в работе своей программы. От версии к версии количество известных ошибок может уменьшаться или увеличиваться. Для контроля ошибок был создан замечательный продукт - система отслеживания ошибок.Отслеживание найденных ошибок для исправления является увлекательной областью исследований в программном обеспечении. Многие открытые, бесплатные и коммерческие инструменты для отслеживания ошибок были разработаны и в настоящее время разрабатываются. Для организаций нужны критерии для выбора лучшего инструмента среди доступных наборов инструментов, которые помогут в фиксации и отслеживании прогресса исправления ошибок.В данной работе мы акцентируем наше внимание на системах отслеживания ошибок.Цель: выявить характеристики, присущие системам отслеживания ошибок.Задачи:1. Рассмотреть сущность понятия систем ошибок2. Определить критерии классификации систем ошибок3. Провести сравнительный анализ систем отслеживания ошибокГлава 1. Сущность понятия систем ошибокСистема отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги), найденные в программах, а также следить за процессом устранения этих ошибок. Так описаны в Wikipedia bug tracking system (далее BTS).BTS помогает программисту следить за ошибками. Когда вы замечаете ошибку, необходимо собрать о ней максимальное количество доступной информации. Необходимо быть предельно точным в наблюдениях. Особенно это касается отчетов об ошибках, приходящих от пользователей.Как правило, BTS позволяет хранить информацию об ошибке в следующем виде:кто сообщил о проблеме;дата и время, когда была обнаружена проблема;серьёзность проблемы;описание неправильного поведения программы;кто занимается устранением проблемы;состояние ошибки.Это минимальный набор требований к БД BTS, на самом же деле многие системы багтрэкинга позволяют вести намного более подробный учет ошибок. В чем то, они напоминают системы управления проектами. А многие из них интегрированы с такими системами.Необходимо заметить, что системы отслеживания ошибок могут быть полезны не только для программистов. Отчеты о «работе над ошибками» могут использовать менеджеры проекта. Фактически такие отчеты позволяют судить о производительности программистов, при работе по улучшению работы ПО. При обработке отчетов необходимо учитывать приоритет ошибок и сложность их устранения. Менеджер должен понимать, что некоторые ошибки могут быть трудно устранимы, в силу архитектуры системы. Бессмысленно требовать скорейшего устранения ошибок в системных модулях: непродуманные действия по устранению одной ошибки могут породить сотни других ошибок.Система отчетности / отслеживания ошибок должна предоставлять интерактивную веб-платформу для отчетности об ошибках и отслеживания прогресса. Система может включать в себя общий процесс или конкретный график обработки сообщений об ошибках. Процесс внесения информации об ошибке может, как правило, содержать следующие пункты:Title (Название)- Название ошибки.Description (Описание) - подробное описание ошибки, включая, что, где, почему, как и когда возникает ошибка. Фактическое сообщение, которое появляется во время операции, может быть включено с фактическим набором входных данных и ожидаемым выходом.Version (Версия) – версия проекта.Component (Компонент) – модуль программы, где найден баг.Screenshot/Attachment (Скриншот/приложение) - соответствующий снимок экрана также может быть загружен как.jpg или.gif файл, захватив фактическую операцию / вывод / сообщение.Priority (Приоритет) - приоритет может быть отнесен к его срочности.Severity (Серьезность) – степень влияния на систему.Status (Статус)- текущий статус ошибки (новый, открытый, подтвержденный, закрытый и т. д.).Created by (Автор) - Имя человека или идентификатор, уже зарегистрированного в системе, который сообщает об ошибке.Assigned to (Назначен) - тестировщик может назначить ошибку конкретному человеку, если известно о конкретном человеке, который может решить эту проблему, иначе назначает менеджер.Revision History (История изменения) – история изменения отчета.Estimated time (расчет времени) – время на исправление. Как правило, используется в случае закрытой рабочей команды, а не в среде с открытым исходным кодом.Comments (Комментарий) - любая другая информация, которая будет полезна при идентификации ошибки.Как только ошибка будет отправлена в систему, менеджер увидит ее статус и посмотрит детали отчета и его различные параметры. Менеджер также может сбросить или обновить некоторые параметры и соответственно обновить значения статуса и обладателя бага. В крупных проектах с открытым исходным кодом средняя скорость передачи сообщений об ошибках достаточно высока. Таким образом, менеджеру очень сложно просматривать каждую ошибку, а затем обновлять ее статус и присваивать ошибку определенному человеку. Хотя каждая система / инструмент имеет свой собственный жизненный цикл ошибки, здесь общий жизненный цикл ошибки (рисунок 1).Есть много систем отслеживания ошибок, доступных в отрасли для использования. Системы отслеживания ошибок также называются системой отслеживания проблем или багтрекером или системой отслеживания дефектов и т. Д. Системы отслеживания ошибок разрабатываются сообществом с открытым исходным кодом, а также организациями с закрытым кодом в качестве проприетарного программного обеспечения. Открытый исходный код означает, что исходный код предоставляется всем в соответствии с политикой GPL. Любой может внести свой вклад в код добровольно. В сообществах с закрытым исходным кодом исходный код является собственностью организации, и люди, которые не входят в проект, возможно, не смогут увидеть / просмотреть код. Некоторые из инструментов отслеживания ошибок принадлежат сообществам с открытым исходным кодом, а некоторые из них - сообществам с закрытым кодом или коммерческим организациям. Существуют организации, которые также могут предоставлять поддержку решений с открытым исходным кодом. Рисунок 1. Жизненный цикл ошибки/багаГлава 2. Критерии классификации систем ошибокСистема отслеживания ошибок варьируется от общего назначения до конкретной цели. Общая система будет иметь множество функций, в то время как системы целевого назначения могут иметь ограниченные возможности. Подходящий инструмент может быть выбран на основе требований пользователя. Это требование обычно отличается от платформы, поддержки, размера, отчетности, отслеживания и других особенностей проекта. Эти широкие критерии могут быть далее классифицированы или классифицированы в три или более подкатегорий, как указано в таблице 1.Платформа относится к политике лицензирования, архитектуре, операционной системе, веб-серверу, серверной базе данных, языку программирования и клиент. Поддержка относится к языку, нескольким проектам, веб-интерфейсу, базе данных, уведомлению по электронной почте и локализации. Отчетность относится к электронной почте, вложений, веб и обратной связи. Отслеживание относится к своевременному обновлению состоянию ошибки, графикам количества отложенных ошибок, назначенным, фиксированным в течение определенного периода времени в каждой категории и средствам поиска новых, а также существующих ошибок, чтобы узнать об их статусе. Другая особенность относится к любой другой функции, которая не является частью вышеупомянутых категорий.Таблица 1Классификация критериев в различных категорияхПлатформаПоддержкаОтчетностьОтслеживаниеДругая особенностьЛицензияАрхитектураОперационная системаВеб серверБаза данныхЯзык программированияКлиент ЯзыкНесколько проектовВеб-интерфейсБазе данныхУведомлению по электронной почтеЛокализация ФормаЭлектронная почтаВложениеВебОбратная связь 1.Своевременное обновление2.Графическое отображение3.Фильтрация Другая особенность, не подходящая под категорииГлава 3. Сравнительный анализ систем отслеживания ошибокИмеется множество систем отслеживания ошибок. Мы выбрали наиболее популярное, наиболее используемое и все еще в процессе усовершенствования, то есть чей релиз продолжается, и ведутся работы по совершенствованию его функции и включению новых функций. В обзоре рассмотрены следующие инструменты: BugZilla, Jira, Trac, Mantis, GNats, BugTracker.Net и Fossil.Классификация на основе характеристик платформы: Критерии сравнения, основанные на характеристиках платформы, показаны в таблице 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. Сравнительный анализ функций, основанных на характеристиках платформПриложениеПлатформаBugZillaJiraTracMantisGnatsBugTrack.NetFossilПлатформаОткрытый код/бесплатная/ патентованныйПатентованныйОткрытый код/бесплатнаяОткрытый код/ бесплатная/платнаяОткрытый код/бесплатнаяОткрытый кодОткрытый код/Архитектура системыКлиентский сервер/ веб-интерфейсКлиентский сервер/ веб-интерфейсВеб-интерфейсВеб-интерфейсВеб-интерфейсВеб-интерфейсDistributed web basedОС сервераLinuxКроссплатформеннаяКроссплатформеннаяКроссплатформеннаяLinuxWindowsLinux/Windows/MacOSВеб серверApache, MS-IISApache, TomcatApacheApache, MS-IISApacheMS-IISApache, MS-IISБаза данныхMySQL, Oracle, PostgreSQLВсе RDBMSMySQL, PostgreSQL, SQLiteMySQL, MS SQL, PostgreSQLMySQLMySQLSQLiteЯзык программированияTCL/PerlJavaPythonPHPCASP.NetCКлиент (веб браузер)ЛюбойЛюбойЛюбойЛюбойЛюбойЛюбойЛюбойКлассификация на основе характеристик поддержки: Важным компонентом для сравнения инструментов являются функции поддержки, которые показаны в таблице 3. Общие характеристики для функций поддержки — это язык, веб-интерфейс, поддержка обслуживания, уведомление по электронной почте и локализация. Большинство инструментов поддерживают несколько языков на основе системы Unicode. Только Fossil и GNats не поддерживают несколько языков. Опять же в той же строке, большинство инструментов поддерживают веб-интерфейс. Люди более заинтересованы в использовании интерфейса на основе браузера, поскольку он не зависит от среды операционной системы. Fossil не имеет полного веб-интерфейса. Техническая поддержка также предоставляется бесплатно или с платной услугой с номинальной оплатой. Всякий раз, когда сообщается о новой ошибке или обновлении, электронное письмо автоматически отправляется всем пользователям, которые находятся в зарегистрированном списке рассылки с проектом. Это письмо также будет отправлено всем зарегистрированным пользователям, даже если есть небольшое обновление. Локализация ошибок, то есть поиск наиболее релевантной части иерархии исходных файлов программного обеспечения в базе данных хранилища ошибок, является еще одной важной функцией, предоставляемой BugZilla, Trac и Mantis, в то время как другие не имеют.Таблица 3. Сравнительный анализ на основе характеристик поддержкиПриложениеПоддержкаBugZillaJiraTracMantisGnatsBugTrack.NetFossilПоддержка языкаДаДаДаДаНетДаНетВеб интерфейсДаДаДаДаДаДаНетТехническая поддержкаДаДаДаДаНетДа E-mail оповещениеДаДаДаДаДаДаНетЛокализация ошибокДаНетДаДаНетНетНетКлассификация по видам отчетности: Другим важным компонентом является сообщение об ошибке в проекте. Это может быть сделано любым из этих методов, например, основанной на форме, электронной почтой, вложениями, веб (онлайн) и обратной связью. Это показано в таблице 4.Таблица 4. Классификация на основе характеристик отчетностиПриложениеОповещениеBugZillaJiraTracMantisGnatsBugTrack.NetFossilФормаДаДаДаДаДаДаДаEmailДаДаНетДаДаДаНетВложениеДаДаНетДаДаДаНетWeb(онлайн)ДаДаДаДаДаДаДаОбратная связьДаДаДаДаДаДаДаBugZilla, Jira, Mantis и BugTraccker.Net имеют почти все средства отчетности, но Trac и Fossil отстают в приложениях и отчетах по электронной почте.Классификация по признакам отслеживания: Функция отслеживания будет содержать подкатегории: своевременные обновления, графический дисплей и средство поиска. Большинство систем имеют эти функциональные возможности, как показано в таблице 5. Это может быть далее отнесено к еще одному уровню. Каждый раз, когда будут получены новые обновления, зарегистрированные участники получат по электронной почте уведомление об обновлениях, а также о новой версии системы. Графическое отображение - одна из очень важных функций, которые сообщают пользователю количество отложенных ошибок, количество открытых ошибок, количество закрытых ошибок, время, затраченное каждой ошибкой в форме интерактивных диаграмм, и расчетное время для устранения ошибки. Чтобы отслеживать ошибку, у инструментов есть средство для поиска ошибки, которая уже отправлена в систему. Это будет полезно при идентификации дублирующихся ошибок. Продукт текущего дня должен иметь все эти объекты с динамическими графическими и графическими параметрами. Поисковый механизм также является одним из важных факторов. Как правило, системы имеют полнотекстовый поиск по названию, описанию и кратким отчетам об ошибках.Таблица 5. Классификация по признакам отслеживанияПриложениеОповещениеBugZillaJiraTracMantisGnatsBugTrack.NetFossilСвоевременное обновлениеДаДаДаДаДаДаДаГрафикиДаДаДаДаДаДаДаПоиск/фильтрацияДаДаДаДаДаДаДаБольшинство систем могут предоставить средство поиска по любому из параметров, таких как идентификатор ошибки, степень серьезности, приоритет, время подачи, автор, кому назначена ошибка, номер назначения / истории назначения и т. д. Существует несколько параметров, на которых может быть обеспечено средство поиска. Jira имеет ограниченные параметры поиска параметров, но мощный. Mantis выводит результаты поиска в столбчатой диаграмме, чтобы показать прогресс конкретной ошибки.Классификация по другим признакам: Любая другая функция может включать в себя гораздо больше функций, которые очень важны, но могут не иметь одну специальную категорию. Это локализация ошибок, предсказание изменений, просмотр репозитория исходного кода, контроль версий и средство Subversion. Некоторые из этих систем обладают возможностями этих функций, но они не являются развитыми.В целом вышеупомянутые подкатегории могут быть дополнительно подразделены на отдельные подгруппы. Это позволит лучше представить систему отчетности и отслеживания ошибок. Это становится очень полезным при выборе инструмента, который будет соответствовать указанным пользователем критериям.

Заключение

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

1. Быковский, М. А. Использование систем отслеживания ошибок (bug tracking systems) в образовательной среде / М. А. Быковский, Д. Б. Шадрин // Новые образовательные технологии в вузе: материалы XII международной научно-методической конференции (НОТВ-2015). – Екатеринбург: УрФУ. – 2015. – C. 113-115.2. Куликов С. Тестирование программного обеспечения/ И. С. Белюченко, О. А. Мельник. – EPAM Systems, 2015. – 157-162 с. 2.3. Изучение и анализ систем bug tracking’a // URL: https://www.gyrnal.ru/statyi/ru/1205/ (дата обращения: 17.05.2022).4. Махмутов, Р. Р., Давлеткиреева, Л. З. Развитие службы поддержки пользователей на основе внедрения системы Trackstudio Enterprise / Р. Р. Махмутов, Л. З. Давлеткиреева // Современная техника и технологии. – 2016. – С. 352-358.5. Описание системы мониторинга задач и отслеживания ошибок // URL: https://vuzlit.com/1025803/opisanie_sistemy_monitoringa_zadach_otslezhivaniya_oshibok (дата обращения: 17.05.2022).6. Топ-7 инструментов отслеживания ошибок 2022 Года // URL: https://xmldatafeed.com/top-7-instrumentov-otslezhivaniya-oshibok-bag-treking-sistem-2022-goda/ (дата обращения: 17.05.2022).