Test Verilerinin Formatı
Test Verilerinin Formatı
Test edilen sisteme uygulanabilir herhangi bir veri formatını test girişi ve test çıkışı olarak kullanın. Buna, yalnızca test edilen sistem tarafından bilinen veritabanları ve dosya biçimleri dahildir. Test edilen yazılım tarafından okunan ve yazılan veri formatlarını kullanmak, her test senaryosundan önce ve sonra dönüştürmede zaman kazandırır ve basitleştirir.
Sorun Kullanılan veri formatı ne kadar özelleşmişse, testleri güncellemek için özel araç desteğine ihtiyaç duyulma olasılığı o kadar yüksektir. Girdi ve çıktı verilerinin yapısında ve biçiminde değişiklikler meydana geldiğinde, test verilerinin güncellenmesi gerekir.
Özel biçimleri ‘düzenlemek’ için araçlar varsa, bu iş otomatikleştirilemezse en azından mümkündür. Ancak araçlar mevcut değilse, test verilerinin yeniden oluşturulması gerekir ve bazı durumlarda (“gerçek” verilerin kopyaları gibi) bu mümkün olmayabilir.
Çözüm Metin biçimindeki veriler genellikle en esnektir ve kolayca manipüle edilebilir. Aynı zamanda farklı donanım platformları ve sistem konfigürasyonları arasında taşınabilir. Test verilerini ve sonuçlarını a-metin formatında (ASCII gibi) saklamanın mümkün olduğu durumlarda bu yapılmalıdır. Verileri dönüştürmek için harcanan zaman ve testlerin ekstra ‘karmaşıklığı’ genellikle özel formatları korumanın maliyetinden çok daha kabul edilebilir.
Bu formdaki test verileri, metin verileri düzenlenerek veya özel bir dönüştürme işlemi oluşturularak kolayca dönüştürülebilir. İkinci yöntemin güzelliği, dönüştürme işlemi geliştirildikten sonra tüm verilerin otomatik olarak güncellenebilmesidir.
Örneğin, kelime işlemciler genellikle oluşturdukları belgeleri ikili biçimde saklarlar. Böyle bir kelime işlemci için bir dizi otomatik test, çeşitli test senaryoları için başlangıç noktaları olarak çok sayıda belge içerebilir. Test senaryolarının amaçları doğrultusunda, belgeler, kelime işlemcinin güncel sürümü tarafından anlaşılan formatta olmalıdır.
Bu nedenle, belge biçimi değişikliklerini içeren kelime işlemcinin yeni bir sürümünün test edilmesi gerektiğinde, tüm test belgelerinin güncellenmesi gerekir. Bunu yapmak kolay olsa da yine de yapılmalıdır – bu bir bakım maliyetidir. Test belgeleri tarafsız bir formatta tutulursa bu önlenebilir.
Belgeleri en son belge biçimine dönüştürme işi, test kurulumunun (veya daha iyisi Test Suite kurulumunun) bir parçası olarak gerçekleştirilebilir. Artık, belge formatı değiştiğinde, yalnızca belge dönüştürme programı güncellenmelidir ve mevcut tüm test senaryoları, belge biçimindeki değişiklikten etkilenmeyecektir.
Test Senaryolarını Çalıştırma Zamanı
Test senaryoları sıkılmayacak, dikkati dağıtmayacak bilgisayarlar tarafından yürütüldüğü için istediğiniz kadar uzun olabilir. İlk kurulum ve temizleme işlevlerinin yalnızca bir kez gerçekleştirildiği uzun test durumlarını çalıştırmak, birçok daha kısa testi çalıştırmaktan çok daha verimlidir, çünkü kurulum ve temizleme işlevlerinin birçok kez tekrarlanması gerekir.
Sorun Genellikle, yürütülmesi uzun zaman alan bir test senaryosu çok çeşitli ve farklı şeyler gerçekleştirir. Özünde, hepsi bir araya getirilmiş birçok testtir. Birden çok kurulum ve temizleme eyleminden kaçınarak kazanılan sezgisel tasarruflar, uzun bir test senaryosunun doğasında var olan verimsizliği büyük ölçüde gölgede bırakır.
Bir şeyler ters gittiğinde, başarısızlığın nedenini analiz etmek, hata ayıklamak ve düzeltmeyi doğrulamak için test senaryosunun en azından başarısızlık noktasına kadar, genellikle çok sayıda tekrarlanması gerekir. Uzun bir test senaryosunda erkenden meydana gelen başarısızlıklar diğerlerini pekala gizleyebilir. Bu sonraki hatalar, ilki düzeltilene kadar bulunamaz. Bu nedenle, test senaryosunun daha fazla analiz ve hata ayıklama turlarından geçmesi gerekir.
Veri dosyası Uzantıları
Veri dosyası Nedir
İşlem tablosu dosyası nedir
İşlem Tablosu dosyası
Çözüm Amaç, işlevsel test senaryolarını olabildiğince kısa ve odaklanmış halde tutmak olmalıdır (mantık dahilinde). Örnek olarak, tamamlanması 30 dakika süren bir test senaryosunu ele alalım. İlk çalıştırıldığında 5 dakika sonra başarısız olduğunu, kusurun bulunup düzeltildiğini ve test senaryosunun yeniden çalıştırıldığını söyleyin.
Bu kez 10 dakika sonra başarısız olur ve tekrar kusur bulunur ve düzeltilir ve test senaryosu yeniden çalıştırılır. Üçüncü kez 15 dakika sonra başarısız olur. Şu ana kadar test senaryosu toplam 30 dakikadır çalışıyor (5 + 10 + 15 = 30) ve üç parça bilgi (yani üç başarısızlık) verdi ve yine de yolun yarısında çalıştı. Bu, kusurların etkili bir şekilde üst üste yığıldığı ve her birinin ancak bir üstteki çıkarıldığında görülebildiği ‘iç içe geçmiş kusur’ sendromudur.
Şimdi, aynı test senaryosu 3 dakikalık on test senaryosuna bölünürse, 30 dakikada tüm parti çalıştırılabilir ve on parça bilgi olur; bazı test senaryoları başarılı olabilir, bazıları başarısız olabilir. Şanslar, daha önce bulunan üç kusurun bu sefer birkaç başka kusurla birlikte bulunmuş olmasıydı. Ayrıca, test senaryosunu arıza noktasına kadar yeniden çalıştırmak 3 dakikadan fazla sürmeyeceğinden, herhangi bir arıza hızlı bir şekilde araştırılabilir.
Test Durumlarının Hata Ayıklama Yeteneği
Otomatikleştirilmiş bir test çalışmasından istenen tek bilgi, başarılı veya başarısız olan test durumlarının bir listesidir. Test aracının işi, testleri çalıştırmak, sonuçları doğrulamak ve her test durumunu “geçti” veya “başarısız” olarak bildirmektir.
Sorun Bir test başarısız olduğunda, neyin yanlış gittiğini nasıl bileceğim? Otomatik testin sağladığı tek bilgi “başarısız oldu” ise, birisinin başarısızlığın nedenini araştırması gerekir. Hata analizi ve hata ayıklama, otomatikleştirilmiş bir test durumu için, genellikle manuel olarak bir çalıştırma için olduğundan çok daha zor olabilir.
Bunun nedeni, manuel test cihazlarının, arızaya yol açan eylemleri üstlendikleri için arızaya neyin sebep olduğu konusunda iyi bir fikre sahip olmalarıdır. Dahası, sorunu biraz daha kesin olarak belirlemeye çalışmak için deney yapabilecekleri ideal bir durumdalar. Bu daha sonra kusuru düzeltmekle görevli geliştiriciye yardımcı olur.
Öte yandan, otomatikleştirilmiş test senaryoları, yalnızca tasarlandıkları ve inşa edildikleri sırada anlatmak üzere “programlandıklarını” söyleyebilirler (bu genellikle “geçti” veya “başarısız oldu” veya belki de gerçek bir test olduğunu gösteren basit bir ifadedir).
Bu nedenle, otomatikleştirilmiş test durumlarının hatalarını analiz etmek, manuel olanlardan daha fazla çaba gerektirir. Hata ayıklamayı yapan kişiye test senaryosunun başarısız olmasına neden olan kusuru düzeltme’ görevi verilebilir. Manuel bir test ortamında, aynı kişiye, kusurun nedenine ilişkin bazı bilgilerle birlikte, kusurun anlamlı bir açıklaması da verilebilir.
İşlem Tablosu dosyası İşlem tablosu dosyası nedir Veri dosyası Nedir Veri dosyası Uzantıları