Kara kutu veya beyaz kutu testi - önce hangisini yapıyorsunuz?


14

Kara kutu ve beyaz kutu testinin aynı kişi tarafından yapıldığı çok küçük bir ekipte, test cihazı önce ne yapmalıdır?


1
Bence bu bağlama bağlı. Spesifikasyonları çoğunlukla uygulamayı bitirdiniz ve son testinize başlamak mı istiyorsunuz yoksa geliştirme döngüsü sırasında genellikle istediğiniz zaman mı bahsediyorsunuz? Cevaplarda belirtildiği gibi, uygulayıcılarınız genellikle bu kodlayıcılar iç işleri anladığından ve uygulamadan önce uygulamalarının işlevselliğini iddia etmek istediklerinden whtie kutusu testinizin bir parçası olarak kabul edilebilecek birim testleri yazacaktır.
Chris

Yanıtlar:


11

En doğru olan her neyse.

Ciddi olarak, beyaz kutu testi (yani kodun içini test etmek) ideal olarak, kodu yazan geliştirici tarafından birim testleri ile yapılmalıdır. Birim testleri zamanla ve derleme sürecinin bir parçası olarak oluşturulacaktır, böylece zayıf testçinin zamanını gerektiği gibi çalışmadığını bildiğimiz kodla harcamayız. Birim testi, ekibiniz küçüldükçe daha da önem kazanır - özellikle de sorunları çözmek için bir test uzmanı ordunuz olmadığı için.

Kara kutu testi (yani kullanıcı / sistem arayüzü üzerinden test etme) çoğu testçinin yaptığı şeydir.

Tüm testler, bir işlevin bitmiş ürün için ne kadar kritik olduğuna göre önceliklendirilmelidir. Görev X yapmak için bir araç sağlamaksa ve ürün X yapmıyorsa, bu büyük bir problemdir.


1
Peki, şimdiye kadar okuduğum en iyi cevap.
Chris

5

Siyah

Özellikleri doğrulamak için kara kutu testi. İşler bozulursa beyaz kutu testi gerektiği gibi. Tüm kara kutu testleri başarılı olursa ve kapsama alanı iyiyse, beyaz kutu testi gerekli değildir.


2
Tabii ki, kara kutu testleri önemli bir işlevsellik veya yapılandırma parçasını test etmediği sürece:}
Alan

3
@Alan: aynı argüman beyaz kutu testi için de geçerlidir, dolayısıyla 'kapsamı iyidir' uyarısı
Steven A. Lowe

1
Kabul edildi - Sanırım ifadem iyi kapsama alanı tanımınıza bağlı.
Alan

1
@DocBrown Açıkladığınız şeyin beyaz kutu testi gibi uzaktan nasıl bir şey olduğunu kesinlikle görmüyorum. Whitebox testi, belirli bir uygulamanın şube yollarını takip etmek ve tüm yolları uygulayacak test senaryoları yazmakla ilgilidir. Henüz bir uygulamanız yoksa, tanım başına beyaz kutu testleri yapamazsınız. TDD ve BDD ile o zaman verilen genel şeklin testlerini yazarsınız. Giriş verilerini veya önkoşul durumunu ayarlarsınız, üniteyi tetikler ve çıkış verilerini veya bitiş durumunu veya üçüncü taraf çağrılarını kontrol edersiniz. Bu kara kutu testinin tanımıdır.
Sammi

1
@SamJudge: benim anlayışımla, uygulama kodunun içine baktığınızda ve bu bilgileri çok özel test verileri (daha sonra genel arayüzden geçirilir) tasarlamak için kullandığınızda, bu beyaz kutu testini çağırmayı haklı çıkardı. Sonuç beklendiği gibi değilse böyle bir test başarısız olur. Daha sonra sadece teste bakarsanız, elbette "bu test beyaz bir kutu (veya kara kutu) yaklaşımı ile üretildi" diyemeyebilirsiniz.
Doc Brown

3

Siyah kutu.

Beyaz kutu bileşenleri genellikle kara kutu bileşenlerine bağlıdır, bu yüzden önce kara kutuyu test etmek ve daha sonra beyaz kutuya geçmek istiyorum.


2
"Kara kutu bileşenleri" ve "beyaz kutu bileşenleri" ile ne demek istediğinizden emin değilim - bana sadece "bileşenler" (altta yatan kod veya mimarinin bilgisi ile veya bilgisi olmadan test edilebilir)
Alan

Burada önerdiğiniz "bağımlı" ilişkiyi anlamıyorum. Beyaz siyah ve siyah kutu bileşenler değildir, daha çok Alan'dan bahsedildiği gibi herhangi bir bileşeni test etme stilidir. Fark, söz konusu bileşeni test etmek için alınan yaklaşımdadır.
Chris

2

İşlerin iyi çalıştığından emin olmak için önce bir kodlayıcı / geliştirici olarak beyaz test düşüncesini yaparsınız. Daha sonra kara kutu testi genellikle programın iç yapısını düşünmeden son kullanıcı gibi düşünmeye çalışıyorsunuz. Bazen siyah bir test yapsanız bile bir kodlayıcı / geliştirici gibi düşünmeniz gerekir, çünkü başka bir kişi tarafından yazılan dahili bir modülü test ediyor olabilirsiniz ve koda erişiminiz yoktur.


