Yazılım Ürünlerinin Denenmesi

Yazılım Ürünlerinin Denenmesi Doğrulama ve Geçerleme Deneme Stratejileri Kara Kutu Denemesi Beyaz Kutu denemesi

Doğrulama ve Geçerleme Doğrulama(validation) ve Geçerleme (verification), yazılım geliştirme süreci adımlarında ürün veya ara ürünlerin istenilen özelliklere uygunluğunu incelemek üzere gerçekleştirilen faaliyetlerdir

Doğrulama ve Geçerleme Doğrulama: “Ürün doğru mu geliştiriliyor?’’ cevap arıyor Yazılım, müşteri gereksinimlerine uygun geliştirilmelidir Geçerleme: “Doğru ürün mü geliştiriliyor?« sorusuna cevap arıyor. Yazılım kullanıcı isteklerini yerine getirmelidir Doğrulama ve Geçerleme (Validation & Verification) yöntemleri yazılım sürecinin her adımına uygulanmalıdır İki önemli hedef: Sistemdeki kusurların (defect) bulunması Sistemin kullanıcı için yararlı olabileceğinin kestirimi

Yazılımı Gözden Geçirme Yazılım geliştirme sürecini oluşturan her basamak tamamlanınca, durak noktalarında yapılan işler gözden geçirilmekte ve gerekli düzeltmeler yapılmaktadır

Yazılımın gözden geçirilmesi Sapmaları ve kusurları ortaya çıkarmak için kaynakların incelenmesi Sistemin yürütülmesini gerektirmez Çalıştırmadan önce kullanıla bilir Kusurlarların bulunması Mantıksal hatalar Kodlardaki sapmalar( örn., başlangıç değer atanmamış değişken) Standartlarla uyumsuzluk Sistemin çeşitli türlerine ve gereksinimlerine uygulana bilir (gereksinimler, tasarım, deneme verileri ) Hataları ortaya çıkarmak için etkili yöntem Basit gözden geçirme ile çok farklı kusurları ortaya çıkarmak mümkündür

Yazılımın statik gözden geçirilmesi-hata türleri statik çözümlemeler Veri hataları Başlangıç değerlerini almamış değişkenlerin kullanılması, Değişkenler ilan edilmiş ama kullanılmamıştır, Değişkenlere iki kez değer verilmiş ama arada hiç kullanılmamışlar Dizilerin sınırlarında olası hatalar, İlan edilmemiş değişkenler Denetim hataları erişilemez program (modül, fonksiyon) Döngüde koşulsuz dallanma Giriş-çıkış hataları aynı değişken iki kez çıkış değişkeni olarak kullanılsa da arada ona yeni değer verilmemiş Arayüzü hataları parametrenin türü yanlış, parametreler sayısı yanlış, işlevlerin sonucu kullanılmayıp çağrılmayan fonksiyon ve yordam Bellek ile bağlı hatalar atanmamış göstergeler, göstergelerin doğru hesaplanmaması

Statik gözden geçirme adımları Denetim akışlarının çözümlenmesi Çok girişli veya çıkışlı döngüleri yoklamalı, erişilemeyen kodları bulmalı ve s. Verilerin kullanımının çözümlenmesi Başlangıç değerler verilmemiş, tanımlanmış, ama hiç zaman kullanılmayan değişkenlerin ve s. bulunması Arayüzü çözümlenmesi Altprogram ve yordamların belirtilmesi ve kullanımındaki tutarlılığının yoklanılması Bilgi akışının çözümlenmesi Çıkış değişkenleri arasındaki ilişkilerin tanımlanması Yol çözümlenmesi Programdaki yolların ve bu yollarda yürütülen komutların araştırılması

Gözden geçirmenin amaçları Yazılımda yapılabilen işlevsel, mantıksal ve gerçekleştirme hatalarının bulunup giderilmesi Yazılımın gereksinimlere uygun olarak düzenlendiğinin onaylanması Yazılımın önceden belirlenen standartlara uygunluğunun sağlanması Yazılımın düzenli olarak geliştirilmesi Yazılım Proje yönetiminin kolaylaştırılması

Gözden Geçirme Ve Projenin Kilometre Taşları Yazılım geliştirme sürecinde gözden geçirme işlemi sistem analizi, yazılım geliştirme plânı, gereksinim analizi, tasarım, kodlama, deneme, bakım ve onarım basamaklarının tamamlandığı «kilometre taşlarında» uygulanmaktadır

Ayıklama-Debugging Beklenen hedeflerin sağlanması amacıyla bilgisayar programında veya donanım parçalarında kusurları (böcekleri) bulmak veya azaltmak için yapılan iş

Yazılım Hataları ve ya “Böcek”(Bug) Yazılım hataları, ürününün kalitesinin düşmesine neden oluyor Yazılım «böceği» bilgisayar programı veya sisteminde oluşan, yanlış, beklenmedik sonuçlara neden olan hatalar, kusurlardır. Böceklerin büyük kısmı insan hatalarından (kaynak kodları ve tasarım hataları) kaynaklanmaktadır. Az bir kısmı ise doğru kod üretmeyen derleyici hatalarından kaynaklanıyor. Programda oluşmuş «böcekler» hakkında bilgiler hata (kusur) raporlarında yer alıyor.

There is some controversy over the origin of the term "debugging." «Böcek» tarihçesi There is some controversy over the origin of the term "debugging." In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitch's in a program a bug. The Oxford English Dictionary entry for "debug" quotes the term "debugging" used in reference to airplane engine testing in a 1945 article in the Journal of the Royal Aeronautical Society, Hopper's bug was found on the 9th of September in 1947. The term was not adopted by computer programmers until the early 1950s. The seminal article by Gill in 1951 is the earliest in-depth discussion of programming errors, but it does not use the term "bug" or "debugging". In the ACM's digital library, the term "debugging" is first used in three papers from 1952 ACM National Meetings

DENEME (sınama, test)

Yazılımın Denenmesi Deneme; bir programdaki hataları bulmak amacı ile yapılan işlemlerdir. Deneme, yazılımın a) işlevsel, b) performans, c) dayanıklık, d) yapısal bakımlardan yeterliğini denetlemektedir.

Deneme Denemenin amacı, hataların var olmasını araştırmaktır Denemenin başarısı onun hataları bulması ile ölçülür Deneme, işlevsel olmayan gereksinimlerin geçerliliğini değerlendirmek için tek yöntemdir Statik doğrulama ile birlikte kullanıla bilir

Deneme türleri Kusur denemesi İstatistiksel deneme Sistemin kusurlarının varoluşunu ortaya çıkarmak için yapılır; deneme programları oluşturulur; Başarılı kusur denemesi sistemde hataların varlığının belirlenmesinde çok önemlidir İstatistiksel deneme Güvenilirliği değerlendirmek için; Kullanıcı girişlerinin sıklığını ifade etmek için; Güvenliğin tahmini için kullanılır

Deneme Belirteci Denemenin Kapsamı Deneme Planı Deneme Yordamı Bütünleme sırası Modüller için Birim denemesi Deneme Ortamı Deneme Durumu verileri Beklenen sonuçlar Gerçek Deneme Sonuçları

Yazılım deneme planının yapısı Deneme süreci Gereksinimlerin izlenebilirliği Denenecek birimler Deneme zaman çizelgelemesi Deneme yordamları Deneme için donanım ve yazılım gereksinimleri Deneme için kısıtlamalar

Yazılım Denemesi Yazılım denemesi, bir yazılımın bütününün veya kodun belli bir kısmının gereksinimleri karşılayıp karşılamadığını, uygun şekilde hazırlanmış testler sayesinde öğrenme amaçlı yapılan çalışmalardır. Yazılım denemsinin yapılma amaçları olarak; ileriye dönük kodun geliştirilme masraflarını azaltmak, ürün çalıştırılmadan önce kalitesini ve senaryolara uygunluğunu denetlemek, geliştirme sırasında gözden kaçan yanlışları bularak bu yanlışların ileride de tekrarlanmasını önleyerek zaman ve maliyet tasarrufu yapmak sayılabilir.

Deneme Süreci Yazılım projeleri değerlendirilirken deneme sürecine gelen ürünler, süreçlere uygun olarak teste tabi tutulur; fakat ideal bir deneme süreci kodlama sürecinden ayrı değerlendirilmemelidir. İdeal bir deneme sürecinde olması gereken, kodlama ve deneme süreçlerinin birbirinden koparılmamasıdır. Bu süreç  analiz, tasarım, teste hazırlık süreci, kodlama süreci, dinamik deneme süreci, denemenin bitirilmesi ve yazılımın ürün haline gelmesi adımlarını içeriyor

