9 "tip" lựa chọn Test cases cho kiểm thử hồi quy

Mỗi sản phẩm phần mềm phải trải qua nhiều thay đổi trong vòng đời phần mềm. Tuy nhiên, theo thời gian điều này có thể dẫn đến sự mất ổn định của ứng dụng. Khi một sự thay đổi xảy ra trong phần mềm: phần mềm có những phiên bản mới hơn phiên bản hiện tại, có những tính năng được thêm mới, có những tính năng được mở rộng,… lúc này kiểm thử hồi quy trở nên cần thiết.

Không thực hiện kiểm thử hồi quy hiệu quả có thể gây ra rất nhiều hậu quả không đáng có. Giả sử mọi tính năng mới đều chạy tốt, nhưng các tính năng cũ được thực hiện trước đây phát sinh ra bug. Nếu điều này xảy ra, khách hàng sẽ không còn đánh giá bạn cao nữa ngay cả với những tính năng mới bạn làm rất tốt.

Kiểm thử qui hồi, hiểu một cách đơn giản, là phương thức kiểm thử để xem ứng dụng ở phiên bản mới có làm thay đổi hoặc có ảnh hưởng gì đến các chức năng đã có sẵn của ứng dụng hay không. Các lỗi (bug) từng xảy có còn lặp lại hay không. Kiểm thử hồi quy có thể trở thành một thách thức đối với các tester, lý do bởi:

1. Số test cases trong bộ hồi qui sẽ tăng lên với mỗi tính năng mới được thêm vào.
2. Đôi khi, việc thực hiện toàn bộ kiểm tra hồi quy trở nên khó khăn do giới hạn về thời gian và ngân sách.
3. Giảm thiểu các trường hợp kiểm tra nhưng vẫn phải đảm bảo tính bao phủ không phải là một điều dễ dàng.
4. Xác định tần số thực hiện kiểm thử hồi quy sau mỗi lần sửa đổi hoặc cập nhật mới luôn là một thách thức.

Do đó việc lựa chọn test cases để kiểm thử hồi quy là một nhiệm vụ khá khó khăn. Dưới đây tôi sẽ chia sẻ một số thủ thuật đơn giản mà tôi thấy hiệu quả nhất trong khi lựa chọn trường hợp kiểm thử để thực hiện kiểm thử hồi quy:

1. Lựa chọn các trường hợp kiểm thử mà thường xuyên xảy ra lỗi Một số chức năng trong sản phẩm rất dễ bị lỗi mà dev thường gặp phải với một thay đổi nhỏ trong code. Vì vậy, chúng ta có thể theo dõi các vùng có trường hợp kiểm thử thất bại trong suốt chu kỳ sản phẩm và lựa chọn chúng trong bộ kiểm tra hồi quy.

2. Lựa chọn các trường hợp kiểm thử mà xác minh tính năng cốt lõi của sản phẩm: Các trường hợp kiểm thử được thiết kế cần đảm bảo được tất cả các tính năng cốt lõi của ứng dụng, đảm bảo rằng trường hợp kiểm thử bao gồm tất cả các chức năng đề cập trong tài liệu yêu cầu. Có thể sử dụng các ma trận truy xuất nguồn gốc để đảm bảo rằng không có yêu cầu còn lại nào chưa được kiểm tra. Ví dụ: Khách hàng sẽ không bao giờ mong đợi Trang chủ / trang Đăng nhập / hay bất kỳ một chức năng chính của ứng dụng bị failed.

3. Lựa chọn các trường hợp kiểm thử cho các chức năng đã qua và gần đây thay đổi: Tài liệu đặc tả yêu cầu (SRS) vẫn luôn được cập nhật. Đôi khi, các bản cập nhật thay đổi không đầy đủ so với bản SRS trước đó. Nhưng thông thường có thể lên tới 15-30% những thay đổi có thể xảy ra cho tất cả các phiên bản nâng cấp. Khi SRS luôn được cập nhật thường xuyên, các tester phải đồng ý rằng, sẽ càng khó hơn để tiếp tục sửa đổi các trường hợp kiểm thử theo đó. Với một số thay đổi code ở bản fix cuối có thể dẫn đến một số lỗi bên trong và gây ra lỗi ở một số chức năng đã tồn tại. Vì vậy với những trường hợp kiểm thử có những thay đổi gần đây, hãy đánh dấu là "M" (yêu cầu bắt buộc "Must") để luôn luôn đưa nó vào bộ kiểm thử hồi quy.

4. Lựa chọn tất cả các trường hợp kiểm thử tích hợp: Ngay cả khi kiểm thử tích hợp là một phần riêng biệt của chu trình kiểm thử phần mềm, các trường hợp kiểm thử của nó nên được bao gồm trong bộ kiểm tra hồi quy. Một bản fix cuối có thể phá vỡ sự toàn vẹn giữa các module khác nhau trong ứng dụng đã được kiểm tra trước đó. Ví dụ, có thể bị mất dữ liệu hiển thị trên giao diện, message có thể bị sai hoặc giao diện có thể còn giống như yêu cầu.

5. Lựa chọn tất cả các trường hợp kiểm thử phức tạp: Một số chức năng của hệ thống chỉ có thể được thực hiện bằng cách làm theo một số trình tự phức tạp của các sự kiện GUI. Ví dụ, để mở một tập tin người dùng phải bấm vào Menu File, sau đó chọn các hoạt động mở rộng, và sau đó sử dụng một hộp thoại để chỉ định tên tập tin, và sau đó tập trung vào ứng dụng trong cửa sổ mới được mở ra. Rõ ràng, việc tăng số lượng các steps làm tăng nguy cơ xảy ra lỗi theo cấp số nhân. Điều này có thể trở thành một vấn đề nghiêm trọng khi có một step không hoạt động trong chuỗi steps đó. Đó là lý do tại sao tất cả các trường hợp kiểm thử phức tạp như vậy nên được đưa vào bộ kiểm tra hồi quy.

