Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

Yazılımda Test Gerçekleri. Yazılım süreç modelleri bir idealdir… gerçek değildir Hiçbir yazılım geliştirme girişimi bir süreci mükemmel bir şekilde uygulayamaz.

Benzer bir sunumlar


... konulu sunumlar: "Yazılımda Test Gerçekleri. Yazılım süreç modelleri bir idealdir… gerçek değildir Hiçbir yazılım geliştirme girişimi bir süreci mükemmel bir şekilde uygulayamaz."— Sunum transkripti:

1 Yazılımda Test Gerçekleri

2 Yazılım süreç modelleri bir idealdir… gerçek değildir Hiçbir yazılım geliştirme girişimi bir süreci mükemmel bir şekilde uygulayamaz. Peki neden? –Şartname asla müşterinin ihtiyaçlarını tam anlamıyla kapsamaz. –Hiçbir zaman bütün test işlemini gerçekleştirmek için yeterli zaman olmaz. Bunlara rağmen ilerlemek için ideal bir modele ihtiyacımız var. –İmtiyazlar kaçınılmazdır.

3 Yazılım testinde varsayımlar (aksiyomlar) 1.Bir programı tamamen test etmek imkansızdır. 2.Yazılım testi riske dayalı bir uygulamadır. 3.Test, hataların yokluğunu gösteremez. 4.Ne kadar fazla hata bulursan o kadar daha hata vardır. 5.Bulunan bütün hatalar düzeltilemeyecektir. 6.Bir hatanın gerçekten bir hata olduğunu söylemek zordur. 7.Şartnameler asla son halini almayacak. 8.Yazılım test uzmanları proje takımında pek popüler değillerdir. 9.Yazılım testi disiplinli ve teknik bir uzmanlık alanıdır.

4 Varsayım 1 Programı tamamen test etmek imkansızdır. Etraflıca test etmek için kaç tane test durumuna (test case) ihtiyaç var: –Powerpoint –A calculator –MS Word Tamamiyle emin olmak için tek yol olası bütün girdilerle bu girdilere karşılık üretilen çıktıları gözlelemektir. Şartnamenin de doğru ve eksiksiz olması lazım.

5 Varsayım 1 (cont’d) It is impossible to test a program completely Olası girdilerin sayısı çok fazladır. Olası çıktıların sayısı çok fazladır. Yazılımın içindeki yolların sayısı çok fazladır. Yazılım şartnamesi yoruma açıktır.

6 Varsayım 2 Yazılım testi riske dayalı bir uygulamadır Eğer yazılımı tüm girdiler için test etmezseniz risk almış olursunuz. Neyse ki birçok doğru çalışan girdi es geçilecek. Hataya sebep olan bir girdi atlanırsa? –Risk: mali kayıp, güvenlik, can kaybı! –Test yapan kişinin üstünde çok baskı vardır!

7 Varsayım 2 (cont’d) Yazılım testi riske dayalı bir uygulamadır Eğer çok fazla test yapılırsa, geliştirme maliyeti altından kalkılamaz hale gelir. Eğer çok az test yapılırsa yazılım hatalarının olasılığı artar ve bu hatalar bize çok fazla zaman kaybettirir. Test maliyeti Kaçırılan hataların sayısı Çok test Test sayısı Az Test İdeal test MiktarMiktar

8 Varsayım 3 Test, hataların yokluğunu gösteremez. «Program testi hataların varlığını göstermek için kullanılabilir ancak, asla yokluklarını göstermek için kullanılmaz!» Edsger Wybe Dijkstra Dijkstra programlama dilleri alanına önemli katkılarından dolayı 1972 ACM Turing ödülünü kazanmıştır.

9 Tartışma… ACM nedir? ACM Turing Ödülü nedir? Alan Turing kimdir?

