Tests / Qualitätssicherung - aber wie?

[Andreas Korthaus]

Hallo!

Ich bin jetzt schon so einige Monate an einem PHP-Projekt, und werde das bald fertigstellen. Jetzt mache ich mir Gedanken über eine Quzalitätssicherung, bzw. über ein systematisches Testen der Software, um möglichst viele Fehler - die sicher vorhanden sind - aufzuspüren.

Nur wie stelle ich das an? Habe da Sachen gehört dass das Testen eines Programms oft 40% und mehr der kompletten Entwicklungszeit in Anspruch nimmt - nur was macht man in der ganzen Zeit? Was ich mache ist halt manuell testen, halt dass ich und andere "beta-Tester" das "Programm" mit möglichst realitätsnahen und möglichst komplexen Daten füttern, und wenn Fehler auftreten kommt das dann in einen Bug-Tracker wie hier im Forum, und wird behoben.

Zu dem (Web-)Projekt, wie gesagt PHP-basiert, ca. 200 PHP-Dateien mit insgesamt ca. 100.000 Zeilen Code, zur Zeit verwende ich noch MySQL als DB, soll aber durch PEAR::DB mit PostgreSQL, Oracle, MSSQL... laufen(da wird mir noch so einiges blühen...). Ich verwende halt ein paar der PEAR-Packages und Smarty als Template-Engine. Ganz grob zur Architektur:
Es gibt ein "Request-Script", an dieses werden alle HTTP-Requests geleitet, dieses läd dann alle notwendigen Libs, je nach Konfiguration verschiedene Plugins, sorgt für Authentifizierung und läd entsprechend dem HTTP-Request ein Script welches dann die eigentliche Aktion durchführt und am Ende ggfs. mit den Templates eine Ausgabe erzeugt.
Es gibt 2 verschiedene Rechte-Systeme, einmal Benutzergruppen(zusammengehörige Abteilungen wo alle Benuitzer denselben Datenbestand haben), und dann gibt es noch verschiedene Benutzertypen, wie Admin, Gast...

Soviel zu der Anwendung. Ich habe gelesen, dass es bei großen Projekten richtige Programme geschrieben werden, die die zu testende Software dann halt auf Herz und Nieren überprüfen - nur wie muss ich mir sowas vorstellen? Geht sowas überhaupt mit einem web-basierten PHP-Projekt? Wie macht Ihr das? Oder muss man sowas direkt in den Code integrierern? Was ich bisher leider erst in Ansätzen gemacht habe aber noch fertig stellen will, ist ein globales Error-Handling mittels PEAR.

Hierbei unterscheide ich nach folgenden Fehlern:

Fehlerhafte Benutzerangaben
Fehlerhafte HTTP-Requests
Fehlerhafte DB-Abfragen
PHP-Fehler

Die werden alle mit möglichst vielen Angaben geloggt. Dann kann ich den Fehler evtl. reproduzieren.

Was könnte man noch machen? Wie kann ich qualitativ hochwertigen Code sicherstellen? Wie kann ich Code testen?

Hätte die Verwendung eines Applikations-Servers + Java hier irgendwelche Vorteile?

Viele Grüße
Andreas

[Pöt]

Hallo Andreas!

Weiterhelfen groß kann ich nicht, aber Du scheinst ein wichtiges Gebiet bei der Fehlersuche vergessen zu haben: Mutwilligkeit und Sabotage. Also nicht nur die Funktionen mit realitätnahen Daten testen, sondern ebenso mit höchst unsinnigen. Etwa Datenfelder "überfüllen" oder mit Hexdaten und mit Steuersequenzen, oder 80x hintereinander vor und zurück klicken (gibts ein Überlauf in irgeneinem pointer etc?); was passiert, wenn man der Aufruf von Funktionen/Modulen von außen kommt, wenn Parameter per Hand verbogen werden; sind Zugriffe auf die DB von außen geschützt? auch mit alten Hexeditoren a la Norton? usw usf!

Ich grüße Dich!

Pöt

[Andreas Korthaus]

Hallo!

Weiterhelfen groß kann ich nicht, aber Du scheinst ein wichtiges Gebiet bei der Fehlersuche vergessen zu haben: Mutwilligkeit und Sabotage. Also nicht nur die Funktionen mit realitätnahen Daten testen, sondern ebenso mit höchst unsinnigen. Etwa Datenfelder "überfüllen" oder mit Hexdaten und mit Steuersequenzen, oder 80x hintereinander vor und zurück klicken (gibts ein Überlauf in irgeneinem pointer etc?); was passiert, wenn man der Aufruf von Funktionen/Modulen von außen kommt, wenn Parameter per Hand verbogen werden; sind Zugriffe auf die DB von außen geschützt? auch mit alten Hexeditoren a la Norton? usw usf!

Vergessen habe ich das nicht. Das Web-Projekt ist nur über den Webserver erreichnbar, DB-Server ist nur intern erreichbar. Ich prüfe also immer wenn ich Parameter erwarte, ob diese den "Erwartungen" entsprechen. Nur das passiert so oft - wie soll ich die alle Testen? Und was soll ich dann testen? Was kann passieren?

Entweder erwarte ich einen von x verschiedenen Werten die genau definiert sind, das kann ich prüfen. Oder ich erwarte z.B. eine Zahl oder einen String mit max. x Stellen, oder einen Array mit entsprechenden Elementen.

Vor- und Zurück, auch ein interessanter Punkt, normalerweise schicke ich Formulare immer an "sich selbst", und überegebe am Ende die "alten" Parameter als GET-Parameter, so dass man normal hin- und zurück klicken kann. Nur ist das ja auch Broweser-spezifisch, die Reagieren ja nicht unbedingt alle gleich... ein interesanter Punkt den ich mir nochmal genauer ansehen werde.

Mit einem Hexeditor kann man wohl nicht wirklich viel ausrichten, da die Kommunikation eh nur über HTTP läuft und die Clients nur HTML-Ausgaben zu sehen bekommen.

Noch eine Sache - was macht man bei auftretenden Fehlern mit dem User? Gut, wenn es Eingabe-Fehler sind muss er halt korrigieren. Bei DB-Fehlern sieht es schon anders aus, vielleicht sollte man hier noch nach INSERTS/UPDATES und SELECTS unterscheiden?

Viele Grüße
Andreas

[Freya]

Hi,
Ich habe das ein wenig anders gelernt, und zwar nicht mit A-C Tests sondern als 'blackbox' und 'whitebox' testing. Dabei ist wichtig, daß jeder der testet - auch der normale Benutzer - jeden Schritt, den er macht, festhält und Dir dann weiterreicht, so dass nachvollziehbar ist, wo der Fehler auftritt und man den nochmal zu sehen bekommt.
Man kann einfach 'los testen' und so relativ viele Fehler finden, aber besser ist es, erstmal mögliche Situationen vorher schriftlich festzuhalten und dann zu testen, ob es klappt oder ob dabei Fehler auftreten. Je genauer man diese Testanweisungen schreibt und von anderen durchführen lässt, desto bessere Ergebnisse bekommt man. Ausserdem kommt man später nicht durcheinander, was man schon versucht hat und was nicht und es ist egal wer testet. Hiermit kann man nämlich auch Fehler isolieren, die auf Grund unterschiedlicher Software z.B. Betriebssystem oder Browser auftreten.
Ansonsten wie oben gesagt, Testscripts schreiben und jedes Modul einzeln testen (sofern möglich).

Tschüss,
Freya

[Richard Voß]

