Test senaryolarını ve önceliklerini tanımlama

Neleri test edeceğinizi belirleyin, test senaryolarınızı tanımlayın ve öncelik verin.

Önceki yayında test stratejileri, bir uygulamayı test etmek için gereken test sayısı ve kaynaklarınızı göz önünde bulundurarak sonuçlara en fazla güveni kazanmak için en uygun yöntemi nasıl bulacağınız hakkında bilgi edinmiştiniz. Ancak bu, ne kadar test yapacağımız konusunda bize yalnızca bir fikir verir. Neleri test edeceğinizi tam olarak belirlemeniz gerekir. Aşağıdaki üç ölçüt, bir testte ne bekleyebileceğinizi anlamanıza ve hangi test türünün ve ayrıntı düzeyinin en uygun olabileceğini görmenize yardımcı olabilir:

  1. Mutlu yolunuzda ilerleyin. Bu, uygulamanızın en genel veya birincil kullanıcı hikayesidir. Kullanıcınızın hatayı çok hızlı bir şekilde fark edeceği yerdir.
  2. Ayrıntı düzeyine dikkatlice karar verin. Kullanım alanınız güvenlik açığı barındırıyorsa veya bir hata büyük hasara neden olacaksa daha ayrıntılı bilgi verin.
  3. Mümkün olduğunda daha yüksek düzeyli uçtan uca testlere kıyasla alt düzey testlere öncelik verin (ör. birim ve entegrasyon testleri).

Bu makalenin geri kalanında bu ölçütler ve test örneklerini tanımlarken bunların nasıl uygulandığı incelenmektedir.

Test kaydı nedir?

Yazılım geliştirmede test senaryosu, bir yazılım programının veya uygulamasının etkinliğini doğrulamak için tasarlanmış bir dizi işlem veya durumdur. Test durumları, yazılımın planlandığı gibi çalışmasını ve tüm özelliklerinin ve işlevlerinin doğru şekilde çalışmasını sağlamayı amaçlar. Yazılım test kullanıcıları veya geliştiriciler, yazılımın belirtilen gereksinimleri ve spesifikasyonları karşıladığını garanti etmek için genellikle bu test durumlarını oluşturur.

Test durumu doğrulanıyor.

Bir test senaryosu çalıştırıldığında yazılım, istenen sonuçları verdiğinden emin olmak için bir dizi kontrol gerçekleştirir. Testler bu işlemi yaparken aşağıdaki görevleri yerine getirir:

  • Doğrulama. Yazılımın hatasız çalıştığından emin olmak için yazılımı ayrıntılı bir şekilde kontrol etme işlemi. Oluşturulan ürünün gerekli tüm işlev dışı koşulları karşılayıp karşılamadığını ve amaçlanan amaca başarıyla ulaşıp ulaşmadığını belirlemek çok önemlidir. Bu soruya yanıt verir: "Ürünü doğru şekilde mi geliştiriyoruz?"
  • Doğrulama. Yazılım ürününün gerekli standartları veya üst düzey gereksinimleri karşılamasını sağlama süreci. Gerçek ürünün beklenen ürünle uyumlu olup olmadığını kontrol eder. Temel olarak, "Kullanıcı ihtiyaçlarını karşılayacak doğru ürünü mü geliştiriyoruz?" sorusunu yanıtlıyoruz.

Programın beklenen sonucu vermediğini varsayalım. Bu durumda, test durumu haberci görevi görür ve başarısız bir sonuç bildirir. Geliştiricinin veya test kullanıcısının sorunu inceleyip bir çözüm bulması gerekir. Kontrolleri ve işlemleri, test türünden bağımsız olarak bilgisayarın izlediği yollar olarak düşünün. Kontrol için kullanılan giriş verisi veya koşul gruplarına "denklik sınıfları" denir. Test edilen sistemden benzer davranışlar veya sonuçlar almalıdır. Bir testin içinde yürütülen belirli yollar değişiklik gösterebilir ancak testinizde yapılan etkinlikler ve iddialarla eşleşmelidir.

Test yolları: Tipik test durumu türleri

Yazılım geliştirmede test senaryosu, belirli bir davranışın beklendiği ve test edildiği bir kod yürütme senaryosudur. Genellikle test senaryoları oluşturmak için üç senaryo vardır.

Mutlu yol.

Bunlardan ilki, muhtemelen zaten kullandığınız en iyi bilinen yöntemdir. "Mutlu gün senaryosu" veya "altın yol" olarak da bilinen mutlu yol, özelliğinizin, uygulamanızın veya değişikliğinizin en yaygın kullanım alanını (müşteri için nasıl çalışması gerektiğini) tanımlar.

Korkunç yol.

Test durumlarınızda ele alınması gereken en önemli ikinci test yolu, adından da anlaşılabileceği gibi rahatsız edici olduğu için genellikle atlanır. Bu, "korkunç yol" veya başka bir deyişle negatif test'tir. Bu yol, kodun hatalı davranmasına veya hata durumuna girmesine neden olan senaryoları hedefler. Bu senaryoları test etmek, özellikle paydaşlar veya kullanıcılar üzerinde yüksek risk oluşturan, yüksek düzeyde savunmasız kullanım alanlarınız varsa önemlidir.

Hakkında bilgi edinip kullanmayı düşünebileceğiniz başka yollar da vardır ancak bunlar genellikle daha az kullanılır. Bunlar aşağıdaki tabloda özetlenmiştir:

Test yolu Açıklama
Kızgın yol Bu, hatalara neden olur ancak bu hatalar beklenir. Örneğin, hata işleme sürecinin doğru çalıştığından emin olmak istiyorsanız bu hataları kullanabilirsiniz.
Ödemenin gecikme yolu Bu yol, uygulamanızın karşılaması gereken tüm güvenlikle ilgili senaryoları ele alır.
Issız yol Uygulamanızdaki senaryoyu test eden yol, işlevini yerine getirmek için yeterli veri almıyordur (ör. boş değerleri test etme).
Unutulmuş yol Uygulamanızın davranışını yetersiz kaynaklarla test etmek (ör. veri kaybını tetiklemek).
Kararsız yol Uygulamanızda işlem yapmaya çalışan veya kullanıcı hikayelerini takip eden ancak bu iş akışlarını tamamlamamış bir kullanıcıyla test etme. Örneğin, kullanıcı iş akışını kesintiye uğrattığında bu durumla karşılaşılabilir.
Açgözlü yol Çok fazla giriş veya veri kullanarak test etmeye çalışmak.
Stresli yol Uygulamanızın çalışmasını engelleyecek kadar yük bindirmeye çalışmak (yük testine benzer).

Bu yolları kategorize etmenin birkaç yöntemi vardır. Sık kullanılan iki yaklaşım şunlardır:

  • Eşdeğerlik bölümlendirme. Test durumlarını gruplara veya bölümlere ayıran ve sonuç olarak eşdeğerlik sınıfları oluşturmaya yardımcı olan bir test yöntemi. Bu, bir bölümdeki bir test durumunda bir kusur ortaya çıkarsa 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 eşdeğerlik sınıfındaki tüm girişler aynı davranışı sergileyeceğinden test örnekleri sayısını azaltabilirsiniz. Eşdeğerlik bölümleme hakkında daha fazla bilgi edinin.
  • Sınır analizi. Sistemin kapasite veya kısıtlama sınırlarına bağlı olarak ortaya çıkabilecek olası sorunları ya da hataları bulmak için giriş değerlerinin sınırlarını veya uç değerlerini inceleyen, sınır değeri analizi olarak da bilinen bir test yöntemi.

En iyi uygulama: Test durumları yazma

Bir test kullanıcısı tarafından yazılan klasik bir test durumu, yapmak istediğiniz testin içeriğini anlamanıza ve elbette testi yürütmenize yardımcı olacak belirli veriler içerir. Tipik bir test kullanıcısı, test çalışmalarını bir tabloda belgeler. Bu aşamada, test durumlarımızı ve daha sonra testlerimizi yapılandırmamıza yardımcı olacak iki kalıp kullanabiliriz:

  • Düzenle, hareket et, iddia et kalıbı. "Düzenle, uygula, iddia et" ("AAA" veya "Üç A" olarak da bilinir) test kalıbı, testleri üç farklı adımda düzenlemenin bir yoludur: Testi düzenleme, ardından testi gerçekleştirme ve son olarak da sonuç çıkarma.
  • Verilen, ne zaman, o zaman kalıbı. Bu kalıp, AAA kalıbına benzer ancak davranışa dayalı geliştirme ile ilgili bazı köklere sahiptir.

Testin yapısı ele alındıktan sonra, gelecekteki makalelerde bu kalıplar hakkında daha fazla bilgi verilecektir. Bu aşamada bu kalıpları daha ayrıntılı incelemek istiyorsanız Düzenle-Yap-İddia Et: İyi testler yazmak için bir kalıp ve Verilen-Ne Zaman-O Zaman makalelerine göz atın.

Bu makaleden edinilen tüm bilgilere göre, aşağıdaki tabloda klasik bir örnek özetlenmiştir:

Bilgi Açıklama
Ön koşullar Testi yazmadan önce yapılması gereken her şey.
Test edilen nesne Neyin doğrulanması gerekiyor?
Giriş verileri Değişkenler ve değerleri.
Yürütülecek adımlar Testinizi hayata geçirmek için yapacağınız tüm işlemler: testlerinizde yaptığınız tüm işlemler veya etkileşimler.
Beklenen sonuç Ne olması gerekir ve hangi beklentiler karşılanmalıdır?
Gerçek sonuç Gerçekte ne oluyor?

Otomatik testte, tüm bu test durumlarını bir test uzmanının ihtiyaç duyduğu şekilde belgelemeniz gerekmez (bunun faydalı olduğu şüphesizdir). Dikkatli olursanız tüm bu bilgileri testinizde bulabilirsiniz. Bu klasik test vakasını otomatik bir teste dönüştürelim.

Bilgi Test otomasyonuna çevirme
Ön koşullar İhtiyacınız olan her şey, testi düzenleme ve test senaryosunun gerçekleşmesi için nelerin sağlandığını düşünme.
Test edilen nesne Bu "nesne" çeşitli şeyler olabilir: test edilen bir uygulama, akış, birim veya bileşen.
Giriş verileri Parametre değerleri.
Yürütülecek adımlar Testinizde yürütülen tüm işlemler ve komutlar, işlem yaptığınız öğeler ve belirli işlemleri yaptığınızda ne olacağını öğrenme.
Beklenen sonuç Uygulamanızı doğrulamak için kullandığınız iddia, uygulamanızda iddia ettiğiniz şeyler.
Gerçek sonuç Otomatik testinizin sonucu.