it-swarm.dev

Was sind die Nachteile von automatisierten Tests?

Auf dieser Website gibt es eine Reihe von Fragen, die zahlreiche Informationen zu den Vorteilen enthalten, die sich aus automatisierten Tests ergeben. Aber ich habe nichts gesehen, was die andere Seite der Medaille darstellt: Was sind die Nachteile? Alles im Leben ist ein Kompromiss und es gibt keine Silberkugeln. Es muss also einige triftige Gründe geben, keine automatisierten Tests durchzuführen. Was sind Sie?

Hier sind einige, die ich mir ausgedacht habe:

  • Erfordert mehr anfängliche Entwicklerzeit für eine bestimmte Funktion
  • Erfordert eine höhere Fähigkeitsstufe der Teammitglieder
  • Erhöhen Sie den Werkzeugbedarf (Testläufer, Gerüste usw.)
  • Komplexe Analyse erforderlich, wenn ein fehlgeschlagener Test aufgetreten ist - ist dieser Test aufgrund meiner Änderung veraltet oder sagt er mir, dass ich einen Fehler gemacht habe?

Bearbeiten
Ich sollte sagen, dass ich ein großer Befürworter automatisierter Tests bin und nicht davon überzeugt sein möchte. Ich möchte verstehen, was die Nachteile sind. Wenn ich zu meiner Firma gehe, um mich dafür einzusetzen, sehe ich nicht so aus, als würde ich die nächste imaginäre Silberkugel herumwerfen.

Außerdem bin ich explizit nicht auf der Suche nach jemandem, der meine obigen Beispiele bestreitet. Ich gehe davon aus, dass es einige Nachteile geben muss (alles hat Kompromisse), und ich möchte verstehen, was das ist.

49
RationalGeek

Sie haben die wichtigsten ziemlich genau getroffen. Ich habe ein paar kleinere Ergänzungen und den Nachteil, dass Tests tatsächlich erfolgreich sind - wenn Sie dies nicht wirklich wollen (siehe unten).

  • Entwicklungszeit: Bei der testgetriebenen Entwicklung wird dies bereits für Komponententests berechnet, Sie benötigen jedoch noch Integrations- und Systemtests, für die möglicherweise auch Automatisierungscode erforderlich ist. Einmal geschriebener Code wird normalerweise in mehreren späteren Phasen getestet.

  • Schwierigkeitsgrad: Natürlich müssen die Tools unterstützt werden. Aber es ist nicht nur Ihr eigenes Team. In größeren Projekten haben Sie möglicherweise ein separates Testteam, das Tests zur Überprüfung der Schnittstellen zwischen dem Produkt Ihres Teams und denen anderer schreibt. So viel mehr Menschen müssen mehr Wissen haben.

  • Werkzeugbedarf: Sie sind genau richtig. Dazu gibt es nicht viel hinzuzufügen.

  • Fehlgeschlagene Tests: Dies ist der wahre Mistkerl (für mich jedenfalls). Es gibt verschiedene Gründe, von denen jeder als Nachteil angesehen werden kann. Der größte Nachteil ist die Zeit, die erforderlich ist, um zu entscheiden, welcher dieser Gründe tatsächlich für Ihren fehlgeschlagenen Test gilt.

    • fehlgeschlagen, wegen eines tatsächlichen Fehlers. (nur der Vollständigkeit halber, da dies natürlich vorteilhaft ist)
    • fehlgeschlagen, weil Ihr Testcode mit einem herkömmlichen Fehler geschrieben wurde.
    • fehlgeschlagen, weil Ihr Testcode für eine ältere Version Ihres Produkts geschrieben wurde und nicht mehr kompatibel ist
    • fehlgeschlagen, da sich die Anforderungen geändert haben und das getestete Verhalten nun als "korrekt" eingestuft wird.
  • Nicht fehlgeschlagene Tests: Dies sind ebenfalls ein Nachteil und können sehr schlecht sein. Es passiert meistens, wenn man Dinge ändert und dem nahe kommt, was Adam geantwortet hat. Wenn Sie den Code Ihres Produkts ändern, der Test dies jedoch überhaupt nicht berücksichtigt, erhalten Sie dieses "falsche Sicherheitsgefühl".

    Ein wichtiger Aspekt nicht fehlgeschlagener Tests ist, dass eine Änderung der Anforderungen dazu führen kann, dass früheres Verhalten ungültig wird. Wenn Sie über eine gute Rückverfolgbarkeit verfügen, sollte die Anforderungsänderung mit Ihrem Testcode abgeglichen werden können und Sie wissen, dass Sie diesem Test nicht mehr vertrauen können. Die Aufrechterhaltung dieser Rückverfolgbarkeit ist natürlich ein weiterer Nachteil. Und wenn Sie dies nicht tun, erhalten Sie einen Test, der nicht fehlschlägt, sondern tatsächlich überprüft, ob Ihr Produkt funktioniert falsch. Irgendwo auf der Straße wird dich das treffen ... normalerweise, wenn/wo du es am wenigsten erwartest.

  • Zusätzliche Bereitstellungskosten: Sie führen Unit-Tests nicht nur als Entwickler auf Ihrem eigenen Computer durch. Mit automatisierten Tests möchten Sie sie auf Commits von anderen an einem zentralen Ort ausführen, um herauszufinden, wann jemand Ihre Arbeit gebrochen hat. Dies ist schön, muss aber auch eingerichtet und gewartet werden.

26
Frank

Nachdem ich gerade angefangen habe, automatisierte Tests in unserem Team auszuprobieren, ist der größte Nachteil, den ich gesehen habe, dass es sehr schwierig ist, auf Legacy-Code anzuwenden, der nicht für automatisierte Tests entwickelt wurde. Es würde zweifellos unseren Code langfristig verbessern, aber der Grad an Refactoring, der für automatisierte Tests unter Beibehaltung unserer geistigen Gesundheit erforderlich ist, ist kurzfristig eine sehr hohe Eintrittsbarriere, was bedeutet, dass wir bei der Einführung von automatisierten Methoden sehr selektiv vorgehen müssen Unit-Tests, um unsere kurzfristigen Verpflichtungen zu erfüllen. Mit anderen Worten, es ist viel schwieriger, die Kreditkarten abzuzahlen, wenn Sie bereits tief in technischen Schulden stecken.

29
Karl Bielefeldt

Der vielleicht wichtigste Nachteil ist ... Tests sind Produktionscode. Jeder Test, den Sie schreiben, fügt Ihrer Codebasis Code hinzu, der gewartet und unterstützt werden muss. Wenn Sie dies nicht tun, führt dies zu Tests, deren Ergebnisse Sie nicht glauben. Sie haben also keine andere Wahl. Versteh mich nicht falsch - ich bin ein großer Verfechter des automatisierten Testens. Aber alles hat Kosten, und das ist groß.

21
Ross Patterson

Ich würde nicht sagen, dass dies durchaus zutreffende Nachteile sind, aber die wenigen, die ich am meisten getroffen habe, sind:

  • Zeitaufwand für die Einrichtung des Tests in einer komplexen Unternehmensanwendung.
  • Der Umgang mit alten Tests, die falsch fehlschlagen, mit anderen Worten, das System hat sich weiterentwickelt und jetzt sind die Tests falsch.
  • Falsches Vertrauen aufgrund uneinheitlicher oder unbekannter Testabdeckung.

Eine uneinheitliche Testabdeckung kann zu einem falschen Sicherheitsgefühl führen. Wenn Sie einen Refactor durchführen und die Tests verwenden, um seine Gültigkeit zu beweisen, was hat bewiesen, dass Ihre Tests dies beweisen können?

Die Zeit, die zum Erstellen des Tests benötigt wird, ist manchmal ein Problem für uns. Unsere automatisierten Tests umfassen nicht nur Komponententests, sondern auch Anwendungsfalltests. Diese sind tendenziell breiter und erfordern Kontext.

