Erstellen einer Abfrage basierend auf Build- und Testintegrationsfeldern

  • Artikel

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

Arbeitselementfelder, die die Build- und Testintegration unterstützen, unterstützen die folgenden Aktionen:

  • Zuordnen von Fehlern zu den Builds, in denen sie gefunden oder korrigiert wurden
  • Abfragen von Fehlern im Zusammenhang mit einem Build
  • Markieren von Testfällen als manuell oder automatisiert, und Speichern von Informationen zur Unterstützung automatisierter Testfälle
  • Für Testfälle und freigegebene Schritte: Definieren der Aktion und der Validierungsschritte sowie der Daten, mit denen die Tests durchgeführt werden.

Unterstützte Operatoren und Makros

Die meisten Build- und Testintegrationsfelder weisen den Datentyp String, PlainText oder HTML auf. In Abfrageklauseln mit einem Text- oder Rich-Text-Feld können die in der folgenden Tabelle aufgeführten Operatoren und Makros verwendet werden.

Datentyp

Unterstützte Operatoren und Makros

Rich-Text (HTML) und
Mehrzeilige Textzeichenfolgen (PlainText)

Contains Words, Does Not Contain Words, Is Empty, Is Not Empty.
Die Operatoren Is Empty und Is Not Empty werden für Azure DevOps Server 2019 RC2 und höher unterstützt.

Einzelne Textzeichenfolge (String)

= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, In, Not In, In Group, Not In Group, Was Ever
Makros: [Any], gültig mit dem Feld Arbeitselementtyp, und @Project, gültig mit dem Feld Teamprojekt Standardmäßig filtert das System automatisch basierend auf dem aktuellen Projekt. Weitere Informationen finden Sie unter Projektübergreifende Abfrage.

Nützliche Filter

Filtern nach

Einzuschließende Abfrageklauseln

Automatisierte Testfälle

        Work Item Type = Test Case And Automation Status = Automated

Abfragebasierte Testsammlungen

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

Anforderungsbasierte Testsammlungen

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

Auflisten von Fehlern und Testfällen, die sie testen

Öffnen Sie eine neue Abfrage, und legen Sie den Abfragetyp auf „Arbeitselemente“ und direkte Verknüpfungen fest. Filtern Sie auf der obersten Ebene nach Fehlern, und fügen Sie den Filter für Testfälle im Filter für verknüpfte Arbeitselemente hinzu.

Auflisten von Fehlern und Testfällen, die sie testen

Hinweis

Sie können keine Abfrage erstellen, die eine hierarchische Ansicht von Testplänen, Testsammlungen und Testfällen anzeigt. Diese Elemente werden nicht mithilfe von über- und untergeordneten Linktypen miteinander verknüpft. Sie können die Hierarchie über die Seite Test>Testpläne anzeigen.

Erstellen und Testen von Datenfeldern

In der folgenden Tabelle werden die Felder beschrieben, die in mindestens einem Test-Arbeitsaufgabentyp (WIT) definiert sind. Informationen zu Datentypen und Feldattributen finden Sie unter Arbeitselementfelder und -attribute.

Informationen zum Anpassen einer Feld- oder Auswahlliste finden Sie unter Hinzufügen oder Ändern eines Felds, um Abfragen, Berichte und Workflow zu unterstützen.

Feldname

Beschreibung

Arbeitsaufgabentyp

Automatisierungsstatus 1

Der Status eines Testfalls. Sie können folgende Werte angeben:

Testfall

Gefunden in 2

Die Produktbuildnummer bzw. die Revision, in der ein Fehler gefunden wurde.
Verweisname=Microsoft.VSTS.Build.FoundIn, Datentyp=Zeichenfolge

Hinweis

Sie können auch den Linktyp Im Build gefunden verwenden, um ein Arbeitselement mit einem Build zu verknüpfen. Dieser Linktyp ist in Azure DevOps verfügbar und funktioniert nur mit den aktuellen Buildprozessen (nicht mit XAML-Builds).

