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

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

Test Yazılımı Setlerini Test Yazılımı Kitaplığından kopyalama görevinin olabildiğince basit olması önemlidir. Bununla mümkün olduğu kadar hızlı ve mümkün olduğunca kusursuz demek istiyoruz. Görev uzun sürerse, insanlar onu üstlenmek konusunda isteksiz olabilir veya bunu yapmak için yeterli zamanı olmayabilir.

Herhangi bir özel mimariyi veya teslwarc’ı değerlendirirken, birisinin aceleyle ne yapması gerekeceğini düşünmeyi severiz. Ciddi bir kusurun rapor edildiğini ve düzeltildiğini ve düzeltilen yazılımın aynı gece gönderilmesi gerektiğini düşünüyoruz.

Otomatik testler olduğu için çoğu kişi testlerin ‘bir düğmeye dokunarak’ çalıştırılmasını bekleyecektir. Ancak, ihtiyacınız olan testlerden bazıları yazılımın yeni bir sürümünü test etmek için güncellendi, bu nedenle orijinal sürümlerin birkaç saat içinde alınması ve çalıştırılması gerekiyor. Testware Library’den gerekli testlerin bulunması ve kopyalanması birkaç saat sürecekse bir sorun var demektir.

Test Yazılımı Setlerini Test Yazılımı Kitaplığından kopyalama mekanizması, tamamlanmamış bir Test Yazılımı Setleri setinin aktarılmasını imkansız hale getirmelidir. Olmazsa, olacağını ve muhtemelen böyle bir hatayı en azından göze alabileceğiniz bir zamanda olacağını garanti edebilirsiniz.

Örneğin, gösterilen Test Suite hata düzeltmesini oluştururken, t_Scribble Breadth ve t_ScribbleList adlı iki Test Setini s_Scribble Document Komut Dosyası Kümesi ve d_ScribbleTypical Veri Kümesi olmadan kopyalamak mümkün olmamalıdır. Bu yapılırsa, testlerin tümü olmasa da çoğu başarısız olur.

Bu kadar küçük bir test koleksiyonu için bunun sonuçları çok kötü olmayabilir. Ancak, bir gecede çalıştırılması gereken çok sayıda test söz konusu olduğunda, yalnızca bir veri dosyasının atlanması, testlerin çoğunun başarısız olmasına ve yazılımın büyük ölçüde denenmemiş kalmasına neden olabilir.

Test yazılımı mimarisi bu akılda tutularak tasarlanmışsa, istenen testler için tüm test yazılımının kopyalandığından emin olmak için birkaç basit araç kullanılabilir. Örneğin, bir test paketinin çalıştırılması için gereken tüm Test Yazılımı Setleri bir metin dosyasında listelenmişse, bu, onları otomatik olarak uygun Test Paketine kopyalamak için kullanılabilecek bir kontrol listesi oluşturabilir.

Bu liste otomatik olarak oluşturulabildiğinden, örneğin gerekli olan diğer komut dizilerini ve veri dosyalarını belirlemek için her bir komut dizisini arayarak ve bunları kontrol listesine ekleyerek, tüm kontrol ve kopyalama işlemi otomatikleştirilebilir.

Yazılım Test programları
Yazılım test Metodolojileri
Yazılım test Süreçleri
Software testing
Yazılım testi Neden gereklidir
Yazılım test türleri
Yazılım Testi Nedir
Yazılım test otomasyon araçları

Konfigürasyon Yönetimi

Test yazılımının yapılandırmasını yönetmenin iki alternatif yolu vardır. Tercih ettiğimiz yöntem, Test Yazılımı Setlerinin Test Yazılımı Kitaplığı’nda yapılandırma öğeleri olarak (yani, bir sürüm numarasına sahip olarak) saklanmasıdır. Her set türünün içeriğini oluşturan ayrı test yazılımı yapıtlarının kendi sürüm numaraları yoktur. Bunun etkisi, Test Yazılımı Setindeki herhangi bir şey değiştiğinde, Test Yazılımı Setinin değiştirilen yapıtları ve değişmeyen yapıtları içeren yeni bir sürümünün yaratılmasıdır.

Temel, sürüm numarası olan ancak bir dizi yapılandırma öğesi içeren bir şeydir; bir temelin her sürümü, yapılandırma öğelerinin belirli sürümlerinden oluşturulur. Temel noktamız, yapılandırma öğeleri olan Test Yazılımı Setlerinden oluşan bir Test Paketidir.

Test yazılımı konfigürasyonunu yönetmenin alternatif bir yolu, bireysel test yazılımı yapıtlarının kendi sürüm numaralarına sahip olmaları olabilir. Bu durumda, bir Test Yazılımı Setindeki herhangi bir şey değiştirildiğinde, yalnızca değişen yapıtların yeni sürümleri olur. Diyagramın en alt düzeyi, sürüm numaralarıyla birlikte yapılandırma öğeleri olacaktır.

Test Yazılımı Setleri daha sonra yapılandırma öğeleri yerine temeller haline gelir. Test Paketi bir temel olarak kalır, ancak diğer temelleri içeren bir temeldir (doğrudan yapılandırma öğelerinden ziyade).

Test Yazılımı Seti temel çizgisinin yeni bir sürümü, değişmeyen yapıtları ve değişenlerin yeni sürümlerini içerecektir. Konfigürasyonu yönetmenin bu alternatif yolu, bazı durumlarda (özellikle iyi bir konfigürasyon yönetim sisteminin yürürlükte olduğu yerlerde) daha iyi olabilir.

Test Yazılımı Kitaplığı’nda bir Test Yazılımı Setinin birden fazla sürümü bir arada bulunabilir, ancak bir Test Paketinde bir Test Yazılımı Setinin yalnızca bir sürümü tutulabilir.

