Vorstellung Kategorie RapidRep

In der neuen Kategorie „RapidRep“ werden in regelmäßigen Abständen Gastbeiträge der Firma
FINARIS rund um das Thema „Testautomatisierung für das Back-End“ veröffentlicht. Ein weiterer Schwerpunkt wird dabei auf Anwendung und Methodik der RapidRep Test Suite liegen. Diese Software Suite zur Testautomatisierung wird von FINARIS entwickelt und liegt aktuell (April 2014) in Version 5.1 vor.

Zum Einstieg wollen wir das Thema allgemein etwas näher betrachten: Was verstehen wir in diesem Zusammenhang unter Back-End? Wie sieht es mit dem Testen des Back-Ends aus und wo steht die Testautomatisierung? Zu guter Letzt: warum ein eigenes Tool, RapidRep, für das automatisierte Testen des Back-Ends verwenden? Haben wir diese Grundlagen geklärt, können wir uns in weiteren Artikeln mit Detailaspekten auseinandersetzen wie zum Beispiel der automatisierten Datenqualitätssicherung durch RapidRep.

Was ist das Back-End?

Grundsätzlich liegt das Back-End „hinter“ bzw. unter den (GUI-)Anwendungen und stellt somit den Teil des Systems dar, der dem Benutzer weniger zugänglich ist und näher am System liegt. Als das Back-End sehen wir daher jene Komponente, die enthält, was keine weiteren Eingaben des Nutzers erfordert, aber für den reibungslosen Ablauf unerlässlich ist. Ein Beispiel wären Datenbanken oder Web-Services, die in verschiedenster Form Daten enthalten. Aus unserer vorigen Definition ergibt sich, was wir eigentlich beim Back-End Test testen wollen.

Back-End Tests und Testautomatisierung

Im Back-End finden sich alle Testobjekte, die keine manuellen Benutzereingaben erfordern: Programme und Funktionen ohne GUI, Datenhaltung, Datenverarbeitung, Prozesse und Web-Services. Im Back-End zu testen bedeutet non-GUI zu testen. Der Markt für Test-Tools und Test-Dienstleister, vor allem auch der Testautomatisierung, konzentriert sich jedoch weitgehend auf den Test von Oberflächen. Wird das Back-End getestet, so wird es meist manuell getestet. Diese Sachlage wirft die Fragen auf, ob das Back-End vielleicht kaum getestet zu werden braucht, sich das Testen eigentlich lohnt und ob man das Back-End nicht automatisiert testen kann?

Man könnte überzeugend vertreten, dass GUI-Tests hoher Aufmerksamkeit bedürfen, da sie nicht nur durch ständige Änderungen an der GUI entsprechende Anpassungen im Test erfordern, sondern eben auch das testen, was für den Endnutzer unmittelbar sichtbar ist. Eine solche Argumentation setzt aber nicht außer Kraft, dass ein funktionierendes Front-End jeglicher Art ein funktionierendes Back-End benötigt: Die Oberfläche kann einwandfrei funktionieren – wenn die dahinter liegenden Daten oder Prozesse nicht korrekt sind, stimmt das Ergebnis nicht. Tests des Back-Ends sollten also zweifelsfrei nicht vernachlässigt werden und der Nutzen liegt auf der Hand.

Bleibt die Frage, ob sich das Back-End automatisiert testen lässt. Da „Testautomatisierung für das Back-End“ das zentrale Thema dieser Artikelreihe darstellt, ist offensichtlich, dass wir diese Frage mit „Ja“ beantworten. Doch worauf stützt sich diese Ansicht?

Die RapidRep Test Suite:Testautomatisierung für das Back-End

In verschiedenen Projekteinsätzen, insbesondere innerhalb der Finanzbranche, hat sich die RapidRep Test Suite bereits bewährt. Testautomatisierung für das Back-End ist somit praxiserprobt, unter anderem in Anwendungsgebieten wie Funktionstests, Migrationstests und Datenqualitätsprüfungen. Die entsprechenden Praxiserfahrungen werden zur Weiterentwicklung der Testautomatisierung genutzt, belegen vor allem aber auch ihre Vorteile. Neben den generellen Vorteilen jeglicher Testautomatisierung (wenige bis gar keine manuellen Eingriffe, Schnelligkeit, Zuverlässigkeit u.a.), lässt sich vor allem die Nachvollziehbarkeit hervorheben. Ein automatisierter Back-End Test mit RapidRep ist für alle Beteiligten nachvollziehbar, auch ohne besondere Programmierkenntnisse.

