Bir eski COBOL yığın işlemi ile onun Java yedekleri arasında eşitliği doğrulamak için, bir manuel testçi her iki sistemi de aynı girdi veri setine karşı çalıştırmalı ve alan alanı karşılaştırması yapmalıdır. Metodoloji, yüksek değerli işlemler, sınır tarihleri (örn. 29 Şubat, yıl dönüşleri) ve kayan nokta kenar durumları gibi kayıtların katmanlı örnekleme yapılmasını içerir; tamamen kapsayıcı karşılaştırma yerine. Testçiler çıktıları nötr formatlara (CSV gibi) aktarmalı ve kritik finansal alanları yuvarlama farklılıkları için manuel olarak inceleyerek differansiyon araçları kullanmalıdır. Julian tarih dönüşümleri ve sıkıştırılmış ondalık (COMP-3) aritmetik davranışa ile IEEE 754 kayan nokta uygulamaları arasında özel dikkat gösterilmelidir. Son olarak, tüm çıktı dosyalarının kontrol toplama doğrulaması ve hash karşılaştırmaları, ayrıntılı alan analizine başlamadan önce bir duman testi olarak hizmet eder.
Uluslararası bir bankada, bir gecelik faiz birikim yığın işinin geçişini IBM Mainframe COBOL sisteminden Linux üzerinde çalışan bir Spring Boot mikro servisine doğrulamaktan sorumluydum. Eski sistem on yıllar boyunca COMP-3 sıkıştırılmış ondalık aritmetikle ve Julian tarih (YYDDD) formatlarıyla milyarlarca işlemi işlemişken, yeni Java uygulaması BigDecimal ve standart Gregory takvimlerini kullanıyordu. Temel sorun, bit düzeyinde aynı çıktıyı sağlamaktı; milyonlarca hesap içinde bir kuruşluk bir farklılık bile kritik bir finansal hata teşkil edecekti ve yuvarlama modları veya artış yılı hesaplamalarındaki ince farklılıklar maddi farklılıklara dönüşebilirdi.
Bir çözüm, tüm çıktı kayıtlarının kaba kuvvet dosya karşılaştırmasını düşünmekti. Bu yaklaşım, her baytın eşleştiğinden kesin olan tam bir kapsama sağladı. Ancak, avantajları ciddi dezavantajlarla gölgeleniyordu: veri seti elli milyonun üzerinde kayıt içeriyordu, bu da manuel karşılaştırmayı gece yığın süresi içinde insan açısından imkansız hale getiriyordu ve beklenen meta verilerin (zaman damgaları gibi) gürültüsünün hacmi, gerçek veri hatalarını maskeleyebiliyordu.
Başka bir seçenek, örneğin yüzde bir gibi belirli bir kayıt yüzdesinin basit rastgele örneklemesiydi. Bu, istatistiksel olarak anlamlı bir genel bakış sağlasa da, finansal denetim için kabul edilebilir değildi: rastgele örnekleme, belirli bir hesap türünün özel yuvarlama kuralları veya 29 Şubat 2024'te gerçekleşen işlemler gibi yüksek etkili aykırı değerleri kolayca gözden kaçırabilirdi; bu durum daha önce Julian gün dönüşü mantığında bugları tetikliyordu.
Seçilen çözüm, manuel doğrulama için otomatik differansiyasyon betikleri ile birleşmiş bir katmanlı örnekleme stratejisiydi. Kayıtları risk katmanlarına göre kategorize ettik: Katman 1, bir milyon doları aşan tüm hesapları ve tarih sınırlarında (ay sonu, yıl sonu, artış günü) gerçekleşen tüm işlemleri içeriyordu, Katman 2 ise farklı ürün türlerinden rastgele örnekleri kapsıyordu. Bu yaklaşım, yüksek riskli işlemler üzerine kesinlik ihtiyacı ile manuel test zamanının pratik sınırlamaları arasında bir denge sağladığı için seçildi.
Katman 1 için Beyond Compare ve özel Python betikleri kullanarak %100 alan seviyesi manuel karşılaştırma gerçekleştirdik ve katman 2 için toplu kontrol değerlerini doğrulayıp bireysel alanları kontrol ettik. Sonuç, COBOL'un ara hesaplama sonuçlarını beş ondalık basamakta kestiği, ancak Java'nın varsayılan BigDecimal bölme işleminin ölçeği öngörülemeyen bir şekilde koruduğu ve bu durumun yüksek faizli hesaplar üzerinde 0,01 $'lık bir farklılığa neden olduğu kritik bir hatanın keşfi oldu. Belirlendikten sonra, Java yuvarlama modunu HALF_UP olarak ayarlayıp açık bir ölçek belirleyerek mükemmel eşitlik sağlandı.
EBCDIC'den ASCII'ye geçiş yapan sabit genişlikli dosyaların doğrulanmasında kodlama bozulmasını nasıl tespit edersiniz?**
Birçok testçi verileri metin düzenleyicilerinde görsel olarak incelerken, COBOL ana çerçevelerinin genellikle EBCDIC kod sayfası CP037 kullandığını, Java sistemlerinin ise UTF-8 kullandığını fark etmez. Ödeme sembolleri (€ , £) veya müşteri adlarındaki aksanlı harfler gibi özel karakterler yanlış haritalanabilir. Doğrulamak için, dosyaları bir hex düzenleyicisinde açmalı ve bayt düzeyinde temsilleri karşılaştırmalısınız; COBOL'daki ardışık boşlukların (genellikle hex 40) Java'daki null sonlandırıcılarıyla (hex 00) karıştırılmadığından ve sıkıştırılmış ondalık (COMP-3) alanların doğru bir şekilde açılmadığından emin olmalısınız.
İki matematiksel olarak eşit hesaplama neden COBOL ve Java'da farklı sonuçlar verebilir, her ikisi de "ondalık" türlerini kullansa bile?
Adaylar genellikle BigDecimal'ın COBOL'un sıkıştırılmış ondalık davranışının aynı olduğuna dair bir garanti sunduğunu varsayarlar. Ancak, COBOL PIC ifadesi ile belirlenen (örn. PIC 9(9)V99) sabit hassasiyetle ondalık aritmetik gerçekleştirir ve her işlem adımında ara sonuçları iş kurallarına göre keser. Java'nın BigDecimal'ı, varsayılan olarak, açıkça bir MathContext ve RoundingMode ayarlamadığınız sürece keyfi hassasiyeti korur. Çözüm, COBOL'un kesme mantığını, ara adımlarda her işlem için açık setScale() çağrılarıyla tekrarlayarak ve miras alınan yuvarlama modlarını (genellikle HALF_UP veya HALF_EVEN) her ara adımda eşleştirerek yinelemektir.
Eski sistemin Yaz Saati Uygulaması'nı (DST) dikkate almadığı, yeni Java uygulamasının ise DST farkındalığı ile UTC veya yerel zaman kullandığı durumlarda zaman doğruluğunu nasıl doğruluyorsunuz?
Bu genellikle, testçilerin zaman damgalarını yüzeysel bir şekilde karşılaştırmaları nedeniyle gözden kaçırılır. Eski COBOL işi yıl boyunca EST (Doğu Standart Zamanı) alanında çalışırken, Java servisi America/New_York (ki bu yazın EDT'ye geçiyor) kullanıyorsa, Mart ayının ikinci pazarında 2:00 AM ile 3:00 AM arasında gerçekleşen işlemler bir saatlik bir etkiye sahip olacaktır. Bunu çözmek için, testçiler her iki zaman damgasını da manuel doğrulama sırasında standart bir formata (örn. UTC epoch milisaniyesi) dönüştürmeli, "günün sonu" yığın kesim parametrelerinin (genellikle "23:59:59") tutarlı bir şekilde yorumlandığını doğrulamalı ve tarih sınırları mantığının (örn. "ayın son iş günü") ilkbahardaki kaybedilen saat veya sonbahardaki ekstra saat nedeniyle kaymadığından emin olmalıdır.