Test Yazılımı Güncellemelerini Kontrol Etme

Test yazılımı yapıtlarında yapılan değişiklikleri kontrol etmek açıkça önemli bir konudur. Test yazılımı mimarimizde, test uzmanlarının test yazılımı yapıtlarını güncelleyebilecekleri ve böylece yapılandırma öğelerinin yeni sürümlerini oluşturabilecekleri bir çerçeve oluşturduk.

Ancak iki veya daha fazla kişinin aynı yapılandırma öğesini aynı anda değiştirmeye çalışmasını engellemedik. İyi bir yapılandırma yönetim sistemi yürürlükteyse, bu zaten bir şekilde karşılanacaktır. Değilse, insanlar birkaç basit kurala uyarsa çoğu çatışmadan kaçınmak mümkündür.

Mevcut bir kaynak kodu kontrol sistemi varsa, test yazılımını kontrol etmek için yeterli olabilir. Bu, bilinen bir sistemi kullanma avantajına sahiptir, dolayısıyla öğrenme süresini en aza indirir. Özellikle manuel olarak yapılması hataya açık veya sıkıcıysa, konfigürasyon yönetimi görevlerini otomatikleştirmek için yardımcı programlar geliştirin.

Test Yazılımı Kitaplığına erişim mekanizmalarının, kişilerin herhangi bir Test Yazılımı Setini değiştirmeyi isteyip istemediklerini kaydetmelerine izin vermesini öneriyoruz. Bunların kopyalarını zaten almış başka kişiler varsa, bilgilendirilebilirler (belki otomatik olarak e-posta ile). Tersine, birisi zaten bir güncelleme için işaretlenmiş bir Test Yazılımı Setini güncelleme niyetini kaydetmeye çalıştığında, o anda onu kimin düzenlediği söylenecektir.

Test yazılımına erişimi kolaylaştırmak için sistemi olabildiğince basit tutun ve sistemi kullanılacağı tüm farklı şekillerde test edin. Örneğin, eski bir yazılım sürümü için test durumlarının bir alt kümesini seçin ve bunları iki farklı ortamda çalıştırın. Bu, başarılı bir şekilde, hızlı bir şekilde ve çok az manuel müdahale ile yapılabiliyorsa, o zaman muhtemelen doğru şeyler yapmışsınızdır.

Test Sonuçları

Şimdiye kadar test materyalleriyle, yani test senaryolarını çalıştırmak için ihtiyaç duyduğumuz tüm test yazılımlarıyla ilgilenen bir test yazılımı mimarisini tanımladık. Test yoluyla üretilen eserler hakkında hiçbir şey söylemedik. Bunlara Test Sonuçları diyoruz ve gerçek sonuçları, fark raporlarını ve test aracı günlüğünü içeriyorlar.

Test Sonucu yapıları, diğer test yazılımı yapılarından farklıdır. Test Sonucu yapıları, test durumu yürütmesi tarafından üretilirken, diğer test yazılımı yapıları, test durumları tarafından kullanılır. Test Sonuçları, bir test senaryosu her yürütüldüğünde üretilir. Bir test senaryosu, her seferinde aynı test materyalleri kullanılarak birçok kez yürütülebilir, ancak muhtemelen farklı Test Sonuçları üretecektir.

Test Sonuçları ile test materyalleri arasındaki diğer bir fark, Test Sonuçlarının genellikle ‘bir kez yazılır’ ve ardından ‘salt okunur’ olmasıdır. Testlerimizin doğru kayıtlarına sahip olmak istiyorsak, Test Sonuçlarının düzenlenebilir olması iyi bir fikir olmaz.

Öte yandan, uygulama öncesi test yazılımının (test materyalleri) düzenlenebilir olması ve gerçekten de test yazılımındaki değişikliklerin zaman içinde izlenebilmesi için yapılandırma kontrolü altında olması gerekir. Test Sonuçları bir kez oluşturulduktan sonra asla değiştirilmemelidir.

Bazı Test Sonuçlarını, büyük ihtimalle yazılım yayınlanmadan önce her bir test senaryosunun son çalışmasının sonuçlarını saklamak gerekli olabilir. Bu, belki de en iyi şekilde bir yapılandırma yönetim sisteminin kontrolü altında yapılır, böylece test yazılımı ve yazılımın doğru sürümleriyle ilişkilendirilirler.

The post Test Yazılımı Kitaplığına Erişim first appeared on Akademi Delisi (Tez Yaptırma).

Test yürütmeyi ve karşılaştırmayı otomatik hale getirmek için tüm bu çabayı sarf ettikten sonra, test aracına test durumlarımızı çalıştırmasını söylemeye hazır olmalıyız, böylece ayaklarımızı kaldırabiliriz, değil mi? Ne yazık ki daha yeni başladık. Sonra ne olur?

Testler neden ikinci kez başarısız oluyor (çevresel açmalar) Testimiz ilk çalıştırıldığında girdi olarak country.dcm dosyasını kullandı. Düzenlenen belge dosyası olarak dosyasını oluşturdu. Testi manuel veya otomatik olarak ilk kez çalıştırırken bu sorun değildir. Test betiğimizin son adımları gösteriliyor.

Bu kesin testi ikinci kez çalıştırdığımızda ne olur? Ekran 25 aslında farklı olacaktır, çünkü hemcountry.dcm hem de countrys2.dcm dosya listesinde gösterilecektir. Ancak araç bunu ‘fark etmeyecek’! Bir sonraki giriş, ülkeleri yazmaktır. Görünen bir sonraki ekran artık Ekran 26’da gösterilen değil, testin ilk kez çalıştırılmasında görülmeyen bir iletişim kutusu içeren yeni bir ekrandır.

