Yazlm Test Sreci Yazlm test sreci Test Hazrlk
- Slides: 13
Yazılım Test Süreci
Yazılım test süreci
Test Hazırlık Adımında Neler Yapılmalıdır? • Test edilecek yazılıma ait analiz ve teknik tasarım aşamaları ile ilgili dökümanlar, test ekibi tarafından incelenir. • Yazılım içinde test edilecek (ve edilmeyecek) modüller belirlenir. • Risk analizi yapılır ve yapılan değerlendirmeye göre dinamik test aşamasında uygulanacak olan test teknikleri ve metodları belirlenir. • Dinamik testin uygulanacağı ortamlar ve bu ortamların ihtiyaçları belirlenip, uygun şartlar sağlanır. • Test ekibi içinde görev paylaşımı ve zaman planlaması yapılır. • Testin sonlandırma kriterleri belirlenir. • Bir programa belirli girdiler verildiğinde hangi çıkışların ne şekilde alınması gerektiğini bildiren test case senaryoları belirlenir. • Dinamik testin hangi adımlarla ve ne şekilde uygulanacağının belirtildiği test planı hazırlanır.
Dinamik Test Süreci Neleri İçermektedir? • Test edilecek yazılımın tipine göre, kullanılacak test yöntemi değişmekle beraber, test yöntemleri genel olarak aşağıdaki şekilde gruplandırılabilir: • Birim testi (Unit testing) • Entegrasyon/Sistem/Tümleyim testi (Integration/System testing) • Regresyon testi (Regression testing) : Genelde büyük bir miktar kod değiştikten sonra, hata bulmaya yönelik yapılan bir test çeşididir. • Performans / Yük testi (Performance / Stress testing) • Kullanıcı kabul testi (User acceptance testing) • Beyaz kutu testi (White box testing) • Kara kutu testi (Black box testing)
Doğrulama testi ve hata testinin farkı nedir? • Doğrulama testi (Validation testing) • Yazılımcının kendisine veya müşteriye, yazılımın isterleri yerine getirip getirmediğini göstermek için; • Sistemin önceden tasarlandığı şekilde çalıştığını ispat etmek; • Hata/Kusur testi (Defect testing) • Yazılan programdaki eksik, bozukluk, kusuru bulma amaçlı. • Program, hatalı sonuç vermeye zorlanır. Sıradan olmayan durumlar yaratılır. • Test, hata olmadığını değil, hatayı gösterir. -> Hata testi sonucu, programın hatasız çalıştığı yargısına varılamaz.
Birim ve sistem testinin ne farkı vardır? • Birim testi • Programı oluşturan bileşenlerden birinin testi; • Genelde birimi geliştiren kişi tarafından yapılır (Kritik sistemler hariç); • Geliştiricinin tecrübesiyle şekillenir. • Sistem testi • Bileşenlerden ikisi veya daha fazlası bir araya getirilerek yapılan test; • Bağımsız bir test ekibi tarafından yapılır; • Testler, sistemin spesifikasyonu esas alınarak şekillenir. Birim testi Sistem testi Yazılım geliştirici Test birimi
Kara kutu testi (Black-box testing)
Sistem testi (Integration/System testing) - 1 • Bileşenler bir araya getirilip, bir alt sistem veya sistem oluştururlar. • İki aşamadan oluşur: • Entegrasyon testi (Integration testing): Test ekibi, bileşenlerin bir araya gelmesiyle oluşan sistemin kodlarına ulaşabilir. Hata (defect) bulma amaçlıdır. Bir sorun (defect) keşfedildiğinde, hangi bileşende sorun olduğu bulunur. • Sürüm testi (Release testing): Müşteriye teslim edilecek programın komple bir versiyonu test edilir. Bakılan şey, sistemin istenilen işi yapıp yapmadığıdır. Kara kutu test sistemi kullanılır; yani test ekibi sadece sistemin verilen işi yapıp yapmadığını kontrol eder. Buldukları problemleri yazılımcıya iletilirler. (Eğer sürüm testine müşteri de dahil edilirse, adı kullanıcı kabul testi (user acceptance testing) olur. )
Sistem testi (Integration/System testing) - 2 • Bileşenlerin bir araya getirilmesi iki şekilde yapılabilir: • Yukarıdan aşağı entegrasyon (Top-down integration) • Önce sistemin omurgasını oluştur, sonra yavaş bileşenleri eklemeye başla. • Aşağıdan yukarıya entegrasyon (Bottom-up integration) • Önce altyapıya ait bileşenler kurulur, üstüne işlevsel bileşenler eklenir. Ör: Önce en çok kullanılan veri tabanı ve ağ bileşenleri birleştirilir. Üstüne diğer fonksiyonlar eklenerek devam edilir.
Adım adım entegrasyon testi (Incremental integration testing)
Test hazırlama • Tüm durumları tek test etmek imkansız! • Olası durumları gösteren alt kümeler oluşturulmalı. • Menülerden ulaşılabilen tüm fonksiyonlar test edilmeli; • Aynı menüden girilen fonskiyon kombinasyonları test edilmeli; • Kullanıcı girdisi gerektiği durumlarda, kullanıcının hem doğru, hem yanlış girdiği durumların ikisi de, tüm fonksiyonlar için test edilmeli. • Sisteme hata mesajı verdirecek girdilerle denenmeli; • Tamponların (buffer) taşmasına sebep olacak şekilde girdilerle denenmeli; • Aynı girdi veya girdi serisini üstüste denemeli; • Geçersiz çıktılar yaratmaya çalışmalı; • İşlem sonuçlarının çok küçük veya çok büyük olmasına çalışmalı.
Test Sonlandırma Adımı • Yapılan testler sonucu bulunan hatalar düzeltildikten sonra, test hazırlık adımında hazırlanan test sonlandırma kriterleri kontrol edilir. • Tüm kriterler kabul edilebilir seviyedeyse, test aşaması sonlandırılabilir. • Ardından, uygulama müşteri testine (user acceptance test) açılır. • Değişmesi gerken yer varsa, yazılımcıya düzelttirilir ve test ekibine yollanır. • Test ekibi tarafından kontrolden geçen yazılım, ürün aşamasına geçer. Yani, yazılım geliştirme sürecinin son basamağına geçilmiş olunur.
Test Otomasyonu • Test, pahalı bir süreç. Test otomasyon araçları teste harcanan süreyi azaltmak ve toplam maliyeti kısmaya yarıyor. • JUnit, IBM Rational Functional Tester, Fit. Nesse, Selenium, soap. UI, vb. testleri otomatik olarak yapan araçlar. • Çoğu test aracı açık kaynak kodlu; çünkü her kuruma/projeye özel şekilde kullanılmaları gerekiyor.