developen

Web tabanlı uygulama geliştiren ekipler için keyword driven automation birçok artıyı beraberinde getiriyor. Bu yazıda beraberce basit bir keyword driven automation alt yapısını inceleyeceğiz.

Lakin dikkat! Burada bahsettiğimiz konsepti birebir alıp uygulamak işinize yaramayabilir yada daha kötüsü sizin durumunuz için hiç de uygun olmayan şeylerden bahsediyor olabiliriz. Bu sebeple kendiniz için benzer bir sistem üretmeden yada satın almadan önce konu ile ilgili yazdıklarıma ve Cem Kaner’in makalesine -özellikle “Maintainability is a Requirements Issue” başlığına- göz atmanızı tavsiye ederim.

Bizim çok statik bir senaryomuz var. Testlerimizi otomasyon altına almaya karar verdik ve uygun model olarak keyword driven bir yaklaşımı seçtik. Bu ön koşullar ile fikir üretmeye başlayalım.

Keyword driven yaklaşımı aslında basit bir ayrıştırma yada bir tür soyutlamadır. GUI, otomasyon alt yapımız ve test durumlarımız birbirlerine gevşek bağlarla bağlıdırlar.

Şemada görebileceğiniz üzere, her bir katman sadece çift yönlü oklarla gösterdiğimiz standart tanımlamalara tabiidir. Bu tanımlamalara uyulduğu sürece, gereken değişiklik sadece ilgili katmanda yapılır ve sistemin kalanı bu değişiklikten etkilenmez.

Örneğin test durumlarının teker teker kodlanarak (yada kaydedilerek) otomasyona alınmasından ziyade, tüm testlerimizi aşağıdaki tablodakine benzer bir biçimde tutarız. Bu format test durumlarımız için standarttır ve be standartlara uyduğumuz sürece istediğimiz test durumlarını tablomuza ekleyip çıkarabiliriz. Otomasyon altyapımız bundan etkilenmez, yada diğer bir deyişle her bir test durumu için otomasyon kodu yazmamız gerekmez.

Tabloyu incelersek, tüm akış alışveriş sepetimizde geçiyor. İlk satırda chkUrun%Urun_ID% isimli checkbox’ı seçili hale getirmek için hazırladığımız tanımı görüyorsunuz. Bu hayali test durumumuzda sepetten bir ürün çıkarmak için, sepetteki ürünün yanında bulunan checkbox’ı işaretliyoruz. Ayrıca eminim ki burada %Urun_ID% isimli bir değişken kullandığımızı dikkatli gözlerden kaçıramamışızdır. Bu değişken, çalışma anında test verilerimizden gelen değeri alacaktır.

İkinci satırdaki tanımlamayı, sepet içerisindeki “Seçili Ürünleri Sil” butonuna tıklamak için ekledik. Bunu takip eden 3. satır ise otomasyonumuzun sayfanın yeniden yüklenmesini beklemesi için yaptığımız bir çağrıdan ibaret.

Son satırda ise bir tespit yapıp, ürün toplam bedelinin %spnToplam% isimli değişkenimiz ile karşılaştırıyoruz ve “Eşit” olup olmadığına bakıyoruz.

Keyword driven yaklaşım, bu noktada bizlere şu avantajları sağlıyor.

1. Yeni bir test eklemek için kod yazmamıza, kayıt yapmamıza gerek yok. Bu tabloya eklenen her satır, otomasyon altyapısı tarafından işletilecektir. Ayrıca testlerin otomasyona alınması için gereken teknik bilgi de böylece azaltılmış olur.
2. Eğer olurda GUI ile ilgili değişiklik olur ise, test durumlarımızı çöpe atmamıza gerek kalmaz. Otomasyon altyapımızda gerekli değişiklikleri yaparız ve test durumlarımız işlemeye devam eder.
3. Uygulama tasarım aşamasındayken testler tasarlanıp otomasyona alınabilir. Bu sayede, örneğin, otomasyon yardımı ile Test-Driven-Development yapabiliriz.

