ABOUT Visual Basic Programmieren Programmierung Download Downloads Tips & Tricks Tipps & Tricks Know-How Praxis VB VBA Visual Basic for Applications VBS VBScript Scripting Windows ActiveX COM OLE API ComputerPC Microsoft Office Microsoft Office 97 Office 2000 Access Word Winword Excel Outlook Addins ASP Active Server Pages COMAddIns ActiveX-Controls OCX UserControl UserDocument Komponenten DLL EXE
Diese Seite wurde zuletzt aktualisiert am 25.05.2000

Diese Seite wurde zuletzt aktualisiert am 25.05.2000
Aktuell im ABOUT Visual Basic-MagazinGrundlagenwissen und TechnologienKnow How, Tipps und Tricks rund um Visual BasicActiveX-Komponenten, Controls, Klassen und mehr...AddIns für die Visual Basic-IDE und die VBA-IDEVBA-Programmierung in MS-Office und anderen AnwendungenScripting-Praxis für den Windows Scripting Host und das Scripting-ControlTools, Komponenten und Dienstleistungen des MarktesRessourcen für Programmierer (Bücher, Job-Börse)Dies&Das...

Themen und Stichwörter im ABOUT Visual Basic-Magazin
Code, Beispiele, Komponenten, Tools im Überblick, Shareware, Freeware
Ihre Service-Seite, Termine, Job-Börse
Melden Sie sich an, um in den vollen Genuss des ABOUT Visual Basic-Magazins zu kommen!
Informationen zum ABOUT Visual Basic-Magazin, Kontakt und Impressum

Zurück...

Teil 2

Zurück...

Von Martin Szugat mailto:ms_bugtrapper2@aboutvb.de

Der BugTrapper 3.0 von MuTek Solutions ist ein innovatives und bisher einzigartiges Werkzeug, mit dem Sie Programmfehler auf dem Rechners des Anwenders aufspüren können. Mit dem zugehörigen BugTrapper Agent zeichnen Sie die Ausführung Ihrer Anwendung beim Kunden auf und im Falle eines Programmfehlers können Sie diese Aufzeichnung am heimischen Entwicklungsrechner im BugTrapper abspielen. Statt den Fehler umständlich zu reproduzieren und die Ausführung Schritt für Schritt im Debugger zu verfolgen, bewegen Sie sich im BugTrapper von der Absturzstelle zurück zu der fehlerhaften Stelle im Quellcode. Für den Einsatz des BugTrappers sind weder Änderungen am Quellcode noch identische Umgebungen bei den Anwendern und den Entwicklern notwendig.

Kammerjäger und Wanzen

Trotz komfortabler Debugger, trotz leistungsfähiger Syntax-Checker und trotz automatischer Testwerkzeuge bleiben viele Codierungsfehler unerkannt und treten erst beim Anwender in Erscheinung, meistens in Form von Programmabstürzen. Als Entwickler stehen Sie stets unter Termindruck, was zur Folge hat, dass Sie kaum in der Lage sind, sämtliche Ausführungspfade, Situationen und Konstellationen Ihres Programms zu testen. Auch die automatischen Debugging-Werkzeuge, die selbstständig Fehler aufspüren und teilweise beheben, können nur bedingt Abhilfe schaffen. Denn sie erkennen zumeist nur beliebte Programmiererfehler oder einfache Syntaxfehler, jedoch keine Unzulänglichkeiten in der Semantik eines Programms. Ebenso wenig Hilfe versprechen Testwerkzeuge, welche die Interaktion eines Anwenders mit dem Programm simulieren und die erfolgreiche oder eben fehlgeschlagene Ausführung protokollieren. Zwar werden diese Programme immer intelligenter, doch kein Programm wird wahrscheinlich jemals so "dumm" sein wie der DAU - der berüchtigte "Dümmste Anzunehmende User". Schließlich helfen Alpha- und Beta-Testphasen zwar die Anzahl der Bugs zu minimieren, dennoch werden mit hoher Wahrscheinlichkeit einige der unliebsamen Krabbeltiere den Weg in die endgültige Version des Programms finden.

Programmfehler können einen nicht unerheblichen Schaden verursachen, sowohl auf Seiten der Anwender als auch auf Seiten der Entwickler. Die betroffenen Anwender werden in ihrer Produktivität gehemmt und im schlimmsten Fall haben die Fehler Datenverluste zur Folge. Der Softwarehersteller wird mit einem Imageverlust bestraft und muss, bei unzureichender rechtlicher Absicherung, womöglich mit Schadensersatzklagen oder zumindest mit Preisminderung rechnen. Zusätzlich kostet die Lokalisierung der fehlerhaften Stellen im Quellcode Zeit und folglich viel Geld. Denn nicht immer lassen sich die Programmfehler mit wenig Aufwand in der Entwicklungsumgebung nachvollziehen oder gar reproduzieren. Ein Grund hierfür sind beispielsweise unterschiedliche Umgebungen bei den Anwendern und den Entwicklern. So können unterschiedliche Versionsnummern bei den System-DLLs oder die installierten Service-Packs und -Patches mitunter erhebliche Auswirkungen auf das Laufzeitverhalten eines Programms ausüben. Des weiteren werden Anwendungen meist in einem Debug-Build getestet und in einem Release-Build ausgeliefert. Zwischen dem Debug- und dem Release-Build einer Anwendung existieren schon alleine auf Grund der Debuginformationen im Quellcode erhebliche Unterschiede.