Allgemein lässt sich wenig formulieren. Ich schreibe zu jedem Modul(ich verwende fast nur Perl) sofort einen Test in einem Testverzeichnis (t/), den ich per :vsplit immer rechts neben dem eigentlichen Code habe und über F9 schlagartig durchlaufen kann. Dadurch kann ich auch tesgetriebene Entwicklung (http://www.wikiservice.at/dse/wiki.cgi?TestgetriebeneEntwicklung) betreiben.

D.h. von vorn herein sollte alles, was du schreibst, modularisiert sein, in Bibliotheken und Klassen. Solche lassen sich dann auch einzeln auf Herz und Nieren testen. Afaik gibt es die Möglichkeit PHP auch auf der Kommandozeile zu interpretieren, also kannst du es im Grunde auch gleich dort beim Entwickeln testen. Ansonsten schreib' halt ein einfaches Testprogramm, das auf dem Webserver die jeweilige Komponente prüft. Ob es so tolle Testframeworks wie Test::More für Perl auch für PHP gibt, weiß ich nicht.

Das "Ganze" Projekt läuft, wenn die einzelnen Teile tun, was sie sollen. Fehler, die dazwischen liegen, können dann durch Betatetester gefunden werden. Die Ganzen Kleinigkeiten in den Komponenten müssen im Beta-Zustand schon eliminiert sein, weil man sonst gar keine lauffähige Betaphase bekommt, sondern nur hunderte Fehler.

Deswegen lohnt es sich spätestens beim Testen, _korrekt_ modularisiert zu haben, denn wenn alles unübersichtlich ineinander verzahnt ist, lassen sich keine wirkichen Test schreiben, sondern nur Stichproben.

Ich hoffe also, deine 200 PHP-Dateien lassen sich alle isoliert testen, d.h. du schreibst 200 Tests, die jeweils nur die korrekte Funktionalität einer Datei prüfen. Wenn die Dateien so beschaffen sind, dass sie einen komplizierten Kontext brauchen, hast du ein Problem, dann musst du diesen Kontext nämlich im test simulieren.

Warum du auf Komponentenebene testen solltest, lässt sich mathematisch begründen:

Wenn jede Komponente n eine Anzahl potentieller Fehler a(n) hat (jede Funktion/Methode enthält mindestens einen potentiellen Fehler), dann ist die Anzahl der zu testenden Fälle für die Komponente a(n), alle Komponenten veruraschen dann also die Summe aller a(n) an Tests.

Testet man nur das komplette System, dürfte die Anzahl der Tests schlimmstenfalls das Produkt aller a(n) sein, wenn nämlich jede Komponente auf jede zugreift. Da das selten der Fall ist, ist auch die Testanzahl nicht ganz so hoch, aber niemals so gering wie beim Komponententest. Die Testfälle werden mehr, entfernen sich aber nicht voneinander, d.h. sie unterscheiden sich untereinander kaum und es werden garantiert welche übersehen.

Zum konkreten Testen in PHP weiß ich nichts. In Perl gibt es eine Konvention über die Ausgabe von Testprogrammen. Das sieht etwa so aus (schreibe ich gerade aktuell):

1..43
ok 1 - use Pie::Object;
ok 2 - Pie::Parent->create
ok 3 - The object isa Pie::Parent
ok 4 - The object isa Pie::Object
ok 5 - Pie::Object->new(parent)
ok 6 - The object isa Pie::Object
[...]
ok 38 - o1->push_stack
ok 39 - o2->push_stack
ok 40 - o1->run_stack walks up
ok 41 - ... in correct order (0 1 2 3 4 5)vs(0-5)
ok 42 - o2->run_stack walks up twice
ok 43 - ... in correct order (0 1 2 3 4 5 6 7 8 9 10 11 12)vs(0-12)

Diese Ausgabe wird dann wiederum von Programmen ausgewertet, die nur noch die Testinformationen von gescheiterten Tests ausgeben. So kann exakt festgestellt werden, ob und welche Test scheitern.
Das Testpogramm selbst sieht so aus:

#!/usr/bin/perl
use strict;
use warnings;

use Test::More qw/tests 43/;
use Test::Exception;

our $CLASS;

BEGIN{
        $CLASS = 'Pie::Object';
        use_ok($CLASS)
                or die "use $CLASS failed";
}

ok(
        my $parent = Pie::Parent->create(),
        'Pie::Parent->create' );
isa_ok( $parent , 'Pie::Parent' );
isa_ok( $parent , 'Pie::Object' );

[...]

Das waren die ersten 4 von 43.
Es dürfte kaum sehr kompliziert sein, solche Programme auch in PHP zu schreiben.

Es kommt jetzt also darauf an, wie sauber dein Design ist.

[Andreas Korthaus]

Hallo!

Allgemein lässt sich wenig formulieren. Ich schreibe zu jedem Modul(ich verwende fast nur Perl) sofort einen Test in einem Testverzeichnis (t/), den ich per :vsplit immer rechts neben dem eigentlichen Code habe und über F9 schlagartig durchlaufen kann. Dadurch kann ich auch tesgetriebene Entwicklung (http://www.wikiservice.at/dse/wiki.cgi?TestgetriebeneEntwicklung) betreiben.

das hört sich ja mal nett an, aber wie soll das funktionieren? Ich kann mir nicht wirklich vorstellen wie ich ein Modul testen kann. Meinst Du Du schreibst ein Testscript welches das originale Script nachbildet und das Modul einbindet und die Schnittstellen mit allen möglichen Daten füttert und bei Fehlerhafter Rückgabe irgendwas ausgibt? Das wäre ja eine tierische Arbeit!

D.h. von vorn herein sollte alles, was du schreibst, modularisiert sein, in Bibliotheken und Klassen.

Was genau wird eigentlich als Bibliothek bezeichnet - wenn ich mal fragen darf? Ich verwende das immer für Code denn ich wiederverwenden kann, z.B. Klassen wie DB-Abstraktion, Authentifizierung... das ist dann immer eine Klasse in einer Datei die ich dann bei bedarf einbinde - ist das ein Bibliothek?

Ok, eine Klasse lässt sich gut testen. Sagen wir mal ich habe verschiedene Schnittstellen, z.B. für eine Klasse "user". Darin speichere ich alle mögichen Inforamtionen über den aktuellen Benutzer, und stelle Schnittstellen bereit den Benutzernamen zu ändern, Passwort zu ändern, ein bestimmtes Recht zu überprüfen...

Mal ein Beispiel für eine Methode,

function set_username($new) {
    if($db->query('UPDATE...SET username = $new')) {
        return TRUE;
    }
    else {
        return FALSE;
    }
}

Den Benutzernamen kann ich dann mit

$user->set_username('willy');

ändern. Und wie teste ich das jetzt? Was teste ich alles? kann mir das nicht vorstellen. Soll ich testen was ich dem Methode alles für Parameter übergeben kann (Länge 0-100, Array...) nur um zu sehen was passiert...? Das wäre ja irgendwie Quatsch. Eigentlich müsste ich nur
prüfe was vom user kommen könnte, aber das wiederum fange ich ja vorher ab, also was soll ich hier noch groß prüfen? Stehe da irgendwie auf dem Schlauch.

Solche lassen sich dann auch einzeln auf Herz und Nieren testen. Afaik gibt es die Möglichkeit PHP auch auf der Kommandozeile zu interpretieren, also kannst du es im Grunde auch gleich dort beim Entwickeln testen.

sicher, das geht. Aber wie soll ich mir das vorstellen? Ich habe also obige Klasse - was bringt es mir jetzt dieses Script in der Kommandozeile auszuführen? Was soll das Script in der Kommandozeile alles machen?

Ansonsten schreib' halt ein einfaches Testprogramm, das auf dem Webserver die jeweilige Komponente prüft. Ob es so tolle Testframeworks wie Test::More für Perl auch für PHP gibt, weiß ich nicht.

Wäre mir nicht bekannt. Ich habe irgendwi eien Problem mir vorzustellen was man an so einer Komponente so alles prüfen sollte. ich könnte in PHP glaube ich ermitteln was eine Klasse für Methoden und Eigenschaften hat(http://de3.php.net/manual/de/ref.objaggregation.php - wobei, geht erst ab PHP5). Problem ist auch, dass viele Klassen nicht fr sich alleien laufen können, die User-Klasse bekommt z.B. den REMOTE_USER namen übergeben, und macht dann als erstes mal einige DB-Abfragen(mit dem DB-Abstraktions-Modul) um mehr über den aktuellen User zu erfahren und schreibt das in die entsporechenden Eigenschaften. Wäre das also ein unsauberes Design? Aber irgendwo _muss_ ich ja an die User-Daten aus der DB kommen. Aber im prinzip könnte ich das Scipt ja in seiner originalen Umgebung testen, und nur den REMOTE_USER übergeben, dann sollte es ja laufen, nur bleibt die Frage - was genau soll ich dann automatisiert testen?

Deswegen lohnt es sich spätestens beim Testen, _korrekt_ modularisiert zu haben, denn wenn alles unübersichtlich ineinander verzahnt ist, lassen sich keine wirkichen Test schreiben, sondern nur Stichproben.

Ja, ich gebe zu dass ich das nicht 100%ig durchgezogen habe, aber ich finde, dasss wenn ich eine Funktionalität nur an einer Stelle brauche, lohnt es sich nicht wirklich die in eine Modul/Klasse zu packen - Trade-Off Performance vs. Modularität. Heißt dass dann aber auch - schlechter zu testenden Code?

Ich hoffe also, deine 200 PHP-Dateien lassen sich alle isoliert testen, d.h. du schreibst 200 Tests, die jeweils nur die korrekte Funktionalität einer Datei prüfen.

Wenn ich recht überlege sind es keine 200 PHP-Dateien, das waren alle Dateien, mit Templates, JS und CSS, aber es sind sicher über 100.

Wenn die Dateien so beschaffen sind, dass sie einen komplizierten Kontext brauchen, hast du ein Problem, dann musst du diesen Kontext nämlich im test simulieren.

Kann ich nicht den Kontext der original-Umgebung verwenden, oder würde das das Testergebnis evtl. verfälschen?

Zum konkreten Testen in PHP weiß ich nichts. In Perl gibt es eine Konvention über die Ausgabe von Testprogrammen. Das sieht etwa so aus (schreibe ich gerade aktuell):

1..43
ok 1 - use Pie::Object;
ok 2 - Pie::Parent->create
ok 3 - The object isa Pie::Parent
ok 4 - The object isa Pie::Object
ok 5 - Pie::Object->new(parent)
ok 6 - The object isa Pie::Object
[...]
ok 38 - o1->push_stack
ok 39 - o2->push_stack
ok 40 - o1->run_stack walks up
ok 41 - ... in correct order (0 1 2 3 4 5)vs(0-5)
ok 42 - o2->run_stack walks up twice
ok 43 - ... in correct order (0 1 2 3 4 5 6 7 8 9 10 11 12)vs(0-12)

Diese Ausgabe wird dann wiederum von Programmen ausgewertet, die nur noch die Testinformationen von gescheiterten Tests ausgeben. So kann exakt festgestellt werden, ob und welche Test scheitern.

Das wäre wirklich gut...

Das Testpogramm selbst sieht so aus:

#!/usr/bin/perl
use strict;
use warnings;

use Test::More qw/tests 43/;
use Test::Exception;

our $CLASS;

BEGIN {
        $CLASS = 'Pie::Object';
        use_ok($CLASS)
                or die "use $CLASS failed";
}

ok(
        my $parent = Pie::Parent->create(),
        'Pie::Parent->create' );
isa_ok( $parent , 'Pie::Parent' );
isa_ok( $parent , 'Pie::Object' );

[...]

Das waren die ersten 4 von 43.

Es dürfte kaum sehr kompliziert sein, solche Programme auch in PHP zu schreiben.

Sicher nicht, nur verstehe ich das Programm nicht wirklich. Vermutlich daher weil ich das Test-Modul nicht kenne, aber was genau macht das?

BEGIN {

was ist das?

Wo bindest Du denn eine andere Datei an die Du in Pie::Object benutzt?

Also ich vermute, als erstes muss ich die zu testende Date einbinden, dann die Klasse initialisieren, und dann für jede Methode verschiedene Tests überlegen, nur welche?

isa_ok( $parent , 'Pie::Parent' );

Was genau wird denn jetzt getestet? Ich kann mir das irgendwie nicht vorstellen. Prüfst Du nicht einzelnd alle Methoden?

Was ist

ok(

?

Es kommt jetzt also darauf an, wie sauber dein Design ist.

Tja....

Vielen Dank für Deine Anregungen, auch wenn ich da noch nicht wirkich durchblicke ;-)

Viele Grüße
Andreas

[Richard Voß]

Am besten du liest einmal http://www.perldoc.com/perl5.8.0/lib/Test/Tutorial.html, das bezieht sich zwar auf Perl aber es geht ja ums Prinzip.

Im Übrigen _ist_ das viel Arbeit. Deswegen testet man auch nicht am Ende, sondern während der Entwicklung jede neue Funktion, so wachsen die Testprogramme nebenbei. Das gehört zu qualitativer Programmierung dazu und das macht sehr schnell auch Spaß.

Ein Testprogramm bindet die Bibliothek/Klasse ein und ruft die Funktionen/Methoden auf und prüft, ob diese auf korrekte Eingaben korrekte Ergebnisse liefern und ob sie auf Unsinn mit entsprechendem Verhalten reagieren. Eine Bibliothek ist übrigens nichst anderes als ein Haufen von Funktionen, den man einbinden kann, um die Funktionen zu verwenden.

Wenn eine Klasse z.B. auf eine Umgebungsvariable zugreift ist das schon ungünstiges Design. Allerdings kannst du das noch simulieren, indem du eine Umgebungsvariable setzt und dann die Klasse verwendest.

[Antje Hofmann]

Hallo Andreas

Ich bin jetzt schon so einige Monate an einem PHP-Projekt, und werde das bald fertigstellen. Jetzt mache ich mir Gedanken über eine Quzalitätssicherung, bzw. über ein systematisches Testen der Software, um möglichst viele Fehler - die sicher vorhanden sind - aufzuspüren.

Nur wie stelle ich das an?

bei uns in der Firma gibt es eine Abteilung, die nichts anderes macht, als unsere bzw. auch fremde Anwendungen zu testen. Etwa 20% der Entwicklungszeit werden für die Tests benötigt. Entwicklertest sind hier nicht drin enthalten.

Ein Test läuft im Regelfall dreistufig ab.

Test A: der sogenannte Hausfrauentest,

hier sitzen Tester vor der Anwendung, die lediglich das Redaktionshandbuch zur Verfügung haben. Die finden im Regelfall alle Fehler und Probleme, die dir als Entwickler undenkbar scheinen. Die Testszenarien werden mit dem Kunden vereinbart und decken alle standardisierten Fälle ab.

Test B: der Lasttest

hier laufen Scripte, mit denen die Dauerbelastung geprüft wird. Entwickelt werden die Scripte anhand des Redaktionshandbuches, der Feinspezifikation und anhand der zu erwartenden Belastungen. Die finden auch heraus, welche Seiten besonders langsam sind und wir dürfen dann das Rätsel lösen warum.

Test C: der Sicherheitstest
Hier wird die Anwendung auf Sicherheitslücken abgeklopft. Was da genau läuft weiß ich auch nicht, wir kriegen nur die Resultate der Tests und können die einzelnen Testszenarien nicht einsehen.

Grundsätzlich gilt eigentlich, der Test muss immer von anderen ausgeführt werden, da du als Programmierer instinktiv alle Schwachstellen vermeidest.

Wenn ihr kein Testzentrum habt, dann nimm dir irgend jemanden der keine Ahnung von der Anwendung hat und setze den davor. Zumindest in einigen Bereichen wird der Fehler finden, die du nie finden wirst.

Viele Grüße

Antje

[rainer groth]

Hallo,

Test C: der Sicherheitstest
Hier wird die Anwendung auf Sicherheitslücken abgeklopft. Was da genau läuft weiß ich auch nicht, wir kriegen nur die Resultate der Tests und können die einzelnen Testszenarien nicht einsehen.

Dass die Entwickler nur die Ergebnisse einer solchen 'Ueberpruefung' bekommen, macht ja mitunter auch Sinn -
von wegen, dass der Ultra-Cracker ein nur ihm bekanntes Loch gefunden hat...

Aber meistens erinnern mich solche Szenarien eher an Clifford Stolls 'Kuckucksei' - alle tun geheimnisvoll, aber keiner redet.

Ich hatte selbst schon 'die Ehre', solche Tests durch zu fuehren - interessant, welcher Wirbel z.B. um die Tatsache gemacht wurde, dass ein eigentlich zum Erreichen von kostenpflichtigen Porno-Sites geschriebener Referrer halt auch andere Sites 'erreichbar' machte.
(Fuer mich als Person war es natuerlich super: 'Der Mann kennt sich aus !' :-))

ICH faende es grundsaetzlich besser, wenn auch solche 'Test-C'-Ergebnisse regelmaessig zur Verfuegung gestellt wuerden - nachvollziehbar/verifizierbar.
Das wuerde IMHO auch Scharlatanen wie Dr.Kimble endlich einmal das Wasser abgraben.

Wenn ihr kein Testzentrum habt, dann nimm dir irgend jemanden der keine Ahnung von der Anwendung hat und setze den davor. Zumindest in einigen Bereichen wird der Fehler finden, die du nie finden wirst.

...meine bevorzugte Test-Methode: fang Dir irgendwelche Menschen ein, die mit Deinem Produkt klarkommen sollen - das bringt (meistens) grosse Ernuechterung.

gruesse
rainer groth

[Andreas Korthaus]

Hi!

Wenn ihr kein Testzentrum habt, dann nimm dir irgend jemanden der keine Ahnung von der Anwendung hat und setze den davor. Zumindest in einigen Bereichen wird der Fehler finden, die du nie finden wirst.

...meine bevorzugte Test-Methode: fang Dir irgendwelche Menschen ein, die mit Deinem Produkt klarkommen sollen - das bringt (meistens) grosse Ernuechterung.

Ja, das ist sicher notwendig, aber damit finde ich wie gesagt nur einen Teil der Fehler. Ich finde so kaum Fehler durch evtl. fehlerhafte Benutzereingaben(da ich mal davon ausgehe das dort kaum jemand falsche oder manipulierte Angaben macht), oder vielleicht falsche Spalten-Typen... wenn dann nur aus Zufall, aber nicht systematisch.

Viele Grüße
Andreas

[Andreas Korthaus]

Hi Antje!

Nur wie stelle ich das an?

bei uns in der Firma gibt es eine Abteilung, die nichts anderes macht, als unsere bzw. auch fremde Anwendungen zu testen.

Ich wünsche mir auch so eine Abteilung... ;-)

Ein Test läuft im Regelfall dreistufig ab.

Test A: der sogenannte Hausfrauentest,

Das aus Deinem Mund? Aha ;-)

hier sitzen Tester vor der Anwendung, die lediglich das Redaktionshandbuch zur Verfügung haben. Die finden im Regelfall alle Fehler und Probleme, die dir als Entwickler undenkbar scheinen. Die Testszenarien werden mit dem Kunden vereinbart und decken alle standardisierten Fälle ab.

Ja, sowas mache ich auch gerne, da wird auch  immer was gefunden, nur  mache ich das nicht wirklich "systematisch", ich sollte in der Tat mal Szenarien entwerfen, die teilweise ganz "normal" sind, andere möglichst komplex, und das alles möglichst na an dem wie es später im Live-Betrieb verwendet wird.

Test B: der Lasttest

Sowas habe ich noch nicht,

hier laufen Scripte, mit denen die Dauerbelastung geprüft wird.

Das heißt - da die Software ja über HTTP erreichbar ist - schreibe ich ein paar Scripte, lege die auf einen anderen Rechner, am besten nichtmal im gleichen LAN, und lasse möglichst viele Requests auf den Server los, am bestebn von mehreren Standortn aus, und das mit möglichst vielen Daten...

Entwickelt werden die Scripte anhand des Redaktionshandbuches, der Feinspezifikation und anhand der zu erwartenden Belastungen. Die finden auch heraus, welche Seiten besonders langsam sind und wir dürfen dann das Rätsel lösen warum.

Ja, da habe ich auch schon einige gefunden, wo ich mir zum verrecken nicht erklären kann warum die so viel langsamer sind als vergleichbare Scripte...

Test C: der Sicherheitstest
Hier wird die Anwendung auf Sicherheitslücken abgeklopft. Was da genau läuft weiß ich auch nicht, wir kriegen nur die Resultate der Tests und können die einzelnen Testszenarien nicht einsehen.

Nur lässt sich da was automatisieren? Wird wohl nichts anderes übrig bleiben,
1. den kompletten Code durchzusuchen und alle Stellen markieren an denen Rechte geprüft werden müssen
2. "cracker-mäßig" versuchen zugriff auf andere Daten durch manipulation der Request-Parameter zu erhalten, bei Kenntnis des Codes,

nur werden das wohl Stichproben bleiben, gerade wenn ich das selbst mache habe ich Angst durch "Befangenheit" irgendwelche Möglichkeiten zu vergessen, die ich ja schon bei der Programmierung vergessen hatte. Ich glaube das kann nur eine andere Person sinnvoll machen, da hast Du wohl Recht.

Vielen Dank für die Anregungen,

Grüße
Andreas

[Ralf Rapude]

Hallo Andreas,
das Testen von Software ist gerade bei groesseren Projekten sehr wichtig. Da geht man (oder sollte es zumindest) so vor, dass man Code schreibt und parallel dazu auch gleich immer die entsprechenden Tests. Fuer Perls scheints, wenn ich Richard richtig verstanden habe, etwas aehnliches zu geben, wie beim testen von Java Code. Unter Java heisst es JUnit und ist in viele IDEs integriert.
Praktisch siehts da so aus, dass du Testfaelle an Hand von Methoden konstruierst, die deine vorhandene Applikation auf Rueckgabewerte usw. ueberprueft. Dazu werden teilweise automatisch Testmethoden generiert, die du dann nur noch ausfuellen musst. Nach dem Aufruf von JUnit werden die Tests von oben nach unten durchlaufen und es wird eine Art Protokoll ausgegeben, obs an irgendeiner Stelle Probleme gegeben hat und wenn ja, welcher Art die waren.
Ein gutes kurzes und sehr gut nachvollziehbares Tutorial findest du hier:
http://www.frankwestphal.de/UnitTestingmitJUnit.html
Und vielleicht gibts ja auch ein Pendant unter PHP.

Hätte die Verwendung eines Applikations-Servers + Java hier »» »» »» irgendwelche Vorteile?

Auf jeden Fall. PHP habe ich jetzt zwar schon laengere Zeit nicht mehr gemacht und fuer Quickhacks finde ich das auch immer noch ziemlich gut, aber im Vergleich schneidet Java bei mir um Laengen besser ab, besonders wenns um etwas groessere Projekte geht. Zwar kann man auch unter Java ziemlich ekligen Code schreiben, aber was es  IMHO deutlich leichter macht sauber zu coden, ist die Tatsache, dass hinter Java ein Objektorientiertes Konzept steht, waehrend PHP eine prozedurale Script Sprache ist, bei der versucht wurde, die Arbeit mit Objekten im nachhinein zu implementieren. Unter PHP 5 wird sich das ja vielleicht aendern, aber die Sachen, die ich unter PHP 4 ueber Klassen geregelt habe, fand ich deutlich unuebersichtlicher als unter Java.
Ein Applikation Server muss es allerdings nicht gerade sein. Den braucht man fuer die Arbeit mit Enterprise Java Beans und das lohnt sich wirklich erst, wenns um sehr grosse Applikationen geht, die auf jeden Fall skalierbar sein muessen bis zum Abwinken und eine umfangreiche Geschaeftlogik implementieren.

Bei 100 PHP Klassen waere dein Leben aber wahrscheinlich schon deutlich leichter, wenn du dir eine Servlet Engine runterlaedst (Resin oder Tomcat) und mit dem Struts Framework arbeitest, um mal ein paar Stichpunkte zu nennen. Und wenn du Objektorientierung als Konzept verstanden hast, was ja der Fall sein wird, wenn du Klassen unter PHP nutzt, ist der Umstieg auf Java wirklich nicht mehr so schwer. Ist, wie gesagt, ein voellig neuer Horizont, der sich da auftut. Nur nuetzt dir das ja wahrscheinlich nichts mehr fuer das jetzige Projekt. Deshalb, wie gesagt, wuerde ich mich mal bei den PHP Freaks auf den einschlaegigen Seiten umgucken, obs da nicht auch sowas wie ein Test Framework gibt.

Gruss
Ralf

[Andreas Korthaus]

Hi Ralf!

Hätte die Verwendung eines Applikations-Servers + Java hier »» »» »» irgendwelche Vorteile?
Auf jeden Fall. PHP habe ich jetzt zwar schon laengere Zeit nicht mehr gemacht und fuer Quickhacks finde ich das auch immer noch ziemlich gut, aber im Vergleich schneidet Java bei mir um Laengen besser ab, besonders wenns um etwas groessere Projekte geht. Zwar kann man auch unter Java ziemlich ekligen Code schreiben, aber was es  IMHO deutlich leichter macht sauber zu coden, ist die Tatsache, dass hinter Java ein Objektorientiertes Konzept steht, waehrend PHP eine prozedurale Script Sprache ist, bei der versucht wurde, die Arbeit mit Objekten im nachhinein zu implementieren. Unter PHP 5 wird sich das ja vielleicht aendern, aber die Sachen, die ich unter PHP 4 ueber Klassen geregelt habe, fand ich deutlich unuebersichtlicher als unter Java.

Ja, aber das ist für mich noch klein wirkliches "Todschlag-Argument". Sicherlich wird der Java-Code schöner, trotzdem ist es dann auch kein wirklich großer Schritt nach vorne, oder? Ich finde gerade das Konzept der EJBs faszinierend, habe das zwar noch nicht genauer angesehen, aber wenn ich das nicht falsch verstanden habe bitene EJBs eine riesige Bibliothek an gutem fertigen Code den ich in meine Anwendung integrieren kann, so dass ich nicht für alles mögliche das Rad immer neu erfinden muss, denn das mache ich wohl meist nicht unbedingt besser als die Entwicler von EJBs. Wenn Java dann auch richtig mit allem was dazu gehört.
Für den Augenblick ust es zwar zu spät, das mit PHP mussich jetzt erstmal fertig stellen, aber ich könnte mir vorstellen, wenn eine größere, grundlegendere Überarbeitung ansteht komplett auf einen Applikations-Server umzusteigen, ich dachte zunächst erstmal an JBoss, oder würdest Du davon abraten(wenn Applikationsserver dann nur Websphere oder Bea)?
Ich wüßte nicht was JSP und Sevlets alleine so viel besser können als PHP.

Ein Applikation Server muss es allerdings nicht gerade sein. Den braucht man fuer die Arbeit mit Enterprise Java Beans und das lohnt sich wirklich erst, wenns um sehr grosse Applikationen geht, die auf jeden Fall skalierbar sein muessen bis zum Abwinken und eine umfangreiche Geschaeftlogik implementieren.

Was heißt umfangreich? Es ist auf jeden Fall eine Geschäftslogik die implementiert wird, jetzt nicht vom Kaliber eines ERP-Systems, aber ich wüßte nicht was das schaden könnte auch bei etwas kleineren Systemen auf einen Applikationsserver zu setzen. Im Augenblick bilde ich ja fast einen Mini-Applikationsserver selbst nach, das hat das Problem verschiedene hinzufügbarere und entfernbarere Plugins, Mehrsprachigkeit... mit sich gebracht.

Bei 100 PHP Klassen waere dein Leben aber wahrscheinlich schon deutlich leichter, wenn du dir eine Servlet Engine runterlaedst (Resin oder Tomcat) und mit dem Struts Framework arbeitest, um mal ein paar Stichpunkte zu nennen.

Was bringt mir eine Sevlet-Engine bei PHP-Code?

Und wenn du Objektorientierung als Konzept verstanden hast, was ja der Fall sein wird, wenn du Klassen unter PHP nutzt, ist der Umstieg auf Java wirklich nicht mehr so schwer. Ist, wie gesagt, ein voellig neuer Horizont, der sich da auftut.

Aber den neuen Horizont stellt ja weniger die Sprache an sich, sondern eher die verfügbaren Server- und Entwicklungsumgebungen, oder?

Nur nuetzt dir das ja wahrscheinlich nichts mehr fuer das jetzige Projekt. Deshalb, wie gesagt, wuerde ich mich mal bei den PHP Freaks auf den einschlaegigen Seiten umgucken, obs da nicht auch sowas wie ein Test Framework gibt.

Ja, "Test Framework" war das Stichwort, da habe ich direkt bei PEAR was gefunden: http://pear.php.net/package-info.php?pacid=38, ist auch stable und basiert wohl auf JUnit, werde mir das mal ansehen.

Viele Grüße
Andreas

[Ralf Rapude]

Moin,

Ja, aber das ist für mich noch klein wirkliches "Todschlag-Argument". Sicherlich wird der Java-Code schöner, trotzdem ist es dann auch kein wirklich großer Schritt nach vorne, oder?

Um schoen gehts ja nicht unbedingt, sondern eher um Uebersichtlichkeit und damit Wartbarkeit von Code, sowie der IMHO leichteren Trennung von Code und Design, d.h. z.B. die leichtere Umsetzung von Design Patterns, wie z.B. dem MVC Pattern

Ich finde gerade das Konzept der EJBs faszinierend, habe das zwar noch nicht genauer angesehen, aber wenn ich das nicht falsch verstanden habe bitene EJBs eine riesige Bibliothek an gutem fertigen Code den ich in meine Anwendung integrieren kann, so dass ich nicht für alles mögliche das Rad immer neu erfinden muss, denn das mache ich wohl meist nicht unbedingt besser als die Entwicler von EJBs. Wenn Java dann auch richtig mit allem was dazu gehört.

Ja. Es gibt fertige EJB Komponenten, aber der Aufwand fuer die Erstellung von EJBs ist sehr hoch. Es wird, vermute ich, auch frei verfuegbare Komponenten geben, aber auch sehr viele, die man kaufen muss. Der Einsatz und vor allem die Entwicklung von EJBs muss sich lohnen und das tut er IMHO erst dann, wenn die Applikationen viel Traffic und eine sehr grosse Datenbasis haben. Ansonsten ist man mit "kleineren" Frameworks wie Struts, Velocity usw. besser dran, weils durch den geringern Entwicklungs- und Einarbeitungsaufwand die Kosten minimiert. Ausserdem ists erfahrungsgemaess guenstig, erstmal klein anzufangen, weil man sonst oft die Konzeption der grossen Fische gar nicht versteht.

Für den Augenblick ust es zwar zu spät, das mit PHP mussich jetzt erstmal fertig stellen, aber ich könnte mir vorstellen, wenn eine größere, grundlegendere Überarbeitung ansteht komplett auf einen Applikations-Server umzusteigen, ich dachte zunächst erstmal an JBoss, oder würdest Du davon abraten(wenn Applikationsserver dann nur Websphere oder Bea)?

JBoss ist wunderbar. Ausserdem gibs eben auch eine IDE fuer Eclipse (basiert auf XDoclet). Wenn du dann noch mit einer Open Source Datenbank arbeitest, bist du im Enterprise Bereich preislich ausser Konkurrenz gegenueber denen, die mit teuren Servern arbeiten (muessen). Aber guck dir erstmal an, was genau hinter dem Konzept von Ejbs steckt. Das es fertige Komponenten gibt, ist naemlich nur ein Teil. Den weitaus groesseren musst du vermutlich selber entwickeln und du wirst kraeftig mit den Ohren schlackern, wenn du anfaengst dich da reinzufummeln.
Etwas leichter wirds vielleicht mit einem guten Buch, z.B. Enterprise Beans von Richard Monson-Haefel von O'Reilly.

Ich wüßte nicht was JSP und Sevlets alleine so viel besser können als PHP.

Um nur mal ein Beispiel zu nennen:
Wenn du mit PHP auf eine Oracle Datenbank zugreifen willst, musst du PHP mit Oracle Unterstuetzung neu kompilieren. Dabei schwillt dein PHP Modul von ca. 3 oder 4 MB auf bis ca. 20 an. Bevor du aber ueberhaupt soweit bist, hast du schon endlos Fummelei gehabt und letztendlich ein riesiges traeges PHP Paket kompiliert. D.h. du kannst zwar mit PHP und Oracle arbeiten, aber das ist wieder so ein Ding, wo ich irgendwie das Gefuehl habe, dass irgendwelche Leute das Dingens solange mit Gewalt zurechtgebogen haben, bis es halt irgendwie lief. Unter Java baust du dir eine Klasse, laedst den Treiber und fertig ist es.

Was bringt mir eine Sevlet-Engine bei PHP-Code?

Natuerlich nix :o). Wenn du Java und Servlets/Jsps benutzt, brauchtst du aber eine.