10 Varsayım 4 Ne kadar fazla hata bulursan o kadar daha hata vardır Hatalar gruplar halinde görülür. Bir hata bulduğunuz zaman muhtemelen daha çok bulacaksınız … Peki neden? –Programcıların kötü günleri olabilir –Programcılar genelde aynı tip hataları yapmaya meyillidirler –Bazı hatalar sadece buz dağının su üstündeki kısmıdır Boris Beizer coined the term pesticide paradox to describe the phenomenon that the more you test software the more immune it becomes to your test cases. «Yazılımı ne kadar fazla test ederseniz, test durumlarınıza o kadar bağışıklık kazanacaktır.» Boris Beizer –Çare: Yazılımın farklı bölümlerini incelemek için sürekli yeni ve farklı test durumları oluşturmalısınız.

11 Varsayım 5 Bulunan bütün hatalar düzeltilemeyecektir Bildiğin bir hatayı neden düzeltemeyesin? –Yeterli zaman yoktur Zaman sınırları aşılamaz –Gerçekten bir kod hatası olmayabilir. Şartname yanlış olabilir –Düzeltmesi çok risklidir Bir hatanın düzeltmesinin sonuçları ağır olabilir (regresyon hatası) –Düzeltmeye değmez Can alıcı olmayan bazı hatalar sonra düzeltilmek üzere bekletilebilir.

12 Varsayım 6 Bir hatanın gerçekten bir hata olduğunu söylemek zordur Yazılımda bir problem varsa ve o zamana kadar kimse bunu fark edememişse… bu bir hata mıdır? –Parodi “Ormanda bir ağaç düşerse, gerçekten gürültü çıkarır mı?” Fark edilmeyen hatalara örtülü/gizli hata (latent bug) denir.

13 Varsayım 7 Şartnameler asla son halini almayacak Amacı/hedefi değişen şartnameye göre bir ürün geliştirmek yazılım geliştirme dünyasında neredeyse kaçınılmazdır. –Şiddetli rekabet –Çok hızlı piyasaya sürme periyotları –Yazılım çok «kolay» değişir Diğer mühendislik alanlarında bu doğru değildir –Örneğin; Boğaziçi Köprüsünün inşası başladıktan sonra treninde geçmesi için uyarlanamaz.

14 Varsayım 8 Yazılım test uzmanları proje takımında pek popüler değillerdir Yazılım test uzmanının hedefi: –Hataları bulmak –Hataları erken bulmak –Hataların düzeltildiğinden emin olmak Takında iyi karşılanmak için öneriler: –Hataları erken bul –Heyecanını bastır… profesyonelce davran –Sadece kötü haberleri raporlama

15 Varsayım 9 Yazılım testi disiplinli ve teknik bir uzmanlık alanıdır Yazılımların daha basit ve yönetilebilir olduğu zamanlarda yazılımı test edenler genelde eğitimsizdiler ve test uygulaması metodik olarak yapılmıyordu. It is now too costly to build buggy software. Artık günümüzde hatalı yazılım üretmek çok maliyetlidir. Bu yüzden test uygulaması bir disiplin haline gelmiştir. –Çok yönlü, gelişmiş teknikler –Araç desteği –Tatminkar kariyerler

16 Bazı önemli terimler Doğrulama (Verification) –«Ürünü doğru bir şekilde üretiyor muyuz?» –Yazılım şartnameyle örtüşüyor mu? Sağlama (Validation) –“Doğru ürünü mü üretiyoruz?” –Yazılım müşterinin ihtiyaçlarını karşılıyor mu?

17 Neler öğrendik… … Yazılım testindeki 9 varsayım … Yazılım doğrulaması (verification) nedir? … Yazılım sağlaması (validation) nedir?


"Yazılımda Test Gerçekleri. Yazılım süreç modelleri bir idealdir… gerçek değildir Hiçbir yazılım geliştirme girişimi bir süreci mükemmel bir şekilde uygulayamaz." indir ppt

Benzer bir sunumlar


Google Reklamları