Yazma Kabul test senaryoları

Bir test sürecini SCRUM sürecimize entegre ediyoruz. Yeni görevim, daha sonra otomatikleştirmek için web uygulamalarımızın kabul testlerini yazmak. Test senaryolarının nasıl yazılması gerektiği hakkında çok şey okudum, ancak hiçbiri karmaşık web uygulamaları için test senaryoları yazmak için pratik önerilerde bulunmadı ve bunun yerine uygulamakta zorlandığım çelişen ilkeleri attılar:

• Test senaryoları kısa olmalıdır: Bir CMS örneğini ele alalım. Kısa test senaryolarının bakımı ve giriş ve çıkışlarının tanımlanması kolaydır. Ancak, uzun bir dizi işlemi test etmek istersem (örn. Belge ekleme, başka bir kullanıcıya bildirim gönderme, diğer kullanıcı cevaplar, belge durumu değiştirir, kullanıcı bir bildirim alır). Bana öyle geliyor ki test senaryoları tam senaryoları temsil etmeli. Ancak bunun açıkça karmaşık test belgelerini nasıl üreteceğini görebiliyorum.

• Testler girdi ve çıktıları tanımlamalıdır:: Pek çok etkileşimli alanla, farklı davranışlarla uzun bir formum varsa. Her şey için bir test mi yoksa her biri için bir test mi yazarım?

• Test senaryoları bağımsız olmalıdır: Ancak, yükleme işleminin test edilmesi bağlantı işleminin başarılı olmasını gerektiriyorsa nasıl başvurabilirim? Ve test senaryoları yazmak için nasıl uygulanır? Her işlem için bir test yazmalı mıyım, ancak her test bağımlılıklarını bildirmeli mi yoksa her test için tüm senaryoyu yeniden mi yazmalıyım?

• Test senaryoları hafifçe belgelenmelidir: Bu ilkeler Çevik projelere özgüdür. Peki bu prensibi nasıl uygulayacağınız konusunda tavsiyeniz var mı?

Kabul testi vakaları yazmanın basit olacağını düşünmeme rağmen, yapmak zorunda olduğum her karardan kendimi bunalmış buldum (FYI: Ben profesyonel bir test kullanıcısı değil geliştiriciyim). Benim asıl sorum şu: Karmaşık uygulamalar için sürdürülebilir kabul testi örnekleri yazmak için hangi adımlara veya tavsiyelere sahipsiniz? Teşekkür ederim.

Düzenleme : Sorumu açıklığa kavuşturmak için: Kabul testinin gereksinimden başlaması ve tüm uygulamayı bir kara kutu olarak görmesi gerektiğinin farkındayım. Sorum, test belgesini yazmak, test senaryolarını tanımlamak, testler arasındaki bağımlılıkları ele almak için ... karmaşık web uygulamaları için pratik adımlarla ilgilidir.

Kabul takımlarımda teknolojiye özgü kontrolleri kullanmaktan uzak kaldım yani web uygulamaları için css kullanma html öğeleri kullanmıyorsanız, bir formu doldurmanız gerekiyorsa gerçek kabul testlerini değil SUT'u kurma adımlarındaki özellikleri yapın

Kabulüm için salatalık kullanıyorum ve aşağıdakilere sahibim

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

Bu örnek bir web uygulaması tarafından geri döndü, ancak yine de kabulleri değil SUT'u ayarlamak için adımlar kullanıldığından testi bir masaüstü uygulamasına karşı test etmek için kullanabilirim

Bu test, devam eden bir satın alma işleminin sonunda yer alır.

Oluştur -> Onayla -> Ödeme -> Makbuzu Yazdır

yukarıdaki test, ödeme adımı için, uygulamanın bu durumlara veri veya http eylemleriyle bu durumlara ayarlanabilmesi nedeniyle diğer testlerde ayarlanmıştır, bu durumda ödemenin onaylama adımlarını gerçekleştiren bir onaylaması vardır ve onaylama dakikaları biraz kırılgan olacak şekilde adımlar oluşturun

Öncelikle Kabul Testini tanımlamanız gerekir .

Açıkladığınız şey entegrasyon veya sistem testidir .

Bu yüzden wikipedia'daki tanımlara% 100 katılmama rağmen, hala büyük ölçüde geçerlidir.

Temel olarak kabul testinin amacı, inşa ettiğiniz yazılımdan yararlanan 'iş' süreçlerinin gerçekte tasarlandığı gibi çalıştığını ve amaca uygun olduğunu doğrulamaktır. Bu nedenle, birim testleri veya diğerleri gibi test senaryoları oluşturmazsınız. Aynı şekilde tasarlanmış olması gerekmez.

Sorulması gereken soru "sistem nasıl kullanılıyor?". Şimdi kullanması gerektiği şekilde test edelim. Tabii ki şimdi mühendislik şapkanızı tekrar giyiyorsunuz ve test durumlarınızı türetmek için dini olarak iş gereksinimlerini karşılıyorsunuz. Bu, iyi yazılmış iş gereksinimleriniz olduğunu varsayar.

Eğer yapmazsanız, çok geç değildir, kullanıcı (lar) veya temsilcileri (ve iş analisti ve teknik tasarım personeli) ile oturup yazılımın ticari açıdan teslim etmesini beklediklerini yazmalısınız ( bunun çok az geç olduğu açık bir uyarıyla, ancak geç başlamak hiç olmadığı kadar iyidir - ve elbette yeni özellikler sunmayın). Test durumlarınız bu olacak.

Bununla ilgili başka bir yol da (böyle bir belgeniz varsa tekrar) kullanım kılavuzundan geçmektir. Bu, gerçek iş gereksinimlerinden bir adım kaldırılmasına rağmen, yalnızca her şey başarısız olursa kullanılmalıdır.

Bir araba satın almaya gittiğinizde, genellikle kaputun altına çok derin gitmezsiniz (eğer bir araba tamircisi değilseniz). Sadece direksiyona oturuyorsunuz ve konfor, kullanışlılık, görünüş, sesler ... yani genel şeyler kontrol ediyorsunuz. Genellikle arabanız ilk etapta elinizde olursa (en azından yeni bir araba için), genellikle güvenli ve iyi inşa edildiğine (bir garanti var, ev işinizi yaptığınıza ve teknik özelliklere baktığınıza) ...). Şimdi, bunun önümüzdeki birkaç yıl için kullanmak isteyeceğiniz araç olup olmadığını kontrol edersiniz.

Yazılım ile aynı.

Çelişkili bilgiler sinir bozucu olabilir ve genel durumunuza özgü ve özel durumunuza uygulanması zor olabilir. Ergo, bağlamınızda en iyi olanı yapmanız gerekebilir.

Uzun test belgelerinin büyük bir hayranı değilim ve birkaç küçük proje için oldukça etkili görseller kullandım. Bunu dene? Yalnızca metin kullanmak yerine akış şeması (veya durum şeması gibi herhangi bir UML diyagramı vb.) Girdileri, çıktıları, koşulları, döngüleri, şeritleri, durumları, diğer bileşenlerle etkileşimleri vb. Belirtin ve ardından bunların ölçütlerinize göre başarılı, başarısız, aktarılmış, diğer (?) Olup olmadığını belirtin.

Başlangıçta biraz iş olabilir, ancak uzun vadede aklı başında olmanıza yardımcı olabilir. Hangi yöntemi seçerseniz seçin, ne kadar çok çalışırsanız, o kadar iyi alırsınız.

HTH ve iyi şanslar!

KM

Sanırım şimdiden bazı iyi kriterleri çektin. İkinci noktanız, testlerinizin kapsamlarını tanımlamak için iyi bir yoldur ve ayrıca hata koşulları ve düzeltmeler için test yapmanızı öneririm (her hata düzeltmesinin en az bir yeni birim testi ile geldiğini savunuyorum). Şimdi bunaltıcı görünebilir, ancak sadece dalın ve biraz deneyim kazandıktan sonra, iyi testler için neyin işe yaradığını anlamak daha kolay hale gelecektir.