Um die Parität zwischen einem Altsystem COBOL und seinem Java-Ersatz zu verifizieren, muss ein manueller Tester beide Systeme mit identischen Eingabedatensätzen ausführen und eine Feld-für-Feld-Abstimmung durchführen. Die Methodik umfasst eine stratifizierte Stichprobenentnahme von Datensätzen - wobei hochpreisige Transaktionen, Grenzdaten (z. B. 29. Februar, Jahreswechsel) und Gleitkomma-Grenzfälle priorisiert werden - anstelle eines erschöpfenden Vergleichs. Tester sollten die Ausgaben in neutrale Formate (wie CSV) exportieren und Vergleichswerzeuge verwenden, während sie kritische finanzielle Felder manuell auf Rundungsabweichungen inspizieren. Besonderes Augenmerk muss auf die Julian-Datumskonvertierungen und das Verhalten der gepackten Dezimalarithmetik (COMP-3) im Vergleich zu den IEEE 754 Gleitkomma-Implementierungen gelegt werden. Schließlich dienen die Überprüfung der Prüfziffern und Hash-Vergleiche der gesamten Ausgabedateien als Rauchtest, bevor die detaillierte Feldanalyse beginnt.
In einer multinationalen Bank wurde ich damit beauftragt, die Migration eines nächtlichen Zinsakkumulationsbatchjobs von einem IBM Mainframe-COBOL-System auf einen Spring Boot-Mikroservice, der auf Linux läuft, zu validieren. Das Altsystem hatte über Jahrzehnte Milliarden von Transaktionen verarbeitet, während es COMP-3 gepackte Dezimalarithmetik und Julian-Datumsformate (YYDDD) verwendete, während die neue Java-Anwendung BigDecimal und Standard-Gregorianische Kalender verwendete. Das Kernproblem bestand darin, bitweise identische Ausgaben sicherzustellen; selbst eine einzige Cent-Abweichung bei Millionen von Konten würde einen kritischen finanziellen Defekt darstellen, und subtile Unterschiede in den Rundungsmodi oder Schaltjahresberechnungen könnten zu erheblichen Abweichungen führen.
Eine in Betracht gezogene Lösung war ein brutaler Dateivergleich aller Ausgabedatensätze. Dieser Ansatz bot umfassende Abdeckung und absolute Sicherheit, dass jedes Byte übereinstimmte. Die Vorteile wurden jedoch durch erhebliche Nachteile überschattet: Der Datensatz enthielt über fünfzig Millionen Datensätze, was einen manuellen Vergleich innerhalb des nächtlichen Batchfensters menschlich unmöglich machte, und das schiere Volumen von Rauschen durch erwartete Metadatenunterschiede (wie Zeitstempel) würde tatsächliche Datenfehler verdecken.
Eine andere Option war die einfache zufällige Stichprobe eines festen Prozentsatzes von Datensätzen, sagen wir ein Prozent. Während dies einen statistisch signifikanten Überblick bot und schnell durchzuführen war, waren die Nachteile für die finanzielle Prüfung inakzeptabel: Zufallsstichproben könnten leicht hochwirksame Ausreißer übersehen, wie eine spezifische Kontenart mit einzigartigen Rundungsregeln oder Transaktionen, die am 29. Februar 2024 stattfanden, die historisch Fehler in der Logik zur Julian-Tag-Konvertierung ausgelöst hatten.
Die gewählte Lösung war eine stratifizierte Stichprobenstrategie, kombiniert mit automatisierten Differenzierungsskripten zur manuellen Validierung. Wir kategorisierten die Datensätze nach Risikostufen: Stufe 1 umfasste alle Konten mit einem Saldo von über einer Million Dollar und alle Transaktionen zu Datumsgrenzen (Monatsende, Jahresende, Schaltjahre), während Stufe 2 zufällige Stichproben aus verschiedenen Produkttypen abdeckte. Dieser Ansatz wurde gewählt, da er den Bedarf an absoluter Sicherheit bei hochriskanten Transaktionen mit den praktischen Einschränkungen der manuellen Testzeit in Einklang brachte.
Für Stufe 1 führten wir eine 100%ige manuelle Feldabstimmung mit Beyond Compare und benutzerdefinierten Python-Skripten durch, um Deltas hervorzuheben, während wir für Stufe 2 Aggregationsprüfziffern überprüften und Einzelne Felder stichprobenartig kontrollierten. Das Ergebnis war die Entdeckung eines kritischen Fehlers, bei dem COBOL Zwischenberechnungsergebnisse auf fünf Dezimalstellen abbrach, während die Standarddivision von Java's BigDecimal die Skala unvorhersehbar beibehielt, was eine Abweichung von $0,01 bei hochverzinslichen Konten verursachte. Nach Identifizierung passten wir den Rundungsmodus von Java auf HALF_UP mit expliziter Skala an und erzielten perfekte Parität.
Wie erkennen Sie Kodierungsbeschädigung, wenn Sie festformatierte Dateien validieren, die von EBCDIC nach ASCII migriert wurden?
Viele Tester inspizieren Daten visuell in Texteditoren und übersehen, dass COBOL-Mainframes oft den EBCDIC-Codepage CP037 verwenden, während Java-Systeme UTF-8 verwenden. Sonderzeichen wie Währungssymbole (€, £) oder akzentuierte Buchstaben in Kundennamen können falsch zugeordnet werden. Um dies zu überprüfen, müssen Sie Dateien in einem Hex-Editor öffnen, um die Byte-niveau Darstellungen zu vergleichen und sicherzustellen, dass nachfolgende Leerzeichen in COBOL (oft hex 40) nicht mit Nullterminatoren in Java (hex 00) verwechselt werden und dass gepackte Dezimalfelder (COMP-3) korrekt ohne Sign-Bit-Korruption entpackt werden.
Warum könnten zwei mathematisch äquivalente Berechnungen in COBOL im Vergleich zu Java zu unterschiedlichen Ergebnissen führen, selbst wenn beide "Dezimal"-Typen verwenden?
Kandidaten nehmen oft an, dass BigDecimal identisches Verhalten zu COBOL's gepackter Dezimalzahl gewährleistet. COBOL führt jedoch Basis-10-Arithmetik mit fester Präzision durch, die durch die PIC-Klausel (z. B. PIC 9(9)V99) festgelegt ist, wobei Zwischenergebnisse bei jedem Operation Schritt gemäß den Geschäftsregeln abgeschnitten werden. Java's BigDecimal hingegen behält standardmäßig willkürliche Präzision bei, es sei denn, Sie setzen explizit einen MathContext und RoundingMode. Die Lösung besteht darin, die Abbruchlogik von COBOL zu replizieren, indem Sie die Operationen mit expliziten setScale()-Aufrufen verketten und den alten Rundungsmodus (häufig HALF_UP oder HALF_EVEN) in jedem Zwischenschritt anpassen, nicht nur im endgültigen Ergebnis.
Wie validieren Sie die zeitliche Genauigkeit, wenn das Altsystem die Daylight Saving Time (DST) ignoriert und die neue Java-Anwendung UTC oder lokale Zeit mit DST-Bewusstsein verwendet?
Dies wird oft übersehen, da Tester Zeitstempel oberflächlich vergleichen. Wenn der Altsystem COBOL-Job das ganze Jahr über in EST (Eastern Standard Time) läuft, während der Java-Dienst America/New_York verwendet (der auf EDT umschaltet), haben Transaktionen, die zwischen 2:00 Uhr und 3:00 Uhr am zweiten Sonntag im März stattfinden, einen einstündigen Unterschied. Um dies zu lösen, müssen Tester beide Zeitstempel in ein kanonisches Format (z. B. UTC-Epoch-Millisekunden) während der manuellen Validierung konvertieren, überprüfen, dass die „End-of-Day“-Batch-Cutoff-Parameter (häufig „23:59:59“) konsistent interpretiert werden und sicherstellen, dass die Logik Grenzen von Daten (z. B. „letzter Geschäftstag des Monats“) sich nicht aufgrund der fehlenden Stunde im Frühling oder der zusätzlichen Stunde im Herbst verschiebt.