1.01k likes | 1.16k Views
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
E N D
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
V & V amaçları • Doğrulama ve geçerlilik, kullanıcıda yazılımın amacına uygun olması güvenini oluşturmalıdır • Ama bu güven yazılımın bütünlükle kusursuz olacağı anlamına gelmez • Gereken güvenin seviyesi yazılımın kullanım amacına bağlıdır: • Uçağın kontrolü yazılımı ve restoranda masa rezervasyonu yazılımı
V & V güveni • Sistemin amacına, kullanıcı beklentilerine ve pazarlama ortamına bağlıdır • Yazılım işlevi • Güven seviyesi, yazılımın kullanılacağı ortam (kurum) için ne kadar önemli olmasına bağlıdır • Kullanıcı beklentileri • Bazı yazılımlar için kullanıcıların beklentileri düşük olabilir • Pazarlama ortamı • Ürünün kusurlu halde erken pazara sürülmesi, kusurların bulunmasından bazen daha önemli olabilir
Statik ve dinamik V&V • STATİK – yazılımı gözden geçirme • Sorunları bulmak için statik sistem çözümlemesi • Araç desteği ve kod çözümlemesi • DİNAMİK – yazılımın denenmesi • Ürünün davranışının izlenilmesi • Sistem deneme verileri ile çalıştırılır ve onun davranışı gözlemlenir
Statik ve dinamik V&V Statik doğrulama Gereksinimlerin belirteci yüksekseviye tasarımı formal belirteç ayrıntılı tasarım program prototip Dinamik geçerlilik
V & V planlama • Deneme ve gözden geçirme süreçlerinden daha iyi sonuç ala bilmek için ciddi planlama gerekmektedir • Planlama geliştirme sürecinin erken aşamalarında başlanılmalıdır • Plan, statik doğrulama ve deneme arasındaki dengeyi tanımlamalıdır • Deneme planlamasında deneme süreci için standartlar tanımlanmalıdır
Geliştirme için V-model Gereksinim belirteci sistem belirteci sistem tasarımı ayrıntılı tasarım Modül kodlama ve deneme teslim denemesi planı sistem bütünleşme denemesi planı alt sistemlerin bütünleşme deneme planı Hizmetler teslim denemesi sistem bütünl. denemesi altsistem büt. denemesi
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 • Kusurlar • Mantıksal hatalar • Kodlardaki sapmalar( örn., başlangıç değer verilmemiş değişken) • Standartlarla uyumsuzluk • Sistemin her türlü kaynaklarına uygulana bilir • gereksinimler, tasarım, deneme verileri ve s. • Hataları ortaya çıkarmak için etkili yöntem • Basit gözden geçirme ile çok farklı kusurları ortaya çıkarmak mümkündür • Alan ve programlama bilgilerinin yeniden kullanımı • Gözden geçirenler, sıklıkla ortaya çıka bilecek kusurları seze bilirler
Gözden geçirme ve deneme • Gözden geçirme ve deneme biri birini tamamlar • Her ikisi V & V sürecinde kullanılır • Gözden geçirme, müşterinin gerçek gereksinimlerine uyumluluğu değil, belirteçlere uyumluluğu yoklar; • Gözden geçirme işlevsel olmayan niteliklerin (başarım, kullanılabilirlik) denemesini yapamaz
Gözden geçirme grubu • En azı 4 kişi • Kodun yazarı • Gözden geçiren(Inspector) hataları ve uyumsuzlukları bular • Okuyucu (Reader) kodu grup üyelerine anlatır • Yönetici (Moderator) toplantılara başkanlık yapar ve hataları kaydeder
Gözden geçirme grubu-devamı • Sistem, gözden geçirme grubuna anlatılır • Kod ve uygun belgeler grup üyelerine dağıtılır • Gözden geçirme zamanı bulunan hatalar kaydedilir • Bulunan hataları gidermek için güncellemeler yapılır
Otomatik statik çözümleme • STATİK çözümleyiciler –kaynak kodu işlemek için yazılım araçları • Onlar program metnini taramakla olası hatalı koşulları bulmaya çalışır ve bu hataları V&V grubuna bildirir • Gözden geçirme sürecinde çok etkilidir. • Gözden geçirme yerine kullanılamaz
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 yoklanılması • Bilgi akışının çözümlenmesi • Çıkış değişkenlerinin bağımlılığının tanımlanması • Yol çözümlenmesi • Programdaki yolların ve bu yollarda yürütülen komutların araştırılması
Kusur denemesi ve kod ayıklama farklı süreçlerdir Denemenin amacı programda kusurların varlığını tespit etmektir Kod ayıklama hataları yerelleştirmek ve aradan kaldırmak içindir Deneme ve kod ayıklama-Testing and debugging
Deneme • Denemenin amacı, hataların var olmasını araştırmaktır • Denemenin başarısı ,onun hatayı bulması ile ölçülür • Deneme, işlevsel olmayan gereksinimlerin geçerliliğini değerlendirmenin tek yöntemidir • Statik doğrulama ile birlikte kullanıla bilir
Deneme türleri • Kusur denemesi • Sistemin kusurlarını bulmak için tasarlanır. • 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; • Güvenliğin tahmini için kullanılır
Yazılım deneme planının yapısı • Deneme süreci • Gereksinimlerin izlenebilirliği • Denenen birimler • Deneme zaman çizelgelemesi • Deneme yordamları • Donanım ve yazılım gereksinimleri • Kısıtlamalar
Önemli hususlar • Doğrulama ve geçerlilik aynı şey değildir. • Doğrulama sistemin belirtece uygunluğunu gösteriyor • Geçerlilik, programın müşteri isteklerini karşılamasını gösteriyor • Deneme sürecini yerine getirmek ve kontrol etmek için deneme planları hazırlanır • Statik doğrulama yöntemleri hataları bulmak için programın çözümlenmesini kapsar • Programın gözden geçirilmesi, hataları bulmak için çok etkili yoldur • Gözden geçirme zamanı program kodu küçük grup tarafından kontrol edilir • Statik çözümleme araçları program sapmalarını bula biliyor
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
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.
«Böcek» tarihçesi There is somecontroversyovertheorigin of theterm "debugging." In 1946, whenHopperwasreleasedfromactiveduty, shejoinedthe Harvard Faculty at theComputationLaboratorywhereshecontinued her work on theMark IIandMark III. Operatorstraced an error in the Mark II to a mothtrapped in a relay, coiningthetermbug. Thisbugwascarefullyremovedandtapedtothelogbook. Stemmingfromthefirstbug, todaywecallerrorsorglitch's in a program a bug. TheOxford English Dictionaryentryfor "debug" quotestheterm "debugging" used in referencetoairplane engine testing in a 1945 article in theJournal of theRoyalAeronauticalSociety, Hopper'sbugwasfound on the 9th of September in 1947. Thetermwas not adoptedbycomputerprogrammersuntiltheearly 1950s. TheseminalarticlebyGill in 1951 is theearliest in-depthdiscussion of programmingerrors, but it does not usetheterm "bug" or "debugging". IntheACM'sdigitallibrary, theterm "debugging" is firstused in threepapersfrom 1952 ACM NationalMeetings
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
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…
• 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 Kalitenin çokboyutluluğu
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.
DENEME DENEME STRATEJİLERİ
Yazılım testi, 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 birim çalışmalardır. • Yazılım testinin 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.
Yazılım projeleri değerlendirilirken test sürecine gelen ürünler, süreçlere uygun olarak teste tabi tutulur fakat ideal bir test süreci kodlama sürecinden ayrı değerlendirilmemelidir. İdeal bir test sürecinde olması gereken kodlama ve test süreçlerinin birbirinden koparılmamasıdır. Bu süreçte analiz, tasarım, teste hazırlık süreci, kodlama süreci, dinamik test süreci, testin bitirilmesi ve yazılımın ürün haline gelmesi şeklinde değerlendirilebilir.
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
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 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ı
Deneme Ölçekleri • Arayüzü bütünlüğü • İşlevsel geçerlilik • Bilgi tamlığı • Başarım
Kusurların denenmesi • Sistem kusurlarının varlığını ortaya çıkaran deneme programları
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ı
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
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
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
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
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 sınırlarında seçmeli 00000, 09999,10000, 10001, 99999, 100000
İ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 ))