Aber den neuen Horizont stellt ja weniger die Sprache an sich, sondern eher die verfügbaren Server- und Entwicklungsumgebungen, oder?

PHP hat ja auch inzwischen einen sehr grossen Umfang erreicht. Ob dieser Umfang mit Java mithalten kann, weiss ich nicht, weil ich mich lange nicht mehr mit PHP beschaeftigt habe. Fakt ist aber, dass du keinerlei Einschraenkungen hast, wenn du mit Java arbeitest. Du kannst die komplette Funktionalitaet nutzen und die ist gewaltig. Das es geniale Entwicklungsumgebungen gibt, die das Leben wirklich leichter machen, ist da eher eine sehr angenehme Dreingabe.

und basiert wohl auf JUnit, werde mir das mal ansehen.

Kenne ich nicht, aber wenns laeuft ist sowas unbezahlbar.

Gruss
Ralf

[Andreas Korthaus]

Hallo!

Ja, aber das ist für mich noch klein wirkliches "Todschlag-Argument". Sicherlich wird der Java-Code schöner, trotzdem ist es dann auch kein wirklich großer Schritt nach vorne, oder?
Um schoen gehts ja nicht unbedingt, sondern eher um Uebersichtlichkeit und damit Wartbarkeit von Code, sowie der IMHO leichteren Trennung von Code und Design, d.h. z.B. die leichtere Umsetzung von Design Patterns, wie z.B. dem MVC Pattern

Trennung von Design und Code habe ich mit einem Template-Modul geschaffen. Funkitoniert eigentlich ganz gut, aber vielleicht kann das Java auch noch besser, k.A.

Ich finde gerade das Konzept der EJBs faszinierend, habe das zwar noch nicht genauer angesehen, aber wenn ich das nicht falsch verstanden habe bitene EJBs eine riesige Bibliothek an gutem fertigen Code den ich in meine Anwendung integrieren kann, so dass ich nicht für alles mögliche das Rad immer neu erfinden muss, denn das mache ich wohl meist nicht unbedingt besser als die Entwicler von EJBs. Wenn Java dann auch richtig mit allem was dazu gehört.
Ja. Es gibt fertige EJB Komponenten, aber der Aufwand fuer die Erstellung von EJBs ist sehr hoch.

Oh ja, ich habe mal die Spezifikation für EJBs überflogen - 180 Seiten oder so waren das glaube ich ;-)

Es wird, vermute ich, auch frei verfuegbare Komponenten geben, aber auch sehr viele, die man kaufen muss.

Ich dachte da wären viele frei verfügbar? Was machen denn "teure" EJBs z.B.?

Der Einsatz und vor allem die Entwicklung von EJBs muss sich lohnen und das tut er IMHO erst dann, wenn die Applikationen viel Traffic und eine sehr grosse Datenbasis haben.