Natürlich ist meine Perspektive eine Anwendung, die älter ist als die Unit-Tests.

15

Ich würde sagen, das Hauptproblem bei ihnen ist, dass sie ein falsches Sicherheitsgefühl vermitteln können. Nur weil Sie Unit-Tests haben, heißt das nicht, dass sie tatsächlich irgendetwas tun und dazu gehört auch das ordnungsgemäße Testen der Anforderungen.

Darüber hinaus können automatisierte Tests auch Fehler selbst enthalten , so dass sich die Frage stellt ob Unit-Tests selbst getestet werden müssen also nicht unbedingt etwas erreichen.

9
billy.bob

Automatisierungstests haben zwar viele Vorteile, aber auch ihre eigenen Nachteile. Einige der Nachteile sind:

  • Zum Schreiben der Automatisierungstestskripte sind Kenntnisse erforderlich.
  • Das Debuggen des Testskripts ist ein Hauptproblem. Wenn im Testskript ein Fehler vorhanden ist, kann dies manchmal zu tödlichen Konsequenzen führen.
  • Die Testwartung ist bei Wiedergabemethoden kostspielig. Obwohl eine geringfügige Änderung in der GUI auftritt, muss das Testskript neu aufgezeichnet oder durch ein neues Testskript ersetzt werden.
  • Die Pflege von Testdatendateien ist schwierig, wenn das Testskript mehr Bildschirme testet.

Einige der oben genannten Nachteile ziehen häufig den Nutzen der automatisierten Skripte ab. Obwohl die Automatisierungstests Vor- und Nachteile haben, werden sie auf der ganzen Welt angepasst.

4
jameswood037

Ich habe kürzlich eine Frage zu Tests in der Spieleentwicklung gestellt - das ist übrigens, woher ich davon wusste. Die Antworten dort wiesen auf einige merkwürdige, spezifische Nachteile hin:

  1. Es ist teuer, wenn Ihr Code stark gekoppelt sein sollte .
  2. Es ist schwierig, wenn Sie sich der verschiedenen Hardwareplattformen bewusst sein müssen, wenn Sie die Ausgabe an den Benutzer analysieren sollten und das Codeergebnis nur in einem breiteren Kontext sinnvoll ist .
  3. UI- und UX-Tests sind sehr schwierig .
  4. Und insbesondere können automatisierte Tests teurer und weniger effektiv sein als eine Reihe sehr kostengünstiger (oder kostenloser) Betatester .

Der vierte Punkt erinnert mich an meine Erfahrungen. Ich habe in einem sehr schlanken, XP-orientierten, von Scrum verwalteten Unternehmen gearbeitet, in dem Unit-Tests dringend empfohlen wurden. Auf dem Weg zu einem schlankeren, weniger bürokratischen Stil hat das Unternehmen jedoch den Aufbau eines QS-Teams vernachlässigt - wir hatten keine Tester. So häufig fanden die Kunden bei einigen Systemen geringfügige Fehler, selbst bei einer Testabdeckung von> 95%. Also würde ich noch einen Punkt hinzufügen:

  • Automatisierte Tests können dazu führen, dass Sie das Gefühl haben, dass Qualitätssicherung und Tests nicht wichtig sind.

Außerdem habe ich damals über Dokumentation nachgedacht und eine Hypothese in Betracht gezogen, die (in geringerem Umfang) für Test zwei gültig sein könnte. Ich hatte nur das Gefühl, dass sich Code so schnell entwickelt, dass es ziemlich schwierig ist, eine Dokumentation zu erstellen, die einer solchen Geschwindigkeit folgt. Daher ist es wertvoller, Zeit damit zu verbringen, Code lesbar zu machen, als schwere, leicht veraltete Dokumentation zu schreiben. (Natürlich gilt dies nicht für APIs, sondern nur für die interne Implementierung.) Der Test leidet ein bisschen unter dem gleichen Problem: Möglicherweise auch Im Vergleich zum getesteten Code langsam zu schreiben. OTOH, es ist ein geringeres Problem, da die Tests warnen, dass sie veraltet sind, während Ihre Dokumentation stumm bleibt, solange Sie sie nicht erneut lesen , sehr, sehr sorgfältig .

