Kurs:Software-Test/Geschichte des Testens
Dieser Abschnitt soll mehr die theoretischen Themen über Testen beinhalten.
Zeitliche Phasen im Testen
[Bearbeiten]Testphasen in der Menschheitsgeschichte
[Bearbeiten]Bestimmt wurde schon seit Anbeginn der Zeit getestet, hier mal eine Einteilung aus dem letzten Jahrhundert :-)
Diese Einteilung (es gibt natürlich noch mehr) aus dem Jahr 1988 stammt von D. Gelperin und W.C. Hetzel.
Diese klassifizierten für das Software-Testen folgende Phasen und Ziele:
- Bis 1956 gab es die Debugging-orientierte Periode (engl. debugging oriented period): Testen wurde oft assoziiert mit Debugging - es gab keine klare Unterscheidung zwischen Testen und Debugging.
- 1957-1958 wurde als die demonstrations-orientierte Periode bezeichnet (engl. demonstration oriented period): nun wurde zwischen Debugging und Testen unterschieden, da es ein Ziel war, zu zeigen, dass die Software ihre Anforderungen erfüllt.
- 1979-1982 gab es die destruktions-orientierte Periode (engl. destruction oriented period): Ziel hier war es, Anomalien in der Software zu finden.
- 1983-1987 wurde als die evaluations-orientierte Periode eingestuft (engl. evaluation oriented period): hier sollte während des Software-Lebenszyklus eine Produkt-Evaluation durchgeführt und die Qualität gemessen werden.
- Ab 1988 begann die präventions-orientierte Periode (engl. prevention oriented period): Testen sollte nun zeigen, dass die Software die Spezifikation erfüllt. Auch Anomalien zu finden und diese überhaupt zu verhindern, gehörte zu den Zielen.
Mehr zu diesen Phasen kann auch im frei verfügbaren, englischen Dokument von G. T. Laycock nachgelesen werden.
Testphasen in Software-Entwicklungsmodellen
[Bearbeiten]Eine Möglichkeit der Einteilung wäre beispielsweise: Tests gleich am Anfang oder nicht gleich (analog zu 0 und 1 im PC). Da die Welt aber mit so starren Mustern nicht umgehen kann, wird in der Theorie diese Einteilung in Teststufen vorgenommen:
- Komponententest (auch Unit-Test genannt)
Übersicht der Test-Richtungen
[Bearbeiten]Hinweis: im Moment sind noch nicht alle Richtungen vertreten.
Unsere Kunden/Anwender sollen doch testen
[Bearbeiten]Nun ja, einige denken ja: Ach was, der Kunde/Anwender wird sich schon beschweren, wenn es nicht geht. Wir brauchen doch (gar) nicht (so viel) zu testen. Wir wollen uns jetzt noch nicht drüber streiten, ob und wann dieser Ansatz auf den Mond geschossen gehört.
Es gibt aber auch vollkommen andere Test-Richtungen.
Test-Driven-Development (TDD)
[Bearbeiten]Test-Driven-Development bzw. Testgetriebene Entwicklung:
Dies ist primär ein Design-Prozess. Bevor der Quelltext implementiert wird, werden vorher Überlegungen angestellt, wie verhindert werden kann, dass der Quelltext "schlecht" wird. Dies geschieht hierbei dadurch, dass vor dem Erstellen des Quelltextes die Testeinheiten (Unit Tests) erzeugt werden und erst danach, oder in einem iterativen Prozess, das eigentliche Programm geschrieben wird. Wobei als minimalistische Forderung dieser Quelltext nichts anderes tun soll, als die Tests zu erfüllen. Somit ergibt sich hier ein "natürliches" Ende der Programmerstellung: nicht, wenn ein Programmierer alle "Feature" fertig hat, sondern wenn die durch Testeinheiten vorgegebenen Forderungen an die Software erfüllt sind.
Hier gibt es Umfrage-Ergebnisse (Februar 2006) zur TDD-Benutzung: Methods & Tools Umfrage: Wie werden Unit Tests bei Ihnen im Unternehmen durchgeführt? (Bitte beachtet, dass Umfragen nicht immer die Wirklichkeit repräsentieren (siehe auch: Umfrage))
XP existiert seit 1996, Mitbegründer: Kent Beck, Ron Jeffries
„Extremes Programmieren“ (engl. extreme programming) ist Teil der flexiblen Softwareentwicklungsmethoden (engl. agile methods). Es umfasst einen Satz von bewährten Methoden in der Softwareentwicklung, zu dem unter anderem auch der TDD Ansatz gehört. Den Gegensatz zur „flexiblen Softwareentwicklung“ bilden „starre Softwareentwicklungsmodelle“ (engl. heavyweight or bureaucratic methods) wie z.B. das V-Modell oder Rational Unified Process (RUP). Mit XP soll in einem Software-Projekt folgendes verbessert werden:
- Kommunikation: Entwickler kommunizieren mit den Kunden und anderen Programmierern
- Einfachheit: beim Entwurf von Quelltext
- Mut: das System wird so früh wie möglich an den Kunden geliefert, um vorgeschlagene Änderungen einarbeiten zu können.
- Feedback: die Software wird gleich vom ersten Tag an getestet.
Dabei ist ein Gedanke, dass die Testfälle (engl. test units) als Spezifikation dienen. Des Weiteren ist eine ständige Einbeziehung (engl. continuous integration) aller Unit-Tests gefordert. Sie müssen jederzeit fehlerfrei laufen, bevor mit der Entwicklung fortgesetzt werden darf. Dazu werden Testumgebungen (wie z.B. JUnit) verwendet.
Ein weiteres Hilfsmittel ist Pair-Programming bzw. paarweises Programmieren: Hierbei macht man sich die alte Weisheit zu nutze, dass vier Augen mehr sehen, als nur zwei. Während ein Programmierer den Quelltext schreibt, denkt der andere mit. Nach einem Rollenwechsel zwischen den beiden drehen sich diese Aufgaben um. Obwohl hier augenscheinlich doppelter Personalaufwand betrieben wird, legt die Forschung nah, dass die Extrakosten lediglich 30% betragen und dafür die Qualität des erstellten Quelltextes sich stark verbessert. Die Paare werden in bestimmten Projektphasen regelmäßig neu zusammengestellt. Hierdurch ergibt sich der nützliche Nebeneffekt, dass nicht nur ein Programmierer einen bestimmten Programmcode kennt, sondern mindestens ein weiterer Programmierer als Ansprechpartner zur Verfügung steht, falls Anpassungen am Programm vorzunehmen sind.
Mitbegründer: Dave Astels, Dan North
„Verhaltenszentrierte Entwicklung“ (BDD) ist unter technischem Gesichtspunkt das Gleiche wie „testzentrierte Entwicklung“ (TDD). BDD widmet sich folgendem Aspekt:
Da bei TDD testzentriertes Vokabular benutzt wird (z.B. TestCase, TestSuite, Test,...) kann dies dazu führen, dass man eher an Testen denkt, obwohl TDD jedoch ein Design-Prozess ist. Dies will BDD durch ein gemeinsames Vokabular verbessern. Denn die Sprache beeinflusst die Denkweise (Sapir-Whorf-These). Wenn zum Beispiel immer Wörter mit Test benutzt werden, dann wird eher vielleicht nur an Verifikation (engl. verification) gedacht. Aber wenn man von Verhalten (engl. behaviour) oder Wechselbeziehungen (engl. interaction) spricht, geht es also nicht mehr nur darum, zu beweisen, dass zum Beispiel der Quelltext richtig ist, sondern der Fokus liegt auf: Was soll mein Quelltext eigentlich tun?
Deshalb geht es bei BDD um die Spezifikation. Der Fokus soll nicht mehr auf der Struktur des Quelltextes liegen (z.B. für die Klasse X braucht man auch eine Test-Klasse Test_X), sondern auf dem Verhalten des Quelltextes. Es soll eine Spezifikation erstellt werden, die das Verhalten präzise, eindeutig und in ausführbarer Form darstellt. Man schreibt eigentlich keine Tests mehr, sondern Spezifikationen.
Womit können Tester rechnen?
[Bearbeiten]Mit Allem - glaubt es ruhig
[Bearbeiten]Ihr habt doch bestimmt schon mal von Murphys Gesetz (engl. Murphy's law) gehört oder nicht?
„Wenn es zwei oder mehrere Arten gibt, etwas zu erledigen, und eine davon kann in einer Katastrophe enden, so wird jemand diese Art wählen.“
Denkt mal nach: habt Ihr nicht mal selbst so einen wirklich besch.s.enen Tag erlebt? Wie soll sich denn ein Stück Software fühlen, dass Tag ein Tag aus nur in einem PC gefangen ist? :-)
Eventuell erinnern sich ein paar ältere Semester auch noch an den Film Tron ?
Ein Standard führt nicht automatisch zu weniger Anomalien
[Bearbeiten]Einige Personen (Entwickler, Tester,...) denken, wenn der Quellcode mal kompiliert ist, sind viele Anomalien gefunden (quasi das Gröbste ist getan und die Tester können weiter ihren Job durchführen und die Entwickler sind nun fertig), denn die Compiler sind ja zuverlässig. Denn über eine Programmiersprache bzw. Compiler hat ja ein Komitee beraten und eine Standardisierung führe ja zu weniger Fehlern. Dabei ist ein Compiler auch nur Software.
Die Vorteile von Standards sind natürlich offensichtlich (z.B. besser als keinen Standard zu haben). Es sollte jedoch beachtet werden, dass manche Standards nicht unbedingt zu weniger Anomalien führen und deswegen auch ein falsches Sicherheitsgefühl erzeugt werden kann.
Les Hatton beschreibt in Static Analysis folgende Situationen:
ISO-Komitees brauchen keine 100%ige Einigung, um einen Aspekt zu beschliessen.
Es kann auch mit 75% Mehrheit über einen Punkt beschlossen werden.
Man stelle sich 40-50 Personen vor, die zusammen beraten und zu einer Entscheidung kommen wollen. Glaubt ihr nicht, dass man irgendwann, wenn man genug hat, einfach alles abschliessen will und dabei auf ein paar wenige Personen nicht hören möchte? (Nehmen wir an wie im amerikanischen Gerichtssystem die Geschworenen. Wurden nicht auch schon Unschuldige zu Tode verurteilt?)
Als die Programmiersprache C 1990 veröffentlicht wurde, beinhaltete der C Standard 201 Punkte, über die sich das Komitee nicht ausreichend einigen konnte. Der Standard von 1999 beinhaltete fast doppelt so viele Punkte (nämlich 366). Für viele dieser Punkte ist das Verhalten nicht einmal definiert. Es gibt nämlich keine Anforderung bzw. Regelung, diese Probleme aufzuspüren.
Wenn die Standardisierung von der Programmiersprache Fortran betrachtet wird: Der Leistungsumfang von Fortran77, Fortran90 zu Fortran95 ist gestiegen. Aber die neuen Features haben neue Probleme erzeugt und ausserdem sollte ja auch eine Rückwärtskompatibilität zu den alten Programmiersprachen existieren. Wer sollte denn nun den existierenden Code verändern (das kostet schliesslich Ressourcen)? Also sind viele der Anomalien weiter existent geblieben.
Aus diesem Grund sind statische Test-Techniken immer noch zu empfehlen, da manche Anomalien erst unter bestimmten Bedingungen eintreten, diese aber katastrophale Auswirkungen haben können. Und dies könnte durch z.B. Reviews überhaupt erst bzw. früher gefunden werden.
Theorie
[Bearbeiten]An dich: Dieser Abschnitt ist am Entstehen. Im Moment wird aber auch an den anderen gearbeitet.
Also: hast du eine Frage dazu? Frage doch bitte einen der Betreuer hier.
Nur Mut, wir Betreuer beissen nicht - nun ja, nur manchmal :-)