WordPress erfreut sich von Version zu Version immer größere Beliebtheit. Leider sieht man auch immer heufiger Blogs die aus sicht der Geschwindigkeit zu wünschen übrig lassen. Die Ursach hierfür liegt meistens am Blog selber. Es gibt einige Punkte die beachtet werden sollten.

1. WordPress stets aktuell halten, ab Version 2.7  wurde die Performens deutlich gesteigert.
2. Nur wirklich benötigte PlugIns verwenden und stets aktuell halten. “Weniger ist meist mehr”, da  jedes installierte PlugIn Rechenzeit kostet.
3. PHP-Code und Datenbankabfragen reduzieren,  oder Seiten nur über einen Cach bedienen.
4. Die Mysql Datenbank per cron immer optimieren und reparieren lassen.
5. Nur optimierte  Bilder verwenden, Bilder sollten nur die benötigt Größe haben, Tip Blogdesk hilft hierbei.
6. WP-Cache nutzen, ab Version 2.8 ist dieser besser als  WP-SuperCache. Beide PlugIns reduziert die Serverlast drastisch.

8.PHP Speedy WP benutzen – dieses PlugIn bindet PHP Speedy in WP ein – eine Bibliothek die die zu übertragende Datenmenge durch Kompression stark verringert. ACHTUNG! Das PlugIn arbeitet nicht ohne Anpassungen mit WP SuperCache zusammen! Am besten lest ihr den Artikel auf Noupe für mehr Details!

9.WP CSS – diese PlugIn komprimiert CSS Dateien und liefert diese aus statt der normalen Version

10.DB Cache – speichert Ergebnisse von Datenbankabfragen im Dateisystem zwischen

11.Nutzung der AJAX Libraries API- diese API ist ein Angebot von Google die es erlaubt die großenJavaScript-Frameworks (jQuery, prototype, dojo, usw.) von den Google-Servern aus einzubinden statt sie auf dem eigenen Server zu hosten. Dies hat den Vorteil, dass die Google-Server im Allgemeinen besser ans Internet angebunden sind als die eigenen  Außerdem speichern Browser die Bibliothek zwischen – was ein Vorteil ist wenn viele Seiten diesen Mechanismus nutzen da die Bibliothek nur einmal geladen wird

12.Die Anzahl Datenbank-Queries und die Seitenladezeit anzeigen- wenn man seine WP-Installation optimiert sollte man sich diese Werte anzeigen lassen um ggf. sofort zu sehen was die Optimierungen bringen (mehr Infos + Code findet sich bei Noupe)

13.Optimize DB nutzen- dieses PlugIn bietet eine ähnliche Funktionalität wie das weiter oben erwähnte WP-Optimize.

14.WP-Optimize nutzen- dieses PlugIn kann einerseits die Datenbank optimieren aber zusätzlich noch ein paar Dinge mehr. Das PlugIn kann z.B. Artikel-Revisionen löschen, Spam-Kommentare aus der Datenbank entfernen, uvm.

15.Anzahl Artikel-Revisionen reduzieren- In den neueren Versionen legt WordPress bei Ãnderungen an Artikeln Kopien der Artikel in der Datenbank an. Dies ist nützlich um z.B. bequem einen älteren Stand eines Artikels wiederherzustellen wenn man z.B. aus Versehen einen Teil gelöscht hat oder Ãhnliches. Das Problem ist, dass WP standardmässig bis zu 10 Versionen eines Artikels in der Datenbank anlegt und dadurch sehr viel Müll in der Datenbank entsteht. Daher empfehle ich das Revision Control PlugIn. Mit ihm kann man das Revisionsmanagement bequem in der Admin-Oberfläche von WP konfigurieren (an-/abschalten, Anzahl der Revisionen für Seiten und Artikel festlegen). Durch weniger Revisionen wird die Datenbank entlastet.

