Để tập trung ưu tiên kiểm thử những phần nào trước, chúng ta phải tìm được những bộ phận quan trọng nhất và tồi nhất của sản phẩm. Những bộ phận quan trọng nhất của hệ thống có thể được tìm thấy qua các nhân tố như thiệt hại do lỗi, những bộ phận hiện diện nhiều nhất và được sử dụng nhiều nhất của sản phẩm. Những bộ phận tồi nhất của hệ thống là những bộ phận có
xác suất hỏng cao nhất. Những bộ phận này có thể được tìm thấy nhờ các nhân tố phát sinh lỗi như độ phức tạp, các khu vực bị thay đổi, công nghệ mới, các giải pháp mới, các phương pháp mới, các công cụ mới, số người tham gia và những điều kiện cục bộ.
Các trọng số sẽ được gán cho mỗi chỉ số thiệt hại và các yếu tố sinh lỗi. Đối với mỗi bộ phận của hệ thống, các giá trị cũng được gán cho các chỉ số và các yếu tố sinh lỗi. Các giá trị cao hơn có nghĩa là khu vực này quan trọng hơn hoặc xấu hơn những khu vực khác. Điều này được minh họa trong bảng 2.2. Bảng này được lấy từ Schaefer [7]. Các giá trị này được nhân với trọng số rồi cộng lại với nhau. Các giá trị lớn nhất cho biết các phần có rủi ro cao nhất và sẽ được ưu tiên kiểm thử trước
Vùng kiểm thử Mức độ quan trọng Mức hiện diện Độ phức tạp Tần xuất thay đổi RỦI RO Trọng số 3 10 3 3 Nhận đặt hàng 2 4 5 1 46*18 Báo giá 4 5 4 2 62*18 Thống kê đơn hàng 2 1 3 3 16*18 Lập báo cáo quản lý 2 1 2 4 16*18 Thực hiện đơn hàng 5 4 0 1 55*3 Làm thống kê 1 1 0 0 13*0 Thực hiện báo giá 4 1 0 1 22*3 Bảng 2.2: Ví dụ về tính toán rủi ro 2.6 So sách các cách tiếp cận khác nhau
Hai ví dụ đã được trình bày trên đây đều sử dụng rủi ro để ưu tiên kiểm thử. Nhiều người sử dụng các phương pháp tương tự như phương pháp của Amland, trong đó chủ yếu là tìm cho ra các yếu tố có thể làm tăng chi phí và
hậu quả do lỗi phát sinh từ một số bộ phận của sản phẩm. Amland xem xét các chi phí liên quan đến vấn đề bảo trì, những phát sinh từ phía luật pháp, và uy tín đối với người bán và khách hàng, trong khi Schaefer [7] và Besson tìm xem những chức năng nào có tầm quan trọng cao nhất và gây ra phiền phức nhất cho người sử dụng.
Schaefer [7] xem xét nhiều yếu tố làm tăng khả năng có thể xảy ra đối với một lỗi nào đó do người phát triển tạo ra – các lỗi này có thể được gọi là ổ phát sinh sai sót. Từ những ổ phát sinh sai sót này, có thể tìm thấy những bộ phận có thể có nhiều lỗi nhất. Besson lại tìm hiểu xem một hỏng hóc sẽ gây trở ngại cho người sử dụng ở một mức độ nào và tần suất xuất hiện của nó để đưa ra thứ tự ưu tiên kiểm thử cái gì trước. Chen có nhiều ý tưởng giống như Amland, nhưng lại chú yếu nhiều đến các ca kiểm thử hơn là các chức năng hệ thống.
Gerrard [4] sử dụng một cách khác để phân loại ưu tiên những gì phải kiểm thử. Thay vì xem xét các bộ phận khác nhau của sản phẩm, một phân tích rủi ro về các kiểu lỗi khác nhau sẽ được tiến hành. Các kiểm thử được sinh ra dựa vào các kiểu lỗi với mức ưu tiên cho các kiểu lỗi có độ rủi ro cao nhất. Việc này cũng tương tự của Stålhane và Sivertsen đã sử dụng HazOp để tìm thấy các nguy cơ rủi ro. Số lượng và độ nghiêm trọng của các mối hiểm nguy đối với mỗi chức năng được sử dụng để phân loại ưu tiên kiểm thử. Đây là một cách khác để phân loại các vùng có vấn đề trong một phân tích rủi ro. Phân tích rủi ro được thực hiện để quyết định những chức năng nào cần phải tăng cường nỗ lực hơn nữa, nhưng cũng có thể được sử dụng để quyết định những chức năng nào phải kiểm thử.
Stålhane phân tích các ca sử dụng có thể thất bại ra sao. Điều này cũng tương tự phương thức kiểm thử từ trong ra (inside-out) của Bach. Stålhane đánh giá mức độ nghiêm trọng đối vói từng kiểu thất bại. Hai phương pháp
tiếp cận này không chỉ ra phải kiểm thử cái gì mà chỉ cố gắng tìm ra các rủi ro để phát hiện các hỏng hóc có thể xảy ra. Các phương pháp này có thể hữu dụng khi các ca sử dụng được thu thập lại, nhưng rất khó để có thể tạo ra một công cụ phần mềm hỗ trợ được cho người kiểm thử.
Tóm tắt Chương 2
Tóm lại, trong chương này chúng ta đã tìm hiểu về cách phân loại ưu tiên kiểm thử và cách sắp xếp ưu tiên kiểm thử cho những bộ phận có nguy cơ xảy ra sai sót cao. Hiểu được các nhân tố gây ra thiệt hại và một số cách tìm ra được chúng. So sánh các cách kiểm thử để hiểu rằng các phương pháp này có thể hữu dụng khi các ca sử dụng được thu thập lại, nhưng lại rất khó để tạo ra một công cụ phần mềm hỗ trợ người kiểm thử.
Chương sau sẽ trình bày một phương pháp kiểm thử mới kết hợp một số quan điểm về các chỉ số tác động tới các thiệt hại do rủi ro gây ra.
Chương 3 Một phương pháp kiểm thử mới
Trong Chương 2, chúng ta đã thấy rõ hiện có một số cách để tìm ra các nhân tố gây ra thiệt hai. Các nhân tố gây thiệt hại là các nhân tố được xem xét đối với một bộ phận nào đó của hệ thống mà sẽ gây ra mất mát lớn hơn nếu có các sai sót trong bộ phận này. Thứ nhất là phải xem xem từng bộ phận của hệ thống có vai trò, được hiện hữu và được sử dụng như thế nào trong hệ thống. Thứ hai là phải xem xét những hậu quả của các sai sót này sẽ gây thiệt hại cho người bán (người phát triển hệ thống) và người mua (người sử dụng hệ thống) như thế nào. Các hậu quả ở đây có thể là vô hình như mất thương hiệu (danh dự, uy tín), chịu các hình phạt về luật pháp hoặc hữu hình như chi phí bảo trì cao hơn chẳng hạn.
Trong chương này sẽ đề xuất một giải pháp kiểm thử mới kết hợp cả hai quan điểm nói trên về các chỉ số tác động tới các thiệt hại do rủi ro gây ra. Lỗi được tìm ra trong quá trình phân tích rủi ro và rủi ro của từng bộ phận trong hệ thống được gộp chung để tìm ra và sắp xếp thứ tự ưu tiên cho việc kiểm thử. Phương pháp được trình bày ở đây dự kiến sẽ được thực hiện bằng một công cụ phần mềm.
3.1 Sắp thứ tự ưu tiên các rủi ro và tạo lập các kiểm thử và các rào cản có liên quan 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.
3.2 Sắp thứ tự ưu tiên kiểm thử cho các modules trong hệ thống
Phần này sẽ miêu tả cách thức ước lượng rủi ro cho từng module trong một hệ thống; Đồng thời còn nghiên cứu các nhóm nguy cơ ảnh hưởng đến thiệt hại do hỏng hóc gây ra và các ổ sinh lỗi trong qúa trình phát triển hệ thống và lập trình. Các nhân tố này sẽ được sử dụng trong phương pháp kiểm thử mới và được trình bày trong bảng 3.4. Chúng ta sẽ sử dụng công thức tính toán độ phơi nhiễm rủi ro như đã mô tả trong phần 2.1, trong đó hậu quả sẽ được thay thế bằng chi phí.
Nhân tố chi phí Ổ phát sinh sai sót tử quá trình phát triển
Ổ phát sinh sai sót khi lập trình
Độ quan trọng Các phương pháp mới Độ phức tạp Mức hiện diện Các công cụ hoặc kỹ thuật mới Số lượng của lỗi Hay được dùng Số người tham gia Các thay đổi
Uy tín Sức ép thời gian Chất lượng thiết kế Khả năng bảo trì Tối ưu hóa
Hậu quả pháp lý Số lượng các rủi ro
Bảng 3.4: Các nhóm rủi ro và các nhân tố rủi ro được sử dụng trong phân tích rủi ro
Đối với mỗi dự án, điều quan trọng là phải quyết định sớm ngay từ khi phát triển những nhân tố rủi ro nào sẽ được sử dụng. Không phải tất cả các nhân tố rủi ro (các nhân tố chi phí và những nhân tố phát sinh sai sót) đều có
liên quan đến dự án. Một vài nhân tố rủi ro có thể quá khó hoặc quá tốn kém để có thể đánh giá được một cách cặn kẽ. Để đơn giản hơn trong khi đánh giá các rủi ro, chúng ta có thể đề xuất sử dụng cùng một số các nhân tố rủi ro và các nhân tố phát sinh sai sót. Điều này sẽ tạo ra sự cân bằng giữa hậu quả và xác suất. Nếu chọn nhiều nhân tố phát sinh sai sót hơn thì xác suất của những sai sót sẽ có một ảnh hưởng lớn hơn trong độ phơi nhiễm rủi ro. Một vài nhân tố rủi ro có thể sẽ bị bỏ qua sau khi việc phân tích các rủi ro đã được thực hiện, nếu như việc thu thập đủ các dữ liệu chính xác cho tất cả các module là khó khăn. Ngoài ra còn có một giới hạn về số lượng các nhóm rủi ro mà chúng ta sẽ cần đến để thực hiện được một phân tích rủi ro có ích. Nếu có quá nhiều nhân tố rủi ro được chọn thì cũng chả khác gì việc tốn thời gian và nỗ lực để xem xét được tất cả. Do đó, chỉ nên chọn những nhóm rủi ro quan trọng nhất đối với dự án. Mỗi nhân tố rủi ro sẽ được gán một trọng số. Trọng