Qytera News

ISTQB Certified Tester - Prüfungsvorbereitung

In unserer neuen Artikelserie möchten wir euch berichten, wie man sich auf die ISTQB Certified Tester Prüfung vorbereiten kann.
Wir starten die Serie im Hinblick auf die Prüfungsvorbereitung für die Foundation Level Zertifizierung.

Warum die ISTQB-Zertifizierung?

Das International Software Testing Qualifications Board (ISTQB) ist weltweit die Nr.1 in Sachen Software Testing Zertifizierungen.
Es gab bis Juni 2015 über 560.000 Prüfungen und davon 410.000 Zulassungen in über 100 Ländern.

Viele Begrifflichkeiten im Bereich Softwaretest sind erst durch das ISTQB zum Standard geworden.

ISTQB Foundation Level

Das Foundation Level ist die Basis für mögliche Weiterbildungen zum (Technical) Test Analysten, Testmanager, zum Testautomatisierer oder auch zum Agilen Tester.

Es ist möglich, einen Kurs dazu zu belegen oder sich im Selbststudium auf die Prüfung vorzubereiten. Kurse werden von verschiedenen Firmen angeboten. Unten sind dazu einige Links.
Für das Foundation Level gibt es stets 40 Multiple Choice Prüfungsfragen und einen Zeitrahmen von 60 Minuten. Dabei sind 66% richtige Antworten zum Bestehen nötig.

Themen des Foundation Level sind:

  • Grundlagen des Softwaretestens
  • Testen im Softwarelebenszyklus
  • Testplanung, Steuerung, Durchführung und Bericht
  • Komponententest, Integrationstest, System- und Abnahmetest
  • Statischer Test
  • Durchführen von Reviews
  • Testfallentwurfsverfahren
  • Blackbox- und Whitebox-Verfahren
  • Testmanagement
  • Konfigurationsmanagement und Priorisierung von Tests
  • Typen, Auswahl und Einführung von Testwerkzeugen
  • Testspezifikation, Durchführung und Protokollierung

Als Prüfungsvorbereitung gibt es folgende Möglichkeiten:

  • Bei Stefan Bregenzer, Betreiber der Online Lernplattform Smartwebapps, gibt es nicht nur eine Datenbank mit Prüfungsfragen, sondern auch Tipps rund um das Thema ISTQB Zertifizierung und wie man sich im Selbststudium vorbereiten kann.
    http://smartwebapps.de/home

Zu Prüfungen anmelden kann man sich zum Beispiel bei:

http://de.gasq.org/
http://www.german-testing-board.info/

Einige Eindrücke:

  • Der Syllabus alleine reicht auf jeden Fall nicht aus, um ein angemessenes Verständnis zu entwickeln, kann allerdings trotzdem hilfreich sein, um einige Bereiche zu veranschaulichen.
  • Wieso sollen Wartungstests "bei Außerbetriebnahme eines Systems" durchgeführt werden?
    Die Gründe dafür können nachgelesen werden, von selbst wäre ich nicht darauf gekommen.
  • "Schlechte Softwareeigenschaften" sind keine Projektrisiken. Zum Verständnis braucht man den Kontext zu den Produktrisiken.
  • Mir haben außerdem einige Tipps sehr geholfen, dass z.B. bestimmte Begriffe immer mit Vorsicht betrachtet werden müssen, wie „immer“, „muss“, „niemals“ u.s.w.
  • Die Prüfungsfragen sind nicht zu unterschätzen. Die Fragensammlung auf smartwebapps.de ist beim Üben sehr hilfreich.
Tags: 

Testautomatisierung mit Geb

In den letzten Jahren sind einige Frameworks um Selenium entstanden, die die Tests im Browser robuster und wartbarer gestalten.

Geb ist ein Framework für Browser-Automatisierung. Dabei benutzt es Selenium WebDriver und setzt als Programmiersprache Groovy ein.

Was ist Groovy?

Groovy ist eine für die Java-Plattform konzipierte Programmiersprache, die Eigenschaften von Skriptsprachen wie Python oder Ruby mit denen von Java verbindet. Durch ihre Syntax kann Groovy sowohl als Skriptsprache eingesetzt werden (obwohl sie eigentlich keine ist), als auch als objektorientierte Programmiersprache. Wegen der Ähnlichkeiten zwischen Java und Groovy können in Java geschriebene Programme sehr oft auch als Groovy-Programme ausgeführt werden. Dadurch erleichtert sich die Erlernung dieser Sprache für Softwareentwickler, die schon Erfahrung mit Java haben.

