Сбор информации об ошибках формирование отчетов об ошибках практическая работа

С этим файлом связано 13 файл(ов). Среди них: 1062005 Отчёт по практике (5).docx, 1.docx, 3-1 ИСиП.docx, Гуров МДК 0101.2.docx, Каниськин 4-1кск жд озу.docx, _Лабораторная 04_2020.pdf, Практическая работа №5.docx, Кортяков 4.docx, pm_05_proektirovanie_i_razrabotka_informatsionnyh_sistem.docx, практические.docx, пр 4.docx, 3.docx, Развитие интереса к математике посредством тетрадей на печатной и ещё 3 файл(а).
Показать все связанные файлы

Подборка по базе: Лабораторная работа 8 (1).docx, Практическая работа к теме 1.2..docx, Практическая работа Шахова.DOCX, контрольная работа.docx, Самостоятельная работа № 1.docx, Контрольная работа по биологии 9 класс по теме_ _ Основы наследс, лабораторная работа по химии №2.docx, Курсовая работа. Пшидаток НД -31.docx, Самостоятельная работа №2.3.docx, Фролова А.С. Педагогика Самостоятельная работа 3.5..rtf

Лабораторная работа № 5. Сбор информации об ошибках

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

Для выполнения лабораторной работы № 5 студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах.
Понятие отчета об ошибках
Отчёт об ошибке (англ. error report или crash report) – это файл, содержащий техническую информацию об исключительной ситуа- ции (исключении), произошедшей в программе на компьютере пользователя.

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

системы и аппаратного обеспечения, а также цифровой код продукта, используемый для определения лицензии. Также пе- редается IP-адрес компьютера, поскольку для отправки отчета необходимо подключиться к сетевой службе. Отчеты об ошибках могут содержать данные файлов журналов, например, имена поль- зователей, IP-адреса, URL-адреса, имена файлов и пути к ним, а также адреса электронной почты. Отчеты об ошибках отправляются с использованием шифрования в базу данных с ограниченным до- ступом и не используются в каких-либо коммерческих целях.
Настройка параметров отбора событий
Можно настроить параметры сбора данных диагностики для ведения журнала событий. События можно регистрировать как в журнале событий Windows, так и журнале трассировки. Можно настроить параметры регулирования событий, чтобы задавать число
событий, регистрируемых в каждом журнале в соответствии с кри- тичностью события. Для расширения возможностей управления при регулировании событий можно задать регулирование всех событий или любой отдельной категории событий. Доступно несколько кате- горий событий в зависимости от служб и возможностей.

Категории событий могут определяться по отдельным служ- бам или по группам связанных событий. К категориям выбранных событий относятся:

• для всех;

• категории, определенные в соответствии с используемым продуктом, например, Office SharePoint Server 2007 или Microsoft Office Project Server 2007;

• административные функции, такие как «Администрирова- ние», «Резервное копирование и восстановление», и др.

Для выбранной категории устанавливается минимальный уро- вень критичности событий, которые следует регистрировать в жур- нале событий Windows и в журнале трассировки. В каждом журнале будут регистрироваться события этого или более высокого уровня критичности. Записи в этом списке сортируются в порядке от мак- симального уровня критичности к минимальному.

События журнала Windows могут иметь следующие уровни:

• не используется;

• error (ошибка);

• warning (предупреждение);

• не удалось выполнить аудит;

• успешное выполнение аудита;

• information (информация).

События журнала трассировки могут иметь следующие уровни:

• не используется;

• unexpected (непредвиденный);

• monitorable (контролируемый);

• high (высокая);

• medium (средняя);

• verbose (подробный).

Структура отчета об ошибке
ID (Идентификатор, Номер). 

Каждой записи в системе учета ошибок присваивается уникальный идентификатор или номер. Как правило, он задается самой системой по определенному шаблону. Это может быть просто числовой номер (1,2,3,…3487), а может быть идентификатор вида ПРОЕКТ-НОМЕР, например, TPO-2367, REG-335 и так далее.

