Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

Güvenlik-Kritik Sistemlerde Yazılım Birim Testleri SW Unit Testing in Safety Critical Systems Hasan ŞİMŞEK AYESAŞ, ANKARA [email protected]

Nermin ÖZDEMİR AYESAŞ, ANKARA [email protected]

Özet Bu bildiride, AYESAŞ’ın RTCA DO-178B standardı uyarınca geliştirdiği güvenlik kritik (safety-critical) yazılım projelerinde uyguladığı “Yazılım Birim Testleri”ne (YBT - Unit testing/low-level requirement based testing) olan yaklaşımı anlatılmaktadır. Bu bildiri ile AYESAŞ edindiği DO-178B yazılım doğrulama süreci deneyimini ulusal yazılım endüstrisine aktarmayı amaçlamaktadır. Birim testleri, birimin bağlı olduğu diğer sistem unsurlarından bütünüyle soyutlanmış olarak doğru çalışıp çalışmadığının belirlenmesi amacıyla yapılan testlerdir. Birim testleri diğer testlerle karşılaştırıldığında daha alt seviyede yer aldığı için daha sık güncellenmesi ve koşturulması gerekir. Bu nedenle bu testlerin otomasyonu büyük önem taşımaktadır. AYESAŞ bu otomasyonu kendi geliştirdiği ve DO178B sertifikasyonu gereğince[2] kalifikasyonunu (tool qualification) yaptığı TRUVA birim test aracı ile sağlamıştır. Aynı zamanda, bu bildiride birim testlerinin TRUVA aracı ile otomasyonunun nasıl gerçekleştirildiği, otomasyon için hangi yöntemlerin kullanıldığı özetlenmiştir. Bunun yanında, birim testleri sürecinde en sık karşılaşılan problemlere ve çözüm önerilerine de değinilmiştir.

Abstract In this paper, AYESAŞ’s unit testing (low-level requirement based testing) approach to RTCA DO-178B compliant software development projects is explained. The purpose of this paper is to share the experience of AYESAŞ in unit testing with software industry of Turkey. Unit tests are performed in order to verify whether a software component is working correctly in isolation of its dependent software components. When compared to other type of tests, unit tests need to be updated and executed more frequently as they test relatively lower level of the software and are subject to a higher degree of change. Therefore, automation of these tests is very

Algan USKARCI AYESAŞ, ANKARA [email protected]

important. AYESAŞ accomplishes automation of unit tests by using internally developed and DO-178B qualified unit and low-level requirement based test tool TRUVA. The automation of unit tests by using TRUVA are summarized in this paper together with the methods employed. Furthermore, problems that are encountered during the unit testing process are presented along with the proposed solutions.

1

Giriş

Günümüzün artan yazılım mühendisliği ihtiyaçlarına cevap verebilmek için bir çok farklı süreç modeli ve standart ortaya konulmuştur. AYESAŞ, savunma, havacılık ve bilişim sektörlerinde üstlendiği yazılım projelerinde bu farklı süreç modelleri ve standartlarını uygulama ve deneyim kazanma şansı bulmaktadır. 1.1 DO-178B Nedir ?

Havacılık sektöründeki güvenlik kritik yazılım gereksinimlerine cevap veren DO-178B [1] uygulama maliyeti en yüksek standartlardan biridir. Temel olarak DO-178B iki temel analiz yapılmasını şart koşmaktadır: •

Gereksinim Kapsama Analizi (GKA)

•

Yapısal Kapsama Analizi (YKA)

GKA her yazılım gereksinimi için ilgili bir test olduğunu doğrularken, YKA her kod parçasının varolan testlerle tam olarak kapsandığının gösterilmesini sağlamaktadır. Şekil 1’de DO-178B’de gerekli olan doğrulama ve geçerleme aktiviteleri ve aralarındaki ilişkiler şekilsel olarak gösterilmiştir. DO-178B Seviye (Level) A, B, C, D ve E olmak üzere 5 faklı güvenlik seviyesi için farklı hedefler ortaya koymaktadır. Örneğin daha kritik ilk üç seviye için “Yapısal Kapsama Analizi” (Structural Coverage Analysis-SCA) yapılmasını istemektedir. Üst seviye testlerin (High Level Tests) yanısıra YBT’lerinin koşturulması sırasında da YKA verisi toplanmakta ve eksik test edilen kısımlar için varolan testleri

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

