Website testen

TyRoXx

"Normalerweise" hat man dafür einen manuellen Testplan. Das kann eine Checkliste mit lauter Kleinigkeiten sein, die funktionieren müssen. Diesen Plan kann logischerweise nicht der Tester selbst definieren.

Shade Of Mine

Das geht idR über Functional Testing.

Selenium ist hier wohl eines der gängigsten Tools. Symfony hat zB sfTestBrowser als Tool oder aber es gibt auch Codeception welches Libraries anbietet.

Gibt wohl noch ein Eck mehr, aber Selenium ist quasi dein Goto-Tool.

PS:
TyRoXx hat natürlich Recht, dir sollte eine Liste gegeben werden was denn genau die Funktionalität der Webseite ist.
Ansonsten musst du selber die passenden User Stories schreiben.

Servus,

ich möchte an der Stelle noch mal pushen:

Wie genau darf ich mir denn den Einsatz von Selenium jetzt vorstellen? Nach etwas Recherche sieht es ja so aus als würde man im Endeffekt die entsprechenden Libs downloaden und dann in der IDE seiner Wahl eine Art von Unit-Tests schreiben.
Anbieten würde es sich wohl, dass man versucht die üblichen Prozesse der Website mit diesem Unit-Test zu simulieren und zu testen.

Habe ich das jetzt richtig auf dem Schirm? Das hört sich nach einer Menge Arbeit an. Aber ich denke mal, dass der Sinn sozusagen ein einmaliger Aufwand sein soll, mit dessem Ergebnis man danach komfortabel automatisiert testen kann?

Ich werde noch weiter recherchieren und schauen was ich rausfinde, aber es wäre echt cool wenn hier jemand villeicht ein paar Worte dazu sagen kann!

Tobiking2

BitteTesten schrieb:

Nach etwas Recherche sieht es ja so aus als würde man im Endeffekt die entsprechenden Libs downloaden und dann in der IDE seiner Wahl eine Art von Unit-Tests schreiben.

Unit-Tests sind es nicht. Es sind Systemtest oder auch End-to-End Test, weil du nicht einzelne isolierte Module testest, sondern das Komplettsystem.

BitteTesten schrieb:

Habe ich das jetzt richtig auf dem Schirm? Das hört sich nach einer Menge Arbeit an. Aber ich denke mal, dass der Sinn sozusagen ein einmaliger Aufwand sein soll, mit dessem Ergebnis man danach komfortabel automatisiert testen kann?

Genau. Für einen nachvollziehbaren Test musst du eh einen Testplan schreiben. Der Mehraufwand den Testplan direkt als Script zu schreiben ist gering für die Zeit die man spart weil die Durchführung von allein läuft.

@Tobiking2 Danke erstmal für die Antwort

Ob es ein End-to-End Test ist könnte ich ja theoretisch selber steuern, oder? Sagen wir man will zunächst einfach mal nur sehen, ob zum Beispiel das GUI (Frontend) der Website so läuft, wie erwartet (zB nach einem Deployment, nur halt als Regressions-Test). Das läge dann wohl in der Hand des Test-Schreibers, ob er hier jetzt unter Berücksichtungen aller Endpunkte (Webservices, SQL-Abfragen, ... ) testet oder eben nur Frontend selber?

Wie würdet Ihr denn selber vorgehen? Wenn man danach recherchiert heißt es immer nur Selenium, Selenium, Selenium ... . Aber es gibt tatsächlich etliche tools, teilweise eigene Script-Sprachen, und und und.

Bietet denn Selenium soweit alles, was man sich so wünscht, oder hat da jemand andere Erfahrungen?

Sicherlich würde es Sinn machen auch ein paar komplett fertige Tools drüberlaufen zu lassen, zum Beispiel sowas wie ein Deadlink-Checker oder ähnliches?

Shade Of Mine

Fang mit Selenium an. Alles bietet Selenium nicht an und es gibt durchaus gröbere Hürden. Aber Selenium ist DAS Tool dass du Beherrschen musst wenn du solche Tests willst.

Also mach mal deine ersten Tests mit Selenium. Wenn du konkrete Fragen hast, frag ruhig.

PS:
So sachen wie "Deadlink Checker" sind eigentlich unnötig, weil ein Link ja eine Funktion hat. Und es ja nicht darum geht: ist der der Link "dead" oder nicht, sondern funktioniert die Funktion dahinter.

Mal abgesehen davon, dass Deadlinks eh instant in den Errorlogs auftauchen. Ich glaube du denkst hier in den falschen Bahnen. Es geht darum User Stories mit Tests abzudecken. Das ist die komplexität. zu Testen ob eine Seite einen Fehler wirft ist trivial. Was nicht trivial ist, ist herauszubekommen ob alles korrekt funktioniert.

@Shade of Mine:

Das war so ziemlich der Sinn meiner Frage ja Ich wollte generell einfach kurz mein Verständnis, was diese Sache betrifft, auf ein gewisses Level bringen. Somit kann ich wesentlich besser recherchieren, weil ich weiß, was ich von meinen Ergebnissen erwarte.

Sonst hat man halt immer den Gedanken im Hinterkopf, dass das noch nicht die richtige Lösung ist, dass es vielleicht mit Tool XY alles viel einfacher wäre, etc.

Ich denke um nun weiteres Verständnis zu erlangen wäre es am besten das zu tun, was du auch vorschlägst: Einfach mal ein Test tatsächlich schreiben.

Da fängt dann das Ganze an. Ich überlege gerade, was überhaupt sinnvoll zu testen wäre. Zu testen, ob falsche Eingaben (zB PLZ->Buchstaben werden eingeben) abgefangen werden, wäre wohl relativ sinnlos.

Puh, gar nicht so simpel sowas zu entscheiden.
Aber nun gut, das ist ja jetzt wohl meine Aufgabe.

Ich danke Dir/Euch

Tobiking2

BitteTesten schrieb:

Ob es ein End-to-End Test ist könnte ich ja theoretisch selber steuern, oder? Sagen wir man will zunächst einfach mal nur sehen, ob zum Beispiel das GUI (Frontend) der Website so läuft, wie erwartet (zB nach einem Deployment, nur halt als Regressions-Test). Das läge dann wohl in der Hand des Test-Schreibers, ob er hier jetzt unter Berücksichtungen aller Endpunkte (Webservices, SQL-Abfragen, ... ) testet oder eben nur Frontend selber?

Selenium testet auf der falschen Ebene für Unit-Tests. Das Frontend besteht üblicherweise schon aus verschiedenen Komponenten, die zudem aus Code, Styles und Markup bestehen. Und in der Kombination ist es eher selten ohne ein Backend lauffähig. Du hast einfach keine Chance dort irgendwas isoliert zu testen.

Für Unit-Tests suchst du dir eine Komponente raus und testest den Code indem du einzelne Funktionen gezielt aufrufst und benötigte Abhängigkeiten durch Mocks ersetzt. Im Prinzip gaukelt man der Komponente einfach eine bestimmte Antwort vom Backend vor und schaut ob sich die Komponente dabei wie erwartet verhält.

BitteTesten schrieb:

Wie würdet Ihr denn selber vorgehen? Wenn man danach recherchiert heißt es immer nur Selenium, Selenium, Selenium ... . Aber es gibt tatsächlich etliche tools, teilweise eigene Script-Sprachen, und und und.

Bietet denn Selenium soweit alles, was man sich so wünscht, oder hat da jemand andere Erfahrungen?

Selenium ist fein für E2E Tests. E2E Tests sind fein dafür einige wenige Fälle automatisiert über das ganze System laufen zu lassen. Wenn du einzelne Komponenten detaillierter testen möchtest, wirst du aber auch Unit Tests brauchen.

Man kann z.B. einen E2E Test schreiben, der einfach mal ein Produkt in den Warenkorb aufnimmt, prüft das er drin ist, und ihn dann wieder entfernt. Für Unit Tests würde man vielleicht testen was der Warenkorb macht wenn man -100 Produkte reinlegt, "ABCD" Produkte reinlegt etc.

Was ich eigentlich damit sagen möchte ist: Für eine vernünftige Testabdeckung brauchst du sowohl E2E als auch Unit Tests. Man kann immer beliebig viel testen, da kommt es darauf an wie viel Zeit man hat und Erfahrung um zu wissen was man priorisiert testet. Oft testet man an Stellen genauer wo man bereits Fehler gefunden hat. Denn ein Fehler kommt selten allein.

Was Frameworks für Unittests angeht, kommt es ein bisschen darauf an was gut zu eurer Entwicklungsumgebung passt. Ich habe bisher meistens mit Karma getestet, da man damit relativ fix und ohne viel Konfiguration auf verschiedenen Browsern testen kann. Passt aber nicht immer in jede Umgebung.

Shade Of Mine

BitteTesten schrieb:

Ich denke um nun weiteres Verständnis zu erlangen wäre es am besten das zu tun, was du auch vorschlägst: Einfach mal ein Test tatsächlich schreiben.

Da fängt dann das Ganze an. Ich überlege gerade, was überhaupt sinnvoll zu testen wäre. Zu testen, ob falsche Eingaben (zB PLZ->Buchstaben werden eingeben) abgefangen werden, wäre wohl relativ sinnlos.

Puh, gar nicht so simpel sowas zu entscheiden.
Aber nun gut, das ist ja jetzt wohl meine Aufgabe.

An die User Stories anknüpfen.

BitteTesten schrieb:

Da fängt dann das Ganze an. Ich überlege gerade, was überhaupt sinnvoll zu testen wäre.
Puh, gar nicht so simpel sowas zu entscheiden.
Aber nun gut, das ist ja jetzt wohl meine Aufgabe.

Ich danke Dir/Euch

Selenium bietet alle Möglichkeiten, die du brauchst und ist auch leicht zu lernen... (sofern es sich um eine 'einfache' Webseite handelt, die keine speziellen Elemente wie Flash, embedded Java, etc nutzt)

Ich nutze es gerade auch (zusammen mit jUnit) um ein (Web-) User Interface zu testen, aber man sollte sich vorher immer fragen ob der Aufwand sich lohnt für automatisierte Tests.
Je nachdem wofür die Webseite genutzt wird und wer sie nutzt (intern oder Kunde) ist es eine Test-Automatisierung vielleicht übertrieben.
(vor allem wenn die Webseite nur einmalig entwickelt wird und dann nie wieder angefasst wird)

Fürs den Anfang am besten immer versuchen einen konkreten (manuellen) Testfall zu automatisieren. Dabei sieht man ob es überhaupt Sinn macht oder nicht.

BitteTesten schrieb:

Zu testen, ob falsche Eingaben (zB PLZ->Buchstaben werden eingeben) abgefangen werden, wäre wohl relativ sinnlos.

Genau das ist sinnvoll!
Gerade bei der Testautomatisierung macht es Sinn eigentlich unnütze Tests (Validierung falscher Eingaben, etc) zu erstellen, weil alle anderen Funktionen die sowieso jeder Benutzer intuitiv richtig macht, werden automatisch dadurch getestet das die Webseite benutzt wird.

@Tobiking2 GIbt es denn da noch einen Unterschied, zu den Unit-Tests, die Backend-seitig sowieso schon bestehen? Jede Klasse im Backend hat meistens einen eigenen Unit-Test dazu, der auch schon beim Jenkins-Build mit berücksichtigt wird.

Ich denke mit Selenium kann man noch mal auf einer anderen Ebene testen. Wäre doof, wenn ich im Endeffekt aber bereits bestehende Dinge ein zweites mal testen lasse. Aber gut, da muss ich halt Hirnschmalz reinstecken und das ganze logisch etwas aufzwirbeln, dann sollte auch klar werden, ob es die gleichen Tests sind.

@Shades of Mine Die sollten ja theoretisch schon existieren ... habe allerdings bis jetzt keine gefunden. Vielleicht ist das ein guter Punkt, um solche zu schreiben.

@Lupo4u2_off Das macht mich sehr zuversichtlich, dass das Ganze bald mehr Sinn ergeben wird Die Website an sich ist tatsächlich "simpel", es wird nur JS/JSP verwendet im Frontend.