Тип (Трекер). Системы управления задачами, как правило, содержат в себе записи различных типов – задача (Task), улучшение (Feature), баг (Bug), пользовательская история (User Story) и так да- лее. Для каждого типа может быть свой набор полей и свой жизнен- ный цикл.

Заголовок (Тема, Title). Краткое описание проблемы. Оно отображается в списках, результатах поиска, фильтрах и позволяет быстро понять, в чем суть проблемы. Оно не должно быть слишком коротким и общим, но одновременно и не должно быть слишком длинным. Существует мнемоническое правило для грамотного со- ставления описания «Что? Где? Когда?»: описание должно описы- вать, что именно сломалось, где сломалось и при каких условиях. Например, «Не работает поиск» – 

плохое описание ошибки, а «В форме поиска после отправки запроса выдается ошибка

«Internal Error» вместо результатов» – уже лучше.

Проект. Как правило, один большой продукт подразделяется на несколько проектов для более удобного управления, и в системе учета задач необходимо указать, к какому именно проекту относит- ся данная ошибка.

Версия. Версия продукта, в которой ошибка была обнаружена.

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

Приоритет (Priority). Приоритет показывает, с какой срочно- стью должен быть исправлен дефект.

Серьезность (Важность, Severity). Серьезность показывает степень влияния дефекта на систему.

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

Описание. Подробное описание проблемы. Иногда бывает од- но 

поле для описания проблемы, и тогда в нем нужно указать шаги для воспроизведения, фактический результат, ожидаемый резуль- тат. Иногда вместо этого поля могут быть 3 разных – для шагов, фактического и ожидаемого результатов.

Шаги для воспроизведения. Не всегда этот пункт выделяется как отдельное поле. Если его нет, то нужно шаги для воспроизведе- ния написать в поле «Описание».

Фактический результат. Должен быть обязательно – нужно указать, что мы получили в результате выполнения указанных шагов.

Ожидаемый результат. Необходимо указать, чтобы было по- нятно, как система должна работать. Если есть возможность, то необходимо давать ссылку на документацию, требования или иные документы, в которых описывается ожидаемое поведение системы. В некоторых случаях этот пункт можно опустить, 

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

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

Контрольные вопросы

1. Какие типы журналов можно просматривать средствами утилиты просмотра событий? Для чего предназначен каждый из них?

2. Какие уровни событий предусмотрены в журнале?

3. Какова структура отчета об ошибках?

4. Что такое отчет об ошибках?

5.
Каковы источники информации для создания отчета об ошибках?

Материалы

Презентация по теме «Организация сбора данных об ошибках в информационных системах. Источники сведений»

Скачать

Справочные материалы по теме «Организация сбора данных об ошибках в информационных системах, источники сведений»

Скачать

Теоретический материал по теме «Сбор информации об ошибках»

Скачать

Практическое задание по теме «Сбор информации об ошибках»

Скачать

Теоретический материал по теме «Формирование отчета об ошибках»

Скачать

Практическое задание по теме «Формирование отчета об ошибках системы»

Скачать

Отчеты об ошибках (на англ. «Bug
Report»)– это основной
материальный продукт тестирования,
надежная техническая документация,
которая описывает вид ошибки в тестируемой
системе.

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

Пример одной из свободных систем
отслеживания ошибок с веб-интерфейсом.
является Bugzilla (разработка
компании Mozilla). Данная
система очень проста и популярна в
использовании [10].

Подобная
система обеспечивает следующие функции:

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

• система
  уведомления о появлении новых ошибок,
  об изменении статуса известных в системе
  ошибок (как правило, это уведомления
  по электронной почте);

• отчеты
  об актуальных ошибках по компонентам
  системы, по интервалам времени, по
  группам разработчиков и разработчикам;

• информация
  об истории ошибки (в том числе отслеживание
  похожих ошибок, отслеживание повторного
  возникновения ошибки);

• правила
  доступа к ошибкам тех или иных категорий;

