YZM 320 - Yazılım Doğrulama ve Geçerlileme

1. YZM 320 - Yazılım Doğrulama ve Geçerlileme Hazırlayan:Emin BORANDAĞ

2. 5.Bölüm Black Box Testting

3. Dinamik Black box Testi • Dinamik Kara kutu testi • Dinamik çünkü program çalıştırılırken yapılıyor. • Kara kutu çünkü kod ile ilgili hiçbir bilgi bilinmeden gerçekleştiriliyor. • Bu test davranış testi olarakta bilinmektedir. • Test için gerekenler • Çalışan bir program ve tanımlamalar( Kullanıcı klavuzu) • Belirlenmiş test durumları( Giriş ve değer testleri gibi)

4. Test Datası ve Test Durumları • Test Datası:Sistem için belirlenmiş ve seçilmiş olan veriler. • Test Case(Durum): Belirlenmiş test senaryolarını kullanarak yazılımları çalıştırmak. Elde edilen verilere bakılarak durumları değerlendirmek.

5. Test to Pass & Test to Fail • Tamamlanan Test: Yazılımın belirlenen test senaryolarında başarılı olduğunu gösteren durum. • Programın temel anlamda çalıştığından emin olmak. • Kapasitesini zorlamamak • Yapısını kolay ve yapıyı çok zorlamayan test durumları ile test etmek. • Programı çökertmeye çalışmamak. • Tamamlanamayan Test: • Yazılımın çalışmasını bozmak için daha komplike test durumları oluşturmak. • Yazılımın güçsüz olduğu noktaları seçmek ve buralara saldırmak.

6. Tartışma • Neden yazılımcı teste test to pass ile başlar? • Zaman kaybı değil mi? • Tess To pass’ın bize ne kazandırır? • Yazılım test uzmanı tess to pass yapmalımı?

7. Kara Kutu Testi • Kara kutu testinin karakteristiği • Test Planı erkenden olmalı. • Program bir kara kutu gibi ele alınmalı. • Uygulamanın detayları sorun olmamalı. • İsterler son kullanıcı düşünülerek yapılmalı. • Kriterler kesin olamaz.

9. Denklik Bölümlendirme • Denklik Bölümlerdirme: Program içerisine girilen değerler ile çıkış değerlerinin karşılaştırılmasına denir.

10. Arama rutin özellikler procedure Search (Key : INTEGER ; T: array 1..N of INTEGER; Found : BOOLEAN; L:1..N) ; Ön Koşul -- En azından bir değere sahip olmalı 1 <= N Sonraki durum -- ( Found and T (L) = Key) Yada -- Eğer değer eşleşmiyorsa ( not Found and not (exists i, 1 >= i >= N, T (i) = Key ))

11. Arama rutin özellikler • Girişleri olan ön koşullar uygundur.Giriş Burada bir ön koşul tutmaz.Girişleri nerede kilit unsur dizinin üyesidir.Girişleri kilit unsur dizinin bir üyesi değildir nerede.

13. Search rutine Test Senaryoları

14. Veri Testi • Eğer bir programı bir fonksiyon gibi düşünüyorsanız, Programın girişi onun etki alanıdır. • Veri giriş örnekleri • Word belgeleri • Excele girilen veriler • Resim dosyaları

15. Sınır Giriş verileri. • Sınır koşulları yazılımın planlı çalışma limitlerini kenarında durumlardır. • Örnek: negatif sayılar, giriş alanı uzunluğu aşan, pozitif sayılar. • Sınır değerlerine sahip olan veri datalarını seç(Eşitlik üstlük değerlerini de kullan) • Geçerli test verisi sınır değerlerini içersin. • Son geçerli değerler ile test et. • Sınır değerlerinin üzerinde olan veriler ile test işlemini gerçekleştir. • Buffer overflow saldırıları gibi güvenlik açıklarına karşı dizi tampon sınırları yararlanabilir.

16. Veri Test Örnek (Syntax Testing) • Sistem veri girişleri tekrardan onaylanmalıdır. Dahili ve harici girişler ve formatları ile uyumlu hale getirilmelidir. • Kullanıcıların veri giriş metin biçimi. • Dosya formatları. • Veritabanı şemaları. • Data biçimleri kolay bir şekilde test programları vasıtası ile dönüştürülerek veri testleri yapılabilir.

