White-Box testleri

White-Box Yazılım Testleri (açık kutu testi, cam kutu testi, şeffaf kutu testi ve yapısal test olarak da bilinir), bir uygulamanın işlevselliğinin (Yani Black-Box Testlerinin) aksine iç yapılarını veya işleyişini test eden bir yazılım testi yöntemidir. White-Box Yazılım Testlerinde, test senaryolarını tasarlamak için sistemin dahili bir perspektifi kullanılır. Test uzmanı bir kimse, koddaki yolları çalıştırmak ve beklenen çıktıları belirlemek için girdileri seçer. Bu, bir devredeki düğümleri test etmeye benzer, örneğin devre içi test (ICT). White-Box Yazılım Testleri, yazılım test sürecinin Birim, Entegrasyon [en] ve Sistem seviyelerinde uygulanabilir. Geleneksel test uzmanları beyaz kutu testinin birim düzeyinde yapıldığını düşünme eğiliminde olsalar da, günümüzde entegrasyon ve sistem testleri için daha sık kullanılmaktadır. Bir birim içindeki yolları, entegrasyon sırasında birimler arasındaki yolları ve sistem düzeyinde bir test sırasında alt sistemler arasındaki yolları test edebilir. Bu test tasarımı yöntemi birçok hata veya sorunu ortaya çıkarabilse de, spesifikasyonun uygulanmamış kısımlarını veya eksik gereksinimleri gözden kaçırma potansiyeline sahiptir. White-Box Yazılım Testlerinin tasarım odaklı olduğu durumlarda,^[1] yani, yazılımın her bir bileşeninin nasıl davranması gerektiğine dair üzerinde anlaşmaya varılmış spesifikasyonlarla yönlendirildiği durumlarda (DO-178C [en] ve ISO 26262 [en] süreçlerinde olduğu gibi), White-Box Yazılım Testleri Tasarım teknikleri uygulanmamış veya eksik gereksinimler için değerlendirme yapabilir.

White-box testleri tasarım teknikleri aşağıdaki Kod Kapsama [en] kriterlerini içerir:

Kontrol Akışı [en] testi
Veri akışı testi
Dal testi
İfade kapsamı
Karar kapsamı
Değiştirilmiş Koşul/Karar Kapsamı [en]
Ana yol testi
Yol testi

Genel Bakış

Beyaz kutu testi, uygulamayı kaynak kodu seviyesinde test etme yöntemidir. Bu test senaryoları, yukarıda belirtilen tasarım tekniklerinin kullanılmasıyla elde edilir: Kontrol Akışı [en] testi, veri akışı testi, dal testi, yol testi, ifade kapsamı ve karar kapsamı ile değiştirilmiş koşul/karar kapsamı. Beyaz kutu testi, tüm kodun incelenerek hatasız bir ortam yaratılması için bu tekniklerin kılavuz olarak kullanılmasıdır. Bu beyaz kutu test teknikleri, özü daha sonra gizli hataları azaltmak için uygulamanın kaynak kodu düzeyinde dikkatli bir şekilde test edilmesi olan beyaz kutu testinin yapı taşlarıdır.^[2] Bu farklı teknikler, hataları en aza indirmek ve hatasız bir ortam yaratmak için kaynak kodun görünür her yolunu kullanır. Beyaz kutu testinin tüm amacı, kodun hangi satırının çalıştırıldığını bilme ve doğru çıktının ne olması gerektiğini belirleyebilme yeteneğidir.^[2]

Seviyeler

Birim Testi [en]. White-box testi, daha önce test edilmiş kodla entegrasyon gerçekleşmeden önce kodun amaçlandığı gibi çalıştığından emin olmak için birim testi sırasında yapılır. Birim testi sırasında yapılan beyaz kutu testi, potansiyel olarak birçok hatayı erkenden yakalar ve kod uygulamanın geri kalanıyla entegre edildikten sonra ortaya çıkan hataların ele alınmasına yardımcı olur ve bu nedenle hataların daha sonraki geliştirme aşamalarındaki etkilerini azaltır.^[2]
Entegrasyon Testi [en]. Bu seviyedeki White-Box testi, arayüzlerin birbirleriyle olan etkileşimlerini test etmek için yazılmıştır. Birim seviyesindeki testler, her bir kodun izole bir ortamda test edildiğinden ve uygun şekilde çalıştığından emin olurken entegrasyon, programcı tarafından bilinen arayüzlerin herhangi bir etkileşimi için beyaz kutu testi kullanarak açık bir ortamdaki davranışın doğruluğunu inceler.^[2]
Regresyon. Regresyon testi sırasında White-Box testi, birim ve entegrasyon testi seviyelerinde geri dönüştürülmüş beyaz kutu test senaryolarının kullanılmasıdır.^[2]

