Leistungseffizienz

R 2.2.0

Was ist Leistungseffizienz?

Was ist Leistungseffizienz?

Eine leistungseffiziente Anwendung muss in der Lage sein, eine Erhöhung der Last zu bewältigen, ohne die Benutzerfreundlichkeit zu beeinträchtigen. Umgekehrt muss sie bei einer Verringerung der Auslastung ihre Ressourcen schonen.

Der Grad, zu dem eine Komponente oder ein System Zeit, Ressourcen und Kapazität verbraucht während sie/es seine vorgesehenen Funktionen ausführt. (ISTQB Performanz)

Der Grad, zu dem Mittel verwendet werden im Verhältnis zu den erzielten Ergebnissen. (ISTQB Effizienz)

Anwendungsbeispiel

Anwendungsbeispiel
ALT MISSING

Wieder einmal saßen Eddy und Marion zusammen vor dem Bildschirm. Marions Finger glitten suchend über die Tastatur, einzelne Buchstaben betätigend. Die Suchmaske füllte sich mit einem Vornamen, anschließend einem Nachnamen. Eddy fiel auf, dass immer eine gewisse Zeit verging, nachdem die Taste eines Buchstabens gedrückt worden war, bis diese schließlich auf dem Bildschirm sichtbar war. Nicht viel Zeit, aber doch auffällig. Er machte sich eine Notiz in seinem Beobachtungsbogen. Aber deswegen hatte Marion gar nicht das Ticket eingestellt. „An diese unschöne Verzögerung scheinen sich die Benutzer schon gewöhnt zu haben“, dachte er. „Möglicherweise verstärkt das aber den Eindruck, die Performance der Anwendung ließe zu wünschen übrig.“

ALT MISSING

Denn da lag der Hase im Pfeffer, das war der Grund, warum sich die Sachbearbeiterin seit geraumer Zeit bei der IT beschwerte. Eddy sah wie sich Marions Finger auf die Entertaste senkte. „Peter Müller“ stand im Suchfeld. Das würde eine Vielzahl von Treffern erzeugen und war ein ganz guter initialer Testfall. „Wie viel Peter Müller haben wir in der Testdatenbank?“, fragte er Marion. „Wir erwarten eine Trefferliste mit 43 Einträgen“ gab sie zur Antwort. Eddy starrte auf den Bildschirm. In Gedanken hatte er, nachdem die Suche gestartet worden war, langsam begonnen zu zählen. Auf dem Bildschirm passierte nichts. Nach einer gefühlten Ewigkeit baute sich eine Ergebnisliste auf. 43 Einträge und beim Zählen war Eddy bis 29 gekommen. Dass da aber so rein gar nichts passierte, kein einziger Hinweis für den Benutzer zu erkennen war, war schon ernüchternd. Das hatten sie wohl in den Anforderungen schlicht übersehen.

ALT MISSING

Überhaupt, so hatte er es im Vorfeld schon ermittelt, gab es keine testbaren Anforderungen an das Verhalten der Anwendung, was die Leistungseffizienz betraf. Antwortzeiten, Anzahl gleichzeitig zu bedienenden Benutzern, Nutzerrollen, Leistungsprofile, das alles war nicht näher definiert worden. Ein Versäumnis, das ihnen jetzt klar wurde. Die Stresstests, die sie durchgeführt hatten, hatten keine Auffälligkeiten gezeigt. Aber das Antwortverhalten, dass sich nun in der Beobachtung zeigte, war inakzeptabel. Marions Nackenmuskulatur versteifte sich zusehends. Eddy ahnte, dass ein eventueller Verweis auf nicht vorhandene Anforderungen jetzt bedeutete, Öl ins Feuer zu gießen.

ALT MISSING

Im weiteren Verlauf der teilnehmenden Beobachtung experimentierten sie mit weiteren Suchszenarien und nahmen jeweils die Messwerte auf. Eddy versäumte auch nicht, nach dem Ablauf eines typischen Arbeitstages zu fragen. Da stellte sich heraus, dass die Sachbearbeiter alle in einem bestimmten Zeitfenster ihre Aufgabenliste abriefen, und dass dies regelmäßig zu einem Performanceeinbruch führte.

