Yazılım Testi (Software Testing)

Transkript

1 Yazılım Testi (Software Testing) Yazılım geliştirme karmaşık bir süreç olduğundan, hataların ortaya çıkması kaçınılmazdır. Bu sebeple yazılım, yaşam döngüsünün her aşamasında, hatalara karşı test edilmelidir. Bu testler sonucunda; Gereksinimler arasındaki tutarsızlıklar, çözümleme şeması ile uygulama alanı arasındaki uyumsuzluklar, tasarım hataları, çalışma anı hataları gibi hatalar yakalanmaya çalışılır.[3] Yaşam döngüsünde ilerledikçe hataların düzeltilmesi zorlaşacaktır. Bu yüzden iyi bir test yaklaşımı hataların erken belirlenmesine katkıda bulunacak ve yazılımın kalitesini arttıracaktır. Bir test yaklaşımı şu bileşenleri içermelidir: Planlama Tasarım Çalıştırma Bilgi toplama ve değerlendirme Test Yaklaşımının Genel Özellikleri Test yaklaşımlarının genel özellikleri şu maddeler ile açıklanabilir[2]: Ürün tek başına bilgisayar yazılımından ibaret olmayabilir. Sistemin bütününde çeşitli algılayıcılar, harici sistemler, vb. yer alabilir. Nesneye Yönelik Programalam (NYP) da sınıfların bireysel görevlerinden başlayıp, yazılımın üst düzey görevlerine kadar tüm işlevler test edilir. Yazılım yaşam döngüsünün değişik aşamalarında değişik test teknikleri uygun olacaktır.

2 Testler hem ilgili bileşeni oluşturan kişi tarafından, hem de bağımsız kişiler tarafından yapılır. Büyük ölçekli kurumlarda ayrı bir test ekibi bulunabilir. Test ve hata ayıklama(debugging) ayrı işlerdir, ancak hata ayıklama her test yaklaşımının önemli bir parçasıdır. Resmi teknik değerlendirmeler sayesinde test öncesinde de hatalar belirlenebilir. Test Amaçlı Yapılanma Test yapılması amacıyla çeşitli süreçler meydana gelecektir. Bu süreçlerin kimler tarafından yürütüleceği, nasıl yürütülmesi gerektiği önemli bir konudur [2]. Bir bileşen ilk olarak onu hazırlayan programcı tarafından test edilir çünkü bir programı en iyi olarak bilen, onu yazandır. Her bileşen aynı zamanda yazarı dışındaki kişilerce test edilir. Yazılım evinin bağımsız bir test ekibi bulunabilir. (ITG: Independent Test Group) Aksi halde farklı projelerde çalışan ekipler, veya aynı projenin farklı alt grupları, birbirlerinin çalışmalarını test eder. Programcıların çıkarları, kendi yazdıkları programın hatasız, zamanında ve bütçe dahilinde tamamlanmasını gerektirir. Bu yüzden test, programcının psikolojisi açısından yıkıcı bir eylemdir, yani genellikle geliştiriciler kendi programlarının hatalarını bulmaya yönelik değil, doğru çalıştığını ispatlamaya yönelik testlere eğilim gösterebilir. Yazılımlar aynı zamanda teknik olmayan kişilerce test edilir. Yazılım testinin ana felsefesini şu olarak özetleyebiliriz: Müşteriler hataları önünde sonunda bulacaklardır. İyisi mi

3 siz onlardan önce davranın, aksi halde prestijiniz sarsılacaktır. Test Yaklaşımının Belirlenmesi Test yaklaşımında göz önünde bulundurulması gereken konular şunlardır [2]: Test çalışmaları, en çok çaba gerektiren yazılım mühendisliği etkinlikleri arasında yer almaktadır. Test çalışmaları, olası tüm hataların yakalanacağı bir güvenlik ağı olarak düşünülmemelidir. Test için ne kadar çok çaba gösterilirse gösterilsin, tespit edilemeyen hatalar olacaktır. Test çalışmalarının hedefleri açıkça belirlenmelidir: Testlerin kapsama alanı, Test çalışmalarına ne kadar kaynak ayrılacağı, Zaman, kişi, bütçe, Yazılımın türüne göre belirlenecek diğer ölçütler, İki hata arası ortalama süre (MTBF), hassasiyet, vb. Testler otomatikleştirilmelidir. Test süreci ölçülmeli ve iyileştirilmelidir. Test Türleri Yaklaşım tarzlarına göre test türleri 2 ye ayrılmaktadır [1]: Kara Kutu Testi (Black-Box Testing): Test edilecek birimin iç işleyişi bilinmez, sadece birimin beklenen girdilere karşı beklenen çıktıları üretip üretilmediğine bakılır. Beyaz Kutu Testi (White-Box Testing): Test edilecek birimin iç işleyişi bilinir ve yapılacak testler buna göre belirlenir. Yürütülme sırasına göre test türleri 2 ye ayrılmaktadır [1]: Doğrulama Testleri (Verification Test): Yazılım ekibi

4 tarafından yapılır. Bu yazıda doğrulama testlerinin 2 türünü inceleyeceğiz. Birim testleri (Unit Test) Entegrasyon Testleri (Integration Tests) Geçerleme Testleri (Validation Tests): Son kullanıcılar tarafından yapılır. Bu yazıda 2 çeşidinden bahsedeceğiz. Alfa Testi Beta Testi Yaklaşım tarzlarına göre testleri tablo yardımı ile inceleyelim. Doğrulama Testleri (Verification Tests)

5 Birim Testleri (Unit Tests) Birim testinde amaç en küçük yazılım bileşeninin test edilmesidir. NYP de bireysel sınıfların test edilmesi olarak karşımıza çıkar. Çevik yaklaşımda, kodlamadan önce tasarlanır ancak kodlama sırasında veya kodlamanın ardından da tasarlanabilir. Yürütülmesi, kodlama sırasında veya kodlamanın ardından yapılır. Bir sınıfın tek başına yürütemediği sorumlulukların test edilmesi için, bu sınıfın ihtiyaç duyduğu diğer sınıfların yerine geçecek kod gerekebilir. Buna vekil, sahte, yalancı kod ya da sınıf denir. Vekil sınıflar, sadece ihtiyaç duyulan sınıflar gerçeklenene dek kullanılır. Vekil sınıfların bu açıdan basit tutulması ek kodlama yükünü azaltır. Vekil sınıfların mümkün olmadığı durumda ortaklaşa yürütülen sorumlulukların test edilmesi tümleştirme sınamalarına bırakılır.[2,3] Yukarıdaki resimden de görülebileceği gibi birim testi, sadece

6 belirli bir sınıfla ve o sınıfın çalışması için gereken kod parçalarıyla ilgilenir. Birim testlerinde yakalanabilecek bazı hata türleri şunlardır [2]: Farklı veri tiplerinin karşılaştırılması veya birbirinin yerine kullanımı. NYP de çok biçimliliğin yan etkileri Mantıksal operatörlerin yanlış kullanımı Operatörlerin önceliklerinin gözden kaçırılması Değişkenlerin karşılaştırılmasındaki hatalar Döngülerin hatalı sonlanması veya sonsuz döngüler Değişkenlere hatalı değerler atanması vb. Birim testi sonunda hatalardan ders çıkarmak çok önemlidir. Yapılabilecek tüm hatalar öngörülemez, ancak kariyer boyunca yapılan her hata aranabilecek hata türleri listesine eklenmelidir. Entegrasyon Testleri (Integration Tests) Birim testlerini geçen sınıflar, bir araya geldiklerinde de bağzı hatalara sebep olabilir. Yazılım geliştirme sürecinin her aşamasında her ayrıntının açıkça belirlenmesi beklenemez. Ayrı ayrı programcılar, belirlenmemiş ayrıntılar üzerinde kendi karar verme yetkilerini (initiative) kullanabilir ya da aynı kişinin farklı ayrıntılar hakkında verdiği kararlar bile birbiri ile uyumlu olmayabilir. İşte bu durumda entegrasyon testinin yapılması büyük önem arzetmektedir. NYP de birim ve entegrasyon sınamalarını birbirinden ayıran kesin çizgiler yoktur. Entegrasyon testinin alt türleri olan duman testi, geriye dönük sınamayı biraz inceleyelim.[1]

7 Duman Testi (Smoke Testing) Yüzeysel ancak başarısız olma durumunda tüm sistemin çalışmasının olanaksız olacağı testlerdir (Show-stopper errors). Diğer entegrasyon testlerinden önce yapılırlar. Çeşitli bileşenler tüm gerekli yazılım elemanlarını içeren (kod, yapılanma dosyaları, dış kütüphaneler, vb.) parçalar bir araya getirilir (build) ve günlük olarak test edilirler.[5] Geriye Dönük Test (Regression Testing) Yazılıma yeni bir işlev veya bileşen eklendiğinde, tüm testlerin yenilenmesidir. Hangi ölçekte bir eklentinin geriye dönük testi başlatacağının kararını vermek gerekir. Bu noktada ölçek düştükçe testin sıklaşacağını ve masrafın artacağını söyleyebiliriz. Otomatik test gereçleri ile masraftan ve zamandan kâr edilmesi sağlanabilir.[5] Yukarıda geriye dönük testin çevik süreçte nasıl kullanıldığını görebiliriz. Geçerleme Testleri (Validation

8 Tests) Gereksinimler belgesinde yazılmış olan işlevsellikten yola çıkılarak, kullanıcı tarafından yapılır. Son kullanıcıların yapabileceği beklenmedik davranışların tümünü teknik ekip önceden bilemez. Bir şeyi ne kadar çok kişi incelerse, ondaki kusurlar o kadar çabuk bulunur ve düzeltilir fikri, open source a da bir dayanak olmuştur. Open Source un kurucusu Eric Raymond bu konu hakkında given enough eyeballs, all bugs are shallow demiştir.[4] Geçerleme testlerinin alfa testi ve beta testi olmak üzere iki türü vardır. Alfa Testi (Alpha Test) Yazılım firması içerisinde, kullanıcı tarafından yapılır. Yazılım geliştirme ekibinin denetiminde ve izlenmesi ile yapılır. Yazılımın doğal kullanım ortamına en yakın koşullarda yürütülür. Beta Testi (Beta Test) Müşterinin kendi yeri içerisinde, gerçek kullanım ortamında yapılır. Yazılım geliştirme ekibinin müdehalesi olmaz. Bulunan hatalar yazılım geliştirme ekibine düzenli aralıklarla ve resmi bir biçimde bildirilir. Sistem Testleri (System Tests) Yazılım tek başına sistemin bütününü oluşturmayabilir. Gömülü uygulamalar, ara katman yazılımları, vb. sistemler buna

