Birim testleri, entegrasyon testleri, duman testleri ve regresyon testleri nelerdir?

Birim testleri, entegrasyon testleri, duman testleri ve regresyon testleri nelerdir? Aralarındaki farklar nelerdir ve her biri için hangi araçları kullanabilirim?

Örneğin, birim testi ve entegrasyon testi için JUnit ve NUnit kullanıyorum . Son iki, duman testi veya regresyon testi için herhangi bir araç var mı?

• Birim testi : Bir sınıfın tek yönteminin sözleşmesinin bir noktasını belirtin ve test edin. Bunun çok dar ve iyi tanımlanmış bir kapsamı olmalıdır. Dış dünyaya karmaşık bağımlılıklar ve etkileşimler saplanır veya alay edilir .

• Entegrasyon testi : Birden çok alt sistemin doğru çalışıp çalışmadığını test edin. Burada, iki sınıf arasındaki entegrasyonu test etmekten, üretim ortamıyla entegrasyonu test etmeye kadar bir spektrum vardır.

• Duman testi ( akıl sağlığı kontrolü olarak da bilinir ) : Test edilen sistem çağrıldığında normal olarak geri döndüğünü ve patlamadığını kontrol ettiğimiz basit bir entegrasyon testi.

  • Duman testi, bir devreye güç verildiğinde ilk testin yapıldığı elektronikte bir benzetmedir (sigara içiyorsa, kötü!) ...
  • ... ve görünüşe göre , bir boru sisteminin tam anlamıyla dumanla doldurulduğu ve daha sonra görsel olarak kontrol edildiği sıhhi tesisatla . Bir şey sigara içerse, sistem sızdırıyor.

• Regresyon testi : Bir hata giderildiğinde yazılan test. Bu hatanın tekrarlanmamasını sağlar. Tam adı "regresyon dışı test" tir. Ayrıca, uygulamanın aynı sonucu verdiğinden emin olmak için bir uygulamayı değiştirmeden önce yapılan bir test olabilir.

Buna, ekleyeceğim:

• Kabul testi : Bir özellik veya kullanım senaryosunun doğru bir şekilde uygulandığını test edin. Bir entegrasyon testine benzer, ancak ilgili bileşenlerden ziyade sağlamak için kullanım durumuna odaklanır.

• Sistem testi : Bir sistemi kara kutu olarak test eder . Test sırasında diğer sistemlere bağımlılıklar genellikle alay edilir veya saplanır (aksi takdirde bir entegrasyon testinden daha fazlası olurdu).

• Uçuş öncesi kontrol : 'Makinemdeki yapı' sendromunu hafifletmek için üretim benzeri bir ortamda tekrarlanan testler. Bu genellikle çevre gibi bir üretimde kabul veya duman testi yapılarak gerçekleştirilir.

• Birim testi : Bir sınıfın dahili işleyişini test etmek için otomatik bir test. Diğer kaynaklarla ilgili olmayan bağımsız bir test olmalıdır.
• Entegrasyon testi : birim testlerine benzer, ancak harici kaynaklarla (db, disk erişimi) bir ortamda yapılan otomatik test
• Regresyon testi : yeni özellikler veya hata düzeltmeleri uyguladıktan sonra, geçmişte çalışan senaryoları yeniden test edersiniz. Burada, yeni özelliklerinizin mevcut özellikleri bozma olasılığını ele alırsınız.
• Duman testi : testçilerin teste devam edip etmeyecekleri sonucuna varabilecekleri ilk testler.

Herkesin biraz farklı tanımları olacak ve genellikle gri alanlar var. Ancak:

• Birim testi: Bu biraz (mümkün olduğunca izole edilmiş) çalışıyor mu?
• Entegrasyon testi: Bu iki (veya daha fazla) bileşen birlikte çalışıyor mu?
• Duman testi: Tüm sistem (mümkün olduğunca bir üretim sistemi olmaya yakın) makul bir şekilde birbirine asılıyor mu? (yani bir kara delik yaratmayacağından oldukça emin miyiz?)
• Regresyon testi: Daha önce düzelttiğimiz hataları yanlışlıkla yeniden ekledik mi?

