İlk geliştirmesinden sonra aracın kendisinde bazı teknik gelişmeler oldu. Otomatik test artık kendileriyle iletişim kurmak için mesaj gönderilmesini gerektiren programlarla daha kolay başa çıkabilir. Ağ arızaları gibi beklenmeyen olaylardan kaynaklanan sorunların üstesinden gelmek için bir dizi testin sonunda başarısız olan tüm testleri otomatik olarak yeniden çalıştırabilir.

Çok ilginç bir teknik gelişme, manuel testleri yarı otomatik hale getirmek için özel olarak yazılmış bir gösteri aracıyla (Dramatix olarak adlandırılır) Autotest’in kullanılmasıdır. Otomatik test, test ortamını ayarlamak için kullanılır, yani yazılımın ve veri dosyalarının doğru sürümünün bulunduğundan emin olun, test verilerini başlatın, vb.

Test edilen yazılım daha sonra çağrılır ancak kontrol, manuel test için test komut dosyasını görüntüleyen Dramatix’e verilir. Manuel test cihazı daha sonra, tüm bağlantıları korurken nesnelerin hareket ettirilip ettirilemeyeceğini kontrol etmek gibi (doğrulamanın görsel doğası nedeniyle otomatikleştirilmesi pratik olmayan) işlemleri gerçekleştirir. Test cihazı daha sonra Başarılı veya Başarısız durumunu kaydeder. Testin sonunda, Otomatik test tüm temizleme işlemlerini gerçekleştirir ve standart şekilde işlemek için Başarılı/Başarısız bilgilerini toplar.

Teknik Problemler

Ayrıca yıllar içinde, örneğin serbest bırakma prosedürlerine entegrasyonu daha verimli hale getirmek gibi bazı küçük geliştirmeler de yapılmıştır. Artık konfigürasyon yönetim sistemine tek bir komut kaynak kodunu kopyalayacak, yapıyı gerçekleştirecek ve otomatikleştirilmiş testleri çalıştıracaktır.

Hâlâ karşılaşılmakta olan birkaç teknik sorun var. Birincisi, beklenen sonuçların yaklaşık %1’inin aslında yanlış olmasıdır. Bunlar zamanla keşfedilir ve bulunduklarında düzeltilir, ancak muhtemelen Test Paketlerinde bazı yanlış beklenen sonuçlar vardır.

Zaman zaman meydana gelen bir domino etkisi de vardır. 10 test vakası başarısız olursa ve bir düzeltmenin bunu düzeltmesi gerekiyorsa, yeni yazılım gerçekte 90 testte başarısız olabilir. Bu cesaret kırıcı olabilir.

Bazı manuel testler hala gereklidir. Örneğin, işlev tuşu düzenleri farklı platformlar için farklıdır. Bu, en az bir kez manuel olarak test edilmeleri gerektiği anlamına gelir. Manuel testten x olayları saklanırsa, işlev tuşu düzeninin değişiklikten etkilenmemesi koşuluyla, değişiklikler yapıldığında testi tekrarlamak için yeniden oynatılabilirler.

Yazılım test Süreçleri
Yazılım test teknikleri
Yazılım test Çeşitleri
Manuel test Örnekleri
Otomasyon testi Nedir
Yazılım test araçları
Kara Kutu test Teknikleri
Manuel test ve otomasyon test

Değişiklikler ve Avantajlar

En çarpıcı fayda, bu kadar geniş bir test setini bu kadar sık çalıştırabilmenin garanti ettiği ürünlerin kalite düzeyidir. Tüm düzeltmeler, yamalar ve değişiklikler, yalnızca bir kez değil, her aşamada tamamen gerileme testine de tabi tutulur.

Testlerin tümü ‘son’ düzeltmeden sonra yeniden çalıştırılabilir, böylece müşterilere gönderilen yazılımın çok yüksek kalitede olduğunun bilinmesi de sağlanır. Otomatik testler gerçekten de kalite sisteminin merkezinde de yer alır.

Yönetim açısından en büyük etki, herhangi bir iş için tahmin edilen sürenin artık her zaman tam bir regresyon testi çalıştırma süresini içermesidir. Önceden, geliştirme tahminleri, yeterli test için harcanan zamanı dahil etmeyi hatırlama eğiliminde olmayan (iyimser?) geliştiriciler tarafından da veriliyordu.

Örneğin, yeni bir özelliği test etmek için süreyi dahil etmiş olabilirler, ancak regresyon testlerini veya mevcut testlerin bakımını dahil etmemiş olabilirler. Bu, geliştirmenin sonunda “yakalanmaya” yol açtı ve zamanın uzatılması gerekti. Örneğin, bir geliştirme projesi için on hafta tahmin ediliyorsa, hiç kimse testin ne kadar süreceğini ve hatta kaç test yapılması gerektiğini doğru bir şekilde de tahmin edemez.

Bu nedenle, geliştirme çalışması olması gerektiği kadar öngörülebilir değildi. Kültürdeki en büyük tek değişiklik, bitiş tarihlerinin artık çok iyi bir doğrulukla tahmin edilebilmesidir. Bu, planlamanın güvenle yapılabileceği ve tüm sürecin çok daha iyi yönetilebileceği anlamına da gelir.

Elbette süreç mükemmel değil, bu nedenle ara sıra küçük bir kayma oluyor, ancak genel olarak işler çok daha öngörülebilir. Bunun bir örneği, bir müteahhit sözleşmesini yakın zamanda bitirdiğinde işi yeniden tahsis edebildi ve etkinin beş ay sonra ne olacağını bildi. Önceden, birkaç hafta ileride bir etki görmek oldukça iyi kabul ediliyordu. Otomatikleştirilmiş test sistemi olmadan, bu doğrulukla ve şimdiye kadarki geleceği tahmin etmek de oldukça zor olurdu.

Otomatikleştirilmiş test rejiminin bir diğer önemli avantajı, Windows NT’ye geçmemizdi. Bu, şimdiye kadar desteklenen UNIX platformlarından tamamen farklı bir mimariye sahiptir. Otomatik test çok yardımcı oldu; aslında, onsuz NT’ye bağlantı kurmak muhtemelen mümkün olmazdı. Ürün hattının %95’ini NT’ye taşıdık ve mümkün olan yerlerde de mevcut testler yapıldı.

Taşıma işi, QA görmeden önce geliştirme aşamasında yapılır. Platformun son KG’si yapıldığında, otomatik testten geçen programlarda çok az kusur bulundu. Bulunan kusurlar temel olarak NT’nin benzersiz özelliklerinde, örneğin işlemciler arasındaki boru iletişimindeydi.

Müşteriler için pek çok küçük değişiklik olduğunda başka bir fayda ortaya çıkar. Çok sayıda şeyle uğraşırken küçük değişiklikleri gözden kaçırmak çok kolaydır. Otomatik test, hepsini hatırlayıp hatırlamadığınızı öğrenmenin de harika bir yoludur.

Karmaşık karşılaştırmalarda filtrelerden yararlandık. Örneğin, bir resim yeniden çizildiğinde, elemanların çizim sırasına bakılmaksızın kullanıcıya aynı görünmelidir. Araç, çizim talimatlarının sıralamasında farklılıklar bulabilir, ancak karşılaştırma yapmadan önce sırayı sıralayabiliriz. Bu özellik aslında yakın zamanda ortaya çıkan bir yenilik değil, zamanla geliştirildi. Ayrıca, 64 bitlik bir platforma (Alfa) geçerken bir miktar yuvarlama hatası toleransı oluşturmayı da faydalı bulduk.

Ne kadar küçük olursa olsun, herhangi bir yama için tüm testleri yeniden yapmak politikamızdır. Bu çok faydalı oldu. Geçen yıl, bir düzeltmeyle getirilen bir dizi kusur bulundu. Bu, müşteri açısından en kötü şeydir; bir kusuru yalnızca bir başkasıyla değiştirmek için de rapor ederler.

The post Otomatik Test Teknikleri first appeared on Akademi Delisi (Tez Yaptırma).

İki farklı test sonucu yapaylığı vardır. Bir test yürütmenin amacı genellikle, daha sonra beklenen sonuçla karşılaştırılan bazı sonuçlar elde etmektir. Dolayısıyla test sonucu, test uygulama sürecinin ‘ürünü’ olarak düşünülebilir.

Bununla birlikte, bir test senaryosu, test farkı raporları ve test aracı günlüğü gibi bazı ‘yan ürünler’ de üretir. Bu test yan ürünleri, bir testin ne zaman çalıştırıldığını, uyguladığı yazılımın sürümünü, test durumunu (testin başarılı veya başarısız olup olmadığını) vb. bize bildirebilen bir denetim izi oluşturdukları için çok önemlidir.

Bir test senaryosu başarısız olduğunda, muhtemelen en çok gerçek ve beklenen sonuç arasındaki farklarla ilgileniriz. Test yan ürünleri hakkında bilgi sahibi olmak da yararlıdır, ancak test başarısız olursa, büyük olasılıkla yeniden çalıştırılması gerekecektir.

Bu nedenle, şimdiye kadar yürütülen tüm test senaryolarının geçmişini kaydetmediğimiz sürece, yan ürün test yazılımlarının çoğunu ‘atabiliriz’ ve yalnızca gerçek sonuç ve fark raporunu tutabiliriz. Bu sadece bir olası görüş. Bir test senaryosu başarısızlığını analiz ederken tam olarak neye ihtiyacınız olacağını her zaman önceden söyleyemeyeceğiniz için aslında test senaryosu başarısızlığı durumunda her şeyi saklamanızı öneririz. Sonuçta, bir şeyi silmek onu yeniden yaratmaktan daha kolaydır.

Bir test geçtiğinde, artık fark raporuyla ilgilenmiyoruz (çünkü tanım gereği hiçbir fark yoktur – bu, bir test geçişini oluşturur). Ayrıca artık gerçek sonuçla da ilgilenmiyoruz (yasal nedenlerle tüm gerçek sonuçların saklanması gerekmiyorsa), çünkü bu bize halihazırda başka bir biçimde sahip olmadığımız hiçbir şeyi söylemiyor.

Beklenmedik farklar olmadığı için gerçek sonucu ve fark raporunu güvenle atabiliriz. Yapılan testin kanıtını sağlamak için gerekliyse, örneğin test günlüğü gibi diğer yan ürünlerin en azından bir kısmını saklamamız gerekebilir. Aksi takdirde tüm test sonuçları silinebilir.

Mantıksal Yapı

Test Sonuçlarının mantıksal yapısı gösterilir. Bir Test Paketinde tek bir test çalışması çalıştırması için test sonucu yapılarının tamamı, ilişkili test durumlarının bulunduğu Test Setlerine göre gruplandırılabilir. Yalnızca çalıştırılmış olan test durumları için Test Sonuçları olacağını unutmayın.

Fiziksel Uygulama

Test Yazılımı Setleri ve Test Paketi ile ilgili açıklamamız, bunların mantıksal bir görünümü ile sınırlandırılmıştır. Yani, çeşitli eserler arasındaki ilişkiyi tanımladık ancak bu ilişkilerin nasıl uygulanabileceğini özel olarak belirtmedik.

Tabii ki, herhangi bir uygulamanın herkese uyması pek olası değildir, ancak bizim tercih ettiğimiz, bir dizinler (klasörler) hiyerarşisini kapsamlı bir şekilde kullanır. Okuyucuların tarif ettiğimiz yapıyı kelimesi kelimesine uygulamasını beklemiyoruz, bunun yerine kendi ihtiyaçlarına daha iyi uyacak şekilde uyarlamalarını bekliyoruz.

Yazılım test araçları
Yazılım test türleri
Yazılım test Süreçleri
Fonksiyonel test nedir
Yazılım test Teknikleri
Yazılım test teknikleri PDF
Yazılım test örnekleri
Yazılım Testi Nedir

Test Yazılımı Seti Dizinleri

Nerede bulunduğuna bakılmaksızın (Testware Kitaplığı’nda veya bir Test Suite’te) her Test Yazılımı Seti için kesinlikle aynı fiziksel yapıyı koruyoruz. Bu, bir dizi yararlı görevi gerçekleştirmek için standart yardımcı programların kullanımını kolaylaştırmak ve bir yerden diğerine kopyalanırken Test Yazılımı Setlerinin yeniden yapılandırılmasını önlemek içindir.