Ein Grund dafür ist der Einsatz von Excel Arbeitsmappen. Diese bieten den Vorteil, weit verbreitet Anwendung zu finden sowie für jeden ohne technisches Spezialwissen lesbar zu sein. RapidRep dokumentiert die maschinell ausgewerteten Testfälle in detaillierten und benutzerdefinierbaren Excel Arbeitsmappen, welche automatisiert an unterstützte Testmanagementsysteme übertragen werden können (revisionssicherer Testnachweis). Zudem werden Excel Arbeitsmappen in RapidRep auch als Grundlage für modell- und regelbasierte Tests verwendet. Wie ein solcher Testprozess aussieht wollen wir am Beispiel der Datenqualitätsauswertung im nächsten Artikel betrachten.

Geschrieben in Back-End Tests,RapidRep | Keine Kommentare

Deutsche Version des Test-Glossars hinzugefügt

Als weiteren Service für unsere Leser wurde die deutsche ISTQB Glossar-Version hinzugefügt. Diese kann hier gefunden werden: Glossar deutsch

Die englische und die russische Version folgen demnächst.

Geschrieben in Allgemein | Keine Kommentare

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.

1. Herstellen einer Verbindung zum Testprojekt:

TfsTeamProjectCollection tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("http://tfs:8080/tfs/DefaultCollection"));
ITestManagementTeamProject project = tfs.GetService<ITestManagementService>().GetTeamProject("dummy");

2. Zusammenstellen von relevanten Informationen (hier anhand von plan, suite und settingsid)

int planID = 12;
ITestPlan testPlan = project.TestPlans.Find(planID);

int suiteid = 22;
ITestPointCollection tpc = testPlan.QueryTestPoints("SELECT * FROM TestPoint WHERE SuiteId = " + suiteid.ToString());

int settingsid = 12;
ITestSettings testSettings = project.TestSettings.Find(settingsid);

3. Ermittelte Informationen dem TestRun zuweisen und durch Save() Methode den Testlauf starten:

ITestRun testrun = testPlan.CreateTestRun(true);
testrun.CopyTestSettings(testSettings);

string build = "C:\\testassemblies";
testrun.BuildDirectory = build;

testrun.Title = "TestRun";
testrun.AddTestPoints(tpc, null);
testrun.Save();
Geschrieben in How To,Microsoft Test Manager,VS UI Automatisierung | 1 Kommentar

Aufbau TFS Testtabellen

Wer sich mit Qualitätssicherung in TFS beschäftigt, wird früher oder später mit den dazugehörigen Testtabellen in Kontakt kommen (Query in tcm.exe, TFS API).
Folgender Blog Eintrag bietet eine gute Übersicht über die einzelnen einzelnen Tabellen und dazugehörigen Interfaces:
http://blogs.msdn.com/b/duat_le/archive/2010/02/25/wiql-for-test.aspx

Geschrieben in Microsoft Test Manager,Visual Studio 2012,Visual Studio Testframework | Keine Kommentare

Selenium WebDriver – MouseOver 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.
Selenium bietet hier die Möglichkeit mit Actions zu arbeiten. Aus dem Driver wird ein Actions Builder erzeugt, dieser kann dann eine MoveToElement Methode auf das gewünschte Webelement ausführen.


Hier ein einfaches Beispiel mit einem InputFeld auf der Google Seite:

IWebDriver driver = new FirefoxDriver();
driver.Navigate().GoToUrl("http://www.google.com/");
IWebElement query = driver.FindElement(By.Name("q"));

new Actions(driver).builder.MoveToElement(query).Build().Perform();
Geschrieben in Selenium,Webautomatisierung | Keine Kommentare

Neue Seleniumversion verfügbar

Seit etwa 2 Wochen steht die neue Selenium C# Assembly (Version 2.33.0) zur Verfügung.
Diese kann wie gewohnt von der Seite seleniumhq geladen werden:

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

Geschrieben in Selenium | Keine Kommentare

VS 2010 Testcontroller überfüllt die Partition

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

Geschrieben in Microsoft Test Manager,Visual Studio Testframework,VS UI Automatisierung | Keine Kommentare

Unittest / Coded UI Testmethoden mit WorkItem TestCase in Visual Studio 2012 verknüpfen

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.

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.
Geschrieben in Allgemein,Microsoft Test Manager,Visual Studio 2012,Visual Studio Testframework | Keine Kommentare

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 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;
}
Geschrieben in How To,Ranorex | Keine Kommentare

Lesetipp: Automated Software Testing Magazine

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
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
Geschrieben in Allgemein,Selenium,Webautomatisierung | Keine Kommentare