Execution of unit tests on target platform in embedded software has been a problematic issue due to the causes such as limited ready made test frameworks for embedded platforms, unpractical compile-linkrun loop and dependence to the target platform. If the software component to be tested fulfills necessary conditions, it may be possible that unit tests can be executed on host system instead of target platform and this may be considered as a more practical method. In this paper, using Google Test which is an open source unit test tool, unit tests of an embedded software component are executed on host system and gained experiences are introduced.
yazılımların da bu gereksinimleri karşılaması gerekmektedir. Gereksinimler,
fonksiyonel ve fonksiyonel olmayan gereksinimler olmak üzere iki gruba ayrılabilir.
Hesaplamalar, teknik detaylar, veri idaresi ve işlemesi fonksiyonel gereksinimlerin
kapsamında ele alınır [
Fonksiyonel olmayan gereksinimlerden kaynak kullanımıyla ilgili olanların karşılanması çoğu zaman yazılımın üzerinde koştuğu platforma bağlıdır. Dolayısıyla eğer bu gereksinimler test yapılarak doğrulanacaksa bu testlerin nihai hedef platformda yürütülmesi gereklidir. Fonksiyonel gereksinimlerin testlerle doğrulanması için ise gereksinimlerin gerçeklenme yöntemlerine bağlı olmakla birlikte çoğu zaman testlerin hedef platformda yürütülmesi gerekli değildir. Bu durum, fonksiyonel gereksinimlerin testlerinin ana sistemde yürütülmesine olanak sağlamaktadır.
Fonksiyonel gereklerin karşılandığının tespiti birim testlerle
yapılabilmektedir. Birim test, yazılımda belli bir işlevi yerine getiren kaynak kod birimlerinin
bu işlevi yerine getirdiğinin test edilmesi ve kullanıma hazır olduğunun
tespitidir [
Bir gömülü yazılım bileşeni için oluşturulan birim testlerin yukarıda anlatılan muhtemel sorunların yaşanmaması için ana sistemde yürütülmesi sonucu edinilen tecrübeler ve kazanımlar bu bildirinin esas konusudur. İlerleyen bölümlerde Google Test Aracı tanıtılmış, neden bu aracı seçtiğimizden bahsedilmiş, test edilen gömülü yazılım bileşeni hakkında bilgi verilmiş, test yöntemi aktarılmış ve son olarak bu yöntemle elde edilen kazanımlardan bahsedilmiştir. 2
Google birim test aracı [
EXPECT_TRUE(carp(3,3) == 9); EXPECT_FALSE(carp(4,3) == 12);
EXPECT_EQ(10, carp(3,3)); } carp(x; y) fonksiyonunun aldığı iki argümanı çarparak işlem sonucunu döndüğünü kabul edersek, verilen örnekte, çarpım işlemlerinin doğruluğunu test eden bir test durumu oluşturulmuştur. T EST () makrosunun içine yazılan ilk argüman test durumunun adı, ikinci argüman ise testin adıdır. EXP ECT _T RU E(), içinde yazılan ifadenin doğruluğunu test etmekte ve bir sonraki cümleye geçmektedir. EXP ECT _F ALSE() cümlesi ise EXP ECT _T RU E() cümlesinin mantıksal olarak tam tersi şeklinde işlemekte, test cümlesinde içine yazdığımız ifadenin yanlışlığı kontrol edilmekte ve bir sonraki cümleye geçilmektedir. EXP ECT _EQ() cümlesi de aldığı iki argümanın birbirine eşit olup olmadığını kontrol etmektedir. İlk argüman beklenen değer, ikinci argüman ise gerçek değerdir. Bu cümleden sonra test bitmektedir. Google birim test aracı, test etme işleminde kaç tane test durumunun çalıştırıldığını ve kaç tane testin başarılı olup kaç testin başarısız olduğunu sonuç olarak göstermektedir. Başarılı testler "P ASSED" olarak, başarısız testler ise "F AILED" olarak gösterilmektedir. Testlerin içinde bulunan başarısız test cümleleri için beklenen ve gerçek değer ekranda gösterilerek kullanıcıya yol gösterilmektedir. Ayrıca Google birim test aracı, test durumlarını koşturmadan önce test durumuna özel test koşullarının oluşturulması için kullanıcıya bir “fixture” sınıfı sunmaktadır. Bu sınıfta SetU p() ve T earDown() fonksiyonları sunulmuştur. SetU p() fonksiyonu ilgili test koşmadan hemen önce ve T earDown() fonksiyonu ise testin bitmesinden hemen sonra otomatik olarak çağrılmaktadır. Bu fonksiyonların içi kullanıcı tarafından doldurulmaktadır. Kullanıcı “fixture” sınıfı yardımıyla test için gerekli bağlamı yaratmakta ve test bittikten sonra da teste özel yarattığı bağlamı temizlemektedir.
Google birim test aracı, yukarıdaki testin içine yazılmış test cümleleri dışında birçok test cümleleri barındırmaktadır ve her test cümlesinin test planlamasındaki etkisi farklıdır. Örneğin; ASSERT _EQ() fonksiyonu iki argüman alır ve bu iki argümanın birbirine eşit olup olmadığını kontrol eder. Bu iki argüman birbirine eşit değil ise test başarısız olur ve diğer hiçbir test yapılmadan tüm test planlaması bitirilir. Bu gibi değişik işlevleri olan test cümlelerinin varlığı, kullanıcının yapacağı testlere işlevsellik katmakla beraber geliştiricinin özgün ve çeşitli test planlaması yapmasına olanak sağlamaktadır. 3
Birim testlerimizde Google birim test aracını seçmemizdeki nedenlerden ilki
Google birim test aracının ücretsiz ve açık kaynaklı bir kütüphane olmasıdır.
Ücretsiz olması, yazılım geliştiricisini ekonomik bir yükten kurtarmaktadır.
Kütüphanenin açık kaynaklı olması ise kütüphaneye erişimi ve kullanımı
kolaylaştırmaktadır. Google birim test aracını seçmemizdeki diğer bir neden ise güvenilir
bir birim test aracı olmasıdır. Google dahil dünyanın birçok büyük teknoloji
ve bilişim firması birim testleri için bu aracı kullanmaktadır. Chrome
tarayıcısının ve Chrome işletim sisteminin arkasındaki Chromium projeleri, LLVM
derleyici, OpenCV kütüphanesi gibi projelerde Google birim test aracı
kullanılmaktadır [
Birim testlerinin ana sistemde yürütülmesi deneyimlenen yazılım bileşeni olan veri yönetimi bileşeni, büyük bir elektronik harp projesinin elektronik taarruz alt sistemi gömülü kontrol biriminde yer alan ve özel formatlı veri tablolarının yazılımdaki organizasyonundan sorumlu olan yazılım bileşenidir. Veri yönetimi bileşeni veri tablolarının okunması, saklanması ve veri tabloları üzerinde sorguların yürütülmesi işlevlerini yerine getirir. Bu bileşen 40’a yakın farklı tablo tipini ve birden fazla tabloyu girdi olarak alabilen 40’a yakın sorguyu barındırmaktadır. Bu bileşenin birim testlerini ana sistemde yürütmeyi tercih etmemizin sebepleri; bu bileşenin içerdiği veri tabloları okuma ve sorguların hataya açık kısımlar olmakla birlikte yoğun birim testlere tabi tutulmaları gerekliliği, bileşenin modüler yapıda olması ve bileşenin hedef platforma bağlı olmamasıdır. 5
Veri yönetimi bileşeni açık kodlu Eclipse geliştirme ortamında C++ diliyle geliştirilmiştir. Eclipse için Aselsan bünyesinde geliştirilmiş bir eklenti, kaynak kodlarımızı hedef platformda kullandığımız gerçek zamanlı işletim sistemi olan VxWorks araç zinciriyle kolayca derlememizi sağlamaktadır. Bu eklentinin yardımıyla aynı geliştirme ortamında hem hedef platform için hem de ana sistem olarak kullandığımız Windows işletim sistemine sahip bilgisayar için derleme yapma yeteneğine sahip olmaktayız. Aynı çalışma alanında yer alan projelerden veri yönetimi bileşeni projesi hedef platform için derlenmekte, veri yönetimi birim test projesi ise ana sistem için derlenmektedir. Birim test projesine, bileşenin kaynak kodları referans olarak eklenmektedir. Böylece orijinal kaynak kodlar, müdahale riski olmadan ana sistem için derlenebilmektedir. Bileşen bünyesinde geliştirilen fonksiyonlar test için hazır hale geldikçe geliştirmeye paralel olarak testler de yürütülmüştür. 6
Veri yönetimi bileşeninin birim testlerinin hedef platform yerine ana sistemde yürütülmesi, biz geliştiricilere çeşitli faydalar sağlamıştır. Sağlanan en büyük fayda zaman kazancı olmuştur.
Bir gömülü sistem yazılımında derleme-bağlama ana sistemde yapılmakta, koşturma hedef platformda yapılmaktadır. Derleme-bağlama sonucu oluşan yürütülebilir dosyalar hedef platforma yüklenir ve hedef platformda yürütülür. Yazılım, hedef platform üzerinde istenilen şekilde çalışmıyorsa hatalar giderildikten sonra hedef platformda tekrar yürütülmelidir. Gerek birim testler yürütülürken gerekse de birim test sonuçları uyarınca tespit edilen hataların takibi/düzeltmesi yapılırken kod defalarca derleme-bağlama-koşturma döngüsüne girmektedir. Bu döngü sırasında platform değiştirmenin getirdiği zaman kaybı, bu döngünün birçok kez tekrarlandığı göz önüne alındığında ciddi boyutlara ulaşmaktadır. Veri yönetimi bileşeni birim testlerinde kullanılan yöntem, bizi bu maliyetten kurtararak bize zaman kazandırmıştır. Birim testlerin yürütülmesi için yaşanan derlemebağlama-koşturma döngüsü bütünüyle ana sistemde yapılmıştır.
Birim testlerin hedef platform yerine ana sistemde koşturulmasının zaman kazancından başka getirdiği bir avantaj ise hata ayıklama kolaylığıdır. Gömülü sistemler üzerinde çalışan yazılımlarda hata ayıklamak çoğu geliştirme ortamında mümkün olmamaktadır. Birim testler yürütülürken, PC ortamındaki geliştirme ortamlarında sunulan hata ayıklama işlevleri kullanılarak verimli bir hata tespit etme süreci gerçekleştirilmiştir.
Birim testlerin ana sistemde yürütülmesinin bize kazandırdığı en büyük
faydalardan biri de test edilen kodun işletim kapsamını, yani test edilen kodun hangi
kısımlarının koşturulduğunu, görmeye olanak sağlamasıdır. Özellikle çok fazla
koşul ve döngü kısımları içeren uzun kodlarda her bir koşulun veya döngünün
koşturulduğunu anlamak zor olmaktadır. Ana sistemde kullandığımız geliştirme
ortamı olan Eclipse aracına entegre bir şekilde çalışan GCov [
Birim testlerinin ana sistemde yürütülmesi 6. bölümde anlatılan faydalar göz önüne alındığında verimli bir pratik olarak tecrübe edilmiştir. Kullanılan yöntemle, gömülü yazılımlarda birim test süreci hem daha kolay uygulanır bir hale gelmekte hem de süreç daha az zaman almaktadır. Böylece gömülü yazılım geliştiricilerinin uygulamaktan imtina ettikleri birim test süreci uygulanabilir hale gelmekte ve bu sürecin uygulanması yazılımın kalitesini arttıran bir faktör olarak yazılım sistemine katkı sağlamaktadır. Bu tecrübemiz sonrasında ekibimiz bünyesinde geliştirilen gömülü yazılımlarda, bu pratiğin uygulanmasına karar verilmiştir.
Bu çalışmadaki sonraki adım, hedef platforma bağlı kodlar bulunduran gömülü yazılım bileşenlerine ait birim testlerin de ana sistemde yürütülebilmesi için bir hedef platform soyutlama katmanının yazılmasıdır. Bu soyutlama katmanıyla, hedef platforma özel fonksiyonlar ana sistem ortamında taklit edilerek aynı işlevsel sonucu vermiş olacaklardır. Bu çalışmanın sonucu olarak birim testlerin ana sistemde yürütülmesi için bileşenlerin hedef platforma özel kod bulundurmaması gereği ortadan kalkmış olacaktır.