Trong vòng đời phát triển phần mềm, việc thêm các tính năng mới hoặc cập nhật các tính năng hiện có là một phần không thể thiếu. Tuy nhiên, việc thay đổi một khối lượng code lớn và phức tạp có thể là một thách thức. Nó có thể vô tình gây ra ảnh hưởng ngoài ý muốn đến hoạt động của phần mềm, dẫn đến trải nghiệm không tốt cho người dùng. Các developer thường sử dụng unit test để ngăn chặn vấn đề này, nhưng cách này không phải lúc nào cũng có thể giải quyết được rủi ro. Đó là lý do vì sao mà kiểm tra hồi quy (regression testing) trở nên rất quan trọng.
Regression testing là gì?
Regression testing là một loại kiểm thử phần mềm để kiểm tra xem những thay đổi trong code có ảnh hưởng đến các chức năng trước đó hay không. Trong quá trình thực hiện regression testing, các nội dung kiểm thử chức năng và phi chức năng sẽ được chạy lại để đảm bảo rằng các chức năng chính hoạt động đúng sau khi phần mềm được sửa đổi. Việc không xác định được các lỗi có thể đã xuất hiện có thể gây tác động tiêu cực đến cảm nhận của người dùng và cũng có thể ảnh hưởng đến lợi nhuận của sản phẩm.
Khi nào regression testing được thực hiện?
Dưới đây là các tình huống có thể áp dụng quy trình kiểm thử hồi quy:
- Một yêu cầu mới được thêm vào một tính năng hiện có.
- Một tính năng mới hoặc chức năng mới được thêm vào phần mềm.
- Codebase được sửa để giải quyết các lỗi.
- Code được tối ưu hóa để cải thiện về performance.
- Các lỗi được sửa.
- Giao diện của phần mềm được thay đổi.
- Cấu hình của phần mềm được thay đổi.
- Có phần mềm/ứng dụng của bên thứ ba được tích hợp vào hệ thống hiện tại.
Tất cả những trường hợp trên đều liên quan đến việc tái cấu trúc hoặc chỉnh sửa code hiện tại. Việc này có thể dẫn đến các hành vi không mong muốn.
Các phương pháp thực hiện regression testing
Chủ yếu có bốn phương pháp kiểm tra hồi quy phổ biến nhất:
- Kiểm tra tất cả: Tất cả các test case từ bộ test case đã có sẵn được thực hiện lại. Đây là phương pháp đơn giản và an toàn nhất nhưng lại đòi hỏi nhiều thời gian và công sức.
- Lựa chọn các trường hợp để kiểm thử hồi quy: Trong phương pháp này, một số test case được lựa chọn từ bộ test case để kiểm tra các thành phần đã sửa đổi code, và các phần bị ảnh hưởng bởi những sửa đổi này. Phương pháp này có thể cắt giảm chi phí vận hành so với kiểm thử lại toàn bộ hệ thống.
- Lựa chọn các trường hợp kiểm thử hồi quy có mức độ ưu tiên cao hơn: Các test case được sử dụng để thực hiện regression test dựa theo chức năng được sử dụng thường xuyên nhất, tác động kinh doanh, và độ quan trọng. Với việc ưu tiên các test case này, thời gian và công sức sẽ giảm đi đáng kể, và có nhiều thời gian để có thể đánh giá kĩ lưỡng cho các phần quan trọng khác của hệ thống.
- Kết hợp: Phương pháp này là sự kết hợp của phương pháp lựa chọn các trường hợp để kiểm thử hồi quy và lựa chọn các trường hợp kiểm thử có mức độ ưu tiên cao hơn.
Trong số tất cả các phương pháp này, kết hợp là phương pháp hiệu quả nhất. Điều này là do thay vì chọn nhiều test case cần thiết cùng một lúc thì thực hiện chúng dựa trên việc bạn muốn tiến hành lựa chọn regression testing trước hay ưu tiên các test case tuỳ vào tình hình. Vì vậy, nó tiết kiệm rất nhiều thời gian và công sức.
Các loại regression testing
Không có cách tiếp cận duy nhất để thực hiện kiểm thử hồi quy. Ngoài các phương pháp được ở trên, còn có một số loại thử nghiệm hồi quy khác. Chúng ta hãy xem xét một số cách tiếp cận phổ biến sau:
- Unit Regression Testing
Loại thử nghiệm hồi quy này có liên quan đến unit test. Các developer chạy lại unit test để kiểm tra xem code unit test có bị ảnh hưởng gì không.
- Corrective regression testing (Kiểm thử hồi quy hiệu chỉnh)
Cách tiếp cận này được sử dụng nếu code của phần mềm không có thay đổi đáng kể. Trong những trường hợp như vậy, QA thường không viết test case mới, mà sử dụng lại test case cũ.
- Progressive regression testing (Kiểm tra hồi quy lũy tiến)
Cách tiếp cận này được sử dụng để kiểm tra tác động của một thành phần mới được đưa vào phần mềm. Trong trường hợp này, các thành viên phát triển cần biết rõ khối lượng và bản chất của các thay đổi trong code và QA thường sẽ viết test case mới để thực hiện regression testing.
- Selective regression testing (Kiểm tra hồi quy chọn lọc)
QA sẽ chọn một loạt các test case để đẩy nhanh tiến độ kiểm thử. Loại kiểm thử này ít tốn thời gian và công sức hơn việc thực hiện test lại nhưng các thành viên của nhóm phát triển cần phải xem xét kĩ các điều kiện và phạm vi test.
Loại kiểm thử này chỉ thực hiện ở những khu vực chính của phần mềm thông qua danh sách các test case đã được chọn sẵn. Khi có sự thay đổi nào đó, các test case này sẽ được chọn lọc để đảm bảo các chức năng chính vẫn hoạt động bình thường.
- Complete regression testing (Kiểm thử tất cả các trường hợp)
Loại kiểm thử này thường được sử dụng khi nhóm phát triển gặp khó khăn trong việc xác định khối lượng code được thay đổi và tác động của những thay đổi này, và khi có những thay đổi lớn ở những phần cốt lõi của phần mềm. Cách này tốn nhiều thời gian nhưng tăng độ tin cậy cho toàn bộ phần mềm. Nếu bạn có một bộ test case tự động bao phủ hầu hết các chức năng chính, thì có thể lên lịch chạy ít nhất 1 lần/tuần vào ngày cuối tuần.
Một ví dụ về các thực hiện regression testing
Bước 1. Xây dựng bộ test case cho regression test
Bước đầu tiên trong việc thiết kế chiến lược cho regression testing là xây dựng bộ test case cho kiểm thử hồi quy - regression suite. Bộ test case này được tạo từ các test case đã có sẵn như functional testing, intergration testing.
Dưới đây là một số mẹo về lựa chọn test case một cách hiệu quả.
- Test case liên quan đến những khu vực dễ xảy ra lỗi của phần mềm.
- Test case liên quan đến các chức năng chính của sản phẩm. Các chức năng cốt lõi phải luôn được kiểm tra.
- Test case cho chức năng hoặc tính năng mới được thêm vào.
Bước 2. Ước tính thời gian thực hiện test
Ước tính thời gian cần thiết để thực hiện kiểm tra tất cả test case, bao gồm thời gian tìm hiểu, thực hiện và báo cáo kết quả test.
Dưới đây là các yếu tố có thể ảnh hưởng đến thời gian ước tính để thực thi test:
- Tạo test data
- Lập kế hoạch
- Review test case
Bước 3. Lựa chọn cách tiếp cận
Lựa chọn cách thực thi từ những phương pháp được giới thiệu trên.
Ngoài ra, với kiểm tra hồi quy thì thường sẽ có xu hướng thực hiện tự động hoá vì sẽ nhanh hơn và đáng tin cậy hơn kiểm thử thủ công. Tuy nhiên, khi kiểm thử các trường hợp phức tạp hay kiểm tra trên GUI thì nên kiểm tra thử công. Vì vậy, bạn cần xem xét những test case nào nên thực hiện thủ công và những test case nào nên thực hiện tự động để tránh gây sai lệch thông tin và có thể quản lý được việc kiểm thử một cách tốt nhất.
Bước 4. Sắp xếp độ ưu tiên trong bộ test case
Để quản lý một phiên thực thi test hiệ quả, điều quan trọng đầu tiên là sắp xếp độ ưu tiên chính xác.
- Đầu tiên cần ưu tiên cho các test case về những chức năng cơ bản vì chúng mang lại lại giá trị cao nhất cho người dùng.
- Tiếp theo là các chức năng quan trọng nhưng không cốt lõi, tức là không có chức năng này thì hệ thống vẫn hoạt động nhưng hiệu suất không đạt yêu cầu.
- Sau nữa là những test case không mang lại giá trị dự án cao nhưng quan trọng để tránh technical debt.
“Best practice” về regression testing
- Cập nhật bộ test case cho regression testing
Bạn cần cập nhật thường xuyên bộ test case để theo kịp với những thay đổi trong sản phẩm mình phát triển bằng cách xem xét đầy đủ các yêu cầu mới về chức năng và phi chức năng.
- Nắm được những thay đổi trong sản phẩm
Thường xuyên liên lạc với các developer và QA khác để biết được thông tin về phiên bản nâng cấp mới nhất cùng với những thay đổi. Từ đó có thể lập kế hoạch kiểm thử đi đúng hướng.
- Hiểu phạm vi kiểm thử
Trước khi bắt đầu quá trình regression testing, điều cần thiết là phải biết phạm vi cần thực hiện kiểm thử. Lý do là mỗi dự án có thể khác nhau về phạm vi, thời gian và mục tiêu. Hiểu được sự khác biệt về phạm vi sẽ cho phép bạn lập kế hoạch thực hiện chu trình hồi quy tốt hơn.
- Tự động hóa test case
Tự động hóa không chỉ có lợi mà còn cần thiết đối với nhóm phát triển phần mềm vì nó cho phép họ thực hiện các egression testing hiệu quả hơn.
Kiểm tra hồi quy thủ công sẽ tốn thời gian, cũng như công sức tốn và khó mở rộng quy mô. Khi sản phẩm có thêm nhiều tính năng mới, sẽ cần phải có thêm nhiều người và thời gian để hoàn thành bộ test case trong mỗi chu kì release sản phẩm.
- Phân tích trải nghiệm của người dùng
Phân tích trải nghiệm người dùng trên sản phẩm của bạn để thu hẹp các chức năng nào được sử dụng nhiều để cập nhật khi xây dựng hoặc bảo trì bộ test case.
Kết luận
Bài viết trên đã tổng hợp một số thông tin về regression testing. Hy vọng bài viết này đã mang lại kiến thức bổ ích cho bạn.
Tham khảo: