Informationen
Das angeforderte Thema wird unten angezeigt. Es ist jedoch nicht in dieser Bibliothek vorhanden.

Ausführen von Testläufen im Buildprozess

Sie können Team Foundation Build verwenden, um im Rahmen der Tests für Ihren Buildprozess automatisierte Tests durchzuführen und die Auswirkungen von Codeänderungen zu analysieren. Beispielsweise können Sie einen Buildprozess definieren, den Sie als regelmäßig geplanten Buildüberprüfungs-Testlauf (Build Verification Test, BVT) Ihres Teams verwenden. Sie können auch über Ihre benutzerdefinierten Buildprozesse automatisierte Tests und dazugehörige Aufgaben durchführen.

Hinweis Hinweis

Wenn Sie die Anwendung im Rahmen des Buildprozesses bereitstellen möchten, müssen Sie einen Erstellungs-, Bereitstellungs- und Testworkflow und eine Lab-Umgebung verwenden. Sie können dann automatisierte Tests als Teil des Workflows durchführen, oder Sie können Tests separat durchführen, nachdem der Workflow abgeschlossen wurde. Weitere Informationen finden Sie unter Automatische Erstellungs-, Bereitstellungs- und Testworkflows.

Im Folgenden sind die Aktivitäten angegeben, die Sie mit Team Foundation Build ausführen können:

Bevor Sie Tests im Buildprozess durchführen, müssen Sie die Tests und das Buildsystem normalerweise vorbereiten.

Vorbereiten der Tests: Stellen Sie sicher, dass die Projektmappe und die Testdateien in die Versionskontrolle eingecheckt werden. Siehe Verwenden der Versionskontrolle.

Kategorisieren und Priorisieren der Tests (optional): Sie können den Tests Kategorien und Prioritäten zuweisen und dann nach diesen Attributen filtern, wenn Sie die Tests im Build durchführen. Sie können z. B. eine Testkategorie mit dem Namen FI erstellen und dann in den fortlaufenden Integrationsbuilds diese Kategorie angeben. Sie können eine weitere Kategorie mit dem Namen bt für die Buildüberprüfungstests erstellen und dann in geplanten Builds, z. B. dem nächtlichen Build, diese Kategorie angeben. Weitere Informationen finden Sie unter Definieren von Testkategorien zum Gruppieren von Tests, TestCategoryAttribute und PriorityAttribute.

Vorbereiten des Buildservers: Manche Testarten können nur von einem Build-Agent auf einem besonders konfigurierten Buildserver ausgeführt werden. Wenn Sie beispielsweise Tests von codierter UI durchführen, müssen Sie den Build-Agent für die interaktive Ausführung konfigurieren. Bevor Sie versuchen, mit Ihrem Buildprozess Tests auszuführen, stellen Sie zunächst sicher, dass diese auf dem zu verwendenden Buildserver ausgeführt werden können. Weitere Informationen finden Sie unter Verwenden des Build-Agents zum Ausführen von Tests.

Microsoft Visual Studio muss auf dem Buildserver für die folgenden Szenarien installiert sein:

  • Um ein CPP-Testprojekt zu erstellen, müssen Sie Visual Studio Professional oder höher installieren.

  • Um Komponententests oder Tests von codierter UI durchzuführen, müssen Sie Visual Studio Professional oder höher installieren.

  • Voraussetzungen zum Verwenden von Daten und diagnostischen Datenadaptern:

    1. Codeabdeckung: Visual Studio Premium oder höher.

    2. Testauswirkung: Visual Studio Ultimate.

    3. IntelliTrace: Visual Studio Ultimate.

  • Zum Erstellen von modernen Apps benötigen Sie auf dem Buildcomputer: Visual Studio Ultimate oder Visual Studio Express for Windows 8 (das Betriebssystem auf dem Buildserver muss Windows 8 sein).

  • Zum Kompilieren und Ausführen von Tests für ein Projekt mit einer falschen Assembly benötigen Sie: Visual Studio Ultimate.

Sie können einen oder mehrere Testläufe im Build ausführen, das auf der Standardvorlage basiert. Sie können für jede Ausführung die folgenden Einstellungen festlegen:

  • Durchzuführende Tests

  • Einstellungen zum Durchführen der Tests

  • Ob für den Build ein Fehler auftreten soll, wenn ein Test nicht erfolgreich ist

  1. Wählen Sie in Team Explorer die Option Startseite und dann Builds aus (Tastenkombination: STRG+0, B).

  2. Wählen Sie auf der Seite Builds die Option Neue Builddefinition aus, oder öffnen Sie das Kontextmenü für den Build oder die Builddefinition, den bzw. die Sie ausgewählt haben, und klicken Sie auf Builddefinition bearbeiten.

    Das Fenster "Builddefinition" wird angezeigt.

  3. Auf der Registerkarte Prozess Ihrer Builddefinition wählen Sie das Feld Automatisierte Tests, und wählen Sie dann die Schaltfläche mit den Auslassungspunkten (...) aus.

    Das Dialogfeld Automatisierte Tests wird angezeigt.

  4. Führen Sie einen der folgenden Schritte aus:

    • Klicken Sie auf Hinzufügen, um einen Satz von Tests hinzuzufügen.

    • Um einen Satz von Tests zu ändern, wählen Sie ihn aus und klicken dann auf Bearbeiten.

    Das Dialogfeld Test hinzufügen wird angezeigt.

  5. (Optional) Geben Sie unter Name den Namen des Testlaufs an. Dieser Name wird im Fenster mit den Buildergebnissen angezeigt. Wenn Sie keinen Namen angeben, generiert das System den Namen automatisch.

  6. Falls für den Build ein Fehler auftreten soll, wenn einer der Tests im Testlauf nicht erfolgreich ist, wählen Sie Buildfehler bei Testfehler aus. Wenn Sie dieses Kontrollkästchen deaktiviert lassen und einer der Test fehlschlägt, wird der abgeschlossene Build als Teilweise erfolgreich klassifiziert.

  7. Dateiangabe für Testassemblys

    Geben Sie die Binärdateien mit den Tests an, die Sie durchführen möchten. Übernehmen Sie den Standardwert (**\*test*.dll), wenn der Build-Agent rekursiv alle DLL-Dateien im Unterverzeichnis binaries des Arbeitsverzeichnisses des Build-Agents suchen soll, die mit *test*.dll übereinstimmen. Alternativ können Sie die Dateispezifikation entsprechend Ihren Anforderungen ändern.

  8. Wenn Sie möchten, dass der Testlauf Codeabdeckungsdaten erfasst und veröffentlicht, legen Sie die Optionen auf Codeabdeckung aktivieren fest.

    Alternativ können Sie die Option Benutzerdefiniert verwenden, um eine RUNSETTINGS-Datei anzugeben. Weitere Informationen finden Sie unter Anpassen der Codeabdeckungsanalyse.

  9. Wählen Sie im Menü Geben Sie die Zielplattform für die Testausführung an die Option x86 aus, um die 32-Bit-Binärdateien zu testen, oder x64, um die 64-Bit-Binärdateien zu testen.

  10. Sie können Kriterien für die Tests angeben, die durchgeführt werden.

Sie können Name-Wert-Paare angeben, um die durchzuführenden Tests zu filtern. Wenn Sie Testkategorie- und Prioritätsattribute nutzen, um die Tests zu organisieren und zu priorisieren, können Sie die auszuführenden Tests filtern, indem Sie die Namen für TestCategory und Priorität verwenden.

Sie können Testkategorien mit einem der folgenden Verfahren angeben:

  • Geben Sie ein einzelnes Name-Wert-Paar an, das eingeschlossen werden soll. Angenommen, Sie verfügen über eine Testkategorie mit dem Namen bvt. Sie können z. B. die Option Testfallfilter auf "TestCategory=bvt" festlegen, um nur Tests in dieser Kategorie durchzuführen.

  • Geben Sie mit dem Operator || (Operator OR) mehrere Testkategorien an. Sie können z. B. "TestCategory=quick||TestCategory=gui" angeben, um Tests in der Kategorie "quick" und Tests in der Kategorie "gui'" durchzuführen.

Wenn Sie Tests vorübergehend deaktivieren müssen, ohne die Testläufe zu löschen, in denen diese enthalten sind, erweitern Sie den Knoten Erweitert und legen Tests deaktivieren auf True fest. Setzen Sie den Wert auf False zurück, wenn Sie die Tests wieder aktivieren möchten.

Die Tester und Entwickler müssen möglicherweise wissen, wie sich Codeänderungen in einem abgeschlossenen Build auf die Tests ausgewirkt haben. Wenn Sie die Testauswirkungsanalyse in einem Build aktivieren, analysiert das System, wie sich Codeänderungen auf die Tests ausgewirkt haben, und gibt diese Auswirkungen im Buildbericht des abgeschlossenen Builds an.

So aktivieren Sie die Testauswirkungsanalyse in einem Buildprozess, der auf der Standardvorlage basiert

  1. Konfigurieren Sie die Testauswirkungsanalyse in einer Testeinstellungsdatei.

    Weitere Informationen finden Sie unter Gewusst wie: Sammeln von Daten, um zu überprüfen, welche Tests nach Codeänderungen ausgeführt werden sollen.

  2. Erstellen Sie eine Gruppe von Tests, die für die Verwendung der Testeinstellungsdatei konfiguriert ist.

    Weitere Informationen finden Sie weiter oben in diesem Thema unter Ausführen von automatisierten Tests.

  3. Erweitern Sie den Knoten "Erweitert", und stellen Sie sicher, dass Testauswirkung analysieren auf True und Tests deaktivieren auf False festgelegt ist.

Sie können so viele Testläufe wie benötigt definieren, um die Anforderungen für den Build- und Testvorgang des Teams zu erfüllen. Möglicherweise müssen Sie z. B. in den folgenden Szenarien mehrere Testläufe in einem einzelnen Build definieren:

  • Sie möchten Visual Studio Test Runner verwenden, um eine Projektmappe zu testen, die Binärdateien mit 32- und 64-Bit-Bitanzahl erzeugt.

  • Sie verfügen über zwei Sätze von Tests:

    • Ein Satz von Kerntests oberster Priorität, die erfolgreich ausgeführt werden müssen. Sie definieren eine Gruppe von Tests, die für Minimale Testpriorität und Maximale Testpriorität den Wert 1 enthält. Sie aktivieren das Kontrollkästchen Buildfehler bei Testfehler.

    • Ein Satz von weniger wichtigen Tests, die Sie ausführen möchten, die jedoch nicht erfolgreich ausgeführt werden müssen, damit der Build verwendbar ist. Sie definieren eine Gruppe von Tests, die für Minimale Testpriorität den Wert 2 und für Maximale Testpriorität den Wert 3 enthalten. Sie lassen das Kontrollkästchen Buildfehler bei Testfehler deaktiviert.

  • Sie möchten den gleichen Satz von Tests mit unterschiedlichen Testeinstellungen ausführen.

  • Auf den Hauptsatz von Assemblys, die Sie erstellen, soll Codeabdeckung angewendet werden. Sie verfügen jedoch über einen weiteren Satz von Assemblys aus einer externen Quelle, die keine Codeabdeckung erfordern. Für diese Art von Vorgang können Sie zwei Gruppen von Tests verwenden, die für die Nutzung von zwei Gruppen von Testeinstellungsdateien konfiguriert sind.

Ihr Buildprozess kann Komponententests auf Basis von Komponententestframeworks von Drittanbietern nur dann ausführen, wenn Sie den Buildcontroller mit Zugriff auf Framework-Assemblys von Drittanbietern bereitgestellt haben.

  1. Suchen Sie ggf. oder geben Sie den Pfad des Buildcontrollers zu benutzerdefinierten Assemblys an.

  2. Suchen Sie ggf. oder erstellen Sie eine Zuordnung im benutzerdefinierten Assemblyordner auf dem Server zu einem lokalen Ordner im Arbeitsbereich.

  3. Rufen Sie ein Komponententest-Plug-In von Drittanbietern ab:

    Adapter

    Sprache

    Boost

    C++

    Chutzpah

    JavaScript

    Google

    C++

    MbUnit

    C#

    MSpec

    MSpec

    nUnit

    C#

    Python Tools für Visual Studio

    Python

    Silverlight

    Silverlight

    TSTestAdapter

    TypeScript

    VsNodeTest

    Node.js

    xUnit.net

    C#

    xUnit++

    C++

  4. Benennen Sie die Plug-In-Datei VSIX-Datei in eine ZIP-Datei um. Verwenden Sie die Eingabeaufforderung beispielsweise so:

    C:\Downloads>ren NUnitTestAdapter.vsix NUnitTestAdapter.zip
    
  5. Entzippen Sie den Inhalt der ZIP-Datei in den lokalen Arbeitsbereichsordner, den Sie in Schritt 2 zugeordnet haben.

  6. Checken Sie die Dateien ein.

    Tipp Tipp

    Erfahren Sie mehr über Strategien zum Arbeiten mit Binärdateien von Drittanbietern in der Versionskontrolle unter Nutzen Sie Binärdateien von Drittanbietern, die dem Code nicht erstellt.

[Visual Studio 2012.3] enthält eine Erweiterung für Komponententestframeworks von Drittanbietern, um ihre Einbindung in die Teambuilddefinitionen zu automatisieren.

Warnhinweis Vorsicht

Möglicherweise müssen Sie die neueste Version der NuGet-Pakete für Komponententestframeworks von Drittanbietern installieren, um so sicherzustellen, dass das Framework die Builddefinitionserweiterung enthält.

Ein Komponententestframework von Drittanbietern auf einem Buildcontroller aktivieren - [Visual Studio 2012.1]

  1. Öffnen Sie im Projektmappen-Explorer das Kontextmenü für das Testprojekt und wählen Sie NuGet-Pakete verwalten aus.

  2. Wählen Sie im Dialogfeld "NuGet Pakete verwalten" in der linken Spalte Online aus.

  3. Wählen Sie das NuGet-Paket für das Komponententestframework von Drittanbietern und wählen Sie dann Installieren aus.

  4. Nachdem dem Abschluss der Installation des NuGet-Pakets wählen Sie Schließen aus.

  5. Öffnen Sie im Projektmappen-Explorer das Kontextmenü zur Projektmappe und wählen Sie Projektmappe zur Quellcodeverwaltung hinzufügen aus.

  6. Sie können Ihr Build nun in die Warteschlange stellen, die Tests mit dem Komponententestframework von Drittanbietern werden automatisch ausgeführt.

Falls das Team einen Buildprozess mit stärker angepassten Funktionen erfordert, können Sie aus dem benutzerdefinierten Buildprozess heraus Tests durchführen und andere testbezogene Aufgaben ausführen. Weitere Informationen finden Sie in folgenden Themen:

Unter Verwenden der Standardvorlage für Ihren Buildprozess finden Sie weitere Informationen zum Erstellen einer Builddefinition, die auf der Standardvorlage beruht. Dieses Thema enthält Informationen zu Bitanzahleinstellungen für die Plattform, die Sie beim Kompilieren des Codes verwenden können.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

Anzeigen:
© 2014 Microsoft