레거시 COBOL 배치 프로세스와 그 Java 대체물 간의 일치를 확인하기 위해 수동 테스터는 두 시스템을 동일한 입력 데이터셋에 대해 실행하고 필드별 조정을 수행해야 합니다. 이 방법론은 고가치 거래, 경계 날짜(예: 2월 29일, 연도 전환) 및 부동 소수점 엣지 케이스를 우선적으로 고려하여 레코드를 계층화 샘플링하는 것이며, 전면적 비교를 지양합니다. 테스터는 출력을 중립 형식(CSV와 같은)으로 내보내고 차이 비교 도구를 사용하면서 중요한 재무 필드에서 반올림 불일치를 수동으로 검사해야 합니다. 율리우스 날짜 변환 및 패킹된 십진수(COMP-3) 산술 동작과 IEEE 754 부동 소수점 구현 간의 차이를 각별히 주의해야 합니다. 마지막으로, 전체 출력 파일의 체크섬 검증 및 해시 비교는 세부 필드 분석이 시작되기 전의 스모크 테스트 역할을 합니다.
다국적 은행에서 저는 IBM 메인프레임 COBOL 시스템에서 리눅스에서 실행되는 Spring Boot 마이크로서비스로의 야간 이자 발생 배치 작업 이주를 검증하는 임무를 수행했습니다. 레거시 시스템은 수십 년간 COMP-3 패킹된 십진수 산술 및 율리우스 날짜(YYDDD) 형식을 사용하여 수십억 건의 거래를 처리해 왔습니다. 새로운 Java 애플리케이션은 BigDecimal과 표준 그레고리 달력을 사용했습니다. 핵심 문제는 비트 단위로 동일한 출력을 보장하는 것이었으며, 수백만 개 계좌에서 단 1센트의 불일치도 심각한 재무 결함으로 간주되었고, 반올림 방식이나 윤년 계산의 미세한 차이가 물질적인 변동으로 이어질 수 있었습니다.
고려된 하나의 솔루션은 모든 출력 레코드의 강제 파일 비교였습니다. 이 접근 방식은 모든 바이트가 일치한다는 확실성을 제공했으나, 장점이 심각한 단점에 의해 상쇄되었습니다: 데이터셋에는 5천만 개 이상의 레코드가 포함되어 있어 수동 비교는 야간 배치 시간 내에 인간적으로 불가능하며, 예상 메타데이터 차이(예: 타임스탬프)로 인한 다량의 잡음이 실제 데이터 결함을 가릴 것입니다.
또 다른 옵션은 고정 비율의 간단한 무작위 샘플링이었습니다. 예를 들어, 1%. 이는 통계적으로 중요한 개요를 제공하며 빠르게 실행되었으나, 재무 감사에 대한 단점은 용납될 수 없었습니다: 무작위 샘플링은 특정 계좌 유형의 독특한 반올림 규칙이나 2024년 2월 29일에 발생하는 거래와 같은 높은 영향 아웃라이어를 쉽게 놓칠 수 있었습니다. 이로 인해 율리우스 일 변환 로직에서 버그가 발생할 수 있었습니다.
선택된 솔루션은 자동화된 차이 비교 스크립트와 수동 검증을 결합한 계층화 샘플링 전략이었습니다. 우리는 레코드를 위험 계층으로 분류했습니다: Tier 1에는 잔고가 백만 달러를 초과하는 모든 계좌와 날짜 경계(월말, 연말, 윤일)의 모든 거래가 포함되었고, Tier 2는 다양한 제품 유형의 무작위 샘플을 포함했습니다. 이 접근 방식은 고위험 거래에 대한 절대적인 확실성을 필요성과 수동 테스트 시간의 실용적 제약을 균형 있게 유지하기 위해 선택되었습니다.
Tier 1의 경우, 우리는 Beyond Compare와 사용자 지정 Python 스크립트를 사용하여 델타를 강조 표시하면서 100% 필드 수준 수동 조정을 수행했고, Tier 2에서는 집계 체크섬을 확인하고 개별 필드를 샘플링하여 점검했습니다. 결과적으로 COBOL이 중간 계산 결과를 소수점 다섯 자리에서 잘라내는 심각한 결함을 발견했습니다. 반면 Java의 기본 BigDecimal 나눗셈은 스케일을 예측할 수 없게 유지하여 고금리 계좌에서 $0.01의 불일치를 초래했습니다. 식별된 후, 우리는 Java 반올림 모드를 명시적 스케일과 함께 HALF_UP으로 조정하여 완벽한 일치를 달성했습니다.
고정 너비 파일이 EBCDIC에서 ASCII로 이주할 때 인코딩 손상을 어떻게 감지합니까?
많은 테스터가 텍스트 편집기에서 데이터를 시각적으로 검사하여 COBOL 메인프레임이 종종 EBCDIC 코드 페이지 CP037를 사용하고 Java 시스템은 UTF-8을 사용한다는 사실을 놓칩니다. 통화 기호(€, £)나 고객 이름의 억음 문자는 잘못 매핑될 수 있습니다. 확인하려면 헥스 편집기에서 파일을 열어 바이트 수준 표현을 비교해야 하며, COBOL의 후행 공백(종종 헥스 40)이 Java의 널 종료(헥스 00)와 혼동되지 않도록 해야 하고, 패킹된 십진수(COMP-3) 필드가 올바르게 unpacked되어 부호 비트 손상이 발생하지 않는 것을 보장해야 합니다.
왜 두 개의 수학적으로 유사한 계산이 COBOL과 Java에서 "소수" 유형을 사용할 때도 다른 결과를 낼 수 있습니까?
후보자들은 종종 BigDecimal이 COBOL의 패킹된 십진수와 동일한 동작을 보장한다고 가정합니다. 하지만 COBOL은 PIC 절(예: PIC 9(9)V99)에 의해 규정된 고정 정밀도로 10진 산술을 수행하여 각 작업 단계에서 사업 규칙에 따라 중간 결과를 잘라냅니다. Java의 BigDecimal은 기본적으로 임의의 정밀도를 유지하며, 명시적으로 MathContext 및 RoundingMode를 설정하지 않는 한 그대로 처리됩니다. 해결책은 COBOL의 잘라내기 로직을 복제하여 중간 단계에서 명시적인 setScale() 호출을 연결하고 이전 반올림 방식을(종종 HALF_UP 또는 HALF_EVEN) 모든 중간 단계에서 일치시키는 것입니다.
레거시 시스템이 일광 절약 시간(DST)을 무시하는 반면, 새로운 Java 애플리케이션이 UTC 또는 DST 인식 로컬 시간을 사용하는 경우 시간 정확성을 어떻게 검증합니까?
이는 테스터가 타임스탬프를 피상적으로 비교하기 때문에 자주 놓칩니다. 레거시 COBOL 작업이 연중 내내 EST(동부 표준시)에서 실행되는 반면 Java 서비스는 America/New_York를 사용합니다(이 경우 EDT로 전환됨). 3월의 두 번째 일요일 오전 2시와 3시 사이에 발생하는 거래는 한 시간의 차이가 있습니다. 해결책은 테스터가 수동 검증 중에 두 타임스탬프를 정준 형식(예: UTC 에포크 밀리초)으로 변환하고, "일 끝" 배치 컷오프 매개변수(종종 "23:59:59")가 일관되게 해석되고 날짜 경계 로직(예: "월의 마지막 영업일")이 봄에 잃어버린 시간이나 가을에 추가된 시간이 회피되지 않도록 해야 합니다.