YZM311 YAZILIM YAPIMI BÖLÜM 6 YAPIM TESTİ VE KALİTESİ. Yrd. Doç. Dr. Volkan TUNALI Mühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

Transkript

1 YZM311 YAZILIM YAPIMI BÖLÜM 6 YAPIM TESTİ VE KALİTESİ Yrd. Doç. Dr. Volkan TUNALI Mühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

2 Genel Bakış 2 Giriş Yazılım Testinin Türleri Geliştirici Testleri Kod Kapsama (Code Coverage) Birim Testi Altyapıları (Unit Testing Frameworks) Hata Ayıklama (Debugging)

3 Giriş 3 Yazılım Testinin iki temel hedefi vardır: Geliştiriciye ve müşteriye yazılımın gereksinimleri karşıladığını göstermek. Yazılımın hatalı, istenmeyen, ya da şartnameye uymayan davranışlarının bulunduğu yerlerdeki hata ve kusurları bulmak. Test, yazılımın hatasız olduğunu ya da her durumda şartnamede belirtildiği şekilde çalışacağını gösteremez. "Test yalnızca hatanın varlığını gösterir, yokluğunu değil." Edsger Dijkstra, 1972

4 Yazılım Testinin Türleri 1/3 4 Kara Kutu testi (Black-box testing) Test eden, test edilen şeyin iç çalışma düzenini göremez Beyaz Kutu testi (Cam Kutu) [White-box testing (glass-box)] Test eden, test edilen şeyin iç çalışma düzenini bilir ve görür Geliştiriciler kendi kodlarını test etmek için bu test türünü kullanırlar

5 Yazılım Testinin Türleri 2/3 5 Birim Testi (Unit testing) Bileşen Testi (Component testing) Tümleştirme Testi (Integration testing) Regresyon Testi (Regression testing) Sistem Testi (System testing)

6 Yazılım Testinin Türleri 3/3 6 Genellikle alanında uzman test personeli tarafından yapılan diğer testler: Alfa testleri (alpha tests) Beta Testleri (beta tests) Müşteri Kabul Testleri (customer-acceptance tests) Performans Testleri (performance tests) Yapılandırma Testleri (configuration tests) Uyumluluk Testleri (compatibility test) Platform Testleri (platform tests) Stres Testleri (stress tests) Kullanılabilirlik Testleri (usability tests)

7 Birim Testi (Unit Testing) 7 Genellikle tek bir programcı ya da programlama ekibi tarafından yazılan sınıf, rutin, veya küçük programların çalıştırılmasıdır Tamamlanmış sistemden izole biçimde gerçekleştirilir

8 Bileşen Testi (Component Testing) 8 Birim Testi ile hemen hemen aynı şeydir Birden çok programcı ya da programlama ekibinin çalışması sonucu ortaya çıkan sınıf, paket, küçük program, ya da diğer program elemanlarının çalıştırılmasıdır Tamamlanmış sistemden izole biçimde gerçekleştirilir

9 Tümleştirme Testi (Integration Testing) 9 Birden çok programcı ya da programlama ekibinin çalışması sonucu ortaya çıkan iki veya daha fazla sınıf, paket, bileşen, ya da altsistemin birlikte çalıştırılmasıdır Genellikle test edilecek birden çok sınıf oluştuğu andan itibaren başlatılır Tüm sistem tamamlanana kadar devam ettirilir

10 Regresyon Testi (Regression Testing) 10 Daha önce çalıştırılmış test vakalarının (test case) tekrarlanmasıdır Daha önce aynı testlerden geçen yazılımda hata bulmak için yeniden test uygulanmasıdır Regresyon testinde amaç: daha önce test edilmiş kodlarda değişiklik yapılması nedeniyle yeni hataların oluşmadığından emin olmak yazılımın bir bölümünde yapılan bir değişikliğin başka bölümlerini etkileyip etkilemediğini tespit etmek

11 Sistem Testi (System Testing) 11 Yazılım en son yapılandırma ile çalıştırılmasıdır diğer yazılım ve donanım sistemleriyle tümleşik olarak Sistem testinde şu özellikler de test edilir: güvenlik (security), performans (performance), kaynak kaybı (resource loss), zamanlama sorunları (timing problems), tümleştirmenin alt seviyelerinde test edilmesi mümkün olmayan diğer konular

12 Geliştirici Testi 1/2 12 Ortalama bir projede geliştirici testi için ne kadar zaman harcanmalı?

13 Geliştirici Testi 2/2 13 Geliştirici testinin sonuçlarıyla ne yapılır? Sonuçlar, geliştirilmekte olan ürünün güvenilirliğini değerlendirmek için kullanılabilir Sonuçlar genellikle yazılımdaki hataların düzeltilmesi için yol gösterici olarak kullanılır Zaman içinde, test sonucunda bulunan hataların kayıtları sayesinde en sık yapılan/karşılaşılan hatalar ortaya çıkarılabilir

14 Yapım Sırasında Test 14 Geliştirme sırasında genellikle bir rutin veya sınıf yazılır, zihinsel olarak kontrol edilir, ve gözden geçirilir ya da test edilir. Tümleştirme ya da sistem testi stratejisi ne olursa olsun her bir yazılım birimi diğerleriyle kombine edilmeden önce iyice test edilmelidir. Birden çok rutin yazıldıysa, her seferinde yalnızca bir tanesi test edilmelidir. Eğer test edilmemiş birden çok rutin eklenir ve bir hata bulunursa, bu rutinlerden herhangi biri hatalı olabilir. Eğer daha önce test edilmiş rutinlere bir yenisi eklenirse, bulunacak yeni hataların bu rutinden ya da onun etkileşimlerinden kaynaklandığı bilinebilir. Bu durumda hata ayıklama çok kolaydır. Asgari olarak her kod satırı test edilmelidir!

15 Önce Test mi Sonra Test mi? 15 Kodu yazmadan önce test vakalarını yazmak, onları kodu yazdıktan sonra yazmaktan daha fazla efor gerektirmeyecektir; yalnızca test vakası yazma etkinliğinin sırası farklılaşacaktır. Test vakaları önce yazılırsa, hatalar daha erken tespit edilebilir ve daha kolay düzeltilebilir. Test vakalarının önce yazılması kod yazılmadan önce gereksinimler ve tasarım üzerinde düşünmeye zorlar ve genellikle daha iyi kod yazılmasıyla sonuçlanır. Test vakalarının önce yazılması gereksinimlerdeki olası sorunların daha erken yani kod yazılmadan tespit edilmesini sağlar çünkü kötü hazırlanmış gereksinimler için test vakası yazmak zordur. Test vakaları saklanırsa ki mutlaka saklanmalı bu vakalar sayesinden sonradan da test yapılabilir.

16 Geliştirici Testinin Limitleri 16 Geliştirici testleri genellikle "temiz test"ler olma eğilimindedir Geliştirici testleri genellikle iyimser seviyede test kapsamasına sahiptir Ortalama %50-60 Geliştirici testleri genellikle gelişmiş ve karmaşık test kapsama türlerini gözardı etme eğilimindedir %100 Deyim kapsama (statement coverage) x %100 Dallanma kapsama (branch coverage)

17 Kod Kapsama (Code Coverage) 17 Programın kaynak kodunun ne derece iyi test edildiğinin göstergesidir. Temek kapsama kriterleri: İşlev kapsama (Function coverage) Programdaki her bir rutin çağrıldı mı? Deyim kapsama (Statement coverage) Programdaki her bir düğüm (node) işletildi mi? Karar kapsama (Decision coverage) Programdaki her bir kenar (edge) işletildi mi? Koşul kapsama (Condition coverage) Her bir boolean ifade true ve false değeri alacak şekilde değerlendirildi mi? Koşul/karar kapsama (Condition/decision coverage) Karar ve koşul kapsama kriterlerinin ikisi birden sağlanmalıdır. Parametre Değeri Kapsama (Parameter Value Coverage PVC) Parametre alan bir rutinde parametrelerin hepsi yaygın değerlerin tümüyle test edildi mi?

18 Kod Kapsama Örnek 1/2 18 Bu fonksiyonun, daha büyük bir programın bir parçası olduğunu ve bir test paketi ile çalıştırıldığını varsayın. int foo (int x, int y) { int z = 0; if ((x>0) && (y>0)) { z = x; } return z; }

19 Kod Kapsama Örnek 2/2 19 Eğer 'foo' en az bir kere çalıştırıldıysa, bu fonksiyon için İşlev Kapsama (Function Coverage) sağlanmış demektir. Eğer örneğin foo(1,1) olarak çağrılırsa fonksiyondaki tüm satırlar (z = x; dahil) işletilmiş olur ve böylece bu fonksiyon için Deyim Kapsama (Statement Coverage) sağlanmış olur. foo(1,1) ve foo(0,1) olarak çağıran testler Karar Kapsama'yı (Decision Coverage) sağlamış olur: İlk durumda her iki if koşulu da sağlanır ve z = x; deyimi işletilir, İkinci durumda, ilk koşul (x > 0) sağlanmaz, yani z = x; deyimi işletilmez. Koşul Kapsama (Condition Coverage) foo(1,1), foo(1,0) ve foo(0,0) çağrıları yapan testlerle sağlanabilir. İlk iki durumda (x>0) true olur, üçüncü durumda false olur. Aynı zamanda, ilk durumda (y>0) true olur, ikinci ve üçüncü durumda false olur. Parametre Değer Kapsama (Parameter Value Coverage (PVC)) bir parametre için yaygın tüm olası değerlerin test edilmesidir. Örneğin bir string genellikle şu değerleri alabilir: 1) null, 2) boş, 3) boşluk (boşluk, tab, satır sonu), 4) geçerli string, 5) geçersiz string, 6) single-byte string, 7) double-byte string. Olası tüm parametre değerlerinin test edilmemesi programda hata bırakabilir. Olası değerlerden yalnızca biriyle test yapılması %100 kod kapsama sağlar ancak olası yedi seçenekten yalnızca biri test edileceği için yalnızca %14.2 PVC sağlanmış olur.

