Регресионо тестирање у мобилном развоју — шта је то, врсте и како се спроводи

Шта је регресионо тестирање?

Регресионо тестирање је врста тестирања усмерена на потврду да измене у коду нису нарушиле постојећу функционалност. Термин „регресија“ значи повратак у горе стање — када функција која је радила у претходној верзији престане да ради у новој. Регресиони тестови се извршавају више пута у сваком развојном циклусу, што их разликује од тестова нове функционалности који се пишу једнократно.

Потреба за регресионим тестирањем произилази из ефекта каскадних измена: исправка грешке у једном модулу може решити проблем, али покварити суседну функционалност која је зависила од њега. На пример, измена SQL упита у репозиторијуму корисника може убрзати пријаву, али покварити извоз података који је користио исти упит. Регресиони тест извоза података откриће ово кршење пре издања.

Према извештају CISQ 2023, цена исправке регресионог дефекта откривеног у производњи је 15 пута већа него у фази аутоматизованог регресионог прогона. Компаније које инвестирају у аутоматизовано регресионо тестирање смањују удео регресионих дефеката у издањима са 25% на 5% у року од годину дана након имплементације, према Capgemini World Quality Report.

Врсте регресионог тестирања

Постоји неколико приступа регресионом тестирању који се разликују по обиму и критеријумима одабира тестова. Избор приступа зависи од величине пројекта, учесталости измена и доступног времена у CI цевоводу. Испод су наведене главне врсте регресионог тестирања са њиховим карактеристикама.

Потпуно регресионо тестирање

Потпун регресиони прогон извршава све аутоматизоване тестове пројекта без изузетка. Овај приступ даје максималну сигурност, али захтева значајне рачунарске ресурсе и време. Потпун прогон се извршава пре великих издања — једном у 2–4 недеље. За апликацију са 5000 тестова, потпун прогон траје од 2 до 6 сати у зависности од инфраструктуре.

Селективно регресионо тестирање

Селективни приступ покреће само тестове повезане са измењеним модулима. За утврђивање повезаности користи се анализа зависности на нивоу кода: ако је измењена класа UserRepository, покрећу се тестови који зависе од UserRepository директно или транзитивно. Алати Jacoco, Android Test Coverage и Xcode Code Coverage пружају мапе покривености за прецизан одабир. Селективни прогон се извршава на сваки pull request и траје 5–15 минута.

Регресија заснована на ризику

Risk-based регресија рангира тестове по критичности функционалности и вероватноћи лома. Критичне функције — плаћање, ауторизација, синхронизација — тестирају се при свакој измени кода. Помоћне функције — екран „О апликацији“, анимације — тестирају се само пре издања. Рангирање се преиспитује квартално на основу података о производним инцидентима.

Чим се регресионо тестирање разликује од ретеста

Често се појмови регресионог тестирања и ретеста мешају, иако су то различити процеси. Ретест је поновно покретање одређеног теста који је раније пао, након исправке дефекта. Циљ ретеста је да се увери да исправка ради: грешка се више не репродукује. Ретест се извршава једнократно, одмах након поправке и потврде поправке од стране програмера.

Регресионо тестирање је покретање тестова на постојећу функционалност која НИЈЕ мењана. Циљ је да се увери да исправка једног дефекта није створила нови дефект на другом месту. Регресиони тестови се покрећу више пута у сваком развојном циклусу, независно од тога које су конкретне грешке поправљане. Главна разлика: ретест проверава саму поправку, регресија проверава последице поправке.

У CI/CD цевоводу оба процеса се извршавају секвенцијално. Након спајања pull request-а, покреће се ретест конкретне грешке, а затим потпун или селективни регресиони прогон. Према SmartBear (2022), раздвајање ових процеса смањује време дијагностике неуспелих CI прогона за 30%, јер тим одмах види који део дефеката је повезан са регресијом, а који са нерадећим поправкама.

Аутоматизација регресионог тестирања

Аутоматизација регресионог тестирања је критичан фактор успеха за савремене мобилне пројекте. Ручно регресионо тестирање није скалабилно: при сету од 200 тестова за један прогон потребно је 2–3 радна дана QA инжењера, што онемогућава дневне прогоне. Аутоматизовани регресиони тестови се извршавају за 10–60 минута без учешћа човека, што омогућава покретање при сваком комиту или pull request-у.

• Модуларни тестови — основа регресионог сета (70%). Извршавају се за секунде, не захтевају емулатор, дају прецизну индикацију сломљене класе.
• Интеграциони тестови — други ниво (20%). Проверавају мрежни слој, базу података и системске сервисе са контролисаним зависностима.
• UI и E2E тестови — врх пирамиде (10%). Покривају критичне корисничке сценарије: регистрацију, плаћање, синхронизацију.

За одржавање регресионог сета у ажурном стању користи се тест аналитика: алати попут Allure, ReportPortal и Xray прате проценат проласка, трајање и стабилност сваког теста. Тестови чија стабилност пада испод 90% (често се ломе због измена у захтевима) означавају се као legacy и упућују се на преиспитивање власнику.

Пример подешавања регресионог теста

Размотримо подешавање аутоматизованог регресионог теста на Android-у коришћењем библиотеке JUnit 5 и Espresso. Пример демонстрира селективну регресију — тест проверава да након рефакторинга репозиторијума корисника није покварен екран профила. За iOS се користи XCTest са аналогном логиком — понављајући тест на кључном сценарију.

Android: регресиони тест профила

Тест користи MockWebServer за емулацију сервера и проверава пун пут: учитавање података о кориснику, приказ на екрану профила и обраду грешке када сервер није доступан. Такви тестови се укључују у регресиони сет и извршавају при свакој измени у module-profile.

@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("Greška učitavanja").assertIsDisplayed()
    }
}

iOS: регресиони тест са XCTest

За iOS регресиони тест користи XCTestExpectation за асинхрону проверу ажурирања UI након добијања података од API-ја. Тест емулира мрежни одговор и проверава да су UI елементи ажурирани исправно.

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

Стратегија изградње регресионог сета

Изградња ефикасног регресионог сета је итеративни процес заснован на подацима о дефектима и изменама кода. Примарна стратегија — укључити све постојеће тестове у регресиони сет и покретати пун прогон пре сваког издања. Како тест база расте (преко 2000 тестова), пун прогон постаје предуг и захтева се селективни приступ.

Друга фаза — увођење алата за анализу зависности: Jacoco за Android, Xcode Test Plan за iOS. Ови алати граде мапу „тест — класа — метод“ и омогућавају одређивање који тестови су погођени одређеном изменом. Селективни прогон заснован на анализи покривености смањује време извршења за 60–80% уз задржавање 95% ефикасности откривања регресија, према Spotify Engineering (2022).

Трећа фаза — континуирани мониторинг и оптимизација. Тестови који нису пали 6 месеци премештају се у нископриоритетни сет. Тестови који падају чешће од једном месечно су кандидати за преиспитивање: или хватају стварне проблеме (захтевају поправку), или су превише крхки (захтевају стабилизацију). Квартална ревизија регресионог сета је стандардна пракса за одржавање његове ефикасности и брзине извршења.