Testautomatisierung.org

Sollte der Testcontroller über eine, im Verhältnis zu den durchzuführenden Testfällen, zu kleine “C” Partition (ggf. auch andere Partition, auf der sich das Users Verzeichnis befindet) verfügen, kann es während der Durchführung zu “Problemen” führen.
Grund dafür ist ein fehlendes, bzw. fast nicht vorhandenes Aufräumen des Users Verzeichnisses “QTController”.

Dieses Fehlverhalten kann während der Testdurchführung folgende “Symptome” aufweisen:

• Ein Teil der Testfälle wird nicht mehr ausgeführt, Testfälle werden als “not executed” markiert – .tr File enthält keine Fehlermeldung oder Hinweis. Je länger die Partition nicht aufgeräumt wird, desto weniger Testfälle einer Suite werden durchgeführt.
• Logfile vom Testagent / Testmanager / Testcontroller zeigen keine Warnungen oder Fehlermeldungen, unabhängig von dem Detailgrad des Logs
• Auf manchen Rechnern taucht die Fehlermeldung “The test assembly ‘C:\Users\..\AppData\Local\VSEQT\QTAgent\..\test.dll’ cannot be loaded. Error details: Could not find file ‘C:\Users\..\AppData\Local\VSEQT\QTAgent\..\Deployment\test.dll’” angezeigt

Das QTController Verzeichnis liegt auf dem Testcontroller unter dem Pfad “C:\Users\{Benutzer}\AppData\Local\VSEQT\QTController”.
Seitens Microsoft gibt es für dieses Problem keine “saubere” Lösung, in MSDN Foren wird empfohlen ein Batch-Datei aufzusetzen, die das Aufräumen in regelmäßigen Abständen übernimmt.
Batch File Inhalt

rmdir /s /q "C:\Users\{user}\AppData\Local\VSEQT\QTController"

Das Batch-File kann dann von der Aufgabenplanung (taskschd.msc) in benötigten Zeitintervallen aufgerufen werden, bei uns hat sich ein Aufruf alle 2 Wochen, als ausreichend erwiesen. Das hängt aber von der Größe der Partition und der Anzahl der Testfälle ab (bzw. Größe der mitgegebenen Assembly- / Testfiles).

Manchmal ist es notwendig, dass einzelne Testfälle länger als 30 Minuten laufen. Die Durchführungszeit wird aber, per default, von MTM auf 30 Minuten festgelegt

Default TimeOut der Testdurchführung aus Microsoft Testmanager, wird in den Test Settings festgelegt.

Mit folgenden Schritten, kann die TimeOut Zeit angepasst werden:

• MTM starten
• Oben den Bereich von “Testing Center” auf “Lab Center” umschalten
• im “Lab Center” den Reiter “Test Settings Manager” auswählen
• Im “Settings Manager” eine neue Test Setting anlegen oder eine bestehende öffnen
• Im Bereich “Steps”, Oberknoten “Advanced” auswählen, dann den Unterknoten “Timeouts”
• “Set Mark an individual test as failed if its execution time exceeds: 30″ deaktivieren
• Speichern
• Fertig!

Um aus Microsoft Test Manager automatisierte Testfälle (Unit Tests, Coded UI Tests, Ranorex, Selenium usw.) ansprechen zu können, müssen diese in Testmethoden “verpackt” werden.
Wie bekannt sind diese Methoden in eine Struktur des UnitTest Frameworks von Microsoft Visual Studio eingepflegt, die auch Initialisierungs- und Abschluss-Methoden bietet:

• Initialisierung: ClassInitialize(), TestInitialize()
• Abschluss: TestCleanup(), ClassCleanup()

nehmen wir mal an, wir haben 2 Testklassen mit je 2 Testfällen:

Klasse1: TC1, TC2
Klasse2: TC3, TC4

Wenn wir alle Testfälle markieren und per “Run” ausführen, werden natürlich auch die einzelnen Initialize / Cleanup Methoden ausgeführt.

Wie ist die Aufrufreihenfolge der einzelnen Initialisierungs / Abschlussmethoden?

Eigentlich würde folgende Reihenfolge der Initialisierung / Abschlussmethoden “logisch” erscheinen:

• ClassInitialize Klasse1
• TestInitialize TC1 / TestCleanup TC1
• TestInitialize TC2 / TestCleanup TC2
• ClassCleanup Klasse1

• ClassInitialize Klasse2
• TestInitialize TC3 / TestCleanup TC3
• TestInitialize TC4 / Testcleanup TC4
• ClassCleanup Klasse2

Wenn die Testfälle gestartet werden, kommt aber folgende Ausgabe:

Die Klasse wird wie vermutet mit dem ersten Testfall einer Klasse initialisiert, aber erst aufgeräumt, nachdem alle Testfälle, aller Klassen, abgeschlossen sind.
Das liegt daran, dass bei der normalen Durchführung, eine Aufruf-Reihenfolge der einzelnen Testfälle nicht sichergestellt werden kann.

Muss vor dem Aufruf der zweiten Klasse sichergestellt sein, dass die erste Klasse abgeschlossen ist (z.B. Filezugriff), kann es entweder durch Ordered Tests oder durch Auslagerung der Initialisierung / Abschlusslogik  in die TestInitialize / Cleanup Methoden realisiert werden.

Es kann vorkommen, dass mit einigen Werkzeugen das Expandieren des kompletten Tree’s nicht oder nur fehlerhaft funktioniert. Um nicht jedes Element auf “expandierbar” prüfen zu müssen, kann die Taste * vom Numblock auf den Oberknoten angewandt werden.

Also ein beliebiges Treeelement auswählen und * klicken. Probiert es einfach mal im Explorer aus, aber vorsicht, wählt dabei eine nicht zu tief verschachtelte Struktur, da sonst der Explorer sich aufhängen kann.

Es ist von Werkzeug zu Werkzeug unterschiedlich wie dieser Befehl an die Oberfläche übergeben werden kann. In VisualStudio kann der Befehl SendKeys() mit Parameter {MULTIPLY} auf einem Oberknoten verwendet werden.