Yazılım Test Süreçleri

Sınır Değer Testi (Boundary Value Testing)

Dr. Öğr. Üyesi Oğuz Emre Kural

2026

Sınır Değer Testi

  • Önceki derslerde, bir fonksiyonun bir kümeden aldığı değerleri başka bir kümeye eşlediğini görmüştük:
    • girişler domain
    • çıktılar range
  • Bir program da benzer biçimde düşünülebilir:
    • program girdileri onun tanım kümesini
    • program çıktıları ise değer kümesini oluşturur.
  • Bu bölümde, programın işlevsel yapısından yararlanarak test durumları üretmeye odaklanacağız.

Sınır Değer Testine Giriş

  • Input domain testing, en bilinen specification-based testing tekniklerinden biridir.
  • Bu yaklaşım yaygın olarak sınır değer testi adıyla da anılır.
  • Tarihsel olarak daha çok girdi uzayı üzerinde uygulanmıştır.
  • Bununla birlikte, bazı durumlarda aynı mantık çıktı uzayı üzerinden de uygulanabilir.
  • Özellikle Commission probleminde göreceğimiz gibi, range-based test tasarımı klasik input-based yaklaşıma güçlü bir tamamlayıcı olabilir.

Input Domain Testing’de İki Temel Boyut

  • Sınır değer testinde iki bağımsız değerlendirme boyutu vardır:
  1. Geçersiz değerler dikkate alınacak mı?
    • Yalnızca geçerli girişler mi test edilecek?
    • Yoksa sınırın dışındaki geçersiz değerler de mi dahil edilecek?
  2. Tek değişken hatası varsayımı yapılacak mı?
    • Hata yalnızca tek bir değişkenin yanlış değerinden mi kaynaklanıyor kabul edilecek?
    • Yoksa birden fazla değişkenin etkileşimi de dikkate alınacak mı?

Dört Temel Sınır Değer Testi Türü

  • Bu iki boyut birleştirildiğinde dört temel yaklaşım ortaya çıkar:
    • Normal sınır değer testi
    • Gürbüz (Robust) sınır değer testi
    • En kötü durum sınır değer testi
    • Gürbüz en kötü durum sınır değer testi

Tek Hata Varsayımı

  • Klasik sınır değer testi yaklaşımında yaygın varsayım:
    • tek hata varsayımı
  • Buna göre hataların, çoğunlukla tek bir değişkenin yanlış değerinden kaynaklandığı kabul edilir.
  • Ancak bu varsayım her zaman yeterli değildir.
  • Eğer iki veya daha fazla değişkenin birlikte oluşturduğu etkileşim önemliyse, değişkenlerin kartezyen çarpımı (cross product) dikkate alınmalıdır.
  • Bu varsayım güvenilirlik kuramından gelir; fakat gerçek yazılımlarda değişken etkileşimleri çok önemli olabilir.

İki Değişkenli Fonksiyon Modeli

  • Çizimleri ve anlatımı sadeleştirmek için iki değişkenli bir fonksiyon ele alınır:

\[ F(x_1, x_2) \]

  • Program düzeyinde bu iki giriş değişkeninin bazı sınırları olduğu varsayılır:

\[ a \leq x_1 \leq b \]

\[ c \leq x_2 \leq d \]

  • Buradaki sınırlar açıkça belirtilmiş olabilir; bazı durumlarda ise yalnızca problem tanımından çıkarılır.

Girdi Alanının Gösterimi

  • Şekilde gölgeli dikdörtgen bölge, \(F\) fonksiyonu için geçerli giriş uzayını temsil eder.
  • Sınırlar da bu geçerli alanın bir parçasıdır.
  • Yani dikdörtgenin içinde kalan ve sınırların üzerinde bulunan her nokta, fonksiyon için meşru bir girdi kabul edilir.
  • Burada küçük bir terminoloji notu vardır:
    • \([a,b]\) ve \([c,d]\) aralıkları da “range” diye anılabildiğinden,
    • input domain ile output range kavramları bağlama göre dikkatle ayrılmalıdır.

Normal Sınır Değer Testi

  • Sınır değer testinin tüm türleri, test durumlarını belirlemek için girdi uzayının sınırlarına odaklanır.
  • Temel gerekçe şudur:
    • Hatalar çoğu zaman giriş değişkenlerinin uç (extreme) değerlerine yakın bölgelerde ortaya çıkar.
  • Özellikle aşağıdaki tür hatalar sınır bölgelerinde sık görülür:
    • Karşılaştırma operatörü hataları (< yerine <= gibi)
    • Sayaç başlangıç hataları
    • 0 yerine 1’den başlama veya tersi türü off-by-one hataları

Normal Sınır Değer Analizinin Temel Fikri

  • Temel yaklaşım, her giriş değişkeni için şu değerleri dikkate almaktır:
    • minimum
    • minimumun hemen üstü
    • nominal değer
    • maksimumun hemen altı
    • maksimum
  • Araçlarda bu değerler çoğu zaman şu şekilde adlandırılır:
    • min
    • min+
    • nom
    • max-
    • max
  • Robust biçimler buna ek olarak min- ve max+ değerlerini kullanır.
  • Normal sınır değer testi yalnızca geçerli giriş aralığı içindeki değerlere odaklanır.

Tek Hata Varsayımı ve Normal BVA

  • Normal sınır değer analizi kritik bir varsayıma dayanır:
    • tek hata varsayımı
  • Buna göre bir hata, çoğu zaman aynı anda iki ya da daha fazla değişkenin değil, tek bir değişkenin sınırdaki yanlış değerinden kaynaklanır.
  • Bu nedenle testler oluşturulurken:
    • bir değişken sınır değerlerini alır,
    • diğer tüm değişkenler ise nominal değerde tutulur.

İki Değişken İçin Test Noktaları

  • Şekilde, \(F(x_1, x_2)\) için normal sınır değer analizi kapsamında seçilen test noktaları gösterilir.
  • Mantık şudur:
    • Önce \(x_1\) sınır değerlerini alırken \(x_2\) nominal tutulur.
    • Sonra \(x_2\) sınır değerlerini alırken \(x_1\) nominal tutulur.
  • Böylece her değişken tek tek sınanır.

İki Değişkenli Fonksiyon İçin Normal BVA Test Kümesi

  • \(F(x_1, x_2)\) için normal sınır değer analizi test durumları:

\[ \{ \langle x_{1nom}, x_{2min} \rangle, \langle x_{1nom}, x_{2min+} \rangle, \langle x_{1nom}, x_{2nom} \rangle, \langle x_{1nom}, x_{2max-} \rangle, \langle x_{1nom}, x_{2max} \rangle, \]

\[ \langle x_{1min}, x_{2nom} \rangle, \langle x_{1min+}, x_{2nom} \rangle, \langle x_{1max-}, x_{2nom} \rangle, \langle x_{1max}, x_{2nom} \rangle \} \]

  • Ortadaki nominal nokta iki kez yazılmadığı için toplam test sayısı:

