Test Kavramı, Tanımları ve Teknikleri

TEST KAVRAMI

• Yazılım testi, ürünün hangi seviyede olduğunun belirlenmesi ile ortaya çıkan, düşük seviyede ise planlanan kaliteye ulaşmasını hedefleyen, eksikliklerin tespit edilme sürecidir. Belirli kurallar dahilinde ilerleyen bir süreçtir.
• Bu süreç ne kadar iyi yürütülürse, test de o oranda başarılı ve kaliteli olur. 
• Yazılım testi, bir ürün ya da sistemin belirli şartlarda incelenmesi ile elde edilen sonuçlardır diyebiliriz. 
• Bu belirli şartlar normal ve anormal durumlardan oluşmalıdır. Bu sebeplerden ötürü test esnasında bilinçli olarak hata yaratacak işlemler yapılmalıdır. Testin amacı, olması gereken şeylerin olması, olmaması gereken şeylerin ise olmadığını göstermektir.

Bir yazılımın sonsuz durumdaki çalışma şeklinden, sınırlı bir taslak çıkarıp, uygulama üzerinde, daha önce oluşturulmuş gereksinimlerin denenerek elde edildiği farklar ile ortaya çıkan sonuçlardan oluşur.

• Öncelikler;
• Uygulamaların çalışma şekilleri sonsuzdur. Kritizme göre durumlar sıralanmalıdır.
• Yazılım mutlaka çalıştırılarak test edilmelidir.
• Yazılım, kullanıcının beklentileri ve gereksinimleri göz önünde bulundurularak yapılmalıdır.

NEDEN TESTE İHTİYAÇ DUYARIZ?

1. Müşteriye ürün sunulmadan evvel, ürünün kalitesinden emin olmamız gerekir.
2. Yazılım hataları ne kadar erken fark edilirse o kadar zamanı ve maliyeti düşürür.
3. Müşteri memnuniyetini üst seviyede tutmak.

YAZILIM TEST METODLARI – DİNAMİK –  STATİK

• Dinamik Test: Yazılımın tamamının belirli yöntemler ile test edilmesini sağlayan metodlardır. Tüm hatalar çözüldükten ve test durdurma kriterleri sağlandıktan sonra sona erer. Test edilecek yazılımın türüne bağlı olarak uygulamasında farklılıklar yer alabilir.
• Statik Test: Statik test yalnızca program ile belli koşullar arasındaki uyumun yani verification un denetlendiği tekniklerdir. Program işlevlerinin doğru bir şekilde yerine getirilip getirilmediği ile ilgilenmez.

YAZILIM TEST METODLARI

BLACK-BOX TEST METODLARI

