9. Hafta

Report
1
YAZILIM TESTİ
YAZILIM TESTİ
 Yazılım
geliştirme sürecinin
çeşitli aşamalarında,
 İnsan yada başka nedenlerden
dolayı çeşitli hataların veya
terslikleri oluşması kaçınılmazdır.
 Önemli olan, bu gibi olumsuz
durumların zamanında
belirlenmesi ve giderilmesidir.
2
 İnsanların
iletişim ve üretim
konularında mükemmel
olamamalarından dolayı,
 İnsan kaynaklı hatalar
geliştirme sürecinin en
başından yer alan tanımlama
aşamasında ortaya çıkmaya
başlar
3
Hataların
4
oluşmaması,
oluşanlarında ortadan
kaldırılmasını sağlamak
üzere yazılım geliştirme işleri
nitelik güvence etkinlikleriyle
beraber yürütülür.
Yazılım
testi yada diğer
adıyla sınama yazılım
geliştirme sürecinin en
önemli aşamalarından biri
olarak çözümleme, tasarım
ve kodlama aşamalarının
son bir değerlendirmesi
yerine geçer.
5
6
Sınaması
yapılmamış bir
tasarım aslında çalışamaz
demektir
7
Yazılım
testi ilk ortaya çıktığı
sıralarda yalnızca hata
ayıklama amacıyla
yapılmaktaydı.
Sonra testler yazılımın doğru
çalıştığını göstermek
amacıyla yapılmaya
başlandı.
 Daha
sonraları testlerin yapıcı
olmaktan çok yıkıcı bir şekilde
yapılmasının daha iyi sonuçlar
verdiği görüldü.
 1980’li
yıllardan sonra daha kurallı
geliştirme teknikleri kullanılmaya
başlandığından tüm geliştirme
sürecini içeren aşamalı testler
kullanıldı.
8
9
Günümüzde
de bu yöntem
yanında hataları önlemeye
yönelik testler
yapılmaktadır.
 Testin
en iyi şekilde
yapılabilmesi için test
mühendisleri tarafından test
senaryoları tasarlanmalıdır.
 Senaryolar, sistemin isterlerini
karşılayıp karşılamadığını
göstermek üzere gerçek
koşullar düşünülerek
hazırlanmalıdır.
10
 Bazı
yazılım geliştirme
yöntemlerinde, test aşamasını
birden fazla alt aşamaya
bölmek de mümkündür.
 Her
11
aşamada belli bir ayrıntıda
test yapılır.
TESTİN AMAÇLARI
 En
genel şekliyle bir yazılım
ürününün testi, bir yazılım
sistemini veya bir birimini
kullanıcıya teslim etmeden
önce kusur bulabilmek
amacıyla çalıştırmaktır.
12
13
 Sorunlardan
kaçınabilmenin
tek yolu yazılımı iyice test
etmek, yani sınamaktır.
 Sınamanın da «deneme» ve
«kabul» olarak iki amacı
olduğunu özellikle vurgulamak
gereklidir.
DENEME TESTLERİ
 Yazılımın
kaynak kodu yazılıp
derlendikten sonra doğru
çalışıp çalışmadığı sınanmalıdır.
 Hata bulmak niyetinden çok
önemli işlevlerin yerine getirilip
getirilmediğini anlayabilmek
amacıyla yapılan bu ön
testlerin amaçlarını şöyle
sıralayabiliriz.
14
15
 Kodlanıp
derlenen, sonra da
bağlanıp yürütülebilir hale getirilen
yazılım biriminin çalışıp
çalışmadığını denemek,
 Birimin
girdilere doğru işlem yapıp
doğr çıktı ürettiğini denemek,
 Birimin
tüm isterleri karşıladığını
denemek,
yanlış girdiler alması halinde16
hataya dayanıklılığını denemek,
 Birimin
 Birimin
ilk çalıştırma sırasında ve
sonlandırma sonrasında sistem öz
kaynaklarını nasıl kullandığını ve
serbest bıraktığını denemek ve
 Bulunan
her hatadan sonra başka
bir hata olup olmadığını
araştırmak.
KABUL TESTLERİ
 Yazılım
ürününün tamamının
istendiği gibi doğru çalıştığını
kullanıcıya veya onun
temsilcisine ya da proje örgütü
içindeki yetkili bir makama
göstermek amacıyla,
uygulama alanına bağlı olarak,
önce üretim yerinde sonra da
kullanım yerinde testler yapılır.
17
18
Bu
testler için genellikle ayrı
test ekipleri bulunur.
Bu testlerin amaçlarını şöyle
sıralayabiliriz :
19
Kullanıcıya
tanımlanan
isterlere göre sistemin doğru
çalıştığını göstermek, yani
doğrulamasını yapmak,
20
 Sistemin
kullanıcısının
amaçladığı şekilde kullanımı
için yeterli olduğunu, doğru
sistemin geliştirildiğini, yani
geçerliliğini göstermek.
Kullanıcının isterlerini çalışan sistem üzerinde
bir kez gözden geçirip amaçlarına tam uyacak
şekilde ince ayarlar yapabilmesini sağlamak
Uygulama alanının özelliğine göre, ya gerçek
durumlarda ya da ona en yakın benzetim
olanaklarıyla sistemi kullanım yerinde denemek
Sistemi olabildiğince ağır yükte ve en kötü
koşullarda çalıştırarak güvenirliğini kanıtlamak
21
Küçük ya da büyük her türlü yazılımın kabulü
için test senaryoları tasarlanmalı,belgelerde
tanımlanmalı,ürünü kabul edecek müşteri
yada makam tarafından onaylanmalıdır. Test
belgesinin onaylanması, test kıstaslarının
taraflarca kabul edilmesi anlamına gelir.
22
TESTİN YAPILIŞI
Yazılım sistemlerinin testinin
yapılabilmesi için aşağıdaki girdilerin
bir düzenleşim sisteminde bulunması
gereklidir :
 Yazılım isterleri belirtimi ( Nelerin test
edilmesinin istendiğini belirtir.)
 Tasarım belirtimi ( Nelerin test
edilmesinin gerektiğini belirtir.)
 Kaynak kod ( En son üretim hata bulma
amacıyla kullanılır )
23
 Test
Ortamı ( Hedef sistem donanımının bir
benzeri veya kendisidir.)
 Test Planlaması ( Hangi testin ne zaman ve
nasıl yapılacağını belirtir.)
 Test Tanımlaması ( Test senaryolarını ayrıntılı
olarak anlatır. )
 Test Yardımcı Gereçleri ( Ölçüm yada veri
giriş/çıkışı için kullanılır. )
 Benzetim Araçları (Gerçek ortamdaki
davranışları denetim altında yaratabilmek
üzere kullanılır.)
24
Bütün bunlar sağlandıktan sonra,
düzenleşim sisteminden çekilerek üretilen
ve test sistemine yüklenen yazılıma test
personeli tarafından test senaryoları tek
tek uygulanır, sonuçları daha sonra
değerlendirilmek üzere
kaydedilir.Kaydedilen sonuçlar olması
gereken değerlerle karşılaştırılır ;farklılık
bulunması halinde nedenleri
değerlendirilerek hataların bulunmasına
çalışılır.
25
Test değerlendirmesi sonunda , ya
tatmin edici bir sonuç elde edilerek
yazılımın yeterli niteliğe sahip
olduğuna kanaat getirilir ; ya da
yazılımın testi geçemeyerek hataları
düzeltilmek üzere tekrar üreticiye
geri verilir.Testlerin olumlu geçmesi
durumunda hatasız veya düşük hata
olasılığına sahip ürün kullanıcıya
teslim edilir.
26
Olumsuz test sonuçları kaynak kodun
düzeltilmesiyle giderilebileceği gibi
tasarımın hatta isterlerin dahi
değiştirilmesine neden olabilir.Bu
değişme ve düzeltmelerden sonra kaynak
kodlar ve etkilenerek değiştirilen belgeler
tekrar gözden geçirilip onaylanarak
düzenleşim sistemine konur ve test tekrar
edilir.
Test süreci boyunca gerçekleşen aşamalar
şekildeki gibi özetlenmektedir :
27
28
Örneğin, bir veritabanı yönetim sisteminde
saniyede 10000 erişim yapılması bir ister
olarak ortaya konmuş olabilir.Yapılan
testlerde bu değere ulaşmak mümkün
olmayıp 2000 düzeylerinde
kalınabilir.Kaynak kod incelemesinde
herhangi bir yanlış kodlama veya
verimsizlik bulanamadığı
takdirde,tasarımda belirlenen veri yapısı
ve erişim algoritmasında bir eksiklik
aranır.
29
Burada da bir hata görülmemesi üzerine
müşteri ile anlaşılarak isterde belirtilen
erişim düzeyini mevcut donanım,işletim
sistemi ve yazılım mimarisi ile
karşılanabilecek bir değere çekmek
gerekebilir.Böyle sonuçlar, çözümlemenin
iyi yapılmadığı ya da var olan teknolojik
kısıtlamaların tam olarak dikkate
alınmadığı durumlarda ortaya
çıkabilir.Bazı durumlarda önemli maddi
kayıplar ortaya çıkabilir.
30
TEST YÖNTEMLERİ
Her türlü üretim olduğu gibi, yazılım ürünü
testinin iki ana amacı vardır: Bunlardan
birincisi olan deneme , bir ürünün tüm iç
yapısının doğru çalıştığından emin olmak üzere
yapılır.İkinci olan kabul testleri ise ürünün
yerine getirmesi gerekli olan tüm işlevleri
başarıyla gerçekleştirdiğinin gösterilmesidir.
Birinci test yaklaşımına saydam kutu testi(whitebox test),ikinci test yaklaşımına da kara kutu
testi (black-box test )adı verilmektedir.
Şimdi bunları ayrıntılarıyla işleyelim.
31
SAYDAM KUTU TESTI
Yazılımın bu test için saydam bir kutuya
benzetilmesi onun tüm iç yapısının
(yordamların,veri yapılarının,iletişim
biçimlerinin)ortaya konmasından
kaynaklanmaktadır.Veri akışları,
bunların yazılım içinde izlediği mantıksal
ve fiziksel yollar,çeşitli test durumları ile
test edilirler.Saydam kutu testinide iki
aşamaya ayırmakta yarar vardır :
32
TASARIM TABANLI TEST
İsterler çözümlenmesi sonunda ortaya
çıkan sistem gereksinimleri , tasarıma
esas olacak sistemi tanımlar.Ancak, çoğu
zaman , bu tanımlamalar kodlama
aşaması için fazla üst düzeyde kalır.Bu
nedenle isterler daha ayrıntılı hale
getirilerek yazılım birimleri olarak kabul
edilen modüllere paylaştırılır.Testler
sırasında bu modüller birer kara kutu
olarak kabul edilerek ,ara yüzleri ile
tanımlanan girdi-çıktı verilerine göre test
durumları tasarlanır ve o şekilde test
edilirler.
33
Yazılım daha küçük parçalara bölündüğü
için bu tür testler daha alt düzeyde
yapılırlar.Örneğin, bir ileti alındığında,
iletinin her bir alanının tipine ve
sınırlarına doğru değerlendirme
yapıldığının, sonuçta beklenen değer
aralıklarında veriler elde edilmekte
olduğunun testi yapılır.Bu tür testler
genellikle kodlayıcının kendisi tarafından
en basit test ortamında yapılır.
34
KOD TABANLI TEST
Bazı durumlarda yalnızca kara kutu testi
yapmak o yazılım biriminin güvenilir
olduğunu kanıtlamayabilir.Örneğin,belirli bir
isteri doğru olarak gerçekleştirdiğini gösteren
bir kara kutu testi sırasında , modüllerden
birinin içine o test yada switch deyimlerinden
bazılarına hiç girilmemiş olabilir.Girilmemiş
bu deyimlerde önemli hatalar bulunabilir ve
testi geçtiği sanılan bu yazılım ,kullanım
sırasında mantıksal akış yollarından birinin
gerçekleşmesi halinde çöküşe neden
olabilir.Kod içinde hata üretebilen başlıca
noktalar arasında şunları sayabiliriz :
35
MANTIK HATALARI
Bir işi bilgisayara yaptırabilmek için
kullanılan kod parçalarının veya
deyimlerin yanlış yerleşimi,bir değişkene
ilk değer verilmemesi,bir isterin yanlış
yorumlanması gibi nedenlerden dolayı
mantıksal hatalar yapılır ve çalışan fakat
yanlış sonuç verebilen yazılımlar ortaya
çıkar.
36
KODLAMA HATALARI
Yeterli deneyimin bulunmadığı kodlama işlemleri
arasına kodlayıcı dilin esnekliği nedeniyle
yanılgıya düşüp önemli hataların oluşmasına
sebep olabilir.Örneğin, dinamik veri yapıları
üzerinde öbek kopyalama sırasında dizi boyunun
aşılması, işaretçilerin yanlış yerleri göstermesi
gibi hatalar yüzünden bazı testlerden geçtiği
halde güvenilirliği son derece zayıf olan
yazılımlar üretilebilir.Bir örnek vermek
gerekirse, veritabanına kayıt ekleme ve çıkarma
işlemi başarılı olabilir;fakat tasarımda dikkate
alınmayan bir şekilde, aynı kayıt tekrar
eklenirse yazılımın davranışının ne olacağı
belirsiz hale gelir.
37
AKIŞ YOLU VARSAYIMI
Yazılım içinde denetim akışının düzenli olarak hep
aynı sırayı izlediğini varsaymak bir hataya yol
açabilecek tehlikedir.Hiç öngörülmeyen bir anda,
farklı bir akış yolunun izlenmesi yazılımın hata
üretmesine neden olur.Örneğin ,bir girdinin
alabileceği değerlerin 1 ile 10 arasında olması
gerektiği varsayımına göre tasarlanan ve
kodlanan bir yazılım birimine -1 ya da 150 gibi
bir değer gelmesi halinde, ya değer reddedilmeli
ya da farklı bir dallanma izlenmeli ve hataya
düşülmemelidir.
38
YAZIM HATALARI
Günümüzde kullanılan birçok derleyici,kod yazım
hatalarını yakalayıp hata vermekte ve kod düzelinceye
kadar derleme yapmamaktadır.
Belirtilen bu nedenlerden dolayı , yürütülebilir kod olarak
kabul edilen bir yazılım birimini oluşturan önemli
deyim satırlarının da bir şekilde test edilmesi
gereklidir.Zira kara kutu testi bu hataları
yakalayamaz.Hiç değilse önemli iş yapan kod parçaları
ayrı bir yazılım içinde yerel olarak
denenmelidir.Örneğin, bir aygıttan okunan sekizli dizisi
şeklindeki veriyi tarayıp çözümleyen kısım tüm
yazılımla beraber değil de ayrı bir şekilde
denenmelidir.Aksi takdirde, diğer işlevlerin de yanlış
39
çalışmasına neden olarak testlerde zaman ve emek
kaybına neden olabilir.
KARA KUTU TESTİ
Yazılım testi ele alındığında, kara kutu testi
yazılımın ara yüzü düzeyinde yapılır.Her ne
kadar test hata bulmak için yapılsa da asıl amaç
yazılımın işlevlerini yerine getirdiğini
göstermektir.Bu amaçla,yazılımın tamamına ya
da test edilmekte olan birimine ara yüzde
belirtilen girdi sağlanır ve doğru çıktıyı vermesi
beklenir.Girdi ya da çıktılar çeşitli ortamlarda
sağlanan veri ya da bilgi olabileceği gibi bir
donanımdan veri alınması veya bir donanıma
kumanda edilmesi de olabilir.
40
Bu testlerde isterler çözümlemesi sonunda
belirlenen sistem gereksinimleri esas kullanıcıya
yönelik test durumları yaratılır,sonuçları
gözlemlenir.Kullanıcı, bu testler sırasında
yazılımın iç yapısıyla ilgilenmez.Testlerin düzey,
kullanım alanına göre değişiklik
gösterebilir.Örneğin, ürünün ilk kez test
sisteminde denenmesi başka olurken (bir uçuş
sisteminin laboratuar koşullarında denenmesi),
gerçek ortamda denenmesi (bir uçak üzerinde
havada denenmesi) başka olur.
41
ÖZEL SİSTEM TESTLERİ
Bilgisayar tabanlı sistemlerin uygulama alanları
değiştikçe onların test şekilleri de değişiklik
gösterir.Sistemlerin hem donanımları hem de
yazılımları uygulamam alanının isterlerini
karşılayacak şekilde test edildikten sonra
kullanıma sunulmalıdır.Şimdi bu tür sistemleri
ve test yöntemlerini gözden geçirelim
42
GÖMÜLÜ SİSTEMLER
Bu tür sistemlerin yazılımları donanıma kumanda
ettiği için testlerin donanımla birlikte yapılması
gereklidir.Özellikle, dış dünyadan koşut
zamansız olarak
43
44
Girdi alan ve bu girdilere tepki vermek
zorun da olan yazılımlar, bu girdilerin ne
zaman ve hangi çalışma kipi sırasında
geleceği belirli olmadığından gerekli
önemleri almalı, hata yaratıp
çökmemelidir.
45
Örnek olarak bir lazer yazıcının çalışmasını
denetleyen yazılımı ele alalım. Yazıcı
açıldıktan sonra kendi testlerini yaparak
çevrimiçi durumuna geçer.
46
Bu durumdayken bilgisayardan gelen
komutlara ve verilere uyarak baskı türünü
belirler,verileri alır, kağıt durumunu kontrol
eder ve baskıya geçer. Basım işi bitince
de yine çevrimiçi durumuna döner.
Denetim yazılımı bu işleri yaparken
dışarıdan gelebilecek girdileri de gerektiği
gibi değerlendirmek zorundadır.
47
Veri alışı sırasın da kağıt tepsisi çıkarıldığın
da ya da bakım kapağı açıldığın da, ilgili
algılayıcıdan gelen işaretle veri alışı
kesilerek uyarı verilmeli, çevrimdışı
durumuna geçmelidir. Kağıt tepsisi yerine
konduğun da tekrar çevrimiçi durumuna
gelmeli ve baskı süreci devam etmelidir.
48
GERÇEK ZAMANLI SİSTEMLER
DAHA ÖNCE DE AÇIKLADIĞIMIZ GİBİ, BİR
SİSTEMİN GERÇEK ZAMANLI SAYILABİLMESİ İÇİN
HIZLI YANIT VERMESİ DEĞİL ÇOK KÜÇÜK
ZAMANDA SINIRLARI İÇİNDE İŞİNİ TAMAMLAMA
ZORUNLULUĞU BULUNMASIDIR.
49
Bu tür sistemlerinde ne zaman gerçek
zamanlı tekpi gerektiren bir olayla
karşılaşacağı her zaman belirli olmaz.Bu
nedenle,gerçek zamanlı sistemlerin
yazılımı ya çok özel benzetim
ortamlarında sınanır yada gerçek sistem
üzerinde,laboratuvarda,olabildiğince
gerçek koşullar altında donanımla birlikte
test edilir.
50

