Criar uma consulta baseada em campos de integração de construção e teste

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server | 2019 TFS 2018

Os campos de trabalho que suportam a construção e a integração de testes suportam as seguintes ações:

  • Associar bugs com as construções onde foram encontrados ou fixos
  • Consulta para insetos associados a uma construção
  • Marque os casos de teste como manuais ou automatizados e guarde informações para suportar casos de teste automatizados
  • Para casos de teste e etapas partilhadas, defina os passos de ação e validação e os dados utilizados para a execução de testes.

Operadores e macros apoiados

A maioria dos campos de integração de construção e teste têm um tipo de dados de String, PlainText ou HTML. As cláusulas de consulta que especifiquem um texto ou um campo de texto rico podem utilizar os operadores e macros listados no quadro seguinte.

Tipo de dados

Operadores e macros apoiados


Texto rico (HTML)

contém palavras, não contém palavras, está vazio1, não está vazio1

Cadeias de texto multi-linhas (PlainText)

contém palavras, não contém palavras, está vazio1, não está vazio1

Texto único (String)

= , <> , > " <>= , <= = = [campo], <>[campo], >[campo], <[campo], >=[campo], <=[campo], contém, não contém, não contém, não em grupo, não no grupo, não no grupo, foi sempre
Macros: [Any], válido com o campo Tipo de Item de Trabalho
Projeto2, válido com o campo Team Project

Nota

  1. Os operadores Is Empty e Is Not Empty são suportados para Azure DevOps Server RC2 2019 e versões posteriores
  2. O @Project macro é suportado para Azure Boards e TFS 2015.1 e versões posteriores. O sistema falha automaticamente na filtragem com base no projeto atual. Para saber mais, consulte a Consulta através de projetos.

Filtros úteis

Filtro para

Incluir estas cláusulas de consulta

Casos de teste automatizados

        Work Item Type = Test Case And Automation Status = Automated

Suítes de teste baseadas em consultas

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

Suítes de ensaio baseadas em requisitos

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

Listar bugs e os casos de teste que os testam

Abra uma nova consulta, desabrocha o tipo de consulta para itens de trabalho e links diretos. Filtrar para insetos no nível superior e adicionar o filtro para caixas de teste no filtro de artigos de trabalho ligados.

Listar bugs e os casos de teste que os testam

Nota

Não é possível construir uma consulta que mostre uma visão hierárquica de planos de teste, suítes de teste e testes. Estes itens não estão ligados entre si usando tipos de ligação pai-filho. Pode ver a hierarquia através da página 'Planos de Teste>'.

Construir e testar campos de dados

A tabela a seguir descreve os campos definidos num ou mais wits de teste. Para obter informações sobre tipos de dados e atributos de campo, consulte os campos e atributos de produto de trabalho.

Para personalizar um campo ou lista de escolhas, consulte Adicionar ou modificar um campo para suportar consultas, relatórios e fluxo de trabalho.

Nome do campo

Descrição

Tipo de artigo de trabalho


Estado de Automação 1

O estado de um caso de teste. Pode especificar os seguintes valores:

Caso de Teste

Encontrado em 2

Número de construção do produto, também conhecido como uma revisão, em que um bug foi encontrado.
Nome de referência=Microsoft.VSTS.Build.FoundIn, Data type=String

Nota

Também pode utilizar o tipo de ligação encontrada na construção para ligar um item de trabalho a uma construção. Este tipo de ligação está disponível a partir de Azure DevOps e só funciona com os processos de construção atuais (não as construções XAML).

Inseto

Construção de Integração 2

Número de construção do produto que incorpora o código ou corrige um bug.
Nome de referência=Microsoft.VSTS.Build.IntegrationBuild, Data type=String

Nota

Também pode utilizar o tipo integrado de ligação de construção para ligar um item de trabalho a uma construção. Este tipo de ligação está disponível a partir de Azure DevOps e só funciona com os processos de construção atuais (não as construções XAML).

Todos

Problema

Indica que os Passos Partilhados estão associados a um resultado esperado. Os valores permitidos são Sim e Não. Nome de referência=Microsoft.VSTS.Common.Issue, Data type=String

Passos Compartilhados

Parâmetros 3

Contém os parâmetros a utilizar durante a execução de um teste manual.
Microsoft.VSTS.TCM.Parâmetros, Data type=HTML

Parâmetros compartilhados, passos compartilhados, caso de teste

Passos