Was ist WebDriver

WebDriver ist eine Schnittstelle für die Fernsteuerung von User Agents wie Browser oder Crawler und wird z.B. von Frameworks wie Selenium und Geb benutzt, um Browser zu automatisieren und Webinhalte zu testen.

Was Geb verbindet

Durch den Einsatz der mächtigen und Java-kompatiblen Sprache Groovy gibt Geb Softwaretestern ein effektives Werkzeug für die Entwicklung von automatisierten Tests. Geb kann leicht mit Test-Frameworks wie Spock, JUnit oder TestNG integriert werden. Das populäre Interface WebDriver gibt Geb eine solide Basis für die Browserautomatisierung.

Die Benutzung von Geb vor allem in Java-basierten Softwareprojekten ist aus diesen Gründen sehr empfehlenswert.

Weitere Links:

http://www.gebish.org

Tags: 

Lasttest (Load Testing) Konzept und Tools

Der Lasttest (engl. Load Testing) ist eine der wichtigsten (nicht funktionalen) Softwaretests, um die Belastbarkeit von Systemen wie z.B. Web-Applikationen zu prüfen. In diesem Artikel gehen wir näher auf diese Testart und die verschiedenen verfügbaren Tools wie JMeter, Grinder, HP Loadrunner, Silk Performer ein.

Lasttest

Jedes Softwaresystem ist für eine bestimmte Arbeitslast konzipiert. Manche sollen mehreren Nutzern gleichzeitig dienen, wie z.B. Content-Management-Systeme. Andere müssen eine Flut von Daten rechtzeitig bearbeiten können. Ein Ausfall solcher Systeme kann teils erheblichen Schaden oder finanzielle Verluste verursachen, weswegen es sehr wichtig ist, dass sie vor ihrem Einsatz Lasttests unterzogen werden.

In einem Lasttest werden im zu testenden System, wie der Name schon sagt, Lasten erzeugt. Ziel ist es zu sehen, ob das System diese Last bewältigen kann, ob z.B. eine Webseite mehreren Besuchern gleichzeitig in akzeptabler Zeit Antworten schicken kann oder ob ein Textverarbeitungsprogramm eine große Datei öffnen kann.

Es gibt verschiedene Arten von Lasttests. Allerdings sind diese nicht immer einheitlich definiert. Allgemein können Lasttests aber in vier Kategorien zusammengefasst werden:

Kann mein System das, was es soll?

Diese Art von Test ist das, was meistens gemeint ist, wenn man schlicht vom Lasttest spricht. Das System wird daraufhin überprüft, ob es die in den Anforderungen genannten Lasten bewältigen kann. Zum Beispiel: Angenommen, wir testen eine Web-Applikation, die gleichzeitig bis zu 100 Nutzer bedienen und Antworten innerhalb von 3 Sekunden senden soll. In einem Lasttest würde man diese Anzahl von Nutzern simulieren und überprüfen, ob die Antwortzeiten die genannte Grenze nicht überschreiten.

Was kann mein System?

Beim Kapazitätentest geht man einen Schritt weiter. Das System wird einem Test unterzogen, der dazu dient, seine maximalen Kapazitäten zu bestimmen. In unserem vorherigen Beispiel würde man die Web-Applikation nun nicht mit hundert Usern, sondern z.B. mit 110, dann mit 120 usw. Usern testen, bis die in den Anforderungen spezifizierte Antwortzeit von 3 Sekunden überschritten ist.

Was passiert, wenn ich mein System überlaste?

Beim Stresstest geht man noch einen Schritt weiter – das System wird unter eine Last gestellt, die es so nicht stemmen kann. Ziel ist es, das Verhalten des Systems unter extremen Belastungen zu überprüfen.
Nehmen wir an, der Kapazitätentest im vorherigen Beispiel hätte ergeben, dass die Web-Applikation maximal 150 simultane Nutzer bedienen kann, ohne dass die Antwortzeiten die vorgegebenen 3 Sekunden überschreiten. Nun wird die Applikation mit 200, 300 oder mehr Nutzern getestet. Wie lange sind die Antwortzeiten? Wann stürzt die Applikation ab? Wie wird mit so einem Absturz umgegangen? Diese und ähnliche Fragen versucht der Stresstest zu beantworten.

