Wenn ich Unit-Tests für jede Klasse und / oder Member-Funktion und Akzeptanztests für jede User Story habe, habe ich genug Tests, um sicherzustellen, dass das Projekt wie erwartet funktioniert?
Zum Beispiel, wenn ich Komponententests und Abnahmetests für ein Feature habe, benötige ich noch Integrationstests oder sollten die Einheits- und Akzeptanztests den gleichen Boden abdecken? Gibt es Überlappungen zwischen den Testtypen?
Ich spreche hier über automatisierte Tests. Ich weiß, dass manuelle Tests immer noch für Dinge wie Benutzerfreundlichkeit usw. erforderlich sind.
Ich würde empfehlen, die Kapitel 20 - 22 in der 2. Ausgabe von Code Complete zu lesen. Es deckt die Softwarequalität sehr gut ab.
Hier ist ein kurzer Überblick über einige der wichtigsten Punkte (alle Anerkennung geht an McConnell, 2004)
Kapitel 20 - Die Landschaft in Softwarequalität:
Kapitel 21 - Collaborative Construction:
Kapitel 22 - Entwickler testen:
Was die Formulierung Ihrer Komponententests betrifft, sollten Sie Basistests, Datenflussanalysen, Grenzanalysen usw. in Betracht ziehen. Diese werden im Buch (das auch viele weitere Literaturhinweise enthält) ausführlich erläutert ).
Vielleicht ist das nicht genau das, was Sie gefragt haben, aber ich würde sagen, automatisiertes Testen ist definitiv nicht genug für eine Strategie. Sie sollten auch Dinge wie Paarprogrammierung, formale Überprüfungen (oder informelle Überprüfungen, abhängig von der Größe des Projekts) und Testgerüste zusammen mit Ihren automatisierten Tests (Komponententests, Regressionstests usw.) In Betracht ziehen.
Wenn ich Unit-Tests für jede Klasse und / oder Member-Funktion und Akzeptanztests für jede User Story habe, habe ich genug Tests, um sicherzustellen, dass das Projekt wie erwartet funktioniert?
Nein. Tests können nur bestätigen, woran Sie gedacht haben. Nicht, woran du nicht gedacht hast.
Die Idee mehrerer Testzyklen besteht darin, Probleme so früh wie möglich zu erkennen, wenn sich die Dinge ändern.
Unit-Tests sollten von den Entwicklern durchgeführt werden, um sicherzustellen, dass die Einheiten isoliert funktionieren .
Abnahmetests sollten vom Kunden durchgeführt werden, um sicherzustellen, dass das System die Anforderungen erfüllt.
Es hat sich jedoch etwas zwischen diesen beiden Punkten geändert, die ebenfalls getestet werden sollten. Das ist die Integration von Einheiten in ein Produkt, bevor es dem Kunden gegeben wird.
Das ist etwas, das zuerst vom Produktentwickler und nicht vom Kunden getestet werden sollte. In dem Moment, in dem Sie den Client in Anspruch nehmen, werden die Dinge langsamer, je mehr Fixes Sie tun können, bevor sie ihre schmutzigen kleinen Hände darauf bekommen, desto besser.
In einem großen Laden (wie dem unseren) gibt es an jedem Punkt, an dem sich das zu liefernde Produkt ändert, Unit-Tests, Integrationstests, Globalisierungstests, Master-Build-Tests usw. Erst wenn alle Fehler mit hohem Schweregrad behoben sind (und ein Plan zur Behebung von Bugs mit niedriger Priorität vorhanden ist), entfesseln wir das Produkt für unsere Beta-Clients.
Wir wollen nicht ihnen ein zwielichtiges Produkt geben, nur weil das Beheben eines Fehlers in dieser Phase viel kostspieliger ist (vor allem in Bezug auf administrativ) als alles, was wir intern tun.
Es ist wirklich unmöglich zu wissen, ob Sie genügend Tests haben, basierend darauf, ob Sie einen Test für jede Methode und Funktion haben. Normalerweise werde ich Tests mit Coverage-Analysen kombinieren, um sicherzustellen, dass alle meine Code-Pfade in meinen Komponententests trainiert werden. Auch das ist nicht wirklich genug, aber es kann ein Hinweis darauf sein, wo Sie Code eingeführt haben, der von Ihren Tests nicht ausgeübt wird. Dies sollte ein Hinweis darauf sein, dass mehr Tests geschrieben werden müssen oder, wenn Sie TDD machen, müssen Sie langsamer und disziplinierter sein. : -)
Tests sollten sowohl gute als auch schlechte Pfade abdecken, insbesondere in Komponententests. Ihre Akzeptanztests beschäftigen sich mehr oder weniger mit dem schlechten Pfadverhalten, sollten jedoch zumindest auf häufig auftretende Fehler reagieren. Je nachdem, wie vollständig Ihre Geschichten sind, können die Akzeptanztests angemessen sein oder auch nicht. Oft besteht eine Viele-zu-Eins-Beziehung zwischen Akzeptanztests und Geschichten. Wenn Sie nur einen automatisierten Abnahmetest für jede Geschichte haben, haben Sie wahrscheinlich nicht genug, es sei denn, Sie haben unterschiedliche Geschichten für alternative Wege.
Mehrere Testschichten können sehr nützlich sein. Unit-Tests, um sicherzustellen, dass sich die Teile verhalten; Integration, um zu zeigen, dass Cluster von kooperierenden Einheiten wie erwartet zusammenarbeiten, und "Akzeptanz" -Tests, um zu zeigen, dass das Programm wie erwartet funktioniert. Jeder kann während der Entwicklung Probleme bekommen. Überlappung per se ist keine schlechte Sache, obwohl zu viel davon zu Verschwendung wird.
Das heißt, die traurige Wahrheit ist, dass Sie niemals dafür sorgen können, dass sich das Produkt "wie erwartet" verhält, denn die Erwartung ist eine unbeständige, menschliche Angelegenheit, die sehr schlecht auf Papier übersetzt wird. Eine gute Testabdeckung verhindert nicht, dass ein Kunde sagt "das ist nicht ganz das, was ich mir vorgestellt habe ...". Häufige Feedback-Schleifen helfen dort. Betrachten Sie häufige Demos als "Vernunfttest", um sie zu Ihrem manuellen Mix hinzuzufügen.
Wahrscheinlich nicht, es sei denn, Ihre Software ist wirklich, wirklich einfach und hat nur eine Komponente.
Unit Tests sind sehr spezifisch, und Sie sollten alles gründlich mit ihnen abdecken. Entscheiden Sie sich hier für eine hohe Code-Abdeckung. Sie decken jedoch nur jeweils eine Funktion ab und nicht, wie die Dinge zusammen funktionieren. Akzeptanztests sollten nur das abdecken, was dem Kunden auf hohem Niveau wirklich wichtig ist, und während es einige Fehler in der Art und Weise zusammenhält, wird es nicht alles erfassen, da die Person, die solche Tests schreibt, das System nicht genau kennt.
Am wichtigsten ist, dass diese Tests möglicherweise nicht von einem Tester geschrieben werden. Komponententests sollten von Entwicklern geschrieben werden und häufig (bis zu alle paar Minuten, je nach Codierungsstil) von den Entwicklern (und im Idealfall auch vom Build-System) ausgeführt werden. Abnahmetests werden oft vom Kunden oder jemandem im Auftrag des Kunden geschrieben, der darüber nachdenkt, was für den Kunden wichtig ist. Sie benötigen jedoch auch Tests, die von einem Tester geschrieben werden und sich wie ein Tester verhalten (und nicht wie ein Entwickler oder Kunde).
Sie sollten auch die folgenden Arten von Tests berücksichtigen, die in der Regel von Testern geschrieben werden:
Integrationstests eignen sich für die Integration Ihres Codes in andere Systeme wie Drittanbieteranwendungen oder andere interne Systeme wie Umgebung, Datenbank usw. Verwenden Sie Integrationstests, um sicherzustellen, dass das Verhalten des Codes weiterhin wie erwartet ist.
Kurz no.
Zunächst sollten Ihre Story-Cards Akzeptanzkriterien haben. Das heißt, Akzeptanzkriterien, die vom Product Owner in Verbindung mit dem Analysten spezifiziert werden und das erforderliche Verhalten spezifizieren, und falls erfüllt, wird die Story Card akzeptiert.
Die Akzeptanzkriterien sollten den automatisierten Komponententest (durchgeführt über TDD) und die automatisierten Regressions- / Funktionstests, die täglich durchgeführt werden sollten, vorantreiben. Denken Sie daran, wir möchten Fehler nach links verschieben, dh je früher wir sie finden, desto billiger und schneller werden sie behoben. Darüber hinaus ermöglicht uns ein kontinuierliches Testen, mit Vertrauen zu refaktorisieren. Dies ist erforderlich, um ein nachhaltiges Entwicklungstempo aufrechtzuerhalten.
Zusätzlich benötigen Sie einen automatisierten Leistungstest. Wenn Sie einen Profiler täglich oder über Nacht ausführen, erhalten Sie einen Einblick in den Verbrauch von CPU und Arbeitsspeicher und ob Speicherlecks vorhanden sind. Darüber hinaus können Sie mit einem Tool wie LoadRunner das System entsprechend der tatsächlichen Nutzung laden. Sie können die Antwortzeiten und den CPU- und Speicherverbrauch auf der Produktion messen, wie die Maschine, auf der loadrunner läuft.
Der automatisierte Leistungstest sollte die tatsächliche Nutzung der App widerspiegeln. Sie messen die Anzahl der Geschäftstransaktionen (d. H. Wenn eine Webanwendung auf eine Seite klickt und die Antwort an die Benutzer oder Rundreisen zum Server). und bestimmen Sie die Mischung dieser Transaktion zusammen mit der Rate, die sie pro Sekunde erreichen. Anhand dieser Informationen können Sie den automatischen Load-Runner-Test, der für den Leistungstest der Anwendung erforderlich ist, ordnungsgemäß entwerfen. Wie es oft der Fall ist, werden einige der Leistungsprobleme auf die Implementierung der Anwendung zurückgeführt, während andere durch die Konfiguration der Serverumgebung bestimmt werden.
Denken Sie daran, dass Ihre Anwendung einem Leistungstest unterzogen wird. Die Frage ist, ob der erste Leistungstest vor oder nach der Veröffentlichung der Software stattfindet. Glauben Sie mir, der schlechteste Ort für ein Performance-Problem ist die Produktion. Leistungsprobleme können am schwierigsten zu beheben sein und können dazu führen, dass ein Fehler für alle Benutzer auftritt und das Projekt abgebrochen wird.
Schließlich gibt es User Acceptance Testing (UAT). Diese werden vom Produktionseigentümer / Geschäftspartner getestet, um das Gesamtsystem vor der Freigabe zu testen. Im Allgemeinen ist es aufgrund der anderen Tests nicht ungewöhnlich, dass die Anwendung während der UAT null Fehler zurückgibt.
Es hängt davon ab, wie komplex Ihr System ist. Wenn Ihre Abnahmetests (die die Kundenanforderungen erfüllen) Ihr System von vorne nach hinten trainieren, dann tun Sie das nicht.
Wenn Ihr Produkt jedoch auf anderen Ebenen beruht (wie Backend-Middleware / Datenbank), dann benötigen Sie einen Test, der beweist, dass Ihr Produkt problemlos von Ende zu Ende verbunden werden kann.
Wie andere Leute kommentiert haben, beweisen Tests nicht notwendigerweise, dass das Projekt wie erwartet funktioniert, wie Sie es erwarten.
Häufige Rückkopplungsschleifen zum Kunden und / oder Tests, die auf eine Weise geschrieben / analysiert werden, die der Kunde versteht (zum Beispiel in einem BDD-Stil ) kann wirklich helfen.
Wenn ich Unit-Tests für jede Klasse habe und / oder Mitgliederfunktion und Akzeptanz Tests für jede User Story habe ich genug Tests, um das Projekt zu gewährleisten funktioniert wie erwartet?
Dies reicht aus, um zu zeigen, dass Ihre Software funktional korrekt ist , mindestens so viel, wie Ihre Testabdeckung ausreicht. Nun, je nachdem, was Sie entwickeln, gibt es sicherlich nicht-funktionale Anforderungen, die wichtig sind, denken Sie an Zuverlässigkeit, Leistung und Leistungsfähigkeit.
Technisch gesehen sollte eine ganze Reihe von Akzeptanztests alles abdecken. Davon abgesehen sind sie für die meisten Definitionen nicht genug. Durch Komponententests und Integrationstests können Sie Bugs / Probleme früher und auf lokalisiertere Weise erkennen, wodurch sie viel einfacher zu analysieren und zu beheben sind.
Bedenken Sie, dass eine vollständige Menge manuell ausgeführter Tests mit den Anweisungen auf Papier ausreichen würde, um zu bestätigen, dass alles wie erwartet funktioniert. Wenn Sie jedoch die Tests automatisieren können, sind Sie viel besser dran, denn das macht das Testen viel einfacher. Die Papierversion ist "vollständig", aber nicht "ausreichend". Auf dieselbe Weise fügt jede Testschicht mehr zum Wert von "genug" hinzu.
Es ist auch erwähnenswert, dass die verschiedenen Tests dazu neigen, das Produkt / den Code von einem anderen "Standpunkt" aus zu testen. Ähnlich wie die QA Fehler auffängt, für die der Entwickler nie gedacht hätte, könnte ein Satz von Tests Dinge finden, die der andere nicht tun würde.
Die Abnahmeprüfung kann vom Kunden sogar manuell durchgeführt werden, wenn das System klein ist.
Unit und kleine Integrationstests (bestehend aus Unit-Tests) sind für Sie da, um ein nachhaltiges System aufzubauen.
Versuchen Sie nicht, einen Test für jeden Teil des Systems zu schreiben. Das ist spröde (leicht zu brechen) und überwältigend.
Entscheiden Sie sich für die kritischen Teile des Systems, die zu viel Zeit in Anspruch nehmen, um Akzeptanztests nur für diese Teile manuell zu testen und zu schreiben, um es für alle einfacher zu machen.
Tags und Links unit-testing integration-testing automated-tests acceptance-testing