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“. Weiterlesen

Durch Visual Studio 2012 haben sich einige Menüs und Funktionen im Testbereich geändert.
Mehrere Dialoge, wie Test View und Test List Editor, wurden jetzt zu einem Test Explorer zusammengefasst. Weiterlesen

Entries with this post type link to a different page with their headline. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor.

Bei manchen Testfällen ist es notwendig die aktuelle Hintergrundfarbe eines Oberflächenelements zu ermitteln.
WinForms / VB6 / usw. Oberflächen stellen diesen Wert nicht als Eigenschaft bereit, aus diesem Grund muss dieser Wert über einen anderen Weg abgefragt 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 Ranorex Adapter oder Ranorex 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;
}

Leider ist die Kultur der Testautomatisierung in Deutschland (noch?) nicht so sehr verbereitet wie in anderen Ländern. So gibt es, neben gut ausgebauten und „lebendigen“ Foren, auch Magazine, die sich speziell dem Thema Testautomatisierung widmen.
Unter dem folgenden Link ist ein gutes „Testautomatisierungs – Magazin“, der Webseite automatedtestinginstitute.com, zu finden:
Automated Software Testing Magazige – PDF Datei(Link entfernt)
Themen u.a. sind:

  • 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

Waldemar – Nachtrag (11/2015):
Leider wurde die Zielseite entfernt und die PDF Datei ist nicht mehr auffindbar. Ich habe den dazugehörigen Link entfernt und den Artikel als obsolete gekennzeichnet.
Danke an Michael Grabowski, der mich darauf aufmerksam gemacht hat, dass der Link nicht mehr zu der gewünschten Seite führt.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem.

Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim.

Weiterlesen

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!

Bei der Automatisierung einer Web-Applikation mit Ranorex, bin ich vor kurzem auf folgendes Problem gestoßen:

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.

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