\[ 4n + 1 \]

  • Burada \(n\), giriş değişkeni sayısıdır.

Sınır Değer Analizini Genelleştirme

  • Temel sınır değer analizi tekniği iki yönde genelleştirilebilir:
    • değişken sayısı açısından
    • değer aralığı / veri tipi açısından
  • Temel mantık değişmez:
    • bir değişken sınır değerlerini alır,
    • diğer değişkenler nominal değerde tutulur.

Değişken Sayısına Göre Genelleme

  • \(n\) değişkenli bir fonksiyon için:
    • her adımda yalnızca bir değişken sınır değerleri boyunca gezdirilir,
    • kalan \(n-1\) değişken nominal değerde sabit tutulur.
  • Her değişken için kullanılan beş temel değer:
    • min, min+, nom, max-, max
  • Bu yaklaşım tekrarlandığında, \(n\) değişken için toplam benzersiz test durumu sayısı:

\[ 4n + 1 \]

  • Buradaki +1, ortak nominal test durumundan gelir.

Aralıkların Türüne Göre Genelleme

  • Boundary value analysis yalnızca sayısal değişkenlerle sınırlı değildir.
  • Asıl belirleyici unsur, değişkenin türünün sıralanabilir ve mümkünse sınırlandırılmış olmasıdır.
  • Örneğin NextDate probleminde değişkenler:
    • ay (month)
    • gün (day)
    • yıl (year)
  • Bazı dillerde ay bilgisi 1..12 şeklinde sayısal tutulabilir.
  • Başka dillerde ise kullanıcı tanımlı türlerle şu biçimde ifade edilebilir:
    • {Jan., Feb., ..., Dec.}
  • Her iki durumda da min, min+, nom, max-, max değerleri bağlama göre belirlenebilir.

Ayrık ve Sınırlı Değerler

  • Bir değişken ayrık (discrete) ve sınırlı (bounded) ise sınır değerlerini belirlemek genellikle kolaydır.
  • Commission problemindeki değişkenler bu türdendir.
  • Böyle durumlarda şu değerler açıkça seçilebilir:
    • minimum
    • minimumun hemen üstü
    • nominal
    • maksimumun hemen altı
    • maksimum
  • Yani klasik boundary value kümesi doğrudan uygulanabilir.

Açık Sınırlar Yoksa

  • Bazı problemlerde sınırlar açık biçimde verilmez.
  • Triangle problem buna örnektir.
  • Böyle durumlarda sınırlar çoğu zaman yapay (artificial) olarak belirlenir.
  • Alt sınır çoğunlukla nettir:
    • bir kenar uzunluğu için alt sınır \(1\) alınabilir,
    • negatif uzunluk anlamsızdır.
  • Üst sınır ise daha belirsiz olabilir:
    • veri tipinin izin verdiği en büyük değer,
    • ya da test amacıyla belirlenen yapay bir üst sınır.
  • Örneğin \(200\) veya \(2000\) gibi bir üst sınır tercih edilebilir.

Sayısal Olmayan Türlerde Sınırlar

  • Bir veri tipi üzerinde sıralama ilişkisi tanımlanabiliyorsa, çoğu zaman şu değerler türetilebilir:
    • min, min+, nom, max-, max
  • Örneğin alfabe karakterleri için örnek test değerleri şu şekilde seçilebilir:
    • a, b, m, y, z
  • Dolayısıyla sınır değer analizi, yalnızca sayılara değil, uygun biçimde sıralanabilen başka veri tiplerine de uygulanabilir.

Boolean Değişkenlerde Durum

  • Boolean değişkenler için sınır değer analizi çok anlamlı değildir.
  • Çünkü uç değerler zaten doğrudan:
    • TRUE
    • FALSE
  • Ancak geri kalan üç konum için (min+, nom, max-) doğal ve sezgisel bir karşılık yoktur.
  • Bu nedenle Boolean değişkenler, sınır değer analizi yerine daha çok karar tablosu tabanlı testlere uygundur.

Mantıksal Değişkenlerde Sezgisel Sınırlılık

  • ATM örneğinde olduğu gibi bazı mantıksal veya kategorik değişkenler vardır:
    • PIN’in kendisi
    • işlem türü: para yatırma, çekme, sorgulama
  • Bu tür değişkenler için sınır değer analizi mekanik olarak uygulanabilse bile, ortaya çıkan testler çoğu zaman testçinin sezgisiyle tam örtüşmez.
  • Yani her veri tipi için sınır değer analizi aynı derecede doğal veya verimli değildir.

Sınır Değer Analizinin Kısıtları

  • Boundary value analysis, en iyi şu durumda çalışır:
    • program birkaç bağımsız (independent) değişkenin fonksiyonuysa,
    • bu değişkenler sınırlı fiziksel nicelikleri (bounded physical quantities) temsil ediyorsa.
  • Ayrıca değişken değerleri arasında bir sıralama ilişkisi (ordering relation) bulunmalıdır.
  • Yani iki değer için hangisinin küçük, eşit veya büyük olduğu anlamlı biçimde söylenebilmelidir.

Sıralanamayan Değişkenlerde Sorun

  • Bazı değer kümeleri doğal bir sıralama ilişkisini desteklemez.
  • Örneğin:
    • araba renkleri
    • futbol takımları
  • Bu tür değişkenlerde min, min+, nom, max-, max fikri anlamlı değildir.
  • Dolayısıyla bu tür alanlar için sınır değer testi uygun bir yaklaşım değildir.

Bağımsızlık Varsayımının Sınırı

  • Boundary value analysis, değişkenlerin gerçekten bağımsız olduğunu varsayar.
  • Ancak gerçek problemler çoğu zaman bu kadar basit değildir.
  • NextDate örneğinde:
    • ay, gün, yıl değişkenleri birbirinden bağımsız değildir.
  • Özellikle şu durumlar güçlü bağımlılıklar içerir:
    • Şubat, artık yıllar, ay sonu, yıl sonu
  • Bu nedenle yalnızca tekil sınır değerlerine bakmak, kritik hata bölgelerini kaçırabilir.

Neden Yetersiz Kalabilir?

  • Boundary value analysis test durumları çoğu zaman yalnızca değişkenlerin uç değerlerinden türetilir.
  • Bu üretim süreci:
    • fonksiyonun doğasını,
    • değişkenlerin anlamsal ilişkilerini,
    • alan bilgisini doğrudan dikkate almaz.
  • Sonuç olarak bu yaklaşım bazen:
    • az içgörüyle üretilmiş,
    • mekanik,
    • görece yüzeysel test kümeleri ortaya çıkarır.
  • Kısacası, yöntem hızlıdır; fakat her zaman derinlikli değildir.

