Vom Wiegen wird die Sau nicht fett: PL/SQL-Qualitätsanalysen

Größe: px

Ab Seite anzeigen:

Download "Vom Wiegen wird die Sau nicht fett: PL/SQL-Qualitätsanalysen"

Brigitte Maya Dieter
vor 6 Jahren
Abrufe

1 Vom Wiegen wird die Sau nicht fett: PL/SQL-Qualitätsanalysen Dr. Elmar Jürgens TU München & CQSE GmbH München Abstract Für Programmiersprachen wie Java oder C# gibt es eine Vielzahl von Qualitätsanalysen: Architektur- Konformitätsanalysen erkennen Verletzungen der Soll-Architektur im Code. Clone Detection erkennt Copy-Paste-Programmierung und damit zukünftige Wartungsprobleme. Strukturanalysen erkennen unverständliche Quelltextabschnitte. Und es gibt noch viele weitere Beispiele. Richtig eingesetzt erkennen Qualitätsanalysen Probleme früh, wenn ihre Behebung noch kostengünstig ist. Ich bin seit zehn Jahren in der Forschung, Entwicklung und im Praxiseinsatz solcher Analysen beschäftigt. In den letzten Jahren arbeite ich auch vermehrt mit Teams zusammen, die PL/SQL verwenden. Im Vortrag möchte ich einerseits verschiedene statische und dynamische Qualitätsanalysen vorstellen und dabei auf der Basis von Forschungsergebnissen sinnvolle von nutzlosen Analysen unterscheiden. Andererseits möchte ich unsere Lessons Learned aus unterschiedlichen Domänen und Teams vorstellen, die gerade bei der Einführung derartiger Analysen bei historisch gewachsener Software helfen und konkrete Tipps zum eigenen Einsatz geben. Schlüsselworte Softwarequalität, statische Analyse, dynamische Analyse, technische Schulden, Forschung, Praxis. Inhalte des Vortrags Sinn und Unsinn von KPIs für Softwarequalität Clone Detection Test-Gap-Analyse Wirksamer Einsatz von Qualitätsanalysen in der eigenen Entwicklung Best Practices und Lessons Learned Die folgenden Seiten geben einen Überblick zu Clone Detection und Test-Gap-Analyse.

2 Clone Detection Auch PL/SQL bietet Abstraktionsmechanismen, um uns Wiederverwendung zu erleichtern. Trotzdem ist Copy & Paste weit verbreitet. Oft wird einfach schnell ein existierendes Codefragment kopiert und geringfügig angepasst, anstatt eine Funktion zu erstellen, über die man die gewünschte Funktionalität wiederverwenden könnte. Abb. 1: Duplizierter PL/SQL-Quelltext. Was kurzfristig als gute Idee erscheint, führt langfristig zu Mehraufwänden, da Änderungen in der Regel nicht nur an einer Stelle, sondern an allen sogenannten Klonen vorgenommen werden müssen. Werden dabei Klone übersehen, führen die resultierenden Inkonsistenzen oft zu Fehlern. Tatsächlich enthalten viele Softwaresysteme 20-30% geklonten Code, in manchen Fällen sind es sogar 50% oder noch mehr. Da es in großen Softwaresystemen unmöglich ist, manuell einen Überblick über existierende Klone zu behalten, sind Entwickler auf Werkzeugunterstützung angewiesen. Clone-Detection-Werkzeuge erkennen Klone in existierender Software sie können dadurch den Umgang mit existierenden Klonen erleichtern und die Entstehung von neuen eindämmen. In diesem Vortrag zeige ich Beispiele von Klonen und dadurch entstandene Fehler in produktiver Software, stelle Clone-Detection für PL/SQL vor und diskutiere Best-Practices und Grenzen des Einsatzes von Clone-Management in der Praxis. Die Abbildungen auf der folgenden Seite visualisieren die Problematik von dupliziertem Quelltext in der Praxis. Es handelt sich dabei um Beispiele aus Systemen, die wir selbst analysiert haben, nicht um hypothetische Schaubilder.