güncelleyip yeniden koşturma veya yeni testler eklenmesi gibi durumlara sıkça rastlanmaktadır. Bu nedenle geliştirilmekte olan testlerin otomatik olarak koşabilmesi büyük önem taşımaktadır. DO-178B’de önemli olan bir diğer nokta ise yazılımın geliştirilmesi sırasında, ürün üzerinde etkisi olabilecek Test Araçları, Kod Gözden Geçirme Araçları gibi her geliştirme ve doğrulama aracının DO-178B’ye göre kalifiye edilmesi şartıdır. Varolan Rafta Hazır Ticari Ürünlerin (RAHAT) çoğu sadece kullanılacak olan ürünü sağlamakta, DO-178B’nin şart koştuğu yazılım yaşam döngüsüne ait tüm verileri (gereksinim, tasarım, izlenebilirlik tabloları, kalifikasyon testleri ve sonuçları vb.) tamamen içermemektedir. AYESAŞ bu amaçla YBT’leri geliştirmek ve koşturmak için TRUVA’yı geliştirmiş ve kalifikasyonunu tamamlamıştır.

2

AYESAŞ’ta Birim Testleri

AYESAŞ, 4 senedir sürdürmekte olduğu ve büyük ağırlıkta test aktivitelerini içeren DO-178B standardı uyumlu, güvenlik kritik bir aviyonik projesini tamamlamıştır. Bu proje kapsamında 240.000 SLOC (kaynak kod satır sayısı) büyüklüğündeki kod için yaklaşık 2200 adet test prosedürü geliştirilmiştir. Bu proje süresince, test süreçleri hakkında birçok konuda bilgi birikimi elde edilmiştir. DO-178B’de birim testleri, alt seviye test olarak adlandırılmaktadır. Alt seviye testleri, bilinen birim testlerine göre çok daha fazla yükümlülükler getirmesine rağmen prensipte kullanılan teknikler birim testlerde kullanılanlarla büyük benzerlik gösterir. AYESAŞ alt seviye testlerini daha verimli şekilde üretebilmek ve koşturabilmek için TRUVA adlı bir test aracı geliştirmiştir. Bu araç sayesinde, doğru test prosedürü geliştirme, hızlı test koşturma, otomatik kalıtımsal (inheritance) test koşturma, dinamik koçanlama (stubbing) tekniği, XML formatında test sonucu raporlama gibi birim testlerini kolaylaştıran iyileştirmeler sağlanmıştır. Bu iyileştirmelerin sonucu olarak örneğin 105 birim testinden oluşan bir test paketi 45 dakikada hepsi bir arada derlenip koşabilmiştir.

Şekil 1: DO-178B’de Doğrulama Aktiviteleri

1.2 Yazılım Birim Testi Nedir ?

Bir yazılımda bulunan alt birimlerin, gereksinimleri tam ve eksiksiz olarak yerine getirip getirmediğini doğrulamak için gerçekleştirilen yöntemler “Yazılım Birim Testi” olarak adlandırılmaktadır. “Yazılım Birim Testi” adından da anlaşıldığı gibi bir bütünün alt parçalarının bağlı olduğu diğer birimlerden bağımsız olarak test edilmesidir. Bu yönüyle Sistem Testlerinden çok farklıdır. Sistem Testleri uygulamanın sağladığı servislerin ve barındırdığı özelliklerin bir bütün halinde testini içermektedir. Testler yazılan uygulamanın ilk kullanıcılarıdır. YBT sayesinde yazılımın entegrasyonundan çok önceki aşamalarda hataları minimuma indirmek mümkün olabilir. DO-178B projelerinde yazılımı doğrulamak için harcanan işgücü, geliştirmek için harcanan işgücünden çok daha fazladır. Bunun nedeni yazılımın güvenlik kritik olmasından dolayı tüm kod parçalarının eksiksiz olarak test edilmesi gerekliliğidir.

Öncesinde ise aynı test paketi her bir test ayrı ayrı derlenip koşturuduğunda yaklaşık 8 saat zaman almaktaydı. TRUVA aracının desteğiyle, testlerin geliştirilmesi, gözden geçirilmesi ve hata ayıklama süresinin de belirgin şekilde azaldığı gözlemlenmiştir. Bu iyileşmenin en büyük nedeni, betik dili kullanılan TRUVA testlerinin, doğal dile daha yakın olması nedeniyle, kolay anlaşılır ve kolay gözden geçirilir olmasıdır. Projenin gerçekleştirlmesi sırasında Test Ortamı ve Test Araçları ile ilgili teknik destek ve eğitimlerin sağlanması amacıyla Teknik Destek Grubu oluşturulmuştur. Bu sayede testlerin daha kolay geliştirilmesini, daha hızlı koşturulmasını sağlayabilecek iyileştirmeler, proje ekibine ek bir yük getirmeden elde edilmiştir.

3

Yazılım Birim Testlerinde Dikkat Edilmesi Gereken Noktalar

3.1 Birim Testleri Ne Detayda Yapılmalı ? Alt Seviye Gereksinimler/Tasarım Verisi Hangi Seviyede Bilgi İçermeli ?

DO-178B projelerinde tasarıma ait bilgiler içeren veriler alt seviye gereksinimleri olarak adlandırılmaktadır. Alt seviye gereksinimleri ile fonksiyonel gereksinimler ve birim testleri arasında izlenebilirlik tabloları

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

oluşturularak her fonksiyonel gereksinim için hangi tasarımın yapıldığı ve bu tasarımın hangi testlerde test edildiği rahatlıkla izlenebilmektedir. Nesne tabanlı yazılımlarda, yazılacak olan testler için en uygun yöntem sadece “public” tipindeki metod’ların test edilmesi, “protected” ve “private” tipindeki metodların ise dolaylı olarak public metodlar üzerinden test edilerek kapsanmasıdır. Ancak “protected” veya “private” metodların karmaşık algoritmalar içerdiği bazı özel durumlarda bu metodlar için ayrı gereksinimler ve testler yazılabilir. Nesne tabanlı olmayan yazılımlarda ise birimin diğer birimlere sağladığı fonksiyonlar/servisler üzerine yoğunlaşmak, birimin kendi içinde gerçekleştirdiği işlemleri mümkün olduğunca servis fonksiyonları üzerinden test etmek gerekmektedir. Metodları tanımlayan gereksinimlerin aşağıdaki bilgileri sağlaması çoğu zaman yeterlidir: •

Tanım

•

Ön Koşullar

•

Parametreler

•

Çıktı (Return)

3.2 Koçan ( Stub ) Yazılırken Nelere Dikkat Edilmeli ?

YBT’lerin yapıları itibariyle, test edilen birimin bağlı olduğu diğer birimlerden bağımsız olarak test edilmesini gerektirir. Bunu gerçekleştirebilmek için bağlı olunan diğer birimlerin koçanlanması gereklidir. Bağımlı olunan birimin de başka birimlere bağımlı olabileceği düşünüldüğünde koçanlama işleminin en düşük seviyede tutulması sonraki test güncelleme işgücünün azaltılması için büyük önem taşımaktadır. TRUVA birim test aracı, dinamik koçan yazma tekniğini sağlamaktadır. Böylece aynı testin içinde aynı koçanın farklı adımlarda farklı davranması sağlanabilmektedir. Bunun yanı sıra bir yazılım dosyası içinde yer alan metod/fonksiyonlar arasında sadece istenilen metodun koçanlanması ve koçanın yer aldığı dosyayı kopyalamadan kullanım sağlaması yöntemleri de kullanılmaktadır. Bu yöntemler sayesinde test edilen birim, kütüphane olarak test içinden çağrılabilmektedir. Test dinamik olarak gerekli yerlerde akışı koçanlara yönlendirmektedir. Bu yöntemin en önemli getirilerinden biri kullandıkları koçanlar farklı olsa da farklı testleri bir arada derleyip koşturabilme imkanıdır. Geleneksel yöntemlerde her bir test kullandıkları koçanlar farklı olduğu için ayrı ayrı derlenmekte ve bunun sonucu olarak her bir test ayrı yüklenip koşturulmaktadır.

Aşağıda önerilen formata uygun bir gereksinim örneği verilmiştir.

public int ExampleClass::getLowestNumber( int* pIntArray, int totalNoOfInts) Tanım: Bu metod pIntArray ile adreslenen “totalNoOfInts” adet tamsayı arasındaki en küçük değeri bularak geri döndürür. Ön Koşul: pIntArray != null, totalNoOfInts > 1, ExampleClass::initialize metodu daha önce çağırılmış olmalı. Paremetreler: pIntArray :

Tüm numaraların saklandığı dizinin ilk elemanını gösterir.

totalNoOfInts: Dizinde bulunan toplam eleman sayısını gösterir. Çıktı : Dizide bulunan en küçük rakamı döndürür.

3.3 Birim Testlerini Otomatik Koşturmanın Önemi

Yukarıdaki örnekteki “Tanım” en küçük sayının nasıl hesaplanması gerektiği bilgisini içermemelidir. Bu bilgi kodlama detayı olarak düşünülmelidir. Alt seviye gereksinimlerde asıl önemli olan verilen girdilere göre ne şekilde çıktılar üretileceğinin doğru ve eksiksiz olarak tanımlanmasıdır

DO-178B projelerinde belirlenmiş olan yazılım doğrulama seviyesine göre yazılımda bulunan tüm kod parçalarının tamamiyle test edilmesi gereklidir. Bu da yazılacak olan testlerin sayısının normal projelere göre çok daha fazla olmasını ve daha sık güncellenmesini beraberinde getirir. Bu nedenle bu testlerin otomatik olarak koşması büyük önem arzetmektedir. AYESAŞ bu otomasyonu, TRUVA birim test

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

aracı ile sağlamıştır. Bu konu ile daha detaylı bilgi Bölüm 5’te verilmiştir. 3.4 Birim Testlerine Ne Zaman Başlanmalı ?

DO-178B Yazılım Geliştirme süreçleri gereğince, “Yazılım Yaşam Döngüsü” içerisinde geliştirilen her ürün ilk kez yayımlandığında kontrol altına alınır. Bu ürünlerde sonradan yapılacak olan her değişiklik kayıt altında olmak zorundadır ve yapılacak olan değişikliğin doğru bir şekilde yapıldığının bağımsız kişilerce doğrulanması gereklidir. Bu nedenle herhangi bir ürün yeterince olgunlaşmadan yayımlandığında hatalar çok çıkmakta ve bu da sonraki fazlarda üretilen ürünlerin de çok sık güncellenmesini beraberinde getirmektedir. Örneğin kod veya gereksinim yeterli olgunluk seviyesine ulaşmadan yayımlandığında; birim testlerinin bulunan kod ve gereksinim hatalarının sonrasında güncellenmesi, çok sık olamamakla beraber bazen de baştan yazılmasını gerektirebilmektedir. Kod ve gereksinimler için teknik bir gözden geçirme yapılarak hataların büyük bir kısmı önceki aşamalarda giderilebilir. Yukarıda anlatılan nedenlerden dolayı, YBTleri geliştirmeye başlamadan önce kodun ve gereksinimlerin yapılacak gözden geçirmelerle belirli bir olgunluğa gelmesini beklemek gereklidir. Çoğu projede, birim testleri geliştirmek için ayrılan süre, kod geliştirme sürecinin uzaması nedeniyle yetersiz kalmaktadır. Bu nedenle bu fazda yapılan aktiviteleri olabildiğince hızlandırmak büyük önem taşır. Buna ek olarak yazılım geliştiricilere kısa zamanda geri besleme yapabilmek için testlerin hızlı güncellenip koşturulması gerekmektedir. 3.5 Birim Test Yazılması Tavsiye Edilmeyen Durumlar

YBT’lerinin temel amacı daha önceden belirtildiği gibi o birime ayrılmış olan fonksiyonalitenin test edilmesidir. Nesne Yönelimli C++ gibi yazılım dillerinde her class’ın sorumlu olduğu ve diğer class’lara sunduğu metodlar “public” olarak tanımlandığı için, sadece “public” metodların test edilmesi çoğu zaman yeterlidir. “protected” veya “private” metodlar karmaşık algoritmik hesaplamaları içermediği sürece public metodlar üzerinden dolaylı olarak test edilebilir. Sadece basit verileri içeren ve tek görevi bu verileri depolamak ve geri döndürmek olan class’ların test edilmesi önemli bir bulgu içermediği için herhangi bir yarar sağlamamaktadır. Ayrıca hemen hemen her class içerisinde yer alan, class içerisindeki değişkenlere değer atanmasını ve geri döndürülmesini (Getter/Setter) sağlayan metodlar da test edilmeyerek YBT’leri

geliştirmek için gerekli olan işgücünden tasarruf sağlanabilir.

4

Yazılım Birim Testlerinde Bulunan Hata Tipleri

Şekil 2’deAYESAŞ’ın yakın zamanda tamamladığı DO178B projesine ait hata oranları verilmiştir. Bu grafik DO-178B Standardı gereği kayıt altında tutulması gerekli olan veriler kullanılarak oluşturulmuştur. İlerleyen alt paragraflarda bu hataların tipleri hakkında daha detaylı bilgiler verilmiştir.

Kod Gereksinim Test Prosedürü 6% 43%

51%

Şekil 2: Örnek Bir DO-178B Projesindeki Hataların Dağılımı

Şekil 3’de ise “Yazılım Yaşam Döngüsü” içerisinde üretilen konfigürasyon birimlerini değiştirmek için açılan “Yazılım Değişiklik İsteği” (software change request), sayılarının oranları verilmiştir. Burada dikkat çeken, hatalı test prosedürü oranının %6 seviyesinde olmasına karşılık, test prosedürlerinde yapılan güncelleme oranının %39 ile en yüksek orana sahip olmasıdır. Bunun temel nedeni, hatalı gereksinim ve kod parçasının değiştirilmesi sonucu, çoğu zaman testin de güncellenmesi gerekliliğidir. Bu nedenle YBT’lerin otomasyonu büyük önem arzetmektedir. Kod Güncelleme Gereksinim Güncelleme Test Prosedürü Güncelleme 28%

39%

33%

Şekil 3: Yazılım Konfigürasyon Elemanlarının Güncelleme Oranları

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

4.1 Kod Hataları

Testler sırasında en sık karşılaşılan hata tipidir. Genellikle hatalı kodun düzeltilmesi yeterlidir. Sonrasında ise test tekrar koşturularak hatanın giderildiği doğrulanır. AYESAŞ bünyesinde birim testleri sırasında sıkça karşılaşılan hata tipleri aşağıda verilmiştir:

Kontrol çevrimlerinde limit değerin hatalı olarak dahil edilmesi veya edilmemesi (> yerine >= kullanılması vb.)

•

Reel sayıların yuvarlanması gereken yerlerde kısaltılması veya tam tersi (3.7’nin 4 yerine 3’e çevrilmesi vb.)

