Kiểm thử hồi quy trong phát triển ứng dụng di động — định nghĩa, các loại và cách thực hiện

Kiểm thử hồi quy là gì?

Kiểm thử hồi quy là một loại kiểm thử nhằm xác nhận rằng các thay đổi mã không làm hỏng chức năng hiện có. Thuật ngữ "hồi quy" có nghĩa là quay trở lại trạng thái tồi tệ hơn — khi một chức năng hoạt động ở phiên bản trước ngừng hoạt động ở phiên bản mới. Kiểm thử hồi quy được thực thi lặp đi lặp lại trong mỗi chu kỳ phát triển, điều này phân biệt chúng với kiểm thử tính năng mới chỉ được viết một lần.

Sự cần thiết của kiểm thử hồi quy xuất phát từ hiệu ứng thay đổi dây chuyền: việc sửa lỗi trong một mô-đun có thể giải quyết vấn đề nhưng làm hỏng chức năng liền kề phụ thuộc vào nó. Ví dụ, thay đổi truy vấn SQL trong kho lưu trữ người dùng có thể tăng tốc xác thực nhưng làm hỏng xuất dữ liệu sử dụng cùng truy vấn đó. Một kiểm thử hồi quy trên xuất dữ liệu sẽ phát hiện vi phạm này trước khi phát hành.

Theo báo cáo CISQ 2023, chi phí sửa lỗi hồi quy được phát hiện trong sản xuất cao gấp 15 lần so với giai đoạn chạy kiểm thử hồi quy tự động. Các công ty đầu tư vào kiểm thử hồi quy tự động giảm tỷ lệ lỗi hồi quy trong các bản phát hành từ 25% xuống 5% trong vòng một năm sau khi triển khai, theo Capgemini World Quality Report.

Các loại kiểm thử hồi quy

Có một số cách tiếp cận kiểm thử hồi quy khác nhau về phạm vi và tiêu chí lựa chọn kiểm thử. Việc lựa chọn cách tiếp cận phụ thuộc vào quy mô dự án, tần suất thay đổi và thời gian có sẵn trong đường ống CI. Dưới đây là các loại kiểm thử hồi quy chính cùng với đặc điểm của chúng.

Kiểm thử hồi quy toàn bộ

Chạy kiểm thử hồi quy toàn bộ thực thi tất cả các kiểm thử tự động của dự án mà không có ngoại lệ. Cách tiếp cận này mang lại sự tin cậy tối đa nhưng đòi hỏi tài nguyên tính toán và thời gian đáng kể. Một lần chạy toàn bộ được thực hiện trước các bản phát hành lớn — mỗi 2–4 tuần. Đối với ứng dụng có 5000 kiểm thử, một lần chạy toàn bộ mất từ 2 đến 6 giờ tùy thuộc vào cơ sở hạ tầng.

Kiểm thử hồi quy chọn lọc

Cách tiếp cận chọn lọc chỉ chạy các kiểm thử liên quan đến các mô-đun đã thay đổi. Để xác định mối liên quan, phân tích phụ thuộc ở cấp độ mã được sử dụng: nếu lớp UserRepository bị thay đổi, các kiểm thử phụ thuộc vào UserRepository trực tiếp hoặc gián tiếp sẽ được chạy. Các công cụ như Jacoco, Android Test Coverage và Xcode Code Coverage cung cấp bản đồ bao phủ để lựa chọn chính xác. Một lần chạy chọn lọc được thực hiện trên mỗi pull request và mất 5–15 phút.

Hồi quy dựa trên rủi ro

Hồi quy dựa trên rủi ro xếp hạng các kiểm thử theo mức độ quan trọng của chức năng và khả năng hỏng hóc. Các chức năng quan trọng — thanh toán, xác thực, đồng bộ hóa — được kiểm thử ở mọi thay đổi mã. Các chức năng phụ trợ — màn hình Giới thiệu, hoạt ảnh — chỉ được kiểm thử trước khi phát hành. Thứ hạng được xem xét hàng quý dựa trên dữ liệu sự cố sản xuất.

Sự khác biệt giữa kiểm thử hồi quy và kiểm thử lại

Các khái niệm kiểm thử hồi quy và kiểm thử lại thường bị nhầm lẫn, mặc dù chúng là các quy trình khác nhau. Kiểm thử lại là việc chạy lại một kiểm thử cụ thể đã thất bại trước đó, sau khi sửa lỗi. Mục đích của kiểm thử lại là xác nhận rằng việc sửa lỗi có hiệu quả: lỗi không còn tái diễn nữa. Kiểm thử lại được thực hiện một lần, ngay sau khi sửa lỗi và xác nhận sửa lỗi từ nhà phát triển.

Kiểm thử hồi quy là việc chạy các kiểm thử trên chức năng hiện tại KHÔNG bị thay đổi. Mục tiêu là đảm bảo rằng việc sửa một lỗi không tạo ra lỗi mới ở nơi khác. Kiểm thử hồi quy được chạy lặp đi lặp lại trong mỗi chu kỳ phát triển, bất kể những lỗi cụ thể nào đã được sửa. Sự khác biệt chính: kiểm thử lại xác minh bản sửa lỗi, hồi quy xác minh hậu quả của việc sửa lỗi.

