Bir test yazılımı yapısının tüm donanım platformu veya ortama özgü sürümleri bir arada tutulur. Bu, aynı Test Yazılımı Setinin farklı sürümlerine ait olan aynı donanım platformu veya ortamı için test yazılımı yapıtlarının farklı sürümleriyle karıştırılmamalıdır.

Örneğin, Test Kümesi t_ScribbleList’teki beklenen sonuçların donanım platformuna özgü olduğunu varsayalım. (Aslında durum böyle olmasa da, sadece bu örneğin amacı için olduğunu varsayacağız.) Bunun nasıl yapılandırılabileceğini gösterir.

Aynı Test Yazılımı Setinde tüm donanım platformuna veya ortama özgü sürümlere sahip olmak hem uygun hem de mantıklıdır. Belirli bir platform için beklenen sonuçlara erişim söz konusu olduğunda, iyi çalışan iki plan vardır.

Uygun sürümü belirlemek ve tüm uygun yapıtları bir dizin düzeyinde Beklenen dizine kopyalamak için Test Paketi için bir ön işleme görevi kullanabiliriz. test yapmak. Alternatif olarak, platforma özgü olabilen yapılara yapılan tüm referanslar, bir ön işleme görevi tarafından düzenlenebilir.

Her farklı donanım platformu veya ortamı için test sonuçları dizini hiyerarşisinin farklı bir örneğinin kullanılması gerektiğinden, test sonuçları yapısında böyle bir ayrım yapmanın gerekli olmayacağını unutmayın.

Ölçeklendirme

Test Setleri için tanımladığımız fiziksel yapı, nispeten az sayıda test vakası için iyi çalışır, ancak bir Test Setindeki bir alt dizinde çok sayıda yapay yapı (diyelim ki onlarca) olduğunda durum zorlaşır. Bunun üstesinden gelmek için Test Setini yeniden düzenliyoruz.

Bir Test Setindeki tüm test durumlarını tek bir grup olarak düşünmek yerine, şimdi onları Test Setinde ayrı gruplara ayırıyoruz. Bu, bir olasılık olmasına rağmen, betiklerin ve veri dosyalarının ayrılmasını gerektirmez. Karalama genişlik testleri Test Seti için farklı bir fiziksel yapı gösterir.

Bu yapı, Beklenen sonuç alt dizinini ortadan kaldırır ve her bir test durumu grubu için bir alt dizinle değiştirir. Bu durumda, artık her işlev için tek bir genişlik test durumu yerine, Karalama’daki her işlev için bir test durum grubumuz var.

Aynı fikir komut dosyalarına ve verilere uygulanabilir, ancak farklı gruplardaki test senaryolarında paylaşılan (ancak diğer Test Setlerindeki test senaryoları tarafından paylaşılmayan) bu komut dosyalarının ve veri dosyalarının işlenmesine özen gösterilmelidir.

Örneğinde, Doc alt dizinine bir dizi test durumu tanımlama dosyası ekledik. Bunların amacı bir araya getirmektir. Bu, ne kadar çok test vakası olursa o kadar önemli hale gelir, ancak her durumda tavsiye edeceğimiz bir şeydir. Bunlar bir sonraki alt bölümde daha ayrıntılı olarak tartışılmaktadır.

İzlenebilirlik Örnekleri
Kalibrasyonda izlenebilirlik Nedir
Üretimde izlenebilirlik
Tekstilde izlenebilirlik
İzlenebilirlik Nedir
İZLENEBİLİRLİK Prosedürü
Ürün seri numarası Nasıl oluşturulur
Gıdada İZLENEBİLİRLİK Nedir

Test Senaryolarını ve İzlenebilirliği Tanımlama

Gördüğümüz gibi, bir test senaryosunun fiziksel uygulaması genellikle birçok farklı türde test yazılımı yapıtı içerir, ancak belirli bir tanesini içermesi garanti edilmez. Örneğin, anahtar kelimeye dayalı test senaryoları, kendileriyle benzersiz bir şekilde ilişkilendirilmiş komut dosyalarına sahip değildir.

Doğrusal betikler tarafından uygulanan test senaryolarının kendileriyle ilişkilendirilmiş test veri dosyalarına sahip olması gerekmez ve benzer şekilde, beklenen sonuç komut dosyasında tutuluyorsa, herhangi bir ayrı beklenen sonuç dosyası olması gerekmez.

Bu oldukça esnek durum göz önüne alındığında, bir Test Kümesinde hangi test durumlarının olduğunu nasıl belirleyebiliriz? Test senaryolarının uygulanması anlaşılırsa zor olmayabilir. Örneğin, veriye dayalı bir yaklaşımın kullanıldığını biliyorsak, her bir test durumu grubu için ayrı bir veri dosyası bulabiliriz. Alınan yaklaşımı bilmiyorsak, o zaman o kadar kolay olmayacaktır.

Bu önemli bir husustur. Bu bölümün başındaki deneyim raporunu hatırlayın: ‘Yeni testleri nasıl geliştireceğimizi veya mevcut testleri nasıl sürdüreceğimizi bilmiyoruz. Bu durum neyin bulunması gerektiği (komut dosyası, veri dosyası, başka bir şey?) anlaşılmadığı için ortaya çıkmış olabilir, nerede bulacağınız önemli değildir.

Test yazılımı mimarimiz iyi yapılandırılmış ve tutarlı olsa bile, test senaryolarının kendileri doğrudan ve tutarlı bir şekilde tanımlanamazsa kusurlu olduğu kanıtlanabilir.

Açıklanacağı gibi, otomatik testler ile otomatik testler arasında büyük bir fark vardır. İkincisi, daha birçok görevin otomatikleştirilmesini gerektirir (kurulum ve temizleme gibi). Bunu yapmak için, test senaryolarını bulabilen ve her biriyle ilişkili tüm ilgili test yazılımlarını tanımlayabilen bazı yardımcı programlara ihtiyacımız olabilir.

Test senaryolarını özellikle bir metin dosyasında tanımlamanızı öneririz. Bu, bir Test Setindeki test durumlarıyla ilgili tüm bilgileri tek bir yerde bir araya getirmemizi sağlayacaktır.

Scribble’ın kontrol işleviyle ilgili genişlik test durumları grubu için bir test durumu tanım dosyası örneğini gösterir. Dosyanın düzeni, bir yardımcı programın hangi test durumlarının mevcut olduğu ve hangi test yazılımlarını kullandıkları gibi şeyleri belirlemek için dosya üzerinde bir metin araması gerçekleştirebileceği şekildedir.

TEST MATERYALLERİ bölümü, test senaryosu için test materyallerini oluşturan tüm dosyaları listeler. Benzer şekilde, TEST SONUÇLARI bölümü, testin sonunda olması gereken tüm test sonuç dosyalarını listeler. Bu kayıtların her birinin başındaki anahtar sözcükler (‘SCRIPT’, ‘DATA’ ve ‘SCRIB_DOC’) dosya türünü belirtir. Bu örnekte, veri dosyası Test Kümesinin dışında bulunur.

Test Suite içinde paylaşılan veri dosyasının tam olarak nerede olacağını belirlemek mümkündür (kendi Veri Kümesinde kaldığı için), ancak Test Suite’in kendisinin nerede bulunacağını tahmin edemeyiz. Bu nedenle, ‘@TESTSUITE’ anahtar kelimesini kullandık, burada ‘@’ bize bunun gerçek bir yol adının yerine kullanılması gerektiğini söyler. Bu, bilmesi gereken yardımcı programlar tarafından istendiğinde yapılabilir, çünkü zaten bu dosyaya bakıyorlarsa Test Paketinin nerede olduğunu bilmeleri gerekir.

Farklı test durumları arasındaki örtüşmeyi azaltmak için farklı bir düzen kullanılabilir. Örneğin, gruptaki tüm test senaryoları için aynı veri dosyası kullanılıyorsa, her test senaryosu için özel olarak tanımlamak yerine bu, gruptaki tüm test senaryoları için ortak olan test materyallerini tanımlayan özel bir bölüme konulabilir.

Vaka tanım dosyalarını test etmek için onları daha özlü hale getirmek ve test faaliyetlerinin daha fazla otomasyonunu (işleme öncesi ve sonrası faaliyetler gibi) desteklemek için uygulanabilecek çok daha fazla fikir vardır. Ancak bunların çoğu uygulamaya ve ortama özel olabilir, bu nedenle bu kitapta bunlara yer vermeyeceğiz. Ayrıca kendimiz hakkında bilmediğimiz birçok fikir var.

The post İzlenebilirliği Tanımlama first appeared on Akademi Delisi (Tez Yaptırma).