© DrHitch/Shutterstock.com
Qualitätssicherung mit JavaScript und PHP

10 Qualitätssicherung in der Praxis


Qualitätssicherung und der verantwortungsbewusste Umgang mit den Informationen, die aus ihr entstehen, ist eine herausfordernde Aufgabe. Die folgenden Kapitel beschäftigen sich vor allem mit den verschiedenen Aspekten der Qualitätssicherung, konkreten Softwaremetriken und deren Wirkung auf ein Projekt. Das Wissen, welche Metriken existieren und wie sie zu deuten sind, ist ein wesentlicher Aspekt der Qualitätssicherung. Aus ihnen leiten sich konkrete Maßnahmen für den Fall ab, dass Werte überschritten werden, die auf eine Fehlentwicklung des Projekts hinweisen.

10.1 Strukturelle Qualität

Der erste Teil dieses Kapitels beschäftigt sich mit der strukturellen Qualität einer Webapplikation. Die strukturelle Qualität sagt nichts darüber aus, wie gut oder schlecht die Anforderungen des Auftraggebers durch das Projekt erfüllt werden. Sie ist ein reiner Indikator darüber, welche Qualität der Quellcode aufweist.

Lines of Code

Die erste und einfachste Softwaremetrik besteht aus den sogenannten „Lines of Code“, kurz LOC. Hier wird lediglich die Anzahl der Zeilen des Quellcodes betrachtet. Damit handelt es sich hierbei um eine rein quantitative Maßzahl. Diese Metrik lässt sich im einfachsten Fall sogar mit Unix Kommandozeilenbefehlen wie „wc“ messen, indem die Zeilen der Quellcodedateien gezählt und aufsummiert werden.

Diese sehr einfache Softwaremetrik besitzt wenig Aussagekraft über das Projekt, da keinerlei Unterscheidung zwischen Programmcode, leeren Zeilen oder Kommentaren gemacht wird. Außerdem gibt diese Metrik lediglich Aufschluss darüber, ob es sich um ein umfangreiches oder eher kleines Projekt handelt, allerdings auch nur auf die Anzahl der Zeilen bezogen. Es wird dabei weder die Komplexität des Quellcodes noch der Funktionsumfang der Software beachtet. Eine Applikation muss nicht nur, weil sie viele Codezeilen umfasst, automatisch besser oder komplexer sein als eine Anwendung, die wesentlich weniger Zeilen umfasst.

Die Lines of Code Metrik beziehungsweise die Gruppe der Metriken, die sich mit dem reinen Umfang einer Software beschäftigt, wird umso sinnvoller, je detaillierter die gesammelten Informationen werden. So bietet sie in der nächsten Stufe, in der zwischen Kommentaren und eigentlichem Quellcode unterschieden wird, bereits um einiges mehr Informationen. Es kann beispielsweise das Verhältnis zwischen Kommentaren und zugehörigem Quellcode gegenübergestellt werden. Viele Anwendungen zur Messung dieser Metriken bieten außerdem die Information über die Anzahl der analysierten Dateien.

Da es sich bei einer Webapplikation in den meisten Fällen um eine Kombination aus mehreren Programmiersprachen wie beispielsweise PHP und JavaScript handelt, muss ein Werkzeug die Lines of Code einer Webapplikation zwischen verschiedenen Sprachen unterscheiden und die jeweiligen Besonderheiten beachten. Die Ausgabe muss hier nach Sprachen aufgeschlüsselt erfolgen.

Es existieren allerdings auch noch wesentlich besser spezialisierter Programme, die nicht nur Informationen über die Anzahl von Quellcodezeilen sammeln, sondern erheblich mehr Informationen wie beispielsweise die Anzahl der Klassen und Methoden liefern.

Aussagekräftige Informationen über eine Applikation erhält man vor allem, wenn man die aus der Messung gewonnenen Rohdaten miteinander kombiniert. Eine Kombinationsmöglichkeit, die bereits vorgestellt wurde, ist das Verhältnis von Kommentarzeilen zu Quellcodezeilen. Dieses Verhältnis sollte bei etwa einer Kommentarzeile zu drei Quellcodezeilen liegen. Dabei wird davon ausgegangen, dass Klassen und Methoden inklusive ihrer Parameter und Rückgabewerte dokumentiert werden. Das Verhältnis trifft eine Aussage darüber, ob der Quellcode ausreichend dokumentiert ist oder nicht.

Eine weitere interessante Kennzahl ist die Länge von Dateien. Hier kann wiederum die durchschnittliche, die minimale und die maximale Länge erfasst werden. Bei der Softwareentwicklung sollte stets darauf geachtet werden, dass Dateien nicht zu umfangreich werden. Je größer eine Datei ist, desto unübersichtlicher und schlechter wartbar wird sie meist. Auch steigt bei sehr langen Dateien die Gefahr, dass der Quellcode übermäßig komplex wird.

Zur Verwendung und Integration von LOC-Werkzeugen lässt sich allgemein sagen, dass sich diese einer sehr großen Beliebtheit auf der Kommandozeile und in der Continuous Integration erfreuen, für PHPStorm ist kein lauffähiges Plugin verfügbar.

CLOC

Ein sehr einfaches Werkzeug, das LOC-Metriken sammelt, ist Count Lines of Code, kurz CLOC. Dieses Programm ist ein in Perl geschriebenes Script. Ein Feature, das dieses Werkzeug sehr interessant macht, ist die Tatsache, dass eine Vielzahl von Sprachen wie beispielsweise PHP und JavaScript unterstützt werden. CLOC gibt an, wie viele Dateien pro Sprache existieren und wie viele Leerzeilen, Kommentarzeilen und Codezeilen jeweils vorhanden sind. Außerdem werden die jeweiligen Kennzahlen sprachübergreifend summiert.

Integration in Jenkins

CLOC lässt sich ohne größere Probleme in Jenkins integrieren. Zu diesem Zweck wird die build.xml-Datei um einen <target>-Abschnitt erweitert. Dieser wird dann in der Konfigurationsoberfläche von Jenkins als Build Step angegeben. Damit ist der erste Teil, die Sammlung der Daten, bereits erledigt. Problematisch ist lediglich die Visualisierung der Ergebnisse. Jenkins stellt nur ein Plugin für das Programm SLOCCount zur Verfügung. Allerdings lässt sich die Ausgabe von CLOC durch ein einfaches Skript in das korrekte Format transformieren.

<target name="cloc">
<exec executable="/opt/cloc/cloc.pl">
<arg value="--by-file" />
<arg value="--xml" />
<arg value="-out=build/cloc.xml" />
<arg value="source" />
</exec>
<exec executable="/opt/cloc/transformSLOCToCLOC">
<arg value="build/cloc.xml" />
<arg value="build/cloc.sc" />
</exec>
</target>

Listing 10.1: Ant-Target zur Einbindung von CLOC

Abb10.1-CLOC.png

Abbildung 10.1: Einbindung einer Ant-Target in Jenkins

Die Visualisierung wird, wie bereits angedeutet, durch das „Jenkins SLOCCount Plug-in“ übernommen. Die Installation erfolgt über „Jenkins“ > „Manage Jenkins“ > „Manage Plugins“. Hier muss lediglich im Tab „Available“ das Plugin aktiviert, die Einstellungen gespeichert und Jenkins neu gestartet werden.

Auf der Einstiegsseite des Projekts ist eine Grafik über die Entwicklung der Codezeilen, aufgeschlüsselt auf die verschiedenen Sprachen, über die letzten Builds verfügbar. Die Detailseite der jeweiligen Builds zeigt, wie viele Zeilen in den verschiedenen Sprachen hinzugekommen beziehungsweise gelöscht wurden. Der Link SLOCCount im jeweiligen Build schließlich führt zu einer Detailseite, auf der eine Aufschlüsselung nach Dateien und Sprachen erfolgt.

phploc

Einen Schritt weiter geht die von Sebastian Bergmann entwickelte Software phploc. Mit ihrer Hilfe lassen sich PHP-Dateien analysieren. Neben den reinen LOC-Metriken erhält der Benutzer hier weitere Informationen über beispielsweise die Anzahl der Klassen, Methoden, Interfaces, Namespaces.

Integration in Jenkins

Das Programm phploc liegt als PEAR-Paket vor und lässt sich mit zwei Kommandos installieren.

pear config-set auto_discover 1
pear install pear.phpunit.de/phploc

Listing 10.2: Installation von phploc

Als Voraussetzung hierfür muss lediglich das PEAR Paket auf dem System installiert sein. Nach der Installation steht phploc als Befehl auf der Kommandozeile zur Verfügung und kann verwendet werden. Der nächste Schritt besteht darin, das Werkzeug in Jenkins einzubinden. Zu diesem Zweck wird die bestehende build.xml-Datei um eine weitere Target erweitert.

<target name="phploc">
<exec executable="phploc">
<arg value="--log-csv" />
<arg value="build/phploc/phploc.csv" />
<arg path="source" />
</exec>
</target>

Listing 10.3: Ant-Target zur Einbindung von phploc

Die Ausgabe des Programms erfolgt im CSV-Format. Die Datei kann im Anschluss dazu verwendet werden, verschiedene Graphen über das „Plot plugin“ zu erstellen. Die entsprechende Konfiguration erfolgt über die grafische Oberfläche beziehungsweise über die zentrale Konfigurationsdatei des Projekts, die config.xml. Diese ist unter „/var/lib/jenkins/jobs/<Projektname>“ zu finden.

<hudson.plugins.plot.PlotPublisher>
<plots>
<hudson.plugins.plot.Plot>
<title>LOC</title>
<yaxis>Code Lines</yaxis>
<series>
<hudson.plugins.plot.CSVSeries>
<file>build/phploc/phploc.csv</file>
<label></label>
<fileType>csv</fileType>
<strExclusionSet>
<string>Lines of Code (LOC)</string>
<string>Comments(CLOC)</string>
<string>Non-Comments(NCLOC)</string>
</strExclusionSet>
<inclusionFlag>INCLUDE_BY_STRING</inclusionFlag>
<exclusionValues>Lines of Code (LOC), Comments (CLOC), Non-Comments (NCLOC)</exclusionValues>
<url></url>
<displayTableFlag>false</displayTableFlag>
</hudson.plugins.plot.CSVSeries>
</series>
<group>phploc</group>
<numBuilds>100</numBuilds>
<csvFileName>phploc.csv</csvFileName>
<csvLastModification>0</csvLastModification>
<style>line</style>
<useDescr>false</useDescr>
</hudson.plugins.plot.Plot>
<hudson.plugins.plot.Plot>

</hudson.plugins.plot.Plot>

</hudson.plugins.plot.PlotPublisher>
</plots>

Listing 10.4: Auszug aus der config.xml zur Visualisierung der phploc-Metriken

Diese Konfiguration sorgt dafür, dass die Ergebnisse von phploc über die letzten 100 Builds in Form eines Liniendiagramms visualisiert werden. Zu diesem Zweck werden die Daten in einer separaten CSV-Datei zwischengespeichert, damit die Grafik unabhängig von den vorgehaltenen Build-Artefakten dargestellt werden kann.

Lint

Lint ist ein klassisches und bereits sehr altes Werkzeug zur statischen Codeanalyse. Ursprünglich stammt die Bezeichnung Lint aus der Zeit, als im C Compiler noch keine vollständige Syntaxprüfung war. Stephen C. Johnson entwickelte Lint, um den Quellcode bereits vor dem Kompilieren analysieren zu können, da ansonsten Syntaxfehler erst bei der Kompilierung auftraten und dieser Vorgang bei mittelgroßen bis großen Applikationen einige Zeit in Anspruch nahm. Aufgrund der Tatsache, dass Compiler mittlerweile eine eigene Syntaxprüfung integriert haben, verlor Lint zunehmend an Bedeutung. Der Ansatz der statischen Syntaxprüfung wurde allerdings in zahlreichen anderen Sprachen aufgegriffen und über verschiedene Werkzeuge umgesetzt.

