Nesneye Yönelik Test PDF

Nesneye Yönelik Test Nesneye yönelik yazılımlarda test stratejileri ve test teknikleri diğer yazılımlardan farklıdır. Nesneye yönelik yazılımlarda, sistem gereksinim tanımları, sınıf modelleri, sistem tasarımı ve nesne tasarımındaki hataların, kodlama sürecinden önce test edilerek belirl...

Nesneye Yönelik Test Nesneye yönelik yazılımlarda test stratejileri ve test teknikleri diğer yazılımlardan farklıdır. Nesneye yönelik yazılımlarda, sistem gereksinim tanımları, sınıf modelleri, sistem tasarımı ve nesne tasarımındaki hataların, kodlama sürecinden önce test edilerek belirlenmesi gerekir. Analiz ve tasarım modellerinin test edilmesi için, çalıştırılabilir olmaması nedeniyle klasik yöntemler yerine formal teknik gözden geçirmeler kullanılır. Nesneye Yönelik Analiz ve Tasarım Modellerinin Test Edilmesi Bu düzeyde doğruluk ve tutarlılık için gözden geçirme yapılır. Doğruluk, – Modellerin mantıksal doğruluk düzeyi incelemesi, – Sözdizimsel doğruluk kontrolu, – Gerçek dünyaya uyumluluk kontrolu İle sağlanır, Tutarlılık ise, Sınıf-Sorumluluk-İşbirliği (CRC) ve nesne ilişki modeli ile her sınıfın diğer sınıflarla ilişkilerinin test edilmesi ile kontrol edilebilir.  2. Nesneye Yönelik Yazılım Testi NY yazılımlarda, birim kavramı da sınıf veya nesne olarak değişmektedir. Sınıflar, test-case tasarımları için doğal birer birimdir. NY yazılımlarda birim test, sınıf testi olarak tanımlanmaktadır. Birim Testi algoritma ayrıntılarına ve veri akışına, sınıf test ise, paketlenmiş işlemler ve durum değişimlerine odaklanır. OO yazılımlar hiyerarşik kontrol yapılarına sahip olmadıkları için, bütünlük testinde, yukarıdan aşağıya veya aşağıdan yukarıya test stratejileri uygulanmaz. Kullanım Temelli veya Thread-Temelli bütünlük Testleri kullanılmaktadır.  Nesneye Yönelik Yazılım Kabul Testi Kabul veya Sistem testi aşamasında sınıf ilişkilerindeki ayrıntılar önemli değildir ve diğer yazılımlar gibi kullanıcı bakış açısıyla gereksinimlerin karşılanmasına sağlanır. Değerlendirme için, kara kutu testi kullanılır ve gereksinim analizinde hazırlanan kullanım senaryolarından faydalanılabilir. Test-case ler OO Analiz aşamasında oluşturulan “Nesne-Davranış” ve “Olay-Akış” diyagramlarından sayesinde hazırlanabilir.  Bölümlemeli Sınıf Testi Amaç test case sayısını azaltarak sınıfların test edilmesidir. Girdi ve çıktılar kategorize edilerek her kategori için test-case oluşturulur. Miras (inheritance) Özelliğinin test üzerine etkisi Miras alınan metodlar, yeni bir kullanımda olacakları için, yeniden test edilmelidir. Çok biçimlilik (Polymorphism Özelliğinin test üzerine etkisi Çok biçimli bileşenlerin olası tüm bağlanma (binding) durumları için ayrı bir test yapılmalıdır.  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 Şekil 7.1. Test Adımları  7.1. Test Yönetimi Test yönetimi geri beslemeli bir süreç ile geliştirilmektedir. Test hata mesajları da, doküman testi altında sınıflanmaktadır, ancak, hata mesajı içeriği belge olarak test edilir, doğru mesajın görüntülenmesi kod testini gerektirir (830-1993) - IEEE Standard for Software Test Doc. Standardı test spesifikasyonunu tanımlamaktadır  Şekil7.2. Test Spesifikasyonu geliştirme adımları Test Test İncelemeye Spesifikasyonu Spesifikasyonu Dayalı Baseline yaz incele Düzeltme  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).  Şekil 7.3. Her Yazılım Projesindeki optimum test miktarı farklıdır. 4 Kaçırılan Bug 3,5 Sayısı Test Maliyeti 3 2,5 Optimum test miktarı 2 Test Maliyeti Test Dışı 1,5 Kaçırılan Bug Sayısı 1 0,5 0 0 0,5 1 1,5 2 2,5 3 Test Miktarı Şekil 7.4. Yazılım Yaşam Döngüsü Boyunca Sınama Etkinlikleri Planlama Sistem Test Planı Yazılım Kalite planı Gereksinim Analizi Alt sistem sınama planları Tasarım Modül Test Planı Test tanımları Test Eğitim Elkitapları Gerçekleme Birim Test Bütünlük testi Sistem Test Kurulum Kullanıcı Testi Test Raporları 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.3. Bakım Maliyetlerinin Azaltılması Bakım ve onarım giderini en aza indirmek için, yazılım ürününün "bakım ve onarıma elverişli" nitelikte oluşturulması gerekmektedir (maintainability). Bunun için de; Yetenekli ve deneyimli yazılım mühendisleri görevlendirmek Anlaşılabilir bir sistem yapısı ve kolay işletilebilir bir sistem tasarlamak Standart programlama dilleri, işletim sistemleri kullanmak ve belgeleri standart biçimde düzenlemek Test programlarından yararlanmak Tasarım aşamasında, hata bulma ve düzeltme kolaylıkları sağlamak gerekmektedir.  Yazılımın bakım ve onarıma elverişliği Yazılımın bakım ve onarıma elverişliği; yazılımın diğer kalite faktörlerinden olan, Sınama kolaylığı Basitlik Değiştirilebilirlik Taşınabilirlik Güvenirlik Esneklik özeliklerinin bir bileşkesi olarak ortaya çıkmaktadır.  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