Создание запроса на основе полей интеграции сборки и тестирования

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

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

Предпосылки

• Разрешения на уровне проекта:
  • Участники: могут создавать и изменять запросы.
  • Читатели: могут просматривать запросы, но не могут создавать или изменять их.
  • Администраторы проекта: полный контроль над всеми параметрами проекта, включая запросы.
• Определенные разрешения для артефактов тестирования:
• Управление планами тестирования. Позволяет создавать, редактировать и удалять планы тестирования.
• Управление наборами тестов: позволяет создавать, редактировать и удалять наборы тестов.
• Изменение рабочих элементов на этом узле: требуется для добавления или редактирования рабочих элементов, таких как тестовые варианты и наборы тестов.

Поддерживаемые операторы и макросы

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

Полезные фильтры

Список ошибок и тестовых случаев, которые их проверяют

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

Создание и проверка полей данных

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

Сведения о настройке поля или списка выбора см. в разделе "Добавление или изменение поля" для поддержки запросов, отчетов и рабочего процесса.

Другие поля

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

Поля, которые интегрируются с Team Foundation Build

Team Foundation Build — это локальная система сборки, которая можно использовать с Azure DevOps Server. Процесс сборки можно настроить с помощью Team Foundation Build, а Team Foundation Build может создавать рабочие элементы при сбое сборки. Он также может добавлять информацию о сборке в рабочие элементы, которые были урегулированы в определённой сборке. Team Foundation Build требует, чтобы следующие два поля были добавлены в определение типа рабочего элемента: Найдено в и Интеграционная сборка.

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

С помощью следующего фрагмента кода можно добавить эти поля в определение WIT.

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>

Если поле Found In присутствует в определении WIT, Team Foundation Build создает рабочий элемент при сбое сборки и задает поле Found In номер сборки, который завершился сбоем. Если поле "Найдено в " отсутствует, Team Foundation Build не создает рабочий элемент для неудачной сборки, и все остальное работает должным образом.

Если поле сборки интеграции присутствует в определении WIT, Team Foundation Build определяет рабочие элементы, которые были разрешены при каждой сборке, а затем обновляет эти рабочие элементы, чтобы задать номер сборки, в котором они были разрешены в поле сборки интеграции . Если поле Integration Build отсутствует, Team Foundation Build не сохраняет номер сборки в рабочих элементах, а все остальное работает так, как ожидалось.

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

При первой постановке сборки в очередь для проекта с помощью Team Foundation Build автоматически добавляется глобальный список с меткой Build — ProjectName. При каждом запуске сборки в этот глобальный список добавляется LISTITEM с именем сборки.

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
        <SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
          <GLOBALLIST name="Builds - TeamProjectName" />
        </SUGGESTEDVALUES>
</FIELD>

Поля, которые интегрируются с планами тестирования

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

При создании рабочего элемента таким образом сведения о системе и шагах по воспроизведению ошибки будут записаны в полях "Сведения о системе" и "Шаги повторного выполнения ".

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />

Поля, которые интегрируются с Team Foundation Version Control

Связывание и разрешение рабочих элементов с TFVC

Team Foundation Version Control (TFVC) предлагает функцию, которая позволяет связывать или разрешать рабочие элементы непосредственно во время проверки кода. При работе с конкретным рабочим элементом и внесении соответствующих изменений в код, вы можете связать этот рабочий элемент из окна фиксации изменений в системе управления версиями по завершении выполнения изменений.

Как TFVC обрабатывает рабочие задачи

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

1. Проверка действия: Система управления версиями запрашивает систему отслеживания рабочих элементов, чтобы определить, поддерживает ли рабочий элемент требуемое действие.
2. Переход состояния: Если действие поддерживается, TFVC извлекает состояния источника и назначения, связанные с переходом.
3. Обновление рабочего элемента: После проверки кода TFVC перемещает состояние рабочего элемента в соответствии с предопределенным переходом.

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

Дополнительные сведения см. в разделе "Автоматизация назначений полей" на основе состояния, перехода или причины.

Ограничения

При запросе по тестовой ситуации существуют следующие ограничения:

• Иерархические представления: невозможно создать запрос, показывающий иерархическое представление планов тестирования, наборов тестов и тестовых вариантов. Эти элементы не связаны между собой с помощью типов связей родитель-ребёнок.
• Наборы тестов на основе запросов. Хотя вы можете создавать наборы тестов на основе запросов, набор автоматически включает все тестовые случаи, возвращаемые заданным запросом, что иногда может привести к включению непреднамеренных тестовых случаев, если запрос не является точным.
• Ограничения полей: некоторые поля, связанные с тестовыми случаями, такие как подробные результаты выполнения, могут потребовать творческого использования существующих полей или настройки данных для их полного использования.
• Ограничения производительности и скорости. Azure DevOps накладывает ограничения на использование ресурсов и количество запросов, которые они могут сделать. Неоптимизированные запросы или чрезмерные вызовы API могут привести к задержкам или заблокированным запросам.
• Связывание тестовых случаев: тестовые случаи не связаны автоматически с другими рабочими элементами таким образом, чтобы поддерживать сложные запросы. Например, вы не можете легко запрашивать иерархическое представление тестовых случаев, связанных с конкретными требованиями или историями пользователей.

Связанные статьи

• Индекс поля рабочего элемента
• Управляйте разработкой в Git с помощью рабочего элемента
• Связывание рабочих элементов с другими объектами
• Запросы ссылок и вложений