Salı, 14 Aralık 2010 09:47

Veriambarı Yazılım Geliştirme Sürecinde Test

Yazan&Gönderen  Yusuf Arslan
Bu Öğeyi Derecelendir
(1 Oy)

Veriambarı bir organizasyonun elektronik olarak saklanan datasının deposudur.Veri

ambarları raporlama ve analizi kolaylaştırmak için dizayn edilmişlerdir. Veriambarları analiz ve ilişkili verilerin sorgulanabildiği sistemlerdir.Birden fazla kaynak sistemin işleme tabi tutulmasıyla oluşmuştur.Ayrıca bu şekilde anlık işlemlerin gerçekleştiği veritabanlarındaki tutarsızlıkların ve kirli verilerin filtrelenerek analiz ve raporların etkilenmemesi sağlanmıştır.

 

Veri ambarının yapısı genel itibariyle şu aşamalardan oluşur;

 datamodelyeni

1.Kaynak sistem:Günlük işlemlerden gelen kayıtların(transactionların)kaydedildiği

veritabanlarıdır.Bu veritabanları genelde tek bir işlev için normalize edildikleri için bunların hem raporlamada hem de işlemler için kullanılmaları verimi düşürür.

 

2.ETL(Extract-Transform-Load):ETL sürecinin ilk parçası olan extract aşamasında veri kaynak sistemlerden

 

ortaya çıkmaktadır.Bu şekilde farklı kaynaklardan gelen datalar üzerinde daha etkin ve kolay şekilde sorgulama yapılabilmektedir.

 

 

Veriambarları iş    zekası çözümlerinde de kullanılmaktadır.İş zekası daha iyi iş kararları verebilmek amacıyla kullanılmaktadır[2].Veriambarları günümüzde birçok sektörde kullanılmakla birlikte özellikle rekabetin yoğun olduğu telekomünikasyon sektöründe kullanılmaktadır.Burada abonelere sunulan kampanyaların sonuçları,verilen bonusların kullanılma durumu gibi çeşitli işlevlerin yanında özellikle numara taşıma sonrası abonenin gidebileceğini tahmin eden algoritmalar da kullanılmaktadır.

 

 

Günümüzün bilgi çağı olmasından dolayı sürekli artan veri miktarının saklanması için veritabanları sürekli artmıştır.Ancak bu veritabanlarında bulunan veriler raporlama ve analiz için kullanılmaya uygun değildir.Bu verileri raporlama ve analizde kullanabilmek için buradaki ham bilginin kulanılır şekile dönüştürülmesi gerekmektedir.

 

 

Genel itibariyle veri tabanları hızlı ve etkin veri girişi,çıkışı ve güncellemesi için tasarlanmışlardır.Ancak bu yapılarda analiz ve raporlama için gereken algoritmaları çalıştırarak analiz ve raporlamaları gerçekleştirmek çok zordur.Bu nedenle yeni bir veritabanı oluşturularak bu yeni veritabanına sadece analiz ve raporlamada kullanılacak verilerin taşınması gerekliliği çekilir.Genellikle veriambarları birden fazla farklı kaynak sistemi kullanmaktadır.

 

 

Bu kısımın esasında çekilen verinin beklenen yapıya uygun olup olmadığının kontrol edilmesidir.Eğer değilse veri veriambarına alınmaz.

 

 

ETL sürecinin ikinci ayağı olan transform(dönüştürme)aşamasında ise birçok kural ve fonksiyonun extract edilen veriye uygulanmasıdır.Bu sayede iş ve teknik taleplei karşılayan hedeflenen veri kaynaktan türetilmiş olmaktadır.

 

 

ETL sürecinin son ayağı olan load(yükleme) aşamasında ise veri veriambarına yüklenir.Ancak bu işlem iş isteklerine göre değişebilmektedir.Mesele kimi işletmelerde mevcut veriye eklenerek giderken,bir kısmında haftalık olarak yenilenmekte ya da tarihsel olarak yeni data eklenmektedir.

 

 

1.Metadata: Veri hakkındaki bilgilere metadata denilmektedir.Veriambarında bulunan herbir veri elemanının anlamını,hangi elemanın hangi elemanlarla ilişkisi olduğunu,bu ilişkinin hangi şekilde gerçekleştiğini ve kaynakta bulunan veri ile hedefteki veri gibi bilgileri kendine tutmaktadır.

 

2.Front-end:Kullanıcı tarafında raporlama ve analizde kullanılmak üzere çeşitli araçlar kullanılarak veriambarına erişmesidir.

 

2.YAZILIM TEST

 

 

Bir program veya sistemin özelliğinin veya yeteneğinin değerlendirilmesi ve beklenen

sonuçlarım gözlemlenebilmesi için yapılan aktivitelere yazılım testi denilmektedir [3].

 

Yazılım testi genel itibariyle müşteri talepleri doğrultusunda geliştirilen bir yazılımın, kalite düzeyi müşteri tarafından belirlenen maliyet analizi göz önüne alınarak,müşterinin beklediği kalitede olup olmadığının belirlenmesi sürecidir.Yazılımlardaki hatalar geliştirici,analist gibi insan kaynaklı olmakla birlikte donanımsal kaynaklı da olabilmektedir.Bütün yazılım hatalarıkodlama hatası olmayabilir.Pahalı hataları meydana getiren ortak kaynak ihtiyaç analizleridir.Beklenilmeyen ihtiyaçlar yazılım dizaynırı tarafından ele alınmaz[4].

 

 

Yazılım geliştirme süreçlerine testin eklenmesinin nedeni yazılım geliştirme süreci sonucunda ortaya çıkan hataların müşteriye geri dönülmesi zor durumlara bırakmamasını sağlamaktır.Çünkü yazılımlarda bulunan bir hata canlıya alındığında yazılımın yaptığı işe göre bir şirkete itibar,para ve müşteri kaybına neden olabilmektedir.Tüm bunların önüne geçebilmek için test süreçlerini yazılım sürecinin içerisine yerleştirmek gerekiyor.

 

 

Yazılım doğrulama(verification) ve onaylama(validation)’nın birleşiminden oluşur.

Doğrulama:Yazılımı doğru yaptık mı?

Onaylama:Doğru yazılımı yaptık mı? 

 

 

Yazılım test süreçlerini aşağıdaki şekilde sınıflandırabiliriz;

Sistem bilgisine göre;

 

1.Black box test;

 

2.White box test;

 

3.Gray box test:

 

Yazılım yaşam döngüsünde çalıştırılma zamanına göre;

 

1.Unit test

 

2.Entegrasyon testi

 

3.Sistem testi

 

4.Kullanıcı onay testi

 

Testleri amaçlarına göre de sınıflandırabiliriz;

 

1.İşlevsel test:Yazılımın işlevsel yönünün irdelendiği testlerdir.Burada verilen bir girdinin

analize göre beklenilen çıktının verilip verilmediği test edilir.İşlevsel test yazılım yaşam

döngüsünün tüm anlarında yapılan testlerde kullanılabilir.

 

1.1.Yükleme testi(Installation test) : Kullanıcının ilk etkileşimi yazılımı yükleme sırasında oluşmaktadır.Farklı platformlarda yazılımın sorunsuz şekilde yüklenebildiği kontrol edilmelidir.Kullanıcı kurulumda sorun istemediği için çok önemli bir testtir.

 

1.2.Regresyon testi(Regression Test) : Regresyon testlerinin amacı yapılan bir hata düzeltmesinin veya bir değişikliğin halihazırda sorunsuz çalışan kısımları etkilemediğinin görülmesidir.

 

1.3.Yükseltme ve uyumluluk  testi(Upgrade and backward compatibility testing) : Her yazılımın sürekliliğini sağlamak için yükseltme sürümleri yapılır.Ancak bu sürümlerin önceki

sürümlerlerle uyumlu olması gerekmektedir.Bu nedenle bunun testinin yapılması gerekir.Bu teste uyumluluk testi adı verilir.

 

Yükseltme testinde ise kullanıcının efor sarfetmeden ve sistemini bozmadan bir yazılım yükseltmesi yapması beklenir.Bunun kontrolü için de yükseltme testi yapılır.

 

1.4.Erişilebilirlik testi: Kullanıcıların görsel,işitsel veya bedensel engelleri olabilir.Yazılımın bu kullanıcılar için çeşitli kolaylık sağlaması gerekmektedir.Bu nedenlede bu özelliklerin fonksiyonel testler sırasında kontrol edilmesi gerekmektedir.

 

1.5.Uluslararasılalıştırma ve yerelleştirme testi : Yapılan yazılımların diğer ülkelerde satışa sunulacak ise yazılımın bu ülkeler için uyumlu olması gerekmektedir.Bunun için yazılımın GUI’si,mesajlar,uyarı ekranları vb. Kısımlarının yerel dille yazılmış olmalıdır.Ayrıca bu değişiklikler yazılımın düzgün çalışmasını engellememelidir.

 

 

2.İşlevsel olmayan test: Test aktivitelerine odaklanılan,yazılımın işlevsel olamayan yönünü

irdeler,

 

2.1.Performans,yükleme ve stres testleri :  İşlevsel testlerden sonra yapılan bir testtir.Genel itibariyle bir kodlamanın hataları düzeltilmesinden sonra yapılır.Genel olarak web uygulamalarında kullanılır.Burada belli bir yük altında iken   sistemin cevap zamanı ve kullanımı testleri yapılır.


2.2.Kullanılabilirlik testleri :  Bir sistemin ne kadar kolay kullanılabilir ve öğrenilebilir olduğuyla ilgili testlerdir.Bu testler sayesinde müşteri memnuniyetiyle satışlar artar,destek için ayrılan kaynak azalır.

2.3.Güvenlik testleri : Güvenlik testindeki birincil amaç güvenlik açıklarını tespit etmek ve bunları tamir etmektir.Güvenlik testi genellikle kodlama  ve yükleme yapılıp operasyonel hale geldikten sonra yapılır. Bu test diğerlerinin aksine periyodik olarak ağ güvenliği için sistemin tüm güvenlik açıklarını tespit etmek için kullanılır.

 

 

 

3.VERİAMBARI PROJESİNDE TEST PROSEDÜRLERİ

 

 

Şirketimizin yapmış olduğu veriambarı projesinde kullanılan veri miktarı çok fazla olduğu için veriambarlarında kullanılan PL/SQL kodlarıyla verinin işlenmesi yetersiz kalmaktaydı.Bu nedenle ABINITIO adında ETL  (Extract,Transform,load) aracı kullanıldı.Bu aracın özelliği parametrik şekilde ayarlanarak paralel işlem yapabilmesidir.Bu nedenle çok büyük verileri kolaylıkla kısa zamanda işleyebilmektedir.

 

 

Bu araç tablo bazlı işlem yapmamaktadır.Yani bir veri işlenmeden önce tablodan dosyaya inilmeli sonrasında raporlamada kullanılmak üzere işlem sonrasında tekrar veriler dosyadan tablolara çıkılmaktadır.

 

Bu aracın bir diğer özelliği yarı görsel olmasıdır.Geliştirme hem görsel komponentler kullanılarak hem de kodlama yapılarak halledilmekteydi.

               

 

Bu projede yapılan geliştirmelerin testleri yukarıda bahsedilen testlerin  tamamı yapılamamıştır.Nedeni de sürenin kısıtlı olması ve bu nedenle bazı sorunlar geliştirme canlıya alındıktan sonra çıkmakta ve canlıda düzeltilmekteydi.

Yapılan testleri anlatacak olursam;

 

 

