Araç seçimi sırasında dikkate almamız gereken en büyük faktör, test aracının operatörlerinin veya kullanıcılarının kim olacağıydı. Sonunda belirlenen personel, teknik altyapıdan değil, programlama becerisi olmayan iş odaklı kişilerdi.

Bu temel faktörü göz önünde bulundurarak, bizim için doğru test aracını belirlemek oldukça kolay bir işti, çünkü basit kayıt ve oynatma özelliğine sahip, ancak programlama becerilerine sahip biri tarafından işlevlerinde ince ayar yapma fırsatına sahip bir ürün arıyorduk. Eğer gerekliyse. Bu, süreci olgunlaştırırken bize her iki dünyanın da en iyisini verebilmelidir.

Buna göre, 1992’nin başlarında seçildi ve satın alındı. Belirlenen araç kullanıcıları başlangıç eğitim kurslarına gittiler ve ürünü nasıl kullanacaklarını öğrendiler. Bununla birlikte, işe geri döndüğünüzde, senaryoların kaydedilebilmesi için gereken hazırlık süresinin başlangıçta beklenenden çok daha uzun olduğu kısa sürede anlaşıldı. Sonuç olarak, test aracını düzgün bir şekilde kurmak için projenin süresi doldu. Bu nedenle, daha tanıdık olan manuel teste başvurulmuştur ve test aracı hızla raf yazılımı haline gelmiştir.

O zamanlar, çok karmaşık olduğu için tüm suç test aracına atılırken, gerçekte onu düzgün bir şekilde uygulamak için yeterli zaman ayrılmamıştı. Açıkçası bu senaryo, bir aracın uygulanmasının başarısız olmasının en yaygın nedenidir. Muhtemelen daha uzun vadeli bir görüşün daha kaliteli bir test otomasyon çabasıyla sonuçlanacağını takdir etmek yerine kısa vadeli bir ek yük olarak görüldüğü için hazırlık için yeterli zaman ayrılmıyor.

Planlama, Hazırlık ve Nihai Başarı

İlk geliştirme tamamlandıktan ve test edildikten sonra, sonraki sürümler zaten agresif tarihlerle planlanmıştı. Gerçekleştirilmesi gereken regresyon testi miktarının üstesinden gelmek için özel olarak ayrı bir test ekibinin kurulması gerektiği hissedildi.

Bu noktada, regresyon testi tarafı için özel sorumluluk taşıyan bir ekip kurmam istendi. Bu, her zaman kullanıcı kabul testinden daha zahmetli olarak görülen bir görevdi çünkü diğer test biçimlerinden daha tekrarlayıcı ve daha az ilgi çekiciydi.

Test aracıyla yeniden başlatma

Raf donanımı test aracımızın tozunu silkeleyerek başladım ve onu yükseltmeye ve kullanıma sunmaya başladım. Gerekli faaliyetleri kapsayacak bazı üst düzey planlar hazırladım ve üst düzey insanlardan bu faaliyetler için onay aldım. Bazı alanlarda diğerlerinden daha zordu, ancak bunun nedeni kısmen, testin bir faaliyet olarak asla bir projenin tüm yaşam döngüsü boyunca değil, genellikle test başlamadan birkaç hafta önce dikkate alınmasıydı. Dolayısıyla, genel test disiplini konusunda farkındalığı artırmak için yönetmem gereken bir eğitim süreci de vardı.

Başlangıçta alet satıcısı tarafından eğitilmiş bir kişi vardı, bu yüzden doğru bir şekilde planlamaya başlayabilirdik. İlk hedefimiz, yayına girmiş olan ilk üründen komut dosyaları yüklemekti. Bu sürüm için manuel test komut dosyaları gözden geçirildi ve test aracına yüklenebilecek anahtar olanlara kadar filtrelendi. Ortalama olarak on manuel komut dosyasını tek bir otomatik komut dosyasına sıkıştırabileceğimizi bulduk. Bu bir bonustu ve beklediğimizden daha az senaryo kaydı yapmamız gerektiği anlamına geliyordu.

Yazılım test otomasyon araçları
Yazılım test araçları
Yazılım test otomasyonu nedir
Yazılım test yönetimi
Katalon Studio
Ranorex Nedir