Kann mein System auch dauerhaft arbeiten?

Viele Softwaresysteme arbeiten rund um die Uhr. Bisher beschrieben wir Lasttests, die über einen kurzen Zeitraum ausgeführt wurden. Es ist aber wichtig zu überprüfen, ob das System auch über einen längeren Zeitraum korrekt funktioniert, ob z.B. Speicherlecks vermieden werden. Dies herauszufinden ist das Ziel des Dauerlasttests. Oft laufen diese Tests über einen oder mehrere Tage.
Beispiel: Unsere Web-Applikation soll 24 Stunden am Tag verfügbar sein. In einem Dauerlasttest, kombiniert mit einem „Standard“-Lasttest, wird nun überprüft, ob das System 100 User gleichzeitig über 36 Stunden bedienen kann.

Damit hätten wir die Hauptarten vom Load Testing beschrieben. Wir möchten nun kurz die verschiedenen Tools vorstellen, mit denen man Lasttests durchführen kann.

Load Testing Tools

Allgemein kann man die verfügbaren Tools in zwei Kategorien unterteilen.
Es gibt einerseits die kostenlosen Open-Source-Projekte. Oft sind sie leicht erweiterbar und damit sehr flexibel. Die populärsten unter ihnen haben eine große Community, was dazu führt, dass der Software viele Plugins zur Verfügung stehen. Der Nachteil ist, dass bei diesen Programmen oft die Einarbeitungszeit länger ist und es keinen professionellen Support gibt.

In der zweiten Kategorie der Lasttest-Tools sind die kommerziellen Programme. Oft gibt es individuelle Betreuung und eine leichtere Einarbeitung. Der Nachteil sind die teilweise hohen Anschaffungskosten von einigen hundert bis mehreren tausend Euro.

JMeter

Die in Java geschriebene Open-Source-Software von Apacheh ist die wohl populärste unter den kostenlosen Load-Testing-Tools. Ursprünglich wurde sie für Webanwendungen konzipiert, was auch weiterhin ihr Fokus ist. Sie wurde aber mittlerweile erweitert und bietet nun auch die Möglichkeit, andere Software zu testen, wie z.B. Datenbanken oder Message Oriented Middleware.

Grinder

Ebenfalls Open Source und sehr beliebt. Es ist Jython und Clojure geschrieben und hat einen starken Fokus auf das Testen von Software, die mit Java geschrieben ist.

HP LoadRunner

Das wohl bekannteste unter den kommerziellen Load-Testing-Tools von Hewlett-Packard ist ein sehr umfangreiches aber auch teures Werkzeug.

Silk Performer

Ein ebenfalls sehr umfangreiches Tool von Micro Focus Borland.

Load Testing ist heute in vielen Softwareprojekten unverzichtbar. Mit den richtigen Werkzeugen können Softwaretester diese Tests auf ihren Testobjekten erfolgreich ausführen.

Tags: 

Testautomatisierung mit Selenium WebDriver Best Practices

Selenium hat sich beim Testen webbasierter Oberflächen bewährt und ist bereits seit über elf Jahren auf dem Markt. Eine der wichtigsten Komponenten von Selenium ist das WebDriver API, das auch von vielen anderen Testframeworks eingesetzt wird.

Wie bei jedem Softwareprojekt gibt es auch bei der Testautomatisierung mit Selenium 2.0 einige Grundprinzipien zu beachten. Des Weiteren existieren Selenium-spezifische Besonderheiten, die der Testautomatisierer berücksichtigen muss. In diesem Artikel wollen wir kurz auf diese Prinzipien und Besonderheiten eingehen.

Testbarkeit

Um Software testen zu können, muss diese zunächst einmal testbar sein. Auch wenn es logisch klingt, die zu testende Software wird nicht primär für dieses Ziel entwickelt, sodass spezielle Anpassungen zur Testunterstützung der Testbarkeit eher die Regel sind. Wenn Sie Testautomatisierung in einem seit langem laufenden Softwareprojekt einführen wollen, kann die zu testende Software Ihnen das Leben sehr schwermachen, da Oberflächenelemente nicht eindeutig erfasst werden können.

Das wandelbare Testobjekt

Für die Tester in einem Softwareprojekt gilt: Das Testobjekt ändert sich. Diese Erkenntnis ist nicht nur für Projekte in der Entwicklungsphase gültig – auch während der späteren Wartungsphase können große und kleine Änderungen am Programm vorgenommen werden.

