Erstellen einer Abfrage basierend auf Build- und Testintegrationsfeldern

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

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

  • Zuordnen von Fehlern zu den Builds, in denen sie gefunden oder behoben wurden
  • Abfragen von Fehlern im Zusammenhang mit einem Build
  • Markieren sie Testfälle als manuell oder automatisiert, und speichern Sie Informationen, um automatisierte Testfälle zu unterstützen.
  • Definieren Sie für Testfälle und freigegebene Schritte die Aktions- und Validierungsschritte sowie die Daten, die zum Ausführen von Tests verwendet werden.

Unterstützte Operatoren und Makros

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

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 Is Empty Operatoren und Is Not Empty werden für Azure DevOps Server RC2-Versionen 2019 und höher unterstützt.

Einzelner Text (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 . Das System filtert standardmäßig automatisch basierend auf dem aktuellen Projekt. Weitere Informationen finden Sie unter Projektübergreifende Abfrage.

Nützliche Filter

Filtern nach

Einschließen dieser 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, in denen sie getestet werden

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

Auflisten von Fehlern und Testfällen, in denen sie getestet werden

Hinweis

Sie können keine Abfrage erstellen, die eine hierarchische Ansicht von Test Plans, Testsammlungen und Testfällen anzeigt. Diese Elemente werden nicht mithilfe von übergeordneten und untergeordneten Linktypen miteinander verknüpft. Sie können die Hierarchie über die Seite Test> Test Plans 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 eines Felds oder einer Auswahlliste finden Sie unter Hinzufügen oder Ändern eines Felds zur Unterstützung von Abfragen, Berichten und Workflow.

Feldname

Beschreibung

Arbeitsaufgabentyp


Automatisierungsstatus 1

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

Testfall

Gefunden in 2

Die Produktbuildnummer bzw. die Revision, in der ein Fehler gefunden wurde.
Referenzname=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.
Referenzname=Microsoft.VSTS.Build.IntegrationBuild, Datentyp=Zeichenfolge

Hinweis

Sie können auch den Linktyp Integriert in Build 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).

All

Problem

Gibt an, dass die freigegebenen Schritte einem erwarteten Ergebnis zugeordnet sind. Zulässige Werte sind Ja und Nein. Referenzname=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 Schritte, Testfall

Schritte

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

Freigegebene Schritte, Testfall

Systeminfo

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

Fehler, Feedbackantwort

Repro-Schritte (oder zu reproduzierende Schritte)

Die erforderlichen Schritte zum Reproduzieren des unerwarteten Verhaltens. Erfassen Sie genügend Informationen, damit andere Teammitglieder die auswirkungen des Problems vollständig nachvollziehen können und ob sie den Fehler behoben haben. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens. Referenzname=Microsoft.VSTS.TCM.ReproSteps, Datentyp=HTML

Bug

Test Suite Typ 1

Die Testsammlungskategorie. Zulässige Werte sind:

  • Abfragebasiert: Verwenden Sie zum Gruppieren von Testfällen, die ein bestimmtes Merkmal aufweisen, z. B. alle Tests mit Priority=1. Die Sammlung umfasst automatisch jeden Testfall, der von der definierten Abfrage zurückgegeben wird.
  • Anforderungsbasiert: Verwenden Sie zum Gruppieren von Testfällen, die zum Nachverfolgen des Teststatus von Backlogelementen konzipiert sind. Jeder Testfall, den Sie einer anforderungsbasierten Testsammlung hinzufügen, wird automatisch mit dem Backlogelement verknüpft.
  • Statisch: Verwenden Sie zum Gruppieren von Testfällen mit beliebigen Merkmalen oder Testsammlungen.
    Weitere Informationen finden Sie unter Erstellen eines Testplans.
    Referenzname=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. Durch Hinzufügen eines GLOBALLIST Elements zur FIELD Definition können Sie ein Dropdownmenü mit Builds bereitstellen, aus denen Benutzer auswählen können. Weitere Informationen hierzu finden Sie weiter unten in diesem Artikel unter Builds und automatisches Auffüllen globaler Listen .

