ĐỀ TÀI THỰC TẬP CHUYÊN NGÀNH: THIẾT KẾ TEST-CASE TRONG KIỂM THỬ PHẦN MỀM

Đề tài thực tập chuyên ngành: MỤC LỤC THIẾT KẾ TEST-CASE TRONG KIỂM THỬ PHẦN MỀM Sinh viên thực : Phạm Thị Trang Lớp : ĐHCQ K4A Giáo viên hướng dẫn : Nguyễn Hồng Tân Bộ môn : Công nghệ phần mềm 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 CHƯƠNG THIẾT KẾ TEST – CASE 22 CHƯƠNG ÁP DỤNG 43 KẾT LUẬN .56 TÀI LIỆU THAM KHẢO 57 NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN 58 DANH MỤC CÁC HÌNH Hình 1.1 Sơ đồ cấp độ kiểm thử .12 Hình 2.1 Một chương trình nhỏ để kiểm thử 24 Hình 2.2 Mã máy cho chương trình Hình 2.1 28 Hình 2.3 Một mẫu cho việc liệt kê lớp tương đương .32 Hình 2.4 Các ký hiệu đồ thị nguyên nhân – kết 37 Hình 2.5 Các ký hiệu ràng buộc 38 Hình 2.6 Những xem xét sử dụng dò theo đồ thị .39 Hình 3.1 Đồ thị nguyên nhân – kết quả: 46 Hình 3.2 Bảng định 47 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ịn Đã 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à khơng có 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 khun 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 tốn thực tế Bản báo cáo hồn thành bảo tận tình thầy giáo, ThS Nguyễn Hồng Tân, giúp đỡ nhiệt tình thầy cô môn Công nghệ phần mềm, tất bạn Em hi vọng nhận đóng góp ý kiến thầy bạn để báo cáo hồ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 Sinh viên Phạm Thị Trang 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 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” CHƯƠNG TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1 1.1.1 Các khái niệm kiểm thử phần mềm 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 tồ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.1 Kiể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 tồ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 1.1.2.2 Kiể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 TRONG SỐ NHỮNG CHIẾN LƯỢC KIỂM THỬ THÔNG DỤNG NHẤT BAO GỒM : KIỂM THỬ HỘP ĐEN, KIỂM THỬ HỘP TRẮNG, VÀ KIỂM THỬ HỘP XÁM 1.1.3.1 Kiể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 CỦA BẠN LÀ HỒN TỒN KHƠNG QUAN TÂM VỀ CÁCH CƯ XỬ VÀ CẤU TRÚC BÊN TRONG CỦA CHƯƠNG TRÌNH THAY VÀO ĐĨ, TẬP TRUNG VÀO TÌM CÁC TRƯỜNG HỢP MÀ CHƯƠNG TRÌNH KHƠNG THỰC HIỆN THEO CÁC ĐẶC TẢ CỦA NÓ THEO HƯỚNG TIẾP CẬN NÀY , DỮ LIỆU KIỂM TRA ĐƯỢC LẤY CHỈ TỪ CÁC ĐẶC TẢ Cá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 – B OUNDARY VALUE ANALYSIS • KIỂM THỬ MỌI CẶP – ALL-PAIRS TESTING • KIỂM THỬ FUZZ – FUZZ TESTING • KIỂM THỬ DỰA TRÊN 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 TRÊN ĐẶ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 CỦA PHẦN MỀM THEO NHỮNG U CẦU THÍCH HỢP DO ĐĨ, KIỂM THỬ VIÊN NHẬP DỮ LIỆU VÀO , VÀ CHỈ THẤY DỮ LIỆU RA TỪ ĐỐI TƯỢNG KIỂM THỬ MỨC KIỂM THỬ NÀY THƯỜNG YÊU CẦU CÁC CA KIỂM THỬ TRIỆT ĐỂ ĐƯỢC CUNG CẤP CHO KIỂM THỬ VIÊN MÀ KHI ĐÓ CÓ THỂ XÁC MINH LÀ ĐỐI VỚI DỮ LIỆU ĐẦU VÀO ĐÃ CHO, GIÁ TRỊ ĐẦU RA (HAY CÁCH THỨC HOẠT ĐỘNG ) CÓ GIỐNG VỚI GIÁ TRỊ MONG MUỐN ĐÃ ĐƯỢC XÁC ĐỊNH TRONG CA KIỂM THỬ ĐĨ HAY KHƠNG KIỂM THỬ DỰA TRÊN ĐẶC TẢ LÀ CẦN THIẾT, NHƯNG KHÔNG ĐỦ ĐỂ ĐỂ NGĂN CHẶN NHỮNG RỦI RO CHẮC CHẮN Ưu, nhược ĐIỂM Kiểm thử HỘP ĐEN KHƠNG CĨ MỐI LIÊN QUAN NÀO TỚI MÃ LỆNH, VÀ KIỂM THỬ VIÊN CHỈ RẤT ĐƠN GIẢN TÂM NIỆM LÀ: MỘT MÃ LỆNH PHẢI CÓ LỖI SỬ DỤNG NGUYÊN TẮC “ HÃY ĐÒI HỎI VÀ BẠN SẼ ĐƯỢC NHẬN”, NHỮNG KIỂM THỬ VIÊN HỘP ĐEN TÌM RA LỖI MÀ NHỮNG LẬP TRÌNH VIÊN ĐÃ KHƠNG TÌM RA NHƯNG, MẶT KHÁC, NGƯỜI TA CŨNG NÓI KIỂM THỬ HỘP ĐEN “GIỐNG NHƯ LÀ ĐI TRONG BĨNG TỐI MÀ KHƠNG CĨ ĐÈN VẬY”, BỞI VÌ KIỂM THỬ VIÊN KHƠNG BIẾT CÁC PHẦN MỀM ĐƯỢC KIỂM TRA THỰC SỰ ĐƯỢC XÂY DỰNG NHƯ THẾ NÀO ĐÓ LÀ LÝ DO MÀ CÓ NHIỀU TRƯỜNG HỢP MÀ MỘT KIỂM THỬ VIÊN HỘP ĐEN VIẾT RẤT NHIỀU CA KIỂM THỬ ĐỂ KIỂM TRA MỘT THỨ GÌ ĐÓ MÀ ĐÁNG LẼ CÓ THỂ CHỈ CẦN KIỂM TRA BẰNG CA KIỂM THỬ DUY NHẤT , VÀ/HOẶC MỘT SỐ PHẦN CỦA CHƯƠNG TRÌNH KHƠNG ĐƯỢC KIỂM TRA CHÚT NÀO Do vậy, kiểm thử hộp đen có ưu điểm “một đánh giá KHÁCH QUAN”, MẶT KHÁC NĨ LẠI CĨ NHƯỢC ĐIỂM CỦA 1.1.3.2 “THĂM DỊ MÙ” Kiể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) Các phương pháp kiểm thử hộp trắng 10 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 để phát nhánh phát sinh lỗi Một nhánh thường chuỗi lệnh thực thi Unit Ví dụ: chuỗi lệnh sau điều kiện If nằm then else nhánh Thực tế việc chọn lựa nhánh để đơn giản hóa việc kiểm thử qt hết Unit địi hỏi phải có kỹ thuật, đơi phải dùng thuật toán để chọn lựa Cùng với mục kiểm thử khác, Unit Test đòi hỏi phải chuẩn bị trước ca kiểm thử (Test case) kịch kiểm thử (Test script), định rõ liệu đầu vào, bước thực liệu đầu mong muốn Các Test case Test script nên giữ lại để tái sử dụng 1.1.4.2 Kiểm thử tích hợp – Intergration Test Integration test kết hợp thành phần ứng dụng kiểm thử ứng dụng hoàn thành Trong Unit Test kiểm tra thành phần Unit riêng lẻ Intgration Test kết hợp chúng lại với kiểm tra giao tiếp chúng Hai mục tiêu Integration Test: • Phát lỗi giao tiếp xảy Unit 13 • Tích hợp Unit đơn lẻ thành hệ thống nhỏ (Subsystem) cuối nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử mức hệ thống (System Test) Trong Unit Test, lập trình viên cố gắng phát lỗi liên quan đến chức cấu trúc nội Unit Có số phép kiểm thử đơn giản giao tiếp Unit với thành phần liên quan khác, nhiên giao tiếp liên quan đến Unit thật kiểm tra đầy đủ Unit tích hợp với thực Integration Test Trừ số ngoại lệ, Integration Test nên thực Unit kiểm tra cẩn thận trước Unit Test, tất lỗi mức Unit sửa chữa Một số người hiểu sai Unit qua giai đoạn Unit Test với giao tiếp giả lập khơng cần phải thực Integration Test Thực tế việc tích hợp Unit dẫn đến tình hồn tồn khác Một chiến lược cần quan tâm Integration Test nên tích hợp dần Unit Một Unit thời điểm tích hợp vào nhóm Unit khác tích hợp trước hồn tất đợt Integration Test trước Lúc này, ta cần kiểm thử giao tiếp Unit thêm vào với hệ thống Unit tích hợp trước đó, điều làm cho số lượng can kiểm thử giảm nhiều, sai sót giảm đáng kể Có loại kiểm thử Integration Test: • Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thử cấu trúc nhằm bảo đảm thành phần bên chương trình chạy trọng đến hoạt động thành phần cấu trúc nội chương trình chẳng hạn câu lệnh nhánh bên • Kiểm thử chức (Functional Test): Tương tự Black Box Test, kiểm thử chức trọng đến chức chương trình, mà không quan tâm đến cấu trúc bên trong, khảo sát chức chương trình theo yêu cầu kỹ thuật 14 • Kiểm thử hiệu (Performance Test): Kiểm thử việc vận hành hệ thống • Kiểm thử khả chịu tải (Stress Test): Kiểm thử giới hạn hệ thống 1.1.4.3 Kiểm thử hệ thống – System Test Mục đích System Test kiểm thử thiết kế tồn hệ thống (sau tích hợp) có thỏa mãn u cầu đặt hay khơng System Test bắt đầu tất phận phần mềm tích hợp thành cơng Thơng thường loại kiểm thử tốn nhiều công sức thời gian Trong nhiều trường hợp, việc kiểm thử đòi hỏi số thiết bị phụ trợ, phần mềm phần cứng đặc thù, đặc biệt ứng dụng thời gian thực, hệ thống phân bố, hệ thống nhúng Ở mức độ hệ thống, người kiểm thử tìm kiếm lỗi, trọng tâm đánh giá hoạt động, thao tác, tin cậy yêu cầu khác liên quan đến chất lượng toàn hệ thống Điểm khác then chốt Integration Test System Test System Test trọng hành vi lỗi tồn hệ thống, cịn Integration Test trọng giao tiếp đơn thể đối tượng chúng làm việc Thông thường ta phải thực Unit Test Integration Test để bảo đảm Unit tương tác chúng hoạt động xác trước thực System Test Sau hoàn thành Integration Test, hệ thống phần mềm hình thành với thành phần kiểm tra đầy đủ Tại thời điểm này, lập trình viên kiểm thử viên bắt đầu kiểm thử phần mềm hệ thống hoàn chỉnh Việc lập kế hoạch cho System Test nên giai đoạn hình thành phân tích u cầu System Test kiểm thử hành vi chức phần mềm lẫn yêu cầu chất lượng độ tin cậy, tính tiện lợi sử dụng, hiệu bảo mật Mức kiểm thử đặc biệt thích hợp cho việc phát lỗi giao tiếp với phần mềm 15 phần cứng bên ngoài, chẳng hạn lỗi "tắc nghẽn" (deadlock) chiếm dụng nhớ Sau giai đoạn System Test, phần mềm thường sẵn sàng cho khách hàng người dùng cuối kiểm thử chấp nhận sản phẩm (Acceptance Test) dùng thử (Alpha/Beta Test) Địi hỏi nhiều cơng sức, thời gian tính xác, khách quan, System Test thường thực nhóm kiểm thử viên hồn tồn độc lập với nhóm phát triển dự án Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến gồm: • Kiểm thử chức (Functional Test): Bảo đảm hành vi hệ thống thỏa mãn yêu cầu thiết kế • Kiểm thử hiệu (Performance Test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ nhớ) nhằm đạt tiêu thời gian xử lý hay đáp ứng câu truy vấn • Kiểm thử khả chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận hành áp lực cao (ví dụ nhiều người truy xuất lúc) Stress Test tập trung vào trạng thái tới hạn, "điểm chết", tình bất thường giao dịch ngắt kết nối (xuất nhiều kiểm tra thiết bị POS, ATM ) • Kiểm thử cấu hình (Configuration Test) • Kiểm thử bảo mật (Security Test): Bảo đảm tính tồn vẹn, bảo mật liệu hệ thống • Kiểm thử khả phục hồi (Recovery Test): Bảo đảm hệ thống có khả khơi phục trạng thái ổn định trước tình tài nguyên liệu; đặc biệt quan trọng hệ thống giao dịch ngân hàng trực tuyến Nhìn từ quan điểm người dùng, cấp độ kiểm thử quan trọng: Chúng bảo đảm hệ thống đủ khả làm việc môi trường thực 16 Lưu ý không thiết phải thực tất loại kiểm thử nêu Tùy yêu cầu đặc trưng hệ thống, tuỳ khả thời gian cho phép dự án, lập kế hoạch, người Quản lý dự án định áp dụng loại kiểm thử 1.1.4.4 Kiểm thử chấp nhận sản phẩm – Acceptance Test Thông thường, sau giai đoạn System Test Acceptance Test, khách hàng thực (hoặc ủy quyền cho nhóm thứ ba thực hiện) Mục đích Acceptance Test để chứng minh phần mềm thỏa mãn tất yêu cầu khách hàng khách hàng chấp nhận sản phẩm (và trả tiền toán hợp đồng) Acceptance Test có ý nghĩa quan trọng, hầu hết trường hợp, phép kiểm thử System Test Acceptance Test gần tương tự, chất cách thức thực lại khác biệt Đối với sản phẩm dành bán rộng rãi thị trường cho nhiều người sử dụng, thông thường thông qua hai loại kiểm thử gọi kiểm thử Alpha – Alpha Test kiểm thử Beta – Beta Test Với Alpha Test, người dùng kiểm thử phần mềm nơi phát triển phần mềm, lập trình viên ghi nhận lỗi phản hồi, lên kế hoạch sửa chữa Với Beta Test, phần mềm gửi tới cho người dùng để kiểm thử môi trường thực, lỗi phản hồi gửi ngược lại cho lập trình viên để sửa chữa Thực tế cho thấy, khách hàng khơng quan tâm khơng tham gia vào q trình phát triển phần mềm kết Acceptance Test sai lệch lớn, phần mềm trải qua tất kiểm thử trước Sự sai lệch liên quan đến việc hiểu sai yêu cầu mong chờ khách hàng Ví dụ phần mềm xuất sắc vượt qua phép kiểm thử chức thực nhóm thực dự án, khách hàng kiểm thử sau thất vọng bố cục hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng khách hàng v.v 17 Gắn liền với giai đoạn Acceptance Test thường nhóm dịch vụ tài liệu kèm, phổ biến hướng dẫn cài đặt, sử dụng v.v Tất tài liệu kèm phải cập nhật kiểm thử chặt chẽ 1.1.4.5 Một số cấp độ kiểm thử khác Ngồi cấp độ trên, cịn số cấp độ kiểm thử khác như: Kiểm thử hồi quy – Regression Testing: Theo chuẩn IEEE610.12-90, kiểm thử hồi quy “sự kiểm tra lại có lựa chọn hệ thống hay thành phần để xác minh thay đổi không gây hậu không mong muốn…” Trên thực tế, quan niệm phần mềm mà qua kiểm tra trước kiểm tra lại Beizer định nghĩa lặp lại kiểm tra để cách hoạt động phần mềm không bị thay đổi, ngoại trừ tới mức yêu cầu Hiển nhiên thỏa hiệp phải thực đảm bảo đưa kiểm thử hồi quy lần thực thay đổi tài nguyên yêu cầu thực điều Kiể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 tin đó, để cách hoạt động đắn từ cách hoạt động sai lầm Kiểm thử viên biết chi tiết bên modun phần mềm kiểm thử, ví dụ luồng điều khiển, lng liệu, v.v … Do đó, quan điểm hộp trắng, quan điểm hộp đen thực kiểm thử phần mềm 18 1.1.5 Các phương pháp kiểm thử người Hai phương pháp kiểm thử người chủ yếu Code Inspections Walkthroughs Hai phương pháp bao gồm nhóm người đọc kiểm tra theo mã lệnh chương trình Mục tiêu chúng để tìm lỗi mà khơng gỡ lỗi Một Inspection hay Walkthrough cải tiến phương pháp kiểm tra mà lập trình viên đọc chương trình họ trước kiểm thử Inspections Walkthroughs hiệu người khác kiểm thử chương trình tốt tác giả chương trình Inspections/Walkthroughs kiểm thử máy tính bổ sung cho Hiệu tìm lỗi thiếu phương pháp Và việc sửa đổi chương trình nên sử dụng phương pháp kiểm thử kỹ thuật kiểm thử hồi quy 1.1.5.1 Tổng duyệt – Walkthrough Walkthrough thuật ngữ mô tả xem xét kỹ lưỡng trình mức trừu tượng nhà thiết kế hay lập trình viên lãnh đạo thành viên nhóm người có quan tâm khác thông qua sản phẩm phần mềm, người tham gia đặt câu hỏi, ghi lỗi có, vi phạm chuẩn phát triển vấn đề khác Walkthrough mã lệnh tập thủ tục công nghệ dị lỗi cho việc đọc nhóm mã lệnh Trong Walkthrough, nhóm nhà phát triển – với thành viên tốt – thực xét duyệt lại Chỉ thành viên tác giả chương trình Một ưu điểm khác walkthroughs, hiệu chi phí gỡ lỗi, thực tế mà lỗi tìm thấy, thường định vị xác mã lệnh Thêm vào đó, phương pháp thường tìm tập lỗi, cho phép sau lỗi sửa tất với Mặt khác, kiểm thử dựa máy tính,chỉ tìm triệu 19 chứng lỗi (chương trình khơng kết thúc đưa kết vơ nghĩa), lỗi thường tìm sửa lỗi 1.1.5.2 Thanh tra mã nguồn – Code Inspection Thanh tra mã nguồn tập hợp thủ tục kỹ thuật dò lỗi cho việc đọc nhóm mã lệnh Một nhóm kiểm duyệt thường gồm người Một số đóng vai trị người điều tiết – lập trình viên lão luyện không tác giả chương trình phải khơng quen với chi tiết chương trình Người điều tiết có nhiệm vụ: phân phối nguyên liệu lập lịch cho buổi kiểm duyệt, đạo phiên làm việc, ghi lại tất lỗi tìm thấy đảm bảo lỗi sau sửa Thành viên thứ hai lập trình viên Các thành viên cịn lại nhóm thường nhà thiết kế chương trình ( nhà thiết kế khác lập trình viên) chuyên viên kiểm thử 1.2 Nguyên tắc kiểm thử phần mềm Để kiểm thử đạt hiệu tiến hành kiểm thử phần mềm cần phải tuân thủ số quy tắc sau: Quy tắc 1: Một phần quan trọng ca kiểm thử định nghĩa đầu hay kết mong muốn Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình Quy tắc 3: Nhóm lập trình khơng nên kiểm thử chương trình họ Quy tắc 4: Kiểm tra thấu đáo kết kiểm tra Quy tắc 5: Các ca kiểm thử phải viết cho trạng thái đầu vào không hợp lệ không mong muốn, cho đầu vào hợp lệ mong muốn 20 ... 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. .. 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 Hình 1.1 1.1.4.1 Sơ đồ cấp độ kiểm thử Kiểm thử đơn... tập test – case cho toán cụ thể : Thiết kế test – case cho chương trình “Tam giác” CHƯƠNG TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1 1.1.1 Các khái niệm kiểm thử phần mềm Kiểm thử phần mềm gì? Kiểm thử