Fiziksel Niceliklerde Güçlü Tarafı

  • Buna rağmen fiziksel nicelikler söz konusu olduğunda sınır değer analizi oldukça değerlidir.
  • Çünkü fiziksel sistemlerde sınırlar gerçekten kritik olabilir.
  • Örnek fiziksel nicelikler:
    • sıcaklık
    • basınç
    • hava hızı
    • hücum açısı
    • yük
  • Böyle değişkenlerde alt ve üst sınırlar, doğrudan sistem davranışını etkileyebilir.

Fiziksel Sınırların Önemi

  • Dikkat çekici örneklerden biri, Phoenix Sky Harbor Havalimanı’nın 26 Haziran 1992’de 122°F hava sıcaklığı nedeniyle kapanmasıdır.
  • Sebep, bazı uçuş öncesi ayarların en fazla 120°F kabul edecek şekilde tasarlanmış olmasıdır.
  • Bir başka örnekte, tıbbi analiz sisteminde step motorlarla döndürülen örnek carousel’inin başlangıç hücresine geri dönüş mekaniği, robot kolun ilk hücreyi kaçırmasına neden olabilmektedir.
  • Bu tür örnekler, fiziksel sınırların yazılım açısından ne kadar kritik olabileceğini açıkça gösterir.

Mantıksal Değişkenlerde Zayıflığı

  • Mantıksal veya kod benzeri değişkenlerde aynı sezgisel güç yoktur.
  • Örneğin:
    • PIN numarası
    • telefon numarası
  • Bu tür alanlarda şu değerleri sınamak çoğu zaman anlamlı bir sınır sezgisi üretmez:
    • 0000, 0001, 5000, 9998, 9999
  • Çünkü burada sayısal görünüm olsa da, değişkenin anlamsal yapısı çoğu zaman gerçek bir fiziksel büyüklük değildir.
  • Bu yüzden sınır değer analizi her veri alanında aynı derecede güçlü değildir.

Gürbüz (Robust) Sınır Değer Testi

  • Robust sınır değer testi, normal sınır değer testinin basit bir genişletmesidir.
  • Normal yaklaşımda kullanılan beş değere ek olarak, sınırların hemen dışındaki iki değer de test edilir:
    • min-
    • max+
  • Böylece her değişken için değerlendirilen küme şu hale gelir:
    • min-, min, min+, nom, max-, max, max+

Gürbüz Yaklaşımın Temel Mantığı

  • Normal sınır değer testi yalnızca geçerli girişler üzerinde çalışır.
  • Robust sınır değer testi ise buna ek olarak geçersiz fakat sınıra çok yakın girişleri de dener.
  • Amaç, sistemin sınır ihlallerine nasıl tepki verdiğini görmektir.
  • Yani soru artık yalnızca:
    • “Sınırdaki geçerli değerler doğru işleniyor mu?” değil,
    • “Sınır biraz aşıldığında sistem ne yapıyor?” sorusudur.

İki Değişken İçin Robust Test Noktaları

  • Şekilde, \(F(x_1, x_2)\) için robust sınır değer testi kapsamında seçilen noktalar gösterilir.
  • Normal sınır değer testine ek olarak:
    • alt sınırın hemen altı,
    • üst sınırın hemen üstü değerleri de test kümesine dahil edilir.
  • Yine temel yaklaşım korunur:
    • bir değişken sınanır,
    • diğer değişken nominal değerde tutulur.

Gürbüz Sınır Değer Testinin Odağı

  • Boundary value analysis ile ilgili genellemelerin ve sınırlılıkların çoğu, gürbüz test için de geçerlidir.
  • Ancak robust yaklaşımın en ilginç yönü girişlerden çok beklenen çıktı davranışı ile ilgilidir.
  • Özellikle şu soru önem kazanır:
    • Bir fiziksel nicelik izin verilen maksimumu aştığında ne olmalıdır?
  • Örneğin:
    • bir uçağın kanadında hücum açısı aşırı yükselirse stall oluşabilir,
    • bir asansör yük sınırını aşarsa güvenli davranış beklenir,
    • May 32 gibi bir tarih için hata mesajı üretilmelidir.

Gürbüz Test ve Hata Yönetimi

  • Gürbüz testin temel değeri, dikkati exception handling ve hata yönetimine çekmesidir.
  • Sistem yalnızca doğru girişlerde değil, yanlış girişlerde de öngörülebilir davranmalıdır.
  • Özellikle şu tür sorular kritik hale gelir:
    • Geçersiz değer açıkça reddediliyor mu?
    • Kullanıcıya anlamlı bir hata mesajı veriliyor mu?
    • Program kontrolsüz biçimde çöküyor mu?
    • Sınır ihlali sessizce kabul edilip yanlış işlem yapılıyor mu?

Güçlü Tür Sistemleri ile İlişki

  • Güçlü tipli dillerde gürbüz test bazı durumlarda daha farklı bir görünüm alabilir.
  • Çünkü bazı dillerde değişken, tanımlı aralığın dışındaki bir değeri zaten kabul etmez.
  • Bu durumda aralık dışı değerler:
    • çalışma zamanı hatasına,
    • normal yürütmenin kesilmesine,
    • ya da dil/runtime düzeyinde istisnaya yol açabilir.
  • Bu da şu tasarım sorusunu gündeme getirir:
    • Aralık kontrolü program içinde açıkça mı yapılmalı?
    • Yoksa tür sisteminin kısıtlarına mı güvenilmelidir?
  • Hangi tercih yapılırsa yapılsın, istisna davranışı test edilmelidir.

En Kötü Durum (Worst-Case) Sınır Değer Testi

  • Önceki sınır değer testi türleri, tek hata varsayımı üzerine kuruluydu.
  • Yani aynı anda yalnızca bir değişkenin uç değerde hata ürettiği varsayılıyordu.
  • En kötü durum sınır değer testi ise bu varsayımı gevşetir.
  • Burada amaç, birden fazla değişkenin aynı anda sınır bölgelerinde bulunduğu durumları da sınamaktır.
  • Elektronik devre analizindeki worst-case analysis fikri burada test üretimine uyarlanır.

En Kötü Durum İçin Temel Yaklaşım

  • Her değişken için normal boundary value kümesi alınır:
    • min, min+, nom, max-, max
  • Daha sonra bu kümelerin Kartezyen çarpımı (Cartesian product) alınır.
  • Böylece değişkenlerin sınır değer kombinasyonları sistematik biçimde üretilir.
  • İki değişken için mantık şöyledir:
    • \(x_1\) kendi 5 değerini alır,
    • \(x_2\) kendi 5 değerini alır,
    • tüm kombinasyonlar test edilir.

Test Sayısı

  • \(n\) değişkenli bir fonksiyon için en kötü durum sınır değer testinin ürettiği test sayısı:

\[ 5^n \]

  • Bu sayı, normal sınır değer analizindeki

\[ 4n + 1 \]

test sayısına göre çok daha büyüktür.

  • Bu nedenle en kötü durum testi:
    • daha kapsamlıdır,
    • fakat çok daha fazla test eforu gerektirir.

İki Değişken İçin En Kötü Durum Test Noktaları

  • Şekilde iki değişken için tüm sınır kombinasyonlarının tarandığı görülür.
  • Normal sınır değer analizi testleri, bu kümenin yalnızca bir alt kümesidir.
  • En kötü durum yaklaşımında artık tek değişkenli sınamalar değil, eşzamanlı sınır etkileşimleri de değerlendirilir.

Ne Zaman Tercih Edilir?

  • En kötü durum testi özellikle şu durumda anlamlıdır:
    • fiziksel değişkenler arasında çok sayıda etkileşim varsa,
    • fonksiyonun hata yapma maliyeti yüksekse.
  • Çünkü bazı hatalar yalnızca:
    • iki ya da daha fazla değişken aynı anda uç değerlere yaklaştığında ortaya çıkabilir.
  • Bu açıdan, en kötü durum testi normal sınır değer testine göre daha temkinli bir yaklaşımdır.

Sınırlılıklar

  • En kötü durum testi, sınır değer analizinin genelleme mantığını izler.
  • Bu nedenle aynı temel sınırlılıkları da taşır.
  • Özellikle şu sorun devam eder:
    • değişkenler gerçekten bağımsız değilse,
    • yalnızca mekanik sınır kombinasyonları üretmek yeterli olmayabilir.
  • Yani test sayısı artsa da, her zaman semantik olarak en kritik durumlar yakalanmayabilir.

Gürbüz En Kötü Durum Sınır Değer Testi

  • Daha da katı bir yaklaşım olarak robust en kötü durum testi kullanılabilir.
  • Bu durumda her değişken için yedi değer alınır:
    • min-
    • min
    • min+
    • nom
    • max-
    • max
    • max+
  • Ardından yine Kartezyen çarpım alınır.
  • \(n\) değişken için test sayısı:

\[ 7^n \]

  • Bu yaklaşım hem çoklu sınır etkileşimlerini hem de sınır dışı yakın değerleri birlikte sınar.

İki Değişken İçin Gürbüz En Kötü Durum Noktaları

  • Şekilde robust en kötü durum yaklaşımında test noktalarının daha yoğun bir ızgara oluşturduğu görülür.
  • Bu yoğunluk kapsamı artırır; ancak test maliyetini de çok yükseltir.
  • Bu nedenle bu yaklaşım genellikle:
    • hata maliyetinin çok yüksek olduğu,
    • çok ihtiyatlı test gerektiği durumlarda tercih edilir.

Özel Değer (Special Value) Testi

  • Special value testing, işlevsel testte en yaygın uygulanan yaklaşımlardan biridir.
  • Aynı zamanda en sezgisel ve en az biçimsel olan yaklaşımlardan biridir.
  • Bu yöntemde testçi:
    • alan bilgisini,
    • benzer sistemlerle ilgili deneyimini,
    • hataya açık bölgeler hakkındaki sezgisini kullanarak test durumları üretir.
  • Bu yaklaşım çoğu zaman ad hoc testing olarak da düşünülebilir.

Özel Değer Testinin Özelliği

  • Bu yöntemde sınır değer analizindeki gibi katı ve tekdüze kurallar yoktur.
  • Temel yönlendirici ilke çoğu zaman şudur:
    • iyi mühendislik yargısı (best engineering judgment)
  • Dolayısıyla ortaya çıkan test kümesi:
    • testçiden testçiye değişebilir,
    • standartlaştırılması zor olabilir,
    • ama güçlü içgörü taşıyabilir.

Neden Yine de Önemlidir?

  • Her ne kadar öznel görünse de, özel değer testi oldukça yararlı olabilir.
  • Çünkü bazı kritik test durumları, yalnızca mekanik kurallarla değil, problem alanını anlayarak seçilebilir.
  • Özellikle boundary value yöntemlerinin yetersiz kaldığı yerlerde, bu yaklaşım daha etkili olabilir.
  • Yazılım testinin pratik yönü burada belirginleşir:
    • iyi test kümesi yalnızca kurallardan değil,
    • aynı zamanda testçinin zanaatından ve deneyiminden de doğar.

NextDate İçin İpuçları

  • Özellikle NextDate örneğinde özel değer testinin önemi dikkat çekmektedir.
  • Boundary value yöntemleriyle üretilecek test kümeleri burada tam olarak tatmin edici olmayabilir.
  • Buna karşılık özel değer testi ile şu tür kritik durumlar özellikle hedeflenebilir:
    • 28 Şubat
    • 29 Şubat
    • artık yıllar
  • Bu tür tarihler, fonksiyonun doğruluğunu sınamak açısından sıradan sınır noktalarından daha değerlidir.

Değerlendirme

  • Special value testing yüksek derecede öznel olabilir.
  • Ancak çoğu zaman, hataları ortaya çıkarmada boundary value yöntemleriyle üretilen test kümelerinden daha etkili sonuç verebilir.
  • Bu da şunu gösterir:
    • iyi test tasarımı yalnızca formel tekniklere değil,
    • alan bilgisi ve dikkatli gözleme de dayanır.

Örnekler

  • Bu bölümde ele alınan üç sürekli örnek de üç değişkenli bir fonksiyon olarak modellenmiştir.
  • Her problem için tüm yöntemlerden üretilen bütün test durumlarını yazmak çok yer kaplayacağından, örneklerde seçilmiş test kümeleri üzerinde durulacaktır.
  • Özellikle şu iki yaklaşımın örneklerine odaklanılır:
    • en kötü durum sınır değer testi
    • gürbüz en kötü durum sınır değer testi
  • Amaç, önceki bölümlerde tanıtılan tekniklerin somut problemlere nasıl uygulandığını göstermektir.

Üçgen Problemi İçin Test Durumları

  • Problem tanımında üç kenar için açık sınırlar verilmemiştir; yalnızca kenarların tamsayı olduğu belirtilmiştir.
  • Alt sınır açıktır:
    • Her kenar için alt sınır \(1\) alınır.
  • Üst sınır ise yapay olarak belirlenmiştir:
    • Bu örnekte üst sınır \(200\) seçilmiştir.
  • Buna göre her değişken için kullanılan boundary value kümesi:

\[ \{1, 2, 100, 199, 200\} \]

