Welches Problem löst das automatisierte Testen der Benutzeroberfläche?

Wir untersuchen derzeit automatisierte Benutzerschnittstellentests (derzeit führen wir automatisierte Unit- und Integrationstests durch).

Wir haben uns Selenium und Telerik angesehen und uns aufgrund des viel flexibleren Rekorders für letzteres als das Werkzeug der Wahl entschieden - und wir möchten nicht, dass Tester zu viel Code schreiben.

Ich versuche jedoch, den Gesamtnutzen zu verstehen. Was sind die Ansichten der Menschen und welche Art von Dingen funktionieren gut und was nicht?

Unser System wird ständig weiterentwickelt und wir veröffentlichen regelmäßig neue Versionen unserer (webbasierten) Plattform.

Bisher ist der Hauptvorteil das Testen von Regressionen, insbesondere bei mehreren Clientbereitstellungen unserer Plattform.

Wirklich auf der Suche nach den Ansichten anderer Leute. Wir "denken", dass es das Richtige ist, aber in einem bereits vollen Zeitplan suchen wir nach zusätzlichen Einsichten.

Als mein Team automatisierte UI-Tests implementierte, passierten viele großartige Dinge.

Erstens wurde das QA-Team beim Testen der Anwendung viel effizienter und auch beim Testen der Anwendung kompetenter. Der leitende QA erklärte, er könne neue QA-Mitglieder schnell auf den neuesten Stand bringen, indem er sie in die Testsuiten für die Benutzeroberfläche einführe.

Zweitens war die Qualität der QA-Tickets, die an das Dev-Team zurückgingen, besser. Anstelle von "Die Seite ist beim Klicken auf die Schaltfläche" Senden "kaputt" wurde der genaue Fall angezeigt, bei dem ein Fehler aufgetreten ist, damit wir sehen können, was in das Formular eingegeben wurde. Das QA-Team ging noch einen Schritt weiter, indem es alle fehlgeschlagenen Fälle überprüfte und andere Szenarien auf dieser Seite testete, um einen besseren Überblick über das Geschehen zu erhalten.

Drittens hatte das QA-Team mehr Zeit. Mit dieser zusätzlichen Zeit konnten sie an weiteren Designmeetings teilnehmen. Dies wiederum ermöglichte es ihnen, die neuen Testsuite-Fälle zu schreiben, während die Entwickler diese neuen Funktionen programmierten.

Auch der von uns verwendete Stresstest war Gold wert. Es hat mir ehrlich gesagt geholfen, nachts besser zu schlafen, weil ich wusste, dass unsere App so ziemlich alles aushält, was darauf geworfen wird. Wir haben einige Seiten gefunden, die unter Druck gerissen sind und die wir vor dem Start reparieren konnten. Einfach perfekt.

Das Letzte, was wir fanden, war, dass wir mit einigen Verbesserungen durch das QA-Team auch einige SQL-Injection-Tests an unserer App durchführen konnten. Wir haben einige Schwachstellen gefunden, die wir schnell beheben konnten.

Das Einrichten der UI-Testsuite nahm viel Zeit in Anspruch. Dort angekommen, wurde es zu einem zentralen Bestandteil unseres Entwicklungsprozesses.

Automatisierte UI-Tests sind die eigentlichen Integrationstests. Sie testen das gesamte System so, wie es tatsächlich verwendet wird, wenn es live ist. Das macht sie zu den aussagekräftigsten Tests. Sie neigen jedoch auch dazu, am sprödesten und am langsamsten auszuführen.

Halten Sie ein Auge auf die Kosten / Nutzen - Verhältnis (mit Sprödigkeit ein Teil der Kosten ist) und hestitate nicht , einige Dinge zu haben , die nur manuell getestet werden (aber stellen Sie sicher , sie sind getestet). Und wenn möglich, können Entwickler bestimmte Teile der UI-Testsuite mit ihrer lokal ausgeführten Version der App ausführen, damit sie während der Entwicklung von den Tests profitieren können.

Es ist natürlich ein absolutes Muss, dass die Tests automatisch auf einem Build-Server ausgeführt werden (mindestens einmal am Tag).

Wir wollen nicht, dass Tester zu viel Code schreiben.

IMO das ist ein Wunschtraum. Das Erstellen automatisierter Tests ist das Schreiben von Code. Recording - Funktionalität können Sie einen Teil dieser Code schneller schreiben helfen und schneller Einstieg mit manuell zu schreiben (und Sie langsam nach unten schrecklich , wenn Sie verpassen den Punkt , wo das Schreiben von Code manuell schneller wird), aber letztlich manuell das Schreiben von Code ist , was Sie wird am Ende viel tun. Besser hoffen, dass Ihr Test-Framework es gut unterstützt und sich bei seiner Entwicklung nicht zu sehr auf den (sehr verkaufsstarken) Wunsch konzentriert, Menschen, die keinen Code schreiben können, die Möglichkeit zu geben, automatisierte Tests zu erstellen.

und wir wollen nicht, dass Tester zu viel Code schreiben

Wir sind den umgekehrten Weg gegangen. Wir wollten, dass die Tester Code schreiben.

Hier ist der Workflow, mit dem wir begonnen haben. Dies ist nicht einfach, da das Management nicht unbedingt vom automatisierten Testen des Frontends abhängt . Sie sind bereit, sich mit "nah genug" zufrieden zu geben.

1. Benutzergeschichten.

2. Betriebskonzept. Wie die Geschichte wahrscheinlich funktionieren würde. Designprüfung.

3. Bildschirmskizze: UI-Design. Wie es aussehen würde.

4. Selenium-Skripte. Wenn alle Skripte funktionieren, ist die Veröffentlichung abgeschlossen.

5. Codieren und testen, bis das Skript funktioniert.

Automatisierte Tests sind die einzige Möglichkeit, um zu demonstrieren, dass die Funktionalität vorhanden ist.

Manuelles Testen ist fehleranfällig und kann vom Management außer Kraft gesetzt werden: "Es ist gut genug, diese fehlgeschlagenen Tests sind weniger wichtig als die rechtzeitige Veröffentlichung."

"Programmfunktionen ohne automatisierten Test gibt es einfach nicht."

Visuelle Präsentation ist eine andere Geschichte. Das manuelle Testen eines visuellen Layouts ist ein Ausnahmefall, da es sich entweder um ein ästhetisches Urteil handelt oder um das Betrachten spezifischer (kleiner) Probleme auf einem sehr großen und komplexen Bildschirm voller Pixel.

Bisher ist der Hauptvorteil das Testen von Regressionen, insbesondere bei mehreren Clientbereitstellungen unserer Plattform.

Die Automatisierung Ihrer Regressionstests ist eine gute Sache. Dies gibt Ihren Testern die Möglichkeit, interessantere Aufgaben zu erledigen - sei es durch das Hinzufügen automatisierter Tests, das Stresstesten Ihrer Anwendung oder eine Reihe anderer Dinge.

Durch die Automatisierung können Sie Ihre Entwickler auch dazu bringen, die Tests auszuführen, sodass Probleme vermieden werden, die erst später im Prozess entdeckt werden.

Wir haben uns Selenium und Telerik angesehen und uns aufgrund des wesentlich flexibleren Rekorders für letzteres als Werkzeug der Wahl entschieden

Ich bin mir nicht sicher, wie viel du darüber nachgedacht hast. Es gibt sicherlich auch andere Möglichkeiten. Haben Sie sich Watir , WatiN , Sikuli angesehen, um nur einige zu nennen?

und wir wollen nicht, dass Tester zu viel Code schreiben.

Ich fühle mich schlecht für die Leute, die diese Skripte warten müssen. In den meisten Fällen werden Skripte ohne Code, der leicht geändert werden kann, zerbrechlich und es dauert länger, das Skript zu ändern, als es neu aufzuzeichnen, was noch mehr Zeit verschwendet.

Ich versuche jedoch, den Gesamtnutzen zu verstehen. Was sind die Ansichten der Menschen und welche Art von Dingen funktionieren gut und was nicht?

Testautomatisierung ist eine schöne Sache, wenn sie richtig durchgeführt wird. Dies spart Zeit bei Regressionstests / -prüfungen, damit Ihre Tester mehr Zeit haben, das zu tun, was sie am besten können. Glauben Sie jedoch keinen Moment, dass es sich um eine Wunderkugel handelt. Die Entwicklung von Automatisierungsskripten nimmt viel Zeit in Anspruch, wenn die Anwendung bereits vorhanden ist, die Tests jedoch nicht. Sie müssen bei jedem Release ständig aktualisiert werden. Automatische Tests sind auch eine großartige Möglichkeit für neue Mitarbeiter im Team, um zu sehen, wie sich das System verhalten soll. Stellen Sie außerdem sicher, dass Ihre Tester entscheiden können, was automatisiert werden muss. Wenn es sich um einen kleinen Scheck handelt, dessen Prüfung nicht viel kostet, der sehr eintönig und leicht zu automatisieren ist, fangen Sie damit an. Beginnen Sie immer mit den Prüfungen, die durch die Automatisierung am meisten gewonnen werden, und arbeiten Sie von dort aus.

Bisher ist der Hauptvorteil das Testen von Regressionen, insbesondere bei mehreren Clientbereitstellungen unserer Plattform.

Dies ist der Hauptvorteil und kann bei korrekter Einrichtung die meisten Browser testen, die Sie mit einer kleinen Konfigurationsänderung benötigen würden.

Wir "denken", dass es das Richtige ist, aber in einem bereits vollen Zeitplan suchen wir nach zusätzlichen Einsichten.

Wie ich bereits sagte, ist die Testautomatisierung mit erheblichem Aufwand verbunden. Bei richtiger Ausführung habe ich jedoch noch kein Team getroffen, das sagte: "Ich wünschte, wir hätten unsere Testautomatisierung nicht eingerichtet."

Sie haben Recht, dass die Regression sehr groß ist. Ebenfalls -

• Wenn Ihre Tests modular geschrieben sind, können Sie durch Mischen und Anpassen von Testsätzen mehr für das Geld bekommen

• Wir haben automatisierte Testskripte für das Laden von Daten wiederverwendet, damit wir keine Datenbank löschen müssen, um große Tests durchzuführen

• Leistungstest

• Multithread-Tests

• auf Websystemen - Wechseln zwischen Browsern und Wechseln zwischen Betriebssystemen. Bei Problemen mit der Browserkonsistenz ist es sehr wichtig, eine möglichst breite Basis zu erreichen.

Dinge, die übersprungen werden müssen - insbesondere in Websystemen -, achten Sie auf Fälle, in denen Elemente Ihrer Anzeige mit dynamischen, sich ändernden IDs erstellt werden. Oft funktionieren automatisierte Testskripten nicht so gut, und Sie müssen möglicherweise gründlich überarbeitet werden, um dies zu aktualisieren.

Nur ein Beispiel: Genaues Messen der Dauer des Webseiten-Renderings

Mit Hilfe von Automatisierungstests ist es viel einfacher, die Leistung des Webbrowsers zu testen. Um die maximale Antwortzeit zu messen, die Sie wahrscheinlich akzeptieren, setzen Sie einfach eine Konstante in Ihren Testskripten und / oder übergeben Sie sie als Funktionsparameter, z. B. in diesem Pseudocode: $ sel-> wait_for_page_to_load ($ mypage, $ maxtime).

Browserübergreifende Tests mit niedrigen Werten können sehr aufschlussreich sein.

Die Alternative wäre, Mitarbeiter mit einer Stoppuhr Zeitmessungen durchführen zu lassen.

Automatisiertes Testen der Benutzeroberfläche bietet folgende Möglichkeiten:

• Wiederholen Sie die Prüfung einer großen Anzahl von Bauteilen schnell
• Denken Sie daran, jedes Mal eine große Anzahl von Funktionen zu testen
• Vergleichen Sie Läufe und Laufzeiten von Testsuiten, wenn die Anwendung wächst
• Setup läuft mit Hunderten von verschiedenen Eingaben und variablen Bedingungen
• Personen, die den Test nicht geschrieben haben, können ihn ausführen und visuelle Probleme erkennen
• Ermöglichen Sie Endbenutzern, schnell und einfach zu sehen, welche Anwendung verwendet wird
• Verteilen Sie die Testbenutzeroberfläche auf ein Netzwerk, einen Remoteserver oder einen Dienst
• Starten Sie den Volumentest mit parallelen Maschinen.

Wie andere angemerkt haben:

Telerik ...

das Werkzeug der Wahl aufgrund seines viel flexibleren Rekorders

ist für viele von uns eine rote Fahne.

