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

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

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

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

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

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

Тип данных

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


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

Contains Words, , Does Not Contain WordsIs EmptyIs Not Empty.
Is Not Empty Операторы Is Empty поддерживаются для Azure DevOps Server 2019 RC2 и более поздних версий.

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

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not ContainInNot InIn GroupNot In GroupWas Ever
Макросы: [Any]допустимый с полем "Тип рабочего элемента"; и @Projectдопустимый с полем командного проекта . Система автоматически использует фильтрацию на основе текущего проекта. Дополнительные сведения см. в разделе Запросы между проектами.

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

Фильтр для

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

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

        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

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

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

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

Примечание.

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

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

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

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

Имя поля

Description

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


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

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

  • Автоматизированный
  • Не автоматизировано
  • Планово
    Сведения о выполнении автоматических тестов см. в разделе "Запуск автоматических тестов" из планов тестирования.
    Эталонное имя=Microsoft.VSTS.TCM.AutomationStatus, тип данных=String

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

Найдено в 2

Номер сборки продукта, также известный как редакция, в которой обнаружена ошибка.
Эталонное имя=Microsoft.VSTS.Build.FoundIn, тип данных=String

Примечание.

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

Служба

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

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

Примечание.

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

Все

Проблема

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

Общие шаги

Параметры

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

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

Шаги

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

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

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

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

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

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

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

Служба

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

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

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

Набор тестов

Примечание.

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

Другие поля

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

Имя поля

Description

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

Автоматизированное тестирование служба хранилища

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

Имя ссылки=Microsoft.VSTS.TCM.AutomatedTest служба хранилища, тип данных=String

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

Автоматический тип теста

Тип теста, который автоматизирует тестовый случай.

Эталонное имя=Microsoft.VSTS.TCM.AutomatedTestType, тип данных=String

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

AutoTestId

Идентификатор теста, который автоматизирует тестовый случай.

Эталонное имя=Microsoft.VSTS.TCM.AutomatedTestId, тип данных=String

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

AutoTestName

Имя теста, используемого для автоматизации тестового случая.

Эталонное имя=Microsoft.VSTS.TCM.AutomatedTestName, тип данных=String

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

LocalDataSource

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

Эталонное имя=Microsoft.VSTS.TCM.LocalDataSource, тип данных=HTML

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

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

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

Эталонное имя=Microsoft.VSTS.TCM.QueryText, тип данных=PlainText

Набор тестов

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

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

Эталонное имя=Microsoft.VSTS.TCM.TestSuiteAudit, тип данных=PlainText

Набор тестов

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

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

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

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

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

Эталонное имя=Microsoft.VSTS.TCM.TestSuiteTypeId, тип данных=целое число

Набор тестов

Примечание.

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

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

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

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

С помощью следующего фрагмента кода можно добавить эти поля в определение 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 определяет рабочие элементы, которые были разрешены при каждой сборке, а затем обновляет эти рабочие элементы, чтобы задать номер сборки, в котором они были разрешены в поле сборки интеграции. Если поле сборки интеграции отсутствует, 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>

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

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

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

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

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

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