Klassifikation der Systemtests

↑

▷ Содержание

⇐ ПредыдущаяСтр 10 из 15Следующая ⇒

· Der Systemtest wird in den funktionalen und den nicht funktionalen Systemtest eingeteilt

o Funktionaler prüft die funktionale Anforderungen, Korrektheit und Vollständigkeit

o Nichtfunktionaler überprüft nicht funktionale Anforderungen

§ Sicherheit

§ Benutzbarkeit

§ Interoperabilität

§ Dokumentation

§ Ausfallsicherheit

§ Leistungstests

Regressionstest

· Ist die Wiederholung eines bereits vollständig durchgeführten Systemtests aufgrund von Pflege, Änderung und Korrektur des betrachteten Systems.

· Zweck: sicherstellen, dass das System nicht in einen schlechteren Zustand als vorher zurückgefallen ist.

· Zur Vereinfachung der Testauswertung werden die Ergebnisse des Regressionstests mit den Ergebnissen des vorausgegangenen Tests vergliechen.

Abnahmetest

· Spezieller Systemtest bei dem:

o Der Kunde beobachtet, mitwirkt oder Feder führt

o Die reale Einsatzumgebung beim Kunden verwendet wird

o Und nach Möglichkeit echte Daten des Auftraggebers verwendet werden

· Der Auftraggeber kann Testfälle des Systemtests übernehmen und/oder modifizieren und/oder eigene Testszenarien durchführen, aber

· … die formale Abnahme ist die bindende Erklärung der Annahme (juristisch) eines Produkts durch den Auftraggeber

Testwerkzeuge

Testwerkzeuge für Softwareamateure

· Testen mit Ausgabeanweisungen im Programm

o Drucken Variablen an bestimmten Stellen im Programm aus

o Werden nach Test gelöscht oder auskommentiert

o Besser: per Übersetzerdirektiven zu- und ausschalten

· Testen mit einem interaktiven Debugger

o Haltepunkte festlegen

o Variable interaktiv an den Haltepunkten inspizieren

o Informationen über Untersuchung ist nach Debuggerlauf verloren

· Testen mit Test-Skripten

o Laufen automatisch ab

o Verknüpft mit print-Anweisungen

o Manuelle Überprüfung der Ausgaben

Nachteile dieser Methoden

· Bei Programmänderungen müssen Testfälle wiederholt werden, was dann mühsam und unpraktisch ist

o Ausgabe-Anweisungen sind oft nicht mehr vorhanden

o Wenn doch vorhanden, sind die richtigen Auskommentierungen zu entfernen

o Bei Testen mit Debugger ist keinerlei Information vorhanden, welche Variablen inspiziert werden sollen

· Ergebnisse müssen manuell überprüft werden

o Nur der Programmierer weiß, was die Ausgaben bedeuten und wann sie richtig sind

o Selbst dieser verliert dieses Wissen mit der Zeit

· Es ist unpraktikabel, Testfälle für viele Komponenten zusammenzufassen und gesammelt auszuführen

o Technisch schwierig

o Zu viele Ausgabedaten zu überprüfen

Alternativen

· Benutze Zusicherungen (assert)

· Schreibe automatisch ablaufende Testfälle, die sich selbst überprüfen

· Benutze Prüfprogramme, die Software auf Schwachstellen untersuchen

Zusicherungen

· Boolsche Funktionen

o Vor- und Nachbedingungen

o Invarianten einer Datenstruktur

· Werden zur Laufzeit ausgeführt

· Im Fehlerfall melden sie sich mit Ausnahme oder Fehlermeldung

· Bei Java ab 1.4 sind die assertions eingebaut

· Bei C und C++ mit Makros

· Wichtig: Zusicherungen können zu und abgeschaltet werden

Benutzung von Zusicherungen

· Unerreichbare Codesegmente können mit einer Zusicherung abgesichert werden

· Konvention für öffentliche Methoden

o Überprüfung der Eingabeparameter nicht mit Zusicherungen, sondern mit IllegalArgumentException

o Folge: Klientprogramme können darauf reagieren

· Konvention für private Methoden

o Eingabeparameter, Nachbedingungen und Invarianten aller privater Methoden mit Zusicherungen überprüfen

o Grund: Verletzung ist unerwarteter Defekt

o Aber: Falsche Parameter bei öffentlichen Methoden sind nicht unerwartet

· Mit Zusicherungen können Missverständnisse und Fehlerinterpretationen der Programmierer rasch aufgedeckt werden

· In Produktionsläufen werden Zusicherungen aus Leistungsgründen abgeschaltet (in Java selektiv für einzelne Klassen)

· Bei Auftreten eines Defekts oder beim Testen von Programmänderungen werden die Zusicherungen wieder zugeschaltet

· Zusicherungen sind keine Testfälle

o Es werden nur bestimmte Bedingungen im Programmlauf überprüft

o Sofern sie zugeschaltet sind, werden sie beim Ablauf von Testfällen mit ausgeführt

Automatisch Ablaufende Testfälle JUnit

Prüfprogramme

· Warnungen und defekte

o Werden von DIE angezeigt, z.B. nicht initialisierte Variablen, nicht erreichbare Anweisungen, unnötige Anweisungen

· Programmierstil überprüfen (Checkstyle)

o Einrücken

o JavaDoc

o Kein final usw.

· Defekte anhand von Fehlermustern finden (FindBugs)

Findbugs Muster

· Schlechte Angewohnheiten

o Klasse definiert clone() aber implementiert cloneable nicht

· Korrektheit

o Verwirrende Methodennamen (Methoden unterscheiden über Groß und Kleinschreibung, ist absichtlich oder nicht?)

· Internationalisierung

o toLowerCase kann mit internationalen Schriftsätzen schief gehen

· Code-Angreifbarkeit

o Ein statisches Attribut soll nur im Paket sichtbar sein

· Korrektheit bei mehrfädigen Anwendungen

o Notify() mit notifyAll() ersetzen

· Ausführungsgeschwindigkeit

o toString an einer String ausführen

· Sicherheit

o Leers Kennwort

· Fragwürdiger Code

o Überprüfung Variable aud null, wenn man weiß, dass sie null ist

Познавательные статьи:



Алгоритмические операторы Matlab

Конструирование и порядок расчёта дорожной одежды

Исследования учёных: почему помогают молитвы?

Почему терпят неудачу многие предприниматели?