Mobiles Linux mit Moblin
Debian 5.0-Installation mit einer Braillezeile
Die Vorgeschichte von Linux
Der Mai im Kernel-Rückblick
Toribash – Kampf mit (der) Physik
Erfahrungsbericht: OpenOffice.org 3.0
Keine Angst vor awk – ein Schnelleinstieg
AVR-Mikrocontroller unter Linux
ECDL/ICDL wagt sich an OpenOffice.org
Rezension: Just for Fun – The Story of an Accidental Revolutionary
Das Ende des Programmierwettbewerbs
Veranstaltungskalender und Leserbriefe

Das freiesMagazin berichtet monatlich über Wissenswertes und Neues aus den Welten Freier Software, Open Source und Linux. Was 2005 als loser Newsletter begann, reifte mit der Zeit durch Akzeptanz und Teilnahme der Linux-Community zum regelmäßig erscheinenden Magazin. Getreu dem Motto „der Community etwas an Wissen, Spaß und Freude zurückzugeben“ laden wir auch weiterhin Autoren zum Wissensaustausch ein.

Bei SuSE 10.X

• autoconf
• php5-5.X
• apache2-mod_php5-5.X
• php5-pdo-5.2.0-10
• php5-devel-5.X
• php5-pear-5.X
• instant client for Oracle http://www.oracle.com/technology/tech/oci/instantclient/index.html)
• instantclient-basic-linux-*.zip und instantclient-sdk-linux-*.zip
• http://pecl.php.net/get/oci8 (oci8-1.2.3.tgz)

Anlegen von mkdir /opt/oracle

Auspacken der Zip-Dateien in den Ordner /opt/oracle/instantclient_10_2
Link anlegen
cd /opt/oracle/instantclient_10_2
ln -s libclntsh.so.10.1 libclntsh.so

Test ob Oracle vorhanden:
echo $ORACLE_HOME

Anlegen der Pfade in der Datei /etc/profile

ORACLE_HOME=/opt/oracle/instantclient_10_2
LD_LIBRARY_PATH=$ORACLE_HOME
export ORACLE_HOME
export LD_LIBRARY_PATH

Der gleiche Eintrag muss auch noch in
/etc/init.d/apache2

Tip: vom System abmelden und wieder anmelden

cd /opt/oracle/
wget http://pecl.php.net/get/oci8
pear5 install oci8-1.2.3.tgz

—————————-Meldung ———————————
10 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
Please provide the path to ORACLE_HOME dir. Use ‘instantclient,/path/to/instant/client/lib’
if you’re compiling against Oracle Instant Client [autodetect] :
—————————-Meldung ———————————

Eingeben von: instantclient,/opt/oracle/instantclient_10_2

Nach der Installation:
Die Datei /etc/php5/conf.d/oci.ini anlegen mit dem Inhalt:

; comment out next line to disable oci extension in php
extension=oci8.so

Test der Installation:
php /usr/share/doc/packages/php5/test.php5 | grep oci8

Apache2 Restarten

Testseite anlegen und ausführen:

Da wir keine tnsnamesora verwenden ändert sich der Aufruf:

—————————-Meldung ———————————
< ?php

$conn = OCILogon(“dbuser”, “dbpasswd”, “//dbserver.host.net/DB”);

$query = ‘select table_name from user_tables’;

$stid = OCIParse($conn, $query);
OCIExecute($stid, OCI_DEFAULT);
while ($succ = OCIFetchInto($stid, $row)) {
foreach ($row as $item) {
echo $item.” “;
}
echo ”
\n”;
}

OCILogoff($conn);

?>
—————————-Meldung ———————————

Links:

http://www.oracle.com/technology/tech/php/index.html

http://en.opensuse.org/Howto_build_oci8_extension_module_for_php

CVS-Ablaufplan

CVS-Vorteile

• Alle Entwickler arbeiten mit den Richtigen Quellen.
• Es entsteht eine Ãœbersicht der Projekte und dessen Status.
• Der Programmiercode wird Dokumentiert.
• Die Qualitätskontrolle wird vereinfacht.
• Anwendungen werden besser programmiert.

CVS-Nachteile

• Es müssen Regeln für die Programmierung aufgestellt werden.
• Es müssen Regeln für den Umgang mit CVS erarbeitet werden.
• Es müssen Schulungen für Anwender und Administratoren durchgeführt werden.
• Neue Software muß eingeführt werden.

CVS Befehlsübersicht

• Checkout: Projektname (Modulname)
• Import: Projektname (Modulname)
• Add: Eine neue Datei oder ein neues Verzeichnis zum Repository hinzufügen.
• Get: Eine lokale Kopie des Repositories anlegen.
• Commit: Änderungen ins Repository eintragen.
• Diff: Unterschiede zwischen lokaler Kopie und Repository anzeigen.
• Log: CVS Log Information anzeigen.
• Rdiff: Eine Sammlung von Diffs zur Anzeige von Versionsunterschieden erzeugen.
• Status: Status der lokalen Dateien im Vergleich zum Repository anzeigen.
• Update: Die lokale Kopie des Repositories aktualisieren.

CVS-Clients

1. WIN-CVS CVS client für Windows, Macintosh and Unix´
2. TortoiseCVS rechte Mause
3. gCVS
4. CVS client für Windows, Macintosh and Unix
5. jCVS
6. CVS Java client.
7. CVSweb

Subversion
aus Linux Usergroup der Zuercher Hochschule Winterthur, der freien Wissensdatenbank
Subversion (abgek\ufffdrzt als SVN) ist ein Programm zur Versionsverwaltung, \ufffdhnlich CVS. Die Bedienung von Subversion ist sehr an diejenige von CVS angelehnt, jedoch bietet es diesem gegen\ufffdber einige Vorteile und Verbesserungen. Zum Beispiel ist es m\ufffdglich Dateien und Verzeichnisse umzubenennen, wobei die History erhalten bleibt. Mit cvs2svn existiert auch ein Konverter, der CVS-Repositories nach SVN umwandeln.

http://lug.zhwin.ch/wiki/index.php/Subversion

Buch:
http://svnbook.red-bean.com/

Software:
http://subversion.tigris.org/

weiter…

Installation und Konfiguration von Subversion ber mod_dav_svn

Subversion untersttzt zwei verschiedene Server-Varianten: Den eigenstndigen Serverprozess svnserve und das Modul mod_dav_svn fr den Webserver Apache.

Voraussetzung:

1. Apache-2-Webserver.
2. Apache-Modul mod_authz_svn.so und mod_dav_svn.so

Die Module mssen von Apache geladen werden. Bei Suse besser ber Yast einbinden. Auszug aus der Konfiguration

#SVN ModuleLoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

Einrichten des SVN im Apache Webserver:

# project repository files for musterprojekt START
<location>
DAV svn
SVNPath /srv/svn/repos/musterprojekt
AuthType Basic
AuthName "Subversion Repository for musterprojekt"
AuthUserFile /srv/svn/user_access/musterprojekt_AuthUserFile
AuthGroupFile /srv/svn/user_access/musterprojekt_AuthGroupfile
# Limit access to certain people
<limitexcept>
           Require group musterprojekt_committers
</limitexcept>
# Limit read access to certain people
<limit>
           Require group musterprojekt_committers
           Require group musterprojekt_readers
</limit>
</location>
# project repository files for musterprojekt ENDE

ber diese Eintr wird festgelegt, wo das Repositories liegt und wer es wie benutzen darf

Bevor der Webserver neu gestartet wird mssen die Verzeichnisse und Gruppen angelegt werden.

Anlegen von Projekten:======================

1. cd /srv/svn/repos
2. svnadmin create projektname
3. chown -R wwwrun:www projektname/{dav,db,locks}
4. touch /srv/svn/user_access/projektname_AuthGroupfile
5. touch /srv/svn/user_access/projektname_AuthUserFile
6. chown root:www /srv/svn/user_access/projektname_AuthGroupfile
7. chown root:www /srv/svn/user_access/projektname_AuthUserFile
8. chmod 644 /srv/svn/user_access/projektname_AuthGroupfile
9. chmod 644 /srv/svn/user_access/projektname_AuthUserFile
10. htpasswd2 /srv/svn/user_access/projektname_AuthUserFile username
11. Berechtigungen anlegen in /srv/svn/user_access/projektname_AuthGroupfile Lesen Schreiben

Zugriff auf das RepositoryNachdem der Apache-Server mit der genderten Konfiguration neu gestartet wurde, kann mit dem normalen Subversion-Client svn auf die Repositories zugegriffen werden. Allerdings muss als Protokoll http oder (falls konfiguriert) https verwendet werden:

http://localhost/repos

Import: Projektname (Modulname)

Add: Eine neue Datei oder ein neues Verzeichnis zum Repository hinzufügen.
Get: Eine lokale Kopie des Repositories anlegen.

Commit: �nderungen ins Repository eintragen.

Diff: Unterschiede zwischen lokaler Kopie und Repository anzeigen.

Log: CVS Log Information anzeigen.

Rdiff: Eine Sammlung von Diffs zur Anzeige von Versionsunterschieden erzeugen.

Status: Status der lokalen Dateien im Vergleich zum Repository anzeigen.

Update: Die lokale Kopie des Repositories aktualisieren.

Powered by ScribeFire.

Die Software arbeite reibungslos und sehr schnell, auch das zurückspielen der Daten ist zuverlässig und schnell. Ich verwende die Software schon seid 3 Jahren und bis sehr zufrieden. Im Notfall wird eine schnelle und einfache Methode immer bevorzugt.

Powered by ScribeFire.

FreeNX Server HOWTO für openSUSE

Einrichten des FreeNX Servers
Zur Installation der FreeNX Serverkomponente steht für aktuelle Versionen wie SUSE Linux 10.x im Online Repository oder auf den verfügbaren CD Images ein RPM-Paket bereit. Dies kann mit Hilfe von YaST oder mittels RPM installiert werden. Achtung den Client nicht vergessen.

Nachdem der Server und ein Client per RPM beziehungsweise YaST installiert wurde, ist die Konfiguration zur Nutzung denkbar einfach.

1) Um sich zu vergewissern, dass tatsächlich die richtige Server Software installiert wurden, kann man als Root User die lokale RPM Datenbank mit folgendem Kommando abfragen:

linux:/ # rpm -q FreeNX

FreeNX
Sollte auf die RPM Abfrage hin kein Package Name ausgegeben werden, ist das Package noch nicht installiert. Wenn wir im Beispiel “FreeNX-0.4.4-4″ angegeben wird, sind schon alle Vorbedingungen für die Konfiguration des installierten Servers erfüllt.

2) Zur Konfiguration wird das (mitinstallierte) Programm nxsetup genutzt.

linux:/ # nxsetup –install –setup-nomachine-key –clean
Die Optionen bedeuten im Folgenden:

–install Installiert die für den Betrieb der Server Software notwendigen Dateien und richtet einen lokalen Benutzern Account für NX ein.

–setup-nomachine-key Diese Option ermöglicht den Aufbau einer verschlüsselten Verbindung mit einem bereits vorhandenen, mitgelieferten und dem Nomachine NX-Client bereits bekannten, SSH-Schlüssel. Dies bedeutet weniger Sicherheit, erleichtert jedoch die Konfiguration des Clients. Um einen neuen Schlüssel zu generieren und zu verteilen, sollte man sich zunächst mit grundlegenden Zusammenhängen der Public-Key Kryptographie vertraut machen.

–clean Vor der Installation werden eventuell bereits vorhandene Konfigurations- dateien entfernt.

Mittels des Programms ‘nxserver’ kann neven der Konfigurationn des NX-Servers auch dessen Status Status abgefragt werden:

linux:/ # nxserver –status
NX> 100 NXSERVER – Version 1.4.0-44 OS (GPL)
NX> 110 NX Server is running
NX> 999 Bye
Für den nxserver müssen die lokalen Benutzerkonten konfiguriert werden, welche sich über einen Client (wie z.B. KNX) anmelden können.

linux:/ # nxserver –adduser <Benutzername>

Achtung: Das Passwort sollte nicht neu gesetzt werden.

Der NX Server wird in der Nomachine-Terminologie als Node bezeichnet. Weitere Möglichkeit zu dessen Konfiguration bietet die Konfigurationsdatei /etc/nxserver/node.conf

3) Die Funktion des NX Servers kann nun mit einem lokal installierten Client getestet werden. Im Beispiel wird der KDE Client KNX genutzt.

News Update:

NoMachine hat eine neue Generation der Terminal-Server-Software NoMachine NX
freigegeben.
Gegenüber der letzten Version kommt NoMachine NX 3.0.0 mit zahlreichen Änderungen und Neuerungen. Unter anderem ist es ab sofort möglich, lokale Desktops mit anderen Nutzern zu teilen. Durch Session-Shadowing gestattet die Applikation auch mehreren Nutzern, auf eine und dieselbe Session zuzugreifen. Eine weitere Neuerung stellt die Möglichkeit dar, Vorgänge durch Skripte auszuführen. Ferner haben die Entwickler nach eigenen Angaben viele Bereiche der Applikation verbessert und zahlreiche Unzulänglichkeiten beseitigt.

Powered by ScribeFire.

Import: Projektname (Modulname)

Add: Eine neue Datei oder ein neues Verzeichnis zum Repository hinzuf�gen.
Get: Eine lokale Kopie des Repositories anlegen.

Commit: �nderungen ins Repository eintragen.

Diff: Unterschiede zwischen lokaler Kopie und Repository anzeigen.

Log: CVS Log Information anzeigen.

Rdiff: Eine Sammlung von Diffs zur Anzeige von Versionsunterschieden erzeugen.

Status: Status der lokalen Dateien im Vergleich zum Repository anzeigen.

Update: Die lokale Kopie des Repositories aktualisieren.

Bei immer komplexeren Produkten spielt besonders im Software-Engineering der Test eine wichtige Rolle. Dort werden bis zu 40% der gesamten Projektdauer dem Testen gewidmet.

Ziele

    * Ziel des Testens ist es, ein Programm mit der Absicht auszuführen Fehler zu finden.

    * Ein Testobjekt sollte nicht vom Entwickler selbst, sondern von anderen, wenn möglichst unabhängigen, Personen getestet werden, denn der Entwickler findet prinzipiell immer weniger Fehler in seinem eigenen Programm als externe Personen.

    * Tests sollte man unter der Annahme planen, dass Fehler gefunden werden können.

    * Ein Fehler in einem Modul weist oft auf weitere Fehler in diesem oder anderen Modulen hin.

    * Testziele in Bezug auf die Anforderungen:

         1. Jede Anforderung muss getestet werden, ansonsten ist das Testen unvollständig.

         2. Ungenügendes bzw. exzessives Testen soll vermieden werden. Es soll zwar jede Anforderung getestet werden, aber die Anzahl der Testfälle für einzelne Anforderungen sollte nicht zu groß sein.

         3. Geeignete Komplexität beim Testen. Die Anzahl der Testfälle, der Anforderungen und der Links zwischen Anforderungen und Testfällen sollte ausgewogen sein.

Abgrenzung

In ihrem Selbstverständnis sind Tests klar abzugrenzen von

    * der klassischen Verifikation, welche einen Korrektheitsbeweis verwendet,

    * dem einfachen Experiment oder Ausprobieren, in der Fachsprache des Software-Testens als “Try” (engl. für Versuch) bezeichnet.

Ursache-Wirkungs-Analyse

Bei dieser Methode werden Ursachen und Wirkungen jeder Teilspezifikation identifiziert. Eine Ursache ist dabei eine einzelne Eingabebedingung oder eine Äquivalenzklasse von Eingabebedingungen; eine Wirkung ist eine Ausgabebedingung oder eine Systemtransformation.

Die folgenden Arten von Abhängigkeiten zwischen Ursachen werden dabei unterschieden:

   1. Exklusive Abhängigkeit: Die Anwesenheit einer Ursache schließt andere Ursachen aus.

   2. Inklusive Beziehung: Mindestens eine von mehreren Ursachen liegt vor (z.B. ist eine Ampel immer grün, gelb oder rot – oder rot und gelb zusammen. Wenn sie funktioniert und eingeschaltet ist).

   3. One-and-only-one-Beziehung: Es liegt genau eine von mehreren Ursachen vor (z.B. männlich oder weiblich oder Zwitter).

   4. Requires-Abhängigkeit: Die Anwesenheit einer Ursache ist Voraussetzung für das Vorhandensein einer anderen (z.B. Alter > 21 und Alter > 18).

   5. Maskierungsabhängigkeit: Eine Ursache verhindert, dass eine andere Ursache eintreten kann.

Entscheidungstabellen-basierter Test

Hier werden die Testfälle auf Basis von Entscheidungstabellen ermittelt, indem Regeln spezifiziert werden, die Bedingungskombinationen mit den zugehörigen Aktionen verknüpfen. Die Methode ähnelt der Ursache-Wirkungs-Analyse.

Strukturorientierte Testmethoden

Strukturorientierte Testmethoden bestimmen Testfälle auf Basis des Softwarequellcodes.

Software-Module enthalten Daten, die verarbeitet werden, und Kontrollstrukturen, die die Verarbeitung der Daten steuern. Entsprechend unterscheidet man Tests, die auf dem Kontrollfluss basieren, und Tests, die Datenzugriffe als Grundlage haben.

Kontrollflussorientierte Tests

Kontrollflussorientierte Tests beziehen sich auf logische Ausdrücke der Implementierung. Datenflussorientierte Kriterien konzentrieren sich auf den Datenfluss der Implementierung. Genau genommen konzentrieren sie sich auf die Art und Weise in welcher Hinsicht die Werte mit ihren Variablen verbunden sind und wie diese Anweisungen die Durchführung der Implementierung beeinflussen.

Die kontrollflussorientierten Kriterien werden in vier weitere Kriterien unterteilt.

    * Überdeckung von Anweisungen (C0)

    * Kantenüberdeckung (C1)

    * Bedingungsüberdeckung

    * Pfadüberdeckung

Alle orientieren sich am Kontrollflussgraphen des Programms.

Anweisungsüberdeckungstest (C0 -Test)

Beim Anweisungsüberdeckungstest werden alle Knoten des Kontrollflussgraphen von mindestens einem Testfall abgedeckt, d.h., jede Anweisung im Quelltext wird mindestens einmal ausgeführt. Der C0-Test hat keine praktische Bedeutung, da er ein zu schwaches Kriterium für eine sinnvolle Testdurchführung darstellt.

Zweigüberdeckungstest (C1 -Test)

Hier werden die Testfälle so spezifiziert, dass alle Zweige (Kanten) des Kontrollflussgraphen mindestens einmal durchlaufen werden.

Auch diese Methode hat Nachteile:

Oft ist es schwierig, Programmzweige zu durchlaufen, da bestimmte Betriebssystemzustände oder schwierig zu erzeugende Datenkonstellationen erforderlich sind. Zudem werden Kombinationen von Zweigen und komplexe Bedingungen nicht angemessen berücksichtigt.

Schließlich werden Programmschleifen nicht ausreichend getestet, da ein einzelner Durchlauf durch den Schleifenkörper von abweisenden Schleifen und eine einzelne Wiederholung von nicht abweisenden Schleifen für die Zweigüberdeckung ausreichend ist.

Einfacher Bedingungsüberdeckungstest (C3A -Test)

Hier wird die Struktur der Entscheidungen innerhalb des Testlings für die Testfallermittlung herangezogen. Dabei wird gefordert, die Testfälle so zu bestimmen, dass die Auswertung jeder Teilentscheidung einmal den Wert wahr und einmal den Wert falsch ergibt.

Dies berücksichtigt jedoch nicht, dass Bedingungen oft aus geschachtelten logischen Verknüpfungen von Teilentscheidungen bestehen. Dadurch werden Fehlersituationen maskiert: Bei „oder“ – Verknüpfungen reicht es, wenn die erste Teilbedingung wahr ist, bei „und“ – Verknüpfungen, wenn die erste Bedingung falsch ist, um den weiteren Kontrollfluss festzulegen. Fehler in den anderen Bedingungsteilen werden nicht erkannt. Daher garantiert der einfache Bedingungsüberdeckungstest nicht einmal eine Zweigüberdeckung.

Mehrfach-Bedingungsüberdeckungstest(C3B / C3C-Test)

Der minimale Mehrfach-Ãœberdeckungstest verlangt, dass neben den Teilentscheidungen und der Gesamtentscheidung auch alle zusammengesetzten Teilentscheidungen gegen wahr und falsch geprüft werden.

Der modifizierte Bedingungsüberdeckungstest verlangt darüber hinaus Testfälle, die demonstrieren, dass jede Teilentscheidung den Wahrheitswert der Gesamtentscheidung unabhängig von den anderen Teilentscheidungen beeinflussen kann.

Der wesentliche Nachteil ist der extrem hohe Testaufwand: Bei n Teilentscheidungen ergeben sich 2n Testfälle.

Pfad-Ãœberdeckungstests (C2 -Test)

Beim Pfadüberdeckungstest werden sämtliche unterschiedlichen Pfade des Testlings in mindestens einem Testfall durchlaufen. In der Regel ist dies allerdings nicht durchführbar, da es sehr häufig unendlich viele Pfade gibt – bedingt durch Schleifen ohne feste Wiederholungszahl. Ein weiteres Problem ist die Nichtausführbarkeit eines Teils der aus dem Kontrollflussgraphen konstruierbaren Pfade. Ein Beispiel dafür: Steht im Programmcode zunächst „Wenn Bedingung A dann Zweig 1 sonst Zweig 2“ und später „Wenn Bedingung A dann Zweig 3 sonst Zweig 4“, dann können Pfade, die Zweig 1 und Zweig 4 enthalten, nicht ausgeführt werden.

Der Pfadüberdeckungstest hat daher keine praktische Bedeutung.

Datenflussorientierte Tests (z.B. für Java)

Datenflussorientierte Testmethoden basieren auf dem Datenfluss, also dem Zugriff auf Variablen. Sie sind besonders geeignet für objektorientiert entwickelte Systeme.

Für die datenflussorientierten Tests gibt es unterschiedliche Kriterien, welche im Folgenden beschrieben werden.

All defs-Kriterium

Für jede Definition (all defs) einer Variablen wird eine Berechnung oder Bedingung getestet. Für jeden Knoten und jede Variable muss ein definitionsfreier Pfad zu einem Element getestet werden. Die Fehlererkennungsrate liegt bei diesem Kriterium bei ca. 24%.

All p-uses-Kriterium

Die „p-uses“ dienen zur Bildung von Wahrheitswerten innerhalb eines Prädikates (predicate-uses). Die Fehlererkennungsrate liegt bei diesem Kriterium bei ca. 34%. Es werden insbesondere Kontrollflussfehler erkannt.

All c-uses Kriterium

Unter dem „c-uses-Kriterium“ wird die Berechnung von Werten innerhalb eines Ausdrucks verstanden. Dieses Kriterium deckt ca. 48% aller c-uses-Fehler auf. Es identifiziert insbesondere Berechnungsfehler.

Wegen ihrer Kompliziertheit sind die Techniken zur datenflussorientierten Testfallermittlung nur werkzeuggestützt einsetzbar. Da es aber kaum Werkzeuge gibt (JUnit), haben sie zurzeit kaum praktische Relevanz.

JUnit

JUnit ist ein Framework zum Testen von Java-Programmen, das besonders für automatisierte Unit-Tests einzelner Units (meist Klassen oder Methoden) geeignet ist. Es basiert auf Konzepten, die ursprünglich unter dem Namen SUnit für Smalltalk entwickelt wurden.

Ein JUnit-Test kennt nur zwei Ergebnisse: Entweder der Test gelingt (dann ist er „grün“) oder er misslingt (dann ist er „rot“). Das Misslingen kann als Ursache einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben, die beide per Exception signalisiert werden. Der Unterschied zwischen den beiden Begriffen liegt darin, dass Failures erwartet werden, während Errors eher unerwartet auftreten. Technisch werden Failures mittels einer speziellen Exception namens „AssertionFailedError“ signalisiert, während alle übrigen Exceptions vom JUnit-Framework als Error interpretiert werden.

http://www.junit.org/index.htm