•

Parantezlerin kullanılmaması, önceliğinin yanlış belirlenmesi.

operatör

Kod ve gereksinimin uyumsuz olması

• •

Döndürülen değerin çözünürlüğünün, olması gerekenden daha küçük olması,

•

Kullanılan değişkenlere başlangıç değerlerinin atanmaması veya yanlış değerlerin atanması,

•

Limit dışı değerlerin metod içerisinde kontrol edilmemesi veya girdilerin tamamen doğru bir formatta olduğunun varsayılması,

Hata Sayısı

•

Bunların dışında kullanılmayan kod parçalarının bulunması, aynı yerel değişkenin birden fazla yerde kullanılması gibi birçok hata tipi de mevcuttur. Bu hataların Örnek DO-178B projesindeki dağılımı Şekil 4’de sunulmuştur.

1200

1000

%53

800

600

400

%18

%10

200 %6

%5

%3

%2

%3

0 Kod-Gereksinim Uyuşmazlığı

Hatalı Değişken Tipi Kullanımı

Başlangıç Değerlerinin Doğru Atanmaması

Limit Dışı Değerlerin İşlenmemesi

Kontrol Çevrimleri Limit Değerlerin İşlen(me)mesi

Sayıların yanlış yuvarlanması

Operatör Önceliğinin Yanlış Kullanımı

Diğer

Hata Tipi

Şekil 4: Kodda Bulunan Hata Kategorileri

4.2 Gereksinim Hataları

Şekil 5’te Örnek DO-178B projesinde bulunan gereksinim hatalarının dağılımı verilmiştir. Eksik veya hatalı olarak tanımlanmış gereksinimler, özellikle geliştiriciler de dahil olmak üzere farklı kişilerin aynı gereksinimi farklı olarak algılamasına ve hataya neden olur.

Diğer hata kategorisne örnek olarak, DO-178B projelerinde YKA sonrasında, kapsanmamış kod parçaları bulunabilmektedir. Bunun nedeni kapsanmamış kod parçasına karşılık gelen bir gereksinimin yer almaması olabilir. Bu hatalar bulunduğunda gereksinimin ve testin güncellenmesi gerekir. Bu tip hataları daha önceden bulabilmek, testi yazacak olan kişilerin gereksinim gözden geçirme toplantılarına katılımı ile mümkün olabilir.

Hata Sayısı

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

1000

%39

800 600

%29

%25

400

%7

200 0 Gereksinimin Test Edilemez Oluşu

Gereksinimin Eksik Bilgi İçermesi

Gereksinim Kod Uyuşmazlığı

Diğer Hata Kategorisi

Şekil 5: Gereksinim Hatalarının Dağılımı

4.3 Test Hataları

Testlerde hataya rastlanıldığında, sadece testin güncellenmesi yeterlidir. Sonrasında ise güncellenmiş testin tekrar koşturulması gereklidir.

14%

Şekil 6’da test prosedürlerinde sıkça karşılaşılan hata tipleri oransal olarak verilmiştir.

Gereksinimin Tümüyle Test Edilmemesi 33%

8%

Robustness Test Koşullarının Test Edilmemesi Görsel Doğrulama Komutlarının Yetersiz Oluşu İzlenebilirlik Tablolarında Yapılan Hatalar

18%

Diğer 27% Şekil 6: Test Prosedürü Hata Tiplerinin Dağılımı

5

Yazılım Birim Testleri Araç Desteği, Truva

Doğrulanması gereken birimler küçüldükçe yazılan gereksinim sayısı ve buna bağlı olarak test miktarı artmaktadır. Birim testinin doğruladığı gereksinim sayısı, üst seviye gereksinim sayısına göre daha fazla olduğu için, birim testler sayı ve miktar olarak üst seviye testlere göre çok daha fazladır. Bu nedenle harcanan iş gücünü düşürmek için birim testleri mutlaka uygun bir araç ile desteklenmelidir. Şu anda yürürlükte olan DO-178B’ye uygun mevcut test araçlarının bilinen tamamı dış menşeilidir. Bu test araçlarının özellikleri, simulasyon ve modelleme ile oluşturulabilen testlerden, koda göre üretilen testler ve statik analize kadar değişik bir yelpazede yer

almaktadır. Buna rağmen FAA ve NASA'nın ortak çalışması sonucunda yayınlanan “Handbook for Object-Oriented Technology in Aviation[4]”da tanımlanmış tüm kriterleri sağlayan bir birim test aracı araştırmalarımıza göre bulunamamıştır. İncelenen test araçları uygulamada istenen sonuçları vermemiş ve bu yüzden TRUVA adlı birim test aracını geliştirilmesine karar verilmiştir. TRUVA geliştirilirken aşağıdaki birim test aracı özelliklerini sağlamasına özen gösterilmiştir: • DO-178B kalifikasyonu • Otomatik test koşma ve dinamik koçanlama • Kalıtımsal test • Test sonuçlarinin değerlendirilmesi • Betik (script) dili,

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

• •

Sunucunun diğer platformları da destekleyecek şekilde kolayca adapte edilebilmesi mümkündür.

XML formatında test sonucu raporlama Test prosedür hatalarının raporlanması

Şekil 7’de TRUVA mimarisi şekilsel olarak verilmiştir. Sunucu tarafında UUT (unit-under-test, test edilen birim ), TRUVA’da yazılmış test prosedürlerinden (test case) uygun girdilerle çağırılır. Test prosedürleri TRUVA kütüphanesi tarafından sunulan, gerçek değerlerle beklenilen değerlerin karşılaştırılmasını sağlayan komutları çağırır. Sunucu tarafında bu karşılaştırmalar sonucunda elde edilen veriler istemci tarafına gönderilir. İstemci tarafında TRUVA her bir alt adım için GEÇTİ/KALDI, gerçek sonuç/beklenen sonuç bilgilerini raporlamaktan sorumludur.

Bu özellikler ile ilgili detaylı bilgiler ilerleyen alt bölümlerde verilmiştir. TRUVA aşağıdaki şekilde görüldüğü gibi istemci ve sunucu bölümlerinden oluşmaktadır. TRUVA’nın istemci tarafı Windows işletim sistemi üzerinde çalışmaktadır. Halihazırda sunucu tarafı ise Greenhills Integrity gerçek zamanlı işletim sistemi, LINUX veya Windows üzerinde çalışabilmektedir. İstemci ve sunucu arasındaki haberleşme ethernet veya serial RS232 protokolleri ile gerçekleşebilmektedir.

TRUVA Server

UUT ClassA

( TARGET platform ) call

TRUVA Server Test Cases

call

TestCaseParser

TC_ClassA

derived

TypeParser

use use

derived

TC_Base

TRUVAServer

Stubs

TRUVA Client (Windows Platform ) TestUtility ( for verification)

Test GUI and reporting Script (TC_ClassA.ts)

Şekil 7: TRUVA Mimarisi

TRUVA aşağıdaki yararları sayesinde birim test sürecinde verimliliği artıran bir araç desteği sunmaktadır: 5.1 DO-178B Kalifikasyonu

DO-178B, yazılım geliştirme aracının kalifikasyonunu, süreçte belirtilmiş işlemlerden herhangi biri kullanılan araç tarafından kısmen veya tamamen yerine getirildiği ve üretilen çıktı için doğrulama yapılmadığı durumda zorunlu tutmaktadır. Kalifikasyonun amacı, yazılım geliştirme aracının kullanım amacını doğru bir şekilde karşıladığını ispat etmektir [2]. Örneğin bir yazılım test aracı, beklenen ve gerçekleşen sonuçları karşılaştırarak otomatik olarak Geçti/Kaldı sonucunu üretiyorsa ve test sonuçları için doğrulama aktivitesi yapılmıyorsa o test aracı için kalifikasyon yapılmalıdır. Bu nedenle TRUVA için DO-178B’de gerekli olan yazılım doğrulama aracı kalifikasyon paketi de oluşturulmuştur.

5.2 Otomatik Test Koşma ve Dinamik Koçanlama

Otomasyon olmadan, birim testlerinin ayrı ayrı koşturulması vakit almaktadır. Bu nedenle bir test aracından beklenen en önemli özellik hiçbir kullanıcı müdahalesi gerektirmeden testleri otomatik olarak koşabilmektir. İdeal durumda amaç testlerin hepsini beraber koşmaya bırakıp daha sonra sonuçları toplu olarak almaktır. Böylelikle hem insan gücü hem de testlerin üzerinde koştuğu kısıtlı donanım kaynakları çok daha verimli kullanılmış olur. Bu amaca Truva iki farklı yöntemle ulaşmaktadır: 5.1.1. Testlerin Birlikte Derlenip Otomatik Koşması ve Dinamik Koçanlama: Testlerin birlikte derlenip koşabilmesinin önündeki en büyük engel farklı testlerin farklı tür koçanları gerektirmesi idi. Bu engeli aşabilmek için TRUVA’da dinamik koçanlama tekniği kullanıldı. Dinamik koçanlama tekniği aynı nesne kodu içinde herhangi bir koçanı

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

açma veya kapama imkanı tanımaktadır. Bu nedenle bir test için koçan durumunda kullanılan bir metod/fonksiyon diğer bir test için koçanı kapatılıp asıl kod kullanılarak çalıştırılabilmektedir. Ya da bir test adımında 5 döndürmesi gereken bir koçan başka bir adımda 7 döndürebilmektedir.

•

A testi koşarken K metodu, L metodu yerine kocanL metodunu kullanmakta,

•

B testi koşarken L metodu, N metodu yerine kocanN metodunu kullanmakta,

Örnek:

•

C testi koşarken M metodu, L metodunu, L metodu N metodunu çağırabilmektedir.

Dinamik koçanlama tekniği ile aşağıdaki testler, koçanlar ve test edilen kod beraber derlenebilmekte ve aynı koşabilir kod içinde yer alabilmektedir. Bunun sonucu olarak testler ardarda otomatik olarak koşabilmektedir.

Şekil 8’de kesintisiz düz oklarla belirtilen akış normal test edilen kodun akışını göstermektedir. Dinamik koçanlama tekniği ile;

Test of C L ve N metodlarının koçanını kapat.

Class C Method M

Class A

Class B

Class D

Method K

Method L

Method N

kocanN

kocanL

A Classının Testi : L metodunun koçanını aç ve “kocanL” fonksiyonunu koçan olarak kullan.

Test of B: N metodunun koçanını aç ve “kocanN” fonksiyonunu koçan olarak kullan.

Şekil 8: TRUVA’da dinamik koçanlama 5.3 Kalıtımsal Test :

5.1.2. Testlerin Bağımsız Derlenip Otomatik Koşması: Dinamik koçanlamanın kullanılmadığı ya da testlerin beraber derlenmesinden kaynaklanabilecek herhangi bir yan etkiyi önlemek için Truva ayrı ayrı derlenip peş peşe testleri otomatik koşturma imkanı da sağlamaktadır. Bu amaçla Truva için komut satırı arayüzü geliştirilmiştir. Komut satırı parametreleri kullanılarak hiçbir kullanıcı müdahalesi gerekmeden testler koşabilmektedir. Bu yöntem 5.1.1. de anlatılan testlerin beraber derlenip koşturulması yöntemine göre daha yavaş olmasına rağmen testler arası bağımlılık olmadığı için daha çok tercih edilmiştir.

DO-178B de önemli konulardan biri de kalıtımsal fonksiyonların tüm türeyen classlar üzerinde doğru çalışacağının doğrulanması gereğidir. Bu doğrultuda, türemiş classların testinde ana classın testinin otomatik olarak koşturulması TRUVA’da mümkündür. Bu sayede her bir ana class özelliğinin türemiş classlarda da doğru çalıştığı fazladan test yazılmadan test edilebilmektedir. TRUVA’nın bu özelliği nesnetabanlı yazılım testlerinde ciddi anlamda işgücü kazancı sağlamaktadır. Örnek: Şekil 9’da DO-178B’ye göre A sınıfının içinde yer alan metodların A dan türetilmiş olan B sınıfı ile de doğru çalıştığı doğrulanmalıdır. Bunun için TRUVA, A sınıfı için yazılmış testi B sınıfı üzerinde otomatik koşturmayı sağlayan bir yapı sunmaktadır.

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

Class B : Class A { public:

Class A { public :

inherits from

X Y

tests

K L M tests

tests

Test of Class A { Test of method X Test of method Y }

Test of Class B : Test of Class A { Test of method K Test of method L

inherits from

Şekil 9: TRUVA’da kalıtımsal Test 5.4 Test Sonuçlarının Değerlendirilmesi

5.5 Betik Dili :

Gerçek sonuçların beklenen sonuçlar ile karşılaştırılması için TRUVA hazır bir kütüphane sunmaktadır. Bu kütüphane yardımı ile her bir veri tipi için gerçek sonuçları beklenen sonuçlar ile belirlenmiş toleranslar dahilinde karşılaştırmak mümkündür. Bu karşılaştırma sonucunda TRUVA her bir karşılaştırma adımı için GEÇTİ/KALDI (PASS/FAIL) kararı vermektedir. Her adım için belirlenen GEÇTİ/KALDI (PASS/FAIL) kararları kullanılarak TRUVA testin bütünü için kararı vermekte ve tüm bu sonuçları rapor halinde sunmaktadır.

TRUVA’da doğal dile yakın olan script dili kullanılarak daha anlaşılır, gözden geçirmesi ve bakımı daha kolay testler oluşturulabilmektedir. Geleneksel yöntemlerde birim testler kod yazarak geliştirilmektedir. TRUVA’da farklı olarak betik dili kullanımı geliştirilmiştir. Bu yöntem geleneksel yöntemlere kıyasla kolay anlaşılır, kolay değiştirilebilir esnek bir ortam sağlamıştır. Örnek:

Şekil 10’da göründüğü gibi betik dili çok daha kolay okunabilir bir arayüz sağlamaktadır.

Geleneksel Yöntem

TRUVA

Main { RunStep1(); RunStep2(); RunStep3(); } RunStep1 { input1= 5; input2= 10; actual = Topla ( 5, 10 ); if ( actual == 15 ) result = PASS; else result = FAIL; } RunStep2 { input1= 0; input2= 0; actual = Topla ( 0, 0 ); if ( actual == 0 ) result = PASS; else result = FAIL; } RunStep3 { input1= 1000; input2= 2999; actual = Topla ( 1000, 2999 ); if ( actual == 3999) result = PASS; else result = FAIL; }

STEP 1 CALL Topla INP parametre1 5 INP parametre2 10 EXP result

15

STEP 2 CALL Topla INP parametre1 0 INP parametre2 0 EXP result

0

STEP 3 CALL Topla INP parametre1 1000 INP parametre2 2999 EXP result

Şekil 10: TRUVA’da Betik Dili

3999

Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu, İstanbul 9-10 Ekim 2008

5.6 XML Formatında Test Sonucu Raporlama :

TRUVA koşulan testler ile ilgili adım detayında GEÇTİ/KALDI, beklenen sonuç/gerçek sonuç gibi bilgileri içeren test sonucunu XML (UTF-8 veya UTF16) formatında otomatik oluşturmaktadır. XML formatında üretilen test raporlarından elde edilen özet bilgi ; a. Mevcut bir veritabanına kolaylıkla aktarılabilir. (bkz. Şekil 11). b.Truvanın sağladığı arayüzle “csv” formatında tablosal gösterimle kaydedilebilir. Bu sayede, testlerin koşması sonrasında, testler hakkında üst seviye rakamsal veriler elde etmek ve test sonuçlarının gözden gecirilmesinde kolaylik sağlamak mümkündür.

etkilemektedir. Bu bildiride bahsi geçen yöntemleri, AYESAŞ güvenlik kritik projelerinde uygulayarak, geleneksel yöntemlere kıyasla belirgin ölçüde iyileşme katetmiştir. Bu uygulamalar sırasında ortaya çıkan yazılım birim test aracı ihtiyacının giderilmesi için TRUVA geliştirilmiştir. TRUVA ile ilgili güncellemelerin ve iyileştirmelerin yapılabilmesi, yeni özelliklerin kazandırılması ve kullanıcı eğitimlerinin verilmesi amacıyla teknik destek ekibi oluşturulmuştur. Yeterli araç ve yöntem desteği gereken bu süreç ile ilgili AYESAŞ’ın mevcut deneyim ve uygulamaları bu bildiride özet halinde verilmiştir. Daha detaylı bilgi için [email protected] adresinden bilgi talep edilebilir.

7

Yazılım mühendisliğinde bilgi paylaşımı için gerekli ortamı bizlere sağladığı için organizasyon komitesine ve şirketimiz AYESAŞ yetkililerine teşekkür ederiz.

8

Şekil 11: TRUVA’da Test Sonucu Raporlama 5.7 Test Prosedür Hatalarının Raporlanması:

TRUVA, betik dilinde test yazarken testçinin yapması mümkün olan bazı test hatalarını yakalayıp bu hataları HTML formatında raporlayabilmektedir. Bu sayede testçinin testten kaynaklı olası hataları ayıklama zamanı en aza indirilmiştir

6

Sonuç

DO-178B, aviyonik projelerine ait yazılımların geliştirilmesi sırasında uyulması gereken krtiterlerin neler olduğunu söylemekte; nasıl yapılması gerektiği konusunda herhangi bir yönlendirmede bulunmamaktadır. DO-178B kriterlerinin projelerdeki uygulanma yötemlerine göre, maliyet artışı farklı güvenlik seviyelerinde %10 ile %40 arasında olabilecekken, yanlış uygulandığı takdirde bu oran %75 ile %150 arasında değişebilmektedir [3]. Bu farklılıkların en büyük nedeni ise birbirileri ile entegre olarak çalışabilecek yazılım geliştirme araçlarının kullanılmaması veya yanlış araç seçimidir. Birim testlerinde kullanılan yöntemler, birim testleri için harcanan zaman ve iş gücünü ciddi anlamda

Teşekkür

Kaynaklar

[1] RTCA DO-178B, “Software Considerations in Airborne Systems and Equipment Certification”, 1992 [2] FAA Order 8110.49 “Software Approval Guidelines” dated 6/3/2003 Chapter 9, “Qualification of Software Tool using RTCA DO-178B” [3] HighRely whitepaper, ”DO-178B Cost & Benefits: what are the true DO-178B costs and benefits; a detailed analysis.”, 2005 [4] FAA, “Handbook for Object-Oriented Technology in Aviation” 26/10/2004 KISALTMALAR: GKA: Gereksinim Kapsama Analizi RTCA: Radio Technical Commission for Aeronautics RAHAT: Rafta Hazır Ticari Ürün (COTS) SCA: Structural Coverage Analysis (Yapısal KapsamaAnalizi)

YBT: YKA: XML : UUT : CSV :

Yazılım Birim Testi Yapısal Kapsama Analizi Extensible Markup Language (Geniştilebilir Biçimleme Dili ) Unit Under Test (Test edilen birim) Comma Seperated Value (Virgülle Ayrılmış Değerler) dosya format