ALT MISSING

Eddy sammelte alle Daten zur Anzahl der Benutzer, Art und Anzahl der Fachaufgaben sowie die unterschiedlichen Nutzerrollen und -verhalten ein. Anschließend, so dachte er, muss unbedingt ein Architekturreview durchgeführt werden. Er war sich ziemlich sicher, dass der langsame Aufbau der Trefferliste durch geeignete programmatische Ansätze schneller zu bewerkstelligen wäre. Und, so war es ihm klar geworden, musste er sich mit dem Thema Usability auseinandersetzen. „Mit Sicherheit gibt es schon Erfahrungswerte darüber, wie lange ein durchschnittlicher Anwender bereit ist, auf eine Antwort des Systems zu warten.“ Sie waren schließlich nicht die ersten, die für die Abteilung Software schrieben.

Beschreibung

Eine gute Leistungseffizienz zeichnet sich durch eine optimierte Nutzung der verfügbaren Ressourcen aus, um in jeder Situation (Normalnutzung, Stressfall, etc.) in der höchstmöglichen Geschwindigkeit und ohne Vernachlässigung der übrigen Anforderungen (Korrektheit, Verlässlichkeit, Benutzbarkeit etc.) zu arbeiten. Mangelnde Leistungseffizienz hingegen kann negative Auswirkungen auf Softwareprojekte und deren Einsatz haben (z.B. Reputationsverlust, Unzufriedenheit, erhöhte Kosten, Verzögerungen), bis hin zum Ausfall des Systems oder zum Projektabbruch.

Die Leistungseffizienz bei Softwaresystemen setzt sich aus folgenden beiden Merkmalen zusammen:

  • Zeitverhalten (Performanz)

  • Ressourcenverhalten (Verbrauch)

Eine Erhöhung der Last muss einerseits durch das System ohne Einbußen in der Benutzerfreundlichkeit und Reaktionszeit bewältigt werden, bei einer verringerten Last sollen auf der anderen Seite die Ressourcen des Systems nachhaltig geschont werden.

Leistungseffizienz ist eines von mehreren nicht-funktionalen Softwarequalitätsmerkmalen, die nach ISO 25010 durch geeignete Maßnahmen sicherzustellen sind. Es handelt sich dabei nicht um eine einmalige Aktion, sondern um einen fortlaufenden Prozess, der bereits während der frühen Entwicklungsphase einsetzt. Nicht-funktionale Anforderungen, z.B. die maximale Antwortzeit oder die Skalierbarkeit der Architektur müssen bereits zu Anfang im Entwicklungsprozess erfasst werden, da Abweichungen nach Abschluss der Entwicklung nicht mehr oder nur mit sehr hohem Aufwand korrigiert werden können.

Es ist zu erwarten, dass sich bei Änderungen an den fachlichen Bestandteilen der Software auch die Nutzung und Leistung ändern wird. Dadurch werden auch die Leistungsziele im Laufe der Zeit variieren und es sind Vorhersagen nötig, um relevante zukunftsfähige Modelle und Ziele bezüglich der Leistung treffen zu können.

Herausforderungen in Projekten

Leistungseffizienztests der Software sind wichtig, da sie u.a. sicherstellen, dass die erwarteten Serviceniveaus erfüllt werden und ein positives Anwendererlebnis durch die Benutzung bleibt.

Typische Risiken und Fehlerwirkungen in Softwareprojekten, die durch Leistungseffizienztests aufgedeckt werden können, sind z.B. lange Wartezeiten des Nutzers, Systemabstürze oder fehlerhaftes Programmverhalten durch Engpässe im Datenbankzugriff, die zu Inkonsistenzen in der Datenhaltung führen.

Die Verifikation der nicht-funktionalen Anforderungen zur Leistungseffizienz stellt uns in Projekten üblicherweise vor einige Herausforderungen.

  • Testziele und das gewünschtes Verhalten der Software müssen definiert und dokumentiert sein

  • Realitätsnahe Testumgebungen zur praxisnahen Testdurchführung werden benötigt

  • Festlegung und Messbarkeit der Akzeptanzkriterien und Metriken für die nicht-funktionalen Anforderungen

  • Analyse von verschiedenen Nutzungsprofilen der Anwender für den Testentwurf (z.B. durch Workshops, Expertenbefragungen, Analyse vorliegender Daten)

  • Realistische Mengengerüste in Testdaten und -nutzern werden benötigt

Im Vorfeld kommt es häufig dazu, dass die Anforderungen nicht einsatzbereit in einem einheitlichen Spezifikationsdokument vorliegen, sondern vor den Tests separat erhoben bzw. zusammengetragen werden müssen. Mögliche Informationsquellen können Spezifikationen, Workshop-Protokolle, Expertengespräche usw. sein. Falls trotz Analyse keine konkreten Anforderungen und Akzeptanzkriterien ermittelbar sind, müssen Annahmen oder Berechnungen erstellt werden und diese als mögliches Risiko kommuniziert werden.

Die eigentliche Prüfung der Leistungseffizienz erfolgt schließlich in separaten Tests, welche nicht die fachliche Funktionalität, sondern nicht-funktionale Anforderung kontrollieren. Die korrekte fachliche Funktionalität zur sinnvollen Bewertung des Zeitverhaltens des Systems ist idealerweise zu diesem Zeitpunkt bereits vorhanden. Die Bedingungen, unter denen das System getestet wird, sollten im Vorfeld durch sogenannte Nutzungsprofile definiert werden. Diese Profile sind Modelle, die vielfältige Situationen und Benutzerverhalten in der Systemnutzung aus der Praxis repräsentieren. Es sollte früh mit den Tests der Leistungseffizienz begonnen werden, die ggf. durch Mock Objekte unterstützt werden, um zeitnah grundsätzlichen Leistungsproblemen der Software begegnen zu können.

Beide Bereiche (funktional und nicht-funktional) stehen also trotz des häufig getrennten Testvorgehens in unmittelbarer Abhängigkeit zueinander.

Testarten zum Testen der Leistungseffizienz

Performanztests

Testen zur Bestimmung der Performanz eines Softwareprodukts.

Bei Performanztests wird die Zeit gemessen, die benötigt wird, um auf die Eingaben des Anwenders oder des Systems zu reagieren.

Die Annahme dabei ist, dass ein niedrigeres Volumen in der Bearbeitung zu schnellerem Antwortzeitverhalten führen sollte. Nutzungsprofile zu den beteiligten Stakeholdern simulieren modellartig das reale Benutzerverhalten und die damit verbundene Last im Austausch mit dem System.

Lasttests

Eine Art des Performanztests, die das Verhalten einer Komponente oder eines Systems unter wechselnder Last bewertet, üblicherweise zwischen zu erwartender niedriger, typischer sowie Spitzenlast.

Lasttests simulieren die zukünftige Nutzung des Systems unter realistischen und erwarteten Lasten, die zu bewältigen sind. Es kann notwendig sein, diese zu erwartenden Lasten in Form von Annahmen zu berechnen oder zu schätzen. Sie entstehen entweder durch die Interaktion der Anwender mit dem System, z.B. durch Transaktionen zur Datenbank, wie Suchanfragen oder Datenspeicherungen. Auch andere Systeme können Lasten auslösen, etwa durch Datenanforderungen, Batch-Jobs usw. Ziele der Lasttests sind u.a.

  • Mehrere gleichzeitig agierende Anwender bewältigen

  • Sicherstellen der funktionalen Integrität (Sessions)

  • Zeitverhalten des Systems: wie schnell liefert das System Antworten oder wie viele Datensätze werden pro Stunde durch den Batch-Job verarbeitet

  • Ressourcenverhalten des Systems (Netzwerkübertragung, Nutzung anderer Systemressourcen)

Stresstests

Spezifische Form des Performanztests, die durchgeführt wird, um ein System oder eine Komponente an oder über den Grenzen, die in den Anforderungen spezifiziert wurden, zu bewerten.

