Asus Transformer TF101 Ice Cream Sandwich
Seit Herbst bin ich stolzer Besitzer eines Asus Transformer TF101. Und auch wenn ich mit dem Tablet sehr zufrieden bin, auf das Update auf Ice Cream Sandwich habe ich schon gewartet.
Heute war es endlich soweit. Nachdem die Meldung im Internet war, dass es auch in Deutschland jetzt ausgerollt wird habe ich den Update-Check gestartet. Download und Installation des Updates verliefen ohne Probleme. Nach ca 15 Minuten war das Tablet mit ICS neu gestartet. Aber -welch Enttäuschung- es war langsam, träge, ständig kamen Meldungen, dass Apps nicht reagieren würden. DAS hatte ich mir von dem Update nicht versprochen.
Kurzes Suchen in Google brachte keine passenden Meldungen. Die wenigsten hatten Probleme, alle lobten die Geschwindigkeit von ICS. Lediglich ein Eintrag sprach von Problemen. Aber die schienen wesentlich heftiger zu sein. Immerhin gab es dort Tipps was man denn bei Problemen mit dem Update machen kann.
- Alle Apps updaten
Flash und Google+ brauchen anscheinend nach den Update auf ICS selbst noch ein Update. Und HIER schien auch das Problem zu liegen. Nach jedem Neustart kam nach ein paar Minuten die Meldung Google+ müsse beendet werden. Ich hatte dem bisher keine Beachtung geschenkt. Leider ließ sich das Update nicht installieren. Das Herunterladen blieb immer hängen.
Kein Update --> Weiterhin Probleme - Kaltstart
Man kann das Gerät mit einem Hardware-Reset neu starten. Dazu muss man die Power und die Volume Down Taste bei ausgeschaltetem Gerät so lange drücken, bis im Display oben Links ein kleiner Text erscheint.
Dies hat bei mir jedoch auch nicht zum erhofften Erfolg geführt. Weiterhin wollte sich Google+ updaten und hat dabei wohl einiges an CPU-Last erzeugt. - Rücksetzen auf Auslieferungszustand (Wipe Data)
Blieb noch der letzte Ausweg. Alles auf Anfang. Man verliert dabei jedoch alle persönlichen Daten. Vorher also falls möglich ein Backup machen. Auch hier Power und Volume Down gedrückt halten. Wenn die Icons "wipe" und "android" angezeigt werden jedech der Anleitung (oben Links) folgen und auf "Wipe" Umstellen.
Das Dauert dann einige Zeit dann begrüßt einen Andriod wie beim ersten Einschalten.
Nun hängt es davon ab, ob man ein Backup mit Google gemacht hat oder nicht. In meinem Fall habe ich das Backup wieder einspielen lassen. Worauf alle Apps wieder installiert wurden.
Noch ein paar Einstellungen machen, Accounts neu eintragen und....
WOW Ice Cream Sandwich rennt. Und das im wahrsten Sinne des Wortes. War das TF101 vorher schon nicht langsam (zumindest könnte man gut mit Arbeiten) ist es nun wirklich schnell. Gerade beim Anzeigen von PDFs merkt man eine deutliche Steigerung. Hier gab es früher bei größeren Dokumenten (ich lese öfters Zeitschriften im PDF Format mit gerne mal 20MB) doch eine kleine Verzögerung beim Blättern. Davon ist jetzt nicht mehr zu bemerken.
Chrome
für ICS steht nun auch der Chrome Browser als Beta zur Verfügung. Den muss man aber noch im Market installieren. Lohnt sich auf jeden Fall. Gegen den bei mir schon installieren Firefox gewinnt der Browser noch deutlich an Geschwindigkeit.
Fazit
ICS ist gelungen. Und Asus zeigt mal wieder, dass man auch Android Tablets relativ zeitnah mit Updates versorgen kann. Die Probleme mit dem Update scheinen an Google+ zu liegen und sind zwar unschön, aber nicht unlösbar.
Morgen wird ICS auf das Tablet meiner Mutter installiert. Mal sehen ob es da dann ohne Probleme geht.
Mit dem Android durch London
Bei meinem Kurztrip nach London wollte ich testen wie gut man mit dem Smartphone zurechtkommt und in wie Weit man sich damit das Leben als Tourist leichter machen kann. Hier nun das Ergebnis:
Vorbereitungen
Online gehen im Ausland ist immer noch ein recht teures Vergnügen. Als Telekom-Kunde gibt es momentan die Möglichkeit einen DayPass zu verwenden. 50MB für ca. 5€. Danach nach Volumen abgerechnet. Naja 50MB ist nicht die Welt, aber sooo viel mehr verbraucht man, wenn man nur das Smartphone verwendet auch wieder nicht.
Wenn man viel mit GPS arbeitet wird der Akku schnell leer. Zumindest mein HTC Desire Z hätte nie durchgehalten. Also einen zweiten Akku und ein Ladegerät mit dem man Handy und Ersatzakku gleichzeitig laden kann besorgen.
Zu guter Letzt noch die gewünschten Applikationen installieren.
Verwendete Apps
Google Maps / Navigation
GoogleMaps ist natürlich die Kern-Applikation. Wann immer man nicht weiter weiß das Handy zücken. Kurz warten bis GPS einen gefunden hat und schon weiß man wo man ist und in welche Richtung man schaut. Für kürzere Strecken kann man auch die Fussgängernavigation verwenden. Zielsicherer und schneller kommt man mit Stadtplan niemals ans Ziel. Zumal man ja nichtmal Adressen/Strassennamen wissen muss. Der nächste Starbucks (ist eh nie wirklich weit weg, aber man will ja nicht in die falsche Richtung laufen), die nächste U-Bahn Station? Alles innerhalb von Sekunden zu finden.
London Tube
http://www.zuti.co.uk/Zuti_Maps/London/London_Tube.aspx
Für grössere Strecken bietet sich in London die U-Bahn an. Das ist eigentlich so schon recht einfach gelöst, wer den U-Bahn Plan nicht versteht sollte London meiden *g*. Aber es geht noch einfacher. Diese App funktioniert zum Glück auch offline (in der U-Bahn hat man ja nur selten Empfang als T-Mobile Kunde). Einfach Startstation und Zielstation aus der Liste oder der Karte Wählen und schon wird gezeigt wie man am Einfachsten dort hinkommt. Mit der geschätzten Fahrtzeit, Umsteigestationen und wie viele Stationen man fahren muss. Vorbei die Zeiten in denen man vor dem Plan stand und sich die richtige Route rausgesucht hat.
Die App stürzt leider ab und an ab, aber startet danach ohne Probleme sofort wieder. Da es sich um eine Offline-App handelt sind nicht alle Störungen und gesperrte Stationen eingetragen.
Barclays Bikes
market://search?q=pname:uk.co.barclays.cycle
Im Zentrum von London hat Barclays hunderte von Fahrrad-Parkstationen aufgebaut. Für 1 Pfund pro Tag kann man sich dort ein Fahrrad nehmen und an einer anderen Station wieder abgeben. Diese App hilft einem die nächste Station zu finden. Für kurze Strecken eine gute Alternative zum Laufen. Man muss sich nur in den Londoner Verkehr trauen....
Es geht los...
Die Navigation zum Parkplatz war dank Navigon App kein größeres Problem. Der Stau wurde auch gleich in die Ankunfszeit eingerechnet. Umfahren machte wohl keinen größeren Sinn (meinte zumindest Navigon)
Im Flieger war das Handy natürlich ausgeschaltet (ich hab noch einen richtigen mp3 Player!). Kaum durch den Zoll kam die erste Ernüchterung. ICH WAR OFFLINE. Handyempfang war ohne Probleme möglich. das "R" zeigte auch an, dass ich im Roaming-Modus war. Dem hatte ich aber erlaubt online zu gehen. Trotzdem NICHTS. Keine Mails, Keine Maps, kein Internet.
Trotzdem ging es weiter. Per Stansted-Express Bus Richtung London Victoria Station. Und -oh Glück- der Bus hatte freies WLAN. Während ich versuchte eine passende Einstellung fürs Roming zu finden kam London immer näher. Nach fast net Stunde habe ich aufgegeben. Noch schnell per Maps geschaut wie ich von der U-Bahn Station (Russel Square) zum Hotel komme und den Rest der Fahrt gemütlich aus dem Fenster mir London schonmal angesehen.
...und es wart ein Netz...
Als wir dann im dichten Londoner Verkehr im Stau standen war es dann plötzlich soweit. Ich war wieder online! Anscheinend ist das mit der flächendeckenden Versorgung mit mobilem Internet so eine Sache. Ich konnte also an der Victoria Station aussteigen mit der Gewissheit mich jederzeit zurechtfindenzu können.
Einer U-Bahn Verbindung zum Russel-Square war dank App schnell gefunden. Und auch der Weg zum Hotel war durch Google Navigation kein Problem.
Sightseeing
Ich hatte beschlossen die Stadt auf eigene Faust mit öf.fentlichen Verkehrsmitteln zu erkunden. Im Internet gibt es ein paar Touren mit denen man die meisten Sehenswürdigkeiten per Bus erreicht. Blöd nur, wenn die Busse sich so gar nicht an den Fahrplan halten (gut bei dem Verkeher erwartet das wohl auch Keiner). Als aber nach 30 Minuten der 9er immer noch nicht gekommen war (und der sollte alle 7 Minuten fahren) Habe ich beschlossen die erste Etappe zu Fuß zu bewältigen. Mit Google Navigation das Ziel eingegeben und losgelaufen. Ecke Hydepark ist es mir dann aber doch zu Viel geworden. Schnell das nächste Fahrrad gesucht und die letzten Kilometer per Pedes erledigt.
So in der Art ging das dann Weiter. Mal Bus, mal zu Fuß oder per Bike. Dank Smartphone ohne Probleme.
Neben der reinen Navigation gibt das Handy natürlich auch Informationen über Sehenswürdigkeiten preis. Es gibt mehrere Applikationen für WikiTravel. Leider haben die alle nur die englische Version angezeigt. Ich hatte mich mit der deuschten Vorbereitet. Aber die kann man ja ohne Probleme im Browser verwenden.
Wenn der Magen knurrt...
...dann hat man in London eh kein größeres Problem etwas zu Essen zu finden. Sucht man aber eine bestimmte Kette (z.B. McDonalds) dann hilft einem natürlich auch Google wieder weiter.
...und in der U-Bahn
Ja in der U-Bahn gibts kein Netz... oder zumindest kaum ein Netz. Ein Glück, dass die London-Tube App offline funktioniert. Während die Touris um mich rum immer ihren Plan ausgepackt haben und lange Diskutierten welche der möglichen Routen denn die Beste wäre, habe ich das innerhalb von ner Minute mit dem Handy geklärt und Stand schon am Bahnsteig.
Dabei fällt man in London nicht mal auf. Die hälfte der Leute schaut eh die ganze Zeit auf ihr Handy.
Fazit
Ich kann die Verwendung eines Smartphones nur empfehlen. So sicher habe ich mich noch durch keine Großstadt bewegt. Was der Spaß jetzt letztendlich kostet werde ich mit der nächsten Abrechnung sehen. Ein Reiseführer ist sicherlich günstiger. Aber bei weitem nicht so komfortabel.
Nachtrag
Die Handy-Rechnung ist jetzt gekommen. 16,80€ hat das Ganze jetzt gekostet. kein Schnäppchen, aber das war es schon wert.
Machen wir die Heizung ein wenig smarter
Okay zugegeben, ganz dumm war meine Heizung bisher auch nicht. Mit Außensensor, Nachabsenkung Party und Urlaubssteuerung konnte man schon etwas regeln. Was mich gestört hat war aber, dass ich immer nur das ganze Haus heizen kann. Oder ich renne durch alle Zimmer und drehe an den Thermostaten. Ich brauche morgens aber nur das Bad, Schlaf und Wohnzimmer wirklich warm. Der Rest kann weiter mit abgesenkter Temperatur betrieben werden.
Also müssen für die erste Ausbaustufe die Thermostate in den einzelnen Räumen mit intelligenz versorgt werden. Da es weitere Ausbaustufen geben wird habe ich mich für (auch aus Kostengründen) für FHT80b Sets entschieden. Diese können zum einen Stand-alone als auch in Kombination mit einer zentralen Steuerung betrieben werden.
So kann für jeden Raum auf die Minute genau gesteuert werden, welche Temperatur zu erreichen ist. Dabei kann man sowohl ein Programm für Arbeitstage und eines für das Wochenende einstellen.
So heizt unter der Woche Schlafzimmer, Bad und Wohnzimmer ab 6:10 hoch. Ab 6:50 gehen alle Heizungen wieder auf den Absenkbetrieb zurück. Abends werden ab 17:30 Wohn und Arbeitszimmer geheizt, ab 22:00 zusätzlich Bad und Schlafzimmer. Ab 23:00 wird dann bei allen Heizungen wieder der abgesenkte Wert eingestellt. Am Wochenende wird das ganze HAus ab 8 bis 23:30 geheizt.
Zusätzlich zur Zeitsteuerung gibt es noch die Möglichkeit über einen Fensterkontakt die Heizung im Raum runterzuregeln, wenn das Fenster geöffnet ist.
Diese Umstellung ist schon ein Schritt in die richtige Richtung. Nur sind mir die Zeiten noch zu statisch. Sollte ich je vor 17:30 nach Hause kommen ist es erstmal ziemlich kalt. Hier muss noch Abhilfe geschaffen werden.
Das dumme Haus
Grundlegend sind Häuser ziemlich dumm. Sie stehen herum und reagieren auf so gut wie keinerlei Einflüsse von Innen oder Außen. Und wenn wir ganz ehrlich sind ist das eigentlich auch gut so. Wäre ja schlimm, wenn so ein Haus bei Regen plötzlich schmilzt oder bei Wind davonläuft.
Aber es gibt Situationen da wünscht man sich schon, dass ein Haus nicht ganz so dumm, oder um es treffender zu nennen "smart" wäre. In der Kategorie "smartHome" versuche ich mein Haus etwas smarter werden zu lassen. Schritt für Schritt werden einzelne Bereiche optimiert.
Ideen gibt es viele. Nur muss der Nutzen natürlich im günstigen Verhältnis zu den Kosten und Aufwand stehen.
Junit 4.1
Das Referat über JUnit habe ich in Zusammenarbeit mit Mircea Dumitru geschrieben.
Referat als PDF: JUnit_4_1.pdf
JUnit in einem Satz
JUnit ist ein Java-Framework für die Erstellung von Unit Tests
Definition von JUnit
JUnit ist ein Framework zum Testen von Java-Programmen, das besonders für automatisierte Unit-Tests einzelner Units (meist Klassen oder Methoden) geeignet ist. Es basiert auf Konzepten, die ursprünglich unter dem Namen SUnit für Smalltalk entwickelt wurden.
Einleitung
Warum Testen?
In der heutigen Zeit, wo Softwareprodukte immer komplexer werden, ist vor allem die Qualität einer Software sehr wichtig. Da aber komplexe Software in begrenzter Zeit nur unvollständig erfassbar und realisierbar ist enthält jede Software Fehler.
Um diese Fehler zu aufzudecken werden Tests notwendig, die eine teilweise hohe Softwarequlität sicherstellen können.
Ziel eines Tests ist somit eine Software mit der Absicht zu prüfen, Fehler zu finden.
Ein Test sollte:
- Fehler so früh wie möglich finden
- unabhängig erfolgen
- mehr bringen als kosten
- automatisiert wiederholbar sein
- möglichst zeitnah zur Programmierung sein
- Spaß machen
Ein Test sollte nicht:
- keine Fehler finden
Somit kann ein Test nicht die Korrektheit eines Software beweisen, sondern nur die Anwesenheit von Fehlern.
Softwaretestarten
Tests können bzgl. eines Testobjekts in verschiedene Testarten klassifiziert werden:
- Unit –bzw. Modul Tests
- Integrationstests
- Performance Tests
- Funktionale –und Akzeptanz Tests
Unit –bzw. Modul Tests
Unit –bzw. Modul Tests dienen zur Verifikation der Korrektheit der einzelnen Softwarebausteine (Module; je nach Programmiersprache z. B. Klassen). Durch Ablauf aller Testfälle soll nach Programmfehlern gesucht werden. Hierzu wird ein ausführbarer Code erzeugt der die einzelnen Testfälle durchspielt und die Ergebnisse mit den erwarteten Werten vergleicht. Dabei prüft jeder Testfall immer nur ein mögliches Verhalten des Moduls ab, um hinterher genau feststellen zu können, wodurch ein Fehler erzeugt wurde.
Unit Tests sollten zeitnah zur Programmierung erstellt und nach jeder Programmmodifikation ausgeführt werden.
Integrationtests
Integrationstests prüfen die kortrekte Interaktion voneinander abhängiger Komponenten in einem komplexen System. Dazu müssen die zu prüfenden Komponenten den Unit-Test erfolgreich abgeschlossen´haben um zu zeigen, dass sie isoliert fehlerfrei funktionieren.
Performance Tests
Performance Tests dienen dazu das Verhalten einzelner Module oder Systeme bezüglich einer definiterten Hardwareumgebung zu Testen. Im Mittelpunkt steht dabei, ob das System die vom Kunden gewünschte Reaktionszeit einhält und auch unter hoher Auslastung keine Fehler produziert.
Funktionale Tests
Funktionale Tests dienen dazu, die vom Kunden gewünschte Funktionalität des Systems unter Real-Bedingungen zu prüfen. Dabei wird getestet ob das entwickelte System den Anforderungen des Auftraggebers oder späteren Benutzers entspricht.
Unit Testarten
Die weitere Klassifizierung von Unit Tests basiert auf drei verschiedene Unit Testarten:
- Logischer Unit Test
- Integrations Unit Test
- Funktionaler Unit Test
Logischer Unit Test
Der Logische Unit Test überprüft nur einzelne Methoden bestimmter Klassen eines Softwaresystems.
Integrations Unit Test
Der Integrations Unit-Test überprüft das Zusammenspiel zwischen den einzelnen Komponenten eines Softwaresystems.
Funtionaler Unit Test
Der Funtionaler Unit-Test erweitert die Grenzen des Logischen Unit Tests und Integrations Unit Test so, dass Arbeitsabläufe getestet werden können. Die einzelnen Arten von Unit Tests können als White-Box-Test oder als Black-Box-Test durchgeführt werden.
White-Box-Test
Der White-Box-Test wird von den gleichen Programmieren entwickelt und durchgeführt wie das zu testende System selbst. Dabei besteht eine Kenntnis über die innere Struktur des Testobjektes.
Black-Box-Test
Der Black-Box-Test wird von speziellen Testabteilungen entwickdet und durchgeführt. Dabei besteht keine Kenntnis über den inneren Aufbau des zu testenden Objektes.
Herleitung der Testfälle
Die wichtigsten Bausteine, um erfolgreich zu Testen, sind die richtigen Testfälle. Es nutzt wenig, wenn man 20 Tests durchführt die im Endeffekt das Selbe Verhalten abprüfen, man dafür jedoch ein anderes Verhalten komplett übersieht. Für die Herleitung der Testfälle gibt es verschiedene Methoden, die wir hier auszugsweise aufzeigen wollen.
Äquivalenzklassenmethode
Bei der Äquivalenzklassenmethode werden Eingabeparameter eines Moduls oder einer Methode, die das gleiche Verhalten haben, in Klassen eingeteilt. Dazu wird die Spezifikation des Moduls oder der Methode analysiert.
Beispiel:
Man betrachtet ein Modul, dass nur Geldbeträge zwischen 0,01€ und maximal 500€ verarbeiten soll. Nun kann man alle Werte zwischen 0,01 und 500 zu einer Klasse zusammenfassen. Man wählt aus diesem Bereich dann einen Wert zum Testen aus. Ist der Test mit diesem Wert erfolgreich kann man davon ausgehen, dass er auch für alle anderen Werte der Klasse erfolgreich verläuft.
In diesem Beispiel kann man 3 Äquivalenzklassen bilden:
- 0,01 <=x <= 500
- x<=0
- x>500
Prüft man aus diesen Bereichen jeweils einen Wert ab, kann man das Verhalten des Moduls testen.
Grenzwertanalyse
Die Grenzwertanalyse ist eine Erweiterung der Äquivalenzklassenmethode. Zusätzlich wird hier besonderes Augenmerk auf die Grenzen der Spezifikationen gelegt, da die Fehler sich in diesem Berech häufen.
In unserem Beispiel würde man die 3 Testfälle für die Äquivalenzklassen um folgende Testfälle erweitern:
- -0,01
- 0,00
- 0,01
- 500,00
- 500,01
Vorgehensmethoden zur Softwareentwicklung
Testgetriebene Entwicklung
Von testgetriebener Entwicklung spricht man, wenn bei der Softwareentwicklung der Testplan vor der eigentlichen Implementierung erstellt wird. Während bei der klassischen Vorgehensweise der Test erst nach Fertigstellung des Moduls/Systems erstellt wird.
Nachteile wie mangelnde Testbarkeit, Zeitmangel, unzureichende Tests werden bei dieser Methode vermieden.
Testgetriebene Entwicklung arbeitet mit Tests auf zwei Ebenen.
Testen im Kleinen
Diese Tests beziehen sich auf die einzelnen Module des Systems. Hierbei wird der Testplan während der Entwicklung mit entwickelt. Man teilt die Implementierung in kleine Portionen auf z.B. in einzelne Methoden. Vor jeder Implementierung einer Methode werden die dazu gehörenden Testfälle erstellt. Dann wird (noch vor der Implementierung der Methode) ein Testlauf durchgeführt, der fehlschlägt. Nun wir die Methode implementiert und anschließend wieder getestet. Dies wiederholt sich so lange, bis alle Testfälle positiv beendet werden. Danach räumt man den Sourcecode auf und kümmert sich um die Kommentare. Ein abschließender Testlauf stellt sicher, dass man dabei keine Änderungen an der Funktion der Methode vorgenommen hat.
Testen im Großen
Diese Tests beziehen sich auf das gesamte System. Die Testfälle lassen sich aus den Spezifikationen ableiten und werden schon vor der Systemimplementierung aufgestellt.
Mit Hilfe dieser Tests kann geprüft werden, ob das System den Anforderungen des Kunden genügt.
Vorteile
Die Vorteile der testgetriebenen Entwicklung liegen in der verringerten Fehleranzahl (besonders bei Änderungen) und einer besseren Messbarkeit der Anforderungen. Da nur korrekte Module gespeichert werden, kann jeder Programmierer meistens auf „korrekte“ Module zugreifen um mit ihnen zu arbeiten. Des Weiteren fördert diese Vorgehensweise das „Think first – code later“-Prinzip, da man sich vor der Implementierung schon Gedanken über die Testfälle und damit auch über mögliche Probleme macht.
Weiterführende Tests
Dieses Kapitel widmet sich weiterführenden Tests, die auch über den Rahmen von JUnit hinausgehen.
Integrationstest (Cactus)
Cactus erlaubt es einem Integrationstests von Servlets und JSPs durchzuführen. Dabei wird das zu testende System auf dem Zielsystem ausgeführt um sein Verhalten in der Laufzeitumgebung zu prüfen. Es erweitert JUnit und verwendet im Moment noch JUnit 3.8.1.
Die Testfälle sind gleich aufgebaut wie bei JUnit selbst. Man kann die Tests sowohl manuell über die Komandozeile, als Plugin in einer IDE, oder im Webbrowser ausführen. Als Ergebnis bekommt man eine Zusammenfassung als XML-Datei die fehlgeschlagene Tests aufzeigt, oder aber eine Erfolgsmeldung zurückgibt.
Funktionale Tests (HTTPUnit)
HttpUnit ist eine Erweiterung für JUnit um automatisierte Website-Tests durchzuführen. Es ermöglicht die zurückgegebene Seite zu analysieren und z.B. dort enthaltenen Links zu folgen. Somit kann das Surf-Verhalten von Usern simuliert werden. Zusätzlich kann man auch Formulare oder JavaScript ausführen.
Load/Performance Testing (JMeter)
Bei JMeter handelt es sich um ein umfangreiches Testtool um Systeme unter großer Last zu testen. Hierzu erzeugt das Tool je nach Vorgabe eine große Anzahl von Threads, die alle auf das gleiche System zugreifen und misst dabei z.B. die Latenzzeit oder den Datendurchsatz. Dabei unterstützt es unter Anderem folgende Tests:
- http, ftp
- Datenbanken über JDBC
- Java
- JUnit
- Webservices
- LDAP
Da dieses Tool die Möglichkeit hat die Tests über mehrere Rechner zu verteilen kann damit auch ein Lasttest gegen größere Maschinen durchgeführt werden.
Load Testing (JUnitPerf)
Mit JUnitePerf kann man erweitert man JUnit um die Funktion Performance-Parameter abtesten zu können. So kann man vorgegebene Reaktionszeiten messen und testen. Zusammen mit einem Lastentest mit JMeter kann das System unter realen bzw. extremen Bedingungen getestet und somit verifiziert werden.