Softwareupdates können Pfade und Verlinkungen ändern, Namen oder Funktionen der Komponenten können modifiziert werden. Damit automatisierte Tests weiterhin funktionieren, müssen sie oft ihrerseits angepasst werden.

Um zu gewährleisten, dass dies ohne zu großen Aufwand geschehen kann, müssen von Anfang an gewisse Designprinzipien beachtet werden.

Page Objects

Um das Testprojekt wartbar zu halten, ist es wichtig, die einzelnen Komponenten in separaten Modulen zu pflegen. Eine effektive und populäre Methode hierfür ist das Page Object Design Pattern. In diesem Entwurfsmuster gilt, dass die Funktionen und Elemente des Testobjekts separat von den eigentlichen Tests kodiert werden.

Wenn z.B. eine Webseite zu testen ist, würden im Page Object die Elemente (Buttons, Textfelder, Slider etc.) und die Funktionen (Suchen, Einloggen etc.) definiert sein. Die separat geschriebenen Tests würden auf diese Elemente und Funktionen über das Page Object zugreifen.

Der Vorteil dieser Methode ist, dass sich das Testprojekt Änderungen leicht anpassen kann. Wenn z.B. an dieser Webseite der Name eines Textfelds geändert wird (und dadurch sich der Pfad, mit dem auf dieses Element zugegriffen wird, ebenfalls ändert), dann muss nicht jeder Test, der dieses Textfeld benutzt, angepasst werden, sondern nur das Page Object.

Selektoren

Die richtige Wahl bei Selektoren stellt sicher, dass Komponenten eindeutig identifiziert werden können. Es gibt mehrere Arten von Selektoren – Identifizierung über die ID des Objektes, zum Beispiel, ist sehr einfach, es kann aber unter Umständen passieren, dass zwei Objekte die gleiche ID haben.

Aus gutem Grund populär sind Xpath- und CSS-Selektoren, wobei die letzteren zwar schwieriger aufzubauen, dafür aber schneller, robuster und weit verbreitet einsetzbar sind. Beide erlauben eine eindeutige Identifizierung des Objektes.

Lesbarer Code

Die Namen von Variablen und Methoden sollten aussagekräftig sein. Das Gleiche gilt für die Namen von Tests – der Name sollte nicht nur sagen, was getestet wird (z.B. loginTest), sondern auch wie und welches das erwartete Ergebnis ist; z.B. loginTest_validPassword_HTTP200 sagt uns, dass der Login-Test mit einem gültigen Passwort durchgeführt wird und das erwartete Ergebnis eine Antwort mit dem HTTP-Statuscode 200 ist.

Ebenfalls wichtig ist, dass es im Projekt eine konsistente Namensstruktur geben sollte. Vor allem in größeren Teams sollte diese Struktur von vorneherein vereinbart werden.

Kommentierter Code

Egal wie lesbar der Code ist, die natürliche Sprache ersetzt er nur selten. Oft brauchen selbst die eigentlichen Programmierer eines Softwareprojekts viel Zeit und Aufwand, um nach einem Jahr ihren eigenen Code zu verstehen.

Deshalb ist es unerlässlich, das Programm umfassend zu kommentieren. Jede Methode sollte neben grundsätzlichen Informationen wie Name des Autors, Erstellungsdatum, Parameter und Rückgabewerte eine Beschreibung seiner Funktion haben.

Viele der hier aufgelisteten Prinzipien gelten auch für Softwareprojekte, denn es gilt: Ein Testautomatisierungsprojekt ist auch ein Softwareprojekt.

Tags: 

Qytera ist Sponsor des Frankfurter Entwicklertages 2016

Am 10 März 2016 findet in Frankfurt die Software Engineering Konferenz für die Rhein-Main-Region rund um die Themen Agilität, Qualität und Innovation statt.
Qytera ist zum ersten Mal Sponsor der Veranstaltung.
Die Konferenz behandelt folgende Themen:

  • Aktuelle Entwicklungen im Umfeld von JavaScript, Java und .NET, iOS und Android
  • Qualitätssicherung im agilen Prozess, Teststrategien, Testautomatisierung
  • Microservices und Cloud
  • DevOps: Infrastructure as Code, Docker, Continuous Delivery
  • Softwaresicherheit: Secure from Cloud to Web to App
  • Sanierung von Legacy-Systemen
  • Scrum reloaded

