모바일 개발에서의 회귀 테스트 — 정의, 유형 및 수행 방법

회귀 테스트란?

회귀 테스트는 코드 변경이 기존 기능을 손상시키지 않았는지 확인하기 위한 테스트 유형입니다. “회귀”라는 용어는 이전 버전에서 작동하던 기능이 새 버전에서 작동하지 않게 되는 더 나쁜 상태로의 복귀를 의미합니다. 회귀 테스트는 각 개발 주기에서 반복적으로 실행되며, 한 번만 작성되는 새 기능 테스트와 구분됩니다.

회귀 테스트의 필요성은 연쇄 변경 효과에서 비롯됩니다. 한 모듈의 버그를 수정하면 문제가 해결될 수 있지만, 이에 의존하던 인접 기능이 손상될 수 있습니다. 예를 들어, 사용자 리포지토리의 SQL 쿼리를 변경하면 인증 속도가 빨라질 수 있지만, 동일한 쿼리를 사용하던 데이터 내보내기가 손상될 수 있습니다. 데이터 내보내기에 대한 회귀 테스트는 릴리스 전에 이 문제를 발견합니다.

CISQ 2023 보고서에 따르면, 프로덕션에서 발견된 회귀 결함을 수정하는 비용은 자동화된 회귀 실행 단계보다 15배 높습니다. Capgemini World Quality Report에 따르면, 자동화된 회귀 테스트에 투자하는 기업은 도입 후 1년 이내에 릴리스의 회귀 결함 비율을 25%에서 5%로 줄입니다.

회귀 테스트의 유형

회귀 테스트에는 범위와 테스트 선택 기준이 다른 여러 접근 방식이 있습니다. 접근 방식의 선택은 프로젝트 규모, 변경 빈도, CI 파이프라인에서 사용 가능한 시간에 따라 달라집니다. 아래는 특성과 함께 주요 회귀 테스트 유형입니다.

전체 회귀 테스트

전체 회귀 실행은 예외 없이 프로젝트의 모든 자동화된 테스트를 실행합니다. 이 접근 방식은 최대한의 확신을 제공하지만 상당한 컴퓨팅 리소스와 시간이 필요합니다. 전체 실행은 주요 릴리스 전(2~4주마다) 수행됩니다. 5000개의 테스트가 있는 애플리케이션의 경우 전체 실행은 인프라에 따라 2~6시간이 소요됩니다.

선택적 회귀 테스트

선택적 접근 방식은 변경된 모듈과 관련된 테스트만 실행합니다. 관련성을 결정하기 위해 코드 수준의 종속성 분석이 사용됩니다. UserRepository 클래스가 변경되면 UserRepository에 직간접적으로 종속된 테스트가 실행됩니다. Jacoco, Android Test Coverage 및 Xcode Code Coverage와 같은 도구는 정확한 선택을 위한 커버리지 맵을 제공합니다. 선택적 실행은 각 풀 리퀘스트에서 수행되며 5~15분이 소요됩니다.

위험 기반 회귀

위험 기반 회귀는 기능의 중요성과 손상 가능성에 따라 테스트의 우선순위를 지정합니다. 중요한 기능(결제, 인증, 동기화)은 모든 코드 변경 시 테스트됩니다. 보조 기능(“정보” 화면, 애니메이션)은 릴리스 전에만 테스트됩니다. 순위는 프로덕션 장애 데이터를 기반으로 분기별로 검토됩니다.

회귀 테스트와 재테스트의 차이

회귀 테스트와 재테스트의 개념은 서로 다른 프로세스임에도 불구하고 자주 혼동됩니다. 재테스트는 결함 수정 후 이전에 실패한 특정 테스트를 다시 실행하는 것입니다. 재테스트의 목적은 수정 사항이 작동하는지 확인하는 것입니다. 버그가 더 이상 재현되지 않는지 확인합니다. 재테스트는 수정 및 개발자의 수정 확인 직후에 한 번 수행됩니다.