Os passos de ação e validação necessários para executar o teste. Microsoft.VSTS.TCM.Steps, Data type=HTML

Passos compartilhados, caso de teste

Informações do Sistema

Informação sobre o software e configuração do sistema que é relevante para o teste.
Microsoft.VSTS.TCM.SystemInfo, Data type=HTML

Bug, Resposta ao Feedback

Passos repro (ou passos para reproduzir)

Os passos que são necessários para reproduzir comportamentos inesperados. Capture informações suficientes para que outros membros da equipa possam entender o impacto total do problema e se eles corrigiram o bug. Isto inclui ações tomadas para encontrar ou reproduzir o bug e o comportamento esperado. Nome de referência=Microsoft.VSTS.TCM.ReproSteps, Data type=HTML

Inseto

Suíte de teste Tipo 1,4

A categoria de suíte de teste. Os valores permitidos são:

  • Base de consulta: Utilize para agrupar casos de teste que tenham uma característica particular - por exemplo, todos os testes que têm Prioridade=1. A suíte incluirá automaticamente todos os casos de teste que são devolvidos pela consulta que define.
  • Estática: Utilize para agrupar caixas de teste destinadas a acompanhar o estado de teste dos itens de atraso. Cada caso de teste que adiciona a um conjunto de teste baseado em requisitos está automaticamente ligado ao item de atraso.
  • Base de requisitos: Utilize para agrupar caixas de teste com quaisquer características ou suítes de teste.
    Para obter mais informações, consulte Criar um plano de teste.
    Nome de referência=Microsoft.VSTS.TCM.TestSuiteType, Data type=String

Suíte de Teste

Nota

  1. Não personalize a lista de escolhas para estes campos. O sistema aceita apenas os valores listados.
  2. Ao adicionar um GLOBALLIST elemento à FIELD definição, pode fornecer um menu suspenso de construções que os utilizadores podem escolher. Para saber como, consulte Builds e a lista global de auto-população mais tarde neste artigo.
  3. Exige que a versão TFS 2013.2 ou posterior seja instalada no servidor de nível de aplicação e que os projetos existentes sejam atualizados para suportar Parâmetros Partilhados. Para saber mais, consulte as funcionalidades configurar após uma atualização TFS.
  4. Exige que a versão TFS 2013.3 ou versão posterior seja instalada no servidor de nível de aplicação e os projetos existentes sejam atualizados para apoiar o Plano de Teste e a Suite de Teste. Para saber mais, consulte as funcionalidades configurar após uma atualização TFS.

Outros campos

Os seguintes campos não aparecem nos formulários de produto de trabalho, mas estes campos são rastreados para casos de teste ou suítes de teste. Pode utilizar alguns destes campos para filtrar consultas e criar relatórios. (Nenhum destes campos é adicionado ao armazém de dados nem indexado.)

Nome do campo

Descrição

Tipo de artigo de trabalho

Armazenamento automatizado de testes

A montagem que contém o teste que automatiza a caixa de teste.

Nome de referência=Microsoft.VSTS.TCM.AutomatedTestStorage, Data type=String

Caso de Teste

Tipo de teste automatizado

O tipo de teste que automatiza a caixa de teste.

Nome de referência=Microsoft.VSTS.TCM.AutomatedTestType, Data type=String

Caso de Teste

Teste Automatizado

A identificação do teste que automatiza o caso do teste.

Nome de referência=Microsoft.VSTS.TCM.AutomatedTestId, Data type=String

Caso de Teste

Nome automatizado Deteste

O nome do teste que é usado para automatizar a caixa de teste.

Nome de referência=Microsoft.VSTS.TCM.AutomatedTestName, Data type=String

Caso de Teste

Fonte local de Dados

A fonte de dados local que suporta o teste.

Nome de referência=Microsoft.VSTS.TCM.LocalDataSource, Data type=HTML

Caso de Teste

Texto de consulta

Campo usado para capturar a consulta definida para um tipo de suite baseada em consulta.

Nome de referência=Microsoft.VSTS.TCM.QueryText, Data type=PlainText

Suíte de Teste

Auditoria de Suíte de Teste 1

Rastreia outras operações executadas ao modificar uma suíte de teste, por exemplo: adicionar testes a uma suíte de teste ou alterar configurações. Este campo pode ser visto através do separador Histórico ou através de uma consulta separada. Haverá uma visão de história combinada, incluindo alterações feitas no campo de itens de trabalho e alterações resultantes de artefactos relacionados, tais como pontos de teste e configurações.