Als Visual Basic-Entwickler sollten Sie sich der Tatsache bewusst sein, dass zwischen der Ausführung einer Anwendung im Debug-Modus und im kompilierten Zustand Unterschiede bestehen, die in den meisten Fällen nicht relevant sind, dennoch in einigen Situationen unterschiedliche Ergebnisse produzieren können. Ein weiterer Grund, der die Nachahmung von Programmfehlern erschwert oder gar verhindert, betrifft die Datenbestände, die das Programm verarbeitet. Erstens ist der Anwender nicht immer bereit, seine Datenbestände für Tests zur Verfügung zu stellen, da diese womöglich sensible Daten beinhalten. Zweitens können die Datenbestände derart umfangreich sein, dass der Aufwand und die Kosten zu hoch sind, diese zu replizieren und in die Entwicklungsumgebung einzuspeisen. Der Faktor Mensch kann ebenfalls ein Hindernis darstellen, denn nicht immer wissen die Anwender, welche Aktionen sie tatsächlich ausgeführt haben, die zum Absturz oder zum Fehlverhalten des Programms geführt haben. Ebenso spielt der Zufall eine Rolle. So können Bugs nur sporadisch auftreten und lassen sich folglich nur schwer einfangen.

Herkömmlicherweise gibt es mehrere Möglichkeiten zur Reproduktion von Fehlern: das Testen der Anwendung vor Ort beim Anwender, das Testen der Anwendung über eine Remote-Verbindung und das Instrumentieren des Quellcodes mit Protokoll- und Testfunktionen. Der direkte Besuch beim Kunden ist ausschließlich im Falle von Individualsoftware und bei einem begrenzten Kundenstamm möglich. Die Kosten hierfür sind hoch und Zeit geht ebenfalls verloren. Auch der Kunde wird es kaum gerne sehen, wenn Fremdlinge ihre Testwerkzeuge auf den heimischen Rechnern installieren und diese für Tage blockieren. Die direkte Einwahl beim Kunden ist gleichermaßen nur in wenigen Fällen möglich und verursacht zusätzliche Kosten, trotz Internet und sinkender Telefongebühren. Die Stabilität und Sicherheit der Verbindung ist ebenso zu bedenken. Das Instrumentieren von Quellcode, also das Einfügen von Anweisungen zum Protokollieren und Testen der Ausführung des Programms, erhöht den Implementierungsaufwand und wirkt sich negativ auf die Performance der Programmausführung aus. Außerdem birgt diese Instrumentierung wiederum ein zusätzliches Fehlerpotential in sich.

Das grundlegende Problem resultiert aus der Art und Weise, wie herkömmliche Werkzeuge zum Testen von Software arbeiten, und in welcher Phase des Entwicklungsprozesses diese Werkzeuge eingesetzt werden. Debugger ermöglichen es, das Verhalten eines Programms zur Laufzeit zu überwachen, jedoch sind sie abhängig vom Quellcode des Programms und der Umgebung, in welcher das Programm ausgeführt wird. Solange sich ein Programm in der Implementierungs- oder Testphase befindet, erfüllen die Debugger ihren Zweck. Tritt ein Bug hingegen erst beim Anwender auf, ist der Nutzen eines Debuggers nur sehr gering. Automatische Testwerkzeuge, die eine Anwendung selbstständig mit Eingaben versehen und die hieraus resultierenden Ausgaben protokollieren, werden vor allem in der Testphase und zur Qualitätssicherung eingesetzt. Hier fehlt allerdings meistens die Verbindung zum Quellcode und es besteht weiterhin die Abhängigkeit von der Testumgebung. Es fehlt also bisweilen eine einfache Methode, oder vielmehr ein leistungsfähiges Werkzeug, um Bugs beim Anwender aufzuspüren oder aufzuzeichnen.

 

Teil 2

Teil 2

Markt


MuTek Solutions GmbH
Weitere Nachrichten
MuTek Solutions GmbH - www.mutek-solutions.de

Schnellsuche



Zum Seitenanfang

Copyright © 1999 - 2017 Harald M. Genauck, ip-pro gmbh  /  Impressum

Zum Seitenanfang

Zurück...

Zurück...

Download Internet Explorer