Mainframe-Tests – Vollständiges Tutorial

Bevor wir uns mit den Konzepten des Mainframe-Testings befassen, wollen wir uns zunächst die Plattform ansehen, auf der die Tests ausgeführt werden.

Was ist ein Mainframe?

Der Mainframe ist ein Hochleistungs- und Hochgeschwindigkeitsrechner. Er wird für umfangreiche Datenverarbeitungsprozesse eingesetzt, die hohe Verfügbarkeit und starke Sicherheit erfordern. Hauptsächlich findet er Verwendung in Branchen wie dem Finanz- und Versicherungswesen, dem Einzelhandel und anderen kritischen Bereichen, in denen täglich riesige Datenmengen verarbeitet werden.

Mainframe-Tests

Mainframe-Tests Mainframe-Testing ist ein Prozess zum Testen von Softwareanwendungen und -diensten auf Basis von Mainframe-Systemen. Ziel des Mainframe-Testings ist es, die Leistungsfähigkeit, Zuverlässigkeit und Qualität einer Softwareanwendung oder eines Dienstes durch Verifizierungs- und Validierungsmethoden sicherzustellen und zu prüfen, ob diese für den Einsatz bereit sind.

Beim Mainframe-Testing muss der Tester hauptsächlich die Navigation der CICS-Bildschirme beherrschen. Diese Bildschirme sind speziell für bestimmte Anwendungen entwickelt. Wenn Änderungen am Code in COBOL, JCL und ähnlichen Sprachen vorgenommen werden, muss sich der Tester keine Gedanken über die Emulatorkonfiguration auf dem System machen, da Änderungen, die auf einem Terminalemulator funktionieren, auch auf den anderen funktionieren.

• Die Mainframe-Anwendung (auch Job-Batch genannt) wird anhand der mithilfe der Anforderungen entwickelten Testfälle getestet.
• Mainframe-Tests werden normalerweise am bereitgestellten Code durchgeführt, wobei verschiedene Datenkombinationen in die Eingabedatei eingefügt werden.
• Auf Anwendungen, die auf dem Großrechner laufen, kann über einen Terminalemulator zugegriffen werden. Der Emulator ist die einzige Software, die auf dem Client-Rechner installiert werden muss.

Da sich die Plattform anders verhält als ein Web-Stack, ist es hilfreich zu wissen, welche Mainframe-Eigenschaften das Testdesign bestimmen. Mainframe-Testing gehört daher zu den anderen Testbereichen. Arten von Softwaretests anstatt auch nur einen davon zu ersetzen.

Mainframe-Attribute

1. Virtueller Speicher
   • Dabei handelt es sich um eine Technik, mit der ein Prozessor einen Hauptspeicher simulieren kann, der größer ist als die tatsächliche Menge an realem Speicher.
   • Es handelt sich um eine Technik zur effektiven Nutzung des Speichers zum Speichern und Ausführen von Aufgaben unterschiedlicher Größe.
   • Es nutzt Festplattenspeicher als Erweiterung des echten Speichers.
2. Multiprogrammierung
   • Der Computer führt mehrere Programme gleichzeitig aus. Doch zu jedem Zeitpunkt kann nur ein Programm die Kontrolle über die CPU haben.
   • Es handelt sich um eine Einrichtung zur effizienten Nutzung der CPU.
3. Batch Processing
   • Dabei handelt es sich um eine Technik, mit der jede Aufgabe in Einheiten erledigt wird, die als Jobs bezeichnet werden.
   • Ein Job kann dazu führen, dass ein oder mehrere Programme nacheinander ausgeführt werden.
   • Der Job-Scheduler entscheidet über die Reihenfolge, in der die Jobs ausgeführt werden sollen. Um den durchschnittlichen Durchsatz zu maximieren, werden Jobs entsprechend ihrer Priorität und Klasse geplant.
   • Die für die Stapelverarbeitung notwendigen Informationen werden über JCL (Job Control Language) bereitgestellt. JCL beschreibt den Stapelverarbeitungsauftrag – Programme, Daten und benötigte Ressourcen.
