Зачем нужен отчет об ошибках

Зачем нужен хороший баг-репорт?

Если ваш отчет об ошибках (баг-репорт) составлен правильно, то шансы на быстрое исправление этих багов — выше. Таким образом, исправление ошибки зависит от того, насколько качественно вы о ней сообщите. Составление отчетов об ошибках — не что иное, как навык, и сейчас мы рассмотрим, как его сформировать.

«Смысл написания отчета о проблемах (баг-репорта) состоит в том, чтобы исправить эти проблемы» — Cem Kaner. Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима.

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

Каковы качества хорошего баг-репорта в разработке программного обеспечения?

Любой может написать баг-репорт. Но не каждый может написать эффективный бар-репорт.

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

Характеристики и методы включают в себя:

1) Наличие четко определенного номера ошибки:

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

2) Воспроизводимость:

Если найденная вами ошибка не воспроизводима, то она никогда не будет исправлена.

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

3) Будьте конкретны:

Не пишите очерк о проблеме.

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

Эффективный баг-репортинг

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

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

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

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

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

Четко указывайте информацию об ошибке: «Как?» и «Где?». Отчет должен ясно показывать, как был выполнен тест и где именно произошел дефект. Читатель отчета должен легко воспроизвести ошибку и найти ее.

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

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

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

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

Как сообщить об ошибке?

Используйте следующий простой шаблон баг-репорта:

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

Составитель отчета: Ваше имя и адрес электронной почты.

Продукт: В каком продукте вы нашли эту ошибку.

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

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

Платформа: 

Укажите аппаратную платформу, на которой вы обнаружили эту ошибку. Различные платформы, такие как «ПК», «MAC», «HP», «Sun» и т. д.

Операционная система: 

Укажите все операционные системы, в которых вы обнаружили ошибку. Операционные системы, такие как Windows, Linux, Unix, SunOS, Mac OS. Упомяните разные версии ОС, такие как Windows NT, Windows 2000, Windows XP и т. д., если это применимо.

Приоритет: 

Когда следует исправлять ошибку? Приоритет обычно устанавливается от P1 до P5. P1 следует понимать, как «исправить ошибку с наивысшим приоритетом» и P5 — «исправить, если позволяет время».

Серьезность ошибки:

Описывает влияние ошибки.

Типы Серьезности ошибки:

• Блокировщик (Blocker): дальнейшая работа по тестированию невозможна.
• Критическая (Critical): сбой приложения, потеря данных.
• Major: серьезная потеря функциональности.
• Minor: незначительная потеря функциональности.
• Незначительная (Trivial): некоторые улучшения пользовательского интерфейса.
• Улучшение (Enhancement): запрос новой функции или некоторого улучшения существующей.

Статус ошибки:

Когда вы регистрируете ошибку в любой системе отслеживания ошибок, то по умолчанию статус ошибки будет «Новый».

Позднее ошибка проходит через различные этапы, такие как «Исправлено», «Проверено», «Повторно открыто», «Не исправлено» и т. д.

Назначить разработчику:

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

URL:

URL страницы, на которой произошла ошибка.

Краткое резюме:

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

Описание:

Подробное описание ошибки.

Используйте следующие поля для поля описания:

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

Это важные шаги в отчете об ошибках. Вы также можете добавить «Тип отчета» как еще одно поле, которое будет описывать тип ошибки.

Видео курсы по схожей тематике:

Типы отчетов включают в себя:

1) Ошибка в коде
2) Ошибка проектирования
3) Новое предложение
4) Проблема с документацией
5) Аппаратная проблема

Важные фичи в вашем отчете об ошибках

Рассмотрим несколько составляющих отчета о найденном баге

Ниже приведены важные элементы баг-репорта:

1) Номер ошибки/идентификатор:

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

2) Наименование ошибки:

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

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

3) Приоритет:

В зависимости от серьезности ошибки, для нее может быть установлен приоритет. Ошибка может быть Blocker, Critical, Major, Minor, Trivial или предложением по улучшению функционала. Приоритет ошибки от P1 до P5 может быть задан так, чтобы важные из них просматривались первыми.

4) Платформа / Среда:

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

5) Описание:

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

Необходимо четко сообщить об эффекте в описании. Всегда полезно использовать полные предложения. Рекомендуется описывать каждую проблему отдельно, а не разрушать их полностью. Не используйте такие термины, как «я думаю» или «я считаю».

6) Шаги для воспроизведения ошибки:

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

Хороший пример правильно написанной пошаговой процедуры приведен ниже:

Последовательность шагов:

• Выберите продукт wer05.
• Нажмите на «Добавить в корзину».
• Нажмите «Удалить», чтобы удалить продукт из корзины.

7) Ожидаемый и фактический результат:

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

Скриншот:

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

Некоторые дополнительные советы, для написания хорошего баг-репорта

Ниже приведены некоторые дополнительные советы, чтобы написать хороший отчет об ошибке:

1) Немедленно сообщите о проблеме:

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

2) Воспроизведите ошибку три раза перед написанием баг-репорта:

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

3) Протестируйте эту же ошибку на других похожих модулях:

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

4) Составьте хорошее резюме ошибки:

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

5) Прочитайте несколько раз отчет об ошибке, прежде чем нажать кнопку «Отправить»:

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

Бесплатные вебинары по схожей тематике:

6) Не используйте оскорбительные выражения:

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

Заключение.

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

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

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

С нашей стороны для качественной подготовки тестировщиков, предлагаем вам ознакомиться с курсом подготовки специалиста-тестировщика на ITVDN — Quality Assurance

По материалам статьи

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

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

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

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

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

Тестировщиком реально стать даже без опыта в 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.

Отключение отчетов об ошибках в Windows 10, 8, 7, Vista и XP

Функция отчетов об ошибках в Windows – это то, что генерирует предупреждения после определенных ошибок в программе или операционной системе, предлагая вам отправить информацию о проблеме в Microsoft.

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

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

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

Отключить отчеты об ошибках в Windows 10

Не можете найти? Если меню Тип запуска недоступно, выйдите из системы и войдите в систему как администратор. Или откройте консоль управления службами с правами администратора, например, открыв командную строку с повышенными правами, а затем выполните команду services.msc.

Ещё один способ отключить отчеты об ошибках – через редактор реестра. Перейдите к разделу реестра, который вы видите ниже, и найдите значение с именем Disabled. Если он не существует, создайте новое значение DWORD с этим именем.

КомпьютерHKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsWindows Error Reporting

Отключите отчеты об ошибках в Windows 8 или Windows 7

Есть также возможность выбор программ для исключения из отчетов, которую вы можете использовать, если вы предпочитаете настраивать отчетность вместо того, чтобы полностью отключать её.

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

Источник

Для чего нужна служба «Windows Error Reporting» и как отключить ее в Windows 7, 8.1 и 10

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

Отключение Error Reporting в Windows 7 и 8.1

Откройте через окошко «Выполнить» ( Win + R ) Центр поддержки командой wscui.cpl апплет «Центр поддержки».

Нажмите в меню справа ссылку «Параметры центра поддержки».

На следующей странице нажмите ссылку «Параметры отчета о неполадках».

И активируйте радиокнопку «Не проверять на наличие новых решений».

Отключение Error Reporting в Windows 10

В Windows 10 опция «Параметры отчета о неполадках» была удалена из окна параметров центра поддержки, поэтому для отключения формирования отчетов о программных ошибках в этой версии системы придется действовать в обход.

Откройте через окошко «Выполнить» одноименной командой редактор реестра Regedit и раскройте ключ:

HKLMSOFTWAREMicrosoftWindowsWindows Error Reporting

Назовите его Disabled и задайте в качестве его значения единицу.

Сохраните настройки, закройте редактор реестра и перезагрузите компьютер.

Описание примера отключения функции Error Reporting через редактор групповых политик мы опускаем, поскольку его результат является эквивалентным применяемому твику реестра, к тому же редактор gpedit.msc доступен не всех редакциях Windows.

Универсальный способ отключения Error Reporting

Предложенный ниже способ является универсальным и одинаково работает в Windows 7, 8.1 и Windows 10.

Отыщите справа службу «Служба регистрации ошибок Windows», откройте ее свойства и выставьте параметры так, как показано на скриншоте после чего сохраните настройки.

Любители командной строки могут отключить ее через консоль.

Запустив командную строку или PowerShell от имени администратора и выполните в ней команду:

sc config wersvc start=disabled

gpupdate /force

Чтобы обновить политику без перезагрузки компьютера.

Источник

Windows problem reporting что это за программа

Служба Windows Error Reporting и очистка каталога WERReportQueue в Windows

Служба WER (Windows Error Reporting) служит для сбора и отправки отладочной информации о падении системных и сторонних приложений в Windows на сервера Microsoft. По задумке Microsoft, эта информация должна анализироваться и при наличии решения, вариант исправления проблемы должен отправляется пользователю через Windows Error Reporting Response. Но по факту мало кто пользуется этим функционалом, хотя Microsoft настойчиво оставляет службу сбора ошибок WER включенной по умолчанию во всех последних версиях Windows. В большинстве случае о службе WER вспоминают, когда каталог C:ProgramDataMicrosoftWindowsWERReportQueue начинает занимать на системном диске довольно много места (вплоть до нескольких десятков Гб).

Служба Windows Error Reporting

Служба Windows Error Reporting представляет собой отдельный сервис Windows, который можно легко отключить командой:

Внутри каталога WERReportQueue содержится множество каталогов, с именами в формате:

Как вы видите, имя каталога содержит степень критичности события и имя конкретного exe файла, который завершился аварийно. Во всех каталогах обязательно имеется файл Report.wer, который содержит описание ошибок и несколько файлов с дополнительной информацией.

Очистка папки WERReportQueue в Windows

Как правило, размер каждой папки незначителен, но в некоторых случаях для проблемного процесса генерируется дамп памяти, который занимает довольно много места. На скриншоте ниже видно, что размер файла дампа memory.hdmp составляет около 610 Мб. Парочка таким дампов – и на диске исчезло несколько свободных гигибайт.

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

Отключение Window Error Reporting в Windows Server 2012 R2 / 2008 R2

Отключить запись информации об ошибках Windows Error Reporting в серверных редакция Windows можно следующим образом:

Отключение функции сбора и отправки отчетов в Windows 10

Отключить Windows Error Reporting в Windows 10 можно через реестр. Для этого в ветке HKLMSOFTWAREMicrosoftWindowsWindows Error Reporting нужно создать новый параметр типа DWORD (32 бита) с именем Disabled и значением 1.

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

Отключение Windows Error Reporting через групповые политики

В результате сообщения об ошибках приложений в Windows перестанут формироваться и автоматически отправляться в Microsoft.

Система Windows Error Reporting

Система отчета об ошибках Windows Error Reporting (WER) является сложным механизмом, автоматизирующим представление сбоев процессов пользовательского режима и режима системных сбоев.

Когда фильтр необработанных исключений, упомянутый в предыдущем разделе, отлавливает такое исключение, он создает контекстную информацию (например, текущее значение регистров и стека) и открывает подключение ALPC-порта к WER-службе. Эта служба приступает к анализу состояния аварийной программы и выполняет соответствующие действия по уведомлению пользователя. Во многих случаях это означает запуск программы WerFault.exe, которая выполняется с полномочиями текущего пользователя, и пока система не настроена на обратное, выводит окно сообщения, информирующее пользователя об аварии. На системах с установленным отладчиком показаны дополнительные возможности по отладке показанного процесса, что можно увидеть на рисунке.

При щелчке на пункте отладки (Debug) будет запущен отладчик (зарегистрированный в строке Debugger, рассмотренном ранее параметре AeDebug), чтобы подключиться к аварийному процессу.

Диалоговое окно Windows Error Reporting.

На системах с исходными настройками отчет об ошибке (мини-дамп и XML-файл с различными подробностями, например, с номерами версий DLL-библиотек, загруженных в процессе) отправляется на интернет-сервер Microsoft, занимающийся анализом аварийных ситуаций. Затем, когда служба уведомляется о решении для проблемы, она выводит подсказку, информирующую пользователя о его действиях, которые нужно выполнить для решения проблемы.