Die Last, die ein System zu bewältigen hat, wird zum Stress, wenn sie die spezifizierten Grenzen überschreitet.

Ziel des Stresstests ist es, die Grenzen des Systems zu testen, um zu sehen, wie es auf eine hohe Last oder unerwartete Situationen reagiert. Bei einem Stresstest wird die simulierte Last über das im Normalbetrieb erwartete Maß erhöht, bis funktionale Fehler auftreten oder das Antwortverhalten des getesteten Systems bestimmte Grenzen überschreitet. Hierfür wird oft eine kontinuierlich ansteigende Nutzerzahl simuliert. Ziele der Stresstests sind u.a.:

  • Das Wissen, wann das System ausfallen wird, ist u.a. für die Erstellung von Notfallplänen wichtig und wertvoll

  • Erkenntnis gewinnen, ob das System bei übermäßiger Belastung ausfällt, oder eine minimale Leistung erhalten bleibt

Skalierbarkeitstests

Testen zur Bestimmung der Skalierbarkeit eines Softwareprodukts.

Wenn ermittelt werden soll, ob das System nicht nur die aktuellen, sondern auch zukünftige Effizienzanforderungen erfüllen kann, kommen Skalierbarkeitstests zum Einsatz. Systeme im Wirkbetrieb mit Wachstumspotenzial sind betroffen, wie z.B.:

  • Systeme, die nach und nach einer wachsenden Nutzerschaft zur Verfügung gestellt werden (erst Abteilung A, dann B usw.)

  • Systeme, deren Anwenderbasis geschätzt werden muss und bei denen von Wachstum ausgegangen wird (z.B. Internetanwendungen)

  • Systeme, deren Anwenderzahl plötzlich steigen wird (z.B. nach gezielter Marketingaktion)

Tests der Ressourcennutzung

Der Grad, bis zu dem die Ressourcen gemäß den in den Anforderungen definierten Mengen und Arten genutzt werden können, wenn eine Komponente oder ein System ihre bzw. seine Funktionen ausführt.

Die Bewertung des Ressourcenverhaltens (Verbrauch von Speicherplatz, Festplattenkapazität, Bandbreiten im Netz usw.) ist das Ziel dieser Tests. Sie erfolgen i.d.R. zeitgleich mit den o.g. Tests. Die Bewertung der Ergebnisse anhand zuvor definierter Service-Level zeigt die Bedingungen, unter denen Grenzwerte überschritten werden. Bei vernetzten Systemen wird ein hoher Datentransfer im Netz überprüft und darüber hinaus ist eine effiziente Nutzung beschränkter Speicherressourcen von Interesse.

Leistungseffizienztests in der Testplanung

Aufgrund der beschriebenen Notwendigkeit und Wichtigkeit der Leistungseffizienztests sollten diese in der Testplanung und -strategie berücksichtigt werden.

Die geeigneten und beschriebenen Testarten sind in den Testprozess zu integrieren. Die Testaktivitäten zu Leistung, Effizienz und Skalierbarkeit sollten auf möglichst produktionsnahen Umgebungen geplant werden. Empfohlen wird, die zeitliche und organisatorische Planung der Aktivitäten im Testkonzept zu definieren.

Teil der Planung ist es u.a. auch, das Testobjekt festzulegen. Bei den Leistungseffizienztests können unterschiedliche von den fachlichen Tests abweichende Testobjekte identifiziert werden, wie z.B.

  • Abschnitte der Systemarchitektur (Hardware wie Router, Software oder andere Teile wie Firewalls)

  • Gesamtes System (nahe dem Produktivsystem)

  • Einzelne zeitkritische Elemente (Berechnungen müssen z.B. innerhalb einer Zeitspanne erledigt sein)

Zu berücksichtigen ist auch, dass nach der Inbetriebnahme die Leistungseffizienz weiter beobachtet wird. So können beispielsweise steigende Nutzerzahlen, wachsende Datenmengen oder verändertes Nutzerverhalten dazu führen, dass sich Performance oder Anwendungseigenschaften verschlechtern. Somit ist im Sinne einer Regression auch die Durchführung von Leistungseffizienztests einzuplanen.

Quellen