Bu eğitici, her Yazılım test uzmanı ve QA uzmanının bilmesi gereken yedi temel Yazılım Test İlkesini tanıtır.
Yazılım Testinin 7 Prensibi
- Test, kusurların varlığını gösterir
- Kapsamlı test mümkün değildir
- Erken test
- Kusur kümeleme
- Böcek öldürücü paradoksu
- Test, içeriğe bağlıdır
- Hataların yokluğu yanlış
Aşağıdaki video örneği ile test prensiplerini öğrenelim:
Videoya erişilemiyorsa burayı tıklayın
Arka fon
Hedeften sapmadan yazılım testi yaparken optimum test sonuçlarına ulaşmanız önemlidir. Peki test için doğru stratejiyi izlediğinizi nasıl belirlersiniz? Bunun için bazı temel test prensiplerine bağlı kalmanız gerekir. Yazılım endüstrisinde yaygın olarak uygulanan yedi ortak test prensibi aşağıda verilmiştir.
Bunu anlamak için, bir dosyayı A klasöründen B Klasörüne taşıdığınız bir senaryo düşünün.
Bunu test edebileceğiniz tüm olası yolları düşünün.
Olağan senaryoların yanı sıra, aşağıdaki koşulları da test edebilirsiniz.
- Dosya Açıkken taşımaya çalışılıyor
- Dosyayı Klasör B'ye yapıştırmak için güvenlik haklarına sahip değilsiniz
- Klasör B bir ortak sürücüde ve depolama kapasitesi dolu.
- Klasör B zaten aynı ada sahip bir dosyaya sahip, aslında liste sonsuz
- Veya test edilecek 15 giriş alanınız olduğunu ve her biri 5 olası değere sahip olduğunu varsayalım, test edilecek kombinasyon sayısı 5 15 olacaktır.
Tüm olası kombinasyonları test edecek olsaydınız YÜRÜTME SÜRESİ ve MALİYETLERİ katlanarak artacaktır. Test çabasını optimize etmek için belirli ilkelere ve stratejilere ihtiyacımız var
İşte 7 İlke:
1) Kapsamlı test yapmak mümkün değildir
Evet! Kapsamlı test yapmak mümkün değildir. Bunun yerine, uygulamanın risk değerlendirmesine dayalı olarak en uygun test miktarına ihtiyacımız var.
Ve milyon dolarlık soru şu, bu riski nasıl belirlersiniz?
Bunu cevaplamak için hadi bir egzersiz yapalım
Size göre, İşletim sisteminizin başarısız olmasına en çok hangi işlem neden olur?
Eminim çoğunuzun aynı anda 10 farklı uygulama açtığını tahmin ederdiniz.
Dolayısıyla, bu İşletim sistemini test ediyor olsaydınız, çoklu görev etkinliğinde kusurların bulunabileceğini ve kapsamlı bir şekilde test edilmesi gerektiğini fark edersiniz ve bu da bizi bir sonraki ilkemiz Kusur Kümeleme'ye getirir.
2) Kusur Kümeleme
Az sayıda modülün, tespit edilen kusurların çoğunu içerdiğini belirten Kusur Kümeleme. Bu, Pareto İlkesinin yazılım testine uygulanmasıdır: sorunların yaklaşık% 80'i modüllerin% 20'sinde bulunur.
Deneyimle, bu tür riskli modülleri tanımlayabilirsiniz. Ama bu yaklaşımın kendine göre sorunları var
Aynı testler defalarca tekrarlanırsa, sonunda aynı test senaryoları artık yeni hatalar bulamayacaktır.
3) Pestisit Paradoksu
Çiftçilik sırasında böcekleri yok etmek için aynı pestisit karışımının tekrar tekrar kullanılması, zamanla böceklerin pestiside direnç geliştirmesine yol açacaktır. Böylelikle pestisitlerin böcekler üzerinde etkisiz kalmasına neden olacaktır. Aynısı yazılım testi için de geçerlidir. Aynı tekrarlayan testler yapılırsa, yöntem yeni kusurları keşfetmek için işe yaramaz.
Bunun üstesinden gelmek için, test senaryolarının düzenli olarak gözden geçirilmesi ve gözden geçirilmesi ve daha fazla kusurun bulunmasına yardımcı olmak için yeni ve farklı test senaryolarının eklenmesi gerekir.
Test uzmanları sadece mevcut test tekniklerine güvenemezler. Testi daha etkili hale getirmek için mevcut yöntemleri iyileştirmek için sürekli olarak dikkat etmelidir. Ancak tüm bu ter ve zorlu test çalışmalarından sonra bile, ürününüzün hatasız olduğunu asla iddia edemezsiniz. Bu noktayı eve götürmek için, Windows 98'in genel lansmanının bu videosunu görelim.
MICROSOFT gibi bir şirketin işletim sistemlerini kapsamlı bir şekilde test etmeyeceğini ve sadece genel lansmanı sırasında işletim sistemlerinin çökmesini görmek için itibarlarını riske atacağını düşünüyorsunuz!
4) Test, kusurların varlığını gösterir
Bu nedenle, test ilkesi şunu belirtir: - Test, kusurların varlığından bahseder ve kusurların yokluğundan bahsetmez. Yani Yazılım Testi, yazılımda keşfedilmemiş kusurların kalma olasılığını azaltır, ancak herhangi bir kusur bulunmasa bile, bu bir doğruluk kanıtı değildir.
Ancak, tüm önlemleri alarak ekstra sıkı çalışırsanız ve yazılım ürününüzü% 99 hatasız hale getirirseniz ne olur? Ve yazılım müşterilerin ihtiyaçlarını ve gereksinimlerini karşılamıyor.
Bu bizi bir sonraki ilkemize götürür ve şunu belirtir: - Hata Yokluğu
5) Hata Yokluğu - yanlışlık
% 99 hatasız olan yazılımın hala kullanılamaz olması mümkündür. Sistem yanlış gereksinim için kapsamlı bir şekilde test edilirse bu durum söz konusu olabilir. Yazılım testi sadece kusurları bulmak değil, aynı zamanda yazılımın iş ihtiyaçlarını karşılayıp karşılamadığını kontrol etmek içindir. Hatanın yokluğu bir Hatadır, örn. Hataların bulunması ve düzeltilmesi, sistem yapısı kullanılamazsa ve kullanıcının ihtiyaçlarını ve gereksinimlerini karşılamıyorsa yardımcı olmaz.
Bu sorunu çözmek için, sonraki test ilkesi Erken Test
6) Erken Test
Erken Test - Test, Yazılım Geliştirme Yaşam Döngüsünde olabildiğince erken başlamalıdır. Böylece gereksinimlerdeki veya tasarım aşamasındaki herhangi bir kusur erken aşamalarda yakalanır. Testin ilk aşamalarında bir Kusuru düzeltmek çok daha ucuzdur. Ama teste ne kadar erken başlanmalı? Gereksinimler tanımlandığı anda hatayı bulmaya başlamanız önerilir. Daha sonraki eğitim eğitiminde bu ilke hakkında daha fazla bilgi.
7) Test bağlama bağlıdır
Test, içeriğe bağlıdır; bu, temel olarak, bir e-ticaret sitesini test etme şeklinizin, bir reklamı kullanıma hazır bir uygulamadan test etme şeklinizden farklı olacağı anlamına gelir. Geliştirilen tüm yazılımlar aynı değildir. Uygulama türüne bağlı olarak farklı bir yaklaşım, metodolojiler, teknikler ve test türleri kullanabilirsiniz. Örneğin, bir perakende mağazasındaki herhangi bir POS sistemi, bir ATM makinesini test etmekten farklı olacaktır.
Efsane: "İlkeler sadece referans içindir. Bunları pratikte kullanmayacağım."
Bu çok doğru değil. Test Prensipleri, etkili bir Test Stratejisi oluşturmanıza ve hata yakalama test senaryoları oluşturmanıza yardımcı olacaktır.
Ancak test prensiplerini öğrenmek, ilk kez araba kullanmayı öğrenmek gibidir.
Başlangıçta, sürmeyi öğrenirken, vites değiştirme, hız, debriyaj kullanımı vb. Gibi her şeye dikkat edersiniz. Ancak deneyim kazandıkça, sadece sürüşe odaklanırsınız, gerisi doğal olarak gelir. Öyle ki arabadaki diğer yolcularla bile sohbet ediyorsun.
Aynı şey test ilkeleri için de geçerlidir. Deneyimli testçiler bu ilkeleri hiç düşünmeden bile uygulayacakları düzeyde içselleştirmişlerdir. Bu nedenle, ilkelerin pratikte kullanılmadığı efsanesi basitçe doğru değildir.