Портал качества Embarcadero обеспечивает процесс сообщества для решения, уточнения и отслеживания проблем с качеством продуктов и услуг Embarcadero. Клиенты Embarcadero с учетной записью EDN могут создавать отчеты об ошибках и запросы функций, просматривать отчеты других клиентов, а также комментировать и голосовать за наиболее важные для них отчеты. Персонал Embarcadero также участвует в Портале качества, обеспечивая постоянную связь между клиентами Embarcadero и командами, производящими продукцию Embarcadero.
Разработчики, у которых есть действующий контракт на поддержку и техническое обслуживание и которым требуется срочный ответ на запрос, должны вместо этого создать заявку в службу поддержки: запись на портале качества — это не то же самое, что заявка в службу поддержки.
Это руководство поможет вам сообщить о проблемах с продуктом RAD Studio , включая Delphi и C++Builder . Этот пост в блоге обновляет и заменяет пост на https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/
Оглавление
Использование портала качества Embarcadero
Перед использованием портала качества (QP) необходимо создать учетную запись пользователя EDN (EDN означает Embarcadero Developers Network). Перейдите на https://my.embarcadero.com , чтобы создать учетную запись, если у вас ее еще нет. Это та же учетная запись, которую вы можете использовать для регистрации продукта Embarcadero.
Под своей учетной записью перейдите на https://quality.embarcadero.com/ и войдите на портал качества (или QP).
Процесс сообщества
Качественный портал — это приложение с поддержкой коллег, в котором другие члены сообщества могут комментировать существующие отчеты или голосовать за них, а также создавать свои собственные. С порталом качества сообщество оказывает большое влияние, помогая Embarcadero расставлять приоритеты в запросах наших клиентов. Вы можете «Смотреть» проблемы других пользователей, чтобы получать уведомления, когда они обновляются.
Я уже упоминал выше, но стоит повторить, что Embarcadero также предлагает программу технической поддержки, с которой вы можете связаться онлайн по адресу https://www.embarcadero.com/support , включая поддержку установки и регистрации, а также ряд билетов технической поддержки ( в зависимости от вашего уровня поддержки). Если вы хотите немедленно решить проблему, воспользуйтесь поддержкой Embarcadero, а не порталом качества.
Максимальное использование преимуществ портала качества
Вы можете получить максимальную пользу от QP, используя его «правильно». В этом разделе руководства пользователя описываются эффективные методы публикации отчетов об ошибках, запросов функций и предложений, а также фактической работы над ошибками, функциями и предложениями. В конце концов, вы используете QP, потому что хотите, чтобы Embarcadero решал волнующие вас вопросы. В этом разделе руководства пользователя описываются различные способы, с помощью которых вы можете максимизировать свое положительное влияние с помощью портала качества.
Руководство по сообщениям об ошибках
Для многих людей первоначальный интерес к QP будет связан с сообщениями об ошибках. В принципах, обсуждаемых в этом разделе, обсуждаются как очевидные, так и тонкие способы эффективного создания и обработки отчетов об ошибках.
Вы увидите форму, похожую на:
Быть конкретной
Пишите эффективные отчеты об ошибках. Будьте максимально полными при описании ошибки и того, что происходит. Включите шаги. Самый эффективный способ исправить ошибку — предоставить воспроизводимый тестовый пример. Если вы не можете легко воспроизвести его, опишите как можно полнее, что произошло до того, как вы увидели ошибку. Отчеты об ошибках должны содержать всю необходимую информацию в одном месте . Если у вас есть воспроизводимый тестовый пример, но вы не хотите по какой-либо причине публиковать код в общедоступной системе QP, мы можем организовать прямой и более закрытый процесс отправки: пожалуйста, укажите это в самом отчете. Также обратите внимание, что для некоторых областей продуктов, таких как CodeInsight и FireDAC, существуют определенные шаги для предоставления нам информации журнала, как описано в разделе советов в конце этой записи блога.
Золотое правило: включайте в каждый отчет только одну проблему.
Тип проблемы
- Ошибка: проблема с продуктом
- Ошибка документации: проблема со справкой или документацией по продукту.
- Запрос функции: новая функция, которую вы хотели бы видеть в продукте.
Обратите внимание, что запросы функций следуют по другому пути: они проверяются менеджерами по продукту (а не командой контроля качества) и назначаются разработчикам для исследования или реализации в будущем выпуске.
Иногда мы переводим проблему из одного типа в другой, например, когда отчет об ошибке действительно может быть устранен путем добавления важной функции в продукт или в случае неправильного заполнения клиентом.
Резюме
Дайте отчету краткое, но описательное резюме. «TButton не работает» — не лучший заголовок, а «[Android] Возникает ошибка при вызове TButton двойным нажатием» — лучше.
Когда это уместно, используйте теги в заголовке, чтобы помочь тому, кто читает его, лучше понять контекст.
Хорошее резюме помогает быстро определить, что происходит, и помочь уменьшить повторяющиеся проблемы. Избегайте описания общих проблем в резюме. Вы никогда не должны использовать:
- У меня проблема с XYZ
- XYZ не работает должным образом
Несколько примеров плохих резюме и их хороших эквивалентов:
Плохо: нарушение прав доступа в IDE
Лучше: открытие пустого файла .pas вызывает нарушение прав доступа.
Плохо: ошибка push-уведомлений .
Улучшено: количество push-уведомлений добавляет одно дополнительное уведомление
Составная часть
Определите, какая часть программного обеспечения затронута этой ошибкой.
- Установить
- FireMonkey
- ВКЛ
- Компилятор C++ (см. советы по отправке ошибок компилятора C++/компоновщика)
- С++ с написанием справа налево
- Компилятор Делфи
- Делфи РТЛ
- Компоновщик (см. советы по отправке ошибок компилятора C++/компоновщика)
- База данных
- Отладчик
- IDE (среда разработки)
- Помощь и документация
- Демо
Описание
Вся информация, полученная в результате выпуска. Если возможно, включите:
- Полное сообщение об ошибке
- Полный стек вызовов
- Если вы считаете это уместным, включите информацию о вашей среде (например, версию Android или региональные настройки Windows).
- Для ошибок, которые проявляются визуально (например, элементы управления не отображаются должным образом или проблемы с макетом IDE), включите снимок экрана, чтобы помочь любому, кто читает ваш отчет, оценить его.
- Если уместно, добавьте журналы устройств, например вывод logcat для Android.
- Для сообщений об ошибках или стеков вызовов используйте теги {code} или {quote}.
- Если вы основываете свой отчет на внешнем источнике информации (например, на странице MSDN для вызова API), включите ссылку на эту информацию.
- Если ваш отчет об ошибке содержит код, либо прикрепите его к проекту, либо добавьте в раздел Шаги . Если вы добавляете в отчет код в виде текста, обязательно используйте теги {code}. Это не позволяет JIRA интерпретировать ваш код и искажать его, а также помогает улучшить читаемость отчета (избегает прокрутки нескольких страниц, чтобы перейти к соответствующим полям).
- Сведите размер вложения к минимуму. Заархивируйте ваши файлы и никогда не включайте двоичные файлы, созданные путем их компиляции (например, DCU или EXE). Используйте только формат ZIP, никогда не используйте другие форматы, для которых требуется сторонняя программа.
- Не включайте более одной проблемы в один отчет. Сообщайте отдельно и связывайте друг друга по мере необходимости.
Шаги
Цель состоит в том, чтобы показать, как воспроизвести ошибку. Держите его кратким и легко читаемым, вы должны описать его как рецепт для воспроизведения ошибки. Попробуйте достичь цели с минимальным количеством шагов.
Примечание. Сообщения об ошибках или стеки вызовов указываются в описании, а не в шагах. Например, в описании должно быть сказано: «При вызове TButton путем двойного нажатия на моем устройстве Android возникает следующая ошибка: [сообщение об ошибке]», а в шагах должны быть просто даны инструкции о том, как воспроизвести проблему.
Ожидаемые и фактические результаты
В конце вашего пошагового описания вы должны описать, каким должен быть ожидаемый результат и что происходит на самом деле.
Пример плохого описания:
Ожидается: приложение не аварийно завершает работу
На самом деле: сбой приложения
Лучше использовать:
Ожидается: приложение отображает меню XYZ.
Фактически: приложение вызывает нарушение прав доступа (см. прилагаемую трассировку стека)
Изолировать отчеты
Будьте добросовестны, отправляя вытекающие мысли в виде новых отчетов, а не просто добавляя их в качестве комментариев к существующему отчету. Это гарантирует, что проблема будет отслежена и в конечном итоге будет устранена.
Общие сведения о повторяющихся отчетах
Группа обеспечения качества помечает «дубликат» отчета как таковой. Какой отчет помечен как «основной», а какой «дубликат» основан на том, какой отчет дает наиболее точную и подробную информацию, описывающую проблему, обсуждаемую в обоих (или во многих) отчетах.
Основной отчет может измениться со временем, если кто-то еще отправит другой дубликат, но этот дубликат на самом деле лучше описывает проблему. «Мастер» и «дубликат» не имеют ничего общего с тем, кто попал первым, но какой отчет наиболее точно освещает проблему.
Как правило, «дублирующаяся» проблема имеет статус «Решено», решение «Дубликат» и связана с «основной» проблемой ссылкой «Дубликаты». Вы должны проверять статус и следить за обновлениями «главного» выпуска.
Как интерпретировать некоторые поля в QP
Поскольку портал качества синхронизируется с внутренними системами, некоторые поля, имеющие значение для наших внутренних процессов, могут не иметь очевидного значения за пределами наших внутренних процессов. Мы надеемся, что следующие таблицы объяснят некоторые значения этих синхронизированных полей.
Поле состояния
Ценность
|
Описание
|
---|---|
Сообщено | Новый дефект, требуется проверка тестировщиком |
Открытым | Открытый дефект, требует устранения. Проблема остается в этом статусе, пока над ней ведется внутренняя работа. |
Решено | Работа, выполненная и доставленная в отгрузочном продукте, репортер может проверить или разрешить спор |
Нужна обратная связь | Требуется дополнительная информация/шаги |
Закрыто | Дефект закрыт, никаких действий не требуется |
Отчет начинается со статуса «Отправлено». Когда тестировщик Embarcadero QA проверяет его во внутренней системе отслеживания ошибок Embarcadero, статус меняется с «Сообщено» на «Открыто». Когда работа с отчетом завершена и исправление входит в состав выпущенного продукта, статус меняется с «Открыто» на «Решено». Обратите внимание, что проблема помечается как решенная только тогда, когда исправление доступно, а не когда оно реализовано внутри отдела исследований и разработок.
Поле разрешения
Ценность
|
Описание
|
---|---|
Исправлено | Ошибка была исправлена |
Не могу воспроизвести | Ошибка не может быть воспроизведена в последней версии продукта. |
Работает как ожидалось | Поведение соответствует замыслу или является следствием текущего замысла |
Дублировать | Ошибка — это дубликат (необходимо отметить повторяющийся номер ошибки) другой проблемы, которая все еще может быть открыта. |
Ошибка тестового примера | Описание ошибки недействительно в том виде, в каком оно отправлено. |
Требуется дополнительная информация | Нужна дополнительная информация/демонстрация/шаги для нашей команды, чтобы воспроизвести |
Больше не применяется | Функция удалена или ошибка больше не актуальна |
Не исправить | Было принято решение, что это никогда не будет реализовано или исправлено |
Для проблем, возвращенных с запросом « Требуется дополнительная информация », статус будет помечен как « Требуется отзыв », чтобы автор сообщения мог добавить дополнительную информацию. Вы должны использовать кнопку « Обновить содержание » при отправке дополнительной информации. Как только изменения, отправленные через «Обновить содержимое», вернутся к статусу «Сообщено», команда QA повторит внутреннюю проверку. « Обновить содержание» также можно использовать, когда вносятся исправления в уже отправленную проблему.
Как правило, старайтесь уточнить описание, добавляя больше деталей и/или контекстной информации, используя приведенные выше рекомендации, или добавляйте/просматривайте шаги для воспроизведения. Также было бы полезно прикрепить скриншоты и/или проекты. Короткое и целенаправленное видео также может быть полезно для понимания.
Еще несколько советов
По вопросам, связанным с подсистемой CodeInsight LSP, см. информацию в конце этой статьи docWiki . Обратите внимание, что журналы LSP могут содержать значительные части анализируемого исходного кода, поэтому, если есть причины сохранить его зарезервированным, попросите прямой канал связи, а не добавляйте файл журнала в общедоступный отчет QP.
Точно так же, если вы сообщаете о проблемах с FireDAC, вы должны предоставить данные среды и журналы трассировки. Шаги описаны в этой статье .
Вы можете обратиться к советам по форматированию текста QP в исходной статье по адресу https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/#Hints_and_Tips .
Наконец, хороший источник рекомендаций по сообщениям об ошибках доступен по адресу http://www.mozilla.org/bugs/bug-reporting.html .
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition