Luận văn thạc sĩ Một số kỹ thuật kiểm thử phần mềm

ĐẠI HỌC THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN LỜI CAM ĐOAN Tôi xin cam đoan luận văn công trình nghiên cứu riêng Các số liệu kết nêu luận văn trung thực chưa công bố công trình nghiên cứu khác LUẬN VĂN THẠC SĨ MỘT SỐ KỸ THUẬT KIỂM THỬ PHẦN MỀM Chuyên ngành : KHOA HỌC MÁY TÍNH Ngƣời hƣớng dẫn khoa học : PGS TSKH NGUYỄN XUÂN HUY Học viên thực : : CAO THỊ BÍCH LIÊN Mã số : 60 48 01 Thái Nguyên - Năm 2009 Số hóa Trung tâm Học liệu – Đại học Thái Nguyên Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn i http://www.lrc-tnu.edu.vn 2.2.2 Kiểm thử cấu trúc điều khiển 22 MỤC LỤC LỜI CAM ĐOAN ………………………………………………………………… i 2.3 Kỹ thuật kiểm thử hộp đen (Black-Box Testing) 26 MỤC LỤC ii 2.3.1 Phân hoạch tương đương 27 DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT …………………….……v 2.3.2 Phân tích giá trị biên (Boundary Value Analysis) 30 DANH MỤC CÁC BẢNG ……………………………………………………… vi DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ ………………………………… …….vii MỞ ĐẦU Chƣơng VẤN ĐỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM……………………………………….…………………… ….4 1.1 Sản phẩm phần mềm vấn đề kiểm thử phần mềm ……….…… .4 1.1.1 Sản phẩm phần mềm gì? 1.1.2 Thế lỗi phần mềm? 1.1.3 Tại lỗi phần mềm xuất hiện? 1.1.4 Chi phí cho việc sữa lỗi 1.1.5 Kiểm thử phần mềm gì? 1.2 Chất lƣợng phần mềm 1.3 Qui trình kiểm thử phần mềm Chƣơng CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM 12 2.1 Nguyên tắc kiểm thử phần mềm 12 2.1.1 Mục tiêu kiểm thử 12 2.1.2 Luồng thông tin kiểm thử 13 2.1.3 Thiết kế trường hợp kiểm thử 13 2.2 Kỹ thuật kiểm thử hộp trắng (White-Box Testing) 14 2.2.1 Kiểm thử đường dẫn sở (Basic Path Testing) 16 2.3.3 Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph) 31 2.3.4 Kiểm thử so sánh 34 2.4 Đoán lỗi 34 Chƣơng CHIẾN LƢỢC KIỂM THỬ PHẦN MỀM 35 3.1 Nguyên lý thiết kế kiểm thử phần mềm 35 3.2 Phƣơng pháp tiếp cận kiểm thử phần mềm 36 3.2.1 Xác minh thẩm định 37 3.2.2 Tổ chức việc kiểm thử 37 3.2.3 Chiến lược kiểm thử phần mềm 38 3.2.4 Điều kiện hoàn thành kiểm thử 39 3.3 Kiểm thử đơn vị 42 3.3.1 Các lý kiểm thử đơn vị 42 3.3.2 Các thủ tục kiểm thử đơn vị 45 3.4 Kiểm thử tích hợp 45 3.4.1 Kiểm thử tích hợp từ xuống (Top-Down Integration) 46 3.4.2 Chiến lược kiểm thử từ lên (Bottom-Up Testing) 47 3.4.3 Kiểm thử hồi qui 48 3.4.4 Các ghi kiểm thử tích hợp 48 3.5 Kiểm thử tính hợp lệ 50 3.5.1 Điều kiện kiểm thử tính hợp lệ 50 Số hóa Trung tâm Học liệu – Đại học Thái Nguyên ii http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên iii http://www.lrc-tnu.edu.vn 3.5.2 Duyệt lại cấu hình 51 DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT 3.5.3 Kiểm thử Alpha Beta 51 3.6 Kiểm thử hệ thống 52 3.6.1 Kiểm thử khôi phục 52 3.6.2 Kiểm thử bảo mật 52 3.6.3 Kiểm thử ứng suất 53 3.6.4 Kiểm thử khả thực 53 Chƣơng MỘT SỐ ỨNG DỤNG CỤ THỂ CỦA QUI TRÌNH KIỂM THỬ 54 BRO : Kiểm thử nhánh toán tử quan hệ BVA : Phân tích giá trị biên DU : Một chuỗi khai báo - sử dụng E : Là số cạnh đồ thị lƣu trình N : Là số đỉnh đồ thị lƣu trình P : Số đỉnh điều kiện có đồ thị lƣu trình 4.1 Mục tiêu 54 R : Số vùng đồ thị lƣu trình 4.2 Phƣơng pháp luận 54 V(G) : Xác định độ phức tạp Cyclomat 4.2.1 Tổng quan phương pháp 54 V&V : Xác minh thẩm định 4.2.2 Phạm vi giải 54 4.2.3 Phân loại kiểu kiểm thử 55 4.2.4 Tổ chức giao diện kiểm thử 56 4.3 Phát sinh trƣờng hợp kiểm thử 57 4.3.1 Chiến lược kiểm thử 57 4.3.2 Kiểm thử đơn vị 57 4.3.3 Kiểm thử khả thực 65 KẾT LUẬN 66 TÀI LIỆU THAM KHẢO 67 Số hóa Trung tâm Học liệu – Đại học Thái Nguyên iv http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên v http://www.lrc-tnu.edu.vn DANH MỤC CÁC BẢNG Bảng 1.1: Tỉ lệ công thức giai đoạn phát triển phần mềm ………… Bảng 2.1: Bảng liệt kê lớp tƣơng 28 tƣơng đƣơng 29 đƣơng………………………………… Bảng 2.2: Ví dụ lớp DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ ………………………………………… Bảng 2.3: Các ký hiệu đồ thị nhân 32 ……………………………… Bảng 2.4: Ví dụ bảng định 33 ……………………………………………… Bảng 3.1: So sánh kiểm thử Top-Down Bottom-Up 49 Bảng trƣờng hợp kiểm thử cho Module Merge 61 ……………… Bảng 4.2: Các trƣờng hợp kiểm thử cho Module Split 62 ……………………… phẩm phần mềm ………………………………………………………… Hình 1.2: Các ……………………… Bảng 4.1: Hình 1.1: Sản nguyên nhân gây lỗi phần mềm ……………………………………… Hình 1.3: Chi phí sửa lỗi theo thời gian phát lỗi số ngữ cảnh phần mềm ………………………………… Hình 1.4: Kiểm thử phần mềm trong xử ………………………………… Hình 1.5: Giai đoạn kiểm thử lý ………………………………… Hình 1.6: Qui trình kiểm thử phần mềm 11 ……………………………………………… Hình 2.1: Luồng thông tin kiểm thử 13 điều khiển 15 lƣu trình 16 …………………………………………………… Hình 2.2: Ví dụ chu trình …………………………………………………… Hình 2.3: Ký Số hóa Trung tâm Học liệu – Đại học Thái Nguyên vi http://www.lrc-tnu.edu.vn hiệu đồ Số hóa Trung tâm Học liệu – Đại học Thái Nguyên thị vii http://www.lrc-tnu.edu.vn ……………………………………………………… Hình 2.4: Điều …………………………………………………… kiện phức 17 ………………………………………………………………… Hình 2.5: Lƣu đồ thuật toán đồ thị họa thuật toán xếp 57 chức 59 MergeSort…………………………………… lƣu trình 17 ……………………………………… Hình 2.6: Độ Hình 4.2: Minh Hình 4.3: Đồ thị lƣu trình Merge……………………………………… phức tạp Cyclomat 19 ………………………………………………………… Hình 4.4: Giao diện điều khiển kiểm thử thuật toán 64 MergeSort……………………… Hình 2.7: Ví dụ minh họa phát sinh trƣờng hợp kiểm thử theo đƣờng dẫn 20 sở Hình 4.5: Kết đƣợc ghi FileLog 64 ………………………………………………… Hình 2.8: Các kiểu vòng lặp 25 ……………………………………………………………… Hình 2.9: Ví dụ đồ thị Hình 4.6: Giao diện điều khiển kiểm thử khả thực thuật toán 65 xếp nhân 33 ………………………………………………………… Hình 3.1: Chiến lƣợc kiểm thử 38 ………………………………………………………… Hình 3.2: Các bƣớc kiểm thử 39 …………………………………………………………… Hình 3.3: Mật độ lỗi hàm thời gian thực 41 ……………………………………… Hình 3.4: Quan hệ chi phí kiểm thử số lỗi chƣa đƣợc phát 42 ……………… Hình 3.5: (a) Kiểm thử đơn vị (b) Môi trƣờng kiểm thử đơn vị 44 ……………………… Hình 3.6: Kiểm thử Top – Down 46 ………………………………………………………… Hình 3.7: Tích hợp Bottom – Up 47 ………………………………………………………… Hình 4.1: Giao diện kiểm Số hóa Trung tâm Học liệu – Đại học Thái Nguyên viii thử nhúng 56 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên ix http://www.lrc-tnu.edu.vn MỞ ĐẦU Lý chọn đề tài Với phát triển vũ bão công nghệ thông tin nói chung công nghệ phần mềm nói riêng, việc phát triển phần mềm ngày hỗ trợ nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm đỡ mệt nhọc hiệu Tuy nhiên, độ phức tạp phần mềm giới hạn thời gian chi phí, cho dù hoạt động đảm bảo chất lượng phần mềm nói chung kiểm thử nói riêng ngày chặt chẽ khoa học, không đảm bảo sản phẩm phần mềm ứng dụng lỗi Lỗi tiềm ẩn sản phẩm phần mềm gây thiệt hại khôn lường Kiểm thử phần mềm trình liên tục, xuyên suốt giai đoạn phát triển phần mềm để đảm bảo phần mềm thoả mãn yêu cầu thiết kế yêu cầu đáp ứng nhu cầu người dùng Các kỹ thuật kiểm thử phần mềm đã, nghiên cứu, việc kiểm thử phần mềm trở thành qui trình bắt buộc dự án phát triển phần mềm giới Kiểm thử phần mềm hoạt động tốn kém, thời gian, khó phát hết lỗi Vì vậy, việc kiểm thử phần mềm đòi hỏi phải có chiến lược phù hợp, kế hoạch hợp lý việc thực quản lí chặt chẽ Ở Việt Nam, thời gian qua việc kiểm thử phần mềm bị xem nhẹ, với công cụ lập trình đại, người ta cảm tính cho không kiểm thử không sao, nên chưa có nhiều quan tâm, nghiên cứu Những năm gần đây, số tổ chức nghiên cứu phát triển phần mềm bắt đầu có quan tâm đến vấn đề kiểm thử phần mềm Tuy nhiên, vấn đề kiểm thử phần mềm chưa đầu tư quan tâm mức Nước ta trình xây dựng ngành công nghiệp phần mềm xem nhẹ việc kiểm thử phần mềm xác suất thất bại cao, nữa, hầu hết công ty phần mềm có uy tín đặt yêu cầu nghiêm ngặt phần mềm tài liệu kiểm thử kèm không chấp nhận Số hóa Trung tâm Học liệu – Đại học Thái Nguyên x http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn Mục tiêu nhiệm vụ nghiên cứu Bố cục Luận văn - Luận văn tập trung nghiên cứu, tìm hiểu, đánh giá nguyên lý, chiến lược kỹ thuật kiểm thử phần mềm Toàn nội dung Luận văn chia thành chương sau: Chƣơng 1: Vấn đề chất lượng phần mềm kiểm thử phần mềm - Thiết kế trường hợp kiểm thử áp dụng cho vài chương trình cụ thể Đối tƣợng phạm vi nghiên cứu Chƣơng 2: Các kỹ thuật kiểm thử phần mềm Chƣơng 3: Chiến lược kiểm thử phần mềm  Qui trình chất kỹ thuật kiểm thử hộp đen kiểm thử hộp Chƣơng 4: Một số ứng dụng cụ thể (của qui trình kiểm thử) trắng  Chiến lược kiểm thử phần mềm  Đặc tả thiết kế kiểm thử Phƣơng pháp nghiên cứu - Nghiên cứu, tìm hiểu kỹ thuật, chiến lược kiểm thử phần mềm - Sử dụng phương pháp kiểm thử nghiên cứu, thiết kế test cho chương trình cụ thể Đưa tài liệu kế hoạch kiểm thử đặc tả kiểm thử; xây dựng chương trình thực thi kiểm thử Dự kiến kết - Thiết kế trường hợp kiểm thử cho số chương trình cụ thể - Tạo tài liệu kiểm thử (đặc tả trường hợp kiểm thử kết kiểm thử.) - Xây dựng chương trình kiểm thử Ý nghĩa khoa học thực tiễn Luận văn Kết nghiên cứu làm tài liệu tham khảo cho sở tiến tới đưa qui trình kiểm thử phần mềm thành qui trình bắt buộc dự án phát triển phần mềm họ Đặt tên đề tài “Một số kỹ thuật kiểm thử phần mềm.” Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn CHƢƠNG Kiểm thử 15% Như vậy, sản phẩm phần mềm không đơn giản đoạn mã chương VẤN ĐỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM trình mà nhiều phần ẩn đằng sau (Hình 1.1) Vì vậy, việc mắc lỗi không xảy lập trình mà xảy cao công đoạn khác 1.1 Sản phẩm phần mềm vấn đề kiểm thử phần mềm qui trình phát triển sản phẩm phần mềm Việc kiểm thử phải 1.1.1 Sản phẩm phần mềm gì? Phần mềm (bộ) chương trình cài đặt máy tính nhằm thực tiến hành tất phần tạo nên sản phẩm phần mềm Đặc tả sản phẩm nhiệm vụ tương đối độc lập nhằm phục vụ cho ứng dụng cụ thể việc quản lý họat động máy tính áp dụng máy tính họat động kinh tế, quốc Duyệt lại sản phẩm Phản hồi từ phiên cũ phòng, văn hóa, giáo dục, giải trí,… TàiError! liệu Tài liệu thiết kế kiểm thử Thông tin cạnh tranh Khảo sát khách hàng Kiến trúc phần mềm Việc tạo sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta gọi Lịch biểu Dữ liệu Mã nguồn qui trình phát triển phần mềm, bắt đầu có ý tưởng đưa sản phẩm phần mềm thực thi Khối lượng công việc giai đoạn trình sản xuất phần mềm thay đổi theo thời gian Bảng 1.1 minh họa cụ thể điều Sản phẩm cuối Bảng 1.1 - Tỉ lệ công việc giai đoạn phát triển phần mềm Giai đoạn Phân tích yêu cầu Hai thập kỉ 1960 - 1970 Thiết kế chi tiết Lập trình kiểm thử đơn vị 10% Thập kỉ 1980 Thập kỉ 1990 Thiết kế sơ 80% 20% 40% Tích hợp kiểm thử tích hợp Setup, Help Files, Samples asn Examples, Readme files, Error Messages, Icons and Arts, User Manuals, Product Support Information, … 10% 60% 30% Kiểm thử hệ thống 20% Hình 1.1 – Sản phẩm phần mềm 30% Theo tài liệu khác [5], chi phí liên quan giai đoạn vòng đời phần 1.1.2 Thế lỗi phần mềm? Có nhiều định nghĩa khác lỗi phần mềm, tựu chung, mềm sau: Các giai đoạn phát triển phát biểu cách tổng quát: “Lỗi phần mềm không khớp chương trình Giai đoạn sản phẩm Phân tích yêu cầu 3% Đặc tả 3% Thiết kế 5% Lập trình 7% Số hóa Trung tâm Học liệu – Đại học Thái Nguyên Vận hành bảo trì 67% đặc tả nó.” [7] Dựa vào định nghĩa, thấy lỗi phần mềm xuất theo ba dạng sau:  Sai: Sản phẩm xây dựng khác với đặc tả http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn  Thiếu: Một yêu cầu đặc tả lại sản phẩm Lỗi lập trình gây dễ hiểu Ai mắc lỗi lập trình Thời kì đầu, phát triển phần mềm có nghĩa lập trình, công việc lập trình nặng xây dựng  Thừa: Một yêu cầu đưa vào sản phẩm mà đặc tả nhọc, lỗi lập trình gây chủ yếu Ngày nay, công việc lập trình Cũng có trường hợp yêu cầu thuộc tính người phần việc trình phát triển phần mềm, cộng với hỗ trợ nhiều công dùng chấp nhận khác với đặc tả nên coi có lỗi Một hình thức khác xem lỗi, phần mềm khó hiểu, khó sử dụng, chậm dễ gây cảm nhận phần mềm họat động không 1.1.3 Tại lỗi phần mềm xuất hiện? cụ lập trình cao cấp, việc lập trình trở nên nhẹ nhàng hơn, độ phức tạp phần mềm lớn nhiều Do đó, lỗi lập trình gây Tuy nhiên, nguyên nhân để lập trình tạo lỗi lại nhiều Đó độ phức tạp phần mềm, tài liệu nghèo nàn, sức ép thời gian đơn giản lỗi “không nói lên được” Một điều hiển nhiên nhiều lỗi xuất bề mặt Khác với cảm nhận thông thường, lỗi xuất nhiều lập trình Nhiều nghiên cứu thực dự án từ nhỏ đến dự án lớn kết giống Số lỗi đặc tả gây nhiều nhất, chiếm khoảng 80% Có số nguyên nhân làm cho đặc tả tạo nhiều lỗi Trong nhiều trường hợp, đặc tả không viết Các nguyên nhân khác đặc tả không đủ cẩn thận, hay thay đổi, chưa phối hợp tốt toàn nhóm phát triển Sự thay đổi yêu cầu khách hàng nguyên nhân dễ gây lỗi phần mềm Khách hàng thay đổi yêu cầu không cần quan tâm đến tác động sau thay đổi yêu cầu phải thiết kế lại, lập lại kế hoạch, làm lại việc hoàn thành Nếu có nhiều thay đổi, khó nhận biết hết phần dự án phụ thuộc phần không phụ thuộc vào thay đổi Nếu không giữ lập trình thực lại lỗi đặc tả thiết kế Một nguyên nhân khác tạo lỗi thân công cụ phát triển phần mềm có lỗi công cụ trực quan, thư viện lớp, biên dịch,… 1.1.4 Chi phí cho việc sửa lỗi Theo tài liệu trích dẫn Martin McCable [7], bảo trì phần chi phí phần mềm kiểm thử hoạt động chi phí đắt thứ hai, ước tính khoảng 40% (15/33) chi phí trình phát triển ban đầu sản phẩm phần mềm Kiểm thử phần chi phí giai đoạn bảo trì phải tiến hành kiểm thử lại thay đổi trình sửa lỗi đáp ứng yêu cầu người dùng Kiểm thử sửa lỗi thực giai đoạn vòng đời phần mềm Tuy nhiên chi phí cho việc tìm sửa lỗi tăng cách đáng kể vết thay đổi dễ phát sinh lỗi trình phát triển Nguyên nhân khác Trong tài liệu Boehm [5], có trích dẫn kết nghiên cứu IBM, GTE Lập trình TRW, tổng kết lỗi phát muộn chi phí cho việc sữa lỗi lớn Chi phí tăng theo hàm mũ hình sau Thiết kế Đặc tả Hình 1.2 – Các nguyên nhân gây lỗi phần mềm Nguồn gây lỗi lớn thứ hai thiết kế Đó tảng mà lập trình viên dựa vào để nỗ lực thực kế hoạch cho phần mềm Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn Chi phí để sữa lỗi  Những đặc tả phần mềm thường không đầy đủ hay mâu thuẫn Đặc tả Thiết kế lập trình Kiểm thử Công nghệ hệ thống Quản lý đảm bảo chất lượng Công nghệ phần mềm Đảm bảo chất lượng phần mềm Xác minh thẩm định phần mềm Xác minh thẩm định phần mềm Kiểm thử phần mềm Kiểm thử phần mềm Phát hành Hình 1.3 – Chi phí sửa lỗi theo thời gian phát lỗi (a) Ngữ cảnh quy trình (b) Ngữ cảnh chất lượng Hình 1.4 - Kiểm thử phần mềm số ngữ cảnh 1.1.5 Kiểm thử phần mềm gì? Trên quan điểm qui trình, kiểm thử phần mềm phần xác minh Kiểm thử phần mềm thường đồng nghĩa với việc tìm lỗi chưa phát thẩm định phần mềm Xác minh thẩm định nằm công nghệ phần mềm, Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ lỗi Kiểm thử phần công nghệ phần mềm lại phần công nghệ hệ thống (Hình 1.4a) Nhìn từ mềm trình thực thi hệ thống phần mềm để xác định xem phần mềm ngữ cảnh chất lượng (Hình 1.4b), kiểm thử phần mềm phần xác có với đặc tả không thực môi trường mong đợi hay không minh thẩm định phần mềm, nên xem phần đảm bảo Mục đích kiểm thử phần mềm tìm lỗi chưa phát hiện, tìm chất lượng phần mềm Nếu phần mềm thành phần hệ thống lớn kiểm cách sớm đảm bảo lỗi sửa, mà kiểm thử phần mềm không làm thử phần mềm xem phần quản lý đảm bảo chất lượng công việc chẩn đoán nguyên nhân gây lỗi phát sửa lỗi Và để đạt phần mềm chất lượng cao, kiểm thử coi thành phần chủ Mục tiêu kiểm thử phần mềm thiết kế tài liệu kiểm thử cách có hệ thống thực cho có hiệu quả, tiết kiệm thời gian, công sức chi phí yếu hoạt động đảm bảo chất lượng phần mềm 1.3 Qui trình kiểm thử phần mềm Mục đích kiểm thử thiết kế chuỗi trường hợp kiểm thử mà có khả phát lỗi cao Để cho việc kiểm thử đạt kết tốt cần có 1.2 Chất lƣợng phần mềm Chất lượng phần mềm khái niệm đa chiều, không dễ định nghĩa đơn giản theo cách chung cho sản phẩm là: “Sản phẩm phát triển phù hợp với đặc tả nó.” [8] Có số vấn đề khó hệ thống phần mềm, là:  Đặc tả phải định hướng theo đòi hỏi chất lượng khách hàng chuẩn bị kế hoạch kiểm thử, thiết kế trường hợp kiểm thử liệu kiểm thử cho trường hợp Đây đầu vào cho giai đoạn kiểm thử Và sản phẩm công việc giai đoạn kiểm thử “báo cáo kiểm thử” mà tài liệu hóa tất trường hợp kiểm thử chạy, liệu đầu vào, đầu mong đợi, đầu thực tế mục đích kiểm thử,… (như Hình 1.5) (như tính hiệu quả, độ tin cậy, tính dễ hiểu, tính bảo mật,…) yêu cầu tổ chức phát triển phần mềm vốn đặc tả Phân tích Thiết kế KIỂM THỬ Mã hóa Bàn giao SP (như yêu cầu khả bảo trì, tính sử dụng lại, ) Kế hoạch kiểm thử  Một số yêu cầu chất lượng khó cách rõ ràng Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn Các trường hợp kiểm thử Các báo cáo kiểm thử Dữ liệu kiểm thử Số hóa Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn Heiser (1997) [3] đưa bốn tiêu chuẩn cho việc kết thúc kiểm thử: Kiểm thử hệ thống Phân tích yêu cầu Kiểm thử tính hợp lệ Thiết kế Kiểm thử tích hợp Mã hoá Kiểm thử đơn vị  Khi dự án hết tiền thời gian  Khi đội ngũ kiểm thử không nghĩ thêm trường hợp kiểm thử  Khi kiểm thử tiếp tục mà không phát lỗi  Khi đạt đến mức độ phủ thích hợp Hình 3.2 – Các bƣớc kiểm thử Chiến lược phổ biến kiểm thử dự án hết tiền  Kiểm thử đơn vị: tập trung module riêng biệt, đảm bảo thời gian Tuy nhiên, chiến lược bao gồm vài rủi ro: việc phát triển vượt ngân sách việc kiểm thử chất lượng chức tương ứng với đơn vị  Kiểm thử tích hợp: tập trung vào việc thiết kế xây dựng kiến trúc phần Một chiến lược khác sử dụng mô hình thống kê lý thuyết độ tin cậy phần mềm, mô hình thất bại phần mềm (được phát trình kiểm thử) mềm  Kiểm thử tính hợp lệ: yêu cầu thiết lập phần việc phân tích yêu cầu phần mềm thẩm định, dựa vào phần mềm theo hàm thời gian thực phát triển Mô hình thất bại gọi mô hình thời gian thực lôga Poisson, có dạng: 1 xây dựng Tiêu chuẩn hợp lệ cần kiểm thử f(t) =   ln[lopt + 1] p  Kiểm thử hệ thống: phần công nghệ hệ thống máy tính, phần mềm thành phần khác hệ thống kiểm thử Kiểm thử hệ thống nhằm xác minh tất thành phần hệ thống khớp cách hợp lý, tất chức hệ thống hiệu suất đạt (0.1)   đó:  f(t) số thất bại luỹ tích dự đoán xuất lần phần mềm kiểm thử khoảng thời gian thực t  lo cường độ thất bại phần mềm ban đầu (số thất bại đơn vị thời 3.2.4 Điều kiện hoàn thành kiểm thử Một câu hỏi khó kiểm thử phần mềm, là: “Khi hoàn thành việc kiểm thử - làm để biết kiểm thử đủ?” Không có câu trả lời dứt khoát cho câu hỏi Thật ra, “không hoàn thành việc kiểm thử, trách nhiệm thường chuyển từ người phát triển cho khách hàng” Mỗi gian) bắt đầu kiểm thử  p biến đổi số mũ cường độ thất bại lỗi phát khắc phục thực Cường độ thất bại tức thời, l(t) suy cách tính đạo hàm f(t): lần, khách hàng (người sử dụng) thực chương trình máy tính, chương trình kiểm thử với tập liệu Có nhiều tranh cãi câu trả lời cho câu hỏi l(t) = lo l o pt  (0.2) trên, nhiên, kỹ sư phần mềm cần phải có tiêu chuẩn chặt chẽ để xác định Sử dụng quan hệ ghi phương trình (3.2), người kiểm thử dự kiểm thử đạt hiệu đoán việc giảm lỗi trình kiểm thử Cường độ lỗi thực tế vẽ Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 40 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 41 http://www.lrc-tnu.edu.vn dọc theo đường cong dự đoán (Hình 3.3) Nếu liệu thực tế tập hợp lại Số lỗi lại số điểm liệu, mô hình sử dụng để dự đoán tổng thời gian thực cần để đạt tỷ lệ thất bại chấp nhận Số thất bại theo thời gian kiểm thử Dữ liệu chọn suốt kiểm thử Mật độ thất bại dự đoán, l(t) Số lỗi lại trình kiểm thử mô hình thời gian thực loga Poisson phù hợp với Số lượng kiểm thử tối ưu Chi phí kiểm thử Quá mức kiểm thử tối ưu Dưới mức kiểm thử tối ưu Chất lượng kiểm thử chấp nhận Mô hình thời gian thực loga Poisson l0 Với điều chỉnh hợp lý, mô hình dự đoán thời gian kiểm thử yêu cầu để đạt tỷ lệ thất bại chấp nhận Số lượng kiểm thử Hình 3.4- Quan hệ chi phí kiểm thử số lỗi chƣa đƣợc phát 3.3 Kiểm thử đơn vị Kiểm thử đơn vị tập trung vào việc xác minh đơn vị nhỏ thiết kế Thời gian thực hiện, t Hình 3.3 - Mật độ lỗi hàm thời gian thực Bằng phép tập hợp việc kiểm thử sử dụng mô hình độ tin cậy phần mềm tồn tại, phát triển dẫn để trả lời cho câu hỏi: “Khi hoàn thành kiểm thử?” phần mềm – thành phần phần mềm, module lớp Sử dụng mô tả thiết kế thủ tục để hướng dẫn, đường dẫn điều khiển quan trọng kiểm thử để phát lỗi phạm vi module Độ phức tạp liên quan kiểm thử lỗi phát giới hạn ràng buộc phạm vi thiết lập cho kiểm thử đơn vị Kiểm thử đơn vị thường hướng hộp trắng, bước thực song Hình 3.4 mối quan hệ số lượng kiểm thử thực số lỗi tìm thấy Nếu kiểm thử nhiều chi phí tăng cách khó chấp nhận được, ngược lại kiểm thử chi phí thấp, nhiều lỗi Số lượng kiểm thử tối ưu không kiểm thử nhiều song nhiều module 3.3.1 Các lý kiểm thử đơn vị Các kiểm thử xuất phần kiểm thử đơn vị minh hoạ hình 3.5(a) Các kiểm thử nhằm phát lỗi phạm vi không module bao gồm:  Giao diện module,  Cấu trúc liệu cục bộ,  Điều kiện biên,  Đường dẫn độc lập,  Đường dẫn xử lý lỗi Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 42 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 43 http://www.lrc-tnu.edu.vn  Giao diện module: kiểm thử để đảm bảo thông tin vào, hợp lệ đơn  Tên biến không (sai tả bị cắt bớt) vị chương trình Thường gồm số kiểm thử cần thiết :  Kiểu liệu không thống  Số tham số đầu vào có số đối số không?  Thiếu tràn nhớ, ngoại lệ  Các thuộc tính tham số đối số có phù hợp không?  Điều kiện biên: Điều kiện biên kiểm thử để đảm bảo module hoạt  Số đối số truyền vào cho module gọi có phù hợp số tham số? động hợp lệ biên thiết lập đạt đến giới hạn xử lý giới hạn  Các thuộc tính đối số truyền cho module gọi có phù hợp với thuộc tính  Đường dẫn độc lập: Tất đường dẫn độc lập cấu trúc điều khiển thực để đảm bảo tất câu lệnh module thực tham số? lần  Khai báo biến toàn cục quán module?  Đường dẫn xử lý lỗi: Một thiết kế tốt cho biết điều kiện lỗi biết  Các ràng buộc phù hợp với tham số? trước đường dẫn xử lý lỗi thiết lập để gửi lại kết thúc xử lý dễ  Các đối số truyền vào có thứ tự? dàng lỗi xuất Một số lỗi tiềm ẩn kiểm thử việc xử lý lỗi Khi module thực vào ra, cần thực kiểm thử giao diện bổ sung: đánh giá:  Các thuộc tính tập tin có không?  Mô tả lỗi khó hiểu  Các lệnh đóng/mở tập tin có không?  Lỗi giải không phù hợp với lỗi gặp phải  Các đặc tả hình thức phù hợp với lệnh vào/ra  Điều kiện lỗi dẫn đến can thiệp hệ thống trước xử lý lỗi  Kích thước vùng đệm phù hợp với kích thước ghi?  Xử lý điều kiện ngoại lệ không xác  Các tập tin mở trước sử dụng?  Mô tả lỗi không cung cấp đủ thông tin để hỗ trợ xác định nguyên nhân lỗi  Xử lý điều kiện kết thúc tập tin? Module  Xử lý lỗi vào ra? Giao diện Bộ điều khiển Cấu trúc liệu cục  Cấu trúc liệu cục bộ: nguồn lỗi phổ biến, kiểm tra để đảm bảo Giao diện Cấu trúc liệu cục Các điều kiện biên Các điều kiện biên Các đường dẫn độc lập Các đường dẫn độc lập Các đường dẫn xử lý lỗi Các đường dẫn xử lý lỗi Module kiểm thử liệu lưu trữ tạm thời đảm bảo tính nguyên vẹn tất bước thực thuật toán Các trường hợp kiểm thử thiết kế để phát loại Các trường hợp kiểm thử lỗi sau:  Kiểu không thích hợp mâu thuẫn KẾT QUẢ (a)  Giá trị khởi tạo giá trị mặc định không Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 44 Các trường hợp kiểm thử Nhánh cụt Nhánh cụt Hình 3.5 – (a) Kiểm thử đơn vị; http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên (b) (b) Môi trƣờng kiểm thử đơn vị 45 http://www.lrc-tnu.edu.vn 3.3.2 Các thủ tục kiểm thử đơn vị 3.4.1 Kiểm thử tích hợp từ xuống (Top-Down Integration) Kiểm thử đơn vị thường xem phần phụ cho bước mã hoá Sau Tích hợp top-down cách tiếp cận gia tăng để xây dựng cấu trúc chương mã nguồn phát triển, duyệt lại kiểm tra cú pháp, trình Các module tích hợp cách di chuyển xuống thông qua phân bắt đầu thiết kế trường hợp kiểm thử đơn vị Việc xem lại thông tin thiết kế cấp điều khiển, bắt đầu với module điều khiển (chương trình chính) Các hướng dẫn cho việc thiết lập trường hợp kiểm thử phù hợp nhằm phát loại module mức (và module mức cùng) kết hợp vào module chương lỗi Mỗi trường hợp kiểm thử phải gắn liền với tập kết mong đợi trình thành cấu trúc theo chiều rộng chiều sâu Vì module chương trình độc lập, nên phần mềm điều Như hình 3.6, tích hợp theo chiều sâu gom tất phần tử theo đường khiển và/hoặc nhánh cụt cần phát triển cho kiểm thử đơn vị Môi trường dẫn điều khiển cấu trúc Việc chọn đường dẫn điều khiển tuỳ kiểm thử đơn vị minh hoạ hình 3.5(b) biến phụ thuộc đặc trưng ứng dụng Quá trình tích hợp thực Các nhánh cụt dùng để thay module cấp gọi module kiểm thử theo bước sau: 1) Module điều khiển sử dụng điều khiển, Kiểm thử đơn vị đơn giản hoá module có liên kết cao thiết kế Khi chức gọi module, số trường hợp kiểm thử giảm xuống lỗi dự đoán phát sớm nhánh cụt thay cho tất module trực tiếp bên module điều khiển 2) Phụ thuộc vào cách tiếp cận tích hợp chọn (tức theo chiều rộng chiều sâu), nhánh cụt bên thay thời điểm với 3.4 Kiểm thử tích hợp module Kiểm thử tích hợp kỹ thuật có hệ thống để xây dựng cấu trúc chương trình thực kiểm thử nhằm phát lỗi liên quan đến giao diện Mục tiêu lấy thành phần kiểm thử xây dựng cấu trúc chương 3) Các kiểm thử thực module tích hợp 4) Khi hoàn thành tập kiểm thử, nhánh cụt khác thay module thực trình mô tả thiết kế Tích hợp gia tăng đối lập với cách tiếp cận big-bang Giống tô màu đồ, chương trình xây dựng kiểm thử đoạn nhỏ, 5) Kiểm thử hồi qui (xem mục 3.4.3) thực để đảm bảo lỗi không xuất lỗi sớm cô lập hiệu chỉnh; giao diện có khả M1 kiểm thử trọn vẹn hơn; cách tiếp cận kiểm thử có hệ thống M2 áp dụng Trong phần tìm hiểu số chiến lược tích hợp gia tăng khác M5 M3 M6 M4 M7 M8 Hình 3.6 - Kiểm thử Top-Down Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 46 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 47 http://www.lrc-tnu.edu.vn 3.4.2 Chiến lƣợc kiểm thử từ dƣới lên (Bottom-Up Testing) 3.4.3 Kiểm thử hồi qui Kiểm thử tích hợp bottom-up, giống tên gọi, bắt đầu xây dựng kiểm Mỗi lần module thêm vào phần kiểm thử tích hợp, thử với module nguyên tử (tức là, module mức thấp cấu trúc phần mềm thay đổi Các đường dẫn luồng liệu thiết lập, vào I/O chương trình) Chiến lược kiểm thử tích hợp bottom-up cài đặt theo xuất hiện, logic điều khiển yêu cầu Các thay đổi gây bước sau: nên vấn đề với chức làm việc hoàn hảo trước Trong ngữ cảnh 1) Các module mức thấp kết hợp thành nhóm (cluster) 2) Bộ điều khiển (chương trình điều khiển cho việc kiểm thử) viết để phối hợp trường hợp kiểm thử đầu vào đầu chiến lược kiểm thử tích hợp, kiểm thử hồi qui việc thực lại số tập kiểm thử thực trước để đảm bảo thay đổi không sinh hiệu ứng không mong muốn Kiểm thử hồi qui hoạt động trợ giúp để đảm bảo thay đổi (do kiểm 3) Kiểm thử nhóm thử nguyên nhân khác) không đưa hành vi lỗi bổ sung 4) Các điều khiển loại bỏ nhóm kết hợp chuyển dịch lên cấu trúc chương trình không mong đợi Kiểm thử hồi quy thực thủ công, cách thực lại tập tất Tích hợp mẫu sau minh họa hình 3.7 Các module kết hợp tạo trường hợp kiểm thử sử dụng công cụ thu phát tự động Bộ kiểm thành nhóm 1, Mỗi nhóm kiểm thử sử dụng điều khiển Các thử hồi quy (tập kiểm thử thực thi) gồm ba lớp trường hợp module nhóm mức Ma Các điều khiển D1 D2 kiểm thử khác nhau: loại bỏ, nhóm giao tiếp trực tiếp với Ma Tương tự, điều khiển D3 cho nhóm loại bỏ trước tích hợp với module Mb Cả hai Ma Mb cuối tích hợp với module Mc,…  Một mẫu đại diện kiểm thử thực tất chức phần mềm  Các trường hợp kiểm thử bổ sung tập trung vào chức phần mềm có Mc Ma D1 khả bị tác động có thay đổi  Các kiểm thử tập trung vào thành phần phần mềm vừa bị thay đổi Mb D2 3.4.4 Các ghi kiểm thử tích hợp D3 Các chiến lược kiểm thử tích hợp top-down bottom-up có ưu Nhóm nhược điểm Ưu điểm chiến lược có xu hướng nhược điểm chiến lược khác Nhóm Nhóm Hình 3.7 – Tích hợp Bottom-Up Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 48 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 49 http://www.lrc-tnu.edu.vn Bảng 3.1 – So sánh kiểm thử top-down bottom-up Kiểm thử top-down Kiểm thử bottom-up tới hạn Module tới hạn có nhiều đặc trưng sau:  Lựa chọn số yêu cầu phần mềm Ƣu điểm Có ưu điểm lỗi tập trung đỉnh Có ưu điểm lỗi xuất chương trình  Có mức điều khiển cao (nằm tương đối cao cấu trúc chương trình) phía chương trình Khi chức vào/ra bổ sung, Các điều kiện kiểm thử dễ dàng đưa trường hợp kiểm thử sớm Khi kiểm thử tích hợp thực hiện, người kiểm thử cần module  Có yêu cầu thực không rõ ràng tạo Việc quan sát kết kiểm thử dễ Việc có chương trình khung sớm tạo  Là phức tạp dễ xảy lỗi Các module tới hạn cần kiểm thử sớm Hơn nữa, kiểm thử hồi quy cần tập trung chức module tới hạn tư rõ ràng tạo tâm lý tốt 3.5 Kiểm thử tính hợp lệ kiểm thử Nhƣợc điểm Điểm cao kiểm thử tích hợp, phần mềm lắp ghép toàn thành Module nhánh cụt bắt buộc phải Các module điều khiển bắt buộc phải tạo tạo mềm cuối - kiểm thử tính hợp lệ - bắt đầu Module nhánh cụt thường phức tạp Chương trình thực thể lần xuất không tồn module cuối tạo Trước chức vào/ra Đặc tả yêu cầu phần mềm tốt có chứa phần gọi “điều kiện hợp lệ”, thiết lập sở cho việc thực kiểm thử tính hợp lệ 3.5.1 Điều kiện kiểm thử tính hợp lệ thêm, việc đưa trường hợp kiểm Tính hợp lệ phần mềm đạt thông qua dãy kiểm thử hộp đen thử nhánh cụt khó khăn nhằm minh chứng phù hợp với yêu cầu Kế hoạch kiểm thử phác thảo Việc tạo điều kiện kiểm thử lớp kiểm thử thực hiện, thủ tục kiểm thử xác định trường hợp kiểm khó khăn thử sử dụng nhằm cố gắng phát lỗi thoả mãn yêu cầu Việc quan sát đầu kiểm thử khó khăn Sau trường hợp kiểm thử hợp lệ thực hiện, tồn hai điều Làm cho người ta nghĩ nhầm việc kiện sau: thiết kế chương trình kiểm thử  Các đặc trưng chức khả thực phù hợp với đặc tả chồng chéo chấp nhận Gây trì hoãn việc hoàn thành  Sự sai lệch với đặc tả phát danh sách thiếu sót tạo module Số hóa Trung tâm Học liệu – Đại học Thái Nguyên gói; lỗi giao diện phát hiệu chỉnh, dãy kiểm thử phần 50 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 51 http://www.lrc-tnu.edu.vn nhiên, kiểm thử beta ứng dụng “sống” phần mềm môi trường 3.5.2 Duyệt lại cấu hình Thành phần quan trọng trình kiểm tra tính hợp lệ duyệt lại cấu hình Mục đích việc duyệt lại nhằm đảm bảo tất thành phần cấu không điều khiển người phát triển 3.6 Kiểm thử hệ thống hình phần mềm phát triển hợp lý, lập danh mục, có chi tiết cần Phần mềm thành phần hệ thống lớn dựa máy tính Cuối thiết để hỗ trợ giai đoạn bảo trì vòng đời phần mềm cùng, phần mềm kết hợp chặt chẽ với thành phần khác hệ thống (như phần 3.5.3 Kiểm thử Alpha Beta cứng, người, thông tin, ) dãy kiểm thử tích hợp tính hợp lệ Người phát triển phần mềm gần đoán trước khách hàng sử hệ thống thực dụng chương trình cách thực Các tài liệu hướng dẫn sử dụng có Kiểm thử hệ thống thực tế tập kiểm thử khác với mục đích thể bị hiểu sai; tổ hợp liệu lạ thường thường xuyên sử dụng; thực đầy đủ hệ thống dựa máy tính Mặc dù kiểm thử có đầu rõ ràng người kiểm thử khó hiểu cho người sử mục đích khác nhau, tất công việc nhằm kiểm tra tất thành dụng phần hệ thống tích hợp cách hợp lý thực chức Khi phần mềm xây dựng theo hợp đồng đặt hàng khách hàng, chuỗi kiểm thử chấp nhận thực cho phép khách hàng thẩm định tất xác định 3.6.1 Kiểm thử khôi phục yêu cầu Nhiều hệ thống dựa máy tính cần khôi phục sai sót tiếp tục Nếu phần mềm phát triển sản phẩm mang tính phổ dụng để sử dụng cho nhiều khách hàng, việc thực kiểm thử chấp nhận với khách hàng không thực tế Đa số người xây dựng sản phẩm phần mềm sử dụng kiểm thử alpha beta để phát lỗi mà người dùng cuối tìm thấy trình xử lý khoảng thời gian xác định trước Kiểm thử khôi phục kiểm thử hệ thống có tác động đến phần mềm bị lỗi theo nhiều cách khác kiểm tra khôi phục thực hợp lý Nếu việc khôi phục tự động (được thực hệ thống) việc khởi tạo lại, kỹ thuật điểm kiểm soát, khôi phục liệu bắt đầu lại ước lượng  Kiểm thử alpha cho xác Nếu việc khôi phục yêu cầu can thiệp người, thời Kiểm thử alpha thực khách hàng vị trí người phát gian trung bình để khôi phục ước lượng để xác định giới hạn chấp nhận triển Phần mềm sử dụng môi trường tự nhiên với người phát triển “xem xét vai trò” người dùng ghi lại lỗi vấn đề sử dụng 3.6.2 Kiểm thử bảo mật Kiểm thử alpha thực môi trường điều khiển  Kiểm thử beta Bất kỳ hệ thống dựa máy tính có quản lý thông tin nhạy cảm dẫn đến hoạt động có khả gây thiệt hại (hoặc lợi ích) không cách cho Kiểm thử beta thực nhiều người dùng cuối phần cá nhân mục tiêu cho việc thâm nhập không bất hợp pháp Kiểm thử mềm Không giống kiểm thử alpha, người phát triển nói chung mặt Tuy tính bảo mật cố gắng kiểm tra kỹ thuật bảo vệ xây dựng hệ thống bảo vệ khỏi việc truy nhập bất hợp pháp Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 52 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 53 http://www.lrc-tnu.edu.vn CHƢƠNG 3.6.3 Kiểm thử ứng suất Trong suốt trình kiểm thử phần mềm trước, kỹ thuật hộp trắng hộp MỘT SỐ ỨNG DỤNG CỤ THỂ CỦA QUI TRÌNH KIỂM THỬ đen dẫn đến ước lượng triệt để chức khả thực chương trình chuẩn tắc Kiểm thử ứng suất thiết kế để đối chiếu chương trình với 4.1 Mục tiêu Phần vào tìm hiểu số toán cụ thể nghiên cứu xây dựng trạng thái không chuẩn tắc Kiểm thử ứng suất thực hệ thống với mục đich tìm giới hạn hệ thống thất bại yêu cầu tài nguyên với chất lượng, tần suất, số lượng không bình thường, chẳng hạn: liệu kiểm thử cho toán chương trình kiểm thử tự động 4.2 Phƣơng pháp luận 4.2.1 Tổng quan phƣơng pháp  Các kiểm thử cụ thể thiết kế cho trường hợp tỷ lệ ngắt cao bình thường Các chức hành vi hệ thống phần mềm phần xác định hệ thống không bị thay đổi không bị ngược lại có thay đổi  Tốc độ liệu đầu vào tăng cường độ để xác định chức đáp ứng đầu vào mã nguồn Vì vậy, với mục đích đảm bảo chương trình không bị ngược lại, cần thiết phải thực việc kiểm thử hồi qui Có hai kiểu kiểm thử thường gọi  Thực trường hợp kiểm thử mà yêu cầu nhớ tối đa tài kiểm thử hồi qui  Các kiểm thử chức kiểm tra toàn hệ thống có thoả mãn yêu cầu nguyên khác  Thiết kế trường hợp kiểm thử gây nên thất bại hệ điều hành ảo mục đích thực  Kiểm thử đơn vị tạo người lập trình để kiểm tra mặt  Thực trường hợp kiểm thử gây nên tìm kiếm mức cho liệu thành phần hệ thống lớp module hành vi mong đợi đĩa Việc thực kiểm thử hồi qui có nghĩa thực nhiều trường hợp kiểm 3.6.4 Kiểm thử khả thực Với hệ thống nhúng thời gian thực, phần mềm cung cấp chức yêu cầu không tuân theo yêu cầu khả thực không chấp nhận Các kiểm thử khả thực thường kết hợp với kiểm thử ứng suất thử khác thực chúng thường xuyên Vì chấp nhận việc thực thủ công, thời gian không tin cậy Do đó, cần thiết thực cách tự động 4.2.2 Phạm vi giải thường yêu cầu trang bị phần cứng phần mềm Bằng việc cung cấp hệ Có nhiều phương pháp xếp khác nghiên cứu phát triển thống, người kiểm thử phát trạng thái mà dẫn đến suy giảm Mỗi phương pháp có ưu nhược điểm riêng độ phức tạp tính toán thời gian thất bại hệ thống thực Vì vậy, để lấy ví dụ tốt cho việc kiểm thử khả thực hiện, chúng Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 54 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 55 http://www.lrc-tnu.edu.vn ta chọn hai nhóm thuật toán sau để thực kiểm thử hộp đen so sánh kết thực 4.2.4 Tổ chức giao diện kiểm thử Để thực trường hợp kiểm thử, cần thiết kế cho chương trình  Độ phức tạp O(n^2): Insertion Sort, Selection Sort, Shell Sort, Bubble Sort  Độ phức tạp O(n log n): Heap Sort, Quick Sort, Merge Sort Việc kiểm thử đơn vị mođun thuật toán sử dụng phương pháp kiểm thử hộp trắng (phương pháp đường dẫn sở) Và để minh hoạ cho qui trình kiểm thử tích hợp thử lấy module MergeSort để thiết kế kiểm thử trình giao diện để kiểm thử Có nhiều cách thiết kế giao diện khác  Các kiểm thử hướng lô: giao diện cho chương trình dòng lệnh, kiểm thử tự động thực hiện, bắt đầu chương trình với tham số cho xem xét đầu ra, tập tin tạo  Kiểm thử dựa luồng: Cách bao gồm hầu hết phương pháp kiểm thử  Kiểm thử GUI: giao diện người dùng đồ hoạ cho việc kiểm thử có 4.2.3 Phân loại kiểu kiểm thử Vấn đề kiểm thử phần mềm, mục đich phát lỗi nhằm để đảm vài vấn đề Mặc dù có công cụ cho giao diện đồ hoạ kiểm thử bảo chất lượng phần mềm Do đó, chọn thuật toán xếp làm ví dụ qui cách làm lại hành động ghi lại trước giống kiện trình kiểm thử, lý nêu trên, việc lựa chọn nhằm kiểm tra phím bấm chuột hình so sánh, chúng đối phó tốt khả thực phần mềm (mỗi thuật toán có ưu nhược điểm khác với cải biên thay đổi nhiều thành phần giao diện Vì thế, nhớ, thời gian, ) trường hợp kiểm thử cần ghi lại sau thay đổi giao diện người dùng Phát biểu cho toán xếp sau:  Các giao diện mã kiểm thử nhúng: Trong trường hợp kiểm thử  Với P chương trình xếp lưu trình hướng lô đơn giản giao diện ứng dụng  S bảng đặc tả cho P sau: giao diện không cung cấp đủ truy cập GUI cần + P nhận đầu vào với số nguyên N (N > 0) dãy N số nguyên gọi phần tử dãy ≤ K ≤ e -1 với e kiểm thử, tập hợp thành phần sử dụng không cung cấp giao diện kiểm thử thích hợp, giao diện kiểm thử nhúng ứng dụng hữu ích + K phần tử dãy + Chương trình P xếp dãy theo thứ tự tăng dần xuất dãy Giao diện người dùng xếp  P xem với đặc tả S nếu: với đầu vào hợp lệ, đầu P tương ứng với đặc tả S Giao diện kiểm thử nhúng Lệnh liệu Ứng dụng Bộ kiểm thử Các kết Hình 4.1– Giao diện kiểm thử nhúng Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 56 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 57 http://www.lrc-tnu.edu.vn 4.3 Phát sinh trƣờng hợp kiểm thử Module MergeSort có cấu trúc sau: 4.3.1 Chiến lƣợc kiểm thử  Merge: Module nối hai mảng xếp, miền kề sát mảng Việc kiểm thử thuật toán xếp thực theo nhiều mức khác nhau:  Mức cao: bao gồm việc kiểm thử chức năng, kiểm thử khả thực  Mức thấp: bao gồm việc kiểm thử đơn vị kiểm thử tích hợp thành phần thành mảng đơn, mảng xếp Sau vùng hai miền ghi đè mảng xếp Vì cần cung cấp không gian tạm thời tham số cho hàm  Split : Hàm tách nhận vào miền chia thành hai nửa, gọi đệ qui cho nửa, chứa nhiều phần tử sau nối hai nửa kề Với việc kiểm thử mức cao cho thuật toán xếp, thiết kế trường hợp kiểm thử nhằm kiểm tra khả tối đa phần tử dãy hiệu thuật toán Vì vậy, mức sử dụng phương pháp hộp đen để sinh liệu đầu vào kiểm tra kết đầu theo đặc tả thuật toán sát hàm nối  MergeSort:Module giao diện người dùng cuối cho chức xếp Trong nhớ tạm thời cấp phát sau hàm tách gọi với tham số khởi tạo Ở mức thấp, để thực kiểm thử cho thuật toán cần thiết kế trường hợp kiểm thử với mục đích tìm lỗi mã lệnh Vì vậy, cần thâm nhập vào lập, đề xuất gọi phụ thuộc áp dụng kiểm mã lệnh thuật toán áp dụng phương pháp hộp trắng để phát sinh Split trường hợp kiểm thử, xây dựng liệu kiểm thử tương ứng 4.3.2 Kiểm thử đơn vị Trong kiểm thử hộp trắng, giao diện người dùng bỏ qua Các đầu vào  Module Merge Sort thử tích hợp chức cách tích hợp từ xuống tích hợp từ lên Để dễ phát sinh trường Merge đầu kiểm thử trực tiếp mức mã kết so sánh theo đặc tả Chúng ta khó để kiểm thử ba chức cách độc MergeSort hợp kiểm thử quan sát 4.3.2.1 Xác định trường hợp kiểm thử thiết kế kiểm thử Các trường hợp kiểm thử sinh từ mô tả chức đơn vị Có phương pháp luận kiểm thử với vài cách tiếp cận để phát sinh trường hợp kiểm thử, cần suy đoán để tìm trường hợp kiểm thử có khả phát lỗi Để thiết kế trường hợp kiểm thử cho module mergesort áp dụng phương pháp kiểm thử đường dẫn sở  Các trường hợp kiểm thử cho chức merge Áp dụng phương pháp đường dẫn sở, xây dựng đồ thị lưu trình sau: Hình 4.2 – Minh hoạ thuật toán xếp MergeSort Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 58 http://www.lrc-tnu.edu.vn  Vẽ đồ thị lưu trình cho hàm merge Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 59 http://www.lrc-tnu.edu.vn + Trường hợp (ứng với đường dẫn 1):    10 12 Dữ liệu cần xếp (Data): 2 R6 R3 Các tham số (left, mid, right): 4 3 R1 R4 Kết mong đợi (Data): R2 10 + Trường hợp (ứng với đường dẫn 2):    10  11  10 Dữ liệu xếp (Data): R5 11 12 Hình 4.3 - Đồ thị lƣu trình chức merge  Đối chiếu hình 4.2, xác định độ phức tạp cyclomat V(G) theo công thức: Các tham số (left, mid, right): 4 Kết mong đợi (data): + Trường hợp (ứng với đường dẫn 3):      … V(G) = số vùng = Chúng ta xét thấy đường dẫn xảy V(G) = số cạnh - số đỉnh + = 16 -12 + = V(G) = Số đỉnh điều kiện + = (Các đỉnh 2, 3, 4, 8, 10 đỉnh điều kiện) + Trường hợp (ứng với đường dẫn 4):     … Vậy độ phức tạp cyclomat tính V(G) = Dữ liệu xếp (Data):  Xác định tập sở đường dẫn độc lập Các tham số (left, mid, right): Kết mong đợi (Data): + Đường dẫn :    10  12 + Trường hợp (ứng với đường dẫn 5): 1 2 3 4    … + Đường dẫn 2:    10  11  10 … Dữ liệu xếp (Data): + Đường dẫn 3:      … Các tham số (left, mid, right): + Đường dẫn 4:     … Kết mong đợi (Data): + Đường dẫn 5:        … + Trường hợp (ứng với đường dẫn 6)  34 6 72… + Đường dẫn 6:        … Các dấu chấm lửng (…) phía sau đưòng dẫn có nghĩa đường dẫn qua phần lại cấu trúc chấp nhận  Chuẩn bị trường hợp kiểm thử để đường dẫn tập sở Dữ liệu xếp (Data): Các tham số (left, mid, right): Kết mong đợi (Data): thực Dữ liệu nên chọn cho điều kiện đỉnh điều kiện tập thích hợp cho đường dẫn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 60 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 61 http://www.lrc-tnu.edu.vn Bảng 4.1 - Bảng trƣờng hợp kiểm thử cho module Merge Số hiệu Tên kiểm Kiểu kiểm thử thử Bảng 4.2 – Các trƣờng hợp kiểm thử cho module Split Đặc tả Đầu vào Kết mong đợi Số hiệu Tên kiểm thử Đặc tả Kiểu kiểm thử Data: 1.1 Merge1 1327562 2.1 Split Condition Data: Basic-Path 1327562 Các tham số : 4 2.2 Split Condition Merge4 Data: Basic-Path 3274651 Các tham số :4 Merge5 2.3 Split Condition 24569 Các tham số : Data: 1.5 31415 Các tham số : 1 Data: 1.4 15243 Các tham số : Data: Merge2 Kết mong đợi Data: Basic-Path Các tham số : 4 1.2 Đầu vào Basic-Path 13416728 Các tham số : Data dãy số cần xếp Các tham số vị trí bắt đầu kết thúc dãy cần tách Data: 1.6 Merge6 Basic-Path 132574823 Các tham số : Chức gọi thực Split kiểm thử cuối cùng, khả  Các trường hợp kiểm thử cho chức split xảy lỗi module khó xảy Tuy nhiên, cần thiết kế Với chức split để chia mảng thành hai nửa, mảng có nhiều phần tử Cứ gọi đệ qui cho hai nửa Sau nối hai nửa thành mảng xếp Với chức áp dụng phương pháp kiểm thử điều kiện để phát sinh trường hợp kiểm thử Trong chức split lệnh thực ứng với điều kiện có dạng: C = E1 > E2 E1 ứng với left E2 ứng với right Điều kiện ràng buộc cho C có dạng (D1, D2) với D1 D2 >, = < Vậy trường hợp kiểm thử cho split phát sinh sau: trường hợp kiểm thử cho module để thực việc kiểm thử thích hợp module tích hợp lại thành module MergeSort Với lớp liệu đầu vào tổ chức thành lớp tương đương sau:  Dữ liệu đầu vào ngẫu nhiên  Dữ liệu đầu vào có thứ tự  Dữ liệu đầu vào xếp theo thứ tự ngược Mảng xếp gồm K phần tử ( ≤ K ≤ N, N= 32000) Do miền liệu đầu vào phân hoạch thành lớp tương đương:  Trường hợp 1: left > right  Lớp tương đương hợp lệ: có K phần tử với < K < 32000  Trường hợp 2: left = right  Lớp tương đương không hợp lệ: có K phần tử với K > 32000  Trường hợp 3: left < right  Lớp tương đương không hợp lệ: có K phần tử với K < Trong left >= 0, right < số phần tử dãy cần tách Số hóa Trung tâm Học liệu – Đại học Thái Nguyên  Các trường hợp kiểm thử cho chức MergeSort 62 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 63 http://www.lrc-tnu.edu.vn Áp dụng phương pháp phân tích giá trị biên, có trường hợp kiểm thử giá trị biên lớp phân hoạch 4.3.2.2 Bộ điều khiển kiểm thử Sau xác định giao diện cho module trường hợp kiểm thử, chúng  Trường hợp mảng có phần tử ta bắt đầu mã hoá điều khiển kiểm thử, mà sau sử dụng để  Trường hợp mảng có phần tử liên lạc kiểm thử mã thực Chương trình đọc tất tham số vào mảng gọi thực hàm cụ thể với tham số Sau đó, mảng kết xuất  Trường hợp mảng có 32000 phần tử để kiểm tra với kiểm thử  Trường hợp mảng có 32001 phần tử 4.3.2.3.Kết kiểm thử Từ việc phân tích trường hợp hợp lệ không hợp lệ trên, tổng kết bảng trường hợp kiểm thử cho MergeSort sau Số hiệu Tên kiểm thử việc thực kiểm thử Đặc tả Kiểu kiểm thử Việc kiểm thử phát vài lỗi mã, kết kiểm thử ứng với trường hợp kiểm thử cần phải ghi lại vào tập tin log Đầu vào Kết mong đợi Data: 3.1 MergeSort Partition 12345 Các tham số : Data: 3.2 MergeSort Partition 12345 Các tham số : Data: 3.3 MergeSort Partition 12345 Các tham số : Data: [] 3.4 MergeSort Partition [] Các tham số: 3.5 MergeSort Partition- Data: …2 VBA Các tham số: 32000 Hình 4.4 – Giao diện điều khiển kiểm thử thuật toán MergeSort 12347… Data: 3.6 MergeSort VBA Các tham số: Data: 3.7 MergeSort VBA 122678… Các tham số: 32001 Hình 4.5 - Kết đƣợc ghi fileLog Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 64 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 65 http://www.lrc-tnu.edu.vn 4.3.3 Kiểm thử khả thực KẾT LUẬN VÀ KIẾN NGHỊ Sau thuật toán xếp cài đặt kiểm thử đơn vị để phát lỗi, cần thực việc kiểm thử hiệu thuật toán, để kiểm tra thời gian thực thi thuật toán, số thông tin Kiểm thử phần mềm hoạt động quan trọng nhằm đảm bảo chất lượng phần mềm Vấn đề đề tài mẻ Việt Nam Việc nghiên cứu lựa chọn kỹ thuật chiến lược kiểm thử phần mềm khác số phép so sánh thực hiện, số lần hoán vị thủ phù hợp giúp cho việc kiểm thử có hiệu quả, giảm chi phí thời gian Việc xây tục có gọi đệ qui đếm số lần thủ tục gọi dựng tài liệu kiểm thử phần mềm hợp lý giúp cho việc tổ chức, quản lý thực kiểm thử có hiệu Trong khuôn khổ luận văn thạc sĩ, học viên nghiên cứu kĩ thuật chiến lược kiểm thử, từ áp dụng để thiết kế kiểm thử cho vài chương trình cụ thể Hiện vấn đề kiểm thử phần mềm chưa đầu tư quan tâm mức Và Việt Nam trình xây dựng ngành công nghiệp phần mềm xem nhẹ việc kiểm thử phần mềm xác suất thất bại cao, nữa, hầu hết công ty phần mềm có uy tín đặt yêu cầu nghiêm ngặt phần mềm tài liệu kiểm thử kèm không chấp nhận Kết nghiên cứu áp dụng thực tế cho đề tài dự án phát triển phần mềm, làm tài liệu tham khảo cho sở tiến tới đưa qui trình kiểm thử phần mềm thành qui trình bắt buộc dự án phát triển Hình 4.6 – Giao diện điều khiển kiểm thử khả thực thuật phần mềm họ toán xếp Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 66 http://www.lrc-tnu.edu.vn Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 67 http://www.lrc-tnu.edu.vn TÀI LIỆU THAM KHẢO Tiếng Việt Nguyễn Xuân Huy (1994), Công nghệ phần mềm, Đại học Tổng hợp Tp Hồ Chí Minh Nguyễn Quốc Toản (2000), Bài giảng nhập môn Công trình học phần mềm, Khoa Công nghệ - Đại học Quốc gia Hà Nội, trang 59- 63 Pressman R, Introduction to Software Engineering, Ngô Trung Việt dịch, Nhà xuất Giáo dục 1997 Tiếng Anh Beizer, B (1995), Black- box Testing, Wiley Boehm B W (1976), Software Engineering, IEEE Transactions on Computers British Standard (1998), BS 7925- - Standard for Software Component Vocabulary, British Computer Society British Standard (1998), BS 7925- - Standard for Software Component Testing, British Computer Society, p 1- 15 Cem Kaner, Jack Falk, Hung Quoc Nguyen (1999), Testing Computer Software, John Wiley & Sons, Inc., p 27- 141 Số hóa Trung tâm Học liệu – Đại học Thái Nguyên 68 http://www.lrc-tnu.edu.vn [...]... truyền cho quá trình kiểm thử:  Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã nguồn  Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp kiểm Có thể chia các kỹ thuật kiểm thử phần mềm thành hai loại: các kỹ thuật kiểm thử, và các công cụ kiểm thử thử hộp đen (black-box testing) và kỹ thuật kiểm thử hộp trắng (white-box testing) Kiểm thử sử dụng kỹ thuật hộp đen thường... Mục tiêu kiểm thử Các nguyên tắc được xem như mục tiêu kiểm thử là:  Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi  Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao việc tìm thấy các lỗi chưa từng được phát hiện CHƢƠNG 2  Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM Có thể sử dụng một số kỹ thuật. .. việc kiểm thử phần  Kiểm thử nhánh (Branch Testing): là phương pháp kiểm thử điều kiện đơn mềm Kiểm thử vòng lặp là một kỹ thuật kiểm thử hộp trắng mà tập trung trên tính hợp lệ của các cấu trúc lặp Việc xây dựng các trường hợp kiểm thử cho mỗi loại giản nhất  Kiểm thử miền (Domain Testing): cần 3 hoặc 4 kiểm thử cho biểu thức quan hệ Với một biểu thức quan hệ có dạng E1 E2, cần có 3 kiểm thử. .. kiểm thử phần  Kiểm thử phần mềm là một nhiệm vụ mang tư duy sáng tạo và tính trách mềm  Tất cả các kiểm thử phải có thể mô tả theo các yêu cầu của khách hàng  Các kiểm thử phải được lập kế hoạch từ lâu trước khi kiểm thử bắt đầu  Kiểm thử cần bắt đầu trong “phạm vi nhỏ” và quá trình hướng đến các kiểm thử trong “phạm vi rộng” nhiệm cao 3.2 Phƣơng pháp tiếp cận kiểm thử phần mềm Kiểm thử là một tập... kiểm thử phần mềm Cấu hình kiểm thử Mô hình tin cậy Kết quả mong đợi Dự đoán độ tin cậy Trong lúc kiểm thử, công nghệ phần mềm phát sinh một chuỗi các trường hợp kiểm thử được sử dụng để “tách từng phần phần mềm Kiểm thử là một bước trong qui trình phần mềm mà có thể được xem xét bởi đội ngũ phát triển bằng cách phá vỡ thay vì xây dựng Các kỹ sư phần mềm chính là những người xây dựng và việc Số hóa... của kỹ thuật kiểm thử hộp trắng  Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình đã tuân theo đặc tả  Một chương trình sai do thiếu đường dẫn Việc kiểm thử hộp trắng không thể biết được sự thiếu sót này  Việc kiểm thử bằng kỹ thuật hộp trắng không thể phát hiện được lỗi do dữ liệu 2.2 Kỹ thuật kiểm thử hộp trắng (White-Box Testing) Như vậy, việc kiểm thử chỉ dùng kỹ thuật. .. trình thì điều kiện bắt buộc là phải kiểm thử tất cả các đầu vào, tức là mỗi một điều kiện đầu vào có thể có là một trường hợp kiểm thử Bởi vì nếu chỉ kiểm thử một số điều kiện đầu vào thì không đảm bảo được chương trình đã hết 2.3 Kỹ thuật kiểm thử hộp đen (Black-Box Testing) Kỹ thuật kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data-driven) hay là kiểm thử hướng vào/ra lỗi Tuy nhiên, điều... bước kiểm thử sắp bắt đầu Mỗi phát biểu trên là không đúng Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 38 http://www.lrc-tnu.edu.vn Kiểm thử hệ thống Hình 3.1 - Chiến lƣợc kiểm thử trên: (1) người phát triển phần mềm sẽ không thực hiện một kiểm thử nào ; (2) phần mềm sẽ được “tung lên tường” để một người lạ sẽ kiểm thử nó một cách khắt khe; Kiểm thử tính hợp lệ Theo quan điểm thủ tục, kiểm thử. .. hệ giữa số lượng kiểm thử được thực hiện và số lỗi được tìm thấy Nếu chúng ta kiểm thử quá nhiều thì chi phí sẽ tăng một cách khó chấp nhận được, ngược lại nếu kiểm thử ít thì chi phí thấp, nhưng sẽ còn nhiều lỗi Số lượng kiểm thử tối ưu chỉ ra rằng chúng ta không kiểm thử quá nhiều nhưng song trên nhiều module 3.3.1 Các lý do của kiểm thử đơn vị Các kiểm thử xuất hiện như một phần của kiểm thử đơn... Các trường hợp kiểm thử Dữ liệu kiểm thử Kết quả kiểm thử Kết quả kiểm thử Hình 1.6 – Qui trình kiểm thử phần mềm + Các thủ tục quản lý V&V bao gồm các chính sách, thủ tục, các chuẩn, thực nghiệm và các qui ước  Giai đoạn bố trí nhân viên kiểm thử Việc kiểm thử thường phải tiến hành một cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat động kiểm thử, gọi là các nhóm kiểm thử  Thiết