17. Garbage-In Garbage-Out • “Garbage-In = Garbage-Out” yazılım testler içerisinde kullanılan bir terimdir. • Bize yazılımın başarısız olduğundan başka bir ifadesi yoktur. • İyi kurulum doğru geçerlileme • Kötü veri için sistem toleransı • Sistemlerin ara yüzleri ve özelliklerinin sağlam olması gerektiğinden. Doğru ve etkili veri girişi ve doğrulama kontrolleri olmalıdır.

18. Milyon Maymun Fenomeni • “A million monkeys sit at a million typewriters for a million years and eventually one of them will type Hamlet!” • “Giriş onaylama düşmanca bir dünyaya karşı ilk savunma hattıdır.”

19. Giriş-Tolerans Testi • Iyi bir kullanıcı arayüzü tasarımcıları çöp kabul etmez. Bu onların sistem tasarımı diğerlerinden ayırır. • İyi bir test farklı çöp değerleri ile yapılan testtir. • Giriş-tolerans testi genellikle sistem testleri bir parçasıdır ve genellikle bağımsız test ile birlikte yapılır.

20. Syntax Testtinin Adımları • Hedef dilini ve formatını tanımla. • Test ve Debug işlemini gerçekleştir. • Normal koşullarda mimimum gereksinimler ile. Temel testleri gerçekleştir. • Geçersiz verilere karşı sistemi test ed. "çöp" koşullar. (yüksek sonuç)

21. Otomasyonu gerekli • Syntax testinin otomatik olarak yapılması gerekmektedir. • Syntax (Söz dizimi) nasıl bulunur? • Her bir veri girişi kendine özgü bir söz dizimine sahiptir. • Yapı içerisinde • Resmen belirlenmiş • Belgesiz • Sadece anladım • Şartnameye test etmek için yaralı çöp değerlerine ihtiyaç duyula bilir.(Farklı değerlerle düzgün bir söz dizilimi yapılıyor mu sorusunu cevaplamak için)

22. Söz dizilim yapıları ve BNF • | = “or”. • * = “zero or more occurrences”. • + = “one or more occurrences”. • means “n repetitions of A”.

23. Söz dizilim yapıları ve BNF special_digit ::= 0 | 1 | 2 | 5 other_digit ::= 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ordinary_digit ::= special_digit | other_digit exchange_part ::= ordinary_digit phone_number ::= exchange_part number_part • Doğru bir telefon numarası: • 4566654, 9904567, 3300000 • Yanlış bir telefon numarası: • 0551212, 123, 8, ABCDEFG

24. Neden BNF • BNF şartname kullanma biçimi için doğru bir yapı sağlar. Tasarım testi için kolay bir yoldur. • Tasarımcıların işlerini kolaylaştır an doğru bir yoldur. • Burada doğru veriler ile yanlış verilerin ayrımı yapılana kadar tasarım başlatılmamalıdır.

25. Test Case Üretimi • Yanlış eylemlerin olası üç türü vardır: • Tanımlama iyi bir dizilimde yapılmamış. • Tanıma kötü bir dizilimde olsa da program tarafından kabul edilmiş. • Tanıma sırasında dizi tanımaları oluşturulmamış. • Gerektiği yerde gerektiği kadar test case üretilmelidir. • Tüm veriler için kullanmaya zaman ve kaynak yoktur.

26. Test Strateji • Girdi dizesinin tüm diğer bileşenleri doğru tutarak, her seferinde bir hata oluşturun. • Testleri komple bir set olarak belirleyin bu işlemin ardından. İkili üçlü hata setleri ile 1. adımdaki aşamayı tekrarlayın... • Her seferinde bir düzeye odaklanın bu odak seviyesini başlangıçta düşük tutarak adım adım yükseltin.

27. Örnek1 Telefon numarası • phone_number ::= exchange_part number_part • Boş değer atama • İlk kısmını değiştirme. • İkinci kısmı değiştirme. • İki kısmı birden değiştirme. • Önce birinci kısmı değiştirme ardımdan ikinci kısmı değiştirme. • Önce ikinci kısmı değiştirme ardından birinci kısmı değiştirme. • …

28. Örnek1 Telefon numarası • Yetersiz karakter girilmesi • Çok fazla karakter girilmesi. • Sayısal olmayan karakter girilmesi. • Kontrol karakterlerinin girilmesi. • Özel karakterler girilmesi. • other_digit ::= 2 | 3 | 4 | 5 6 | 7 | 8 | 9 • special_digit ::= 0| 1 | 2 | 5

29. Sınırlayıcı Hatalar • Sınırlayıcı karakterler bir karakter bittikten sonra diğer karakter arasında kullanılan karakterdir. • Eksik. örnek., (x+y • Yanlış. örnek., (x+y] • Fazla. örnek., (x+y))

30. Söz dizilimi kaynağı • Tasarımcı Test İşbirliği • Kılavuzlar • Ekranlar • Tasarım Belgeler • Prototip • Programcı Röportajlar • Hacking

31. Sözdizimi Test Tasarım Tehlikeleri • Program dizannının nasıl olacağını bilmek sizin gereksiz “case” ler ile ilgilenmenizi ortadan kaldıracaktır. • Yapısal testti göz ardı etmeyin. Sözdizimi testtini yapı içerisinde gerçekleştirin. • Yapısal test ile söz dizim testtini birbirine karıştırmak kolaydır dikkat etmek gerekir.

32. Sözdizimi Test Sürücüleri • Test caseler genellikte bir data olarak saklanır. Bunun için bir program kullanılabilir. • Gereksiz verilerin olduğu “çöp” datalardan oluşan bilgileri bu hazırladığınız test caseleri içerisine almayın.

33. Tasarım Otomasyonu: İlkel Yöntem • Doğru bir giriş dizeleri kümesi kapsayan belirtmek , için bir kelime işlemci kullanın. • Arama değiştirme alt string değerlerini kullanın.

34. Tasarım Otomasyonu: Rastgele StringÜreteçleri • Rasgele string içeren diziler ile programa değer vererek programın çalışma durumu değerlendirin. • ( Kaba güç ile programı zorlama)

35. Verimlilik, Eğitim, Etkililik • Sözdizimi testiprogramları kullanan kişiler için büyük bir güven kaynağı verir. • Yazılım ekibi içersinde yeni başlayan  stajyerlere verilen kolayca bir eğitimi sonrası gerçekleştirile bilir. • Busayede stajer saatte 20-30 test durumları üretebilir. • Sözdizimi test acemi bir tester için inandırıcı mükemmel bir yoldur: • Bu sayede testtin sonsuz bir süreç olduğunu. • Hangi testlerin önce yapılması gerektiğini bilir.

36. Ad-lib testleri • Ad-lib test ler doğaçlama olarak yapılan rast gele sayılar ile programın test edilmesini sağlar. • Ad-lib testleri tam olarak sistem ile ilgili bir şey ispat edemesede. Genel anlamda kullanılabilrilike ile ilgili yapılan testlerdir.

37. Özet • Veri girişleri sistem için çok önemli noktalardır. • Güvenlik ve sistemin doğru çalışması açısından. • Dış dünyadaki veriler ,belli bir formata göre sistem içerisine alınmalıdırlar. • Çöp olarak belirlenen verilerin sistem içerisine alınmaması için anlık kontroller yapılmalıdır. • Hata kontlerleri sistemin en alt noktasından başlatılmalı ve her seferinde tek bir hata oluşturularak kontrol edilmesi gerekmektedir. Sonrasında ise hata sayıları arttırırlarak test işlermleri gerçekleştirilmelidir.

38. Özet-2 • Onaylama testleri söz dizimini kapsayıcı şekilde olamlıdır. • Uç değerler ve sınır değerler test edilmesine öncelik verilmelidir.(Sınırlayıcıları düşünün.) • Otomatik test programları çalıştırılarak testler yapılmalıdır. • Anlık yapılan Ad-lib testleri ile sistemin durumu incelenebilir. • Değer üreteçleri ile programa değerler verilerek programın düzün olarak çalışıp çalışmadığına bakılmalıdır.

39. Son kısımda bakılan konular • … test-to-pass test-to-fail testleri • … black-box test • … sınır değerleri • … Veri testti(Doğru verinin ne şekilde alınacağı)

40. Etc • 10.1.1.82 www.hurriyet.com.tr # deneme