Bu, manuel olarak ark testi yaptığınızda meydana gelirse, doğal olarak ‘Evet’ yanıtını ek bir adım atarsınız ve ardından Dosya menüsünden Çıkış’ı seçersiniz. Teste fazladan bir adım attığınızın farkında bile olmayabilirsiniz.

Ancak araç, ülkeleri2 gönderdikten sonra tam girişi yeniden oynatmaya geldiğinde, gönderdiği bir sonraki şey Dosya menüsünü seçme girişimidir. Bu, bu ekran için geçerli bir giriş olmadığından, Karalama bip sesi çıkaracak ve aynı ekranı yeniden gösterecektir.

Otomatik test daha sonra Çıkış seçeneğini belirlemeye çalışarak Karalama’nın tekrar bip sesi çıkarmasına ve aynı ekranı yeniden görüntülemesine neden olur. Araç artık bittiğini düşünür ve Karalama’dan çıkar, bu nedenle dizideki bir sonraki test senaryosunu başlatmak için devam edebilir. Otomatikleştirilmiş testin kısa süre sonra yararlı hiçbir şey sağlayamayacağı ve veri dosyalarını silerek veya değiştirerek zarar verebileceği bir duruma nasıl ulaşacağını görebilirsiniz.

Test aracı, gerçekte olanlara karşı esasen kördür. Hakkında bilebileceği tek şey, kendisine söylenenlerdir. Otomatik testin bilmesini istediğiniz herhangi bir şeyi açıkça söylemelisiniz.

Yine, burada özetlenen sorun, bir testin tetiklenebileceği birçok olası yoldan yalnızca biridir. Bütün bu tür şeylerde olduğu gibi sorun aşılmaz değil ama aşmak zaman ve emek istiyor.

Bu sorunu aşmanın bir çok alternatif yolu vardır. İşte üç tane:

• Ek istemi yanıtlamak için komut dosyasını değiştirin. Test senaryosu şimdi ikinci ve sonraki seferleri çalıştıracak, ancak ilk seferinde  herhangi bir nedenle silinmişse başarısız olacaktır.
• Ekstra istem olup olmadığını kontrol etmek ve her oluştuğunda yanıt vermek için komut dosyasını değiştirin. Bu,  olup olmadığına bakılmaksızın çalışacak bir komut dosyasına sahip olmamızı sağlar. Komut dosyamız, şu satırlar boyunca ek bir if ifadesi içerecektir: ‘arsa, “Y”ye basın.’ Bunun komut dosyamızı tekrar daha karmaşık hale getireceğini unutmayın.
• Dosyayı kontrol etmek için komut dosyasını değiştirin ve test senaryosunu çalıştırmadan önce varsa silin. Sorunun oluştuğu noktada bu dosyanın var olup olmadığını komut dosyasına ‘sabit kodlamak’ yerine, başka bir olasılık da sorunu komut dosyasının başında tahmin etmektir. Bu, bakım açısından daha iyi olabilir, çünkü betiğin sonunda gömülü olan bir şey daha kolay gözden kaçabilir.

Bu durumda, test betiğinin başına dosyanın var olup olmadığını kontrol edebilir ve varsa dosyayı silebiliriz, böylece betiğin geri kalanı şimdi doğru şekilde çalışır. Artık gelmeyeceğini bildiğimiz için ekstra ekranı kontrol etmemize gerek yoktur.

Bu örnek, bir testi tetiklemek için meydana gelebilecek birkaç şeyin tipik örneğidir. Bir dizi test durumu için bu tür tüm benzer şeyleri tek bir yerde toplamak daha verimli olabilir, burada tüm ortam faktörleri ya bir test durumu ya da bir dizi test için ele alınabilir.

Bu, test aracı dilinde ayrı bir komut dosyası olarak yapılabilir veya tamamen ayrı bir alıştırma olarak yapılabilir, muhtemelen bir komut dosyasında veya yazılım mühendisleri veya test uzmanlarına en aşina olan herhangi bir dosyada uygulanabilir. Buna ön işleme denir ve tartışılır. Hangi çözüm en iyisidir? Bu, cevapların olmadığı, ancak yapılacak seçimlerin olduğu başka bir alandır.

Yazılım test otomasyon araçları
Test otomasyon araçları
Yazılım test otomasyonu nedir
Test otomasyon Eğitimi
Test otomasyon Nedir
Test otomasyonu
Test Otomasyon Maaşları
Test otomasyon Çeşitleri

Seçilen çözüm, aşağıdakiler de dahil olmak üzere birçok faktörün değiş tokuşu olacaktır:

• uygulama çabası; gelecekteki sürdürülebilirlik;
• test durumu başarısızlık analizi çabası;
• hata ayıklama çabası;
• bu test senaryosunun benzer durumlarla başa çıkma yeteneği;
• sağlamlık;
• diğer otomatik test senaryoları için ne yapılır.

Diğer Doğrulama Gereksinimleri

Çevre hususlarını dikkate alarak, testimiz artık bitti, değil mi? Şu anda sahip olduğumuz şey, basitçe girdileri yakalamaya yönelik ilk girişimimizden kesinlikle çok uzun bir yol.

Sorulacak bir sonraki soru şudur: Bu iyi bir test senaryosu mu?

Aslında bu, onu otomatikleştirmeye başlamadan önce sormamız gereken ilk soruydu. Tartıştığımız gibi, zayıf test senaryolarını otomatikleştirmenin bir anlamı yok. Ancak şimdi değinmek istediğimiz nokta, yaptığımız karşılaştırmalarla ilgili. Yapmamız gereken her şeyi kontrol ettik mi? Bu test senaryosu tarafından bulunabilecek tüm kusurları ortaya çıkaracaklar mı?

Çoğu zaman, basit Karalama örneğimizle gösterebileceğimizin ötesine geçen, kontrol edebileceğimiz bir test senaryosunun sonucunun birçok yönü vardır.

Test senaryolarını manuel olarak gerçekleştiren test kullanıcıları, bazıları bilinçli ve muhtemelen birçoğu bilinçsiz olmak üzere çok sayıda kontrol yapacaktır. Otomatik testler yalnızca kontrol etmeye programlandıklarını kontrol edecek, bu nedenle tam olarak neyin programlandığını ve neyin dışarıda bırakılabileceğini dikkate almamız önemlidir.

Birçok sistem için dikkate alabileceğimiz sonuçlardan bazıları şunlardır:

» oluşturulmuş veya değiştirilmiş olabilecek dosyalar (Doğru dosyalar oluşturuldu mu? Doğru dosyalar değiştirildi mi? Doğru şekilde değiştirildi mi?);
• değiştirilmiş olabilecek veri tabanları (Doğru kayıtlar değiştirildi mi? Diğer kayıtlarda dokunulmaması gereken herhangi bir değişiklik yapıldı mı?);
» yazıcılar, ağlar veya diğer iletişim ekipmanları gibi diğer çıktılar (Doğru şeyler doğru yerlere gönderildi mi? Nasıl emin olabilirsiniz?);
« ekran nitelikleri değiştirilmiş olabilir, muhtemelen bir alanın korunup korunmadığı gibi görünmeyenler (Doğru nitelikler doğru yeni değerlerle değiştirildi mi?);

The post Gelişen Test Otomasyonu first appeared on Akademi Delisi (Tez Yaptırma).

Örnek Test Durumu

Örnek uygulamamızın adı Scribble. Değinmek istediğimiz noktaları göstermek amacıyla kullanılan çok basit bir kelime işlemcidir. Gerçek uygulamalar çok daha karmaşık olacak ve bu, testlerini otomatikleştirme sorunlarını da buna bağlı olarak daha karmaşık hale getirecek.

Karalama’nın bir özelliği, bir belgenin Liste olarak bilinen bir yapı içerebilmesidir. Bu bölümde kullandığımız örnek test durumu, bazı Liste düzenleme işlevlerini kullanır.

Listede (Hollanda) yalnızca bir öğe bulunan ilk durumdan başlayarak, Listenin sonuna eklenen yeni bir öğe olan Belçika’yı (Öğe Ekle işlevini kullanarak) ekliyoruz. Ardından, iki öğenin sırasını değiştiren Listeyi sıralarız.

Üçüncü öğeyi (Danimarka) eklediğimizde, artık sıralanmamış değil sıralanmış bir Liste olduğu için Listeye doğru yere eklenir. Son olarak, Listedeki (Belçika) ilk öğeyi, Öğeyi sil’i seçip konum numarasını girerek siliyoruz.

Bir Karalama Listesi Testi

Artık uygulamamızı (manuel olarak) test etmeye hazırız. Ülkeler adlı bir belgede bir Listenin düzenlenmesini test edeceğiz (‘dcm’ soneki ‘belge’ anlamına gelir). Başlangıç durumu, üç öğeden oluşan sıralanmış bir Listedir.

Test durumu aşağıdakileri gerçekleştirecektir:

• sıralanan listeye iki yeni öğe ekleyin;
• bir öğeyi hareket ettirin (bu, Listeyi sıralanmamış hale getirir);
• sıralanmamış listeye bir öğe ekleyin;
• bir öğeyi silin;
• orada olmayan bir öğeyi silmeye çalışın (geçersiz konum numarası).

Bu çok titiz bir test durumu değil ve elbette bu işlevselliği yeterince test etmek için başkaları da gerekecek. Ancak, yukarıdaki test durumunu amaçlarımız için makul olarak seçtik. Test senaryosunun yürütülmesi bir dizi ekran görüntüsünde gösterilmektedir.

Test Girdisi Nedir?

Yukarıdaki test durumunda, uygulamayı ilk çalıştırmadan tamamlamaya götürmek için girdi girdik ve test senaryosunu gerçekleştirmek için belirli verileri girdik. Gerçekleştirdiğimiz belirli tuş basmaları ve/veya fare eylemleri gösterilir.

Eylemlerimizi fiziksel konumları yerine ekrandaki mantıksal öğeler açısından tanımladığımıza dikkat edin, örneğin ‘bit konumu’ yerine ‘Liste menüsü’. Listelenen tüm fare tıklamalarının sol fare düğmesi olduğunu da unutmayın.

Yazılım test otomasyon araçları
Test otomasyon araçları
Yazılım test otomasyonu nedir
Test otomasyon Eğitimi
Manuel test ve otomasyon test
Otomasyon testi Nedir
Test otomasyon Çeşitleri
Test otomasyonu

Manuel Test Süreci

Yukarıdaki örnekte az önce manuel olarak gerçekleştirdiğimiz test durumu, şimdi bir tekrar yakalama aracı kullanarak otomatikleştirmeye çalışacağımız test durumudur. Tek bir test senaryosunu otomatikleştirmek için harcanan çabanın miktarı birçok şeye bağlıdır ve büyük ölçüde değişir.

Deneyimli otomatörler, genellikle testi manuel olarak çalıştırmak için gereken çabanın 2 ila 10 katı gerektiğini bildirir ve ara sıra raporlar bunun manuel test çabasının 30 katına kadar çıktığını söyler.

