Neleri test edeceğinizi belirleyin, test durumlarınızı tanımlayın ve öncelikleri belirleyin.
Bir önceki gönderide test stratejileri, bir uygulamayı test etmek için gereken test sayısı ve kaynaklarınızı göz önünde bulundururken sonuçlardan en yüksek güveni elde etmek için en iyi eşleşmenin nasıl bulunacağı hakkında bilgi edindiniz. Ancak bu, bize yalnızca ne kadar test yapmamız gerektiği konusunda bir fikir verir. Yine de tam olarak neyi test edeceğinizi belirlemeniz gerekir. Aşağıdaki üç kriter, bir testten neler bekleyebileceğinizi anlamanıza ve hangi test türü ve ayrıntı düzeyinin en uygun olduğunu görmenize yardımcı olabilir:
- Kendinize iyi bakın. Bu, uygulamanızın bir hatayı çok hızlı fark edeceği en genel veya birincil kullanıcı hikayesidir.
- Ayrıntı düzeyine dikkatlice karar verin. Kullanım alanınız savunmasızsa veya bir hatanın yüksek hasara neden olacağı durumlar hakkında daha ayrıntılı bilgi verin.
- Mümkün olduğunda üst düzeydeki uçtan uca testler yerine, birim ve entegrasyon testleri gibi alt seviyedeki testlere öncelik verin.
Bu makalenin geri kalanında, bu ölçütler ve test durumlarını tanımlarken nasıl geçerli oldukları açıklanmaktadır.
Test senaryosu nedir?
Yazılım geliştirmede test senaryosu, bir yazılım programının veya uygulamanın etkinliğini onaylamak için tasarlanan bir dizi eylem veya durum dizisidir. Test senaryosunun amacı, yazılımın planlandığı gibi çalışmasını ve tüm özellikleri ile işlevlerinin doğru çalışmasını sağlamaktır. Yazılım test kullanıcıları veya geliştiriciler genellikle bu test senaryolarını, yazılımın belirtilen gereksinimleri ve spesifikasyonları karşıladığını garanti etmek için oluşturur.
Test durumu çalıştırıldığında, yazılım istenen sonuçları verdiğinden emin olmak için bir dizi kontrol gerçekleştirir. Bu sırada test, aşağıdaki görevleri yerine getirir:
- Doğrulama. Hatasız çalıştığından emin olmak için yazılımı baştan sona kontrol etme işlemi. Üretilen ürünün işlevsel olmayan gerekli tüm gereklilikleri karşılayıp karşılamadığını ve amaçlanan amacına başarıyla ulaşıp ulaşmadığını belirlemek son derece önemlidir. Yanıtladığı soru şudur: "Ürünü doğru üretiyor muyuz?"
- Doğrulama. Yazılım ürününün gerekli standartları veya üst düzey gereklilikleri karşıladığından emin olma süreci. Gerçek ürünün beklenen ürünle uyumlu olup olmadığını kontrol eder. Esas olarak şu soruya cevap vermemiz gerekir: "Kullanıcının gereksinimlerine uygun ürünü üretiyor muyuz?"
Programın beklenen sonucu alamadığını varsayalım. Bu durumda, test vakası mesajı veren kişi olacaktır. Bu nedenle, başarısız bir sonuç bildirilir ve geliştirici veya test kullanıcısının sorunu araştırıp bir çözüm bulması gerekir. Kontrolleri ve işlemleri, test türü ne olursa olsun bilgisayarın izlediği yollar olarak düşünebilirsiniz. Kontrol için kullanılan giriş verisi veya koşulu gruplarına "eşdeğer sınıfları" adı verilir. Test edilen sistemden benzer davranış veya sonuçlar almaları gerekir. Test içinde yürütülen belirli yollar değişiklik gösterebilir, ancak testinizde yapılan etkinlikler ve onaylarla eşleşmelidir.
Test yolları: Tipik test durumu türleri
Yazılım geliştirmede test durumu, belirli bir davranışın beklendiği ve test edildiği bir kod yürütme senaryosudur. Genellikle test senaryolarının oluşturulacağı üç senaryo vardır.
Bunlardan ilki en iyi bilinenlerden biridir ve muhtemelen zaten kullanıyorsunuzdur. "Mutlu günler senaryosu" veya "altın yol" olarak da bilinen mutlu yol. Özelliğiniz, uygulamanız veya değişikliğinizin en yaygın kullanım alanını, yani müşteri için nasıl çalışması gerektiğini tanımlar.
Test durumlarınızda ele alınacak en önemli ikinci test yolu, adından da anlaşılacağı gibi rahatsız edici olduğundan genellikle dışarıda bırakılır. "Korkunç yol" veya başka bir deyişle negatif test verilebilir. Bu yol, kodun hatalı çalışmasına veya hata durumu girmesine neden olan senaryoları hedefler. Paydaşlar veya kullanıcılar için yüksek risk oluşturan son derece savunmasız kullanım alanlarınız varsa bu senaryoları test etmek özellikle önemlidir.
Bilgi edinmek ve kullanmayı düşünebileceğiniz başka yollar da vardır, ancak bunlar genellikle daha seyrek kullanılır. Aşağıdaki tabloda bunlar özetlenmiştir:
Yolu test et | Açıklama |
---|---|
Öfkeli yol | Bu, bir hataya yol açar ancak beklenen bir hatadır (örneğin, hata işlemenin doğru çalıştığından emin olmak istiyorsanız). |
Geciken yol | Bu yol, uygulamanızın karşılaması gereken güvenlikle ilgili tüm senaryoları halleder. |
Issız yol | Uygulamanızdaki senaryo için hazırlanan yol testi, boş değerleri test etme gibi işlemler için yeterli veriyi alamıyor. |
Unutulan yol | Uygulamanızın davranışını yetersiz kaynak olmadan test etmek (örneğin, veri kaybını tetikleme). |
Belirsiz yol | Uygulamanızda işlem yapmaya veya kullanıcı hikayelerini takip etmeye çalışan ancak bu iş akışlarını tamamlamayan bir kullanıcıyla test etme. Bu, kullanıcının iş akışını kesintiye uğratması gibi bir durum olabilir. |
Açılı yol | Çok fazla miktarda giriş veya veri kullanarak test etmeye çalışmak. |
Stresli yol | Uygulamanız artık işlevsiz hale gelene kadar (yük testine benzer şekilde) gerekli herhangi bir yolla uygulamanıza bir yük koymaya çalışma. |
Bu yolları kategorilere ayırmak için birkaç yöntem vardır. İki yaygın yaklaşım şunlardır:
- Eşdeğer bölümlendirme. Test durumunu gruplara veya bölümlere ayıran ve sonuç olarak denklik sınıflarının oluşturulmasına yardımcı olan bir test yöntemidir. Bu, bir bölümdeki bir test durumu bir kusuru ortaya çıkarırsa aynı bölümdeki diğer test durumlarının da büyük olasılıkla benzer kusurları ortaya çıkaracağı fikrine dayanır. Belirli bir denklik sınıfındaki tüm girişler aynı davranış sergilemesi gerektiğinden, test durumu sayısını azaltabilirsiniz. Denklik bölümlendirme hakkında daha fazla bilgi edinin.
- Analizi sınırlayın. Sistemin yeteneklerinin sınırlarında veya kısıtlamalarında ortaya çıkabilecek sorunları ya da hataları bulmak için giriş değerlerinin sınırlarını veya uç değerlerini inceleyen bir test yöntemidir. Bu yöntem, sınır-değer analizi olarak da bilinir.
En iyi uygulama: Test senaryoları yazma
Test kullanıcısı tarafından yazılan klasik bir test senaryosu, gerçekleştirmek istediğiniz testin içeriğini anlamanıza ve tabii ki testi yürütmenize yardımcı olacak özel veriler içerir. Tipik bir test kullanıcısı test çabalarını bir tabloda belgeler. Bu aşamada kullanabileceğimiz iki kalıp vardır ve bunlar test durumlarımızı yapılandırmamıza yardımcı olur ve daha sonra, testlerimizi kendileri de oluşturur:
- Kalıbı düzenleyin, uygulayın, doğrulayın. "Düzenleme, harekete geçme, onaylama" ("AAA" veya "Üçlü A" olarak da bilinir) test kalıbı, testleri üç farklı adımda düzenlemenin bir yoludur: testi düzenleme, testi gerçekleştirme ve son olarak sonuçlar çıkarma.
- Verilen, ne zaman, sonra kalıbı. Bu kalıp, AAA modeline benzer ancak davranış odaklı gelişim ile ilgili bazı noktalara sahiptir.
Testin kendi yapısını ele aldığımızda, bundan sonraki makalelerde bu kalıplarla ilgili daha fazla ayrıntı verilecektir. Bu aşamada bu kalıpları daha ayrıntılı incelemek isterseniz şu iki makaleyi inceleyebilirsiniz: Düzenleme-İşlem-Onaylama: İyi testler yazmak için bir kalıp ve Verilen-Ne zaman-Sonra.
Bu makaleden edinilen bilgiler doğrultusunda, aşağıdaki tabloda klasik bir örnek özetlenmektedir:
Bilgi | Açıklama |
---|---|
Ön koşullar | Testi yazmadan önce yapılması gereken her şey. |
Nesne test ediliyor | Neyin doğrulanması gerekiyor? |
Giriş verileri | Değişkenler ve değerleri. |
Uygulanacak adımlar | Testinizi hayata geçirmek için yapacağınız her şey: testlerinizde gerçekleştirdiğiniz tüm eylemler veya etkileşimler. |
Beklenen sonuç | Ne olması gerektiği ve hangi beklentilerin karşılanması gerektiği. |
Gerçek sonuç | Gerçekte ne olacağı. |
Otomatik testte, tüm bu test durumlarını test kullanıcısının ihtiyaç duyduğu şekilde belgelemeniz gerekmez, ancak kuşkusuz faydalı olabilir. Dikkat ederseniz tüm bu bilgileri testinizde bulabilirsiniz. Şimdi bu klasik test senaryosunu otomatik bir teste dönüştürelim.
Bilgi | Test otomasyonuna çeviri |
---|---|
Ön koşullar | İhtiyaç duyduğunuz her şeyi temin etmek, testi düzenlemek ve test senaryonuzun gerçekleşmesi için ne verileceğini düşünmek. |
Nesne test ediliyor | Bu "nesne" çeşitli şeyler olabilir: test edilen uygulama, akış, birim veya bileşen. |
Giriş verileri | Parametre değerleri. |
Uygulanacak adımlar | Testinizin içinde yürütülen tüm eylemler ve komutlar, uyguladığınız eylemler ve belirli şeyleri yaptığınızda ne olduğunu öğrenme. |
Beklenen sonuç | Başvurunuzu doğrulamak için kullandığınız iddialar, başvurunuzda iddia ettiğiniz ifadeler. |
Gerçek sonuç | Otomatik testinizin sonucu. |