Đồ án môn học kiểm thử phần mềm

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 Trần Văn Đại, sự giúp đỡ nhiệt tình của các thầy cô trong khoa CNTT, 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.

Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại MỤC LỤC MỤC LỤC DANH MỤC CÁC HÌNH LỜI NÓI ĐẦU TÓM TẮT NỘI DUNG CHƯƠNG TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM .6 1.1CÁC KHÁI NIỆM CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM 1.1.1 Kiểm thử phần mềm gì? 1.1.2 Các phương pháp kiểm thử 1.1.2.1 Kiểm thử tĩnh – Static testing 1.1.2.2 Kiểm thử động – Dynamic testing 1.1.3 Các chiến lược kiểm thử 1.1.3.1 Kiểm thử hộp đen – Black box testing 1.1.3.2 Các phương pháp kiểm thử hộp đen 1.1.3.3 Ưu, nhược điểm 1.1.3.4 Kiểm thử hộp trắng – White box testing 1.1.3.5 Các phương pháp kiểm thử hộp trắng 1.1.3.6 Kiểm thử hộp xám – Gray box testing 1.1.4 Các cấp độ kiểm thử phần mềm 1.1.4.1 Kiểm thử đơn vị – Unit test 10 1.1.4.2 Kiểm thử tích hợp – Intergration Test 11 1.1.4.3 Kiểm thử chấp nhận sản phẩm – Acceptance Test 13 1.1.4.4 Một số cấp độ kiểm thử khác .14 1.1.4.5 Kiểm thử hồi quy – Regression Testing: .14 1.1.4.6 Kiểm thử tính – Correctness testing: 15 1.1.5 Các phương pháp kiểm thử người 15 1.1.5.1 Tổng duyệt – Walkthrough 15 1.1.5.2 Thanh tra mã nguồn – Code Inspection .16 1.2 NGUYÊN TẮC KIỂM THỬ PHẦN MỀM 16 CHƯƠNG THIẾT KẾ TEST – CASE 17 2.1KHÁI NIỆM 17 2.2VAI TRÒ CỦA THIẾT KẾ TEST – CASE 17 2.3QUY TRÌNH THIẾT KẾ TEST – CASE 17 2.3.1 Kiểm thử hộp trắng - Kiểm thử bao phủ logic .18 2.3.1.1 Bao phủ câu lệnh – Statement Coverage 18 2.3.1.2 Bao phủ định – Decision coverage .19 2.3.1.3 Bao phủ điều kiện – Condition coverage 20 2.3.1.4 Bao phủ định/điều kiện – Decision/condition coverage 22 2.3.1.5 Bao phủ đa điều kiện – Multiple condition coverage 23 2.3.2 Kiểm thử hộp đen 24 2.3.2.1 Phân lớp tương đương – Equivalence Patitioning 24 2.3.2.2 Xác định lớp tương đương .25 2.3.2.3 Xác định ca kiểm thử .26 2.3.2.4 Phân tích giá trị biên – Boundary Value Analysis 26 2.3.2.5 Đồ thị nguyên nhân – kết - Cause & Effect Graphing 27 2.3.2.6 NHẬN XÉT 31 2.3.2.7 Đoán lỗi – Error Guessing 32 2.3.3 Chiến lược 33 CHƯƠNG ÁP DỤNG BÀI TOÁN THỰC TẾ 34 3.1.ĐẶC TẢ 34 3.2.THIẾT KẾ TEST – CASE 34 3.2.1 Vẽ đồ thị nguyên nhân – kết 34 Nguyên nhân 34 Kết 34 1.Từ lao động đến 100 lao động 34 5.Giá trị nhập vào số âm, số nguyên dương nhỏ giá trị số 34 100.Phí bảo hiểm 590.000 đồng 34 SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại 101.Phí bảo hiểm 800.000 đồng 34 102.Phí bảo hiểm 960.000 đồng 34 103.Phí bảo hiểm 1.050.000 đồng 34 104.Thông báo lỗi nhập liệu .34 1.1.5.3 Từ 20 lao động đến < 50 lao động .35 1.1.5.4 >100 lao động 35 3.2.2 Phân lớp tương đương 36 3.2.2.1 Xác định lớp tương đương 36 3.2.2.2 Xác định ca kiểm thử .36 3.2.3 Phân tích giá trị biên 36 3.2.3.1 Xét trạng thái đầu vào 36 3.2.3.2 Xét không gian kết 36 KẾT LUẬN 38 TÀI LIỆU THAM KHẢO 39 NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN 40 SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại DANH MỤC CÁC HÌNH HÌNH 1.1 SƠ ĐỒ CÁC CẤP ĐỘ KIỂM THỬ 10 HÌNH 2.1 MỘT CHƯƠNG TRÌNH NHỎ ĐỂ KIỂM THỬ .19 HÌNH 2.2 MÃ MÁY CHO CHƯƠNG TRÌNH TRONG HÌNH 2.1 22 HÌNH 2.3 MỘT MẪU CHO VIỆC LIỆT KÊ CÁC LỚP TƯƠNG ĐƯƠNG 25 HÌNH 2.4 CÁC KÝ HIỆU ĐỒ THỊ NGUYÊN NHÂN – KẾT QUẢ CƠ BẢN 29 HÌNH 2.5 CÁC KÝ HIỆU RÀNG BUỘC 30 HÌNH 2.6 NHỮNG XEM XÉT ĐƯỢC SỬ DỤNG KHI DÒ THEO ĐỒ THỊ 31 SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại LỜI NÓI ĐẦU Trong ngành kỹ nghệ phần mềm, năm 1979, có quy tắc tiếng là: “Trong dự án lập trình điển hình, xấp xỉ 50% thời gian 50% tổng chi phí sử dụng kiểm thử chương trình hay hệ thống phát triển” Và nay, sau gần phần kỷ, quy tắc Đã có nhiều ngôn ngữ, hệ thống phát triển với công cụ tích hợp cho lập trình viên sử dụng phát triển ngày linh động Nhưng kiểm thử đóng vai trò quan trọng dự án phát triển phần mềm Rất nhiều giáo sư, giảng viên than phiền rằng: “ Sinh viên tốt nghiệp làm mà kiến thực thực tế cần thiết cách để kiểm thử chương trình Hơn nữa, có lời khuyên bổ ích để cung cấp khóa học mở đầu cách sinh viên nên làm kiểm thử gỡ lỗi tập họ” Các tác giả sách 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 sách rằng: “ Hầu hết thành phần quan trọng thủ thuật nhà kiểm thử chương trình kiến thức cách để viết ca kiểm thử có hiệu quả” Việc xây dựng test – case nhiệm vụ khó khăn Để xây dựng tập test – case hữu ích cho kiểm thử, cần nhiều kiến thức kinh nghiệm Đó lý thúc đẩy em thực đề tài Mục đích đề tài tìm hiểu kiến thức tổng quan kiểm thử, cách thiết kế test – case kiểm thử phần mềm Việc thực đề tài giúp em tìm hiểu sâu lĩnh vực hấp dẫn này, vận dụng kiến thức học để thiết kế test –case cách có hiệu áp dụng vào toán thực tế Bản báo cáo hoàn thành bảo tận tình thầy giáo, Ths Trần Văn Đại, giúp đỡ nhiệt tình thầy cô khoa CNTT, tất bạn Em hi vọng nhận đóng góp ý kiến thầy cô bạn để báo cáo hoàn thiện Những đóng góp kinh nghiệm quý báu cho em Và từ đó, em tiếp tục phát triển đề tài cho đợt thực tập tốt nghiệp đồ án tốt nghiệp tới, cho công việc tương lai Em xin chân thành cám ơn SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại TÓM TẮT NỘI DUNG Bản báo cáo chia thành chương với nội dung sau: • Chương 1: Tổng quan kiểm thử phần mềm Chương nhìn tổng quan kiểm thử phần mềm: khái niệm kiểm thử phần mềm, quy tắc kiểm thử, phương pháp kiểm thử phần mềm tiêu biểu • Chương 2: Thiết kế test – case kiểm thử phần mềm Trong chương này, em tìm hiểu phương pháp thiết kế test – case có hiệu Từ rút nhận xét ưu nhược điểm phương pháp • Chương 3: Áp dụng toán thực tế Từ phương pháp thiết kế test – case tìm hiểu Chương 2, em áp dụng để xây dựng tập test – case cho toán cụ thể : Thiết kế test – case cho chương trình “Tam giác” SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại CHƯƠNG TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1 Các khái niệm kiểm thử phần mềm 1.1.1 Kiểm thử phần mềm gì? Kiểm thử phần mềm trình khảo sát hệ thống hay thành phần điều kiện xác định, quan sát ghi lại kết quả, đánh giá khía cạnh hệ thống hay thành phần (Theo Bảng giải thuật ngữ chuẩn IEEE Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software Engineering Terminology) Kiểm thử phần mềm trình thực thi chương trình với mục đích tìm lỗi (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm) Kiểm thử phần mềm hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm môi trường chúng dự định triển khai nhằm cung cấp cho người có lợi ích liên quan thông tin chất lượng sản phẩm hay dịch vụ phần mềm Mục đích kiểm thử phần mềm tìm lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu hoạt động tối ưu phần mềm nhiều ngành khác (Theo Bách khoa toàn thư mở Wikipedia) Có thể định nghĩa cách dễ hiểu sau: Kiểm thử phần mềm tiến trình hay tập hợp tiến trình thiết kế để đảm bảo mã hóa máy tính thực theo mà chúng thiết kế để làm, không thực thứ không mong muốn Đây pha quan trọng trình phát triển hệ thống, giúp cho người xây dựng hệ thống khách hàng thấy hệ thống đáp ứng yêu cầu đặt hay chưa? 1.1.2 Các phương pháp kiểm thử Có phương pháp kiểm thử là: Kiểm thử tĩnh Kiểm thử động 1.1.2.1Kiểm thử tĩnh – Static testing Là phương pháp thử phần mềm đòi hỏi phải duyệt lại yêu cầu đặc tả tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần chi tiết mà không cần chạy chương trình Kiểu kiểm thử thường sử dụng chuyên viên thiết kế người mà viết mã lệnh Kiểm thử tĩnh tự động hóa Nó thực kiểm tra toàn bao gồm chương trình phân tích trình thông dịch biên dịch mà xác nhận tính hợp lệ cú pháp chương trình SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại 1.1.2.2Kiểm thử động – Dynamic testing Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng thái tác động chương trình Đó kiểm thử dựa ca kiểm thử xác định thực đối tượng kiểm thử hay chạy chương trình Kiểm thử động kiểm tra cách thức hoạt động động mã lệnh, tức kiểm tra phản ứng vật lý từ hệ thống tới biến thay đổi theo thời gian Trong kiểm thử động, phần mềm phải thực biên dịch chạy Kiểm thử động thực bao gồm làm việc với phần mềm, nhập giá trị đầu vào kiểm tra xem liệu đầu có mong muốn hay không Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, Kiểm thử chấp nhận sản phẩm – Acceptance Tests 1.1.3 Các chiến lược kiểm thử Ba số chiến lược kiểm thử thông dụng bao gồm: Kiểm thử hộp đen, Kiểm thử hộp trắng, Kiểm thử hộp xám 1.1.3.1Kiểm thử hộp đen – Black box testing Một chiến lược kiểm thử quan trọng kiểm thử hộp đen, hướng liệu, hay hướng vào/ra Kiểm thử hộp đen xem chương trình “hộp đen” Mục đích bạn hoàn toàn không quan tâm cách cư xử cấu trúc bên chương trình Thay vào đó, tập trung vào tìm trường hợp mà chương trình không thực theo đặc tả Theo hướng tiếp cận này, liệu kiểm tra lấy từ đặc tả 1.1.3.2Các phương pháp kiểm thử hộp đen  Phân lớp tương đương – Equivalence partitioning  Phân tích giá trị biên – Boundary value analysis  Kiểm thử cặp – All-pairs testing  Kiểm thử fuzz – Fuzz testing  Kiểm thử dựa mô hình – Model-based testing  Ma trận dấu vết – Traceability matrix  Kiểm thử thăm dò – Exploratory testing  Kiểm thử dựa đặc tả – Specification-base testing Kiểm thử dựa đặc tả tập trung vào kiểm tra tính thiết thực phần mềm theo yêu cầu thích hợp Do đó, kiểm thử viên nhập liệu vào, thấy SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại liệu từ đối tượng kiểm thử Mức kiểm thử thường yêu cầu ca kiểm thử triệt để cung cấp cho kiểm thử viên mà xác minh liệu đầu vào cho, giá trị đầu (hay cách thức hoạt động) có giống với giá trị mong muốn xác định ca kiểm thử hay không Kiểm thử dựa đặc tả cần thiết, không đủ để để ngăn chặn rủi ro chắn 1.1.3.3Ưu, nhược điểm Kiểm thử hộp đen mối liên quan tới mã lệnh, kiểm thử viên đơn giản tâm niệm là: mã lệnh phải có lỗi Sử dụng nguyên tắc “ Hãy đòi hỏi bạn nhận”, kiểm thử viên hộp đen tìm lỗi mà lập trình viên không tìm Nhưng, mặt khác, người ta nói kiểm thử hộp đen “giống bóng tối mà đèn vậy”, kiểm thử viên phần mềm kiểm tra thực xây dựng Đó lý mà có nhiều trường hợp mà kiểm thử viên hộp đen viết nhiều ca kiểm thử để kiểm tra thứ mà cần kiểm tra ca kiểm thử nhất, và/hoặc số phần chương trình không kiểm tra chút Do vậy, kiểm thử hộp đen có ưu điểm “một đánh giá khách quan”, mặt khác lại có nhược điểm “thăm dò mù” 1.1.3.4Kiểm thử hộp trắng – White box testing Là chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên chương trình Chiến lược xuất phát từ liệu kiểm thử kiểm thử tính logic chương trình Kiểm thử viên truy cập vào cấu trúc liệu giải thuật bên chương trình (và mã lệnh thực chúng) 1.1.3.5Các phương pháp kiểm thử hộp trắng  Kiểm thử giao diện lập trình ứng dụng - API testing (application programming interface): phương pháp kiểm thử ứng dụng sử dụng API công khai riêng tư SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại  Bao phủ mã lệnh – Code coverage: tạo kiểm tra để đáp ứng số tiêu chuẩn bao phủ mã lệnh  Các phương pháp gán lỗi – Fault injection  Các phương pháp kiểm thử hoán chuyển – Mutation testing methods  Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm kiểm thử tĩnh Phương pháp kiểm thử hộp trắng sử dụng để đánh giá hoàn thành kiểm thử mà tạo với phương pháp kiểm thử hộp đen Điều cho phép nhóm phần mềm khảo sát phần hệ thống kiểm tra đảm bảo điểm chức quan trọng kiểm tra 1.1.3.6Kiểm thử hộp xám – Gray box testing Kiểm thử hộp xám đòi hỏi phải có truy cập tới cấu trúc liệu giải thuật bên cho mục đích thiết kế ca kiểm thử, kiểm thử mức người sử dụng hay mức hộp đen Việc thao tác tới liệu đầu vào định dạng liệu đầu không rõ ràng, giống “hộp xám”, đầu vào đầu rõ ràng bên “hộp đen” mà gọi hệ thống kiểm tra Sự khác biệt đặc biệt quan trọng quản lý kiểm thử tích hợp – Intergartion testing modun mã lệnh viết hai chuyên viên thiết kế khác nhau, giao diện đưa để kiểm thử Kiểm thử hộp xám bao gồm thiết kế đối chiếu để định, ví dụ, giá trị biên hay thông báo lỗi 1.1.4 Các cấp độ kiểm thử phần mềm Kiểm thử phần mềm gồm có cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hệ thống Kiểm thử chấp nhận sản phẩm SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm Hình 1.1 GVHD: Trần Văn Đại Sơ đồ cấp độ kiểm thử 1.1.4.1Kiểm thử đơn vị – Unit test Một đơn vị thành phần phần mềm nhỏ mà ta kiểm thử Ví dụ, hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) xem Unit Vì Unit chọn để kiểm tra thường có kích thước nhỏ chức hoạt động đơn giản, không khó khăn việc tổ chức kiểm thử, ghi nhận phân tích kết kiểm thử Nếu phát lỗi, việc xác định nguyên nhân khắc phục tương đối dễ dàng khoanh vùng đơn thể Unit kiểm tra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test đền bù việc tiết kiệm nhiều thời gian chi phí cho việc kiểm thử sửa lỗi mức kiểm thử sau Unit Test thường lập trình viên thực Công đoạn cần thực sớm tốt giai đoạn viết code xuyên suốt chu kỳ phát triển phần mềm Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức thiết kế code chương trình Mục đích Unit Test bảo đảm thông tin xử lý xuất (khỏi Unit) xác, mối tương quan với liệu nhập chức Unit Điều thường đòi hỏi tất nhánh bên Unit phải kiểm tra SVTH: Lê Huy Bảo 10 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại loại lớp tương đương không hợp lệ Nếu trạng thái đầu vào định tình “chắc chắn – must be”, xác định lớp tương đương hợp lệ lớp tương đương không hợp lệ Nếu có lý để tin chương trình không xử lý phần tử lớp nhau, chia lớp tương đương thành lớp tương đương nhỏ 2.3.2.3 Xác định ca kiểm thử Với lớp tương đương xác định bước trên, bước thứ hai sử dụng lớp tương đương để xác định ca kiểm thử Quá trình sau: Gán số cho lớp tương đương Cho đến tất lớp tương đương hợp lệ bao phủ (hợp thành) ca kiểm thử, viết ca kiểm thử bao phủ nhiều lớp tương đương chưa bao phủ tốt Cho đến ca kiểm thử bạn bao phủ tất lớp tương đương không hợp lệ, viết ca kiểm thử mà bao phủ lớp tương đương không hợp lệ chưa bao phủ Lý mà ca kiểm thử riêng bao phủ trường hợp không hợp lệ kiểm tra đầu vào không che giấu thay kiểm tra đầu vào không khác Mặc dù việc phân lớp tương đương tốt lựa chọn ngẫu nhiên ca kiểm thử, có thiếu sót Ví dụ, bỏ qua kiểu test – case có lợi Hai phương pháp tiếp theo, phân tích giá trị biên đồ thị nguyên nhân kết , bao phủ nhiều thiếu sót 2.3.2.4 Phân tích giá trị biên – Boundary Value Analysis Kinh nghiệm cho thấy ca kiểm thử mà khảo sát tỷ mỷ điều kiện biên có tỷ lệ phần trăm cao ca kiểm thử khác Các điều kiện biên điều kiện mà tình tại, cạnh lớp tương đương đầu vào lớp tương đương đầu Phân tích giá trị biên phương pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương, khác với phân lớp tương đương khía cạnh: Phân tích giá trị biên không lựa chọn phần tử lớp tương đương điển hình, mà yêu cầu hay nhiều phần tử lựa chọn mà cạnh lớp tương đương đối tượng kiểm tra SVTH: Lê Huy Bảo 26 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại Ngoài việc tập trung ý vào trạng thái đầu vào (không gian đầu vào), ca kiểm thử nhận việc xem xét không gian kết (các lớp tương đương đầu ra) Phân tích giá trị biên yêu cầu óc sáng tạo lượng chuyên môn hóa định trình mang tính kinh nghiệm cao Tuy nhiên, có số quy tắc chung sau: Nếu trạng thái đầu vào định rõ giới hạn giá trị, viết ca kiểm thử cho giá trị cuối giới hạn, ca kiểm thử đầu vào không hợp lệ cho trường hợp vừa phạm vi Nếu trạng thái đầu vào định rõ số lượng giá trị, viết ca kiểm thử cho số lớn nhỏ giá trị giá trị trên, giá trị giá trị Sử dụng quy tắc cho trạng thái đầu vào Ví dụ, chương trình tính toán khấu trừ FICA hàng tháng mức tối thiểu 0.00$, tối đa 1,165.25$, viết ca kiểm thử mà khấu trừ 0.00$ 1,165.25, khấu trừ âm khấu trừ lớn 1,165.25$ Chú ý việc xem xét giới hạn không gian kết quan trọng lúc biên miền đầu vào mô tả tập kiện biên giới hạn đầu (ví dụ, xét chương trình tính SIN) Ngoài ra, lúc tạo kết bên giới hạn đầu ra, nhiên đáng để xem xét tiềm ẩn Sử dụng nguyên tắc cho trạng thái đầu Nếu đầu vào hay đầu chương trình tập thứ tự ( ví dụ,1 file hay danh sách định tuyến hay bảng) tập trung ý vào phần tử cuối tập hợp Sử dụng khéo léo bạn để tìm điều kiện biên 2.3.2.5 Đồ thị nguyên nhân – kết - Cause & Effect Graphing Một yếu điểm phân tích giá trị biên phân lớp tương đương chúng không khảo sát kết hợp trường hợp đầu vào Việc kiểm tra kết hợp đầu vào nhiệm vụ đơn giản bạn phân lớp tương đương trạng thái đầu vào, số lượng kết hợp thường lớn Nếu bạn cách lựa chọn có hệ thống tập trạng thái đầu vào, có lẽ bạn chọn tập tùy hứng điều kiện, điều dẫn tới việc kiểm thử hiệu SVTH: Lê Huy Bảo 27 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại Đồ thị nguyên nhân – kết hỗ trợ việc lựa chọn cách có hệ thống tập ca kiểm thử có hiệu cao Nó có tác động có lợi ảnh hưởng tới việc tình trạng chưa đầy đủ nhập nhằng đặc tả Nó cung cấp cách biểu diễn xác cho điều kiện logic hành động tương ứng Quá trình sử dụng để xây dựng test – case: Đặc tả chia thành phần thực Điều cần thiết đồ thị nguyên nhân – kết trở nên khó sử dụng sử dụng đặc tả lớn Nguyên nhân kết đặc tả nhận biết Một nguyên nhân trạng thái đầu vào định hay lớp tương đương trạng thái đầu vào Một kết trạng thái đầu hay biến đổi hệ thống (kết lại mà đầu vào có trạng thái chương trình hay hệ thống) Bạn nhận biết nguyên nhân kết việc đọc từ đặc tả gạch chân từ cụm từ mô tả nguyên nhân kết Khi nhận biết, nguyên nhân kết gán cho số Xây dựng đồ thị nguyên nhân – kết cách phát triển biến đổi nội dung ngữ nghĩa đặc tả thành đồ thị Boolean nối nguyên nhân kết Đồ thị được diễn giải với ràng buộc mô tả kết hợp nguyên nhân và/hoặc kết ràng buộc ngữ nghĩa môi trường Bằng việc dò theo điều kiện trạng thái đồ thị cách cẩn thận, bạn chuyển đổi đồ thị thành bảng định mục vào giới hạn Mỗi cột bảng mô tả ca kiểm thử Các cột bảng định chuyển thành ca kiểm thử Ký hiệu cho đồ thị hình 2.4 Tưởng tượng nút có giá trị 1; mô tả trạng thái vắng mặt mô tả trạng thái có mặt Hàm đồng nói a b 1; ngược lại, b Hàm not nói a b 0; ngược lại b Hàm or khẳng định a b c 1, d 1; ngược lại d Hàm and khẳng định a b c 1; ngược lại c Hai hàm or and phép có số lượng đầu vào SVTH: Lê Huy Bảo 28 Đồ án môn học: Kiểm thử phần mềm Hình 2.4 GVHD: Trần Văn Đại Các ký hiệu đồ thị nguyên nhân – kết Trong hầu hết chương trình, kết hợp số nguyên nhân lý ngữ nghĩa môi trường (ví dụ, ký tự đồng thời vừa “A” vừa “B”) đó, ta sử dụng ký hiệu Hình 2.5 Ràng buộc E (Exclude – loại trừ) khẳng định tối đa, có a b (a b đồng thời 1) Ràng buộc I (Include – bao hàm) khẳng định a, b c phải luôn (a, b c đồng thời 0) Ràng buộc O (Only – một) khẳng định a b phải Ràng buộc R (Request – yêu cầu) khẳng định a 1, b phải (ví dụ, có trường hợp a 1, b 0) Ràng buộc M (Mask – mặt nạ) khẳng định kết a 1, kết b bắt buộc phải SVTH: Lê Huy Bảo 29 Đồ án môn học: Kiểm thử phần mềm Hình 2.5 GVHD: Trần Văn Đại Các ký hiệu ràng buộc Bước tạo bảng định mục vào giới hạn – limited-entry decision table Tương tự với bảng định, nguyên nhân điều kiện kết hành động Quy trình sử dụng sau: Chọn kết để trạng thái có mặt (1) Lần ngược trở lại đồ thị, tìm tất kết hợp nguyên nhân (đối tượng cho buộc) mà thiết lập kết thành Tạo cột bảng định cho kết hợp nguyên nhân Với kết hợp, quy định trạng thái tất kết khác đặt chúng vào cột Trong biểu diễn bước 2, cần quan tâm vấn đề sau: Khi lần ngược trở lại qua nút or mà đầu 1, không thiết lập nhiều đầu vào cho nút or cách đồng thời Điều gọi path sensitizing – làm nhạy đường Mục tiêu để ngăn chặn dò lỗi thất bại nguyên nhân che nguyên nhân khác hi lần ngược trở lại qua nút and mà đầu 0, dĩ nhiên, phải liệt kê tất kết hợp đầu vào dẫn tới đầu Tuy nhiên, bạn khảo sát trạng thái mà đầu hay nhiều đầu khác 1, không thiết phải liệt kê tất điều kiện mà điều kiện đầu vào khác SVTH: Lê Huy Bảo 30 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại Khi lần ngược trở lại qua nút and mà đầu là 0, cần liệt kê điều kiện tất đầu vào (Nếu nút and đồ thị tất đầu vào xuất phát từ nút trung gian khác, có nhiều trạng thái mà trạng thái tất đầu vào 0.)  Nếu x=1, không quan trường tâm hợp a=b=1 (sự xem xét thứ 1) Nếu x=0, liệt kê tất trường hợp a=b=0  Nếu x =1, liệt kê tất trường hợp a=b=c=1  Nếu x=0, bao gồm trường hợp mà a=b=c=0 (sự xem xét 3) Đối với trạng thái mà abc 001, 010, 100, 011, 101 110 , Bao gồm trường hợp trạng thái (sự xem xét 2) Hình 2.6 Những xem xét sử dụng dò theo đồ thị Những xem xét xuất thất thường, chúng có mục đích quan trọng: để giảm bớt kết kết hợp đồ thị Chúng liệt kê trường hợp mà hướng ca kiểm thử có lợi Nếu ca kiểm thử có lợi không liệt kê, đồ thị nguyên nhân – kết lớn tạo số lượng ca kiểm thử lớn Nếu số lượng ca kiểm thử thực tế lớn, bạn chọn tập đó, không đảm bảo ca kiểm thử có lợi ca kiểm thử liệt kê Do đó, tốt hết liệt kê chúng suốt trình phân tích đồ thị 2.3.2.6 NHẬN XÉT Vẽ đồ thị nguyên nhân – kết phương pháp tạo ca kiểm thử có hệ SVTH: Lê Huy Bảo 31 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại thống mô tả kết hợp điều kiện Sự thay đổi lựa chọn kết hợp dự tính trước, thực vậy, bạn bỏ sót nhiều ca kiểm thử “thú vị” xác định đồ thị nguyên nhân – kết Vì vẽ đồ thị nguyên nhân – kết yêu cầu chuyển đặc tả thành mạng logic Boolean, cung cấp triển vọng khác hiểu biết sâu sắc đặc tả Trên thực tế, phát triển đồ thị nguyên nhân – kết cách hay để khám phá mơ hồ chưa đầy đủ đặc tả Mặc dù việc vẽ đồ thị nguyên nhân – kết tạo tập ca kiểm thử hữu dụng, thông thường không tạo tất ca kiểm thử hữu dụng mà nhận biết Ngoài ra, đồ thị nguyên nhân – kết không khảo sát thỏa đáng điều kiện giới hạn Dĩ nhiên, bạn cố gắng bao phủ điều kiện giới hạn suốt trình Tuy nhiên, vấn đề việc thực điều làm cho đồ thị phức tạp dẫn tới số lượng lớn ca kiểm thử Vì thế, tốt xét phân tích giá trị giới hạn tách rời Vì đồ thị nguyên nhân – kết làm thời gian việc chọn giá trị cụ thể cho toán hạng, nên điều kiện giới hạn bị pha trộn thành ca kiểm thử xuất phát từ đồ thị nguyên nhân – kết Vì vậy, đạt tập ca kiểm thử nhỏ hiệu mà thỏa mãn mục tiêu Chú ý việc vẽ đồ thị nguyên nhân – kết phù hợp với số quy tắc Chương Việc xác định đầu mong đợi cho ca kiểm thử phần cố hữu kỹ thuật (mỗi cột bảng định biểu thị kết mong đợi) Cũng ý khuyến khích tìm kiếm kết có tác dụng không mong muốn Khía cạnh khó kỹ thuật trình chuyển đổi đồ thị thành bảng định Quá trình có tính thuật toán, tức bạn tự động hóa việc viết chương trình Trên thị trường có vài chương trình thương mại tồn giúp cho trình chuyển đổi 2.3.2.7 Đoán lỗi – Error Guessing Một kỹ thuật thiết kế test-case khác error guessing – đoán lỗi Tester đưa cho chương trình đặc biệt, họ đoán, trực giác kinh nghiệm, loại lỗi sau viết ca kiểm thử để đưa lỗi Thật khó để đưa quy trình cho kỹ thuật đoán lỗi quy trình có tính trực giác cao dự đoán trước Ý tưởng liệt kê danh SVTH: Lê Huy Bảo 32 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại sách lỗi hay trường hợp dễ xảy lỗi sau viết ca kiểm thử dựa danh sách Một ý tưởng khác để xác định ca kiểm thử có liên đới với giả định mà lập trình viên thực đọc đặc tả (tức là, thứ bị bỏ sót khỏi đặc tả, tình cờ, người viết có cảm giác đặc tả rõ ràng) Nói cách khác, bạn liệt kê trường hợp đặc biệt mà bị bỏ sót chương trình thiết kế 2.3.3 Chiến lược Các phương pháp thiết kế test-case thảo luận kết hợp thành chiến lược toàn diện Vì phương pháp đóng góp tập riêng ca kiểm thử hữu dụng, không số chúng tự đóng góp tập trọn vẹn các ca kiểm thử Chiến lược hợp lý sau: Nếu đặc tả có chứa kết hợp điều kiện đầu vào, bắt đầu với việc vẽ đồ thị nguyên nhân – kết Trong trường hợp bất kỳ, sử dụng phương pháp phân tích giá trị biên Hãy nhớ phân tích biên đầu vào đầu Phương pháp phân tích giá trị biên mang lại tập điều kiện kiểm tra bổ sung, nhiều hay toàn điều kiện hợp thành kiểm thử nguyên nhân – kết Xác định lớp tương đương hợp lệ không hợp lệ cho đầu vào đầu ra, bổ sung ca kiểm thử xác định cần thiết Sử dụng kỹ thuật đoán lỗi để thêm ca kiểm thử thêm vào Khảo sát tính logic chương trình liên quan đến tập ca kiểm thử Sử dụng tiêu chuẩn bao phủ định, bao phủ điều kiện, bao phủ định/điều kiện, hay bao phủ đa điều kiện ( bao phủ đa điều kiện sử dụng nhiều ) Nếu tiêu chuẩn bao phủ không đạt ca kiểm thử xác định bốn bước trước, việc đạt tiêu chuẩn ( tức là, kết hợp chắn điều kiện tạo chất chương trình), thêm vào ca kiểm thử có khả làm cho thỏa mãn tiêu chuẩn Tuy việc sử dụng chiến lược không đảm bảo tất lỗi tìm thấy, xác minh đại diện cho thỏa thuận hợp lý SVTH: Lê Huy Bảo 33 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại CHƯƠNG ÁP DỤNG BÀI TOÁN THỰC TẾ Từ phương pháp thiết kế test – case tìm hiểu trên, em vận dụng chúng vào thiết kế test – case cho chương trình “Hệ thống tính phí phần mềm kê khai bảo hiểm xã hội công ty TNHH thương mại VisNam” 3.1.Đặc tả Chương trình đọc vào giá trị từ hộp thoại Các giá trị tương ứng với số lượng lao động toán tính phí phần mềm kê khai bảo hiểm xã hội Yếu tố xác định phí bảo hiểm xã hội số lượng lao động Bài toán đặc tả cụ thể sau: o Đối với số lượng lao động từ lao động đến < 20 lao động, phí bảo hiểm là: 590.000 đồng o Đối với số lượng lao động từ 20 lao động đến < 50 lao động, phí bảo hiểm là: 800.000 đồng o Đối với số lượng lao động từ 50 lao động đến < 100 lao động, phí bảo hiểm là: 960.000 đồng o Đối với số lượng lao động >100 lao động, phí bảo hiểm là: 1.050.000 đồng 3.2.Thiết kế test – case Áp dụng chiến lược kiểm thử trình bày Chương 2, ca kiểm thử xây dựng sau: 3.2.1 Vẽ đồ thị nguyên nhân – kết Nguyên nhân Kết 1.Từ lao động đến 100 lao động 103.Phí bảo hiểm 1.050.000 đồng 5.Giá trị nhập vào số âm, số nguyên dương nhỏ giá trị số 104.Thông báo lỗi nhập liệu - Chuyển nội dung ngữ nghĩa đặc tả thành đồ thị liên kết nguyên nhân kết SVTH: Lê Huy Bảo 34 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại Áp dụng cho có mặt kết đầu vào, ta bảng định sau: Bảng định 1 Y N N N N Y N N N Y N N Y N 100 Y X 101 X 102 103 X X 104 X Bước cuối chuyển đổi bảng định thành ca kiểm thử Các ca kiểm thử thu sau: STT Các điều kiện Ca kiểm thử Hành động Từ lao động 100 lao động 200 103 Giá trị nhập vào số âm, số nguyên dương nhỏ giá trị số -5, 0, 7.5, abc 104 SVTH: Lê Huy Bảo 35 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại 3.2.2 Phân lớp tương đương 3.2.2.1 Xác định lớp tương đương Các giá trị nhập vào số Giá trị số (1) Giá trị số (2) Các giá trị nguyên Giá trị số nguyên (3) Giá trị số nguyên (4) Các giá trị dương Giá trị dương (5) Giá trị bé (6) Giá trị so với số Lớn (7) Nhỏ (8) 3.2.2.2 Xác định ca kiểm thử Các ca kiểm thử bao phủ lớp tương đương hợp lệ: Ca kiểm thử 0, 15, 45, 60, 200 bao phủ lớp (1), (3), (5), (7), (8) Ca kiểm thử 7.5 bao phủ lớp (1), (4), (5), (7) Các ca kiểm thử tương ứng với ca kiểm thử không hợp lệ: (2) abc (4) 7.5 (6) -5 3.2.3 Phân tích giá trị biên 3.2.3.1 Xét trạng thái đầu vào Xét trạng thái đầu vào thu ca kiểm thử sau: -5 7.5 15 45 60 200 abc 3.2.3.2 Xét không gian kết Xét không gian kết quả, thu ca kiểm thử sau: Số đầu vào thỏa mãn phí dịch vụ 590.000 đồng SVTH: Lê Huy Bảo 36 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại 15 Số đầu vào thỏa mãn phí dịch vụ 800.000 đồng 10 45 Số đầu vào thỏa mãn phí dịch vụ 960.000 đồng 11 60 Số đầu vào thỏa mãn phí dịch vụ 1.050.000 đồng 12 200 Số đầu vào không thỏa mãn 13 14 7.5 Lỗi định dạng liệu vào 15 Abc SVTH: Lê Huy Bảo 37 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại KẾT LUẬN Kiểm thử phần mềm, hướng không mẻ giới, lại hướng Việt Nam Nó hứa hẹn tương lai cho học sinh, sinh viên ngành CNTT Qua tìm hiểu xây dựng đề tài này, em thấy đạt ưu điểm số tồn Những điểm đạt được:  Nắm tổng quan kiểm thử phần mềm: Các khái niệm bản, phương pháp kiểm thử phần mềm, vấn đề liên quan …  Tìm hiểu nắm phương pháp chiến lược thiết kế test – case kiểm thử phần mềm, áp dụng phương pháp tìm hiểu để xây dựng test – case cho toán cụ thể - Chương trình “Tam giác”  Bổ sung rèn luyện thêm kỹ sử dụng phần mềm Word Powerpoint  Nâng cao khả đọc hiểu tài liệu Tiếng Anh Những điểm chưa đạt:  Sự áp dụng kiến thức tìm hiểu dừng lại toán nhỏ, mà chưa thử áp dụng cho toán hay ứng dụng lớn Từ điểm đạt chưa đạt trên, em hi vọng nhận góp ý chân thành thầy cô bạn để báo cáo hoàn thiện SVTH: Lê Huy Bảo 38 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại TÀI LIỆU THAM KHẢO The Art of Software Testing, Glenford J Myers, Second Edition, John Wiley and Sons, Inc Software Engineering - A Practitioner’s Approach, Roger S.Pressman, Sixth Edition, Ph.D, McGraw-Hill, Inc A Practitioner's Guide to Software Test Design, Lee Copeland, First Edition, Artech House Publishers Boston, London Effective methods for Software Testing, William E Perry, 3rd Edition, Wiley Publishing, Indian Software Testing, Ron Patton, Second Edition, Sam Publishing http://www.vietnamesetestingboard.org/ http://en.wikipedia.org/wiki/Software_testing Một số trang web kiểm thử phần mềm khác SVTH: Lê Huy Bảo 39 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… ……………………………………………………………………………………… Đà Nẵng, ngày … tháng … năm … Giáo viên hướng dẫn SVTH: Lê Huy Bảo 40 ... cấp độ kiểm thử phần mềm Kiểm thử phần mềm gồm có cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hệ thống Kiểm thử chấp nhận sản phẩm SVTH: Lê Huy Bảo Đồ án môn học: Kiểm thử phần mềm Hình... quan kiểm thử phần mềm Chương nhìn tổng quan kiểm thử phần mềm: khái niệm kiểm thử phần mềm, quy tắc kiểm thử, phương pháp kiểm thử phần mềm tiêu biểu • Chương 2: Thiết kế test – case kiểm thử phần. .. 14 Đồ án môn học: Kiểm thử phần mềm GVHD: Trần Văn Đại 1.1.4. 6Kiểm thử tính – Correctness testing: Tính đắn yêu cầu tối thiểu phần mềm, mục đích chủ yếu kiểm thử Kiểm thử tính cần kiểu người đáng