Makale Özeti

Bu makalede test işlemine ilişkin esaslar incelenmiştir.

Makale

Programların Test Edilmesi - 1

  Verification & Validation Kavramları

      Verification ve Validation (V&V) yazılımın belirlenen şartlara uygun olup olmadığını ve müşterinin ihtiyaçlarını karşılayıp karşılamadığını kesinleştirmeye yarayan kontrol işlemlerine verilen genel isimdir. Birbirleri ile çok karıştırılan bu kavramlar gerçekte birbirlerinden çok farklı aktiviteleri ifade eder. 1979 da Boehm tarafından bu iki kavram arasındaki farlılık şöyle özetlenmiştir;

  •      Doğru ürünümü üretiyoruz ?     (Validation )
  •      Ürünü doğru üretiyormuyuz ?    (Verification)

    Verification; programın şartnamesinde belirtilen özelliklere uygun olup olmadığını denetler.  Validation; ise programın, müşterinin beklentilerini karşılayıp karşılamadığını denetler.

Static Ve Dinamik Teknikler

     Statik teknikler; sistem analizi, sistemi temsil eden dökümanlar, dizayn diyagramları ve program kaynak kodu ile ilişkilidir. Statik teknikler yazılım geliştirme sürecinin her aşamasında uygulanabilir. Dinamik tekniklerin uygulanması için ise çalışabilir bir programın elde edilmiş olması gerekmektedir. Aşağıdaki şekil statik ve dinamik tekniklerin yazılım işlemindeki yerlerini göstermektedir.

  22,1 

    Statik tekniklere program denetimi, analiz ve biçimsel verification dahildir. Statik teknikler sadece program ile programın şartnamesinde belirtilen, koşullar arasındaki uyumu denetler (verification) ancak programın işlevlerini doğru şekilde yerine getirip getiremediğini denetleyemez. Buna rağmen statik verification teknikleri geniş çapta kullanılmaktadır.

      Bundan sonraki test aşaması performans ve sistem güvenliği değerlendirilmesidir.

  • İstatistiksel Test : Programın performansını ve güvenirliliğini test etmek için kullanılabilir. 
  • Hata Testi : Programın şartnamede belirtilen şartlara uymayan kısımlarının bulunması içindir.

      Program içinde hatalar bulunduğu zaman tanımlanmalı ve yok edilmelidir. Bu işlem debugging işlemi olarak anılır. Hata testi ve debugging bazen aynı prosesin parçaları gibi düşünülebilir. Gerçekte bunlar birbirlerinden oldukça farklıdırlar. Test işlemi sadece var olan hataları tanımlarken, debugging ise hatanın yerini bulur ve hatayı düzeltir.

     Aşağıdaki şekil muhtemel bir debug işlemini göstermektedir. Kod içindeki hataların lokalizasyonu belirlenmeli ve program buna göre yeniden modifiye edilmelidir. Test işlemi yapılan her değişlikliğin doğru sonuç verip vermediğini kesinleştirmek için yapılan her değişiklikten sonra tekrar edilmelidir.       

   Debugger sistemin davranışı hakkında hipotezler üretmeli ve sistem çıktılarında hangi hatanın anomaliye sebeb olduğunu bulabilmelidir. Ayrıca program kodunun çalışması adım adım izlenebilmeli (trace) ve gerektiğinde manipüle edilebilmelidir.   

Debugging process  22,2

    Programda herhangi bir hatanın bulunmasının ardından hata düzeltilmeli ve program yeniden test edilmelidir. Bu test şekline reggression testi denilmektedir. Prensip olarak, aslında tüm testler her hatanın onarılışından sonra tekrarlanmalıdır. Ancak bu işlemler pratikte çok pahalıya mal olabilir. Bu yüzden sistemin parçaları arasındaki bağımlılık ilişkilerinin tanımlanması ve bir değişiklik yapıldığında sadece değişiklik yapılan parça ile ona bağımlı parçaların değişiklikten etkilenmesi sağlanmalıdır. Bu sayede sistemde yapılacak bir değişikliğin ardından sistemin bütünü ile test edilmesi yerine sadece değişiklik yapılan parça ile bu parçaya bağımlılığı tanımlanan diğer parçaların test edilmesi yeterli olur.   

Test İşleminin Aşamaları 

      En çok uygulanan test işlemi genellikle beş aşamadan oluşur. Test sırası component testi, integrasyon testi, kullanıcı testi şeklindedir.

22,3 Test sırası     

  1. Component (Birim) Testi : Bu aşamada componentlerin bireysel olarak işlevini doğru biçimde yerine getirip getirmediği kesinleştirilir. Her bir component sistemin diğer componentlerinden bağımsız olarak test edilmelidir.
  2. Modül Testi : Modül; birbirleri ile fonksiyonel olarak ilişkili componentleri içeren bir taşıyıcıdır. Ve sistemin diğer modüllerinden bağımsız olarak test edilmelidir.
  3. Alt Sistem Testi : Bu aşamaya modüllerin biraraya gelerek oluşturduğu alt sistemlerin test edilmesi dahildir. Alt sistemler bağımsız olarak tasarlanmalı ve implemente edilmelidir. Büyük yazılım sistemlerinde yaşanan ortak problem alt sistemler arasındaki uyumsuzluktur.   
  4. Sistem Testi : Alt sistemler biraraya gelerek programı yani sistemi oluşturur. Sistem testi bulunan hatalar ile alt sistemler ve sistem componentleri arasındaki beklenmeyen etkileşimlerin yarattığı sonuçlar ile ilgilidir.
  5. Alfa ya da Acceptance Testi : Bu aşama; programın beta testi kullanıcısına verilmeden önceki son test aşamadır ve alfa testi olarak adlandırılır. Program bu aşamada gerçeğe yakın koşullarda, simüle edilen test dataları ile test edilir.

Beta Testi

       Bir program bir yazılım ürünü olarak pazarlanmadan önce, ismine beta testi denen bir test işlemi kullanılır. Beta testi; ileride yazılımı satın alacak olası müşterilere, yazılan programın bir kopyasının ücretsiz olarak dağıtılıp programı belirli bir süre için ya da süresiz olarak kullanmalarını sağlamaktır. Bu kişiler programı gerçek çalışma koşullarında sınayacak ve gördükleri hataları developer grubuna raporlayacaktır. Raporlanan bu buglar düzeltilecek ve yazılım ürünü bu aşamalardan sonra satışa sunulacaktır.

Object Oriented Sistemlerin Test Edilmesi

       Nesne yönelimli sistemlerde sınıfların test edilmesi yukarıda anlatılan component testine uygundur. Ancak modül testinin bir eşleniği nesne yönelimli sistemler için yoktur. Bununla beraber Murphy (1994) sınıfları sağladığı işlevler açısından gruplayarak test etmeyi önermiştir. Bu işlem cluster testi olarak anılır.


Aykut TAŞDELEN

MVP (MS Most Valuable Professional)

Kaynak : Software Engineering