Korrekte Struktur der funktionalen/Akzeptanztests

Question

Ich arbeite zZ an dem Aufbau einer automatisierten Funktions-/Abnahmetestsuite für ein Projekt, aber ich habe nicht viel Erfahrung, diese Typen der Tests zu schreiben, also wollte ich einiges erhalten Eingabe über die richtige Strukturierung. Insbesondere arbeite ich mit Arquillians Graphene-Erweiterung.

Zum Beispiel sagen, ich habe 3 Tests, A, B und C.

TestA: Tests auf ein Konto bei der Anwendung anzumelden. Wenn der Test erfolgreich ist, sollte sich der Browser also auf der Home/Info-Seite des Accounts befinden.

TestB: Testet das Ändern eines Kontopassworts. Dies würde erfordern, dass man sich beim Account anmeldet und dann die Passwortänderungsfunktionalität testet.

TestC: Tests zum Ändern der E-Mail-Adresse eines Kontos. Dies würde wiederum erfordern, dass Sie sich beim Konto anmelden und dann die E-Mail-Änderungsfunktionalität testen.

Wenn TestA aufgrund eines Problems mit dem Login-Code fehlschlägt, sollten TestB und TestC natürlich ebenfalls fehlschlagen, da sie bei einem Account angemeldet sein müssen.

Frage: Sollten automatisierte Funktions-/Akzeptanztests jeweils einen Prozess duplizieren, der zur Vervollständigung des Tests erforderlich ist? In diesem Fall müssen sich TestB und TestC beim Konto anmelden, bevor Sie etwas anderes tun. Jede Prüfung sollte rufen ausdrücklich etwas wie:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assertTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

Oder sollte ich in gewisser Weise ein Konto in der Sitzung des spöttischen, die durch Tests B und C verwendet werden können, so dass sie nicht ausfallen, auch wenn TestA (die tatsächliche Login-Test) tut?

Da es sich um Benutzerakzeptanztests handelt, dachte ich, dass sie genau das tun sollten, was der Benutzer tun würde, und sich bei Bedarf einloggen, aber ich bin nicht sicher, ob dies unnötige Duplizierung ist, die anders gehandhabt werden sollte. behandelt wie Funktionseinheiten, ähnlich einem Standard-Unit-Test) und ich wollte Feedback von jemandem mit mehr Erfahrung in diesem Bereich bekommen.

Vielen Dank im Voraus. Hoffentlich ist meine Frage nicht zu verworren. :)

Answer 1

Ich persönlich habe es getan, so dass jeder Testfall die Aktion des Benutzers so viel wie möglich repliziert, aber Orte ausschneiden, wo es sein muss. Zum Beispiel TestA: Logins in, geht auf die richtige Webseite geht, um es Admin-System ist, findet einen Benutzer und löscht einen Teil der Benutzer Informationen (wie zB Name), TestB: Logins in, geht auf die richtige Webseite, geht an Es ist Admin-System, findet einen Benutzer und versucht, die Benutzer vollständig über eine Schaltfläche zu löschen.

TestA und TestB auf der gleichen Seite am Ende - die Benutzer Detailseite. So in Test A, kann ich alles richtig machen, genau wie ein Benutzer es tut, aber in Test B, gehe ich direkt auf die Detailseite für den Benutzer, im Gegensatz manuell über die korrekte Navigation zu gehen. Warum?

Spart Zeit, warum sollte ich die Navigation in Test B wiederholen, wenn Test A das ohnehin schon testet?

Denken Sie daran, dass Tests nicht voneinander abhängig sein sollten - wenn alle drei Tests fehlschlagen, weil Sie sich nicht anmelden können - das ist der springende Punkt, Sie können sich nicht anmelden, so dass Sie keine der anderen Aktionen ausführen können.