Yazılım Denemesine Strateji Yaklaşım Deneme- önceden planlaştırılan ve düzenli yapılan girişimler kümesi Deneme modül (birim) seviyesinde başlar ve “içten dışa” doğru tüm bilgisayarlı sistemi kapsar Farklı geliştirme süreçlerinde farklı deneme teknikleri uygulana bilir Deneme ve Kod ayıklama (debugging) farklı girişimlerdir ve kod ayıklama her bir deneme stratejisinde kullanıla bilir Deneme yazılım geliştirici tarafından ve (büyük projeler için) bağımsız deneme grubu tarafından gerçekleştirilir

Yazılım Kalitesinin Sağlanması Ölçme Formal Teknik İnceleme Yazılım Mühendisliği Yöntemleri Yazılım sistemi Deneme Yazılım Kalite Yöneticiliği ve Yazılım kalite Güvencesi Standartlar ve Yöntemler

Yazılımın Denenmesi Mekanizmasının oluşturulması Yapıcı işler- yazılım çözümleme ve tasarım “Dağıtıcı” iş- deneme Yazılım geliştirici program birimlerinin (modüllerinin) denenmesinde sorumludur Geliştirici, bütünleme denemesine de katılır Yazılım Mimarisi bittikten sonra bağımsız deneme grubu devreye girer

Yazılım Deneme Adımları gereksinimler Sistem Denemesi Bütünleme Denemesi tasarım Birim d. kod Deneme yönü

Deneme Ölçekleri Arayüzü bütünlüğü İşlevsel geçerlilik Bilgi tamlığı Başarım

Kusur denemesi sureci deneme durumları deneme verileri deneme sonuçları deneme raporları Deneme durumlarının deneme verilerinin hazırlanması deneme verileri ile durum sonuçlarının Tasarlanması programın çalıştırılması karşılaştırılması

Birim Denemesi: Ayrı-ayrı program bileşenlerinin denenmesi Genelde bileşenin geliştiricisi sorumludur (kritik sistemler dışında) Denemeler geliştiricinin deneyimlerine dayanmaktadır Amaç: Altsistemlerin doğru kodlaştırıldığının ve gereken işlevleri yerine getirdiğinin doğrulanması

Birim Denemesi Birim Denemesi yazılım ürününün en küçük birimi üzere doğrulama işlemlerini yapmak içindir Arayüzü Yerel veri yapısı Sınır koşulları Bağımsız yollar Modul Deneme durumları

Birim Denemesi Birim Denemesi, yazılım tasarımının en küçük birimi olan modül üzerinde uygulanmaktadır. Ayrıntılı tasarım tanımlarına dayanılarak, modül içerisindeki hataları bulmak üzere, önemli kontrol yolları sınanmaktadır. Beyaz (cam,saydam kutu) denemesi olarak uygulanan bu işlem, çok sayıdaki modül üzerinde, paralel olarak yürütülmektedir. Birim testinde; modülün arabirim, yerel veri yapısı, kontrol yapıları arasındaki ana yollar, hata arama yolları ve modül sınırları sınanmaktadır.

Birim Denemesi Deneme senaryosu (durumu) (test case); belirli bir program yolunu işlemek ya da özel bir gereksinime uygunluğu onaylamak amacı ile düzenlenen bir dizi sınama verisinden ve buna ilişkin işlemlerden oluşturulmaktadır. Deneme programlarının geliştirilmesi, diğer yazılımlar gibidir. Geliştirmeye de, test plânı uyarınca ve yazılım tasarımı ile birlikte başlanmalıdır. Modülün bağımsız olmaması halinde, sınamada diğer modüllerin etkileri (girdileri) dikkate alınmalıdır.

Bütünleme Denemesi: Geliştirici tarafından yerine getirilir Sistemi veya altsistemi oluşturmak için bir araya getirilmiş bileşenler grubunun denenmesi Bağımsız deneme grubu sorumludur Deneme sistem belirteçleri üzere gerçekleştirilir Bütünleme denemesinde modüller teker teker birbirine bağlanmaktadır Amaç: Altsistemler arasında arayüzlerinin denenmesi

Sistem Denemesi Bilgisayar sistemi, donanım ve yazılım alt sistemlerinden oluşmaktadır. Bu nedenle, yazılım alt sisteminin kendi başına sınanması yeterli olmayıp, bilgisayar sistemi içerisinde de denetlenmelidir. Sistem denemesinin amacı; sistemin bütün öğelerinin uygun olarak bir araya getirildiğinin ve her birinin işlevini tam olarak gerçekleştirebildiğinin onaylanması; Sistemin gereksinimleri (işlevsel ve genel) karşıladığının belirlenmesi- dır. Sistem denemesi; a) kurtarma denemesi, b) güvenlik denemesi, c) dayanıklılık denemesi, d) yetenek denemesi biçimlerinde uygulanmaktadır.

Geçerleme (validation) Denemesi Geliştiricinin teslim ettiği sistemin değerlendirilmesi Kara kutu denemeleri ardışıklığı Geçerlilik denemesi sonucu: işlev veya başarım belirteçlere uygundur; kabul edilir belirteçten sapmalar var ve yetersizlik listesi oluşturulur Amaç: Sistemin gereksinimleri karşıladığını ve kullanım için hazır olduğunu göstermek

Geçerleme Denemesi Bütünleme denemesi sonunda, yazılım bir paket halinde derlenmiş, arabirim hataları bulunmuş ve düzeltilmiş olmaktadır. Bundan sonra, geçerleme denemesi yapılmaktadır. Bu denemede, yazılımın müşteri ve kullanıcı beklentilerini gerçekleştirme olanağı denetlenmektedir.

Deneme Türleri İşlevsel-başarım(performans) ve dayanıklık denemeleri, sistemin dış beliteçlerine ve gereksinimlerine dayandırıldığı için, bu denemelere kara kutu denemesi (black box testing) adı verilmektedir. Buna karşılık, yapısal denetimde modül düzeyinde programın deyimleri ya da dalları sınanarak iç yapısı incelenmektedir. Bu şekilde uygulanan sınama yöntemine de beyaz kutu denemesi (white box, glass box testing) denilmektedir.

Beyaz kutu denemesi Beyaz kutu denemsinde, işlemsel (procedural) tasarımın kontrol yapısı kullanılmaktadır. Bu test ile; Bir modüldeki bütün bağımsız yolların en az bir kez çalışacağı garanti edilmekte, Bütün mantıksal kararların "doğru" ve "yanlış" durumları denenmiş olmakta, Bütün döngülerin kendi içinde ve çevresinde işlerliği sağlanmakta, İç veri yapıları denenerek, geçerliliği güvence altına alınmaktadır. Beyaz kutu testinin uygulanmasında, temel yol testi ve döngü testi teknikleri kullanılmaktadır.

Kara Kutu Denemesi Kara kutu denemesi; yazılımın bütünlenmesi sırasında uygulanan ve yazılım arabirimi üzerinde yapılan bir sınamadır. Bu sınama ile, yazılım işlevlerinin yerine getirildiği, girdilerin kabul edildiği, çıktıların doğru olarak bütünlüğün sağlandığı gösterilmektedir. Kara kutu denemesinde yazılımın mantıksal iç yapısından çok, temel sistem modeli denenmiş olmaktadır. Bu nedenle, kara ve beyaz kutu denemeleri birlikte uygulanarak, yazılım arabiri minin geçerliği onaylanmaktadır

Kara Kutu Testi Başlıca kara kutu deneme yöntemleri; a) eşdeğerli bölümleme, b) sınır değer analizi, c) neden-sonuç grafı çizimi, d) veri onaylama testi olarak sayılmaktadır.

Deneme öncelikleri Yalnız “tepeden-tırnağa” deneme, programın kusurlarının olmadığını göstere bilir. Ama, böyle deneme mümkün değil. Deneme ilk öncelikle bileşenlerinin değil, sistemin kendisinin yeteneklerinin sınanmasına yönelmelidir Tipik durumların denenmesi, sınır değerlerine uygun durumların denemesinden daha önemlidir

Deneme verileri ve deneme durumları Deneme verisi- Sistem denemesi için giriş değerleri Deneme durumları- Sistemi denemek için giriş verileri ve eğer sistem, belirtecine uygun işlerse, bu veriler sonucu öngörülen çıkışlar

Eşit parçalama Sistemin giriş ve çıkışlarının “eşit kümelere” parçalanması Eğer giriş 10,000 ve 99,999 arasında 5 rakamlı tam sayıdırsa , eşdeğerli kısımlar <10,000, 10,000-99, 999 ve > 10, 000 olacak Deneme durumlarını bu kümelerin içinden ve kümelerin sınır değerlerinden seçmeli 00000, 09999,10000, 10001, 99999, 100000

Eşit parçalama-örnek

Örnek-İkili arama programı için koşullar procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; önkoşul -- dizide en az bir eleman vardır T’FIRST <= T’LAST sonkoşul -- aranan eleman bulunmuştur ve dizinin L.ci elemanıdır ( Found ve T (L) = Key) veya -- aranan eleman dizide yoktur ( not Found ve not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))

İkili arama-eşit parçalama Aranan eleman dizidedir Aranan eleman dizide değil Giriş dizisi tek bir değerden oluşuyor Giriş dizisinde çift sayıda değer vardır Giriş dizisinde tek sayıda değer vardır

İkili arama-deneme durumları

Arama modülü-girişlerin parçalanması

İkili arama-eşit parçalama

Kutu Yaklaşımı Kutu yaklaşımı, test mühendislerinin testi geliştirirken ve test gerçekleştirilirken hangi açıdan baktıklarıyla ilgilidir. Bu bakış açısı kodun, algoritmanın, içsel bileşenlerin (değişken, yapılar, veriler, vb.) mi yoksa sadece girdi ve çıktıların mı göz önünde tutularak testin yapılacağıyla ilgilidir. Temel olarak “kara kutu” ve “beyaz kutu” yaklaşımlarından bahsedilir. Ancak son günlerde bir de “gri kutu” yaklaşımından bahsedilmeye başlanmıştır. Kara kutu yaklaşımı; işlevi kapalı bir yapı olarak kabul eder ve içsel olarak neye sahip olduğu veya ne yaptığıyla ilgilenmez. Sadece verilen girdiler için doğru çıktılar üretiliyor mu? Diye bakar. Beyaz kutu yaklaşımı; işlevin doğru çalışmasının yanında, içsel değişkenlerini ve algoritmasının da doğru/uygun olup olmadığını denetler. Gri kutu yaklaşımı; testin tasarımıyla ilgilidir. Gri kutu testleri aynı kara kutu gibi uygulanır. Ancak test tasarlanırken işlevin içsel veri ve algoritma yapısı da göz önünde bulundurulmaktadır.

Kara kutu denemesi Programa kara kutu gibi bakılır Program deneme durumları sistem belirtecine dayanmaktadır Deneme planlaması yazılım sürecinin erken aşamalarında başlamalıdır

Kara kutu denemesi Giriş deneme verileri Çıkış deneme sonuçları Normal olmayan durumlara neden olan girişler Çıkış deneme sonuçları Kusurların varlığını ortaya çıkaran çıkışlar

Kara kutu Birim denemesi teknikleri Amaç: küçük boyutlu deneme durumları kümelerinin seçilmesi Sınır değerlerinin çözümlenmesi ile eşit parçalamanın kullanılması. Bu yaklaşım, denemeye tabi tutulan yazılımın giriş ve çıkış belirteçlerine dayanmaktadır. Giriş verilerinin seçilmesi (örnek): Eğer yazılım birimi (modülü) 1-25 arasındaki tam sayılarla işlerse, hatanın bulunma riskinin 1 ve 25 arasında olacağını kabul ediyoruz . Bu aralık, eşdeğer sınıfı belirler. Birimin işlemeli olduğu 3 eşdeğer sınıf: 1. <1 2. 1…25 3. >25

her sınıfın her bir üyesi deneme girişi gibi seçile bilir, örn her sınıfın her bir üyesi deneme girişi gibi seçile bilir, örn.,-567, 1 ve 2356. Programlama deneyimleri,hataların sıklıkla sınıfların her iki sınırında da var ola bileceğini gösteriyor. Uygun olarak aşağıdaki deneme girişleri kullanılmalıdır: Giriş 1: 0 Giriş 2: 1 Giriş 3: 2 Giriş 4: 17 Giriş 5: 24 Giriş 6: 25 Giriş 7: 26

Beyaz kutu denemesinin 4 türü: İfade (komut) Denemesi Döngü denemesi Cam kutu, mantıksal veya yol yönlü deneme de denir.En yaygın biçimi her kod ardışıklığı yolunun en azından bir kez yürütülmesini gerektirir. Beyaz kutu denemesinin 4 türü: İfade (komut) Denemesi Döngü denemesi Yol Denemesi Koşul Denemesi

Beyaz kutu denemesi Denemeler alınıyor Bileşenin (modülün) kodu

Beyaz kutu denemesi – Döngü denemesi: –İfade Denemesi (Cebri Deneme) : Tek elemanın denenmesi – Döngü denemesi: – Döngünün bütünlükle yürütülmesi – Yol Denemesi: – Programdaki tüm yolların yürütüldüğüne emin olmak - Koşul denemesi: Koşulun her mümkün sonucunun en azından bir kez denenmesi Örnek: if ( i = TRUE) printf("YES\n"); else printf("NO\n"); Deneme durumları: 1) i = TRUE; 2) i = FALSE

Beyaz kutu Birim Denemesi Teknikleri Deneme verileri programın iç yapısına göre seçilir Yapı, programdaki ardışıklığı, kararları, döngüleri ifade eden akış çizgesi ile gösterile bilir. Akış çizgesini program kodlarından almak mümkündür Mantıksal bütünlük oluşturan komutlar ardışıklığı tek düğümle ifade edile biler. Her düğümün böyle bir özelliği vardır ki, o bir kez yürütülse, ondaki her bir komut da bir kez yürütülmelidir. Her hangi kenar bir düğümde sonlanmalıdır (düğüm yordamsal ifadeyi anlatmaya da bilir) Her karmaşık koşul basit koşullara parçalanmalıdır. Tek düğüm tek (sade) koşulu ifade ediyor.

Yol Denemesi Yol Denemesinde amaç,öğle deneme durumları kümelerini oluşturmaktır ki, bu kümelerle programın her bir yolu en azından bir kez denenmiş olsun Yol Denemesi için başlangıç nokta programın akış çizgesidir.Çizgede düğümler program komutlarını (komutlar ardışıklığını), kenarlar kontrol akışlarını ifade eder Koşul ifadeleri de kenarlardır

Programın akış çizgesi Programın denetim akışını ifade ediyor. Her dal ayrı yolla gösteriliyor. Döngüsel karmaşıklığı (cyclomatic complexity ) hesaplamak için temeldir Döngüsellik = kenarlar sayısı – düğümler sayısı +2

İKİLİ ARAMA ALGORİTMASI Binary search (Java)

İkili arama modülü için akış çizgesi Bağımsız yollar 1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 Deneme durumları öğle seçilmelidir ki, tüm bu yollar yürütülmüş olsun

Beyaz kutu denemesi (örnek) Böyle bir akış çizgesine bakalım: Akış çizgesine göre 12 milyondan fazla yol bulunuyor. Bir döngüde dörtgenlerden geçen 5 yol var. Çizge üzere dörtgenlerden geçen yolların toplam sayısı: 5 1 + 5 2 + 5 3 + … + 5 10 = 12207030 Tüm yolların denenmesi mümkünsüzdür. Ama beyaz kutu uygulamasının diğer gerekçeleri vardır.

Tüm yolların yürütülmesi herzaman hatanın bulunması anlamına gelmez. Örneğin, aşağıdaki kod parçasına bakalım; ‘eğer 3 tamsayının ortalaması birinciye eşitse, bu sayılar eşittir’ varsayımına dayanarak 3 tam sayının eşitliğinin hesaplanması if ((x+y+z)/3==x) printf("x, y, z eşittir"); else printf("x, y, z eşit değillerl); Test 1: x=1, y=2, z=3 Test 2: x=y=z=2 deneme verileri kullanılırsa kod parçasındaki tüm yollar denenecek, fakat parçada hata meydana çıkarılamayacak. (örn., x=2, y=1, z=3) Diğer bir örnek: (a) if (d==0) zero_division_routine; x=n/d; (b) x=n/d; (a) halinde d = 0 ve d != 0 denenmelidir. (b) halinde ise yalnız bir yol denenecek,bu halde hata ortaya çıkmayabilir

Beyaz Kutu Denemesine örnek /*artı sayılarının ortalamasının bulunması*/ FindMean(float Mean, FILE ScoreFile) { SumOfScores = 0.0; NumberOfScores = 0; Mean = 0; Read(ScoreFile, Score); /* veri dosyasından sayının okunması */ while (! EOF(ScoreFile) { if ( Score > 0.0 ) { SumOfScores = SumOfScores + Score; NumberOfScores++; } Read(ScoreFile, Score); /* ortalamayı hesaplamalı ve sonucu yazdırmalı */ if (NumberOfScores > 0 ) { Mean = SumOfScores/NumberOfScores; printf(“ortalama sayı %f \n", Mean); } else printf(“dosyada sayı bulunmadı\n");

Beyaz Kutu denemesi örneği-yolların belirlenmesi

Örnek için akış çizgesi

Beyaz Kutu Denemesi (bir örnek daha) 1-8 sayıları düğümleri ifade ediyor. void main() { /* giriş sayılarının sayısını ve küçük sayılarla büyük sayıların ayrılıkta toplamını hesaplayan bir program */ int big_tot, small_tot, count, number; 1 big_tot = 0; small_tot = 0; count = 0; number = 1; 2 while (number) { 3 scanf(“%d”, &number); if (number > 100) 4 big_tot += number; 5 else if (number < 50) 6 small_tot += number; 7 count ++; } 8 printf(“%d %d %d”, count, big_tot, small_tot);

İfade denemesi Programın her bir cümlesi (ifadesi) en azından bir kere yürütülmüş olmalıdır. Basit ifadelere atama, giriş-çıkış, yordam çağırma ifadeleri ait edile biler. İfade denemesi için kıstas formal olarak böyledir: İfade denemesi kıstası. Öyle bir T deneme kümesi seçilmelidir ki, P programı yürütülürken T’deki her bir d giriş verileri için programın her bir basit ifadesi en az bir kere yürütülmüş olsun.

İfade denemesi yönteminin yetersizliği Kontrol akışı grafında 1 düğümü while ifadesi ve 2 düğümü if ifadesi içermektedir. 1,2,3,4,5 yolu ile program yürütülürken ifade denemesi kıstası sağlanmış oluyor. Ama bu halde do-while ve if ifadeleri denenmemiş durumdadırlar

Kenar denemesi İfade denemesinin geliştirilmesidir. Kenar denemesi tüm kenarların (veya dalların) en azından bir kere (kenar ifade içermediği durumda da) denenmesini gerektiriyor. Örneğin, while veya if ifadelerinin doğru ve yanlış tarafları en azından bir kere yürütülmelidir. Bu kıstas formal olarak böyle ifade edile bilir: Kenar denemesi kıstası: Öyle bir T deneme durumu seçilmelidir ki, P programı yürütülürken T’deki her bir d verileri için P’nin akış grafındaki her bir kenar en azından bir kere taranmış olsun

Koşul denemesi if c1 and c2 then s1; else s2; if c1 then if c2 then Öyle deneme durumları seçilmelidir ki, bu durumlara uygun verilerle programın akış çizgesindeki her bir kenar taranmış olsun ve karmaşık koşullardaki her bir alt koşulun mümkün değerleri en azından bir kere yürütülmüş olsun. Bu amaçla karmaşık koşul basit koşullara parçalanmalıdır: Örnek: if c1 and c2 then s1; else s2; karmaşık koşul yapısı deneme sürecinde aşağıdaki gibi ifade edilmelidir: if c1 then if c2 then

Kenar denemesine örnek Kenar denemesi kıstasını sağlamak için öyle deneme durumları seçilmelidir ki, çizgedeki her bir kenar en azından bir kere taranmış olsun: 1, 2, 3, 4, 6, 7 1, 2, 4, 5, 6, 7 1, 2, 4, 6, 1, 2, 4, 6, 7 Göründüğü gibi deneme kümesindeki veriler her bir koşul için doğru ve yanlış değerleri kontrol edecek. Bu bakımdan kenar denemesi ifade denemesi ile nispette daha iyi bir yöntemdir

Koşul denenmesi Kenar denemesi daha fazla hata bula bilmesi için güçlendirile bilir. Verilmiş bir elemanı tabloda arayan böyle bir programa göz atalım: found = 0; counter = 0; while ((!found) && (counter < number_of_items - 1)) { if (table[counter] == desired_element) found = 1; counter++; } if (found) printf(“the desired element exists in the table”); else printf (“the desired element does not exist in the table”); Bu program parçasında yanlış olarak while-ifadesinde "<=“ yerine "<" kullanılmıştır. T = {<number_of_items = 0, desired_element = 2>, <number_of_items = 3, desired_element = table[1]>} deneme kümesi kenar denemesi kıstasını sağlamaktadır. Ama hatayı bulmayacaktır. Bunun nedeni ise koşulun karmaşık olması- "!found" ve "counter < number_of_items - 1“ gbi iki kısımdan oluşmasıdır. Baktığımız deneme kümesi bu karmaşık koşulun her bir kısmının doğru ve yanlış değerleri için yürütülmeği sağlamıyor

Deneme yaklaşımları Deneme çalıştırması Mimari geçerlilik Sistem mimarisinde hataları bulmak için yukarıdan aşağı deneme iyidir Sistemin gösterişi Yukarıdan aşağı deneme ile, geliştirmenin ilk aşamalarında sistemin sınırlı gösterimi yapıla biler Deneme çalıştırması Aşağıdan yukarıya deneme ile daha kolaydır Denemenin incelenmesi Her iki yaklaşımda sorunlar var.İnceleme için ilave programlar yapmak gerekiyor

Arayüzü Denemesi Modüller veya altsistemler, daha büyük sistemleri oluşturmak için bütünleştirildikte gerek ola bilir Arayüzü hatalarını veya arayüzleri hakkındaki yanlış varsayımları meydana çıkarmak için kullanılır Nesneler, arayüzleri ile tanımlandığı için nesneye yönelik geliştirmede önemlidir

Arayüzü denemesi

Arayüzü türleri Parametre arayüzleri: Ortak bellek arayüzleri Veriler bir yordamdan diğerine gönderilir Ortak bellek arayüzleri Belleğin bir kısmı yordamlar arasında ortak kullanılır Yordamsal arayüzleri Altsistem, diğer altsistemleri çağırmak için yordamlar kümesini ihtiva eder Haber gönderme arayüzleri Altsistemler diğer altsistemlerden hizmetler istemektedir

Arayüzü hataları Arayüzü yanlış kullanılıyor Arayüzü anlaşılmazdır Bir bileşenin diğer bileşeni çağırması zamanı arayüzü yanlış kullanılır (parametreler sırası yanlıştır) Arayüzü anlaşılmazdır Bileşen, çağrılan bileşenin davranışı hakkında doğru olmayan bilgiler içermektedir Zamanlama hataları Çağıran ve çağrılan bileşenlerde işlem süratleri farklıdır veya zamanı geçmiş verilere erişilir

Arayüzü Denemesi için tavsiyeler Çağrılan yordama parametrelerin uç değerleri verilmelidir Bileşeni başarısızlığa götüren deneme tasarlamalı Haber aktarma sistemlerinde gerilim (stres) denemesini kullanmalı Ortak bellekli sistemlerde, bileşenlerin farklı ardışıklıkla belleğe erişimin denemeli

Beyaz ve kara kutu deneme teknikleri hataların yalnız var olduklarını göstere bilir. Ama, bu teknikler hataları ortaya çıkaran nedenleri aradan kaldırmaz.

Stres denemesi Sistemi en fazla tasarım yüklenmesinde çalıştırmalı Sistemler felaket biçiminde çökmemelidir. Gerilim denemesi, hizmet veya verilerin kabul edilemeyecek kaybını yoklamak içindir Özellikle, dağıtık sistemlerde kullanılması uygundur. Bu sistemler, ağın aşırı yüklenmesi ile bozulmalara çok meyillidir

Bütünleşik denemesi Bütünleşen bileşenlerden oluşan sistemlerin veya altsistemlerin denemesi Bütünleşik denemesi kara kutu denemesidir ve belirteçler üzere gerçekleştirilir Hataların yerelleştirilmesi zordur Gelişen bütünleşik denemesi bu sorunu aradan götürür

Yaşam Döngüsü Boyunca Deneme Modül Deneme Planı Deneme Belirteçleri Deneme Eğitim Klavuzu Modül Denemesi Bütünleştirici Deneme Deneme Eğitimi Altsistem Deneme planları Kullanıcı Denemesi Deneme Raporları Sistem Deneme Planı P Ç T G K P: Planlama Ç: Çözümleme T: Tasarım G: Gerçekleştirim K:Kurulum Yazılım Mühendisliği Yönetimi Güray YILMAZ