• интерфейс
  ограниченного доступа к системе bug
  tracking для конечного пользователя
  информационной системы, который
  используется как интерфейс обмена
  информацией между пользователем и
  службой технической поддержки системы.

Существуют основные виды продвижения
ошибки (на англ. «bug») по
системе (на англ. «Defect
flow»)(см. рисунок 6).

Рисунок 6 — Defect
flow

При поступление ошибки в систему, из
любого источника (заказчик, разработчик,
тестировщик), баг принимает статус new
(пер. с англ. «новый»). Затем рассматривается
программистом его описание и: или ошибка
решается (на англ. «resolve»)
или ей ставится статус duplicated
(пер. с англ. «дубль»), что означает, что
данная ошибка уже была и на данном этапе
решается, или же ей ставится статус
invalid (пер. с англ.
«необоснованный»)- неверное описание,
такой ошибки не существует. После всего
этого командой тестировщиков данная
ошибка перепроверяется и закрывается
(на англ. «verify») в случае,
если она больше не повторяется, или
переоткрывается (на англ. «reopen»), если
изменения все равно приводят к ошибке.

В отчете об ошибки необходимо соблюдать
некоторые правила:

1. В отчете должна быть с самого начала
понятна суть ошибки.

2.Должны быть четко понятны шаги
воспроизведения.

3.Должен быть известен альтернативный
правильный вариант поведения.

4. Указана версия и приоритет данной
ошибки.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

Почему важно сообщать об ошибках и кто это делает

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

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

Тестировщиком реально стать даже без опыта в IT. Для этого пройдите курс Skypro «Инженер по тестированию». Научитесь писать тестовую документацию и составлять отчеты, тестировать веб- и мобильные приложения и API, освоите нужные инструменты. Внутри — мастер-классы с реальными рабочими задачами, домашки и разборы от наставника. Создадите четыре проекта для портфолио и получите диплом гособразца.

Основные принципы

Правильные отчеты помогают программистам быстрее исправлять ошибки. Детали зависят от типа багов. Но есть несколько основных принципов — что и как включать в баг-репорт, чтобы заранее снять вопросы разработчиков.

Указывайте:

1️⃣ Только одну ошибку на отчет. Это золотое правило, потому что так гораздо проще исправлять баги. Легче отслеживать статус отдельных отчетов и выставлять приоритеты задач, распределять работу между несколькими разработчиками. Да и меньшее количество информации проще запомнить и проанализировать.

2️⃣ Место интерфейса программного обеспечения, в котором возникла ошибка. Опишите экран, на котором находитесь, состояние интерфейса. Включите URL-адрес страницы, если это веб-приложение.

3️⃣ Действия в программе. Пошагово опишите действия, которые выполняли перед тем, как столкнулись с ошибкой. Это важно: может оказаться, что некорректное поведение программы началось до того, как вы его заметили.

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

5️⃣ Скриншот или запись экрана с ошибкой. Есть риск ошибиться, когда пишешь отчет об ошибке. Это значительно усложнит работу команды разработки. Визуальные материалы — более точный способ указать на проблему, чем просто описать ее.

6️⃣ Техническую информацию. То есть вашу операционную систему, браузер, тип устройства — персональный компьютер, мобильный телефон или планшет. А еще тип устройства ввода — клавиатуру, мышь, сенсорный экран и прочее. Будут полезны и параметры монитора, чтобы исправить ошибки в отображении пользовательского интерфейса.

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

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

9️⃣ Пробовали ли исправить проблему. Есть причина, по которой айтишник всегда спрашивает: «Вы пробовали выключить и снова включить?» или «Пытались ли обновить веб-страницу?». Перезагрузка может быть простым способом исправить проблему. Если она не исчезает — это дает много информации. Укажите, и это сэкономит время на последующее обсуждение проблемы.

🔟 Насколько проблема влияет на работу. Обычно серьезность варьируется от очень высокой (полностью останавливает работу) до очень низкой (визуальные недочеты). Эта информация поможет командам разработчиков расставить приоритеты, определить порядок, в котором устранять ошибки.