Wann? Frankfurter Entwicklertag, 10.-11. März 2016, Campus Westend, Goethe Universität Frankfurt.

Das Programm und Anmeldemöglichkeiten des Frankfurter Entwicklertages 2016 finden Sie hier:
https://entwicklertag.de/frankfurt/2016/

Tags: 

Linktipp: Interview mit Dan Cuellar, Erfinder von Appium

In diesem sehr interessanten Interview mit Dan Cuellar kann man viel über die Geschichte von Appium lernen.

Unter anderem werden folgende Themen besprochen:

  • Die Inspiration hinter der Erfindung von Appium
  • Die ersten Schritte der Entwicklung
  • Die Beteiligung von Jason Huggins am Projekt
  • Die Geschichte hinter dem Namen Appium
  • Der Hintergrund für den Wechsel von Python zu Javascript
  • Ein kritischer Blick auf die derzeitigen Mängel von Appium
  • Ausblick für die zukünftige Entwicklung von Appium
  • Die Rolle von Appium in Mobile Device Clouds

Wen diese Themen interessieren, kann das Interview lesen unter:
Interview mit Dan Cuellar, Erfinder von Appium

Tags: 

Teststrategien beim Mobile Testing

In der heutigen Entwicklung gibt es drei Arten von mobilen Applikationen: Native, hybride und Web-Apps.

Native Apps bestehen aus ausführbarem Code, der direkt auf dem mobilen Gerät installiert wird und für eine spezifische Plattform konzipiert ist. Native Apps können oft auf die verschiedenen Hardware-Komponenten des Geräts zugreifen.

Wie der Name schon sagt sind Web-Apps im World Wide Web zuhause. Auf dem Device des Benutzers wird kein Code installiert, es können aber einige Daten lokal gespeichert werden. Der Benutzer verbindet sich, zum Beispiel durch Benutzung eines Browsers, mit dem im Web angebotenen Service. Eine vorherige Installation ist nicht nötig.

Hybrid-Apps besitzen Eigenschaften beider vorangegangenen Applikationsarten. Neben einem ausführbaren Code, der wie bei nativen Apps auf dem Gerät installiert wird, beruht ein großer Teil ihrer Funktionalität auf Services, die im Web angeboten werden und mit dem sich der Benutzer über einen in der Hybrid-App eingebauten Browser verbindet.


Teststrategien

Native Apps besitzen in der Regel eine geringe Code-Portabilität, da sie hauptsächlich für eine bestimmte Plattform geschrieben werden. Um die Benutzung der App auf mehreren Plattformen zu ermöglichen, müssen oft Änderungen am Code vorgenommen werden, oder der Code gar in einer anderen Programmiersprache neu geschrieben werden. Oft hat man deshalb mehrere Versionen der App, die sich, je nachdem wie die App programmiert wurde, mehr oder weniger stark unterscheiden. Dies kann die Automatisierung der Tests erschweren.

Web-Apps hingegen müssen nicht auf dem Gerät installiert werden und haben somit eine hohe Portabilität – Devices aller Art müssen sie benutzen können. Dies vereinfacht die Testautomatisierung, da die Tests nicht auf verschiedene Plattformen zugeschnitten werden müssen.

Da eine Hybrid-App native und Web-Eigenschaften besitzt, muss ein Tester zwischen diesen beiden Unterscheiden und sie entsprechend testen. Manche Hybrid-Apps können auf Hardware-Komponenten wie z.B. der Kamera zugreifen – was bei Web-Apps nicht vorkommt, bei nativen Apps aber schon.

Jede App hat ihre eigenen Besonderheiten, die beim Mobile-Testing eine Herausforderung darstellen können. Ein Software-Tester kann sich auf viele dieser Herausforderungen einstellen, in dem er sich mit den Eigenschaften ihrer zugrundeliegenden Designkonzepten vertraut macht. 


Tags: 

Mobile Testing: professionelles Multi-Device-Testing mit BrowserSync

In dem letzten Artikel dieser Reihe schrieben wir über Ghostlab, mit dem das synchrone Cross-Browser-Testing und die Testautomatisierung leicht zu handhaben sind. Heute möchten wir eine kostenlose Alternative zu diesem Software-Tool vorstellen.

