Otomatik birim testi, entegrasyon testi veya kabul testi [kapalı]


29

TDD ve ünite testleri şu an için en büyük rave gibi görünüyor. Ancak diğer otomatik test yöntemleriyle karşılaştırıldığında bu gerçekten faydalı mı?

Sezgisel olarak, otomatik entegrasyon testinin birim testinden çok daha faydalı olduğunu tahmin ediyorum. Tecrübelerime göre, çoğu hata modüller arasındaki etkileşimin içinde görünüyor ve her bir birimin fiili (olağan sınırlı) mantığından çok fazla değil. Ayrıca, modüller arasındaki arayüzler değiştiği için (ve önceden ve sonrası koşullar değişti) de gerileme yaşandı.

Bir şeyi yanlış mı anlıyorum, yoksa birim testi entegrasyon testine kıyasla neden daha fazla odaklanıyor? Bunun nedeni, entegrasyon testinin sahip olduğunuz bir şey olduğu ve ünite testlerinin geliştiriciler olarak uygulamak için öğrenmemiz gereken bir sonraki şey olduğu varsayılmasıdır.

Veya belki de ünite testi, otomatikleştirmenin karmaşıklığına kıyasla en yüksek kazancı sağlar mı?

Otomatik birim testi, otomatik entegrasyon testi ve otomatik kabul testi konusunda deneyiminiz ve deneyiminizde en yüksek yatırım getirisini elde ettiğiniz şey nedir? ve neden?

Bir sonraki projenizde otomatik hale getirmek için yalnızca bir test yöntemi seçmeniz gerekirse, hangisi olurdu?

Şimdiden teşekkürler.


JB Rainsberger'in Entegrasyon Testleri Are A Scam'e gecikmiş bir bağlantı eklemek istiyorum . Entegrasyon testlerinin sahte bir ekonomi olmasının birçok nedenini vurgulamaktadır.
Tim


6
Bu, üç yıl önce sorulduğunda bu sitede mükemmel bir soruyu kapatmanın başka bir örneği! Kuralların değiştiği bir topluma katkıda bulunmak gerçekten can sıkıcıdır ve tüm eski şeyleri atıyorsunuz!
Bjarke Freund-Hansen

Yanıtlar:


34

Birim testlerini son derece yararlı kılan önemli bir faktör hızlı geribildirimdir .

Uygulamanızı, entegrasyon / Sistem / fonksiyonel testlerle tamamen kapladığınızda (çoğu geliştirme mağazasında gerçeklikten uzak, zaten ideal bir durumdur) ne olacağını düşünün. Bunlar genellikle özel bir test ekibi tarafından yönetilir.

  • SCM deposunda değişiklik yapmak
  • bir süre (muhtemelen günler) sonra, test görevlileri yeni bir dahili sürüm alırlar ve test etmeye başlarlar,
  • bir hata buldular ve bir hata raporu hazırladılar,
  • (ideal durumda) birisi hata raporunu size geri atar.

Bunların hepsi günler hatta haftalar sürebilir. Bu zamana kadar zaten başka işler üzerinde çalışıyordunuz, bu nedenle aklınızda daha önce yazılmış olan kodun dakika detaylarına sahip değilsiniz. Dahası, tipik olarak, hatanın gerçekte nerede olduğuna dair doğrudan bir kanıtınız bile yoktur, bu yüzden hatayı bulmanız ve düzeltmeniz oldukça zaman alır.

Oysa birim testinde (TDD)

  • sen bir test yaz
  • testi yerine getirmek için bazı kodlar yazarsanız,
  • Test hala başarısız oluyor.
  • koduna bakarsınız ve genellikle birkaç saniye içinde "ayy" deneyimi yaşarsınız ("ayy, bu durumu kontrol etmeyi unuttum!" gibi), sonra
  • derhal hatayı düzeltmek.

Bütün bunlar birkaç dakika içinde olur .

Bu, entegrasyon / sistem testlerinin faydalı olmadığını söylemek değildir; sadece farklı amaçlara hizmet ediyorlar. İyi yazılmış birim testleriyle, kodları bulmak ve düzeltmek için çok daha pahalı olan entegrasyon aşamasına gelmeden önce koddaki hataların büyük bir bölümünü yakalayabilirsiniz . Birim testlerinde yakalanması zor ya da imkansız olan bu tür böcekleri yakalamak için entegrasyon testlerine ihtiyaç vardır. Ancak, benim deneyimlerime göre bunlar daha nadirdir; Gördüğüm hataların çoğu, bir yöntem içinde bir yerde bazı basit veya hatta önemsiz ihmallerden kaynaklanıyor.

