Yazılımda test ortamı ve canlı veri maskeleme rehberi

Özel yazılımda test ortamı, canlı veritabanının birebir kopyası değildir; aynı şemayı ve aynı sürümü taşıyan, ama kişisel ve ticari verisi maskelenmiş ayrı bir kurulumdur. Canlı veriyi olduğu gibi test sunucusuna almak en hızlı yol gibi görünür, fakat müşteri adını, telefonunu ve ciro bilgisini erişim denetimi zayıf bir ortama taşır. Üstelik test sırasında tetiklenen bir e-posta ya da bir kargo çağrısı gerçek müşteriye ulaşabilir. Aşağıda kaç ortam gerektiğini, maskelemenin nasıl yapıldığını ve ortamların birbirine karışmasını önleyen işaretleri anlatıyoruz.

Neden canlının kopyası test ortamı sayılmaz

İki ayrı gerekçe var. Birincisi veri sorumluluğu: canlıda sıkı yetkiyle korunan müşteri bilgisi, test ortamında geliştiriciden stajyere kadar geniş bir kitleye açılır ve çoğu zaman o ortamın yedekleri de aynı özenle korunmaz. İkincisi yan etkiler: test sırasında bir sipariş kapatıldığında bildirim gidebilir, bir iade denemesi gerçek bir ödeme sağlayıcısına ulaşabilir, bir toplu iş gerçek adreslere e-posta yollayabilir.

Bu yüzden doğru soru canlıyı kopyalayalım mı değil, canlıya benzeyen ama zararsız bir veri kümesini nasıl üretiriz sorusudur. Hacim, tarih dağılımı ve ilişki yapısı korunur; kimliğe götüren her şey değiştirilir.

Üçüncü bir gerekçe de pratiktir: canlının rastgele bir kopyası, test için en gerekli kayıtları içermeyebilir. Sınır durumlarını temsil eden veriler, yani sıfır tutarlı sipariş, kısmen iade edilmiş fatura, adresi eksik müşteri ya da çok kalemli belge, canlıda seyrek görüldüğü için kopyada hiç bulunmayabilir. Olgun ekipler bu kayıtları test ortamında elle üretir ve her tazelemede korunacak sabit bir küme olarak saklı tutar.

Kaç ortam gerekir

Küçük projelerde geliştirme ve test birleşebilir, fakat ön canlı ile canlıyı birleştirmek hiçbir ölçekte doğru değildir. Ön canlı, sürümün canlıya benzer veri hacmiyle denendiği son duraktır; burada yakalanmayan sorun kullanıcıda ortaya çıkar.

Maskeleme neyi değiştirir, neyi korur

• Değiştirilenler: ad soyad, firma unvanı, telefon, e-posta, adres, kimlik ve vergi numarası, IBAN, serbest metin notlar.
• Hiç taşınmayanlar: kart verisi, parola, oturum belirteçleri, dış servis anahtarları. Bunların maskelenmiş hâli de test ortamına girmez, alan boş bırakılır.
• Korunanlar: kayıt sayısı, tarih aralıkları, tutar büyüklükleri, durum dağılımı, tablolar arası ilişkiler ve alan uzunlukları.

Korunan kısım önemlidir. Üç yüz kayıtla test edilen bir rapor, canlıdaki üç yüz bin kayıtta çalışmayabilir. Maskelemenin amacı veriyi küçültmek değil, kimliksizleştirmektir.

Maskelemenin üç kuralı

1. Tutarlı olmalı. Aynı müşteri hangi tabloda geçerse geçsin aynı sahte isme dönüşmeli; yoksa sipariş ile cari kayıt eşleşmez ve test anlamını yitirir.
2. Geri döndürülemez olmalı. Sahte değerden gerçeğe dönüş sağlayan bir eşleme tablosu test ortamında tutulmaz; tutulursa maskeleme yalnızca bir perdeye dönüşür.
3. Kopyalama anında uygulanmalı. Maskeleme, veri canlıdan çıkarken yapılır. Önce ham kopyayı test sunucusuna indirip orada maskelemek, ham veriyi zaten o ortama taşımış olmak demektir.

Dış sistemler test ortamında nasıl bağlanır

Ödeme, kargo, muhasebe ve bildirim servisleri test tarafında gerçek hesapla çalıştırılmaz. Uygulanan yöntemler şunlardır: sağlayıcının kendi test ortamı varsa onun hesabı tanımlanır; yoksa beklenen cevabı döndüren bir taklit servis yazılır. Giden tüm e-posta ve kısa mesajlar tek bir test kutusuna yönlendirilir, alıcı adresi veride ne yazarsa yazsın dışarı çıkmaz. Dosya aktarımı yapan entegrasyonlarda hedef klasör ayrı tutulur. Son olarak, test ortamındaki hiçbir anahtar canlıya yazma yetkisi taşımamalıdır; bu tek kural, en pahalı kazaların çoğunu engeller.

Taklit servis yazarken yalnızca başarılı cevabı taklit etmek yeterli değildir. Zaman aşımı, biçimi bozuk cevap, yetki hatası ve yarıda kalan işlem gibi hâller de üretilebilmelidir; entegrasyonların çoğu tam olarak bu noktalarda kırılır ve senaryo test edilmediğinde kırılma ilk kez canlıda görülür.

Ortamların karışmasını önleyen işaretler

• Her ortam için ayrı alt alan adı ve ayrı veritabanı adı kullanın.
• Arayüzün üstüne ortam adını yazan renkli bir şerit koyun; ekran görüntüsünden bile hangi ortam olduğu anlaşılsın.
• Anahtar setleri ortam başına ayrı üretilsin, aynı dosyada yan yana durmasın.
• Veri akışı tek yönlü olsun: canlıdan test ortamına kopyalanır, tersi asla yapılmaz.
• Test ortamı arama motorlarına kapatılsın ve erişim kurum ağıyla ya da kullanıcı girişiyle sınırlansın.

Test verisi ne zaman tazelenir

Tazeleme için üç doğal an vardır: büyük bir sürüm öncesinde, şema değişikliği sonrasında ve canlıda ancak gerçek veriyle görülebilen bir hata araştırılırken. Her tazelemede maskeleme betiği yeniden çalışır; betiği elle çalıştırılan bir adım olarak bırakmak, bir gün unutulacağı anlamına gelir. Yeni bir tablo eklendiğinde maskeleme betiğinin de güncellenmesi, sürüm kontrol listesine yazılır.

Kısa kontrol listesi

• Test ve ön canlı ortamları canlıdan ayrı sunucu ve ayrı veritabanında mı?
• Maskeleme canlıdan çıkış anında mı uygulanıyor?
• Kart verisi, parola ve dış servis anahtarları test tarafına hiç taşınmıyor mu?
• Giden e-posta ve kısa mesajlar tek bir test kutusuna yönleniyor mu?
• Test ortamındaki anahtarların canlıya yazma yetkisi kapalı mı?
• Yeni tablo eklendiğinde maskeleme betiği güncelleniyor mu?
• Sınır durumlarını temsil eden sabit test kayıtları her tazelemede korunuyor mu?

KAV Yazılım, geliştirdiği projelerde ortam ayrımını ve maskeleme adımını kurulumun parçası olarak teslim eder; sonradan kurulan test ortamı çoğu zaman eksik kalır.