Nome de referência=Microsoft.VSTS.TCM.TestSuiteAudit, Data type=PlainText

Suíte de Teste

Suíte de teste ID 1, 2

Um valor atribuído ao sistema que corresponde à categoria de suíte de teste e que só é aplicável às suítes de teste. Os valores atribuídos são:

  • 1 (Estática)

  • 2 (à base de consultas)

  • 3 (Baseado em Requisitos)

Nome de referência=Microsoft.VSTS.TCM.TestSuiteTypeId, Data type=Inteiro

Suíte de Teste

Nota

  1. Exige que a versão TFS 2013.3 ou versão posterior seja instalada no servidor de nível de aplicação e os projetos existentes sejam atualizados para apoiar o Plano de Teste e a Suite de Teste.
  2. Não personalize a lista de escolhas para estes campos. O sistema aceita apenas os valores listados.

Campos que se integram com a Team Foundation Build

Team Foundation Build é o sistema de construção no local que você pode usar com Azure DevOps Server e TFS. Você pode configurar o seu processo de construção usando Team Foundation Build, e Team Foundation Build pode gerar itens de trabalho quando uma construção falha. Também pode adicionar informação de construção a itens de trabalho que foram resolvidos numa determinada construção. Para que isto funcione, a Team Foundation Build exige que sejam adicionados os dois campos seguintes à definição do tipo de artigo de trabalho: Encontrados e IntegraçãoBuild.

Os campos encontrados e integrados em build são definidos para Bugs nos processos padrão. Estes campos associam insetos às construções onde foram encontrados ou fixos.

Pode utilizar o seguinte corte de código para adicionar estes campos a uma definição de 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>

Quando o campo Found In está presente numa definição de WIT, a Team Foundation Build cria um item de trabalho quando uma construção falha, e define o campo Found In para o número de construção que falhou. Se o campo Found In faltar, a Team Foundation Build não cria um item de trabalho para a construção falhada, e tudo o resto funciona como esperado.

Quando o campo De Construção de Integração está presente na definição de WIT, a Team Foundation Build identifica itens de trabalho que foram resolvidos a cada construção e, em seguida, atualiza esses itens de trabalho para definir o número de construção em que foram resolvidos no campo Build Integration . Se o campo De Construção de Integração estiver em falta, a Team Foundation Build não armazena o número de construção nos itens de trabalho, e tudo o resto funciona como esperado.

Construções e autopopulação de lista global

A primeira vez que faz fila para um projeto que usa a Team Foundation Build, a TFS adiciona automaticamente uma lista global com a marca Build - ProjectName. Cada vez que uma construção é executada, um LISTITEM é adicionado a esta lista global com o nome da construção.

Ao adicionar um elemento GLOBALLIST à definição FIELD , pode fornecer um menu suspenso de construções que os utilizadores podem escolher. Por exemplo:

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

Campos que se integram com planos de teste

Com planos de teste, pode automatizar a criação de um bug ou outro tipo de produto de trabalho quando um teste falha. Para obter mais informações, consulte adicionar as descobertas aos bugs existentes com testes exploratórios.

Quando um item de trabalho foi criado desta forma, as informações sobre o sistema e os passos para reproduzir o bug são capturados nos campos Informação do Sistema e Passos Repro .

Pode adicionar estes campos aos tipos de produto de trabalho que cria para rastrear defeitos utilizando o seguinte corte de código.

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

Campos que se integram com o Team Foundation Version Control

Uma das funcionalidades disponíveis no controlo da versão da Team Foundation (TFVC) permite-lhe associar ou resolver itens de trabalho quando fizer o check-in no código. Pode ter trabalhado num determinado item de trabalho quando escoda uma alteração de código e pode definir essa associação a partir da janela de check-in de controlo de origem quando terminar de trabalhar no código.

A capacidade do controlo da versão da Team Foundation para resolver um item de trabalho requer que os itens de trabalho contenham uma determinada ação. O sistema de controlo de origem consulta então o rastreio de item para determinar se o item de trabalho suporta essa ação, e se apoia essa ação, também questiona os estados de origem e destino da transição. Se a ação for encontrada, o sistema de controlo de origem pode transitar o produto de trabalho de acordo com a transição definida quando verifica o código.

Nota

Quando utilizar a ação Checkin , deve definir o apropriado de e para os Estados para refletir a transição do Estado que deseja.

Para obter mais informações sobre Ações, consulte atribuições de campo automatizada com base no Estado, Transição ou Razão.