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

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

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

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

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

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

Data type

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


Форматированный текст (HTML)

Содержит слова, не содержит слова, пуст1, не пуст1

Многострочный текстовый текст (PlainText)

Содержит слова, не содержит слова, пуст1, не пуст1

Один текст (строка)

<> = , , > , <>= , <= , =[Поле], <>[Поле], >[Поле], <[Поле], >=[Поле], <=[Поле], содержит, не содержит, в группе, а не в группе, когда-либо был
Макросы: [Любой], допустимый с полем "Тип рабочего элемента"
Project2, допустимое в поле "Команда Project"

Примечание

  1. Операторы Is Empty и Is Not Empty поддерживаются для Azure DevOps Server версии RC2 2019 и более поздних версий.
  2. Макрос @Project поддерживается для Azure Boards и TFS 2015.1 и более поздних версий. Система автоматически использует фильтрацию по текущему проекту. Дополнительные сведения см. в разделе "Запросы в проектах".

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

Фильтр для

Включите эти предложения запросов

Автоматизированные тестовые случаи

        Work Item Type = Test Case And Automation Status = Automated

Наборы тестов на основе запросов

        Work Item Type = Test Suite And Test Suite Type = Query Based

Наборы тестов на основе требований

        Work Item Type = Test Suite And Test Suite Type = Requirement Based

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

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

List bugs and the test cases that test them

Примечание

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

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

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

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

Имя поля

Описание

Тип рабочего элемента


Состояние автоматизации 1

Состояние тестового случая. Можно указать следующие значения:

Тестовый случай

Найдено в 2

Номер сборки продукта (также называемый редакцией), в которой была найдена ошибка.
Reference name=Microsoft.VSTS.Build.FoundIn, Data type=String

Примечание

Можно также использовать тип ссылки "Найдено в сборке ", чтобы связать рабочий элемент со сборкой. Этот тип ссылки доступен в Azure DevOps и работает только с текущими процессами сборки (а не сборками XAML).

Bug

Сборка интеграции 2

Номер сборки продукта, которая включает код или исправление для ошибки.
Имя ссылки=Microsoft.VSTS.Build.IntegrationBuild, data type=String

Примечание

Можно также использовать тип ссылки "Интегрированная сборка" для связывания рабочего элемента со сборкой. Этот тип ссылки доступен в Azure DevOps и работает только с текущими процессами сборки (а не сборками XAML).

Все

Проблема

Указывает, что общие шаги связаны с ожидаемым результатом. Допустимые значения: "Да " и "Нет". Reference name=Microsoft.VSTS.Common.Issue, Data type=String

Общие шаги

Параметры 3

Содержит параметры, используемые при запуске ручного теста.
Microsoft.VSTS.TCM.Parameters, Data type=HTML

Общие параметры, общие шаги, тестовый случай

Этапы

Действия и шаги проверки, необходимые для запуска теста. Microsoft.VSTS.TCM.Steps, тип данных =HTML

Общие шаги, тестовый случай

Сведения о системе

Сведения о конфигурации системы и программного обеспечения, имеющие отношение к тесту.
Microsoft.VSTS.TCM.SystemInfo, data type=HTML

Ошибка, ответ на отзывы

Шаги воспроизведения (или шаги для воспроизведения)

Шаги, необходимые для воспроизведения непредвиденного поведения Захватить достаточно информации, чтобы другие участники команды могли понять полное влияние проблемы и исправили ли они ошибку. Сюда входят действия, необходимые для поиска или воспроизведения ошибки и ожидаемого поведения. Reference name=Microsoft.VSTS.TCM.ReproSteps, Data type=HTML

Bug

Тип набора тестов 1,4

Категория набора тестов. Допустимые значения:

  • На основе запросов: используется для группировки тестовых случаев с определенной характеристикой, например всех тестов с приоритетом=1. Набор автоматически включает все тестовые случаи, возвращаемые определенным запросом.
  • Static: используется для группирования тестовых случаев, предназначенных для отслеживания состояния невыполненной работы. Каждый тестовый случай, добавляемый в основанный на требованиях набор тестов, автоматически связывается с элементом невыполненной работы.
  • На основе требований. Используйте для объединения тестовых случаев с любыми характеристиками или наборами тестов.
    Дополнительные сведения см. в разделе "Создание тестового плана".
    Reference name=Microsoft.VSTS.TCM.TestSuiteType, Data type=String

Набор тестов

Примечание

  1. Не настраивайте список выбора для этих полей. Система принимает только эти значения в списке.
  2. Добавив GLOBALLIST элемент в FIELD определение, вы можете предоставить раскрывающееся меню сборок, которые пользователи могут выбрать. Дополнительные сведения см. в разделе "Сборки и глобальное автоматическое заполнение списка " далее в этой статье.
  3. Требуется установка TFS 2013.2 или более поздней версии на сервере уровня приложений и существующих проектах для поддержки общих параметров. Дополнительные сведения см. в разделе "Настройка функций после обновления TFS".
  4. Требуется установка TFS 2013.3 или более поздней версии на сервере уровня приложений и существующих проектах для поддержки плана тестирования и набора тестов. Дополнительные сведения см. в разделе "Настройка функций после обновления TFS".

Другие поля

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

Имя поля

Описание

Тип рабочего элемента

Хранилище автоматического теста

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

Reference name=Microsoft.VSTS.TCM.AutomatedTestStorage, Data type=String

Тестовый случай

Тип автоматического теста

Тип теста, автоматически выполняющего тестовый случай.

Reference name=Microsoft.VSTS.TCM.AutomatedTestType, Data type=String

Тестовый случай

AutomatedTestId

Идентификатор теста, автоматически выполняющего тестовый случай

Reference name=Microsoft.VSTS.TCM.AutomatedTestId, Data type=String

Тестовый случай

AutomatedTestName

Имя теста, который используется для автоматического выполнения тестового случая

Reference name=Microsoft.VSTS.TCM.AutomatedTestName, Data type=String

Тестовый случай

LocalDataSource

Локальный источник данных, поддерживающий тест

Ссылка name=Microsoft.VSTS.TCM.LocalDataSource, Data type=HTML

Тестовый случай

Текст запроса

Используется для записи запроса, определенного типом набора, основанного на запросе.

Reference name=Microsoft.VSTS.TCM.QueryText, Data type=PlainText

Набор тестов

Аудит набора тестов 1

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

Reference name=Microsoft.VSTS.TCM.TestSuiteAudit, Data type=PlainText

Набор тестов

Тип набора тестов 1, 2

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

  • 1 (статический)

  • 2 (на основе запросов)

  • 3 (на основе требований)

Reference name=Microsoft.VSTS.TCM.TestSuiteTypeId, Data type=Integer

Набор тестов

Примечание

  1. Требуется установка TFS 2013.3 или более поздней версии на сервере уровня приложений и существующих проектах для поддержки плана тестирования и набора тестов.
  2. Не настраивайте список выбора для этих полей. Система принимает только эти значения в списке.

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

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

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

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

<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 не создает рабочий элемент для неудачной сборки, и все остальное работает должным образом.

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

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

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

Добавив элемент GLOBALLIST в определение FIELD , вы можете предоставить раскрывающееся меню сборок, которые пользователи могут выбрать. Пример:

<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>

Поля, которые интегрируются с Test Plans

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

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

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

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

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

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

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

Примечание

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

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