Temel Prosedür

White-box testinin temel prosedürleri, test uzmanının test edilen kaynak kod hakkında derinlemesine bilgi sahibi olmasını gerektirir. Programcının ne tür test senaryoları oluşturacağını bilmesi için uygulama hakkında derin bir anlayışa sahip olması gerekir, böylece her görünür yol test için kullanılır. Kaynak kod anlaşıldıktan sonra, oluşturulacak test senaryoları için analiz edilebilir. Aşağıda, beyaz kutu testinin test senaryoları oluşturmak için izlediği üç temel adım yer almaktadır:

Girdi, farklı gereksinim türlerini, işlevsel özellikleri, belgelerin ayrıntılı tasarımını, uygun kaynak kodunu ve güvenlik özelliklerini içerir Bu, tüm temel bilgileri ortaya koymak için beyaz kutu testinin hazırlık aşamasıdır.
İşlem, tüm test sürecini yönlendirmek için risk analizi yapmayı, uygun test planını, test senaryolarını yürütmeyi ve sonuçları iletmeyi içerir. Bu, verilen sonuçların buna göre kaydedildiği uygulamayı kapsamlı bir şekilde test ettiklerinden emin olmak için test senaryoları oluşturma aşamasıdır.
Çıktı, yukarıdaki tüm hazırlıkları ve sonuçları kapsayan nihai raporun hazırlanmasını içerir.

Avantajlar

Side effects of having the knowledge of the source code is beneficial to thorough testing.
Optimization of code becomes easy as inconspicuous bottlenecks are exposed.
Gives the programmer introspection because developers carefully describe any new implementation.
Provides traceability of tests from the source, thereby allowing future changes to the source to be easily captured in the newly added or modified tests.^[3]
Easy to automate.^[4]
Provides clear, engineering-based rules for when to stop testing.^[4]^[5]

Dezavantajlar

White-box testleri, belirli bir uygulamanın ayrıntılarını test etmek için yazılır. Bu, test uygulamaya sıkı sıkıya bağlı olduğu için uygulama değiştiğinde testlerin başarısız olacağı anlamına gelir. Testleri güncellemek için ek çalışma yapılması gerekir, böylece uygulama değiştirildiğinde tekrar eşleşirler. Öte yandan, Black-Box Testinde testler uygulamadan bağımsızdır ve bu nedenle uygulama değişse de uygulamanın çıktısı veya yan etkileri değişmezse başarılı bir şekilde çalışmaya devam ederler.
Test edilen kod, aynı işlevselliği farklı bir şekilde uygulamak için yeniden yazılabilir ve bu da teste dahil edilen varsayımları geçersiz kılar. Bu durum, testlerin gereksiz yere başarısız olmasına ya da en kötü ihtimalle yanlış pozitif sonuç veren ve koddaki hataları maskeleyen testlere neden olabilir. White-Box Yazılım Testi hiçbir zaman test edilen kodun amaçlanan davranışını test edecek şekilde yazılmamıştır, bunun yerine yalnızca belirli bir uygulamanın yaptığı şeyi yapacak şekilde yazılmıştır.
White-Box Yazılım Testi teste karmaşıklık getirir çünkü test uzmanının program hakkında bilgi sahibi olması veya test ekibinin programı kod düzeyinde anlayabilen en az birçok iyi programcıya sahip olması gerekir. White-Box Yazılım Testi, yapılması gereken test seviyesinin karmaşıklığı nedeniyle yüksek bilgi seviyesine sahip bir programcı gerektirir.
Bazı durumlarda, uygulamanın mevcut her koşulunu test edebilmek gerçekçi değildir ve bazı koşullar test edilmeyecektir.
Testler, mevcut haliyle yazılıma odaklanır ve eksik işlevler keşfedilemeyebilir.

Çağdaş Görünüm

Daha modern bir görüşe göre, beyaz kutu testi ile kara kutu testi arasındaki ikilik bulanıklaşmış ve daha az önemli hale gelmiştir. “Beyaz kutu” başlangıçta kaynak kodu kullanmak anlamına gelirken ve kara kutu gereksinimleri kullanmak anlamına gelirken, testler artık çeşitli soyutlama düzeylerinde birçok belgeden türetilmektedir. Asıl mesele, testlerin genellikle girdi alanı, bir grafik veya mantıksal yüklemler gibi soyut bir yapıdan tasarlanmasıdır ve soru, bu soyut yapıyı hangi soyutlama düzeyinden türettiğinizdir.^[4] Bu kaynak kodu, gereksinimler, girdi alanı açıklamaları veya düzinelerce tasarım modeli türünden biri olabilir. Bu nedenle, “White-Box / Black-Box” ayrımı daha az önemlidir ve terimler daha az ilgilidir.

Korsanlama

Sızma Testinde [en] White-Box testi, Beyaz Şapkalı Bir Bilgisayar Korsanının [en] saldırıya uğrayan sistem hakkında tam bilgiye sahip olduğu bir yöntemi ifade eder.^[6] Beyaz kutu sızma testinin amacı, hedef sistem hakkında bilgi sahibi olan ve muhtemelen temel kimlik bilgilerine sahip olan kötü niyetli bir içeriden kişiyi simüle etmektir. Böyle bir sızma testi için, hangi saldırıların yüksek ayrıcalıklı hesapları nasıl etkileyebileceğini analiz etmek amacıyla genellikle yönetici kimlik bilgileri sağlanır.^[7] Source code can be made available to be used as a reference for the tester. Kaynak kodu, test uzmanı için referans olarak kullanılmak üzere kullanıma sunulabilir. Kod kendi başına bir hedef olduğunda, bu (sadece) bir sızma testi değil, aynı zamanda bir Kaynak Kodu Güvenlik Denetimidir [en] (veya güvenlik incelemesi).^[8] saldırıya uğrayan sistem hakkında tam bilgiye sahiptir.

Ayrıca Bakınız

Kaynakça

^ Stacy Nelson (June 2003), NASA/CR–2003-212806 Certification Processes for Safety-Critical and Mission-Critical Aerospace Software (PDF), Ames Research Center, s. 25, 3 Aralık 2024 tarihinde kaynağından arşivlendi (PDF)5 Haziran 2025, [Glossary] White Box Testing: Design-driven testing where engineers examine internal workings of code
^ ^a ^b ^c ^d ^e Williams, Laurie. "White-Box Testing" (PDF). ss. 60-61, 69. 3 Mart 2016 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 13 Şubat 2013. ^{[doğrulama gerekli]}
^ Binder, Bob (2000). Testing Object-oriented Systems. Addison-Wesley Publishing Company Inc. ISBN 9780201809381.
^ ^a ^b ^c Ammann, Paul; Offutt, Jeff (2008). Introduction to Software Testing. Cambridge University Press. ISBN 978-0-521-88038-1. 25 Nisan 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Haziran 2025.
^ Myers, Glenford (1979). The Art of Software Testing. John Wiley and Sons. ISBN 9780471043287.
^ "A Penetration Testing Model" (PDF). Federal Office for Information Security (BSI). 4 Nisan 2025 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 5 Haziran 2025.
^ Baran, Ewelina (20 Şubat 2023). "Types of penetration testing". Blaze Information Security GmbH. 12 Eylül 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 12 Eylül 2024.
^ Sullivan, James. "What is Code Audit: Understanding its Purpose and Process". 17 Web Dev, LLC. 8 Eylül 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 12 Eylül 2024.

Dış bağlantılar

BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): http://www.testingstandards.co.uk/Component%20Testing.pdf Standard for Software Component Testing], Working Draft 3.4, 27. April 2001.
http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf has more information on control flow testing and data flow testing.
http://research.microsoft.com/en-us/projects/pex/ Pex – Automated white-box testing for .NET

[1] Stacy Nelson (June 2003), NASA/CR–2003-212806 Certification Processes for Safety-Critical and Mission-Critical Aerospace Software (PDF), Ames Research Center, s. 25, 3 Aralık 2024 tarihinde kaynağından arşivlendi (PDF)5 Haziran 2025, [Glossary] White Box Testing: Design-driven testing where engineers examine internal workings of code

[level2-2] Williams, Laurie. "White-Box Testing" (PDF). ss. 60-61, 69. 3 Mart 2016 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 13 Şubat 2013. ^{[doğrulama gerekli]}

[binder2-3] Binder, Bob (2000). Testing Object-oriented Systems. Addison-Wesley Publishing Company Inc. ISBN 9780201809381.

[introtest2-4] Ammann, Paul; Offutt, Jeff (2008). Introduction to Software Testing. Cambridge University Press. ISBN 978-0-521-88038-1. 25 Nisan 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Haziran 2025.

[myers2-5] Myers, Glenford (1979). The Art of Software Testing. John Wiley and Sons. ISBN 9780471043287.

[6] "A Penetration Testing Model" (PDF). Federal Office for Information Security (BSI). 4 Nisan 2025 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 5 Haziran 2025.

[7] Baran, Ewelina (20 Şubat 2023). "Types of penetration testing". Blaze Information Security GmbH. 12 Eylül 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 12 Eylül 2024.

[8] Sullivan, James. "What is Code Audit: Understanding its Purpose and Process". 17 Web Dev, LLC. 8 Eylül 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 12 Eylül 2024.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]