Was sind die Nachteile des automatisierten Testens?

49

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

Hier sind einige, die ich mir ausgedacht habe:

  • Benötigt mehr anfängliche Entwicklerzeit für ein bestimmtes Feature
  • Erfordert eine höhere Fähigkeitsstufe der Teammitglieder
  • Erhöhung des Werkzeugbedarfs (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 des automatisierten Testens bin und nicht überzeugt sein möchte, dies zu tun. Ich versuche zu verstehen, was die Nachteile sind, also sehe ich nicht so aus, als würde ich die nächste imaginäre Silberkugel umwerfen.

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 sind.

RationalGeek
quelle
18
"Komplexe Analyse erforderlich ..." Der Test ist nicht die Ursache des Fehlers, sondern ein Indikator. Zu sagen, dass es keine Tests gibt, bedeutet, dass keine komplexe Fehleranalyse erforderlich ist, als den Kopf in den Schlamm zu stecken.
P. Brian Mackey
1
* Längere Build-Zeiten, wenn Tests bei jedem Build ausgeführt werden, und wiederholter Code, wenn die Tests auf einem sehr niedrigen Level sind (Testen von Gettern und Setzern)
Ratschenfreak
2
1. Wenn ein Entwickler Zeit verwendet, um neue Funktionen zu testen, ist das Risiko eines Ausfalls geringer, was bedeutet, dass Ihr Produkt stabiler ist. 2. Es ist eine gute Sache, Ihre Teammitglieder für einen Testfokus-Ansatz zu schulen. Sie können dieses Wissen für andere Dinge in der Arbeit (und im Leben) nutzen. 3. Erstellen Sie eine automatisierte Installation für die Testumgebung. 4. Dies sagt mir, dass 1 Test zu viel bewirkt.
CS01
1
Wenn derselbe Entwickler die Tests wie den eigentlichen Code codiert, werden sie nur an dieselben Testfälle denken, für die sie Tests schreiben, an die sie bei der Codierung gedacht haben.
Paul Tomblin
Ich habe gerade eine Antwort auf die entsprechende Frage gepostet und möchte diese zumindest kommentieren. IMO, fast alle hier (und in den Antworten) erwähnten Nachteile sehen falsch und irreführend aus, wenn wir über das echte Live-Projekt sprechen und nicht über etwas, das Sie schnell programmieren und vergessen. Ich fürchte, diese Frage kann als Ausrede dienen, um sich ohne automatische Tests weiterzuentwickeln, und in vielen Fällen führt dies zum Tod des Projekts oder zu einer vollständigen Neuverdrahtung.
Boris Serebrov

Antworten:

26

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

  • Entwicklungszeit: Bei testgetriebener Entwicklung ist 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.

  • Geschicklichkeitsstufe: Natürlich müssen die Werkzeuge unterstützt werden. Aber es ist nicht nur dein eigenes Team. In größeren Projekten verfügen Sie möglicherweise über ein separates Testteam, das Tests zur Überprüfung der Schnittstellen zwischen dem Produkt Ihres Teams und dem des anderen Teams erstellt. So viel mehr Menschen müssen mehr Wissen haben.

  • Werkzeugbedarf: Da sind Sie genau richtig. Dem ist nicht viel hinzuzufügen.

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

    • fehlgeschlagen, wegen eines tatsächlichen Fehlers. (Nur der Vollständigkeit halber, da dies natürlich von Vorteil ist)
    • ist fehlgeschlagen, da Ihr Testcode mit einem herkömmlichen Fehler geschrieben wurde.
    • fehlgeschlagen, da 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: Diese sind ebenfalls ein Nachteil und können ziemlich schlecht sein. Es passiert meistens, wenn man Dinge ändert und sich dem annähert, was Adam geantwortet hat. Wenn Sie etwas am Code Ihres Produkts ändern, der Test dies jedoch überhaupt nicht berücksichtigt, erhalten Sie dieses "falsche Sicherheitsgefühl".

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

  • Zusätzliche Bereitstellungskosten: Sie führen nicht nur Unit-Tests als Entwickler auf Ihrem eigenen Computer durch. Bei automatisierten Tests möchten Sie sie an einer zentralen Stelle auf Veranlassung anderer ausführen, um herauszufinden, wann jemand Ihre Arbeit unterbrochen hat. Das ist schön, muss aber auch eingerichtet und gewartet werden.

Frank
quelle
1
Wenn sich bei fehlgeschlagenen Tests die Anforderungen ändern und die aktuellen Tests fehlschlagen, wird der Test bestanden, da die vorherige Implementierung nicht mehr gültig ist. Wenn der Test nicht fehlgeschlagen ist, entspricht die Implementierung nicht den Anforderungen.
CS01
In Fall 4 (b) dreht sich alles um testgetriebene Entwicklung: Sie schreiben einen fehlgeschlagenen Test, erweitern das Produkt und stellen sicher, dass der Test durch diese Änderung erfolgreich ist. Dies schützt Sie vor fehlerhaften schriftlichen Tests, die immer erfolgreich sind oder immer fehlschlagen.
Kilian Foth
@Frank danke für die Antwort. Da gibt es viel Einsicht. Ich schätze besonders die Unterscheidung der verschiedenen Ursachen für nicht bestandene Tests. Zusätzliche Bereitstellungskosten sind ein weiterer hervorragender Punkt.
RationalGeek
Das amüsante, was ich gefunden habe, ist, dass mein Fehler-pro-LOC-Verhältnis für Tests weitaus schlechter ist als der von echtem Code. Ich verbringe mehr Zeit damit, Testfehler zu finden und zu beheben als echte. :-)
Brian Knoblauch
fehlgeschlagen, da Ihr Testcode für eine ältere Version Ihres Produkts geschrieben wurde und nicht mehr kompatibel ist. Wenn Ihre Tests aus diesem Grund fehlschlagen, testen Ihre Tests wahrscheinlich eher Details zur Implantation als das Verhalten. CalculateHighestNumber v1 sollte immer noch das gleiche Ergebnis wie CalculateHighestNumber v2
Tom Squires
29

Nachdem wir gerade angefangen haben, automatisierte Tests in unserem Team zu testen, ist der größte Nachteil, den ich gesehen habe, dass es sehr schwierig ist, Legacy-Code anzuwenden, der nicht für automatisierte Tests entwickelt wurde. Dies würde unseren Code auf lange Sicht zweifellos verbessern, aber das Ausmaß der Umgestaltung, das für automatisierte Tests erforderlich ist, bei gleichzeitiger Wahrung unserer Vernunft, stellt kurzfristig eine sehr hohe Markteintrittsbarriere dar, was bedeutet, dass wir bei der Einführung von Automatisierung sehr selektiv vorgehen müssen Unit Testing, um unsere kurzfristigen Verpflichtungen zu erfüllen. Mit anderen Worten, es ist viel schwieriger, die Kreditkarten zurückzuzahlen, wenn Sie bereits eine hohe technische Verschuldung haben.

Karl Bielefeldt
quelle
2
Als jemand, der 80% einer sehr großen alten Codebasis bearbeitet, konnte ich nicht mehr zustimmen. Um dies zu mildern, habe ich einige davon in [link] amazon.com/Working-Effective-Legacy-Michael-Feathers/dp/… verwendet, die einen Blick wert sind.
DevSolo
1
Das ist ein wirklich gutes Buch, ich habe viel davon. Drei Hauptpunkte, versuchen Sie es, ein bisschen nach dem anderen. Einige gute Tests sind besser als keine Tests. Behalten Sie den Überblick und refaktorieren Sie nicht alles, was refaktorisiert werden muss, auf einmal. Stellen Sie klar, wo die Grenzen zwischen testbarem und nicht testbarem Code liegen. Stellen Sie sicher, dass auch alle anderen Bescheid wissen.
Tony Hopkinson
21

Der vielleicht wichtigste Nachteil ist ... Tests sind Seriencode . 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. Verstehen Sie mich nicht falsch - ich bin ein großer Verfechter des automatisierten Testens. Aber alles hat Kosten, und das ist eine große.

Ross Patterson
quelle
Guter Punkt, Ross, das ist eine interessante Art, es auszudrücken.
RationalGeek
Einverstanden, obwohl nach meiner Erfahrung die Zeitersparnis aufgrund von Komponententests, bei denen potenzielle Fehler im neu geschriebenen Code sofort gefunden wurden (dh Regressionstests), diese zusätzliche Wartungszeit aufgewogen hat.
dodgy_coder
15

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

  • Zeitaufwand für die Einrichtung des Tests in einer komplexen Unternehmensanwendung.
  • Das System hat sich weiterentwickelt und jetzt sind die Tests falsch.
  • Falsches Vertrauen durch lückenhafte oder unbekannte Testabdeckung.

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

