<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Web Uygulamaları için Model Bazlı Test Süreci Otomasyonu</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Uğur Özkan</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Hasan Sözer</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Özyeğin Üniversitesi</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>İstanbul</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Türkiye</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>ugur.ozkan@ozu.edu.tr</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>hasan.sozer@ozyegin.edu.tr</string-name>
        </contrib>
      </contrib-group>
      <fpage>101</fpage>
      <lpage>112</lpage>
      <abstract>
        <p>Özet. Yazılım sistemlerinin boyutları ve karmaşıklıkları arttıkça, bu sistemlerin test edilmesi daha maliyetli olmaktadır. Maliyeti düşürmek ve verimliliği artırmak için model bazlı test teknikleri geliştirilmiştir. Bu teknikler ile sistem kullanım modelinden otomatik olarak test senaryoları oluşturulabilmektedir. Fakat sistem modelinin manuel bir şekilde oluşturulması gerekmektedir. Ayrıca, model ile oluşturulan test senaryolarının sistem üzerinde otomatik çalıştırılmalarını sağlamak için betikler veya özel programlar geliştirilmesi gerekmektedir. Bu çalışmada, Web uygulamaları için model bazlı test sürecini otomasyon desteği ile iyileştirmekteyiz. Farklı araçları birleştirerek, sistem modelinin yarı-otomatik bir yöntem ile oluşturulmasını ve bu model ile oluşturulan test senaryolarının, ayrı bir program geliştirilmesine gerek olmaksızın, sistem üzerinde otomatik çalıştırılmalarını sağlamaktayız.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>sayfasının MBT ile sınanması için gereken yarım saati aşkın sürenin, üç dakika gibi
kısa bir zamana indirilebildiği görülmüştür.</p>
      <p>Bildirinin organizasyonu: bir sonraki bölümde MBT hakkında genel bilgiler
sunulmakta ve bu çalışmada kullanılan araçlar tanıtılmaktadır. Üçüncü bölümde, ele
alınan problem ve ihtiyaçlar listelenmektedir. Dördüncü bölümde, çözüm
yaklaşımımız ve yaklaşımımızı somutlaştıran süreç detaylarıyla anlatılmaktadır.
Beşinci bölümde elde ettiğimiz sonuçlar tartışılmaktadır. Altıncı bölümde,
çalışmamızla ilgili yapılmış diğer çalışmalar özetlenmektedir. Son olarak, yedinci
bölümde temel çıkarımlar özetlenmekte ve ileriye dönük yapılacak çalışmalar
listelenmektedir.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Model Bazlı Test ve Yazılım Test Otomasyon Araçları</title>
      <p>Bu bölümde öncelikle MBT yaklaşımı kısaca açıklanmaktadır. Devamında ise bu
çalışmada kullanılan araçlar ve teknolojiler tanıtılmaktadır.</p>
      <p>MBT, yazılım test senaryolarının otomatik olarak oluşturulduğu, yazılım testlerini
gerçekleştirmekte kullanılan, model bazlı geliştirme yaklaşımının (model-based
development) bir uygulamasıdır [1]. MBT, sistemin gereksinimlerinin ve görevlerinin
tanımlandığı modelleri temel almaktadır. Bu modeller genellikle teste tabi tutulacak
sistemin beklenilen davranışlarının kısmî gösterimidir ve test senaryoları
oluşturabilmek için gerekli olan bilgileri içermektedir. MBT için kullanılan modeller
genellikle sistem hayata geçirilmeden önce hazırlansalar da, sistem uygulamaya
konulurken veya konulduktan sonra da hazırlanabilmektedir. Her hâlükârda, bu
modeller ağırlıklı olarak manuel bir şekilde geliştirilir ve dolayısıyla ek çaba
gerektirir. Buna rağmen, harcanan emek ile elde edilen verim, geleneksel yazılım testi
yaklaşımlarına göre avantaj sağlamaktadır [3] çünkü sistem davranışlarının sadece bir
defa tanımlanması yeterli olmaktadır. Her yeni bir özellik için manuel bir şekilde
oluşturulan test senaryoları yerine, güncellenen model ile otomatik oluşturulan
senaryolar kullanılmaktadır. Böylece test senaryolarını güncellemek ve idâme
ettirmek daha kolay olmaktadır.</p>
      <p>Biz bu çalışmada MBT aracı olarak, Java dili ile geliştirilmiş açık kaynak kodlu bir
araç olan GraphWalker1 aracını (sürümü 3.2.0) kullanmaktayız. GraphWalker, sonlu
durum makinalarından (Finite State Machine – FSM) yararlanarak test senaryoları
üreten bir MBT aracıdır. GraphWalker, XML tabanlı GraphML2 biçimine uygun bir
şekilde oluşturulmuş modelleri işleyip, muhtemel test dizinlerini oluşturmaktadır.
Kullanılan model bir yönlendirilmiş çizgedir (directed graph) ve sistem durumlarını
(state) temsil eden birden çok düğüm (node) ve aksiyonları gösteren birden çok
ayrıtlara (edge) sahip olabilmektedir.1</p>
      <sec id="sec-2-1">
        <title>1 http://graphwalker.org/</title>
        <p>2 http://graphml.graphdrawing.org/</p>
        <p>GraphML dosyası bir çizim öğesi, ve bu öğenin içinde sıralanmış düğüm ve ayrıt
öğeleri içermektedir. Her düğümün kendine özgü bir kimliğinin (ID) olması
gerekmektedir. Aynı şekilde her ayrıtın da kendisine mahsus bir kimliğinin olmasının
yanı sıra, bağlı olduğu kaynak ve hedef düğümlerin kimliklerini içermektedir.
GraphML formatında çizimlerin oluşturulmasını ve değiştirilmesini sağlayan çeşitli
araçlar bulunmaktadır. Biz bu çalışmada, Java programlama dilinde yazılmış açık
kaynaklı bir çizim programı olan yEd3 aracını (sürüm 3.14.0) kullandık.</p>
        <p>GraphWalker, düğüm kaplamı (vertex coverage), ayrıt kaplamı (edge coverage),
düğüm erişimi (vertex reach) gibi durma koşulları ile ‘Random’, ve ‘A*’ gibi yol
üreticileri (path generator) kullanarak GraphML formatında oluşturulan modeli
dolaşmaktadır. Bu araç uzun ve tahmin edilmesi zor dizinler oluşturduğu için
rastlantısal olarak daha kapsamlı test sonuçlarının elde edilmesini sağlamaktadır.
Fakat oluşturulan dizinler sistem üzerinde çalıştırılabilecek test durumları değildir.</p>
        <p>Sistem üzerinde otomatik çalıştırılabilecek test durumlarını elde etmek için
GraphWalker tarafından oluşturulan test adımlarına tekâbül eden betikler (script)
yazmak gerekmektedir. Çalışmamızda, bu betikler açık kaynak kodlu bir yazılım aracı
olan Selenium4 (sürüm 2.8.0) kullanılarak otomatik bir şekilde oluşturulmaktadır.
Selenium, her platformda çalışabilen, web sitelerinin testlerinde kullanılan, Java
programlama dilinde yazılmış bir yazılım test aracıdır ve temelde kaydet – oynat
(capture – replay) işlevleri sunmaktadır. Ayrıca, Web uygulamaları için test
adımlarının otomatik çalıştırılmasını sağlayan komutları bir kütüphane olarak
programcılara sağlamaktadır.</p>
        <p>Yukarıda tanıtılan araçlar bir sonraki bölümde değinilecek olan problem ve
ihtiyaçları gidermek amacıyla bir araya getirilmiş ve geliştirdiğimiz yardımcı araçlar
ile birlikte çalışmaları sağlanmıştır.
3</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Problem ve İhtiyaçlar</title>
      <p>MBT, test senaryolarının sistematik ve otomatik bir şekilde oluşturulması, bu
senaryoların etkin bir şekilde idâme ettirilmesini sağlamakla birlikte bazı kısıtlamalar
ve dezavantajlar da içermektedir. Literatürde yer alan bazı çalışmalarda [4], MBT
kullanımına ilişkin zorluklar raporlanmıştır. Bu zorluklar, çoğunlukla ücretli, ticarî
MBT araçları kullanılmasına rağmen karşılaşılan, kullanılan araçtan çok, sürecin
doğası gereği karşılaşılan zorluklardır. Genel olarak MBT süreci kapsamında
gerçekleştirilen işlemler aşağıdaki gibi sıralanabilir:
1. Sistemin, kullanıcılar tarafından kullanım şekillerini, sistemden beklenen
davranışlarını yansıtan bir model oluşturulmaktadır. Örneğin, biz
çalışmamızda MBT aracı olarak GraphWalker aracını kullanıyoruz ve bu
3 http://www.yworks.com
4 http://www.seleniumhq.org/</p>
      <p>araç için sistem davranışlarının bir sonlu durum makinası (Finite State
Machine – FSM) olarak modellenmesi gerekmektedir.</p>
      <p>Modeldeki bütün durum ve aksiyonlar (durum geçişleri) için ayrı ayrı test
kodu veya betikler (script) yazılmaktadır.</p>
      <p>MBT aracı modeli sistematik bir şekilde dolaşarak test senaryoları
oluşturmaktadır. Bu senaryoların her biri, modelde yer alan durumların farklı
birleşim ve sıralarda dolaşılması ile oluşan birer dizi şeklindedir.</p>
      <p>Oluşturulan test senaryoları sistem üzerinde otomatik bir şekilde sırasıyla
çalıştırılmaktadır. İkinci aşamada geliştirilen test kodları, senaryolara dâhil
olan her durum dizisinin somut test adımlarına dönüşmesini sağlar.</p>
      <p>Yukarıdaki adımlardan ilk ikisi manuel olarak gerçekleştirilmektedir. İlk aşamada,
sistem modelinin sıfırdan oluşturulması çok fazla zaman ve çaba sarf edilmesine
sebep olmaktadır. Ayrıca model geliştirme sırasında hata yapılması olasılığı da
mevcuttur. İkinci aşamada ise modelde yer alan her durum ve aksiyona karşılık gelen
test kodları veya betikler yazılması gerekmektedir. Bu işlem de manuel bir şekilde
gerçekleştirildiğinden emek gerektirir ve hata oluşumuna açıktır. Biz bu çalışmada
Web uygulamalarına yönelik MBT kapsamında, manuel iş gerektiren ve hataya açık
olan bu işlemlerin, otomasyon desteği ile iyileştirilmeleri için bir çözüm ve araç seti
öneriyoruz. Bir sonraki bölümde çözüm yaklaşımımız ve yöntemimiz detaylarıyla
açıklanmıştır.
4
Çözüm Yaklaşımı ve Yöntem
Çözüm yaklaşımımız genel hatları ile Şekil 1’de görülmektedir. Bu şekilde hem
uygulanan süreç, hem de bu süreci destekleyen araçlar gösterilmektedir. Bu araçların
bir kısmı daha önceden Bölüm 2’de tanıttığımız, açık kaynak kodlu, dışarıdan
kullandığımız araçlardır (GraphWalker, yEd, Selenium). Diğer araçlar ise, bizim
geliştirdiğimiz, tüm araçların bir arada çalışmalarını sağlayan ve sürecin baştan sona
otomasyonunu destekleyen araçlardır. Esnekliği ve modülerliği artırmak için tüm
araçlar tek başına çalışabilecek şekilde tasarlanmıştır. Bu sayede bu araçlar başka
projelerde kullanılabilecek ya da ihtiyaçlara göre kolaylıkla değiştirilebileceklerdir.
Bunun yanı sıra, geliştirilen tüm bu araçları ve süreci baştan sona kontrol eden,
araçların uyumlu bir şekilde ve sırayla bir arada çalışmalarını sağlayan ayrı bir araç
daha geliştirilmiştir5.</p>
      <p>Süreçten kısaca bahsetmek gerekirse, ilk aşamada ‘Web Element Extractor’
Selenium aracılığıyla açtığı Web sayfasını tarayıp “id” ve “name” nitelikleri olan
Web elemanlarını ayıklıyor (1). Yapısı gereği bu araç diğer nitelikleri de ayıklama
yetisine sahiptir.
5 Tüm kaynak kodlara bu adresten ulaşılabilinir: https://github.com/uguurozkan/SeniorProject
Şekil 1: Genel Süreç ve Araçlar</p>
      <p>Ayıklanan Web elemanları, ‘Element Convertor’ aracılığıyla, ‘Element’ objelerine
