Funktionstest

Prüfkonzepte - Hettwer UnternehmenBeratung GmbH

Ein Funktionsbaustein ist eine erfolgreiche Realisierung der Möglichkeit eines Produkts oder einer Baugruppe, eine betriebswirtschaftliche Aufgabenstellung eigenständig im Dialog oder automatisiert im Kontext eines durchgeführten Batch-Laufs zu erledigen. Von einer einzelnen Routine (Unterprogramm) unterscheidet sich eine solche durch die Tatsache, dass in der Regel viele unterschiedliche individuelle Funktionen zur Ausführung einer oder mehrerer Tasks in der Component zur Verfügung stehen.

Das Ergebnis der Funktionsprüfung ist zu protokollieren. Die Funktionsprüfung umfasst also das Prüfen der einzelnen Funktionalitäten und soll nachweisen, dass alle an die Applikation gestellten Funktionsanforderungen richtig implementiert wurden.

Eine Funktionsprüfung kann auch in Gestalt eines Dynamiktests erfolgen. Dabei werden die Prüffälle über die Funktionsspezifikation des Prüflings abgeleitet. Anhand des Pflichtenheftes kann die Vollzähligkeit der Überprüfung (Abdeckungsgrad) beurteilt werden. Ein negativer Versuch ist ein funktionsfähiger Versuchsfall mit Eingangswerten, die gemäß der Spezifizierung des Prüflings nicht zulässig sind.

Bei einem negativen Test sollte sich herausstellen, dass ein Software-System oder eine Komponenten nicht funktionieren. Einzelne Funktionstests. Ein Funktionsbaustein ist eine funktional erledigte Maßnahme, die vom Sachbearbeiter selbstständig (online) oder automatisiert (Batch) durchgeführt werden kann. Die technische Umsetzung der Funktionalität spielt dabei keine Rolle. Der Funktionstest auf Testebene sollte von der Abteilung erstellt und betreut werden, da die Erstellung der Tests aus betriebswirtschaftlicher Perspektive erforderlich ist.

Damit Prüfungsvorbereitung, -durchführung und -auswertung getrennt von einander stattfinden können, sollte der Funktionstest von einem Prüfteam ausgeführt werden, das sich ausschliesslich mit der Durchführung des Testes auseinandersetzt. Zur frühzeitigen Erkennung konzeptioneller Unterschiede sollte die komplette Aufbereitung des Funktionstestes auf Basis des Pflichtenheftes und der logisch-physikalischen Datenmodelle (Geschäftskonzept) zeitgleich mit der Erarbeitung des IT-Konzeptes und dessen Umsetzung ablaufen.

Entscheidend für den erreichbaren Deckungsgrad ist die Wahl einer speziellen Technologie oder Verfahren. Prüflinge des Funktionstestes sind individuelle Funktionsfunktionen. Aus dem Funktionskonzept oder der Aufgabe sollen die Prüflinge abgeleitet werden. Jede Abteilungsfunktion ist im Grunde genommen ein Prüfobjekt. Es können sich dadurch Regelwidrigkeiten einstellen, um die Verwaltbarkeit der Prüflinge während der Testausführung zu gewährleisten.

Alle Prüflinge in dieser Prüfstufe sind unabhängige Prüfeinheiten und können daher zeitunabhängig geprüft werden. Auch für die Instandhaltung bietet diese eigenständigen Prüflinge einen großen Nutzen, da sich der Arbeitsaufwand der Funktionsprüfung auf die Prüfung der veränderten Prüflinge begrenzt. Zur Beurteilung des Gefährdungspotenzials werden die Prüflinge nach Kritiken kategorisiert.

Die folgenden Beurteilungskriterien werden zur Bewertung der Kritizität herangezogen. Kritizität legt die Prüfmethode des Prüflings fest. Sie legen hier fest, welche Art der Testfallbestimmung, Testdatenbestimmung, Testablauferstellung, Testdurchführung und -auswertung für A-, B- oder C-Testobjekte verwendet werden soll. Die systematische Prüfung erfordert eine lückenlose und aktualisierte Dokumentierung in Gestalt eines technischen und IT-Konzeptes.

Der unsystematische Versuch (ad-hoc oder intuitiv bedienbare Testfallbestimmung) erfordert Expertenwissen über die Applikation. Folgende Verfahren werden für den Funktionstest vorgeschlagen (Methode 10 beinhaltet die Verfahren 3-9) - je größer der Skalierungsgrad, umso stärker die Verfahrensausprägung, umso größer der Erreichungsgrad. Für hochkritische Projekte wird die Methodik 10 für Prüfobjekte der Kritikalitätsstufe A, die Methodik 4 für mittlere Projekte für B-Prüfobjekte angewendet.

Für die Verwendung der Verfahren bei der Testfallbestimmung steht ein Bereich von 10 verschiedenen Skalierungsebenen zur Auswahl. Bei der unsystematischen Testfallbestimmung werden die Ebenen 1 und 2 verwendet und repräsentieren die riskantesten Verfahren. Diese werden nur für Subprojekte mit niedriger Kritizität und nur für nicht-kritische Prüfobjekte verwendet.

