WikiDer > Rahmen für integrierten Test

Es Rahmen für integrierten Test (oder PASSEN) ist ein Konzept in der Entwicklung und zu testen von Computer Programmwurde entwickelt von Gemeinde Cunningham, Rick Mugridge und andere Mitarbeiter der amerikanisch Beratungsunternehmen Object Mentor.

Basiskonzept

FIT basiert auf Extremes Programmieren und andere agil Methoden.

Das Grundkonzept von FIT besteht darin, ein Computerprogramm innerhalb der Softwareentwicklung hängt hauptsächlich vom Grad der Kommunikation innerhalb der Entwicklungsgruppe für das Programm. Konkret muss eine intensive Kommunikation zwischen allen unterschiedlichen Akteuren innerhalb eines Softwareprojekts stattfinden, unabhängig von deren Rolle.

Ein großes Problem dabei ist jedoch, dass es innerhalb jedes Softwareprojekts eine Reihe unterschiedlicher Rollen gibt, die alle eine unterschiedliche Sicht auf das Projekt haben. Grundsätzlich spricht die FIT-Gruppe von drei Rollen (der Kunden, das Tester und der Programmierer). Alle diese Rollen haben ihre eigene Sicht auf das Projekt und ihr eigenes Interesse, das Projekt erfolgreich abzuschließen. Da aber alle ihre eigene Sicht auf das Leben und das Projekt haben, ist es schwierig, eine tiefgreifende Kommunikation zwischen Akteuren mit unterschiedlichen Rollen aufzubauen: Ein „Kunde“ hat beispielsweise eine funktionale Sicht auf das Projekt, weiß, wo das Projekt hingehört die Geschäftslandschaft, was von dem zu liefernden Programm funktional erwartet wird. Ein „Programmierer“ hingegen betrachtet es technisch, weiß, wie die Software gebaut werden, welche Bibliotheken verwendet werden und so weiter.

FIT ist als Software-Tool gedacht, um die Kommunikation zwischen all diesen Rollen herzustellen.

Theorie

Die Theorie hinter FIT baut auf der Theorie dahinter auf domänengesteuertes Design, wie beschrieben in Domänengetriebenes Design von Eric Evans. Einer der Hauptgedanken in diesem Buch ist, dass ein Softwareprojekt nur dann erfolgreich sein kann, wenn eine reibungslose Kommunikation zwischen allen Beteiligten stattfindet (und:Interessengruppen) zum Projekt. Allerdings werden die Stakeholder in ihrer Kommunikation dadurch behindert, dass sie alle das Projekt aus ihrer eigenen Perspektive sehen und ihr eigenes Interesse am Projekt haben; sie alle spielen ihr eigenes Rolle beim Projekt. Dadurch spricht auch jeder Stakeholder seine eigenen Sprache, ein eigenes Slang die auf seine Perspektive auf das Projekt zugeschnitten ist.

Domain-driven Design basiert auf der Idee, dass Stakeholder in jeder Rolle im Projekt zu einer gemeinsamen Sprache zusammenkommen sollten, in der sie über das Projekt sprechen können. Durch die Etablierung einer gemeinsamen Sprache können alle Schauspieler (Mitarbeiter) im Projekt das Projekt gemeinsam so besprechen, dass jeder es versteht und auch in sein eigenes übersetzen kann Slang um zu sehen, ob das Gesagte wirklich richtig ist.

FIT ist eine vereinfachte Implementierung dieses Prozesses, spezialisiert auf das Erstellen und Testen der zu liefernden Software (Domain-Driven Design hat auch Auswirkungen außerhalb der Software und beeinflusst die gesamte Projektstruktur, die Projektmanagement, und so weiter). FIT erzwingt eine gemeinsame Sprache, die die Stakeholder jeder Rolle verwenden können, um gemeinsam zu bestimmen, wann die Software so funktioniert, wie sie sollte und wann nicht.

Rollen

Die Macher von FIT unterscheiden drei rollen (Kunde, Tester und Programmierer), die für die zu liefernde Software wichtig sind.

Kunde

Der Kunde ist die treibende Kraft hinter dem Projekt. Der Kunde ist der Grund für den Projektstart, der Kunde ist derjenige, der das Projekt bezahlt (und somit Erwartungen an die Software äußern kann) und der Kunde ist auch derjenige, der funktional weiß, was die Software leisten soll. (dh er weiß, welche Funktionen die Endbenutzer von der Software erwarten). Und natürlich kennt der Kunde auch die nicht-funktionalen Anforderungen, die an die Software gestellt werden, wie z.Performance" (wie auch immer der Kunde es definiert), Systemumgebung usw.

Tester

Der Tester ist die Rolle innerhalb des Projekts, die dafür verantwortlich ist, dass die gelieferte Software den Anforderungen des Kunden entspricht. Zu diesem Zweck hat der Tester sowohl funktionale Einblicke (er ist mit dem Problembereich der Software vertraut) als auch technische Einblicke (er weiß mehr über die Funktionsweise der Software, er weiß neben dem, was sie tut, auch, ob es praktische Probleme oder Grenzen der Software gibt usw.). Der Tester ist beispielsweise in der Lage, die funktionalen Anforderungen des Kunden zu liefern; wenn der Kunde sagt "die Software muss Zinsen berechnen", kann der Tester das übersetzen in "wenn ich diese und diese Zahl eingebe, sollte diese Zahl rauskommen".

Programmierer

Der Programmierer ist die Person, die für die Programmierung der Software nach einer Spezifikation des Kunden verantwortlich ist. Der Programmierer hat hauptsächlich technische Kenntnisse der Software: Er weiß, wie der Code aufgebaut ist, was Datenstrukturen verwendet wurden, die APIs es gibt gebrauchte, solche Sachen. Der Programmierer baut sich natürlich nebenbei ein gewisses Funktionswissen über die Software auf, hat aber in der Regel keinen Überblick über das Gesamtsystem oder wie sich seine Software in das Ganze einfügt.

Gemeinsame Sprache

FIT implementiert eine gemeinsame Sprache für alle Rollen und Interessengruppen, die verwendet wird, wenn Softwaretest. Um dies zu ermöglichen und gleichzeitig einfach zu halten, betrachtet FIT eine zu testende Software als Blackbox, bei der das Testteam nur die Kontrolle über die Ein- und Ausgabe der Software hat. Das FIT-Framework besteht aus einem ziemlich einfachen Mechanismus, der es Kunden, Testern und Programmierern ermöglicht, mit einer Reihe von Tests für Software zusammenzuarbeiten und zu interagieren.

Ein Test einer Software im FIT-Framework besteht aus a Tabelle die die Eingabe für einen Test und die erwartet Ausgabe. Das Framework selbst besteht aus einer Software, die die Tabelle liest, die Eingabewerte extrahiert und die zu testende Software mit dieser Eingabe spielt. Die tatsächliche Ausgabe wird dann mit den erwarteten Werten aus der Tabelle verglichen. Schließlich zeigt das Framework die ursprüngliche Tabelle erneut an, ergänzt um eine Farbcodierung: Wenn der erwartete Wert mit dem realen Ergebnis übereinstimmt, wird der erwartete Wert in Grün angezeigt, andernfalls in Rot. Die zugrunde liegende Idee ist, dass die Sprache der Eingabe- und Ausgabepaare und Grün oder Rot so einfach ist, dass Akteure in jeder Rolle dieser Sprache folgen und diese sprechen können.

Ein wichtiger Teil des FIT-Frameworks ist die Fähigkeit für alle Rollen, schnell Tests zu erstellen, auszuführen, zu ändern oder darauf zuzugreifen. Dies erfordert eine Software, die es allen Arten von Akteuren leicht macht, Tabellen zu erstellen und zu ändern und auch die Tests durchzuführen. Dies sind strengere Anforderungen als zunächst erscheinen; Bedenke nur, dass es den meisten Menschen ohnehin schon schwerfällt, reinzukommen HTML einen Tisch bauen. Außerdem muss es natürlich nicht nur möglich sein, einen Test einzurichten und zu ändern, sondern ein nützliches Tool muss auch Änderungen vornehmen zurück laufen kann (weil Fehler durchaus vorkommen). Erstellte Tests müssen speicherbar und leicht auffindbar sein (ein Tool, in das Sie 150 Testtabellen eingeben, die weg sind, wenn Sie Computer ausschalten wird einfach nicht verwendet). Idealerweise sollte es möglich sein, Tests zu kopieren, um andere Tests zu erstellen, die den kopierten Tests ähneln. Und die Möglichkeit, die Testtabelle mit erklärenden Texten zu ergänzen, ist sicherlich wünschenswert. Und auch das Testen selbst sollte einfach sein: Es sollte genauso einfach sein, eine Batterie von 1000 Tests durchzuführen wie einen einzelnen Test. Oder eine Auswahl aus diesen 1000 Tests.

Benutzerfreundlichkeit

Es wird klar sein, dass die Benutzerfreundlichkeit bei FIT an erster Stelle steht: die Verarbeitung und Testwerkzeug muss erreichbar sein und den Benutzer in allem unterstützen. Das FIT-Team von Object Mentor empfiehlt Entwicklern von FIT-Implementierungen, a Wiki-Tool und wandeln diese um, damit die Tests direkt aus dem Wiki ausgeführt werden können.

Der Rahmen

Das FIT-Framework selbst ist keine ausführbare Software. Das Framework besteht hauptsächlich aus Dokumentation und Standards.