\[ \{1, 2, 100, 199, 200\} \]

  • Burada:
    • 1 \(\rightarrow\) min
    • 2 \(\rightarrow\) min+
    • 100 \(\rightarrow\) nom
    • 199 \(\rightarrow\) max-
    • 200 \(\rightarrow\) max
  • Robust boundary value testleri bu kümeye 0 ve 201 değerlerini ekler.

Üçgen Problemi İçin Normal Sınır Değer Test Durumları

Durum a b c Beklenen Çıktı
1 100 100 1 İkizkenar
2 100 100 2 İkizkenar
3 100 100 100 Eşkenar
4 100 100 199 İkizkenar
5 100 100 200 Üçgen değil
6 100 1 100 İkizkenar
7 100 2 100 İkizkenar
8 100 100 100 Eşkenar
9 100 199 100 İkizkenar
10 100 200 100 Üçgen değil
11 1 100 100 İkizkenar
12 2 100 100 İkizkenar
13 100 100 100 Eşkenar
14 199 100 100 İkizkenar
15 200 100 100 Üçgen değil

Triangle Problem için Not

  • Tablo 5.1’de görülen test kümesinde tekrar eden durumlar vardır.
  • Özellikle:
    • test case 3
    • test case 8
    • test case 13 aynıdır.
  • Bunlardan ikisi silinmelidir.
  • Ayrıca bu kümede çeşitkenar (scalene) üçgen için test durumu yoktur.

Üçgen Problemi İçin Seçilmiş En Kötü Durum Test Durumları

  • Üç değişkenin her biri için 5 test değeri olduğundan, tam çapraz çarpım:

\[ 5^3 = 125 \]

adet test durumu üretir.

Üçgen Problemi İçin Seçilmiş En Kötü Durum Test Durumları Tablosu

Durum a b c Beklenen Çıktı
1 1 1 1 Eşkenar
2 1 1 2 Üçgen değil
3 1 1 100 Üçgen değil
4 1 1 199 Üçgen değil
5 1 1 200 Üçgen değil
6 1 2 1 Üçgen değil
7 1 2 2 İkizkenar
8 1 2 100 Üçgen değil
9 1 2 199 Üçgen değil
10 1 2 200 Üçgen değil
11 1 100 1 Üçgen değil
12 1 100 2 Üçgen değil
13 1 100 100 İkizkenar
14 1 100 199 Üçgen değil
15 1 100 200 Üçgen değil
16 1 199 1 Üçgen değil
17 1 199 2 Üçgen değil
18 1 199 100 Üçgen değil
19 1 199 199 İkizkenar
20 1 199 200 Üçgen değil
21 1 200 1 Üçgen değil
22 1 200 2 Üçgen değil
23 1 200 100 Üçgen değil
24 1 200 199 Üçgen değil
25 1 200 200 İkizkenar

Triangle Problem için Gözlem

  • Seçilmiş en kötü durum tablosu, bir değişken sabit tutulurken diğer iki değişkenin tüm sınır kombinasyonları değerlerini alabildiğini gösterir.
  • Buradaki kesit, \(a = 1\) düzlemi gibi düşünülebilir.
  • Yani üç boyutlu test uzayının tamamı değil, onun dikdörtgensel bir kesiti gösterilmektedir.
  • Triangle probleminde asıl kritik nokta şudur:
    • sınır değerler tek başına değil,
    • üç kenar arasındaki üçgen eşitsizliği ile birlikte anlam kazanır.

NextDate Fonksiyonu İçin Test Durumları

  • NextDate fonksiyonu için üretilen 125 en kötü durum test durumunun tamamı Tablo 5.3’te verilmiştir.
  • Bu test kümesini dikkatle incelemek gerekir.
  • Çünkü bu kadar büyük bir sınır tabanlı test kümesi iki önemli soruyu gündeme getirir:
    • Test boşlukları (gaps) var mı?
    • Gereksiz tekrarlar (redundant testing) var mı?
  • Örneğin:
    • Gerçekten Ocak 1 tarihini beş farklı yıl için test etmek gerekli midir?
    • Şubat sonu yeterince ve doğru biçimde sınanmış mıdır?

NextDate İçin En Kötü Durum Test Durumları (1–25)

Durum Ay Gün Yıl Beklenen Çıktı
1 1 1 1812 1, 2, 1812
2 1 1 1813 1, 2, 1813
3 1 1 1912 1, 2, 1912
4 1 1 2011 1, 2, 2011
5 1 1 2012 1, 2, 2012
6 1 2 1812 1, 3, 1812
7 1 2 1813 1, 3, 1813
8 1 2 1912 1, 3, 1912
9 1 2 2011 1, 3, 2011
10 1 2 2012 1, 3, 2012
11 1 15 1812 1, 16, 1812
12 1 15 1813 1, 16, 1813
13 1 15 1912 1, 16, 1912
14 1 15 2011 1, 16, 2011
15 1 15 2012 1, 16, 2012
16 1 30 1812 1, 31, 1812
17 1 30 1813 1, 31, 1813
18 1 30 1912 1, 31, 1912
19 1 30 2011 1, 31, 2011
20 1 30 2012 1, 31, 2012
21 1 31 1812 2, 1, 1812
22 1 31 1813 2, 1, 1813
23 1 31 1912 2, 1, 1912
24 1 31 2011 2, 1, 2011
25 1 31 2012 2, 1, 2012

NextDate İçin En Kötü Durum Test Durumları (26–57)

Durum Ay Gün Yıl Beklenen Çıktı
26 2 1 1812 2, 2, 1812
27 2 1 1813 2, 2, 1813
28 2 1 1912 2, 2, 1912
29 2 1 2011 2, 2, 2011
30 2 1 2012 2, 2, 2012
31 2 2 1812 2, 3, 1812
32 2 2 1813 2, 3, 1813
33 2 2 1912 2, 3, 1912
34 2 2 2011 2, 3, 2011
35 2 2 2012 2, 3, 2012
36 2 15 1812 2, 16, 1812
37 2 15 1813 2, 16, 1813
38 2 15 1912 2, 16, 1912
39 2 15 2011 2, 16, 2011
40 2 15 2012 2, 16, 2012
41 2 30 1812 Geçersiz tarih
42 2 30 1813 Geçersiz tarih
43 2 30 1912 Geçersiz tarih
44 2 30 2011 Geçersiz tarih
45 2 30 2012 Geçersiz tarih
46 2 31 1812 Geçersiz tarih
47 2 31 1813 Geçersiz tarih
48 2 31 1912 Geçersiz tarih
49 2 31 2011 Geçersiz tarih
50 2 31 2012 Geçersiz tarih
51 6 1 1812 6, 2, 1812
52 6 1 1813 6, 2, 1813
53 6 1 1912 6, 2, 1912
54 6 1 2011 6, 2, 2011
55 6 1 2012 6, 2, 2012
56 6 2 1812 6, 3, 1812
57 6 2 1813 6, 3, 1813

NextDate İçin En Kötü Durum Test Durumları (58–86)

Durum Ay Gün Yıl Beklenen Çıktı
58 6 2 1912 6, 3, 1912
59 6 2 2011 6, 3, 2011
60 6 2 2012 6, 3, 2012
61 6 15 1812 6, 16, 1812
62 6 15 1813 6, 16, 1813
63 6 15 1912 6, 16, 1912
64 6 15 2011 6, 16, 2011
65 6 15 2012 6, 16, 2012
66 6 30 1812 7, 1, 1812
67 6 30 1813 7, 1, 1813
68 6 30 1912 7, 1, 1912
69 6 30 2011 7, 1, 2011
70 6 30 2012 7, 1, 2012
71 6 31 1812 Geçersiz tarih
72 6 31 1813 Geçersiz tarih
73 6 31 1912 Geçersiz tarih
74 6 31 2011 Geçersiz tarih
75 6 31 2012 Geçersiz tarih
76 11 1 1812 11, 2, 1812
77 11 1 1813 11, 2, 1813
78 11 1 1912 11, 2, 1912
79 11 1 2011 11, 2, 2011
80 11 1 2012 11, 2, 2012
81 11 2 1812 11, 3, 1812
82 11 2 1813 11, 3, 1813
83 11 2 1912 11, 3, 1912
84 11 2 2011 11, 3, 2011
85 11 2 2012 11, 3, 2012
86 11 15 1812 11, 16, 1812

NextDate İçin En Kötü Durum Test Durumları (87–115)

Durum Ay Gün Yıl Beklenen Çıktı
87 11 15 1813 11, 16, 1813
88 11 15 1912 11, 16, 1912
89 11 15 2011 11, 16, 2011
90 11 15 2012 11, 16, 2012
91 11 30 1812 12, 1, 1812
92 11 30 1813 12, 1, 1813
93 11 30 1912 12, 1, 1912
94 11 30 2011 12, 1, 2011
95 11 30 2012 12, 1, 2012
96 11 31 1812 Geçersiz tarih
97 11 31 1813 Geçersiz tarih
98 11 31 1912 Geçersiz tarih
99 11 31 2011 Geçersiz tarih
100 11 31 2012 Geçersiz tarih
101 12 1 1812 12, 2, 1812
102 12 1 1813 12, 2, 1813
103 12 1 1912 12, 2, 1912
104 12 1 2011 12, 2, 2011
105 12 1 2012 12, 2, 2012
106 12 2 1812 12, 3, 1812
107 12 2 1813 12, 3, 1813
108 12 2 1912 12, 3, 1912
109 12 2 2011 12, 3, 2011
110 12 2 2012 12, 3, 2012
111 12 15 1812 12, 16, 1812
112 12 15 1813 12, 16, 1813
113 12 15 1912 12, 16, 1912
114 12 15 2011 12, 16, 2011
115 12 15 2012 12, 16, 2012

NextDate İçin En Kötü Durum Test Durumları (116–125)

Durum Ay Gün Yıl Beklenen Çıktı
116 12 30 1812 12, 31, 1812
117 12 30 1813 12, 31, 1813
118 12 30 1912 12, 31, 1912
119 12 30 2011 12, 31, 2011
120 12 30 2012 12, 31, 2012
121 12 31 1812 1, 1, 1813
122 12 31 1813 1, 1, 1814
123 12 31 1912 1, 1, 1913
124 12 31 2011 1, 1, 2012
125 12 31 2012 1, 1, 2013

NextDate Tablosuna İlk Bakış

  • Bu tablo en kötü durum yaklaşımının ne kadar mekanik ve kapsamlı test üretebildiğini açıkça gösterir.
  • Ancak aynı tablo, yöntemin bazı zayıf yönlerini de görünür hale getirir:
    • çok sayıda benzer test üretilmesi,
    • bazı semantik olarak kritik tarihlerin yeterince öne çıkmaması,
    • Şubat sonu ve artık yıl davranışının özel dikkat gerektirmesi.
  • Bu nedenle NextDate problemi, boundary tabanlı testlerin yanında özel değer testi ihtiyacını da güçlü biçimde gösteren klasik bir örnektir.

Komisyon Problemi İçin Test Durumları

  • Commission probleminde bu kez 125 adet sıradan en kötü durum test durumunu tekrar listelemek yerine, daha ilginç bir açıdan ilerlenir.
  • Odak, girdi alanından değil, çıktı aralığından (output range) türetilen boundary değerler üzerindedir.
  • Özellikle komisyon yüzdesinin değiştiği eşik noktaları önemlidir:
    • $1000
    • $1800
  • Amaç, satış/komisyon fonksiyonunun bu eşiklerin hemen altında, tam üzerinde ve hemen üstünde nasıl davrandığını sınamaktır.

Commission Problem için Girdi/Çıktı Geometrisi

  • Eksenler üç girdi değişkenini temsil eder:
    • Kilitler (Locks)
    • Tetikler (Stocks)
    • Namlular (Barrels)
  • Aynı zamanda bu uzay içinde satış eşik düzlemlerinin eksenleri kestiği noktalar gösterilir.
  • Alt düzlem ile orijin arasındaki hacim, $1000 altındaki satışları;
  • iki düzlem arasındaki hacim ise %15 komisyon bölgesini temsil eder.

Çıktı Sınır Değer Analizi Test Durumları

Durum Locks Stocks Barrels Sales Comm Açıklama
1 1 1 1 100 10 Çıktı minimumu
2 1 1 2 125 12.5 Çıktı minimumu +
3 1 2 1 130 13 Çıktı minimumu +
4 2 1 1 145 14.5 Çıktı minimumu +
5 5 5 5 500 50 Orta nokta
6 10 10 9 975 97.5 Sınır noktası –
7 10 9 10 970 97 Sınır noktası –
8 9 10 10 955 95.5 Sınır noktası –
9 10 10 10 1000 100 Sınır noktası
10 10 10 11 1025 103.75 Sınır noktası +
11 10 11 10 1030 104.5 Sınır noktası +
12 11 10 10 1045 106.75 Sınır noktası +
13 14 14 14 1400 160 Orta nokta
14 18 18 17 1775 216.25 Sınır noktası –
15 18 17 18 1770 215.5 Sınır noktası –
16 17 18 18 1755 213.25 Sınır noktası –
17 18 18 18 1800 220 Sınır noktası
18 18 18 19 1825 225 Sınır noktası +
19 18 19 18 1830 226 Sınır noktası +
20 19 18 18 1845 229 Sınır noktası +
21 48 48 48 4800 820 Orta nokta
22 70 80 89 7775 1415 Çıktı maksimumu –
23 70 79 90 7770 1414 Çıktı maksimumu –
24 69 80 90 7755 1411 Çıktı maksimumu –
25 70 80 90 7800 1420 Çıktı maksimumu

Output Boundary Değerlerinin Yorumu

  • Orijin ile alt eşik düzlemi arasındaki hacim, $1000 altındaki satışları temsil eder.
  • İki eşik düzlemi arasındaki hacim, %15 komisyon bölgesini temsil eder.
  • Girdi aralığından üretilen klasik testler çoğunlukla %20 komisyon bölgesinde kalma eğilimindedir.
  • Bu nedenle özellikle şu çıktı sınırlarını hedefleyen testler daha öğreticidir:
    • $100
    • $1000
    • $1800
    • $7800

Çıktı Özel Değer Test Durumları

Durum Locks Stocks Barrels Sales Comm Açıklama
1 10 11 9 1005 100.75 Sınır noktası +
2 18 17 19 1795 219.25 Sınır noktası –
3 18 19 17 1805 221 Sınır noktası +

Commission Problem için Gözlem

  • Ilginç bulunan noktalar şunlardır:
    • case 9, tam olarak $1000 sınır noktasıdır.
    • cases 6–8 ve 10–12, bu sınırın hemen altı ve üstündeki durumları verir.
  • İstenirse (22, 1, 1) gibi sınıra yakın başka değerler de seçilebilir.
  • Bu yaklaşım, matematiksel içgörü kullanarak kodun “ilginç” bölgelerini egzersiz ettirdiği için, bir tür special value testing olarak da görülebilir.
  • Sonuç olarak:
    • Tablo 5.4, output boundary value analysis testlerini,
    • Tablo 5.5 ise output special value testlerini göstermektedir.

Rastgele Test (Random Testing)

  • Rastgele test uzun süredir literatürde tartışılan bir yaklaşımdır.
  • Özellikle akademik açıdan istatistiksel olarak ilgi çekicidir.
  • Bu bölümdeki üç örnek problem de rastgele teste uygundur.
  • Temel fikir şudur:
    • Her zaman min, min+, nom, max-, max gibi sabit boundary değerlerini seçmek yerine,
    • tanımlı aralık içinden rastgele test değerleri üretmek.
  • Böylece test tasarımındaki sistematik seçim önyargısı bir ölçüde azaltılmış olur.

Rastgele Testin Temel Sorusu

  • Rastgele test bir önyargıyı azaltır; ancak beraberinde önemli bir soru getirir:
    • Kaç tane rastgele test yeterlidir?
  • Şimdilik tablolar, bounded değişkenler için rastgele üretilmiş testlerin dağılımını göstermektedir.

Rastgele Değer Üretimi

  • Sınırları \(a \leq x \leq b\) olan bir değişken için kullanılan üretim mantığı:

\[ x = \mathrm{Int}((b - a + 1) * \mathrm{Rnd} + a) \]

  • Burada:
    • Int, ondalıklı sayının tamsayı kısmını alır.
    • Rnd, \([0,1]\) aralığında rastgele sayı üretir.
  • Program, her tabloda her çıktı türünden en az bir tane oluşana kadar rastgele test üretmeye devam eder.
  • Her tabloda yedi döngü (cycle) sonunda, üretilmesi zor olan son durum da görülmüş olur.

Üçgen Programı İçin Rastgele Test Durumları

Test Durumları Üçgen Değiller Çeşitkenar İkizkenar Eşkenar
1289 663 593 32 1
15,436 7696 7372 367 1
17,091 8556 8164 367 1
2603 1284 1252 66 1
6475 3197 3122 155 1
5978 2998 2850 129 1
9008 4447 4353 207 1
Percentage 49.83% 47.87% 2.29% 0.01%

Komisyon Programı İçin Rastgele Test Durumları

Test Durumları 10% 15% 20%
91 1 6 84
27 1 1 25
72 1 1 70
176 1 6 169
48 1 1 46
152 1 6 145
125 1 4 120
Percentage 1.01% 3.62% 95.37%

Rastgele Test Üzerine Gözlem

  • Son satırlarda, her çıktı sınıfının toplam testler içindeki yüzdesi gösterilir.
  • Bu yüzdeler, bazı çıktı kategorilerinin rastgele testte ne kadar seyrek üretildiğini açıkça gösterir.
  • Örneğin:
    • Triangle probleminde eşkenar üçgen çok nadirdir.
    • Commission probleminde testlerin büyük çoğunluğu %20 dilimine düşmektedir.
  • Dolayısıyla rastgele test tarafsız olabilir; ancak nadir ve kritik durumları yakalamak için çok fazla test gerektirebilir.

NextDate Programı İçin Rastgele Test Durumları

Test Durumları 31 Günlük Ayların 1-30. Günleri 31 Günlük Ayların 31. Günü 30 Günlük Ayların 1-29. Günleri 30 Günlük Ayların 30. Günü
913 542 17 274 10
1101 621 9 358 8
4201 2448 64 1242 46
1097 600 21 350 9
5853 3342 100 1804 82
3959 2195 73 1252 42
1436 786 22 456 13
Percentage 56.76% 1.65% 30.91% 1.13%
Probability 56.45% 1.88% 31.18% 1.88%

NextDate Programı İçin Rastgele Test Durumları (Devam)

Test Durumları Şubatın 1-27. Günleri Artık Yılda 28 Şubat Artık Olmayan Yılda 28 Şubat Artık Yılda 29 Şubat Geçersiz Günler/Tarihler
45 1 1 1 1 22
83 1 1 1 1 19
312 1 8 3 3 77
92 1 4 1 1 19
417 1 11 2 2 94
310 1 6 5 5 75
126 1 5 1 1 26
Percentage 7.46% 0.04% 0.19% 0.08% 1.79%
Probability 7.26% 0.07% 0.20% 0.07% 1.01%

NextDate Rastgele Test Üzerine Gözlem

  • NextDate tablosunda yüzdelerin kuramsal olasılıklara oldukça yakın olduğu görülür.
  • Ancak bu tablo aynı zamanda kritik bir problemi görünür kılar:
    • bazı tarih sınıfları son derece seyrektir.
  • Özellikle şu durumlar rastgele üretimde nadir görünür:
    • artık yıldaki 28 Şubat,
    • artık yıldaki 29 Şubat,
    • artık yıl olmayan yıldaki 28 Şubat,
    • geçersiz/imkânsız günler.
  • Bu nedenle rastgele test, dağılımı yansıtabilir; fakat semantik açıdan kritik tarihleri güvence altına almak için tek başına yeterli değildir.