4. Zeitteilung
   • In einem Time-Sharing-System hat jeder Benutzer über das Endgerät Zugriff auf das System. Anstatt Aufträge zu übermitteln, die für eine spätere Ausführung eingeplant sind, gibt der Benutzer Befehle ein, die sofort verarbeitet werden.
   • Daher wird dies „Interaktive Verarbeitung“ genannt. Es ermöglicht dem Benutzer, direkt mit dem Computer zu interagieren.
   • Die Time-Sharing-Verarbeitung wird als „Vordergrundverarbeitung“ und die Stapelverarbeitung als „Hintergrundverarbeitung“ bezeichnet.
5. Aufspulen
   • SPOOLing steht für Simultane Peripherie Operations Online.
   • Das SPOOL-Gerät dient zum Speichern der Ausgabe eines Programms oder einer Anwendung. Die gespeicherte Ausgabe wird gegebenenfalls an Ausgabegeräte wie einen Drucker weitergeleitet.
   • Es handelt sich um eine Einrichtung, die den Vorteil der Pufferung ausnutzt, um die Ausgabegeräte effizient zu nutzen.

Klassifizierung manueller Tests im Mainframe

Diese Eigenschaften teilen die manuelle Testarbeit auf dem Großrechner in zwei klar getrennte Ströme auf.

Großrechner Manuelle Prüfung kann in zwei Typen eingeteilt werden:

1. Batch-Job-Tests —

• Der Testprozess beinhaltet die Ausführung von Batch-Jobs für die in der aktuellen Version implementierten Funktionen.
• Die Testergebnisse extracDie aus den Ausgabedateien und der Datenbank entnommenen Daten werden überprüft und protokolliert.

2. Online-Tests —

• Online-Testing bezieht sich auf das Testen von CICS-Bildschirmen, was dem Testen einer Webseite ähnelt.
• Die Funktionalität der vorhandenen Bildschirme könnte geändert oder neue Bildschirme hinzugefügt werden.
• Verschiedene Anwendungen können über Abfragebildschirme und Aktualisierungsbildschirme verfügen. Die Funktionalität dieser Bildschirme muss im Rahmen des Online-Tests überprüft werden.

Wie man Mainframe-Tests durchführt

1. Das Business-Team erstellt Anforderungsdokumente, die festlegen, wie ein bestimmter Artikel oder Prozess im Laufe des Release-Zyklus modifiziert werden soll.
2. Das Testteam und das Entwicklungsteam erhalten das Anforderungsdokument. Sie ermitteln, wie viele Prozesse von der Änderung betroffen sein werden. Normalerweise sind bei einem Release nur 20–25 % der Anwendung direkt von der kundenspezifischen Anforderung betroffen. Die verbleibenden 75–80 % des Release-Aufwands entfallen auf die Standardfunktionalität, wie beispielsweise das Testen der zugehörigen Anwendungen und Prozesse.
3. Daher muss eine Mainframe-Anwendung in zwei Teilen getestet werden:
   • Prüfanforderungen — Testen der Anwendung auf die im Anforderungsdokument erwähnte Funktionalität oder Änderung.
   • Integration testen — Testen des gesamten Prozesses oder anderer Anwendungen, die Daten an die betroffene Anwendung senden oder von ihr empfangen. Regressionstests ist der Hauptschwerpunkt dieser Testaktivität.

Testtools für die Mainframe-Automatisierung

Nachfolgend finden Sie eine Liste der Tools, die für den Mainframe verwendet werden können Automatisierungstests.

• REXX — die mit z/OS ausgelieferte Skriptsprache, die häufig zur Steuerung wiederkehrender Jobübermittlungen und Ausgabeprüfungen verwendet wird.
• Excel — wird zusammen mit Makros verwendet, um Testdaten und Ausgabedateien zu erstellen, zu vergleichen und darüber zu berichten.
• OpenText UFT Eins — die aktuelle Bezeichnung des Werkzeugs, das die Branche immer noch so nennt QTP oder QuickTest Professional; es automatisiert 3270 Terminalbildschirme.
• Galasa — eine Open-Source-Lösung Open Mainframe Project Deep Integration Test Framework das 3270 Bildschirme, JCL-Batch-Jobs und Db2 aus einer CI/CD-Pipeline steuert.
• Hersteller z/OS Test-Suites - IBM Test Accelerator für Z und BMC AMI DevX Total Test deckt COBOL-Unit-Tests und virtualisierte Testumgebungen ab.

Welches Werkzeug auch immer gewählt wird, es zahlt sich nur dann aus, wenn es in einem gewarteten System eingesetzt wird. Testautomatisierungs-Framework eher als ein loser Stapel Skripte.

Methodik beim Mainframe-Testen

Betrachten wir folgendes Beispiel: Die XYZ-Versicherungsgesellschaft verfügt über ein Modul zur Mitgliederregistrierung. Dieses Modul bezieht Daten sowohl von der Mitgliederregistrierungsmaske als auch von der Offline-Registrierung. Wie bereits erwähnt, werden für Mainframe-Tests zwei Ansätze verwendet: Online-Tests und Batch-Tests.

• Die Online-Tests werden auf der Seite zur Mitgliederregistrierung durchgeführt. Genau wie bei einer Webseite wird die Datenbank mit den über die Bildschirme eingegebenen Daten validiert.
• Die Offline-Registrierung kann per Papierformular oder über eine Website eines Drittanbieters erfolgen. Die Offline-Daten (auch als Batch bezeichnet) werden über Batch-Jobs in die Unternehmensdatenbank eingegeben. Eine Eingabedatei wird gemäß dem vorgegebenen Datenformat erstellt und den Batch-Jobs zugeführt. Für Mainframe-Anwendungstests kann daher folgendes Vorgehen verwendet werden.
  • Der erste Job in der Reihe der Stapelverarbeitungsjobs prüft die eingegebenen Daten – beispielsweise Sonderzeichen oder Buchstaben in Feldern, die nur Zahlen enthalten.
  • Der zweite Schritt überprüft die Datenkonsistenz anhand der Geschäftsbedingungen. Beispielsweise sollte die Anmeldung eines Kindes keine Daten von Angehörigen oder eine Postleitzahl enthalten, die vom gewählten Tarif nicht abgedeckt wird.
  • Der dritte Arbeitsschritt formatiert die Daten für die Datenbank. Beispielsweise wird der Planname gelöscht (die Datenbank speichert nur die Plan-ID und den Namen des Versicherungsplans), das Datum der Eingabe angehängt und ähnliche Änderungen vorgenommen.
  • Der vierte Job lädt die Daten in die Datenbank.
• Die Batch-Job-Tests dieses Prozesses werden in zwei Phasen durchgeführt —
  • Jeder Auftrag wird separat validiert, und
  • Die Integration der einzelnen Jobs wird validiert, indem dem ersten Job die Eingabedatei bereitgestellt und die Datenbank validiert wird. (Zwischenergebnisse müssen zur zusätzlichen Sicherheit ebenfalls validiert werden.)

Für Mainframe-Tests wird folgende Methode angewendet:

Schritt 1) ​​Schüttel-/Rauchtest

Der Schwerpunkt dieser Phase liegt auf der Überprüfung, ob der bereitgestellte Code in der richtigen Testumgebung ausgeführt wird. Außerdem wird sichergestellt, dass keine kritischen Fehler im Code vorliegen. Dies entspricht dem Mainframe-Äquivalent von Rauchprüfung auf jeder anderen Plattform.

Schritt 2) Systemtest

Nachfolgend sind die Testarten aufgeführt, die im Rahmen des Systemtests durchgeführt werden.

1. Chargentests — Diese Prüfung erfolgt durch die Validierung der Testergebnisse in den Ausgabedateien und der von den Batch-Jobs im Testbereich vorgenommenen Datenänderungen sowie durch deren Aufzeichnung.
2. Online-Testing — Diese Tests werden im Frontend der Mainframe-Anwendung durchgeführt. Hier wird die Anwendung auf korrekte Eingabefelder wie Versicherungstarif, Zinsen für den Tarif und ähnliche Werte geprüft.
3. Online-Batch-Integrationstests Diese Tests werden auf Systemen durchgeführt, die sowohl Batch-Prozesse als auch eine Online-Anwendung umfassen. Der Datenfluss und die Interaktion zwischen den Online-Bildschirmen und den Batch-Jobs werden validiert.

   (Beispiel für diese Art von Test – Betrachten wir eine Aktualisierung der Plandetails, z. B. eine Zinserhöhung. Die Zinsänderung erfolgt auf einem Aktualisierungsbildschirm, und die Salden der betroffenen Konten werden erst durch einen nächtlichen Batch-Job geändert. Der Test erfolgt in diesem Fall durch Validierung des Plandetails-Bildschirms und des Batch-Job-Laufs zur Aktualisierung aller Konten.)

4. Datenbanktests — Die Datenbanken, in denen die Daten der Mainframe-Anwendung gespeichert sind (IMS, IDMS, Db2, VSAM/ISAM, sequentielle Datensätze, GDGs), werden hinsichtlich ihres Layouts und ihrer Datenspeicherung validiert.

Schritt 3) System Integrationstests

Der Hauptzweck dieser Tests besteht darin, die Funktionalität der Systeme zu validieren, die mit dem zu testenden System interagieren.

Diese Systeme sind von den Anforderungen nicht direkt betroffen. Sie verwenden jedoch Daten des zu testenden Systems. Es ist wichtig, die Anforderungen zu testen. Schnittstelle und die verschiedenen Arten von Meldungen (wie Job erfolgreich, Job fehlgeschlagen, Datenbank aktualisiert), die zwischen den Systemen ausgetauscht werden können, sowie die daraus resultierenden Aktionen der einzelnen Systeme.

Folgende Arten von Tests werden in dieser Phase durchgeführt:

1. Chargentests
2. Online-Testing
3. Online — Batch-Integrationstests

Schritt 4) Regressionstests

Regressionstests sind eine übliche Phase in jedem Testprojekt. Diese Tests auf Mainframes stellen sicher, dass Batch-Jobs und Online-Oberflächen, die nicht direkt mit dem zu testenden System interagieren (oder nicht zum Anforderungsumfang gehören), durch die aktuelle Projektversion nicht beeinträchtigt werden.

Für effektive Regressionstests sollte eine Auswahl von Testfällen anhand ihrer Komplexität getroffen und eine Testfalldatenbank (Repositorie) erstellt werden. Diese Datenbank sollte bei jeder Einführung neuer Funktionen aktualisiert werden. Ist die Testfalldatenbank zu groß für die vollständige Ausführung, Risikobasiertes Testen Wird verwendet, um zu entscheiden, welche Jobs und Bildschirme zuerst erneut ausgeführt werden.

Schritt 5) Performance Testing

Diese Tests dienen dazu, Engpässe in stark frequentierten Bereichen wie der Dateneingabe im Frontend und Online-Datenbankaktualisierungen zu identifizieren und die Skalierbarkeit der Anwendung zu prognostizieren. Langlaufende Batch-Verarbeitungsfenster werden üblicherweise mit folgenden Kriterien untersucht: Belastbarkeitstest im Vergleich zu Spitzenvolumina.

Schritt 6) Sicherheitstests

Diese Tests werden durchgeführt, um zu bewerten, wie gut die Anwendung zur Abwehr von Sicherheitsangriffen konzipiert und entwickelt ist.

Es sollten zweifache Sicherheitstests am System durchgeführt werden – Mainframe-Sicherheit und Netzwerksicherheit.

Folgende Funktionen müssen getestet werden:

1. Integrity
2. Vertraulichkeit
3. Genehmigung
4. Authentifizierung
5. Verfügbarkeit

Schritte beim Batch-Test

1. Nachdem das QA-Team das genehmigte Paket erhalten hat (das Paket enthält Prozeduren, JCL, Steuerkarten, Module und ähnliche Elemente), sollte der Tester den Inhalt bei Bedarf in PDS abrufen.
2. Konvertieren Sie die Produktions-JCL oder Entwicklungs-JCL in QA-JCL, auch Job-Setup genannt.
3. Kopieren Sie die Produktionsdatei und bereiten Sie die Testdateien vor.
4. Für jede Funktionalität wird eine Jobsequenz definiert (wie im Beispiel im Abschnitt „Methodik beim Mainframe-Testing“ erläutert). Die Jobs sollten mit dem Befehl SUB und den Testdatendateien übermittelt werden.
5. Überprüfen Sie die Zwischendatei, um die Gründe für fehlende oder fehlerhafte Daten zu ermitteln.
6. Überprüfen Sie die endgültige Ausgabedatei, die Datenbank und den Spool, um die Testergebnisse zu validieren.
7. Wenn der Job fehlschlägt, kennt der Spooler den Grund für den Jobfehler. Beheben Sie den Fehler und senden Sie den Job erneut.

Testberichte - EIN Defekt Es sollte protokolliert werden, wenn das tatsächliche Ergebnis vom erwarteten Ergebnis abweicht.

Schritte beim Online-Test

1. Wählen Sie den Online-Bildschirm in einem Test Umgebung.
2. Testen Sie jedes Feld auf akzeptable Daten.
3. Testen Sie die Testszenario auf dem Bildschirm.
4. Überprüfen Sie die Datenbank auf dem Online-Bildschirm auf Datenaktualisierungen.

Testberichte — Ein Fehler sollte protokolliert werden, wenn das tatsächliche Ergebnis vom erwarteten Ergebnis abweicht.

Schritte beim Online-Batch-Integrationstest

1. Führen Sie den Job in einer Testumgebung aus und überprüfen Sie die Daten auf den Online-Bildschirmen.
2. Aktualisieren Sie die Daten auf den Online-Bildschirmen und überprüfen Sie, ob der Batch-Job mit den aktualisierten Daten korrekt ausgeführt wird.

Befehle, die beim Mainframe-Test verwendet werden

Diese Schritte werden vom Terminal aus gesteuert, sodass ein kleiner Befehlswortschatz den größten Teil des Arbeitstages eines Testers abdeckt.

1. ABSENDEN — Reichen Sie einen Hintergrundjob ein.
2. ABBRECHEN — Einen Hintergrundauftrag stornieren.
3. ZUWEISEN — Einen Datensatz zuweisen.
4. COPY — Einen Datensatz kopieren.
5. UMBENENNEN — Einen Datensatz umbenennen.
6. LÖSCHEN — Einen Datensatz löschen.
7. Job-Scan — Bindet die JCL an das Programm, Bibliotheken, Dateien und andere Ressourcen, ohne sie auszuführen.

Es gibt viele andere Befehle, die bei Bedarf verwendet werden, aber sie kommen nicht so häufig vor.

Voraussetzungen für den Start von Mainframe-Tests

Folgende grundlegende Details werden für Mainframe-Tests benötigt:

• Login-ID und Passwort für die Anmeldung bei der Anwendung.
• Grundkenntnisse der ISPF-Befehle.
• Namen der Dateien, Dateikennung und Dateitypen.

Vor Beginn der Mainframe-Tests sollten die folgenden Aspekte überprüft werden.

1. Job
   • Führen Sie einen Job-Scan durch (Befehl — JOBSCAN), um vor der Ausführung auf Fehler zu prüfen.
   • Der Parameter CLASS sollte auf die Testklasse verweisen.
   • Leiten Sie die Jobausgabe in den Spooler oder einen JHS um, oder nach Bedarf, indem Sie den Parameter MSGCLASS verwenden.
   • Leiten Sie die E-Mail im Auftrag an den Spooler oder an eine Test-E-Mail-Adresse weiter.
   • Kommentieren Sie die FTP-Schritte für erste Tests aus und verweisen Sie den Auftrag anschließend auf einen Testserver.
   • Falls im Rahmen des Jobs ein IMR (Incident Management Record) generiert wird, fügen Sie den Kommentar „TESTZWECK“ in die Job- oder Parameterkarte ein.
   • Alle Produktionsbibliotheken im Job sollten geändert und auf Testbibliotheken verwiesen werden.
   • Die Arbeit sollte nicht unbeaufsichtigt bleiben.
   • Um zu verhindern, dass der Job im Fehlerfall in einer Endlosschleife läuft, sollte dem Parameter TIME eine bestimmte Zeit hinzugefügt werden.
   • Speichern Sie die Ausgabe des Jobs einschließlich des Spools. Der Spool kann mit XDC gespeichert werden.
2. Reichen Sie das
   • Erstellen Sie nur eine Testdatei in der benötigten Größe. Verwenden Sie gegebenenfalls GDGs (Generation Data Groups – Dateien mit gleichem Namen, aber fortlaufenden Versionsnummern, z. B. MYLIB.LIB.TEST.G0001V00 und MYLIB.LIB.TEST.G0002V00), um Daten in aufeinanderfolgenden Dateien mit demselben Namen zu speichern.
   • Der DISP-Parameter (Disposition – teilt dem System mit, ob der Datensatz nach normalem oder abnormalem Abbruch des Schritts oder Jobs beibehalten oder gelöscht werden soll) für die Dateien muss korrekt codiert sein.
   • Stellen Sie sicher, dass alle für die Jobausführung verwendeten Dateien ordnungsgemäß gespeichert und geschlossen werden, um zu verhindern, dass der Job in den Status „HALTEN“ wechselt.
   • Achten Sie beim Testen mit GDGs darauf, dass die richtige Version verwendet wird.
3. Datenbank
   • Achten Sie bei der Ausführung des Auftrags oder des Online-Programms darauf, dass keine unbeabsichtigten Daten eingefügt, aktualisiert oder gelöscht werden.
   • Stellen Sie außerdem sicher, dass für die Tests die richtige Db2-Region verwendet wird.
4. Testfälle
   • Prüfen Sie stets auf Randbedingungen wie z. B. eine leere Datei, die Verarbeitung des ersten Datensatzes und die Verarbeitung des letzten Datensatzes.
   • Geben Sie immer sowohl positive als auch negative Testbedingungen an.
   • Falls im Programm Standardprozeduren wie Checkpoint-Neustart, Abbruchmodule oder Steuerdateien verwendet werden, binden Sie diese ein. Testfallum zu überprüfen, ob die Module korrekt verwendet wurden.
5. Testdaten
   • Die Einrichtung der Testdaten sollte vor Beginn des Tests erfolgen.
   • Ändern Sie niemals die Daten in der Testregion, ohne andere zu benachrichtigen. Möglicherweise arbeiten andere Teams mit denselben Daten, und deren Tests würden fehlschlagen.
   • Falls die Produktionsdateien während der Ausführung benötigt werden, sollte vor dem Kopieren oder Verwenden eine entsprechende Genehmigung eingeholt werden.

Best Practices

