воскресенье
15:49
Deeptown Night
Ru Gb

Project blogs

Как правильно составить отчет об ошибке

Published by Дмитрий Роот on 17.02.2007

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

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

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

1. Как можно более подробно опишите, что и в какой последовательности Вы делали

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

2. Опишите симптомы ошибки

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

Опишите возникшие визуальные эффекты. Например, если клиент вылетел с ошибкой, то нам очень важно знать, как именно он это сделал. Вариантов может быть множество: окно может просто закрыться; Windows может предложить написать отчет об ошибке; может появиться окно с описанием ошибки графического движка; клиент может повиснуть и не реагировать на клавиатуру.

Кстати, о повисании клиента. Повисшим его стоит считать только в том случае, если в левом нижнем углу экрана не обновляется статистика. Если статистика обновляется - об этом нужно обязательно сообщить в отчете.

3. Вложите в очет логи и файлы конфигурации

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

  • error_log
  • event_log
  • Media\Ogre.log
  • Media\CEGUI.log
  • local_startup.dsh
  • Media\ogre.cfg

Больше никаких файлов вкладывать не нужно. Если Windows предложила отправить отчет об ошибке - не нужно отправлять этот отчет. Это лишняя трата времени и трафика.

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

4. Больше ничего писать не нужно

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

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

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

Примеры

Приведу два примера - правильного и неправильного отчета.

Пример хорошего отчета:

"Я запустил клиента. Через некоторое время мне было предложено ввести логин и пароль. Я прошел авторизацию, вошел. Увидел двух человек, идущих навстречу. Я попытался пойти вперед, нажав клавишу ВВЕРХ. В этот момент клиент повис: персонажи напротив остановились, статистика кадров не обновлялась, на ввод с клавиатуры и движение мыши он не реагировал. Я нажал ctrl+alt+del и снял задачу deep.exe."

В этом отчете - всего несколько строк, но они содержат только факты, которые и являются ценной информацией. С начала и до слова "ВВЕРХ" идет описание собственных действий. Такой подробности описания будет вполне достаточно. После - описание симптомов.

Пример плохого отчета:

"Я нажал клавишу ВВЕРХ, и графический движок повис. Мне пришлось прибить клиента из диспетчера задач."

И речь даже не о том, что этот отчет очень краток - мне просто было лень придумывать пример длинного неправильного отчета :). Я бы хотел обратить Ваше внимание на то, что из этих двух предложений ценной информацией являются только первые четыре слова - т.е. то, что какая-то ошибка произошла после нажатия клавиши ВВЕРХ. О том, произошло ли это в момент авторизации, в самый первый момент после появления, или же через некоторое время после входа - автор умалчивает. Информация о том, что повис графический движок - это не более чем нелепое предположение автора. Повисание клиента может произойти по тысяче причин. Так посудите сами, кто сможет дать лучшую оценку причины ошибки - разработчики, которые держат в голове весь код клиента, или автор отчета, который, возможно, видит клиентскую программу впервые? Так позвольте же разработчикам самим судить о причине ошибки, дав им для этого как можно больше ценной информации!

В заключение мне бы хотелось привести довольно неприятную статистику. Вчера было массовое тестирование, в котором участвовали по меньшей мере 10 человек. В процессе тестирования были выявлены ошибки - сервер зависал через некоторое время. После тестирования мы не получили ни одного отчета об ошибке! Ни мне на e-mail, ни в специально созданную для этого ветку форума. Итого - об этой ошибке мы вынуждены судить лишь по скудным логам сервера и не менее скундым логам общения участников тестирования в IRC. Представление об ошибке заключается лишь в том, что она "где-то есть". Ценность такого тестирования - ноль целых и ноль десятых.

Нам часто задают вопросы - "как помочь проекту? ну дайте же сделать хоть что-нибудь для проекта!". Как видите, решение - на поверхности: написав буквально 3-4 строчки, Вы можете сэкономить несколько часов, а то и дней, которые тратятся на поиск ошибки.

Please login or register to see comments