Test Araçlarıyla Arayüz
Test Araçlarıyla Arayüz
Çalıştırmak istediğimiz tüm test senaryolarını içeren bir Test Paketine sahip olmak iyi ve güzel, ancak test aracının hangi test senaryolarının var olduğunu, nerede olduklarını ve nasıl çalıştırılacağını anlamasını sağlamalıyız.
Bunun elde edilme şekli, kullanılacak test aracına bağlı olarak büyük ölçüde değişecektir. Örneğin, bazı araçlar, tüm komut dosyalarının (veya daha doğrusu, komut dosyalarının derlenmiş sürümlerinin) tek bir dizinde olmasını veya özel bir dizinlenmiş dosya türüne eklenmesini gerektirir. Diğer araçlar, farklı dizinlere dağıtılan betiklerle çalışabilir.
Diğer bir önemli arayüz sorunu, bir test senaryosunun gerçek tanımıdır. Bazı araçlar test senaryolarını betiklerle doğrudan ilişkilendirerek tanımlarken, diğerleri test senaryolarını betiklerden bağımsız olarak belirlemenizi gerektirir. Her iki durumda da, önceki bölümde tartışıldığı gibi, her test durumuyla ilgili bazı bilgileri bir metin dosyasında tutmayı yararlı bulduk.
Bu yalnızca test adı (veya numarası), amacı ve onu uygulayan komut dosyaları ve veri dosyalarının bir listesi olabilir. Bu, bir test durumu hakkında herhangi bir bilginin bulunabileceği tek bir nokta sağlar. Ayrıca bazı test araçlarının gerektirdiği bilgileri de sağlar. Bizim görüşümüze göre, bu bilgi en iyi test yazılımı mimarisinde (yani Test Setlerinde) araçtan bağımsız bir biçimde ve dolayısıyla yapılandırma yönetimi altında bir metin dosyasında tutulur.
O zaman soru, bu bilgilerin test aracına nasıl kopyalanacağıdır. Bu, aracı belirli bir formatta metin dosyasıyla birlikte sunmanın basit bir durumu olabilir veya aracın kendisini kullanarak veri girişi sürecini otomatikleştirmeyi içerebilir. Hangi yaklaşımı benimsemeniz gerekiyorsa, onu otomatikleştirmelisiniz.
Test Paketi ile test aracı arasındaki arabirimle ilişkili tüm görevler (komut dosyalarının kopyalanması ve test tanımlarının test aracına yüklenmesi gibi), Test Paketi veya Test Seti ön işleme görevleri olarak gerçekleştirilebilir.
Bu noktada anlattığımız yazılım mimarisi, ilk başta bir somunu kırmak için balyoz almak gibi görünebilir. Dürüst olmak gerekirse, çok fazla test dosyanız yoksa, bu yaklaşım size zaman kazandıracağından daha fazla çaba gerektirecektir.
Ancak, test otomasyon çabalarınız başarılı olursa büyüyecek ve kontrol etmeniz gereken dosya sayısı da çok hızlı artacaktır. Gösterdiğimiz örnekler zorunlu olarak küçük ölçeklidir. Uygulamada, çoğu Test Setinde onlarca (hatta birkaç yüz) test durumu olmasını bekleriz. Ayrıca Scribble uygulamasının her bir özelliği için çok daha fazla test durumu görmeyi bekleriz.
Test senaryolarını bir ortamdan diğerine kopyalamak veya güncellemeler üzerinde çalışmak için olsun, bir test yazılımı alt kümesini kolayca izole edebilmenin faydaları hafife alınmamalıdır. Test yazılımının işlenme biçimlerindeki esneklik, test otomasyonunda uzun vadeli başarının anahtarıdır.
Test otomasyonu girişiminin başlangıcında uygun bir mimariyi devreye sokmazsanız, baştaki herhangi bir organizasyonu geri almak, özellikle de zaten hantal hale geldiyse, çok daha fazla çaba gerektirecektir. Bu mimari ile başlar ve baştan test otomasyon standartlarınızın bir parçası haline getirirseniz, ‘otomasyon yapmanın yolu’ olarak kabul edilecektir.
Test yazılımı mimarisi, test ve test otomasyonu için gerekli olan yapıların düzenlenmesidir. Kendi test yazılımı mimarinizin uygulanması, otomasyonunuzun nihai ölçeğine bağlı olacaktır. Betikler ve veriler gibi test yazılımlarını nasıl yeniden kullandığınızı, birden çok sürümü nasıl takip ettiğinizi ve farklı platformlarda ve ortamlarda nasıl test ettiğinizi etkileyecektir.
Yazılım test araçları
Yazılım test otomasyon araçları
Test Otomasyon araçları
İnterface testing
Selenium Test Otomasyon
Test otomasyon Nedir
Selenium Nedir
Test Otomasyon örnekleri
Tutarlı bir yaklaşım, daha fazla yeniden kullanım ve daha fazla esneklik anlamına gelir ve çok sayıda farklı ve uyumsuz planın ortaya çıkmasına izin vermek yerine en baştan geliştirilmelidir.
Şemamız, test durumlarını Test Setleri dediğimiz yapılar halinde gruplandırır. Bunlar, test durumlarını çalıştırmak için gereken tüm yapıtları (veriler, betikler ve beklenen sonuç gibi) içerir.
Test Paketi, hata düzeltme testi veya regresyon testi gibi bazı hedefleri karşılamak için gereken tüm test durumlarını içeren bir Test Setleri koleksiyonudur.
Farklı Test Setleri halinde gruplanan test senaryoları arasında paylaşılan herhangi bir test verisi veya komut dosyası, sırasıyla Veri Kümeleri ve Komut Dosyası Setleri olarak adlandırdığımız ayrı yapılarda depolanır. Benzer şekilde, herhangi bir paylaşılan yardımcı program (sürücüler, saplamalar ve özel karşılaştırıcılar gibi) Yardımcı Program Kümelerinde tutulur. Tüm bu farklı set türlerinin (toplu olarak Testware Setleri olarak bilinirler) ana sürümleri, bir Testware Kitaplığı’nda tutulur.
Test yazılımı yapıtlarına kolayca erişilebilmesini ve tüm değişikliklerin kontrol edilebilmesini sağlamak için Test Yazılımı Kitaplığı, yapılandırma yönetimi altında olmalıdır.
Test Sonuçları, Test Suite’in yapısına paralel olarak ayrı bir yapıda düzenlenir. Test Sonuçları, her test çalıştırıldığında oluşturulur. Yürütmenin ürünü gerçek sonuçtur; yürütmenin yan ürünleri test günlüklerini, fark raporlarını, test durum raporlarını vb. içerir.
Test yazılımı mimarisini bir dizin yapısında uyguluyoruz. Her Test Yazılımı Setinin kendi dizini (klasörü) vardır ve bu, Test Yazılımı Setinde bulunan her test yazılımı yapısı türü için bir alt dizin içerir.
Test Suite Dizini, Test Suite’in amacını yansıtır ve tüm ilgili Testware Setlerini alt dizinler olarak içerir. Test Sonuçları paralel dizinlerde tutulur. Mantıklı bir adlandırma kuralı önemlidir.
Testlerin fiziksel uygulamalarına göre izlenebilirliğine yardımcı olmak için, test durumlarının ayrıntılarının yardımcı programlar tarafından aranabilmesi için metin dosyalarında açıklanmasını öneririz. Son olarak, test senaryolarının test yürütme aracı tarafından çalıştırılması gerekir; test yazılımının yeniden yapılandırılması (komut dosyalarını aracın kendi komut dosyası kitaplığına kopyalamak gibi) da otomatikleştirilmelidir.
Bu bölümde açıklanan yaklaşım, kapsamlı test otomasyonuna sahip birçok kuruluşta iyi çalıştı. Şu anda ‘aşırı’ gibi görünse de, başlangıçta bu sorunları çözmezseniz daha sonra ciddi sorunlarla karşılaşacaksınız.
İnterface testing Selenium Nedir Selenium Test Otomasyon Test otomasyon araçları Test otomasyon Nedir Test Otomasyon örnekleri Yazılım test araçları Yazılım test otomasyon araçları