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