2

İyi bir test döngüsüne sahip olmak istiyorsanız, Her ikisini birden yapan farklı kişilerin olması gerekir :

  • Ağırlıklı olarak beyaz kutu testine odaklanan bir geliştirici, kodda son zamanlarda neyin değiştiğini, hangi alanların daha karmaşık (ve dolayısıyla kırılması muhtemel), vb.

  • Öte yandan, kara kutu testine odaklanan bir KG test cihazı, son kullanıcı gibi testlere daha kolay yaklaşabilir. Kodun herhangi bir iç bilgisi olmadan, yeni bir yaklaşım alabilirler ve çözümün farklı bölümlerinin nasıl uygulandığına dair bilgi sahibi olmazlar. Geliştiricinin gözden kaçırmış olabileceği hataları veya yanlışlıkla uygulamanın diğer alanlarını bozan kod değişikliklerinden kaynaklanan gerilemeleri yakalarlar.

Sorunuzu cevaplamak için önce beyaz kutu testi yapılmalıdır. Ancak etkili olmasını istiyorsanız, kara kutu testini yapan farklı bir kişiye sahip olmanız gerekir.


1

Kara kutu testi ile başlamak, sonra ne yaptığımı anlamak ve neler olduğunu analiz etmek için kod kapsama bilgilerini veya hata ayıklayıcıyı kullanmak istiyorum.

Ama asıl cevap duruma bağlı . API testi yapıyorum, ancak daha sonra benim hedefim bazı büyük uçtan uca senaryolara bakmak için daha erken (hatta ilk cevher) koda dalış.


1

Önce Kara Kutu testi söyleyebilirim , çünkü TDD'nin bir savunucusu olarak, testler kod (veya kutu) zaten var olmadan önce yazılır :)

White Box testi (anladığım kadarıyla), hata ayıklama zihniyetinde daha kullanışlıdır.


-1, TDD olan beyaz kutu testi. TDD'de, bir sonraki testi yazmak için teste dahil olan kodun ne yaptığını (ve ne yapmadığını) bilmek önemlidir. Kara kutu testi, kod hakkında hiçbir fikri olmayan bir kişinin (bir test cihazı, nasıl kod yazacağını bile bilmesi gerekmeyen biri ) testleri tasarladığı anlamına gelir.
Doc Brown

1
O zaman TDD'yi aynı şekilde uygulamıyoruz. TDD benim için bir sınıfın / fonksiyonun özelliklerini uygulamakla ilgilidir: testler, sınıfın / fonksiyonun belirtildiği gibi davrandığını kontrol etmek için yazılır, ancak bu spesifikasyonlar desteklendiği sürece kodun perde arkasında nasıl davrandığını daha az umursabilir ... bu da testlerin fonksiyonellikten önce yazıldığı göz önüne alındığında gereklidir.
Matthieu M.

1

Kara kutu testi, çünkü kod var olmadan önce testler yazıyorsunuz. Test cihazının, küçük bir ekipte verimli olabilmesi için geliştirici yazma koduna paralel olarak zaman alıcı otomatik testler geliştirmesi gerekir.

Kod zaten yazıldıysa, beyninizi gerçek kodla karıştırmadan önce biraz beyin fırtınası yaptığınızdan emin olmak için kara kutu bakış açısından test kapsamını çizmek için biraz zaman harcamanızı öneririm. Bununla birlikte, riskli alanlar hakkında fikir edinmek ve daha önce beyin fırtınası yaptığınız testlere öncelik vermek (ve üzerinde düşünülen yeni testlerle onları artırmak için) kodun karmaşık veya şüpheli görünen bölümlerine bakmak).


0

Ne. Right BICEP'imi kullanarak aklınıza gelen sipariş ne olursa olsun DOĞRU sınır koşullarını göz önünde bulundurarak iyi testler yazmaya çalışıyorum . Bunların her ikisi de Pragmatik Birim Testinde önerilen kısaltmalardır .

Amacım, önce hangi rengin yazacağına değil, iyi testler yazmaya odaklanmak.


'Beyaz' ve 'siyah' birim test terimleri değildir, bu yüzden elbette bunun için endişelenmiyorsunuz. Ünite testleri fiili beyaz kutudur.
Ethel Evans

@Ethel Evans: Tanımı gereği beyaz kutu testleri değiller. Birim testlerin büyük çoğunluğu beyaz kutu testleridir, ancak bu bir zorunluluk değildir. Girdi alanlarını bir işlevin çıktı aralıklarıyla eşleştiren testler birim testlerdir, ancak uygulamanın ayrıntılarını bilmeleri gerekmez.
Steven Evers

0

İlk önce beyaz kutu testi yapın .

İkinci kara kutu testi için gidin.

> Kara Kutu Testi

I. Test cihazı, Metin kutusu, Radyo düğmesi, liste kutusu, Komut düğmesi, vb. Gibi uygulamanın işlevselliğini kontrol etmelidir.

II. Test cihazı, uygulamanın logo, Görüntü, yazım, vb.

III. Test cihazı uygulamanın tüm akışını kontrol etmelidir.

Not: Pozitif ve Negatif koşulları kontrol etmek için.

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.