Az önce farkına vardığım yeni bir test kategorisi kanarya testi . Bir kanarya testi olan bir otomatik, tahribatsız testtir düzenli olarak çalıştırmak bir de canlı o başarısız olması durumunda çevre, böyle bir şey gerçekten kötü oldu ki.

Örnekler şunlar olabilir:

• Sadece geliştirme / testide bulunması gereken veriler canlı olarak görüntülendi mi?
• Bir arka plan işlemi yürütülemedi mi?
• Bir kullanıcı oturum açabilir mi?

Yazılım test teknikleri için en iyi web sitelerinden birini yanıtlayın:

Yazılım testi türleri - tam liste için tıklayınız

Oldukça uzun bir açıklama ve buraya yapıştırmayacağım: ancak tüm test tekniklerini bilmek isteyen biri için yararlı olabilir.

Birim testi: Belirli bir bileşenin (yani, sınıfın) tasarlandığı gibi oluşturulduğu veya değiştirildiği işlevleri doğrulama. Bu test manuel veya otomatik olabilir, ancak bileşenin sınırlarının ötesine geçmez.

Entegrasyon testi: Belirli bileşenlerin etkileşiminin tasarlandığı gibi çalıştığını doğrulama. Entegrasyon testleri birim düzeyinde veya sistem düzeyinde yapılabilir. Bu testler manuel veya otomatik olabilir.

Regresyon testi: Mevcut koda yeni hataların girilmediğini doğrulama. Bu testler manuel veya otomatik olabilir.

SDLC'nize ( şelale , RUP , çevik , vb.) Bağlı olarak, belirli testler “aşamalar” da yapılabilir veya hepsi aynı anda veya daha fazla yapılabilir. Örneğin, birim testi, daha sonra kodu entegrasyon ve regresyon testi için test edicilere dönüştüren geliştiricilerle sınırlı olabilir. Bununla birlikte, başka bir yaklaşım, birim testi ve bir miktar entegrasyon ve regresyon testi yapan geliştiricilere sahip olabilir ( sürekli entegrasyon ve otomatik birim ve regresyon testleriyle birlikte bir TDD yaklaşımı kullanarak ).

Araç seti büyük ölçüde kod tabanına bağlı olacaktır, ancak birim testi (JUnit) için birçok açık kaynaklı araç vardır. HP'nin (Mercury) QTP veya Borland'ın İpek Testi , otomatik entegrasyon ve regresyon testi için kullanılan araçlardır.

Birim testi : Bir uygulamadaki bağımsız bir modülün veya bağımsız bir bileşenin test edilmesinin birim test olduğu bilinmektedir. Birim testi geliştirici tarafından yapılacaktır.

Entegrasyon testi : modüller arasındaki iletişim ve veri akışının düzgün çalışıp çalışmadığını doğrulamak için tüm modülleri birleştirmek ve uygulamayı test etmek. Bu test geliştiriciler tarafından da gerçekleştirildi.

Duman testi Duman testinde uygulamayı sığ ve geniş bir şekilde kontrol ederler. Duman testinde uygulamanın ana işlevselliğini kontrol ederler. Uygulamada herhangi bir engelleyici sorun varsa, geliştirici ekibine rapor verecekler ve geliştirme ekibi sorunu düzeltecek ve arızayı giderecek ve test ekibine geri verecektir. Şimdi test ekibi, bir modülde yapılan değişikliklerin diğer modülü etkileyip etkilemeyeceğini doğrulamak için tüm modülleri kontrol edecektir. Duman testinde test senaryoları senaryo haline getirilir.