20 Koşul Kapsama & Karar Kapsama 20 Koşul kapsamanın sağlanması Karar kapsamanın sağlanmasını gerektirmez! Örneğin: if a and b then Koşul kapsama şu iki test ile sağlanabilir: a=true, b=false a=false, b=true Ancak bu testler karar kapsamayı sağlamaz çünkü her iki durumda da if koşulu sağlanmış olmuyor. Testler sırasında tüm koşullar ve istisna yönetimi dallanmalarında yeterli kapsama sağlandığından emin olmak için Hata enjeksiyonu (Fault injection) adı verilen teknik gerekli olabilir.

21 Bazı Kod Kapsama Araçları 21 CodeCover Java için açık-kaynak kod kapsama aracı dotcover.net kod kapsama aracı JetBrains tarafından geliştirilmekte Clover Java ve Groovy için kod kapsama aracı Atlassian tarafından geliştirilmekte EMMA Java için ücretsiz bir kod kapsama aracı

22 Hatalar 1/2 22 Çoğu yapım hatası programcıların kusurudur Yazım hataları (tipo), problemlerin sürpriz derecede yaygın kaynağıdır Programcı hataları arasında tasarımın yanlış anlaşılması sürekli yaşanan bir durumdur Hataların çoğunu düzeltmek kolaydır kuralı burada da geçerli Çalıştığınız kurumun hatalarla olan deneyimini ölçümlemek iyi bir fikir olabilir

23 23 Hatalar 2/2

24 Testin Kendisindeki Hatalar 24 Test vakaları da en az test edilen kodun kendisi kadar ve hatta daha fazla hata içerebilmektedir! Test vakalarındaki hataları azaltmak için: Çalışmanızı kontrol edin Yazılımı geliştirirken test vakalarını planlayın Test vakalarını saklayın Birim testlerinizi bir test altyapısıyla (test framework) bütünleştirin

25 Bazı Birim Testi Altyapıları 25 Java JUnit.Net NUnit Visual Studio Unit Testing Framework xunit.net PHP PHPUnit Python PyUnit C++ xunit++

26 JUnit 26 JUnit, Java programlama dili için bir birim testi altyapısıdır Genellikle xunit olarak bilinen test altyapıları ailesinin bir üyesidir Birim testinde de-facto standart olmuştur İki yaygın sürümü vardır: JUnit 3 JUnit 4

27 Hata Ayıklama (Debugging) 27 Test, hata bulma sürecidir. Hata ayıklama ise hatanın ana kaynağını belirleyip hatayı düzeltme sürecidir. Test gibi hata ayıklama da yazılımın kalitesini arttırma yöntemi değildir. Hataları teşhis etme yöntemidir Yazılımın kalitesi daha en başından itibaren oluşturulmalıdır! Yüksek kalitede bir ürün oluşturmanın en iyi yolu gereksinimleri dikkatlice analiz etmek, İyi tasarlamak, ve yüksek kaliteli kodlama pratikleri kullanmaktır. Hata ayıklama son çare olmalıdır.

28 Hataları Fırsat Olarak Görmek 28 Üzerinde çalıştığınız programı öğrenin Sık yaptığınız hataların türlerini öğrenin Kodlarınızı okumak zorunda kalan dışarıdan birinin bakış açısından kodlarınızı kalitesini değerlendirin Problemleri nasıl çözdüğünüzü öğrenin Hataları nasıl düzelttiğinizi öğrenin

29 Yetersiz Hata Ayıklama Yaklaşımları 29 Hatayı tahmin ederek bulmaya çalışın Problemi gerçekten anlamaya çalışarak zaman kaybetmeyin Hatayı en belirgin yöntemle giderin x = Compute( y ) if ( y = 17 ) x = $25.15 // Compute() doesn't work for y = 17, so fix it Elbette ki bunları yapmayın!

30 Etkili Hata Bulma Yaklaşımları Hatayı sabitleyin (tekrar üretebilir duruma gelin) 2. Hatanın kaynağını bulun 1. Hatayı yaptırabildiğiniz verileri toplayın 2. Toplanan veriyi analiz edin ve hatanın oluşumu hakkında bir hipotez geliştirin 3. Programı test ederek ya da kodu inceleyerek hipotezinizi nasıl destekleyebileceğinizi ya da çürütebileceğinizi belirleyin te belirlediğiniz prosedürü kullanarak hipotezinizi destekleyin ya da çürütün 3. Hatayı düzeltin 4. Düzeltilmiş kodu test edin 5. Benzer hatalar arayın

31 Hatayı Düzeltmek 1/2 31 Düzeltmeye başlamadan önce problemi iyi anlayın Sadece problemi değil, programı iyi anlayın Hatayla ilgili teşhisin doğru olduğundan emin olun Rahat olun Orijinal kaynak kodu yedekleyin Problemi giderin, belirtilerini değil!

32 Hatayı Düzeltmek 2/2 32 Kodu gerçekten iyi bir nedenle değiştirin Her seferinde yalnızda bir değişiklik yapın Yaptığınız düzeltmeyi kontrol edin Düzeltilen hatayı ortaya çıkartmaya yönelik yeni bir birim testi ekleyin Benzer hatalar arayın