Der Hauptteil des Frameworks ist die Dokumentation zur Nutzung und Anwendung von FIT. Diese Dokumentation steht kostenlos auf der FIT-Website zur Verfügung. Dazu kommt das Buch von Ward Cunningham und Rick Mugridge.

Für diejenigen, die FIT-Implementierungen erstellen möchten, enthält die Dokumentation eine Anleitung zur Funktionalität des Bearbeitungstools und eine Spezifikation der Art von Testtabellen, die unterstützt werden sollten. In Bezug auf Bearbeitungssoftware, a Wiki empfohlen, aber auch ein anderes Tool mit ähnlicher Funktionalität ist möglich. Die Verwendung von a . wird beschrieben Textverarbeitungssystem und das eingebaute Skriptsprache.

Tests und Tabellen

Das Framework definiert drei Arten von Tests und zugehörige Tabellen. Diese Typen sind durch den entsprechenden Typ gekennzeichnet Halterung.

Säulentest (ColumnFixture)

In diesem Testtyp die Tabelle enthält in jeder Zeile der Tabelle einen separaten Test. Jede Spalte der Tabelle kann für einen Test oder eine erwartete Ausgabe eingegeben werden.

Reihentest (RowFixture)

In dieser Testebene gibt es keine Eingabe. Jede Zeile ist eine separate Ausgabe, die aus einer Reihe von Feldern besteht (jede Spalte ist ein Feld). Diese Art von Test dient zum Testen der Art von Software, die große Datenmengen erzeugt, wie z DatenbankAnfragen.

Aktionstest (ActionFixture)

Diese Testebene dient zum Testen von Prozessen (die Ausführung einer Reihe von Aktionen durch das Programm, die Ausführung eines GUI, solche Sachen). Ein Prozess wird als Maschine mit Schaltflächen und einem internen Zustand dargestellt. Jede Zeile enthält eine Befehlsspalte mit einem Befehl ("Drücken Sie diese Taste") und eine Spalte, die den Effekt beschreibt. Die ganze Tabelle ist eine Art Beschreibung von a endliche Automaten, so dass alle möglichen einfachen Prozesse beschrieben werden können. Das Ganze wird in der Dokumentation mit der Bedienung von a Taschenrechner mit Tasten und einem auslesbaren Display.

Geräte

Eine wichtige Position bei der Nutzung von FIT ist dem Programmierer vorbehalten. Für jeden erstellten Test muss Code geschrieben werden, um die Tabelle mit der zu testenden Software zu verbinden. Während Implementierungen des Frameworks Software bereitstellen, die die Testtabellen liest, müssen die gelesenen Werte dennoch in einer für die Software verständlichen Weise an die zu testende Software gespeist werden. Und natürlich muss die Ausgabe der Software für die FIT-Software in einer Form aufbereitet werden, die die FIT-Software versteht.

Die Brücke, die ein Programmierer zwischen Tabelle und zu testender Software schreibt, wird zu a Halterung erwähnt. Von einer Framework-Implementierung wird erwartet, dass sie es dem Programmierer leicht macht, ein Fixture zu schreiben; Das bedeutet, dass eine Framework-Implementierung jede Testebene mit einem Basis-Fixture unterstützen muss, das die meisten der erforderlichen Funktionen bereitstellt. Die Idee ist, dass ein Programmierer ein Fixture bauen kann, indem er ein paar einfache Erweiterungen zu einem Basic Fixture schreibt. Und diese Erweiterungen sollten möglichst einfach sein: Nicht nur, weil die Verwendung von FIT dem Programmierer sonst zu viel Arbeit macht, sondern auch, weil die Komplexität der Fixtures die Fehlerwahrscheinlichkeit erhöht. Und das in Software, die eigentlich dazu gedacht ist Fehler zu erkennen.

Implementierungen

Es stehen verschiedene Implementierungen des FIT-Frameworks zur Verfügung, die sich hauptsächlich auf Programmiersprache. Zum Zeitpunkt dieses Schreibens sind die folgenden Implementierungen bekannt:

• FitLibrary Eine einfache Implementierung, die sich hauptsächlich auf Gerätetypen und weniger auf die Bearbeitungssoftware konzentriert. Implementiert alle Standard-Fixtures und fügt einige Fixtures hinzu. Ermöglicht auch das Hinzufügen von benutzerdefinierten Geräten als Plugins. Enthält Implementierungen für unter anderem, Java, C# und C .
• FitNesse Eine umfassende Implementierung von FIT. Verwendet FitLibrary und legt ein selbst erstelltes Wiki dagegen. FitNesse konzentriert sich auf Java, aber es wird hart an der ersten, endgültigen Version einer Portierung auf gearbeitet C#. Es ist die Bedeutung, die C und Python auch Implementierungen erhalten.
• WinFitRunnerLite Eine kleine Umsetzung von Microsoft, die eine kleine Bibliothek verwendet und Excel als vorne.