Creare una query basata su campi di integrazione di compilazione e test

  • Articolo

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

I campi dell'elemento di lavoro che supportano l'integrazione di compilazioni e test supportano le azioni seguenti:

  • Associare bug alle compilazioni in cui sono stati trovati o corretti
  • Eseguire una query per individuare i bug associati a una compilazione
  • Contrassegnare i test case come manuali o automatizzati e archiviare le informazioni per supportare i test case automatizzati
  • Per i test case e i passaggi condivisi, definire i passaggi di azione e convalida e i dati usati per eseguire i test.

Operatori e macro supportati

La maggior parte dei campi di integrazione di compilazione e test ha un tipo di dati String, PlainText o HTML. Le clausole di query che specificano un campo di testo o RTF possono usare gli operatori e le macro elencate nella tabella seguente.

Tipo di dati

Operatori e macro supportati

RTF (HTML) e
Stringhe di testo a più righe (Testo normale)

Contains Words, Does Not Contain Words, Is EmptyIs Not Empty.
Gli Is Empty operatori e Is Not Empty sono supportati per Azure DevOps Server 2019 RC2 e versioni successive.

Testo singolo (stringa)

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, InNot In, In Group, , Not In GroupWas Ever
Macro: [Any], valido con il campo Tipo elemento di lavoro e @Project, valido con il campo Progetto team. Per impostazione predefinita, il sistema applica automaticamente il filtro in base al progetto corrente. Per altre informazioni, vedere Query tra progetti.

Filtri utili

Filtro per

Includere queste clausole di query

Test case automatizzati

        Work Item Type = Test Case And Automation Status = Automated

Gruppi di test basati su query

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

Gruppi di test basati sui requisiti

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

Elencare i bug e i test case che li testano

Aprire una nuova query, impostare il tipo di query su Elementi di lavoro e collegamenti diretti. Filtrare i bug nel livello superiore e aggiungere il filtro per i test case nel filtro degli elementi di lavoro collegati.

Elencare i bug e i test case che li testano

Nota

Non è possibile costruire una query che mostra una visualizzazione gerarchica dei piani di test, dei gruppi di test e dei test case. Questi elementi non vengono collegati insieme usando tipi di collegamento padre-figlio. È possibile visualizzare la gerarchia tramite la pagina Test Test Plans .You can view the hierarchy through the Test Test>Plans page.

Campi dati di compilazione e test

Nella tabella seguente vengono descritti i campi definiti in uno o più wit di test. Per informazioni sui tipi di dati e sugli attributi dei campi, vedere Campi e attributi dell'elemento di lavoro.

Per personalizzare un campo o un elenco a discesa, vedere Aggiungere o modificare un campo per supportare query, report e flusso di lavoro.

Nome campo

Descrizione

Tipo di elemento di lavoro

Stato automazione 1

Stato di un test case. È possibile specificare i valori seguenti:

  • Automatizzato
  • Non automatizzato
  • Pianificato
    Per eseguire test automatizzati, vedere Eseguire test automatizzati dai piani di test.
    Reference name=Microsoft.VSTS.TCM.AutomationStatus, Data type=String

Test case

Trovato in 2

Numero di build del prodotto, noto anche come revisione, in cui è stato trovato un bug.
Nome di riferimento=Microsoft.VSTS.Build.FoundIn, Tipo di dati=String

Nota

È anche possibile usare il tipo di collegamento Trovato nella compilazione per collegare un elemento di lavoro a una compilazione. Questo tipo di collegamento è disponibile in Azure DevOps e funziona solo con i processi di compilazione correnti (non con compilazioni XAML).

Bug

Compilazione integrazione 2

Numero di build del prodotto che incorpora il codice o corregge un bug.
Nome di riferimento=Microsoft.VSTS.Build.IntegrationBuild, Tipo di dati=String

Nota

È anche possibile usare il tipo di collegamento Integrato nella compilazione per collegare un elemento di lavoro a una compilazione. Questo tipo di collegamento è disponibile in Azure DevOps e funziona solo con i processi di compilazione correnti (non con compilazioni XAML).

Tutte le date

Problema

Indica che i passaggi condivisi sono associati a un risultato previsto. I valori consentiti sono Sì e No. Nome di riferimento=Microsoft.VSTS.Common.Issue, Tipo di dati=String

Passaggi condivisi

Parametri

Contiene i parametri da usare durante l'esecuzione di un test manuale.
Microsoft.VSTS.TCM.Parameters, Data type=HTML

Parametri condivisi, passaggi condivisi, test case

Passaggi

Passaggi di azione e convalida necessari per eseguire il test. Microsoft.VSTS.TCM.Steps, Tipo di dati=HTML

Passaggi condivisi, test case

Informazioni di sistema

Informazioni sul software e sulla configurazione del sistema rilevanti per il test.
Microsoft.VSTS.TCM.SystemInfo, Data type=HTML

Bug, Risposta commenti e suggerimenti

Passaggi di riproduzione (o passaggi da riprodurre)

Passaggi necessari per riprodurre un comportamento imprevisto. Acquisire informazioni sufficienti in modo che altri membri del team possano comprendere l'impatto completo del problema e se hanno risolto il bug. Sono incluse le azioni eseguite per trovare o riprodurre il bug e il comportamento previsto. Nome di riferimento=Microsoft.VSTS.TCM.ReproSteps, Data type=HTML

Bug

Test Suite Type 1

Categoria del gruppo di test. I valori consentiti sono i seguenti:

  • Basato su query: usare per raggruppare i test case con una particolare caratteristica, ad esempio tutti i test con Priority=1. La famiglia di prodotti include automaticamente ogni test case restituito dalla query definita.
  • Basato sui requisiti: usare per raggruppare i test case progettati per tenere traccia dello stato di test degli elementi backlog. Ogni test case aggiunto a un gruppo di test basato sui requisiti viene collegato automaticamente all'elemento backlog.
  • Statico: usare per raggruppare i test case con eventuali caratteristiche o gruppi di test.
    Per altre informazioni, vedere Creare un piano di test.
    Nome di riferimento=Microsoft.VSTS.TCM.TestSuiteType, Data type=String

Gruppo di test

Nota

  1. Non personalizzare l'elenco di selezione per questi campi. Il sistema accetta solo i valori elencati.
  2. Aggiungendo un GLOBALLIST elemento alla definizione, è possibile fornire un menu a FIELD discesa di compilazioni tra cui gli utenti possono scegliere. Per informazioni su come, vedere Compilazioni e popolamento automatico elenco globale più avanti in questo articolo.

Altri campi

I campi seguenti non vengono visualizzati nei moduli degli elementi di lavoro, ma questi campi vengono rilevati per i test case o i gruppi di test. È possibile usare alcuni di questi campi per filtrare le query e creare report. Nessuno di questi campi viene aggiunto al data warehouse né indicizzato.

Nome campo

Descrizione

Tipo di elemento di lavoro

Archiviazione di test automatizzata

Assembly contenente il test che automatizza il test case.

Nome di riferimento=Microsoft.VSTS.TCM.AutomatedTestStorage, Data type=String

Test case

Tipo di test automatizzato

Tipo di test che automatizza il test case.

Nome di riferimento=Microsoft.VSTS.TCM.AutomatedTestType, Data type=String

Test case

AutomatedTestId

ID del test che automatizza il test case.

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

Test case

AutomatedTestName

Nome del test usato per automatizzare il test case.

Nome di riferimento=Microsoft.VSTS.TCM.AutomatedTestName, Data type=String

Test case

LocalDataSource

Origine dati locale che supporta il test.

Nome di riferimento=Microsoft.VSTS.TCM.LocalDataSource, Data type=HTML

Test case

Testo query

Campo usato per acquisire la query definita per un tipo di suite basato su query.

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

Gruppo di test

Test Suite Audit

Tiene traccia delle altre operazioni eseguite durante la modifica di un gruppo di test, ad esempio l'aggiunta di test a un gruppo di test o la modifica delle configurazioni. Questo campo può essere visualizzato tramite la scheda Cronologia o tramite una query separata. È disponibile una visualizzazione cronologia combinata, incluse le modifiche apportate al campo degli elementi di lavoro e le modifiche risultanti da elementi correlati, ad esempio punti di test e configurazioni.

Nome di riferimento=Microsoft.VSTS.TCM.TestSuiteAudit, Data type=PlainText

Gruppo di test

Test Suite Type ID 1