1. Bei einem Batch-Job signalisiert MAX CC 0, dass der Job erfolgreich ausgeführt wurde. Dies bedeutet jedoch nicht, dass die Funktionalität einwandfrei funktioniert. Der Job wird auch dann erfolgreich ausgeführt, wenn die Ausgabe leer ist oder nicht den Erwartungen entspricht. Daher sollten Sie vor der Bestätigung des Erfolgs stets alle Ausgaben prüfen.
2. Es empfiehlt sich, stets einen Probelauf des zu testenden Jobs durchzuführen. Ein Probelauf erfolgt mit leeren Eingabedateien. Dieses Verfahren sollte für alle Jobs angewendet werden, die von den im Testzyklus vorgenommenen Änderungen betroffen sind.
3. Vor Beginn des Testzyklus sollte die Einrichtung des Testjobs rechtzeitig abgeschlossen sein. Dies hilft, JCL-Fehler frühzeitig zu erkennen und somit Zeit bei der Ausführung zu sparen.
4. Beim Zugriff auf Db2-Tabellen über SPUFI (eine Option des Emulators zum Zugriff auf Db2-Tabellen) sollte Auto Commit immer auf „NO“ gesetzt werden, um versehentliche Aktualisierungen zu vermeiden.
5. Die Verfügbarkeit von Testdaten stellt die größte Herausforderung beim Batch-Testing dar. Die benötigten Daten sollten rechtzeitig vor dem Testzyklus erstellt und auf Vollständigkeit geprüft werden. Tracking diese Vorbereitung in einer gemeinsamen Testmanagement Das Repository sorgt für die Abstimmung von Regressionsumgebung und Datenaufbau.
6. Manche Online-Transaktionen und Batch-Jobs schreiben Daten in MQs (Message Queues) für transmitDas Übertragen von Daten an andere Anwendungen kann problematisch sein. Sind die Daten ungültig, kann dies die Message Queues deaktivieren oder stoppen und den gesamten Testprozess beeinträchtigen. Es empfiehlt sich daher, nach dem Testen die korrekte Funktion der Message Queues zu überprüfen.

Herausforderungen und Fehlerbehebung beim Testen von Mainframes

Selbst mit diesen Maßnahmen treten bei fast jeder Mainframe-Version einige Probleme erneut auf. Die folgende Tabelle ordnet jedem Problem den entsprechenden Lösungsansatz zu.

Challenges	Ansatz
Unvollständige/unklare Anforderungen	Es mag zwar Zugriff auf ein Benutzerhandbuch oder eine Schulungsanleitung geben, diese ersetzen jedoch keine dokumentierten Anforderungen. Tester sollten in den Prozess einbezogen werden. Lebenszyklus von Softwaretests ab der Anforderungsphase. Dies hilft zu überprüfen, ob die Anforderungen testbar sind.
Dateneinrichtung / Identifizierung	Es kann Situationen geben, in denen vorhandene Daten je nach Bedarf wiederverwendet werden sollten. Manchmal ist es schwierig, die benötigten Daten aus den vorhandenen Daten zu identifizieren. Für die Dateneinrichtung können je nach Bedarf selbstentwickelte Tools verwendet werden. Um vorhandene Daten abzurufen, sollten Abfragen im Voraus erstellt werden. Bei Schwierigkeiten kann eine Anfrage an das Datenmanagement-Team gestellt werden, um die benötigten Daten zu erstellen oder zu klonen.
Job-Setup	Sobald die Jobs in PDS abgerufen wurden, müssen sie in der QA-Region eingerichtet werden, damit sie nicht mit einem Produktionsqualifizierer oder Pfaddetails übermittelt werden. Zur Vermeidung menschlicher Fehler während der Einrichtung sollten Tools zur Jobeinrichtung verwendet werden.
Ad-hoc-Anfrage	Es kann Situationen geben, in denen End-to-End-Test Aufgrund eines Problems in vorgelagerten oder nachgelagerten Anwendungen ist Unterstützung erforderlich. Solche Anfragen erhöhen den Zeit- und Arbeitsaufwand im Ausführungszyklus. Der Einsatz von Automatisierungsskripten, Regressionsskripten und Gerüstskripten kann helfen, diesen Aufwand zu reduzieren.
Pünktliche Veröffentlichungen für Umfangsänderungen	Es kann vorkommen, dass sich die Funktionsweise des Systems durch Codeänderungen grundlegend verändert. Dies kann Anpassungen an Testfällen, Skripten und Daten erforderlich machen. Ein Prozess für das Änderungsmanagement und eine Folgenabschätzung sollten daher implementiert sein.