Schließlich ein Problem, das ich manchmal finde: Automatisierte Tests können von Werkzeugen abhängen, und diese Werkzeuge sind möglicherweise schlecht geschrieben. Ich habe vor einiger Zeit ein Projekt mit XUL gestartet und es ist nur schmerzhaft, Unit-Tests für eine solche Plattform zu schreiben. Ich habe eine andere Anwendung mit Objective-C, Cocoa und Xcode 3 gestartet, und das Testmodell war im Grunde eine Reihe von Problemumgehungen.

Ich habe andere Erfahrungen mit den Nachteilen automatisierter Tests gemacht, aber die meisten davon sind in anderen Antworten aufgeführt. Trotzdem bin ich ein vehementer Verfechter automatisierter Tests. Dies ersparte eine Menge Arbeit und Kopfschmerzen und ich empfehle es immer standardmäßig. Ich bin der Meinung, dass diese Nachteile im Vergleich zu den Vorteilen automatisierter Tests nur Details sind. (Es ist wichtig, immer Ihren Glauben zu verkünden, nachdem Sie Häresien kommentiert haben, um das Auto da Fé zu vermeiden.)

3
brandizzi

Zwei, die nicht erwähnt werden, sind:

  • Länge der Uhrzeit, die zum Ausführen einer großen Testsuite erforderlich sein kann

Ich war Teil der automatisierten QS-Bemühungen, bei denen die Durchführung der Tests einen halben Tag dauerte, da die Tests langsam waren. Wenn Sie beim Schreiben Ihrer Tests nicht vorsichtig sind, könnte sich Ihre Testsuite auch so entwickeln. Das klingt nicht nach einer großen Sache, bis Sie diese Zeit jetzt verwalten: "Oh, ich habe gerade eine Korrektur vorgenommen, aber es wird 4 Stunden dauern, um die Richtigkeit zu beweisen.".

  • Gebrechlichkeit einiger Testschreibmethoden

Einige Testmethoden (z. B. die Automatisierung der Benutzeroberfläche) scheinen jedes Mal zu brechen, wenn Sie sich umdrehen. Besonders schmerzhaft, wenn Ihr Skript beispielsweise den Testprozess aufhält, weil es darauf wartet, dass eine Schaltfläche angezeigt wird - die Schaltfläche wurde jedoch umbenannt.

Beides können Sie mit einer guten Testpraxis umgehen: Finden Sie Wege, um Ihre Testsuite schnell zu halten (auch wenn Sie Tricks wie das Verteilen von Testläufen auf Maschinen/CPUs ausführen müssen). Ebenso kann mit einiger Sorgfalt versucht werden, gebrechliche Methoden zum Schreiben von Tests zu vermeiden.

3
RyanWilcox

Ich möchte noch eines hinzufügen, ein falsches Sicherheitsgefühl.

Über sehr kleine, genau definierte Problemstellungen hinaus ist es nicht möglich, umfassende Tests zu erstellen. Es kann und wird häufig immer noch Fehler in unserer Software geben, auf die die automatisierten Tests einfach nicht testen. Wenn die automatisierten Tests bestanden sind, gehen wir allzu oft davon aus, dass der Code keine Fehler enthält.

2
Jim C

Es ist schwer, den Management-/Risikokapitalgeber zu überzeugen

  • testautomation erhöht die Vorabkosten.
  • testautomation verlängert die Markteinführungszeit.
  • der Vorteil der Testautomatisierung liegt in der Mitte und im Logterm. Der harte Wettbewerb konzentriert sich mehr auf kurzfristige Vorteile.

siehe Market Driven Unit Testing für Details.

0
k3b