9 örnektir. Sistemin tümünü her yönüyle incelemeye yönelik testlerdir.[4] Bu testlerin dördünden bahsedeceğiz. Kurtarma Testi (Recovery Test) Hatalara dayanıklı (fault tolerant) sistemler için geçerlidir. Bir hata ortaya çıktığında sistemin kendini toparlayarak doğru çalışmaya devam edip edemediği sınanır. Kurtarma işlemi belli bir süre içerisinde tamamlanmalıdır. (MTTR: Mean Time To Repair). Güvenlik Testi (Security Test) Sistem için herşeyin denenmesidir. Kuralları yoktur. Sistemin izin vermediği şeyler yapılmaya çalışılır.[5] Zorlama Testi (Stress Test) Normalin dışında yüklenme durumunda, sistemin nereye kadar dayanabileceğinin test edilmesidir. Başarım Testi (Performance Test) Gerçek zamanlı uygulamalarda özel öneme sahiptir. Program kendisinden bekleneni doğru yapabilir ama zamanında yapamayabilir. Bunun gibi hataları yakalamaya çalışır.[5] Hata Ayıklama (Debugging) Yapılan türlü testlerin sonucunda bulunan hatalar düzeltilmelidir. Test ve hata ayıklama çalışmaları kimileri tarafından angarya, ayak işi, sıkıcı, ikinci sınıf olarak nitelendirilebilir. Bu hataların düzeltilmesi işlemine debugging denilir.[2] Testin önemini gördük, yazılımınızdaki hatalar size ve kurumunuza prestij kaybettirir. Düzeltilemeyen veya düzeltmesi uzun süren hatalar ise daha çok prestij kaybettirir. Test etme ve güvenlik açıklarının belirlenmesi için alışılagelmiş düşünce biçiminin dışına çıkabilmek gerekir ki bu da özel bir

10 yetenektir. Saygı duyulan ünlü programcılar, hata ayıklamanın kodlama yapmaktan daha zor ve daha çok yetenek isteyen bir iş olduğu görüşünde birleşmektedirler. Bir noktada takıldığınızda, biraz ara verip sorunu yeniden icelemeniz, başarı şansınızı arttıracaktır. Gelişme ortamının hata ayıklama yetenekleri programcıya yardımcı olmaktadır. Yazılım testlerinden önce yazılım gözden geçirme çalışmaları yapılmaktadır. Büyük oluşumlarda toplantı şeklinde yürütülmektedir. Resmi Yazılım Gözden Geçirme Çalışmaları IEEE 1028 std. göre bir resmi yazılım gözden geçirme adımları şu şekildedir[2]: Değerlendirme Başlangıcı: Değerlendirme yöneticisi standart bir checklist kullanarak, verimli bir toplantı için gerekli koşulları sağlar. Yönetimin Hazırlanması: Sorumlu yönetim, gözden geçirme için gerekli kaynakları hazırlar ve toplantının standartlara uygun yürütülmesini sağlar. Gözden Geçirme Prosedürlerine Genel Bakış: Değerlendirme yöneticisi tüm değerlendiricilerin gözden geçirmenin amaçlarını ve prosedürlerini anladığından emin olur. Bireysel Hazırlık: Değerlendiriciler bireysel olarak inceleme toplantısına hazırlanır ve toplantının standartlara uygun yürütülmesini sağlar. Grup İncelemesi: Bireysel hazırlıkların sonuçları önceden belirlenen yer ve zamandaki toplantıda biraraya getirilir ve sonuç raporu üzerinde uzlaşıya varılır. Düzenleme: İncelenen çalışmanın yazar(lar)ı veya atanacak başka bir kişi/ekip, önceki adımlarda belirlenen noktaları düzeltir. Sonlandırma: Değerlendirme yöneticisi düzeltmelerin yeterliliğini inceler.

11 IEEE Yazılım Gözden Geçirme Çalışmalarının Standartlarına Bu Siteden Ulaşabilirsiniz : Netbeans IDE sinin sunduğu Birim Test oluşturma toolu kullanımı: Kaynakça 1. Keytorc, 50 Soruda Yazılım Testi, a-yazlm-testi 2. İTÜ Bilgi İşlem Daire Başkanlığı, ılım-testi-ve-test-süreçleri 3. Wikipedia, Software Testing,

12 pcgvkaweub3jnl3dpa2kvu29mdhdhcmvfdgvzdgluzw 4. Ultimateqa, eps-to-ensure-software-quality/ 5. Solvepark, Yazılım Test Methodları,