0

Risk-based testing - Kiểm thử dựa trên rủi ro

Bài viết này sẽ giới thiệu đầy đủ về Risk-based testing - Kiểm thử dựa trên mức độ rủi ro. Trước khi thảo luận về loại kiểm thử này chúng ta sẽ tìm hiểu khái niệm Rủi ro trong phần mềm là gì.

1. Rủi ro trong phần mềm là gì?

Rủi ro trong phần mềm là những vấn đề hoặc tình huống tiềm ấn chưa xảy ra hoặc nó có thể không bao giờ xảy ra trong tương lai nhưng nó có thể gây ảnh hưởng không tốt đến mục tiêu của các bên liên quan đến dự án.

Khả năng rủi ro xảy ra phụ thuộc vào mức độ rủi ro liên quan đến hậu quả tiêu cực có thể của nó.

2. Khái niệm Kiểm thử dựa trên rủi ro

032316_1114_RiskBasedTe1.png

Kiểm thử dựa trên rủi ro là một loại kiểm thử phần mềm mà các chức năng và chức năng được kiểm thử dựa vào độ ưu tiên, tầm quan trọng và các lỗi tiềm ẩn.

Risk-based testing (RBT) - Kiểm thử dựa trên rủi ro cơ bản là thực hiện kiểm thử dự án hoặc ứng dụng dựa vào rủi ro. Nó sử dụng rủi ro để ưu tiên và nhấn mạnh những trường hợp kiểm thử phù hợp tại thời điểm thực thi kiểm thử. Nói cách khác, rủi ro là khả năng xảy ra của một kết quả không mong muốn. Kết quả này cũng liên quan đến một tác động. Đôi khi khó có thể hoặc không thể kiểm tra tất cả các chức năng của ứng dụng. Sử dụng kiểm thử dựa vào rủi ro trong trường hợp này sẽ kiểm thử các chức năng mà có tác động và khả năng gây ra lỗi cao nhất.

Sẽ tốt hơn nếu bắt đầu thực hiện thử nghiệm dựa trên rủi ro bằng việc phân tích rủi ro của sản phẩm. Có rất nhiều phương pháp được sử dụng cho điều này:

  • Hiểu rõ yêu cầu phần mềm, tài liệu thiết kế và các tài liệu liên quan khác của dự án
  • Thảo luận với các bên liên quan của dự án

Kiểm thử dựa trên rủi ro là quá trình tập trung nỗ lực kiểm thử vào việc làm giảm rủi ro sản phẩm khi hệ thống được triển khai:

  • Kiểm thử dựa trên rủi ro bắt đầu sớm trong dự án, xác định các rủi ro đối với chất lượng hệ thống và sử dụng những kiến thức về rủi ro để lập kế hoạch kiểm thử, chuẩn bị và thực hiện kiểm thử.
  • Kiểm thử dựa trên rủi ro bao gồm cả việc làm giảm khả năng xảy ra của các defect/ fault, đặc biệt những defect/ fault có ảnh hưởng lớn và dự phòng.
  • Kiểm thử dựa trên rủi ro cũng bao gồm đánh giá việc chúng ta tìm defect và loại bỏ defect trong những vùng quan trọng như thế nào.
  • Sử dụng phân tích rủi ro để xác định khả năng loại bỏ, ngăn ngừa defect thông qua các hoạt động phi kiểm thử và giúp chúng ta lựa chọn hoạt động kiểm thử để thực hiện.

3. Khi nào thực hiện Kiểm thử dựa trên rủi ro

Kiểm thử dựa trên rủi ro được thực hiện khi:

  • Dự án hạn chế thời gian, nguồn lực, ngân sách
  • Dự án mà phân tích rủi ro có thể được sử dụng để phát hiện các lỗ hổng tấn công SQL injection
  • Kiểm thử bảo mật trong các môi trường điện toán đám mây
  • Dự án mới với các yếu tố rủi ro cao như thiếu kinh nghiệm với công nghệ được sử dụng, thiếu kiến thức về lĩnh vực kinh doanh.
  • Mô hình gia tăng (Incremental model) và mô hình lặp lại (iterative model)...