Sehr interessant auch, dass du meinst man sollte sowas wie Eingabe-Validierung doch testen. Hätte ich jetzt intuitiv wohl falsch gemacht, danke!

Lohnen tut es sich schon, ja. Die Website ist seit längerem fertig gestellt und das Team, das jetzt dahinter steht ist nur für die Wartung und WE's zuständig (Webshop)

Sofern ich jetzt gelesen habe besteht Selenium ja aus mehreren Anwendungen.

Bietet es sich an, zunächst ein paar simple Tests mit der "IDE" zusammen zu bauen und dann eben zum Beispiel in einen Webdriver Test zu übersetzen und dort auszubauen oder sollte man einfach direkt mit WebDriver loslegen?

Tobiking2

BitteTesten schrieb:

@Tobiking2 GIbt es denn da noch einen Unterschied, zu den Unit-Tests, die Backend-seitig sowieso schon bestehen? Jede Klasse im Backend hat meistens einen eigenen Unit-Test dazu, der auch schon beim Jenkins-Build mit berücksichtigt wird.

Ja, sie testen das Frontend.

Es kommt natürlich darauf an wie komplex die Logik in dem Frontend überhaupt ist. Wenn das Frontend hauptsächlich Daten vom Backend anzeigt, ist es meistens nicht nötig detaillierter zu testen. Wenn es aber z.B. darum geht das das Frontend die Preise der Produkte im Warenkorb selber zusammenrechnet, sollte das getestet werden (mit Gutschriften, Rabatte etc.). Wenn das Backend getestet wurde, wird es beim Kauf vermutlich den richtigen Preis verwenden, aber der Käufer wird nicht froh darüber sein das der angezeigte Preis falsch war.

@Tobiking2

Ah okay, sehr interessanter Ansatz um hier abzugrenzen. Ja bei uns ist tatsächlich so gut wie jede Logik im Backend umgesetzt. Jede wirklich relevante, sowas wie Preisberechnung zu mindestens.
(Beispielsweise: Warenkorb->Gutschein einfügen->Request an Backend, dieses sucht den Gutschein, fügt ihm der Warenkorb-Seite hinzu und kalkuliert den Preis neu, dann gibt es die gefüllte Seite (MVC) zurück).

Dennoch könnten solche Selenium-Tests aus meiner Sicht Sinn machen. Bin gerade dabei welche zu schreiben und ist schon ganz spaßig

Tobiking2

Ok, wenn das Backend sogar die Seitenfragmente zusammenbaut tut das Frontend ja wirklich nichts anderes als Eingaben übermitteln und daraufhin Teile der Seite zu ersetzen. Das braucht man nicht mit Unittests abdecken. Das empfangene Fragmente auch angezeigt werden, ergibt sich ja durch die Tests mit Selenium. Selbst das ausführliche Testen von Fehleingaben sehe ich nur als begrenzt nötig, da das Backend ja die Validierung vornimmt und die in den dort vorhandenen Unittests getestet werden sollte. 1-2 Testfälle die sicherstellen das auch Sonderzeichen etc. vernünftig ans Backend übertragen werden, sollten da reichen.

Hab mich jetzt die letzte Woche damit auseinander gesetzt und auch mal ein Test geschrieben.

Muss sagen, dass das ganze schon sehr cool ist.

Allerdings fühlt es sich noch sehr fragil an. Problem ist, dass bei der Website, die ich teste, viel JavaScript mit eingebunden ist. Überall ein bisschen.

Da kann man dann zum Beispiel in Chrome und IE von einem Dropdown ganz normal per Select.selectByValue etc. was auswählen, aber der FireFox macht Stress (Element not visible -> may not be interacted with). Weiß immer noch nicht wieso, das Element ist, rein aus dem HTML-Kontext, auf jeden Fall nicht disabled.
Hab ein Workaround dafür gefunden, aber nun jut.

Das größte Problem ist immer noch der IE. Während bei Chrome und FF jeweils 300 Testfälle alle positiv durchlaufen, schlagen bei IE um die 30 fehl. Weil irgendein Element plötzlich nicht mehr anklickbar ist.

Ich hab leider nicht mehr dazu gefunden, falls es einer zufällig weiß: Die implicit waits von Selenium ... beziehen die sich nur auf findElement(s) Aufrufe oder setzen die auch ein, wenn man zum Beispiel ein WebElement.click() ausführen will? Also greift der implicit wait auch, wenn ein Element (Noch) disabled ist?

Kann es sein, das du versuchst auf den gleichen Button nochmal zuzugreifen, nachdem du ihn gedrückt hast?
(dann kann es nämlich sein, dass das WebElement nicht mehr referenziert ist, weil z.b. die seite neu geladen wurde

Ich habe auch das Problem wenn z.b. ein 'Button' nicht als reiner (HTML) <button> dargestellt wird, sondern mittels CSS als UI element erstellt und über ein CSS flag enabled/disabled wird.
Dann ist der reine HTML <button> nicht sichbar oder nicht enabled und mittels Selenium kann man ihn dann nicht klicken.
(aber als Benutzer kann man trotzdem drauf klicken)
Könnte das ein Problem bei dir sein?

Lupo_off schrieb:

Kann es sein, das du versuchst auf den gleichen Button nochmal zuzugreifen, nachdem du ihn gedrückt hast?
(dann kann es nämlich sein, dass das WebElement nicht mehr referenziert ist, weil z.b. die seite neu geladen wurde

Ich habe auch das Problem wenn z.b. ein 'Button' nicht als reiner (HTML) <button> dargestellt wird, sondern mittels CSS als UI element erstellt und über ein CSS flag enabled/disabled wird.
Dann ist der reine HTML <button> nicht sichbar oder nicht enabled und mittels Selenium kann man ihn dann nicht klicken.
(aber als Benutzer kann man trotzdem drauf klicken)
Könnte das ein Problem bei dir sein?

Leider nicht, dann hätte ich eine schöne Erklärung des Fehlers

Scheint wohl einfach nicht gute Praxis zu sein, sowas wie "Klick dadrauf und dann klick auf den erschienen Button" zu schreiben. Das klappt zwar bei FF und Chrome in 100% aller Fälle. Bei IE aber nur in etwa 70%.
Anscheinend muss man eher sowas wie "Klick dadrauf und dann versuche für x Sekunden, den Button zu drücken, der eigentlich auftauchen sollte." schreiben. Umständlich aber ich denke es ist die beste Lösung dafür

Shade Of Mine

Für solche Fragen ist ein Selenium Fachforum wohl besser geeignet.
Ich kann mir nämlich nicht vorstellen dass das die beste Lösung ist.

Ich selber schreibe keine Selenium Tests, deshalb kenne ich die Tricks auch nicht. Aber prinzipiell funktioniert Selenium sehr gut - solche trivialitäten sind sicher schon per Standardlösungen abgedeckt.

Shade Of Mine schrieb:

Für solche Fragen ist ein Selenium Fachforum wohl besser geeignet.
Ich kann mir nämlich nicht vorstellen dass das die beste Lösung ist.

Ich selber schreibe keine Selenium Tests, deshalb kenne ich die Tricks auch nicht. Aber prinzipiell funktioniert Selenium sehr gut - solche trivialitäten sind sicher schon per Standardlösungen abgedeckt.

Eher nicht, fürchte ich.

Es gibt implicit waits, die beziehen sich aber - nach meinem Verständnis - nicht auf dieses Szenario.
Dann gibt es anscheinend auch eine automatische Prüfung von documument.ready-state. Wenn ich zum Beispiel einen Button klicke, der die Website neu lädt, dann erkennt Selenium das und wartet mit der nächsten Aktion, bis alles fertig geladen hat. Ohne, dass ich irgenwas dafür tun muss.

Sofern ich gelesen habe schreibt man Selenium-Tests wohl so, wie ich gemeint habe.

Aber Du hast Recht, das Selenium-Forum wäre jetzt wohl der deutlich bessere Ort, um sowas zu klären.

Danke trotzdem noch mal an alle Beteiligten!