YAZILIM HATALARI KALİTE DENEME

Kalite nedir? Gereksinimlere uymak 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… Kalitenin boyutları güvenebilirlik kullanılabilirlik bakılabilirlik denetlenebilirlik işlevsellik işlem hızı ölçeklenebilirlik teknik desteklenebilirlik

Doğrulama ve Geçerlilik

Doğrulama ve Geçerlilik Doğrulama: “Ürün doğru mu geliştiriliyor?" Yazılım, belirteçlere uygun geliştirilmelidir Geçerlilik: “Doğru ürün mü geliştiriliyor?" Yazılım kullanıcı isteklerini yerine getirmelidir Doğrulama ve Geçerlilik (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ı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

Statik çözümleme-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 atanmış, 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 atanmamış 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ı

Kodun statik çözümleme 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 yoklanması 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ı

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ş; 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

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öcekleri» 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 Denemenin amacı, hataların var olup olmadığını araştırmaktır Denemenin başarısı hataları bulma başarımı 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

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ış testleri kullanmakla öğrenme amacıyla yapılan çalışmalardır. Yazılım denemesinin yapılma amaçları: 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

Deneme ve Ayıklama Deneme- önceden planlanan ve düzenli yapılan girişimler kümesidir 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 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

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

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

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

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

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ı

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

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ı

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ünleşik denemesi kara kutu denemesidir ve belirteçler üzere gerçekleştirilir Hataların yerelleştirilmesi zordur Amaç: Altsistemler arasında arayüzlerinin denenmesi

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

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

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

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

Deneme Yaklaşımı-Kutu-1 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 yıllarda bir de “gri kutu” yaklaşımından bahsedilmeye başlanmıştır.

Deneme Yaklaşımları-2 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? Buna 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

Kara kutu Birim denemesi teknikleri-devamı 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 – 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 denemesi Denemeler alınıyor Bileşenin (modülün) kodu

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

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ı