Raocan.aspx mang đến cho người dùng khả năng tạo ra những rào cản cho mỗi rủi ro. Rào cản là một hoạt động để cản trở rủi ro xảy ra. Một rào cản được đặt tên và mô tả. Người dùng có thể soạn thảo và xóa một rào cản phụ bằng sử dụng mối liên kết “Xóa”. Những rào cản mới được thêm dưới bảng. Có thể thêm một kiểm thử mà rào cản đang làm việc bởi ấn vào liên kết “Thêm kiểm thử” tới trang Taokiemthu.aspx. Nút “Đồng ý” đưa người sử dụng trở về trang Trangchu.aspx. Raocan.aspx sử dụng những yêu cầu chức năng : F - 29, F - 30, F - 31, F - 32 và F - 33.
4.5 Thử nghiệm với công cụ phần mềm
Công cụ đã được thử nghiệm bởi người kiểm thử giàu kinh nghiệm của những hệ thống lớn với sự phát triển của những công cụ cho kiểm thử. Khi kiểm thử học dường như người kiểm thử không hiểu rõ thời hạn sử dụng công cụ phần mềm. Họ cần nhiều giải thích và hướng dẫn. Có những vấn đề cần hiểu được quan hệ giữa những thứ được làm và tại sao chúng được làm. Việc này có thể giúp người sử dụng qua cách đọc tài liệu, bao gồm giải thích công cụ phần mềm và một file giúp đỡ. Một bản demo cách sử dụng những công cụ phần mềm và khái niệm liên quan cho người dùng mới cũng là cần thiết.
Có một số vấn đề liên quan đến giao diện người dùng. Những điều đó đã được sửa đổi trong trình bày ở mục 4.3. Người kiểm thử yêu cầu khả năng sửa đổi ma trận rủi ro thành module rủi ro. Hơn nữa, nó cũng cần dễ dàng để những gì áp dụng cho module X cũng cần áp dụng cho module Y và Z. Tính hoạt động này không có do bị giới hạn về thời gian, nhưng có thể được thực hiện trong những phiên bản công cụ phần mềm tới.
Do mục tiêu thực hiện công cụ phần mềm này không phải là thương mại nên không thể tránh khỏi những sai sót, nó chỉ là một bản thực nghiệm để chứng minh các khái niệm được nêu.
Tóm tắt chương 4
Thuật ngữ kiểm thử hệ thống dựa trên các rủi ro đã được nói đến ở trên. Những phương pháp ưu tiên kiểm thử chia rủi ro cho mỗi hệ thống đang kiểm tra hoặc các rủi ro mà kiểm thử hướng tới. Trong báo cáo này đã giới thiệu một phương pháp cho kiểm thử hệ thống dựa trên các rủi ro đã nhận dạng được và cố gắng sử dụng tốt nhất một số phương pháp đã nêu. Ưu tiên những hệ thống con được Amland [2] và Schaefer [7] mô tả đã sử dụng trong phương pháp này. Ưu tiên những kiểm thử liên quan đến rủi ro được Gerrard [4] mô tả đã áp dụng kiểm thử cho những rào cản. Hai cách tiếp cận trên đã được kết hợp để ưu tiên những kiểm thử trong phương pháp này.
Tuy nhiên công cụ được xây dựng mô phỏng trên đây mới chỉ giải quyết một bài toán nhỏ trong lớp các bài toán kiểm thử phần mềm, nó chưa phải là tối ưu và vẫn còn một số nhu cầu cần sửa đổi, bổ sung và cải tiến trước khi có thể được ứng dụng. Trong một dự án phần mềm thường sử dụng nhiều công cụ để kiểm thử với chức năng nhiệm vụ khác nhau, được sử dụng trong từng giai đoạn cụ thể và thường phải quyết định lựa chọn công cụ nào sẽ được sử dụng, sử dụng trong giai đoạn nào. Thêm vào đó là sự phát triển như vũ bão của công nghệ, kỹ thuật hiện đại. Chính vì vậy để xây dựng được một công cụ có thể giải quyết được mọi vấn đề, đáp ứng được mọi yêu cầu của kiểm thử phần mềm là rất khó khăn.
Kết luận
Trong quá trình thực hiện đồ án tốt nghiệp tôi đã thu được một số kết quả như sau:
1. Nắm được khái niệm cơ bản bao gồm nguyên tắc và kỹ thuật của phân tích và quản lý rủi ro trong phát triển phần mềm; các cách tiếp cận kiểm thử phần mềm dựa trên rủi ro và so sánh.
2. Tìm hiều và nắm được một số kỹ thuật kiểm thử phần mềm. 3. Đề xuất một phương pháp kiểm thử dựa trên rủi ro.
4. Bước đầu phân tích các yêu cầu của công cụ phần mềm kiểm thử và thiết kế các giao diện và cơ sở dữ liệu của công cụ.
5. Nâng cao được khả năng đọc, hiểu và dịch tài liệu tiếng Anh cho bản thân. Tuy nhiên do thời gian có hạn, kinh nghiệm bản thân trong thực tế chưa nhiều và còn do đây là một vấn đề rất mới mẻ không chỉ đối với bản thân tôi mà còn rất mới mẻ tại Việt Nam nên chắc chắn trong bản báo cáo còn nhiều hạn chế. Hy vọng đây sẽ là bước đệm tốt cho những nghiên cứu và công việc sau này. Hướng nghiên cứu tiếp theo của tôi là phát triển công cụ phần mềm và chạy thử nghiệm ở một vài dự án phát triển phần mềm.
Tôi mong nhận được những nhận xét, chỉ bảo của các thầy, cô để làm cơ sở cho hướng phát triển sau này. Tôi xin chân thành cảm ơn!
Tài liệu tham khảo
Tiếng Anh
[1] Ed Adams (1984), Optimising preventive service of software products, IBM J. Research and Development, 28, 1, pp 2-14
[2] Ståle Amland (1999) Risk Based Testing and Metrics, EuroSTAR '99,
Barcelona.
[3] James Bach (1999) Heuristic Risk-Based Testing, Software Testing and Quality Magazine.
[4] Paul Gerrard (2002) Risk-Based E-Business Testing, ISBN 1580533140,
pp 3 – 29 and 51 - 80
[5] Marnie L. Hutcheson (2003) Software Tesing Fundamentals, ISBN 0-471- 43020-X.
[6] Glenford J. Myers (1979), The art of software testing.
[7] Hans Schaefer (1998), Strategies for Prioritizing Tests, STAR WEST. [8] Shamus P. Smith, Michael D. Harrison and Bastiaan A Schupp (2004),
How explicit are the barriers to failure in safety arguments?, In Proceedings
of the SafeComp.
[9] IEC 61508-5 (1998) Functional safety of electronical/electronic/ programmable electronic safety-related systems.
Website
[10] Website: http://www.wikipedia.org.
[11] Website: http://www.VietNameseTestingBoard.com. [12] Website: http://www.ddth.com.