çevriliyor (2). Kullanıcı bu elemanlar üzerinden işlemler (seçme, değiştirme, tıklama
gibi) yapabileceği için, işlemlerle ilgili olarak isimlendirme yapılıyor ve bu işlemlere
ilişkin ayrı ayrı metodlar oluşturuluyor. Elemanların ve metodların isimlendirmeleri
Selenium komutları ile tutarlı olacak şekilde yapılıyor ki ilerleyen aşamalarda her
eleman için otomatik çalıştırılabilir test adımları oluşturulabilsin.</p>
      <p>Oluşturulan ‘Element’ objeleri, modelin aslî yapısını oluşturmaktan sorumlu
‘GraphML Creator’ aracına veriliyor ve isteğe bağlı olarak boş, sadece düğümlerin
olduğu, ya da düğümlerle beraber ayrıtların da olduğu bir diagramın saklandığı
.graphml uzantılı bir dosya oluşturuluyor (3). Oluşan bu dosya sonradan eksikleri
tamamlanacak modelin bulunduğu dosyadır.</p>
      <p>Bu noktaya kadar süreç araçlar ile otomatik olarak ilerliyor; ama bu aşamada eğer
oluşturulan model tamamlanmamışsa (çizge bağlı değilse) manuel müdahalenin
yapılması gerekmektedir. Bu aşamada ‘Model Completeness Checker’, temel olarak
modelde izole kalmış düğüm veya düğüm gruplarını tespit ediyor (4). Eğer modelde
tüm düğümler birbirlerine bağlı değil ise, bir uyarı mesajı ile birlikte tamamlanmamış
model Şekil 2’deki gibi yEd aracı ile kullanıcıya sunuluyor. Testi gerçekleştiren kişi
bu araç ile modeli düzeltiyor ve ‘Model Completeness Checker’ güncellenen modeli
tekrar teyit etmeye çalışıyor. Bu döngü teyit işlemi başarılı olana kadar devam ediyor.
Genel süreç göz önünde bulundurulduğunda bu aşamanın manuel müdahale
gerektiren tek aşama olduğu ve diğer aşamaların otomatik olarak yapıldığı
vurgulanmalıdır.
Şekil 2: Başarısız Model Teyit İşlemi</p>
      <p>Teyit aşaması başarılı bir şekilde sonlandıktan sonra ‘Test Step Creator’ ile