Değişmeyen modülün herhangi bir kusura neden olmamasını sağlamak için aynı test vakalarını tekrar tekrar yürüten regresyon testi . Regresyon testi fonksiyonel teste tabi tutulur

GERİLEME TESTİ-

"Bir regresyon testi, mevcut yazılımda yapılan değişikliklerin mevcut yazılımın işlevselliğini etkilemediğinden emin olmak için değiştirilmiş yazılıma karşı önceki testleri yeniden çalıştırır."

Sadece bu test seviyelerine neden sahip olduğumuza, örneklerle gerçekte ne anlama geldiklerine biraz daha bağlam eklemek ve vermek istedim.

Mike Cohn, “Agile ile Başarılı Olmak” adlı kitabında, projelerde otomatik testlere yaklaşmanın bir yolu olarak “Test Piramidi” ni buldu. Bu modelin çeşitli yorumları vardır. Model, ne tür otomatik testlerin oluşturulması gerektiğini, test edilen uygulama hakkında ne kadar hızlı geri bildirim verebileceklerini ve bu testleri kimin yazdığını açıklar. Temel olarak herhangi bir proje için 3 seviye otomatik test gereklidir ve bunlar aşağıdaki gibidir.

Birim Testleri - Bunlar, yazılım uygulamanızın en küçük bileşenini test eder. Bu, kelimenin tam anlamıyla bazı girdilere dayalı bir değeri hesaplayan bir kodda bir işlev olabilir. Bu işlev, uygulamayı oluşturan donanım / yazılım kod tabanının diğer birçok işlevinin bir parçasıdır.

Örneğin - Web tabanlı bir hesap makinesi uygulaması alalım. Bu uygulamanın birim test edilmesi gereken en küçük bileşenleri toplama yapan bir işlev, çıkarma yapan bir işlev olabilir. Bütün bu küçük fonksiyonlar bir araya getirilerek hesap makinesi uygulamasını oluşturur.

