Endüstriyel otomasyon ve saha uygulamalarında yazılım hataları sadece bir yazılım kusuru değil; üretim kesintisi, kalite düşüşü ve güvenlik riski doğurur. Bir vana kontrolü ya da PLC arayüzündeki beklenmedik hatanın sonuçları, yazılım katmanında ortaya çıkan bir senkronizasyon hatasından daha fazlasıdır; ekipman duruşu, insan riskleri ve maliyet artışı getirir. Bu bağlamda test stratejileri, sadece kod kalitesini değil operasyonel sürekliliği güvence altına almalıdır.
Operasyonel riskleri yönetmek için test türlerinin hedefleri, kapsamı ve ölçülebilir sınırları net olmalıdır. Testler; gecikme, hata oranı, başarı yüzdesi gibi somut metriklerle izlenmeli ve SLAs ile ilişkilendirilmelidir. Örneğin üretim hattında sensör okuma gecikmesinin 50 ms'i aşması kritik bir alarm tetikleyebiliyorsa, bu sınır test senaryolarına dahil edilmelidir.
Teknik kapsam açısından Unit, Integration ve End-to-End (E2E) testleri farklı sorumluluklara sahiptir: birisi parçayı doğrular, diğeri bileşen etkileşimini, üçüncüsü ise sistem davranışını gerçek dünya koşullarında test eder. Bu üçlü birlikte uygulandığında, yazılım teslimatının saha davranışına yakın olmasını sağlar. Unutmayın: tek bir test katmanı tüm riskleri kapatmaz.
Bu yazıda geliştirici ve saha mühendisi perspektifiyle her test türünün neyi hedeflediğini, ölçülebilir parametrelerini, ölçüm yöntemlerini ve saha örneklerini vereceğim. KB Yazılım'ın saha odaklı yaklaşımını örnek uygulamalarla göstereceğim.
Unit testleri, tek bir fonksiyon, sınıf ya da modülün beklenen davranışı sağladığını doğrular. Ölçülebilir sınırları genellikle fonksiyon başına cevap süresi (ms), bellek sızıntısı (MB/işlem) ve kod kapsama oranı (%) ile ifade edilir. Birim testleri ile 1 ms altı gerçekleşmesi gereken algoritmaların performans regresyonu erken tespit edilebilir.
Unit test: İzole edilmiş birimlerin işlev doğrulaması; amaç hızlı geribildirim, hedef < 100 ms yanıt ve %90+ kapsama oranıdır.
Integration testleri, birden fazla bileşenin birlikte çalışmasını doğrular. Bunlar, API çağrıları arasındaki gecikmeyi (ms), hata dönüş yüzdesini (%) ve işlem/yığın başına ortalama veritabanı sorgu sayısını (sorgu/adet) ölçer. Örneğin bir mikroservis çağrısı zincirinde 200 ms üzeri aktarım süreleri entegrasyon problemlerine işaret eder.
Integration test: Bileşenler arası arabirim doğrulaması; ölçütler arasında 95. yüzdelik gecikme (p95 < 250 ms) ve hata oranı < 1% yer alır.
End-to-End testleri, kullanıcının veya saha cihazının gerçek etkileşimini simüle eder. Burada ölçülen parametreler işlem başına gecikme (saniye), uçtan uca başarım (%) ve sistem başına throughput (TPS) olur. Örneğin bir batch işinin tamamlanma süresinin 30 saniyeden fazla olması kabul edilemezse, E2E senaryolar buna göre kurgulanır.
E2E test: Gerçek kullanım akışının doğrulanması; hedef işlem süresi, sistem throughput ve kullanıcı gözlemlenebilir hata oranını kontrol etmektir.
Sorun: Gerçek servislerin yerine kullanılan mock'lar sahadaki zamanlama ve hata davranışlarını doğru yansıtmayabilir. Bu durum, entegrasyon aşamasında beklenmeyen hatalara yol açar.
Teknik olarak, stub davranışı ile gerçek servis arasındaki gecikme ve hata dağılımı farklı olursa, test pass oranı ile saha stabilitesi arasında örtüşme azalır. Mock kullanımı sırasında gözlenen %0.1 hata oranı sahada %2-5 hataya dönüşebilir.
Ölçülebilir parametreler: 1) Mock vs gerçek p95 gecikme farkı (ms), 2) Tahmin edilen hata oranı ile gerçek hata oranı arasındaki sapma (%).
Analiz yöntemi: Log korelasyonu + request/response histogram karşılaştırması.
Sorun: Stateful bileşenler arasında oturum yönetimi ve bağlantı sabitliği farklı ortamlarda değişken davranış sergileyebilir. Özellikle bağlantı havuzu, zaman aşımı ve yeniden deneme politikaları sahada sıkıntı yaratır.
Trafik artışında oturum açık kalma süreleri artar, bağlantı sızıntıları görünmeye başlar ve bu da 300-500 ms ek gecikmeye sebep olabilir. State yönetimindeki hatalar TPS'de düşüş olarak gözlenir.
Ölçülebilir parametreler: 1) Bağlantı havuzu doluluk oranı (%), 2) Ortalama yeniden deneme sayısı/adım (adet).
Analiz yöntemi: Connection leak profiler + histogram ve garbage collection izleme.
Sorun: Planlanmış batch işler, artan gecikme yüzünden beklenen pencereye sığmayabilir. Özellikle gece işlerinde kaynak kısıtları diğer işlerle çakıştığında gecikme birikir.
Tedavi edilmezse, işlem tamamlama süreleri %30-60 artış gösterebilir ve hatalı retry'ler kaynak tüketimini artırarak domino etkisi yaratır.
Ölçülebilir parametreler: 1) Batch tamamlama süresi (saniye), 2) Görev gecikme oranı (% zamanında tamamlanmayan işler).
Analiz yöntemi: Load test + zaman çizgisi histogramı (latency over time).
Sorun: E2E testleri, ortam değişkenlerine duyarlı olup rastgele başarısızlıklara (flaky) açıktır. Ağ gecikmeleri, DNS çözümlenememe veya üçüncü parti hizmetlerin ara sıra devre dışı kalması testleri bozabilir.
Flaky testler test güvenirliğini düşürür; sonucu olarak CI geçme oranı azalır ve geliştiriciler test başarısızlıklarını görmezden gelme eğilimine girer. Flakiness oranı %5'in üzerine çıkarsa test değeri tartışılır hale gelir.
Ölçülebilir parametreler: 1) Test flakiness oranı (%), 2) Ortalama tekrar çalışma sayısı (retry/adet).
Analiz yöntemi: Test run korelasyonu + packet capture (ağ kesintilerinin doğrulanması) + log korelasyonu.
| Kod | Belirti | Olası Neden | Ölçüm |
|---|---|---|---|
| UT-01 | Birim testleri sık fail | Yanlış mock konfigürasyonu | Kod kapsama raporu, ms performans |
| IT-11 | Servisler arası 500 hatası | Timeout ve retry konfig hatası | Log korelasyonu, p95 gecikme |
| E2E-07 | CI'da rastgele başarısızlık | Çevresel flakiness | Packet capture, flakiness % |
Bir arıza geldiğinde önce fiziksel katman (donanım, ağ) sonra altyapı bileşenleri, entegrasyon yolları ve en son uygulama mantığını sırasıyla ele alarak daraltma yapılmalıdır. Bu yaklaşım, yanlış ipuçlarına dayanarak zaman kaybını azaltır.
Problem: Bir üretim hattında operatör arayüzü zaman zaman veri güncellemelerini göstermiyor; raporlara göre %12 kullanıcı geri bildirimi vardı. İlk yanlış varsayım, frontend komponentinin hatalı olduğu yönündeydi. Hızlı bakışta, tarayıcı cache'i ya da DOM hatası suçlandı.
Analiz: Log korelasyonu ve API trace sonucu, entegrasyon servislerinde zaman zaman 502 döndüğü gözlendi. Kök neden, üçüncü parti mesajlaşma kuyruğunda gecikme patikası ve retry politikalarının çok agresif olmasıydı. Kalıcı çözüm: Kuyruk yapılandırmasında visibility timeout ve prefetch limit ayarı yapıldı; retry stratejisi exponensiyel backoff ile değiştirildi. Sonuç olarak, sahada görülen arayüz güncellememe vakaları %87 azaldı ve ortalama uçtan uca veri tazeleme süresi %33 iyileşti.
Dayanıklılık, sürekli ölçüm ve geri besleme ile inşa edilir; testler sadece release anına özgü değil, sürdürülmesi gereken canlı kontrol noktalarıdır.
Sürdürülebilir test kültürü, otomasyonun ötesinde ölçüm odaklı bir geri besleme döngüsü gerektirir; ölçümler olmadan dayanıklılık soyut bir hedeftir.
Unit, Integration ve E2E testleri bir arada düşünüldüğünde çok katmanlı bir doğrulama sağlar: her katman farklı riskleri azaltır ve birlikte operasyonel güvenilirliği artırır. Ölçümlere dayalı kararlar (ms, %, TPS gibi) testi somutlaştırır ve saha sonuçlarına doğrudan bağlanabilir hale getirir.
İzleme, log korelasyonu ve düzenli saha veri entegrasyonu olmadan testlerin saha başarısı sınırlı kalır; bu nedenle ölçüm ve izleme kültürü proje yaşam döngüsünün merkezinde olmalıdır. KB Yazılım olarak saha odaklı test veri yönetimi, contract testing ve izleme hattını birleştiren bir metodoloji izliyoruz; bu yaklaşım gerçek dünya uygulamalarında %30-50 arasında daha hızlı problem tespiti ve %40 civarında iyileşme sağladı.
Bu konuda birlikte çalışmak isterseniz, proje özgü riskleri ve ölçütleri birlikte belirleyip uygulanabilir bir test stratejisi oluşturabiliriz. KB Yazılım saha tecrübesiyle entegrasyon süreçlerinizi hızlandırmaya hazırdır.