Mobil ishlanmada regressiya testi — bu nima, turlari va qanday o'tkaziladi

Regressiya testi nima?

Regressiya testi — koddagi o'zgarishlar mavjud funksionallikni buzmagani haqida tasdiqlashga qaratilgan test turi. „Regressiya” atamasi yomonroq holatga qaytishni anglatadi — oldingi versiyada ishlagan funksiya yangi versiyada ishlamay qolganda. Regressiya testlari har bir rivojlanish siklida qayta-qayta bajariladi, bu ularni bir marta yoziladigan yangi funksionallik testlaridan farqlaydi.

Regressiya testiga ehtiyoj kaskad o'zgarishlar ta'siridan kelib chiqadi: bir moduldagi xatoni tuzatish muammoni hal qilishi mumkin, ammo unga bog'liq bo'lgan qo'shni funksionallikni buzishi mumkin. Masalan, foydalanuvchi repozitoriyasidagi SQL so'rovini o'zgartirish kirishni tezlashtirishi mumkin, ammo xuddi shu so'rovdan foydalangan ma'lumotlarni eksport qilishni buzishi mumkin. Ma'lumotlarni eksport qilish bo'yicha regressiya testi bu buzilishni chiqarishdan oldin aniqlaydi.

CISQ 2023 hisobotiga ko'ra, ishlab chiqarishda aniqlangan regressiya nuqsonini tuzatish narxi avtomatlashtirilgan regressiya yugurish bosqichidan 15 baravar yuqori. Avtomatlashtirilgan regressiya testiga sarmoya kiritadigan kompaniyalar Capgemini World Quality Report ma'lumotlariga ko'ra, joriy etilgandan so'ng bir yil ichida chiqarishlardagi regressiya nuqsonlarining ulushini 25% dan 5% gacha kamaytiradi.

Regressiya testining turlari

Regressiya testiga bir necha yondashuvlar mavjud bo'lib, ular hajm va test tanlash mezonlariga ko'ra farqlanadi. Yondashuvni tanlash loyihaning hajmiga, o'zgarishlar chastotasiga va CI quvuridagi mavjud vaqtga bog'liq. Quyida regressiya testining asosiy turlari ularning xususiyatlari bilan keltirilgan.

To'liq regressiya testi

To'liq regressiya yugurishi loyihaning barcha avtomatlashtirilgan testlarini istisnosiz bajaradi. Bu yondashuv maksimal ishonch beradi, ammo sezilarli hisoblash resurslari va vaqt talab qiladi. To'liq yugurish katta chiqarishlardan oldin — 2–4 haftada bir marta bajariladi. 5000 testli ilova uchun to'liq yugurish infratuzilmaga qarab 2 soatdan 6 soatgacha davom etadi.

Tanlab regressiya testi

Tanlab yondashuv faqat o'zgartirilgan modullar bilan bog'liq testlarni ishga tushiradi. Bog'liqlikni aniqlash uchun kod darajasida bog'liqlik tahlilidan foydalaniladi: agar UserRepository sinfi o'zgartirilgan bo'lsa, UserRepository ga to'g'ridan-to'g'ri yoki tranzitiv bog'liq testlar ishga tushiriladi. Jacoco, Android Test Coverage va Xcode Code Coverage vositalari aniq tanlash uchun qamrov xaritalarini taqdim etadi. Tanlab yugurish har bir pull requestda bajariladi va 5–15 daqiqa davom etadi.

Riskga asoslangan regressiya

Riskga asoslangan regressiya testlarni funksionallikning muhimligi va buzilish ehtimoli bo'yicha tartiblaydi. Muhim funksiyalar — to'lov, avtorizatsiya, sinxronizatsiya — har bir kod o'zgarishida test qilinadi. Yordamchi funksiyalar — „Ilova haqida” ekrani, animatsiyalar — faqat chiqarishdan oldin test qilinadi. Tartiblash ishlab chiqarish insidentlari haqidagi ma'lumotlar asosida har chorakda qayta ko'rib chiqiladi.

Regressiya testi retestdan nimasi bilan farq qiladi

Regressiya testi va retest tushunchalari ko'pincha aralashtiriladi, garchi ular turli jarayonlar bo'lsa ham. Retest — nuqson tuzatilgandan so'ng avval muvaffaqiyatsiz bo'lgan aniq testni qayta ishga tushirish. Retestning maqsadi tuzatish ishlayotganiga ishonch hosil qilishdir: xato endi takrorlanmaydi. Retest bir marta, tuzatish va dasturchi tomonidan tasdiqlanganidan so'ng darhol bajariladi.

Regressiya testi — O'ZGARTIRILMAGAN mavjud funksionallik bo'yicha testlarni ishga tushirish. Maqsad bir nuqsonni tuzatish boshqa joyda yangi nuqson yaratmaganligiga ishonch hosil qilishdir. Regressiya testlari qanday aniq xatolar tuzatilganidan qat'i nazar, har bir rivojlanish siklida qayta-qayta ishga tushiriladi. Asosiy farq: retest tuzatishning o'zini tekshiradi, regressiya tuzatishning oqibatlarini tekshiradi.

