Dijital dönüşüm sürecinde olan işletmeler, genellikle görev kritik çekirdek bankacılık işlemlerinin on yıllık COBOL ana makineleri aracılığıyla IBM z/OS sistemlerinde işlendiği karmaşık "brownfield" ortamlarında faaliyet göstermektedir. Aynı anda, müşteri odaklı kayıt ve hizmet akışları giderek daha fazla modern React tabanlı web portalları ve mobil uygulamalar tarafından yönetilmektedir. Bu teknolojik farklılık, QA ekiplerinin, temel olarak farklı mimariler arasında hatasız veri akışı ve işlemsel tutarlılığı sağlamak zorundadırlar, dolayısıyla önemli bir doğrulama zorluğu yaratmaktadır.
Geleneksel olarak, bu tür ortamlardaki otomasyon çabaları, ana makine terminal emülasyonu (Jagacy veya Extra! gibi), genel UI otomasyonu (Selenium veya Cypress) ve API doğrulaması (Rest-Assured veya Postman) için ayrı araç setleri oluşturan uzman ekiplerle yoğun bir şekilde bölünmektedir. Bu parçalanma, teknik jargonla yazılmış kırılgan entegrasyon paketlerinin ortaya çıkmasına yol açmaktadır ki bunlar, teknik olmayan iş analistlerinin gereksinimleri gözden geçirememesi veya doğrulayamaması anlamına gelmektedir. Ayrıca, bir test çalışması sırasında başarısız olduğunda sıklıkla felaket veri bütünlüğü sorunları ortaya çıkmakta, bu durum bir ana makine hesabının oluşturulmasına rağmen ilgili web portalı doğrulamasının tamamlanmaması sonucunda aşağı akış ortamlarının orjinal test verisi ile kirlenmesine yol açmaktadır.
Bu özel soru, mobil bir React uygulaması, bir Kafka olay ağı, bir Java mikroservis katmanı ve nihai hesap tahsisi için bir IBM z/OS ana makineleri arasındaki karmaşık "yeni müşteri kaydı" iş akışını doğrulama zorluğu yaşayan bir Fortune 500 finansal hizmetler firması tarafından ortaya çıkmıştır. Kuruluş, bu teknik bölünmeleri köprüleyecek ve modern DevOps boru hatlarında beklenen çevikliği koruyacak birleşik bir otomasyon stratejisi gerekmekteydi. Zorluk, iş analistlerinin her sistemin altyapı uygulamalarını anlamadan test senaryolarını yazması ve anlaması gerekliliğiyle daha da karmaşık hale gelmiştir.
Temel zorluk, senkronize web otomasyonu ile 3270 ana makinelerinin blok modda terminal emülasyonundaki temel uygulama uyumsuzluğu ile ilgilidir; senkronize web otomasyonu, anında DOM güncellemeleri ve olay odaklı etkileşimler beklemektedir. RESTful API’ler, oturum sürekliliğinin bulunmadığı, durumsuz istek-yanıt paradigmasında çalışarak daha fazla karmaşıklık getirmektedir. Bu mimari stiller arasında köprü kurmak, yüksek düzeyde iş eylemlerini sistem özel komutlarına çevirebilen bir soyutlama katmanını gerektirmektedir, bu katman test senaryolarına teknik implementasyon ayrıntıları sızdırmamalıdır.
Birleşik bir Alan Özel Dili (DSL) sürdürmek, test adımlarının teknik uygulamalarının sistemler arasında o kadar çok ayrıştığı zaman, Gherkin gibi araçlar kullanıldığında son derece zor hale gelmektedir. Web elemanları genellikle CSS seçicileri veya XPath ifadeleri kullanılarak tanımlanırken, API doğrulamaları JSON yolı doğrulamaları ve şema doğrulamasına dayanır; buna karşılık ana makine etkileşimleri alan koordinatları, ekran etiketleri veya F1 gibi belirli tuş dizileri gibi spesifik arayüzlere dayanır. Güçlü bir soyutlama stratejisi olmadan, DSL hızlı bir şekilde teknik yerleştiriciler ve sistem özel jargon ile dağılır, bu da iş ve teknik paydaşlar arasında bir iletişim aracı olarak amacını bozar.
Ayrıca, bu dağıtım sistemleri arasında gerçek işlemsel bütünlüğü garanti etmek, test çerçevesi mimarisi içinde bir Saga veya Telafi İşlemi örüntüsünü doğrudan uygulamayı gerektirir; bu, test katmanının ana makinelerin iki aşamalı komite protokolleri veya dağıtılmış işlem yöneticilerine yerel bağlantılarının olmadığı durumlarda oldukça basit değildir. Ana makine işlemi zaten onaylandığında bir test hatası web portalında meydana geldiğinde, çerçevenin çevresel tutarlılığı sağlamak için açık geri alma prosedürlerini tetikleme yeteneğine sahip olması gerekir. Bu, standart try-catch bloklarının çok ötesinde karmaşık durum izleme ve hata işleme mekanizmalarını gerektirir.
Son olarak, otomasyon çerçevesi, hassas kimlik bilgilerini test betiklerine doğrudan gömmekten kaçınarak, farklı kimlik doğrulama mekanizmalarını güvenli bir şekilde yönetmelidir. Web portalları, genellikle Çok Faktörlü Kimlik Doğrulama (MFA) ile modern OAuth2 veya SAML akışlarını kullanırken, REST API'leri API anahtarları veya JWT jetonları kullanır; miras ana makineleri ise statik kullanıcı profilleri kullanarak RACF veya ACF2 sağlayıcılarına karşı kimlik doğrulaması yapar. Bir merkezi, şifrelenmiş kimlik bilgisi kasası, ortam spesifik enjekte etme yetenekleri ile birlikte güvenlik duruşunu korumak ve etkin bir sistemler arası kimlik doğrulamayı sağlamak için gereklidir.
Bu karmaşıklıkları ele almak için çerçeve, Hexagonal Mimari (Portlar ve Adaptörler) desenini kullanarak, test alanı mantığı ile dış sistem etkileşimleri arasında katı bir ayrım dayatacak şekilde tasarlanmalıdır. enterCustomerData(), verifyAccountCreation() ve rollbackTransaction() gibi yüksek seviyeli alan yöntemlerini tanımlayan soyut bir ApplicationDriver port arabirimi tanımlayın. Bu arabirim, DSL katmanınızın (Cucumber Adım Tanımları veya SpecFlow Bağlantıları gibi) etkileşime girmesine izin verilen tek sözleşmedir ve böylece uygulama spesifiklerinden tam bir izolasyon sağlanır.
Somut adaptör uygulamaları, sistem özel teknik detayları ile ilgilenir: SeleniumWebAdapter, port yöntemlerini tarayıcı etkileşimlerine çevirirken; RestAssuredAdapter, HTTP çağrılarını gerçekleştirir ve JSON yanıtlarını ayrıştırırken; HllapiMainframeAdapter, tuşları göndermek, ekran tamponlarını okumak ve 3270 emülatöründe alan içeriklerini doğrulamak için Yüksek Düzey Dil API’sini kullanır. Her bir adaptör, kendi teknoloji yığınına uygun tekrar deneme mantığı, açık bekleme mekanizmaları ve hata işleme stratejileri kapsar. Bir adaptör, durumu değiştiren bir işlemi başarılı bir şekilde tamamladığında, ilkel veri türleri döndürmek yerine, merkezi TestEventBus 'a bir alan olayı yayımlar (örneğin, AccountCreatedEvent).
İşlemsel bütünlük için, test senaryosunda gerçekleştirilen tüm CompensableAction nesnelerinin sıralı bir günlüğünü tutan bir Test Saga Orkestratörü uygulayın. İş akışındaki herhangi bir adım bir istisna ile başarısız olursa, orkestratör daha önce başarılı olan işlemlerin compensate() yöntemini ters sırayla otomatik olarak çalıştırır ve böylece ana makine hesabını silmek veya API rezervasyonunu iptal etmek için bir telafi işlemi gerçekleştirir. Bu, test ortamının, uygulamanın kendi nihai tutarlılık modelini yansıtan bir yaklaşım ile, uçtan uca testlerin hatalı olduğu durumlarda bile temiz kalmasını sağlar.
Heterojen yığın boyunca durum yönetimi, TestContext 'i birincil bir varlık olarak ele alarak ThreadLocal<DomainContext> kullanarak zengin alan nesnelerini depolamakla sağlanır; bu şekilde, test adımları arasında sıkı bir bağımlılık önlenir. React adaptörü, bağlamda bir CustomerProfile nesnesini doldurabilir; bu, ana makine adaptörü tarafından iş akışının kendi kısmını gerçekleştirmek için alınır. Bu yaklaşım, DSL'nin, oturum kimlikleri veya ekran koordinatları gibi teknik tanımlayıcılara odaklanmasını sağlar.
Bu bileşenleri bir araya getirmek için, Google Guava EventBus veya reaktif bir akış gibi hafif bir mesajlaşma otobüsü kullanın, bu sayede adaptörler, doğrudan yöntem çağrısı olmaksızın durum değişikliklerini iletebilir, böylece ana makine akışını web doğrulama akışından ayırabilirsiniz. HllapiMainframeAdapter başarılı bir şekilde bir hesap oluşturduğunda, hesap detaylarını içeren bir etkinlik yayınlar ve SeleniumWebAdapter, uygun doğrulama ekranına otomatik olarak gitmek için bunu tüketir. Test çerçevesi içindeki bu etkinlik odaklı yaklaşım, modern mikroservis mimarisini yansıtır ve bireysel sistem arayüzleri değiştiğinde bakım yükünü önemli ölçüde azaltır.
// Port Arabirimi Tanımı public interface BankingDriver { void enterCustomerData(Customer customer); AccountDetails submitAccountCreation(); void verifyAccountInPortal(AccountDetails account); void rollbackAccountCreation(AccountDetails account); } // Ana Makine Adaptörü HLLAPI Kullanarak public class MainframeAdapter implements BankingDriver { private final HllapiWrapper hllapi; private final EventBus eventBus; @Override public AccountDetails submitAccountCreation() { hllapi.sendKey("@E"); // Enter tuşunu simüle et waitForScreen("Hesap Oluşturuldu"); String accountId = hllapi.getTextByLabel("Hesap Numarası:"); AccountDetails details = new AccountDetails(accountId); eventBus.post(new AccountCreatedEvent(details)); return details; } @Override public void rollbackAccountCreation(AccountDetails account) { hllapi.sendKeys("SİL " + account.getId()); hllapi.sendKey("@E"); verifyScreen("Silme Onaylandı"); } } // İşlemsel Bütünlük İçin Saga Orkestratörü public class TestSagaOrchestrator { private final List<CompensableAction> executedActions = new ArrayList<>(); public void execute(Runnable action, Runnable compensation) { try { action.run(); executedActions.add(new CompensableAction(action, compensation)); } catch (Exception e) { compensate(); throw new TestFailureException(e); } } private void compensate() { Collections.reverse(executedActions); for (CompensableAction action : executedActions) { try { action.compensate(); } catch (Exception ex) { publishToDeadLetterQueue(action, ex); } } } }
2022 yılında dijital dönüşüm sürecine giren bir küresel sigorta sağlayıcısıyla yapılan bir danışmanlık anlaşmasında, tam olarak bu tür zorlukları örnekleyen kritik bir "Hasar Bildirimi" (FNOL) iş süreci ile karşılaştım. İş akışı, bir poliçe sahibinin kaza fotoğraflarını yükleyerek bir talep sunmasını gerektiriyordu, bu da hasar değerlendirmesi ve dolandırıcılık algılama için bir Python tabanlı makine öğrenimi mikroservisini tetikliyordu, en sonunda ise miras bir Unisys ana makine sistemini güncelleyerek mali rezervleri tahsis etmeyi ve poliçe kapsamını doğrulamayı içeriyordu. Mevcut otomasyon stratejisi, mobil uygulama için Cypress, API için Pytest ve ana makine terminal emülasyonu için Jagacy kullanan, birbirleriyle iletişim kurmayan üç ayrı pakete dayanıyordu.
Bölünmüş yaklaşım, takımlar arasında paylaşılan Excel tablolarını kullanarak talep numaralarının manuel bağıntısını gerektiriyordu ve çevresel kirlenme, regresyon döngülerinde ciddi bir engel oluşturuyordu. Zor an, bir mobil ağ zaman aşımının, ana makinenin zaten 50.000 $'lık bir rezerv tahsisi gerçekleştirdiği sırada bir testin başarısız olmasına neden olduğu ve mali verilerin tutarsız bir durumda kaldığı anda meydana geldi; bu, ana makine sistem programcısı tarafından dört saatlik manuel bir temizleme gerektirdi. Bu durum, ekibin "temiz ortam" politikasını doğrudan ihlal etti ve CI/CD boru hattını bir iş günü boyunca engelledi.
Gelecek olayların önlenmesi için üç potansiyel iyileştirme stratejisinde değerlendirme yapıldı. İlk seçenek, ana makine işlemlerini manuel olarak tersine çevirmek için test sonrası veritabanı temizleme betikleri yazmayı içeriyordu; ancak, bu öneri, güvenlik politikaları nedeniyle doğrudan SQL erişimine izin vermediği için reddedildi. İkinci yaklaşım, test yürütmesini sıraya koymak için pessimistik kilitleme mekanizmalarına sahip paylaşılan bir test veri havuzu oluşturmayı öneriyordu ancak bu, paket yürütme süresini yirmi dakikadan dört saatin üzerine çıkaracaktı ve CI/CD'deki paralelleşmenin faydalarını tamamen ortadan kaldıracaktı. Son olarak, üçüncü strateji, test otomasyon çerçevesi içinde bir Saga örüntüsünü uygulamayı, uygulamanın kendi nihai tutarlılık modelini yansıtırken, yüzlerce testin paralel çalışabilmesi yeteneğini korumayı içeriyordu.
Uygulanan çözüm, mobil ve ana makine adaptörleri tarafından gerçekleştirilen her işlemi durdurmak üzere ClaimSaga orkestratörünü tanıttı. Mobil adaptör, ağ zaman aşımından dolayı bir StaleElementReferenceException fırlattığında, saga hemen ana makine adaptörü üzerinde reverseReserveAllocation() telafi işlemünü, ThreadLocal bağlamındaki talep kimliği ile tetikledi. Bu otomatik geri alma mekanizması, çevresel veri kirlenmesini yüzde 98 oranında azaltarak, ekibin Jenkins pipeline’larında beş yüz paralel iş parçacığı çalıştırmalarına olanak tanıdı.
Bu önemli test güvenilirliğindeki iyileşme, QA ekibinin manuel veri temizliği yapmak yerine keşif testi ve kenar durum analizi yapmaya odaklanmasını sağladı. İş analistleri, sonunda, "Bir poliçe sahibi büyük bir kaza bildirdiğinde, fotoğraflar yüklendiğinde ancak AI değerlendirme hizmeti zaman aşımına uğradığında, mali rezerv tahsis edilmeyecektir" gibi, sade İngilizce ile yazılmış test senaryolarını yazabilmekte ve gözden geçirebilmektedir. Bu, otomasyon paketerinin, tüm üç teknolojik katmanda karmaşık iş kurallarını yansıtan doğru bir yaşam belgesi işlevi görmesini sağladı.
Emülatör ve web portalı genelinde oturum durumu sürekliliğini nasıl sağlıyorsunuz, adaptörler arasında sıkı bir bağımlılık oluşturmadan?
Yeni adaylar, genellikle bunu, adım tanım yöntemi doğrudan ham oturum tanımlayıcıları veya veritabanı birincil anahtarlar döndürüldüğünde, adım B'nin belirli bir dize değeri döndürünceye kadar yürütülemeyeceği kırılgan bağımlılıklar oluşturma yoluyla çözmeye çalışır. Bu yaklaşım, Temel Alan Odaklı Tasarım ilkelerini temelden bozar ve iş açıcılığına hitap eden Gherkin adımlarının, mantıksal bir iş akışı yerine sıkı bir teknik sıraya dizilmesine zorlar. Ayrıca, bu, DSL katmanına uygulama ayrıntılarını sızdırarak, teknik tanımlayıcılar biçim değiştirdiğinde testleri kırılgan hale getirir.
Güçlü mimari çözüm, test yürütme süresince geçici bir kayıt defteri görevi gören bir Senaryo Bağlamı veya Test Veri Bağlamı uygulayarak gerçekleştirilir; genellikle ThreadLocal<Map<Class<?>, Object>> kullanılarak, paralel yürütme sırasında iş parçacığı güvenliği sağlanır. Adaptörler, DSL katmanına ilkel değerler döndürmez; bunun yerine, bu bağlamda güçlü bir şekilde tiplenmiş alan olayları veya nesnelerini yayınlarlar. Örneğin, ana makine adaptörü başarılı bir şekilde bir hesap oluşturduğunda, tam hesap varlığını içeren bir AccountCreatedEvent yayımlar; bu, web adaptörü tarafından daha sonra etkinlik otobüsünü dinleyerek veya bağlamı sorgulayarak alınır.
Bu etkinlik odaklı yaklaşım, DSL katmanının verinin kaynağına tamamen kayıtsız olmasını sağlar; poliçe numarasının bir yeşil ekran üzerinden kazınıp kazınmadığı veya bir JSON yanıtında döndürülüp döndürülmediği fark etmeksizin. Soyutlamalara dayanarak, çerçeve, Bağımlılık Ters Çevirme İlkesi'ne uyar. Bireysel adaptörlerin yeniden yapılandırılmasına veya değiştirilmesine olanak tanır; böylece iş-okunur test senaryolarını etkilemeden uzun vadeli bakım maliyetlerini önemli ölçüde azaltır.
Telafi işleminin kendisinin başarısız olmasını, sistemin tutarsız bir durumda kalmasını nasıl önlersiniz?
Birçok junior mühendis, telafi mantığının kendisinin bir hata ile karşılaştığı kritik hata modunu gözden kaçırır. Bu tür hatalar, bir ana makine kaydını silmeye çalışırken ağ zaman aşımını içerebilir veya kayıt, eşzamanlı bir arka plan süreci tarafından daha önce değiştirilmişse doğrulama hatalarına neden olabilir. Bu senaryo, orijinal eylemin başarılı olduğu ancak geri dönmenin başarısız olduğu "zehirli verilerin" birikmesine yol açar ve test ortamını kalıcı olarak bozabilir.
Çözüm, herhangi bir zaman kaybı yaşamadan güvenli bir şekilde birden fazla kez tekrar edilebilecek idempotent telafi işlemleri uygulamayı gerektirir. Bu, geçici altyapı hatalarını zarif bir şekilde yönetmek için üstel gerileme ve devre kesici desenleri içeren güçlü bir tekrar mekanizması ile birleştirilmelidir. Tüm tekrar deneme girişimleri tükenirse, çerçevenin, başarısız telafi ayrıntılarını kalıcı bir Ölü Mektup Kuyruğuna (DLQ) yayımlaması gerekir. Bu DLQ, tam ilişki tanımlayıcıları ve yığın izleri içeren bir veritabanı tablosu veya mesaj konusu olarak uygulanabilir.
Ayrıca, telafi işlemi gerçekleştirmeden önce alt sistemlerin mevcut durumunu doğrulamak için doğrulama kapıları uygulayın. Örneğin, ana makine hesabının var olduğunu, sıfır bakiyesi olduğunu ve yakın zamanda kullanıcı değiştirilmediğini doğrulayarak silme komutunu verin. Gece boyunca otomatik bir uzlaşma işi, DLQ'deki bu yetim kayıtların manuel olarak işlenmesini sağlayacak; bu, test ortamının kendi kendine iyileşmesini sağlayacak ve kritik regresyonların mevcut veri kirlenmesi tarafından maskelememesine olanak tanıyacaktır.
Ana makinelerde koordinat tabanlı ekran kazıma (HLLAPI) kullanmanın neden bir yük olarak kabul edildiğini düşünüyorsunuz ve bakım yükünü azaltmak için bunu nasıl soyutluyorsunuz?
Adaylar genellikle, getText(10, 45, 10) gibi, oninci satırdan, 45inci sütundan başlayarak on karakter okumak için kodlanmış satır ve sütun koordinatlarını savunurlar. Bu yaklaşımı tercih ederler çünkü bu, ilk test geliştirme sırasında kesin ve belirleyici görünmektedir. Ancak, bu strateji, ana makine uygulamalarının sık sık ekran değişikliklerinden geçtiği ve yeni alanların eklendiği durumlarda tüm sonraki koordinat kaydırmalarını tetikleyerek test paketlerinin tamamını uyarı vermeden geçersiz hale getirdiği için ciddi bir bakım yükü oluşturmaktadır.
Güçlü mimari çözüm, mantıksal alan adlarını (örneğin, ACCOUNT_NUMBER_FIELD) dinamik arama kriterlerine mapleyen bir Ekran Nesne Modeli uygulamaktadır; bu, HLLAPI işlevleri aracılığıyla alan etiketleri ile FindFieldPosition veya SearchField gibi alanları aramak için ana makine emülatörünün Alan Tanımlama yeteneklerini kullanmaktadır. Çalışma zamanında adaptör, ekran tamponundaki etiket metnini arar ve karşılık gelen girdi alanlarına göre göreli kaydırmayı hesaplar. Ekran düzeni değiştiğinde, yalnızca etiketleri kaydırma yapılandırmalarını güncellemek için gereken JSON yapılandırma dosyasının güncellenmesi yeterlidir; derlenmiş Java koduna dokunulmaz.
Daha fazla dayanıklılık sağlamak için, etkileşim başlangıcında korunan alan içeriklerinin kriptografik hash’ini yakalayan bir Ekran Hash’ı veya Checksum mekanizması uygulayın. Eğer hash beklenen referans ile eşleşmezse, çerçeve, yanlış konumlardan veri okumaya çalışmak yerine net bir "Ekran Uyuşmazlığı" hatasıyla hızlıca başarısız olur. Bu durum, testlerin, yanlış negatifler veya yanlış pozitifler üreten bozuk verilerle devam etmesini önler ve otomasyon ekibini, yapılandırma güncellemeleri gerektiren ekran değişiklikleri hakkında hemen uyarır.