Schlagwortarchiv für: C#

HTML Test Reports für Selenium Tests mit ExtentReport Framework

Selenium ist als Testautomatisierungstool für Webanwendungen absoluter Standard. Der Standard WebDriver an sich hat keinen integrierten Reporter und das ist auch nicht seine Kernaufgabe. Diese wird vom WebDriver an die Testframeworks (JUnit / NUnit / MSTest / Jasmine usw.) delegiert. Es kann aber trotzdem vorkommen, dass die von den Testframeworks zur Verfügung gestellten Reporter für Auswertung von den Tests nicht ausreichend sind.

Gute Testreports haben allgemein folgende Vorteile:

  • Bieten gute Übersicht über den Testlauf auf verschiedenen Ebenen an: von hoch-granaular als Testmanagement Sicht bis feingranular für die Analyse einzelner Testschritte
  • Als lesbarer strukturierter Text / HTML abgelegt, enthalten fachliche Schritte
  • Enthalten eingebetete Screenshots, was beim Nachvollziehen der Probleme hilft
  • Vereinfachen die Fehlersuche
  • Können archiviert werden
  • Können von Menschen ohne Programmier-Kenntnissen ausgewertet werden

Auf dem Markt existieren viele mehr oder weniger gute Lösungen, die das Reporting für Selenium Tests bereitstellen. Nicht alle erfüllen die davor genannten Anforderungen an gute Testberichte, aber je nach Anwendungsfall und Projekt ist es auch oft gar nicht notwendig.

Bei uns in den Projekten hat sich der Testreporter ExtentReports bewährt. Neben einer kostenpflichtigen Version, gibt es auch eine Community Edition, die für den Einsatz in den meisten Projekten absolut ausreichend ist.

In diesem Beitrag möchte ich aufzeigen, wie ExtentReports in ein .NET Projekt eingebunden und benutzt werden kann.

Weiterlesen

/1 Kommentar/von

Automatisierte Tests mit C# in eigener AppDomain starten

In C# existiert die Möglichkeit, automatisierte Testfälle in einer eigenen AppDomain zu starten.
Der Vorteil von AppDomains ist, dass alle Aktionen in einem separaten Bereich ausgeführt werden. Anwendungsdomänen helfen dabei, den ausführenden Code von den anderen Bereichen zu isolieren und nach der Ausführung nicht benötigte Referenzen zu entladen. Weiterlesen

/0 Kommentare/von

Selenium Tutorial: Automatisiertes Testen von Webanwendungen – Teil 1

Lernziele des Tutorials: Anlage von einem C# Projekt, Anbindung der Selenium DLLs in .Net Umgebung. Öffnen der Seite www.testautomatisierung.org in Firefox.

Zielgruppe: Dieses Selenium Tutorial ist für Anfänger gedacht, vorausgesetzt sind rudimentäre C# / Testautomatisierungserfahrungen. Weiterlesen

/0 Kommentare/von

OptionTag Auswahl mit Selenium

Um in einem automatisierten Test einen Eintrag aus einer DropDown Liste auszuwählen (Select-Tag), gibt es in Selenium mehrere Möglichkeiten.

Weiterlesen

/0 Kommentare/von

MTM Testdurchführung über TFS API starten

Um einen automatisierten Testrun über die TFS API zu erstellen, kann die CreateTestRun Methode der Schnittstelle ITestPlan verwendet werden.
Das Erstellen von einem neuen Testlauf funktioniert (zumind. für die Basis-Workflows) ziemlich einfach. Weiterlesen

/0 Kommentare/von
,

Selenium MouseOver Event erzeugen

Um auf dynamische Untermenüs zugreifen zu können, ist es oft Notwendig ein „MouseOver-Event“ auf ein bestimmtest Element zu erzeugen. Alles andere führt bei Selenium zu der „Element is not currently visible and so may not be interacted with“ – Exception.

Wenn auch das Eltern-Element mit einer Seite im Hintergrund belegt ist, kann der Zugriff auf das Untermenü, nicht mit einem Klick realisiert werden. Es sollte also möglich sein, ein Selenium MouseOver aus dem automatisierten Test zu erzeugen.
Selenium bietet hier die Möglichkeit mit Actions zu arbeiten. Aus dem Driver wird ein Actions Builder erzeugt, dieser kann dann eine Selenium MoveToElement Methode auf das gewünschte Webelement ausführen.

Weiterlesen

/0 Kommentare/von

Ranorex: Pixelfarbe ermitteln

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;
}
/0 Kommentare/von
,

Ranorex: Problem beim dynamischen Zugriff auf eine Webtabelle

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.

/0 Kommentare/von