Get in touch
or send us a question?
CONTACT

Kiểm thử hồi quy (Regression Test)

Khi phần mềm được phát triển thì sẽ có những thay đổi để phù hợp với hệ thống cũng như yêu cầu của khách hàng, các tính năng mới được tích hợp, do đó luôn có những phiên bản mới thay thế phiên bản cũ.

Việc kiểm thử sẽ phải thực hiện lại và tốn nhiều thời gian. Trong trường hợp này, ta nên áp dụng Kiểm thử hồi quy – Regression Test.

1. Regression Test là gì?

Regression Test (Kiểm thử hồi quy) là một loại kiểm thử phần mềm để xác nhận rằng một tính năng mới được thêm không ảnh hưởng xấu đến các tính năng hiện có.

Thử nghiệm hồi quy là một biện pháp kiểm soát chất lượng nhằm đảm bảo hai điều kiện sau đây:

  • Code mới thay đổi đạt yêu cầu quy định.
  • Code cũ hiện tại không thay đổi sẽ không bị ảnh hưởng bởi sự thay đổi mới như trên.


Phương pháp kiểm thử này được thực hiện để đảm bảo rằng các thay đổi code mới sẽ không có gây ra bất kỳ ảnh hưởng nào tới các chức năng hiện có. Đồng thời đảm bảo rằng toàn bộ code cũ vẫn hoạt động bình thường sau khi những thay đổi của code mới nhất được đưa vào phần mềm.

Những trường hợp cần phải được kiểm thử hồi quy:

  • Thay đổi trong yêu cầu và mã code được sửa đổi theo yêu cầu
  • Tính năng mới được thêm vào phần mềm
  • Sửa lỗi (Fixed bug)
  • Khắc phục sự cố về hiệu suất


2. Đặc điểm và tính chất của Regression Test

Test hồi quy không phải là một mức kiểm tra. Nó đơn thuần kiểm tra lại phần mềm sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản phần mềm mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt. Test hồi quy có thể thực hiện tại mọi mức kiểm tra.

Test hồi quy là một trong những loại kiểm tra tốn nhiều thời gian và công sức nhất. Tuy nhiên, việc bỏ qua Test hồi quy là “không được phép” vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!


3. Làm thế nào để thực hiện Regression Test?

Bảo trì phần mềm là một hoạt động bao gồm cải tiến, sửa lỗi, tối ưu hóa và có thể xóa bớt các tính năng hiện có và làm thêm các tính năng mới. Những sửa đổi này có thể khiến hệ thống hoạt động không chính xác. Do đó, Kiểm tra hồi quy trở nên cần thiết. Kiểm tra hồi quy có thể được thực hiện bằng các kỹ thuật sau:


🔆 Kiểm thử lại tất cả

Đây là một trong những phương pháp để Kiểm thử hồi quy trong đó tất cả các kiểm thử trong nhóm kiểm thử hoặc bộ kiểm thư hiện có sẽ được thực hiện lại. Điều này rất tốn kém vì nó đòi hỏi thời gian và nguồn lực rất lớn.

🔆 Lựa chọn kiểm thử hồi quy

Thay vì thực hiện lại toàn bộ các trường hợp kiểm thử, tốt hơn là chỉ thực hiện một phần mà thôi. Các trường hợp kiểm thử được chọn có thể được phân thành 2 loại:

  • Các trường hợp kiểm thử có thể tái sử dụng: Là các trường hợp kiểm thử có thể được sử dụng trong các vòng đời kiểm thử hồi quy thành công.
  • Các trường hợp thử nghiệm lỗi thời: Là các trường hợp không thể sử dụng trong các vòng đời kiểm thử hồi quy thành công.


🔆 Độ ưu tiên của các trường hợp kiểm thử

Các trường hợp kiểm thử được sắp xếp độ ưu tiên tùy thuộc vào tác động kinh doanh, các chức năng quan trọng và được sử dụng thường xuyên. Lựa chọn các trường hợp kiểm thử dựa trên mức độ ưu tiên sẽ giảm đáng kể bộ kiểm tra hồi quy.