Um das kenntlich zu machen, sind die Fragmente er in der gleichen Farbe (rot) hinterlegt.

3 Jeder Buchstabe Quelltext ist nur noch als ein einzelner Pixel dargestellt. Ganz links sind zwei Code-Fragmente dupliziert. Um das kenntlich zu machen, sind die Fragmente er in der gleichen Farbe (rot) hinterlegt. In dieser Abbildung sind alle duplizierten Bereiche farblich hinterlegt. Die Farbe ist zufällig gewählt, aber immer, wenn zwei oder mehr Regionen die gleiche Hintergrundfarbe haben, enthalten sie duplizierten Quelltext.

Test-Gap-Analyse Bei großen Systemen stehen einem Tester oder Testmanager selten genug Ressourcen zur Verfügung, um die gesamte Funktionalität vollständig zu testen.

4 Test-Gap-Analyse Bei großen Systemen stehen einem Tester oder Testmanager selten genug Ressourcen zur Verfügung, um die gesamte Funktionalität vollständig zu testen. In der Praxis müssen wir uns in jeder Testphase daher notwendigerweise auf einen Ausschnitt aller möglichen Tests beschränken. Die Frage, wie man diese auszuführenden Tests möglichst sinnvoll auswählt, beschäftigt seit Jahrzehnten ein eigenes Forschungsgebiet. Ein zentrales Ergebnis der Arbeiten der letzten Jahre ist, dass typischerweise in denjenigen Bereichen die meisten Fehler auftreten, in denen in letzter Zeit (z.b. seit dem letzten Release) am meisten geändert wurde. Daher sollte im Rahmen der Qualitätssicherung der Testaktivitäten überprüft werden, ob alle relevanten Änderungen auch getestet wurden. Diese Aufgabe wird erfahrungsgemäß umso wichtiger, je größer Systeme (und damit je unübersichtlicher Änderungen und Testaktivitäten) werden. Um Tester und Testmanager bei dieser Überprüfung zu unterstützen, haben wir in den letzten Jahren die Test-Gap-Analyse entwickelt, die ermittelt, welche Änderungen noch ungetestet sind. Test-GapAnalyse wird inzwischen von vielen Firmen eingesetzt. Ein typisches Ergebnis von Test-Gap-Analyse ist in der folgenden Abbildung dargestellt. Jedes weiß umrandete Rechteck beschreibt eine Komponente im System under Test, jedes darin enthaltene kleinere schwarz umrandete Rechteck eine Prozedur. Der Flächeninhalt der Rechtecke korrespondiert mit der Größe der dazugehörigen Prozeduren in Lines of Code. Prozeduren, die sich

5 seit dem letzten Release nicht verändert haben, werden grau dargestellt, veränderte farbig. Nur wenn die veränderten Methoden grün dargestellt werden, sind sie im Test durchlaufen worden. Die roten und orangenen Bereiche zeigen Methoden, die seit dem letzten Release neu entwickelt oder verändert, aber noch nicht getestet wurden. Test-Gap-Analyse ermöglicht es Testern und Test-Managern, eine bewusste Entscheidung zu treffen, ob Änderungen vor einem Release nachgetestet werden sollen. Bio: Dr. Elmar Jürgens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst-Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH und begleitet seit acht Jahren Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Jürgens spricht regelmäßig auf Konferenzen wie dem QS-Tag, W-JAX, JAX, OOP, Teamconf, DWX, ICSE, CSMR, SQD oder den XP Days. Er wurde von den Teilnehmern zum besten Sprecher der Clean Code Days 2014, der Software Quality Days 2015, dem Java Forum 2015 und dem QS-Tag 2016 gewählt. Elmar Jürgens wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt. Kontaktadresse: Dr. Elmar Jürgens CQSE GmbH Lichtenbergstr. 8 D Garching bei München Telefon: juergens@cqse.eu Internet:

Ähnliche Dokumente

Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse in der Praxis

Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse in der Praxis Elmar Jürgens CQSE GmbH juergens@cqse.eu Dennis Pagano CQSE GmbH pagano@cqse.eu Zusammenfassung Bei langlebiger Software