Karşılaştırma Araçları 

info@akademidelisi.com * 0 (312) 276 75 93 * Her bölümden, Ödev Yazdırma, Proje Yaptırma, Tez Yazdırma, Rapor Yazdırma, Makale Yazdırma, Araştırma Yazdırma, Tez Önerisi Yazdırma talepleriniz için iletişim adreslerini kullanın. Makale YAZDIRMA siteleri, Parayla makale YAZDIRMA, Seo makale fiyatları, Sayfa başı yazı yazma ücreti, İngilizce makale yazdırma, Akademik makale YAZDIRMA, Makale Fiyatları 2022, Makale yazma, Blog Yazdırma, Blog Yazdırmak İstiyorum

Karşılaştırma Araçları 

3 Temmuz 2023 Yazılım test araçları Yazılım test otomasyon araçlar 0
Sürüm Örneği Sunmak

Karşılaştırma Araçları 

Karşılaştırılacak beklenen sonuç yoksa veya test aracı tarafından bulunamıyorsa, herhangi bir karşılaştırma yapmak mümkün değildir. Bir şeyle karşılaştıramıyorsanız, herhangi bir fark olup olmadığını söyleyemezsiniz ve bu nedenle testin başarılı olup olmadığını, başarısız olup olmadığını veya beklenen bir başarısızlık olup olmadığını söyleyemezsiniz. Bu durumdaki test durumu da bilinmiyordur.

Orijinal kusur düzeltildikten ve yazılım artık doğru olduktan sonra, beklenen başarısız sürüm yerine beklenen sonucun doğru bir sürümünü geri yükleyerek test durumunu Geçti olarak geri yüklememiz gerekir. Beklenen gerçek sonucu geri getirmenin iki yolu vardır. İlki, orijinal beklenen sonucu geri yüklemektir. Şimdi testi çalıştırdığımızda herhangi bir fark yok yani testi geçtik.

Beklenen gerçek sonucun geri yüklenmesini otomatik hale getirebilirsiniz. Beklenen başarısız bir sonuçla karşılaştırma yaptığınızda ve farklılıklar olduğunda, gerçek beklenen sonucu kullanarak karşılaştırmayı yeniden çalıştırın. Şu anda herhangi bir fark yoksa, yazılımın artık doğru olduğunu otomatik olarak onaylayarak ve teste Geçti durumu atayarak kendinize daha fazla zaman kazandırmış olursunuz.

Diğer yol, eğer gerçek beklenen sonuç kaydedilmediyse, gerçek sonucu analiz etmek ve şimdi doğru olup olmadığını kontrol etmektir.

Testin asıl sonucu artık doğruysa, sonucun bu sürümü, bu testin bir sonraki çalıştırılışında beklenen sonuç olması için artık ‘terfi ettirilecektir’. Gerçek sonucun son derece dikkatli bir şekilde kontrol edilmesi çok önemlidir, çünkü bu testin gelecekteki tüm uygulamaları şimdi onunla karşılaştırılacak ve doğruluğuna bağlı olacaktır. Bu adım aceleye getirilirse ve yanlış beklenen sonuçlarla karşılaştırma yapmak zorunda kalırsanız, çok fazla zaman kaybedebilirsiniz.

Ayrıntılı Arıza Durumu

Yukarıda özetlenen dört durum değeri, analiz süresinden tasarruf ederek test otomasyonunu daha verimli hale getirmeye yardımcı olacaktır. Bu bilgilere test aracı veya rejiminiz tarafından kolayca erişilebilir durumdaysa, en çok ilginizi çeken arızalar hakkında daha ayrıntılı bilgilere sahip olunarak daha fazla zaman kazanılabilecek başka yollar da olabilir. Aşağıda birkaç örnek verilmiştir.

Bir test tamamlanamıyorsa, karşılaştırılacak sonuç yoktur veya eksiktir. Olağan test durumlarından herhangi birini atayamayız. Normalde testlerin neden tamamlanmadığını analiz etmek için zaman harcamamız gerekirdi.

Aşağıdaki durumlardan bazılarını otomatik olarak raporlayabilirsek, ilgili testlerin yeniden yapılması gerektiğini hemen anlayabiliriz:

« Ağın bir testin ortasında çökmesi gibi çevresel arıza;
» test için gerekli dosyaların eksik olması gibi ilk kurulum yanlış; test edilecek yazılım eksik veya yanlış sürüm;
»Karşılaştırılacak beklenen sonuçlar olmadığı için karşılaştırma yapılamaz ve test başlamadan önce silinmesi gereken yabancı dosyalar varsa;
» bir şey zaman aşımına uğrar, örneğin bir yazıcı açık değilse ve test bir şey yazdırmaya çalışıyorsa;

Bunlardan herhangi biri (veya çevrenizde sorunlara neden olan diğerleri) rejiminiz tarafından tespit edilebilirse, size çok zaman kazandırabilir. Daha ayrıntılı bir test başarısızlık durumunun yararı, test ortamının kalitesini daha doğru bir şekilde yansıtmasıdır. Aksi halde yazılımın kalitesine kötü yansıyor gibi görünüyor ki bu haksızlık olabilir.


