Gerçek Zamanlı Dağıtık Sistemlerde Test Yaklaşımı

Gerçek Zamanlı Dağıtık Sistemlerde Test Yaklaşımı Testing Approach in Real-Time Distributed Systems Volkan BEYAZGÜN Lider Yazılım Test Mühendisi, MilSOFT Yazılım Teknolojileri A.Ş., ODTU Teknokent Ankara, vbeyazgun@milsoft.com.tr Hüseyin KUTLUCA Lider Yazılım Mühendisi, MilSOFT Yazılım Teknolojileri A.Ş., ODTU Teknokent Ankara, hkutluca@milsoft.com.tr Ömer Faruk MORALIOĞLU Yazılım Test Mühendisi, MilSOFT Yazılım Teknolojileri A.Ş., ODTU Teknokent Ankara omoralioglu@milsoft.com.tr Özet MilSOFT tarafından 2004 yılında gerçekleştirilmeye başlanan Gemi Komuta Kontrol Sistemi (diğer adıyla Savaş Yönetim Sistemi SYS) Yazılımı (GEMKOMSİS) ARGE projesi gerçek zamanlı dağıtık bir mimariye sahiptir. Bu proje kapsamında iz yönetimi, muharebe yönetimi ve bunun gibi diğer modüllerle birlikte DDS (Data Distribution Service) arakatman yazılımı da geliştirilmiştir. DDS Arakatmanı temel olarak veri merkezli (data centric) ve yayımla-abone ol (publish-subscribe) mimarisine dayalıdır [1,2]. Bu sistem için test yaklaşımının belirlenmesi sırasında, yazılım mimarisinin yapısı ve DDS arakatman yazılımının özellikleri belirleyici olmuştur. DDS arakatmanını kullanan her bir yazılım modülünün ayrı ayrı test edilebilmesi için, DDS Spy test aracı geliştirilmiştir. DDS Spy, sistemde bulunan tüm modülleri ve onların yayımladığı ve/veya abone olunan verilerin izlenmesi ve test amaçlı olarak ihtiyaç duyulan verilerin tekrar sisteme verilebilmesini sağlamaktadır. DDS Tester aracı ile de bu işlemlerin otomatik bir şekilde yapılarak test otomasyonunun sağlanması hedeflenmiştir. Dağıtık sistem testlerinde; konfigürasyon birimi testleri (ya da modül testleri), entegrasyon testleri ve sistem testlerinin her birinin ayrı bir önem taşıdığı görülmektedir. Test yaklaşımında da buna uygun test stratejilerinin ve yöntemleri ile ilgili test araçlarının planlanması ve kullanılması çok kritik bir konudur. Abstract GEMKOMSİS R&D Project which has been developed since 2004 has a real-time distributed system architecture. In this project scope, DDS middleware application is also developed in addition to many other software components like track management, warfare, and etc. DDS middleware is mainly data centric and is based on publish-subscribe architecture [1,2]. Software architecture and DDS middleware features affected the identification of testing approach for this system. DDS Spy test tool is developed, for testing each software module of this system separately using this middleware. This tool provides monitoring of participating applications and the data that each application publishes/subscribes and also injects the data to the system for testing purposes. By DDS Tester application automation of these tasks are aimed leading to test automation. It has been observed that in distributed systems testing, each of configuration item (CSCI) tests, integration tests, and system tests has individual role and importance. Planning and utilization of suitable test strategies, methods, and related test tools for determining the test approach is a vital issue. 1. Giriş Gerçek zamanlı dağıtık sistemlerde, birlikte çalışabilirlik, hataya dayanıklılık, güvenirlik, uyumluluk, senkronizasyon, zamanlama ve performans gibi kalite öznitelikleri bulunmaktadır. Bu kalite öznitelikleri kalite servisi (QoS) ile ilişkilidir [3]. Test genellikle zaman alıcı ve maliyetlidir; dağıtık sistemlerin testleri özellikle zordur çünkü birçok uygulama aynı anda çalışmakta olduğundan mesaj aktarımında ve senkronizasyonda problemler yaşanabilir [3]. Dağıtık gerçek zamanlı bir sistemin, doğru zamanda doğru davranışı göstermesi gerekmektedir. Birbiriyle etkileşimli olan uygulamaların tekrar edilebilir ve kararlı bir şekilde test edilebilmesi için, test girdilerinin zamanlamasının da kontrol edilebilmesi çok önemlidir [4]. Bu özellikleri ile gerçek zamanlı dağıtık bir sistemdeki test yaklaşımının, gerçek zamanlı ve dağıtık olmayan bir yazılım sisteminden farklılıklar göstermesi doğaldır. Dağıtık sistemlerde, birçok uygulama bir arada çalışırken her bir uygulamanın sistem içerisinde bir rolü bulunmaktadır. Bir fonksiyonun gerçekleştirilmesi sırasında görev alan yazılım birimlerinin öncelikle ayrı ayrı test edilmesi ve her bir yazılım biriminin üzerine düşen görevi tam olarak yerine getirdiğinden emin