Das habe ich nicht wirklich...

Ansonsten ist man mit "kleineren" Frameworks wie Struts, Velocity usw. besser dran, weils durch den geringern Entwicklungs- und Einarbeitungsaufwand die Kosten minimiert. Ausserdem ists erfahrungsgemaess guenstig, erstmal klein anzufangen, weil man sonst oft die Konzeption der grossen Fische gar nicht versteht.

Ja, das ist ein Argument, ich hätte auch die Angst gehabt dass ich das gar nicht vernünfig hinbekomme ohne Erfahrung, ist sogar sehr wahrscheinlich... hast schon Recht, erstmal klein anfangen. Aber was ist wenn ich eines Tages dann doch auf einen Applikationsserver umsteigen wollte, kann ich dann alten Code weiterverwende, oder muss ich dann alles neu schreiben? Denn Sachen die später EJBs erledigen werde ich vermutlich vorher mit Sevlets implementieren, oder?

Für den Augenblick ist es zwar zu spät, das mit PHP muss ich jetzt erstmal fertig stellen, aber ich könnte mir vorstellen, wenn eine größere, grundlegendere Überarbeitung ansteht komplett auf einen Applikations-Server umzusteigen, ich dachte zunächst erstmal an JBoss, oder würdest Du davon abraten(wenn Applikationsserver dann nur Websphere oder Bea)?
JBoss ist wunderbar. Ausserdem gibs eben auch eine IDE fuer Eclipse (basiert auf XDoclet).

Ja, hatte ich auch von gelesen, JBoss habe ich mir mal installiert, aber wirklich durchblicken tue ich da noch nicht, wobei ich das schon irgendwie praktisch finde wie einfach es da ist eine andere Datenbank einzubinden, ohne das ich da am Code großartig was ändern muss. Ich denke der JDBC-Treiber kann sowas besser als die verschiedenen PHP-Module in Kombination mit der PEAR-Datenbank-Abstraktion.
Wobei man ja auch da das Problem hat was wenn ich DB-Transaktionen verwenden will, aber die DB das nicht kann, also muss ich auch an solche Dinge denken wenn ich Programmiere(nur so als dummes Beispiel, Transaktionen sind natürlich Grundvoraussetzungen).

Aber zumn Thema Transaktionen, ich kenen das nur aus dem Kontext von Datenbank-Transaktionen, mit Begin, Commit und Rollback, aber ich habe mir sagen lassen dass Transaktionen in einer Java-Applikationsserver-Umgebung noch weitergehen, also ein kompletter Request ist eine Transaktion oder sowas, aber das habe ich nicht verstanden wie das genau gemeint ist. Sowas geht dann aber nicht mit Struts oder sowas, oder?

Wenn du dann noch mit einer Open Source Datenbank arbeitest, bist du im Enterprise Bereich preislich ausser Konkurrenz gegenueber denen, die mit teuren Servern arbeiten (muessen).

Das schon, aber auf der anderen Seite habe ich schon zu spüren bekommen dass gerade nach der New-Econemy Kriese ungern auf solche Techniken gesetzt wird, Geld spielt nicht immer eine so große Rolle, eher im Gegenteil, viele Leute haben z.B. eine tiefe Abneigung gegen PHP und MySQL, "das kann ja nichts sein...", das ist auch ein weiterer Grund warum ich weg will von PHP. Aber ist die Verwendung von Tomcat und PostgreSQL denn so viel besser? Im Prinzip ist es ja nur der Austausch der Sprache, aber die Architektur wird dadurch ja nicht _so_ viel "professioneller". Ich glaube Dir auch gerne das sich Java hier viel besser eignet, nur will ich nicht denselben Fehler ein 2. mal machen, wenn man später auf einen richtigen Applikations-Server wechseln könnte wäre das ja schon nicht schlecht, aber alles ein 3. mal neu zu schreiben wäre großer Mist. Was ist denn wenn man JBoss mit Tomcat verwendet, und erstmal nur weitgehend mit Sevlets und wenn möglich mit wenigen vorhandenen EJBs arbeitet, wäre das nicht eine gute Möglichkeit? Tomcat kann man ja wahlweise als HTTP-Server für den JBoss verwenden. Oder was hätte das denn konkret für Nachteile wenn ich direkt auf so eine Architektur schwenke? Meinst Du die Komplexität die das mit sich bringt? Ich will einen Applikations-Server weniger wegen seiner Performance-Vorteile, Skalierbarkeit..., sondern eher um eine saubere, qualitativ hochwertige Applikation hinzubekommen, und dabei noch möglichst alles selbst zu schreiben sondern auch auf guten vorhandenen Code zurückgreifen zu können.

Aber guck dir erstmal an, was genau hinter dem Konzept von Ejbs steckt. Das es fertige Komponenten gibt, ist naemlich nur ein Teil. Den weitaus groesseren musst du vermutlich selber entwickeln und du wirst kraeftig mit den Ohren schlackern, wenn du anfaengst dich da reinzufummeln.

Das glaube ich gerne, ist halt die Frage in wieweit man am Anfang eigene EJBs braucht.

Etwas leichter wirds vielleicht mit einem guten Buch, z.B. Enterprise Beans von Richard Monson-Haefel von O'Reilly.

Das solt eich mir dann sicher besorgen. Hast Du vielleicht noch einen Tipp für den Anfang auf Lager? Ich kenn Java so gut wie nicht, habe mal ein längeres Tutorial durchgearbeitet, und danach konnte ich kleine GUIs, Applets und Kommandozeilen-Tools erstellen, kann das zwar nicht auswendig, aber _sooo_ schwer war das nicht. Nur war ich noch nicht so weit wie sevlets, jsp oder gar ejbs geschweige denn Applikationsserver.

Ich wüßte nicht was JSP und Sevlets alleine so viel besser können als PHP.
Um nur mal ein Beispiel zu nennen:
Wenn du mit PHP auf eine Oracle Datenbank zugreifen willst, musst du PHP mit Oracle Unterstuetzung neu kompilieren. Dabei schwillt dein PHP Modul von ca. 3 oder 4 MB auf bis ca. 20 an. Bevor du aber ueberhaupt soweit bist, hast du schon endlos Fummelei gehabt und letztendlich ein riesiges traeges PHP Paket kompiliert. D.h. du kannst zwar mit PHP und Oracle arbeiten, aber das ist wieder so ein Ding, wo ich irgendwie das Gefuehl habe, dass irgendwelche Leute das Dingens solange mit Gewalt zurechtgebogen haben, bis es halt irgendwie lief. Unter Java baust du dir eine Klasse, laedst den Treiber und fertig ist es.

Ja, das hört sich schon gut an. Ich muss mich damit halt näher auseinander setzen, dann kann ich das vielleicht auch bessedr einschätzen.

Aber den neuen Horizont stellt ja weniger die Sprache an sich, sondern eher die verfügbaren Server- und Entwicklungsumgebungen, oder?
PHP hat ja auch inzwischen einen sehr grossen Umfang erreicht. Ob dieser Umfang mit Java mithalten kann, weiss ich nicht, weil ich mich lange nicht mehr mit PHP beschaeftigt habe. Fakt ist aber, dass du keinerlei Einschraenkungen hast, wenn du mit Java arbeitest. Du kannst die komplette Funktionalitaet nutzen und die ist gewaltig. Das es geniale Entwicklungsumgebungen gibt, die das Leben wirklich leichter machen, ist da eher eine sehr angenehme Dreingabe.

