DENEME.

... konulu sunumlar: "DENEME."— Sunum transkripti:

1 DENEME

2 Yazılımın Denenmesine Strateji Yaklaşım
Deneme- önceden planlaştırılan ve düzenli yapılan girişimler kümesi Deneme modül 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

3 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

4 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

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

6 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ı

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

8 Sistem kusurlarının varlığını ortaya çıkaran deneme programları
Kusurların denenmesi Sistem kusurlarının varlığını ortaya çıkaran deneme programları

9 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ı

10 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ı

11 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ı

12 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 Amaç: Altsistemler arasında arayüzlerinin denenmesi

13 Türleri: Sistem Denemesi:
Sistem geliştirici tarafından yerine getirilir Amaç: Sistemin, gereksinimleri (işlevsel ve genel) karşıladığının belirlenmesi Türleri: Kurtarma (recovery) Denemesi Güvenirlik (security) Denemesi Stres Denemesi Başarım Denemesi

14 Geçerlilik (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

15 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

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

17 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 sınırlarında seçmeli 00000, 09999,10000, 10001, 99999,

18 Eşit parçalama-örnek

19 İ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 ))

20 İ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

21 İkili arama-deneme durumları

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

23 İkili arama-eşit parçalama

24 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

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

26 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

27 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

28 Çıkış verilerinin seçilmesi
Çıkış verilerinin seçilmesi. Giriş verilerinde olduğu gibi çıkışlar için de sınır koşulları seçilmelidir. Deneme verisi yalnız doğru ve yanlış giriş verilerini değil, çıkış için sınır koşulları denemesini de içermelidir Genelde, her R1 … R2 aralığı, giriş ve çıkış belirteçleri ile belirlenir. 5 deneme durumu seçile bilir: R1 ‘den küçük R1’ e eşit R1’den büyük, R2’den küçük R2’ye eşit R2’den büyük

29 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

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

31 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

32 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.

33 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

34 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

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

36 İ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

37 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ı: … = Tüm yolların denenmesi mümkünsüzdür. Ama beyaz kutu uygulamasının diğer gerekçeleri vardır.

38 Tüm yolların yürütülmesi hükmen 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 denenebiliyor, fakat hata ortaya çıkmaya bilir

39 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");

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

41 Örnek için akış çizgesi

42 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);

43 İ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.

44 İ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

45 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

46 Kenar denemesine örnek
Kenar denemesi kıstasını sağlamak için aşağıdaki yollar öyle yürütülmelidir ki, çizgenin 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

47 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

48 Koşul denemesi kıstası
Öyle bir T deneme durumu seçmeli ki, P programının yürütülürken T2deki her bir d giriş verileri için 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 deneme kıstasını,karmaşık koşulu basit koşullara parçalamakla daha iyi anlamak mümkündür. Örnek: if c1 and c2 then s1; else s2; İfadesi aşağıdaki ifadeye eşittir: if c1 then if c2 then

49 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.

50 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

51 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

52 Arayüzü denemesi

53 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

54 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

55 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

56 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

57 Nesneye-yönelik deneme
Deneme bileşenleri nesne sınıflarıdır Beyaz kutu denemesi daha büyük boyutlarda kullanıla bilir

58 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

59 Gelişen bütünleşik denemesi

60 Bütünleşik denemesi yaklaşımları
Yukarıdan aşağıya deneme Yüksek seviye sistemle başlayarak ve nerede gerekiyorsa ayrı-ayrı bileşenlerin yerine kütükler kullanarak yukarıdan aşağıya doğru bütünleşme Aşağıdan yukarıya deneme Aşağı seviyelerde ayrı-ayrı bileşenleri bütün sistem oluşuncaya dek bütünleştirme Uygulamalarda, genelde her iki strateji bir yerde kullanılır

61 Yukarıdan-aşağıya deneme

62 Aşağıdan yukarıya deneme

63 Deneme Seviyeleri Nesnelerle bağlı işlemleri denemeli
Nesne sınıflarını denemeli Birlikte çalışan (cooperating) nesneler kümelerini denemeli Nesneye Yönelik sistemi bütünlükte denemeli

64 Nesne sınıflarının denemesi
Nesnelerin tümüyle denenmesi için Nesneyle bağlı tüm işlemleri denemeli Tüm nesne özellikleri tanımlanmalı ve incelenmeli Nesne tüm mümkün durumlarda çalıştırılmalı Kalıtımlık nesne denemelerini zorlaştıran etkendir.

65 Küme (cluster) denemesi yaklaşımları
Kullanım durumlarının veya senaryolarının denenmesi Deneme, kullanıcının sistemle etkileşimine dayanmaktadır Kullanıcının beklediği sistem özelliklerinin denenmesi Tehlike denemesi Sistemin tehlikeli durumlarda tepkisinin denenmesi system

66 Önemli Noktalar Sistemin daha çok kullanılan kısımlarını dene Eşit parçalama, programın eşit yollarla davranışını denemek içindir. Kara kutu denemesi sistem belirteçleri üzere yapılır Yapısal deneme, programın tüm yollarının çalıştırılacağı deneme durumlarını belirler.

67 Önemli noktalar Deneme ölçümleri her ifadenin en az bir kez yürütülmesini sağlamalıdır. Arayüzlerinde hatalar, belirteçlerin yanlış okunulması, yanlış anlaşılması, doğru olmayan zamanlamalardan dolayı meydana gelmektedir Nesne sınıflarını denemek için tüm işlemleri, özellikleri ve durumları denemeli Nesneye yönelik sistemleri nesneler kümelerinde bütünleştirmeli