Valore assegnato dal sistema che corrisponde alla categoria del gruppo di test e applicabile solo ai gruppi di test. I valori assegnati sono:

  • 1 (statico)

  • 2 (basato su query)

  • 3 (basato sui requisiti)

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

Gruppo di test

Nota

  1. Non personalizzare l'elenco di selezione per questi campi. Il sistema accetta solo i valori elencati.

Campi che si integrano con Team Foundation Build

Team Foundation Build è il sistema di compilazione locale che è possibile usare con Azure DevOps Server e TFS. È possibile configurare il processo di compilazione usando Team Foundation Build e Team Foundation Build può generare elementi di lavoro in caso di errore di compilazione. Può anche aggiungere informazioni di compilazione agli elementi di lavoro risolti in una determinata compilazione. Per il corretto funzionamento, Team Foundation Build richiede che i due campi seguenti vengano aggiunti alla definizione del tipo di elemento di lavoro: Trovato in e Compilazione integrazione.

I campi In e Integrated in Build sono definiti per Bug nei processi predefiniti. Questi campi associano bug alle compilazioni in cui sono stati trovati o corretti.

È possibile usare il frammento di codice seguente per aggiungere questi campi a una definizione di 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 il campo Trovato in è presente in una definizione WIT, Team Foundation Build crea un elemento di lavoro quando una compilazione ha esito negativo e imposta il campo Trovato in sul numero di build non riuscito. Se il campo Trovato in non è presente, Team Foundation Build non crea un elemento di lavoro per la compilazione non riuscita e tutto il resto funziona come previsto.

Quando il campo Compilazione integrazione è presente nella definizione WIT, Team Foundation Build identifica gli elementi di lavoro risolti con ogni compilazione e quindi aggiorna tali elementi di lavoro per impostare il numero di build in cui sono stati risolti nel campo Compilazione integrazione. Se il campo Compilazione integrazione non è presente, Team Foundation Build non archivia il numero di build negli elementi di lavoro e tutto il resto funziona come previsto.

Compilazioni e popolamento automatico elenco globale

La prima volta che si accoda una compilazione per un progetto usando Team Foundation Build, TFS aggiunge automaticamente un elenco globale con etichetta Build - ProjectName. Ogni volta che viene eseguita una compilazione, un listITEM viene aggiunto a questo elenco globale con il nome della compilazione.

Aggiungendo un elemento GLOBALLIST alla definizione FIELD , è possibile fornire un menu a discesa di compilazioni tra cui gli utenti possono scegliere. Ad esempio:

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

Campi che si integrano con i piani di test

Con i piani di test è possibile automatizzare la creazione di un bug o di un altro tipo di elemento di lavoro quando un test ha esito negativo. Per altre informazioni, vedere Aggiungere risultati a bug esistenti con test esplorativi.

Quando un elemento di lavoro è stato creato in questo modo, le informazioni sul sistema e i passaggi per riprodurre il bug vengono acquisiti nei campi Informazioni di sistema e Passaggi di riproduzione.

È possibile aggiungere questi campi ai tipi di elemento di lavoro creati per rilevare i difetti usando il frammento di codice seguente.

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

Campi che si integrano con controllo della versione di Team Foundation

Una delle funzionalità disponibili nel controllo della versione di Team Foundation consente di associare o risolvere gli elementi di lavoro quando si esegue la archiviazione del codice. È possibile che si sia lavorato su un particolare elemento di lavoro quando si apporta una modifica al codice ed è possibile impostare tale associazione dall'interno della finestra di archiviazione del controllo del codice sorgente al termine dell'utilizzo del codice.

La possibilità di controllare la versione di Team Foundation per risolvere un elemento di lavoro richiede che gli elementi di lavoro contengano un'azione specifica. Il sistema di controllo del codice sorgente esegue quindi una query sul rilevamento degli elementi di lavoro per determinare se l'elemento di lavoro supporta tale azione e, se supporta tale azione, esegue query anche per gli stati di origine e di destinazione della transizione. Se l'azione viene trovata, il sistema di controllo del codice sorgente può eseguire la transizione dell'elemento di lavoro in base alla transizione impostata quando controlla il codice.

Nota

Quando si usa l'azione Checkin , è necessario impostare gli stati appropriati da e su per riflettere la transizione di stato desiderata.

Per altre informazioni sulle azioni, vedere Automatizzare le assegnazioni dei campi in base allo stato, alla transizione o al motivo.