Testi Ne Zaman Durdurmayı Nasıl Bilirsiniz?

Bunun çok temel bir soru olduğunu biliyorum. Bazı yazılım uygulamaları için, bir uygulama için neredeyse sonsuz sayıda yüksek sayıda test vakası vardır. Tüm bu test durumlarını test etmek pratik değildir. Testin ne zaman durdurulacağına nasıl karar veririz? ("para tükendiğinde" hariç).

Glenford Myers'ın Yazılım Sanatı Testi'nin kitabı bunun için basit ama iyi bir ilkeye sahiptir: Hata bulmayı bıraktığınızda test tamamlanmıştır. Ya da daha pratik olarak, yeni böcek bulma oranınız oldukça yavaşlar.

Hatalar, bazı modüllerde ve bazı fonksiyonlarda "kümelenme" eğilimindedir: Birinde bir böcek bulduğunuzda, daha fazla hata için daha fazla araştırmanız gerektiğini bilirsiniz. Hata bulmak için , kara kutu testi, beyaz kutu testi ve mutasyon testi tekniklerini kullanabilirsiniz . Hata bulduğunuz sürece, test sürecinizin çalıştığını biliyorsunuzdur!

İlerlemenizi görselleştirmek için, ekibinizin günlük olarak bulduğu hataların sayısını çizin. Eğer grafik aşağı doğru eğilirse, ekibinizin kullandığı teknikleri zaten bilmeyeceksiniz demektir. Elbette, tekniklerinizin aynı olmadığına inanıyorsanız, lütfen Myers'ın kitabını okuyun ve ilkeleri uygulayın.

Şimdi, yeni bir hata düzeltme ekini kaçırmanızın bir eksikliği olabilir ve bir miktar daha test etmeye devam etmenize rağmen böcek bulma oranının büyük oranda artacağı ihtimali vardır. Ancak, tekniklerinizin sağlam olduğuna inanıyorsanız, bu olası değildir.

Basit cevap sisteme bağlı olmasıdır. Bir kalp monitörü için gömülü yazılım veya nükleer bir reaktör için güvenlik izleme araçları yazıyorsanız, standart bir blog oluşturma platformu yazdığınızdan çok daha yüksektir.

Bu gerçekten iyi bir sistem test cihazı için bir sorudur (ve ben bir değilim) ama bir şans vereceğim.

Temel önleminiz test kapsamı olacaktır: Başvurunun ne kadarı gerçekten test edilmiştir (hem birim testiyle hem de işlevsel olarak).

Her potansiyel kullanım senaryosunu (ve bu kullanım senaryosunun parametrelerini) gerçekten kullanılma olasılığına göre değerlendirmelisiniz (bu nedenle son vakaları düşürebilirsiniz), karmaşıklık (böcekleri içermesi daha düşük veya daha zor olması daha az olasıdır) böcek bulmak için), test edilme maliyeti (zaman açısından) ve bu alanda keşfedilirse bir hatanın potansiyel etkisi (bu, nükleer reaktör ve blog platformunun geldiği yer).

Bu değerlendirmeye dayanarak, hangilerinin test edileceğini ve ne kadar ayrıntıyla çalışmanız gerekir. Böyle bir listeye sahip olduğunuzda, ekip (bir ürün yöneticisi / proje yöneticisi / kullanıcı temsilcisi dahil) bu listeye girebilir ve sahip olduğunuz kısıtlamalara dayanarak öncelik atabilir.

Düşünmek için kullanışlı bir teknik, her sürümde test edilen kullanım durumlarını da değiştirebileceğinizdir. Örneğin, kritik olmayan test senaryolarının bir listesi olabilir ve bunların yarısını bir sürümde ve yarısını diğerinde (sonra alternatif) test edebilirsiniz. Bu şekilde, çaba için elde ettiğiniz toplam test kapsamını arttırıyorsunuzdur (gerileme hataları ortaya çıkma riski altında olsa da).

Bu aynı zamanda platform testini de genişletebilir - iki veritabanı arka ucunu (veya birden çok tarayıcı) destekliyorsanız, uygulamanın yarısını bir diğerinde diğer yarısını test edip bir sonraki sürümde değiştirebilirsiniz.