• Black-box testi kod ile ilgilenmez. Tamamen analizi yapılan gereksinim listesinde bulunan fonksiyonel özelliklerin denenmesi üzerine kuruludur.
• Aynı zamanda closed box, fonksiyonellik ya da opaque test olarak da isimlendirilmektedir.
• Fonksiyonelliğe uygun bir şekilde seçilen verinin program üzerinde, normal ve anormal adımlar izlenerek yapılması adımlarına bağlıdır.
• Bu test stratejisinde sistem gereksinimleri ile bunlara nasıl cevap verileceği bilinmelidir. Bu test grubu iki şekilde incelenebilmektedir. Bunu kullanıcı gereksinimi duyanlar ile duymayanlar şeklinde iki grupta incelenmektedir.
• Kullanıcı Gereksinimi Duymayan Yazılım Testi Metodları
• Fonksiyonel (Functional) Testi :  Fonksiyonel gereksinimlerin testinin yapılmasıdır. Uygulama iki türlü davranış sergileyebilir.Gerçekleşen Sonuç (Actual Result) ve Beklenen Sonuç (Expected Result) tur. Beklenen sonuç ile gerçekleşen sonuç aynı ise uygulama başarılıdır. 
• Stres Testi: Uygulamanın dayanıklılığının (robustness) test edilmesidir. Büyük verilerle, çok sayıda veriler ile uygulama test edilir.
• Duman (Smoke) Testi : Bu test biçimi uygulamanın büyük testlere hazır olup olmadığının belirlendiği ve küçük testlerin başarılı sonuçlandırıldığının bilgisinin ortaya çıktığı testtir. En temel işlemler test edilir. Versiyonlama varsa ve testten geçilemediyse eski versiyona dönüşle sonuçlanabilir. Temel şekilde çalışıyorsa sistem, daha büyük testlere geçişine yol açar.
• Yükleme Testi : Bir sistemin performansının derecelendirildiği, ağır yükler ve oldukça fazla veri ile yapılan testtir. Stres testinden farkı sistemin bir noktada çakılması beklenir ve nerde çakılacağı öğrenilmeye çalışılır.
• Kullanıcı Gereksinimi Duymayan Yazılım Testi Metodları
• Ad-Hoc Testi: Geçerli bir test yaratılmadan evvel kullanılan testtir. Diğer testlerin kapsamlarının belli olmasını sağlar.
• Araştırma Testi :  Uygulamanın öğrenilmesine ve ön bilgi elde edilmesine yardımcı olan testtir, Ad-Hoc testine benzemektedir.
• Kullanılabilirlik(Usability) Testi : Arayüzün önemli olduğu test tipidir ve amacı kullanıcı dostu bir sistem elde etmektir.
• Yenilenme Testi (Re-Test): Sistemin herhangi bir hata tespit edildiğinde eski haline dönmesinin sağlanmasının, gereksime göre tip ve yenilenmesinin hızının belli ettiği testtir.
• Seviye Testi : Sistemin uç limitlerinin test edilmesidir. Büyük veri işlemi yapılırken uygulanır.
• Kullanıcının Gerekli Olduğu Yazılım Testleri
• Kullanıcı Kabul Testi: Kullanıcının sistemi ve gereksinimlerin sistemde doğru şekilde çalıştığının incelendiği test tipidir.
• Alfa Testi :  İlk kullanıcının yaptığı testtir. Uygulama ya da sistem herkese henüz açılmamıştır. Geliştiriciler programı kullanır, program hakkında notlar tutulur ve kullanıcıya sistem aktarılır.
• Beta Testi : Kullanıcılara dağıtılan versiyondur. Test edilmesine ve uygulamanın kullanılmasına izin verilir. Herhangi bir hata bulunduğunda geliştiricilere bildirilir.
• WHITE-BOX TESTING
• Sistemin kodu baz alınarak testler yapılmaktadır. Kodun alanları, koşulları, açıklamaları baz alınır. 
• Cam, açık kutu, temiz kutu şeklinde de isimlendirilir.
• Bu kısımla uğraşan tester, sorun bulmak için kodu incelemelidir.
• WHITE-BOX TESTING AVANTAJLARI
• Kod optimizasyonuna katkıda bulunur.
• Ekstra kodlara ve ilk bakışta farkedilmeyen sorunların ortaya çıkmasına yardımcı olur.
• Hangi veri ile kodun daha iyi test edilebileceği tespit edilir.
• WHITE-BOX TESTING DEZAVANTAJLARI
• Maliyeti artırabilir.
• Kodu inceleyerek testin sonuçlanması zor bir işlemdir. Oldukça zaman alan bir işlemdir.

YAZILIM TEST METODLARI

• Birim (Unit) Testi :  Modül, çalışan bir kod parçası gibi geliştiriciler tarafından yazılan bir kısmın, doğru çalışıp çalışmadığının kontrolünün yapıldığı, düşük seviyeli bir test tipidir.
• Statik ve Dinamik Analiz: Statik analiz kodun sıralı bir şekilde incelendiği, hatalarının araştırıldığı bir test iken dinamik analiz kodun çalışmasının ve çıktının analizidir.
• Açıklama Kapsamı: Hiçbir yazılım devamlı olarak kodlanmamaktadır. Bazı alanlarda, kodun dağılımı incelenmelidir. Belirli fonksiyonların çalıştırılılmalıdır. 
• Güvenlik Testi : Sisteme izinsiz erişimlerin, kodun bozulmasının, hacklenmesi gibi olaylardan korunup korunulamayacağının testidir. Metodları oldukça karmaşıktır.
• Değişim Testi : Belirli hataların düzeltilmelerinden sonra yapılan testlerdir. Hangi kodların ve stratejilerin geliştirmede destek olunacağının belirlenmesine yardımcı olunur.

YAZILIM TEST METODLARI – ORTAK TESTLER

• Fonksiyonellik Testi : Kod ile birlikte yapılan fonksiyonel testtir.
• Birleştirme Testi : Sisteme eklenen kodlar ile birlikte yapılan testlerdir. 
• Performans ve Yükleme Testi : Sistemin kaynaklarının yönetildiği ve performanslarının verilişlerinin belirlendiği test tipidir.

Test senaryolarının Sayısını Tahmin Etme

Test Case Nedir?

• Test caseleri yani senaryoları, gereksinim listesine göre hazırlanan input, olay ya da aksiyonlar ile test yapıldığı takdirde beklenen sonuçların listelendiği dökümanlardır. 
• Yazılımın nasıl tasarlanacağının temelini oluşturan gereksinimlerin, design problemlerinin, noksanlarının da göz önüne çıkarılması hedeflenmektedir.
• Yazılım testleri bir plana sadık kalmalı ve sistematik şekillerde oluşturulmalıdır.  Kişi ve zaman bağımsız yapılabilmeli. Her bir yazılım fonksiyonu ile müşterinin her ihtiyacına ve isteğine uygun şekilde hazırlanmalıdır.
• Test Case Sayısı Tahmin Edilebilir Mi?
• Test caselerinin sayısı net olarak hesaplanamaz. Ancak, belli metodolojisi mevcuttur. Bu noktada, zaman ve maliyet eforu çok önemlidir.
• Hesaplama Metodu:
• Zaman: (uygun zaman x mevcut personel) / (bir test case i hazırlamak için ortalama süre)
• Maliyet: (Mevcut bütçe) / (Her test senaryosu için ortalama hazırlık maliyeti)
• Her iki değer için minimum seçilir.
• Örnek:

Bir projenin geliştirme bütçesi 4 milyon dolardır ve %10 u test case i hazırlamak için harcanabilir. Her test casei hazırlanabilmesi için 250 dolar ya da 4 saat maliyeti mevcuttur. Proje süresi 25 hafta, her hafta 40 saat olarak atanmıştır. 5 kişilik de test personeli mevcuttur. Kaç test senaryosu hazırlanmalıdır?

Maliyet:N1 = (4,000,000 × 0.1) / 250 = 1,600

Zaman:N2 = (25 × 40 × 5) / 4 = 1,250

Minimum olan seçilmelidir.

ÖRNEK – LOGIN İŞLEMİ

Ön Koşul:

Daha önceden başarılı bir üye kaydı yapılmış olması bekleniyor.

Gereksinimler:

Kullanıcının e mail adresini girebileceği bir textbox olmalıdır.

Kullanıcının şifresini girebileceği bir textbox olmalıdır.

Email ve şifre bilgisinin gönderilebilmesi için bir buton bulunmalıdır.

Test Senaryoları

Test Senaryoları Nasıl Belirlenir?

• Belirli işlemler için, aynı davranışın beklendiği seviyelere göre, doğrudan input değişkenlerin seviyeleri ölçülür.
• Belirlenen test durumları için doğrudan input seviyeleri bir kombinasyon ile belirtilir.
• Kombinasyon sayısı çok fazla ise ve test senaryolarının sayısından fazla çıkarsa, hepsini seçmek yerine kritik durumda olan durumlar seçilir.
• Örnek Test Case
• Bir ATM’ den para çekme işlemi için test caseleri oluşturalım. “Withdraw_amount” olsun değişkenimiz.
• Örnek Test Case (Devamı…)

