Cevap.

Konunun geçmişi:

Smoke testleri (smoke tests, "duman testleri") ilk olarak, bir sistemin temel işlevselliğinin dağıtım veya kod değişikliği sonrasında çalıştığından emin olmanın hızlı bir yolu olarak ortaya çıkmıştır. Bu testlerin ideolojisi, "kritik bir şey bozuksa, ayrıntılı kontrolleri çalıştırmanın bir anlamı yoktur" şeklindedir. Otomatikleştirmede ilk smoke testleri, uygulamanın başlatılması, giriş ekranına erişimi ve temel işlemleri kontrol eden küçük manuel betikler olarak gerçekleştirilmiştir.

Sorun:

Smoke testlerinin otomatikleştirilmesindeki başlıca zorluklar, minimum senaryo setinin doğru bir şekilde izole edilmesi, yüksek yürütme hızı, kararsız bileşenlerden (örneğin, üçüncü taraf hizmetler) minimum bağımlılık ve bu testlerin "hafif ve şeffaf" olmasını destekleyen görsel ve teknik destek sağlamaktır. Bunu başaramazsanız, smoke otomasyonu ya çok ağır olur ya da sık sık yanlış alarm vererek büyük bakım gerektirir.

Çözüm:

Smoke testlerinin sayısını minimize edin: bunlar yalnızca en kritik "giriş noktalarını" (örneğin, yetkilendirme, ana modülün başlatılması, veritabanına erişim) kontrol etmelidir.
Kararsız adımları ve dış bağımlılıkları smoke senaryolarının dışında tutun veya ortamları "kurulumlar" ile stabilize edin.
Smoke testlerini her zaman ilk olarak çalıştırmak için etiketleme (@smoke, Suite('smoke') vb.) ve CI/CD pipeline'ında ayrı bölümler kullanın.

Ana özellikler:

Smoke senaryoları hızlı bir şekilde çalıştırılmalı ve yalnızca en stabil alt yapıyı kullanmalıdır.
Smoke sınıfındaki otomatik testler, UX detaylarını veya karmaşık iş akışlarını kapsamalıdır.
Smoke otomasyonu, bağımlılıkların katı bir kontrolünü ve minimum destek kodunu gerektirir.

Soru-Cevap

Smoke setine edge-case mantığı kontrolleri eklenebilir mi?

Hayır, smoke seti yalnızca sistemin temel yaşamsallığını ve erişilebilirliğini kontrol etmek için tasarlanmıştır, edge-case'ler burada gereksizdir, bu durum yürütmeyi yavaşlatacak ve bakımı zorlaştıracaktır.

Smoke testlerinde çok katmanlı hata işleme ve kurtarma gerekli midir?

Çoğu zaman, smoke testlerinin karmaşık kurtarma mekanizmalarını gerektirdiği yanlış bir şekilde düşünülmektedir. Aslında, bir smoke testinin başarısız olması — bunu düzeltmek için bir kritik sorun olduğunu gösterir, otomatik testte "aşmak" değil.

Smoke testleri, diğer testlerin bıraktığı verilere bağlı olmalı mıdır?

Hayır, smoke testleri hiçbir dış test verisine ve özellikle diğer testlerin kalıntılarına bağlı olmamalıdır. Bu, güvenilirliğinin ana prensiplerinden biridir.

Tipik hatalar ve anti-paternler

Smoke testlerini aşırı yüklemek: çok fazla senaryo eklemek, bunları regresyon testlerine dönüştürmek.
Smoke ve normal otomatik testler arasında kodun tekrar kullanılması.
Dolaylı bağımlılıklar: test, diğer senaryolardan "kirli" verileri/kalıntıları kullanıyor.

Hayattan bir örnek

Negatif durum

Smoke senaryoları setine 30 farklı kontrol eklendi, bunların bir kısmı yalnızca sistemi başlatmakla kalmayıp, karmaşık algoritmaları ve edge-case koşullarını da test ediyor. Smoke yürütmesi 30 dakika sürdü ve periyodik olarak bazı kontroller, arka ucu kararsız olduğu için başarısız oldu.

Artılar:

Sistem üzerindeki dar noktaları görmek kolay.
Dağıtım sonrası yüksek test kapsamı.

Eksiler:

Smoke testinin özü kayboldu: "yeşil" bir derleme almak ancak uzun bir bekleyiş ve sistemin üretime geçmesi için önem arz etmeyen sorunların giderilmesinden sonra mümkün olabiliyor.
Testleri sürdürmek ve gerçek kritik hataları ayırmak zorlaştı.

Pozitif durum

Smoke grubuna katı bir minimum seviyeyi dahil ettik: giriş, anasayfa açılışı, veritabanına istekte bulunma, temel API el sıkışması. Smoke çerçevesi, ana test matrisinden bağımsız çalışmakta ve her zaman CI/CD pipeline'ında ilk olarak yer almaktadır. Sonuçlar, ayrı bir sohbet kanalında ve hızlı teşhis için her zaman erişilebilir durumdadır.