Häufige Abende angetroffen

Wenn ein Job fehlschlägt, meldet der Spooler einen Abbruchcode. Die folgende Liste enthält die Codes, die einem Mainframe-Tester am häufigsten begegnen, sowie deren übliche Ursachen.

1. S001 — Es ist ein E/A-Fehler aufgetreten.

   Grund – Lesevorgang am Ende der Datei, Dateilängenfehler oder Versuch, in eine schreibgeschützte Datei zu schreiben.

2. S002 — Ungültiger E/A-Datensatz.

   Grund — Versuch, einen längeren Datensatz als die zulässige Datensatzlänge zu schreiben.

3. S004 — Beim Öffnen ist ein Fehler aufgetreten.

   Grund – Ungültiger DCB.

4. S013 — Fehler beim Öffnen eines Datensatzes.

   Grund — Das PDS-Element existiert nicht oder die im Programm angegebene Datensatzlänge stimmt nicht mit der tatsächlichen Datensatzlänge überein.

5. S0C1 - Operation Ausnahme.

   Grund – Datei konnte nicht geöffnet werden oder DD-Karte fehlt.

6. S0C4 — Schutzausnahme / Speicherverletzung.

   Grund — Versuch, auf einen für das Programm nicht verfügbaren Speicher zuzugreifen.

7. S0C7 — Programmprüfungsausnahme, Daten.

   Grund – Änderung des Datensatz- oder Dateilayouts.

8. Sx22 — Die Stelle wurde storniert.

   Grund — Der Auftrag wurde vor Fertigstellung abgebrochen; die mittlere Ziffer gibt an, wer oder was ihn abgebrochen hat.

9. S222 — Der Auftrag wurde vom Benutzer ohne Dump abgebrochen.
10. S322 — Die Job- oder Schrittzeit hat das angegebene Limit überschritten, das Programm befindet sich in einer Schleife oder der TIME-Parameter ist unzureichend.
11. S522 — TSO-Sitzungstimeout.
12. S806 — Verbindung oder Laden nicht möglich.

    Grund – Der Auftrag konnte das angegebene Lademodul nicht finden.

13. S80A — Nicht genügend virtueller Speicherplatz, um GETMAIN- oder FREEMAIN-Anfragen zu erfüllen.
14. S913 — Versuch, auf einen Datensatz zuzugreifen, zu dessen Verwendung der Benutzer nicht berechtigt ist.
15. Sx37 — Es konnte nicht genügend Speicherplatz für den Datensatz zugewiesen werden.

Fehlerhilfe — Ein sehr beliebtes Tool, um detaillierte Informationen über verschiedene Arten von Abbrüchen zu erhalten.

Häufige Probleme beim Mainframe-Test

• Jobabende Für den erfolgreichen Abschluss des Auftrags sollten Sie die Daten, die Eingabedatei und das Vorhandensein der Module am angegebenen Speicherort überprüfen. Fehler können aus verschiedenen Gründen auftreten, am häufigsten aufgrund ungültiger Daten, eines falschen Eingabefelds, eines Datumskonflikts oder systembedingter Probleme.
• Ausgabedatei leer Auch wenn der Job erfolgreich ausgeführt wird (MaxCC 0), entspricht die Ausgabe möglicherweise nicht den Erwartungen. Daher muss der Tester vor dem Bestehen eines Testfalls die Ausgabe gegenprüfen. Erst dann sollte der Test fortgesetzt werden.
• Eingabedatei leer In manchen Anwendungen werden Dateien von vorgelagerten Prozessen empfangen. Bevor die empfangene Datei zum Testen der aktuellen Anwendung verwendet wird, sollten die Daten gegengeprüft werden, um erneute Ausführung und Nachbearbeitung zu vermeiden.

Häufig gestellte Fragen