Keyword driven yaklaşım için soyutlama demiştik. Lakin her soyutlamada olduğu gibi, esnek de olsa katmanlar arasında bazı bağlara ihtiyacımız olacaktır. Bunun ilk örneği yukarıdaki tabloda görebileceğiniz “Nesne” sütunudur.

Web tabanlı uygulamamızın her GUI kontrolünde bir ID parametresinin bulunmasını isteyeceğiz. Bu ID parametresi uygulama tasarım aşamasındayken tanımlanacak ve değişmeyeceği garanti edilecek. Yani örnek bir buton, HTML kodunda şu şekilde görünecek.

<input type="submit" name="btnSepetSeciliSil" value="Sil"

         id="btnSepetSeciliSil" class="siteButtonRed"></input>

Gördüğünüz gibi butonumuzun bir ID’si mevcut ve biz bu ID’yi bu ekranın ilk grafik çalışmaları onaylandığında belirlemiştik.

Diğer bir bağ ise otomasyon alt yapımızın GUI ile ilgili olan bağı olacaktır. Bu bağı sağlayacak olan ise, otomasyon altyapımızdır. Otomasyon altyapımız kabaca tablomuzdan test durumlarımızı satır satır okuyacak, ilgili nesneyi bulacak ve bu nesne üzerinde tanımladığımız aksiyonları gerçekleştirmeye çalışacak. Gerek görülen durumlarda tespitler (İng. “assertion”) yapıp sonuçlarımızı loglayacak.

Bunun yanında, aşağıdaki kod örneğinde belirtilmeyen ama çözmeniz gereken sorunlarınız olabilir. Bu sorunlar büyük olasılıkla otomasyonunuzun koşacağı ortamı da kendiniz geliştirme kararı almanız durumunda karşılaşacağınız sorunlardır. Eğer otomasyonunuz bir araç üzerinde koşacak ise, bu sorunların çözülmüş olabileceğini hatırlatalım.

• Eğer doğrudan tarayıcı üzerinde koşan JScript tabanlı bir otomasyon altyapısı geliştiriyorsanız, test datalarını okumak ve test sonuçlarını loglamak sorun olabilir. OLE otomasyonu buna çözüm olabilecek olsa da,

• Test datalarını JScript ile XMLHttpRequest() nesnesi kullanarak bir Web sunucudan okuyabilir,
• Test sonuçlarını da aynı şekilde XMLHttpRequest() ile bir sunucu üzerinde toplayabilirsiniz.

Aslında bu liste biraz daha uzayabilir ama bizim niyetimiz bu yazıyı kabul edilebilir biçimde tutmak, o yüzden örnek kodumuza bir bakalım.

Bu kod, gördüğünüz üzere çalışmaktan ziyade, organizasyonu göstermek için yazılmış durumda. Burada metin tipindeki girdi alanları için bir kütüphane çatısı görüyorsunuz. Tüm GUI nesnelerimiz State isimli bir nesnemizden türüyorlar. Bu nesne aynı zamanda bizim test durumları tablomuzun bir satırına karşılık gelen tüm verileri içerisinde özellik olarak barındırmakta.

Yapacağımız basit aslında, tablomuzdan bir satır okuyacağız, bu satırda belirtilen nesnenin tipine göre aşağıdakine benzer bir nesne tanımından bir örnek üreteceğiz, değerlerimizi atayıp aksiyonumuzu gerçekleştireceğiz. Her GUI bileşeni tipi, yine ortak olarak miras aldıkları -dikkat, bu aşağıda örneklenmemiştir- servisleri kullanarak log tutacak yada test datalarına erişecekler.

Örnek GUI bileşeni kütüphane çatısı;