Planlamanın ve Hazırlığın Önemi

Bu erken noktada, planlama çalışması esastır. Harcanan emek için gösterecek çok bir şey yok ama en önemli adımlardan biri. Düzgün veya temiz bir bitişin gerekli olduğu herhangi bir şey gibidir, hazırlık, nihai sonucu yapabilir veya bozabilir. Buradaki anahtar mesaj, testlerin mantıksal bir sıra ve hiyerarşiyi takip edecek şekilde planlanması ve yapılandırılması için yeterli zamanın verildiğinden emin olmaktır.

Sponsorlar bu noktadan önce bu çabanın gösterilmesi gerektiğini kabul etmeli ve çok çabuk geri ödeme beklememelidirler. Sponsorlardan bu desteği alırken onları ilerlemeden haberdar etmelisiniz: “Acı yoksa kazanç da yok”.

Burada planlamaya odaklandığım için özür dilemiyorum, çünkü bu, harcanan çabayı hafife almanın kolay olduğu bir alandır. Bizim durumumuzda, ham yazılım ve araçla başlayıp ilk ürünümüz üzerinde tam bir regresyon testi çalıştırabilmemiz dokuz ayımızı aldı.

Geriye dönüp bakıldığında ve hatalardan ders çıkarıldığında, bu süre muhtemelen yaklaşık üç aya indirilebilirdi. Ancak, bu zaman çizelgesi büyük ölçüde otomatikleştirilen sistemin karmaşıklığına ve dahil olan personelin becerilerine bağlıdır.

Organizasyon ve motivasyon

Ekip, temel olarak iş akışından ve kullandığımız test aracıyla ilgili ayrıntılı bilgiden sorumlu tek kişi olan tek bir Sistem Uzmanı etrafında organize edildi. Bu kişi şirket içi sorun giderici olarak çalışır ve sorular, yükseltmeler vb. durumlarda satıcılarla tek irtibat noktasıdır.

Bu yapıya sahip olarak, test uzmanları ortaya çıktıkça kendi sorunlarını çözmede bir dereceye kadar kendi kendine yeterli olabilirler. Testerlara ek olarak, donanım, LAN, iletişim vb. konularda ortaya çıkabilecek daha ayrıntılı teknik sorunları ele almak için bir teknik destek ekibim de var.

Gerekli teknik becerilerin (çeşitli olan) öğretilebileceğine inanıyorum. Benim alanımda, test uzmanlarının test ettikleri ürünü, üzerinde çalışacağı işletim sistemlerini, ağ yapılandırmalarını, donanım kurulumunu, iletişimleri ve bazı programlama becerilerini bilmesi gerekir. Farklı kuruluşların farklı ihtiyaçları olacaktır, ancak bunlar bizim için değerli olanlardır.

Bununla birlikte, ekip üyelerinin uyum sağlayabilmeleri için test etme konusunda doğru zihniyete sahip olmaları gerekir. Hevesli, hevesli, test etmeye ilgi duyan, düşünen ve kaliteyi göz önünde bulunduran kişiler olmaları ve aynı zamanda tüm geliştirmeyi geliştirmeye çabalamaları gerekir. 

Motivasyon, birçok yönetim kitabında iyi bir şekilde ele alınmıştır ve ana ilkelerin tümü geçerlidir. Bununla birlikte, test çalışmasının tekrarlayan doğası nedeniyle, test uzmanlarının meslektaşlarının saygısını kazanarak yaptıklarının değerini görmelerini sağlamak önemlidir.

Bu, en iyi şekilde, projelerde test sürecinin önemini artırmak ve başarılarını göstermekle sağlanır. Ayrıca, değer en iyi şekilde, bir test aracı ve özel personel mevcut olmadığında alternatifin ne olacağı görülerek anlaşılır.

The post Yazılım Aracı Seçimi first appeared on Akademi Delisi (Tez Yaptırma).

İlk geliştirmesinden sonra aracın kendisinde bazı teknik gelişmeler oldu. Otomatik test artık kendileriyle iletişim kurmak için mesaj gönderilmesini gerektiren programlarla daha kolay başa çıkabilir. Ağ arızaları gibi beklenmeyen olaylardan kaynaklanan sorunların üstesinden gelmek için bir dizi testin sonunda başarısız olan tüm testleri otomatik olarak yeniden çalıştırabilir.

