Programmfehler

aus Wikipedia, der freien Enzyklopädie

Ein Programmfehler oder Softwarefehler, häufig auch im Deutschen mit dem englischen Wort Bug (Wanze, Käfer, Insekt; Aussprache [bʌg]) bezeichnet, ist ein Ausdruck aus dem EDV-Bereich.

Ein Bug tritt in Computerprogrammen auf, wenn der Programmierer einen bestimmten Zustand in der Programmlogik nicht berücksichtigt hat, oder wenn die Laufzeitumgebung an sich fehlerhaft arbeitet. Auch Unvollständigkeit, Fehler, Ungenauigkeiten, Mehrdeutigkeiten o. ä. in der Spezifikation des Programms können zu Bugs führen, bzw. als solche interpretiert werden.

Es gibt eine Regel, nach der ein Computerprogramm ab einer bestimmten Größe immer auch Programmfehler beinhaltet. Programmierfehler lassen sich auch bei sorgfältigster Programmierung nicht vermeiden. Man schätzt, dass pro 1000 Zeilen Code im Mittel etwa zwei Fehler auftreten.

Die Anzahl von Fehlern zur Lebenszeit eines komplexen Systems verhält sich nach der sogenannten Badewannenkurve. Diese besagt, dass für neue Produkte auch die Zahl der Fehler hoch ist. Die Fehler werden zum Großteil behoben, wonach eine Phase mit wenig Fehlern erreicht wird. Gegen Ende der Nutzungszeit steigt die Zahl der Fehler wieder an, was erheblich zur Softwarealterung beiträgt.

Um Bugs in Programmen besser verstehen zu können, gibt es Programme, sogenannte Debugger, mit denen man ein Programm, welches man analysiert, schrittweise ablaufen und sich dabei sämtliche internen Zustände (Variablen) des Programms anzeigen lassen kann.

Inhaltsverzeichnis

1 Das engl. Wort „Bug“ als Synonym für Programmfehler
2 Arten von Programmfehlern
3 Vermeidung und Behebung von Programmfehlern
4 Fehlerfreiheit
5 Folgen von Programmfehlern
6 Reproduzierbarkeit von Programmfehlern
7 Siehe auch
8 Literatur
9 Einzelnachweise
10 Weblinks

[Bearbeiten] Das engl. Wort „Bug“ als Synonym für Programmfehler

Logbuch-Seite des Mark II Aiken Relay Calculator mit dem ersten Bug (1947)

Das Wort „Bug“ wurde schon im 19. Jahrhundert für kleine Fehler in mechanischen und elektrischen Teilen verwendet. Knistern und Rauschen in der Telefonleitung würde z. B. daher rühren, dass kleine Tiere („Bugs“ (engl: Wanze)) an der Leitung knabbern. Thomas Edison hat 1878 an seinen Freund Tivadar Puskás (dem Erfinder der Telefonzentrale und des Telefongraphen) einen Brief über die Entwicklung seiner Erfindungen geschrieben, in dem er kleine Störungen und Schwierigkeiten als „Bugs“ bezeichnete („… that ‚Bugs‘ – as such little faults and difficulties are called – show themselves…“).

Die Erfindung des Begriffs in bezug auf Computer geht möglicherweise auf die Computerpionierin Grace Hopper zurück.^[1] Sie verbreitete die Geschichte, dass am 9. September 1945 eine Motte in einem Relais des Computers Mark II Aiken Relay Calculator zu einer Fehlfunktion führte. Die Motte wurde entfernt und in das Logbuch mit den Worten „First actual case of bug being found.“ („Das erste Mal, dass tatsächlich ein Bug gefunden wurde.“) geklebt. Die Legende von der Begriffsfindung hält sich hartnäckig, obwohl die Logbuch-Eintragung gerade auf die frühere Verwendung des Begriffs hinweist. Zudem irrte Grace Hopper sich hinsichtlich des Jahres: Der Vorfall ereignete sich tatsächlich am 9. September 1947. Die entsprechende Seite des Logbuchs wurde bis Anfang der 1990er Jahre am Naval Surface Warfare Center Computer Museum der US-Marine in Dahlgren, Virginia, aufbewahrt. Zur Zeit befindet sich diese Logbuch-Seite mit der Motte am Smithsonian Institute.

