Was sind die Nachteile des automatisierten Testens?

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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 .

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.