회귀 테스트는 변경되지 않은 기존 기능에 대한 테스트를 실행하는 것입니다. 목표는 하나의 결함을 수정해도 다른 곳에서 새 결함이 발생하지 않았는지 확인하는 것입니다. 회귀 테스트는 어떤 특정 버그가 수정되었는지에 관계없이 각 개발 주기에서 반복적으로 실행됩니다. 주요 차이점: 재테스트는 수정 자체를 검증하고, 회귀는 수정의 결과를 검증합니다.

CI/CD 파이프라인에서는 두 프로세스가 순차적으로 실행됩니다. 풀 리퀘스트를 병합한 후 특정 버그의 재테스트가 실행되고, 이어서 전체 또는 선택적 회귀 실행이 수행됩니다. SmartBear(2022)에 따르면, 이러한 프로세스를 분리하면 실패한 CI 실행 진단 시간이 30% 단축됩니다. 팀이 어떤 결함이 회귀와 관련되고 어떤 결함이 작동하지 않는 수정과 관련되는지 즉시 확인할 수 있기 때문입니다.

회귀 테스트 자동화

회귀 테스트 자동화는 현대 모바일 프로젝트의 중요한 성공 요소입니다. 수동 회귀 테스트는 확장이 불가능합니다. 200개 테스트의 스위트에서 한 번 실행하는 데 QA 엔지니어의 2~3일이 필요하므로 매일 실행이 불가능합니다. 자동화된 회귀 테스트는 사람의 개입 없이 10~60분 안에 실행되므로 모든 커밋 또는 풀 리퀘스트에서 실행할 수 있습니다.

• 단위 테스트 — 회귀 스위트의 기초(70%). 몇 초 안에 실행되며 에뮬레이터가 필요 없고 손상된 클래스를 정확히 지적합니다.
• 통합 테스트 — 두 번째 수준(20%). 제어된 종속성으로 네트워크 계층, 데이터베이스 및 시스템 서비스를 확인합니다.
• UI 테스트 및 E2E 테스트 — 피라미드의 정점(10%). 등록, 결제, 동기화 등의 중요한 사용자 시나리오를 다룹니다.

회귀 스위트를 최신 상태로 유지하기 위해 테스트 분석이 사용됩니다. Allure, ReportPortal 및 Xray와 같은 도구는 각 테스트의 통과율, 기간 및 안정성을 추적합니다. 안정성이 90% 미만으로 떨어지는 테스트(요구 사항 변경으로 인해 자주 실패)는 레거시로 표시되고 검토를 위해 소유자에게 할당됩니다.

회귀 테스트 설정 예시

JUnit 5 라이브러리와 Espresso를 사용하여 Android에서 자동화된 회귀 테스트를 설정하는 방법을 살펴보겠습니다. 이 예시는 선택적 회귀를 보여줍니다. 사용자 리포지토리를 리팩토링한 후 프로필 화면이 손상되지 않았는지 테스트가 확인합니다. 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("로딩 오류").assertIsDisplayed()
    }
}

iOS: XCTest를 사용한 회귀 테스트

iOS의 경우 회귀 테스트는 XCTestExpectation을 사용하여 API에서 데이터를 수신한 후 UI 업데이트를 비동기적으로 확인합니다. 테스트는 네트워크 응답을 에뮬레이션하고 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개 테스트 초과) 전체 실행이 너무 길어져 선택적 접근 방식이 필요합니다.

두 번째 단계 — 종속성 분석 도구 도입: Android용 Jacoco, iOS용 Xcode Test Plan. 이러한 도구는 “테스트 — 클래스 — 메서드” 맵을 구축하고 특정 변경에 의해 어떤 테스트가 영향을 받는지 결정할 수 있게 합니다. Spotify Engineering(2022)에 따르면, 커버리지 분석 기반 선택적 실행은 95%의 회귀 탐지 효과를 유지하면서 실행 시간을 60~80% 단축합니다.

세 번째 단계 — 지속적인 모니터링 및 최적화. 6개월 동안 실패하지 않은 테스트는 낮은 우선순위 스위트로 이동됩니다. 월 1회 이상 실패하는 테스트는 검토 대상입니다. 실제 문제를 포착하는 경우(수정 필요)이거나 너무 취약한 경우(안정화 필요)입니다. 회귀 스위트의 분기별 검토는 효과성과 실행 속도를 유지하기 위한 표준 관행입니다.