İ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).

Test Yazılımı Setlerini Test Yazılımı Kitaplığından kopyalama görevinin olabildiğince basit olması önemlidir. Bununla mümkün olduğu kadar hızlı ve mümkün olduğunca kusursuz demek istiyoruz. Görev uzun sürerse, insanlar onu üstlenmek konusunda isteksiz olabilir veya bunu yapmak için yeterli zamanı olmayabilir.

Herhangi bir özel mimariyi veya teslwarc’ı değerlendirirken, birisinin aceleyle ne yapması gerekeceğini düşünmeyi severiz. Ciddi bir kusurun rapor edildiğini ve düzeltildiğini ve düzeltilen yazılımın aynı gece gönderilmesi gerektiğini düşünüyoruz.

Otomatik testler olduğu için çoğu kişi testlerin ‘bir düğmeye dokunarak’ çalıştırılmasını bekleyecektir. Ancak, ihtiyacınız olan testlerden bazıları yazılımın yeni bir sürümünü test etmek için güncellendi, bu nedenle orijinal sürümlerin birkaç saat içinde alınması ve çalıştırılması gerekiyor. Testware Library’den gerekli testlerin bulunması ve kopyalanması birkaç saat sürecekse bir sorun var demektir.

Test Yazılımı Setlerini Test Yazılımı Kitaplığından kopyalama mekanizması, tamamlanmamış bir Test Yazılımı Setleri setinin aktarılmasını imkansız hale getirmelidir. Olmazsa, olacağını ve muhtemelen böyle bir hatayı en azından göze alabileceğiniz bir zamanda olacağını garanti edebilirsiniz.

Örneğin, gösterilen Test Suite hata düzeltmesini oluştururken, t_Scribble Breadth ve t_ScribbleList adlı iki Test Setini s_Scribble Document Komut Dosyası Kümesi ve d_ScribbleTypical Veri Kümesi olmadan kopyalamak mümkün olmamalıdır. Bu yapılırsa, testlerin tümü olmasa da çoğu başarısız olur.

Bu kadar küçük bir test koleksiyonu için bunun sonuçları çok kötü olmayabilir. Ancak, bir gecede çalıştırılması gereken çok sayıda test söz konusu olduğunda, yalnızca bir veri dosyasının atlanması, testlerin çoğunun başarısız olmasına ve yazılımın büyük ölçüde denenmemiş kalmasına neden olabilir.

Test yazılımı mimarisi bu akılda tutularak tasarlanmışsa, istenen testler için tüm test yazılımının kopyalandığından emin olmak için birkaç basit araç kullanılabilir. Örneğin, bir test paketinin çalıştırılması için gereken tüm Test Yazılımı Setleri bir metin dosyasında listelenmişse, bu, onları otomatik olarak uygun Test Paketine kopyalamak için kullanılabilecek bir kontrol listesi oluşturabilir.

Bu liste otomatik olarak oluşturulabildiğinden, örneğin gerekli olan diğer komut dizilerini ve veri dosyalarını belirlemek için her bir komut dizisini arayarak ve bunları kontrol listesine ekleyerek, tüm kontrol ve kopyalama işlemi otomatikleştirilebilir.

Yazılım Test programları
Yazılım test Metodolojileri
Yazılım test Süreçleri
Software testing
Yazılım testi Neden gereklidir
Yazılım test türleri
Yazılım Testi Nedir
Yazılım test otomasyon araçları

Konfigürasyon Yönetimi

Test yazılımının yapılandırmasını yönetmenin iki alternatif yolu vardır. Tercih ettiğimiz yöntem, Test Yazılımı Setlerinin Test Yazılımı Kitaplığı’nda yapılandırma öğeleri olarak (yani, bir sürüm numarasına sahip olarak) saklanmasıdır. Her set türünün içeriğini oluşturan ayrı test yazılımı yapıtlarının kendi sürüm numaraları yoktur. Bunun etkisi, Test Yazılımı Setindeki herhangi bir şey değiştiğinde, Test Yazılımı Setinin değiştirilen yapıtları ve değişmeyen yapıtları içeren yeni bir sürümünün yaratılmasıdır.

Temel, sürüm numarası olan ancak bir dizi yapılandırma öğesi içeren bir şeydir; bir temelin her sürümü, yapılandırma öğelerinin belirli sürümlerinden oluşturulur. Temel noktamız, yapılandırma öğeleri olan Test Yazılımı Setlerinden oluşan bir Test Paketidir.

Test yazılımı konfigürasyonunu yönetmenin alternatif bir yolu, bireysel test yazılımı yapıtlarının kendi sürüm numaralarına sahip olmaları olabilir. Bu durumda, bir Test Yazılımı Setindeki herhangi bir şey değiştirildiğinde, yalnızca değişen yapıtların yeni sürümleri olur. Diyagramın en alt düzeyi, sürüm numaralarıyla birlikte yapılandırma öğeleri olacaktır.

Test Yazılımı Setleri daha sonra yapılandırma öğeleri yerine temeller haline gelir. Test Paketi bir temel olarak kalır, ancak diğer temelleri içeren bir temeldir (doğrudan yapılandırma öğelerinden ziyade).

Test Yazılımı Seti temel çizgisinin yeni bir sürümü, değişmeyen yapıtları ve değişenlerin yeni sürümlerini içerecektir. Konfigürasyonu yönetmenin bu alternatif yolu, bazı durumlarda (özellikle iyi bir konfigürasyon yönetim sisteminin yürürlükte olduğu yerlerde) daha iyi olabilir.

Test Yazılımı Kitaplığı’nda bir Test Yazılımı Setinin birden fazla sürümü bir arada bulunabilir, ancak bir Test Paketinde bir Test Yazılımı Setinin yalnızca bir sürümü tutulabilir.

Test Yazılımı Güncellemelerini Kontrol Etme

Test yazılımı yapıtlarında yapılan değişiklikleri kontrol etmek açıkça önemli bir konudur. Test yazılımı mimarimizde, test uzmanlarının test yazılımı yapıtlarını güncelleyebilecekleri ve böylece yapılandırma öğelerinin yeni sürümlerini oluşturabilecekleri bir çerçeve oluşturduk.

Ancak iki veya daha fazla kişinin aynı yapılandırma öğesini aynı anda değiştirmeye çalışmasını engellemedik. İyi bir yapılandırma yönetim sistemi yürürlükteyse, bu zaten bir şekilde karşılanacaktır. Değilse, insanlar birkaç basit kurala uyarsa çoğu çatışmadan kaçınmak mümkündür.

Mevcut bir kaynak kodu kontrol sistemi varsa, test yazılımını kontrol etmek için yeterli olabilir. Bu, bilinen bir sistemi kullanma avantajına sahiptir, dolayısıyla öğrenme süresini en aza indirir. Özellikle manuel olarak yapılması hataya açık veya sıkıcıysa, konfigürasyon yönetimi görevlerini otomatikleştirmek için yardımcı programlar geliştirin.

Test Yazılımı Kitaplığına erişim mekanizmalarının, kişilerin herhangi bir Test Yazılımı Setini değiştirmeyi isteyip istemediklerini kaydetmelerine izin vermesini öneriyoruz. Bunların kopyalarını zaten almış başka kişiler varsa, bilgilendirilebilirler (belki otomatik olarak e-posta ile). Tersine, birisi zaten bir güncelleme için işaretlenmiş bir Test Yazılımı Setini güncelleme niyetini kaydetmeye çalıştığında, o anda onu kimin düzenlediği söylenecektir.

Test yazılımına erişimi kolaylaştırmak için sistemi olabildiğince basit tutun ve sistemi kullanılacağı tüm farklı şekillerde test edin. Örneğin, eski bir yazılım sürümü için test durumlarının bir alt kümesini seçin ve bunları iki farklı ortamda çalıştırın. Bu, başarılı bir şekilde, hızlı bir şekilde ve çok az manuel müdahale ile yapılabiliyorsa, o zaman muhtemelen doğru şeyler yapmışsınızdır.

Test Sonuçları

Şimdiye kadar test materyalleriyle, yani test senaryolarını çalıştırmak için ihtiyaç duyduğumuz tüm test yazılımlarıyla ilgilenen bir test yazılımı mimarisini tanımladık. Test yoluyla üretilen eserler hakkında hiçbir şey söylemedik. Bunlara Test Sonuçları diyoruz ve gerçek sonuçları, fark raporlarını ve test aracı günlüğünü içeriyorlar.

Test Sonucu yapıları, diğer test yazılımı yapılarından farklıdır. Test Sonucu yapıları, test durumu yürütmesi tarafından üretilirken, diğer test yazılımı yapıları, test durumları tarafından kullanılır. Test Sonuçları, bir test senaryosu her yürütüldüğünde üretilir. Bir test senaryosu, her seferinde aynı test materyalleri kullanılarak birçok kez yürütülebilir, ancak muhtemelen farklı Test Sonuçları üretecektir.

Test Sonuçları ile test materyalleri arasındaki diğer bir fark, Test Sonuçlarının genellikle ‘bir kez yazılır’ ve ardından ‘salt okunur’ olmasıdır. Testlerimizin doğru kayıtlarına sahip olmak istiyorsak, Test Sonuçlarının düzenlenebilir olması iyi bir fikir olmaz.

Öte yandan, uygulama öncesi test yazılımının (test materyalleri) düzenlenebilir olması ve gerçekten de test yazılımındaki değişikliklerin zaman içinde izlenebilmesi için yapılandırma kontrolü altında olması gerekir. Test Sonuçları bir kez oluşturulduktan sonra asla değiştirilmemelidir.

Bazı Test Sonuçlarını, büyük ihtimalle yazılım yayınlanmadan önce her bir test senaryosunun son çalışmasının sonuçlarını saklamak gerekli olabilir. Bu, belki de en iyi şekilde bir yapılandırma yönetim sisteminin kontrolü altında yapılır, böylece test yazılımı ve yazılımın doğru sürümleriyle ilişkilendirilirler.

The post Test Yazılımı Kitaplığına Erişim first appeared on Akademi Delisi (Tez Yaptırma).