BrowserSync ist eine von der britischen Web Agency JH entwickelte Open-Source-Software, mit der man schnell und effektiv Webseiten über mehrere Geräte synchronisieren kann. Die Installation und Bedienung ist zwar nicht so einfach wie bei Ghostlab, sollte aber für den durchschnittlichen Software-Tester kein Problem sein.

BrowserSync ist ein Node.js-Modul, deshalb ist zuerst die Installation von Node.js nötig (siehe http://nodejs.org/download). Danach kann man BrowserSync mit dem Befehl npm install -g browser-sync installieren.

BrowserSync wird hauptsächlich über die Kommando-Zeile gesteuert. So wird zum Beispiel mit dem Befehl browser-sync start --proxy=http://www.qytera.de ein Proxy-Server gestartet. Danach müssen für einen Cross-Device-Test auf den Geräten lediglich die IP und der Port in der Browserzeile eingegeben werden, so wie bei Ghostlab.

Es gibt für BrowserSync aber auch eine Benutzeroberfläche, die das Einstellen der Optionen vereinfacht. Öffnen kann man diesen User Interface, indem man im Browser die Adresse localhost:3001 aufruft. localhost:3000 wiederum zeigt die zu synchronisierende Webseite.

BrowserSync ist sehr vielseitig. Es kann als eigenständiges NPM-Paket benutzt werden, oder auch als Grunt-Plugin. Ein weiterer Vorteil von BrowserSync ist, dass es neben Mac und Windows auch auf Linux läuft.

So wie Ghostlab, liefert auch BrowserSync das Remote-Debugging-Tool Weinre mit, das es ermöglicht, den Code der Webseite für jedes der angeschlossenen Geräte zu inspizieren.

Wer sich ein wenig mit der dahinterliegenden Technologie auskennt, wird in BrowserSync ein viel mächtigeres Werkzeug finden als in Ghostlab. Aber auch weniger erfahrene Nutzer können mit wenig Aufwand die wichtigsten Funktionalitäten von BrowserSync nutzen.


Tags: 

Testautomatisierung für Android und iOS mit Appium - Teil 2

Was ist Appium, Teil 2

Mobile Systeme haben in den letzten Jahren immer mehr an Bedeutung gewonnen. Mit der voranschreitenden Entwicklung und Verbreitung von mobilen Systemen wie Smartphones und Tablets, von mobilem Internet und Cloud Computing, wird das Testen von mobilen Apps immer wichtiger.

Der Erfolg von mobilen Applikationen wird bestimmt von deren Stabilität, Funktionalität und Sicherheit. Diese Eigenschaften können nur durch Softwaretests garantiert werden.

Softwaretests auf mobilen Geräten stellen eine größere Herausforderung dar als Tests auf Computern. Die kleinere Rechenkapazität und fehlende oder Eingeschränkte Eingabemechanismen wie Keyboards verhindern es, dass die Tests direkt auf den mobilen Devices geschrieben und ausgeführt werden.

Stattdessen befindet sich die Testsoftware meist auf standardmäßigen Computern und läuft mittels Proxys auf den Geräten.

Ein solches Proxy ist Appium, ein noch relativ junges Testframework, das in den letzten Jahren immer mehr an Popularität gewonnen hat. Obwohl die Entwicklung von Appium noch vorangeht, überzeugt es durch Features, die das Testen von Software auf mobilen Endgeräten stark vereinfacht.

Im vorherigen Artikel stellten wir die Vorteile und Nachteile von Appium vor. In diesem Artikel möchten wir auf die verschiedenen Features von Appium eingehen.

 

Appium Inspector

Appium Inspector hilft dem Softwaretester, die Hierarchie des Apps zu untersuchen. Mit ihm können XPath-Referenzen auf die Elemente der App leicht ausgelesen werden. Außerdem bietet der Inspector die Funktion, automatisierte Tests mit einem Recorder aufzunehmen und später abzuspielen.

Appium Doctor

Appium Doctor untersucht die Installation von Appium und informiert den Nutzer, ob alle Abhängigkeiten korrekt installiert wurden. Leider ist dieses Feature noch nicht auf Windows erhältlich.

 

Android/iOS Settings

Hier können die Einstellungen für die zu untersuchenden Geräte betätigt werden. Vorteilhaft ist, dass diese auch programmatisch eingestellt werden können. Bei der Testautomatisierung oder -parallelisierung ist dies unerlässlich, da die Anforderung, manuelle Einstellungen vorzunehmen die Tests unterbrechen würde.

Tags: 

Seiten