Mobil geliştirmede regresyon testi — nedir, türleri ve nasıl yapılır

Regresyon testi nedir?

Regresyon testi, kod değişikliklerinin mevcut işlevselliği bozmadığını doğrulamayı amaçlayan bir test türüdür. “Regresyon” terimi, daha kötü bir duruma dönüş anlamına gelir — önceki sürümde çalışan bir işlevin yeni sürümde çalışmayı durdurması. Regresyon testleri her geliştirme döngüsünde tekrar tekrar yürütülür, bu da onları bir kez yazılan yeni özellik testlerinden ayırır.

Regresyon testi ihtiyacı, basamaklı değişiklikler etkisinden kaynaklanır: bir modüldeki hatayı düzeltmek sorunu çözebilir ancak ona bağlı olan bitişik işlevselliği bozabilir. Örneğin, kullanıcı deposundaki bir SQL sorgusunu değiştirmek kimlik doğrulamayı hızlandırabilir ancak aynı sorguyu kullanan veri dışa aktarmayı bozabilir. Veri dışa aktarma üzerinde bir regresyon testi, bu ihlali sürümden önce tespit edecektir.

CISQ 2023 raporuna göre, üretimde bulunan bir regresyon kusurunu düzeltme maliyeti, otomatik regresyon çalıştırma aşamasına göre 15 kat daha yüksektir. Capgemini World Quality Report'a göre, otomatik regresyon testine yatırım yapan şirketler, uygulamadan sonraki bir yıl içinde sürümlerdeki regresyon kusurlarının payını %25'ten %5'e düşürmektedir.

Regresyon testi türleri

Regresyon testine kapsam ve test seçim kriterleri açısından farklılık gösteren birkaç yaklaşım vardır. Yaklaşım seçimi proje boyutuna, değişiklik sıklığına ve CI hattında bulunan süreye bağlıdır. Aşağıda özellikleriyle birlikte ana regresyon testi türleri verilmiştir.

Tam regresyon testi

Tam regresyon çalıştırması, istisnasız projenin tüm otomatik testlerini yürütür. Bu yaklaşım maksimum güven sağlar ancak önemli bilgi işlem kaynakları ve zaman gerektirir. Tam çalıştırma, büyük sürümlerden önce — her 2–4 haftada bir — gerçekleştirilir. 5000 testi olan bir uygulama için tam çalıştırma, altyapıya bağlı olarak 2 ila 6 saat sürer.

Seçici regresyon testi

Seçici yaklaşım yalnızca değiştirilen modüllerle ilgili testleri çalıştırır. İlişkiyi belirlemek için kod düzeyinde bağımlılık analizi kullanılır: UserRepository sınıfı değiştirilirse, UserRepository'ye doğrudan veya geçişli olarak bağlı olan testler çalıştırılır. Jacoco, Android Test Coverage ve Xcode Code Coverage gibi araçlar, hassas seçim için kapsama haritaları sağlar. Seçici çalıştırma her pull request'te gerçekleştirilir ve 5–15 dakika sürer.

Risk bazlı regresyon

Risk bazlı regresyon, testleri işlevsellik kritikliği ve bozulma olasılığına göre sıralar. Kritik işlevler — ödemeler, kimlik doğrulama, senkronizasyon — her kod değişikliğinde test edilir. Yardımcı işlevler — Hakkında ekranı, animasyonlar — yalnızca sürümden önce test edilir. Sıralama, üretim olay verilerine dayalı olarak üç ayda bir gözden geçirilir.

Regresyon testi ve yeniden test arasındaki fark

Regresyon testi ve yeniden test kavramları, farklı süreçler olmalarına rağmen sıklıkla karıştırılır. Yeniden test, kusur düzeltmesinden sonra daha önce başarısız olan belirli bir testin yeniden çalıştırılmasıdır. Yeniden testin amacı, düzeltmenin çalıştığını doğrulamaktır: hata artık tekrarlanmaz. Yeniden test, düzeltmeden ve geliştiricinin düzeltmeyi onaylamasından hemen sonra bir kez gerçekleştirilir.

Regresyon testi, değiştirilmemiş mevcut işlevsellik üzerinde testlerin çalıştırılmasıdır. Amaç, bir kusurun düzeltilmesinin başka bir yerde yeni bir kusur yaratmadığından emin olmaktır. Regresyon testleri, hangi belirli hataların düzeltildiğine bakılmaksızın her geliştirme döngüsünde tekrar tekrar çalıştırılır. Temel fark: yeniden test düzeltmenin kendisini doğrular, regresyon düzeltmenin sonuçlarını doğrular.

Bir CI/CD hattında, her iki süreç sırayla yürütülür. Bir pull request birleştirildikten sonra, belirli hatanın yeniden testi çalıştırılır, ardından tam veya seçici bir regresyon çalıştırması gelir. SmartBear (2022)'ye göre, bu süreçleri ayırmak, başarısız CI çalıştırmalarının teşhis süresini %30 azaltır, çünkü ekip hangi kusurların regresyonla ve hangilerinin çalışmayan düzeltmelerle ilgili olduğunu hemen görür.

Regresyon testi otomasyonu

Regresyon testi otomasyonu, modern mobil projeler için kritik bir başarı faktörüdür. Manuel regresyon testi ölçeklenemez: 200 testlik bir pakette, bir çalıştırma bir QA mühendisinin 2–3 iş gününü gerektirir ve günlük çalıştırmaları imkansız hale getirir. Otomatik regresyon testleri, insan müdahalesi olmadan 10–60 dakikada çalışır ve her commit veya pull request'te çalıştırılmalarına olanak tanır.

• Birim testler — regresyon paketinin temeli (%70). Saniyeler içinde çalışır, emülatör gerektirmez ve bozuk sınıfın kesin olarak belirlenmesini sağlar.
• Entegrasyon testleri — ikinci seviye (%20). Kontrollü bağımlılıklarla ağ katmanını, veritabanını ve sistem hizmetlerini kontrol eder.
• UI testleri ve E2E testleri — piramidin tepesi (%10). Kritik kullanıcı senaryolarını kapsar: kayıt, ödeme, senkronizasyon.

Regresyon paketini güncel tutmak için test analitiği kullanılır: Allure, ReportPortal ve Xray gibi araçlar her testin geçme oranını, süresini ve kararlılığını izler. Kararlılığı %90'ın altına düşen testler (genellikle gereksinim değişiklikleri nedeniyle bozulan) eski olarak işaretlenir ve inceleme için sahibine atanır.

Regresyon testi kurulumu örneği

JUnit 5 kütüphanesi ve Espresso'yu kullanarak Android'de otomatik bir regresyon testinin kurulumuna bakalım. Örnek, seçici regresyonu göstermektedir — test, kullanıcı deposu yeniden düzenlendikten sonra profil ekranının bozulmadığını doğrular. iOS için benzer mantıkla XCTest kullanılır — önemli bir senaryoda tekrarlanan test.

Android: profil regresyon testi

Test, sunucuyu öykünmek için MockWebServer kullanır ve tam yolu kontrol eder: kullanıcı verilerinin yüklenmesi, profil ekranında görüntülenmesi ve sunucu kullanılamadığında hata işleme. Bu tür testler regresyon paketine dahil edilir ve profil modülündeki her değişiklikte çalıştırılır.

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("Yükleme hatası").assertIsDisplayed()
    }
}

iOS: XCTest ile regresyon testi

iOS için regresyon testi, API'den veri aldıktan sonra UI güncellemesinin eşzamansız doğrulaması için XCTestExpectation kullanır. Test bir ağ yanıtını öykünür ve UI öğelerinin doğru şekilde güncellendiğini doğrular.

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

Regresyon paketi oluşturma stratejisi

Etkili bir regresyon paketi oluşturmak, kusur ve kod değişikliği verilerine dayanan yinelemeli bir süreçtir. İlk strateji, mevcut tüm testleri regresyon paketine dahil etmek ve her sürümden önce tam bir çalıştırma yapmaktır. Test tabanı büyüdükçe (2000'den fazla test), tam çalıştırma çok uzun hale gelir ve seçici bir yaklaşım gerekir.

İkinci aşama — bağımlılık analizi araçlarının uygulanması: Android için Jacoco, iOS için Xcode Test Plan. Bu araçlar bir “test — sınıf — yöntem” haritası oluşturur ve belirli bir değişiklikten hangi testlerin etkilendiğini belirlemeye olanak tanır. Spotify Engineering (2022)'ye göre, kapsama analizine dayalı seçici çalıştırma, %95 regresyon tespit etkinliğini korurken yürütme süresini %60–80 oranında azaltır.

Üçüncü aşama — sürekli izleme ve optimizasyon. 6 aydır başarısız olmayan testler düşük öncelikli bir pakete taşınır. Ayda birden fazla başarısız olan testler inceleme için adaydır: ya gerçek sorunları yakalarlar (düzeltme gerekir) ya da çok kırılgandırlar (stabilizasyon gerekir). Regresyon paketinin üç ayda bir gözden geçirilmesi, etkinliğini ve yürütme hızını korumak için standart bir uygulamadır.