Ancak bazı durumların test edilmesi için
mümkün olmayabilir;onun yerine,en yakın
durum için işlevsellik testi yapılarak
varsayıma gidilir.
51

Gerçek zamanlı sistemlerin en yaygın
örneklerinden biri olan bilgisayarlı kontrol
sistemleri içinde uçuş kontrol sistemleri
güç santrali denetimi,hava trafik
kontrolü,silah atış kontrol sistemleri,uzay
araçları yer almaktadır.
52

BÜYÜK VERİ TABANI SİSTEMLERİ:Bankacılık,personel
ve envanter bilgileri gibi çeşitli kayıtlar artık
bilgisayarlı sistemlerde tutulmakta ve her türlü erişim
işlemi onun üzerinden yapılmaktadır.Bu sistemler için
geliştirilecek yazılımlar tam olarak kullanıma
sunmadan önce çok ayrıntılı ve hassas testten
geçirilmeli.
53

Benzer bir şekilde envanter kontrol
sistemine yeni yüklenen hatalı bir yazılım
birimi üzerinde işlem yapılan ürün yada
nesnenin farklı sayıda
gözükmesine,dolayısıyla hesaplarda
açığa yol açabilir.Böyle sistemlerin
hatalarını bulup düzeltmek çok güç
olabilir hatta bazen geri dönüşü mümkün
olmayabilir.
54

GÜVENLİK SİSTEMLERİ:En dikkatli şekilde
test edilmesi gereken sistemlerden biri
olan güvenlik sistemleri çeşitli algılayıcılar
ve alarmlardan oluşur bu tür sistemler hiç
kesintisiz çalışmalı sürekli devrede kalmalı
her türlü olağan dışı olayı tespit edebilmeli
hem de yanlış alarm üretmemelidirler.
55

GENİŞ PAKET YAZILIMLAR:Büyük çapta
kullanıcısı olan paket yazılımlar için
yapılacak testler bir kusurun çok sayıda
kullanıcıyı etkileyebileceği istenmeyen
sonuçlara yol açabileceği göz önünde
bulundurarak yoğun testler yapıldıktan
sonra ürün sürümü gerçekleştirilmelidir.
56

AKILLI DERLEYİCİLER:Bazı derleyiciler
kaynak kodu tarayıp fazlaca tip denetimi
yapmadan makine kodu üretirler.Bazıları
ise kaynak kodu çok sıkı denetimden
geçtikten sonra kod üretirler.
57

OTOMATİK TEST ARAÇLARI:Yazılım testleri
çok uzun sürdüğü ve yüksek maliyet
gerektirdiği için bu işin bir kısmını kolayca
ve otomatik olarak yapabilecek araçlar
kullanmak mümkündür.Bu tür test
araçlarını şöyle sıralayabiliriz
58

DURAGAN ÇÖZÜMLEYİCİLER:Bu araçlar
yazılımın kaynak kodunu inceleyerek
yapısındaki zayıf noktasını bulur ve uyarı
verirler.Kodlayıcı bu uyarı ve önerileri
dikkate alarak kodu daha güvenilir hale
getirir.
59

BENZETİM ORTAMLARI:Bir yazılımın gerçek
ortamda çalıştığı taktirde nasıl
davranacağını denemek üzere onu sanal
bir işlemci üzerinde çalıştırarak test etmek
mümkündür.Bu maksatla merkez işlem
birimi donanım mimarisi ve işletim
sisteminin özellikleri dikkate alınarak özel
sistemler geliştirilir.
60

GİRDİ DOSYALARI:Bazı yazılımlar çeşitli
dosyalardan veri okuyarak işlem yapmak
üzere geliştirildiler.Bu tür yazılımları test
edebilmek üzere uygulama alanında
kullanılabilecek türden verileri önceden
üretip uygun bir biçimde dosyalara yazan
araçlar kullanılır.
61

TEST YAZILIMLARI; Test edilmesi gereken bir
yazılım birimine gerçek ortamda ki gibi
veri veya olay girişi sağlamamın bir yolu
da test edilecek yazılıma girdi sağlayan
diğer yazılım ya da donanımların yerine
geçebilecek yazılımlar kullanmaktır
62

SİMGESEL TESTLER; Bu testler sayısal
değersel yerine cebirsel işlemlerle yapılır
bazı yazılımlar belirli algoritmalar
çalıştırarak giriş değerlerine göre çıkış
değeri üretirler. Bu algoritmaları test ede
bilmek için girişte cebirsel denklemler
kullanan ve çıkışıda cebirsel olan özel
yazılım gereçleri kullanılır
63

ÇEVRE BENZETİCİLERİ;özellikle gömülü,
tahsisli ve gerçek zamanlı kontrol
sistemlerine gerçek çalıştırma koşullarında
dinamik olarak test edebilmek üzere
çevreden gelen etkileri benzetim yoluyla
sisteme gire bilen ve sistem çıkışlarını ala
bilen benzeticiler kullanılır.
64

SERGİLEME YAZILIMLARI; zaman aralıklı
ölçümler, hesaplamalar ve denetimler
yapan sistemlerin hesaplama sonuçlarını
grafik üzerinde göstermek, elde edilen
değerleri 2 ya da 3 boyutlu grafik
nesneler halinde sergilemek yapılan
testlerin sonuçlarının daha çabuk
değerlendirilmesini ve anlatılmasını sağlar.
65

TEST STRATEJİLERİ; buraya kadar açıkladıgımız
yöntemlerde yazılım testlerının nasıl
yapılabileceğini ortaya koyduk ancak, yazılım bir
sistem olarak geliştiriliyorsa bu sistemin testlerinin
de belirli bir sıra da, belirli sekil de , belirli stratejilere
göre yapılması gereklidir.
66
Bu modelde,ürünün en riskli görülen
kısımlarına daha fazla eğilecek şekilde
testler konmaktadır. Bunların bir kısmı
durağan, bir kısmı da dinamik testlerdir.
Birim Testi
Bir bilgisayar yazılımının en küçük birimi
yürütülebilir bir programdır. Bir sistem, bir
yada daha fazla yürütülebilir
programdan oluşabilir. Özellikle çok
programlı sistemlerde önce birimlerin ayrı
ayrı test edilmesi gereklidir.
67
68
Bu şekilde, yazılım mühendisinin veya
kodlayıcının elinden çıkan kodun
hatalarının önce kendi içinde düzeltilmesi
sağlanır. Daha çok saydam kutu
yönteminin kullanıldığı birim testi ile
düzgün ve hatasız çalıştığına kanaat
getirilen bir birim artık tümleştirme testi için
hazır hale gelmiş olur.
Birim Gerçekleştiriminde
Hatalar
Gerçekleştirim, yani kodlama sırasında
denetiminden geçen ancak çalışma
sırasında ortaya çıkabilen yaygın hatalar
arasında şunları sıralayabiliriz:
69
70

Deyimleri simgesel olarak göstermedeki
yanlışlıklar

İlk değerlerin atanmasında yanlışlık yada
eksiklik

Farklı veri tiplerinin karşılaştırılmasının ve
yordam parametrelerinde uyuşmazlık

Kayan nokta değerleri arasında karşılatırma
yapıldığında hassasiyet değerinin
karşılaştırmayı yanıltması
71

Aritmetik operatörlerin önceliklerinin yanlış
kullanılması

Parantezlerin kullanılmasında hata yapılması

Döngüden yanlış çıkış yada hiç çıkmama

Döngü kontrol değişkenlerinin yanlış kullanımı

Tasarım sırasında hiç olasılık verilmeyen bir
dallanmada yapılması gerekenlerin göz ardı
edilmesi
Birim Testi Yöntemleri
Test edilebilecek yazılım birimi ya bir
yürütülebilir programdır yada bir sınıf, bir
paket veya bir kütüphane gibi pasif bir
yazılım modülüdür. Yazılım birimi olarak bir
sınıf, bir paket veyaz bir kütüphane kabul
edilirse, bir pasif birimin testi şu şekilde
yapılır:
72
73

Bir test programı geliştirilerek test edilecek
birimi kullanması sağlanır

Test programının ana yordamı içinden
birimin tüm arayüzlerini denemek üzere
çağrılar yapılır

Birime gönderilen ve alınan değerler ya
ekrana yada bir dosyaya yazdırılır

Test edilecek birim başka birimleri
kullanıyorsa bu birimlerde test programı
içine dahil edilmelidir
Yazılım birimi kendi başına yürütülen, ayrı bir
aktif program ise şu şekilde tespit edilir:

Önce programın çalışabilmesi için gerekli
alt yapı, ilklendirme ve yapılandırma
dosyaları hazırlanır

Test edilecek programın etkileşiminde
olduğu diğer programlar hazır ise önce
onlar çalıştırılır sonrada test edilcek
program başlatılır eğer diğer programlar
hazır değilse onların yerine geçecek birer
test programı hazırlanır
74
75
BİRİM TESTİNİ YAPILIŞI
Birim testi yapılırken aşağıdakilere dikkat
edilmelidir:

Birimin arayüzü test edilerek bilgi
giriş/çıkışlarının uygun ve yeterli şekilde
yapıldığı kontrol edilir

Yerel veri yapıları inceleme altına alınarak
algoritmanın çalışması boyunca yada
yordamların çağırılması sırasında verilerin
saklandığı yerin bütünlüğünün bozulup
bozulmadığı test edilmelidir

Yazılım birimleri işlevsel kısıtlamalar ve sayısal
sınırlar içinde çalışırlar bu şekilde verilerin ve
işlevlerin korunması sağlanır
76