Bu nedenle, manuel olarak yarım saat süren bir test senaryosunun otomatikleştirilmesi 1 ila 5 saat arasında sürebilir, ancak 15 saate kadar da sürebilir. Otomatikleştirmeye başladığınızda, bir testi otomatikleştirmenin, manuel olarak çalıştırmaya göre en az beş kat daha uzun sürmesini bekleyin.

Bir test senaryosunu otomatikleştirmek için gereken çaba miktarını etkileyen şeylerden bazıları şunlardır:

» Kullanılan araç. Araçlar, otomatikleştirilmiş testler oluşturmayı kolaylaştırmak için tasarlanmış çeşitli kolaylıklar ve özellikler sağlar ve test uzmanlarının kayıt sırasında testin yeniden oynatılırken nasıl davranması gerektiği konusunda daha fazla belirlemesine giderek daha fazla olanak tanır.

« Test otomasyonuna yaklaşım. Otomatikleştirilmiş testler oluşturmak için kullanabileceğimiz birkaç farklı yaklaşım vardır, ancak çoğu kişinin kullandığı ilk yaklaşım manuel olarak gerçekleştirilen testi kaydetmek ve ardından bu kaydı yeniden oynatmaktır.

Diğer yaklaşımlar, kaydedilen komut dosyalarını değiştirmek veya komut dosyalarını manuel olarak hazırlamak için ek çaba gerektirir. Bu başlangıçta daha uzun sürse de, fikir yeni testlerin uygulanmasını kolaylaştırmak ve bakım maliyetlerini azaltmaktır.

» Test otomatının deneyim düzeyi. Açıkçası, bir test aracını kullanmaya çok aşina olan kişiler, onu daha hızlı ve daha az hatayla kullanabilecektir. Ayrıca iyi çalışmayan uygulamalardan kaçınabilmeli ve işe yarayanlara konsantre olabilmelidirler.

” Çevre. Test edilecek yazılımın, test için tam olarak çoğaltılmasının zor olduğu belirli ortamlarda çalıştığı durumlarda, testi otomatikleştirmek daha zor olabilir. Örneğin, gömülü yazılımlar ve gerçek zamanlı yazılımlar, ticari olarak temin edilemeyen özel araçlar veya özellikler gerektirebileceğinden özellikle zahmetlidir.

» Test edilen yazılım. Toplu programlar gibi kullanıcı etkileşimi olmayan yazılım uygulamalarının testlerinin otomatikleştirilmesi, yürütüldükleri ortamın yeniden üretilebilmesi koşuluyla çok daha kolaydır. Bunun nedeni, kullanıcı etkileşiminin ‘programlanmış’ olması gerektiğidir ve bu çok fazla iş gerektirebilir.

Bu kayıt altına alınabilse de uzun vadede uygun maliyetli bir çözümle sonuçlanmamaktadır. Bir toplu programın kullanıcı etkileşimi yoktur, ancak çağrıldığında veya yürütme sırasında dosyalardan veya veritabanlarından okunduğunda kendisine iletilen bilgilerle denetlenir.

Testi ve özellikle otomatik testi daha zor hale getirebilen yazılım uygulamalarının birçok yönü de vardır. Yazılım uygulamalarını tasarlarken dikkate alınması gereken birçok test sorunu vardır.

Ve genellikle, otomatikleştirme testini yapacak veya bozacak olan, yazılımın kendisinin tasarımıdır.

• Mevcut test süreci. Testi otomatikleştirirken, açıklandığı gibi test sürecini oluşturan beş aktiviteden bazılarını (test koşullarının belirlenmesi, test durumlarının tasarımı, testleri oluşturma, yürütme ve beklenen sonuçların gerçek sonuçlarla karşılaştırılması) otomatik hale getiriyoruz. Bunun sonuçları bir sonraki tartışma noktamız.

Mevcut test sürecinin, testi otomatikleştirmek için gereken çaba üzerindeki etkisi çok büyüktür. Test senaryoları belgelenmemişse ancak test uzmanları bunları gerektiği gibi oluşturuyorsa, test senaryolarının otomatikleştirilmesi, bunların tasarlanmasını da içerecektir. Diğer uçta ise, test durumları her girdi ve karşılaştırma not edilecek şekilde çok ayrıntılı olarak belgelenirse, bunları otomatikleştirmek daha az çaba gerektirecektir.

Aşağıdaki alt bölümlerde, test sürecinin üç geniş kategorisini açıklıyoruz: test senaryolarının tasarlanmadığı veya belgelenmediği geçici test, test senaryolarının belgelendiği ancak tüm detayların belirtilmediği belirsiz manuel komut dosyaları ve her girdinin ve karşılaştırmanın not edildiği ayrıntılı kılavuz metinleri söz konusudur. Kendi test süreçleriniz, aşağı yukarı bu kategorilerin bir veya daha fazlasına uymalıdır.

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

Test otomasyonu, bazı test görevlerinin, manuel olarak yapılan testlerden çok daha verimli bir şekilde gerçekleştirilmesini sağlayabilir. Aşağıda listelenenler de dahil olmak üzere başka faydalar da vardır.

1. Mevcut (gerileme) testlerini bir programın yeni sürümünde çalıştırın. Bu, özellikle birçok programın sıklıkla değiştirildiği bir ortamda belki de en bariz görevdir. Bir dizi regresyon testini gerçekleştirmek için gereken çaba minimum düzeyde olmalıdır. Testlerin halihazırda var olduğu ve programın önceki bir sürümünde çalıştırılmak üzere otomatikleştirildiği göz önüne alındığında, testleri seçmek ve yalnızca birkaç dakikalık manuel çabayla yürütmelerini başlatmak mümkün olmalıdır.

