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 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 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 Deneme Adımları

Sistem Denemesi

Bütünleme Denemesi

Birim d.

Deneme yönü

gereksinimler

tasarım

kod

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

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

denenmesiGenelde 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

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 öncelikleri

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

Deneme verileri ve deneme durumları

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

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

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-eşit parçalama

İ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

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

Programın akış çizgesi

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

Beyaz Kutu Denemesi (bir örnek daha)

1

2

3

4 5

6

7 8

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

1

2

4

5

3

6

7

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, 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

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

elses2;

elses2;

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

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ü Denemesi

Arayüzü denemesi

Testcases

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üzleriAltsistem, 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

Deneme bileşenleri nesne sınıflarıdır Beyaz kutu denemesi daha büyük

boyutlarda kullanıla bilir

Nesneye-yönelik deneme

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

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 denemeYü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 denemeAş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 1Testing

sequence

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çinNesneyle bağlı tüm işlemleri denemeliTüm nesne özellikleri tanımlanmalı ve

incelenmeliNesne 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

denenmesiDeneme, kullanıcının sistemle etkileşimine

dayanmaktadırKullanıcının beklediği sistem özelliklerinin

denenmesi Tehlike denemesi

Sistemin tehlikeli durumlarda tepkisinin denenmesi system

Ö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