Bisher konnte ich mit PHP wirklich alles machen was ich wollte. Nur bei dem aktuellen komplexen Projekt wird es etwas unübersichtlich, bzw. und ich habe das Gefühl das Rad des öfteren neu erfunden zu haben. Ich denke genau da spielt Java seine Stärken aus, da es eher für sowas gedacht ist. Die Frage ist jetzt, ob ich bei einem kleinen Framework bleibe, oder direkt einen J2EE Server verwende.

Viele Grüße
Andreas

[Ralf Rapude]

Moin nochmals,

Trennung von Design und Code habe ich mit einem Template-Modul geschaffen. Funkitoniert eigentlich ganz gut, aber vielleicht kann das Java auch noch besser, k.A.

Das Prinzip ist IMHO ungefaehr das gleiche, aber es gibt ja noch Code hinter der Template Engine, der noch entwickelt werden muss. Und damit bleibt die Frage, wie strukturiere ich Code (auch den von der Template Engine selbst), um den moeglichst ueberschaubar und wartbar zu machen.

Aber was ist wenn ich eines Tages dann doch auf einen Applikationsserver umsteigen wollte, kann ich dann alten Code weiterverwende, oder muss ich dann alles neu schreiben? Denn Sachen die später EJBs erledigen werde ich vermutlich vorher mit Sevlets implementieren, oder?

Ja. Vermutlich und wahrscheinlich noch diverse Hilfsklassen usw. Den dann wiederzuverwenden, wenn die Anwendung auf EJBs portiert wird, ist wahrscheinlich mehr Arbeit, als den Code neu zu schreiben. Ausserdem ist mit wiederverwendbaren Komponenten auch nicht unbedingt die erneute Verwendung des Codes gemeint, sondern eher die Wiederverwendbarkeit von Objekten, d.h. du baust z.B. einmal ein deiner Anwendung eine EJB zur Verwaltung von Adressdaten und die nimmst du auch dann, wenn du 1000.000 Adressen hast. Die Bean selber ist dann ganz anders aufgebaut, als du das z.B. in einem Servlet machen wuerdest, dass mit einer Datenbank interagiert. Die einzelne Bean stellt vielmehr (jedenfalls bei Entity Beans) einen Datensatz dar. D.h. du arbeitest gar nicht mehr direkt mit der Datenbank sondern operierst nur noch auf den EJBs, die aehnlich wie Tabellen miteinander in den unterschiedlichsten Relationen verknuepft werden koennen 1:1, 1:n usw.

Wobei man ja auch da das Problem hat was wenn ich DB-Transaktionen verwenden will, aber die DB das nicht kann, also muss ich auch an solche Dinge denken wenn ich Programmiere(nur so als dummes Beispiel, Transaktionen sind natürlich Grundvoraussetzungen).

Transaktionen, referentielle Integritaet usw. wird komplett von EJB implementiert. D.h. du kannst auch eine DB nehmen, die das nicht beherrscht, weil diese Zustaende vom Container ueber deine Beans ueberwacht werden.

also ein kompletter Request ist eine Transaktion oder sowas, aber das habe ich nicht verstanden wie das genau gemeint ist. Sowas geht dann aber nicht mit Struts oder sowas, oder?

Nee. Das Prinzip ist wie gesagt ein ganz anderes. Struts erlaubt eine sehr saubere Trennung von Model (deine Daten), View (z.B. eine jsp Seite) und Controler (der Teil, der deine Anwendung z.B. beim Absenden durch Betaetigung eines Buttons kontolliert). Bei EJBs geht es kurz gesagt darum, wiederverwendbare Komponenten zu entwickeln, bei denen du dich um ganz viele Probleme die du sonst hast, z.B. Resourcenverwaltung usw., nicht kuemmern musst. Das macht alles der Applikationserver. Der Preis den du zahlst ist der hohe Entwicklungsaufwand.

Das schon, aber auf der anderen Seite habe ich schon zu spüren bekommen dass gerade nach der New-Econemy Kriese ungern auf solche Techniken gesetzt wird, Geld spielt nicht immer eine so große Rolle, eher im Gegenteil, viele Leute haben z.B. eine tiefe Abneigung gegen PHP und MySQL, "das kann ja nichts sein...",

Ja. Das ist in der Tat ein Problem. Es wird sich aber IMHO aendern, da der Kostendruck fuer die Unternehmen immer hoeher wird. Wenn die dann eine Enterprise Anwendung wollen, bzw. brauchen, stehst du mit Open Source konkurrenzlos da. Das JBoss fei verwendbar ist, muss man ja erstmal nicht an die grosse Glocke haengen.

die Verwendung von Tomcat und PostgreSQL denn so viel besser? Im Prinzip ist es ja nur der Austausch der Sprache, aber die Architektur wird dadurch ja nicht _so_ viel "professioneller".

Genau das glaube ich eben doch. Es gibt natuerlich auch bei PHP saubere Open Source Sachen. Aber vergleiche mal irgendwelche komplexen Open Source Shop Systeme und ein Tool wie Eclipse. Bei den Shop Systemen hatte ich Anpassungen, die ein absoluter Albtraum waren. Teilweise Objektorientiert, teilweise nicht, Spaghetti Code ohne Ende, staendig wechselnde Variablennamen usw. Wobei man natuerlich der Gerechtigkeit halber sagen muss, dass hinter Eclipse zum einen auch viel mehr Geld steht, weil Firmen wie Sun und IBM dahinterhaengen. Und zum anderen wird das natuerlich von diesen Firmen gepusht, um die Vorherrschaft von Java gegen C#, bzw. die ganzen .net Geschichten durchzusetzen. Ganz andere und viel, viel maechtiger Interessen also, als dies z.B. bei PHP der Fall ist. Rechts hast du IMHO aber auf jeden Fall damit, dass PHP und MySQl nicht so ernst genommen werden. Und deshalb warens auch bei mir, zumindest teilweise, auch ganz profane wirtschaftliche Ueberlegungen, die zum Umstieg auf Java gefuehrt haben.

Ich glaube Dir auch gerne das sich Java hier viel besser eignet, nur will ich nicht denselben Fehler ein 2. mal machen, wenn man später auf einen richtigen Applikations-Server wechseln könnte wäre das ja schon nicht schlecht, aber alles ein 3. mal neu zu schreiben wäre großer Mist.

Ich wuerde mir einfach vorher ueberlegen, wie gross meine Anwendung, bzw. die Last maximal wird. Wenns maximal um ein paar tausend Datensaetze geht und die Zugriffe im Rahmen sind, tuts eine Anwendung ohne EJBs. Wenn die Last eher in Richtung des Auskunftssystems der Deutschen Bahn geht oder eines Shops wie Amazon oder Karstadt oder sowas, wuerde ich eine Enterprise Loesung bevorzugen. Vielleicht lohnt es sich aber auch schon, wenns "nur" hundert oder zweihundert User sind, die gleichzeitig die Applikation nutzen. Das kann ich nicht genau beurteilen und die Experten sind sich AFAIK auch nicht einig, ab wann der Aufwand gerechtfertigt ist.

Was ist denn wenn man JBoss mit Tomcat verwendet, und erstmal nur weitgehend mit Sevlets und wenn möglich mit wenigen vorhandenen EJBs arbeitet, wäre das nicht eine gute Möglichkeit?

Ja klar. Kann man machen. Ist wahrscheinlich allein schon zu Uebungszwecken keine schlechte Loesung, wenn du die Zeit hast, das zu machen (oder es sich vielleicht, zumindest teilweise, sogar auf den Kunden umlegen laesst).

Tomcat kann man ja wahlweise als HTTP-Server für den JBoss verwenden. Oder was hätte das denn konkret für Nachteile wenn ich direkt auf so eine Architektur schwenke? Meinst Du die Komplexität die das mit sich bringt? Ich will einen Applikations-Server weniger wegen seiner Performance-Vorteile, Skalierbarkeit..., sondern eher um eine saubere, qualitativ hochwertige Applikation hinzubekommen,

Wirkliche Nachteile hat das gar nicht. Es ist eben nur aufwendig und verhaeltnismaessig kompliziert.

Gruss
Ralf

[lulu]

Hallo Andreas

falls Du das nicht sowieso schon machst, würde ich in jedem Fall
in der php.ini das error_reporting auf E_ALL setzen.

Oder direkt im Skript per ini_set('error_reporting', E_ALL); .

so short ...

Viele Grüße

lulu

[Andreas Korthaus]

Hi lulu!

falls Du das nicht sowieso schon machst, würde ich in jedem Fall
in der php.ini das error_reporting auf E_ALL setzen.

Das habe ich zwar noch nicht, aber ich werde in mein Error-Handling Modul das error-Reporting entsprechend setzen, und die Fehler abfangen und loggen.

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Ich bin jetzt schon so einige Monate an einem PHP-Projekt, und werde das bald fertigstellen. Jetzt mache ich mir Gedanken über eine Quzalitätssicherung, bzw. über ein systematisches Testen der Software, um möglichst viele Fehler - die sicher vorhanden sind - aufzuspüren.

Für das nächste Mal würde ich empfehlen, die hochgelobten Testcases bereits während dem
Umsetzen festzulegen; erspart einiges an Zeit.

Nur wie stelle ich das an? Habe da Sachen gehört dass das Testen eines Programms oft 40% und mehr der kompletten Entwicklungszeit in Anspruch nimmt - nur was macht man in der ganzen Zeit?

Plaudern, Kaffe trinken, Rauchen, wie in den verbleibenden 60% :-)

Soviel zu der Anwendung. Ich habe gelesen, dass es bei großen Projekten richtige Programme geschrieben werden, die die zu testende Software dann halt auf Herz und Nieren überprüfen -

richtige Programme. Mal sehen, Microsoft XP, Office, Oracle? - Hm. Meistens kann man froh
sein, wenn man überhaupt zum testen kommt, die Software wird meist schon vor Abschluss
der Testphase auf den Markt geschmissen. Naja, egal...