function State()
{
    var stateID;    // satir kodu
    var location;   // konum
    ....            // ve diğer sutunlar

    var objectHolder; // nesne tutucu
    this.objectHolder = document.getElementById(this.objectID);
} 

////////////////////////////////////////////////
///
/// Metin alani
/// <input type="text"...
///
//////////////////////////////////////////////// 

// Metin alanimizi State nesnesinden turetelim
OTextInput.prototype = new State();
OTextInput.prototype.constructor = OTextInput;
OTextInput.prototype.baseClass = State.prototype.constructor; 

// Bu nesneye ozel aksiyonlarimizi tanimlayalim
OTextInput.MetinEkle = OTextInput_SetText;
..... 

function OTextInput_SetText()
{
    try
    {
        this.objectHolder.text = this.condition;
        ....
    }
    catch(Exception e)
    {
        // Burada hata raporlamasi
        ....
    }
}

Organizasyon basit ve sanırım, kabaca da olsa, katmanlarımız arasındaki bağlantıyı nasıl kurduğumuzu göstermiş olduk. O halde, kodu bir kenara bırakıp, otomasyon altyapımızın üzerinde koşacağı ortam ile ilgili birkaç şey daha söyleyelim.

Otomasyon altyapınız herhangi bir test otomasyon aracı üzerinde koşabilir. Eğer bir test otomasyon aracı kullanıyorsanız, birçok temel işlev araç ile beraber gelecektir ve bunlara doğrudan sahip olursunuz. Örneğin çoğu modern otomasyon aracı mock GUI nesneleri yaratmanıza izin vermektedir. Bu sayede programatik olarak tablodan okuduğunuz verilere göre çalışma anında GUI nesne örneği (İng: “instance”) oluşturabilirsiniz. Sadece bu sebepten dolayı, benim kişisel tercihim otomasyon aracı kullanmak.

Otomasyon altyapınız, test otomasyonu aracı olmadan, Firefox gibi bir tarayıcı üzerinde doğrudan da koşabilir. Bunu GreaseMonkey gibi bir Firefox eklentisi ile yada Internet Explorer üzerinde OLE otomasyon teknikleri ile yapabilirsiniz.

Keyword driven yaklaşım ile ilgili, bedelini geçmişte kanla ödediğimiz, bir iki dersi de sizlerle paylaşmak istiyorum.

1. Test durumlarınızın her satırı için bir kod belirleyin. Bu kod, otomasyondaki test geçilmediği zaman yaptığınız incelemeyi kolaylaştıracaktır. Tabii ki sizler örneğimizdeki 1,2,3 gibi rakamlardan ziyade, sizlere daha fazla yardımı dokunacak kodlar seçebilirsiniz.
2. Tabloları oluşturmak için favori ofis aracınızda makrolar hazırlayabilirsiniz. Böylece testlerin otomasyona alınmaları kolaylaşacaktır. Belki de en önemli fayda olarak seçilen nesnenin tipine göre aksiyonların seçim listesinin gelmesini sayabiliriz. Bu sayede kontrollerin ezberlenmesine gerek olmayacaktır. Ör: Eğer seçilen nesne bir metin kutusu ise “metin girişi, metin okuma, vb”, Checkbox kontrolleri için sadece ilgili “İşaretle, İşareti Kaldır” aksiyonlarının görüntülenmesi gibi.
3. Ayrıca yine söz konusu makrolar ile test durumlarınızı düz metin, CSV yada XML formatında kaydedebilirsiniz. Bazı otomasyon araçları, ofis dokümanları yerine kendi formatlarındaki dosyaları kullanmayı tercih edebilirler.
4. Test verilerini gerektiğinde test durumu tanımlarınızın dışına taşıyın. Alt yapınızın buna izin vermesi, farklı test verileri ile aynı testleri işletmenize imkan verecektir.

Son olarak, Pettichord’un ev yapımı otomasyon isimli sunumuna buradan link verelim.

İyi Testler!