Sınır Değer Testi Kılavuz İlkeleri

  • Special value testing hariç tutulursa, bir fonksiyonun girdi alanına dayalı test yöntemleri specification-based tekniklerin en ilkel biçimleri arasındadır.
  • Bu yöntemlerin ortak varsayımı şudur:
    • giriş değişkenleri gerçekten bağımsızdır.
  • Bu varsayım geçerli değilse, üretilen test kümeleri tatmin edici olmayabilir.
  • NextDate örneğinde bunun açık sonucu görülür:
    • June 31, 1912 gibi tatmin edici olmayan testler üretilebilir.
  • Buna rağmen bu yöntemler, uygun bağlamda yararlı ve hızlı başlangıç noktalarıdır.

Output-Based ve Internal Variable Testing

  • Bu yöntemler yalnızca giriş alanına değil, programın çıktı aralığına da uygulanabilir.
  • Commission probleminde bunun örneği görülmüştür.
  • Özellikle hata mesajı üreten sistemlerde output-based testler yararlıdır.
  • Testçi şu durumları da doğrulamalıdır:
    • hata mesajı gerektiğinde üretiliyor mu?
    • gerekmeyen yerde yanlışlıkla üretiliyor mu?
  • Boundary value analysis ayrıca iç değişkenlerde de kullanılabilir:
    • döngü kontrol değişkenleri,
    • indisler,
    • pointer’lar.
  • Teknik olarak bunlar dış girdiler olmayabilir; fakat pratikte sık hata kaynağıdır.
  • İç değişkenler için özellikle gürbüzlük testi uygun bir tercihtir.

Syntactic ve Semantic Yaklaşım

  • Amaç, sözdizimsel (syntactic) ve anlamsal (semantic) test tasarımı arasındaki farkı kısa bir örnekle göstermektir.
  • Üç değişkenli bir fonksiyon düşünülür:

\[ F = \frac{a - b}{c} \]

  • Sınırlar şu şekildedir:

\[ 0 \leq a < 10{,}000,\quad 0 \leq b < 10{,}000,\quad 0 \leq c < 18.8 \]

  • Yalnızca sınır bilgisine bakarsak normal boundary value testleri mekanik biçimde üretilebilir.
  • Ancak semantik bilgi olmadan üretilen testlerin bazıları problemli olabilir.

Normal Boundary Value Test Cases for \(F = (a - b)/c\)

Test Case a b c F
1 0 5000 9.4 -531.9
2 1 5000 9.4 -531.8
3 5000 5000 9.4 0.0
4 9998 5000 9.4 531.7
5 9999 5000 9.4 531.8
6 5000 0 9.4 531.9
7 5000 1 9.4 531.8
8 5000 5000 9.4 0.0
9 5000 9998 9.4 -531.7
10 5000 9999 9.4 -531.8
11 5000 5000 0 Undefined
12 5000 5000 1 0.0
13 5000 5000 9.4 0.0
14 5000 5000 18.7 0.0
15 5000 5000 18.8 0.0

Neden Syntactic Yaklaşım Yetersiz Kalabilir?

  • Yalnızca sözdizimsel sınırlar üzerinden gidildiğinde şu problemler ortaya çıkar:
    • anlamsız negatif sonuçlar üretilebilir,
    • aynı anlamı taşıyan testler tekrar edebilir,
    • sıfıra bölme gibi açık bir hata senaryosu test kümesine girebilir.
  • Kitabın ifadesiyle, sınır testi aracı ilk dört testi üretir; ancak beklenen çıktıları doğal olarak üretmez.
  • Üstelik sözdizimsel versiyon bile test case 11’deki division by zero olasılığını önleyemez.

Semantic Information Eklendiğinde

  • Şimdi semantik bilgi eklenir:
    • \(F\), bir otomobilin mil per gallon değerini hesaplamaktadır.
    • \(a\) = yol sonu odometre değeri
    • \(b\) = yol başlangıcı odometre değeri
    • \(c\) = yakıt deposu kapasitesi
  • Bu durumda dört önemli sonuca varılır:
    1. Her zaman \(a \geq b\) olmalıdır; böylece negatif değerler elenir.
    2. Test cases 3, 8 ve 12–15 sıfır uzunluklu yolculukları temsil eder; bunlar tek bir teste indirgenebilir.
    3. c = 0 için sıfıra bölme açıktır; bu nedenle test case 11 elenmelidir.
    4. Buna rağmen Tablo 5.10 da tam yeterli değildir; tank kapasitesindeki sınır etkisini göstermemektedir.

Semantic Boundary Value Test Cases for \(F = (a - b)/c\)

Test Case End Odometer Start Odometer Tank Capacity Miles per Gallon
4 9998 5000 9.4 531.7
5 9999 5000 9.4 531.8
6 5000 0 9.4 531.9
7 5000 1 9.4 531.8
8 5000 5000 9.4 0.0

Sınır Değer Testi için Kılavuz İlkeler

  • Boundary value testing’i özellikle şu durumda tercih et:
    • değişkenler sıralanabilir ve sınırlıysa,
    • fiziksel nicelikleri temsil ediyorsa,
    • bağımsızlık varsayımı makulse.
  • Değişkenler semantik olarak bağımlıysa, salt mekanik sınır üretimine güvenme.
  • Gerektiğinde çıktı uzayındaki sınırları da hedefle.
  • Hata mesajları ve istisna davranışlarını ayrıca sınamayı unutma.
  • İç değişkenler için gürbüzlük testi düşün.
  • En önemlisi:
    • sözdizimsel sınırlar yararlı bir başlangıçtır,
    • fakat iyi test kümesi çoğu zaman semantic insight gerektirir.

Bölüm Sonu Alıştırmaları

  1. \(n\) değişkenli bir fonksiyon için robustness test case sayısına ilişkin formülü geliştirin.
  2. \(n\) değişkenli bir fonksiyon için robust worst-case test case sayısına ilişkin formülü geliştirin.
  3. Boundary value analysis, robustness testing, worst-case testing ve robust worst-case testing kümeleri arasındaki ilişkileri gösteren bir Venn diyagramı hazırlayın.
  4. Output range robustness testing yapmaya çalışırsak ne olur? Commission probleminden yararlanarak tartışın.
  5. Bölüm 2’deki 8. alıştırmayı yaptıysanız, CRC Press sitesindeki specBasedTesting.xls dosyasını inceleyin. Triangle, NextDate ve Commission için worst-case boundary value test kümelerini çalıştırın ve naive testing sonuçlarıyla karşılaştırın.
  6. Tables 5.9 ve 5.10’daki miles-per-gallon örneğine special value testing uygulayın ve seçtiğiniz testleri gerekçelendirin.

Ders Sonu: Rastgele Test Simülasyonu

Konuları pekiştirmek için, rastgele testin dağılım istatistiklerini aşağıda interaktif olarak deneyebilirsiniz. Aşağıdaki Python bileşeni, Triangle ve Commission problemleri için belirlediğiniz sayıda rastgele test üretmenizi ve sonuçların dağılımını canlı olarak görmenizi sağlar.