Regression Testing sa Mobile Development — ano ito, mga uri at kung paano ito isinasagawa

Ano ang regression testing?

Ang regression testing ay isang uri ng pagsusuri na naglalayong kumpirmahin na ang mga pagbabago sa code ay hindi nakaapekto sa umiiral na functionality. Ang terminong „regression” ay nangangahulugang pagbabalik sa mas masamang estado — kapag ang isang function na gumagana sa nakaraang bersyon ay huminto sa paggana sa bago. Ang regression tests ay isinasagawa nang maraming beses sa bawat development cycle, na nagpapahiwalay sa kanila mula sa mga pagsusulit ng bagong functionality na isinusulat nang isang beses lamang.

Ang pangangailangan para sa regression testing ay nagmumula sa epekto ng mga cascading na pagbabago: ang pag-aayos ng bug sa isang module ay maaaring malutas ang problema ngunit masira ang katabing functionality na nakadepende dito. Halimbawa, ang pagbabago ng SQL query sa user repository ay maaaring mapabilis ang pag-login ngunit masira ang data export na gumamit ng parehong query. Ang regression test sa data export ay makakatuklas ng paglabag na ito bago ang release.

Ayon sa ulat ng CISQ 2023, ang gastos sa pag-aayos ng regression defect na natuklasan sa produksyon ay 15 beses na mas mataas kaysa sa yugto ng automated regression run. Ang mga kumpanyang namumuhunan sa automated regression testing ay nagbabawas ng bahagi ng regression defects sa mga release mula 25% hanggang 5% sa loob ng isang taon pagkatapos ng implementasyon, ayon sa Capgemini World Quality Report.

Mga uri ng regression testing

Mayroong ilang mga approach sa regression testing, na nagkakaiba sa dami at pamantayan ng pagpili ng pagsusulit. Ang pagpili ng approach ay depende sa laki ng proyekto, dalas ng mga pagbabago at magagamit na oras sa CI pipeline. Sa ibaba ay ang mga pangunahing uri ng regression testing kasama ang kanilang mga katangian.

Buong regression testing

Ang buong regression run ay nagsasagawa ng lahat ng automated na pagsusulit ng proyekto nang walang pagbubukod. Ang approach na ito ay nagbibigay ng maximum na katiyakan ngunit nangangailangan ng malaking computing resources at oras. Ang buong run ay isinasagawa bago ang malalaking release — isang beses bawat 2–4 na linggo. Para sa isang application na may 5000 pagsusulit, ang buong run ay tumatagal ng 2 hanggang 6 na oras depende sa imprastraktura.

Piling regression testing

Ang piling approach ay nagpapatakbo lamang ng mga pagsusulit na may kaugnayan sa mga binagong module. Para sa pagtukoy ng kaugnayan, ginagamit ang dependency analysis sa antas ng code: kung ang klase na UserRepository ay binago, ang mga pagsusulit na nakadepende sa UserRepository nang direkta o transitibo ay pinapatakbo. Ang mga tool na Jacoco, Android Test Coverage at Xcode Code Coverage ay nagbibigay ng coverage maps para sa tumpak na pagpili. Ang piling run ay isinasagawa sa bawat pull request at tumatagal ng 5–15 minuto.

Risk-based regression

Ang risk-based regression ay nagra-rank ng mga pagsusulit batay sa kritikalidad ng functionality at posibilidad ng pagkasira. Ang mga kritikal na function — pagbabayad, awtorisasyon, synchronization — ay sinusuri sa bawat pagbabago ng code. Ang mga pantulong na function — screen na „Tungkol sa Application”, mga animation — ay sinusuri lamang bago ang release. Ang ranking ay sinusuri kada quarter batay sa data ng mga insidente sa produksyon.

Pagkakaiba ng regression testing sa retest

Madalas na napagkakamalan ang mga konsepto ng regression testing at retest, kahit na magkaibang proseso ang mga ito. Ang retest ay ang muling pagpapatakbo ng isang partikular na pagsusulit na dati nang nabigo, pagkatapos ng pag-aayos ng depekto. Ang layunin ng retest ay tiyakin na gumagana ang pag-aayos: hindi na na-uulit ang bug. Ang retest ay isinasagawa nang isang beses, kaagad pagkatapos ng pag-aayos at kumpirmasyon ng pag-aayos ng developer.

Ang regression testing ay ang pagpapatakbo ng mga pagsusulit sa umiiral na functionality na HINDI binago. Ang layunin ay tiyakin na ang pag-aayos ng isang depekto ay hindi lumikha ng bagong depekto sa ibang lugar. Ang regression tests ay pinapatakbo nang maraming beses sa bawat development cycle, anuman ang mga partikular na bug na naayos. Ang pangunahing pagkakaiba: sinusuri ng retest ang pag-aayos mismo, sinusuri ng regression ang mga kahihinatnan ng pag-aayos.