Die für die Erstellung des Tests erforderliche Zeit ist für uns manchmal ein Problem. Unsere automatisierten Tests umfassen nicht nur Unit-Tests, sondern auch Use-Case-Tests. Diese sind in der Regel weiter gefasst und erfordern einen Kontext.

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

Adam Houldsworth
quelle
Das OP deckte bereits Zeit und veralteten Code in der Frage ab.
P. Brian Mackey
@ P.Brian.Mackey eigentlich ist das Zeitelement subjektiv. Die Zeit, die zum Codieren des Tests benötigt wird, unterscheidet sich von der Zeit, die benötigt wird, um die Anforderungen des Tests zu verstehen und den Test korrekt zu codieren.
Adam Houldsworth
@AdamHouldsworth Danke, das sind einige gute Beispiele für Nachteile. Ich hatte den falschen Konfidenzwinkel nicht wirklich berücksichtigt.
RationalGeek
9

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 noch lange nicht, dass sie tatsächlich etwas tun, und dazu gehört auch, die Anforderungen richtig zu testen.

Darüber hinaus können automatisierte Tests auch selbst Fehler enthalten , sodass sich die Frage stellt, ob Komponententests selbst getestet werden müssen, um nicht unbedingt etwas zu erreichen.

Billy Bob
quelle
Test Driven Development hilft beim ersten, indem es einen fehlgeschlagenen Test erfordert, bevor der Feature-Code geschrieben wird. Jetzt wissen Sie, dass der Test unterbrochen wird, wenn das Feature unterbrochen wird. Für den zweiten, komplizierten Testcode handelt es sich um einen Codegeruch. Wenn Sie den Test zuerst schreiben, können Sie versuchen, ihn zu vereinfachen und die schwierige Arbeit in den Feature-Code zu schreiben, der den Test behebt.
David Harkness
Code, der schwer zu testen ist, ist kein Codegeruch. Der am einfachsten zu testende Code ist eine riesige Kette von Funktionsaufrufen, die sich als Klassen tarnen.
Erik Reppen
4

Obwohl Automatisierungstests viele Vorteile haben, hat sie auch ihre eigenen Nachteile. Einige der Nachteile sind:

  • Kenntnisse sind erforderlich, um die Automatisierungstestskripte zu schreiben.
  • Das Debuggen des Testskripts ist ein großes Problem. Wenn das Testskript einen Fehler enthält, kann dies manchmal zu tödlichen Konsequenzen führen.
  • Die Testwartung ist bei Wiedergabemethoden kostspielig. Obwohl in der Benutzeroberfläche eine geringfügige Änderung vorgenommen wurde, muss das Testskript neu aufgezeichnet oder durch ein neues Testskript ersetzt werden.
  • Die Wartung von Testdatendateien ist schwierig, wenn das Testskript mehr Bildschirme testet.

Einige der oben genannten Nachteile ziehen sich oft von den Vorteilen der automatisierten Skripte ab. Obwohl der Automatisierungstest Profis und Hühneraugen hat, ist er auf der ganzen Welt weit verbreitet.

jameswood037
quelle
Vielen Dank. Gute Argumente. Ich habe Ihren Beitrag für Grammatik und Formatierung bearbeitet. Ich hoffe es macht dir nichts aus.
RationalGeek
3

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

  1. Es ist teuer zu tun , wenn Ihr Code sollte stark gekoppelt werden .
  2. Dies ist schwierig, wenn Sie die verschiedenen Hardwareplattformen kennen müssen, wenn Sie die Ausgabe für den Benutzer analysieren sollen und das Code-Ergebnis nur in einem breiteren Kontext Sinn macht .
  3. UI- und UX-Tests sind sehr schwierig .
  4. Insbesondere können automatisierte Tests teurer und weniger effektiv sein als eine Reihe von sehr kostengünstigen (oder kostenlosen) Betatestern .