(Sanırım buna striptiz denir ama benden alıntı yapmayın.)

Ve sonra düşünülmesi gereken son şey neyi test ettiğiniz değil, sorunlar keşfedildiğinde gerçekte neyi düzelttiğinizdir. "Tüm hataları düzelt" demek yaygındır, ancak gerçek şu ki zaman baskısı vardır ve tüm hatalar eşit değildir. Yine, tüm ilgili taraflarla düzenli hata önlükleri en iyi yoldur. Bu, özellikle bir hata düzeltmesinin, yeniden test etme ve gerileme testlerinde yapılan ek çalışma, düzeltmenin yararından ağır basabileceği için özellikle müdahaleci olabileceği durumlarda geçerlidir.

Yazılımın kullanımıyla ilgili risk kabul edilebilir bir düzeye indirildiğinde.

"Program testi, hataların varlığını göstermek için kullanılabilir ancak hiçbir zaman onların yokluğunu göstermez!" --Edsger Dijkstra

Herhangi bir test yaparken, otomatik veya başka türlü akılda tutulması gereken bir şey. Artık başka bir böcek bulamadığınızı kanıtlayabilirsiniz, başka bir şey olmadığını kanıtlayabilirsiniz.

Ancak bir kod bölümüne ne kadar çok göz koyarsanız, düzgün çalışması için o kadar güvende olursunuz. Knuth'un bu konudaki optimizasyon teklifine çok benziyor: yanlış şeyleri çok kolay bir şekilde test edebilirsiniz ve gelişiminizdeki yanlış zamanlarda test edebilirsiniz.

Temel olarak, iki büyük alanda ele almak istiyorsunuz:

1. Yazılım, belirtilen gereksinimleri karşıladığını gösteren BDD testlerini geçiyor mu? Bu doğru değilse, yazılım bile yapılamaz.

2. En kritik, karmaşık ve emin olmayan segmentler güven sağlamak için yeterli testlere sahip mi? Bu bir çekirdek döngü veya optimize etmek veya kesmek zorunda kaldığınız bir şeyse: bir test yapın. Eğer karmaşıksa ve çok fazla mantıksal bölünme varsa: üzerine çok fazla test yapın. Test edemiyorsanız veya doğrudan pratikte test etmek için çok derine gömülmüşse: kodun gözden geçirildiğinden ve kodun dolaylı olarak elle test edildiğinden emin olun.

Proje bitinceye kadar beklerseniz, gerçekten çok sayıda test senaryosuna sahip olacaksınız. Sürekli olarak küçük teslimatlara odaklanarak teslim ederseniz, her yinelemede daha az test vakası olur ve her şeyi test edebilirsiniz. Küçük teslimatlar yapamıyorsanız, en yüksek önceliğe göre önceliklendirin ve test edin ve durmanız gerekmeden teste geçin.

Ünite testinden bahsediyorsanız ve TDD (ilk önce testleri yazan) yapıyorsanız, bu sorun değil: sadece özellikler tamamlandığında testi durdurursunuz.

Artımlı TDD'de, başarısız bir sınama yazın, sonra geçmesi için en küçük miktarda kod uygulayın, sonra yeniden yansıtın. Yöntem özellik tamamlanıncaya kadar testleri bu şekilde eklemeye devam edin.

İşte harika bir örnek.

İstatistikçiler de bu konuya baktılar - aslında 1970-80'lerde olduğu gibi. Hataların nasıl keşfedildiğine dair uygun varsayımlar göz önüne alındığında, test verilerinden böcek sayısını tahmin etmeye çalışırlar. Bu daha sonra bir kayıp fonksiyonunun optimize edilmesine dayanarak ne zaman duracağının belirlenmesinde kullanılır. Bunun pratikte nasıl yapılacağına ilişkin R kodu da dahil olmak üzere bu konudaki yazılardan birinin kısa bir tedavisi için örneğin https://rpubs.com/hoehle/17920 ... bakınız .

