Yazılım test sunumu by bilisim calisanlari

Yazılım Test Eğitimi

İçindekiler 1. 2. 3. 4. 5.

Yazılım Testine Giriş Testin Temelleri Test Seviyeleri Statik Testler Sürekli Entegrasyon

1. Yazılım Testine Giriş Test Tarihçesi • 1947 - Thomas Alve Edison - İlk bug kavramı

• 1979 - Glenford J. Meyer - Yazılım Test Mimarisinin İnşaası

• 1983 - IEEE 829 -Testle İlgili 8 aşamadan oluşan standartların ilk versiyonu yayınlandı

• 1989 - Mercury Interactive - Test Otomasyonlarının piyasaya çıkı

• 2002 - ISTQB Kuruluşu - The International Software Testing Qualifications Board

• 2006 - TTB - Turkish Testing Board

1. Yazılım Testine Giriş • Türkiye’de Test • Dünyada Test

2. Testin Temelleri • • • •

Test Neden Gerekli? Test Nedir? 7 Test Prensibi Temel Test Süreçleri

2.1. Test Neden Gerekli?

2.1. Test Neden Gerekli? • • • • • • • • •

Yazılımdan istenilenler yerinde ve yapılmış mı? Yazılım istenilen işlevleri yerine getiriyor mu? Yazılım işlevleri yaparken hata veriyor mu? Yazılım istenilen hızda yapıyor mu? Yazılım istenilen kadar işlev yapabiliyor mu? Yazılım istenilen işlevleri en çok ne kadar yapıyor? Yazılım istenilenleri kolay yapıyor mu? Yazılım istenilen işlevleri güvenli yapıyor mu? Yazılım işlevleri herzaman yapabiliyor mu?

2.1 Test Neden Gerekli? • Bug Nedir? Error Fault, Defect, Bug Failure

2.1 Test Neden Gerekli?

2.1. Test Neden Gerekli? • Büyük Yazılım Hataları Ariane 5: 7 Milyon Dolar Mariane spavce probe to Venus: 250 Milyon Dolar Hartford Coliseum Collapse: 90 Milyon Dolar

2.2. Test Nedir? • • • •

Deneme ve yanılma değildir. Elle tutulur bilgi üzerine icra edilir. Test için gereksinim olmalıdır. Test faaliyetleri özel bir bakış açısına saip yazılım mühendisleri tarafından yapılır.

2.2. Test Nedir? • Temel Kavramlar Code Debuging Development of software Reqirement Review Test basis Test cases Test objective

2.2. Test Nedir? • Neler Test Edilir? – Fonksiyonel Testler • Onaylama (Verification)  Yazılım istenilen işlevi yerine getiriyor mu?  Analiz çalışmalarının gereksinimlerine uygun mu?

• Sağlama (Validation)  Yazılımdan istenilenler yerinde istekler mi?  Kulanıcılar açısından bu istekler uygun mu?

2.2. Test Nedir? • Neler Test Edilir? – Fonksiyonel Olmayan Testler Test Otomasyonu Performans Testleri Uyumluluk Testleri Güvenlik Testleri Kullanılabilirlik Testleri

2.3. Yedi Test Prensibi • 7 Test Prensibi Test hataları gösterir. Biz uygulamayı %100 test etmek imkansızdır. Teste yazılım geliştirme sürecinin başından başlamak gerekir. Hatalar genellikle yazılımın belli alanlarında yoğunlaşır. Testimizi gerçekleştirirken, farklı teknikler kullanmazsak, tek düze bakarız ve belki de önemli konuları atlayabiliriz. Testler proje içeriğine göre değişiklik gösterir. Test hiçbir zaman bitmez.

2.4. Temel Test Süreçleri • Temel Kavramlar Conformance Testing Exit Criteria Incident Regression Testing Test Contition Test Date Test Log Test Summary Repor Testware Test Plan

2.4. Temel Test Süreçleri

2.4. Temel Test Süreçleri • Aşamalar Planlama ve Kontrol Analiz ve Dizayn Uygulama ve çalıştırma Test bitiş kriterlerini sağlama ve raporlama Test bitiş faaliyetleri

2.4.1 Planlama ve Kontrol • • • • • •

Testin kapsamını ve riskini belirlemek. Test yaklaşımı kararlaştırılır. Hangi metodlarla test edileceği belirlenir. Gereksinimleri ve ihtiyaçlar belirlenir. Testin zaman planlamasını yapılır. Çıkış kriterleri ve kapsama hedefleri belirlenir

2.4.2 Analiz ve Dizayn • • • • •

Testin temeli(kaynağı) incelenir. Test şartlarını belirlenir. Testi ağacı çıkarılır. Test senaryoları hazırlanır. Sistemlerin ve gereksinimlerin test edilebilirliği değerlendirilir. • Test ortamı kurulur. • Yardımcı araçlar hazırlanır. • Developer ve Danışmanla etki analizi çıkarılır.

2.4.2 Analiz ve Dizayn • Test Suite&Case Nasıl Hazırlamalı  Benzer Test Caseler, Test Suite’ler altında gruplanmalı  Test Case başlığı anlaşılır ve düzgün olmalı  Test Case’nin başlangıç koşulları ve öncesinde gerekli olan test adımları belirtilmelidir.  Test Case adımları step step girilmelidir.  Test Çıkış kriteri, beklenen sonuç yazılmalıdır.  Alternatif test senaryoları olmalıdır.  Test Case koşturulduğu zaman statüleri workflow’a uygun girilmedir.

2.4.2. Analiz ve Dizayn • Hata Senaryoları Hazırlama No Input Invalid

2.4.2. Analiz ve Dizayn

2.4.2. Analiz ve Dizayn • Test Ortamları ve Hazırlanması WRK Dev QA Strange Production

2.4.3. Uygulama Ve Çalıştırma(Execution) • • • • • • • •

Testler için data oluşturulur. Testi otomatize etmek için test scriptleri de yazılabilir. Test ortamını doğrulanıp ve hayata geçirilir. Test prosedürleri ve senaryolar izleyerek test gerçekleştirilir. Hata bulunan alanlar fixlenme sonrası tekrar test edilir. Versiyona göre olaylar raporlanır. Çıkan ve beklenen sonuçlar karşılaştırılır. Bulgular bildirilir.

2.4.3. Uygulama Ve Çalıştırma(Execution) • Test Datası Oluşturma Temiz data olmalı Hatalı veya mevcut data kullanımından kaynaklı hatalı test ihtimali yüksek Black box test metodunda ki teknikler esas alınarak datalar hazırlanıp gruplanabilir Çoklu data için script hazırlanabilir

2.4.3. Uygulama Ve Çalıştırma(Execution) • Hata Bildirimi  Hata assign edilirken basit ve anlaşılır bir dil kullanılmalı.  Hata adımına kadar tüm stepler ve kullanılan veriler belirtilmelidir.  Hata’nın oluşma zamanı, ortam bilgileri(İşletim Sistemi, Versiyon, Browser) bildirilmelidir.  Ekran görüntüleri iletilmelidir.  Hata takip edilmelidir.  Müşteriden gelen bir hata bildirilmeden önce kendi localinde test edilmelidir.  Hata bildiriminde statüler workflow’a göre girilmelidir.  Hata kapatıldıktan sonra hata sebebi girilmelidir.

2.4.3. Uygulama Ve Çalıştırma(Execution) • Bulgu bulmada başarı için 5 ipucu Developer’a, analize bağımlı kalma! Geçmiş örnekleri incele! Bulguları dize getir! Oluşabilecek bulgular hakkındaki sezilerine önem ver! Farklı kişiyle gözden geçir!

2.4.3. Uygulama Ve Çalıştırma(Execution)

2.4.3. Uygulama Ve Çalıştırma(Execution) • Hata Sebepleri Algoritma Hatası Ortam Hatası Hatalı Data Kullanımı Analiz Tasarım Kodlama …

2.4.4. Test Bitiş Kriterlerini Sağlama ve Raporlama • Maksimum oranda case, yüksek başarı oranı ile test edildiğinde. • Bulgu oranı çok düşük olduğunda. • Projede sona yaklaştıkça.

2.4.5. Test Kapanış Faaliyetleri • Test planına göre test edilmesi gereken yerler test edildiyse. • Proje iptal olduysa. • Test hedefleri tutturulduysa. • Yazılımda güncelleme yada bakım çalışması olacaksa.

2.4.5. Test Kapanış Faaliyetlerinin Amacı • Ürünün planlandığı gibi teslim edilip edilmediğini kontrol edip , raporlamak. • Yaptığımız testten kazandığımız deneyimleri, test datalarını, test scriptlerini saklamak , dokümante etmek ve sonraki testlerde kullanmak. • Test sonrasında yaptığımız işi değerlendirmek.

3. Geliştirme Boyunca Test • Test Seviyesi • Test Türleri • Test Teknikleri

3.1. Test Seviyesi • • • •

Birim Test Entegrasyon Testi Sistem Testi Kabul Testleri

3.1.1. Birim Testi

3.1.1. Birim Testi • Unit Test • Kod Seviyesine İnilir • Programcılar Yapar

3.1.1. Birim Testi • • • •

TDD Nedir? BDD Nedir Mxunit Nedir? Code Coverage

3.1.1. Birim Testi • TDD Nedir? Yazılımı test etmekten ziyade onu geliştirirken kullanılan yöntemidir. Önce test sonra testi geçecek kod yazılır. Testleri kim yazacak?

3.1.1. Birim Testi • TDD Adımları Tek satır kod yazmadan kodun testini yaz. Testi çalıştır ve testin geçemediğini (kırmızı çubuğu) gör. Testi geçecek en basit kodu yaz. Tüm testlerin geçtiğini gör. Kodu düzenle (Refactoring) Tekrar başa dön.

TDD Örnek

3.1.1. Birim Testi • Unit Kod İçin Sık Kullanılan Annotationlar  @Test  @Test(expected = Exception.class) :  @Test (timeout = 100) :  @Before  @After  @BeforeClass  @AfterClass  @Ignore

3.1.1. Birim Testi •        

Unit Kod için kullanılan metodlar assertTrue(true); assertsEquals(message, expected, actual) assertsEquals(message, expected, actual, tolerance) assertNull(message, object) assertNotNull(message, object) assertSame(message, expected, actual) assertNotSame(message, expected, actual) assertTrue(message, boolean condition)

          

assertXPath(xpath,data,text,message) assertIsTypeOf(obj,type) assertIsXMLDoc(obj) assertIsArray(obj) assertIsStruct(obj) assertIsQuery(obj) assertIsDefined(obj) assertIsEmpty(obj) assertIsEmptyArray(obj) assertIsEmptyQuery(obj) assertIsEmptyStruct(obj)

3.1.1. Birim Testi Unit Test İçin Mock Nesneler

3.1.1. Birim Testi • BDD Nedir? Senaryoyu test eden kodlar yazılır. Syntax'i konuşma dilidir. Yalın uygulama geliştirme esastır. TDD olmadan BDD olmaz.

BDD Ă&#x2013;rnek /** * This tests the BDD functionality in TestBox. This is CF10+, Railo4+ */ component extends="testbox.system.testing.BaseSpec"{ /*********************************** LIFE CYCLE Methods ***********************************/ function beforeAll(){ print( "<h1>BDD Testing is Awesome!</h1>" ); console( "Executed beforeAll() at #now()# " ); application.salvador = 1; } function afterAll(){ console( "Executed afterAll() at #now()#" ); structClear( application ); } /*********************************** BDD SUITES ***********************************/ function run(){ /** * describe() starts a suite group of spec tests. * Arguments: * @title The title of the suite, Usually how you want to name the desired behavior * @body A closure that will resemble the tests to execute. * @labels The list or array of labels this suite group belongs to * @asyncAll If you want to parallelize the execution of the defined specs in this suite group. * @skip A flag that tells TestBox to skip this suite group from testing if true */ describe( "A spec", function(){ // before each spec in THIS suite group beforeEach(function(){ coldbox = 0; coldbox++; debug( "beforeEach suite: coldbox = #coldbox#" ); });

3.1.1. Birim Testi Code Coverage Nedir?

3.1.2. Entegrasyon Testi • Farklı Sistemlerle Bağlantılar  İşletim Sistemleri  Dosyalama Sistemleri  Arayüzler

• İki seviyede entegrasyon olailir  Birim Entegrasyon  Sistem Entegrasyon

• Entegrasyon Test Stratejileri  Big-bang  Aşağıdan Yukarıya  Yukarıdan Aşağıya

3.1.2. Entegrasyon Testi • Aşağıdan Yukarıya Entegrasyon • Yukarıdan Aşağıya Entegrasyon • Big Bang Workcube Hangisine Daha Çok Benziyor?

3.1.2. Entegrasyon Testi • Web Servis Testleri – SoapUI

3.1.3. Sistem Testi • Tüm sistem göz önüne alınır Gereksinimler İş süreçleri Use-Caseler

• Son aşamada yapılır Genelde test uzmanları, 3rd party firmalar yapar Herşey test edilir, yazılı olmayan kısımlar olabilir

• Fonksiyonel + Fonksiyonel olmayan özellikler

3.1.4. Kabul Testleri • Kullanıcı Kabul Testleri • Operasyonel Kabul Testleri • Uyumluluk Testleri – Kanunlara Uyumluluk – Tarayıcı Uyumluluk

• Alfa Testi • Beta Testi

3.2. Test Türleri • Fonksiyonel Testler – Black-box • Gereksinim temelli testler • İş- süreç temelli testler