Входящее сообщение будет также отображено в Центре поддержки. Кроме того, в Мониторе стабильности системы (ReliabilityMonitor) будут также показаны все экземпляры аварий приложений и системы.

ПРИМЕЧАНИЕ. WER будет активно (визуально) информировать пользователя аварийного приложения только в том случае, когда приложение имеет как минимум одно видимое интерактивное окно. В противном случае авария будет занесена в журнал, но пользователю придется вручную зайти в Центр поддержки для просмотра соответствующей записи. Такое поведение призвано избавить пользователя от путаницы, не выводя диалогового окна WER, относящегося к невидимым аварийным процессам, о которых пользователь может не знать, например, о службе, выполняемой в фоновом режиме.

В окружениях, где системы не подключены к Интернету или где администратор хочет контролировать, какие именно отчеты об ошибках будут представлены Microsoft, место назначения отчета об ошибках может быть настроено на внутренний файловый сервер. Средство MicrosoftSystemCenterDesktopErrorMonitoringпонимает структуру каталогов, созданных WindowsErrorReporting, и предоставляет администратору возможность получить избирательные отчеты об ошибках и отправить их компании Microsoft.

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

WER содержит множество настраиваемых параметров, к которым пользователь может получить доступ через редактор групповой политики (Group Policy) или внося изменения в реестр вручную. В таблице представлен список вариантов настройки WER в реестре, показано их использование и возможные значения.

Эти значения находятся в подразделе HKLMSOFTWAREMicrosoftWindows Windows Error Reporting для настроек компьютера и в аналогичном пути в разделе HKEY_CURRENT_USER для настройки для каждого пользователя.

Настройки WER в реестре.

Настройка	Смысл	Значение
ConfigureArchive	Содержание архивных данных	1 — для параметров, 2 — для всех данных
ConsentDefaultConsent	Какие данные должны требовать согласия	1— для любых данных, 2 — только для параметров, 3 — для параметров и безопасных данных, 4 — для всех данных.
ConsentDefaultOverrideBehavior	Должен ли DefaultConsent замещать значения согласия дополнительного модуля WER	1 — для разрешения замещения
ConsentPluginName	Значение согласия для конкретного дополнительного модуля WER	То же самое, что и для DefaultConsent
CorporateWERDirectory	Каталог для общего хранилища WER	Строка, содержащая путь
CorporateWERPortNumber	Порт, используемый для общего хранилища WER	Номер порта
CorporateWERServer	Имя, используемое для общего хранилища WER	Строка, содержащая имя
CorporateWERUseAuthentication	Использование для общего хранилища WER встроенной аутентификации Windows (Windows Integrated Authentication)	1— для разрешения встроенной аутентификации
CorporateWERUseSSL	Использование для общего хранилища WER протокола защищенных сокетов (SSL)	1 — для разрешения SSL
DebugApplications	Список приложений, требующих от пользователя выбора между отладкой (Debug) и продолжением (Continue)	1— для предоставления пользователю возможности выбора
DisableArchive	Включен ли архив	1 — для выключения архива
Disabled	Выключена ли служба WER	1 — для выключения WER
DisableQueue	Определение необходимости постановки отчетов в очередь	1 — для выключения очереди
DontShowUI	Выключение или включение WER UI	1 — для выключения UI
DontSendAdditionalData	Предотвращение отправки дополнительных данных об аварии	1 — не отправлять
ExcludedApplicationsAppName	Список приложений, исключенных из WER	Строка, содержащая список приложений
ForceQueue	Нужно ли отчеты отправлять в очередь пользователя	1 — для отправки отчетов в очередь
LocalDumpsDumpFolder	Путь, который нужно использовать для хранения дапм-файлов	Строка, содержащая путь
LocalDumpsDumpCount	Максимальное количество дапм-файлов в пути	Счетчик
LocalDumpsDumpType	Тип дампа, генерируемого при аварии	0 — для специального дампа, 1 — для мини-дампа, 2 — для полного дампа
LocalDumpsCustomDumpFlags	Для специальных дампов, указывает их специализацию	Значения, определенные в MINIDUMP_TYPE
LoggingDisabled	Включение или выключение ведения журнала	1 — для выключения ведения журнала
MaxArchiveCount	Максимальный размер архива (в файлах)	Значение в диапазоне 1–5000
MaxQueueCount	Максимальный размер очереди	Значение в диапазоне 1–500
QueuePesterInterval	Дни между запросами, чтобы пользователь мог проверить решения	Количество дней

ПРИМЕЧАНИЕ. Значения, перечисленные в параметре LocalDumps, могут также быть настроены для каждого приложения путем добавления имени приложения в пути подраздела между LocalDumps и соответствующим значением. Но они не могут быть настроены для каждого пользователя, поскольку существуют только в пути HKLM.

Как уже говорилось, для связи с аварийными процессами служба WER использует ALPC-порт. Этот механизм использует общесистемный порт ошибки, который служба WER регистрирует через функцию NtSetInformationProcess (использующую DbgkRegisterErrorPort). В результате все процессы Windows теперь имеют порт ошибки, который на самом деле является объектом ALPC-порта, зарегистрированным службой WER. Ядро, которое уведомляется об исключении в первую очередь, использует этот порт для отправки сообщения службе WER, которая затем анализирует аварийный процесс.

Служба Windows Error Reporting и очистка каталога WERReportQueue в Windows

Служба WER (Windows Error Reporting) служит для сбора и отправки отладочной информации о падении системных и сторонних приложений в Windows на сервера Microsoft. По задумке Microsoft, эта информация должна анализироваться и при наличии решения, вариант исправления проблемы должен отправляется пользователю через Windows Error Reporting Response. Но по факту мало кто пользуется этим функционалом, хотя Microsoft настойчиво оставляет службу сбора ошибок WER включенной по умолчанию во всех последних версиях Windows. В большинстве случае о службе WER вспоминают, когда каталог C:ProgramDataMicrosoftWindowsWERRep ortQueue
или
c:UsersAll UsersMicrosoftWindowsWERReportQueue
начинает занимать на системном диске довольно много места (вплоть до нескольких десятков Гб), даже не смотря на то что на этом каталоге по умолчанию включена NTFS компрессия.

Служба Windows Error Reporting

Служба Windows Error Reporting представляет собой отдельный сервис Windows, который можно легко отключить командой:

net stop WerSvc

Внутри каталога WERReportQueue содержится множество каталогов, с именами в формате:

Как вы видите, имя каталога содержит степень критичности события и имя конкретного exe файла, который завершился аварийно. Во всех каталогах обязательно имеется файл Report.wer, который содержит описание ошибок и несколько файлов с дополнительной информацией.

Очистка папки WERReportQueue в Windows

Как правило, размер каждой папки незначителен, но в некоторых случаях для проблемного процесса генерируется дамп памяти, который занимает довольно много места. На скриншоте ниже видно, что размер файла дампа memory.hdmp составляет около 610 Мб. Парочка таким дампов – и на диске исчезло несколько свободных гигибайт.

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

Отключение Window Error Reporting в Windows Server 2012 R2 / 2008 R2

Отключить запись информации об ошибках Windows Error Reporting в серверных редакция Windows можно следующим образом:

Windows Server 2008 R2 – откройте консоль Server Manager и промотайте список, перейдя в раздел Resources and Support. Нажмите на Turn Off Windows Error Reporting и выберите пункт I don’t want to participate, and don’t ask me again.

Отключение функции сбора и отправки отчетов в Windows 10

Отключить Windows Error Reporting в Windows 10 можно через реестр. Для этого в ветке HKLMSOFTWAREMicrosoftWindowsWindows Error Reporting нужно создать новый параметр типа DWORD (32 бита) с именем Disabled и значением 1.

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

Отключение Windows Error Reporting через групповые политики

В результате сообщения об ошибках приложений в Windows перестанут формироваться и автоматически отправляться в Microsoft.

Windows problem reporting что это за программа?

Отчеты об ошибках Windows 7 ‹ Windows 7 — Впечатления и факты

Если вы не хотите, чтобы информация об ошибках операционной системы и установленных программ сохранялась на компьютере и отправлялась в Microsoft, то вы можете настроить параметры сохранения и отправки отчетов об ошибках Windows 7.

Параметры отправки отчетов об ошибках и поиска решений проблем можно настроить двумя способами:

Важно: после изменения настроек отчетов об ошибках вы не сможете получать информацию о решении проблем в Центре поддержки Windows 7. Изменяйте эти настройки только если вы точно знаете, зачем вам это нужно.

Настройка отчетов об ошибках с помощью Центра поддержки Windows 7

1. Откройте Панель управления > Центр поддержки.

2. Нажмите Обслуживание > Параметры.

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

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

Чтобы настроить отправку отчетов об ошибках для всех пользователей компьютера, войдите в Windows 7 как администратор, откройте Панель управления > Центр поддержки > Обслуживание > Параметры и нажмите Изменить параметры отчетов для всех пользователей.

Настройка отчетов об ошибках с помощью Редактора локальной групповой политики

Поскольку редактор локальной групповой политики присутствует не во всех версиях Windows 7, данный способ может быть применен только в Windows 7 Профессиональная, Windows 7 Максимальная и Windows 7 Корпоративная.

Важно: настройки, заданные в Редакторе локальной групповой политики, имеют более высокий приоритет, чем настройки, заданные в Центре поддержки.

1. Войдите в Windows 7 с правами администратора.

2. Откройте меню Пуск, введите в поисковую строку gpedit.msc и нажмите Ввод.

4. Выполните одно или несколько действий:

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

Чтобы отключить отправку отчетов об ошибках, дважды щелкните пункт Отключить отчеты об ошибках Windows, выберите Включить и нажмите ОК. Если этот параметр включен, то в случае обнаружения ошибок, Windows 7 не будет отправлять информацию о них в Microsoft. Однако и вы не сможете получать информацию о решениях проблем через Центр поддержки.

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

Почему Microsoft вас не слушает, и можно ли что-нибудь сделать с этим

В негативной реакции на Windows 8 красной нитью проходит крик души «Microsoft нас не слушает!». Действительно, кто положительно ответит на вопрос, можно ли убрать кнопку «Пуск»? Сегодня я хочу поговорить о том, что можно сделать, чтобы Microsoft вас услышала.

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

Показательным примером является разделение результатов поиска, о котором негативно высказались многие энтузиасты Windows, включая меня. А вы знаете, как Microsoft обосновала свое решение?

Зачем Microsoft нужна телеметрия

Пример с поиском характерен, поскольку на начальном экране можно было реализовать отображение результатов во всех категориях сразу. И тут Microsoft задается вопросом: «Кому это вообще нужно?».

Чтобы составить четкое представление о том, какими возможностями Windows мы пользуемся и каким именно образом, Microsoft нужны данные телеметрии — сведения о нашей с вами работе в Windows, полученные дистанционно.

Разработчики обращаются к ним и видят, что 67% пользователей Windows 7 ищут в меню «Пуск» приложения, 22% — файлы, и лишь 9% идут туда за элементами панели управления.

Кто все эти люди? Полагаю, что эти пользователи достаточно опытные, чтобы найти и включить параметры отправки телеметрии, понимать их важность для Microsoft и не верить в теорию заговора.

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

«Ага», — думают в Microsoft, — «значит, можно убрать отображение элементов панели управления в основных результатах поиска, тем более что с появлением Metro фокус у нас еще сильнее смещается в сторону приложений!». Да, гики будут недовольны, но они же достаточно опытны, чтобы выучить специально сделанное для них сочетание клавиш Win + W.

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

Программа улучшения качества программного обеспечения

В Windows встроена программа улучшения качества программного обеспечения (Customer Experience Improvement Program, CEIP). Заметьте, что ее оригинальное название фокусируется на улучшении пользовательского опыта клиентов, т.е. нас с вами.

Изначально эта программа всегда отключена, и если передача данных в Microsoft противоречит вашим принципам, компания не узнает о том, как вы используете Windows.

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

Безусловно, при отправке сведений о вашей системе и работе в ней нужно учитывать вопросы конфиденциальности. На рисунке выше вы видите ссылку на заявление о конфиденциальности. Я оставляю его прочтение на ваше усмотрение, но отмечу, что в данном случае Microsoft не собирает сведения, позволяющие идентифицировать вас как личность.

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

Отправка отчетов о неполадках

Мы хотим видеть Windows не только удобной, но и стабильной. Исходя из информации в MSDN, на платформе Windows:

Вторым компонентом телеметрии являются отчеты о неполадках, работающие в рамках технологии Windows Error Reporting (WER).

С ее помощью собираются сведения об ошибках системы, драйверов и приложений и передаются в Microsoft.

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

На рисунке вы видите графическое представление отчетов, хранящихся в папке %ProgramData%MicrosoftWindowsWER.

Обратите внимание, что некоторые отчеты не были отправлены ввиду отсутствия дополнительных сведений. Это не случайно!

Какие данные считаются конфиденциальными

В центре поддержке можно выполнить поиск решений и одновременно с этим отправить «застрявшие» отчеты.

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

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

Кто получает доступ к отправленным отчетам

Microsoft делится информацией с разработчиками программного и аппаратного обеспечения посредством специального сайта SysDev. Причем участие в этой программе обязательно, чтобы пройти сертификацию на совместимость ПО с операционной системой.

На основе этих сведений Microsoft и партнеры могут делать выводы о конфликтах программ и драйверов, а при достижении некой критической отметки выпускать:

Любопытно, что Microsoft может сама заниматься отладкой отчетов, полученных в результате ошибок сторонних приложений и драйверов. Это происходит в том случае, когда партнер вступил в программу получения отчетов, но не утруждает себя исправлением ошибок. Об этом рассказывал в своем блоге Рэймонд Чен в контексте бета-тестирования Windows 7.

Какой нам смысл отправлять отчеты

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

В моей практике был случай, когда старый ноутбук начал падать в BSOD после обновления драйвера видеокарты NVIDIA. Драйвер я, конечно, откатил и забыл про это. Но спустя какое-то время в центре поддержки появилось уведомление о том, что проблема решена в новой версии драйвера. Выглядело это примерно так:

Главный смысл Windows Error Reporting в том, что каждый отправленный вами отчет голосует за исправление этой ошибки. Поэтому, если вы хотите, чтобы возникающие у вас ошибки исправляли, не отключайте автоматическую отправку отчетов!

Отзывы о приложениях Metro

В предварительных версиях Windows 8 у приложений Metro, созданных Microsoft, есть возможность отправки отзывов.

Неизвестно, будет ли она присутствовать после выхода финальной версии, но пока этим можно пользоваться для:

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

Сообщения о багах и пожелания к продуктам Microsoft

У Microsoft есть несколько каналов, по которым вы можете доставлять сообщения о найденных ошибках и свои пожелания.

Microsoft Connect

С помощью Microsoft Connect можно отправлять баги и/или пожелания по всем продуктам компании, для которых в данный момент открыта обратная связь.

Впрочем, далеко не для каждого продукта такая возможность предоставляется широкой публике, и в случае с Windows 8 ее не было. Еще одним «ограничением» является необходимость отправки сообщений на английском языке.

На момент написания статьи для отправки отзывов и багов по Windows 8 и IE10 можно использовать Windows Send Feedback Tool. Чтобы получить его, нужно вступить в программу тестирования IE10.

Форумы Microsoft Answers

Нетрудно догадаться, что форумы TechNet ориентированы на ИТ-специалистов, а форумы Answers – на домашних пользователей. Менее явное отличие между ними заключается в том, что форумы Answers представляют собой первую линию официальной технической поддержки Microsoft.

Среди модераторов форумов Answers есть инженеры Microsoft, в обязанности которых входит не только поддержание порядка, но и ответы на вопросы участников. Answers являются официальным каналом для сообщений об ошибках и пожеланиям к продуктам Microsoft.

Адреса русских форумов:

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

Опрос и дискуссия

Я участвую в программе улучшения качества ПО, высылаю отчеты об ошибках приложений Microsoft и драйверов, а также отправил с десяток пожеланий и багов по приложениям Metro. При этом я крайне редко отправляю баги посредством Microsoft Connect и никогда не делал это на форумах Answers.

Предположу, что поднятая тема вызовет болезненную реакцию у ряда читателей 🙂 Поэтому я хочу расставить точки над i и подчеркнуть смысл, который я вкладываю в эту запись.

Решение об использовании того или иного способа отправки сведений в Microsoft – это ваш выбор, который должен быть полностью осознан и лишен предрассудков.

Microsoft Windows 7: рекомендации по улучшению стабильности приложений. Часть 4. Механизм Windows Error Reporting

Механизм Windows Error Reporting

Использование механизма Windows Error Reporting

В предыдущей статье данного цикла, посвященной механизму Application Restart and Recovery, мы упомянули механизм Windows Error Reporting (WER). О нем и пойдет речь в настоящей статье данного цикла

В предыдущей статье данного цикла, посвященной механизму Application Restart and Recovery, мы упомянули механизм Windows Error Reporting (WER). О нем и пойдет речь в настоящей статье данного цикла.

Механизм Windows Error Reporting

С помощью механизма Windows Error Reporting (WER) можно собирать данные об ошибках, происходящих в приложениях, и либо отсылать эту информацию на специальный сайт Microsoft (сайт http://winqal.microsoft.com), либо сохранять ее локально. Сбор детальной информации об ошибках и сбоях помогает в устранении недостатков приложений, коррекции ошибок, упрощает выпуск пакетов обновлений и новых версий приложений, обеспечивает общую стабильность и надежность как самих приложений, так и операционной системы.

Отметим, что компания Microsoft сама активно использует механизм Windows Error Reporting как в процессе разработки, так и после выпуска продуктов на рынок. Так, продуктовая группа Microsoft Office исправила 50% ошибок в Office Service Pacl 2, продуктовая группа Visual Studio — 74% ошибок в Beta 1 Visual Studio 2005, 29% ошибок в Windows XP было исправлено в Windows XP Service Pack 1. В настоящее время более 2 тыс. компаний применяют сервисы Windows Error Reporting для улучшения качества своих приложений.

Механизм Windows Error Reporting впервые появился в Windows XP, был существенно расширен в Windows Vista и получил дальнейшее развитие в Windows Server 2008, Vista Service Pack 1 и Windows 7 и Windows Server 2008 R2. Так, на уровне Windows Vista у разработчиков появилась возможность не только получать информацию о сбоях, произошедших в приложениях, но и данные о производительности.

Теперь можно более гибко создавать, настраивать и отсылать отчеты о проблемах, улучшились средства онлайнового анализа данных и упростился механизм коммуникаций с пользователями — через механизм Problem Reports and Solutions (в Windows Vista — Start —> Control Panel —> System and Maintenance —> Problem Reports and Solutions —> View Problem History) и Action Center (в Windows 7).

Затем в Windows Server 2008 и Vista Service Pack 1 появилась возможность создания локальных дампов, а в Windows 7 и Windows Server 2008 R2 добавлена возможность генерации исключений, которые не будут обрабатываться традиционными обработчиками и будут приводить к немедленному завершению приложения и автоматическому запуску механизма Windows Error Reporting, а также возможность задания внешнего процесса — обработчика исключений, который будет вызываться для получения названия события, параметров отчета об ошибке и опционального запуска отладчика.

Использование механизма Windows Error Reporting

Давайте кратко рассмотрим, как разработчики могут применять механизм Windows Error Reporting для получения информации о сбоях и других проблемах со своими приложениями. Начиная с Windows Vista Windows по умолчанию предоставляет отчет о сбоях, зависаниях и ошибках уровня ядра операционной системы (kernel faults) для всех приложений — внесения изменений в код приложений не требуется.

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

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

В случае возникновения сбоев, зависаний или ошибок уровня ядра операционной системы механизм Windows Error Reporting выполняет следующую последовательность действий:

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

В приложении могут использоваться перечисленные ниже функции для настройки содержимого отчета, посылаемого в Microsoft, — регистрационная функция указывает Web на необходимость включения в создаваемый отчет указанных файлов и блоков памяти.

Для включения в состав отчета файла применяется функция WerRegisterFile(), которой в качестве параметров передаются: полное имя файла, его тип (одно из значений WER_REGISTER_FILE_TYPE) и два флага: WER_DELETE_FILE_WHEN_DONE, указывающий на то, что файл должен быть удален после отсылки отчета, и WER_ANONYMOUS_ DATA, указывающий на то, что в файле не содержатся приватные данные. Возможные значения параметра WER_REGISTER_FILE_ TYPE приведены в табл. 2.

Отметим, что задача генерации дампа памяти возлагается на разработчика приложения — для ее решения можно применять, например, отладочные механизмы, описанные в Windows SDK (см. функцию MiniDumpWriteDump()).

Для исключения файла из отчета следует использовать функцию WerUnRegisterFile(), указав ей в качестве параметра имя исключаемого файла.

В большинстве сценариев отсылка дополнительных файлов происходит только при получении от сервера соответствующего запроса. В случае отсылки дополнительных файлов необходимо применять флаг WER_ADD_ REGISTERED_DATA при вызове функции WerReportSubmit() — о ней мы расскажем далее.

Для включения в состав отчета копии области памяти применяется функция WerRegisterMemoryBlock(), в качестве параметров которой передаются адрес начала включаемого блока памяти и размер этого блока в байтах (максимальный размер блока памяти — WER_MAX_MEM_BLOCK_SIZE). Для отмены включения копии области памяти в отчет следует применять функцию WerUnRegisterMemoryBlock(). В случае отсылки данных из памяти необходимо использовать флаг WER_ADD_REGISTERED_DATA при вызове функции WerReportSubmit().

Функции WerSetFlags() и WerGetFlags() могут применяться соответственно для управления состоянием процесса в момент генерации отчета об ошибках и получения информации о настройках.

Процесс генерации и отсылки отчета состоит из нескольких шагов. Инициализация отчета выполняется вызовом функции WerReportCreate(), с помощью которой указывается тип события, для которого создается отчет, тип отчета (WerReportNonCritical — для сбоев с возможностью восстановления и WerReportCritical — для сбоев, повлекших аварийное завершение приложения), ссылка на информацию, включаемую в отчет (см. структуру WER_REPORT_INFORMATION), и переменная, которая будет содержать ссылку на созданный отчет, — ReportHandle.

После того как отчет успешно инициализирован, необходимо добавить в него парамет­ры первой и второй групп. Параметры первой группы задаются с помощью функции WerReport-Set-Parameter(), которой передается ссылка на созданный отчет (результат успешного выполнения функции WerReportCreate), набор флагов, имя параметра и его значение (16-битная строка в Unicode, заканчивающаяся нулем).

Для включения в состав отчета дополнительных параметров применяется функция WerReportAddSecondaryParameter(), которой передается ссылка на отчет, имя параметра и его значение.

Помимо возможности включения в состав отчетов файлов и снимков областей памяти, предусмотрена передача в составе отчета и дампов памяти — для этого можно использовать функцию WerReportAddDump(), в качестве параметров которой указываются ссылка на отчет, ссылки на процесс и поток, для которых был создан дамп, тип дампа (одно из значений WER_DUMP_TYPE), информация об исключении (указатель на структуру типа WER_EXCEPTION_INFORMATION), дополнительные опции (тип данных WER_DUMP_CUSTOM_OPTIONS) и флаги. Отметим, что процесс, для которого создается дамп, должен иметь права доступа STANDARD_RIGHTS_READ и PROCESS_QUERY_INFORMATION.

Для включения в состав отчета файлов мы применяем функцию WerReportAddFile(), которой передаем ссылку на отчет, полное имя файла, тип файла (WER_FILE_ TYPE) и дополнительные флаги.

Помимо этого разработчикам предоставляется возможность настройки пользовательского интерфейса — выбора информации, отображаемой в системной диалоговой панели. Для этих целей служит функция WerReportSetUI Option(), которой передается ссылка на отчет, тип интерфейса отчета (WER_REPORT_UI) и значение отображаемой строки. Приложение может модифицировать любое из полей интерфейсного элемента, заданного параметром WER_REPORT_UI; каждый вызов функции позволяет модифицировать только одно поле. Функция WerReportSetUIOption() может вызываться в любой момент работы приложения до непосредственной отсылки отчета.

После того как отчет сформирован и настроен, мы используем функцию WerReportSubmit() для отсылки отчета. В качестве параметров этой функции передаются ссылка на отчет, тип пользовательского интерфейса (наличие прав администратора, подтверждение отсылки и т.п.) и набор флагов. После того как отчет послан, следует закрыть ссылку на него, используя функцию WerReportCloseHandle().

Для отключения приложения от механизма Windows Error Reporting следует использовать функцию WerAddExcludedApplication(), а для повторного подключения — функцию WerRemoveExcludedApplication().

Настройки Windows Error Reporting располагаются в двух ветвях реестра:

Наиболее полезные настройки показаны в табл. 3.

Заключение

В данном цикле статей мы обсудили различные вопросы улучшения стабильности работы приложений. Мы рассмотрели технику, позволяющую избежать утечки памяти, предотвратить зависание приложений, обсудили использование механизма Application Restart and Recovery, позволяющего перезапускать приложения, которые либо заблокировали какие­то ресурсы, либо перестали реагировать на сообщения системы, и механизма Windows Error Reporting, который дает возможность собирать данные о сбоях, происходящих в приложениях.

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

Какие службы Windows можно отключить, чтобы ускорить систему

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

Как настроить службы Windows

Включать и отключать службы можно в специальном менеджере Windows. Чтобы открыть его, воспользуйтесь комбинацией клавиш Windows + R, в появившейся строке введите команду services.msc и нажмите Enter. Вы увидите такое же или похожее (если у вас одна из старых версий ОС) окно:

Менеджер отображает службы в виде таблицы. Здесь можно просмотреть их список и прочитать краткое описание каждой программы. Особую важность представляет столбец «Тип запуска». Именно он показывает, используется ли та или иная служба.

Чтобы отключить службу, нужно кликнуть по ней дважды, нажать «Тип запуска», выбрать «Отключена» и кликнуть «Ок». Но среди прочих вариантов запуска есть значение «Вручную». В целях безопасности выбирайте именно его для всех служб, которые вы захотите отключить. Это позволит системе запускать программы, когда они действительно необходимы, и не тратить на них ресурсы в остальное время.

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

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

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

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

Отчеты об ошибках Windows 7 ‹ Windows 7 — Впечатления и факты

Если вы не хотите, чтобы информация об ошибках операционной системы и установленных программ сохранялась на компьютере и отправлялась в Microsoft, то вы можете настроить параметры сохранения и отправки отчетов об ошибках Windows 7.

Параметры отправки отчетов об ошибках и поиска решений проблем можно настроить двумя способами:

Важно: после изменения настроек отчетов об ошибках вы не сможете получать информацию о решении проблем в Центре поддержки Windows 7. Изменяйте эти настройки только если вы точно знаете, зачем вам это нужно.

Настройка отчетов об ошибках с помощью Центра поддержки Windows 7

1. Откройте Панель управления > Центр поддержки.

2. Нажмите Обслуживание > Параметры.

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

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

Чтобы настроить отправку отчетов об ошибках для всех пользователей компьютера, войдите в Windows 7 как администратор, откройте Панель управления > Центр поддержки > Обслуживание > Параметры и нажмите Изменить параметры отчетов для всех пользователей.

Настройка отчетов об ошибках с помощью Редактора локальной групповой политики

Поскольку редактор локальной групповой политики присутствует не во всех версиях Windows 7, данный способ может быть применен только в Windows 7 Профессиональная, Windows 7 Максимальная и Windows 7 Корпоративная.

Важно: настройки, заданные в Редакторе локальной групповой политики, имеют более высокий приоритет, чем настройки, заданные в Центре поддержки.

1. Войдите в Windows 7 с правами администратора.

Источник

Уровень сложности
Простой

Время на прочтение
3 мин

Количество просмотров 1.7K

Чтобы написать bug report(отчет об ошибке) в Jira необходимо выполнить несколько действий, которые ты узнаешь на примере «боевой» жиры. Уверен, что общую концепцию поймешь.

Далее ты узнаешь:

• Что такое Jira?

• Шаги для составления баг репорта

Что такое Jira?

Jira — это система управления проектами и отслеживания задач, которая используется командами разработки программного обеспечения.

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

Jira помогает командам разработки эффективно управлять проектами и обеспечивать успешную доставку программного обеспечения.

Шаги для составления баг репорта:

1). Перейдите в Jira и нажмите кнопку «Создать».

