MỤC LỤC

MỤC LỤC 1[FONT="]

DANH MỤC CÁC HÌNH 3[FONT="]

LỜI NÓI ĐẦU 4[FONT="]

TÓM TẮT NỘI DUNG 6[FONT="]

CHƯƠNG 1.[FONT="] TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM . 7[FONT="]

1.1[FONT="] Các khái niệm cơ bản về kiểm thử phần mềm 7[FONT="]

1.1.1[FONT="] Kiểm thử phần mềm là gì?. 7[FONT="]

1.1.2[FONT="] Các phương pháp kiểm thử. 8[FONT="]

1.1.2.1[FONT="] Kiểm thử tĩnh – Static testing. 8[FONT="]

1.1.2.2[FONT="] Kiểm thử động – Dynamic testing. 8[FONT="]

1.1.3[FONT="] Các chiến lược kiểm thử. 9[FONT="]

1.1.3.1[FONT="] Kiểm thử hộp đen – Black box testing. 9[FONT="]

1.1.3.2[FONT="] Kiểm thử hộp trắng – White box testing. 10[FONT="]

1.1.3.3[FONT="] Kiểm thử hộp xám – Gray box testing. 11[FONT="]

1.1.4[FONT="] Các cấp độ kiểm thử phần mềm 11[FONT="]

1.1.4.1[FONT="] Kiểm thử đơn vị – Unit test 12[FONT="]

1.1.4.2[FONT="] Kiểm thử tích hợp – Intergration Test 13[FONT="]

1.1.4.3[FONT="] Kiểm thử hệ thống – System Test 15[FONT="]

1.1.4.4[FONT="] Kiểm thử chấp nhận sản phẩm – Acceptance Test 17[FONT="]

1.1.4.5[FONT="] Một số cấp độ kiểm thử khác. 18[FONT="]

1.1.5[FONT="] Các phương pháp kiểm thử con người 19[FONT="]

1.1.5.1[FONT="] Tổng duyệt – Walkthrough. 19[FONT="]

1.1.5.2[FONT="] Thanh tra mã nguồn – Code Inspection. 20[FONT="]

1.2[FONT="] Nguyên tắc kiểm thử phần mềm 20[FONT="]

CHƯƠNG 2.[FONT="] THIẾT KẾ TEST – CASE 22[FONT="]

2.1[FONT="] Khái niệm 22[FONT="]

2.2[FONT="] Vai trò của thiết kế test – case. 22[FONT="]

2.3[FONT="] Quy trình thiết kế test – case. 22[FONT="]

2.3.1[FONT="] Kiểm thử hộp trắng - Kiểm thử bao phủ logic. 24[FONT="]

2.3.1.1[FONT="] Bao phủ câu lệnh – Statement Coverage. 25[FONT="]

2.3.1.2[FONT="] Bao phủ quyết định – Decision coverage. 26[FONT="]

2.3.1.3[FONT="] Bao phủ điều kiện – Condition coverage. 27[FONT="]

2.3.1.4[FONT="] Bao phủ quyết định/điều kiện – Decision/condition coverage. 29[FONT="]

2.3.1.5[FONT="] Bao phủ đa điều kiện – Multiple condition coverage. 30[FONT="]

2.3.2[FONT="] Kiểm thử hộp đen. 32[FONT="]

2.3.2.1[FONT="] Phân lớp tương đương – Equivalence Patitioning. 32[FONT="]

2.3.2.2[FONT="] Phân tích giá trị biên – Boundary Value Analysis. 35[FONT="]

2.3.2.3[FONT="] Đồ thị nguyên nhân – kết quả - Cause & Effect Graphing. 36[FONT="]

2.3.2.4[FONT="] Đoán lỗi – Error Guessing. 42[FONT="]

2.3.3[FONT="] Chiến lược. 43[FONT="]

CHƯƠNG 3.[FONT="] ÁP DỤNG 44[FONT="]

3.1[FONT="] Đặc tả. 44[FONT="]

3.2[FONT="] Thiết kế test – case. 46[FONT="]

3.2.1[FONT="] Vẽ đồ thị nguyên nhân – kết quả. 46[FONT="]

3.2.2[FONT="] Phân lớp tương đương. 50[FONT="]

3.2.2.1[FONT="] Xác định các lớp tương đương. 50[FONT="]

3.2.2.2[FONT="] Xác định các ca kiểm thử. 50[FONT="]

3.2.3[FONT="] Phân tích giá trị biên. 51[FONT="]

3.2.3.1[FONT="] Xét các trạng thái đầu vào. 51[FONT="]

3.2.3.2[FONT="] Xét không gian kết quả. 51[FONT="]

3.2.4[FONT="] Các phương pháp hộp trắng. 52[FONT="]

3.2.4.1[FONT="] Bao phủ câu lệnh. 52[FONT="]

3.2.4.2[FONT="] Bao phủ quyết định. 54[FONT="]

3.2.4.3[FONT="] Bao phủ điều kiện. 55[FONT="]

3.2.4.4[FONT="] Bao phủ quyết định – điều kiện. 55[FONT="]

3.2.4.5[FONT="] Bao phủ đa điều kiện. 55[FONT="]

TÀI LIỆU THAM KHẢO 57[FONT="]

KẾT LUẬN 58[FONT="]

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

LỜI NÓI ĐẦU

Trong ngành kỹ nghệ phần mềm, năm 1979, có một quy tắc nổi tiếng là: “Trong một dự án lập trình điển hình, thì xấp xỉ 50% thời gian và hơn 50% tổng chi phí được sử dụng trong kiểm thử các chương trình hay hệ thống đã được phát triển”. Và cho đến nay, sau gần một phần 3 thế kỷ, quy tắc đó vẫn còn đúng. Đã có rất nhiều ngôn ngữ, hệ thống phát triển mới với các công cụ tích hợp cho các lập trình viên sử dụng phát triển ngày càng linh động. Nhưng kiểm thử vẫn đóng vai trò hết sức quan trọng trong bất kỳ dự án phát triển phần mềm nào.

Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “ Sinh viên của chúng ta tốt nghiệp và đi làm mà không có được những kiến thực thực tế cần thiết về cách để kiểm thử một chương trình. Hơn nữa, chúng ta hiếm khi có được những lời khuyên bổ ích để cung cấp trong các khóa học mở đầu về cách một sinh viên nên làm về kiểm thử và gỡ lỗi các bài tập của họ”.

Các tác giả của cuốn sách nổi tiếng “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm,Glenford J. Myers, Tom Badgett, Todd M. Thomas, Corey Sandler đã khẳng định trong cuốn sách của mình rằng: “ Hầu hết các thành phần quan trọng trong các thủ thuật của một nhà kiểm thử chương trình là kiến thức về cách để viết các ca kiểm thử có hiệu quả”. Việc xây dựng các test – case là một nhiệm vụ rất khó khăn. Để có thể xây dựng được tập các test – case hữu ích cho kiểm thử, chúng ta cần rất nhiều kiến thức và kinh nghiệm.

Đó là những lý do thúc đẩy em thực hiện đề tài này. Mục đích của đề tài là tìm hiểu những kiến thức tổng quan nhất về kiểm thử, và cách thiết kế test – case trong kiểm thử phần mềm. Việc thực hiện đề tài sẽ giúp em tìm hiểu sâu hơn và lĩnh vực rất hấp dẫn này, vận dụng được các kiến thức đã học để có thể thiết kế được các test – case một cách có hiệu quả và áp dụng vào những bài toán thực tế.

Bản báo cáo được hoàn thành dưới sự chỉ bảo tận tình của thầy giáo, ThS Nguyễn Hồng Tân, sự giúp đỡ nhiệt tình của các thầy cô trong bộ môn Công nghệ phần mềm, và tất cả các bạn. Em hi vọng sẽ nhận được sự đóng góp ý kiến của các thầy cô và các bạn để bản báo cáo được hoàn thiện hơn. Những đóng góp đó sẽ là kinh nghiệm quý báu cho em. Và từ đó, em có thể tiếp tục phát triển đề tài này cho đợt thực tập tốt nghiệp và đồ án tốt nghiệp sắp tới, cũng như cho công việc trong tương lai.

59[FONT="