Mobil tətbiqi inkişafında reqressiya testi — bu nədir, növləri və necə aparılır

Reqressiya testi nədir?

Reqressiya testi — koddakı dəyişikliklərin mövcud funksionallığı pozmadığını təsdiqləməyə yönəlmiş test növüdür. „Reqressiya” termini daha pis vəziyyətə qayıdış deməkdir — əvvəlki versiyada işləyən funksiyanın yeni versiyada işləməməsi. Reqressiya testləri hər inkişaf dövründə dəfələrlə yerinə yetirilir ki, bu da onları bir dəfə yazılan yeni funksionallıq testlərindən fərqləndirir.

Reqressiya testinə ehtiyac zəncirvari dəyişikliklər effektindən irəli gəlir: bir moduldakı səhvin düzəldilməsi problemi həll edə bilər, lakin ondan asılı olan qonşu funksionallığı poza bilər. Məsələn, istifadəçi repozitoriyasında SQL sorğusunun dəyişdirilməsi girişi sürətləndirə bilər, lakin eyni sorğudan istifadə edən məlumat ixracını poza bilər. Məlumat ixracı üzrə reqressiya testi bu pozuntunu buraxılışdan əvvəl aşkar edəcək.

CISQ 2023 hesabatına görə, istehsalda aşkar edilmiş reqressiya qüsurunun düzəldilməsi dəyəri avtomatlaşdırılmış reqressiya qaçışı mərhələsindən 15 dəfə yüksəkdir. Avtomatlaşdırılmış reqressiya testinə sərmayə qoyan şirkətlər Capgemini World Quality Report məlumatlarına görə, tətbiqdən sonra bir il ərzində buraxılışlardakı reqressiya qüsurlarının payını 25%-dən 5%-ə endirirlər.

Reqressiya testinin növləri

Reqressiya testinə bir neçə yanaşma mövcuddur, onlar həcm və test seçim meyarlarına görə fərqlənir. Yanaşma seçimi layihənin ölçüsündən, dəyişikliklərin tezliyindən və CI boru xəttində mövcud vaxtdan asılıdır. Aşağıda reqressiya testinin əsas növləri xüsusiyyətləri ilə verilmişdir.

Tam reqressiya testi

Tam reqressiya qaçışı istisnasız olaraq layihənin bütün avtomatlaşdırılmış testlərini yerinə yetirir. Bu yanaşma maksimum əminlik verir, lakin əhəmiyyətli hesablama resursları və vaxt tələb edir. Tam qaçış böyük buraxılışlardan əvvəl — 2–4 həftədə bir dəfə yerinə yetirilir. 5000 testi olan bir tətbiq üçün tam qaçış infrastrukturdan asılı olaraq 2 saatdan 6 saata qədər çəkir.

Seçmə reqressiya testi

Seçmə yanaşma yalnız dəyişdirilmiş modullarla əlaqəli testləri işə salır. Əlaqəliliyi müəyyən etmək üçün kod səviyyəsində asılılıq təhlilindən istifadə olunur: UserRepository sinfi dəyişdirilmişsə, UserRepository-dən birbaşa və ya tranzitiv olaraq asılı olan testlər işə salınır. Jacoco, Android Test Coverage və Xcode Code Coverage alətləri dəqiq seçim üçün əhatə xəritələri təqdim edir. Seçmə qaçış hər pull requestdə yerinə yetirilir və 5–15 dəqiqə çəkir.

Risk əsaslı reqressiya

Risk əsaslı reqressiya testləri funksionallığın kritikliyinə və sınma ehtimalına görə sıralayır. Kritik funksiyalar — ödəniş, avtorizasiya, sinxronizasiya — hər kod dəyişikliyində test edilir. Köməkçi funksiyalar — „Tətbiq haqqında” ekranı, animasiyalar — yalnız buraxılışdan əvvəl test edilir. Sıralama istehsal insidentləri haqqında məlumatlar əsasında rübdə bir dəfə yenidən nəzərdən keçirilir.

Reqressiya testi retestdən nə ilə fərqlənir

Reqressiya testi və retest anlayışları tez-tez qarışdırılır, baxmayaraq ki, bunlar fərqli proseslərdir. Retest — qüsur düzəldildikdən sonra əvvəllər uğursuz olmuş konkret testin təkrar işə salınmasıdır. Retestin məqsədi düzəlişin işlədiyinə əmin olmaqdır: səhv artıq təkrarlanmır. Retest bir dəfə, düzəlişdən və proqramçı tərəfindən təsdiqləndikdən dərhal sonra yerinə yetirilir.

Reqressiya testi — DƏYİŞMƏMİŞ mövcud funksionallıq üzrə testlərin işə salınmasıdır. Məqsəd bir qüsurun düzəldilməsinin başqa yerdə yeni qüsur yaratmadığına əmin olmaqdır. Reqressiya testləri hansı konkret səhvlərin düzəldilməsindən asılı olmayaraq hər inkişaf dövründə dəfələrlə işə salınır. Əsas fərq: retest düzəlişin özünü yoxlayır, reqressiya düzəlişin nəticələrini yoxlayır.

CI/CD boru xəttində hər iki proses ardıcıl yerinə yetirilir. Pull request birləşdirildikdən sonra konkret səhvin retesti, daha sonra tam və ya seçmə reqressiya qaçışı işə salınır. SmartBear (2022) məlumatlarına görə, bu proseslərin ayrılması uğursuz CI qaçışlarının diaqnostika müddətini 30% azaldır, çünki komanda dərhal qüsurların hansı hissəsinin reqressiya ilə, hansının isə işləməyən düzəlişlərlə bağlı olduğunu görür.

Reqressiya testinin avtomatlaşdırılması

Reqressiya testinin avtomatlaşdırılması müasir mobil layihələr üçün kritik uğur amilidir. Əl ilə reqressiya testi miqyaslanmır: 200 testlik dəstlə bir qaçış üçün QA mühəndisinin 2–3 iş günü tələb olunur ki, bu da gündəlik qaçışları qeyri-mümkün edir. Avtomatlaşdırılmış reqressiya testləri insan iştirakı olmadan 10–60 dəqiqə ərzində yerinə yetirilir və hər commit və ya pull requestdə işə salınmağa imkan verir.

• Vahid testlər — reqressiya dəstinin əsası (70%). Saniyələr ərzində yerinə yetirilir, emulyator tələb etmir, qırılan sinfi dəqiq göstərir.
• İnteqrasiya testləri — ikinci səviyyə (20%). Şəbəkə qatını, verilənlər bazasını və idarə olunan asılılıqları olan sistem xidmətlərini yoxlayır.
• UI və E2E testləri — piramidanın zirvəsi (10%). Kritik istifadəçi ssenarilərini əhatə edir: qeydiyyat, ödəniş, sinxronizasiya.

Reqressiya dəstini aktual vəziyyətdə saxlamaq üçün test analitikası istifadə olunur: Allure, ReportPortal və Xray kimi alətlər hər bir testin keçmə faizini, müddətini və sabitliyini izləyir. Sabitliyi 90%-dən aşağı düşən testlər (tələblərdəki dəyişikliklər səbəbindən tez-tez sınır) legacy olaraq qeyd olunur və sahibi tərəfindən yenidən baxılmağa göndərilir.

Reqressiya testinin qurulması nümunəsi

JUnit 5 kitabxanası və Espresso ilə Android-də avtomatlaşdırılmış reqressiya testinin qurulmasını nəzərdən keçirək. Nümunə seçmə reqressiyanı göstərir — test istifadəçi repozitoriyasının refaktorinqindən sonra profil ekranının pozulmadığını yoxlayır. iOS üçün eyni məntiqlə XCTest istifadə olunur — əsas ssenari üzrə təkrarlanan test.

Android: profil üçün reqressiya testi

Test server emulyasiyası üçün MockWebServer istifadə edir və tam yolu yoxlayır: istifadəçi məlumatlarının yüklənməsi, profil ekranında göstərilməsi və server əlçatmaz olduqda xətanın idarə edilməsi. Bu cür testlər reqressiya dəstinə daxil edilir və module-profile-dəki hər dəyişiklikdə yerinə yetirilir.

@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ükləmə xətası").assertIsDisplayed()
    }
}

iOS: XCTest ilə reqressiya testi

iOS üçün reqressiya testi API-dən məlumat alındıqdan sonra UI yenilənməsinin asinxron yoxlanılması üçün XCTestExpectation istifadə edir. Test şəbəkə cavabını emulyasiya edir və UI elementlərinin düzgün yeniləndiyini yoxlayır.

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)
    }
}

Reqressiya dəstinin qurulması strategiyası

Səmərəli reqressiya dəstinin qurulması qüsurlar və kod dəyişiklikləri haqqında məlumatlara əsaslanan iterativ prosesdir. İlkin strategiya — bütün mövcud testləri reqressiya dəstinə daxil etmək və hər buraxılışdan əvvəl tam qaçışı işə salmaqdır. Test bazası böyüdükcə (2000 testdən yuxarı) tam qaçış çox uzun olur və seçmə yanaşma tələb olunur.

İkinci mərhələ — asılılıq təhlili alətlərinin tətbiqi: Android üçün Jacoco, iOS üçün Xcode Test Plan. Bu alətlər „test — sinif — metod” xəritəsini qurur və konkret dəyişiklikdən hansı testlərin təsirləndiyini müəyyən etməyə imkan verir. Əhatə təhlilinə əsaslanan seçmə qaçış Spotify Engineering (2022) məlumatlarına görə, reqressiyaların aşkarlanmasının 95% effektivliyini qoruyarkən icra müddətini 60–80% azaldır.

Üçüncü mərhələ — davamlı monitorinq və optimallaşdırma. 6 ay ərzində uğursuz olmayan testlər aşağı prioritet dəstinə köçürülür. Ayda bir dəfədən çox uğursuz olan testlər yenidən baxılmağa namizəddir: ya real problemləri tutur (düzəliş tələb edir), ya da çox kövrəkdir (sabitləşdirmə tələb edir). Reqressiya dəstinin rüblük reviziyası onun effektivliyini və icra sürətini saxlamaq üçün standart təcrübədir.