Elbette bir konu daima hata bulma süreciyle ilgili varsayımlar olacaktır. Örneğin, yukarıdaki tedavide böceklerin birbirlerinden bağımsız olarak keşfedildiği varsayılmaktadır. Pratikte, büyük bir böceğin düzeltilmesi, örneğin, yeni böceklere, vb. Neden olabilir.

Nakliye tarihi geldiğinde. Bir yazılımı test etmenin sonu yok. Ama sonra yine program olarak bilinen bir şey var. İşlevlerinizin çoğunu planlanan zamanda sınamanız ve karşılaştığınız hataları gidermeniz gerekir. Yazılımın mükemmel olduğunu garanti edemezsiniz.

Test edilecek ilk şeyler "mutlu yol", son durumlar ve geçersiz girdiler olacaktır. Birden fazla eşzamanlı kullanıcı olacaksa, kilitleme ve yarış koşulları gibi eşzamanlılık sorunlarını test etmeniz gerekir. Uygulama harici kaynaklar kullanıyorsa, bu kaynaklar kullanılamadığında uygulamanın nasıl davrandığını test etmeniz gerekir. Ondan sonra, kodun kırılmasına ve test edilmesine neden olabilecek şeyleri aramak için kullanabilirsiniz. Tüm bu testler geçtiğinde, daha sonraki testlerin maliyet / fayda oranı artmaya başlar, bu nedenle bu noktada durmanız mantıklıdır.

Her şey bir güven meselesine bağlı. Sistemin yeterince test edildiğinden emin misiniz?

Açıkçası, "güven düzeyi" son derece özneldir, çünkü asla tamamen kesin hissedemezsiniz, ancak yeterince kesindir - ve aradığımız şey budur. Bunun için, genellikle yapılan tanımın tanımı olarak bilinen bir göstergeler listesi oluşturmanız gerekir ve tüm ekibinizin kabul ettiği bir şey olmalıdır.

İşte "Bitti göstergeleri" ile ilgili birkaç test:

• Yapım ve kurulumunuz tamamen otomatikleştirilmiş mi ve tüm testler (birim, gui, entegrasyon) otomatik olarak yapılıyor mu?
• Testlerinizi, kodu yazmak yerine (veya daha önce) yazarken mi yapıyorsunuz?
• Hata bildirmeden büyük kod yeniden yapılandırması yapacak kadar güvende hissediyor musunuz?
• Kod kapsam seviyeniz yeterince yüksek mi?
• Takımında özel bir test cihazı var mı? Sadece sonunda değil tüm gelişim boyunca günlük olarak yer alıyor mu?
• Test cihazınız elle (keşif) başarıya ulaşmadan kırmaya çalıştı mı?

Bu noktaları kontrol edebiliyorsanız, muhtemelen yeterince test yaptığınızı söyleyebilirsiniz.

Asla, bir sistemde test yapmayı asla bitiremeyeceğinizi düşünüyorum .. yönetemeyeceğiniz birçok değişken var.

Ancak, bildiğimiz gibi, "sonsuza dek" test edemezsiniz, bu nedenle sınırın temelde aşağıdakilere bağlı olduğunu düşünüyorum:

• Yazılımın kullanımıyla ilgili risk kabul edilebilir bir düzeye indirildiğinde. (@Graham Lee'nin dediği gibi)
• Sistem kullanıcısı kim? Siz ya da Amerika Birleşik Devletleri Başkanı olabilirsiniz. İlk durumda, bir sorunu çözüp çözmediğiniz ve bunun bittiği için çok fazla umursamıyorsunuz. İkinci durumda, HERHANGİ bir hatanın görünmesini istemezsiniz.
• Müşterinle ilişkiniz nedir? Belki müşteri senin babandır, o yüzden o kadar da kötü değil, ya da belki de büyük bir şirket.
• Sistem kullanıcıları için bir hata ne kadar ciddi? Üçüncü dünya savaşına mı yoksa çirkin bir mesaja mı sebep olacak?

Dağıtıma imza atması gereken insanlar tatmin olduğunda.

veya bazı durumlarda sorumlu tarafların çoğunluğu tatmin edicidir.