JSLint

Die bekannteste Umsetzung einer Syntaxprüfung für JavaScript wurde von Douglas Crockford implementiert und trägt den Namen JSLint. JSLint ist aber wesentlich mehr als eine reine Syntaxprüfung. Douglas Crockford hat sich mit seinem Werkzeug zum Ziel gesetzt, die guten Seiten von JavaScript zu fördern und Entwickler dabei zu unterstützen, die schlechten Seiten von JavaScript weitestgehend zu vermeiden. So entstand über längere Zeit ein Werkzeug, das den JavaScript-Quellcode einer Applikation analysiert und nach bestimmten Anti-Patterns durchsucht.

Integration in PHPStorm

JSLint ist sowohl auf der Kommandozeile als auch in vielen IDEs verfügbar. In PHPStorm kann die JSLint-Unterstützung einfach in der Projektkonfiguration aktiviert und konfiguriert werden. Über „Preferences“ > „JavaScript“ > „Code Quality Tools“ > „JSLint“ gelangt man entsprechend dorthin. Einmal aktiviert, prüft JSLint automatisch im Hintergrund jede JavaScript-Datei auf syntaktische Fehler und Anti-Patterns und zeigt diese im Editor auch an.

Wem die Regeln von JSLint zu strikt sind, der kann gewisse Prüfungen in der Konfiguration deaktivieren und so das Verhalten von JSLint entsprechend den Bedürfnissen im Projekt anpassen.

Abb10.2-JSLint-Config.png

Abbildung 10.2: Konfiguration von JSLint in PHPStorm

In der Entwicklungsumgebung werden die Fehler und Probleme, die JSLint festgestellt hat, durch Markierungen am rechten Rand des Fensters dargestellt. Diese Marker enthalten einen Hinweistext mit dem Prefix „JSLint“ und einer Beschreibung des Problems.

Abb10.3-JSLint_Error_fmt.png

Abbildung 10.3: Fehlermeldungen durch JSLint in PHPStorm

Integration in Jenkins

Um JSLint in Jenkins zu integrieren, sind zwei Schritte notwendig. Da JSLint in JavaScript implementiert ist, wird im ersten Schritt eine Kommandozeilenversion der Software benötigt, die entsprechend konfiguriert wird und zum anderen ist ein Plugin zur Visualisierung der Ergebnisse nötig.

Damit JSLint auf der Kommandozeile laufen kann, ist eine Ausführungsumgebung, also eine JavaScript Engine, notwendig. Diese Anforderung kann von Node.js erfüllt werden, einer serverseitigen Engine auf Basis der von Google entwickelten V8 Engine, wie sie auch in Google Chrome zum Einsatz kommt. Eine weitere Möglichkeit ist die Verwendung des Java-Wrappers jslint4java, der seinerseits eine leichtgewichtige JavaScript Engine zur Verfügung stellt. Die einzige Anforderung an das Wrapper-Programm um JSLint ist, dass die Ausgabe zur korrekten Weiterverarbeitung im XML-Format erfolgen muss.

<target name="JSLint">
<apply executable="java" output="${basedir}/build/JSLint/JSLint.xml">
<arg value="-jar" />
<arg value="/opt/JSLint4java/JSLint4java.jar" />
<arg value="--report" />
<arg value="xml" />
<fileset dir="${basedir}/source">
<patternset>
<include name="**/*.js" />
</patternset>
</fileset>
</apply>
</target>

Listing 10.5: Ant-Target zur Einbindung von JSLint

Die zweite Komponente, die notwendig für die korrekte Funktionsweise von JSLint im Zusammenspiel mit Jenkins ist, ist ein Plugin zur Visualisierung. Zu diesem Zweck kann das Violations-Plugin verwendet werden. Es muss lediglich dahingehend konfiguriert werden, dass es die zuvor generierte XML-Datei als Eingabe erhält.

PHPLint

Für PHP existiert eine klassische Syntaxprüfung, die über eine Kommandozeilenoption des Kommandozeilenbefehls „php“ aktiviert werden kann. Als Argument wird hier eine Datei erwartet. Die übergebene Datei wird dann durch den PHP-Interpreter nach Syntaxfehlern durchsucht.

Die Syntaxprüfung ist in diesem Fall vor allem von Vorteil, wenn man den Quellcode nicht direkt testen kann und zumindest ausschließen möchte, dass die Applikation durch einen Syntaxfehler beendet wird. Ein weiteres Einsatzgebiet für PHPLint ist die Syntaxprüfung im Vorfeld von Commits ins Versionskontrollsystem als sogenannter Pre-Commit Hook. Diese Technologie erlaubt es, Commits nach bestimmten Regeln zu filtern und auch Commits abzuweisen. Kombiniert mit der Syntaxprüfung kann so sichergestellt werden, dass nur syntaktisch einwandfreier Quellcode ins Repository geladen wird. Mit Hilfe dieses Werkzeugs werden Syntaxfehler in PHP-Dateien gefunden. Hierunter fallen beispielsweise fehlende Semikolons am Zeilenende.

Integration in PHPStorm

Der Funktionsumfang von PHPStorm schließt eine Syntaxprüfung von PHP-Code mit ein. Hier ist also keine weitere Interaktion des Entwicklers erforderlich. Die Prüfung des Quellcodes erfolgt dabei automatisch während der Eingabe. Tritt im Quellcode ein Syntaxfehler auf, wird dieser durch die IDE erkannt und der Entwickler durch eine visuelle Hervorhebung auf den Fehler aufmerksam gemacht. Wird der Syntaxfehler behoben, wird die Markierung automatisch entfernt. Auch hier ist keine weitere Aktion erforderlich.

Integration in Jenkins

Die Syntaxprüfung von PHP-Dateien ist eine kritische Aufgabe innerhalb der Qualitätssicherung, da durch einen Syntaxfehler die Applikation abgebrochen wird und im schlimmsten Fall wesentliche Teile der Funktionalität nicht zur Verfügung stehen. Aus diesem Grund wird der Ant Task, der für die PHP-Syntaxprüfung verantwortlich ist, so konfiguriert, dass bei einem gefundenen Fehler der Build als nicht erfolgreich gewertet wird. Es existiert kein Plugin, das den speziellen Anforderungen dieses Werkzeugs zur Visualisierung genügt. Die Resultate werden allerdings dennoch über die Konsolenausgabe angezeigt, was dem Benutzer Rückschluss auf den Grund des Fehlschlags gibt.

Code Style

Noch bevor die Arbeit an einem Softwareentwicklungsprojekt begonnen wird, sollte man einen Coding Standard festlegen. Das gilt nicht nur, wenn mehrere Personen an einem Projekt beteiligt sind, sondern auch schon, wenn nur ein Entwickler allein eine Aufgabe erledigt.

Der Coding Standard wird zu Projektbeginn festgelegt und jeder Entwickler sichert zu, dass er diesen Standard über die Projektlaufzeit hinweg respektiert und einhält. Um die Entwickler bei dieser Aufgabe zu unterstützen, existieren die verschiedensten Werkzeuge, die den Quellcode analysieren und dem Entwickler Hinweise zur korrekten Formatierung des Quellcodes geben.

Ein Vorteil, der durch eine einheitliche Formatierung des Quellcodes entsteht, ist, dass er für die Entwickler leichter zu lesen ist. Sind gleichartige Statements stets auf die selbe Art formatiert, erleichtert dies das schnelle Überfliegen des Quellcodes, da hier bereits Verzweigungen und Fallunterscheidungen erkannt werden. Außerdem erzeugt eine einheitliche Formatierung eine gewisse Erwartungshaltung bei den Entwicklern. Ein Beispiel hierfür ist die Einrückung von Quellcode. Gleich eingerückte Statements operieren auf der gleichen Ebene und werden meist nacheinander abgearbeitet. Wird ein Statement weiter eingerückt, deutet dies auf eine Schleife oder eine Verzweigung hin.

Formatierungskonventionen dienen allerdings nicht nur der besseren Lesbarkeit, sondern können auch dazu verwendet we...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang