IEEE, Beyaz Kutu Testini şu şekilde tanımlar: “Bir sistemin veya bileşenin iç mekanizmasını dikkate alan test.”
Beyaz Kutu Testi, yazılım testçisinin uygulamayı etkili bir şekilde test etmek için doğru türde giriş verilerini bulmasına yardımcı olur; testçi, iç yapıyı bildiği için en etkili test senaryolarını (test girdilerini) optimize ederek sistemin sınırlarını daha iyi zorlayabilir.
Pressman’a göre, beyaz kutu testi, bir yazılım testçisinin aşağıdaki işlevleri yerine getirmesine yardımcı olur:
Bir birim veya modül içindeki bağımsız yolları test etme.
Mantıksal doğruluğu test etme (hem doğru hem de yanlış koşulları test etme).
Döngüleri test etme, özellikle sınırlarında ve operasyonel sınır doğruluğunu kontrol etme.
İç veri yapılarını test etme ve geçerliliklerini sağlama.
Statik Beyaz Kutu Testi
Statik beyaz kutu testinde amaç, programı yürütmeden kodun yapısını, mantığını ve olası kusurlarını incelemektir.
Statik beyaz kutu testinin en büyük avantajı, potansiyel hata kaynaklarının erken tespit edilmesi ve dinamik beyaz kutu testleriyle ortaya çıkarılamayan kusurların da belirlenebilmesidir.
Bu tür testleri gerçekleştirebilmek için bir yazılım test uzmanının yazılım kodlaması ve iç mantık hakkında bilgi sahibi olması gerekir.
Bu bilgi, test uzmanının ulaşılabilir ve ulaşılamaz kod parçalarını, mantıksal olarak mümkün olan ve olmayan yolları, ayrıca şüpheli kontrol akışlarını ayırt etmesini sağlar.
Statik Beyaz Kutu Test Süreçleri
Statik beyaz kutu testi, yazılımın kontrol yapısını, veri kullanımını, kodlama hatalarını ve tasarımla tutarlılığını inceleme sürecidir.
Bu test kapsamında incelenen farklı unsurlar arasında kodlar, dallanmalar, yollar ve iç mantık yer alır.
Tasarım ve Kodun İncelenmesi
Tasarımın ve kodun incelenmesi, kodların çalıştırılmadan gözden geçirilmesi ve değerlendirilmesi anlamına gelir.
Hataların tespit edilip yakalanmasını sağlayan üç yöntem bulunmaktadır:
Bu üç yöntem, bulunan hataları analiz etmek ve bunları düzeltmek için belirli prosedürler ve hata tespit teknikleri kullanır.
Planlı inceleme toplantıları düzenlenir ve bu toplantılarda geliştiriciler ile test uzmanları, uygulamanın yapısını ve olası hata bölgelerini tartışır.
Belirlenen alanlar ya düzeltilir ya da dinamik beyaz kutu testine tabi tutulmak üzere işaretlenir.
Resmi İnceleme (Formal Review)
Formal review, statik test kapsamında kullanılan, yazılım ürünlerinin belirli kurallar ve roller çerçevesinde sistematik olarak incelenmesine dayanan bir tekniktir.
Bu süreçte amaç; kusurları, eksiklikleri, standart ihlallerini, tutarsızlıkları ve bakım güçlüğü oluşturabilecek noktaları erken aşamada belirlemektir.
Başarılı bir review süreci için temel unsurlar
Kusur odaklılık
Formal inceleme, yazılımın tasarımı ve koduyla ilgili sorunları belirlemelidir.
Katılımcılar eleştirel ve dikkatli bir inceleme yapmalı; ancak bunu yapıcı, profesyonel ve kişiden bağımsız bir dille yürütmelidir.
Kurallara uygunluk
İncelemeler, belirli kurallar çerçevesinde gerçekleştirilmelidir.
Bir oturumda incelenecek kod miktarı ve inceleme süresi önceden belirlenmeli; kapsam aşırı büyütülerek sürecin yüzeysel hale gelmesine izin verilmemelidir.
Sürecin verimli ilerleyebilmesi için her katılımcının görevleri önceden netleştirilmelidir.
Hazırlık
Her katılımcı toplantıya hazırlıklı gelmeli ve sürece aktif olarak katkıda bulunmalıdır.
Katılımcıların rolleri inceleme türüne göre değişiklik gösterebilir.
Toplantı, kusur bulmanın yapıldığı ana yer değil; bireysel hazırlıkta bulunan bulguların doğrulandığı, sınıflandırıldığı ve kayıt altına alındığı aşamadır.
Rapor yazımı
İnceleme ekibi, toplantının sonuçlarını içeren yazılı bir rapor hazırlar.
İnceleme sonunda bulunan kusurlar kayıt altına alınır, gerekli düzeltmeler atanır ve gerekiyorsa yeniden gözden geçirme için takip adımı planlanır.
Peer Reviews (Akran İncelemeleri)
Peer review, ekip üyelerinin birbirlerinin iş ürünlerini değerlendirdiği akran incelemesidir. Genellikle inspection’a göre daha az resmi, daha hızlı ve daha esnek yürütülür.
Bu incelemeler, mimariyi veya kodu tasarlamada yer almış bir programcı ile diğer programcılar veya test uzmanları tarafından gerçekleştirilir.
Walkthroughs (Yürütme İncelemesi)
Walkthrough, kodun veya tasarımın geliştiricisi tarafından adım adım anlatıldığı, katılımcıların soru ve yorumlarla katkı verdiği bir inceleme türüdür.
Bu yöntemde, kodu geliştiren programcı, kodu beş ila altı kişilik bir programcı ve test uzmanı ekibine sunar.
Walkthrough’un amacı, kodu genel hatlarıyla anlatmak ve ekibe yapısını göstermektir.
Sunumu yapan programcı, kodun her satırını veya fonksiyonunu tek tek okuyarak her satırın ne anlama geldiğini açıklar.
Yorumlar ve sorular oturum sırasında ele alınır.
Walkthrough oturumları genellikle bir kıdemli programcı ve diğer gözden geçirenlerin önünde gerçekleştirilir.
Inspections (Denetlemeler)
Denetlemeler, yapılandırılmış bir format izler ve walkthrough ve peer review süreçlerinden oldukça farklıdır.
Inspection sürecinde oturum genellikle geliştirici tarafından değil, moderatör tarafından yönetilir; geliştirici ise gerekli durumlarda açıklama yapan katılımcı konumundadır.
Denetleyiciler, ürünü gereksinimler, standartlar, test edilebilirlik, bakım yapılabilirlik ve olası kusurlar açısından sistematik biçimde inceler.
Bu yöntem, ürünle ilgili farklı perspektiflerin ortaya çıkmasını sağlayarak farklı hataların tespit edilmesine yardımcı olur.
Inspections (Devam)
Bazı incelemelerde, dikkat dağılmasını azaltmak ve alışılmış okuma düzeninin dışına çıkmak için farklı inceleme stratejileri uygulanabilir.
Bu, ürünün eşit şekilde gözden geçirildiğini garanti altına almak için yapılır.
Ayrıca, denetleyicilere moderatör (moderator) ve raportör (recorder) görevleri verilir.
Bunlar, test sürecinin kurallara uygun şekilde yürütüldüğünü ve incelemenin etkin bir şekilde gerçekleştirildiğini sağlar.
Inspections (Devam)
Denetleme tamamlandıktan sonra, denetleyiciler kendi aralarında bir toplantı yaparak tespit edilen hataları tartışır.
Denetleyiciler, deneyimli programcılar olan moderatörlerle birlikte hangi alanların yeniden ele alınması gerektiğini belirler.
Programcı, tespit edilen kusurlar düzeltir ve moderatörler düzeltmelerin uygun şekilde yapıldığını doğrular.
Eğer tespit edilen kusur kritik düzeydeyse, yeniden denetleme (re-inspection) süreci başlatılır.
Kodlama Standartları
Resmi inceleme yönteminde, denetleyiciler koddaki kusurları, eksiklikleri ve standart ihlallerini sistematik biçimde inceler.
Ancak hatalar, kodu dikkatlice analiz ederek bulunur ve bu analiz, kıdemli programcılar ve test uzmanları tarafından yapılır.
Kod doğru çalışıyor olabilir; ancak proje kodlama standartlarına, adlandırma kurallarına veya tasarım ilkelerine uygun yazılmamış olabilir.
Bir kod parçası sözdizimsel olarak doğru ve çalışır durumda olabilir; ancak anlam, amaç veya standart açısından yetersiz olabilir. Bu durum, dilbilgisel olarak doğru ama anlamsal olarak zayıf bir cümleye benzetilebilir.
Bu tür durumları önlemek için kodlama standartları, rehberler ve kontrol listeleri oluşturulur.
Kod İnceleme Kontrol Listesi
Kod incelemeleri, kodun standartlar ve kılavuzlarla karşılaştırılmasının yanı sıra, yazılım projesinin tasarım gereksinimlerini karşıladığını doğrulamak için gerçekleştirilir.
Bu süreci ayrıntılı bir şekilde yürütmek için belirli bir programlama deneyimi gereklidir.
Kod incelemelerinde dikkate alınabilecek bazı soruları inceleyelim.
Kod İncelemede Karşılaşılabilecek Hatalar
Veri Referans Hataları
Veri referans hataları; ilklenmemiş, yanlış tanımlanmış veya yanlış biçimde erişilen değişken, sabit, dizi, karakter dizisi ya da kayıt yapılarından kaynaklanır.
Kontrol edilmesi gerekenler:
İlklenmemiş değişken kullanılmış mı?
Diziler veya karakter dizileri için indeksler, geçerli aralıklarda mı?
Dizi indeksleme işlemlerinde veya referanslarında “off-by-one” hatası var mı?
Veri öğeleri, beklenen veri türü ve kullanım amacıyla uyumlu biçimde kullanılmış mı?
İşaretçiler için bellek ayrılmış mı?
Veri yapıları, farklı fonksiyonlarda tutarlı bir şekilde tanımlanmış ve referans gösterilmiş mi?
off-by-one error örneği
Örnek 1:
arr = [10, 20, 30, 40]for i inrange(1, len(arr)): # HATA! 0 yerine 1’den başlatılmışprint(arr[i])
Örnek 2:
arr = [10, 20, 30, 40]for i inrange(len(arr) +1): # HATA! Fazladan bir adım atıyorprint(arr[i]) # IndexError: list index out of range
Bilgi
Düşük seviyeli dillerde veri referans hataları, dizi sınırlarının aşılması ve geçersiz bellek erişimleri gibi ciddi güvenlik açıklarına yol açabilir. Python gibi dillerde ise bu tür hatalar çoğu zaman çalışma zamanı istisnası olarak ortaya çıkar.
Veri Bildirim Hataları (Data Declaration Errors)
Veri bildirim hataları, değişken ve sabitlerin yanlış, eksik veya uygunsuz biçimde tanımlanmasından kaynaklanır.
Kontrol Edilmesi Gerekenler:
Değişkenlerin veri türü, kapsamı (scope), ömrü ve gerekirse boyutu doğru belirlenmiş mi?
Değişkenler kullanılmadan önce uygun biçimde ilklenmiş mi ve atanan başlangıç değeri veri türüyle uyumlu mu?
Birbirine çok benzeyen, karışıklığa yol açabilecek değişken adları kullanılmış mı?
Hiç kullanılmayan değişkenler var mı? Tekrar değişmeyecek değerler için sabit tanımı tercih edilmeli mi?
Değişkenler uygun kapsamda tanımlanmış mı? Gereksiz yere global tanımlar kullanılmış mı?
Değişken adı, taşıdığı anlamı doğru yansıtıyor mu?
Gereksiz global değişken kullanımı var mı?
Hesaplama Hataları (Computation Errors)
Hesaplama hataları, aritmetik işlemler, tür dönüşümleri, sınır değerler veya işlem sırası nedeniyle ifadenin beklenen matematiksel ya da mantıksal sonucu üretmemesinden kaynaklanır.
Kontrol Edilmesi Gerekenler:
Hesaplamalarda farklı veri türleri birlikte kullanılıyorsa, tür dönüşümleri ve sonuç üzerindeki etkileri doğru değerlendirilmiş mi?
Aynı tür ailesine ait fakat farklı aralık veya bit genişliğine sahip veri tipleri birlikte kullanılmış mı?
Tür dönüşümleri açık mı, örtük mü yapılmış? Dönüşüm sırasında veri kaybı, işaret değişimi veya hassasiyet kaybı oluşuyor mu?
Bir hesaplama sırasında taşma (overflow) oluşma ihtimali var mı?
Kontrol Edilmesi Gerekenler (Devam):
Bir bölme veya mod alma işleminde sıfıra bölme ihtimali var mı?
Hesaplama sonucunda elde edilen değer, veri türünün veya iş kuralının izin verdiği aralığın dışına çıkabiliyor mu?
Bir atama sırasında, sonucun hedef veri tipine sığmama, kesilme (truncation) veya hassasiyet kaybı riski var mı?
İfade içerisindeki işlemlerin sırasını netleştirmek için parantezler kullanılmalı mı?
Özellikle tamsayı bölme işlemlerinde hassasiyet kaybı olup olmadığı kontrol edildi mi?
Karşılaştırma Hataları
Karşılaştırma hataları, koşul ifadelerinde kullanılan karşılaştırma ve mantıksal operatörlerin yanlış seçilmesi, sınır değerlerin hatalı ele alınması veya ifadelerin beklenenden farklı değerlendirilmesi sonucu ortaya çıkar.
Karşılaştırma hatalarını analiz ederken dikkat edilmesi gereken bazı yaygın noktalar
Karşılaştırma Hataları (Devam)
Koşul ifadelerinde kullanılan karşılaştırma operatörlerinin iş kuralını doğru yansıtıp yansıtmadığı kontrol edilmelidir. Özellikle sınır değerlerde < yerine <= ya da > yerine >= kullanımı dikkatle incelenmelidir.
Örnek: < yerine <= kullanılması
def check_limit(value):if value <10: # Hata: 10 da dahil edilmeliydiprint("Değer limitin altında!")else:print("Değer geçerli.")check_limit(10) # Beklenen: "Değer limitin altında!" yerine "Değer geçerli."
Karşılaştırma Hataları (Devam)
Kayan noktalı (floating-point) değerler arasında karşılaştırma olup olmadığını kontrol edin
a =7.000000000000000007b =7.000000000000000008if a == b:print("Eşit!")else:print("Eşit değil!")
Karşılaştırma Hataları (Devam)
Boolean operatörlerinin (mantıksal operatörlerin) doğru operandlarla kullanıldığını kontrol edin
Her Boolean ifadesinin beklenen şekilde çalışıp çalışmadığını ve değerlendirme sırasıyla ilgili herhangi bir şüphe olup olmadığını kontrol edin
Kontrol Akışı Hataları
Kontrol akışı hataları, bir dildeki döngülerin ve kontrol yapılarının hatalı çalışması sonucu ortaya çıkar.
Bu hatalar genellikle doğrudan veya dolaylı olarak hesaplama ya da karşılaştırma hatalarından kaynaklanır.
Kontrol Akışı Hataları (Devam)
Her switch ifadesinin bir default bloğu olup olmadığını kontrol edin.
İç içe geçmiş switch ifadelerinin döngüler içinde olup olmadığını kontrol edin.
Bir döngünün hiç çalışmama olasılığını kontrol edin.
Derleyicinin (compiler) ifadeleri değerlendirirken kısa devre (short-circuiting) desteği olup olmadığını kontrol edin.
Kontrol Akışı Hataları (Devam)
Dilin begin…end veya do…while gibi ifade grupları içerip içermediğini ve end ifadelerinin açıkça belirtilip belirtilmediğini ve uygun gruplarla eşleşip eşleşmediğini kontrol edin.
Döngünün beklenenden önce sona erme ihtimalini kontrol edin.
Döngüde beklenmeyen bir akışa neden olabilecek “off by one” hatalarının olup olmadığını kontrol edin.
Alt Program (Subroutine) Parametre Hataları
Alt program parametre hataları, alt programlara yanlış veri gönderildiğinde veya alt programlardan yanlış veri alındığında meydana gelir.
Bu tür hataları kontrol ederken dikkat edilmesi gereken noktalar şunlardır:
Sabitlerin (constant) alt programa argüman olarak geçirilip geçirilmediğini ve alt program içinde yanlışlıkla değiştirilip değiştirilmediğini kontrol edin.
Her parametrenin birimi ile ilgili argümanın biriminin eşleşip eşleşmediğini kontrol edin.
Alt programın aldığı parametrelerin tür ve boyutlarının, çağıran kod tarafından gönderilenlerle eşleşip eşleşmediğini kontrol edin.
Sadece giriş (input) olarak kullanılması gereken bir parametrenin alt program tarafından değiştirilip değiştirilmediğini kontrol edin.
Girdi/Çıktı Hataları
Girdi/çıktı hataları, bir dosyadan okuma, klavye veya fareden giriş kabul etme ve bir dosyaya ya da ekrana çıktı yazma gibi işlemlerle ilgili hatalardır.
Yazılımın, harici cihaz tarafından okunan veya yazılan verinin belirlenen formatına kesinlikle uyup uymadığını kontrol edin
Hata durumunun ele alınıp alınmadığını kontrol edin.
Harici cihazın bağlantısının kesilmesi durumunun yazılım tarafından işlenip işlenmediğini kontrol edin.
Tüm istisnaların (exceptions) kodun bir bölümü tarafından ele alınıp alınmadığını kontrol edin.
Diğer Kontroller
Kodun lint testinden geçip geçmediğini kontrol edin
Uluslararasılaştırma (i18n) ile ilgili sorunları kontrol edin.
Kodun kullanımdan kalkmış (deprecated) API’lere dayanıp dayanmadığını kontrol edin.
Kodun ASCII ve Unicode gibi farklı kodlamaları düzgün şekilde işleyip işlemediğini kontrol edin.
İşletim sistemi uyumluluklarını kontrol edin
Dinamik Beyaz Kutu Testi
Dinamik beyaz kutu testi, test senaryolarını belirli giriş değerleriyle çalıştırarak yapılan bir doğrulama kontrolüdür.
Bu test yöntemi, uygulamanın çalıştırma süresi boyunca belirlenen spesifikasyonlara uygun şekilde çalıştığını doğrular.
Çalıştırma sonuçları, kodun gerçek davranışına dair kanıt sağlar.
Dinamik beyaz kutu testinin kapsadığı dört temel alan şunlardır:
Düşük seviyeli fonksiyonların, prosedürlerin, alt programların veya kütüphanelerin doğrudan test edilmesi.
Yazılımın en üst seviyede, tamamlanmış bir program olarak test edilmesi ve test senaryolarının, yazılımın çalışma prensiplerine göre ayarlanması.
Yazılımın değişkenlerini ve durum bilgilerini okumak için erişim sağlanması, böylece testlerin amaçlarına uygun çalışıp çalışmadığının belirlenmesi.
Bir test uzmanının, testleri çalıştırırken kodun ne kadarının ve hangi bölümlerinin test edildiğini ölçmesi.
Dinamik Beyaz Kutu Testi vs Debugging
Dinamik beyaz kutu testi ve hata ayıklama teknikleri benzer görünse de, yazılım kodu ve hatalarla ilgilenirken farklı amaçlara sahiptirler. Bu iki süreç, yazılımda hata bulunduğunda kesişse de, temel farkları şunlardır:
Dinamik beyaz kutu testi, yazılımdaki hataları bulmayı amaçlar.
Hata ayıklama (debugging) ise, test aşamasında bulunan hataların düzeltilmesi sürecidir.
Bir yazılım test uzmanı olarak, hataları gösteren test senaryolarına odaklanmanız gerekir. Beyaz kutu testinde, hatalı görünen kod satırları belirlenerek hata tespiti daraltılır.
Parçaları Test Etmek
Dinamik kara kutu testinde, bir hata genellikle testin son aşamalarında bulunur. Hatanın neden ortaya çıktığını anlamak zor, hatta bazen imkânsızdır.
Bu nedenle, bir test uzmanı yazılımın hangi bölümünün soruna yol açtığını belirleyemez.
Bazı hatalar, diğer hataların varlığını gizleyebilir ve bu hatalar yazılımın başarısız olmasına neden olabilir.
Programcı sorunu düzelttiğinde, test uzmanı yazılımı tekrar çalıştırır ancak yazılım yine başarısız olabilir.
Sonuç olarak, hatalar birikmeye devam eder ve asıl sorunun kaynağına ulaşmak imkânsız hâle gelir.
Birim ve Entegrasyon Testi
Yazılımdaki hataların sistem geneline yayılmadan erken aşamada yakalanabilmesi için, yazılım önce küçük parçalar hâlinde test edilir; ardından bu parçalar kademeli olarak birleştirilerek daha büyük yapılar oluşturulur.
Bu doğrultuda, en düşük seviyede birim testi (unit testing) veya modül testi uygulanır.
Bu yöntemde, yazılım küçük birimler hâlinde test edilir; bulunan hatalar kaydedilir ve düzeltilir.
Daha sonra bu birimler birleştirilerek, modüller arasındaki etkileşimi doğrulamaya yönelik entegrasyon testi (integration testing) gerçekleştirilir.
Birim ve entegrasyon testleri, hataların daha düşük seviyelerde tespit edilmesini sağlayarak düzeltme maliyetini azaltır.
Entegrasyon testinde yaygın olarak kullanılan 3 temel strateji vardır.
Integration Testing├── Bottom Up Testing├── Top Down Testing└── Umbrella Approach Testing
Bottom Up Testing (Aşağıdan Yukarı)
Alt modüllerden başlanarak üst modüllere doğru ilerleyen bir entegrasyon test yöntemidir.
Üst seviye modüller henüz hazır değilse, sürücü (driver) adı verilen geçici programlar kullanılır.
Sürücüler, test edilen alt modülleri çağıran, onlara test verisi gönderen, çıktıları alan ve sonuçları kontrol eden geçici bileşenlerdir.
Bu yaklaşım, özellikle alt seviyedeki işlevlerin doğrulanmasında ve test sonuçlarının daha kolay gözlemlenmesinde avantaj sağlar.
Top Down Testing (Yukarıdan Aşağı)
Ana modülden başlanarak alt modüllere doğru ilerleyen bir entegrasyon test yöntemidir.
Alt seviye modüller henüz hazır değilse, kukla modül (stub) adı verilen geçici bileşenler kullanılır.
Kukla modüller, henüz tamamlanmamış alt modüllerin yerine geçerek üst modüllerin test edilmesine olanak tanır.
Bu yaklaşım, sistemin genel akışının ve üst düzey kontrol yapısının erken aşamada değerlendirilmesini sağlar.
Özellikle kullanıcıya görünen ana iş akışlarının erken doğrulanması açısından yararlıdır.
Umbrella Uproach (Şemsiye Yaklaşımı)
Şemsiye yaklaşımı, bottom-up ve top-down entegrasyon stratejilerinin birlikte kullanıldığı bir yaklaşımdır.
Bu yöntemde, kullanıcı etkileşimi yüksek bölümler ve kritik iş akışları öncelikli olarak ele alınır.
Girişe yakın modüller genellikle aşağıdan yukarıya doğru entegre edilirken, çıktı ve kontrol akışına yakın modüller yukarıdan aşağıya doğru birleştirilebilir.
Bu yaklaşım, özellikle kullanıcı arayüzü yoğun sistemlerde erken geri bildirim alınmasına yardımcı olur.
Böylece sistemin farklı bölümleri eşzamanlı olarak ilerletilebilir ve kritik işlevler daha erken değerlendirilebilir.
Beyaz Kutu Testinde Kapsam Analizleri
Birim ve entegrasyon testlerini gerçekleştirirken temel soru şudur: “Kodun ne kadarını test ettik?”
Beyaz kutu testinde, testlerin yeterliliğini ölçmek için kapsam analizleri (coverage analysis) kullanılır.
Kapsam analizi, test senaryolarının kodun hangi bölümlerine dokunduğunu ve hangi bölümlerin henüz test edilmediğini sayısal olarak ortaya koyar.
Kapsam analizlerini iki ana grupta inceleyebiliriz:
Veri Kapsamı (Data Coverage): Değişkenlerin ve verilerin izini sürer.
Kod Kapsamı (Code Coverage): Mantıksal yolların ve ifadelerin izini sürer.
Kapsam Analizleri (Detaylı İnceleme)
Kapsam analizleri, yazılımın iç yapısını ve veri akışını doğrulamak için kullanılan temel yöntemlerdir.
Bu analizler, testlerin kapsamını ve kalitesini ölçmek için iki ana başlık altında toplanır.
1. Veri Kapsamı (Data Coverage)
Veri kapsamı, yazılım boyunca verinin nasıl tanımlandığını, kullanıldığını, değiştirildiğini ve aktarıldığını incelemeye odaklanır.
Bu inceleme; değişkenler, sabitler, diziler ve veri yapıları içinde tutulan değerleri kapsar.
Veri kapsamı yaklaşımında kod, kontrol akışının yanı sıra veri akışı ve veri durumları açısından da ele alınır.
Bu yaklaşım, veri odaklı beyaz kutu test senaryoları ile girdiler ve beklenen çıktılar üzerinden kurulan kara kutu test senaryoları arasında ilişki kurmayı kolaylaştırır.
Veri Kapsamı Alt Başlıkları
Veri Akışı (Data Flow)
Alt Sınırlar (Sub-Boundaries)
Formüller ve Denklemler (Formulas and Equations)
Hata Zorlaması (Error Forcing)
Veri Akışı (Data Flow)
Veri akışı, bir verinin program içinde nerede tanımlandığını, nasıl kullanıldığını, hangi işlemlerden geçtiğini ve nerede sonlandığını izlemeyi içerir.
Birim testi düzeyinde bu izleme daha kolaydır; çünkü daha küçük modüller üzerinde değişken tanımları, kullanımları ve dönüşümleri daha açık biçimde takip edilebilir.
Dinamik incelemelerde, bir hata ayıklayıcı (debugger) ve izleme değişkenleri (watch variables) kullanılarak program yürütülürken ara değerler gözlemlenebilir.
Statik beyaz kutu incelemesinde ise program çalıştırılmadan, değişkenlerin tanımlanma ve kullanılma noktaları ile olası veri akış yolları analiz edilir.
Bu nedenle veri akışı analizi, hem statik hem de dinamik beyaz kutu testlerinde önemli bir yere sahiptir.
Alt Sınırlar (Sub-Boundaries)
Alt sınırlar, sistemin belirli kaynak veya koşul eşiklerine yaklaştığı bölgeleri ifade eder.
Bu tür bölgeler, sabit sınır değerlerinden farklı olarak çalışma ortamına göre değişebilir.
Özellikle bellek, disk alanı, bağlantı sayısı, kuyruk kapasitesi ve zaman aşımı gibi kaynaklara bağlı sınırlar, hataların sık görüldüğü noktalardır.
Örnek: Düşük RAM ile çalışan bir işletim sisteminde, veriler geçici olarak sabit diskteki bir alan kullanılarak yönetilebilir. Bu durumda etkili sınır yalnızca RAM miktarına değil, aynı zamanda kalan disk alanına da bağlıdır. Bu nedenle hata olasılığı, bu tür alt sınır bölgelerinde artar.
Formüller ve Denklemler
Yazılımdaki bazı hesaplamalar, doğrudan görünür olmayan formüller ve denklemler üzerine kuruludur.
Bu yapılar çoğu zaman kodun içinde dağılmış, yardımcı fonksiyonlara bölünmüş veya dolaylı işlemler içinde gizlenmiş olabilir.
Bu nedenle test sırasında yalnızca sonuca değil, sonuca götüren hesaplama mantığına da dikkat edilmelidir.
Özellikle finansal hesaplamalar, bilimsel işlemler, puanlama sistemleri ve dönüşüm formülleri bu açıdan dikkatle incelenmelidir.
Hata Zorlaması (Error Forcing)
Hata zorlaması, bir değişkene olağan akışta beklenmeyen veya sınırda bir değerin bilinçli olarak atanması ve yazılımın bu duruma nasıl tepki verdiğinin incelenmesidir.
Bu yöntem, özellikle dinamik beyaz kutu testinde hata ayıklayıcı (debugger) kullanılarak uygulanabilir.
Test uzmanı, program çalışırken bir değişkenin değerini değiştirerek istisna durumlarını, hata yönetimini ve koruyucu kontrolleri gözlemleyebilir.
Böylece normal yürütme sırasında zor ulaşılan hata senaryoları daha kolay test edilebilir.
Örneğin, bir hata ayıklayıcı yardımıyla bir değişkenin değeri sıfıra zorlanabilir ve sistemin bu durumda sıfıra bölme, geçersiz durum veya beklenmeyen akış gibi durumları nasıl ele aldığı incelenebilir.
Kod Kapsamı
Kara kutu testi, yazılımın dıştan gözlenen davranışını değerlendirir; ancak iç yapı ve yürütme yollarının incelenmesi için beyaz kutu testine de ihtiyaç vardır.
Kod kapsamı yaklaşımında amaç, testler çalıştırıldığında kodun hangi bölümlerinin yürütüldüğünü belirlemek ve kritik yapıların gerçekten sınandığını doğrulamaktır.
Bu kapsamda; modüllerin giriş ve çıkışları, yürütülen satırlar, karar noktaları ve mantıksal yollar analiz edilir.
Bu test metodolojisine kod kapsamı testi (code coverage testing) adı verilir.
Kod kapsamı testi, program çalıştırılarak gerçekleştirilen dinamik beyaz kutu testi kapsamında ele alınır.
Test uzmanı, yürütme sırasında kodun hangi bölümlerinin çalıştığını, hangi dalların izlendiğini ve hangi kısımların hiç test edilmediğini gözlemleyebilir.
Bu yaklaşım, yalnızca hataların ortaya çıkarılmasını değil, aynı zamanda testlerin kod üzerinde ne ölçüde etkili olduğunu değerlendirmeyi de sağlar.
Kod tabanlı test (code-based testing), yürütme odaklı tekniklerle kodun iç yapısının sınanmasına dayanır ve beyaz kutu testinin temel uygulama alanlarından biridir.
Kod tabanlı testin temel gereklilikleri:
Test hedeflerini anlamak ve buna uygun test senaryoları oluşturmak
Programlama stillerini ve kodlama standartlarına uyumu değerlendirmek
Mantıksal hataları ve kodlama sırasında yapılan yanlış varsayımları tespit etmek
Yürütme yollarına ilişkin eksik veya hatalı varsayımları belirlemek
Yazım hataları, dikkatsizlik kaynaklı kusurlar ve basit kodlama hatalarını bulmak
İfade Kapsamı (Statement Coverage)
En temel kod kapsamı ölçütlerinden biri ifade kapsamı (statement coverage) veya satır kapsamı (line coverage) olarak adlandırılır.
Bu yaklaşımda amaç, programdaki her ifadenin en az bir kez çalıştırıldığını doğrulamaktır.
İfade kapsamı, testlerin kodun hangi bölümlerine ulaştığını göstermesi bakımından yararlıdır; ancak tek başına yeterli değildir.
Not
İfade kapsamı, uygulanması en kolay ve maliyeti görece düşük kapsam ölçütlerinden biridir. Ancak yalnızca her ifadenin en az bir kez çalıştırıldığını gösterir; karar yapılarının, koşulların ve farklı yürütme yollarının gerçekten test edilip edilmediğini garanti etmez.
Örnek
print("Good Morning")print("Be Positive")print("Today is a Great Day")
Yukarıdaki programda tüm ifadeler en az bir kez çalıştırıldığında, ifade kapsamı sağlanmış olur. Ancak ifade kapsamı yanıltıcı olabilir.
Çünkü bu ölçüt, yalnızca ifadelerin çalıştırılıp çalıştırılmadığını gösterir; programın izlediği farklı yollar, karar noktaları ve alternatif akışlar hakkında yeterli bilgi vermez.
Yol Kapsamı (Path Coverage)
Yol kapsamı, programın kontrol akışı içinde yer alan farklı yürütme yollarının test edilmesini ifade eder.
Teorik olarak amaç, programdaki tüm olası yolları çalıştırmaktır.
Ancak koşul sayısı ve özellikle döngüler arttıkça, tüm yolların test edilmesi çoğu zaman pratik olmaktan çıkar.
Bu nedenle uygulamada, yol kapsamına yaklaşmak için daha yönetilebilir ölçütler olan dal kapsamı (branch coverage) ve benzeri kapsam türleri kullanılır.
Döngüler, yapılandırılmış programların kritik parçalarıdır; çünkü kontrol akışının yönü ve ifadelerin kaç kez yürütüleceği, döngülerin başlangıç, devam ve bitiş koşullarına bağlıdır.
Örnek
# Farklı yolları görmek için date_str değerini değiştirindate_str ="25-12-2008"time_str ="10:30:00"print("Good Morning")if date_str =="25-12-2008":print("MERRY CHRISTMAS")print(f"The date is: {date_str}")print(f"The time is: {time_str}")
Bu programda en az iki farklı yürütme yolu vardır:
date_str == "25-12-2008" koşulu doğru olduğunda izlenen yol
koşul yanlış olduğunda izlenen yol
Eğer program yalnızca date_str = "25-12-2008" değeriyle test edilirse, tüm ifadeler çalıştırılmış olabilir.
Ancak bu durumda yalnızca koşulun doğru olduğu yol test edilmiş olur.
Koşul Kapsamı (Condition Coverage)
Koşul kapsamı, bir karar ifadesi içindeki temel koşulların (atomic conditions) ayrı ayrı değerlendirilmesine odaklanır.
Amaç, her temel koşulun en az bir kez doğru (True) ve en az bir kez yanlış (False) sonuç üretmesini sağlamaktır.
Bu yönüyle koşul kapsamı, yalnızca karar sonucuna odaklanan dal kapsamından daha ayrıntılıdır.
Özellikle bir if ifadesi içinde and, or gibi mantıksal operatörlerle birden fazla koşul birlikte kullanıldığında önem kazanır.
İki temel koşul varsa, her biri için True ve False durumları dikkate alınır.
Dolayısıyla tam koşul kapsamı için, her koşulun her iki sonucu da en az bir kez görülmelidir.
Koşul içeren bir if ifadesi:
# Test senaryolarını denemek için değerleri değiştirindate_str ="25-12-2008"time_str ="00:00:00"print("1: Good Morning")if date_str =="25-12-2008"and time_str =="00:00:00": # 2print("3: MERRY CHRISTMAS")print(f"4: The date is: {date_str}")print(f"5: The time is: {time_str}")
4 farklı senaryo için test edilmeli
Date
Time
Yürütülen Satırlar
25-12-2007
11:11:11
1, 2, 5, 6, 7
25-12-2007
00:00:00
1, 2, 5, 6, 7
25-12-2008
11:11:11
1, 2, 5, 6, 7
25-12-2008
00:00:00
1, 2, 3, 4, 5, 6, 7
Görev
def eval_function(X, Y, A):if (X >1) and (Y ==0): A = A / Xif (X ==2) or (A >1): A = A +1return A# Çözümdeki test senaryolarını burada deneyebilirsiniz:X, Y, A =2, 0, 3print(f"Girdi: X={X}, Y={Y}, A={A} | Çıktı: A={eval_function(X, Y, A)}")
Yukarıdaki kod bloğu için statement coverage test durumlarını yazınız.