Birim testinin ayrıca arabirimlerinizi kullanılabilirlik / güvenlik vb. İçin test ettiğini ve böylece tasarımınızı ve API'lerinizi geliştirmek için hayati önem taşıyan geri bildirimler sağladığından bahsetmiyorum bile. Hangi IMHO, modül / susbystem entegrasyon hataları olasılığını önemli ölçüde azaltabilir: API ne kadar kolay ve temizse, yanlış anlama veya ihmal etme olasılığı o kadar az olur.

Otomatik birim testi, otomatik entegrasyon testi ve otomatik kabul testi konusunda deneyiminiz ve deneyiminizde en yüksek yatırım getirisini elde ettiğiniz şey nedir? ve neden?

Yatırım getirisi birçok faktöre bağlıdır, muhtemelen en önemlisi projenizin yeşil alan mı yoksa eski mi olduğu. Yeşil alan gelişimi ile tavsiyem (ve şu ana kadarki deneyimlerim) TDD tarzını en baştan test etmek. Bunun bu durumda en uygun maliyetli yöntem olduğuna eminim.

Bununla birlikte, eski bir projede, yeterli birim test kapsamı oluşturmak, fayda sağlamak için çok yavaş olacak büyük bir girişimdir. Mümkünse, UI üzerinden sistem / işlev testleriyle en önemli işlevleri kapsamaya çalışmak daha etkilidir. (otomatik GUI uygulamaları yavaş yavaş geliştirilse de, masaüstü GUI uygulamalarının GUI üzerinden otomatik olarak test edilmesi zor olabilir ...). Bu size hızlı bir şekilde kaba ama etkili bir güvenlik ağı sağlar. Ardından, uygulamanın en kritik kısımları etrafında kademeli olarak ünite testleri yapmaya başlayabilirsiniz.

Bir sonraki projenizde otomatik hale getirmek için yalnızca bir test yöntemi seçmeniz gerekirse, hangisi olurdu?

Bu teorik bir soru ve onu anlamsız buluyorum. Her türlü test, iyi bir SW mühendisinin araç kutusunda kullanımına sahiptir ve bunların hepsinin, yeri doldurulamaz oldukları senaryoları vardır.


2
Birim testleri için "hızlı geri besleme" için +1. Ayrıca, Sürekli Entegrasyon sunucusunda taahhüt sonrası çalışmak için çok kullanışlıdır.
Frank Shearar

1
“Her türlü test iyi bir SW mühendisinin araç kutusunda kullanılıyor ve hepsinin yeri doldurulamaz senaryoları var.” - Keşke bunun için birkaç defa oy kullanabilseydim! Sadece bir ideal test aracı / yöntemi bulabileceklerini ve her yere uygulayabileceklerini düşünen insanlar beni yıkıyor.
ptyx

8

Tüm test türleri çok önemlidir ve sistemin farklı yönlerinin spesifik olmasını sağlar. Yani geriye doğru çalışmak için, "Bir tür test seçmek zorunda olsaydım ..." yapmazdım. Ünite testi bana entegrasyon testinden veya bir kişi tarafından etkileşimli testten farklı geribildirim sağlar.

İşte yaptığımız testin türü / avantajı:

  • Birim testi - birimlerin beklediğimiz gibi çalışmasını sağlar. Her arayüz için hem sağlayıcıyı hem de tüketici sözleşmelerini test ediyoruz - ve bu otomatikleştirilmesi oldukça kolaydır. Ayrıca sınır koşullarımızı vb. Kontrol ediyoruz.
  • Entegrasyon testi - ünitelerin birlikte çalışmasını sağlar. Bu esas olarak tasarımımızı test etmektir. Burada bir şey kırılırsa, bir daha olmayacağından emin olmak için birim testlerimizi ayarlamamız gerekir.
  • Sistem testi - sistemin gereksinimleri / teknik özellikleri karşılamasını sağlar. Genellikle insanlar bu tür testleri yapar.
  • Kabul testi - müşteri, nihai ürünün reklamı yapılan şeyi yaptığını doğrulamak için yapar.

