Tests


Allgemeiner Hinweis
Informationen in Fragen der Testplanung und -durchführung sowie Toolunterstützung beim Testen bietet das Support-Zentrum Test der PSE.

Wozu testen wir?

  • Um ein System zu erhalten, das so fehlerfrei wie nötig (!) ist
  • Um die Entwickler zu informieren, wie sie Fehler vermeiden können!
  • Um ein "testable design" zu erreichen - ein Design, das überhaupt erst das Auffinden von Fehlern ermöglicht!
  • Um Abweichungen von explizit oder implizit erwarteten Systemeigenschaften festzustellen ("breaking the software")
  • Um dem Management Information über die Qualität eines Systems zu geben - zur Entscheidung über die Verwendung des Systems und seine Weiterentwicklung
  • Um ein System zu validieren, d.h. zu zeigen, daß es einer Spezifikation genügt

[nach B.Beizer, "Black Box Testing", p.7]

Test-Coverage als Testendekriterium
Coverage (Testüberdeckung) ist eine gute Annäherung an die Güte des Tests, aber mit großer Vorsicht zu behandeln. Wichtig dabei ist die Akkumulierung regredierbarer Testfälle aller Art wie z.B.

  • Benutzeroberflächentests formal
  • Zweigüberdeckung im Code via Instrumentierung
  • Funktionale Tests (gemäß Spezifikation, markiert)
  • Anwenderszenarien (Use Cases),...

Nach Kaner (Cem Kaner : 'Testing computer software', Int. Thomson Computer Press, 1993) gibt es ca. 100 verschiedene Coverage-Arten. Über die Testfallarten hat man eine Beziehung zu den wahrscheinlich zu entdeckenden Fehlertypen und damit kann Coverage als Testendekriterium genommen werden.

Die verschiedenen Sichten des Tests auf das Produkt sind wichtig, hingegen ergibt die Berechnung einer Gesamt-Coverage keinen Sinn!

Testbarkeit
Der Aspekt der Testbarkeit - die Möglichkeit der Verifikation der über eine Schnittstelle angebotenen Funktionalität durch eine Teststrategie - sollte in allen Phasen der Software-Entwicklung berücksichtigt werden. Die Entwickler sollten auf Testbarkeit und ausreichende Dokumentation des Code achten. Guidelines dazu werden vom Test Support-Zentrum zur Verfügung gestellt.

Technologiemanagement
Für ein erfolgreiches Projekt muß es einen Mechanismus für die Ermöglichung von ständigen Verbesserungen beim Test geben (‘Fahrplan für ein ‘Test Improvement Road Map’):

  1. Neue Technologien tauchen auf
    • Neue Erkenntnisse bei Tagungen/Workshops?
    • Welche Erfahrungen gibt es -> Test Support-Zentrum?
  2. Bedürfnisse werden ermittelt
    • Welches Modell wird beim Test verwendet z.B. Funktionsnachweismodell: 'Jeder fehlerfreie Testfall erhöht die Qualität des Produkts!'
  3. Praktiken im Projekt werden überprüft
    • Werden Leitfäden verwendet?
    • Können Verfahren verbessert und neue Tools eingesetzt werden?
  4. Alternativen werden ermittelt
    • Welche Leitfäden sollen von Entwicklung/Test verwendet werden?
    • Welche geeigneten Tools sind am Markt verfügbar?
  5. Verbesserungen werden ermöglicht
    • Erlaubt die Termin-Situation eine Verbesserung der verwendeten Praktiken?
    • In welchen Teilprojekten werden die neuen Methodologien, Tools angewandt?
    • Konnte die Effektivität und Effizienz des Tests gesteigert werden?
  6. und dann wieder Punkt 1

Organisatorische und strategische Aspekte beim Test

Bei den Test betreffenden Entscheidungen spielen die Faktoren Zuverlässigkeit, Menge an Features, Projektkosten und Auslieferungsdaten eine große Rolle. Damit der Test genügend Budget zugeteilt bekommt, muß die Arbeit der Tester zu erhöhter Kundenzufriedenheit führen und den Gewinn der Firma steigern helfen. Eine Firma hofft die Qualitätskosten zu reduzieren. Daher ist es Aufgabe des Tests den Nutzen des Tests in Hinblick auf die Reduktion anderer Qualitätskosten herauszustellen.

Ein Beispiel: Kann man nachweisen, daß sich Testautomatisierung bereits nach 3 -5 fiktiven manuellen Tests amortisiert und ca. 50 Regressionstest-Läufe im Software-Lebenszyklus zu erwarten sind, so ist der Aufwand für den Aufbau der Infrastruktur für automatisierte Tests ausreichend begründet.

Qualitätskontrolle des Testens

Ist der Test effektiv, d.h. werden die Fehler gefunden, die gefunden werden sollen? Eine der Maßnahmen ist Error Seeding, d.h. der gewollte Einbau von typischen Fehlern in ausgewählten Moduln, um die Fehleraufdeckungs-Kapazität der Testfälle zu testen.

Workflow im Entwicklungsprozeß

Für einen effizienten Einsatz von Test-Methodologien, -Tools im Entwicklungsprozeß ist die Erstellung eines Workflow-Diagramms erforderlich. Dieses enthält die Daten (e.g. Detailspezifikation), die Aktivitäten (z.B.. Design von Testfällen), Benutzer (Designer, Programmierer, Tester etc.). Im Diagramm werden beginnend mit der Phase Definition bis zum Einsatz alle Beziehungen - z.B.- 'erzeugt', 'benötigt', 'behandelt' etc. - zwischen den Objekten definiert.

Integration des Testens mit anderen Aspekten der Qualitätssicherung

Die folgenden Maßnahmen ändern die Art der auftretenden Fehler:

  • Vorbereiten und Durchführen von Reviews (auch bei Testfall-Design mit der Entwicklung).
  • Aus- und Weiterbildung der Tester
  • Verwendung von adäquaten Methoden und Tools (Design-Tools, Code-Generatoren etc.)
  • Fehlerursachenanalyse (Warum werden bestimmte Fehler erst beim Kunden entdeckt?)
  • Definition von Metriken

"Tester-Thinking"
Um Test-Aufgaben erfolgreich zu bewältigen, ist - analog zum "Programming Thinking" des Entwicklers - ein "Tester Thinking" nötig - mit den Zielen,

  • möglichst effizient Fehler zu finden
  • möglichst systematisch Fehler zu finden
  • möglichst viele Fehler zu finden.

Kaner: 'As a final note, I hope that you'll take a moment to appriciate the richness, multidimensionality, and complexity of what we do as testers'.


Siemens AG Österreich, Programm- und Systementwicklung PSE
Ansprechpartner: stdSEM-Webmaster
Zuletzt aktualisiert am: 07 Juli 1998 13:48
Copyright © Siemens AG Österreich 1997. Alle Rechte vorbehalten.