Değişken Adı /Tanımı	Şartname
İsmi: Withdraw_amount Tanımı: Tek bir işlemde çekilebilecek nakit miktarı	1. 3 basamaklı sayılar kabul edilir (yalnızca para çekme 100 $ ile 1,000 $ arası nakit) 2. Numara 0 ile başlayamaz 3. En sağdaki rakam 0 (10 $, 20 $, 50 $ olmalıdır. ve sadece 100 $ faturalar) 4. 4 haneli sayılar, sadece 1000 kabul edilebilir 5. Başka herhangi bir basamak sayısı kabul edilemez

• Bu değişken için minimum durum bulunmalıdır. Ayrıca, gereksiz durumlardan kaçınılması gerekmektedir.

Test Durumları Nasıl Belirlenir?

1. Eşdeğer sınıflara dayalı test senaryosu oluşturma.
2. Sınır koşullarına göre test senaryosu oluşturma.
3. Durum geçişlerine dayanarak test senaryosu oluşturma.

Case	“Withdraw_amount”  Değişkeninin Case Değeri	Durumu(Başarılı-Başarısız)
1	i where 0≤ i ≤9	Başarısız
2	ij where 0≤ i ≤9 and 0≤ j ≤9	Başarısız
3	ijk where i =0 and 0≤ j ≤9 and 0≤ k ≤9	Başarısız(i=0)
4	ijk where 1≤ i ≤9 0≤ j ≤9 and k ≠0	Başarısız(k!=0)
5	ijk where 1≤ i ≤9 0≤ j ≤9 and k =0	Başarılı
6	ijkl where i=1 and j = k = l = 0	Başarılı
7	ijkl where 0≤ j, k, l ≤9 and i ≠1	Başarısız(i!=1)

1.Eşdeğerlik Sınıfları

Eşdeğer olan caseler aşağıdaki özelliklere sahiptir. Eşdeğer caselerden yalnızca biri koşulmalıdır.

1. Hepsi aynı işlemi test ediyordur. 
2. Bir test casei bir hatayı yakalayabiliyorsa, diğerleri de yakalayacaktır.
3. Bir test case i bug yakalayamıyorsa, diğerleri de yakalayamaz.
4. Aynı inputları içermektedirler.
5. Hepsi aynı çıktıyı gösteriyordur.

Case	“Withdraw_amount”  Değişkeninin Case Değeri	Durumu(Başarılı-Başarısız)
1	i where 0≤ i ≤9	Başarısız
2	ij where 0≤ i ≤9 and 0≤ j ≤9	Başarısız
3	ijk where i =0 and 0≤ j ≤9 and 0≤ k ≤9	Başarısız(i=0)
4	ijk where 1≤ i ≤9 0≤ j ≤9 and k ≠0	Başarısız(k!=0)
5	ijk where 1≤ i ≤9 0≤ j ≤9 and k =0	Başarılı
6	ijkl where i=1 and j = k = l = 0	Başarılı
7	ijkl where 0≤ j, k, l ≤9 and i ≠1	Başarısız(i!=1)

• Eğer, birbirini kapsayan 2 ya da daha fazla case mevcutsa kapsanan case e gerek yoktur. Kapsayan case yeterlidir. Örneğin, 2. case 1. case i kapsıyordur. 1. Case e gerek yoktur.

2.SINIR DEĞER TESTLERİ

 Bu testler değişim ve karar noktalarında, yazılımın kararlılığı üzerine yoğunlaşıldığı testlerdir. Bundan evvel eşdeğer aralıkların çıkarılması, en büyük ve en küçük değişim noktalarının tespit edilmesi gerekmektedir. 2 değerli ve 3 değerli sınır değer testleri yaklaşımları mevcuttur.

2 değerli yaklaşımda, değişim noktası ile bundan sonraki değer alınır. 3 değerli yaklaşımda ise önceki, değişim noktası ve sonraki değer alınır.

3. VISIBLE STATE Geçişleri

Etkileşimli durumlar arasında geçişi kontrol eden test tipidir.

Test Sürelerinin Tahsisi

Test süresi nasıl bölüneceği, nasıl yönetileceği gibi kısımların netleştirildiği alandır. Sistem bileşenleri, test tipleri, operasyon modları gibi birçok etken vardır.

