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ıtmam; yine, bunlar biraz yünlü ve diğerleri aynı fikirde olmayabilir.
Birim Testleri
Genellikle bir yöntem / işlev olan en küçük işlevsellik birimini test eder (örneğin, belirli bir duruma sahip bir sınıf verildiğinde, 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 bir atmalıdır InvalidOperationException). Dokunduğu her şey bellekte yapılmalıdır; bu, test kodunun ve test edilen kodun:
- (Önemsiz) ortak çalışanlara çağrı yapın
- Ağa erişin
- Bir veritabanına basın
- Dosya sistemini kullanın
- Bir iş parçacığını döndür
- vb.
Yavaş / anlaşılması / başlatılması / manipüle edilmesi zor olan her türlü bağımlılık, uygun teknikler kullanılarak kesilmeli / alay edilmeli / ne olursa olsun, bağımlılıklarının ne yaptığına değil, kod biriminin ne yaptığına odaklanabilirsiniz.
Kısacası, birim testleri olabildiğince basit, hata ayıklaması kolay, güvenilir (azaltılmış dış etkenler nedeniyle), hızlı bir şekilde yürütülür ve programınızın en küçük yapı taşlarının bir araya getirilmeden önce istendiği gibi çalıştığını kanıtlamaya yardımcı olur. Uyarı, tek başına mükemmel bir şekilde çalıştıklarını kanıtlayabilmenize rağmen, kod birimleri birleştiğinde patlayabilir ve bu da bizi ...
Entegrasyon Testleri
Entegrasyon testleri, kod birimlerini birleştirerek ve ortaya çıkan kombinasyonun doğru çalışıp çalışmadığını test ederek birim testleri üzerine kuruludur. Bu, bir sistemin iç kısımları olabilir veya yararlı bir şey yapmak için birden fazla sistemi bir araya getirebilir. Ayrıca, entegrasyon testlerini birim testlerden ayıran başka bir şey de ortamdır. Entegrasyon testleri, tüm kodların ve farklı ortam değişikliklerinin doğru bir şekilde çalışmasını sağlamak için iş parçacıkları kullanabilir, veritabanına erişebilir veya gereken her şeyi yapabilir .
Biraz serileştirme kodu oluşturduysanız ve ünite, disklerini diske dokunmadan test ettiyseniz, yükleme ve diske kaydettiğinizde çalışacağını nasıl anlarsınız? Belki de akarsuları yıkayıp atmayı unuttun. Belki dosya izinleriniz yanlış ve bellek akışlarında kullanarak doğası test ettiniz. Kesin olarak öğrenmenin tek yolu, üretime en yakın ortamı kullanarak 'gerçek için' test etmektir.
Ana avantajı, birim testlerinin kablolama hataları (örneğin, A sınıfı bir örnek beklenmedik bir şekilde B boş bir örneği alır) ve ortam hataları (tek CPU makinemde iyi çalışır, ancak benim meslektaşının 4 çekirdekli makinesi testleri geçemez). Ana dezavantaj, entegrasyon testlerinin daha fazla koda dokunması, daha az güvenilir olması, arızaların teşhis edilmesinin ve testlerin sürdürülmesinin daha zor olmasıdır.
Ayrıca, entegrasyon testleri, tam bir özelliğin çalıştığını kanıtlamak zorunda değildir. Kullanıcı programlarımın iç detaylarını umursamayabilir, ama ben!
Fonksiyonel Testler
Fonksiyonel testler, belirli bir girişin sonuçlarını spesifikasyonla karşılaştırarak belirli bir özelliği doğruluğunu kontrol eder. İşlevsel testler, ara sonuçlar veya yan etkilerle kendilerini ilgilendirmez, sadece sonuç (x'i yaptıktan sonra y nesnesinin z durumuna sahip olması umurumda değildir). Bunlar, "Kare (x) işlevinin 2 döndürme 4 bağımsız değişkeniyle çağrılması" gibi belirtimin bir kısmını test etmek için yazılmıştır.
Kabul testleri
Kabul testi iki türe ayrılmıştır:
Standart kabul testi, uygulamanın işlevselliğinin teknik özellikleri karşılayıp karşılamadığını görmek için tüm sistemde testler yapılmasını içerir (örn. Web sayfanızı bir web tarayıcısı aracılığıyla kullanma). Örneğin, bir yakınlaştırma simgesine tıklamak belge görünümünü% 25 büyütmelidir. " Sonuçların gerçek bir sürekliliği yoktur, sadece başarılı veya başarısız bir sonuç vardır.
Avantajı, testlerin basit İngilizce olarak tanımlanması ve yazılımın bir bütün olarak özelliklerin eksiksiz olmasını sağlar. Dezavantajı ise test piramidinde bir seviye daha ilerletmiş olmanızdır. Kabul testleri kod dağlarına dokunur, bu nedenle bir arızayı izlemek zor olabilir.
Ayrıca, çevik yazılım geliştirmede, kullanıcı kabul testi, geliştirme sırasında yazılım müşterisi tarafından / müşterisi için oluşturulan kullanıcı hikayelerini yansıtmak için testler oluşturulmasını içerir. Testler başarılı olursa, yazılımın müşterinin gereksinimlerini karşılaması gerektiği ve hikayelerin tamamlandığı düşünülebilir. Kabul sınama paketi, temel olarak, sistem kullanıcıları tarafından kullanılan dilde sınamaları tanımlayan, etki alanına özgü bir dilde yazılmış yürütülebilir bir belirtimdir.
Sonuç
Hepsi tamamlayıcı. Bazen bir türe odaklanmak veya tamamen kaçınmak avantajlıdır. Benim için temel fark, bazı testlerin bir şeye programcının bakış açısıyla bakması, diğerlerinin ise müşteri / son kullanıcı odağı kullanmasıdır.