Лабораторная работа Сбор информации об ошибках
 Скачать 21.57 Kb.
|
|
Лабораторная работа № 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, программа аварий- но завершается и т. п.) Вложения (скриншоты, файлы журнала и пр.). Файлы, ко- торые могут помочь для понимания, воспроизведения, локализации и исправления дефекта. Контрольные вопросы Какие типы журналов можно просматривать средствами утилиты просмотра событий? Для чего предназначен каждый из них? Какие уровни событий предусмотрены в журнале? Какова структура отчета об ошибках? Что такое отчет об ошибках? 5. Каковы источники информации для создания отчета об ошибках? |