After migrating from TFS 2008 to TFS 2010 the way test results are handled has changed.

Szenario

When running tests a whole system szenario is setup which means that a lot of files and additional content  is copied to the test run folder

Issue

 When test results are published to TFS 2010 the content of the test run folder is also published. This causes the TFS databases to grow rapidly

Solution

1.       Disable publishing test result

2.       Cleanup test result folders before publishing the test results

3.       Publish test results manually

HowTo: Disable publishing test results

Simply set a specific MSBuild property that is used by the TestToolsTask

<PublishTestResults>false</PublishTestResults>

TFS 2010: Cleanup test result folders before publishing the test results

The test run’s execution folder is the out directory. From that directory we drop everything except the  instrumented binaries and debug symbols. This allows us to still retrieve code coverage data. Dropping all other files will prevent the test execution when we open the test results from the build summary.

<CreateItem Include="$(TestResultsRoot)\**\Out\*.instr.pdb">

    <Output TaskParameter="Include" ItemName="InstrumentedDebugSymbolFiles"/>

</CreateItem>

<RegExReplace Input="@(InstrumentedDebugSymbolFiles)" Expression="\.instr\.pdb$" Replacement=".exe">

    <Output ItemName="InstrumentedExeAssemblies" TaskParameter="Output" />

</RegExReplace>

<RegExReplace Input="@(InstrumentedDebugSymbolFiles)" Expression="\.instr\.pdb$" Replacement=".dll">

    <Output ItemName="InstrumentedDllAssemblies" TaskParameter="Output" />

</RegExReplace>

<CreateItem Include="$(TestResultsRoot)\**\Out\**\*" exclude="@(InstrumentedExeAssemblies);@(InstrumentedDllAssemblies);@(InstrumentedDebugSymbolFiles)">

    <Output TaskParameter="Include" ItemName="TestOutputToDelete"/>

</CreateItem>

<Delete Files="@(TestOutputToDelete)"  />

HowTo: Publish test results manually

In order to publish the test result we just use the publishing feature of mstest. We identify all trx files and publish them one by one. For ease of use we do not determine the MSTest.exe path dynamically. We just defined a property that keeps the path.

<MSTestCommand>$(ProgramFiles)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe</MSTestCommand>

Using this property and the information from the current build we can easily publish the results as follows:

<!– Get all trx files for publishing –>

<CreateItem Include="$(TestResultsRoot)\**\*.trx">

    <Output TaskParameter="Include" ItemName="TestResultFiles"/>

</CreateItem>

<!– Now publish all trx files –>

<Exec Command="&quot;$(MSTestCommand)&quot; /publish:&quot;$(TeamFoundationServerUrl)&quot; /publishbuild:&quot;$(BuildUri)&quot; /PublishResultsFile:&quot;%(TestResultFiles.Identity)&quot; /teamproject:&quot;$(TeamProject)&quot; /platform:&quot;Mixed Platforms&quot; /flavor:&quot;Debug&quot;" ContinueOnError="true" />

Please also notice that we do not determine the build configuration (platform and flavor) dynamically. We “hard-coded” it.

Wie kann ich die Code Coverage Analyse für Tests aktivieren?

(more…)

Die Microsoft Visual Studio 2010-Roadshow zu integriertem anforderungs-basiertem Testen und Testautomatisierung in der modernen Software-Entwicklung

Im Rahmen von Visual Studio 2010 bringt Microsoft im März 2010 unter dem Namen umfangreiche neue Werkzeuge speziell für die Qualitätssicherung und für nicht-technische Tester auf den Markt, die erstmals eine reibungsfreie Zusammenarbeit zwischen Testern und Entwicklern ermöglichen, und beispielsweise das häufige Problem nicht nachvollziehbarer Fehler beseitigen (die so genannten „No Repro Bugs“). Das komfortable Einrichten, Verwalten und Auswerten von virtuellen Testumgebungen wird durch leistungsfähige Systemmanagement-Werkzeuge mit Visual Studio 2010 einfacher und komfortabler als je zuvor.

Die Qualitätsroadshow dauert einen halben Tag und richtet sich an Verantwortliche aus der Qualitätssicherung, Softwaretester, Projektleiter und Entwickler. In drei Vortragsblöcken gefolgt von einer offenen Diskussionsrunde stellen Ihnen die Softwareentwicklungsprofis von Microsoft und AIT auf dieser Roadshow einen optimalen Ansatz zur Verbesserung der Produktqualität mittels eines durchgängigen Testprozess vor. Während der interaktiven Veranstaltung bleibt außerdem viel Zeit für Ihre Fragen und angeregte Diskussionen mit den Teilnehmern und Referenten.