Chọn các trường hợp kiểm thử để kiểm thử hồi quy

Kiểm thử hồi quy hiệu quả có thể được thực hiện bằng cách chọn các trường hợp kiểm tra sau:

  • Các trường hợp kiểm thử thường xuyên xảy ra lỗi
  • Các chức năng dễ thấy hơn đối với người dùng
  • Các trường hợp kiểm thử xác minh các tính năng cốt lõi của sản phẩm
  • Các trường hợp kiểm thử của chức năng đã trải qua nhiều thay đổi gần đây
  • Tất cả các trường hợp kiểm thử tích hợp
  • Tất cả các trường hợp kiểm thử phức tạp
  • Trường hợp kiểm thử giá trị biên
  • Một vài các trường hợp kiểm thử mẫu đã thành công
  • Một vài các trường hợp kiểm thử mẫu đã thất bại


4. Một số công cụ dùng để Regression Test

Nếu một phần mềm trải qua những thay đổi thường xuyên, chi phí kiểm thử hồi quy sẽ leo thang.

Trong các trường hợp như vậy, việc thực hiện thủ công các trường hợp kiểm thử làm tăng thời gian thực hiện kiểm thử cũng như chi phí.

Tự động hóa các trường hợp kiểm thử hồi quy là sự lựa chọn thông minh trong các trường hợp như vậy.

Phạm vi tự động hóa phụ thuộc vào số lượng các trường hợp kiểm thử vẫn có thể sử dụng lại cho các chu kỳ hồi quy kế tiếp.

Sau đây là các công cụ quan trọng nhất được sử dụng cho cả kiểm thử chức năng và hồi quy trong công nghệ phần mềm:

  • akaAT Studio
  • Katalon Studio
  • Ranorex Studio
  • Selenium
  • testRigor
  • Quick Test Professional (QTP)
  • Rational Functional Tester (RFT)

5. Sự khác biệt giữa Kiểm thử lại (Re-Testing) và Kiểm thử hồi quy

Kiểm thử lại có nghĩa là chỉ kiểm thử lại chức năng hoặc lỗi để đảm bảo lỗi đó đã được sửa. (một phần nhỏ)

Kiểm thử hồi quy có nghĩa là kiểm thử ứng dụng phần mềm khi có trải qua thay đổi code để đảm bảo rằng code mới thay đổi không ảnh hưởng đến các phần khác của phần mềm. (toàn phần lớn)

6. Những khó khăn trong kiểm thử hồi quy

Sau đây là một số khó khăn khi thực hiện kiểm thử hồi quy:

  • Khi kiểm thử hồi quy liên tục được thực hiên, các bộ test cases trở nên khá lớn. Do hạn chế về thời gian và ngân sách có thể toàn bộ test cases kiểm thử hồi quy không thể được thực thi.
  • Tối thiểu hóa bộ test cases trong khi vẫn đạt được phạm vi kiểm thử tối đa vẫn là một thách thức
  • Xác định tần suất của Kiểm thử hồi quy, tức là sau mỗi lần sửa đổi hoặc mỗi lần cập nhật bản build hoặc sau một loạt các lỗi được sửa là một thách thức.

Kết luận

Một chiến lược kiểm thử hồi quy hiệu quả sẽ tiết kiệm cả thời gian và tiền bạc.

Theo những trường hợp nghiên cứu trong lĩnh vực ngân hàng, kiểm thử hồi quy tiết kiệm tới 60% thời gian trong việc sửa lỗi (có thể đã phát hiện bởi kiểm thử hồi quy) và 40% chi phí cho kiểm thử phần mềm

Tài liệu tham khảo:.https://www.guru99.com/regression-testing.html
https://anhtester.com/blog/kiem-thu-hoi-quy-regression-test-b592.html

https://anhtester.com/blog/kiem-thu-hoi-quy-regression-test-b592.html

Leave a Reply

Your email address will not be published. Required fields are marked *