2). Выберите тип проблемы «Ошибка» из списка вариантов.

3). Заполните поле сводки кратким описанием проблемы(summary), например такой шаблон: «путь до бага» — «какая проблема?», «когда?», «где?». Заголовок можно по разному строить.

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

5). Напишите шаги для воспроизведения в специальное поле. Рекомендую в виде пронумерованного списка.

6). Прикрепите к проблеме любые соответствующие файлы, например снимки экрана и/или файлы журнала(логи, иные файлы), возможно еще какие либо ярлыки, компоненты.

7). Установите уровень приоритета проблемы в зависимости от серьезности ошибки и срочности ее исправления.

8.) По серьезности (Severity) бага в большинстве случаев, на практике, остаются пустым, по моему опыту, потому что тут разрабу виднее и то даже они часто оставляют это поле пустым.

9.) Назначьте проблему на разработчика или на другого члена команды, ответственному за дальнейшую судьбу ошибки (поле Assignee) на определенном этапе её решения.

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

Заполните поле сводки кратким описанием проблемы.

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

Указывать номер билда и/или commit hash — НЕ обязательно. Тут не особо принципиально, потому что если в девелопе, то следующие билды тоже будут с багой. По хэшу коммита, а если их несколько в таске? Вряд ли угадаешь в каком косяк. Еще бывает так, что несколько PR в сборку попало. Данное требование может возникнуть в редких случаях, например удаленно надо подебажить разрабу. Но так не всегда. Тут скорее зависит от разработчика, потому что кому-то реально проще подебажить и найти по коммиту место, где поломалось.

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

12). Нажмите кнопку «Создать», чтобы отправить отчет об ошибке.

Это основные шаги для работы с баг репортом, но шагов может быть больше. Главное, как по мне, это логи и шаги воспроизведения.

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

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

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

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

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

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

Определение

Чтобы дать наиболее точное определение, необходимо обратиться к стандартам. В нашем случае, к ISTQB.

Отчет о дефекте (bug report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]

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

С определением разобрались, поехали дальше.

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

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

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

Таким образом, главными задачами отчета об ошибке являются:
1. Показать, в чем заключается ошибка.
2. Помочь исправить дефект с минимальными затратами.

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

Каким должен быть отчет

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

Полезные репорты это те, которые приводят к исправлению ошибки. Хороший баг-репорт должен быть:

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

Итак, баг-репорт — это основной инструмент, который помогает тестировщику объяснить программисту место поиска бага. А о том, как его составлять мы поговорим в следующей статье.

Баг-репорт (bug report) — это технический документ, который подробно описывает ошибку в работе программы, приложения или другого ПО. Его составляет тестировщик, чтобы разработчикам было понятно, что работает неправильно, насколько дефект критичен и что нужно исправить.

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

Виды багов

• Функциональные. Возникают, когда фактический результат работы не соответствует ожиданиям: не получается опубликовать комментарий на сайте, добавить товар в корзину или открыть страницу.
• Визуальные. Это случаи, когда приложение выглядит иначе, чем задумано: кнопка накладывается на текст, не отображаются картинки или текст выходит за пределы окна.
• Логические. Баг, при котором что-то работает неправильно с точки зрения логики, — например, когда можно указать несуществующую дату (31 февраля) или поставить дату рождения из будущего (2077 год).
• Дефекты UX. Приложение или программа неудобны в использовании: при просмотре ленты новостей пользователя постоянно отбрасывает к началу, слишком близко расположены кнопки и вместо одной нажимается другая.
• Дефекты безопасности. Случаи, когда из-за ошибки в коде данные пользователей (почты, пароли, фото, информация о платежах) могут быть доступны третьим лицам.

Структура баг-репорта

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

Серьезность и приоритет багов

Серьезность — это показатель влияния бага на работу программы, того, может ли она функционировать без исправления или баг ломает всю систему. Выделяют пять уровней серьезности багов:

• S0 Trivial (Тривиальный) — баг не влияет на работу программы, поэтому для его исправления могут не выделить отдельную задачу, а исправить попутно при исправлении других, похожих ошибок. Например, при заполнении анкеты в поле «Дата рождения» по умолчанию отображается не актуальный год, а 1999-й.
• S1 Minor (Незначительный) — баг почти не нарушает логику процессов, поэтому с ним программа может нормально работать. Например, неудобная навигация в интерфейсе.
• S2 Major (Серьезный) — баг создает неудобства в использовании, но еще не нарушает функционал программы.
• S3 Critical (Критический) — баг мешает приложению выполнять основные функции: калькулятор расходов неправильно считает бюджет или в текстовом редакторе невозможно вводить текст.
• S4 Blocker (Блокирующий) — ситуация, когда программа не работает в принципе: сайт выдает «ошибку 404» или не запускается приложение.

Приоритет — это срочность выполнения задачи. Всего выделяется три уровня приоритетов:

• P1 Высокий — исправляется в первую очередь, так как баг ломает работу приложения.
• P2 Средний — обязательный к исправлению баг после критического.
• P3 Низкий — не требует немедленного решения.

Жизненный цикл бага

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

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.
• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.
• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.
• Закрыт (Closed) — баг устранен и больше не воспроизводится.

Кроме основных есть еще несколько статусов:

• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».
• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.
• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

Как правильно писать баг-репорт

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

На что стоит обратить внимание при описании дефекта?

Выявить причину возникновения. Например, если на сайте не получается восстановить пароль, то проблема может быть как в бэкенде, так и во фронтенде. Задача тестировщика — разобраться в ней, так как от этого зависит, кому из разработчиков отдавать баг на исправление.

Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.

Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.

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

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

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

Откуда берутся баги

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

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

Виды багов

🧨 Логические. Приводят к тому, что программа зависает, работает не так, как надо, или выдает неожиданные результаты — например, не записывает файл, а стирает.

🧨 Синтаксические. Это опечатки в названиях операторов, пропущенные запятые или кавычки.

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

🧨 Компиляционные. Появляются, если что-то не так с компилятором или в коде есть синтаксические ошибки. Компилятор будто ругается: «Не понимаю, что тут написано. Не знаю, как обработать».

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

🧨 Арифметические. Бывает, в коде есть числовые переменные и математические формулы. Если где-то проблема — не указаны константы или округление сработало не так, возникает баг.

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

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

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

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

Как составить баг-репорт

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

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

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

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

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

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

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

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

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

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

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

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

Остальные элементы указывают, в зависимости от условий. Например, если софт на ставят на ПК, то нужна версия ОС. Если приложение браузерное, то указывают браузер.

Пример баг-репорта

Заголовок	Не срабатывает кнопка Start
Проект	Аванта
Компонент приложения	Кнопка запуска приложения. Начальное меню
Номер версии	0.9а
Критичность	Блокирующий
Приоритет	P1 Высокий
Статус	Новый
Автор	Картавых Игорь Сергеевич
Назначен на	Мудрых Андрей Иванович
Описание	ОС Win10, 19045.2728, Google Chrome 111.0.5563.65, 0.9а (0.9.11.5А). При запуске приложения, на главном экране. Отсутствие вывода Запуск приложения
Прикрепленный файл	N/A

Основные принципы: как не допускать ошибок в баг-репорте

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

Указывайте:

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

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

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

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

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

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

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

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

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

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

Жизненный цикл баг-репорта

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

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

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

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

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

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

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

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

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

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

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

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

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

• Jira.
• YouTrack.
• Redmine.

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

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

• GitHub.
• GitLab.
• Bitbucket.

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

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

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

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

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

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

Главное: что такое баг-репорт

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