İsteğe bağlı, ancak önerilen testler:

  • Kullanıcı deneyimi testi: Sistem testlerinden iyi bir geri bildirim alırken, müşteriden bazı ön sürümlerin önizlemesini yapan kişilerin olması çok geç olmadan bir şeyi değiştirmemiz gerekip gerekmediğinin belirlenmesinde gerçekten yardımcı olabilir.

Birim Testinin neden entegrasyon testlerine göre bir üstünlüğü olduğunu anlamak için, kapsamlı olmanız gereken büyük testlerin sırasını anlamanız gerekir. Ünite A için olası her sonuç için, bir test yapılması gerekir. Ünite B için aynıdır. Şimdi, ikisi de daha eksiksiz bir çözüm için birlikte çalışırsa, testlerin sayısı birleştiricidir. Kısacası, ünite A ile ünite B arasındaki etkileşimin her permütasyonunu test etmek için A * B testlerine ihtiyacınız vardır. Ünite C'yi ekleyin, üçlünün test sayısı A * B * C olacaktır.

Arayüzler ve nesne sınırları kavramının çok önemli olduğu yer burasıdır. Arayüzler belirli bir sözleşmeyi temsil eder. Bir arabirimin uygulayıcısı , belirli bir şekilde davranacağını kabul eder. Benzer şekilde, bir ara yüzün bir tüketicisi , uygulamayı belirli bir şekilde kullanacağını kabul eder. Bir arabirim uygulayan her sınıfı toplayan bir test yazarak, her uygulamanın arabirim sözleşmelerini izlediğini kolayca test edebilirsiniz. Bu denklemin yarısı. Diğer yarısı, tüketici tarafını test etmektir - ki sahte nesneler oynamak için buraya gelir. Sahte, etkileşimlerin her zaman spesifik olmasını sağlamak için yapılandırılmıştır. Bu noktada, gereken tek şey uygulayıcı / tüketici sözleşmelerini doğru yaptığımızdan emin olmak için birkaç entegrasyon testidir.


"Sistem testi - sistemin gereksinimleri / özellikleri karşılamasını sağlar Genellikle insanlar bu tür testleri yapar". Sistem / aka fonksiyonel / aka "uçtan uca" / aka yüksek seviye entegrasyon testleri de otomasyon için iyidir.
MiFreidgeim SO-stop kötülük olmak

3

Bunlar farklı amaçlara sahip farklı araçlardır:

  • Birim testi bir tasarım aracıdır (TDD) ve yeniden yapılandırma için neredeyse ön şarttır.

  • Entegrasyon testleri, projenin ilerleyişini görselleştirmek için harika ve aynı zamanda regresyon hatalarını önlemek için de harika.

Hatırlanması gereken nokta, entegrasyon testleriyle gerçekten tasarım yapamayacağınız ve birim testlerle ilgili regresyonları bulamayacağınızdır.


@ entegrasyon testleriyle gerçekten tasarım yapamazsınız ve birim testlerle ilgili regresyonları bulamazsınız. Kesinlikle!
Chankey Pathak

Birim testleri, yeniden yerleştirmenin neden olduğu gerilemeleri bulabilir, örneğin değiştirilmiş paylaşılan yardımcı yöntem. Entegrasyon testleri bunun için çok daha iyidir.
StuperUser

Entegrasyon testleriyle ilgili ikinci nokta "sistem / fonksiyonel" (aka "uçtan uca") testleridir
MiFreidgeim SO-stop kötü olma

Tamamen kabul etti; benzer bir nokta birkaç yıl önce Steve Sanderson tarafından da yapıldı. Buraya biraz tamamlayıcı düşünceler için blog.stevensanderson.com/2009/08/24/… adresindeki 2009 blog yazısındaki "Hedef - En Güçlü Teknik" tablosuna bakın .
Mark A. Fitzgerald,

1

Selenium'u akıl sağlığı kontrolleri için yoğun kullandım .

Büyük bir web yayıncısında, yeni bir sürüm yayınlandığında, genellikle sitelerin tüm ailelerini ziyaret etmek ve test senaryosuna göre her şeyin yolunda olduğundan emin olmak yaklaşık bir veya üç saat sürdü. Selenyum ile, testi otomatikleştirip birçok makineye ve tarayıcıya dağıttık. Şu anda, test komut dosyaları çalıştırıldığında, otomatik olarak aynı şeyi yapmak VE güzel bir rapor tükürmek için yaklaşık 10 dakika 3 PC alır.

Selenyum hakkındaki en iyi şey, onu XUnit, TestNG veya MSTest gibi ünite test çerçevelerine bağlayabilmenizdir.

Tecrübelerime göre, bu çok değerli bir şeydi, ancak böyle bir şeyin kurulması projenize ve ekibinize gerçekten bağlı, bu nedenle yatırım getirisi kesinlikle değişecek.


1

En iyi yatırım getirisi, genellikle bu tür bir hatayı bulan en erken testtir.

Birim testi, yalnızca bir yöntemde veya bir bileşende bulunan hataların çoğunu bulmalıdır. Genellikle bir dakika içinde çözülebilen ve toplam geri dönüş süreleri bir saatten az olan böcekler bulur. ÇOK ucuz testler, ÇOK ucuz böcek bulmak ve düzeltmek için! Bu hatalar entegrasyon testine girdiyse, geri dönüş bir güne daha çok benzeyebilirdi (test çalışmaları genellikle her gece gerçekleşir), hatanın başka bir hata tarafından tıkanmadığını varsayarak; Artı, ilk buggy koduna karşı başka bir kod yazıldığı için daha fazla hata ortaya çıkması muhtemeldir; artı herhangi bir yeniden tasarım daha fazla kod parçasını etkileyecektir. Ayrıca, entegrasyon testi tamamlanmadan önce daha fazla hata yapmak, daha fazla test çalışması yapmak zorunda kalmanın anlamına gelir. Zayıf birim testi genellikle uzun, zorlu, pahalıTest entegrasyon döngüleri. Ünite testinin atlanması geliştirme süresini yarıya indirebilir, ancak test en az 3 ila 4 kez sürecek, tüm proje uzunluğu iki katına çıkacak ve ünite IME test etmenize göre daha düşük kaliteye sahip olacaksınız.

Entegrasyon testi genellikle entegrasyon hatalarını bulabilen en eski gerçek testlerdir (inceleme süreçleri yazılım yazılmadan önce veya kodun test edilmesinden önce bazı hataları bulabilmesine rağmen). Yazılımı kullanıcıya göstermeye başlamadan veya piyasaya sürmeden önce bu hataları bulmak istiyorsunuz, çünkü hataları son anda düzeltmek (veya sıcak onarım!) Çok pahalı. Düzeltmek için daha ucuz olacakları zaman, bu hataları daha önce bulamazsınız, çünkü entegrasyon için birden fazla çalışma bileşenine ihtiyacınız vardır (tanım gereği). Etkileşen parçalarla (küçük yazım hataları gibi) ilgisi olmayan hataların, daha ilginç testlere bile başlanmadan önce çözülmesi gerektiğinde entegrasyon testi yavaşlar.

Kullanıcı kabul testi, yazılımın müşterinin istediğini yapmasını sağlar (müşteri her zaman umarım dahil olmuş olsa da, proje sonunda beklentiler ve gerçek yazılım arasında büyük bir boşluk bulma riskini azaltmak için - ÇOK pahalı !). Testin bu aşamasına geldiğinizde, ürününüzdeki hataların çoğunun, en azından teknik özelliklere kıyasla, zaten bulunduğuna gerçekten inanmalısınız. Kullanıcı kabul testi, ürünün spesifikasyonlara göre hiçbir hata olmadığından emin olmaktan ziyade, müşterinin ihtiyaçlarına uygun olduğundan emin olmakla ilgilidir.

Sadece bir test türünü otomatikleştireceksem, birim testi olurdu. Entegrasyon testleri manuel olarak yapılabilir ve bu şekilde birçok büyük şirket tarafından yıllarca yapılmıştır. Bilgisayarda tekrar tekrar yapılabilecek işleri el ile yapmak daha fazla zaman alır ve çoğu proje için sıkıcı ve hataya açık olmaktan ziyade çok daha pahalıdır, ancak yapılabilir. Kullanıcı kabul testleri çoğu zaman el ile yapılır çünkü kullanıcılar çoğu zaman neye önem verdiklerini sınarken testlerini nasıl otomatikleştireceğini bilmiyorlar. Ünite testleri otomatikleştirilmelidir. Tüm birim testlerini talep üzerine birkaç saniyede bir, birkaç saniyede bir yapabilmeniz gerekir. İnsanlar sadece manuel testlerle bile yaklaşamıyorlar. Ünite testlerinin kodda olduğunu ve kodları çağırmadan, yani otomatikleştirmeden gerçekleştirilemeyeceklerinden bahsetmeyin.