2. Daha fazla testi daha sık çalıştırın. Otomasyonun açık bir yararı, daha kısa sürede daha fazla test çalıştırma ve dolayısıyla bunları daha sık çalıştırma olanağı sağlamasıdır. Bu da sisteme olan güveni artıracaktır. Çoğu kişi otomasyonla aynı testleri daha hızlı yapacaklarını varsayar. Aslında daha fazla test yapma eğilimindedirler ve bu testler daha sık yapılır.

3. Manuel olarak yapılması zor veya imkansız olan testleri yapın. Diyelim ki 200 kullanıcıyla çevrimiçi bir sistemin tam ölçekli canlı testini gerçekleştirmeye çalışmak imkansız olabilir, ancak 200 kullanıcıdan gelen girdi, otomatik testler kullanılarak simüle edilebilir. Son kullanıcıların otomatik olarak yeniden yürütülebilecek testleri tanımlamasını sağlayarak, kullanıcı senaryosu testleri, tüm iş uygulamasının inceliklerini anlamayan teknik personel tarafından bile herhangi bir zamanda çalıştırılabilir.

Manuel olarak test ederken, beklenen sonuçlar tipik olarak testçi tarafından görülebilen bariz şeyleri içerir. Ancak, manuel olarak doğrulanması kolay olmayan, test edilmesi gereken nitelikler vardır. Örneğin, bir grafik kullanıcı arabirimi (GUI) nesnesi, herhangi bir anlık çıktı üretmeyen bazı olayları tetikleyebilir. Bir test yürütme aracı, olayın tetiklenip tetiklenmediğini kontrol edebilir ve bu, bir araç kullanılmadan kontrol edilemez.

4. Kaynakların daha iyi kullanımı. Aynı test girdilerinin tekrar tekrar girilmesi gibi önemsiz ve sıkıcı görevlerin otomatikleştirilmesi, personelin moralinin artmasının yanı sıra daha fazla doğruluk sağlar ve yetenekli test uzmanlarını çalıştırılacak daha iyi test senaryoları tasarlamaya daha fazla çaba harcamak için serbest bırakır.

Yazılım test otomasyonu nedir
Test otomasyonu Nedir
Test otomasyon araçları
Test otomasyon Çeşitleri
Yazılım test Otomasyon Mühendisi
BTK Akademi Yazılım Test Otomasyonu sınav soruları
Test Otomasyon is ilanları
Yazılım test otomasyon araçları

Her zaman en iyi şekilde manuel olarak yapılan bazı testler olacaktır; manuel olarak çalıştırılacak çok daha az test varsa, test uzmanları manuel test konusunda daha iyi bir iş çıkarabilir. Aksi takdirde gece boyunca veya hafta sonu boşta kalacak olan makineler, otomatik testler yapmak için kullanılabilir.

5. Testlerin tutarlılığı ve tekrarlanabilirliği. Otomatik olarak tekrarlanan testler her seferinde aynen tekrarlanacaktır (en azından girişler öyle olacaktır; örneğin zamanlama nedeniyle çıkışlar farklılık gösterebilir). Bu, testlere manuel olarak elde edilmesi çok zor olan bir tutarlılık düzeyi sağlar.

Aynı testler, farklı donanım konfigürasyonlarında, farklı işletim sistemlerinde veya farklı veritabanlarında gerçekleştirilebilir. Bu, çok platformlu ürünler için manuel testle elde edilmesi neredeyse imkansız olan bir çapraz platform kalitesi tutarlılığı sağlar.

İyi bir otomatik test rejiminin dayatılması, hem testte hem de geliştirmede tutarlı standartlar sağlayabilir. Örneğin araç, her uygulamada veya programda aynı türde özelliğin aynı şekilde uygulanıp uygulanmadığını kontrol edebilir.

6. Testlerin yeniden kullanımı. Neyin test edileceğine karar vermek, testleri tasarlamak ve testleri oluşturmak için harcanan çaba, bu testlerin birçok uygulamasına dağıtılabilir. Yeniden kullanılacak testler, güvenilir olduklarından emin olmak için zaman ayırmaya değer. Bu, manuel testler için de geçerlidir, ancak otomatikleştirilmiş bir test, manuel olarak tekrarlanan aynı testten çok daha fazla tekrar kullanılabilir.

7. Pazara daha erken zaman. Bir dizi test otomatikleştirildikten sonra, manuel olarak olduğundan çok daha hızlı tekrarlanabilir, böylece test için geçen süre kısaltılabilir (geliştiricilerin kusurları düzeltme yeteneği gibi diğer faktörlere tabidir).

8. Artan güven. Kapsamlı bir otomatikleştirilmiş test setinin başarıyla yürütüldüğünü bilmek, sistem piyasaya sürüldüğünde herhangi bir hoş olmayan sürpriz olmayacağına dair daha fazla güven olabilir (çalıştırılan testlerin iyi testler olması şartıyla!).

Özetle, hem kalite hem de üretkenlikte artış sağlayan daha az çabayla daha kapsamlı testler gerçekleştirilebilir.

Test Otomasyonunun Yaygın Sorunları

Testi otomatikleştirmeye çalışırken karşılaşılabilecek bir dizi sorun vardır. Tam bir sürpriz olarak gelen sorunların üstesinden gelmek genellikle daha zordur, bu nedenle karşılaşabileceğiniz sorun türleri hakkında bir fikir sahibi olmak, kendi otomasyon rejiminizi uygulamanıza yardımcı olacaktır.

Çoğu sorunun üstesinden gelinebilir ve bu kitap, onlarla başa çıkmanıza yardımcı olmayı amaçlamaktadır. Aşağıda daha yaygın sorunlardan bazılarını açıklıyoruz.

1. Gerçekçi olmayan beklentiler. Sektörümüz, herhangi bir yeni teknik çözümü benimsemesi ve mevcut tüm sorunlarımızı çözeceğini düşünmesiyle tanınır. Test araçları bir istisna değildir. Yeni bir araçla neler başarılabileceği konusunda iyimser olma eğilimi vardır. Bu çözümün şu anda yaşadığımız tüm sorunları en sonunda çözeceğini ummak insan doğasında var.

Satıcılar doğal olarak faydaları ve başarıları vurgularlar ve kalıcı faydalar elde etmek için gereken çaba miktarını hafife alabilirler. İyimserlik ve satıcılığın birlikte etkisi, gerçekçi olmayan beklentileri teşvik etmektir. Yönetim beklentileri gerçekçi değilse, araç teknik açıdan ne kadar iyi uygulanırsa uygulansın beklentileri karşılamayacaktır.

2. Zayıf test uygulaması. Test uygulaması zayıfsa, kötü organize edilmiş testlerle, az veya tutarsız belgelerle ve kusur bulmada pek iyi olmayan testlerle, testi otomatikleştirmek iyi bir fikir değildir. İlk önce testin etkinliğini artırmak, zayıf testin etkinliğini artırmaktan çok daha iyidir.

3. Otomatikleştirilmiş testlerin pek çok yeni hata bulması beklentisi. Bir testin ilk kez çalıştırıldığında bir kusur bulma olasılığı yüksektir. Bir test zaten çalıştırılmış ve başarılı olmuşsa, test değiştirilen veya yazılımın farklı bir bölümünde yapılan bir değişiklikten etkilenebilecek bir egzersiz kodu olmadıkça, aynı testi tekrar çalıştırmanın yeni bir kusur bulma olasılığı çok daha düşüktür. veya farklı bir ortamda çalıştırılıyor.

Test yürütme araçları, ‘tekrar oynatma’ araçlarıdır, yani regresyon testi araçlarıdır. Kullanımları, halihazırda çalıştırılmış olan tekrarlanan testlerdedir. Bu, yapılacak çok yararlı bir şeydir, ancak özellikle daha önce olduğu gibi aynı donanım ve yazılım ortamında çalıştırıldığında, çok sayıda yeni kusur bulması pek olası değildir.

Kusurları bulmaya yönelik iyi bir test tasarımına yönelik olsa da, kusur bulmayan testler değersiz değildir. Bir dizi testin tekrar geçtiğini bilmek, yazılımın eskisi gibi çalışmaya devam ettiği ve başka yerlerdeki değişikliklerin öngörülemeyen etkileri olmadığı konusunda güven verir.

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

Yazılımın amaçlanan ortamda olması gerektiği gibi çalışacağından emin olmak için test edilmesi gerekir. Yazılım testinin, var olan herhangi bir kusuru bulmada etkili olması gerekir, ancak aynı zamanda testleri olabildiğince hızlı ve ucuz bir şekilde gerçekleştirerek verimli olması gerekir.

Yazılım testinin otomatikleştirilmesi, yeterli test için gereken çabayı önemli ölçüde azaltabilir veya sınırlı bir süre içinde yapılabilecek testi önemli ölçüde artırabilir. Testler, manuel olarak saatlerce süren dakikalar içinde çalıştırılabilir. Bu kitapta yer alan vaka incelemeleri, farklı kuruluşların testi nasıl otomatikleştirebildiğini ve bazılarının önemli miktarda para tasarrufu sağladığını gösteriyor.

Manuel test eforundan %80’e varan tasarruf sağlandı. Bazı kuruluşlar doğrudan paradan veya çabadan tasarruf etmediler, ancak test otomasyonları, yalnızca manuel testle mümkün olandan daha kaliteli yazılımları daha hızlı üretmelerini sağladı.

Olgun bir test otomasyon rejimi, makinelerin normalde boşta olacağı gece boyunca yapılan testlerle ‘bir düğmeye dokunarak’ test yapılmasına izin verecektir. Otomatik testler tekrarlanabilir, tam olarak aynı girdileri aynı sırada tekrar tekrar kullanır, bu manuel testle garanti edilemeyen bir şeydir.

Otomatik test, en küçük bakım değişikliklerinin bile en az çabayla tam olarak test edilmesini sağlar. Test otomasyonu aynı zamanda pek çok basit işi de ortadan kaldırır. Test ne kadar sıkıcı görünürse, araç desteğine olan ihtiyaç o kadar artar.

Bu çalışma, yazılım testinin başarıyla otomatikleştirilmesiyle ilgili sorunları açıklayacaktır. Vurgu, otomatikleştirilmiş test yazılımları için teknik tasarım sorunları üzerindedir.

Test yazılımı, komut dizileri, girdiler, beklenen sonuçlar, kurulum ve temizleme prosedürleri, dosyalar, veritabanları, ortamlar ve otomatik testte kullanılan tüm ek yazılımlar veya yardımcı programlar dahil olmak üzere (‘otomatik’) test için gerekli olan dosyalar kümesidir. 

Bu giriş bölümünde genel olarak teste ve testin (parçalarının) otomasyonuna bakıyoruz. Test yürütmenin ve sonuç karşılaştırmanın neden test tasarımındansa otomatikleştirmeye daha uygun olduğunu düşündüğümüzü açıklıyoruz ve test otomasyonunun faydalarını, sorunlarını ve sınırlamalarını açıklıyoruz.

Rejim, bir hükümet sistemidir. Bu çalışma, test otomasyonu için bir rejimin nasıl kurulacağı ile ilgilidir. Bir test otomasyon rejimi, diğer şeylerin yanı sıra, test otomasyonunun nasıl yönetildiğini, otomatik testlerin uygulanmasında kullanılan yaklaşımları ve test yazılımının nasıl organize edildiğini belirler.

Test ve test otomasyonu farklıdır. Test etmek bir beceridir. Bu, bazı insanlar için şaşırtıcı gelse de, basit bir gerçektir. Herhangi bir sistem için astronomik sayıda olası test durumu vardır ve yine de pratikte bunların yalnızca çok küçük bir kısmını çalıştırmak için zamanımız vardır.

Yine de bu az sayıda test senaryosunun yazılımdaki kusurların çoğunu bulması beklenir, bu nedenle hangi test senaryolarının oluşturulacağını ve çalıştırılacağını seçme işi önemli bir iştir. Hem deneyler hem de deneyimler bize, test durumlarını rastgele seçmenin etkili bir test yaklaşımı olmadığını göstermiştir. İyi test senaryoları geliştirilecekse daha düşünceli bir yaklaşım gereklidir.

İyi bir test durumu tam olarak nedir? Bir test senaryosunun kalitesini tanımlayan dört özellik vardır; yani, ne kadar iyi. Belki de bunlardan en önemlisi, kusur bulma etkinliği, kusur bulup bulmadığı veya en azından kusur bulma olasılığının olup olmadığıdır.

İyi bir test senaryosu aynı zamanda örnek olmalıdır. Örnek bir test durumu, birden fazla şeyi test etmeli, böylece gereken toplam test durumu sayısını azaltmalıdır. Diğer iki özelliğin her ikisi de maliyet hususlarıdır: bir test senaryosunun gerçekleştirilmesi, analiz edilmesi ve hatalarının ayıklanması ne kadar ekonomiktir; ve ne kadar evrim geçirebilir olduğu, yani yazılım her değiştiğinde test senaryosu üzerinde ne kadar bakım çalışması gerekir.

Bu dört özellik genellikle birbirine karşı dengelenmelidir. Örneğin, pek çok şeyi test eden tek bir test senaryosunun gerçekleştirmesi, analiz etmesi ve hata ayıklaması muhtemelen çok maliyetli olacaktır. Ayrıca, yazılım her değiştiğinde çok fazla bakım gerektirebilir. Bu nedenle, örnek ölçekte yüksek bir önlemin, ekonomik ve evrilebilir ölçeklerde düşük önlemlerle sonuçlanması muhtemeldir.

Dolayısıyla, test etme becerisi yalnızca test senaryolarının yüksek oranda kusur bulmasını sağlamakla kalmaz, aynı zamanda test senaryolarının aşırı maliyetlerden kaçınmak için iyi tasarlanmasını da sağlar.

Yazılım test otomasyonu nedir
Test otomasyonu Nedir
Test otomasyon araçları
Test otomasyon Çeşitleri
Yazılım test Otomasyon Mühendisi
BTK Akademi Yazılım Test Otomasyonu sınav soruları
Test Otomasyon is ilanları
Yazılım test otomasyon araçları

Test Otomasyonu

Testleri otomatikleştirmek de bir beceridir ancak test etmekten çok farklı bir beceridir. Birçok kuruluş, bir testi otomatikleştirmenin, bir kez manuel olarak gerçekleştirmekten daha pahalı olduğunu görünce şaşırır. Test otomasyonundan fayda sağlamak için, otomatikleştirilecek testlerin dikkatle seçilmesi ve uygulanması gerekir. Otomatik kalite, test kalitesinden bağımsızdır.

Bir testin otomatikleştirilmiş veya manuel olarak yapılmış olması, onun etkinliğini veya ne kadar örnek teşkil ettiğini etkilemez. Bir testi otomatikleştirmede ne kadar zeki olduğunuz veya ne kadar iyi yaptığınız önemli değildir, eğer testin kendisi hiçbir şey başaramazsa, o zaman nihai sonuç hiçbir şeyi daha hızlı başaramayan bir testtir.

Bir testi otomatikleştirmek, yalnızca ne kadar ekonomik ve geliştirilebilir olduğunu etkiler. Bir kez uygulandığında, otomatik bir test genellikle çok daha ekonomiktir ve çalıştırma maliyeti, manuel olarak gerçekleştirme çabasının yalnızca bir kısmıdır.

Bununla birlikte, otomatik testlerin oluşturulması ve sürdürülmesi genellikle daha maliyetlidir. Testleri otomatikleştirme yaklaşımı ne kadar iyi olursa, onları uzun vadede uygulamak o kadar ucuz olacaktır. Testler otomatikleştirildiğinde bakım konusu düşünülmezse, otomatikleştirilmiş bir test paketinin tamamını güncellemek, tüm testleri manuel olarak gerçekleştirmenin maliyetinden daha fazla değilse bile daha pahalıya mal olabilir.

Bir test senaryosunun dört kalite özelliğini bir Keviat diyagramında gösterir. Manuel olarak gerçekleştirilen bir test durumu, düz çizgilerle gösterilir. Aynı test ilk kez otomatikleştirildiğinde, daha az evrim geçirebilir ve daha az ekonomik hale gelecektir (çünkü otomatikleştirmek için daha fazla çaba harcanmıştır). Otomatik test birkaç kez çalıştırıldıktan sonra, manuel olarak yapılan aynı testten çok daha ekonomik hale gelecektir.

Etkili ve verimli bir otomatik testler paketi için, iyi bir test paketinin ham maddesiyle, en önemli şeyleri uygulamak için bir test uzmanı tarafından ustaca tasarlanmış bir dizi testle başlamanız gerekir. Daha sonra, testleri makul bir maliyetle oluşturulabilecek ve sürdürülebilecek şekilde otomatikleştirmek için otomasyon becerilerini uygulamanız gerekir.

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