Wie macht Ihr das? Oder muss man sowas direkt in den Code integrierern?

Kann man ja und ich halte das auch für sinnvoll. Es gibt einfach ausgedrückt zwei
Arten der Programmierung:

a) Einfach mal alles umsetzen, sodass es halbwegs smothly funktioniert und dann Fehler
   mühsam suchen, oder...
b) Von anfang an ein durchdachtes und sehr strickte arbeitendes Testsystem in den Source
   packen, sodass man gar keine Fehler machen darf (z.B. Input-Parameter check und andere
   Low-Level-Fehler).

letzteres dient IMHO dazu, sich selber einen gewissen Programmierstil aufzuzwingen, der
den Anforderungen eines "auf den ersten Blick" fehlerfreien gerecht wird und einem von
lästigem Fehlersuchen abhält.

Das Auffinden von Fehlern ist jedoch in den meisten Fällen dadurch noch lange nicht
abgedeckt und es geht hier um die Feststellung genau _dieser_ Fehler.

Die letztgenannte "Fehlerklasse" liesse sich zum grossen Teil über die bereits genannten
Mechanismen auffinden, aber am Ende des Endes braucht es einen _Menschen_ der die
Software testet. Die intelligentesten Testmodule und -Extensionen sind auch nur so gut,
wie das Programm selber, wenn sie von derselben Person geschrieben sind. Natürlich ist
das definieren von testconditions ein ganz anderes Problem und somit lassen sich wirklich
Fehler finden, aber sie decken nicht alle Fälle ab, besonders die _Interaktion_ Mensch zu
Computer lässt sich sehr schlecht in testconditions abbilden. Deshalb ist für mich das
Testen am "Lebenden Objekt" genauso wichtig, wie das testen mit toter Materie (Software
Code).

Oftmals geht es einfach um:

Input ergibt Output, vergleiche Output mit Erwartungswert, Softwarefehler bei
Nichtübereinstimmung. Aber leider ist Software oft komplex, logisch nicht gut getrennt
und nicht atomar (mit atomar meine ich, dass zu einem Input eben nur ein Output möglich
ist, der also von keinen externen Einflüssen wie z.B. andere Module abhängt), das macht
das Auffinden von Fehlern zu einem grossen Unterfangen.

Die werden alle mit möglichst vielen Angaben geloggt. Dann kann ich den Fehler evtl. reproduzieren.

und bereits auf Herz und Nieren getestete Codebestandteile können vom logging ausge-
nommen werden um die Ressourcen zu schonen. Aber das ist auch mit Vorsicht zu geniessen,
denn meistens fehlt einem bei einem Fehler dann _genau diese Information_.

Was könnte man noch machen? Wie kann ich qualitativ hochwertigen Code sicherstellen? Wie kann ich Code testen?

Nun, vielleicht noch dies:
Du hast selbst gesagt, dass die Entwicklung dem Ende naht, ich nehme an, dass das System
in den etwas eingeschränkten Umgebung (sprich, keine relle Kundendaten, nur eigene
Testdaten) bereits akzeptabel läuft, denn sonst wirst du es bereits korrigiert haben.
Den Grossteil des Testings hast du ja bereits hinter dir und unbewusst vollzogen. Du
musst dir jetzt IMHO den Kopf darüber zerbrechen, um was für eine Art Fehler es sich noch
handelt bzw. wie du diese am besten Auffinden kannst. Denn hier geht es um keine
trivialen Fehler in der Software und die nicht trivialen Fehler findet man nicht leicht.

Manchmal hilft es übrigens schon den Quelltext auf Papier zu sehen, denn ein anderes
Medium gibt andere Möglichkeiten. Mir zumindest geht das Auffinden von Fehlern auf
Papier wesentlich einfacher.

Und noch ein Erfahrungswert: Testing ist nötig, aber der ganze Rummel um maschinelles
Testing halte ich auch für etwas übertrieben. Oftmals hilft es, wenn man einfach mal mit
seiner Software spielt und die ganzen Prozesse mit halbwegs realem Hintergrund
durchspielt, man findet oftmals schneller Fehler, dafür ist dieses Testing sehr
oberflächlich. Das maschinelle, automatische Testing birgt einige Gefahren, die man damit
umgehen kann und umgekehrt. Ich vote für ein hybrides Testing (nicht auf eine Technik
beschränken).

Und noch was, was jedem einleuchten dürfte: Gute Dokumentation, gute Schnittstellen(
-beschreibungen) sind das A und O und unterbinden bereits 20% Fehler, dazu ein strictes
Programmieren, wo low-level-Fehlerbehandlung schon integriert ist und jedesmal abbricht,
wenn "schlampig" Programmiert wurde (oder z.B. die benötigte Datei nicht existiert
o.ä.), weitere x %... Dann eine gute, klar strukturierte und gekapselte (nicht zwei
Problemkreise in einem Modul behandeln) Modellierung...

Mach dich darauf gefasst, dass mit der Zeit noch mehr Fehler auftauchen, denn eine
Software ist eines nie: Perfekt.

Auch wenn ich nicht viel neues gesagt habe, hoffe ich doch, dass zumindest die Gedanken,
die ich zum Thema habe/hatte klar dargestellt sind und hoffentlich helfen.

Viele Grüsse

Philipp

[Lude]

Hallo, Philipp,

verzeihe bitte meinen Egoismus, aber ich moechte Deine Mitteilungsbereitschaft nun ausnutzen, um Deine Meinung zur "UML-Geschichte" abrufen. Diese verspricht ja Code anhand eines Modells zu erstellen, so dass, wenn der Code-Generator keine Fehler macht, auch keine Programmfehler "bereitgestellt" werden, sondern bestenfalls "Features".

Die Codegeneratoren sind kostenpflichtig, die "UML-Geschichte" ein kostenfreier Standard, richtig?

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

verzeihe bitte meinen Egoismus, aber ich moechte Deine Mitteilungsbereitschaft nun ausnutzen, um Deine Meinung zur "UML-Geschichte" abrufen.

Nun, dann bring ich jetzt mal mein internes Hypertextsystem und den Assoziationsblaster
online. Mal sehen, was der so zu UML zu sagen hat... :-)

Diese verspricht ja Code anhand eines Modells zu erstellen, so dass, wenn der Code-Generator keine Fehler macht, auch keine Programmfehler "bereitgestellt" werden, sondern bestenfalls "Features".

Das mit den Features verstehe ich nicht, was meinst du damit?
Wie ich beim Testing gesagt habe, ist auch hier der erzeugte Code nur so gut, wie der
Developer modelliert hat. Der Generator mag zwar keine syntaktischen Fehler machen und
das Modell auch richtig umsetzen, deswegen muss das Programm aber noch lange nicht
fehlerfrei sein.
Nun, die Generatoren mögen eine Hilfe sein, aber sie verhindern nicht wirklich Fehler,
die man erst später erkennt. Der Gen setzt das Modell in Code um, genau das macht der
Developer am Anfang und dieser würde sehr schnell erkennen, wenn er vom Modell etwas
falsch implementiert hat. Die automatische Umwandlung spart IMHO nur etwas Zeit und Ärger
im Anfangsstadium, dafür ist man etwas unflexibler, da Anpassungen im Modell nicht
einfach vorgenommen werden können.

Pauschal würde ich mal folgende These wagen:
Für kleine Softwareprojekte bringt UML und CodeGeneratoren absolut _gar nichts_. Es ist
schlicht verlorene Zeit. Bei grösseren Projekten halte ich UML z.T. für einen grossen
Mehrwert, der sich als wirklich hilfreich erweisen kann (unter der Voraussetzung, dass
man mit diesem "Werkzeug" auch gut umgehen kann).

Die Codegeneratoren sind kostenpflichtig, die "UML-Geschichte" ein kostenfreier Standard, richtig?

Wäre der Standard nicht kostenfrei, hätte er sich niemals in diesem Masse verbreitet und
ja, ich schätze mal die meisten Codegeneratoren dürften kostenpflichtig sein, obwohl sie
ja meistens (oder wohl immer?) mit der Modellierungssoftware ausgeliefert werden (als
fest integrierter Bestandteil).

---

Was wolltest du eingentlich _genau_ wissen?
Zudem halten sich meine Erfahrungen mit UML in Grenzen. Codegeneratoren habe ich noch nie
benutzt.

Viele Grüsse

Philipp

[Lude]

Hi,

Diese verspricht ja Code anhand eines Modells zu erstellen, so dass, wenn der Code-Generator keine Fehler macht, auch keine Programmfehler "bereitgestellt" werden, sondern bestenfalls "Features".

Das mit den Features verstehe ich nicht, was meinst du damit?

ein Code-Generator macht idealerweise keine Fehler. Wenn doch ein vom Nutzer gemeldeter Programmfehler nicht mehr zu verkennen ist, ist es "technisch" gesehen doch ein "Feature". "It's not a bug, it's a feature" (Microsoft?)

Pauschal würde ich mal folgende These wagen:
Für kleine Softwareprojekte bringt UML und CodeGeneratoren absolut _gar nichts_.

Kleinere Softwareprojekte verdienen hier ja auch nicht besprochen zu werden.   ;-)

Bei grösseren Projekten halte ich UML z.T. für einen grossen

Mehrwert, der sich als wirklich hilfreich erweisen kann (unter der Voraussetzung, dass
man mit diesem "Werkzeug" auch gut umgehen kann).

Ein Forumsteilnehmer "RobiC" (oder s.ae.) hat sich hier mal vehement fuer UML ausgesprochen. Kollegen von mir haben's auch mal getestet, sich aber fuer den generierten Code nicht "erwaermen" koennen.

Was wolltest du eingentlich _genau_ wissen?

Da das Testen ja einen betraechtlichen Mehraufwand generiert, so versprach ich mir von der "UML-Geschichte" eine betraechtliche Minderung dieses Aufwandes. (Zudem wird geruechteweise behauptet, dass mit UML komplexere Anforderungen bearbeitet werden koennen und komplexe Anforderungen effektiver bearbeitet werden koennen)
Interessieren tat mich Deine Meinung zur "UML-Geschichte". Konkretes wollte ich nicht wissen, bzw. wusste nicht was ich wissen wollte, oder so aehnlich...

Zudem halten sich meine Erfahrungen mit UML in Grenzen. Codegeneratoren habe ich noch nie
benutzt.

Wer hat das schon?

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

Was wolltest du eingentlich _genau_ wissen?
Da das Testen ja einen betraechtlichen Mehraufwand generiert, so versprach ich mir von der "UML-Geschichte" eine betraechtliche Minderung dieses Aufwandes.

Jain. UML vermindert genau _eine_ "Gattung" von Fehler: Konzeptionelle Fehler. Logische,
pysikalische, etc. Fehler lassen sich damit genauso wenig beheben wie finden.

Ich würde jetzt mal behaupten, dass genau _diese_ Gattung von Fehlern bei grossen
Softwareprojekten verherend sind und deshalb lohnt sich auch der grosse Aufwand and
Konzeptionierung in der ersten Phase (sei dies nun über UML, ER, ORM oder was auch
immer). Aber nochmals: das Testing ist damit nicht implizit gemacht, sondern nur um einen
Faktor verkürzt (Faktor Modellierungsfehler, ggf. Redundante Programmierung durch
schlecht oder ungenügend atomare Konzeption [sprich: ein Modul hat eine oder mehrere
themenfremde Aufgaben]).

(Zudem wird geruechteweise behauptet, dass mit UML komplexere Anforderungen bearbeitet werden koennen und komplexe Anforderungen effektiver bearbeitet werden koennen)

Das könnte ich mir vorstellen. Denn UML arbeitet ja primär auf einer visuellen Ebene
(vergl. visuelle Use Case-Diagramme) und ist somit sehr überschaubar. Eine textuelle
Fassung aller Use Cases wäre zwar konkreter, jedoch nicht überschaubar. Komplexe
Anfragen lassen sich visuell (eg. Verbindungen zwischen Klassen) wesentlich einfacher
zusammenstellen, als wenn man sie textuell verfasst sind.

Interessieren tat mich Deine Meinung zur "UML-Geschichte". Konkretes wollte ich nicht wissen, bzw. wusste nicht was ich wissen wollte, oder so aehnlich...

here you are ;-)

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo nochmals

Jain. UML vermindert genau _eine_ "Gattung" von Fehler: Konzeptionelle Fehler. Logische,
pysikalische, etc. Fehler lassen sich damit genauso wenig beheben wie finden.

hier könnte man leicht etwas falsches verstehen: Mit logischen und physikalischen
Fehlern meinte ich nicht Fehler bzgl. der logischen und physikalischen Repräsentation
oder Ausarbeitung des konzeptionellen Entwurfes. Background: vom konzeptionellen Entwurf
kommt man zu logischen Sichten/Entwürfen und von da aus zu den Physikalischen (d.h.
sozusagen ein Schritt vor der Umsetzung, vom hohen Abstraktionsgrad zur fast 1:1
Abbildungsvorschrift in Code).

Ich sprach vielmehr von den "grundlegenden Fehlern", wie z.B. die von Richard genannten.
Klasse falsch geblessed, ist das Ergebnis der eigenen Quadratwurzelfunktion positiv,
existiert die Datei namens 'foo' etc.

Viele Grüsse

Philipp

[Lude]

Hallo, Philipp,

Jain. UML vermindert genau _eine_ "Gattung" von Fehler: Konzeptionelle Fehler. Logische,
pysikalische, etc. Fehler lassen sich damit genauso wenig beheben wie finden.

hier könnte man leicht etwas falsches verstehen: [...]

hey, das waere nicht passiert, wenn Du Dir selbst geantwortet haettest, dann haettest Du ein sequentielles Lesen fast erzwungen. - Aber man antwortet sich ja nicht gerne selbst.   ;-)

Gruss,
Lude

[Lude]

Hallo, Philipp,

Was wolltest du eingentlich _genau_ wissen?
Da das Testen ja einen betraechtlichen Mehraufwand generiert, so versprach ich mir von der "UML-Geschichte" eine betraechtliche Minderung dieses Aufwandes.

Jain. UML vermindert genau _eine_ "Gattung" von Fehler: Konzeptionelle Fehler. Logische,
pysikalische, etc. Fehler lassen sich damit genauso wenig beheben wie finden.

Moment, ich dachte, dass der typische kleine Denkfehler des Entwicklers (nehmen wir mal die nicht unterbundene Division durch 0), also der logische Fehler, dann nicht mehr auftauchen kann. - "Physikalische" Fehler koennten Hardwarefehler meinen, diese koennen auch durch UML nicht zuverlaessig vermieden werden.

Interessant, ich dachte, dass es fast nur noch konzeptionelle Fehler geben wuerde - Ausnahme o.g.

Ich würde jetzt mal behaupten, dass genau _diese_ Gattung von Fehlern bei grossen
Softwareprojekten verherend sind und deshalb lohnt sich auch der grosse Aufwand and
Konzeptionierung in der ersten Phase (sei dies nun über UML, ER, ORM oder was auch
immer). Aber nochmals: das Testing ist damit nicht implizit gemacht, sondern nur um einen
Faktor verkürzt (Faktor Modellierungsfehler, ggf. Redundante Programmierung durch
schlecht oder ungenügend atomare Konzeption [sprich: ein Modul hat eine oder mehrere
themenfremde Aufgaben]).

Also UML ist gut, weil die konzeptionelle Herangehensweise bei der Softwareentwicklung unterstuetzend, aber die Codegeneratoren kann man vergessen ?!

Interessieren tat mich Deine Meinung zur "UML-Geschichte". Konkretes wollte ich nicht wissen, bzw. wusste nicht was ich wissen wollte, oder so aehnlich...

here you are ;-)

Wie immer vielen Dank.

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

Was wolltest du eingentlich _genau_ wissen?
Da das Testen ja einen betraechtlichen Mehraufwand generiert, so versprach ich mir von der "UML-Geschichte" eine betraechtliche Minderung dieses Aufwandes.
Jain. UML vermindert genau _eine_ "Gattung" von Fehler: Konzeptionelle Fehler. Logische,
pysikalische, etc. Fehler lassen sich damit genauso wenig beheben wie finden.
Moment, ich dachte, dass der typische kleine Denkfehler des Entwicklers (nehmen wir mal die nicht unterbundene Division durch 0), also der logische Fehler, dann nicht mehr auftauchen kann. - "Physikalische" Fehler koennten Hardwarefehler meinen, diese koennen auch durch UML nicht zuverlaessig vermieden werden.

Missing Begriffsdefinition. Das logisch und physikalisch in UML ist IMHO nicht direkt mit
logischem oder physikalischem Fehler gleichzusetzen. Meistens wird in UML gar nicht auf
diese Ebene runter modelliert (bzw. diese Ebene ist gar nicht mehr Bestandteil der
Modellierungsarbeit). Die konzeptionelle Schicht definiert z.B. die Relation zwischen
Kunde und Warenkorb, wobei eine logische Schicht z.B. definiert, welche Artikel welcher
Kunde sehen darf, bzw. wie man die Gesamtzahl aller Artikel oder Endsumme der Bestellung
berechnet. Hm, eigentlich gar nicht unwahr, dass das ein logischer Fehler ist, evtl. sind
die Begriffe doch einigermassen synonym verwendbar; dennoch geht man mit UML oftmals
nicht so weit in die Tiefe, dass man logische Fehler wirklich 100% ausschliessen kann.
Zudem ist nicht jede "division durch 0" (um beim Beispiel zu bleiben) durch die
konzeptionelle, logische oder physikalische Sicht sichtbar, denn dieser Fehler wird
meistens in der Programmlogik per se verursacht, nicht in der Relation mehrerer
Programmlogiken. UML modelliert ja nicht den Quelltext einer Methode, sondern höchstens
die Verbindung/Nachrichtenaustausch jener.

Interessant, ich dachte, dass es fast nur noch konzeptionelle Fehler geben wuerde - Ausnahme o.g.

Das ist IMHO stark von der Tiefe der Modellierung abhängig... Zudem: ggf. erkennt man
Fehler bereits während der Konzeptionierung, aber man kann sie genauso leicht
übersehen, wie es im resultierenden Quelltext geschieht. Die Maschine kann nicht
entscheiden, was richtig und was falsch ist; demnach muss der Mensch es dem Computer
beibringen (eg. Test-Module) oder es in der Konzeptionierung bereits erkennen. Wenn der
Computer über UML feststellen soll, wo ein Fehler ist, musst du ihm beibringen, was
richtig und was falsch ist und somit verschiebt sich das Testing einfach auf das UML
Modell (irgendwelche sinnvollen Constraints definieren, wie dies in den Test-Modulen
der Fall wäre).

Ich würde jetzt mal behaupten, dass genau _diese_ Gattung von Fehlern bei grossen
Softwareprojekten verherend sind und deshalb lohnt sich auch der grosse Aufwand and
Konzeptionierung in der ersten Phase (sei dies nun über UML, ER, ORM oder was auch
immer). Aber nochmals: das Testing ist damit nicht implizit gemacht, sondern nur um einen
Faktor verkürzt (Faktor Modellierungsfehler, ggf. Redundante Programmierung durch
schlecht oder ungenügend atomare Konzeption [sprich: ein Modul hat eine oder mehrere
themenfremde Aufgaben]).
Also UML ist gut, weil die konzeptionelle Herangehensweise bei der Softwareentwicklung unterstuetzend, aber die Codegeneratoren kann man vergessen ?!

Nein, das würde ich nicht sagen. Sie sind lediglich ein Werkzeug, das man verwenden kann,
oder man lässt es. Sie machen nichts schlechter oder besser (vorausgesetzt der
Programmierer bildet das Modell ebenfalls 100% richtig ab, was IMHO nicht unmöglich ist,
denn wenn er falsch abbildet merkt er es früher oder später [eg. eine Klasse vergessen,
oder einen Inputparameter nicht angegeben]). Um das Programmieren kommt aber (noch)
keiner herum und _da_ entstehen eben noch weitere Fehler (welche ich vorher mit dem
"anderen" logisch und physikalisch umschrieben habe).

Viele Grüsse

Philipp