Nachdem ein Subprojekt mit einer mittleren Kritizität beurteilt wurde, sollte eine systematische Testfallbestimmung durchgeführt werden. Die systematische Testfallbestimmung unterscheidet 8 verschiedene Möglichkeiten / Skalierungsstufen. Ebenen 3 bis 6: Hier werden die Tests auf der Ebene der Felder mit den Mitteln der Äquivalenzklasseanalyse durchgeführt, aber das Vorgehen ist so beschränkt, dass in Ebene 3 so viele Tests durchgeführt werden, dass mindestens jedes Mussfeld durch den erlaubten Wertbereich gedeckt ist.

Im Schritt 4 wird der Anwendungsbereich der zu berücksichtigenden Eingabefelder um die optionalen Eingabefelder erweitert, d.h. die Tests stellen die positive Verarbeitung der Funktionalitäten für jedes Eingabefeld wenigstens einmal mit einem positivem Ergebnis durchlaufen. Die Ebenen 5 und 6 ergänzen den Anwendungsbereich der Äquivalenzklasseanalyse um einen Fehlertestfall, d.h. es wird gewährleistet, dass Pflichtfeld- und optionale Feldprüfungen auf Wertbereichsebene einwandfrei ablaufen.

Alle Gleichwertigkeitsklassen und alle Kombination von Gleichwertigkeitsklassen, die zu positiver Wirkung führt, werden in Versuchsfällen herangezogen und ggf. durch die Eliminierungsmethode auf eine optimierte Zahl gebracht. Die Vorgehensweise ist unter der Begriffsbestimmung eines Testfalls zusammengefaßt. Dieser Anfangszustand der Prüfdaten umfasst sekundäre Daten, d.h. alle Inventardaten, auf die die zu prüfende Prüffunktion während der Bearbeitung zugegriffen hat, und primäre Daten, d.h. alle Eingangsdaten für Online-Funktionalitäten.

Je nach Verfahren (siehe folgende Abbildung) der Testdatenbeschreibung wird ein Testfall durch eine oder mehrere Testdaten-Kombinationen dargestellt. Für die Definition der Testdaten ist es erforderlich, dass die Testfallbestimmung für das Prüfobjekt und die Organisation der Testdaten für die Testebene vollständig sind und dass das physikalische Modell bzw. die physikalischen Strukturen des Prüfobjekts verfügbar sind.

Nein. Es gibt 5 Verfahren in der Definition der Testdaten. Der niedrigste Level der Ad-hoc-Testdatendefinition stellt die simpelste Variante dar und erfolgt nicht systematisch. Jeder übergeordnete Skalierungsgrad ist eine Art systematische Definition der Testdaten. Wiederum bauen die Verfahren entsprechend den Skalierungsebenen auf, so dass die Absicherung im Versuch auch während der Testausführung gesteigert (oder reduziert) werden kann.

Mindestvoraussetzung ist die Deckung von Vorgabewerten (jede weitere Ebene ist als Zusatz zu betrachten). Eine weitere Absicherung der Grenzwerte, d.h. die Ober- und Untergrenze eines Felds oder einer Gleichwertigkeitsklasse, bieten die nächst höhere Betriebssicherheit. Darüber hinaus können dem Prüffall auch Mittelwerte und in der oberen Variante sogenannte kritische Daten zugeordnet werden.

Je größer der Skalierungsgrad, desto aufwendiger die Vorgehensweise und damit die Sicherstellung. Beim Erstellen von Ad-hoc-Testdaten kann der Sicherheitsbeiwert nicht bewertet werden, da er von der Expertise und dem Erfindungsreichtum des Prüfers abhängt. Wir empfehlen für Subprojekte mit einer hohen Kritizität die Methodik 2, für Prüfobjekte mit einer niedrigen Kritizität die Methodik 3, für Prüfobjekte mit einer mittleren Kritizität die Methodik 5 und für Prüfobjekte mit einer hohen Kritizität die Methodik 5.

Bei Unterprojekten mit Kritikalitätsmedium wird die Bedeckung von Normwerten für niedrig- bis mittelkritische Prüflinge, bei kritischen Prüflingen die Bedeckung von Durchschnittswerten vorgeschlagen. Bei Unterprojekten mit niedriger Kritizität wird die Erfassung von Prüfobjekten mit erhöhter Kritizität vorgeschlagen; bei niedrig- bis mittelkritischen Prüfobjekten ist in der Regel die Ad-hoc-Testdatendefinition ausreichen.

Dies fängt bei der automatischen Testdatenbereitstellung für die Durchführung von manuellen Tests an und reicht bis hin zur vollständigen Automatisierung aller Testausführungsaktivitäten. Sobald genehmigte Geschäftskonzepte zur Verfügung stehen, kann die Testfallfindung gestartet werden. Damit der Test beginnen kann, müssen die Prüflinge den Interfacetest bestanden haben, d.h. die festgelegten Testendekriterien wurden verifiziert.

Deshalb sollte ein Schwellenwert unter Beachtung der Fehlerbewertung definiert werden, wenn ein Versuch mit Erfolg abgeschlossen wurde. Vorzugsweise sollten die Funktionalitäten getestet werden, die die wesentlichen und kritischen Verarbeitungsvorgänge durchlaufen. Beim Funktionstest sollte die Durchführung der Rückführungstests so weit wie möglich automatisiert werden.