Transcript 9. Hafta
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