Çok ilginç bir teknik gelişme, manuel testleri yarı otomatik hale getirmek için özel olarak yazılmış bir gösteri aracıyla (Dramatix olarak adlandırılır) Autotest’in kullanılmasıdır. Otomatik test, test ortamını ayarlamak için kullanılır, yani yazılımın ve veri dosyalarının doğru sürümünün bulunduğundan emin olun, test verilerini başlatın, vb.

Test edilen yazılım daha sonra çağrılır ancak kontrol, manuel test için test komut dosyasını görüntüleyen Dramatix’e verilir. Manuel test cihazı daha sonra, tüm bağlantıları korurken nesnelerin hareket ettirilip ettirilemeyeceğini kontrol etmek gibi (doğrulamanın görsel doğası nedeniyle otomatikleştirilmesi pratik olmayan) işlemleri gerçekleştirir. Test cihazı daha sonra Başarılı veya Başarısız durumunu kaydeder. Testin sonunda, Otomatik test tüm temizleme işlemlerini gerçekleştirir ve standart şekilde işlemek için Başarılı/Başarısız bilgilerini toplar.

Teknik Problemler

Ayrıca yıllar içinde, örneğin serbest bırakma prosedürlerine entegrasyonu daha verimli hale getirmek gibi bazı küçük geliştirmeler de yapılmıştır. Artık konfigürasyon yönetim sistemine tek bir komut kaynak kodunu kopyalayacak, yapıyı gerçekleştirecek ve otomatikleştirilmiş testleri çalıştıracaktır.

Hâlâ karşılaşılmakta olan birkaç teknik sorun var. Birincisi, beklenen sonuçların yaklaşık %1’inin aslında yanlış olmasıdır. Bunlar zamanla keşfedilir ve bulunduklarında düzeltilir, ancak muhtemelen Test Paketlerinde bazı yanlış beklenen sonuçlar vardır.

Zaman zaman meydana gelen bir domino etkisi de vardır. 10 test vakası başarısız olursa ve bir düzeltmenin bunu düzeltmesi gerekiyorsa, yeni yazılım gerçekte 90 testte başarısız olabilir. Bu cesaret kırıcı olabilir.

Bazı manuel testler hala gereklidir. Örneğin, işlev tuşu düzenleri farklı platformlar için farklıdır. Bu, en az bir kez manuel olarak test edilmeleri gerektiği anlamına gelir. Manuel testten x olayları saklanırsa, işlev tuşu düzeninin değişiklikten etkilenmemesi koşuluyla, değişiklikler yapıldığında testi tekrarlamak için yeniden oynatılabilirler.

Yazılım test Süreçleri
Yazılım test teknikleri
Yazılım test Çeşitleri
Manuel test Örnekleri
Otomasyon testi Nedir
Yazılım test araçları
Kara Kutu test Teknikleri
Manuel test ve otomasyon test

Değişiklikler ve Avantajlar

En çarpıcı fayda, bu kadar geniş bir test setini bu kadar sık çalıştırabilmenin garanti ettiği ürünlerin kalite düzeyidir. Tüm düzeltmeler, yamalar ve değişiklikler, yalnızca bir kez değil, her aşamada tamamen gerileme testine de tabi tutulur.

Testlerin tümü ‘son’ düzeltmeden sonra yeniden çalıştırılabilir, böylece müşterilere gönderilen yazılımın çok yüksek kalitede olduğunun bilinmesi de sağlanır. Otomatik testler gerçekten de kalite sisteminin merkezinde de yer alır.

Yönetim açısından en büyük etki, herhangi bir iş için tahmin edilen sürenin artık her zaman tam bir regresyon testi çalıştırma süresini içermesidir. Önceden, geliştirme tahminleri, yeterli test için harcanan zamanı dahil etmeyi hatırlama eğiliminde olmayan (iyimser?) geliştiriciler tarafından da veriliyordu.