olduktan sonra birlikte çalışmalarının kontrol edilmesi, daha çok hatanın tespit edilebilmesi ve hataların kaynağının daha rahat bulunabilmesi açılarından önemlidir. Entegrasyon ve sistem testleri ile de sistemi oluşturan yazılım birimlerinin, birlikte çalışmaları sırasında karşılaşılabilecek olan hataların tespiti hedeflenmektedir. MilSOFT 2004 yılında başlattığı GEMKOMSİS ARGE projesi kapsamında DDS (Data Distribution Service) arakatmanını geliştirmiştir [1]. DDS arakatmanı, OMG (Object Management Group) tarafından gerçek zamanlı sistemler için hazırlanmış ve Haziran 2004 te yayımlanmış olan bir arakatman yazılımı standardıdır. DDS standardı; veri merkezli veri alışverişi, Yayımla- Abone ol (Publish-Subscribe) mimarisi ile veri üreticisi ile kullanıcısı arasında bağımsızlık sağlarken, gerçek zamanlı ve hataya dayanıklı sistem altyapısı ve genişleyebilir sistem yapısını da desteklemektedir. DDS standardı, halen bu konuda söz sahibi olan Thales Hollanda, RTI, MITRE, Amerikan Deniz Kuvvetleri gibi sayılı firma/kuruluşların da geçiş yapmakta olduğu/yaptığı bir standarttır. GEMKOMSİS projesinde, mimarinin en önemli unsurlarından biri olan arakatman ihtiyaçlarını karşılamak için özellikle veri dağıtımı seviyesinde DDS standardı referans alınarak, MilSOFT DDS arakatmanı geliştirilmiştir (Şekil 1)[5]. Şekil 1: MilSOFT DDS Arakatmanı ve Araçları DDS arakatmanı kullanılması ile sistem içerisinde yer alan uygulamalar, birbirlerinden bağımsız olarak çalıştırılabilmekte ve fonksiyonlarını yerine getirmek için sadece diğer kaynaklardan gelecek olan verileri kullanmaktadırlar. Bu yaklaşım ile sistemi meydana getiren uygulamalar birbirlerinden tamamen bağımsız olarak test edilebilmektedirler. Bölüm 2 de GEMKOMSİS Projesi nde uygulanan yazılım geliştirme süreci anlatılmıştır. Birim ve birim entegrasyon testleri Bölüm 3 de ele alınmıştır. Yazılım konfigürasyon birimi testleri Bölüm 4 de detaylı bir şekilde incelenmiştir. Entegrasyon ve sistem testleri ile ilgili bilgi Bölüm 5 de verilmiştir. 2. Spiral Yazılım Geliştirme Süreci ve Testin Spiral Yazılım Geliştirme Sürecindeki Yeri GEMKOMSİS projesi kapsamında Spiral Yazılım Geliştirme Yaşam Döngüsü (SYGYD) kullanılmıştır. SYGYD yayım (release), yinelemeye (iteration) ve aşamalı olarak sürekli entegrasyona dayalı bir süreçtir [6]. Her yayım / yinelemede geliştirilen sistem / yazılım özelliklerine paralel olarak test durumları bağımsız test mühendisleri tarafından gereksinimlerden (kullanım durumlarından) yola çıkılarak hazırlanmaktadır. Bir özelliğin, kodlanmasının ardından, birim ve birim entegrasyon testleri yazılım mühendisleri tarafından gerçekleştirilmektedir. Birim entegrasyon testlerinden sonra, yazılım konfigürasyon birimi testleri bağımsız test mühendisleri tarafından yapılmakta ve testler sırasında karşılaşılan hatalar Mantis hata takip aracı ile raporlanmaktadır. SYGYD de, belirli periyotlarda geliştirilen özellikler entegre edilmekte ve bu özellikler ile ilgili entegrasyon ve sistem testleri yapılmaktadır. Yayım / yineleme süreci içerisinde, her bir test aşamasında test mühendisleri tarafından raporlanan hatalar, lider yazılım mühendisleri tarafından ilgili yazılım mühendisine atanmaktadır. Yazılım mühendisleri tarafından düzeltilen hatalar, test mühendisleri tarafından tekrar kontrol edilmekte ve düzeldiği gözlenen hata kayıtları kapatılmaktadır. Her bir yayım periyodunun son yinelemesi entegrasyon ve test amaçlı olarak planlanmaktadır. Bu yinelemede, yayım süreci içerisinde gerçekleştirimi (implementation) yapılan özellikler ile birlikte tüm sistem özelliklerinin yazılım konfigürasyon, entegrasyon ve sistem testleri gerçekleştirilmektedir. Bu testlerin sonucunda ilgili yayımın başarı durumu tüm proje grubu personelinin katılımıyla değerlendirilmektedir. Yazılım geliştirme süreci içerisinde yayım/yineleme temelli olarak yapılan bu işlemler, sistemdeki hataların önceden tespit edilip, giderilmesi açısından önemlidir. 3. Birim ve Birim Entegrasyon Testleri Gerçek zamanlı dağıtık sistemler olan Savaş Yönetim Sistemleri nde (SYS) yer alan modüllerin sayıca fazla olması nedeniyle, modüllerin yapılandırılmaları (build), birim ve birim entegrasyon testlerinin [7] koşturulması işlemleri çok zaman almaktadır. Bu nedenle yapılandırma ve birim testlerinde, otomasyonu sağlayacak araçların (yapılandırma için Cmake, Maven

2 ve LuntBuild; birim testleri için CPPUnit ve Junit) kullanılması bir zorunluluk haline gelmiştir. Yapılandırma ve birim testleri için kullanılacak araçların seçiminde organizasyonel seçim kriterlerinin kullanılmasına önem verilmektedir. Bu sayede farklı projelerde benzer araçların kullanılması ve böylece araç konusunda oluşan deneyim ve araç özgünleştirmelerinden (scripts gibi) yararlanılabilmesi sağlanmaktadır. Birim ve birim entegrasyon testleri, yapılandırma aracına entegre edilerek, bu testlerin otomasyonu sağlanmakta ve yapılandırılan modülün konfigürasyon birimi testlerine hazır hale getirilmesi hedeflenmektedir. 4. Yazılım Konfigürasyon Birimi Testleri SYS de yer alan ve başka birimlerden bağımsız olarak bir sistem özelliğini (feature) gerçekleştirebilen yazılım bütünü konfigürasyon birimi (CSCI) olarak adlandırılmaktadır. GEMKOMSİS Sistemi nde kullanıcı arayüzü ya da İnsan Makina Arayüzü (İMA) de ayrı bir konfigürasyon birimi olarak belirlenmiştir. Bunun en büyük nedeni İMA nın, farklı platformlarda en çok değişime uğrayabilecek olan birimlerden biri olmasıdır. Daha çok sistemdeki hesaplamaları yapan ve kullanıcı arayüzüne veri sağlayan birimler (iz yönetimi, alarm yönetimi, seyir yönetimi gibi) ise platformdan platforma fazla değişime uğramamaktadırlar. Kullanıcı arayüzü ve kullanıcı arayüzü olmayan (arka plan uygulamaları) birimlerin testlerinin ayrılması, farklı platformlara geçiş yapılması durumunda yeniden kullanılan ortak servis ve fonksiyonlardan ötürü iyi ayırt edilmiş olması durumunda daha az test eforunun harcanmasını sağlayacaktır. Yazılım konfigürasyon birimlerinin ayrı ayrı test edilebilmesi ve birimlerin fonksiyonları gerçekleştirebilmeleri için kullanacakları veri ihtiyaçlarının farklı bir kaynaktan sağlanması ve aynı zamanda birimlerinin işlevlerini gerçekleştirmelerinin sonucu olarak oluşturdukları verileri gözlemleyebilmek gerekmektedir. Bu ihtiyacın karşılanması için GEMKOMSİS Projesi kapsamında DDS Spy test aracı geliştirilmiştir. DDS Spy test aracı (Şekil 2) ile o anda ağ üzerinde bulunan uygulamalar ve bu uygulamaların yayımladıkları ve dinledikleri DDS mesajları gözlemlenebilmekte ve ayrıca uygulamaların test edilebilmesi için gereken DDS mesajları ağ ortamında iletilebilmektedir. Test verileri, test mühendisleri tarafında Microsoft Office Excel formatında hazırlanmakta ve kaydedilmektedir. Bu format farklı platformlardaki araçlar (Open Office, Star Office vb.) tarafından da desteklenmekte olduğundan farklı platform testlerinde de hazırlanan bu test verileri kullanılabilmektedir. Veriler uygulamaya kopyala/yapıştır ve dosya yükleme şeklinde aktarılabilmektedir. Verilerin hazırlanması sırasında verilerin gönderilme zamanları mili saniye hassasiyetinde önceden belirlenmekte ve kaydedilmektedir. Hazırlanan bu test verileri ile testlerin yeniden koşturulması ve hata koşullarının yeniden oluşturulmasını kolaylaşmaktadır. Uygulamalar için aynı ön koşulların oluşturulması ve aynı test girdilerinin uygulanması durumunda, her zaman için aynı sonuçlara ulaşılabilmesi ve bu durumun sağlanabilirliği her test tekrarında yeniden tecrübe edilebilmektedir. DDS Spy, DDS arakatmanını kullanması nedeniyle, veri tabanlı bir uygulamadır. Test edilecek uygulama için veriyi gönderen kaynak önemli olmadığı gibi, DDS Spy içinde gönderilen veriyi alanın bir önemi yoktur. Bu nedenle test edilecek olan uygulamaların mesaj alış verişi içerisinde olduğu uygulamalar DDS Spy ile kolaylıkla simüle edilmekte ve izole (uygulamanın sistemde mesaj alış verişi yaptığı diğer yazılım birimleri kullanılmadan) bir şekilde test yapılması sağlanmaktadır. DDS Spy ın bir diğer önemli özelliği ve benzer test araçlarından farkı da, testleri tasarlayan ve uygulayan kişilerin herhangi bir yazılım aracı kullanma ve test kodu hazırlama ihtiyaçlarının olmamasıdır. Bu sayede hazırlanan test verileri, sadece yazılımın mesaj arayüzüne (DDS topic) bağımlı olmakta ve yazılım içerisinde yapılan değişikliklerden etkilenmemektedir. Test kodu yazılarak uygulanan test yaklaşımında, bir süre sonra test için ayrılan zamanın çoğunluğu test kodunun bakımı için harcanmakta bu da yapılan testlerin yaratıcılığını ve kalitesini düşürdüğü gözlenmektedir [8]. Şekil 2: DDS Spy