• Die Teilnehmerzahlen sind begrenzt.
  Melden Sie sich daher gleich hier an. Als AIT-Kunde kontaktieren Sie bitte Ihren AIT TeamSystemPro Ansprechpartner für weitere Informationen. 

Die Ausführung von Unit Tests im Buildprozess kann komfortabel über Testlisten verwaltet werden. In manchen Fällen ist das aber nicht anwendbar, z.B. wenn zu viele Solutions gebaut werden und die Tests in Form von Test-Assemblies vorliegen. Hierbei sollen alle Tests ausgeführt werden, die im Source Ordner eines Projektes stecken. Gleichzeitig sollen Code Coverage Werte ermittelt werden.

Dabei treten folgende Fragestellungen auf:

1. Wie führe ich MSTest in einem lokalen Build aus?
2. Wie ermittle ich alle Test Assemblies?
3. Wie aktiviere ich Code Coverage?

Dieser Beitrag soll die Antworten aufzeigen.

(more…)

Viele Kunden, die aus stark diversifizierten Entwicklungsumgebungen zum Visual Studio Team System migrieren, stehen vor der Herausforderung, auch ihre gesamte Testplattform entweder zu integrieren oder neu aufzubauen. Der Neuaufbau fällt schwer, wenn sehr viele Tests auf Basis von Legacy-Code existieren. Wenn bereits die vollständige Migration des Legacy-Codes nicht in Betracht kommt, so werden auch die Tests nicht ohne Aufwand und weitere Risiken zu migrieren sein. Dennoch liegt der Nutzen einer solchen Migration z.B. von NUnit-Tests nach MSTest auf der Hand. Können die Testergebnisse von MSTest doch komfortabel mit Visual Studio ausgewertet werden.

Zudem lassen sich die Testergebnisse in Form von .trx-Dateien direkt an den TFS publizieren. So erhält man ein vollständiges Reporting über die gelaufenen Tests. Zum Beispiel im Quality-Indicators-Report:

Für die einfache Integration von NUnit-Tests haben wir ein Tool namens Unit Test Result Converter geschrieben, welches Ergebnisdateien aus den verschiedenen Legacy-Testplattformen nach MSTest konvertiert.

(more…)

Kürzlich stellte sich uns die Anforderung, Unit-Tests auf einem virtuellen PC während des Buildprozesses auszuführen und die Ergebnisse im Build sichtbar zu machen - sprich die Testergebnisse auf den TFS zu pulbizieren. Der Kunde, der die Anforderung stellte, wollte damit umfangreiche Smoke-Tests auf mehreren Zielplattformen automatisieren. So sollte es z. B. möglich sein, eine Applikation auf einem Windows XP und Vista zu testen. Dazu wurden mehrere virtuelle PCs (hier mit VM-Ware) erstellt und Snapshots erzeugt. Im Buildprozess sollen diese gestartet und für das Applikationsdeployment verwendet werden. Nach einiger Zeit der Evaluierung mit dem Visual Studio Load Test Agent, entschieden wir uns für eine Scripting-Lösung. Wir wollten mstest.exe remote auf dem VPC ausführen.

(more…)

VSTS bietet die Möglichkeit, in Testprojekten manuelle Tests hinzuzufügen. Dabei handelt es sich um eine Testfallbeschreibung in Form einer Text- oder Word-Datei. Die manuellen Tests können dann im Rahmen eines Testlaufs ausgeführt werden (vgl. Abb. Ausführung eines manuellen Tests). Wie die Word-Vorlage für den manuellen Test geändert, bzw. weitere Vorlagen angeboten werden können, soll im Folgenden beschrieben werden.

(more…)

Um ein verteiltes Test-Szenario umzusetzen, muss man evtl. mit mehreren Testlauf-Konfigurationen (Abb. Solution mit mehreren testrunconfig-Dateien) arbeiten und diese in einem Build ausführen. Der Standard-Buildprozess kann nur die in der .vsmdi-Datei aktivierte Testrunconfig verwenden. Dies ist für Tests auf mehreren VSTT-Controllern (Visual Studio Team System Load Test Controller) aber nicht ausreichend. Wir haben daher den Buildtypen angepasst, um auch dieses Szeanrio zu unterstützen.

(more…)