Основные элементы

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

Обычно программисты и тестировщики договариваются, что и как указывать. Еще на это влияет система, в которой готовят отчет. Но есть общие компоненты баг-репорта:

👉 Резюме — краткое обозначение проблемы, причина и тип ошибки.

👉 Описание — подробности и любые сведения, которые помогут локализовать и исправить ошибку.

👉 Вложения — любые визуальные или другие материалы.

👉 Срок выполнения — если важно, чтобы ошибку исправили к определенной дате.

👉 Критичность — комментарий, насколько баг мешает нормальной работе приложения.

Часто выделяют следующие уровни критичности ошибок:

☝ Блокирующий (Blocker) — полностью блокирует нормальную работу программы, нужно исправить как можно быстрее.

☝ Критический (Critical) — сильно искажает логику приложения и значительно осложняет работу с ним.

☝ Значительный (Major) — затрагивает только отдельные элементы программы, существенно мешает работать.

☝ Незначительный (Minor) — либо не сильно влияет на работу программы, либо проявляется редко.

☝ Тривиальный (Trivial) — относится к визуальным недочетам в интерфейсе: опечатки, неудобные цвета и прочее.

Жизненный цикл

Порядок работы тоже зависит от соглашений в команде, системы управления. Но выделяют общие статусы отчета, которые встречаются практически везде:

💡 Новый — только создан, ждет проверки разработчиком.

💡 Принят — отчет проверили, проблему подтвердили.

💡 Отклонен — отчет проверили, но команда разработки отказалась работать по нему. Например, потому что ошибку не удалось повторить. Или то, что показалось ошибкой, — нормальное поведение программы. Или проблему уже устранили, когда работали над другим отчетом.

💡 Назначен — ошибку передали исполнителю.

💡 В работе — разработчик исправляет ошибку.

💡 Проверяется — исполнитель закончил работу, результат проверяет старший специалист.

💡 Закрыт — ошибку исправили, результат доступен пользователям.

Системы для отчетов об ошибках

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

Такие программы называют баг-трекерами. Чаще всего они — часть более сложных систем: управления проектами или исходным кодом приложения.

Системы управления проектами созданы, чтобы помочь контролировать разработку программы. Акцент в них сделан на планировании, отчетности и аудите. Такие системы чаще используют менеджеры проектов, тестировщики, разработчики в коммерческих продуктах.

К наиболее распространенным системам управления проектами относят:

• Jira.
• YouTrack.
• Redmine.

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

К основным системам управления исходным кодом относят:

• GitHub.
• GitLab.
• Bitbucket.

Интерфейсы и функции систем довольно сильно отличаются, но для работы с отчетами все предоставляют базовый набор функций:

✔️ форма создания отчета об ошибке с полями для ввода основных элементов;

✔️ управление состоянием и параметрами;

✔️ форма обсуждения, в которой команда задает вопросы и оставляет комментарии, указывает дополнительные детали;

✔️ уведомление об изменениях через имейл или другую систему обмена сообщениями.

У части баг-трекеров есть публичное голосование. Пользователи голосуют за или против бага: так повышают или понижают его приоритет.

Главное

• Баг-репорт — специальный вид отчета о неисправности в программном обеспечении или веб-сайте. Баг-репорт готовят тестировщики или специалисты из команды по контролю качества.
• Оформление баг-репорта сильно влияет на скорость, с которой исправят ошибки, на итоговый результат. Указывайте причину и тип ошибки, подробности, срок выполнения, критичность. Прикладывайте скриншоты или запись экрана.
• Прописывайте, пробовали ли исправить проблему, насколько она влияет на работу. Указывайте операционную систему, браузер, тип устройства, параметры монитора.
• Есть системы, с которыми проще создавать баг-репорты и управлять ими. Основные: Jira, YouTrack, Redmine, GitHub, GitLab, Bitbucket.