Bug

Integrationsbuild 2

Die Produktbuildnummer, in der der Code enthalten ist oder ein Fehler behoben wird.
Verweisname=Microsoft.VSTS.Build.IntegrationBuild, Datentyp=Zeichenfolge

Hinweis

Sie können auch den Linktyp In den Build integriert verwenden, um ein Arbeitselement mit einem Build zu verknüpfen. Dieser Linktyp ist in Azure DevOps verfügbar und funktioniert nur mit den aktuellen Buildprozessen (nicht mit XAML-Builds).

Alle

Problem

Gibt an, dass den freigegebenen Testschritten ein erwartetes Ergebnis zugeordnet ist. Zulässige Werte sind Ja und Nein. Verweisname=Microsoft.VSTS.Common.Issue, Datentyp=Zeichenfolge

Freigegebene Schritte

Parameter

Enthält die Parameter, die bei der Ausführung eines manuellen Tests zu verwenden sind.
Microsoft.VSTS.TCM.Parameters, Datentyp=HTML

Freigegebene Parameter, freigegebene Testschritte, Testfall

Schritte

Die Aktion und die Validierungsschritte, die zum Durchführen des Tests erforderlich sind. Microsoft.VSTS.TCM.Steps, Datentyp=HTML

Freigegebene Testschritte, Testfall

Systeminfo

Informationen über die für den Test relevante Software- und Systemkonfiguration.
Microsoft.VSTS.TCM.SystemInfo, Datentyp = HTML

Fehler, Feedbackantwort

Reproduktionsschritte (oder „Zu reproduzierende Schritte“)

Die erforderlichen Schritte zum Reproduzieren des unerwarteten Verhaltens. Zeichnen Sie ausreichende Informationen auf, sodass andere Teammitglieder sowohl die vollständigen Auswirkungen des Problems verstehen als auch sicherstellen können, dass der Fehler behoben wurde. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens. Verweisname=Microsoft.VSTS.TCM.ReproSteps, Datentyp=HTML

Bug

Testsammlungstyp 1

Die Testsammlungskategorie. Zulässige Werte sind:

  • Abfragebasiert: dient dem Gruppieren von Testfällen, die ein bestimmtes Merkmal aufweisen, beispielsweise alle Tests mit Priorität = 1. Die Sammlung umfasst automatisch jeden Testfall, der von der Abfrage, die Sie definieren, zurückgegeben wird.
  • Anforderungsbasiert: dient dem Gruppieren von Testfällen, die auf das Nachverfolgen des Teststatus von Backlog Items ausgelegt sind. Jeder Testfall, den Sie einer anforderungsbasierten Testsammlung hinzufügen, wird automatisch mit dem Backlogelement verknüpft.
  • Statisch: Dient dem Gruppieren von Testfällen mit beliebigen Merkmalen oder Testsammlungen.
    Weitere Informationen finden Sie unter Erstellen eines Testplans.
    Verweisname=Microsoft.VSTS.TCM.TestSuiteType, Datentyp=Zeichenfolge

Testsammlung

Hinweis

  1. Passen Sie die Auswahlliste für diese Felder nicht an. Das System akzeptiert nur diese aufgelisteten Werte.
  2. Indem Sie der GLOBALLIST-Definition ein FIELD-Element hinzufügen, können Sie ein Dropdownmenü mit Builds bereitstellen, aus denen die Benutzer*innen auswählen können. Informationen dazu finden Sie weiter unten in diesem Artikel unter Builds und automatische Auffüllung von globalen Listen.

Weitere Felder

Die folgenden Felder werden nicht in Arbeitselementformularen angezeigt, jedoch für Testfälle oder Testsammlungen nachverfolgt. Sie können einige dieser Felder verwenden, um Abfragen zu filtern und Berichte zu erstellen. (Keines dieser Felder wird dem Data Warehouse hinzugefügt oder indiziert.)