Sa CI/CD pipeline, ang parehong proseso ay isinasagawa nang sunud-sunod. Pagkatapos ma-merge ang pull request, ang retest ng partikular na bug ay pinapatakbo, na sinusundan ng buo o piling regression run. Ayon sa SmartBear (2022), ang paghihiwalay ng mga prosesong ito ay nagbabawas ng oras ng diagnostic ng mga nabigong CI run ng 30%, dahil nakikita agad ng team kung aling bahagi ng mga depekto ang nauugnay sa regression at alin sa hindi gumaganang pag-aayos.

Automation ng regression testing

Ang automation ng regression testing ay isang kritikal na salik ng tagumpay para sa mga modernong mobile project. Ang manual regression testing ay hindi scalable: sa isang set ng 200 pagsusulit, isang run ay nangangailangan ng 2–3 araw ng trabaho ng isang QA engineer, na ginagawang imposible ang araw-araw na runs. Ang automated regression tests ay isinasagawa sa loob ng 10–60 minuto nang walang interbensyon ng tao, na nagpapahintulot sa mga ito na patakbuhin sa bawat commit o pull request.

• Unit tests — pundasyon ng regression set (70%). Isinasagawa sa ilang segundo, hindi nangangailangan ng emulator, tumpak na nagpapahiwatig ng sirang klase.
• Integration tests — pangalawang antas (20%). Sinusuri ang network layer, database at system services na may kontroladong dependencies.
• UI at E2E tests — tuktok ng pyramid (10%). Sinasaklaw ang mga kritikal na senaryo ng user: pagpaparehistro, pagbabayad, synchronization.

Para mapanatili ang regression set sa napapanahong estado, ginagamit ang test analytics: mga tool tulad ng Allure, ReportPortal at Xray ay sumusubaybay sa mga porsyento ng pagpasa, tagal at katatagan ng bawat pagsusulit. Ang mga pagsusulit na ang katatagan ay bumaba sa ibaba 90% (madalas masira dahil sa mga pagbabago sa mga kinakailangan) ay minarkahan bilang legacy at ipinapadala para sa pagsusuri sa may-ari.

Halimbawa ng configuration ng regression test

Isaalang-alang natin ang configuration ng isang automated regression test sa Android gamit ang library na JUnit 5 at Espresso. Ipinapakita ng halimbawa ang piling regression — sinusuri ng pagsusulit na pagkatapos ng refactoring ng user repository, ang profile screen ay hindi nasira. Para sa iOS, ginagamit ang XCTest na may katulad na lohika — paulit-ulit na pagsusulit sa pangunahing senaryo.

Android: regression test ng profile

Ang pagsusulit ay gumagamit ng MockWebServer para sa emulation ng server at sinusuri ang buong landas: pag-load ng data ng user, pagpapakita sa profile screen at paghawak ng error kapag hindi available ang server. Ang mga ganitong pagsusulit ay isinasama sa regression set at isinasagawa sa bawat pagbabago sa 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("Error sa pag-load").assertIsDisplayed()
    }
}

iOS: regression test gamit ang XCTest

Para sa iOS, ang regression test ay gumagamit ng XCTestExpectation para sa asynchronous na pagsusuri ng pag-update ng UI pagkatapos makatanggap ng data mula sa API. Ginagaya ng pagsusulit ang network response at sinusuri na ang mga elemento ng UI ay na-update nang tama.

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

Estratehiya sa pagbuo ng regression set

Ang pagbuo ng epektibong regression set ay isang paulit-ulit na proseso batay sa data ng mga depekto at pagbabago ng code. Ang pangunahing estratehiya ay isama ang lahat ng umiiral na pagsusulit sa regression set at magpatakbo ng buong run bago ang bawat release. Habang lumalaki ang test base (higit sa 2000 pagsusulit), ang buong run ay nagiging masyadong mahaba at nangangailangan ng piling approach.

Ang ikalawang yugto — implementasyon ng mga tool sa dependency analysis: Jacoco para sa Android, Xcode Test Plan para sa iOS. Ang mga tool na ito ay bumubuo ng mapa ng „pagsusulit — klase — metodo” at nagpapahintulot na matukoy kung aling mga pagsusulit ang apektado ng isang partikular na pagbabago. Ang piling run batay sa coverage analysis ay nagbabawas ng oras ng pagpapatupad ng 60–80% habang pinapanatili ang 95% na epektibidad ng pagtuklas ng regression, ayon sa Spotify Engineering (2022).

Ang ikatlong yugto — patuloy na pagsubaybay at pag-optimize. Ang mga pagsusulit na hindi nabigo sa loob ng 6 na buwan ay inililipat sa mababang-priyoridad na set. Ang mga pagsusulit na nabigo nang higit sa isang beses bawat buwan ay mga kandidato para sa pagsusuri: maaaring nakakahuli sila ng mga tunay na problema (nangangailangan ng pag-aayos), o masyadong marupok (nangangailangan ng pagpapapanatag). Ang quarterly na pagsusuri ng regression set ay isang karaniwang kasanayan upang mapanatili ang epektibidad at bilis ng pagpapatupad nito.