Yazılım Testi
Yazılım testi, hataları tespit etmek ve yazılımın amaçlandığı gibi davrandığına dair güven kazanmak amacıyla seçilmiş girdilerle bir programın dinamik olarak yürütülmesidir.
Tanım
Yazılım testi, gerçek ve gereksinim duyulan davranış arasındaki tutarsızlıkları ortaya çıkarmak ve yazılım güvenilirliğini tahmin etmek amacıyla, beklenen sonuçlarla eşleştirilmiş girdiler olan test senaryolarını tasarlama ve yürütme etkinliğidir.
Kapsam
Bu konu, test seviyelerini (birim, entegrasyon, sistem, kabul); eşdeğerlik bölümleme, sınır değer analizi ve kombinatoryal test gibi kara kutu tekniklerini; kod kapsamı kriterleri tarafından yönlendirilen beyaz kutu tekniklerini; regresyon, performans ve keşifsel testi; test otomasyonunu; ve test yeterliliği ve kapsamı kuramını kapsamaktadır.
Temel sorular
- Baş edilemez büyüklükteki bir girdi uzayından etkili test senaryoları nasıl seçilir?
- Bir test paketinin yeterliliğini hangi kapsam kriterleri ölçer?
- Birimden kabule kadar olan test seviyeleri birbirini nasıl tamamlar?
- Test nasıl otomatikleştirilebilir ve teslimat hattına entegre edilebilir?
Temel kuramlar
- Kara kutu ve beyaz kutu test tasarımı
- Kara kutu teknikleri, bölümleme ve sınır analizi yoluyla belirtimden testler türetirken, beyaz kutu teknikleri kapsam kriterleri tarafından yönlendirilen kod yapısından testler türetir; bu iki yaklaşım birbirini tamamlamaktadır.
- Kapsam ve test yeterliliği kriterleri
- İfade, dal ve koşul kapsamı gibi yeterlilik kriterleri ve kontrol- ve veri-akış grafikleri üzerindeki model tabanlı kriterler, bir test paketinin bir programı ne kadar kapsamlı bir şekilde çalıştırdığına dair ölçülebilir hedefler sunmaktadır.
Klinik önem
Test, yazılımın piyasaya sürülmeden önce doğru çalıştığından emin olmak için en yaygın uygulanan yöntemdir; iyi tasarlanmış otomatik testler regresyonları erken yakalar, yeniden düzenlemeyi (refactoring) ve sürekli teslimatı destekler ve güvenilir yazılım için merkezi öneme sahiptir.
Kanıt ve kılavuzlar
ISO/IEC/IEEE 29119, yazılım testi süreçleri, dokümantasyonu ve teknikleri için uluslararası standartlar sağlamaktadır ve SWEBOK Yazılım Testi bilgi alanı uzlaşmaya dayalı bir genel bakış sunmaktadır.
Tarihçe
Test, 1979'da Myers'ın sistematik yaklaşımıyla rastgele hata ayıklamadan bir disipline dönüşmüştür; sonraki on yıllar boyunca kapsam kuramı, model tabanlı test ve test otomasyonu gelişmiştir ve test güdümlü geliştirme ile sürekli entegrasyon, otomatik testi temel bir çevik uygulama haline getirmiştir.
Tartışmalar
- Ne kadar otomatik testin değerli olduğu
- Birim, entegrasyon ve uçtan uca otomatik testler arasındaki doğru denge tartışılmaktadır; test piramidi, yavaş uçtan uca testlere kıyasla birçok hızlı birim testini tercih eder, ancak eleştirmenler bu dengenin sistem tipine ve riske bağlı olduğunu belirtmektedir.
Öne çıkan isimler
- Glenford Myers
- Paul Ammann
- Jeff Offutt
- Boris Beizer
İlgili konular
Temel eserler
- myers2011
- ammann2016
- swebok2014
Sıkça sorulan sorular
- Neden her olası girdiyi test edemiyoruz?
- Çoğu program için olası girdilerin ve yürütme yollarının alanı astronomik derecede büyük veya sonsuzdur, bu nedenle kapsamlı test mümkün değildir; bunun yerine test, test başına hata tespitini en üst düzeye çıkarmak için sistematik teknikler kullanarak temsilci ve sınır durumları seçer.
- Test seviyeleri arasındaki fark nedir?
- Birim testi, bireysel bileşenleri izole bir şekilde çalıştırır; entegrasyon testi bunların etkileşimlerini kontrol eder; sistem testi, tüm sistemi gereksinimlerine göre değerlendirir; ve kabul testi, kullanıcı ihtiyaçlarını karşıladığını doğrular; her seviye farklı türde hataları hedefler.