Betrachten Sie es als Benutzer tun würde.Jeder Test hat seine eigenen Funktionen, die er testen kann, aber wenn Sie sich nicht anmelden können, kann ein Benutzer nichts davon sehen oder irgendetwas mit der Funktionalität machen. Wenn ich mich nicht anmelden kann, kann ich mein Passwort oder meine E-Mail-Adresse nicht ändern. Logischerweise sollten die Tests auf die gleiche Weise fehlschlagen.

Answer 2

Dies ist wirklich eine pro-Projekt-Frage, da beide gültige Ansätze sind, aber in verschiedenen Situationen sollte man mehr bevorzugt werden. In einem großen System bevorzuge ich den Testfall von Anfang bis Ende, unabhängig davon, wie oft dies wiederholt wird (z. B. ich logge mich für jeden Test ein). Ich glaube, das hat Arran schon gesagt (+1!). Der Grund, warum ich dies normalerweise tue, ist, dass manchmal ein Zustand, der von einem vorherigen Bildschirm übernommen wurde, später einen Fehler verursachen kann, und das ist die Art von Dingen, für die automatisierte Tests großartig sind. Mit diesen jedoch stelle ich sicher, dass die Testdaten alle für die Vorlaufschritte gültig sind und eine möglichst schnelle Lösung anstreben. Zum Beispiel sollte Login immer korrekte Benutzer und Passwort haben, dann bei der Überprüfung der Anmeldung wurde entweder angenommen, dass es sollte und eine Ausnahme später behandeln oder suchen Sie nach einem leicht identifizierbaren Element auf der Seite statt einer komplizierten 'wichtiger'.

Mit diesem gesagt, können Sie auch Tests schreiben, die mehrere Anforderungen in einer Art von Funktionsablauf testen. Wenn der Fluss unterbrochen wird, sollten Tests geschrieben werden, um den Bereich zu identifizieren, in dem die Gesamtaufgabe fehlschlägt. Ich würde dies nur für kleine Projekte empfehlen, oder wenn das Testen aufgrund mangelnder Ressourcen keine Priorität hat. Wenn Sie zum Beispiel einen Test ausführen, der sich anmeldet, ein Element auswählt, es in einen Einkaufswagen legt, zum Auschecken geht, werden alle diese Funktionen getestet, und ein Team kann den übergreifenden "Prozess" statt nur mehrerer, möglicherweise nicht verbundener Prozesse, reparieren , Fehler. Ich denke jedoch, dass der erste Ansatz gründlicher ist, aber auch mehr Zeit in Anspruch nimmt (aber es lohnt sich oft :)).

In der Angst, dass meine Antwort zu lang und blockig werden wird, werde ich hier nicht weiter darauf eingehen, aber es gibt eine Menge darüber zu reden und ich würde vorschlagen, sich hinzusetzen und was du herausziehst versuchen in der Anwendung jetzt und in der Zukunft zu testen. Dies wird wahrscheinlich sehr aufschlussreich sein und eine gute Teststruktur und automatisierte Schreibpraktiken fördern. Hoffe, das hilft und es war nicht zu lange :)

Answer 3

In einer Benutzerakzeptanz Test möchten Sie nicht zu verspotten, aber so nah wie möglich an die Art und Weise, wie ein Endbenutzer das System verwenden würde.

jedoch das Unit-Test-Mantra one assert per test kann die Abnahmeprüfung erweitert werden: In TestA Ihre Prüfungslogik über Geltendmachung richtige Login ist: In TestB Sie nicht brauchen diese Prüfung zu wiederholen, nur dass die Passwortänderung behauptet behandelt wurde korrekt .

In JUnit kann man assumeTrue statt assertTrue zu diesem Zweck verwenden. So würde Ihr TestB:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assumeTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

Jetzt, wenn assumeTrue fehlschlägt, wird der Test einfach ignoriert. Ihr TestA wird jedoch weiterhin fehlschlagen und Ihnen und Ihrem Endbenutzer sagen, was das eigentliche Problem ist.