Auf diese Weise aufgezeichnete Skripte sind in der Regel keine langfristige Lösung, da:

• Die Datenbank- / Objekt-ID ändert sich in der Regel von Fall zu Fall
• Manuell aufgezeichnete Skripte basieren häufig auf Seitenlayout-Tags, die sich häufig ändern
• Häufige Aktionen müssen immer wieder geschrieben werden, anstatt die Wiederverwendung zuzulassen (siehe SitePrism- und PageObject-Ansatz).
• Manchmal müssen Sie Tools wie xpath verwenden, um zusätzliche Informationen basierend auf den aktuellen Seiteninformationen abzurufen. Ein einfaches aufgezeichnetes Skript wird dies nicht tun.
• Entwicklern und Testern, die Code schreiben, wird nicht empfohlen, CSS-Klassen, IDs und HTML5-Datenattribute zu verwenden. Dies sind Methoden, die zu robusteren, wartbaren Tests führen.

Telerik hat jedoch einige Vorteile, die berücksichtigt werden sollten:

• richtet sich an mobile Kunden
• integrierte Tools zur Steuerung des Wachstums
• Unterstützt Android, iOS und Windows Phone

Ein Ansatz, der helfen kann, die Lücken zu schließen, besteht darin, das anfängliche Skript mit dem Tools-Seitenrekorder aufzuzeichnen und es dann so zu ändern , dass IDs, Klassen und Datenattribute verwendet werden, damit es über einen längeren Zeitraum Bestand hat. Dies ist ein Ansatz, den ich tatsächlich mit dem Firefox-Selen-Plugin verwendet habe.

"Expert Testing" (ähnlich wie "Exploratory Testing", jedoch von Endbenutzern oder Teammitgliedern mit umfangreichen Geschäftskenntnissen durchgeführt) ist einfacher durchzuführen, Ergebnisse aufzuzeichnen, zu messen und zu automatisieren.

Ich komme dazu aus einem anderen Hintergrund. Bei meinen früheren Arbeitgebern haben wir kommerzielle automatisierte Testtools entwickelt (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

Wir sahen in automatisierten UI-Tests zwei Rollen:

1. Volle Regressionstests

2. Automatisierte Einrichtung von Testumgebungen

Wir stützten uns stark auf die Tools, um nächtliche Regressionstests durchzuführen. Wir waren einfach nicht in der Lage, alle Schaltflächen und Dialogfelder zu testen, um sicherzustellen, dass zwischen der Benutzeroberfläche und der Geschäftslogik keine Fehler aufgetreten sind.

Bei wichtigeren Tests haben wir festgestellt, dass eine einzelne Person mehrere VMs hochfahren und Skripte verwenden kann, um zum eigentlichen Test zu gelangen. Sie konnten sich auf die wichtigen Punkte konzentrieren und versuchten nicht, einen Testfall mit 24 Schritten durchzuführen.

Das einzige Problem bei automatisierten Tests war die Angewohnheit, zu viele Tests ohne jegliche Überwachung auf die Box zu werfen, um doppelte oder unnötige Tests zu vermeiden. Hin und wieder mussten wir die Dinge zurückschneiden, damit die Suite in weniger als 12 Stunden fertig war.

Automatisierte Tests jeglicher Art ermöglichen Regressionstests. Indem Sie den Test ausführen, der früher funktioniert hat, stellen Sie sicher, dass er immer noch funktioniert (oder nicht), unabhängig davon, was Sie noch hinzugefügt haben. Dies gilt unabhängig davon, ob der Test ein Integrationstest (der normalerweise die Benutzeroberfläche nicht berührt) oder ein AAT (der normalerweise die Benutzeroberfläche erfordert ) ist.

Durch automatisiertes Testen der Benutzeroberfläche kann das System so getestet werden, als ob ein Benutzer auf Schaltflächen klickt. Solche Tests können daher verwendet werden, um die Navigation durch das System, die Richtigkeit von Etiketten und / oder Nachrichten, die Leistung und / oder Ladezeiten in einer bestimmten Testumgebung usw. zu überprüfen. Ähnlich wie Integration und Unit-Tests für den Programmierer. Er kann einen Test einmal einrichten (normalerweise durch Aufzeichnen seiner eigenen Mausklicks und Dateneingaben in einem Skript), und sobald der Test ordnungsgemäß funktioniert, muss er ihn erneut ausführen, um die Richtigkeit des zu testenden Systems zu überprüfen. Einige Frameworks, wie Selenium, ermöglichen die Migration von Tests zwischen Browsern, sodass verschiedene Umgebungen getestet werden können, in denen die Site ordnungsgemäß funktionieren soll.

Ohne automatisierte Tests sind Sie durch die Anzahl und Geschwindigkeit Ihrer QS-Tester begrenzt. Sie müssen buchstäblich das System zum Anfassen haben und testen, ob Ihre neue Funktion den Anforderungen entspricht und (genauso wichtig), dass Sie nichts kaputtgemacht haben, was bereits vorhanden war.

Testen bestimmt viele verschiedene Dinge. Viele dieser Tests können automatisiert werden, um die Plackerei zu beseitigen und mehr zu erledigen. Um festzustellen, ob Ihre Tests automatisiert werden können, müssen Sie zunächst prüfen, ob die von ihnen gestellte Frage für diese geeignet ist.

• Bestimmen Sie, ob eine Komponente gemäß Spezifikation funktioniert?
• Möchten Sie alle möglichen Ein- und Ausgänge testen?
• Stresstest der Komponente?
• Oder versuchen Sie zu testen, dass "es funktioniert"?

Die meisten davon können automatisiert werden, da sie mechanischer Natur sind. Die neue Funktion akzeptiert Eingaben. Was passiert also, wenn wir zufällige Daten darauf werfen? Aber manche, wie das Testen, ob das System funktioniert, erfordern, dass jemand es tatsächlich benutzt . Wenn dies nicht der Fall ist, werden Sie nie erfahren, ob die Erwartungen Ihrer Benutzer mit denen des Programms übereinstimmen. Bis das System "kaputt" geht.

Nach meiner Erfahrung deckt das automatisierte Testen von Benutzeroberflächen viele Lücken ab, darunter:

• Fehlende Dokumentation (Beispiel: Nutzung des automatisierten Testrunners zur Demonstration der vorhandenen Funktionalität)
• Veraltete Anforderungen aufgrund von Scope Creep (Beispiel: Ermitteln der Lücke zwischen Anforderungen und Code durch Erfassen des Bildschirms während Testläufen)
• Hoher Umsatz von Entwicklern und Testern (Beispiel: Reverse Engineering Legacy JavaScript durch Erfassung des Bildschirms während der Testläufe bei geöffnetem Entwicklertool)
• Feststellen von Verstößen gegen Standardnamenskonventionen mithilfe von XPath-Regressionstests (Beispiel: Durchsuchen aller DOM-Attributknoten nach Namen in Kamelgehäusen)
• Erkennen von Sicherheitslücken, die nur ein Computer entdecken kann (Beispiel: Abmelden von einer Registerkarte bei gleichzeitiger Übermittlung eines Formulars in der anderen)

Ich möchte die Erfahrung unseres Teams teilen. Wir haben unser eigenes UI-Testtool, Screenster, verwendet, um unsere und die Web-Apps unserer Kunden zu testen. Es hat sich als hilfreiche Alternative zu Selen für visuelle / CSS-Testaufgaben erwiesen. Screenster ist ein Testautomatisierungstool, das auf Screenshots basierende Vergleiche verschiedener Versionen Ihrer Webseiten durchführt. Zunächst wird eine visuelle Grundlinie für eine Seite erstellt, wobei für jede Benutzeraktion ein Screenshot erstellt wird. Während des nächsten Durchlaufs wird bei jedem Schritt ein neuer Screenshot erstellt, der mit dem Screenshot aus der Baseline verglichen und Unterschiede hervorgehoben.

Zusammenfassend hat Screenster die folgenden Vorteile: Visuelle Basis: Screenshots werden für jeden Benutzerschritt während der Testaufzeichnung aufgenommen. Screenshotbasierter Vergleich: Screenster vergleicht die während der Wiedergabe aufgenommenen Bilder mit denen aus der Basis und hebt alle Unterschiede hervor. Smart CSS-Selektoren: Tester können auswählen CSS-Elemente auf den Screenshots und führen mit ihnen Aktionen aus - markieren Sie sie z. B. als ignorierte Bereiche, um sie vom weiteren Vergleich auszuschließen