Örneğin, yeni bir özelliği test etmek için süreyi dahil etmiş olabilirler, ancak regresyon testlerini veya mevcut testlerin bakımını dahil etmemiş olabilirler. Bu, geliştirmenin sonunda “yakalanmaya” yol açtı ve zamanın uzatılması gerekti. Örneğin, bir geliştirme projesi için on hafta tahmin ediliyorsa, hiç kimse testin ne kadar süreceğini ve hatta kaç test yapılması gerektiğini doğru bir şekilde de tahmin edemez.

Bu nedenle, geliştirme çalışması olması gerektiği kadar öngörülebilir değildi. Kültürdeki en büyük tek değişiklik, bitiş tarihlerinin artık çok iyi bir doğrulukla tahmin edilebilmesidir. Bu, planlamanın güvenle yapılabileceği ve tüm sürecin çok daha iyi yönetilebileceği anlamına da gelir.

Elbette süreç mükemmel değil, bu nedenle ara sıra küçük bir kayma oluyor, ancak genel olarak işler çok daha öngörülebilir. Bunun bir örneği, bir müteahhit sözleşmesini yakın zamanda bitirdiğinde işi yeniden tahsis edebildi ve etkinin beş ay sonra ne olacağını bildi. Önceden, birkaç hafta ileride bir etki görmek oldukça iyi kabul ediliyordu. Otomatikleştirilmiş test sistemi olmadan, bu doğrulukla ve şimdiye kadarki geleceği tahmin etmek de oldukça zor olurdu.

Otomatikleştirilmiş test rejiminin bir diğer önemli avantajı, Windows NT’ye geçmemizdi. Bu, şimdiye kadar desteklenen UNIX platformlarından tamamen farklı bir mimariye sahiptir. Otomatik test çok yardımcı oldu; aslında, onsuz NT’ye bağlantı kurmak muhtemelen mümkün olmazdı. Ürün hattının %95’ini NT’ye taşıdık ve mümkün olan yerlerde de mevcut testler yapıldı.

Taşıma işi, QA görmeden önce geliştirme aşamasında yapılır. Platformun son KG’si yapıldığında, otomatik testten geçen programlarda çok az kusur bulundu. Bulunan kusurlar temel olarak NT’nin benzersiz özelliklerinde, örneğin işlemciler arasındaki boru iletişimindeydi.

Müşteriler için pek çok küçük değişiklik olduğunda başka bir fayda ortaya çıkar. Çok sayıda şeyle uğraşırken küçük değişiklikleri gözden kaçırmak çok kolaydır. Otomatik test, hepsini hatırlayıp hatırlamadığınızı öğrenmenin de harika bir yoludur.

Karmaşık karşılaştırmalarda filtrelerden yararlandık. Örneğin, bir resim yeniden çizildiğinde, elemanların çizim sırasına bakılmaksızın kullanıcıya aynı görünmelidir. Araç, çizim talimatlarının sıralamasında farklılıklar bulabilir, ancak karşılaştırma yapmadan önce sırayı sıralayabiliriz. Bu özellik aslında yakın zamanda ortaya çıkan bir yenilik değil, zamanla geliştirildi. Ayrıca, 64 bitlik bir platforma (Alfa) geçerken bir miktar yuvarlama hatası toleransı oluşturmayı da faydalı bulduk.

Ne kadar küçük olursa olsun, herhangi bir yama için tüm testleri yeniden yapmak politikamızdır. Bu çok faydalı oldu. Geçen yıl, bir düzeltmeyle getirilen bir dizi kusur bulundu. Bu, müşteri açısından en kötü şeydir; bir kusuru yalnızca bir başkasıyla değiştirmek için de rapor ederler.

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

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.

The post Karşılaştırma Araçları  first appeared on Akademi Delisi (Tez Yaptırma).

Otomatik bir test, belirli bir beklenen sonucu yazılımın ürettiği gerçek sonuçla karşılaştırabilir, ancak aracın kendisi size yazılımın geçip geçmediğini söyleyemez, yalnızca eşleşip eşleşmediğini söyleyebilir. Bu, test otomasyonu için hatırlanması gereken önemli bir ayrımdır.

Örneğin, beklediğiniz sonuç yanlışsa, bir manuel testçi bunu fark edebilir ve gerçek sonuç hatalı beklenen sonuçla eşleşmediğinde bile yazılımın doğru olduğunu beyan edebilir.

Bir alet bunu asla yapmaz. Çoğu kişi, belirli bir testle ilgili olarak yazılımın yalnızca iki durumunun Geçti ve Kaldı olduğunu varsayar. Ancak test otomasyonu ile birlikte bazı ek durumlara ihtiyaç duyulmaktadır.

Bilinen Düzeltilmemiş Kusurlar

Bir dizi testin başarısız olduğunu, ancak hepsinin başarısız olmasına neden olan kusurun ciddi olmadığını ve henüz düzeltmenin aciliyeti olmadığını varsayalım. Artık yazılımda düzeltilmemiş bilinen bir kusurumuz var. Örneğin, Karalama’daki kelime sayısının 1 olduğunu varsayalım, bu nedenle 143 kelime varsa, sadece 142 sayılır. Bu bir kusur, kelime sayısının farklı paragraflar için kontrol edilen şeylerden biri olduğu yarım düzine testte başarısız olabilir. 

Bu yazılım üzerinde bir sonraki otomatik testleri çalıştırdığımızda, kusur düzeltilmemişse, tekrar hatalar alacağız. Büyük olasılıkla aynı başarısızlıklardır, ancak hepsini analiz edene kadar bunu bilemeyeceğiz. Daha önce gördüğümüz gibi, başarısızlık analiz süresi önemli olabilir. Yine de bu bilinen kusurdan kaynaklanan arızaların hiçbiriyle ilgilenmiyoruz.

Yalnızca birkaç testiniz varsa bu ciddi bir sorun değildir. Ancak yüzlerce veya binlerce testiniz varsa, o zaman ilginizi çekmediğini gördüğünüz başarısızlıkları analiz etmek için zaman harcamak zorunda kalmak sadece boşa değil, aynı zamanda çok sinir bozucudur.

Yukarıda gösterilen arızaların analizi zaman alacaktır. Ama daha önce tamamen aynı şekilde başarısız oldu ve şimdi bununla ilgilenmiyoruz.

Muhtemel Çözümler

Daha önce başarısız olan testlerin tüm başarısızlıkları yoksayılsın mı?

Tüm bu başarısızlıkları basitçe görmezden gelebiliriz. Daha önce başarısız olan bir test çalıştırıldığında, bu test için başarısızlık analizinde herhangi bir zaman harcamayız.

Ama neden test çalıştırıldı? Çalıştırmak ve sonuçları yok saymak, bu testi geçerli setten çıkarmaktan daha kolay olabilir – o zaman sonuçları yok saymak iyi bir çözümdür.

Bilinen kusurumuz henüz giderilmemiş olsa da yazılım başka bir şekilde değiştirildiği için testi yeniden çalıştırmış olabiliriz. Şimdi sonuçlara bakmak istiyoruz. Ancak belki de tek bir ilginç sonuç bulmak için gözden geçirmemiz gereken 100 sahte sonucumuz olduğu gerçeği, zamanımızı iyi kullanmak değildir ve o kadar sıkılabiliriz ki aradığımız ilginç sonucu kaçırabiliriz.

Başka bir alternatif, başarısız sonuçları yeni beklenen sonuçlar olarak adlandırmaktır. Bu, bir dahaki sefere onları başarısızlık olarak ortadan kaldırma avantajına sahip olacaktır. Şimdi testleri çalıştırdığımızda sadece iki veya üç başarısızlık elde edebiliyoruz ve bunlar bizi ilgilendiren şeyler.

Burada önemli bir tehlike var. Beklenen sonuçları kasıtlı olarak yanlış olacak şekilde değiştirdiğimizi hatırladığımız sürece, küçük kusur düzeltildikten sonra geri dönüp beklenen gerçek sonuçları eski haline getirebiliriz. Ancak, insan doğası gereği, bu unutulabilir.

Bu test durumuna ‘beklenen başarısızlık’ diyoruz. Bir test hatası olarak etiketlenmiş olması, onu değiştirdiğimizi unutamayacağımız anlamına gelir. Beklenen bir sonuç olması, ilgilenmediğimiz başarısızlıkları analiz ederek zaman kaybetmekten kendimizi kurtarabileceğimiz anlamına gelir. Test çalıştırıldığında, beklenen gerçek sonuç yerine beklenen başarısızlık sonucuyla karşılaştırırız.