Feldname

Beschreibung

Arbeitsaufgabentyp

Speicher des automatisierten Tests

Die Assembly mit dem Test, der den Testfall automatisiert.

Verweisname=Microsoft.VSTS.TCM.AutomatedTestStorage, Datentyp=Zeichenfolge

Testfall

Typ des automatisierten Tests

Der Typ des Tests, der den Testfall automatisiert.

Verweisname=Microsoft.VSTS.TCM.AutomatedTestType, Datentyp=Zeichenfolge

Testfall

AutomatedTestId

Die ID des Tests, der den Testfall automatisiert.

Verweisname=Microsoft.VSTS.TCM.AutomatedTestId, Datentyp=Zeichenfolge

Testfall

AutomatedTestName

Der Name des Tests, der den Testfall automatisiert.

Verweisname=Microsoft.VSTS.TCM.AutomatedTestName, Datentyp=Zeichenfolge

Testfall

LocalDataSource

Die lokale Datenquelle, die den Test unterstützt.

Verweisname=Microsoft.VSTS.TCM.LocalDataSource, Datentyp=HTML

Testfall

Abfragetext

Feld für die Erfassung der für einen abfragebasierten Sammlungstyp definierten Abfrage.

Verweisname=Microsoft.VSTS.TCM.QueryText, Datentyp=PlainText

Testsammlung

Testsuiteüberwachung

Verfolgt weitere Vorgänge nach, die ausgeführt werden, wenn eine Testsammlung geändert wird (z. B. Hinzufügen von Tests zu einer Testsammlung oder Ändern von Konfigurationen). Dieses Feld kann über die Registerkarte "Verlauf" oder mittels einer gesonderten Abfrage angezeigt werden. Es gibt eine kombinierte Verlaufsansicht, einschließlich durchgeführter Änderungen am Feld „Arbeitselemente“ sowie der Änderungen, die aus zugehörigen Artefakten wie Testpunkten und Konfigurationen resultieren.

Verweisname = Microsoft.VSTS.TCM.TestSuiteAudit, Datentyp = PlainText

Testsammlung

Testsammlungstyp-ID 1

Ein vom System zugewiesener Wert, der der Testsammlungskategorie entspricht; nur anwendbar auf Testsammlungen. Zugewiesene Werte sind:

  • 1 (Statisch)

  • 2 (Abfragebasiert)

  • 3 (anforderungsbasiert)

Verweisname=Microsoft.VSTS.TCM.TestSuiteTypeId, Datentyp=Integer

Testsammlung

Hinweis

  1. Passen Sie die Auswahlliste für diese Felder nicht an. Das System akzeptiert nur diese aufgelisteten Werte.

Felder, die in Team Foundation Build integriert werden können

Team Foundation Build ist das lokale Buildsystem, das Sie mit Azure DevOps Server und TFS verwenden können. Sie können Ihren Buildprozess mithilfe von Team Foundation Build konfigurieren, und Team Foundation Build kann Arbeitselemente generieren, wenn ein Build fehlschlägt. Team Foundation Build kann auch Buildinformationen zu Arbeitsaufgaben hinzufügen, die in einem bestimmten Build aufgelöst wurden. Damit dies funktioniert, erfordert Team Foundation Build, dass die beiden folgenden Felder zur Definition des Arbeitselementtyps hinzugefügt werden: Gefunden in und Integrationsbuild.

Die Felder Gefunden in und In den Build integriert sind für Fehler in den Standardprozessen definiert. Diese Felder ordnen Fehler den Builds zu, in denen sie gefunden oder korrigiert wurden.

Sie können den folgenden Codeausschnitt verwenden, um diese Felder einer Definition des Arbeitsaufgabentyps hinzuzufügen.

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

Wenn das Feld Gefunden in in der Definition des Arbeitselementtyps vorhanden ist, erstellt Team Foundation Build bei einem Buildfehler ein Arbeitselement und legt das Feld Gefunden in auf die Buildnummer des Builds fest, bei dem der Fehler soeben aufgetreten ist. Wenn das Feld Gefunden in fehlt, erstellt Team Foundation Build kein Arbeitselement für den Build, bei dem der Fehler aufgetreten ist, und die übrigen Funktionen werden erwartungsgemäß ausgeführt.

Wenn das Feld Integrationsbuild in der Definition des Arbeitselementtyps vorhanden ist, identifiziert Team Foundation Build mit den einzelnen Builds aufgelöste Arbeitselemente und aktualisiert diese Arbeitselemente dann mit der Nummer des Builds, in dem sie aufgelöst wurden, im Feld Integrationsbuild. Wenn das Feld Integrationsbuild fehlt, speichert Team Foundation Build die Buildnummer nicht in den Arbeitselemente, und die übrigen Funktionen werden erwartungsgemäß ausgeführt.

Builds und automatische Auffüllung von globalen Listen

Wenn Sie zum ersten Mal einen Build für ein Projekt mit Team Foundation Build in eine Warteschlange stellen, fügt TFS automatisch eine globale Liste mit der Bezeichnung Build – Projektname hinzu. Bei jeder Ausführung eines Builds wird dieser globalen Liste ein LISTITEM-Element mit dem Namen des Builds hinzugefügt.

Indem Sie der FIELD-Definition ein GLOBALLIST-Element hinzufügen, können Sie ein Dropdownmenü mit Builds bereitstellen, aus denen die Benutzer*innen wählen können. Beispiel:

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

Felder, die in Test Plans integriert werden

Mit Test Plans können Sie die Erstellung eines Fehlers oder eines anderen Arbeitsaufgabentyps automatisieren, wenn bei einem Test ein Fehler auftritt. Weitere Informationen finden Sie unter Hinzufügen von Ergebnissen zu vorhandenen Fehlern mit explorativen Tests.

Wenn ein Arbeitselement auf diese Weise erstellt wurde, werden Informationen zum System und den Schritten zum Reproduzieren des Fehlers in den Feldern Systeminfo und Reproduktionsschritte erfasst.

Sie können diese Felder zu Arbeitsaufgabentypen hinzufügen, die Sie zum Nachverfolgen von Fehlern mit dem folgenden Codeausschnitt erstellen.

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

Felder, die in die Team Foundation-Versionskontrolle integriert werden können

Durch eines der in der Team Foundation-Versionskontrolle (TFVC) verfügbaren Features können Arbeitselemente beim Einchecken von Code zugeordnet oder aufgelöst werden. Wenn bei einer Codeänderung beispielsweise ein bestimmtes Arbeitselement bearbeitet wurde, können Sie diese Zuordnung innerhalb des Eincheckfensters der Quellcodeverwaltung festlegen, nachdem die Codebearbeitung abgeschlossen wurde.

Damit Arbeitselemente von der Team Foundation-Versionskontrolle aufgelöst werden können, müssen die Arbeitselemente eine besondere Aktion enthalten. Anschließend wird die Arbeitselementverfolgung vom Quellcodeverwaltungssystem abgefragt, um festzustellen, ob diese Aktion von dem Arbeitselement unterstützt wird. Falls die Aktion unterstützt wird, werden zusätzlich der Quell- und Zielzustand des Übergangs abgefragt. Wenn die Aktion gefunden wird, kann die Arbeitsaufgabe entsprechend dem festgelegten Übergang vom Quellcodeverwaltungssystem beim Einchecken des Codes umgewandelt werden.

Hinweis

Bei Verwendung der Eincheck-Aktion müssen die geeigneten Quell- und Zielzustände festgelegt werden, um die gewünschten Übergänge des Zustands widerzuspiegeln.

Weitere Informationen zu Aktionen finden Sie unter Automatisieren von Feldzuweisungen auf Grundlage von Zustand, Übergang oder Grund.