• Fonksiyonel Olmayan Testler – – – – – –

Performance, stress, load Usability Maintainability Portability Security Compatibilitiy

• Yapısal Testler (Structural Testing) –

White-box

• Regresyon Testleri

3.2.2. Fonksiyonel Olmayan Testler Performance, Stress, Load

3.2.2. Fonksiyonel Olmayan Testler Usability

3.2.2. Fonksiyonel Olmayan Testler Performance, stress, load Usability Maintainability Portability Security Compatibilitiy

3.2.3 Yapısal Testler • Yapı Mimari test edilir. • White-box ağırlıklıdır.

3.2.4 RegressionTestler • • • • • • •

Değişikliğe bağlı testlerdir. Onaylama testleridir. Re-test. İlgili bölümler test edilir. Genel testlerdir. Sistemde oluşabilecek yan etkiler saptanır Otomasyona uygundur Yazılımda her güncelleme sonrası yapılmalıdır.

3.3. Test Teknikleri

3.3.1. Statik Test Teknikleri

3.3.1. Statik Test Teknikleri Statik Test Ad覺mlar覺

3.3.1. Statik Test Teknikleri

3.3.2 Dinamik Testler • Black Box Testing • Gray Box Testing • White Box Testing

Test Tipleri Aras覺nda ki Farklar

3.3.2 Dinamik Testler Black-box Test Metodlar覺

3.3.2 Dinamik Testler

3.3.2 Dinamik Testler • Black-box Test Metodları Equivalence Partitioning(Denklik Sınıfı) Boundary Value Analysis(Uç Değer Analizi) State Transition Tables Decision Table Testing(Karar Tablosu) Use Case Testing Exploratory Testing(Araştırmacı Test)

Equivalence Partitioning Test dokümanlarında belirlenmiş test koşullarını gruplarız. Aynı sınıf denkliği içerisinde bulunan test koşullarını aynı yöntemleri uygulayarak test ederiz. İf age > 17 print ‘yetişkin’ İf age > 5 print ‘çocuk’ else print ‘bebek’

Boundary Value Analysis Uç noktalar arasındaki her durumda da testlerin geçerli olduğu öngörülür. İf age > 17 print ‘yetişkin’ İf age > 5 print ‘çocuk’ else print ‘bebek’

State Transition Tables Bu teknik kullanılarak her bir geçerli durum geçişi belirlenir ve geçişler test edilir.

Decision Table Testing Test koşullarının oluşturabileceği kombinasyoları belirler ve bu kombinasyoları test ederiz

Use Case Testing Kullanım senaryolarını belirleyerek, bu senaryolardaki sırayı bozmadan yapılan test tekniğidir

Exploratory Testing

3.3.2 Dinamik Testler • Gray Box Testing Nedir ? Black box ve White Box tek başına yeterli değil Diğer test tekniklerinin dezavantajlarını ortadan kaldırır. Yazılımın temel dinamikleri bilinmeli Girdi ve Çıktılarla kod parçası kontrol edilir.

3.3.2 Dinamik Testler White Box Testing Nedir ?

3.3.2 Dinamik Testler • White Box Test Tekniği Nerede Kullanılır? Geliştirici Birim Birim Entegrasyon

Code Coverage

5. S端rekli Entegrasyon

5. Sürekli Entegrasyon • Sürekli Entegrasyon Bileşenleri Selenium / Otomasyon ANT Jenkins Git MXUnit

5. S端rekli Entegrasyon

5.1. Otomasyon • Otomasyon Nedir? • Neden Test Otomayonu? • Test Otomasyonu Avantajları?

5.1. Otomasyon • Otomasyon Araçları Selenium IDE Selenium RC Selenium Web Driver Selenim Grid

Selenium Yap覺s覺

5.1.1 Selenium IDE • Selenium IDE Firefox için geliştirilmiş bir eklentidir. • Selenium Web tabanlı uygulamaların testlerini browser/tarayıcı üzerinden yapmamızı sağlayan bir araçtır. • Tüm web testlerinin yapılabileceği açık kaynak kodlu bir test aracıdır (Veri tabanı bağlantısı ile yapılabilecek testler hariç). • Diğer test araçlarına göre daha fazla gelişmiştir.

5.1.2 Selenium RC • Server ve yazılım dilleri için Client Driver 'lar içermektedir. • Hem Server olarak hem de Client olarak aynı dizin yapısı kullanılabilir • Selenium Remote Control (RC), Java ile yazılmış bir .jar paketidir ve her türlü işletim sisteminde çalışabilir