Yazılım test otomasyon araçları
Yazılım test araçları
Manuel test araçları
Hermenik test modeli
Fonksiyonel test Araçları
Test yönetim Araçları
Hp LoadRunner nedir
Appium

Bu testi manuel olarak analiz etmek özellikle zorsa, beklenen gerçek sonucu bir yere kaydederek saklayabiliriz. Aksi takdirde, beklenen sonucu, beklenen başarısızlık sonucuyla değiştireceğiz. Gösterilen Çalıştırma 4’te kusur henüz giderilmemiştir. Bu testi yeniden çalıştırmak istiyoruz, çünkü muhtemelen bu testi çalıştırılacak bir pakette tutmak, bu testi özel olarak hariç tutmaktan daha kolaydır. Geçen seferki başarısızlıklarla ilgilenmiyoruz.

Bu nedenle, gerçek sonucu beklenen başarısızlık sonucuyla karşılaştırırız. Fark olmadığı için analiz için zaman harcamamıza gerek yok. Test durumu Geçti değil, Beklenen Başarısız olduğundan, bu testin henüz geçilmediğini hala biliyoruz. Bu, sorunu çok düzgün bir şekilde çözdü.

Orijinal kusurun giderildiğini varsayalım. Bir yere kaydetmiş olsaydık, testi yeniden çalıştırmadan önce orijinal gerçek beklenen sonucu geri yükleyebilirdik. Bu, Pass durumuyla sonuçlanacaktır. Ancak, beklenen gerçek sonucu henüz geri yüklemezsek, ancak testi beklenen başarısızlık sonucuyla düzeltilmiş yazılım üzerinde çalıştırırsak ne olur?

Artık yazılımda herhangi bir kusur yok, dolayısıyla gerçek sonuç doğru. Ancak, gerçek sonucu beklenen başarısızlık sonucuyla karşılaştırıyoruz. Bu, aracın farklılıkları bulacağı ve bunların analiz edilmesi gerekeceği anlamına gelir.

Bu noktada tam olarak istediğimiz şey budur. Artık bir değişikliği araştırmamız gerektiğini biliyoruz, dolayısıyla bu bizi beklenen başarısızlık sonucunu gerçek beklenen sonuçla değiştirmeye sevk edecek, bu yüzden unutmadık. Bu test için durum ne olmalıdır?

Gerçek sonucun, beklenen başarısız sonuçtan ziyade gerçek beklenen sonuçla karşılaştırmasını gerçekleştirmeden testin geçtiğini söyleyemeyiz. Bunun beklenen bir başarısızlık olmadığını biliyoruz çünkü farklılıklar var ve beklenen bir başarısızlığın beklenen başarısızlık sonucunda hiçbir farkı yok.

Buna Başarısız diyebilirdik, ancak bu yanıltıcı olabilir çünkü yazılım artık doğru olabilir ve buna başarısızlık demek haksızlık gibi görünebilir! Bu nedenle dördüncü bir test durumu sunuyoruz: Bilinmiyor. Test durumu bilinmiyorsa, farklılıkları analiz etmemiz gerekir, ancak bu analizden sonra bir Geçti veya Kaldı durumu atayabiliriz.

Yazılım değişti ancak orijinal kusur henüz düzeltilmedi. Yazılım, orijinal kusurumuz henüz giderilmeden başka bir şekilde değiştirilmişse ne olur? Bunun, testte ek bir yeni hatalı sonuçla sonuçlandığını varsayalım. Bu, Çalıştırma 6’da yazılımdaki ikinci bir kusurla (*) gösterilir. Test sonucunu beklenen başarısız sonuçla karşılaştırırsak bir farkımız olur ama bu sadece ilgilendiğimiz bir sonuç olur.

Zamandan tasarruf etmek için sadece bir farkı analiz etmemiz gerekiyor. (Bu, kusurların birbiriyle etkileşime girmediğini varsayar; eğer etkileşime girerlerse, arızaları analiz etmek için zaman harcamanız gerekecektir.) Bu durum Başarılı veya Beklenen Başarısız değildir. Başarısız olabilir (bu örnekte olduğu gibi), ancak bunu henüz bilmiyoruz, dolayısıyla bu test durumu da bilinmiyor.

