Birim, işlevsel, kabul ve entegrasyon testi (ve bahsetmediğim diğer test türleri) arasındaki fark nedir?
Nereye baktığınıza bağlı olarak, biraz farklı cevaplar alırsınız. Konu hakkında çok şey okudum ve işte benim damıtma; Yine, bunlar biraz yünlü ve diğerleri aynı fikirde olmayabilir.
Birim Testleri
En küçük işlevsellik birimini test eder, genellikle bir yöntem/işlev (örneğin, belirli bir duruma sahip bir sınıfa verilen, sınıfta x yönteminin çağrılması y'nin gerçekleşmesine neden olmalıdır). Birim testleri belirli bir özelliğe odaklanmalıdır (örneğin, yığın boşken pop yöntemini çağırmak
InvalidOperationException atmalıdır). Dokunduğu her şey bellekte yapılmalı; bu, test kodunun ve test edilen kodun yapmaması gerektiği anlamına gelir:
Anlaşılması/başlatılması/manipüle edilmesi yavaş/zor olan herhangi bir bağımlılık uygun teknikler kullanılarak sertleştirilmeli/alay edilmeli/ne olursa olsun kullanılmalıdır, böylece kodlama biriminin ne yaptığına, bağımlılıklarının ne yaptığına odaklanabilirsiniz.
Kısacası, birim testleri olabildiğince basit, hata ayıklaması kolay, güvenilir (harici faktörlerin azalması nedeniyle), yürütülmesi hızlı ve programınızın en küçük yapı taşlarının bir araya getirilmeden önce tasarlandığı gibi çalıştığını ispatlamaya yardımcı oluyor. Dikkat, mükemmel bir şekilde yalıtılmış olduklarını ispatlayabilseniz de, kod birimleri birleştiğinde patlayabilir;.
Entegrasyon Testleri
Entegrasyon testleri, kod birimlerini birleştirerek ve sonuçtaki birleşimin doğru çalıştığını test ederek birim testleri oluşturur. Bu, ya bir sistemin içindekileri olabilir ya da yararlı bir şeyler yapmak için birden fazla sistemi bir araya getirebilir. Ayrıca, entegrasyon testlerini birim testlerden ayıran bir başka şey de çevredir. Entegrasyon testleri, iş parçacığı kullanabilir, veritabanına erişebilir veya tüm kodun ve farklı ortam değişikliklerinin doğru çalışmasını sağlamak için gereken her şeyi yapabilir.
Bazı serileştirme kodları oluşturduysanız ve ünite diske dokunmadan doğuşlarını test etmişse, diske yüklerken ve diske kaydederken nasıl çalışacağını nereden biliyorsunuz? Belki de filestleri yıkıp atmayı unutmuşsun. Belki de dosya izinleriniz yanlış ve bellek akışlarını kullanarak innards test ettiniz. Kesin olarak öğrenmenin tek yolu, üretime en yakın ortamı kullanarak 'gerçek için' test etmektir.
En büyük avantaj, ünite testlerinin kablolama kabloları (örneğin A sınıfı beklenmedik şekilde boş bir B örneği alır) ve çevre hataları (tek bir CPU makinemde iyi çalışıyor. meslektaşının 4 çekirdek makinesi testleri geçemez). Temel dezavantajı, entegrasyon testlerinin daha fazla koda değmesi, daha az güvenilir olması, arızaların teşhisi daha zor olması ve testlerin sürdürülmesi daha zor olmasıdır.
Ayrıca, entegrasyon testleri, tam bir özelliğin çalıştığını kanıtlamaz. Kullanıcı programlarımın iç ayrıntılarını umursamıyor olabilir, ama ben yapıyorum!
İşlevsel Testler
İşlevsel testler, belirli bir girişin sonuçlarını spesifikasyona göre karşılaştırarak doğruluğu kontrol etmek için belirli bir özelliği kontrol eder. İşlevsel testler, ara sonuçlarla ya da yan etkilerle, sadece sonuçla ilgilenmez (x yaptıktan sonra, y nesnesinin z durumuna sahip olması umrunda değildir). Bunlar, "Çağırma işlevi Square (x) işlevini 2 döndüren 4 ifadesiyle" olarak belirtmek için yazılmıştır.
Kabul Testleri
Kabul testi iki türe bölünmüş görünmektedir:
Standart kabul testi, uygulamanın işlevselliğinin şartnameye uygun olup olmadığını görmek için tam sistem üzerinde testler yapılmasını (örneğin, web sayfanızı bir web tarayıcısı kullanarak) içerir. Örneğin. msgstr "bir zoom simgesine tıkladığınızda belge görünümünü% 25 oranında büyütmelisiniz." Gerçek bir sonuç sürekliliği yoktur, sadece bir başarılı veya başarısız sonuçtur.
Bunun avantajı, testlerin düz İngilizce olarak tanımlanması ve yazılımın bir bütün olarak özelliklerin eksiksiz olmasını sağlamasıdır. Dezavantajı, test piramidini başka bir seviyeye taşımış olman. Kabul testleri kod dağlarına dokunur, bu nedenle bir başarısızlığın izini sürmek zor olabilir.
Ayrıca, çevik yazılım geliştirmede, kullanıcı kabul testi, geliştirme sırasında yazılımın müşterisi için/müşterisi tarafından yaratılan kullanıcı hikayelerini yansıtmak için testler oluşturmayı içerir. Testler başarılı olursa, yazılımın müşterinin gereksinimlerini karşılaması gerektiği ve hikayelerin eksiksiz olarak kabul edilebileceği anlamına gelir. Bir kabul testi paketi, temel olarak, sistemin kullanıcıları tarafından kullanılan dilde yapılan testleri açıklayan, alana özgü bir dilde yazılmış çalıştırılabilir bir özelliktir.
Sonuç
Hepsi tamamlayıcı. Bazen bir türe odaklanmak veya onları tamamen terk etmek avantajlıdır. Benim için temel fark, bazı testlerin programcı bakış açısıyla konulara bakması, diğerleri ise müşteri/son kullanıcı odağını kullanıyor.
Önemli olan, bu terimlerin meslektaşlarınız için ne anlama geldiğini bilmenizdir. Farklı gruplar, örneğin "uçtan uca" testleri deyince ne anlama geldiklerini biraz farklı tanımlamaları olacaktır.
Google'ın adlandırma sistemine son zamanlarda testleri için rastladım ve daha çok hoşuma gitti - yalnızca Küçük, Orta ve Büyük kullanarak argümanları atladılar. Bir testin hangi kategoriye girdiğine karar vermek için birkaç faktöre bakar - çalışması ne kadar sürer, ağa, veritabanına, dosya sistemine, harici sistemlere vb. Erişir.
Mevcut iş yeriniz için Küçük, Orta ve Büyük arasındaki farkın Google’dan farklı olabileceğini hayal ediyorum.
Ancak, sadece kapsam ile ilgili değil, amaç ile de ilgilidir. Mark'ın testler için farklı bakış açıları hakkındaki noktası; Programcı vs müşteri/son kullanıcı, gerçekten önemlidir.
Martin Fowler'in blog yazısı kodu test etme stratejileri hakkında konuşuyor (özellikle bir mikro hizmetler mimarisinde) ancak çoğu herhangi bir uygulama için geçerli.
Özet slaytından alıntı yapacağım:
- Birim testleri - beklendiği gibi davranıp davranmadıklarını belirlemek için uygulamadaki en küçük test edilebilir yazılım parçalarını kullanın.
- Entegrasyon testleri - arayüz hatalarını tespit etmek için iletişim yollarını ve bileşenler arasındaki etkileşimi doğrulayın.
- Bileşen testleri - kullanılan yazılımın kapsamını test altındaki sistemin bir kısmıyla sınırlandırın, sistemi dahili kod arayüzleri üzerinden manipüle edin ve test altındaki kodu diğer bileşenlerden test etmek için iki katına çıkarın.
- Sözleşme testleri - Tüketici bir servis tarafından beklenen sözleşmeyi karşıladığını iddia ederek harici bir servisin sınırındaki etkileşimleri doğrulayın.
- Uçtan Uca testleri - bir sistemin dış gereklilikleri karşıladığını ve amaçlarını gerçekleştirerek tüm sistemi test ederek uçtan uca doğrulayın.
Birim Testi - Adından da anlaşılacağı gibi, bu yöntem nesne düzeyinde test eder. Tek tek yazılım bileşenleri herhangi bir hata için test edilir. Bu test için program bilgisi gereklidir ve yazılımın amaçlandığı gibi davranıp çalışmadığını kontrol etmek için test kodları oluşturulur.
Fonksiyonel test - Sistemin iç işleyişini bilmeden gerçekleştirilir. Test cihazı, sadece gereksinimleri takip ederek, farklı girdiler sağlayarak ve üretilen çıktıları test ederek sistemi kullanmaya çalışacaktır. Bu test aynı zamanda kapalı kutu testi veya kara kutu olarak da bilinir.
Kabul testleri - Bu, yazılım müşteriye teslim edilmeden önce yapılan son testtir. Geliştirilen yazılımın tüm müşteri gereksinimlerini karşılamasını sağlamak için gerçekleştirilmiştir. İki tür kabul testi vardır - biri geliştirme ekibinin üyeleri tarafından iç kabul testi (Alpha testi) olarak bilinen, diğeri ise müşteri veya son kullanıcı tarafından (Beta testi) olarak gerçekleştirilen testtir.
Entegrasyon Testi - Zaten ünite testine tabi tutulan modüller birbiriyle entegre edilmiştir. Genellikle iki yaklaşım izlenir:
1) Yukarıdan Aşağıya
2) Aşağıdan yukarıya
Bu çok basit.
Birim testi: Bu aslında kodlama bilgisi olan geliştiriciler tarafından yapılan testtir. Bu test kodlama aşamasında yapılır ve beyaz kutu testinin bir parçasıdır. Bir yazılım geliştirme için geldiğinde, birim olarak bilinen kod parçası veya kod dilimleri halinde geliştirilir. Ve bu ünitelerin bireysel testleri, geliştiriciler tarafından yapılan bildirimlerin kapsamı vb.
İşlevsel testler: Bu test, test (QA) aşamasında yapılır ve kara kutu testinin bir parçasıdır. Daha önce yazılan test durumlarının gerçek uygulaması. Bu test aslında test uzmanları tarafından yapılır, sitedeki herhangi bir fonksiyonelliğin gerçek sonucunu bulur ve bu sonucu beklenen sonuçla karşılaştırır. Herhangi bir eşitsizlik buldularsa o zaman bu bir hatadır.
Kabul testi: UAT olarak bilinir. Ve bu aslında test edicinin yanı sıra geliştiriciler, yönetim ekibi, yazar, yazarlar ve bu projede yer alan herkes tarafından yapılır. Projenin sonunda hatasız olarak teslim edilmek üzere hazır olmasını sağlamak.
Entegrasyon testi: Projeyi tamamlamak için kod birimleri (1. maddede açıklanan) birbirleriyle tümleştirilmiştir. Bu kod birimleri farklı kodlama teknolojisinde yazılabilir veya bunlar farklı sürümde olabilir, bu nedenle bu test geliştiriciler tarafından kodun tüm birimlerinin diğerleriyle uyumlu olmasını sağlamak için yapılır ve herhangi bir entegrasyon sorunu yoktur.
Aşırı alaycı ve saf birim testine karşı (nispeten) yeni fikirler:
birim testi: Bir uygulamadaki bireysel modül veya bağımsız bir bileşenin testi birim testi olarak bilinir, birim testi geliştirici tarafından yapılır.
entegrasyon testi: tüm modülleri birleştirmek ve iletişimi ve modüller arasındaki veri akışını doğrulamak için uygulamayı test etmek, bu test geliştiriciler tarafından da yapılmıştır.
funcional test Bir uygulamanın bireysel işlevselliğini kontrol etmek, fonksiyonel test olmak anlamına gelir
kabul testi bu test, derleme uygulamasının müşteri ihtiyacına göre olup olmadığına dair son kullanıcı veya müşteri tarafından yapılır ve müşteri spesifikasyonu kabul testi olarak bilinir.
Bunu size pratik bir örnekle ve hiçbir teoriyle açıklamam:
Bir geliştirici kodu yazar. Henüz bir GUI uygulanmadı. Bu seviyedeki test, fonksiyonların doğru çalıştığını ve veri tiplerinin doğru olduğunu onaylar. Testin bu aşamasına Birim testi denir.
Bir GUI geliştirildiğinde ve bir test cihazına uygulama atandığında, iş gereksinimlerini bir müşteriyle doğrular ve farklı senaryoları yürütür. Buna işlevsel test denir. Burada müşteri gereksinimlerini uygulama akışlarıyla eşleştiriyoruz.
Entegrasyon testi: Diyelim ki uygulamamızın iki modülü var: İK ve Finans. İK modülü daha önce teslim edildi ve test edildi. Artık Finans geliştirildi ve test edilebilir. Birbirine bağlı özellikler şimdi de mevcuttur, bu nedenle, bu aşamada, ikisi arasındaki iletişim noktalarını test edecek ve gereksinimlerde istenen şekilde çalıştıklarını doğrulayacaksınız.
Regresyon testi, yeni bir gelişme veya hata düzeltmeden sonra yapılan önemli bir aşamadır. Amacı daha önce çalışan fonksiyonları doğrulamaktır.