Kaçınılmaz olarak, test otomasyonu için gereken çok sayıda yapı vardır. Geliştirdiğimiz örnek otomatik test durumu aşağıdaki üç temel dosyaya sahipti:

»country.scp, test betiği;
» countrys.dcm, düzenlenecek ilk belge – test verilerimiz;
« country2.dcm, yürütme sonrası karşılaştırma için beklenen çıktı.

Bunlar, test senaryosu için test malzemeleridir. Test çalıştırıldıktan sonra, ek olarak aşağıdaki üç dosyaya sahip olabiliriz:

» country.dcm, gerçek çıktı;
»country.dif, karşılaştırma aracı tarafından üretilen fark raporu;
«country.log, test çalıştırıldığında ne olduğunun denetim izi.

Ülkelerin gerçek çıktısı, test senaryosunun ürünüdür ve diğer ikisi yan ürünlerdir. Betik oluşturma yaklaşımına ve kullanılan araca bağlı olarak aşağıdaki dosyalara da sahip olabiliriz:

• Paylaşılan bir komut dosyası olan ScribbleOpen.scp;
• Paylaşılan bir komut dosyası olan ScribbleSaveAs.scp;
• her betiğin derlenmiş sürümleri.

Son olarak, bununla ve muhtemelen diğer test durumlarıyla ilişkili bir belirtim olmalıdır:

• test senaryosunun tasarımını ve uygulamasını belgeleyen test spesifikasyonu.

Bu bize sadece bir test durumu için olası toplam on iki dosya verir. Elbette, ikinci bir test durumu bunlardan bazılarını paylaşıyor olabilir (özellikle test spesifikasyonu, paylaşılan betikler ve ülkeler.dcm test veri dosyası). Ancak bu, ikinci bir test durumu için altı yeni dosyaya ve üçüncü bir test durumu için yine altı yeni dosyaya ihtiyaç duymamıza neden oluyor.

Farklı ortamlar, test araçları ve test durumları daha fazla veya daha az dosya gerektirebilir, ancak burada belirtmek istediğimiz nokta, birkaç on otomatik test durumu için bile muhtemelen birkaç on veya belki birkaç yüz dosya olabileceğidir.

Tamam, tüm bilgilerin ayrı dosyalarda saklanması gerekmez. Örneğin, veriye dayalı bir komut dosyası oluşturma yaklaşımı kullanılıyorsa, tek bir veri dosyasında birçok farklı girdi verisi kümesi bulunabilir. Bazı bireysel dosyaların boyutunun yönetilemez hale gelmesi muhtemel olduğundan, yapılabilecek sıkıştırma miktarının bir sınırı olacaktır.

Test prosedürü örneği
Yazılım test Süreçleri
Yazılım test Çeşitleri
Yazılım test Nedir
Yazılım test Metodolojileri
Yazılım test araçları
Yazılım test teknikleri PDF
Fonksiyonel test nedir

Yalnızca birkaç on otomatik test durumu olsa da ve özellikle bunlarla ilgilenen yalnızca bir veya iki kişi olduğunda, yapılandırılmış veya özel amaçlı herhangi bir test yazılımı mimarisi yeterli olacaktır.

Bununla birlikte, test vakalarının sayısı, örneğin on kat arttığında veya yeni kişiler otomatik testlerin sürdürülme sorumluluğunu üstlendiğinde, daha önce yeterli olan birçok hatanın ve verimsiz otomatik testlerin temel nedeni haline gelecektir.

Bu deneyim raporu, test otomasyonunun bir veya iki kişinin sorumluluğu veya yalnızca özel ilgisi olduğu bir dizi kuruluş için tipiktir. Ayrıldıklarında veya başka projelere geçtiklerinde, otomatik testlere ilişkin bilgileri (ne yaptıkları ve bunları nasıl kullanacakları) onlarla birlikte gider.

Testleri otomatikleştirmek için harcadıkları tüm çaba ve kazandıkları deneyim, projede kaybolur. Bu vakaların çoğunda ortak bir tema, test yazılımının organizasyon eksikliğidir.

Tüm yapıtların bir yerde bulunması gerekir ve bir otomasyon girişiminin başlangıcında bunun nerede olması gerektiğine karar vermek çok daha iyidir, aksi takdirde, test yazılımını düzenlemek için elinizdeki test kullanıcıları kadar çok farklı yol bulursunuz.

Evet, çoğu insan üzerinde çalıştıkları test senaryolarının kısıtlamaları göz önüne alındığında mantıklı bir şeyler yapacaktır, ancak bu her ne ise, başka birinin benimsediği yaklaşımla tutarlı olması pek olası değildir. Test otomasyonu, bir test her otomatikleştirildiğinde hangi dosyaların nereye yerleştirileceğine tekrar tekrar karar vermek zorunda kalmadan veya her başka test çalıştırıldığında Test Sonuçlarını nerede bulacağınızı hesaplamak zorunda kalmadan yeterince zordur.

Bir kişi başka biri tarafından otomatikleştirilmiş testleri kullanmaya başladığında, durup komut dosyalarının nerede olduğunu, test verilerinin nerede tutulduğunu, sonuçların nerede saklandığını vb. öğrenmesi gerekir. Bu elbette zaman alacak ve otomasyonu çok daha az verimli hale getirecektir.

Pilot proje sırasında en uygun test yazılımı mimarisini belirlemek için uyumlu bir çaba gösterilmesini öneririz. Bu, farklı türde otomatik test senaryolarının ve farklı test cihazlarının ihtiyaçlarının dikkate alınmasına yardımcı olacaktır. Elbette bu, yeni gereksinimler ve fırsatlar ortaya çıktıkça zaman içinde geliştirilebilir, ancak bu, iyileştirmelerin iyi bir temel üzerine inşa edildiği anlamına gelmelidir.

Yeniden Kullanma

Test otomasyonunda gerçek bir ilerleme kaydetmek için betiklerin ve verilerin yeniden kullanılması çok önemlidir. İyi bir otomatik betik seti, çok sayıda betiğin yeniden kullanımını içerecektir. Açıkladığımız gibi, yeniden kullanımın ana nedeni, tekrarı ortadan kaldırmak (örneğin navigasyon için), böylece yeni testlerin uygulanmasını hızlandırmak ve bakım maliyetlerinden tasarruf etmektir.

Komut dosyalarını ve verileri yeniden kullanma niyeti, gerçek yeniden kullanımı garanti etmez. Yeniden kullanılabilir komut dosyaları ve veriler geliştirmek için çok çaba harcanmalıdır, ancak bu çaba yalnızca komut dosyaları ve veriler gerçekten yeniden kullanılıyorsa değerlidir. Yeniden kullanmak için, farklı test edicilerin bu paylaşılan komut dizilerini ve verileri bulabilmeleri ve kopyalar oluşturmadan bunlara kolayca başvurabilmeleri gerekir.

Paylaşılan betiklerle ilgili tartışmamızda, birinin kendi sürümünü uygulamaya karar vermeden önce yeniden kullanılabilir bir betik aramak için harcayacağı süre (iki dakika) için bir sınırdan bahsetmiştik. Bunun gerçek olduğuna inanıyoruz.

Belirli bir işi yapmak için bir komut dosyasının var olup olmadığını hızlı bir şekilde bulma yeteneği, başarılı bir şekilde yeniden kullanım için çok önemlidir, ardından komut dosyasını hızlı bir şekilde bulabilmek de aynı şekilde çok önemlidir. Komut dosyalarının ne kadar hızlı bulunabileceği, test yazılımı mimarisi tarafından yönetilir. Tüm otomatik testlerde tutarlılık yoksa, otomatörleri yeniden kullanmak yerine komut dosyalarını yeniden icat etmeye teşvik ederek, daha zor ve hataya açık olacaktır.

Yeniden kullanılabilir komut dosyaları kolayca bulunsa bile yeniden kullanım garanti edilmez. Otomatörün daha sonra betiğin uygunluğunu belirleyebilmesi gerekir. (Garip bir şekilde, bazı yeniden kullanılabilir komut dosyaları yeniden kullanılabilir değildir. Yeniden kullanım, komut dosyaları olarak tasarlanması gereken bir şeydir.)

Bir betiğin belirli bir amaca uygunluğunu belirlemek için ne kadar çaba gerekeceği, büyük ölçüde betiğin belgelerinin kalitesine bağlıdır. Bu aynı zamanda betiğin nasıl kullanılacağına ilişkin ayrıntıları öğrenmenin ne kadar kolay olduğunu da yönetecektir.

The post Test Yapısının Çözülmesi first appeared on Akademi Delisi (Tez Yaptırma).