ThS37.079_Cách tiếp cận kiểm thử khác nhau và đề xuất phương pháp kiểm thử hệ thống
Kiểm thử phần mềm là một công việc đòi hỏi rất nhiều thời gian trong qui trình phát triển phần mềm. Thế nhưng, kiểm thử phần mềm lại thường được thực hiện vào pha gần cuối của vòng đời phát triển hệ thống khi tiền bạc và thời gian không còn dư rả nữa. Những người quản lý đều rất mong muốn sớm có được một phiên bản của sản phẩm và thường thúc ép những người kiểm thử phải hoàn thành công việc trong một khoảng thời gian không dễ dàng có thể thực hiện được. Nhưng cho dù thế nào thì những người kiểm thử vẫn phải làm công việc của họ, và vì vậy có thể họ không thể kiểm thử tất cả những thứ cần phải kiểm thử. Do đó, họ chỉ kiểm thử những thứ mà họ cho là quan trọng nhất.
Mục tiêu của luận văn là nghiên cứu các cách tiếp cận kiểm thử khác nhau và tìm cách đề xuất một phương pháp kiểm thử hệ thống dựa trên các rủi ro đã phân tích được. Những rủi ro có thể có đối với hệ thống sẽ được phân tích cho từng ca sử dụng. Việc đánh giá những rủi ro này sẽ được sử dụng để tìm ra bản chất của rủi ro cho từng ca sử dụng. Các ca kiểm thử sẽ được thiết lập từ những ca sử dụng này và các ca kiểm thử có rủi ro cao nhất sẽ được chọn để thực hiện. Ngoài ra, trong luận văn sẽ xác định thêm những yêu cầu cần thiết cho việc xây dựng một công cụ phần mềm hỗ trợ cho phương pháp kiểm thử này và đề xuất một mô hình thử nghiệm.
Kinh nghiệm cho thấy khi gặp một vấn đề nào đó trong cuộc sống, con người thường giải quyết bằng cách nhớ lại những vấn đề họ đã gặp trước đây để tìm ra vấn đề tương tự, rồi lục lại trí nhớ để tìm lại cách giải quyết của vấn đề tương tự này, và cuối cùng điều chỉnh cách giải quyết vừa tìm thấy nếu cần thiết để đưa ra cách giải quyết hợp lý cho vấn đề hiện tại của mình. Trong phân tích và quản lý rủi ro cũng vậy, khi tiếp nhận một dự án, những người quản trị dự án bao giờ cũng nhớ lại những dự án trong quá khứ mà họ đã quản lý để tìm ra một số dự án tương tự, sau đó tìm lại danh sách rủi ro của các dự án tương tự này, và cuối cùng hiệu chỉnh trên các danh sách rủi ro vừa tìm thấy cho phù hợp với ngữ cảnh hiện tại để đưa ra dự đoán danh sách rủi ro cho dự án đang phát triển. Thực tế, các dự án luôn luôn có một độ tương tự nhất định tùy theo hướng nhìn nhận của người quản trị dự án và rủi ro phần mềm là một vấn đề phức tạp không nằm trong tầm kiểm soát của người quản trị dự án.
Mục tiêu của mô hình là đảm bảo tự động hóa một phần quá trình phân tích và quản lý rủi ro. Dựa trên những thông tin về phân tích và quản lý rủi ro của các dự án phần mềm đã hoàn thành, mô hình đưa ra một dự đoán danh sách rủi ro cho dự án hiện tại, và mỗi rủi ro trong danh sách này là một trong những rủi ro đã được dự đoán trong quá khứ. Vì vậy khi sử dụng mô hình này, các nhà quản trị dự án có thể tận dụng và trau dồi những kinh nghiệm phân tích và quản lý rủi ro mà họ đã trải qua trong quá khứ, và họ có thể tự bổ sung kinh nghiệm bằng cách thêm những rủi ro mới xuất hiện và kế hoạch quản lý rủi ro tương ứng vào danh sách rủi ro của dự án hiện tại.
Ngoài ra, do đặc điểm của lý thuyết, mô hình thử nghiệm được đề xuất trong luận văn chỉ áp dụng trong một ngữ cảnh hẹp, chẳng hạn một công ty phần mềm. Hiện nay, các công ty phần mềm có xu hướng phát triển phần mềm trong một số lĩnh vực nhất định, đáp ứng nhu cầu của một số đối tượng khách hàng nhất định, sử dụng một số công nghệ phát triển nhất định, … nên xây dựng mô hình trong một ngữ cảnh hẹp là hoàn toàn hợp lý