Yazılım test otomasyon araçları
Yazılım test araçları
Test otomasyon araçları
Appium
Yazılım testi
Yazılım test yönetimi
Selenium
Selenium Test Otomasyon


Test Edilebilirlik İçin Yazılım Tasarlama

Test etmek için gereken çaba önemli olabilir. Ancak test edilmesi kolay olacak şekilde tasarlanmamış yazılımları test etmek, olması gerekenden çok daha zordur. Örneğin, sistem, tüm Veri Kümesini bir veritabanına veya başka bir sisteme göndermeden önce, kullanıcı girişlerini doğrulayarak ve değerleri çapraz kontrol ederek karmaşık bir veri kümesi oluşturursa, bu Veri Kümesini kontrol edebilmek yararlı olabilir.

Bunun nedeni, gönderildikten sonra tüm verileri veritabanının çeşitli bölümlerinden alarak kontrol etmenin çok daha zor olabilmesidir. Bu ara sonuçlara erişim, hem manuel testlerde hem de otomatik testlerde çok yararlı olabilir. Hatalar bulunursa, hatanın veriler gönderilmeden önce mi yoksa sonra mı ortaya çıktığını biliyorsanız, örneğimiz için analiz süresi önemli ölçüde kısalır.

Ara sonuçlara erişim, genellikle yazılıma ‘test kancaları’ eklemek olarak adlandırılır. Bu tür test kancalarının sayısı ve ayrıntı düzeyi, yazılımın ne kadar test edilebilir olduğunu belirler. Herhangi bir test kancası tarafından sağlanan bilgi miktarını belirtebilmek de yararlıdır. Bazı testler için yalnızca minimum düzeyde bilgi gerekebilir; Eğer büyük miktarda bilgi mevcutsa tek seçenek bu durumda test verimsiz olacaktır.

Test edilen uygulama, otomatikleştirilmiş testi kolaylaştırmak için de geliştirilebilir. Örneğin, uygulama, girdilerin ekran yerine bir dosyadan alındığı bir “test modu” içeriyorsa, uygulama kendi test dosyasında ayarlanan testlerden kendini test edebilir.

Test edilebilirliği geliştirmenin en iyi yolu, uygulama tasarlanırken ve yazılırken nasıl test edileceğini düşünmektir. Neyin test edilmesi gerektiğini ve nasıl test edilebileceğini düşünmek, daha kaliteli tasarım ve yazılımla sonuçlanacak ve geliştiricilere yazılımda hata ayıklamaya geldiklerinde yardımcı olacaktır.

Senkronizasyon

Otomatik testlerin test edilen yazılımla senkronizasyonu, herkes için bir sorun olmasa da, test otomasyonu için büyük bir sorun olabilir.

Sorun şu ki, bir test yürütme aracı, test edilen yazılıma girdileri, bir insan kullanıcının testleri çalıştırabileceğinden çok daha hızlı bir şekilde ateşleyebilir. İnsan test cihazı bir kullanıcı arayüzü ile etkileşime girdiğinde, test cihazı yazılıma ayak uydurur. Örneğin, test cihazı bir dosyanın açılmasını isteyebilir. Pencere ekranda görünene kadar o dosyanın verilerini yazmaya çalışmaz.

Ancak test otomatikleştirildiğinde, araç kendisine açıkça söylenmediği sürece bir şeyin gerçekleşmesini beklemesi gerektiğini fark etmez (ekranda pencere açılır ve odaklanır).

Araç, belirli sistem olaylarıyla eşitlenebilir veya olmayabilir. Olayı tanımlayamazsa, belirli bir süre beklemesi söylenebilir, ancak bu bazı durumlarda yeterli olmayabilir ve testin adımdan çıkmasına neden olabilir.

Garip dosya adlarına sahip olmanın veya bir test tarafından oluşturulan bir dosyayı bulamamanın senkronizasyon sorunlarından kaynaklanması şaşırtıcı olabilir. Ancak, test Farklı Kaydet menü seçeneğini isterse ve bununla senkronize olmazsa, dosya adı olarak gönderilen ilk üç karakter kaybolabilir. Bu, garip bir dosya adı verecektir ve bir sonraki test, bu test tarafından oluşturulmuş olması gereken dosyayı bulamayacaktır.

Tüm bir karakter dizisi kaçırılırsa, uygulama sonunda karakter beklediği duruma gelir ve bir miktar karakter gelene kadar orada kalır. Sonraki test girişleri bir seçenek seçimiyse, uygulama metin bekliyorsa bunlar geçersiz olabilir, bu nedenle bunlar da göz ardı edilir. Otomatikleştirilmiş test, çok geçmeden yapması gereken şeyle tamamen ilgisiz hale gelebilir.

yazar avatarı
akademi22 akademi22

 

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir