Regression testing và Retesting là hai trong số các phương pháp kiểm tra có giá trị để xem xét các khía cạnh đã nói ở trên, nơi trước đây được sử dụng để đảm bảo tính xác thực của các chức năng hiện có và phương pháp sau xác thực việc loại bỏ hoặc sửa (các) lỗi đã xác định, mọi người vẫn thường bị nhầm lẫn giữa hai thuật ngữ này.
Anh Tester sẽ liệt kê một số điểm khác biệt đáng chú ý giữa Regression testing và Retesting để loại bỏ sự nhầm lẫn này.
Retesting là một quy trình kiểm tra lại các testcase failed trong lần cuối cùng thực hiện test. Nói chung, tester tìm bug đó trong quá trình kiểm thử và assign lại cho Dev fix. Sau khi Dev fix xong thì đẩy lại cho Tester kiểm tra lại. Quá trình liên tục này được gọi là Re-testing.
Retesting có nghĩa là kiểm tra lại. Khi bạn lặp lại một kiểm thử thì đó chính là retest. Bạn có thể test lại chức năng của phiên bản hiện tại, một bug đã fix, chức năng của phiên bản trước đó hay một test case bạn vừa thực hiện, vv…
Nếu bạn vẫn suy nghĩ tại sao lại phải làm vậy thì hãy theo dõi một vài lý do sau:
Chắc chắn bạn đã nắm được điều này.
Retesting là khi bạn lặp lại một kiểm thử cho bầt kỳ một lý do nào. Đây là một trong những điều kiện gần đúng với định nghĩa của nó.
Regression testing (kiểm thử hồi quy) là một loại kiểm thử phần mềm được thực hiện để kiểm tra các tính năng và chức năng hiện tại có bị ảnh hưởng khi thay đổi một đoạn code hay không.
Kỹ sư đảm bảo chất lượng (QA) thực hiện các bài tập này để xem liệu các sửa đổi để phá vỡ mã hoặc cản trở cách thức hoạt động của ứng dụng hoặc cách nó sử dụng tài nguyên.
Regression testing là một dạng của Retesting. Những đặc trưng của “Why” và “When” là những điểm khác biệt giữa test hồi quy so với retest.
When: khi nào chúng ta thực hiện retest? Khi phần mềm trải qua một sự thay đổi.
Why: tại sao chúng ta phải retest? Để đảm bảo việc thêm mới và thay đổi các tính năng không làm ảnh hưởng đến sự ổn định của các chức năng cũ. Regression là phần thực hiện chung và được yêu cầu khi:
Note: Kiểm thử hồi quy toàn bộ ( Exhaustive regression testing) là không thể thực hiện mặc dù rất mong muốn.
Đó là lý do tại sao phải phân tích Regression trước khi bạn nhảy luôn vào thực hiện kiểm thử. Đây là bước quan trọng liên quan đến việc quyết định cần phải thực hiện bao nhiêu Regression cho một ứng dụng.
Thực hiện kiểm thử hồi quy phụ thuộc vào những mức độ nào?
Tester làm thế nào để xác định được mức độ của Regression?
Tùy thuộc vào các nhân tố khi hoạt động, một tập hợp kiểm thử có thể thực hiện theo một trong những follow sau:
Unit regression nghĩa là bạn chỉ cần thực hiện retest đối với sự thay đổi ở module hoặc vùng nào đó của ứng dụng.
Partial regression nghĩa là bạn sẽ thực hiện retest đối với sự thay đổi ở các module kèm theo những tương tác với nó.
Full regression là bạn sẽ phải kiểm tra lại toàn bộ ứng dụng, không phụ thuộc vào vị trí của sự thay đổi.
Điều này dựa trên tình hình (thời gian và nguồn lực sẵn có), mức độ nghiêm trọng của sự thay đổi (mức độ ảnh hưởng của nó), đầu vào của deverlopver, vv… Sẽ hiệu quả hơn khi bạn lựa chọn đúng một bộ kiểm thử so với việc kiểm thử toàn bộ.
Có rất nhiều quan niệm sai lầm về Regression Testing:
#1) Regression luôn luôn được thực hiện một cách tự động: Không, Regression cũng được thực hiện bằng cách thủ công.
Lưu ý rằng Regression là một ứng viên hoàn hảo cho kiểm thử tự động. Mức độ của sự lặp đi lặp lại gây tốn thời gian và có thể dẫn đến sự nhàm chán. Ngoài ra những validation quan trọng có thể bị bỏ sót. Kiểm thử tự động là một sự lựa chọn đáng tin cậy, nhanh chóng và hiệu quả.
#2) Regression là không bao giờ hoàn thành: Đúng, nhưng không hoàn toàn. Theo những gì tôi nghĩ thì kiểm thử hồi quy toàn bộ có thể là không thể. Nhưng kiểm thử hồi quy toàn bộ có thể không quá cần thiết.
Giả sử rằng bạn đã thay đổi một lỗi chính tả trên trang chủ. Việc sửa chữa này là rất nhỏ. Nó cũng được độc lập với các khu vực khác của ứng dụng. Vậy, một quá trình retest đơn giản của tính năng này sẽ làm gì. Không cần thực hiện hồi quy tính năng cũ xung quanh trang chủ.
#3) Nó là không cần thiết khi bạn có nhiều công việc chồng chéo nhau trong cùng một khoảng thời gian: Không đúng. Nếu không thực hiện hồi quy sẽ dấn đến việc mất độ tin cậy trong sản phẩm. Bạn sẽ không bao giờ biết được những kỳ vọng đến từ những kịch bản khác nhau của end user.
#4) Nó chính là việc chạy hết từng test case riêng lẻ của bản release trước đó: Không nên chạy lại toàn bộ test case của bản trước đó. Cần lựa chọn đúng những test case phù hợp để test lại. Chiến lược chọn các test case là mấu chốt của vấn đề. Hiểu được sự thay đổi và lựa chọn những test case phù hợp.
Đúng vậy, đó chính là chi tiết của Retesting và Regression Test.
Bây giờ, hãy thực hiện so sánh
| Re-testing | Regression testing |
|---|---|
| Re-testing được thực hiện để xác nhận lại các trường hợp failed trong lần cuối cùng thực hiện có pass sau khi Dev fix hay không | Kiểm thử hồi quy được thực hiện để xác nhận xem những chương trình hoặc code thay đổi có ảnh hưởng đến tính năng cũ hay không |
| Re-testing được thực hiện dựa trên cơ sở các lỗi đã được fix | Mục đích của kiểm thử hồi quy là khi 1 phần code thay đổi nhưng không được sinh ra bất kì ảnh hưởng nào khác đến các chức năng đã có |
| Xác minh lỗi là một phần của re-testing | Xác minh lỗi không phải là một phần của regression testing |
| Mức độ ưu tiên của re-testing cao hơn kiểm thử hồi quy, vì vậy nó được thực hiện trước khi kiểm thử hồi quy | Dựa vào dự án và nguồn nhân lực, kiểm thử hồi quy có thể được thực hiện song song với kiểm thử chấp nhận |
| Không thể tự động hóa các test case | Có thể sử dụng auto test để kiểm thử hồi quy do kiểm thử thủ công tốn thời gian và nhân lực |
| Kiểm thử chấp nhận là kiểm thử theo kế hoạch | Kiểm thử hồi quy được coi là kiểm thử chung |
| Test lại các case failed | Được thực hiện cho các case passed |
| Kiểm tra lại để đảm bảo rằng các lỗi đã được fix | Check các ảnh hưởng không mong đợi |
| Re-testing thực thi 1 lỗi với cùng 1 dữ liệu, cùng 1 môi trường nhưng đầu vào khác nhau là 1 bản built mới | Kiểm thử hồi quy được thực hiện khi có bất kì chỉnh sửa hoặc thay đổi nào đó. Nó trở thành bắt buộc trong dự án |
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