Trong đường ống CI/CD, cả hai quy trình được thực hiện tuần tự. Sau khi hợp nhất pull request, một kiểm thử lại lỗi cụ thể được chạy, tiếp theo là chạy kiểm thử hồi quy toàn bộ hoặc chọn lọc. Theo SmartBear (2022), việc tách biệt các quy trình này giúp giảm 30% thời gian chẩn đoán các lần chạy CI thất bại, vì nhóm có thể thấy ngay lỗi nào liên quan đến hồi quy và lỗi nào liên quan đến bản sửa lỗi không hoạt động.

Tự động hóa kiểm thử hồi quy

Tự động hóa kiểm thử hồi quy là yếu tố thành công quan trọng cho các dự án di động hiện đại. Kiểm thử hồi quy thủ công không mở rộng được: với bộ 200 kiểm thử, một lần chạy cần 2–3 ngày làm việc của kỹ sư QA, khiến việc chạy hàng ngày là không thể. Kiểm thử hồi quy tự động chạy trong 10–60 phút mà không cần can thiệp thủ công, cho phép chạy chúng trên mọi commit hoặc pull request.

• Kiểm thử đơn vị — nền tảng của bộ hồi quy (70%). Chạy trong vài giây, không cần trình giả lập và xác định chính xác lớp bị hỏng.
• Kiểm thử tích hợp — cấp độ thứ hai (20%). Kiểm tra lớp mạng, cơ sở dữ liệu và dịch vụ hệ thống với các phụ thuộc được kiểm soát.
• Kiểm thử UI và E2E — đỉnh của kim tự tháp (10%). Bao phủ các kịch bản người dùng quan trọng: đăng ký, thanh toán, đồng bộ hóa.

Để giữ bộ hồi quy được cập nhật, phân tích kiểm thử được sử dụng: các công cụ như Allure, ReportPortal và Xray theo dõi tỷ lệ đỗ, thời lượng và độ ổn định của mỗi kiểm thử. Các kiểm thử có độ ổn định giảm xuống dưới 90% (thường xuyên hỏng do thay đổi yêu cầu) được đánh dấu là kế thừa và gán cho chủ sở hữu để xem xét.

Ví dụ thiết lập kiểm thử hồi quy

Hãy xem xét việc thiết lập kiểm thử hồi quy tự động trên Android sử dụng thư viện JUnit 5 và Espresso. Ví dụ minh họa hồi quy chọn lọc — kiểm thử xác minh rằng sau khi tái cấu trúc kho lưu trữ người dùng, màn hình hồ sơ không bị hỏng. Đối với iOS, XCTest được sử dụng với logic tương tự — kiểm thử lặp lại trên một kịch bản chính.

Android: kiểm thử hồi quy hồ sơ

Kiểm thử sử dụng MockWebServer để mô phỏng máy chủ và kiểm tra toàn bộ đường dẫn: tải dữ liệu người dùng, hiển thị trên màn hình hồ sơ và xử lý lỗi khi máy chủ không khả dụng. Các kiểm thử như vậy được đưa vào bộ hồi quy và chạy trên mọi thay đổi trong mô-đun hồ sơ.

@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("Lỗi tải").assertIsDisplayed()
    }
}

iOS: kiểm thử hồi quy với XCTest

Đối với iOS, kiểm thử hồi quy sử dụng XCTestExpectation để xác minh không đồng bộ việc cập nhật UI sau khi nhận dữ liệu từ API. Kiểm thử mô phỏng phản hồi mạng và xác minh rằng các phần tử UI đã được cập nhật chính xác.

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

Chiến lược xây dựng bộ kiểm thử hồi quy

Xây dựng một bộ kiểm thử hồi quy hiệu quả là một quy trình lặp lại dựa trên dữ liệu lỗi và thay đổi mã. Chiến lược ban đầu là đưa tất cả kiểm thử hiện có vào bộ hồi quy và chạy toàn bộ trước mỗi bản phát hành. Khi cơ sở kiểm thử phát triển (hơn 2000 kiểm thử), việc chạy toàn bộ trở nên quá lâu và cần có cách tiếp cận chọn lọc.

Giai đoạn thứ hai — triển khai các công cụ phân tích phụ thuộc: Jacoco cho Android, Xcode Test Plan cho iOS. Các công cụ này xây dựng bản đồ "kiểm thử — lớp — phương thức" và cho phép xác định kiểm thử nào bị ảnh hưởng bởi một thay đổi cụ thể. Chạy chọn lọc dựa trên phân tích bao phủ giảm thời gian thực thi 60–80% trong khi vẫn duy trì hiệu quả phát hiện hồi quy 95%, theo Spotify Engineering (2022).

Giai đoạn thứ ba — giám sát liên tục và tối ưu hóa. Các kiểm thử không thất bại trong 6 tháng được chuyển sang bộ ưu tiên thấp. Các kiểm thử thất bại hơn một lần mỗi tháng là ứng viên để xem xét: hoặc chúng phát hiện vấn đề thực sự (cần sửa lỗi) hoặc chúng quá mong manh (cần ổn định hóa). Đánh giá bộ hồi quy hàng quý là thông lệ tiêu chuẩn để duy trì hiệu quả và tốc độ thực thi của nó.