The post Otomatik Test Araçları first appeared on Akademi Delisi (Tez Yaptırma).

Çalıştırmak istediğimiz tüm test senaryolarını içeren bir Test Paketine sahip olmak iyi ve güzel, ancak test aracının hangi test senaryolarının var olduğunu, nerede olduklarını ve nasıl çalıştırılacağını anlamasını sağlamalıyız.

Bunun elde edilme şekli, kullanılacak test aracına bağlı olarak büyük ölçüde değişecektir. Örneğin, bazı araçlar, tüm komut dosyalarının (veya daha doğrusu, komut dosyalarının derlenmiş sürümlerinin) tek bir dizinde olmasını veya özel bir dizinlenmiş dosya türüne eklenmesini gerektirir. Diğer araçlar, farklı dizinlere dağıtılan betiklerle çalışabilir.

Diğer bir önemli arayüz sorunu, bir test senaryosunun gerçek tanımıdır. Bazı araçlar test senaryolarını betiklerle doğrudan ilişkilendirerek tanımlarken, diğerleri test senaryolarını betiklerden bağımsız olarak belirlemenizi gerektirir. Her iki durumda da, önceki bölümde tartışıldığı gibi, her test durumuyla ilgili bazı bilgileri bir metin dosyasında tutmayı yararlı bulduk.

Bu yalnızca test adı (veya numarası), amacı ve onu uygulayan komut dosyaları ve veri dosyalarının bir listesi olabilir. Bu, bir test durumu hakkında herhangi bir bilginin bulunabileceği tek bir nokta sağlar. Ayrıca bazı test araçlarının gerektirdiği bilgileri de sağlar. Bizim görüşümüze göre, bu bilgi en iyi test yazılımı mimarisinde (yani Test Setlerinde) araçtan bağımsız bir biçimde ve dolayısıyla yapılandırma yönetimi altında bir metin dosyasında tutulur.

O zaman soru, bu bilgilerin test aracına nasıl kopyalanacağıdır. Bu, aracı belirli bir formatta metin dosyasıyla birlikte sunmanın basit bir durumu olabilir veya aracın kendisini kullanarak veri girişi sürecini otomatikleştirmeyi içerebilir. Hangi yaklaşımı benimsemeniz gerekiyorsa, onu otomatikleştirmelisiniz.

Test Paketi ile test aracı arasındaki arabirimle ilişkili tüm görevler (komut dosyalarının kopyalanması ve test tanımlarının test aracına yüklenmesi gibi), Test Paketi veya Test Seti ön işleme görevleri olarak gerçekleştirilebilir.

Bu noktada anlattığımız yazılım mimarisi, ilk başta bir somunu kırmak için balyoz almak gibi görünebilir. Dürüst olmak gerekirse, çok fazla test dosyanız yoksa, bu yaklaşım size zaman kazandıracağından daha fazla çaba gerektirecektir.

Ancak, test otomasyon çabalarınız başarılı olursa büyüyecek ve kontrol etmeniz gereken dosya sayısı da çok hızlı artacaktır. Gösterdiğimiz örnekler zorunlu olarak küçük ölçeklidir. Uygulamada, çoğu Test Setinde onlarca (hatta birkaç yüz) test durumu olmasını bekleriz. Ayrıca Scribble uygulamasının her bir özelliği için çok daha fazla test durumu görmeyi bekleriz.

Test senaryolarını bir ortamdan diğerine kopyalamak veya güncellemeler üzerinde çalışmak için olsun, bir test yazılımı alt kümesini kolayca izole edebilmenin faydaları hafife alınmamalıdır. Test yazılımının işlenme biçimlerindeki esneklik, test otomasyonunda uzun vadeli başarının anahtarıdır.

Test otomasyonu girişiminin başlangıcında uygun bir mimariyi devreye sokmazsanız, baştaki herhangi bir organizasyonu geri almak, özellikle de zaten hantal hale geldiyse, çok daha fazla çaba gerektirecektir. Bu mimari ile başlar ve baştan test otomasyon standartlarınızın bir parçası haline getirirseniz, ‘otomasyon yapmanın yolu’ olarak kabul edilecektir.

Test yazılımı mimarisi, test ve test otomasyonu için gerekli olan yapıların düzenlenmesidir. Kendi test yazılımı mimarinizin uygulanması, otomasyonunuzun nihai ölçeğine bağlı olacaktır. Betikler ve veriler gibi test yazılımlarını nasıl yeniden kullandığınızı, birden çok sürümü nasıl takip ettiğinizi ve farklı platformlarda ve ortamlarda nasıl test ettiğinizi etkileyecektir.

Yazılım test araçları
Yazılım test otomasyon araçları
Test Otomasyon araçları
İnterface testing
Selenium Test Otomasyon
Test otomasyon Nedir
Selenium Nedir
Test Otomasyon örnekleri

Tutarlı bir yaklaşım, daha fazla yeniden kullanım ve daha fazla esneklik anlamına gelir ve çok sayıda farklı ve uyumsuz planın ortaya çıkmasına izin vermek yerine en baştan geliştirilmelidir.

Şemamız, test durumlarını Test Setleri dediğimiz yapılar halinde gruplandırır. Bunlar, test durumlarını çalıştırmak için gereken tüm yapıtları (veriler, betikler ve beklenen sonuç gibi) içerir.

Test Paketi, hata düzeltme testi veya regresyon testi gibi bazı hedefleri karşılamak için gereken tüm test durumlarını içeren bir Test Setleri koleksiyonudur.

Farklı Test Setleri halinde gruplanan test senaryoları arasında paylaşılan herhangi bir test verisi veya komut dosyası, sırasıyla Veri Kümeleri ve Komut Dosyası Setleri olarak adlandırdığımız ayrı yapılarda depolanır. Benzer şekilde, herhangi bir paylaşılan yardımcı program (sürücüler, saplamalar ve özel karşılaştırıcılar gibi) Yardımcı Program Kümelerinde tutulur. Tüm bu farklı set türlerinin (toplu olarak Testware Setleri olarak bilinirler) ana sürümleri, bir Testware Kitaplığı’nda tutulur.

Test yazılımı yapıtlarına kolayca erişilebilmesini ve tüm değişikliklerin kontrol edilebilmesini sağlamak için Test Yazılımı Kitaplığı, yapılandırma yönetimi altında olmalıdır.

Test Sonuçları, Test Suite’in yapısına paralel olarak ayrı bir yapıda düzenlenir. Test Sonuçları, her test çalıştırıldığında oluşturulur. Yürütmenin ürünü gerçek sonuçtur; yürütmenin yan ürünleri test günlüklerini, fark raporlarını, test durum raporlarını vb. içerir.

Test yazılımı mimarisini bir dizin yapısında uyguluyoruz. Her Test Yazılımı Setinin kendi dizini (klasörü) vardır ve bu, Test Yazılımı Setinde bulunan her test yazılımı yapısı türü için bir alt dizin içerir.

Test Suite Dizini, Test Suite’in amacını yansıtır ve tüm ilgili Testware Setlerini alt dizinler olarak içerir. Test Sonuçları paralel dizinlerde tutulur. Mantıklı bir adlandırma kuralı önemlidir.

Testlerin fiziksel uygulamalarına göre izlenebilirliğine yardımcı olmak için, test durumlarının ayrıntılarının yardımcı programlar tarafından aranabilmesi için metin dosyalarında açıklanmasını öneririz. Son olarak, test senaryolarının test yürütme aracı tarafından çalıştırılması gerekir; test yazılımının yeniden yapılandırılması (komut dosyalarını aracın kendi komut dosyası kitaplığına kopyalamak gibi) da otomatikleştirilmelidir.

Bu bölümde açıklanan yaklaşım, kapsamlı test otomasyonuna sahip birçok kuruluşta iyi çalıştı. Şu anda ‘aşırı’ gibi görünse de, başlangıçta bu sorunları çözmezseniz daha sonra ciddi sorunlarla karşılaşacaksınız.

The post Test Araçlarıyla Arayüz first appeared on Akademi Delisi (Tez Yaptırma).

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