OperaBeispiel für einen nationalen Abnahmetest (OAT).

Was ist Operafunktionale Abnahmeprüfung?

OperaNationale Abnahmetests (OAT) Die Betriebsabnahmeprüfung ist eine Softwaretestmethode, die die Betriebsbereitschaft einer Softwareanwendung vor ihrer Produktionsfreigabe bewertet. Ziel der Betriebsabnahmeprüfung ist es, die Konformität des Systems und seiner Komponenten sowie einen reibungslosen Systembetrieb gemäß den Standards sicherzustellen. Operating Environment (SOE).

OperaDie nationale Abnahmeprüfung wird auch als … bezeichnet. OperaBetriebsbereitschaftstest (Operational Readiness Testing, ORT) oder, kürzer, Funktionstest. Alle drei Bezeichnungen beschreiben dieselbe Prüfung: Die Software mag zwar bereits die vom Unternehmen geforderten Funktionen erfüllen, doch niemand hat bisher bewiesen, dass sie von den zukünftigen Nutzern nach der Inbetriebnahme installiert, gesichert, neu gestartet, überwacht und wiederhergestellt werden kann.

Diese Auszeichnung platziert OAT fest unter den nicht-funktionale Tests Es geht um die Art der Systemausprägung. Gefragt wird, wie sich das System unter realen Betriebsbedingungen verhält, und nicht darum, ob eine Funktion die richtige Antwort liefert.

Arten von Operafunktionale Tests

OperaNationale Prüfungen sind eine übergeordnete Aktivität. Jeder der folgenden Punkte stellt eine separate Prüfung mit eigenen Zugangsbedingungen und eigenen Nachweisen dar, und ein vollständiger OAT-Zyklus umfasst in der Regel die meisten davon.

• Installationstest — bestätigt, dass der Build in der Zielumgebung mithilfe der mitgelieferten Dokumentation installiert, aktualisiert und zurückgesetzt werden kann.
• Last- und Leistungstest OperaProduktion — prüft, ob das System unter produktionsähnlichen Bedingungen die erwartete Durchsatzleistung und Reaktionszeiten beibehält. Siehe Leistungstest und Lastprüfung für die zugrunde liegenden Techniken.
• Backup- und Wiederherstellungstests — beweist, dass ein Backup tatsächlich planmäßig erstellt und in einen funktionsfähigen Zustand wiederhergestellt werden kann, und nicht nur auf die Festplatte geschrieben wird.
• Sicherheitstests — überprüft Zugriffskontrollen, Anmeldeinformationen, Zertifikate und die Härtung der Betriebsumgebung. Siehe Sicherheitstests für die detaillierte Methode.
• Code Analyse — eine statische Überprüfung des ausgelieferten Codes und der Konfiguration auf Wartbarkeit und bekannte Schwachstellen, bevor diese zur Produktionslast für jemanden werden.
• Failover-Tests — erzwingt den Ausfall eines Knotens, Dienstes oder Standorts und beobachtet, ob der Standby-Knoten innerhalb der vereinbarten Zeit die Funktion übernimmt.
• Wiederherstellungstests — misst, wie vollständig und wie schnell das System nach einem Absturz wieder betriebsbereit ist. Wiederherstellungstests behandelt die Technik ausführlich.
• Ende zu Ende Test Umgebung Operafunktionale Tests — steuert die gesamte Kette von Servern, Netzwerken, Jobs und Schnittstellen als eine einzige Betriebseinheit.
• Operanale Dokumentation Review — prüft, ob Runbooks, Servicediagramme, Neustartanweisungen und Eskalationspfade mit dem tatsächlich erstellten System übereinstimmen.

Das untenstehende Diagramm gruppiert diese Prüfungen rund um die Veröffentlichung und zeigt den Betriebstest als letzte Hürde, bevor die Anwendung in ihre Live-Umgebung gelangt.

Warum Operafunktionale Tests

OperaOffizielle Tests sind notwendig, weil eine Version, die alle funktionalen Anforderungen erfüllt, dennoch nicht ausgeführt werden kann.

• Während des OAT werden Softwarekonfigurationen und Komponenten für den Betrieb erstmals zusammengeführt.
• Es testet die Implementierung funktionaler oder struktureller Änderungen an einer Software oder einem Dienst in einer funktionalen oder nicht-funktionalen Umgebung.
• Mit diesem Test wird ermittelt, ob eine Anwendung gemäß den Standards der IT Infrastructure Library (ITIL) in einem Netzwerk bereitgestellt werden kann.
• Es gibt Auskunft darüber, ob eine Software so funktioniert, wie sie konzipiert wurde, ohne den Geschäftsprozess zu stören.
• OAT konzentriert sich hauptsächlich auf folgende Aspekte des Softwareprodukts:
  • Elastizität
  • Wiederherstellungsfähigkeit
  • Verwaltbarkeit und Unterstützbarkeit
  • Integrity

Wer tritt auf? OperaNationale Tests und wann

Die Zuständigkeit für OAT unterscheidet sich von allen vorherigen Teststufen, und dieser Unterschied erklärt einen Großteil der Ergebnisse. Die Verantwortlichen sind diejenigen, die nachts um drei Uhr angerufen werden.

• Systemadministratoren und Infrastrukturingenieure — Installations-, Failover- und Neustartfälle in der Zielumgebung ausführen.
• Operationen und Supportteams — Überprüfung der Benachrichtigungen, Schwellenwerte, Eskalationswege und der in den jeweiligen Benachrichtigungen referenzierten Lösungsdokumente.
• Datenbank- und Backup-Administratoren — Datensicherungen erstellen und wiederherstellen, einschließlich der Wiederherstellung an einem zweiten Standort.
• Mitarbeiter für Sicherheit und Compliance — Bestätigung der Härtung, Zugriffskontrolle und Audit-Protokollierung in der realitätsnahen Umgebung.
• Testmanager — Sammeln Sie die Beweise im Go-Live-Entscheidungspaket.

Im Lebenszyklus von SoftwaretestsDie operative Prüfung findet ganz am Ende statt. Systemtests Der OAT (Operational Acceptance Testing) beweist die Funktionsfähigkeit des fertigen Produkts, der Benutzerakzeptanztest die Akzeptanz durch das Unternehmen und der OAT schließlich die Betriebsfähigkeit der Organisation. Da eine produktionsähnliche Umgebung erforderlich ist, wird der OAT üblicherweise nach dem Einfrieren des Release Candidates geplant – jede Codeänderung danach führt dazu, dass der Zyklus von vorne beginnt.

Beispieltestfälle für Operationelles Testen oder OAT

Nachfolgend finden Sie eine praktische Checkliste für den OAT. Jede Zeile ist so formuliert, dass das Ergebnis ein klares „bestanden“ oder „nicht bestanden“ ist, was für ein Go-Live-System erforderlich ist.

1. An einem Standort erstellte Backups können am selben Standort wiederhergestellt werden.
2. An einem Standort erstellte Backups können am anderen Standort wiederhergestellt werden.
3. Die Implementierung neuer Funktionen in die laufende Produktionsumgebung beeinträchtigt die Integrität der aktuellen Produktionsdienste nicht.
4. Der Implementierungsprozess kann mithilfe einer gültigen Dokumentation nachvollzogen werden.
5. Jede Komponente kann innerhalb des vereinbarten Zeitrahmens erfolgreich heruntergefahren und wieder gestartet werden.
6. Bei Warnmeldungen müssen alle kritischen Warnmeldungen an das TEC weitergeleitet werden und das entsprechende Lösungsdokument referenzieren.
7. Es gibt Warnmeldungen, die ausgegeben werden, wenn vereinbarte Schwellenwerte überschritten werden.
8. Sämtliche erstellten oder geänderten Wiederherstellungsdokumente, einschließlich Servicediagramme, sind gültig. Diese sollten an die zuständigen Supportbereiche weitergeleitet werden.
9. Bei jeder von einem Ausfall betroffenen Komponente werden die empfohlene Reihenfolge des Neustarts, die benötigte Zeit und die beteiligten Abhängigkeiten angezeigt.

Eine sinnvolle Ergänzung zur Liste ist der Negativfall: Man unterbricht absichtlich eine Abhängigkeit und überprüft anschließend, ob die Warnung ausgelöst wird, das Runbook gefunden wird und die dokumentierte Neustartreihenfolge den Dienst wiederherstellt. Eine Checkliste, die ausschließlich Erfolge protokolliert, hat den Vorgang überhaupt nicht getestet.

OperaNationales Testen vs. Benutzerakzeptanztest

OAT und User Acceptance Testing Beides sind Abnahmeverfahren und dauern in der Regel länger als geplant, weshalb sie so oft verwechselt werden. Sie beantworten unterschiedliche Fragen und werden von verschiedenen Personen abgezeichnet.

Die beiden ergänzen sich, anstatt Alternativen zu sein. Eine Version, die den Benutzertest (UAT) besteht, aber den Betriebstest (OAT) nicht besteht, funktioniert bis zum ersten Ausfall einwandfrei.

Vorteile und Herausforderungen von Operafunktionale Tests

Teams, die OAT einsetzen, nennen in der Regel dieselben Vorteile und stoßen auf dieselben Hindernisse.

Vorteile

• Das Ausfallrisiko sinkt, da Wiederherstellungs- und Ausweichmechanismen getestet werden, bevor die Kunden darauf angewiesen sind.
• Die Supportteams erhalten Dokumentationen, die sich im realen System bewährt haben und nicht auf der Grundlage der Konstruktionsplanung erstellt wurden.
• Überraschungen bei der Bereitstellung treten in einem kontrollierten Zeitfenster auf, anstatt in der Nacht der Inbetriebnahme.
• Die Erstellung von Nachweisen zur Einhaltung der Vorschriften und zur Durchführung von Audits erfolgt als Nebenprodukt der Checkliste.

Challenges

• Eine produktionsnahe Umgebung ist teuer, und eine verkleinerte Kopie verbirgt genau die Fehler, die OAT eigentlich aufspüren soll.
• Der Zyklus konkurriert mit der Veröffentlichung um denselben Kalenderplatz und wird daher als erste Aktivität gestrichen, wenn ein Termin verschoben wird.
• Destruktive Vorgänge wie Failover und Wiederherstellung erfordern Genehmigungen und ruhige Zeitfenster, die schwer zu erhalten sind.
• Die Ergebnisse hängen vom Betriebspersonal ab, das gleichzeitig den laufenden Live-Service betreut.

Üblicherweise beginnt man klein: Zuerst sollten die Backup- und Wiederherstellungsvorgänge sowie die Neustarts automatisiert werden, da sie sich bei jedem Release wiederholen und das eindeutigste Signal für Erfolg oder Misserfolg liefern. Anschließend kann die Checkliste mit jedem Zyklus erweitert werden, und jede Änderung an den Runbooks wird zu einem Kandidaten für eine solche Automatisierung. Regressionstests in der nächsten Version.

Häufig gestellte Fragen