Arka plan uygulamalarının testleri sırasında, test girdileri ve çıktıları test verileri olarak önceden hazırlanmaktadır. Test sırasında, test girdileri DDS Spy ile uygulamalara gönderilmekte, uygulamalar tarafından oluşturulan veriler ise önceden hazırlanan test sonuçları ile otomatik olarak karşılaştırılmaktadır. DDS Spy ile gerçek zaman bilgisi gönderilen mesajlardaki ilgili alanların içerisine eklenebilmektedir. Bu şekilde test edilecek uygulama kara kutu (black box) olarak görülmekte, uygulamanın sistem içerisinde gerçek zamanlı olarak veri aldığı uygulamalar DDS Spy ile simüle edilebilmektedir. DDS Spy aracı sistem ağı içerisinde herhangi bir düğümde çalışabilmektedir. GEMKOMSİS Sistemi nde düğümler arası zaman senkronizasyonu NTP (Network Time Protocol) ile sağlanmakta olduğundan DDS Spy aracında ayrıca bir senkronizasyona ihtiyaç duyulmamaktadır. İMA testlerinde ise, test girdileri kullanıcı arayüzünden girilmekte, İMA tarafından oluşturulan sonuçlar (DDS mesajları) DDS Spy ile görüntülenmektedir. Kullanıcı arayüzünün diğer sistem birimlerinden alması gereken veriler de DDS Spy ile test girdisi olarak test mühendisi tarafından gönderilmektedir. DDS Spy ile uygulamaların manuel olarak test edilmesi sırasında kolaylık sağlanmıştır. Ancak, özellikle SYS lerin, yazılım açısından büyük (milyonlarca satır) olması, test koşum sürelerinin de artmasına neden olmaktadır. Spiral yazılım geliştirme sürecinin bir gereği olarak da her yayımda (2-3 ayda bir) testlerin tekrar edilmesi gerekmektedir. Test sürelerinin azalması için, test otomasyonu kaçınılmaz olarak karşımıza çıkmaktadır. GEMKOMSİS için test otomasyonu; DDS Spy ile kullanıcı tarafından girilen test verilerinin kopyalanması, gönderilmesi ve gözlemlenerek test sonuçları ile karşılaştırılması işlemlerinin otomatik olarak yapılmasından oluşmaktadır. Şekil 3: DDS Tester DDS Tester aracının temel özellikleri arasında, önceden hazırlanmış olan test verilerinin otomatik olarak test edilen uygulamaya gönderilmesi, uygulama tarafında üretilen sonuçlar ile yine daha önceden hazırlanmış olan beklenen test sonuçlarının otomatik olarak karşılaştırılması (karşılaştırılan alanlar için değerlendirme kriterlerinin girilebilmesi), test sonucunda test raporlarının üretilmesi sayılabilir. DDS Spy uygulamasında ise tüm bu işlemler testi uygulayan kişi tarafından manuel olarak yapılmaktadır. DDS Tester (Şekil 3) uygulaması ile kullanıcı, DDS Spy uygulaması için daha önceden hazırlamış olduğu test verilerini yeniden kullanabilmektedir. DDS Tester ile kullanıcı arayüzü olmayan uygulamaların test otomasyonu başarılı bir şekilde sağlanmıştır. Kullanıcı arayüzü olan uygulamalarda ise test veri girişi sadece DDS Tester ile sağlanamamaktadır. Bu durumda, kullanıcı arayüzüne veri girişi için ayrı bir uygulama kullanılması gerekliliği ortaya çıkmaktadır. Test otomasyonunun ise bu iki uygulamanın senkronize bir şekilde çalıştırılması ile sağlanması planlanmaktadır. Test otomasyonu faydalı olsa da, her özelliğin bu yöntemle test edilmesi mümkün olmamaktadır. Bu nedenle test otomasyonunun mümkün olan her aşamada kullanılması ve sadece test otomasyonunun mümkün olmadığı durumların manuel yöntemlerle yapılması uygun olacaktır. Test otomasyonunun test hazırlama sürelerini arttıracağı ve testlerin yeniden koşturulması durumlarında fayda sağlayacağı unutulmaması gereken başka bir konudur. Manuel testler için DDS Spy ın ve otomatik testler için de DDS Tester ın kullanılması konfigürasyon birimi testlerinde ihtiyacı tam olarak karşılamaktadır. Konfigürasyon birimi testleri hazırlanırken, yazılım seviyesi kullanım durumlarından (use case) faydalanılmaktadır. Oluşturulan test verilerinde, verinin test edilecek uygulamaya gönderilme zamanları kontrol edilerek bir senaryo akışı da yaratılabilmektedir. Böylelikle bağımsız olarak test edilen konfigürasyon biriminin, sistem entegre edildiğinde karşılaşacağı birbirini takip eden veri yapısı ile olan davranışı da önceden gözlemlenebilmektedir. Konfigürasyon birimi seviyesinde bağımsız test yapmanın en büyük avantajlarından biri de sistem seviyesinde nadir olarak karşılaşılan ve yaratılması zor olan koşulların kolay bir şekilde oluşturulabilmesi ve olası yazılım problemlerinin entegrasyon ortamına taşınmadan giderilmesine imkan sağlamasıdır. 5. Entegrasyon ve Sistem Testleri

Konfigürasyon birimi testlerinin başarılı bir şekilde tamamlanmasının ardından, bu birimler bir araya getirilerek öncelikle entegrasyon testleri gerçekleştirilmektedir. Entegrasyon testlerinde birimlerin mesaj alış verişlerini düzgün bir şekilde gerçekleştirmesi kontrol edilmektedir. GEMKOMSİS de ortam verilerinin sisteme beslenmesi için test amaçlı bir senaryo editörü ve oynatıcı (Şekil 4) kullanılmaktadır. testlerinin hazırlanması sırasında daha az efor harcanmaktadır. Sistem testlerinde ayrıca operasyonel konsept dokümanında yer alan senaryolardan da faydalanılmaktadır. Gerçek sistem (radar, elektro optik vb) verilerinin temin edilmesi durumunda bu verilerin sisteme veri kaynağı olarak sağlanarak ilgili testlerin yapılması da sistem testlerinde mümkün olabilmektedir. Entegrasyon ve sistem testlerinde bulunan hataların tespit edilmesi (debug) sırasında DDS Spy aracından da faydalanılmaktadır. Sistemin test senaryolarını oluştururken, operasyonel konsepte hakim olmak ve bir operatörün gözüyle sisteme bakmak, sistemdeki hataların büyük ölçüde tespiti ve giderilmesi için önemlidir. Test yaklaşımındaki temel hedef sistemin bütün operasyonel gereksinimleri tam olarak karşıladığının geçerlenmesi (validation) ve sistemin çalışmasının güvenilir bir şekilde sürdürüldüğünün doğrulanması (verification) olmalıdır. 6. Sonuç Şekil 4: Senaryo Editörü ve Oynatıcı Senaryo editörü ve oynatıcı ile hava, suüstü vb. izlerini içeren senaryolar hazırlanarak, gerçek dünyaya yakın bir sanal ortam yaratılmaktadır. Entegrasyon testlerinde, senaryo verileri ile birlikte sistemi oluşturan birimlerin mesaj alış verişlerinin doğrulanması sistemin temel özelliklerini kullanarak uygulama detayına inilmeden test edilmektedir. Entegrasyon testi ile, konfigürasyon birimi testlerinde gözlemlenemeyen, birimler arası mesaj alış verişinden kaynaklanan hataların tespit edilmesi ve giderilmesi hedeflenmektedir. Entegrasyon testlerinden sonra, sistem özelliklerinin doğrulandığı sistem seviyesi testler uygulanmaktadır. Konfigürasyon birimi testlerinde, yazılım özellikleri detaylı bir şekilde test edilmekte; nominal girdi testleri, hatalı girdi testleri, sınır değeri testleri gibi test yöntemleri uygulanmaktadır. Sistem seviyesi testlerde bu nedenle daha çok sistem davranışını gözlemlemek, sistemin operasyonel olarak doğru çalışıp çalışmadığını, sistemin uzun süreli ve zor koşullarda çalışmasını sistemdeki performans kriterleri ile birlikte doğrulamak hedeflenmektedir. Sistem testlerinde ortam verilerini simüle etmek için senaryo editörü ve oynatıcı ile alt sistem simülatörleri kullanılmaktadır. Konfigürasyon testlerinde hazırlanmış olan veri bazlı senaryolar, senaryo editörü ve oynatıcı ile gerçek sistem senaryolarına dönüştürülebilmektedir. Bu sayede sistem Bu makalede, gerçek zamanlı dağıtık bir sistem olan ve MilSOFT tarafından 2004 yılında geliştirilmeye başlanan GEMKOMSİS te uygulanan test yaklaşımı ve bu test yaklaşımı için düşünülen iyileştirme ve geliştirme kabiliyetlerinden bahsedilmiştir. Özellikle DDS gibi bir arakatman kullanan gerçek zamanlı dağıtık sistemlerde, tekrar edilebilir testlerin otomatik olarak koşturulabilmesinin önemi vurgulanmıştır. Milyonlarca satır büyüklüğündeki ve dağıtık yapıdaki SYS lerinde yazılım geliştirmenin her aşamasında testlerin yinelenmesi ve sonuçların otomatik olarak oluşturulması kritik bir isterdir. Bunu karşılamak yönünde test stratejileri proje başında oluşturulmalı ve gerekli test ortamı ve araçları gerektiğinde geliştirilerek entegre edilmelidir. GEMKOMSIS te manuel test uygulama için harcanan zaman konfigürasyon birimi testleri için 280 saat civarındadır. Sistemin farklı işletim sistemlerinde çalışması da göz önüne alınır ise bu sürelerin büyük bir efora neden olduğu görülmektedir. Otomatik test yaklaşımında, test koşturma sürelerinin çok daha kısa olması ve testlerin herhangi bir müdahaleye gerek duyulmadan çalışma saatleri dışında da koşturulabilmesinden dolayı efor kazancı oldukça büyüktür. Yazılım konfigürasyon birimi testleri için uygulanan test otomasyonunun, kullanıcı arayüzü, sistem

entegrasyon ve sistem testleri için de başarılı bir şekilde uygulanabilmesi ve birim testleri gibi yapılandırma süreci ile entegre edilmesi, hedeflenen işler arasında yer almaktadır. Bu konuda, otomatik IMA test araçları incelenmekte ve bu araçların DDS Spy ve DDS Tester ile entegrasyonu konusunda çalışmalar devam etmektedir. Gerçek Zamanlı Dağıtık Sistem testlerinde, konfigürasyon, entegrasyon ve sistem testlerinin her birinin ayrı bir önemi vardır. Sistemin kararlı bir yapıya kavuşması, sistemdeki hataların büyük ölçüde giderilmesi ve sistemin güvenilir bir şekilde kullanılabilmesi için her bir test aşamasının titizlikle tamamlanması gerekmektedir. 7. Kaynaklar [1] MilSOFT, (2006), MilSOFT DDS Middleware, http://dds.milsoft.com.tr [2] H.Kutluca, İ.E.Çetin, E.Deniz, B.Bal (2007), MilSOFT DDS Arakatmanı ve DDS in Savaş Yönetim Sistemlerinde Simülasyon Amaçlı Kullanımı USMOS 2007, Ankara, Türkiye [3] W. T. Tsai, L. Yu, A. Saimi, Scenario-Based Object-Oriented Test Frameworks for Testing Distributed Systems [4] Henrik Thane and Haris Harisson, Towards Systematic Testing of Distributed Real- Time Systems 20th IEEE Real-Time Systems Symposium (RTSS, 1999) [5] H. Kutluca, İzzet Emre Çetin, Uğur Çakır, Murat Kılıç (2008), GEMKOMSİS Savaş Yönetim Sistemi Yazılımının AR-GE Projesi Olarak Geliştirilmesi, Deniz Platformları için Sunduğu Ortak Altyapı ve Sahil Güvenlik Arama Kurtarma Gemisi Uygulaması, YKGS 2008 [6] Boehm B A Spiral Model of Software Development and Enhancement,IEEE, 21(5):61-72, May 1998 [7] Ilene Burnstein, Practical Software Testing-A Process Oriented Approach [8] Steve Splaine, Positioning Your Test Automation Team As A Product Group STAREAST Conference, May 14-18, 2007 Orlando, FL, USA