1.Yapılan geliştirme test grubuna ulaştığında öncelikle run olup olamadığı testi yapılmaktaydı.Yani giriş dosyaları veildiğinde dml hataları varmıydı,geliştirmenin çıkışında data oluşup oluşmadığıyla ilgili genel yapıyla alakalı testler yapılmaktaydı.Bu kısımda işlevsel testimizi halletmiş oluyorduk.

 

 

2.Canlıdan alınan güncel verilerle geliştirme run edilmekteydi.Bu şekilde oluşan çıkış verileri   ‘Veri Kalitesi’(Data Quality) testlerinde kullanılmak üzere tablolara yüklenmektaydi.Daha sonrasında bizler giriş veri tablolarını verilen analize göre SQL kodlamasıyla çıkış veri tablosunu oluşturmaktaydık.Son aşamada ABINITIO geliştirmesinin çıkış verisiyle,bizim yaptığımız SQL kodunun çıkış verisi  SQL’in ‘MINUS’ özelliği kullanılarak çıkış verisinin doğruluğu test edilmekteydi.

 

3.Incremental run   yapılarak geliştirmenin bir sonraki gün gelecek yeni insertleri,updateleri ve delete datalarını işleyip işleyemediğinin testini yapıyorduk.

 

 

4.Extraction ve load shell script kodlarının doğru şekilde tablolardan verileri çekip,tablolara düzgün şekilde yüklemesinin  testini yapıyorduk.

 

 

5.Canlıda olan bir geliştirmede hata bulunduysa düzeltmesi yapıldıktan sonra tüm geliştirme tekrardan bütünlüğünün bozulup bozulmadığıyla ilgili teste tabii tutulmaktaydı.

 

 

6.Performans testlerinde yapılan geliştirmelerde işlem tekrarlarının azaltılması yönünde yapılan geliştirmeler gözden geçirilmekte ve geliştiriciye bununla ilgili geri dönüş yapılmaktaydı.

Yukarıda bahsettiğim gibi yapılan testler daha fazla çeşitlendirilebilirdi.Ancak bir proje dahilinde kısıtlı zaman içerisinde yapıldığından dolayı test çeşidi olarak bu kadar yapılmıştır.

 

Okan Beşli

İ.Hakkı ÇAVDAR

 

 

 

 

Son Düzenleme Salı, 14 Aralık 2010 09:53
Yusuf Arslan

Yusuf Arslan

Oracle Open Source

1985 Tokat/Reşadiye doğumluyum.İlk-orta-lise hayatını Amasya/Suluova ilçesinde geçirdim.Sakarya Üniversitesi Bilgisayar Mühendisliği bölümünü bitirdikten sonra kariyerime Oracle,SAP alanlarında danışmanlık vermek üzere devam etmekteyim. Kullandığım,bildiğim teknolojiler ve diller; SAP BO Oracle BI Applications Oracle Data Mining Oracle BI Reports(http://www.iski.gov.tr/web/statik.aspx?KID=1000717) Oracle Data Integrator Oracle BI Publisher(XML Publisher) Oracle Database 10g Oracle Mapviewer PL/SQL,Java,Oracle JDeveloper,Oracle Forms-Reports,C# Data warehouse process optimization Database system implementation Using encoding for security systems Software development, test and deployment Presentation and communication skills Bu adreslerden de bana ulaşabilirsiniz, [email protected] https://datawarehouse.gen.tr/ http://www.arslanyusuf.blogspot.com/ http://yusufarslaneng.blogspot.com/ http://twitter.com/yusars http://tr.linkedin.com/pub/yusuf-arslan/27/35b/57b

Website: arslanyusuf.blogspot.com/ E-posta: Bu e-Posta adresi istek dışı postalardan korunmaktadır, görüntülüyebilmek için JavaScript etkinleştirilmelidir

En Son Yusuf Arslan

İlgili Öğeler (Etikete Göre)

Başa Dön