Weitere Felder

Die folgenden Felder werden nicht in Arbeitselementformularen angezeigt, aber diese Felder werden 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.

Referenzname=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.

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

Testfall

AutomatedTestName

Der Name des Tests, der den Testfall automatisiert.

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

Testfall

LocalDataSource

Die lokale Datenquelle, die den Test unterstützt.

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

Testfall

Abfragetext

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

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

Testsammlung

Testsuiteüberwachung

Verfolgt andere Vorgänge, die beim Ändern einer Testsuite ausgeführt werden, z. B. das Hinzufügen von Tests zu einer Testsuite oder das Ändern von Konfigurationen. Dieses Feld kann über die Registerkarte "Verlauf" oder mittels einer gesonderten Abfrage angezeigt werden. Es wird eine kombinierte Verlaufsansicht vorhanden sein, einschließlich Änderungen am Feld für Arbeitselemente und Änderungen, die sich aus verwandten Artefakten wie Testpunkten und Konfigurationen ergeben.

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

Testsammlung

Test Suite-Typ-ID 1

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

  • 1 (Statisch)

  • 2 (abfragebasiert)

  • 3 (Anforderungsbasiert)

Referenzname=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 der Definition des Arbeitselementtyps die folgenden beiden Felder hinzugefügt werden: Found In und Integration Build.

Die Felder Found In und Integrated in Build 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 Found In in einer WIT-Definition vorhanden ist, erstellt Team Foundation Build ein Arbeitselement, wenn ein Build fehlschlägt, und legt das Feld Found In auf die Buildnummer des Builds fest, bei dem ein Fehler aufgetreten ist. Wenn das Feld Gefunden in fehlt, erstellt Team Foundation Build kein Arbeitselement für den fehlerhaften Build, und alles andere funktioniert wie erwartet.

Wenn das Feld Integration Build in der WIT-Definition vorhanden ist, identifiziert Team Foundation Build Arbeitselemente, die mit jedem Build aufgelöst wurden, und aktualisiert dann diese Arbeitselemente, um die Buildnummer festzulegen, in der sie im Feld Integration Build aufgelöst wurden. Wenn das Feld Integration Build fehlt, speichert Team Foundation Build die Buildnummer nicht in den Arbeitselementen, und alles andere funktioniert wie erwartet.

Builds und globale Listenautopopulation

Wenn Sie zum ersten Mal einen Build für ein Projekt mithilfe von Team Foundation Build in die Warteschlange stellen, fügt TFS automatisch eine globale Liste mit der Bezeichnung Build - ProjectName hinzu. Jedes Mal, wenn ein Build ausgeführt wird, wird dieser globalen Liste ein LISTITEM mit dem Namen des Builds hinzugefügt.

Durch Hinzufügen eines GLOBALLIST-Elements zur FIELD-Definition können Sie ein Dropdownmenü mit Builds bereitstellen, aus denen Benutzer auswä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 Arbeitselementtyps automatisieren, wenn ein Test fehlschlägt. 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 über das System und die Schritte zum Reproduzieren des Fehlers in den Feldern Systeminformationen und Reproschritte 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

Eines der in der Team Foundation-Versionskontrolle (TFVC) verfügbaren Features ermöglicht ihnen das Zuordnen oder Auflösen von Arbeitselementen beim Einchecken von Code. Möglicherweise haben Sie an einem bestimmten Arbeitselement gearbeitet, wenn Sie eine Codeänderung vornehmen, und Sie können diese Zuordnung im Eincheckfenster der Quellcodeverwaltung festlegen, wenn Sie mit der Arbeit am Code fertig sind.

Die Fähigkeit der Team Foundation-Versionskontrolle zum Auflösen eines Arbeitselements erfordert, dass Arbeitselemente eine bestimmte 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

Wenn Sie die Checkin-Aktion verwenden, müssen Sie geeignete von und auf Zustände festlegen, um den gewünschten Zustandsübergang widerzuspiegeln.

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