Gösterildiği gibi bir Testware Set Dizininin temel fiziksel yapısını öneriyoruz. Test Yazılımı Setinin tamamı, her bir test yazılımı kategorisi için bir dizi alt dizin içeren bir dizinde (klasör) tutulur. Aynı alt dizin adları, tüm Test Yazılımı Setlerinde tutarlı bir şekilde kullanılır.

Dizinlerin bu hiyerarşik yapısı, kopyalanmalarını ve taşınmalarını çok kolaylaştırır. Çoğu ortamda, tek bir komut veya kullanıcı etkileşimi (‘sürükle ve bırak’ gibi) ile bir dizin hiyerarşisini kopyalamak veya taşımak mümkündür (bazen buna dizin ağacı denir). Test Yazılımı Setlerindeki test yazılımının fiziksel olarak organize edilebilmesinin tek yolu bu değildir, ancak bu uygulama birçok kuruluşta iyi sonuç vermiştir.

Temel olarak bir Testware Setinin mantıksal dosyalarını alıyoruz ve bunları dosya türüne göre çeşitli fiziksel alt dizinler halinde düzenliyoruz. Bu nedenle, Test Kümesinden beklenen tüm sonuçlar, örneğin Beklenen adlı bir alt dizine konulacaktır.

Tüm Testware Set Dizinleri için her alt düzey alt dizinin mevcut olmayacağını unutmayın. Bir Test Kümesi Dizini, gösterilen tüm alt dizinleri içerebilir; Veri Kümesi Dizini, komut dosyası, kaynak veya yardımcı program alt dizinlerini içermez; Yardımcı Program Kümesi Dizini, komut dosyalarını, verileri veya beklenen sonuçları içermez ve Komut Dosyası Kümesi Dizini, yalnızca komut dosyalarını ve belgeleri içerir.

Her bir Test Yazılımı Seti türünün fiziksel yapısının bir örneğini gösterir. Test Kümesi t_ScribbleList, ‘Doc’ belge alt dizinine giren bir belge (test belirtimi) içerir.

Dört komut dosyası, Komut Dosyaları alt dizinine ve beş beklenen sonuç dosyası (bu durumda tümü Karalama belgeleridir) Beklenen alt dizinine gider. Bu test senaryoları, ayrı Veri Kümesi d_ScribbleTypical’da tutulan paylaşılan veri dosyalarını kullandığından, bu Test Kümesinde (t_ScribbleList) veri dosyası yoktur.

u_GeneralCompare Yardımcı Program Setinde tutuldukları için bu Test Setinde hiçbir yardımcı program yoktur. Bu nedenle, Test Kümesi alt dizini yalnızca Doc, Script ve Beklenen alt dizinlerini içerir; diğer alt dizinler atlanmıştır.

Ayrıca, bir dokümantasyon alt dizini (Doc) ve bir komut dosyası alt dizini (Scripts) içeren, ancak başka alt dizinler içermeyen bir Komut Dosyası Kümesinin, s_ScribbleDocument’in örnek bir fiziksel uygulamasını gösterir.

Benzer şekilde, Veri Kümesinin fiziksel uygulaması bir dokümantasyon alt dizini (Doc) ve bir veri alt dizini (Data) içerir. Yardımcı Program Seti, biri dokümantasyon (Doc) için olmak üzere üç alt dizin tarafından uygulanır. Yardımcı Program Seti, UStoUKDate.frm ve UStoUKDate.vbp olmak üzere iki kaynak dosya içerir.

Bunlar UStoUKDate.exe yürütülebilir görüntüsünü oluşturmak için kullanılır. Test otomasyon rejimimizde yürütülebilir görüntü Test Yazılımı Kitaplığında tutulmaz, Yardımcı Program Seti bir Test Paketine kopyalandıktan sonra kaynaktan oluşturulur. Bu, bir Test Paketi veya Test Yazılımı Seti ön işleme görevi olarak üstlenilebilecek bir görevdir.

Tüm yürütülebilir dosyaların (Yardımcı Programlar) alt dizini, derlenmek yerine yorumlanan derlenmiş programı (.exe soneki) ve iki komut dosyasını (.cmd soneki) içerir. Bu, tüm yürütülebilir yardımcı programların tek bir alt dizinde olduğu anlamına gelir.

The post Test Yürütme Ürünleri first appeared on Akademi Delisi (Tez Yaptırma).