Beheben von Problemen bei der Testausführung
Aktualisiert: November 2007
Wenn ein Test fehlschlägt, können Sie den Fehler durch eine Überprüfung der Testumgebung ermitteln. Dazu zählen die Testkonfiguration sowie die Einstellungen in der aktiven Testlaufkonfiguration. In einigen Fällen, z. B. in solchen, die mit der Bereitstellung zusammenhängen, sind Fehler nicht abhängig vom Testtyp. In anderen Fällen kann anhand des Testtyps bestimmt werden, welche Bereiche untersucht werden müssen. Tipps zur Untersuchung nach Testtyp finden Sie unter Details nach Testtyp.
Berichte über Fehler, die in Verbindung mit Tests auftreten, werden an zwei Stellen ausgegeben:
Fehler auf Testebene. Im Fenster Testergebnisse können Sie auf ein Testergebnis doppelklicken oder mit der rechten Maustaste darauf klicken und Testergebnisdetails anzeigen auswählen. Dadurch wird die Seite [Details] angezeigt, die Fehlermeldungen sowie je nach Testtyp weitere Informationen enthält, z. B. Stapelüberwachungsinformationen für Komponententests. Ein Beispiel für Fehler auf Testebene sind Timeoutfehler während eines Tests, die beim Überschreiten des Zeitlimits für einen Test auftreten.
Fehler auf Ausführungsebene. Berichte über Fehler auf Ausführungsebene, z. B. Testlaufkonfigurationsfehler, werden im Fenster Testergebnisse ausgegeben. Wenn ein Fehler während des Testlaufs auftritt, wird in der Statusleiste des Fensters Testergebnisse eine Verknüpfung angezeigt. Durch Klicken auf diese Verknüpfung werden auf der Seite [Details] für den Testlauf weitere Informationen zum Fehler angezeigt. Sie können die Seite [Details] für den Testlauf auch anzeigen, indem Sie im Fenster Testergebnisse auf der Symbolleiste auf Testlaufdetails klicken. Ein Beispiel für Fehler auf Ausführungsebene sind Timeoutfehler während eines Tests, die beim Überschreiten des Zeitlimits für einen Test auftreten.
Nicht alle Probleme lassen die Ausführung eines Tests fehlschlagen. Wenn die Erfassung von Codeabdeckungsdaten aktiviert ist, kann das Durchführen von Tests zur Ausgabe einer Warnmeldung führen, wenn bestimmte Buildeinstellungen festgelegt sind. Weitere Informationen finden Sie unter Verwenden der AnyCPU-Buildeinstellung beim Erfassen von Codabdeckungsdaten.
Bereitstellungsfehler
Bestimmte Fehler können bei allen Tests auftreten, die automatisch ausgeführt werden können, d. h. bei allen nicht manuellen Testtypen. Diese Fehler treten meist im Zusammenhang mit der Bereitstellung von Tests auf. Bei der Bereitstellung eines Tests wird die Datei, die den Test enthält, in einen anderen Ordner auf dem lokalen oder auf einem Remotecomputer kopiert. Weitere Informationen finden Sie unter Testen der Bereitstellung.
Bei Komponententests muss beispielsweise die DLL-Datei bereitgestellt werden, die aus dem Testprojekt erstellt wurde. Wenn diese Binärdatei nicht bereitgestellt werden kann, werden alle in ihr enthaltenen Komponententests bei der Ausführung der Tests im Fenster Testergebnisse als fehlgeschlagen angezeigt.
Überprüfen Sie zum Beheben dieses Fehlers, ob die Dateien auf dem lokalen Computer verfügbar sind und ob Fehler bei der letzten Neuerstellung der Testbinärdateien aufgetreten sind.
Nicht nur Binärdateien können bereitgestellt werden. Sie können z. B. angeben, dass eine bestimmte Datendatei für einen Test erforderlich ist und mit diesem zusammen bereitgestellt werden muss. Wenn diese Datei zum Zeitpunkt der Bereitstellung nicht gefunden werden kann, da sie verschoben oder gelöscht wurde, kann der Test nicht ordnungsgemäß ausgeführt werden, und es wird ein Fehler angezeigt. Informationen zu diesem Fehler in Bezug auf generische Tests finden Sie unter Details nach Testtyp.
Überprüfen Sie bei der Untersuchung dieses Fehlers zunächst die Dateien und Ordner, die im Dialogfeld zum Bearbeiten der Testlaufkonfigurationen auf der Seite Bereitstellung angegeben wurden. Weitere Informationen finden Sie unter Gewusst wie: Angeben einer Testlaufkonfiguration. Stellen Sie anschließend sicher, dass diese Dateien auf dem Datenträger vorhanden sind und dass die Namen übereinstimmen.
Ihre Projektmappe enthält möglicherweise mehrere Testlaufkonfigurationsdateien. Achten Sie in diesem Fall darauf, dass Sie die Testlaufkonfiguration überprüfen, die beim Auftreten des Testfehlers aktiv war. Überprüfen Sie die Seite Testlaufdetails zum Ermitteln, welche Testlaufkonfiguration aktiv war. Weitere Informationen finden Sie im Abschnitt "Seite Testlaufdetails" unter Ausgegebene Testergebnisse.
Weitere Informationen zu aktiven Konfigurationsdateien für einen Testlauf finden Sie unter Gewusst wie: Übernehmen einer Testlaufkonfiguration.
Fehler bei der Berichterstellung für Remotetest-Ergebnisse
Wenn Sie Tests remote ausführen, können die Testergebnisse möglicherweise nicht angezeigt werden. Der Grund für diesen Fehler ist häufig die remote Ausführung des Testlaufs.
Wie bei lokalen Testläufen werden auch die Ergebnisberichte für Remotetestläufe lokal erstellt. Die Berichterstellung aus bestimmten Remotetest-Ergebnissen ist abhängig von der Fähigkeit von Visual Studio Team System Test Edition, generierte Testergebnisdateien vom Remotetestcomputer auf den lokalen Computer zu kopieren.
Wenn bei Remotetest-Ergebnissen Fehler auftreten, überprüfen Sie zunächst, ob die Netzwerkverbindung zwischen dem Remotecomputer und dem Computer, auf dem Visual Studio ausgeführt wird, unterbrochen wurde.
Weitere Informationen finden Sie unter Problembehandlung für Controller, Agents und Rigs.
Instrumentationsfehler
Zum Aktivieren der Berichterstellung für die Codeabdeckung müssen die zu testenden Binärdateien instrumentiert und bereitgestellt werden, bevor Sie Tests dieser Dateien durchführen können.
Wenn die Binärdatei nicht instrumentiert werden kann, schlägt die Berichterstellung für die Codeabdeckung fehl. Nach Abschluss des Testlaufs wird auf der Seite Testlaufdetails eine Fehlermeldung angezeigt, die auf den Fehler bei der Berichterstellung für die Codeabdeckung hinweist und zusätzlich die Fehlerursache angibt.
Wenn die direkte Instrumentation einer Binärdatei fehlschlägt, können die Ursachen dafür aktivierter Schreibschutz oder die Verwendung der Datei durch einen anderen Prozess sein. Zur Fehlerbehebung überprüfen Sie bei einer schreibgeschützten Binärdatei zunächst die Dateiattribute. Stellen Sie sicher, dass in die Binärdatei geschrieben werden kann. Öffnen Sie die Seite Codeabdeckung der aktiven Testlaufkonfiguration, um zu ermitteln, welche Binärdateien überprüft werden müssen. Die zu instrumentierenden Dateien werden auf dieser Seite angegeben. Weitere Informationen finden Sie unter Gewusst wie: Erfassen von Codeabdeckungsdaten.
Eine weitere Ursache für das Fehlschlagen der Codeabdeckung bei direkter Instrumentation ist die Durchführung von einem oder mehreren Komponententests gemeinsam mit einem manuellen Test. Während des manuellen Tests wird der zu testende Produktionscode vom Tester ausgeführt. Wenn F5 oder STRG+F5 gedrückt wird, um den Code bzw. das Debuggen des Codes zu starten, wird die ausführbare Datei des Projekts neu erstellt und die Instrumentation dadurch entfernt.
Stellen Sie sicher, dass die Binärdatei von keinem anderen Prozess verwendet wird. Stellen Sie sicher, dass die Datei nicht in einer anderen Instanz von Visual Studio geöffnet ist.
Beim Instrumentieren einer Assemblys mit starkem Namen können durch die erneute Signatur der Assembly weitere Fehler auftreten. Weitere Informationen finden Sie unter Instrumentieren und erneutes Signieren von Assemblys.
Schließen von Testergebnissen zur Verbesserung der Leistung
Schließen Sie alte Testergebnisse, um die Leistung von Visual Studio zu verbessern.
Bei der Ausführung von Tests speichert Visual Studio die Testläufe und die Testergebnisse im Arbeitsspeicher. Für eine zunehmende Anzahl an Testläufen und Testergebnissen muss weiterer Arbeitsspeicher reserviert werden. Klicken Sie in der Symbolleiste des Fensters Testergebnisse auf Ergebnisse schließen, um Testläufe aus dem Arbeitsspeicher zu entfernen. Durch diese Aktion werden Testergebnisobjekte entfernt, der Garbage Collector wird jedoch nicht explizit aufgerufen. Daher werden die Arbeitsspeicherressourcen wieder zur Verfügung gestellt, wenn auch nicht notwendigerweise sofort.
Außerdem können Sie die maximale Anzahl an Testläufen festlegen, die im Arbeitsspeicher gespeichert werden. Weitere Informationen finden Sie unter Gewusst wie: Einschränken der Anzahl gespeicherter Testläufe.
Verwenden der AnyCPU-Buildeinstellung beim Erfassen von Codabdeckungsdaten.
Codeabdeckungsdaten können nur erfasst werden, wenn Sie Code in 32-Bit-Assemblys testen. Dazu muss die folgende Buildeigenschaft festgelegt werden:
Legen Sie für C#-Projekte die Zielplattform auf x86 fest. Weitere Informationen finden Sie unter Gewusst wie: Festlegen von Buildeigenschaften (C#).
Legen Sie für Visual Basic-Projekte die Ziel-CPU auf x86 fest. Weitere Informationen finden Sie unter Dialogfeld "Erweiterte Compilereinstellungen (Visual Basic).
.gif "Hinweis") Hinweis: |
|---|
Für C++-Projekte gilt dieser Hinweis nicht, da AnyCPU für C++-Projekte nicht als Plattform zur Verfügung steht. |
Wenn Sie ein Projekt mit dem Wert AnyCPU erstellen, werden in einem Testlauf der resultierenden Assembly Codeabdeckungdaten erstellt, der Testlauf gibt jedoch eine Warnmeldung aus. Auf der Seite Testlaufdetails können Sie den Inhalt dieser Warnmeldung einsehen:
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
Diese Warnmeldung weist darauf hin, dass die Assembly unter Anwendung der x86-Eigenschaft erneut kompiliert wurde, um Codeabdeckungsdaten während des Testlaufs zu erfassen. Kompilieren Sie jede Assembly, für die Codeabdeckungsdaten erfasst werden sollen, mit der x86-Einstellung, um diese Warnmeldung zu vermeiden.
| Hinweis: |
|---|
Wenn Ihre Anwendung auf 32-Bit- und 64-Bit-Computern ausgeführt werden soll, muss die Anwendung nach Abschluss der Testphase mit aktivierter AnyCPU-Einstellung erneut kompiliert werden. |
Das Ausführen von Komponententests kann zum Sperren einer C++/CLI-Testassembly führen
Es können Situationen auftreten, in denen das Testausführungsmodul eine Assembly im Testprojekt öffnet und sperrt. In diesem Fall können beispielsweise keine Änderungen an der Assembly gespeichert werden. Dieses Problem könnte in den folgenden Situationen auftreten:
Fall 1: Sie haben die Bereitstellung für das Testprojekt TestProjectA deaktiviert. TestProjectA wurde in C++/CLI kompiliert. Durch den Code in TestProjectA wird eine Attributklasse definiert, und durch dieses Attribut wird mindestens einer der Testmethoden in TestProjectA eine Ergänzung hinzugefügt. Wenn Sie zu diesem Zeitpunkt Komponententests in TestProjectA ausführen, öffnet das Testausführungsmodul TestProjectA.DLL und verursacht u. U. eine Sperrung.
Fall 2: Ihr Testprojekt, TestProject1, enthält eine DLL, die aus einem zweiten Testprojekt, TestProject2, kompiliert wurde. TestProject2 wurde in C++/CLI kompiliert. Durch den Code in TestProject2 wird eine Attributklasse definiert, und durch dieses Attribut wird mindestens einer der Testmethoden in TestProject2 eine Ergänzung hinzugefügt. Wenn Sie zu diesem Zeitpunkt Komponententests in TestProject1 ausführen, öffnet das Testausführungsmodul TestProject2.DLL und verursacht u. U. eine Sperrung.
In beiden dieser Fälle kann die Lösung aus zwei Teilen bestehen. Führen Sie zuerst die folgenden Schritte aus.
Klicken Sie im Menü Extras auf Optionen.
Das Dialogfeld Optionen wird geöffnet.
Erweitern Sie Testtools, und klicken Sie auf Testausführung.
Deaktivieren Sie unter Leistung das Kontrollkästchen Testausführungsmodul zwischen Testläufen weiter ausführen.
Wenn das Problem weiterhin besteht, nachdem Sie diese Schritte ausgeführt haben, gehen Sie wie folgt vor:
Ändern Sie den Code dahingehend, dass das in C++/CLI kompilierte Testprojekt nicht in die Standard-AppDomain geladen werden muss. Eine Möglichkeit besteht darin, die Definitionen der verwendeten benutzerdefinierten Attribute in eine separate Assembly zu verschieben, die in C# implementiert wird.
Details nach Testtyp
Einige Fehler treten regelmäßig oder vorrangig beim Ausführen bestimmter Testtypen auf, wie in diesem Abschnitt beschrieben.
Manuelle Tests. Manuelle Tests können nicht remote ausgeführt werden. Wenn ein Testlauf gestartet wird, der einen manuellen Test enthält, versucht Test Edition, den manuellen Test aus dem Testlauf zu entfernen. In diesem Fall wird eine entsprechende Warnmeldung angezeigt, in der Sie auswählen können, ob der Test abgebrochen oder ohne den manuellen Test durchgeführt werden soll. Weitere Informationen finden Sie unter Dialogfelder der Test Edition.
Testreihen. Fehler in Testreihen treten meist im Zusammenhang mit der Bereitstellung von Dateien auf. Vor der Ausführung einer Testreihe müssen die Testdateien aller enthaltenen Tests sowie alle anderen benötigten Dateien vom Testmodul gefunden und bereitgestellt werden. Wenn dieser Vorgang für einen der enthaltenen Tests fehlschlägt, führt dies zu einem Fehler.
Generische Tests. Bereitstellungsfehler können auch bei der Ausführung generischer Tests auftreten. Dateien können für generische Tests auf zwei verschiedene Arten bereitgestellt werden: auf der Seite Bereitstellung der Testlaufkonfiguration oder auf der Erstellungsseite für den generischen Test selbst. Der Test schlägt möglicherweise fehl, wenn nicht alle benötigten Dateien angegeben wurden oder wenn Testtools in Team System eine der Dateien am angegebenen Speicherort nicht finden kann.
Diese zwei verschiedenen Arten der Dateibereitstellung führen auf verschiedenen Ebenen zu Fehlern. Wenn sich der Bereitstellungsfehler auf eine Datei bezieht, die auf der Erstellungsseite des generischen Tests angegeben wurde, tritt der Fehler auf der Testebene auf. Wenn sich der Bereitstellungsfehler auf eine Datei bezieht, die in der Testlaufkonfiguration angegeben wurde, tritt der Fehler auf der Ausführungsebene auf.
Siehe auch
Aufgaben
Gewusst wie: Festlegen von Zeitlimits für die Ausführung von Tests
Konzepte
Instrumentieren und erneutes Signieren von Assemblys