SİSTEME GÖRE

 Tahmini risklere göre diğer sistem arayüzleri de oluşturulmak için zaman ayrılmalıdır. Bu componentlerin sertifikasyon testlerine kalan sürenin %10 undan daha azı tahsis edilmelidir. (Satın alınan bileşenler yüzde 10 undan daha az olmalı.)

Önemlerine göre bileşenler öncelik sıralamasına sokulmalıdır.

Örneğin, 340 saatlik yani 8.5 haftalık bir proje test süremiz  olsun. Sistem arayüzlerine 40saat, sistem ve yazılıma 80 saat, ilgili sistem bileşenlerine ise 220 saatlik test süreleri atanabilir.

Satın alınan bileşenlere 20 saat, geliştirilenlere ise 200 saat ayrılabilir.

TEST TİPİNE GÖRE

1. Tüm yeni test durumları önceliklidir.(İlk versiyon)
2. Kritik kabul edilen gereksinimler ve bunun doğrultusunda yapılan testler önceliklidir.
3. Test durumlarının büyük bir kısmı geliştirilen ürünün testlerine ayrılmalıdır.

OPERASYONA GÖRE

1. Yeni operasyonlar oldukça fazladır.
2. Daha seyrek ve yeni operasyonlar bundan daha azdır, kritik sayısı ise en az olan kısımdır.
3. En önceliğe kritik durum, ardından seyrek yeni durumlar, bunun arkasından da diğer yeni operasyonlar incelenmelidir.

Yazılım Test Ölçütleri Nedir?

• Yazılım test ölçütleri genel olarak süreci izlemek, süreç kalitesini artırmak ve geliştirmek için kullanılmakta olan metriklerdir. 
• Projelerin belirli alanlarında proje bütçesini hesaplanması, gelecek projeler ile ilgili maliyet tahmini yapılması, düzenlenmesi veya güncellenmesi gerekli bulunan süreç ya da teknolojilerin tespit edilmesi gibi amaçları vardır.
• Metrikler sayesinde projenin kontrolden çıkması önlenmeye ve sürekli kontrollü ilerlemenin sağlanması hedeflenmektedir.
• Test casei sayısı, koşulmayan testlerin sayıs, kaçının başarılı kaçının başarısız olduğunun sayısı, kaçının durdurulduğu, hata kayıtlarının listesi gibi verilerden oluşur.

Yazılım Test Metrikleri Nelerdir?

• Test sonlandırma işlemleri belirli metriklere bağlıdır. Bunların tümüne Exit Criteria denir. Bunlar belirli oranlara bağlıdır. Coverage yani, kapsam işletilen testlerin toplam testlere oranı anlamına gelmektedir. Bunlardan ilki Statement Coveragedır.

Statement Coverage (Durum Kapsamı)

• Bu durum kapsamı bize kodların durumların çalıştırılma oranlarını verir.

• St= Yapılmış durum casei sayısıdır.
• Sp: Toplam durum casei sayısıdır.

Branch Coverage (Branch Kapsamı)

• Branch kapsamı, her bir karar noktasındaki tüm branchlerin en az bir kez test edilebilmesine dayanır. Tüm kodların test edilmesi hedeflenmektedir.

• nbt= Test edilen kararların sayısı
• nb: Toplam kararların sayısı

• Component Coverage (Bileşen Kapsamı)
• Sistemin tüm bileşenlerine erişmeyi sağlayan test metriğidir. Bunda da oran, yapılan component testlerinin tüm bileşen testlerine oranıdır

• ncmt= Test edilen componentlerinsayısı
• ncm  =  Toplam componentlerin sayısı

GUI Coverage (Grafiksel Kullanıcı Arayüzü Kapsamı)

• Graphical user interface in bölümlerinin testleri ile ilgili kapsamdır. Arayüzde yapılan testlerin, toplam arayüz testlerine oranıdır.

• nguıt= Test edilen arayüz sayısı
• ngui  =  Toplam arayüz test sayısı

Diğer Metrikler

Path Coverage (Yol Kapsamı) : Yazılımdaki olası her yolun test edilmesine dayanır. Sayı ya da veri çok büyük olabilir. Bunun sonucunda da bütün yollar yeterince test edilmemiş olabilir.

Boundary Coverage (Sınır Kapsamı) : Her input/output değişkeni ile sınır değerleri test edilmesinin oranıdır.

Data Coverage (Veri Kapsamı) : Her veri için test edilebilme oranıdır.

TEST Başarı, Hata VE Beklemede DURUMLARI

Test Başarı Oranı (Test Pass Rate )

• Başarılı bir şekilde yürütülen test caselerinin oranıdır.Çıktı beklenti doğrultusunda üretilmiştir.

• nt pass = Geçerli-başarılı test sayısı
• ntcase: Toplam test case i sayısı

Test Hata Oranı (Test Failure Rate )

• Başarısız bir şekilde yürütülen test caselerinin oranıdır.Çıktı beklenti doğrultusunda üretilememiştir.

• nt fail = Hatalı-başarısız test sayısı
• ntcase: Toplam test case i sayısı

Beklemedeki Test Oranı (Test Pending Rate )

• Bekleme durumunda bulunan test caselerinin oranıdır. Gerçekleştirilememiş veya çıktının doğruluğunun ya da yanlışlığının belirlenemediği durumlardır.

• nt pend = Beklemede bulunan test sayısı
• ntcase: Toplam test case i sayısı

• Uygulanabilen ve açıklamaları düzgün yapılan built-in test (BIT – cihaz içi, uygulama içi test ya da dahili test ) yapılabiliyorsa test sistemi ölçülebilirdir.
• Farklı seviyelerde ve farklı aşamalarda ölçülebilirdir. Bu seviyelere design, modül, sistem gibi seviyeler örnek olarak verilebilir.
• Bağımsız Belirlenen BCS, Bağımlı Belirlenen BCS şeklinde değerlendirilebilir.
• Boolen değişkenlerinin veya ifadelerinin değerleri yalnızca BCS’yi içeren bileşenin harici inputlarına bağlıysa bağımsız, değilse bağımlı kabul edilir.

BCS İLE TEST KONTROL EDİLEBİLİRLİĞİ

• Bir bileşendeki BCS (TCBCS)’nin test kontrol edilebilirliği, BCS’ sin kontrol değişkenlerinin input verileri ile belirlenir. (Direk inputlar ile belirlenebiliyorsa bağımsızdır, BCS bağımsız olarak belirlenebilir ise TCBCS = 1, değilse 0 dır)

Bir Bileşenin Test Kontrol Edilebilirliği

• Bir bileşenin test kontrol edilebilirliği (TC), BCS’lerinin TCBCS’sinin matematiksel ortalamasıdır.
• TC = 1 ise componentin test edilebilirliğinin tamamen kontrol edilebilir olduğu manasına gelir.

Örnekler:

KAYNAKLAR:

1. http://www.yazilimtest.com/yazilim-test-nedir-neden-gereklidir/
2. http://www.orhanyener.net/yazilim-testi-2/yazilim-test-teknikleri/
3. https://www.iztim.com/Blog/YazilimTeknolojisi/YAZILIM-METODOLOJI
4. http://blog.solvepark.com/makale/yazilim-test-metodlari
5. https://www.akademi.net/blog/test-case-nedir–ideal-test-case-nasl-yazlr–355
6. https://www.linkedin.com/pulse/test-senaryolar%C4%B1-durumlar%C4%B1-ve-ad%C4%B1mlar%C4%B1-hakk%C4%B1nda-her-%C5%9Fey-kavakl%C4%B1o%C4%9Flu
7. https://people.ucalgary.ca/~far/Lectures/SENG421/PDF/SENG421-10.pdf
8. http://www.testrisk.com/2012/04/test-tasarm-kategorileri.html
9. https://www.slideshare.net/MesutGne/test-mhendisliine-giri-eitimi-blm-2
10. http://ceur-ws.org/Vol-1721/UYMS-YTM_2016_paper_9.pdf
11. https://yazilimcorbasi.blogspot.com/2014/06/built-in-test-bit-yontemleri.html
12. https://www.freepik.com/