üzerinde çalışılan proje için Şekil 3’deki arayüz ve bu arayüzden oluşturulan, içine
Selenium komutlarının yerleştirildiği test adımları oluşturuluyor (5). Bu yapı .java
uzantılı bir dosya olarak kaydediliyor (Bkz. Ek bölümde yer verilen Şekil 4).
//Generated by GraphWalker
(http://www.graphwalker.org)
package org.myorg.testautomation;
import ...
@Model(file =
"org/myorg/testautomation/Demo.graphml"
)
public interface Demo {
// Truncated
}
Şekil 3: Test adımlarının tanımlandığı arayüz sınıfı</p>
      <p>Bir sonraki aşamada GraphWalker, test adımlarını ve modeli kullanarak, modelin
başlangıç noktasından itibaren, önceden tanımlanan algoritmasıyla bitirme koşulu
sağlanana kadar yolları takip ediyor. Her düğüm ve ayrıtta, karşılık gelen metot,
dolayısıyla metodun içindeki Selenium komutları, sistem üzerinde çalıştırılıyor (6).</p>
      <p>Bu süreci örnek bir uygulamada denedik. Bir sonraki bölümde, gerçekleştirdiğimiz
kontollü deneye ilişkin değerlendirme ve sonuçları paylaşıyoruz.
5</p>
    </sec>
    <sec id="sec-4">
      <title>Değerlendirme</title>
      <p>Önerdiğimiz yöntem ve geliştirmiş olduğumuz araçların etkinliğini test etmek ve
sürecin manuel bir şekilde hazırlanmasına kıyasla ne kadar kolaylık getirdiğini
ölçmek için programlama konusunda deneyimi az olan kişilerin katılımıyla kontrollü
bir deney gerçekleştirdik.</p>
      <p>Hipotezimiz, bir sistem üzerinde geliştrdiğimiz araçları kullanarak MBT
uygulandığında sürenin manuel olarak uygulandığından daha kısa sürdüğü üzerinedir.</p>
      <p>Kontrollü deneyimizi, değişkenleri en aza indirmek amacıyla programlama ile
alâkalı derslerden en çok iki tane alan ve not ortalaması 2.80 üzerinde olan (14 adet)
Endüstri Mühendisliği dördüncü sınıf öğrencileri ile aynı bilgisayar ortamında ve aynı
web uygulaması üzerinde gerçekleştirdik.</p>
      <p>Deneyde, katılımcılar rastlantısal bir şekilde eşit sayıda iki gruba ayrılmıştır. İlk
gruptan öncelikle modelin ve test senaryolarının manuel olarak oluşturulması
istenmiştir. Sonrasında ise aynı işlemin, geliştirilen araçlar yardımıyla yapılması
istenmiştir. İkinci grupta yer alan öğrencilerden ise tam tersi sırada bu işlemlerin
gerçekleştirilmesi istenmiştir. Yani, ikinci grup ilk olarak araç yardımı ile, sonradan
ise manuel bir şekilde işlemleri gerçekleştirmiştir.</p>
      <p>Deney sırasında işlemlerin gerçekleştirilme süreleri ölçülmüştür6. Ölçülen süreler
Tablo 1’de gösterilmektedir.</p>
      <p>Tablo 1’de görüldüğü üzere, araç yardımı olmadan yapılan işlemlerde ulaşılan en
kısa süre 47 dakika iken geliştirilen araçların yardımı ile bu sürenin 3 dakikaya
düştüğü görülmüştür7.</p>
      <p>Sonuç olarak, geliştirilen araçlar sayesinde sürecin teyit aşaması hariç tamamıyla
otomatikleştirildiği, dolayısıyla süre nezdinde ciddi bir düşüş yaşandığı
gözlemlenmektedir.
6 Süre, programların çalıştırılmasından itibaren test sonuçlarının ekrana bastırılmasına kadar
olan kısmı kapsamaktadır.
7 Araçlar yardımıyla tamamlanan test sürecinin kayıtlarına http://youtu.be/8VQVu59J-Jo
adresinden ulaşmak mümkündür.</p>
      <sec id="sec-4-1">
        <title>Tablo 1: Deney sonuçları</title>
        <p>Katılımcılar</p>
      </sec>
      <sec id="sec-4-2">
        <title>Geliştirilen araçlar</title>
        <p>kullanılarak8</p>
      </sec>
      <sec id="sec-4-3">
        <title>Geliştirilen araçlar</title>
        <p>kullanılmadan8</p>
        <sec id="sec-4-3-1">
          <title>Grup 1</title>
        </sec>
        <sec id="sec-4-3-2">
          <title>Grup 2</title>
        </sec>
        <sec id="sec-4-3-3">
          <title>Denek 1</title>
          <p>Denek 2
Denek 3
Denek 7
Denek 8
Denek 9
Denek 10</p>
        </sec>
        <sec id="sec-4-3-4">
          <title>Denek 4</title>
          <p>Denek 5
Denek 6
Denek 11
Denek 12
Denek 13
Denek 14</p>
          <p>Sürenin yanı sıra, araçların otomatik olarak test senaryolarını üretmesi, testlerin
kapsamında da bir artışa neden olmuştur. Manuel yapılan testlerde katılımcıların
büyük bir çoğunluğunun bir kaç düğümü modele eklemeyi unutmuş olduğu
gözlemlenmiştir. Öte yandan geliştirilen araçlar aracılığıyla yapılan denemelerde, web
uygulamasında yer alan elemanların9 otomatik olarak ayıklanıp diagrama otomatik
olarak yerleştirilmesinden dolayı bu tarz sorunlarla karşılaşılmamıştır.</p>
          <p>Görüldüğü üzere, geliştirilen araçlar sayesinde test senaryolarının daha çok durumu
kapsadığı ve manuel işlemler sırasında yapılabilecek hataların engellendiği
gözlemlenmiştir.</p>
          <p>Gerçekleştirdiğimiz kontrollü deneyde az sayıda kişiler ile denemeler yapmış
olmamıza rağmen test otomasyon yaklaşımımızın potansiyel faydalarını gösteren
sonuçlar elde edilmiştir.</p>
          <p>bölümde,
literatürde
yayınlanmış
diğer
ilgili
çalışmalar
Literatürde MBT üzerine yazılmış çok sayıda vaka çalışmaları bulunmaktadır [5].
[6] gibi mobil uygulamalarının GUI’si üzerine ya da [7] gibi yazılımların GUI’si
üzerine yazılmış bir çok MBT uygulaması görmek mümkündür. Ama Li et al. [8]’un</p>
        </sec>
        <sec id="sec-4-3-5">
          <title>8 Süre dakika:saniye olarak belirtilmiştir.</title>
          <p>9 Bahsedilen düğümler sadece “id” ve “name” niteliklerini içeren elemanlardan oluşmaktadır.
araştırmasından da görülebileceği üzere model bazlı test yaklaşımıyla alâkalı yazıların
oranı biraz düşük durumdadır.</p>
          <p>Ricca ve Tonella [9], Web uygulamalarının üst düzey soyutlaması için UML
modelleri sunmuşlardır. Sunulan bu modeller tamamıyla statik HMTL linklerinden
oluşuyor ve herhangi bir Web uygulaması UML modelinin bir oluşumu olarak
varsayılıyor. Model, HTML linklerinden oluşan statik bir çizim ve URL’den oluşan
test senaryolarını oluşturan iki araçla desteklenmiştir. Araçlardan analiz yapmakla
sorumlu olan ReWeb, bu işlemi gerçekleştirmek için bütün ulaşılabildiği Web
sayfalarını indirmekte ve ilerleyen aşamalarda bunları testi uygulayan kişi
birleştirmektedir. Bu yönüyle Beyaz Kutu (white-box) yaklaşımını sergilemektedir.
Öte yandan bizim çalışmamızda Web uygulamasının herkese açık olan kaynak
kodundan model üretilmektedir ve herhangi bir indirme işlemi de bulunmamaktadır.
Dolayısıyla da testi gerçekleştiren kişi herhangi bir birleştirme işlemi yapmamaktadır.
Ayrıca ikinci araç olan ve testlerden sorumlu TestWeb’de test senaryolarında
girdilerin manuel bir şekilde girilmesi gerekmektedir. Bu yönüyle bizim çalışmamıza
kısmen benzemektedir fakat gene de bizim çalışmamızda öncelikle rastlantısal olarak
üretilen değerler kullanılmakta, gerekirse de testi gerçekleştiren kişinin müdahelesi
gelmektedir. Ama test senaryolarının başarılı/başarısız olduğu, Ricca ve Tonella’nın
çalışmasında testi gerçekleştiren kişi tarafından yapılırken, bizim çalışmamızda bu
işlem tamamen otomatik yapılmaktadır.</p>
          <p>Yang et al. [10] [11] Web uygulamalarını test etmeye yönelik geliştirilen test
araçları için beş alt sistemden (geliştirme, ölçme, uygulama, başarısızlık analizi,
yönetim) oluşan bir yapı önermişlerdir. Bu alt sistemlerden ikisi Anderews et al. [12]
tarafından karşılanmaktadır. Bizim çalışmadaki sonlu durum makinaları ile yapılan
modelleme üstte bahsedilen çalışmalar ile ortak özellik göstermektedir. Ama bizim
çalışmamız özellikle varolan bir aracın hızlandırılması üzerine iken bu çalışmalar yeni
birer araç ya da yapı oluşturmayı hedeflenmiştir.</p>
          <p>Qian et al. [13] ise Web uygulamalarını muhtemel sonlu durum makinaları
(Probable Finite State Machine – PFSM) ile test ederek MBT yaklaşımına olasılığı da
katmıştır. Ama burada model tamamen manuel olarak oluşturulmak zorundadır.</p>
          <p>Bir başka çalışmada [14] model üretmek yerine XML üzerinde yazılmış test
senaryolarını çalıştırılmıştır. Bu çalışmada test senaryoları sistem üzerinde otomatik
bir şekilde çalıştırılabilmektedir. Fakat bu senaryolar bir model baz alınarak
oluşturulmamaktadır; her biri manuel bir şekilde tanımlanmaktadır.</p>
          <p>GraphWalker aracı daha önceden MBT sürecini uygulamak üzere kullanılmıştır
[15]. Fakat bu çalışmada daha çok çevik yazılım geliştirme süreci kapsamındaki MBT
uygulama yöntemlerine odaklanılmıştır. Model oluşturma süreci ve oluşturulan test
senaryolarının otomatik çalıştırılması üzerine bir çalışma yapılmamıştır.</p>
          <p>Bu bildiride, MBT için geliştirilmiş bir araç olan GraphWalker, Web uygulamaları
için test sürecini iyileştirmek üzere farklı araçlar ile bir arada kullanılmıştır. MBT
sürecinde manuel olarak yapılması gereken, fakat (kısmen) otomasyon desteği
sağlanabilecek aktiviteler bulunmaktadır. Öncelikle bu aktiviteler tespit edilmiş ve bu
aktivitelerin otomasyonu için mevcut araçlar kullanılmış ve yeni araçlar
geliştirilmiştir. Bir araya getirilen farklı araçlar sayesinde, test oluşturma hızı artarken
harcanan zaman ve çaba düşmüştür. Buna ek olarak, bu araçlar sayesinde program
yazma ihtiyacı ortadan kalkmış, programlamaya dair az veya hiç bilgisi olmayan
insanlar için de model ve test oluşturma, testleri otomatik çalıştırma imkânı
sunulmuştur.</p>
          <p>Gelecekte yapılacak çalışmalar için bu araçların geliştirilmesi ve GraphWalker’ın
Selenium ile içiçe nasıl daha etkin bir şekilde çalışacağı araştırılabilir. Bunun yanında,
model oluşturma aşamasında makine öğrenme teknikleri ile otomasyonun artırılması
da ilerisi için üzerinde durulabilecek araştırma konuları arasındadır.</p>
          <p>Teşekkür
Gerçekleştirdiğimiz deneye katılımlarından ötürü Özyeğin Üniversitesi Endüstri
Mühendisliği öğrencilerinden B. Uydaşoğlu, C. Özeltürkay, E. Elmas, F. Yorgancı,
J. Aras, M. Boncuk, N. Altundağ, R. B. Parlar, S. Aşıtepe, S. Alkaya, T. Balcı,
T. Özcan, T. Pınar ve Y. Yurd’a teşekkür ederiz.
Ek Bölüm
package org.myorg.testautomation;
import org.graphwalker.core.condition.ReachedVertex;
//Truncated
public class DemoTest extends ExecutionContext implements Demo {
public final static Path MODEL_PATH =
Paths.get("org\\myorg\\testautomation\\Demo.graphml");
private WebDriver driver;
private String baseUrl;
public void setUp() {
driver = new FirefoxDriver();
baseUrl = "http://localhost:801/";
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
driver.get(baseUrl + "/xampp/CS401Website/");
}
@Override
public void e_v_type_name_firstname() {
driver.findElement(By.name("firstname")).clear();
driver.findElement(By.name("firstname")).sendKeys("Testi");
}
@Override
public void v_type_name_firstname() { // No need to fill. }
@Override
public void v_type_name_firstnameLink() { // No need to fill. }
//Truncated
@Test
public void runFunctionalTest() {
new TestBuilder()
.setModel(MODEL_PATH)</p>
          <p>.setContext(new DemoTest())
.setPathGenerator(new RandomPath(new EdgeCoverage(100)))
.setStart("e_Start")</p>
          <p>.execute();
}
@Test
public void runStabilityTest() {
new TestBuilder()
.setModel(MODEL_PATH)
.setContext(new DemoTest())
.setPathGenerator(new RandomPath(new TimeDuration(30,
TimeUnit.SECONDS)))
.setStart("e_Start")
.execute();
}
Şekil 4: Test Creator aracının oluşturduğu, test adımlarını içeren sınıf
15.</p>
        </sec>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list />
  </back>
</article>