Любая компания по разработке программного обеспечения стремится к тому, чтобы продукт, который она создаёт, был высочайшего качества. Для того, чтобы этого добиться, QA специалисты должны обнаружить все недостатки и недочёты приложения ещё на ранних стадиях жизненного цикла разработки программного обеспечения. А когда ошибка обнаружена, её нужно описать так, чтобы разработчики могли легко понять, в чём заключается проблема, воспроизвести её и оперативно исправить. Именно для этого пишутся баг-репорты.
В этой статье мы обсудим основные компоненты отчёта об ошибке, разберём, на какие моменты стоит обращать внимание при их составлении, а также рассмотрим, какие существуют инструменты для отслеживания багов.
Что такое баг-репорт?
Баг-репорт — это отчёт, который информирует разработчиков об ошибке (баге) в работе приложения. Этот документ должен быть хорошо структурированным и содержать достаточно деталей, чтобы читатель мог легко найти ответы на главные вопросы:
Тестирование ПО. Урок 5. Bug report.
- Где возникла проблема?
- Что именно работает не так, как ожидалось?
- Какие действия нужно выполнить, чтобы воспроизвести ошибку?
Не стоит также забывать о том, что у разработчиков нет времени читать слишком длинные, с множеством несущественных подробностей описания багов. Поэтому отчёты должны быть как можно более краткими.
Как правило, репорт попадает в категорию плохо составленных по одной из двух причин: слишком много ненужных деталей или слишком мало полезной информации. Навык не включать в отчёт ничего лишнего приходит с опытом. А для того, чтобы не пропустить ничего важного, достаточно помнить об основных элементах баг-репорта.
Основные компоненты баг-репорта.
Давайте рассмотрим каждый раздел отчёта об ошибке и поговорим о том, на что стоит обращать внимание при написании.
Описание бага.
Раздел с описанием ошибки должен содержать подробную информацию о том, что привело к возникновению проблемы, какой результат ожидали получить тестировщики, а что произошло на самом деле. Он может иметь такую структуру:
Очень важно предоставить разработчикам чёткие инструкции, как они могут воспроизвести ошибку. В идеале это должен быть пронумерованный список понятных действий:
- Перейти на страницу входа в систему.
- Ввести правильное имя пользователя.
- Ввести неправильный пароль.
Чтобы сделать список короче, можно заранее оговорить некие условия. Например, если что-то не работает на странице редактирования профиля, не обязательно подробно описывать все шаги для входа в систему. Вместо этого можно внести информацию: предварительные условия — зарегистрированный пользователь вошёл в систему.
- Фактические и ожидаемые результаты.
Здесь вы объясняете разницу между ожидаемым и фактическим поведением приложения.
Ожидаемый результат: Не удаётся войти в учётную запись. Появляется сообщение об ошибке «Неверное имя пользователя или пароль».
Первое знакомство c Bug report. Шок! Смотреть до конца!
Фактический результат: Не удаётся войти в учётную запись. Появляется сообщение об ошибке «Неверное имя пользователя”.
При написании каждого из этих подразделов не забывайте о том, что добавить всю полезную информации и исключить все ненужные детали одинаково важно.
Приложения
Скриншоты или видеозапись экрана помогут разработчикам быстрее разобраться в сути проблемы и найти оптимальное решение. Однако это не означает, что можно добавить к отчёту видео и не утруждать себя описанием ошибки. Приложения лишь дополняют, но ни в коем случае не заменяют текстовую информацию.
Критичность и приоритет (Severity, Priority)
Эти разделы подсказывают, насколько серьёзные последствия может вызвать обнаруженная ошибка и как срочно её нужно устранить. Обычно багам присваивается один из 6 уровней критичности: блокирующий, критический, серьёзный, незначительный, тривиальный, предлагаемое улучшение. В зависимости от критичности проблемы ей назначается высокий, средний или низкий уровень приоритета.
Программно-аппаратное окружение (Environment)
На разных устройствах приложения могут вести себя по-разному. Поэтому качественный отчёт об ошибке должен также содержать информацию об операционной системе, версии приложения, браузерах и девайсах, использованных в процессе тестирования.
Подход к составлению отчётов об ошибках может немного отличаться от компании к компании. Это зависит от используемых технологий, типа проекта, принятых рабочих процессов и тестируемых продуктов. Однако понимание основных компонентов баг-репорта и требований к ним поможет вам составлять хорошие отчёты независимо от этих факторов.
Инструменты для отслеживания ошибок или баг-трекеры.
Баг-трекеры — это инструменты, которые позволяют командам эффективнее фиксировать и отслеживать дефекты в приложениях. В их функционал обычно входит следующее:
- Создавать баг-репорты.
- Присваивать ошибкам приоритет.
- Менять статус бага на разных этапах его жизненного цикла (например, новый, открыт, отклонён, исправлен и т.д.).
- Назначать ответственных за выполнение той или иной задачи.
- Искать, фильтровать и сортировать ошибки по различным параметрам: по названию, критичности, идентификационному номеру и т.д.
Вот краткий обзор десяти популярных инструментов для отслеживания ошибок.
JIRA
JIRA — это баг-трекер и инструмент для управления Agile-проектами, который используют многие компании. Её легко подстроить под нужды конкретной команды и интегрировать практически с любым другим инструментом разработки.
Bugzilla
Bugzilla — это популярный баг-трекер с открытым исходным кодом. Он прост в использовании, имеет все необходимые функции и предоставляет расширенные возможности поиска.
Trello
Trello — популярная система управления проектами. Она невероятно гибкая и позволяет наладить эффективный рабочий процесс по отслеживанию ошибок для команд любого размера.
Asana
Asana — ещё один инструмент управления проектами, который широко используется для отслеживания ошибок. В ней даже есть готовый шаблон для таких целей, который можно легко изменить или дополнить, в зависимости от потребностей компании.
Redmine
Redmine — баг-трекер с открытым исходным кодом. Он популярен среди небольших команд, которым нужно простое и гибкое решение для управления различными проектами.
FogBugz
FogBugz — веб-система управления проектами с функциями для отслеживания ошибок, управления задачами и учёта рабочего времени.
YouTrack
YouTrack — это веб-система для отслеживания ошибок и управления проектами, разработанная компанией JetBrains. Она позволяет фиксировать дефекты, планировать спринты, управлять задачами и составлять отчёты о проделанной работе.
Backlog
Backlog — простая, но мощная платформа. Расширенные возможности поиска, полная история обновлений и изменений статусов, вики, иерархия задач, диаграммы Ганта и множество других полезных функций позволяют без труда наладить эффективный процесс отслеживания ошибок.
Zoho Bug Tracking
Zoho Bug Tracking — это онлайн-платформа, с помощью которой можно создавать проекты, отслеживать ошибки, генерировать отчёты или обмениваться документами.
BugHerd
BugHerd — инструмент, который позволяет собирать отчёты о работе сайта прямо на его страницах.
Безусловно, использование подходящих инструментов может облегчить работу по отслеживанию багов. Однако, чтобы наладить действительно эффективный процесс, одних инструментов мало. Нужно ещё, чтобы все члены команды придерживались основных правил по написанию качественных баг-репортов.
О чём стоит помнить при составлении баг-репортов?
Вот несколько принципов, которых стоит придерживаться:
- Один отчет — одна ошибка. Даже если вы обнаружили проблемы в одном и том же месте, создавайте отдельные репорты для каждого бага. Если описывать несколько в одном отчёте, это только запутает читателя и он может упустить какой-то из дефектов. Кроме того, статус такого репорта невозможно будет изменить, пока разработчики не исправят все перечисленные в нём ошибки. И разобраться, как продвигается работа, будет сложнее.
- Избегайте дубликатов. Прежде чем создавать новый баг-репорт, проверьте, если проблема уже не была описана ранее.
- Воспроизведите ошибку несколько раз, чтобы убедиться, что вы не пропустили ни одного важного шага в инструкциях для разработчиков. Если у вас не получается повторить проблему каждый раз, упомяните об этом и укажите коэффициент воспроизводимости (например: 7/10 раз баг воспроизводится).
- Придерживайтесь фактов и не стройте предположений о том, что могло стать причиной дефекта. Это может задать разработчикам неверное направление мысли и отсрочить устранение ошибки.
- Всегда будьте вежливы, не обвиняйте и не критикуйте коллег. Ваша работа как тестировщика заключается в обеспечении высокого качества продукта, а не в оценке чьей-то работы.
- И наконец, перечитайте свой отчёт, прежде чем отправить его. Он должен быть кратким, понятным и содержать всю необходимую информацию.
Создание качественных баг-репортов — ценный навык для любого специалиста по обеспечению качества. Теперь, когда вы получили достаточно теоретической информации, пришло время применить свои знания на практике. Тренируйтесь — и совсем скоро вы будете писать отчёты, которые точно понравятся вашим разработчикам!
Полезные ссылки
Источник: www.careerist.com
Home
Так уж случилось, что у нас накопилась масса материала, посвященного теме создания идеального отчета об ошибках (bug report). Обобщив эту информацию и вооружившись практическим опытом, мы решили написать статью. Перед вами подробный текст о стандарте написания баг репортов.
Каналы поступления багов
Начнем с каналов поступления багов. Мы можем столкнуться с проблемами и получить информацию об их появлении следующим образом:
- В процессе тестирования — функционального и нефункционального.
- Обращение клиента (заказчика) с информацией о возникшей проблеме.
- Баги, выявленные пользователями. Соответствующая информация может быть передана как разработчикам, так и заказчику.
- Ошибки полученные при помощи систем мониторинга, например Sentry, Errbit, Crashlytics.
Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму.
Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.
Направления работы отдела QA
С каналами поступления информации о багах мы определились. Теперь перейдем к направлениям работы QA инженеров. Их несколько:
- Веб-приложения;
- Мобильные приложения (iOS и Android);
- API (как часть мобильного или веб-приложения или или же в качестве самостоятельного проекта);
В зависимости от направления работы состав информации, подаваемой в баг репорт, будет изменяться. Однако окончательная цель QA специалиста останется неизменной. Речь, разумеется, идет об устранении бага.
Вот здесь начинается самое интересное. Чем полнее и точнее подана информация, тем проще QA инженеру или менеджеру проекта определить приоритет проблемы, а разработчику — ее устранить. Все просто, у команды общие цели — стабильный проект, довольный заказчик и счастливые пользователи программного обеспечения, отсутствие переработок.
Написание bug report — один из кирпичиков, которые закладываются в фундамент достижения этих целей. Он должен быть ровным и красивым. В противном случае мы сталкиваемся с проблемами: разработчикам приходится тратить время на воспроизведение бага, вместо того чтобы писать код.
Написание bug report: как это происходит
В идеальном мире QA специалист добавляет баг в трекинговую систему только в том случае, если он может воспроизвести проблему. Сообщения же о дефектах, которые приходят от заказчика и пользователей, не всегда содержат максимум полезной информации. В таких случаях QA специалист должен либо самостоятельно определить проблему, либо связаться с лицами, заявившими о ее наличии и собрать все недостающие сведения.
Прежде чем создавать баг-репорт, убедитесь, что такого же дефекта нет в системе отслеживания ошибок. Если он уже зафиксирован, при необходимости дополните описание актуальной информацией.
Чего делать нельзя? Нельзя информировать сразу о нескольких проблемах в пределах одного баг репорта. Закон джунглей: один bug report = одна проблема. Не ленитесь.
Чем плох баг репорт с несколькими проблемами в пределах одной задачи? Это значительно замедляет процесс их устранения. Следите за руками: после починки дефекта разработчик переназначает задачу на QA специалиста для проверки. Если мы имеем несколько проблем в одной задаче – разработчик не сможет отдать их на проверку, пока не устранит каждую из них. Чувствуете как утекает время?
Когда же все баги упакованы в отдельную задачу, QA специалист может приступить к проверке исправлений значительно раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и программное обеспечение быстрее продвигается к релизу.
Нельзя заводить, как баг, то, что не имеет отношения к спецификации проекта. Не нужно отнимать у разработчиков время на работу, которая не согласована.
По аналогии поступаем и с code-review. Весьма полезно иногда показывать коллегам свежесозданный отчет об ошибке. Возможно они подскажут, что следует добавить и/или исключить из описания проблемы.
К слову, баг репорт состоит не только из описания. Любое сообщение о дефекте включает в себя два элемента:
Рассмотрим каждый из них в отдельности.
- Содержать предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о баге;
- Ответить на три вопроса: Что? Где? И при каких условиях? (или хотя бы на те 1-2 вопроса, которые применимы к конкретной ситуации);
- Быть достаточно коротким, чтобы полностью помещаться на экране (имеются в виду баг-трекинговые системы, где заголовок обрезается или приводит к необходимости скроллинга);
- Содержать информацию об окружении, под которым был обнаружен баг (в зависимости от типа проекта);
- Быть законченным предложением русского или английского языка, построенным в соответствии с правилами грамматики.
Давайте рассмотрим работу с заголовком на простом примере:
- Ситуация: поле описания товара в веб-приложении должно допускать ввод максимум 250 символов. В процессе тестирования выяснилось, что необходимое ограничение отсутствует (вводится хоть миллион символов).
- Суть проблемы: исследование показало, что ни на клиентской, ни на серверной стороне нет никаких механизмов, проверяющих и/или ограничивающих количество символов, вводимых в поле описания товара.
- Используем золотое правило. Что: отсутствует проверка и ограничение длины вводимого текста. Где: поле описания товара. При каких условиях: при любых, то есть — всегда.
- Формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле описания товара.
- Сокращение (итоговое summary): Нет ограничения максимальной длины поля «Описание».
- Англоязычный вариант: No check for max length of Description field.
Небольшой комментарий к информации об окружении и проектных традициях. Приведем простой пример. Мы имеем дело с проектом, в пределах которого разрабатывается мобильное приложение под две платформы: iOS и Android. В зависимости от того, к какой платформе привязан баг, в заголовке указываем: iOS или Android. Например, “iOS.
Application accepts dates of birth from the future.”.
Дополнительный вариант — использование так называемых ярлыков (labels). Некоторые системы отслеживания ошибок предоставляют соответствующий функционал.
Описание
Переходим ко второму компоненту bug report. Описание должно содержать следующую информацию:
- Подготовительные операции, то есть действия, обеспечивающие возможность воспроизведения проблемы.
- Шаги воспроизведения. Сразу заметим: везде нужна золотая середина. Категорически запрещается пропускать важные шаги. Но в то же время не следует разжевывать очевидные вещи. Например, вставлять скриншоты в каждый отчет об ошибке совершенно не обязательно. Не плодите лишние сущности. Если они ничем не помогут в воспроизведении проблемы — не тратьте время на их изготовление.
- Актуальный результат.
- Ожидаемый результат.
- Дополнительная информация: различного рода уточнения, логины, пароли и прочее. Все, что может понадобиться в процессе воспроизведения проблемы.
- Уровень проблемы. Чаще всего используются следующие уровни (это не панацея, в зависимости от традиций компании или типа используемой системы отслеживания багов, названия уровней могут меняться):
- Blocker — устанавливается, если баг блокирует дальнейшую работу приложения или процесс тестирования.
- Critical — присваивается при значительном влиянии проблемы на поведение ПО, но без блокировки его работы или процесса тестирования.
- Major — указывается при незначительном влиянии на эталонное поведение ПО. Проблема такого уровня не блокирует работу программного обеспечения и процесс тестирования. В качестве примера можно привести некорректный подсчет количества записей в каком либо списке.
- Minor — ставится в тех случаях, когда баг не оказывает влияния на функционал и поведение ПО. Например, это может быть опечатка или грамматическая ошибка в тексте, очень сложно воспроизводимый дефект.
При работе с Pivotal Tracker мы привыкли маркировать уровни проблемы цифровым значением от 1 до 4, это значение указывается в качестве label. По уровням градация следующая: 1 — это Blocker и Critical, 2 — это Major, 3 — это Minor и 4 — это Trivial. Такая градация уровня проблемы используется на всех проектах, которые ведутся в Pivotal Tracker.
А теперь рассмотрим каждый из компонентов описания баг репорта в отдельности.
- Подготовительные операции. Самый простой пример: авторизация перед совершением каких-либо действий в панели управления.
- Шаги воспроизведения проблемы. Последовательность действий, приводящих к возникновению (проявлению) дефекта. Шаги могут сопровождаться скриншотами или видео. Однако наличия набора медиафайлов недостаточно. Текстовое описание шагов должно присутствовать всегда и в обязательном порядке.
- Актуальный результат — ошибка или поведение ПО, не соответствующее описанию в спецификации проекта.
- Ожидаемый результат — описание типового поведения ПО, без ошибки и соответствующего описанию в спецификации проекта.
- Информация об окружении, если она необходима для воспроизведения бага (версия приложения и/или браузера, операционная система, разрешение экрана, логин и пароль, примеры файлов, локализация)
- Уровень проблемы (minor, major, critical или blocker).
Примеры
Пример #1
Один из баг репортов для мобильного приложения. Проект ведется в Pivotal Tracker. Уровню проблемы присваивается значение в диапазоне от 1 до 4, где наиболее важные моменты — это “1” и далее по убыванию. Приложение разрабатывалось сразу под две платформы — Android и iOS. Поэтому мы решили прописывать платформу в заголовок задачи.
Переходим к составляющим баг репорта:
Так как отдельных полей о тестовом окружении в Pivotal Tracker не предусмотрено, мы добавляем информацию о билде (Build v2.0.6) и версии Android, на которой был воспроизведен баг (Android 6.0), в поле Description.
В этом же поле прописываем шаги воспроизведения бага:
- Open a track with related Label (as the example EDX — My Friend Extended Mix)
- Tap on the Info icon (top right corner)
- Tap on the Label name, nothing happens
И ожидаемый результат: Expected behaviour: Label screen should be opened.
Кроме того, к задаче были прикреплены скриншоты экрана About Track с явным указанием проблемной надписи. При нажатии на нее ожидался переход на другой экран.
Пример #2
Следующий пример — баг репорт из проекта, связанного с реализацией REST API для мобильных приложений. Проблема состояла в том, что в ответе не возвращалась необходимая информация (атрибуты).
Кликните на изображение для увеличения
Проект также велся в Pivotal Tracker, поэтому уровень проблемы был указан с помощью label. Использовалась аналогичная шкала (от 1 до 4). Мы присвоили проблеме уровень “2”, так как отсутствие данной в ответе метода не позволяло выполнить некоторые операции в профиле пользователя.
Итак, заголовок — The method «View User Profile» should return information about user’s location. Мы совершенно отчетливо указываем на метод и проблему. Далее в поле Description мы даем понять, что речь идет о стейджинге.
Указываем реквизиты пользователя, которые могут понадобиться для воспроизведения проблемы. В нашем случае это: email, пароль и токен.
Email: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
Password: qwerty
Token: xVjowqgm-FHjNwB9tAbG
Описываем проблему и добавляем техническую информацию: пример вызова метода при помощи curl и текущий ответ.
Наконец, указываем что мы ожидали увидеть в ответе недостающие атрибуты.
- Location name (location_name)
- location ID (location_id)
- location type (location_type).
Выводы
Как видите, сведения об окружении и технические детали могут меняться в зависимости от направления проекта. В остальном состав подаваемой информации в отчетах об ошибках идентичен.
Что еще важно отметить? На сегодняшний день существует масса систем для автоматического сбора информации об ошибках. Например, Errbit для веб или Crashlitics для мобильных приложений. Они могут быть интегрированы с вашей системой отслеживания ошибок и передавать все технические подробности проблемы.
Однако автоматически созданные задачи должны тщательно исследоваться тестировщиком для определения и добавления шагов воспроизведения проблемы. Лишь после этого задача передается разработчикам.
Использование общих шаблонов и практик дизайна отчетов об ошибках в пределах компании позволяет существенно сократить время коммуникации между разработчиками и QA специалистами. Дело в том, что согласование задач (то есть случаи, когда разработчики возвращают тестировщикам задачи со статусами rejected, can’t reproduce, more info) зачастую существенно затягивается. Соблюдение же правил написания bug reports позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.
Источник: www.software-testing.ru
Как я могу исправить проблемы, связанные с BugReporter.exe?
Обычно причиной ошибок, связанных с исполняемым файлом EXE при запуске программного обеспечения The Swapper, является повреждение или отсутствие файлов BugReporter.exe. Большую часть проблем, связанных с данными файлами, можно решить посредством скачивания и установки последней версии файла EXE. Помимо прочего, в качестве общей меры по профилактике и очистке мы рекомендуем использовать очиститель реестра для очистки любых недопустимых записей файлов, расширений файлов EXE или разделов реестра, что позволит предотвратить появление связанных с ними сообщений об ошибках.
Исполнимые файлы, которые относятся к формату Windows Executable File обычно содержат суффикс файла EXE. Ниже вы также можете найти последние версии файлов для %%os%% (и для других версий ОС). В нашей базе представлены не все версии BugReporter.exe, поэтому нажмите на кнопку Request (Запрос), чтобы наши сотрудники её получили. В крайнем случае, если ниже отсутствует необходимый вам файл ниже, для получения необходимой версии вы также можете связаться с Olli Harjola, Otto Hantula, Tom Jubert, Carlo Castellano.
Поместите новый файл BugReporter.exe на место предыдущего (перезаписав предыдущий). Проблема больше не должна возникать, однако, чтобы убедиться в этом окончательно, следует выполнить проверку. Проверьте, результат замены файла, запустив The Swapper и убедившись, что сообщение об ошибке больше не выводится.
| Формат файла: | EXE |
| Тип приложения: | Game |
| Новейшие программы: | The Swapper |
| Версия выпуска: | 226328 |
| Создано: | Olli Harjola, Otto Hantula, Tom Jubert, Carlo Castellano |
| Имя файла: | BugReporter.exe 62899e1b0f7fb12e3a21054131ac7a4fa5e1cb94 |
| MD5: | 54220d28dacfe14f307c992b29074103 |
| CRC32: | 5a58afe1 |
Источник: www.solvusoft.com
Инструмент AMD Bug Report Tool: как это работает и руководство пользователя
Вы когда-нибудь задумывались о том, как было бы удобно, если бы у вас был Проблема с ПК Вы могли бы сообщить об этом непосредственно производителю? AMD разработал инструмент под названием Инструмент отчета об ошибках AMD для этого, и в этой статье мы расскажем вам, что это такое, как оно работает и как вы можете использовать его самостоятельно.
Было бы почти нереальной утопией, что когда мы сталкиваемся с проблемой или ошибкой на ПК, будь то аппаратное или программное обеспечение, мы могли бы напрямую проинформировать человека, ответственного за это, чтобы они могли напрямую найти решение и решить его. На самом деле это не так быстро и прямо, но с помощью этого программного обеспечения AMD предлагает очень интересный подход, цель которого — упростить жизнь как пользователям, так и их команде разработчиков.
Недавно мы видели пример с портами USB 3.0 на платах чипсетов AMD 500 Series, которые периодически отключались, и производитель попросил на своем официальном Reddit, что затронутые пользователи отправили им отчеты с проблемой, чтобы они могли ее найти. Если бы этот инструмент был под рукой, все было бы намного быстрее и проще.
Что такое инструмент отчетов об ошибках AMD?
Идея этого программного обеспечения AMD заключается в том, что при обнаружении проблемы или «ошибки» на своем ПК вы можете отправить всю необходимую информацию непосредственно команде разработчиков AMD, чтобы они попытались решить ее как можно скорее; Будь то проблема с оборудованием или программным обеспечением, ваша группа инженеров может быстро определить основную причину проблемы и устранить ее как можно быстрее, развернув решение в следующем обновлении программного или микропрограммного обеспечения.
Таким образом, AMD Bug Report Tool — это утилита, позволяющая пользователям оборудования и приложений AMD сообщать об ошибках непосредственно производителю. При отправке отчета об ошибке инструмент автоматически фиксирует необходимые детали конфигурации оборудования и программного обеспечения системы, избавляя пользователя от необходимости вводить какие-либо данные (но будьте осторожны, поскольку вы отправляете относительно конфиденциальную информацию в AMD).
Инструмент также предлагает возможность прикреплять дополнительные файлы, такие как снимки экрана и изображения, чтобы они могли помочь AMD лучше понять возникшую проблему и, таким образом, более эффективно ее исследовать.
AMD Bug Report Tool совместим с Windows 10 64-битных систем, которые имеют процессор AMD Ryzen или оснащены графикой AMD Radeon (т. Е. Не работает, если на вашем ПК установлен Intel ЦП и NVIDIA GPU / ГРАФИЧЕСКИЙ ПРОЦЕССОР, но это так, если процессор — графика Intel и AMD или процессор — графика AMD и NVIDIA). Вы должны иметь в виду, и AMD предупреждает вас, что они будут проверять только отчеты, отправленные из последней версии приложения, то есть вы должны помнить, что вы должны постоянно обновлять его, чтобы оно работало должным образом.
Как отправлять сообщения об ошибках напрямую в AMD
AMD Bug Report Tool поставляется в комплекте с драйверами Radeon Software Adrenalin Edition 2020 от версии 20.7.1 и более поздних. Вы можете получить доступ к инструменту как с помощью значка «ошибка», расположенного в правом верхнем углу экрана приложения, так и из системного меню.
Если в вашем случае это программное обеспечение не установлено, потому что вы не хотите этого или потому, что у вас нет графического процессора AMD, вы также можете загрузить и установить отдельную версию, доступную на Сайт AMD .
После запуска приложения вы увидите окно с рядом опций, которые вы должны выбрать в зависимости от вашей проблемы. Первоначально вам нужно будет выбрать, какой продукт является затронутым (графический процессор от AMD или Radeon Software, AMD Ryzen Master, AMD Link или связанный с набором микросхем), приложение или игру, в которой у вас есть проблемы, симптомы, которые у вас есть (все это раскрывающееся меню для выбора), а затем описание и объяснение проблемы с указанием шагов, которые вы предприняли для ее воспроизведения.
Например, представьте, что ваша проблема в том, что когда вы пытаетесь открыть игру, она закрывается и выдает ошибку. Здесь вы должны отметить AMD Graphics / Radeon Software, затем выберите игру, в симптомах выберите «Сбой / Зависание / Синий экран / Черный экран / Зеленый экран», в описании вы можете указать «Сбой игры после запуска» и в шагах например, чтобы воспроизвести проблему, просто «Игра вылетает сразу после входа в нее». Еще лучше, если вы приложите снимок экрана с полученной ошибкой.
Ниже у вас также есть возможность указать, сколько ватт у вашего источника питания, если вы хотите добавить изображения или другие вложения, и если вы хотите ввести свой e-mail адрес для получения ответов на вопрос (все это необязательно).
После ввода всей этой информации вам просто нужно нажать кнопку «Отправить отчет», и все, он будет автоматически отправлен в AMD, и они смогут приступить к работе, чтобы попытаться определить причину проблемы и разработать решение.
Источник: itigic.com