rào cản có liên quan
Giai đoạn đầu tiên và có lẽ quan trọng nhất trong phương pháp kiểm thử dựa vào các rủi ro này là nghiên cứu chi tiết về các kiểu hư hỏng tiềm ẩn trong hệ thống dự kiến sẽ kiểm thử. Bảng 3.1 liệt kê các thông tin cần phải tìm được khi phân tích rủi ro.
Rủi ro Những gì có thể sai sót ? (các kiểu hư hỏng)
trình sẽ làm xuất hiện rủi ro này?
Module Module nào hoặc hệ thống con nào sẽ làm xuất hiện rủi ro này?
Xác xuất Khả năng xảy ra như thế nào, thấp, trung bình, cao?
Kết quả Hậu quả như thế nào, thấp, trung bình, cao?
Độ phơi nhiễm rủi ro
Sử dụng một ma trận hoặc một công thức để tính rủi ro từ xác xuất và thiệt hại
Rào cản Chúng ta có thể ngăn ngừa và cài đặt một rào cản như thế nào?
Các kiểm thử Chúng ta có thể biết đến mức độ nào về việc rủi ro này sẽ không xảy ra?
Bảng 3.1: Các thông tin cần biết từ việc phân tích lỗi
Đầu tiên, chúng ta phải nhận dạng được các nguy cơ tiềm ẩn trong hệ thống. Trong Chương 2 cũng đã trình bày rõ ràng về một số cách phân tích rủi ro. Tuy nhiên phương pháp kiểm thử này không phụ thuộc vào một cách phân tích lỗi cụ thể nào. Việc lựa chọn các kỹ thuật chỉ phụ thuộc vào dự án và các kinh nghiệm đã có của những người tham gia. Cách tốt nhất là kết hợp một vài phương pháp lại để có một giải pháp hiệu quả nhất. Điều quan trọng ở đây là nhận dạng được các nguy cơ càng sớm càng tốt, vì vậy phương pháp phân tích rủi ro sơ bộ (PHA) có thể được thực hiện ngay từ khi bắt đầu dự án để phát hiện những lỗi hiển nhiên. Sau đó, có thể tiến hành phân tích lỗi bằng phương pháp HazOp khi đã hiểu rõ hơn về hệ thống.
Việc tìm ra nguyên nhân của các rủi ro là rất quan trọng. Đây sẽ là cơ sở để xây dựng các rào cản và các kiểm thử. Nguyên nhân có thể là một lỗi cá biệt nào đó của hệ thống, một hành vi bất thường của người sử dụng hệ thống hoặc các trạng thái môi trường đặc biệt của hệ thống. Thông thường, một lỗi sẽ xảy ra khi có nhiều thứ sai hỏng xả ra tại cùng một thời điểm.
Thông thường, một lỗi sẽ chỉ liên quan đến một bộ phận cụ thể nào đó của hệ thống. Rất nhiều sai sót trong một module hoặc một hệ thống con sẽ làm tăng khả năng cho một rủi ro trở thành một vấn đề thực sự.
Bây giờ, chúng ta sẽ ước lượng xác suất để một nguy cơ sẽ có thể xảy ra. Chúng ta sẽ sử dụng các mức độ thấp, trung bình và cao để phân lọai,
nhưng có thể sẽ phải phân loại chính xác hơn khi sử dụng các ma trận rủi ro. Đôi khi, cần phải thay thế cách phân loại này bằng các con số khi cần có độ chính xác cao hơn trong các tính tóan. Các điểm từ một đến ba thường được sử dụng nhưng cũng có một vài vấn đề. Xác suất trung bình (2) lớn gấp đôi mức thấp (1) nhưng mức cao (3) lại chỉ lớn hơn 50% so với mức trung bình. Điều này chưa hợp lý lắm. Một giải pháp cho vấn đề này là sử dụng 1, 3, và 10 thì các khoảng cách giữa chúng cân bằng hơn. Điều này được minh họa trong bảng 3.2 với các số trong ngoặc ( ) và chúng cũng được dùng trong phần 2.2.
Chúng ta sẽ sử dụng cùng kiểu phân loại này đối với hậu quả như khi thực hiện đối với xác suất. Độ phơi nhiễm của một rủi ro được tính bằng tích của thiệt hại do rủi ro gây ra và xác suất xảy ra rủi ro này. Ma trận rủi ro trong bảng 3.2 được sử dụng để tìm ra mức độ rủi ro đối với các rủi ro.
Xác xuất
Hậu quả
Cao (10) Trung bình (3) Thấp (1)
Cao (10) Cao (100) Cao (30) Trung bình (10)
Trung bình (3) Cao (30) Trung bình (9) Thấp (3) Thấp (1) Trung bình (10) Thấp (3) Thấp (1)
Bảng 3.2: Ma trận rủi ro cho độ phơi nhiễm
Khi mối rủi ro và độ phơi nhiễm đối với rủi ro này được tìm ra, điều quan trọng là phải xem xét các hành động để giảm thiểu thiệt hại. Nếu độ
phơi nhiễm đối với rủi ro này cao, chúng ta nên cố gắng thay đổi mã chương trình hoặc thiết lập một rào chắn. Một rào chắn sẽ ngăn không cho rủi ro xảy ra. Tuy nhiên, việc tạo rào chắn như vậy sẽ khiến cho hệ thống trở nên phức tạp hơn và sẽ đòi hỏi thêm mã chương trình tiềm ẩn cùng với những rủi ro khác. Thực hiện rào chắn sẽ cần thêm lập trình viên, và có thể sẽ chiếm dụng thời gian của những nhiệm vụ quan trọng khác. Đối với mỗi mức độ rủi ro, chi phí cho việc thiết lập một rào chắn cần phải được cân nhắc so sánh với lợi ích có thể có do việc giảm thiểu thiệt hại do nguy cơ này gây ra. Một rào chắn nên được thiết lập nếu lợi ích nó đem lại cao hơn chi phí để thiết lập nó. Độ phức tạp của rào chắn và mức độ dễ dàng để kiểm thử rào chắn đó cũng là một yếu tố quan trọng cần cân nhắc.
Ngoài ra, cũng cần phải xem xét làm thế nào để kiểm thử xem một nguy cơ có không xảy ra hay không. Điều này có thể dẫn đến phải thêm một hoặc nhiều kiểm thử vào danh sách các kiểm thử cho mỗi nguy cơ. Nếu một rào chắn được đề xuất thì cùng với nó phải có miêu tả về việc làm thế nào để kiểm thử nó. Việc làm thế nào để kiểm thử một rào chắn sẽ được trình bày trong phần 3.3.4.
Nguy cơ Nguyên nhân Đơn vị Xác suất Hậu quả Độ phơi nhiễm Hành động/ rào cản Các kiểm thử Không tính được Y Biến X có một giá trị không hợp lệ Module 1 Trung bình
Cao Cao Ngăn không
cho biến X nhận một giá trị không hợp lệ khi được sử dụng trong module 1 Kiểm tra xem X có thể có một giá trị không hợp lệ không
Bảng 3.3: Bảng với các thông tin nhận được từ phân tích rủi ro
Trong bảng 3.3 đã chỉ ra các thông tin cần thiết về một lỗi tiềm ẩn. Độ phơi nhiễm rủi ro có thể tính được từ cột xác suất và cột hậu quả của Bảng 3.2. Một rào cản và một phép kiểm thử sẽ được đề xuất. Rào cản có thể được
tìm ra bằng cách phân tích miêu tả và nguyên nhân của rủi ro. Người phát triển hệ thống sẽ có trách nhiệm cài đặt rào cản trong khi người kiểm thử cần phải kiểm thử xem nó có hoạt động hay không.