http://docs.seleniumhq.org/download/

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).

Menu “Test”-”Fenster” Visual Studio 2010

Menu “Test”-”Fenster” Visual Studio 2012

Leider hat der neue Testexplorer nicht mehr die Funktionen, die in der Test View möglich waren. Neben der fehlenden Gruppierung der Testfälle nach Klassen oder Projekt, gibt es im Testfall Contextmenü in Visual Studio 2012 keine Möglichkeit mehr, eine Testmethode mit einem Testfall in TFS zu “verknüpfen”.

Kontextmenü Testfall Visual Studio 2010 

Kontextmenü Testfall Visual Studio 2012 

Um die Testmethoden mit einem Test Case zu verknüpfen sind folgende Schritte in Visual Studio 2012 notwendig:

1. Button “Gehe zu Arbeitsaufgabe” auswählen:
   
2. WorkItem ID des zu verknüpfenden Testfalls eintippen:
   
3. Im geöffneten Testfall Tab (seit neuestem Link) “ASSOCIATED AUTOMATION” auswählen
4. Button … auswählen
5. gesuchten Testfall auswählen.
   
   Leider gibt es hier keine Suchfunktion, eintippen der ersten drei Buchstaben des Testfallnamens hilft den Testfall schneller zu finden. Bei einer großen Anzahl von Testfällen hilft eine einheitliche Namenskonvention.
6. Testfall speichern – fertig!
   
   Der Automatisierungsstatus des Testfalls hat sich automatisch in “automated” geändert. Testfall kann in Microsoft Testmanager als automatisierter Test ausgewählt werden.

Der einfachste Weg ist es, ein Screenshot des Elements zu erzeugen und diesen dann mit der GetPixel Methode abfragen.
Ranorex stellt dazu z.B. die Methode

Report.Screenshot(element);

bereit.
Bei dieser Methode wird allerdings das Bild lokal gespeichert, dieses Vorgehen ist etwas fehleranfällig und vor allem unnötig.
Nach einer längerer Suche, bin ich auf die Methode Imaging.CaptureCompressedImage() gestoßen, diese liefert ein Bitmap Objekt zur Laufzeit zurück, ohne dass Bilder lokal gespeichert werden müssen.
Als Parameter kann ein Element vom Typ Adapter oder Element übergeben werden.

Hier ist eine Beispiels-Methode, mit der vom übergebenen Control die Hintergrundfarben ermittelt werden können.
Natürlich können auch die Pixel verändert bzw. parametrisiert werden.

public static string Color(Adapter ui_control)
{
   Bitmap bmp = Imaging.CaptureCompressedImage(ui_control);
   Color cElementColor = bmp.GetPixel(2, 2);
   return cElementColor.Name;
}

• So easy even a child can use it – Is Your Test Automation Architecture Usable?
• Cells, Selenium, XPath and Labels – Using Labels to identify Dynamic Objects
• Test Automation Experiences
• Selenium vs. Watir… And the Winner is Webdriver

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!

Die Tabelle besteht aus ca 10 Zeilen und 2 Header Zeilen.
Um einen flexibelen Zugriff zu ermöglichen, setze ich mir den Ranorex Pfad (Ranorex XPath) selbst zusammen.
Der Zugriff sollte in diesem Fall über “Zeilen / Spalten – Nummer” aus Sicht der Tabellenebene stattfinden.
Das Element setzte sich so zusammen:

element = tablepath + "//tr[" + row + "]/td[" + column + "]";

Alles soweit in Ordnung. Variablen row = 1 und column = 3 gesetzt, Ranorex Pfad wird richtig gefüllt und die td Zelle lässt sich, mit dem generierten Pfad, durch Ranorex Spy finden.

Der Versuch dieses Element per Methode TryFindSingle() während der Testdurchführung zu finden, ist aber gescheitert.

Host.Local.TryFindSingle(element, TimeSpan.FromSeconds(time), out tdElement))

Nach einer kurzen Try/Fail-Phase, habe ich versucht die Zelle über den Ranorex Typ “WebElement” zu finden.
Dazu wird einfach das letzte Element (td) durch ein * ersetzt und mit TryFindSingle nach Typ “WebElement” gesucht.
Dadurch kann jedes Element identifiziert werden, das den Suchkriterien entspricht. Als Result kam Tag TH (Head Element) raus.
Also row = 3 (von der Anzahl höher als das letzte TH Element) gesetzt, schon hat der Zugriff über TryFindSingle() funktioniert.
Reicht als Lösung des Problems natürlich nicht aus, die ersten beiden Zeilen sollen schließlich auch angesprochen werden können. Da kommt das Element tbody ins Spiel.
Durch tbody kann hier sichergestellt werden, dass der Zugriff wirklich auf den “Content” der Tabelle stattfindet. Die Identifikation ist so eindeutig.
Also den Ranorex XPath Ausdruck angepasst, schon funktioniert die TryFindSingle() Suche fehlerfrei:

element = tablepath + "//tbody/tr[" + row + "]/td[" + column + "]";

Man könnte annehmen, dass //tr[1]/td[1] Kombination ausreichend wäre, dem war hier leider nicht so.
Warum dieser Pfad in Ranorex Spy richtig erkannt wird und per TryFindSingle() nicht, kann ich leider nicht sagen, aber durch diesen kleinen “Workaround” kann an dieser Stelle weitergearbeitet werden.

Im Ranorex Forum gibt es ein ähnliches Problem: Beitrag im Ranorex Forum
Die dort vorgeschlagenen Lösungen, haben bei diesem Problem aber keine Besserung gebracht.

• 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.

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.

Hier ein kleines Beispiel, wie jedes Zeichen eines Strings nacheinander ausgegeben werden kann:

For i=1 to Len("Tomate")
  msgbox Mid("Tomate", i, 1)
Next