Erstellen einer Abfrage basierend auf Build- und Testintegrationsfeldern

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

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

  • Zuordnen von Fehlern zu den Builds, in denen sie gefunden oder behoben wurden
  • Abfrage nach Fehlern, die einem Build zugeordnet sind
  • Markieren von Testfällen als manuell oder automatisiert, und Speichern von Informationen zur Unterstützung automatisierter Testfälle
  • Definieren Sie für Testfälle und freigegebene Schritte die Aktions- und Validierungsschritte und die Daten, die zum Ausführen von Tests verwendet werden.

Unterstützte Operatoren und Makros

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

Datentyp

Unterstützte Operatoren und Makros


Rich-Text (HTML)

Enthält Wörter, enthält keine Wörter, ist leer1, ist nicht leer1.

Mehrzeilige Textzeichenfolgen (PlainText)

Enthält Wörter, enthält keine Wörter, ist leer1, ist nicht leer1.

Einzelner Text (Zeichenfolge)

= , <><>>< = , = [Feld], <>>[Feld], <[Feld], =[Feld], >=[Feld], <enthält, enthält nicht, nicht in, nicht in gruppe, nicht in gruppe, war jemals
Makros: [Alle], gültig mit dem Feld "Arbeitselementtyp "
Project2, gültig mit dem Teamprojektfeld

Hinweis

  1. Die Operatoren "Leer" und "Nicht leer" werden für Azure DevOps Server 2019 RC2- und höher-Versionen unterstützt.
  2. Das @Project-Makro wird für Azure Boards und TFS 2015.1 und höhere Versionen unterstützt. Das System wird automatisch basierend auf dem aktuellen Projekt gefiltert. Weitere Informationen finden Sie unter "Abfrage für alle Projekte".

Nützliche Filter

Filtern nach

Einschließen dieser Abfrageklauseln

Automatisierte Testfälle

        Work Item Type = Test Case And Automation Status = Automated

Abfragebasierte Testsuiten

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

Anforderungsbasierte Testsuiten

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

Listet Fehler und die Testfälle auf, die sie testen

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

Listet Fehler und die Testfälle auf, die sie testen

Hinweis

Sie können keine Abfrage erstellen, die eine hierarchische Ansicht von Test Plans, Testsuiten und Testfällen anzeigt. Diese Elemente werden nicht mit übergeordneten Verknüpfungstypen 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 Workflows.

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.
Referenzname=Microsoft.VSTS.Build.FoundIn, Datentyp=Zeichenfolge

Hinweis

Sie können auch den Linktyp "In Buildlink gefunden " verwenden, um ein Arbeitselement mit einem Build zu verknüpfen. Dieser Linktyp ist über 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 integrierten Buildlinktyp verwenden, um eine Arbeitsaufgabe mit einem Build zu verknüpfen. Dieser Linktyp ist über 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 3

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 Schritte zur Aktion und Überprüfung, 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 Schritte zum Reproduzieren)

Die erforderlichen Schritte zum Reproduzieren des unerwarteten Verhaltens. Erfassen Sie genügend Informationen, damit andere Teammitglieder die vollständige Auswirkung des Problems verstehen 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,4

Die Testsammlungskategorie. Zulässige Werte sind:

  • Abfragebasiert: Verwenden Sie zum Gruppieren von Testfällen, die über ein bestimmtes Merkmal verfügen– z. B. alle Tests mit Priority=1. Die Sammlung umfasst automatisch jeden Testfall, der von der definierten Abfrage zurückgegeben wird.
  • Statisch: Verwenden Sie die Verwendung zum Gruppieren von Testfällen, die zum Nachverfolgen des Teststatus von Backlogelementen entwickelt wurden. Jeder Testfall, den Sie einer anforderungsbasierten Testsammlung hinzufügen, wird automatisch mit dem Backlogelement verknüpft.
  • Anforderungsbasiert: Verwenden Sie zum Gruppieren von Testfällen mit allen Merkmalen oder Testsuiten.
    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 Definition können Sie ein Dropdownmenü mit Builds bereitstellen, aus denen FIELD Benutzer auswählen können. Informationen dazu finden Sie weiter unten in diesem Artikel unter Builds und globale Listen automatischen Populationen .
  3. Erfordert, dass TFS 2013.2 oder höher auf dem Anwendungsebenenserver installiert werden muss und vorhandene Projekte aktualisiert werden, um freigegebene Parameter zu unterstützen. Weitere Informationen finden Sie unter Konfigurieren von Features nach einem TFS-Upgrade.
  4. Erfordert, dass TFS 2013.3 oder höher auf dem Anwendungsebenenserver installiert werden und vorhandene Projekte aktualisiert werden müssen, um Testplan und Test Suite zu unterstützen. Weitere Informationen finden Sie unter Konfigurieren von Features nach einem TFS-Upgrade.

Weitere Felder

Die folgenden Felder werden nicht für Arbeitselementformulare angezeigt, aber diese Felder werden für Testfälle oder Testsuiten nachverfolgt. Sie können einige dieser Felder verwenden, um Abfragen zu filtern und Berichte zu erstellen. (Keine dieser Felder werden 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.

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

Test Suite Audit 1

Verfolgt andere Vorgänge, die beim Ändern einer Testsuite ausgeführt werden, z. B. das Hinzufügen von Tests zu einer Testsuite oder zum Ändern von Konfigurationen. Dieses Feld kann über die Registerkarte "Verlauf" oder mittels einer gesonderten Abfrage angezeigt werden. Es gibt eine kombinierte Verlaufsansicht, einschließlich Änderungen an Arbeitselementenfeld 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, 2

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. Erfordert, dass TFS 2013.3 oder höher auf dem Anwendungsebenenserver installiert werden und vorhandene Projekte aktualisiert werden müssen, um Testplan und Test Suite zu unterstützen.
  2. 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 folgenden beiden Felder zur Definition des Arbeitselementtyps hinzugefügt werden: Gefunden in und Integrationsbuild.

Gefunden in und integriert in Build-Felder werden 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 einer WIT-Definition vorhanden ist, erstellt Team Foundation Build eine Arbeitsaufgabe, wenn ein Build fehlschlägt, und legt das Feld "Gefunden in " auf die Buildnummer des Builds fest, der fehlgeschlagen ist. Wenn das Feld "Gefunden in " fehlt, erstellt Team Foundation Build keine Arbeitsaufgabe für den fehlgeschlagenen 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 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 Listen-Autopopulation

Wenn Sie einen Build für ein Projekt zum ersten Mal mit 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 ein LISTITEM dieser globalen Liste mit dem Namen des Builds hinzugefügt.

Wenn Sie der FELDdefinition ein GLOBALLIST-Element hinzufügen, 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 sind

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 " Repro-Schritte " 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

Eine der features, die im Team Foundation-Versionssteuerelement (TFVC) verfügbar sind, ermöglicht ihnen das Zuordnen oder Auflösen von Arbeitselementen beim Einchecken des Codes. Möglicherweise haben Sie an einer bestimmten Arbeitsaufgabe gearbeitet, wenn Sie eine Codeänderung vornehmen, und Sie können diese Zuordnung aus dem Eincheckfenster der Quellcodeverwaltung festlegen, wenn Sie mit der Arbeit am Code fertig sind.

Die Möglichkeit des Team Foundation-Versionssteuerelements zum Auflösen einer Arbeitsaufgabe 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 die entsprechenden Zustände festlegen, um den gewünschten Zustandsübergang widerzuspiegeln.

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