4. Quy trình thực hiện Kiểm thử dựa trên rủi ro

risk-based-testing-approach.jpg

Process 1

Dự án bao gồm nhiều rủi ro khác nhau được định nghĩa bởi các bên liên quan của project. Các bên liên quan ở đây là sự kết hợp của đội làm kinh doanh và đội kỹ thuật. Các bên liên quan này gồm rất nhiều người khác nhau đến từ nhiều bộ phận, ví dụ như khách hàng, chuyên gia kinh tế, chuyên gia kỹ thuật, quản lý dự án, Trưởng dự án, người dùng, người phát triển, bộ phận infrastructure.

Process 2

Sau khi tất cả các rủi ro có thể có và ảnh hưởng của chúng được đánh giá, quản lý dự án cần có được độ ưu tiên của yêu cầu phần mềm. Độ ưu tiên của yêu cầu phần mềm cần có được sự đồng thuận và phải được cập nhật vào trong tài liệu về các tính năng của yêu cầu phần mềm; điều tương tự cũng cần được thực hiện đối với đội phát triển và đội test.

Process 3

Sau khi nhận được các yêu cầu phần mềm được đính kèm độ ưu tiến, ta có thể bắt đầu hoạt động test trong khi vẫn nắm được độ ưu tiên của các yêu cầu.

Process 4

Nếu trong thời gian thực hiện test, có thêm rủi ro được phát hiện, thì sẽ có thể xảy ra khả năng team phát triển không làm kịp tiến độ. Trong trường hợp này, do deadline từ đưa ra cho customer không thể thay đổi, người quản lý dự án cần áp dụng nguyên lý Pareto và thay đổi phạm vi test để giảm thời gian thực hiện và đảm bảo có ít rủi ro và đạt được chất lượng tốt nhất.

5. Lợi ích / thuận lợi của Kiểm thử dựa trên rủi ro

  • Tăng tốc độ phát triển và giảm chi phí
  • Tăng cơ hội cho sản phẩn trên thị trường (giảm thời gian đưa ra thị trường)
  • Tăng hiệu năng của sản phẩm
  • Tăng chất lượng của sản phẩm khi các tính năng then chốt đều đã được test kỹ càng
  • Có được thông tin rõ ràng về test coverage. Sử dụng cách tiếp cận này, ta có thể biết các tính năng nào đã và chưa được test.
  • Test dựa theo đánh giá rủi ro là cách hiệu quả nhất để giảm thiểu rủi ro tồn đọng sau khi release.
  • Kết quả test dựa trên đánh giá rủi ro cho phép tổ chức, hệ thống biết được mức độ tồn đọng cảu rủi ro sau khi thực hiện test, để từ đó có thể đưa ra được quyết định chính xác nhất.
  • Tối ưu hóa việc test với các phương pháp đánh giá rủi ro được định nghĩa cụ thể.
  • Tăng sự hài lòng của khách hàng - Dựa trên sự tìm hiểu về khách hàng và các báo cáo, theo dõi tiến độ.
  • Phát hiện sớm các vấn đề tiềm năng giúp ngăn chặn và vượt qua các vấn đề này.
  • Việc theo dõi và đánh giá rủi ro một các liên tục trong suốt vòng đời của dự án giúp phát hiện và định hình rủi ro, tìm ra được vấn đề có thể gây ra nguy hiểm cho mục tiêu và mục đích của toàn dự án.

6. Một vài kỹ thuật kiểm thử hữu ích để thực hiện Kiểm thử dựa trên rủi ro

  • Kiểm thử luồng/ Path Flow testing
  • Kiểm thử khám phá, kiểm thử dựa vào kinh nghiệm / Some amount of exploratory / Experience based testing
  • Phân tích giá trị biên/ Boundary Value analysis
  • Phân lớp tương đương/ Equivalence partitioning
  • Bảng quyết định/ Decision tables

Bài viết tham khảo từ một số tài liệu:

http://www.softwaretestingclass.com/what-is-risk-based-testing-in-software-testing/

http://www.guru99.com/risk-based-testing.html#11


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí