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

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

Bu yazımızda, test aktivitelerini açıklıyoruz, çünkü bunlar otomatikleştirmek isteyebileceğimiz aktivitelerdir. Bu faaliyetlerin farklı kuruluşlarda gerçekleştirilme biçiminde geniş farklılıklar vardır. Bazı kuruluşlar tüm bu faaliyetleri resmi olarak gerçekleştirecektir. Diğerleri neredeyse kaotik olma noktasına kadar gayrı resmi olabilir. Her halükarda, temel faaliyetler hala aşağı yukarı açıklanan sırayla gerçekleştirilir.

İdeal bir dünyada test, kurumsal test hedeflerinin ve test politikasının belirlenmesi, test hedeflerini karşılamak için test stratejilerinin belirlenmesi ve bireysel projeler için politikalar ve stratejiler ile başlamalıdır.

Yönetim seviyesindeki test planlaması, tüm test faaliyetleri için gereken sürenin tahmin edilmesini, test faaliyetlerinin planlanmasını ve kaynaklandırılmasını, testin ilerleyişini izlemeyi ve tüm test çabasını yolunda tutmak için gereken tüm önlemleri almayı içerir. Bu üst düzey faaliyetler, bir projenin başlangıcında yapılmalı ve geliştirme süreci boyunca sürdürülmelidir.

Test senaryoları tipik olarak sistemin test edilecek çeşitli işlevsel alanları için geliştirilecektir. Bu test durumlarının her biri, beş ayrı geliştirme faaliyetinden (yeniden test etme hariç) geçecektir.

Beş test geliştirme faaliyeti, herhangi bir test durumu için ardışıktır, yani test koşulları, bu koşullar için bir test senaryosu tasarlanmadan önce tanımlanmalıdır, bir test senaryosu oluşturulmadan önce tasarlanmalı, çalıştırılmadan önce inşa edilmelidir, ve sonuçları karşılaştırılmadan önce çalıştırın. Beş adım, her adımda belgelerle resmi olarak yapılabilir veya beş adımın tümü, testi yapan kişi test etmek için oturduğunda gayri resmi olarak yapılabilir.

Testte birçok terminoloji varyasyonu olduğuna dikkat edin. Sözlükte her terimle ne demek istediğimizi tanımladık.

Test Koşullarını Tanımlayın

İlk aktivite, ‘neyin’ test edilebileceğini belirlemek ve ideal olarak bu test koşullarına öncelik vermektir. Test koşulu, bir testle doğrulanabilecek bir öğe veya olaydır. Bir sistem için ve işlevsellik testleri, performans testleri, güvenlik testleri vb. gibi farklı test kategorileri için birçok farklı test koşulu olacaktır.

Test teknikleri, test uzmanlarının test koşullarını titiz ve sistematik bir şekilde türetmesine yardımcı olur. Test üzerine bir dizi kitap denklik bölümleme, sınır değer analizi, neden-sonuç grafiği ve diğerleri gibi test tekniklerini açıklar. Sınavla ilgili kitaplar ve diğer konular hakkında bir bibliyografya, yazarların web sitesinde bulunabilir.

Test koşulları, incelenebilecek durumların açıklamalarıdır. Kısa cümleler, tablolardaki girişler veya akış grafikleri gibi diyagramlar dahil olmak üzere farklı şekillerde belgelenebilirler. Test koşullarını belirleme faaliyetinin en iyi ilgili geliştirme faaliyetleriyle paralel olarak, yani V-modelinin sol tarafında yapıldığını unutmayın.

Test Senaryoları Tasarlayın

Test senaryosu tasarımı, ‘neyin’ nasıl test edileceğini belirler. Bir test senaryosu, sırayla gerçekleştirilen ve bir test hedefiyle, yani testlerin nedeni veya amacı ile ilgili bir dizi testtir. Test durumu tasarımı, belirli girdi değerlerini, beklenen sonuçları ve ortam önkoşulları gibi testin çalışması için gereken diğer bilgileri içeren bir dizi test üretecektir.

Beklenen sonuçların, çıktısı alınması veya oluşturulması gereken şeyleri, değiştirilmesi veya güncellenmesi gereken şeyleri (örneğin bir veritabanında), değiştirilmemesi gereken şeyleri ve silinmesi gereken şeyleri içerdiğine dikkat edin. Beklenen sonuçlar kümesi oldukça büyük olabilir.

Örnek bir test durumu verilmiştir. Bu test senaryosunu gerçekleştiren test uzmanının, en azından yeni bir sipariş oluşturmayı, bir satınalma siparişini doğrulamayı, yeni bir sipariş raporu yazdırmayı vb. bilecek ölçüde satınalma siparişi sistemini anlaması gerektiğini unutmayın. 

Aşağıdaki üç test koşulu bu test durumu tarafından gerçekleştirilir:

• tek bir ürün için oluşturulan sipariş (VB10);

• 100 sipariş miktarı (VB23);  

• e-siparişin oluşturulması

Her koşulun sonundaki parantez içindeki etiketler, test koşulları ve test senaryoları arasında çapraz referans için kullanılır. Burada kullanılan etiketler, denklik bölümleme ve sınır değer analizi kullanılarak türetilen test koşullarını temsil eder. VB10, 10. Geçerli Sınır, VB23, 23. Geçerli Sınır ve V8, 8. geçerli denklik bölümüdür.

Yazılım test Süreçleri
Yazılım testleri
Yazılım test Metodolojileri
Test prosedürü örneği
Yazılım test programları
Yazılım test Çeşitleri
Yazılım Test Dokümanı Örneği
Yazılım test teknikleri PDF

Bu örnek test senaryosu, daha geniş bir test senaryosu setinden alınmıştır. Satınalma siparişlerinin doğru yazdırılması gibi diğer hususları halihazırda test ettiğimiz varsayılmaktadır. Bu örnek test durumunda, farklı yönleri test etmek için bazı ‘güvenilir’ işlevler kullanıyoruz. Son sütunda, kapsanan koşul etiketlerini not ettik. Adım 2 ve 3 ayrıca adım 1 ile aynı etiketleri uygular ve adım 4 ve adım 5 V8 alıştırmasını yapar.

Bu test durumu stilinin, belirsiz manuel test komut dosyası olarak tanımlayacağımız şey olduğuna dikkat edin. Her test beklenen sonucu belirtmelidir. Beklenen sonuç çalıştırılmadan önce belirtilmemişse, yazılımın doğru olup olmadığını kontrol etmek için ilk gerçek sonuç dikkatlice incelenmeli ve doğrulanmalıdır.

Bu, elbette, sonucun doğru bir şekilde değerlendirilmesi için test edilen yazılım hakkında yeterli bilgiye sahip bir test uzmanı gerektirecektir. Doğruysa, gelecekte beklenen sonuç olabilir, yani bu testin gelecekteki gerçek sonuçlarının otomatik olarak karşılaştırılabileceği sonuç. Bu yaklaşıma referans testi denir. Doğrulanmış beklenen sonuca bazen altın versiyon denir.

Test senaryosu tasarımı (ideal olarak beklenen sonuçların önceden tahmin edilmesiyle) en iyi V modelinin sol tarafındaki ilişkili geliştirme faaliyetleriyle paralel olarak, yani test edilecek yazılım oluşturulmadan önce yapılır.

Test Senaryolarını Oluşturma

Test senaryoları, test komut dosyaları, test girdileri, test verileri ve beklenen sonuçlar hazırlanarak uygulanır. Bir test komut dosyası, bir test yürütme otomasyon aracı tarafından kullanılan ve tipik olarak bir dosyada tutulan resmi bir sözdizimine sahip veriler ve/veya talimatlardır. Bir test komut dosyası, bir veya daha fazla test senaryosu, gezinme, kurulum veya temizleme prosedürleri veya doğrulama uygulayabilir.

Bir test komut dosyası, testi manuel olarak çalıştırmak için kullanılabilecek bir formda olabilir veya olmayabilir (manuel test komut dosyası bir test prosedürüdür). Test girdileri ve beklenen sonuç, bir betiğin parçası olarak dahil edilebilir veya betiğin dışında, ayrı bir dosya veya veritabanında olabilir.

Test senaryolarının ön koşulları, testlerin yürütülebilmesi için uygulanmalıdır. Örneğin, bir test bir dosya veya veritabanındaki bazı verileri kullanıyorsa, bu dosya veya veritabanı testin bulmayı beklediği bilgileri içerecek şekilde başlatılmalıdır.

Bir test durumu, ağ bağlantısı veya yazıcı gibi özel donanım veya yazılım gerektirebilir. Bu aynı zamanda test senaryosu çalıştırılmadan önce kurulması gereken ortamın bir parçasını oluşturur.

Beklenen sonuçlar, otomasyon araçlarının kullanması için dosyalar halinde düzenlenebilir. Manuel test için, bunlar sadece manuel test prosedürü veya komut dosyasıyla ilgili notlar olabilir. Otomatik karşılaştırma için beklenen sonuçları ayarlamak, manuel test için beklenen sonuçları ayarlamaktan çok daha karmaşık olabilir. Araçlar, her şeyin ayrıntılı olarak açıklanmasını gerektirir, bu nedenle manuel testten çok daha fazla titizlik gerekir.

Test oluşturma faaliyetinin önceden hazırlanabilen herhangi bir yönü, örneğin V modelinin sol tarafı, daha sonra zaman kazandıracaktır.

The post Test Faaliyetleri first appeared on Akademi Delisi (Tez Yaptırma).