YAZILIM KALİTESİ YAZILIM HATALARI DENEME

1. YAZILIM KALİTESİYAZILIM HATALARIDENEME Sarı arka planlı sayfalar bilgi amaçlıdır; içeriği sınav soruları kapsamına dahil değil

2. Yazılım Hataları ve ya “Böcek”(Bug) Yazılım hataları- ürününün kalitesinin gereksiz veya sebepsiz yere düşmesine neden olan her şey 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.

3. «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

5. Ayıklama-Debugging Beklenen hedefleri sağlamaları amacıyla bilgisayar programında veya donanım parçalarında kusurları (böcekleri) bulmak veya azaltmak için yapılan süreç Ayıklamanın, özellikle sıkı birleşimli altsistemlerde yapılması zordur; bir altsistemdeki değişmeler diğerlerinde pek çok “böceğe” sebep olabilir

6. Kalite nedir? Gereksinimlere uymak Gerçek gereksinimler (yazılı veya yazılı olmayan) Bir ürünün özellikleri bütünü Belirli bir ihtiyacı karşılama yeteneği Ürün ve hizmetlerin müşteri isteklerini karşılaması Ürünün ve hizmetin içeriği…

7. Kalitenin çokboyutluluğu • güvenilirlik • kullanılabilirlik • bakımı yapılabilirlik • denene bilirlik • işlevsellik/yetenek • işlem hızı • ölçeklenebilirlik • yerelleştirile bilirlik • belgelene bilirlik • öğrenile bilirlik • teknik desteklenebilirlik

9. Kaliteye farklı bakış açıları Yerelleştirme Yöneticisi (Localization Manager): İyi ürünün diğer bir ülkeye,dile, kültüre uygun değiştirilmesi çok kolay olmalıdır Teknik Belgeleyici (Tech Writers): İyi ürün kolaylıkla anlatıla bilmelidr. Her türlü belirsizlikler, tutarsızlıklar ve açıklamalardaki zorluklar ,ürünün kalitesini düşürecektir. Pazarlama (Marketing): İyi ürünleri alıcılar satın almakta isteklidirler ve bu ürünü almak için diğerlerini de teşvik ederler. Müşteri Hizmeti (Customer Service): İyi ürün destekleyici olmalıdır: insanlara kendi sorunlarını çözmekte yardımcı olmalıdır. Programcı (Programmers): İyi program kodu bakımı yapılabilir olmalı, kolay anlaşılmalı, hızlı çalışmalı ve kompakt olmalıdır.

10. DENEME DENEME STRATEJİLERİ

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

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

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

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

15. 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ı

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

17. Kusurların denenmesi • Sistem kusurlarının varlığını ortaya çıkaran deneme programları

18. 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ı

19. 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ı

20. 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ı

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

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

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

24. 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ındenemesinden daha önemlidir

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

26. 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, 100000

27. Eşit parçalama-örnek

28. İ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 ))

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

30. İkili arama-deneme durumları

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

32. İkili arama-eşit parçalama

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

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

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

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

37. Çı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, herR1 … 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

38. Beyaz kutu 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

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

40. Beyaz kutu 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

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

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

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

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

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

46. 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ı: 51 + 5 2 + 53 + … + 510 = 12207030 Tüm yolların denenmesi mümkünsüzdür. Ama beyaz kutu uygulamasının diğer gerekçeleri vardır.

47. 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; • else • 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

48. 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"); }

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

50. Örnek için akış çizgesi