Birim içindeki birbirinden bağımsız tüm çalışma
yolları, tüm dallanmalar tek tek sınanmalıdır.
Birim içindeki hata yakalayıcılar birer birer
denenmelidir. Bir hata durumu yakalandığında
aşağıdakilerin varlığı da test edilmelidir:
-Yakalanan hataya uygun bir uyarı iletisinin
verilmesi
-Hatanın durdurup yeniden başlatmaya neden
olup olmadığı
77
-Hatanın kotarılmasının uygun bir şekilde
yapılması
-Hata iletisinin hatanın meydana geldiği
yeri tam olarak belirli etmesi.
TÜMLEŞTİRME TESTİ
Bir yazılım paketi çeşitli birimlerden
oluşabilir. Bu paket uygun bir donanım
üzerinde çalıştırılır. Yazılım ve donanım
birimlerinin kendi başlarına sorunsuzca
çalışıyor olmaları bir araya geldiklerinde
de sorunsuz çalışacakları anlamına
gelmez.
78
79
Çünkü, birimler arası uyumu tam olarak
sağlayabilmek oldukça güçtür ve çok test
gerektirir. Birden fazla yazılım biriminin bir
araya getirilerek uyumlu bir şekilde ve
hatasız çalışması her birinin tek tek
değilde bir bütün içinde, tasarımda
belirtildiği şekilde kendi üzerine düşen
görevleri yerine getirip getirmedikleri
tümleştirme testi ile kontrol edilir. Bu testin
yapılma nedenlerini şöyle özetleyebiliriz:
80

Bir birim Çalışması bir başka birimin
çalışmasını etkileyebilir.

Birimler arasında koşut zamanlığın
sağlanması gereklidir.

Bütün bir işlevi oluşturan alt işlevlerin her
biri belirli birimler tarafından doğru olarak
yerine getirilse bile hepsi bir araya
getirildiğinde beklenen sonucu
vermeyebilir.
81

Birimler arasındaki arayüzler arasında
verilerin kaybolması olasılığı vardır.

Birimlerin ağ üzerinde dağıtılması
durumunda çalışma sırası, ileti aktarımı,
koşutzamanlı iletişim sorunları, geri
kazanma gibi konularda sorun yaşanabilir
2 tane tümleştirme çeşidi vardır
1- Yukarıdan Aşağıya
Tümleştirme
Yazılımı oluşturan birimlerin denetim
sıradüzeni içinde, birimler ya derinlik
tabanlı yada genişlik tabanlı olarak
tümleştirilirler. Önce ana birimin testi
yapılır. bir sonraki aşamada ya aynı
düzeydeki bir başka birimin testi yapılır
yada aynı birimin bir alt düzeyindeki
birimle tümleştirmesi ve testi yapılır.
82
83
Bu işlemler sırasında, tümleştirmesi daha
sonra yapılacak olan birimin geçici olarak
yerine geçecek şekilde basit kod
parçaları veya sürücüler kullanılır. Test
sırası geldikçe bu geçici kod parçaları
gerçekleriyle değiştirilir. Her bir eklemede
daha önce yapılan testlerin bir kısmı yada
tamamı tekrar yapılarak yeni bir kusur
eklenip eklenmediğinden emin olunur.
2-Aşağıdan Yukarıya
Tümleştirme
Bu stratejide tümleştirme atomik birimlerin
çalıştırılıp test edilmesiyle başlar. Alt düzey
birimler birleştirilerek kümeler halinde
getirilir. Bu küme, test senaryosu
gereğince geliştirilen bir sürücü ana
programla veri giriş/çıkışı bakımından test
edilir. Benzer şekilde, d,ğer alt düzey
birimler de kümeler halinde test edilir.
84
85
Daha sonra sürücü programlar ayrılarak
yazılım paketinin yapısı içinde bulunan bu
kümelerin birleştirilmesinden oluşan daha
üst düzeyde yeni kümeler meydana
getirilir. Bu kümeler de yine sürücü
programlarla test edilir. Bu şekilde en üstte
bulunan ana birime kadar ulaşır.
YETERLİLİK TESTİ
Yazılım yeterlilik testi çoğu zaman
doğrulama ve geçerleme konusunun bir
parçası olarak değerlendirilir. Tümleştirme
testinden sonra yazılım büyük ölçüde
kusurlarından arındırılmış, arayüzleri doğru
çalışır hale gelmiştir Bundan sonra bir dizi
test daha yapılır işte bunlar yeterlilik
testleridir.
86
HAZIRLAYANLAR
Öğr. Gör. Mevlüt İNAN

similar documents