Der vierte Punkt erinnert mich an einige meiner 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 vernachlässigte das Unternehmen jedoch den Aufbau eines QA-Teams - wir hatten keine Tester. So häufig fanden die Kunden bei einigen Systemen sogar bei einer Testabdeckung von> 95% triviale Fehler. Also würde ich einen weiteren Punkt hinzufügen:

  • Bei automatisierten Tests haben Sie möglicherweise das Gefühl, dass Qualitätssicherung und Tests nicht wichtig sind.

Außerdem dachte ich damals über Dokumentation nach und stellte eine Hypothese auf, die (in geringerem Umfang) für die Prüfung von 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. (Dies gilt natürlich nicht für APIs, sondern nur für die interne Implementierung.) Der Test weist das gleiche Problem auf: Im Vergleich zum getesteten Code ist das Schreiben möglicherweise zu langsam. OTOH, es ist ein geringeres Problem, da die Tests darauf hinweisen, dass sie veraltet sind, während Ihre Dokumentation stumm bleibt, solange Sie sie nicht sehr, sehr sorgfältig durchlesen .

Schließlich stelle ich manchmal ein Problem fest: Automatisierte Tests hängen möglicherweise von Tools ab, und diese Tools sind möglicherweise schlecht geschrieben. Ich habe vor einiger Zeit ein Projekt mit XUL gestartet, und es tut mir weh, 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 darauf bestand im Grunde aus einer Reihe von Problemumgehungen.

Ich habe andere Erfahrungen mit Nachteilen des automatisierten Testens gemacht, aber die meisten davon sind in anderen Antworten aufgeführt. Trotzdem bin ich ein vehementer Befürworter des automatisierten Testens. Dies ersparte eine Menge Arbeit und Kopfschmerzen und ich empfehle es immer standardmäßig. Ich schätze, diese Nachteile sind nur Details im Vergleich zu den Vorteilen des automatisierten Testens. (Es ist wichtig, immer deinen Glauben zu verkünden, nachdem du Häresien kommentiert hast, um das Auto-Da-Fé zu vermeiden.)

brandizzi
quelle
3

Zwei, die nicht erwähnt werden, sind:

  • Es kann einige Zeit dauern, bis eine große Testsuite ausgeführt wird

Ich war Teil automatisierter QS-Bemühungen, bei denen die Durchführung der Tests einen halben Tag in Anspruch nahm, da die Tests langsam waren. Wenn Sie beim Schreiben Ihrer Tests nicht aufpassen, könnte sich Ihre Testsuite auch so entwickeln. Das hört sich nicht nach einer großen Sache an, bis Sie diese Zeit geschafft haben: "Oh, ich habe gerade eine Korrektur vorgenommen, aber es wird 4 Stunden dauern, um die Richtigkeit zu beweisen."

  • Schwäche einiger Testschreibmethoden

Einige Testmethoden (wie z. B. die Automatisierung der Benutzeroberfläche) scheinen bei jeder Umdrehung nicht mehr zu funktionieren. Besonders schmerzhaft, wenn Ihr Skript beispielsweise den Testvorgang anhält, weil es darauf wartet, dass eine Schaltfläche angezeigt wird - die Schaltfläche wurde jedoch umbenannt.

Dies sind zwei Dinge, die Sie mit guter Testpraxis umgehen können: Suchen Sie nach Möglichkeiten, 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, fragile Methoden zum Schreiben von Tests zu vermeiden.

RyanWilcox
quelle
2

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

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

Jim C
quelle
0

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

  • Testautomation erhöht die Vorabkosten.
  • Testautomation erhöht die Time-to-Market.
  • Der Vorteil der Testautomation liegt in der Mitte und im Logterm. Der harte Wettbewerb konzentriert sich mehr auf kurzfristige Vorteile.

Einzelheiten finden Sie unter Market Driven Unit Testing .

k3b
quelle
-1

Einer der Hauptnachteile kann durch den Einsatz von Selbstlerntests überwunden werden. In dieser Situation werden die erwarteten Ergebnisse alle als Daten gespeichert und können mit minimaler Überprüfung durch den Benutzer der Testsuite im Selbstlernmodus aktualisiert werden (Unterschiede zwischen dem alten erwarteten Ergebnis und dem neuen tatsächlichen Ergebnis anzeigen - Aktualisierung erwartet, wenn y gedrückt wird). Dieser Lernmodus der Testsuite muss mit Vorsicht verwendet werden, damit fehlerhaftes Verhalten nicht als akzeptabel erachtet wird.

Richard Kay
quelle