Doğrulama ve Geçerlilik
-
Upload
larissa-mejia -
Category
Documents
-
view
53 -
download
0
description
Transcript of Doğrulama ve Geçerlilik
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
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
Formalspecification
High-leveldesign
Requirementsspecification
Detaileddesign Program
Prototype Dynamicvalidation
Staticverification
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
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand tess
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
Service Acceptancetest
Systemintegration test
Sub-systemintegration test
Gereksinim belirteci sistem belirteci sistem tasarımı ayrıntılı tasarım
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
Modül kodlama ve deneme
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-hata türleriHata 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ışlarDizilerin 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 çö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 HATALARI
DENEME
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çesiThere 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
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…
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
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.
DENEMEDENEME 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ı
Yazılım Mühendisliği
Yöntemleri
Formal Teknik İnceleme
Standartlar ve Yöntemler
Deneme
Ölçme
Yazılım Kalite Yöneticiliği ve Yazılım kalite Güvencesi
Yazılım sistemi
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ı
Sistem Denemesi
Bütünleme Denemesi
Birim d.
Deneme yönü
gereksinimler
tasarım
kod
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
Design testcases
Prepare testdata
Run programwith test data
Compare resultsto test cases
Testcases
Testdata
Testresults
Testreports
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ı
deneme durumları deneme verileri deneme sonuçları deneme raporları
• 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
ModulArayüzü
Yerel veri yapısı
Sınır koşulları
Bağımsız yollar
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ı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 sınırlarında seçmeli00000, 09999,10000, 10001, 99999, 100000
Eşit parçalama-örnek
Between 10000 and 99999Less than 10000 More than 99999
999910000 50000
10000099999
Input values
Between 4 and 10Less than 4 More than 10
34 7
1110
Number of input values
İ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ırT’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ı
Dizi Eleman Tek değer Dizinin ortasında Tek değer Dizide yok 1’den çok değer Dizinin birinci elemanı 1’den çok değer Dizinin sonuncu elemanı 1’den çok değer Dizinin orta elemanı 1’den çok değer Dizide yok
Giriş dizini (T) Aranan (Key)
Sonuç (Found, L)
17 17 true, 1 17 0 false, ?? 17, 21, 23,29 17 true, 1 9,16,18, 30,31,41,45 45 true, 7 17, 18, 21, 23, 29, 38,41 23 true, 4 21, 23, 29, 33, 38 25 false, ??
İkili arama-eşit parçalama
Mid-point
Elements < Mid Elements > Mid
Equivalence class boundaries
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ı; adı üzerinde 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
Ie
Input test data
OeOutput test results
System
Inputs causinganomalousbehaviour
Outputs which revealthe presence ofdefects
Normal olmayan durumlara neden olan girişler
Kusurların varlığını ortaya çıkaran çıkışlar
Çıkış deneme sonuçları
Giriş deneme verileri
• 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.,-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
• Çı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
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
Beyaz kutu denemesi
Componentcode
Testoutputs
Test data
DerivesTests
Bileşenin (modülün) kodu
Denemeler alınıyor
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
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
Binary search (Java)
class BinSearch {
// This is an encapsulation of a binary search function that takes an array of// ordered objects and a key and returns an object with 2 attributes namely// index - the value of the array index// found - a boolean indicating whether or not the key is in the array// An object is returned because it is not possible in Java to pass basic types by// reference to a function and so return two values// the key is -1 if the element is not found
public static void search ( int key, int [] elemArray, Result r ){
int bottom = 0 ;int top = elemArray.length - 1 ;int mid ;r.found = false ; r.index = -1 ;while ( bottom <= top ){
mid = (top + bottom) / 2 ;if (elemArray [mid] == key){
r.index = mid ;r.found = true ;return ;
} // if partelse{
if (elemArray [mid] < key)bottom = mid + 1 ;
elsetop = mid - 1 ;
}} //while loop
} // search} //BinSearch
İKİLİ ARAMA ALGORİTMASI
1
2
3
4
65
7
while bottom <= top
if (elemArray [mid] == key
(if (elemArray [mid]< key8
9
bottom > top
İkili arama modülü için akış çizgesi
1
2
3
4
65
7
while bottom <= top
if (elemArray [mid] == key
(if (elemArray [mid]< key8
9
bottom > top
1, 2, 3, 8, 91, 2, 3, 4, 6, 7, 21, 2, 3, 4, 5, 7, 21, 2, 3, 4, 6, 7, 2, 8, 9Deneme durumları öğle seçilmelidir ki, tüm bu yollar yürütülmüş olsun
Bağımsız yollar
Beyaz kutu denemesi (örnek)Böyle bir akış çizgesine bakalım:
loop <= 10 times
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 = 12207030Tüm yolların denenmesi mümkünsüzdür. Ama beyaz kutu uygulamasının diğer gerekçeleri vardır.
• 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
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ı
• 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);} elseprintf(“dosyada sayı bulunmadı\n");}
Beyaz Kutu denemesi örneği-yolların belirlenmesi
Örnek için akış çizgesi
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); }
1
2
3
4 5
6
7 8
Beyaz Kutu Denemesi (bir örnek daha)1-8 sayıları düğümleri ifade ediyor.
İ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
1
2
4
3
5
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 Ö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 thens1;
elses2;
karmaşık koşul yapısı deneme sürecinde aşağıdaki gibi ifade edilmelidir:if c1 then
if c2 thens1;
elses2;
elses2;
1
2
4
5
3
6
7
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, 71, 2, 4, 5, 6, 71, 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
Kenar denemesine örnek
• 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
• 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.
Deneme yaklaşımları• 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ü denemesiTestcases
BA
C
Arayüzü türleri• Parametre 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
– 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ırBileş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
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
Nesneye-yönelik deneme
• Deneme bileşenleri nesne sınıflarıdır• Beyaz kutu denemesi daha büyük boyutlarda
kullanıla bilir
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
Yansı - 91 Yazılım Mühendisliği Yönetimi Güray YILMAZ
Alfa ve Beta Deneme
• Alfa Denemede; sistemin geliştirildiği yerde kullanıcıların gelerek katkıda bulunması sistemi test etmesi amaçlanmaktadır.
• Beta Denemede; kullanıcı, geliştirilen sistemi kendi yerleşkesinde, bir gözetmen eşliğinde yapar.
Gelişen bütünleşik denemesi
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test sequence1
Test sequence2
Test sequence3
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
Yukarıdan-aşağıya deneme
Level 2Level 2Level 2Level 2
Level 1 Level 1Testingsequence
Level 2stubs
Level 3stubs
. . .
Aşağıdan yukarıya deneme
Level NLevel NLevel NLevel NLevel N
Level N–1 Level N–1Level N–1
Testingsequence
Testdrivers
Testdrivers
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
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.
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
Yansı - 99 Yazılım Mühendisliği Yönetimi Güray YILMAZ
Yaşam Döngüsü Boyunca Sınama
SistemSınama Planı
Altsistem Sınama planları
• Modül Sınama Planı• Sınama Belirtimleri• Sınama Eğitim Klavuzu
•Modül Sınama•Bütünleştirici Sınama•Sınayıcı Eğitim
•Kullanıcı Sınaması•Sınama Raporları
P Ç T G K
P: Planlama Ç: Çözümleme T: Tasarım G: Gerçekleştirim K:Kurulum
Ö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.
Ö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