Yaz*l*m Test Süreci

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ş 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 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, FitNesse, Selenium, soapUI, vb. testleri otomatik olarak yapan araçlar.
• Çoğu test aracı açık kaynak kodlu; çünkü her kuruma/projeye özel şekilde kullanılmaları gerekiyor.