Tarihsel olarak geliştirici bu testleri genellikle yazılım uygulamasıyla aynı programlama dilinde yazıldığından yazar. JUnit ve NUnit (java için), MSTest (C # ve .NET için) ve Jasmine / Mocha (JavaScript için) gibi birim test çerçeveleri bu amaçla kullanılır.

Birim testlerinin en büyük avantajı, kullanıcı arayüzünün altında gerçekten hızlı çalışması ve uygulama hakkında hızlı geri bildirim alabilmemizdir. Bu, otomatik testlerinizin% 50'sinden fazlasını içermelidir.

API / Entegrasyon Testleri - Bunlar, yazılım sisteminin çeşitli bileşenlerini birlikte test eder. Bileşenler, test veritabanlarını, API'leri (Uygulama Programlama Arayüzü), 3. taraf araçlarını ve uygulamalarını içerebilir.

Örneğin - Yukarıdaki hesap makinesi örneğimizde, web uygulaması değerleri depolamak için bir veritabanı kullanabilir, bazı sunucu tarafı doğrulamaları yapmak için API'leri kullanabilir ve sonuçları farklı yerlerde kullanılabilir hale getirmek için buluta yayınlamak için 3. taraf bir araç / hizmet kullanabilir platformlar.

Tarihsel olarak bir geliştirici veya teknik KG bu testleri Postman, SoapUI, JMeter ve Testim gibi diğer araçları kullanarak yazacaktır.

Bunlar, hala kaputun altında çalıştıkları için UI testlerinden çok daha hızlı çalışırlar, ancak sistemin çeşitli bağımsız bileşenleri arasındaki iletişimi kontrol etmek ve sorunsuz entegrasyona sahip olduklarından emin olmak zorunda olduğu için birim testlerinden biraz daha fazla zaman harcayabilirler. Bu, otomatik testlerin% 30'undan fazlasını içermelidir.

UI Testleri - Son olarak, uygulamanın kullanıcı arayüzünü doğrulayan testlerimiz var. Bu testler genellikle uygulama boyunca uçtan uca akışları test etmek için yazılır.

Örneğin - Hesap makinesi uygulamasında, tarayıcıyı açmak için bir uçtan uca akış olabilir-> Hesap makinesi uygulaması url'sini girme -> Kullanıcı adı / şifre ile giriş yapma -> Hesap makinesi uygulamasını açma -> Hesap makinesinde bazı işlemler yapma -> bu sonuçları kullanıcı arayüzünden doğrulama -> Uygulama oturumunu kapatma. Bu, UI otomasyonu için iyi bir aday olabilecek bir uçtan uca akış olabilir.

Tarihsel olarak, teknik KG'ler veya manuel testçiler kullanıcı arayüzü testleri yazmaktadır. Testleri yazmak, yürütmek ve sürdürmek için Selenium gibi açık kaynaklı çerçeveler veya Testim gibi UI test platformları kullanırlar. Bu testlerin nasıl çalıştığını, ekran görüntüleri, günlükler, test raporları aracılığıyla beklenen ve gerçek sonuçlar arasındaki farkı görebileceğiniz için bu testler daha görsel geri bildirim sağlar.

UI testlerinin en büyük sınırlaması, Birim ve API seviyesi testlerine kıyasla nispeten yavaş olmasıdır. Bu nedenle, toplam otomatik testlerin sadece% 10-20'sini içermelidir.

Sonraki iki test türü projenize bağlı olarak değişebilir ancak fikir,

Duman Testleri

Bu, yukarıdaki 3 test seviyesinin bir kombinasyonu olabilir. Fikir, her kod kontrolü sırasında çalıştırmak ve sistemin kritik işlevlerinin beklendiği gibi çalıştığından emin olmaktır; yeni kod değişiklikleri birleştirildikten sonra. Arızalarla ilgili daha hızlı geri bildirim almak için genellikle 5-10 dakika koşmaları gerekir

Regresyon Testleri

Genellikle günde en az bir kez çalıştırılır ve sistemin çeşitli işlevlerini kapsar. Uygulamanın beklendiği gibi çalışmasını sağlarlar. Duman testlerinden daha fazla detaydır ve kritik olmayanlar da dahil olmak üzere uygulamanın daha fazla senaryosunu kapsar.

Birim testi , uygulamanın mümkün olan en küçük kısmına yöneliktir. Java'da bu, tek bir sınıfı test ettiğiniz anlamına gelir. Sınıf diğer sınıflara bağlıysa bunlar sahte olur.

Testiniz birden fazla sınıf çağırdığında, bir entegrasyon testidir .

Tam test paketlerinin çalışması uzun zaman alabilir, bu nedenle bir değişiklikten sonra birçok takım önemli kırılmaları tespit etmek için testleri tamamlamak için hızlı bir şekilde çalışır. Örneğin, URI'leri temel kaynaklara ayırdınız. Bunlar duman testleri .

Regresyon testleri her yapıda çalışır ve kırdığınızı yakalayarak etkili bir şekilde yeniden düzenleme yapmanıza izin verir. Her türlü test regresyon testi olabilir, ancak birim testlerin hatanın kaynağını bulmakta en yararlı olduğunu düşünüyorum.

• Entegrasyon testi: Entegrasyon testi başka bir öğeyi entegre etmektir
• Duman testi: Duman testi aynı zamanda derleme sürümü testi olarak da bilinir. Duman testi, test edilen yazılımın daha fazla test için hazır / kararlı olup olmadığını kontrol etmek için yapılan ilk test sürecidir.
• Regresyon testi: Regresyon testi tekrarlanan testtir. Yeni yazılımın başka bir modülde etkilenip etkilenmediği.
• Birim testi: Beyaz kutu testidir. Sadece geliştiriciler buna dahil olur

Birim testi: Belirli bir bileşenin (yani, sınıfın) tasarlandığı gibi oluşturulduğu veya değiştirildiği işlevleri doğrulama. Bu test manuel veya otomatik olabilir, ancak bileşenin sınırlarının ötesine geçmez.

Entegrasyon testi: Belirli bileşenlerin etkileşiminin tasarlandığı gibi çalıştığını doğrulama. Entegrasyon testleri birim düzeyinde veya sistem düzeyinde yapılabilir. Bu testler manuel veya otomatik olabilir.

Regresyon testi: Mevcut koda yeni hataların girilmediğini doğrulama. Bu testler manuel veya otomatik olabilir.

SDLC'nize (şelale, kopma, çevik, vb.) Bağlı olarak, belirli testler “aşamalarda” yapılabilir veya hepsi aynı anda veya daha fazla yapılabilir. Örneğin, birim testi, daha sonra kodu entegrasyon ve regresyon testi için test edicilere dönüştüren geliştiricilerle sınırlı olabilir. Bununla birlikte, başka bir yaklaşım, geliştiricilerin birim testi ve bir miktar entegrasyon ve regresyon testi yapmasını sağlayabilir (sürekli entegrasyon ve otomatik birim ve regresyon testleriyle birlikte bir TDD yaklaşımı kullanarak).

Birim testleri Birim testleri, uygulamanızın kaynağına yakın, çok düşük düzeydedir. Yazılımınız tarafından kullanılan sınıfların, bileşenlerin veya modüllerin bireysel yöntemlerini ve işlevlerini test etmekten oluşur. Birim testleri genellikle otomatikleştirmek için oldukça ucuzdur ve sürekli bir entegrasyon sunucusu tarafından çok hızlı bir şekilde çalıştırılabilir.

Entegrasyon testleri Entegrasyon testleri, uygulamanız tarafından kullanılan farklı modüllerin veya hizmetlerin birlikte iyi çalıştığını doğrular. Örneğin, veritabanı ile etkileşimi test edebilir veya mikro hizmetlerin beklendiği gibi birlikte çalıştığından emin olabilir. Bu tür testlerin yürütülmesi, uygulamanın birden çok bölümünün çalışır durumda olmasını gerektirdiklerinden daha pahalıdır.

İşlevsel testler İşlevsel testler bir uygulamanın iş gereksinimlerine odaklanır. Yalnızca bir eylemin çıktısını doğrularlar ve bu eylemi gerçekleştirirken sistemin ara durumlarını kontrol etmezler.

Bazen entegrasyon testleri ile fonksiyonel testler arasında karışıklık olabilir, çünkü her ikisi de birbirleriyle etkileşime geçmek için birden fazla bileşen gerektirir. Fark, bir entegrasyon testinin veritabanını sorgulayabileceğinizi doğrulaması ve işlevsel bir testin ürün gereksinimleri tarafından tanımlanan veritabanından belirli bir değer almayı beklemesidir.

Uçtan uca testler Uçtan uca test, kullanıcı davranışını tam bir uygulama ortamında yazılımla eşleştirir. Çeşitli kullanıcı akışlarının beklendiği gibi çalıştığını doğrular ve bir web sayfasını yüklemek veya giriş yapmak veya e-posta bildirimlerini, çevrimiçi ödemeleri vb. Doğrulayan çok daha karmaşık senaryolar kadar basit olabilir.

Uçtan uca testler çok faydalıdır, ancak yapılması pahalıdır ve otomatikleştirildiklerinde bakımı zor olabilir. Birkaç önemli uçtan uca teste sahip olmanız ve kırılma değişikliklerini hızlı bir şekilde tanımlayabilmek için daha düşük seviyeli test türlerine (birim ve entegrasyon testleri) güvenmeniz önerilir.

Kabul testi Kabul testleri, bir sistemin iş gereksinimlerini karşılayıp karşılamadığını doğrulamak için yapılan resmi testlerdir. Tüm uygulamanın çalışır durumda olmasını ve kullanıcı davranışlarını çoğaltmaya odaklanmasını gerektirirler. Ancak, daha ileri gidebilir ve sistemin performansını ölçebilir ve belirli hedeflere ulaşılmazsa değişiklikleri reddedebilirler.

Performans testi Performans testleri, önemli yük altında sistemin davranışlarını kontrol eder. Bu testler işlevsel değildir ve platformun güvenilirliğini, kararlılığını ve kullanılabilirliğini anlamak için çeşitli biçimlere sahip olabilir. Örneğin, çok sayıda istek gerçekleştirirken yanıt sürelerini gözlemleyebilir veya sistemin önemli bir veriyle nasıl davrandığını görebilir.

Performans testleri, doğası gereği uygulanması ve çalıştırılması oldukça pahalıdır, ancak yeni değişikliklerin sisteminizi bozup bozmayacağını anlamanıza yardımcı olabilirler.

Duman testi Duman testleri, uygulamanın temel işlevlerini kontrol eden temel testlerdir. Çalışmaları hızlı olmalı ve hedefleri size sisteminizin ana özelliklerinin beklendiği gibi çalıştığından emin olmanızı sağlamaktır.

Duman testleri, daha pahalı testler yapıp yapamayacağınıza karar vermek için yeni bir derleme yapıldıktan hemen sonra veya uygulamanın yeni dağıtılan ortamda düzgün çalıştığından emin olmak için bir dağıtımdan hemen sonra yararlı olabilir.

Kaynak: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

Birim Testi: Geliştirme tarafından, kalite kontrolüne herhangi bir gereklilik getirmeden önce test tarafındaki sorunu bulmak için geliştirici tarafından her zaman gerçekleştirilir.

Entegrasyon Testi: Bazı veri / fonksiyon çıkışları bir modüle diğer modüle götürüldüğünde test cihazının modülü modülden alt modüle doğrulaması gerektiği anlamına gelir. Veya sisteminizde kullanmak için sistem verilerinizi kullanarak üçüncü taraf bir araç kullanıyorsanız.

Duman Testi: sistemi yüksek seviye test için doğrulamak ve değişiklikler veya kod yayınlanmadan önce gösteri durdurucu hatasını bulmaya çalışmak için test cihazı.

Regresyon Testi: Test cihazı, yeni geliştirme veya sistemdeki değişiklikler için sistemde uygulanan değişiklikler nedeniyle mevcut işlevselliğin doğrulanması için regresyon gerçekleştirdi.

Birim Testi

Birim testi genellikle geliştiriciler tarafından yapılırken, testçiler kısmen testlerin birime göre yapıldığı bu test türünde kısmen gelişmiştir. Java JUnit test senaryolarında yazılı kodun mükemmel tasarlanmış olup olmadığını test etmek de mümkündür.

Entegrasyon Testi:

Bu tip testler, tüm / bazı bileşenler entegre edildiğinde ünite testinden sonra mümkündür. Bu tür testler, bileşenler entegre edildiğinde, birbirlerinin çalışma yeteneklerini veya işlevlerini etkilediğinden emin olur mu?

Duman Testi

Bu tür testler en sonunda sistem başarılı bir şekilde entegre edildiğinde ve üretim sunucusuna hazır olduğunda yapılır.

Bu tür testler, baştan sona tüm önemli işlevlerin iyi çalıştığından ve sistemin üretim sunucusuna dağıtılmaya hazır olduğundan emin olacaktır.

Gerileme testi

Bu tür testler, geliştirici bazı sorunları düzelttiğinde sistemde istenmeyen / istenmeyen hataların bulunmadığını test etmek için önemlidir. Bu test ayrıca tüm hataların başarıyla çözüldüğünden ve başka sorunların oluşmadığından emin olur.

Duman ve akıl sağlığı testi, teste başlayıp başlamayacağını belirlemek için bir yazılım derlemesinden sonra gerçekleştirilir. Duman testi sonrasında akıl sağlığı sağlanabilir veya uygulanmayabilir. Bunlar ayrı ayrı veya aynı zamanda uygulanabilir - dumandan hemen sonra akıl sağlığı.

Akıl sağlığı testi daha derinlemesine ve daha fazla zaman aldığından, çoğu durumda otomatikleştirilmeye değer.

Duman testi genellikle yürütme için 5-30 dakikadan fazla sürmez. Daha geneldir: yazılımın kararlılığının daha fazla test için yeterince iyi olduğunu ve planlanan test senaryolarının çalışmasını engelleyen herhangi bir sorun olmadığını doğrulamak için tüm sistemin az sayıda temel işlevselliğini kontrol eder.

Sağlık testi dumandan daha ayrıntılıdır ve yeni yapının ölçeğine bağlı olarak 15 dakikadan bütün güne kadar sürebilir. İlerlemeden veya yeniden testten sonra gerçekleştirilen daha özel bir kabul testi türüdür. Regresyon testinin daha büyük bir ölçekte gerçekleştirilebilmesi için gerekli operasyonel mantık için çalıştıklarını doğrulamak amacıyla belirli yeni işlevlerin ve / veya hata düzeltmelerinin temel özelliklerini, bunlarla yakından ilişkili olan bazı özelliklerle birlikte kontrol eder.

Zaten bazı iyi cevaplar var, ama onları daha da hassaslaştırmak istiyorum:

Birim testi, burada beyaz kutu testinin tek şeklidir. Diğerleri kara kutu testidir. Beyaz kutu testi, girdiyi bildiğiniz anlamına gelir; mekanizmanın iç işleyişini bilir ve inceleyebilir ve çıktıyı bilirsiniz. Kara kutu testi ile yalnızca girdinin ne olduğunu ve çıktının ne olması gerektiğini bilirsiniz.

Açıkça birim testi, burada tek beyaz kutu testi.

• Birim testi, belirli kod parçalarını test eder. Genellikle yöntemler.
• Entegrasyon testi, yeni özellik yazılımınızın diğer her şeyle entegre olup olmadığını test eder.
• Gerileme testi. Bu, hiçbir şeyi kırmadığınızdan emin olmak için yapılan testlerdir. Eskiden işe yarayan her şey hala çalışmalıdır.
• Duman testi, daha kuvvetli testlere katılmadan önce her şeyin iyi göründüğünden emin olmak için hızlı bir test olarak yapılır.

Duman testleri burada zaten açıklanmıştır ve basittir. Regresyon testleri entegrasyon testlerine tabi tutulur.

Otomatik testler sadece ikiye ayrılabilir.

Birim testleri ve entegrasyon testleri (önemli olan budur)

Entegrasyon testleri, fonksiyonel testler, regresyon testleri, UI testleri, vb. Gibi tüm testler için "uzun test" (LT) ifadesini "kısa test" olarak adlandırmayı söyleyebilirim.

Bir LT örneği, bir web sayfasını otomatik olarak yüklemek, hesaba giriş yapmak ve bir kitap satın almak olabilir. Test başarılı olursa, canlı sitede aynı şekilde yayınlanması daha olasıdır (dolayısıyla 'daha iyi uyku' referansı). Uzun = web sayfası (başlangıç) ve veritabanı (bitiş) arasındaki mesafe.

Ve bu, entegrasyon testinin (uzun test) birim test üzerindeki faydalarını tartışan harika bir makaledir .

Regresyon testi - Hata düzeltmesini ele almaya veya kontrol etmeye çalıştığımız bir tür yazılım testidir . Hata düzeltmesi çevresindeki işlevsellik, sağlanan düzeltme nedeniyle değiştirilmemeli veya değiştirilmemelidir. Bu süreçte bulunan sorunlara regresyon sorunları denir .

Duman Testi: Daha fazla KG testi için derlemeyi / yazılımı kabul edip etmemeye karar vermek için yapılan bir tür testtir.