CI/CD quvurida ikkala jarayon ketma-ket bajariladi. Pull request birlashtirilgandan so'ng aniq xatoning retesti, so'ngra to'liq yoki tanlab regressiya yugurishi ishga tushiriladi. SmartBear (2022) ma'lumotlariga ko'ra, bu jarayonlarni ajratish muvaffaqiyatsiz CI yugurishlarini diagnostika qilish vaqtini 30% ga qisqartiradi, chunki jamoa darhol nuqsonlarning qaysi qismi regressiya bilan, qaysi qismi ishlamaydigan tuzatishlar bilan bog'liqligini ko'radi.

Regressiya testini avtomatlashtirish

Regressiya testini avtomatlashtirish zamonaviy mobil loyihalar uchun muvaffaqiyatning muhim omilidir. Qo'lda regressiya testi masshtablanmaydi: 200 testli to'plam bilan bitta yugurish uchun QA muhandisining 2–3 ish kuni kerak bo'ladi, bu esa kundalik yugurishlarni imkonsiz qiladi. Avtomatlashtirilgan regressiya testlari inson ishtirokisiz 10–60 daqiqa ichida bajariladi va har bir commit yoki pull requestda ishga tushirishga imkon beradi.

• Birlik testlari — regressiya to'plamining asosi (70%). Bir necha soniyada bajariladi, emulyator talab qilmaydi, buzilgan sinfni aniq ko'rsatadi.
• Integratsiya testlari — ikkinchi daraja (20%). Tarmoq qatlamini, ma'lumotlar bazasini va boshqariladigan bog'liqliklarga ega tizim xizmatlarini tekshiradi.
• UI va E2E testlari — piramidaning cho'qqisi (10%). Muhim foydalanuvchi stsenariylarini qamrab oladi: ro'yxatdan o'tish, to'lov, sinxronizatsiya.

Regressiya to'plamini yangi holatda saqlash uchun test analitikasi ishlatiladi: Allure, ReportPortal va Xray kabi vositalar har bir testning o'tish foizini, davomiyligini va barqarorligini kuzatadi. Barqarorligi 90% dan pastga tushadigan testlar (talablar o'zgarishi sababli tez-tez buziladi) legacy deb belgilanadi va egasi tomonidan qayta ko'rib chiqishga yuboriladi.

Regressiya testini sozlash namunasi

JUnit 5 kutubxonasi va Espresso yordamida Android-da avtomatlashtirilgan regressiya testini sozlashni ko'rib chiqaylik. Misol tanlab regressiyani ko'rsatadi — test foydalanuvchi repozitoriyasi refaktoringidan so'ng profil ekrani buzilmaganligini tekshiradi. iOS uchun xuddi shunday mantiq bilan XCTest ishlatiladi — asosiy stsenariy bo'yicha takrorlanadigan test.

Android: profil uchun regressiya testi

Test server emulyatsiyasi uchun MockWebServer dan foydalanadi va to'liq yo'lni tekshiradi: foydalanuvchi ma'lumotlarini yuklash, profil ekranida ko'rsatish va server mavjud bo'lmaganda xatoni boshqarish. Bunday testlar regressiya to'plamiga kiritiladi va module-profile dagi har bir o'zgarishda bajariladi.

@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("Yuklash xatosi").assertIsDisplayed()
    }
}

iOS: XCTest bilan regressiya testi

iOS uchun regressiya testi API dan ma'lumot olingandan so'ng UI yangilanishini asinxron tekshirish uchun XCTestExpectation dan foydalanadi. Test tarmoq javobini emulyatsiya qiladi va UI elementlarining to'g'ri yangilanganligini tekshiradi.

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

Regressiya to'plamini qurish strategiyasi

Samarali regressiya to'plamini qurish nuqsonlar va kod o'zgarishlari haqidagi ma'lumotlarga asoslangan takrorlanuvchi jarayondir. Boshlang'ich strategiya — barcha mavjud testlarni regressiya to'plamiga kiritish va har bir chiqarishdan oldin to'liq yugurishni ishga tushirish. Test bazasi o'sib (2000 testdan yuqori) to'liq yugurish juda uzun bo'lib qoladi va tanlab yondashuv talab qilinadi.

Ikkinchi bosqich — bog'liqlik tahlili vositalarini joriy etish: Android uchun Jacoco, iOS uchun Xcode Test Plan. Bu vositalar „test — sinf — metod” xaritasini quradi va aniq o'zgarishdan qaysi testlar ta'sirlanganligini aniqlashga imkon beradi. Qamrov tahliliga asoslangan tanlab yugurish Spotify Engineering (2022) ma'lumotlariga ko'ra, regressiyalarni aniqlash samaradorligini 95% saqlagan holda bajarilish vaqtini 60–80% ga qisqartiradi.

Uchinchi bosqich — doimiy monitoring va optimallashtirish. 6 oy davomida muvaffaqiyatsiz bo'lmagan testlar past ustuvor to'plamga o'tkaziladi. Oyiga bir martadan ko'proq muvaffaqiyatsiz bo'lgan testlar qayta ko'rib chiqishga nomzoddir: yoki real muammolarni tutadi (tuzatish talab qiladi), yoki juda mo'rt (barqarorlashtirish talab qiladi). Regressiya to'plamining har choraklik reviziyasi uning samaradorligi va bajarilish tezligini saqlash uchun standart amaliyotdir.