[Bearbeiten] Arten von Programmfehlern

In der Softwaretechnik wird zwischen folgenden Typen von Fehlern in Programmen unterschieden:

Syntaxfehler sind Verstöße gegen die grammatischen Regeln der benutzten Programmiersprache. Ein Syntaxfehler verhindert die Kompilierung des fehlerhaften Programms. Bei Programmiersprachen, die sequentiell interpretiert werden, bricht das Programm an der syntaktisch fehlerhaften Stelle undefiniert ab.

Laufzeitfehler sind alle Arten von Fehlern, die auftreten, während das Programm abgearbeitet wird. Da diese Fehler die Programmlogik und damit die Bedeutung des Programmcodes betreffen, spricht man hier auch von semantischen Fehlern. Ihre Ursache liegt in den meisten Fällen in einer inkorrekten Implementierung der gewünschten Funktionalität im Programm. Gelegentlich tritt als Ursache auch eine ungeeignete Laufzeitumgebung auf (z. B. eine falsche Betriebssystem-Version). Laufzeitfehler können sich auf die unterschiedlichsten Arten zeigen. Oftmals zeigt das Programm ungewünschtes Verhalten, im Extremfall wird die Ausführung des Programms abgebrochen („Absturz“), oder das Programm geht in einen Zustand über, in dem es keine Benutzereingaben mehr akzeptiert („Einfrieren“, „Hängen“). Wird in Programmiersprachen ohne Garbage Collection (etwa C oder C++) Speicher nach der Verwendung nicht mehr freigegeben, so wird durch das Programm auf Dauer immer mehr Speicher belegt. Diese Situation wird Speicherleck genannt. Aber auch in Programmiersprachen mit automatischer Speicherbereinigung (etwa Java oder C#) können ähnliche Probleme auftreten, wenn zum Beispiel Objekte durch systemnahe Programmierung unkontrolliert angesammelt werden. Noch kritischer sind versehentlich vom Programmierer freigegebene Speicherbereiche, die oft trotzdem noch durch hängende Zeiger referenziert werden, da dies zu völlig unkontrolliertem Verhalten der Software führen kann. Moderne Laufzeitumgebungen erlauben daher solche programmierbaren Speicherfreigaben grundsätzlich nicht, da der Programmierer in echten objektorientierten Umgebungen gar nicht entscheiden kann, ob und wie lange bestimmte Objekte benötigt werden.

Logischer Fehler ist ein falscher Problemlösungsansatz oder der Algorithmus ist nicht korrekt.

Designfehler sind Fehler im Grundkonzept, entweder bei der Definition der Anforderungen an die Software, oder bei der Entwicklung des Softwaredesigns, auf dessen Grundlage das Programm entwickelt wird. Fehler bei der Anforderungsdefinition beruhen oft auf mangelnder Kenntnis des Fachgebietes, für das die Software geschrieben wird oder auf Missverständnissen zwischen Nutzern und Entwicklern. Fehler direkt im Softwaredesign hingegen sind oft auf mangelnde Erfahrung der Softwareentwickler oder auf Folgefehler durch Fehler in der Anforderungsspezifikation zurückzuführen. In anderen Fällen ist das Design historisch gewachsen und wird mit der Zeit unübersichtlich, was wiederum zu Designfehlern bei Weiterentwicklungen des Programms führen kann. Vielen Programmierern ist das Softwaredesign auch lästig, sodass oftmals ohne richtiges Konzept direkt entwickelt wird, was dann insbesondere bei steigendem Komplexitätsgrad der Software unweigerlich zu Designfehlern führt. Sowohl für Fehler in der Anforderungsdefinition als auch im Softwaredesign kommen darüber hinaus vielfach Kosten- oder Zeitdruck in Frage.

Regressionsbug oder kurz Regression ist ein Fehler, der in einer früheren Programmversion bereits behoben wurde, der aber in einer späteren Programmversion wieder auftaucht.

Fehler im Bedienkonzept. Das Programm verhält sich anders als es einzelne oder viele Anwender erwarten, obwohl es technisch an sich fehlerfrei arbeitet.

So genannte Bug-Tracker (wie Bugzilla oder Mantis) dienen der Erfassung und Dokumentation von Fehlerberichten. Daneben nehmen sie auch Verbesserungsvorschläge und Wünsche der Nutzer oder allgemeine Vorgänge auf. Bei manchen Projekten spricht man dann zum Beispiel von Metabugs, wo ein Bug ein Element einer Aufgabenliste darstellt. Bei einigen Projekten spricht man stattdessen von „Issues“ (Angelegenheiten), da sich dieser Ausdruck nicht auf Programmfehler beschränkt.

[Bearbeiten] Vermeidung und Behebung von Programmfehlern

Generell gilt der Leitsatz: Je früher in einem Entwicklungsprozess der Fehler auftritt und je später er entdeckt wird, umso aufwendiger wird es, den Fehler zu beheben.

[Bearbeiten] Während der Planung

Am wichtigsten ist eine gute und geeignete Planung des Entwicklungsprozesses. Hierfür gibt es bereits etliche Prozessmodelle, aus denen ein geeignetes ausgewählt werden kann.

[Bearbeiten] In der Analysephase

Ein Problem ist, dass die Korrektheit eines Programms nur gegen eine entsprechend formalisierte Spezifikation bewiesen werden kann. Eine solche Spezifikation zu erstellen kann jedoch im Einzelfall ähnlich kompliziert und fehlerträchtig sein, wie die Programmierung des Programms selbst.

Auch die Entwicklung immer abstrakterer Programmierparadigmen und Programmierstile wie die objektorientierte Programmierung, Design By Contract und die aspektorientierte Programmierung dienen unter anderem der Fehlervermeidung und Vereinfachung der Fehlersuche. Aus den zur Verfügung stehenden Techniken für das Problem ist eine geeignete auszuwählen. Ein wichtiger Punkt hierbei ist aber auch, dass für das jeweilige Paradigma erfahrene Programmierer zur Verfügung stehen müssen, sonst entsteht oft der gegenteilige Effekt.

Ferner ist es sehr nützlich, von den Entwicklungswerkzeugen möglichst viele Aufgaben der Fehlervermeidung zuverlässig und automatisch erledigen zu lassen. Dies betrifft zum einen bereits Kontrollen wie Sichtbarkeitsregeln und Typsicherheit, sowie die Vermeidung von Zirkelbezügen, die bereits vor der Übersetzung von Programmen vom Compiler übernommen werden können, aber auch Kontrollen, die erst zur Laufzeit durchgeführt werden können, wie zum Beispiel Indexprüfung bei Datenfeldern oder Typprüfung bei Objekten der objektorientierten Programmierung.

[Bearbeiten] In der Designphase

Softwareexperten sind sich darüber einig, dass praktisch jedes nicht-triviale Programm Fehler enthält. Deshalb wurden Techniken entwickelt, mit Fehlern innerhalb von Programmen tolerant umzugehen. Zu diesen Techniken gehören defensives Programmieren, Ausnahmebehandlung, Redundanz und die Überwachung von Programmen (z. B. durch Watchdog-timer) sowie die Plausibilisierung des Programmes während der Entwicklung und der Daten während des Programmablaufs.

[Bearbeiten] Bei der Programmierung

Darüber hinaus wird eine Reihe fortgeschrittener Anwendungen angeboten, die entweder den Quellcode oder den Binärcode analysieren und versuchen, häufig gemachte Fehler automatisiert zu finden. In diese Kategorie fallen etwa Programme zur Ausführungsüberwachung, die üblicherweise fehlerhafte Speicherzugriffe und Speicherlecks zuverlässig aufspüren. Beispiele sind das frei erhältliche Tool Valgrind und das kommerzielle Purify. Eine weitere Kategorie von Prüfprogrammen umfasst Anwendungen, die Quell- oder Binärcode statisch analysieren und etwa nicht geschlossene Ressourcen und andere Probleme auffinden und melden können. Darunter fallen etwa Findbugs, Lint und Splint.

[Bearbeiten] Beim Testen

Es ist durchaus sinnvoll, dass der Test vor dem eigentlichen Programm entwickelt wird. Damit wird erreicht, dass nicht ein Test geschrieben wird der zu dem bereits geschriebenen Programm passt. Dies kann durch Ermittlung von Testfällen anhand der Spezifikation bereits während der Analyse- bzw. Designphase erfolgen. Die Ermittlung von Testfällen in diesem frühen Stadium der Softwareentwicklung ermöglicht zudem die Prüfung der Anforderungen an das Programm auf Testbarkeit und Vollständigkeit. Die anhand der Spezifikation ermittelten Testfälle stellen die Basis für die Abnahmetests und können kontinuierlich über den gesamten Entwicklungsprozess verfeinert werden.

Manche Softwareanbieter führen Testphasen teilweise öffentlich durch und geben Betaversionen heraus, um die unvorhersehbar vielfältigen Nutzungsbedingungen verschiedener Anwender durch diese selbst testen und kommentieren zu lassen. Man nennt dies auch scherzhaft „Bananensoftware“, weil sie „erst beim Kunden reift“. Diese Bezeichnung wird ebenfalls oft abwertend gebraucht um die geringe Wertschätzung zu früher Vermarktung ungenügend entwickelter bzw. schlecht getester Software zum Ausdruck zu bringen.

[Bearbeiten] Fehlerfreiheit

In Spezialfällen ist ein Beweis der Fehlerfreiheit eines Programms möglich. Insbesondere in Bereichen, in denen der Einsatz von Software mit hohen finanziellen, wirtschaftlichen oder menschlichen Risiken verbunden ist, wie z. B. bei militärisch oder medizinisch genutzter Software oder in der Luft- und Raumfahrt, verwendet man zudem eine (formale) Verifizierung genannte Methode, bei der die Korrektheit einer Software formal-mathematisch nachgewiesen wird. Dieser Methode sind allerdings wegen des enormen Aufwands enge Grenzen gesetzt und sie ist daher bei komplexen Programmen praktisch unmöglich durchzuführen (siehe auch Berechenbarkeit). Allerdings gibt es mittlerweile Werkzeuge, die diesen Nachweis zumindest für Teilbereiche (Laufzeitfehler) schnell und zuverlässig erbringen können (PolySpace Verifier von The MathWorks, Coverity Prevent).

Neben der mathematischen Verifizierung gibt es noch eine praxistaugliche Form der Verifizierung, die durch die Qualitätsmanagement-Norm ISO 9000 beschrieben wird. Bei ihr wird nur dann ein Fehler konstatiert, wenn eine Anforderung nicht erfüllt ist. Umgekehrt kann demnach ein Arbeitsergebnis (und damit auch Software) als fehlerfrei bezeichnet werden, wenn es nachweisbar alle Anforderungen erfüllt. Die Erfüllung einer Anforderung wird dabei durch Tests festgestellt. Wenn alle Tests das erwartete Ergebnis bringen, ist eine Anforderung erfüllt.

[Bearbeiten] Folgen von Programmfehlern

Die Folgen eines Programmfehlers können außerordentlich sein:

1962 führte ein fehlender Bindestrich in einem Fortran-Programm zum Verlust der Venus-Sonde Mariner 1.
1982 stürzte ein Prototyp des F117 ab, da bei der Programmierung die Steuerung des Höhenruders mit der des Seitenruders vertauscht worden war.
Zwischen 1985 und 1987 gab es mehrere Unfälle mit dem medizinischen Bestrahlungsgerät Therac-25. Infolge einer Überdosis, die durch fehlerhafte Programmierung und fehlende Sicherungsmaßnahmen verursacht wurde, mussten Organe entfernt werden, drei Patienten verstarben.
Am 25. Februar 1991 verfehlte eine Patriot-Rakete in Saudi-Arabien wegen eines Register überlaufs eine Scud-Rakete, und diese zerstörte daraufhin eine Armee baracke, wobei es zu 28 Toten kam^[2].
Am 12. März 1995 kam es wegen eines um wenige Byte zu klein bemessenen Stapelspeichers in der Software eines Hamburger Stellwerks, bei dem auch das Ersatzsystem aus Sicherheitsgründen abgeschaltet wurde, zu massiven Verzögerungen im bundesweiten Zugverkehr^[3].
Am 4. Juni 1996 wurde der Prototyp der Ariane-5-Rakete der Europäischen Raumfahrtbehörde eine Minute nach dem Start in vier Kilometern Höhe gesprengt, weil der Programmcode, der von der Ariane 4 übernommen worden war und nur für einen (von der Ariane 4 nicht überschreitbaren) Bereich funktionierte, die Steuersysteme zum Erliegen brachte, als eben dieser Bereich von der Ariane 5 überschritten wurde. Dabei war es zu einem Fehler bei einer Typumwandlung gekommen^[4], dessen Auftreten durch die verwendete Programmiersprache Ada eigentlich hätte entdeckt und behandelt werden können. Diese Sicherheitsfunktionalität ließen die Verantwortlichen jedoch abgeschaltet.
1999 verpasste die NASA-Sonde Mars Climate Orbiter den Landeanflug auf den Mars, weil die Programmierer das falsche Maßsystem verwendeten - Pfund x Sekunde statt Newton x Sekunde. Die NASA verlor dadurch die Sonde.
Zum Jahreswechsel 1999 / 2000 kam es in vielen Programmen zum Jahr-2000-Problem.
2002 schalteten sich Siemens-Mobiltelefone im April bei Aufruf der Kalenderfunktion ab. Bekannt ist der Fehler auch als Aprilbug. Als Folge könnte angesehen werden, dass der Mobiltelefonhersteller von dem Nutzen einer benutzergesteuerten Software-Aktualisierung überzeugt wurde.
Bei Toll Collect kam es 2003^[5] unter anderem wegen der fehlenden Kompatibilität von Softwaremodulen zu drastischen Verzögerungen mit Vertragsstrafen und Einnahmeausfällen in Milliardenhöhe.
Ende 2004 kam es bei der Bundesagentur für Arbeit wegen eines Programmierfehlers bei der Bank-Überweisung zur Verzögerung von Auszahlungen^[6].
Im November 2005 war es an der Tokioter Börse wegen des Ausfalls einer Software stundenlang nicht möglich, Handel zu betreiben^[7].
2007 kam es in Österreich bei der Umstellung auf digitales terrestrisches Fernsehen zu Problemen in rund 30.000 Haushalten, weil Software im Receiver fehlerhaft war^[8].
Oktober 2007 kamen 10 Personen der südafrikanischen Armee aufgrund eines Programmfehlers in einem vollautomatisierten 35-mm Flak-Geschütz ums Leben^[9].
In der Nacht vom 29. zum 30. Oktober 2007 kam es bei der Deutschen Telekom zu bundesweiten Ausfällen und Fehlverbindungen bei Sprachdiensten im Kommunikationssystem, weil eine aktualisierte Server-Software fehlerhaft war. Das System konnte erst nach mehreren Stunden durch die Installation der alten Software wieder zum Laufen gebracht werden^[10]^[11].

[Bearbeiten] Reproduzierbarkeit von Programmfehlern

Manche Programmfehler sind nur äußerst schwer oder gar nicht zuverlässig reproduzierbar. Bei der Wiederholung eines zuvor gescheiterten Vorgangs unter scheinbar unveränderten Bedingungen ist die Wahrscheinlichkeit hoch, dass sich diese Fehler nicht erneut äußern. Es gibt zwei mögliche Gründe für dieses Verhalten: Zum einen kann es zu Verzögerungen zwischen der Fehleraktivierung und dem letztlich auftretenden Problem beispielsweise einem Programmabsturz kommen, welche die tatsächliche Ursache verschleiern und deren Identifikation erschweren. Zum anderen können andere Elemente des Softwaresystems (Hardware, Betriebssystem, andere Programme) das Verhalten der Fehler in dem betrachteten Programm beeinflussen. Ein Beispiel hierfür sind Fehler, die in nebenläufigen Umgebungen mit mangelnder Synchronisation (genauer: Sequentialisierung) auftreten. Wegen der hieraus folgenden Wettlaufsituationen (Race Conditions) können die Prozesse in einer Reihenfolge abgearbeitet werden, welche zu einem Laufzeitfehler führt. Bei einer Wiederholung der gleichen Aktion ist es möglich, dass die Reihenfolge der Prozesse unterschiedlich ist und kein Problem auftritt.

[Bearbeiten] Mandelbug

Ein Programmfehler, dessen Ursachen - in mindestens einer der beschriebenen Formen - so komplex sind, dass sein Verhalten chaotisch oder gar nichtdeterministisch erscheint, wird in Anspielung auf den Mathematiker Benoît Mandelbrot als „Mandelbug“ bezeichnet.^[12]

[Bearbeiten] Heisenbug

Eine Untergruppe von Mandelbugs sind Programmfehler, die ihr Verhalten verändern, wenn man versucht, sie (zum Beispiel mithilfe eines Debuggers) im Programmcode aufzuspüren. Eine mögliche Ursache für eine solche Verhaltensänderung ist, dass der Einsatz eines Analysewerkzeuges die Rahmenbedingungen (insbesondere das zeitliche Verhalten des Softwaresystems) beeinflussen und somit das Auftreten eines Fehlers verhindern kann. Im Programmiererjargon spricht man dabei manchmal scherzhaft von „Heisenbug“, in Anlehnung an Werner Heisenbergs Unschärferelation.^[13]

[Bearbeiten] Bohrbug

Das komplementäre Antonym zu Mandelbug ist „Bohrbug“, was für einen Fehler steht, der sich unter bestimmten, einfach zu fassenden Bedingungen zuverlässig äußert und deshalb - analog zu Niels Bohrs Atommodell - vergleichsweise einfach zu verstehen ist.^[14] ^[15]

[Bearbeiten] Schroedinbug

Ein Programmfehler, der sich bis zu seinem Auffinden im Quellcode noch nie bemerkbar gemacht hat, wird als Schroedinbug bezeichnet (in Anlehnung an Schrödingers Katze des österreichischen Physikers Schrödinger).^[16]

[Bearbeiten] Siehe auch

[Bearbeiten] Literatur

William E. Perry: Software Testen, Mitp-Verlag, November 2002, ISBN 3826608879
Elfriede Dustin, Jeff Rashka, John Paul: Software automatisch testen, Springer, Berlin, Januar 2001, ISBN 3540676392
Cem Kaner, Jack Falk, Hung Q. Nguyen: Testing Computer Software, John Wiley & Sons, Juni 1999, ISBN 0471358460

[Bearbeiten] Einzelnachweise

[Bearbeiten] Weblinks

Über die Auswirkungen größerer Softwarefehler
Fighting bugs: Remove, retry, replicate, and rejuvenate. IEEE Computer 40(2):107-109, Februar 2007 (Englisch): Eine Darstellung von „Bohrbugs“, „Mandelbugs“, „Heisenbugs“ und „aging-related bugs“, sowie der jeweils geeigneten Strategien zur Bekämpfung dieser Programmfehler.
Heisenbugs and Bohrbugs: Why are they different? (PDF, Englisch): Dieses Positionspapier diskutiert tatsächlich die Unterscheidung zwischen „Bohrbugs“ und „Mandelbugs“, der Begriff „Heisenbug“ wird zu weit gefasst.
Blutseuche in World of Warcraft

Kategorien: Programmierung | Sicherheitslücke

See also ebooksgratis.com: no banners, no cookies, totally FREE.