6. Xét độ ưu tiên cho các trường hợp thử nghiệm trong bộ kiểm thử hồi quy

Ưu tiên các trường hợp thử nghiệm tùy thuộc vào chiến lược kinh doanh, chức năng quan trọng và có thường xuyên được sử dụng. Nó luôn luôn hữu ích nếu một số phân tích được thực hiện để tìm ra những trường hợp kiểm thử có liên quan và trường hợp kiểm thử không liên quan. Nó là một phương pháp tốt để lập kế hoạch và hành động để thử nghiệm hồi quy từ đầu của dự án trước khi các chu kỳ test. Một trong những ý tưởng để phân loại các trường hợp kiểm thử là dựa vào các ưu tiên khác nhau dựa trên tầm quan trọng và cách sử dụng của khách hàng. Thông thường, các trường hợp kiểm thử được phân thành ba loại như gợi ý dưới đây: Lựa chọn các trường hợp thử nghiệm dựa trên độ ưu tiên sẽ làm giảm đáng kể effort dành cho kiểm thử hồi quy.

7. Phân loại các trường hợp kiểm thử được lựa chọn:

Kiểm thử hồi quy trở nên rất khó khăn khi phạm vi ứng dụng là rất lớn và gia tăng liên tục. Trong trường hợp này kiểm thủ cần được chọn lọc để tiết kiệm chi phí và thời gian. Để phân loại các trường hợp kiểm thử dễ dàng hơn, ta có thể phân loại chúng như sau:

1. Reusable Test Cases: Bao gồm các trường hợp kiểm thử có thể được lặp đi lặp lại sử dụng trong chu kỳ tiếp theo. Nó có thể được làm tự động dó đó dễ dàng xây dựng các trường hợp kiểm thử và dễ dàng thực hiện.
2. Obsolete Test Cases: Những trường hợp kiểm thử cũ có thể là những khiếm khuyết cụ thể, hoặc không thể được sử dụng trong chu kỳ tiếp theo. Tốt nhất là sử dụng chúng là khi khiếm khuyết liên quan xảy ra.

8. Chọn các trường hợp thử nghiệm dựa trên từng trường hợp cụ thể (Case to Case basic)

Có nhiều cách tiếp cận quyền kiểm tra hồi quy mà cần phải được quyết định dựa trên từng trường hợp cụ thể:

• Trường hợp 1: Nếu mức độ rủi ro và ảnh hưởng của việc fix bug là Low, tester sẽ lựa chọn một số trường hợp kiểm thử từ TCDB (Test case DB) để execute. Những trường hợp kiểm thử này có thể thuộc bất kỳ độ ưu tiên nào (0, 1 hoặc 2).

• Trường hợp 2: Nếu mức độ rủi ro và ảnh hưởng của việc fix bug là Medium, tester cần phải thực hiện tất cả các trường hợp kiểm thử có độ ưu tiên 0 và độ ưu tiên 1. Nếu việc fix lỗi cần test bổ sung những trường hợp có độ ưu tiên-2, thì những trường hợp kiểm thử này cũng có thể được lựa chọn và sử dụng cho thử nghiệm hồi quy. Lựa chọn các trường hợp kiểm thử có ưu tiên 2 trong trường hợp này chỉ là mong muốn nhưng không bắt buộc.

• Trường hợp 3: Nếu mức độ rủi ro và ảnh hưởng của việc fix bug là High, tester cần phải thực hiện tất cả các trương hợp kiểm thử có độ ưu tiên 0, độ ưu tiên 1 và lựa chọn kỹ càng các trường hợp có độ ưu tiên 2.

• Trường hợp 4: Theo dõi log những thay đổi đã xảy ra vì sửa lỗi để lựa chọn các trường hợp kiểm thử đưa vào kiểm thử hồi quy. Đây là một quá trình phức tạp nhưng có thể đạt hiệu quả tốt.

9. Thay đổi các trường hợp thử nghiệm hồi quy bất cứ khi nào cần thiết Dự kiến việc RESET trường hợp kiểm thử sẽ không được thực hiện thường xuyên. Việc thay các đổi các trường hợp kiểm thử cần được thực hiện với các cân nhắc sau đây:

a. Khi có một sự thay đổi lớn trong sản phẩm b. Khi có một sự thay đổi trong thủ tục xây dựng mà ảnh hưởng đến sản phẩm c. Chu kỳ phát hành lớn, một số trường hợp kiểm thử không được thực hiện trong một thời gian dài d. Bạn đang ở trong chu kỳ kiểm thử hồi quy cuối cùng với một vài trường hợp kiểm thử được lựa chọn e. Khi xảy ra tình huống mà kết quả expected của trường hợp kiểm thử khác với kết quả từ các chu kỳ trước đó

Hy vọng bài viết này sẽ giúp bạn tìm ra những trường hợp kiểm thử nên được lựa chọn vào bộ kiểm tra hồi quy của bạn để giúp cho việc kiểm thử hồi quy đạt hiệu quả hơn.

Nguồn tham khảo: http://prototechsolutions.com/blog/9-tips-for-selecting-test-cases-for-regression-testing/