Ön ve son işlemeyi uygulamaya yönelik alternatif yaklaşımları göstermek için örnek bir test durumu kullanacağız. Kullanmayı seçtiğimiz, Scribble’ın Kaydetme işlevini kullanmak için kullanılan ve t_ScribbleBreadth Test Kümesine ait olan bir test senaryosunun geliştirilmiş bir versiyonudur. Bu ilk olarak verilen örneklerde gösterildi.

Bu test senaryosunda, ön işleme görevleri tarafından yerine getirilebilecek bir dizi ön koşul ve son işleme görevleri tarafından benzer şekilde ele alınabilecek birkaç son koşul vardır.

Önkoşullar, bazı özel dosyaların çalışma dizininde (yani, varsayılan dizin veya klasör) bulunması ve Scribble uygulaması için bir yapılandırma ayar dosyasının (Scribble.ini) belirli bir sürümünün, Scribble uygulamasıyla aynı yerde bulunması gerektiğidir. kendisi. Bu ön koşulları elde etmek için gereken ön işleme görevleri gösterilmektedir.

Ön işleme görevleri aşağıdaki gibidir:

» EditMe.dcm, NoRead.dcm ve NoWrite.dcm veri dosyalarını Test Setinden (Data alt dizini) sonuçlar dizinine kopyalayın;
« NoRead.dcm dosyasında ‘okuma erişimi yok’ iznini ve NoWrite.dcm dosyasında ‘yazma erişimi yok’ iznini ayarlayın;
» paylaşılan veri dosyası country.dcm’yi Veri Kümesinden sonuçlar dizinine kopyalayın;
» Scribble uygulaması için mevcut yapılandırma ayarları dosyasını Scribble.ini’yi Saved.ini olarak yeniden adlandırın;
« Testl.ini dosyasını Test Setinden Scribble dizinine (uygulamanın tutulduğu yer) kopyalayın ve yeni yapılandırma ayarları dosyası olması için Scribble.ini olarak yeniden adlandırın.

Gösterilen Test Takımı ve Test Setinin tamamlanmadığını unutmayın; yalnızca örnek test durumuyla ilgili ayrıntıları gösterdik. Test senaryosu yürütüldükten sonra, gerçekleştirilecek birkaç işlem sonrası görev vardır.

Bunlar, gösterilmektedir ve aşağıdaki gibidir:

• sonuçlar dizininden NoRead.dcm ve NoWrite.dcm dosyalarını silin;
• yapılandırma ayarları dosyasını Karalama dizininden sonuçlar dizinine taşıyın;
• kaydedilen Scribble yapılandırma ayarları dosyasının Saved.ini dosyasını Scribble.ini olarak yeniden adlandırın.

Kodlar

İşlem öncesi ve sonrası görevler, doğrudan test yürütme aracı tarafından gerçekleştirilecek şekilde betiklerde uygulanabilir. Görevlerin çoğunun benzer olduğu göz önüne alındığında, bu, paylaşılan komut dosyaları kullanılarak en verimli şekilde yapılabilir.

Örneğin, paylaşılan bir komut dosyası, standart bir dosya kopyalama işlevi sağlayabilir. Test komut dosyası, paylaşılan komut dosyasına kopyalanacak dosyanın adını iletir ve ardından paylaşılan komut dosyası, kaynak ve hedef dosyanın tam yol adlarını belirleyebilir (çünkü test yazılımı mimarisi hakkında bir bilgi yerleşik olabilir). 

Bu yaklaşım, her test durumu için bir komut dosyası olduğunda açıkça uygundur. İki betiği gösterir, bunlardan biri (SaveTestl.scp) ‘Kaydet’ test senaryosunun kendisini uygular ve diğeri test senaryosunu çalıştırmak için diğer betiği çağırmadan önce ön işlemeyi gerçekleştirir ve ardından son işlemeyi gerçekleştirir.

Test Case ve test senaryosu farkı
Yazılım test senaryosu örneği
Yazılım test örnekleri
Örnek test senaryosu
Test case Nedir
Test senaryosu Şablonu
Test Case Örnekleri Excel
Test Dokümanı nasıl hazırlanır

Ön ve son işleme, her biri ortak bir işleme görevi gerçekleştiren ayrı paylaşılan komut dosyaları tarafından uygulanır. Dosyayı Kopyala betiği, test yazılımı mimarisine ilişkin bilgi birikimine sahiptir. Basit bir dosya adı iletildiğinde, bu dosyayı test senaryosunun ait olduğu Test Kümesinin Veri alt dizininde bulduğunu bilir.

Bir yol adı iletilirse, onu doğrudan kullanır. Bir yol adının bir değişken adı içerdiği durumlarda (örnekte ©TESTSUITE ve ©SCRIBBLE gibi), onu uygun yol adıyla değiştirecektir. CopyFilc komut dosyası, kopyalaması için kendisine verilen herhangi bir dosyanın hedefinin mevcut test senaryosunun sonuç dizini olduğunu da bilir. Böylece, ortak bir ön işleme görevini gerçekleştirmek için çok basit bir arayüz kullanabiliyoruz.

CopyTo betiği, kendisine bir hedef yol adı verilmesi gerektiği için, CopyFile betiğinden işlevsellik açısından farklıdır. Bu, dosyaları sonuç dizini dışındaki hedeflere kopyalamak için kullanılır. MoveFile komut dosyası, dosyaları her zaman sonuçlar dizinine taşır ve SetAccess ve DeleteFile komut dosyaları, yalnızca bir dosya adı verildiğinde yol adının sonuçlar dizinininki olduğunu varsayar.

Bu basit arabirimlerin nedeni, işlem öncesi ve sonrası görevleri belirlemeyi kolaylaştırması ve böylece hata olasılığını azaltmasıdır. Ayrıca, bu paylaşılan betikler, belirli hataların yapılmamasını sağlamak için ek kontroller oluşturabilir.

Örneğin, bir ön işleme görevinin bir kutucuğu Test Paketinden çıkarmasını istemeyiz (çünkü test senaryosunun bir sonraki çalıştırılışında orada olmayacaktır), bu nedenle MoveFile betiği Test Paketiyle eşleşen bir yol adını kabul etmez. yol adı.

Komut Dosyalarının Kullanımı

Yukarıda gösterildiği gibi, işlem öncesi ve sonrası görevler, doğrudan test yürütme aracı tarafından gerçekleştirilecek şekilde betiklerde uygulanabilir. Ancak, alternatif bir yaklaşımın değerlendirilmesini öneriyoruz.

İşleme öncesi ve sonrası görevlerin çoğu, bir tür komut dosyası (birkaç alternatif ad vermek için komut prosedürü, kabuk betiği veya toplu iş dosyası) kullanılarak uygulanabilir.

Bunun birkaç zorlayıcı nedeni var:

1. Komut dilleri genellikle yürütme aracının komut dosyası yazma dilinden çok işlem öncesi ve sonrası görevler için daha uygundur.
2. Genellikle, daha fazla kişi komut diline aşinadır, çünkü bu komutlar dosyaları kopyalamak ve taşımak gibi temel işlevler için kullanılır (el ile test edenler, işleri kendileri için kolaylaştırmak için zaten kendi komut dosyalarını yazabilirler).
3. Komut dosyaları, herhangi bir zamanda, diğer test görevlerinden bağımsız olarak ve test yürütme aracına ilişkin herhangi bir özel beceri veya bilgi olmaksızın herkes tarafından çalıştırılabilir.
4. Komut dosyaları, manuel testin işlem öncesi ve sonrası görevlerini otomatikleştirmek için kullanılabilir.

Dördüncü nokta genişletmeye değer. Test otomasyonu genellikle test yürütmenin otomasyonu olarak anlaşılır, ancak test yürütme dışındaki test görevlerinin otomatikleştirilmesinde yanlış bir şey yoktur. İşleme öncesi ve sonrası görevler, yürütme manuel olarak yapılsa bile otomasyon için ideal adaylardır. Bu, manuel test üzerinde olumlu ve anında bir etki yaratmanın iyi bir yoludur.

Bazı testçiler bunu yine de yapıyor ancak komut dosyaları testlerin resmi bir parçası haline gelmiyor ki bu çok yazık. Test uzmanlarını bu tür komut dosyalarını kullanmaya ve paylaşmaya teşvik edin. Komut dosyalarının kullanılması, manuel testi biraz hızlandırabilir ve can sıkıcı yazım hatalarından bazılarını önlemeye yardımcı olabilir.

Biraz ustalıkla, veri odaklı birkaç genel komut dosyası geliştirmek mümkün olabilir, bu da test uzmanlarının otomasyonu uygulamak zorunda kalmadan otomatikleştirilmiş ön ve son işleme görevlerini belirlemesine olanak tanır. Bunlar, işleme öncesi ve sonrası görevlerin belki de %80’ini gerçekleştirebilir. Bu, açıklandığı gibi test yazılımı mimarisinin tutarlılığını gerektirecektir.

Komut dosyaları muhtemelen önceki bölümde paylaşılan betikler için açıklanan işlevlerin aynısını sunar. Bu yapılsaydı, yine de komut dosyalarını çağırmamız gerekirdi. Bu, komut dosyasından yapılabilir, bu nedenle, paylaşılan komut dosyalarını çağırmak yerine, test komut dosyası, paylaşılan komut dosyalarını çağırır.

Alternatif olarak, bir komut dosyası her test senaryosunu uygulayabilir. Bu, ön ve son işlemeyi gerçekleştirmek için paylaşılan komut dosyalarını çağırır ve test senaryosunun kendisini yürütmek için test yürütme aracını çağırır.

The post Örnek Test Durumu first appeared on Akademi Delisi (Tez Yaptırma).