Yazılım Testi ve Kalite PowerPoint Sunumu PDF

Test Tipleri Fonksiyonel-performans ve dayanıklık testlerine, sistemin dış spesifikasyonlarına ve gereksinimlerine dayandırıldığı için, kara kutu testi (black box testing) adı verilmektedir. Buna karşılık, yapısal denetimde modül düzeyinde programın deyimleri ya da dalları sınanarak iç...

Test Tipleri Fonksiyonel-performans ve dayanıklık testlerine, sistemin dış spesifikasyonlarına ve gereksinimlerine dayandırıldığı için, kara kutu testi (black box testing) adı verilmektedir. Buna karşılık, yapısal denetimde modül düzeyinde programın deyimleri ya da dalları sınanarak iç yapısı incelenmektedir. Bu şekilde uygulanan sınama yöntemine de saydam kutu testi (white box, glass box testing) denilmektedir.  Saydam kutu testi Saydam kutu testinde, işlemsel (procedural) tasarımın kontrol yapısı kullanılmaktadır. Bu test ile; Bir modüldeki bütün bağımsız yolların en az bir kez çalışacağı garanti edilmekte, Bütün mantıksal kararların "doğru" ve "yanlış" durumları denenmiş olmakta, Bütün döngülerin kendi içinde ve çevresinde işlerliği sağlanmakta, İç veri yapıları denenerek, geçerliliği güvence altına alınmaktadır. Saydam kutu testinin uygulanmasında, temel yol testi ve döngü testi teknikleri kullanılmaktadır.  Saydam Kutu: Temel Yollar Testi Temel yollar testi, işlemsel tasarımın mantıksal karmaşıklığını ölçmek ve bu ölçüye göre uygulama yolları için bir temel grup oluşturmak esasına dayanmaktadır. Test programları, test sırasında programdaki her deyimi en az bir kez uygulayarak denemektedir. Uygulama; Ayrıntılı tasarım veya kaynak programa dayanarak, bir akış grafı çizmek. Akış grafı üzerinde döngüsel karmaşıklık (McCABE) ölçüsünü saptamak, Doğrusal bağımsız yolların temel grubunu ve düğümleri belirlemek, Temel grubun içerdiği her yolun denenmesi için birer test programı düzenlemek, Her test programını uygulamak ve beklenen sonuç ile karşılaştırmak şeklinde, basamaklar halinde yürütülmektedir  Saydam Kutu:Döngü Testi Döngü testi; bir saydam kutu testi olup, temel yollar analizine ek olarak yürütülmektedir. Bir döngü içerisinde bir giriş ve bir çıkışlı olarak soyutlanmış bulunan yollar da, birer döngü halinde ayrıca sınanmaktadır. Döngü testinin amacı; döngü içerisindeki başlama hatalarının, indeksleme ve artırma hatalarının, döngüyü sınırlama hatalarının bulunmasıdır. Test sonunda, döngü yapısının geçerliği onaylanmış olmaktadır.  Kara Kutu Testi Kara kutu testi; yazılımın bütünlenmesi sırasında uygulanan ve yazılım arabirimi üzerinde yapılan bir sınamadır. Bu sınama ile, yazılım işlevlerinin yerine getirildiği, girdilerin kabul edildiği, çıktıların doğru olarak bütünlüğün sağlandığı gösterilmektedir. Kara kutu testinde yazılımın mantıksal iç yapısından çok, temel sistem modeli denenmiş olmaktadır. Bu nedenle, kara ve saydam kutu testleri birlikte uygulanarak, yazılım arabiriminin geçerliği onaylanmakta ve yazılımın iç işlerliğinin doğruluğu kısmen güvence altına alınmaktadır Kara Kutu test modeli  keşif testi Smoke Test.keşif testi, ürün spesifikasyonu veya gereksinim belgesi olmadan yazılımın ürün spesifikasyonu gibi kullanılarak test edilmesidir. Dinamik kara kutu testi, ürün spesifikasyonu veya gereksinim belgesi olmadan yapılabilir.  Hata Giderme (Debugging) Hata Giderme (Debugging) Sınama sonucu saptanan hata ve eksiklerin nedenlerinin bulunup, düzeltilmesi gerekmektedir. Hataları giderme (debugging) adı verilen bu işlemde, belirtiler ile nedenlerinin karşılaştırılması, sonra da hataların düzeltilmesi yoluna gidilmektedir. Şekil 5.11 de görüldüğü gibi bug nedenleri büyük oranda gereksinim analizinden kaynaklanmaktadır. Şekil 5.11. Yazılım Bug Nedenleri Diğer Kod Bug Nedenleri Gereksinim Tasarım Kod Gereksinim Diğer Tasarım  Hata Düzeyleri Hataların düzeyleri, Ölümcül, Kritik, Büyük, Orta, Küçük ve Görünüm Olarak tanımlanır. 6.KALİTE ÖLÇÜM ve DEĞERLENDİRMELERİ Bölüm Hedefi Yazılım kalite ölçütlerinin incelenmesi Yazılım ölçütlerinin test adımlarında kullanımının anlaşılması Kalite Güvenirliğinin kestirimini ve modellerini tanima  6.1. Yazılım Ölçümü Yazılım üretimi ölçülemez ise kontrol edilememektedir. (Tom De Marco) Yöneticiler ve yazılım mühendisleri açısından ölçme gereksinimleri farklıdır. Yöneticiler: – Yazılım üretimi için maliyetin ne olacağına – Farklı bölüm çalışanlarının ücretlerini belirlemek için personel üretkenliğini ölçmeye – Farklı projelerde geliştirilen yazılım ürünlerini kıyaslayabilmek için yazılım kalitesini ölçmeye – Projeler için ölçülebilir hedefler belirlenmesi örneğin, yazılım sisteminin nasıl güvenilir olması. – Şirkette kullanımına başlamak üzere, yöntem veya yazılım geliştirme araçlarının etkinliğinin ölçülmesine gereksinim duymaktadırlar.  1 2 R1 3 R2 4 1 5 R 0 6 1 R3 1 R4 6 2 1 1 R5 7 3 8 9 Şekil-6.1Ortalama alma yöntemine ait akış grafı, (R 2,.. R5 , graf içindeki kapalı bölgeler, R1, graf dışında kalan bölge ,  6.3.Yazılım Güvenirliği Tüm yazılımların aynı kalitede ve aynı bileşenlerle aynı sonucu vermesi beklenen bir durum değildir. Ayrıca, bir yazılımı tümüyle test etmek de mümkün değildir. 1000 kodluk bir ticari programda en az 1 kod satırı hatalı çıkmakta olduğu bilinmektedir. Kalite güvenirliği; geçmiş bilgilere ve sınamaya dayalı olarak, Başarı oranı = Başarılı süre / Toplam işletim süresi formülü ile kestirilmektedir. 6.3.1. Yazılım Güvenirliliği Modelleri Yazılım güvenirliliğinin ve geçerliliğinin ölçülmesi için 1980’lerde 100’e yakın model geliştirilmiştir. En yaygın olan dört model: – Schneidewind Model – Jelinski/Moranda Model – Musa Basic - Musa/Okumoto Log. Poison Execution-time Model – Littlewood-Verrall Model  Yazılım Güvenirliliği Modelleri Güvenirlik modelleri, istatistiki verilere dayanarak yazılımın güvenirliliğini saptamaktadır. Bu modellerin çalıştırılması sonucunda, Toplam hata sayısı Güvenirlilik düzeyi Sistemde yapılan revizyon sonucunda kalan hata sayısı vs. Gibi değerler elde edilmektedir.  7.YAZILIM TEST PLANLAMA ve YÖNETİM 7.0 Bölüm Hedefi Test spesifikasyonu belgesi içeriğini inceleme Test Planı içeriğini öğrenme Test senaryolarını hazırlayabilmek Yazılım bakımı (software maintenance) kavramını anlama, Yazılım mühendisliğinde konfigürasyon yönetiminin yeri ve önemini anlama, Yazılım değişim kontrolü ve versiyon kontrolü yollarını inceleme  7.1. Test Yönetimi Test kapsamında gerçekleştirilen işlemler (Şekil 7.1) de görüldüğü gibi planlama, tasarım ve gerçekleştirme adımları ile yürütülmektedir. Yazılım testlerini tanımlamak, planlamak, düzenlemek ve belgelemek için, test spesifikasyonu adı verilen bir belge düzenlenmektedir. Bu belge, genel hatları ile; Test plânları: test şekilleri, zamanlama, gider, ortam ve kaynaklar Test senaryoları Test işlemleri: her testin tanımlanması (bütünleme biçimi, amacı ve test edilen modüller, özel araç ve teknikler, gideri, test programı verisi) ve beklenen sonuçlar Gerçek test sonuçları Referans Ekler  7.1.1.Test Planı Test planı içeriği, – Test Stratejisi ve Test Edilecek Öğeler – Doğrulama Yöntemleri – Testlerin Tamamlanma Kriterleri – Hata ve Test Sonuç Raporlama – Test Sorumlulukları – Test Ortamı – Eleman ve Eğitim İhtiyacı – Test Takvimi – Risk Yönetimi – Test Çıktıları Şeklinde hazırlanmalıdır. Ancak bu plandaki ayrıntılar değişebilmektedir  7.1.2.Test Senaryoları Test Senaryosu Adı, kimliği Yazarı, Tarih İlgili gereksinimler/Testin Amacı Ön Koşul / Varsayımlar Test Girdileri Test Senaryosu Adımları Beklenen sonuçlar  7.1.3 Test Çalışma Ekibi Yapısı. Yazılımın sınanması sürecinde, sınamada bağımsızlık özelliğinin sağlanması için, yazılımın sınanmasından sorumlu olan kişiler, yazılımı tasarlayan ve oluşturan gruptan olmamalıdır. Test ekibinin görevi, Planlarda belirtilen testler için gerekli test hazırlıklarını yapmak, testleri yürütmek, testlerde bulunan hataları yazılımcıya bildirmek, izlemek test sonuçlarını raporlamaktır. İyi bir testçi ne zaman mükemmele ulaşılmayacağını, iyinin yeterli olacağını bilir. Her Yazılım Projesindeki optimum test miktarı farklıdır (Şekil 7.3).  7.2. Yazılım Teslim Sonrası Kalite Sağlama Yazılım sisteminin geliştirilmesi, yazılım ürününün müşteriye teslimi ve kullanılmaya başlanması ile tamamlanmış olmaktadır. Kullanım süresinde de – bakımı ve korunması, onarılması ve geliştirilmesi gerekmektedir.  7.2.1. Yazılım Bakımı Yazılımın bakımı ve onarımı (software maintenance); sonradan görülen hataların düzeltilmesi, yazılımın iyileştirilmesi-uyarlanması ve geliştirilmesi şeklindedir. Yazılımın bakımı konusundaki işlerin: – %21'inin hata düzeltme, – %25'inin iyileştirme, – %50'sinin uyarlama ve %4'ünün diğer durumlarda olduğu bildirilmektedir.  7.2.1. Yazılım Bakımı Geniş bir programın kullanımı sırasında, sınama aşamasında bulunamamış olan çeşitli işlem, yetenek ve tasarım hataları ortaya çıkabilmektedir. Yazılımın yeteneğini iyileştirmek ve kullanımını kolaylaştırmak üzere, programa bazı eklemeler gerekebilmektedirBu durumda, birkaç modül üzerinde değişiklik yapmak gerekmektedir. Ayrıca, günün koşullarına göre yeterli bulunmayan bir yazılımın; gereksinim analizi, tasarım, tamamlama ve sınama basamakları halinde yeniden geliştirilmesi ve böylece onarılması da söz konusudur.  7.2.2. Yazılım Konfigürasyonu Yazılım mühendisliğinin ürünleri, programlar, belgeler ve veri yapılarıdır. Bu ürünlere ait bütün maddelere topluca, yazılım konfigürasyonu denir. Yazılım Konfigürasyon Maddesi (Software Configuration Item), ise, YKY işlemlerinin uygulandığı yazılım modülüdür. YKY etkinlikleri: Konfigürasyon tanımı (Configuration Identification), Konfigürasyon değişiklik kontrolu (Configuration Control), Konfigürasyon denetimi (Configuration Auditing), ve Konfigürasyon raporlama (Configuration Status Accounting) olmak üzere dört aşamada gerçekleştirilmektedir.  Yazılım Konfigürasyon yönetimi YKY sürecinde herhangi bir işlemin yada ürünün değerlendirilmesi için bir standart gerekmektedir. Örneğin YKY planı standardı, YKY planının ne içermesi gerektiğini tanımlar YKY ile ilgili standartlara örnek, IEEE-STD-828 IEEE Standart For SCM Plans IEEE-STD-1042 IEEE Guide For SCM Plans ISO 9004 Quality Management & Quality System Elements Part 6  YAZILIM RİSK YÖNETİMİ Risk ile uğraşma taktikleri: – Sonradan (Reactive): Risk gerçekleşince çaresine bakmak. – Önceden (Proactive): Riskleri daha gerçekleşmeden önlemeye çalışmak. – Proactive yaklaşımları işleyeceğiz. Risk tanımı Olasılık: Belirli bir risk ortaya çıkabilir veya çıkmayabilir, risk %100 olasılıkla ortaya çıkacak diye bir şey yoktur. Kayıp: Risk ortaya çıktığında istenmeyen sonuçlar ve kayıplar doğurur. Genel risk çeşitleri: Proje riskleri Teknik riskler İş riskleri Farklı risk sınıflandırmaları ve risk işleme önerileri için bkz. SEI, ISO, ANSI, makaleler, kitaplar, vb.  RİSK YÖNETİMİ Proje riskleri: – Proje planını tehdit eder. – Gerçekleşirse zamanlama ileri tarihlere sarkar ve maliyet artar. Örnekler: Bütçe riskleri, Zaman riskleri, Personel riskleri, vb. Teknik riskler: – Üretilen yazılımın kalitesini ve zamanında bitirilmesini etkiler. – Gerçekleşirse yazılımı gerçekleme zorlaşır veya imkansızlaşır. – Çözümleme, tasarım, gerçekleme ve bakım aşamaları ile ilgili risklerdir. Örnek: 'Son teknoloji' ürünler yüksek teknik riske sahiptir. Bug'lar var mı? Dokümantasyonu tam mı? Tam anlayabildik mi bu teknolojiyi? Yarın da bu teknoloji hayatta olacak mı? İşletme riskleri: Pazar riskleri: Ürüne talep olur mu? Satış riskleri: Pazarlama ekibi ürünü nasıl satacağını biliyor mu?  RİSK TABLOSU Risk tablosu oluşturma: Tüm ekip veya risk işleme ekibinin tüm üyeleri olası riskleri adlandırsın. Risklerin çeşitlerini belirleyin (proje, teknik, iş) Herkes kendi uzmanı olduğu risk alanında riskleri alt türlere ayırsın. Ör. Teknik: Planlanandan daha düşük yeniden kullanım, kullanılan gereçlerde deneyimsizlik, vb. Risklerin gerçekleşme olasılıklarını belirleyin. Düşük, orta, yüksek gibi kategoriler. Risklerin etkilerinin büyüklüğünü değerlendirin Bu bilgilerden bir tablo yapın. ID, ad, çeşit, olasılık, etki. Listeyi bir yerden sonra kesin (Düşük olasılık ve etkileri atın). Ele alacağınız riskler için risk bilgi sayfaları oluşturun. Bu sayfa risk hakkında bilgiler ve önleme yollarını içersin.  Yazılım ölçümü Yazılım ölçümü zordur: yorumlama engeli yüksektir. Zorluğun nedenleri: – Yazılımın karmaşıklığı – Ölçütlerin nicel doğası Yazılımı neden ölçeriz? Ne kadar iyi bir ürün ortaya çıkardığımızı anlamak – Ne kadar iş yapacağımızı kestirmek – Böylece ne kadar zaman ve para harcayacağımızı anlamak Ölçülemeyen ilerleme yönetilemez: YAZILIM KALİTE ÖLÇÜTLERİ Nicel kalite ölçütleri farklı kişilerce farklı şekillerde öbeklenmekte ve farklı dallara ayrılmaktadır. ISO 9126 kalite ölçütleri: İşlevsellik Uygunluk, doğruluk, güvenlik, … Güvenilirlik Olgunluk, hata bağışıklığı, … Kullanılabilirlik … Verimlilik/Etkinlik … Bakım kolaylığı … Taşınabilirlik … McCall ve arkadaşlarının kalite ölçütleri: İşlevsel ölçütler Doğruluk, Güvenilirlik, Bütünlük, Kullanılabilirlik, Verimlilik Değiştirilme ölçütleri Bakım kolaylığı, Esneklik, Sınanabilirlik Taşınma ölçütleri Taşınabilirlik, Yeniden Kullanılabilirlik, Birlikte Çalışabilirlik McConnell'a göre kalite ölçütleri: İç kalite ölçütleri Dış kalite ölçütleri  Nesneye yönelik ölçütler Nesneye yönelik ölçütler: Kaliteli bir yazılıma götüren tasarım ilkelerine yöneliktirler. NYP'de çözümleme ve tasarım arasında kopukluk olmadığı için, aynı ölçütler çözümleme ve kodlama aşamalarında da kullanılabilir. Chidamber ve Kemerer'in ölçütleri (CK metrics suite): WMC: Sınıftaki ağırlıklı metot sayısı (Weighted Methods per Class). DIT: Kalıtım ağacının derinliği (Depth of Inheritance Tree). NOC: Alt sınıf sayısı (Number of Children) RFC: Sınıfın yanıt kümesinin eleman sayısı (Response For a Class) CBO: Sınıflar arası bağlaşım (Coupling Between Objects) LCOM: Uyum eksikliği (Lack of COhesion in Methods)  8.KALİTE İYİLEŞTİRME 8.0 Bölüm Hedefi Yazılım iyileştirme Sürecini anlamak CMMI Süreç modeli yeterlik düzeylerini incelemek Yazılım Geliştirme sreci ve Anahtar süreç alanları ilişkisini özetlemek Çalışanlar Yetenek modelini incelemek  Süreç İyileştirme YAZILIM GELİŞTİRME ORTAMI SERTİFİKASİSTEMLERİ CMM CMMI SPICE ISO  8.1. CMMI Yazılım sektöründe ürünün kalitesini ağırlıkla onu üreten sürecin kalitesi belirlemektedir ve süreç odaklı kalite yaklaşımı vardır. CMMI etkin bir yazılım sürecinin anahtar elemanlarını tanımlayan bir çerçeve model ve yazılım sürecinin olgunluğunu değerlendirmek için bir ölçüm aracıdır.  CMMI Yeterlilik Düzeyleri CMMI modeli, süreçler için beş yeterlilik düzeyi tanımlamaktadır. Başlangıç Yönetilebilir Tanımlı Sayısal Yönetilebilir Eniyilenebilir  CMMI Anahtar Süreç Alanları Etkin bir yazılım süreci geliştirmek için tanımlanan anahtar süreç alanlarının düzeylere göre dağılımı belirtilecektir. Birinci düzeyde anahtar süreç alanı yoktur. II. Düzey (Yönetilen) – Gereksinimlerin Yönetimi – Proje Planlama – Proje İzleme ve Kontrol – Tedarikçi Sözleşme Yönetimi – Ölçümleme ve Analiz – Süreç ve Ürün Kalite Güvence – Konfigürasyon Yönetimi  CMMI Anahtar Süreç Alanları III. Düzey (Tanımlı) – Gereksinimleri Geliştirme – Teknik çözüm – Ürün entegrasyonu – Doğrulama Onaylama – Kurumsal süreç tanımlama ve odaklanma – Kurumsal eğitim – IPPD (entgre ürün ve süreç geliştirme) için tümleşik proje yönetimi – Risk yönetimi – Entegrasyon için organizasyonel altyapı  CMMI Anahtar Süreç Alanları IV. Düzey (Niceliksel Yönetilen) – Organizasyonel süreç başarımı – Niceliksel proje yönetimi V. Düzey (eniyileştirilmiş ) – Organizasyonel yenilenme ve yaygınlaştırma – Nedensel analizler ve çözümleme  8.1.4.People CMM P-CMM kavramları 1992 yılında SEI tarafından projelendirildi. Organizasyonlar performanslarını artırmak için birbiriyle ilişkili insan, Süreç ve Teknoloji kavramları üzerinde odaklanmalıdır. İnsanlarla ilişkili konuları tanımlayıp iyileştirme isteyen organizasyonlar için geliştirilen P-CMM CMM’in genel yapısına benzeyen bir olgunluk çerçevesidir. Bir yazılım ve bilgi sistemleri organizasyonunun insan değerlerinin yönetimi ve geliştirilmesini yönlendirir.  P-CMM P-CMM temel hedefleri; Yazılım geliştirme yeteneğini tanımlamak ve sağlamak iş gücünün yeteneklerini artırarak organizasyonun yeteneklerini artırmak ve iyileştirmek, Her bir çalışanın ile organizasyonun hedeflerini birlikte tutmak İnsan değerlerini elinde tutmaktır.  P-CMM Düzeyleri Düzey 1—Başlangıç Düzey 2—Tekrarlanabilir – Tazminat – Eğitim – Performans Yönetimi – Personel Sağlama – İletişim – Çalışma Ortamı Düzey 3—Tanımlı – Katılımcı Kültür – Yeteneğe Dayalı Pratikler – Kariyer Geliştirme – Yetenek Geliştirme – İşgücü Planlama – Bilgi ve Becerilerin Analizi  P-CMM Düzeyleri Düzey 4—Yönetilen – Organizasyonel Performans Ayarlama – Organizasyonel Yetenek Yönetimi – Takım Temelli Pratikler – Takım Kurma – Danışmanlık Düzey 5—En İyileşen – Sürekli İşgücü İnovasyonu – Koçluk – Kişisel Yetenek Geliştirme  Software Reusability Approach Subroutine, Procedure, Module Object Oriented Programming Component-Based Development Design Pattern Application Programming Interface (API) Prog.Library Code Generation Aspect-Oriented Software Development Frameworks Service Oriented Architecture Software Product Lines - SPL CHEMNITZ UNIVERSITY OF November 22, 2024 44 TECHNOLOGY