Akılda tutulması gereken bir şey, bu testçiler için değil, öncelikle geliştiriciler için bir forum olmasıdır. Entegrasyon testi öncelikle test yapanlar tarafından uygulanır. Birim testi geliştiriciler tarafından uygulanır. Doğal olarak, geliştiriciler ünite testi hakkında diğer test türlerinden daha fazla konuşuyor. Bu, diğer testlerin önemli olduğunu düşünmedikleri anlamına gelmez. Bu sadece aslında yapmadıkları anlamına gelir (ya da daha az sıklıkta yaparlar).


Özellikle bu son paragraf için teşekkürler, bunu düşünmedim.
Bjarke Freund-Hansen

Bilginize, okuduğunuzdan beri cevabı güncelledim - farkettim ki asıl soruyu yeterince yakından okumadım
Ethel Evans

@EthelEvans, yeni testler için birim test öncelikleri konusundaki sebepleriniz doğru. Test kapsamı otomatikleştirilmeden yazılan eski projeler için, sistem / aka fonksiyonel / aka yüksek seviye entegrasyon testleri en önemlisidir. Programmers.stackexchange.com/a/39370/31574 yanıtının son bölümüne bakın .
MiFreidgeim SO-stop kötülük olmak

@MichaelFreidgeim, sonuçta arayüzlerin ne kadar kararlı olduğuna bağlı. Üst düzey testlerin otomatikleştirilmesi, güncelliğini yitirirse hızlı bir şekilde engelleyici bakım maliyetlerine neden olabilir. Bu durumda, daha düşük otomasyon, daha istikrarlı bir yapı oluşturmak ve E2E ve entegrasyon testleri için keşif testlerini (muhtemelen oturum veya kontrol listesi tabanlı) kullanmak için iğrenç otomasyon bakım maliyetlerinin ortaya çıkmasını önlemek için keşif testi kullanmaktadır. Yine de tüm eski projeler istikrarlı arayüzlere sahip değildir - özellikle de yeniden yapılandırılmışlarsa veya agresif bir şekilde yeniden yapılandırılmışlarsa.
Ethel Evans,

1

Bu senaryoda kabul testleri kral gibi hissediyorum.

Bir taahhüt kabul testlerini ihlal ederse, çözülmesi gerekir.

Kabul testleri, yazılımınızın nerede olduğunu gösterir, birim testleri yapmaz.

Bu nedenle, birim testleri çok yanlış bir güvenlik hissi sağlayabilir.


0

Sorun, neyin otomatik olduğu ve hızlı bir şekilde çalıştırılabileceği kadar önemli olan şey değil.

Birim testleri, küçük bir bileşenin belirli bir amaç için uygun olup olmadığını ve tipik olarak küçük ve hızlı çalışması olup olmadığını gösterir. Küçük olmak, genellikle otomatikleştirmek için oldukça kolaydır.

Entegrasyon testleri, bileşenlerin birlikte çalışıp çalışmadığını gösterir. Genellikle daha büyüktürler ve otomatikleştirmeleri kolay olmayabilir. Koşmaları daha uzun sürebilir. Onları otomatik olarak çalıştırabilmenin değeri var, ama bu daha büyük bir iş ve zaten sık sık çalıştırılmayacak.

Kabul testleri bir projenin kabul edilebilir olup olmadığını gösterir. Bu normalde tamamen otomatik hale getirmek imkansızdır (otomatik testler bir rol oynamasına rağmen), çünkü normalde kaynak kodun kendisinden daha az karmaşık olan resmi bir konuda kesin ve eksiksiz gereklilikleri belirlemek imkansızdır. Kabul testi genellikle sistemde bir şeyler yapan ve normalde kısmen öznel olan sonuçların her bakımdan tatmin edici olduğunu gözlemleyen potansiyel kullanıcıları içerir. Kabul testi genellikle bir kez yapıldığından (farklı müşteriler normalde kendi ayrı kabul testlerini yapmak isteyeceklerdir) gerçekten de otomatikleşmeye değmez.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.