Otomatik Test Araçları
Otomatik Test Araçları
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.
Appium Fonksiyonel test Araçları Hermenik test modeli Hp LoadRunner nedir Manuel test araçları Test yönetim Araçları Yazılım test araçları Yazılım test otomasyon araçları