CÁC kỹ THUẬT TRONG KIỂM THỬ DÒNG dữ LIỆU TĨNH

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ YÊN CÁC KỸ THUẬT TRONG KIỂM THỬ DÒNG DỮ LIỆU TĨNH LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM Hà Nội - 2016 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ YÊN CÁC KỸ THUẬT TRONG KIỂM THỬ DÒNG DỮ LIỆU TĨNH Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã số: 6048103 LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Đặng Văn Hưng Hà Nội - 2016 LỜI CAM ĐOAN Tôi xin cam đoan: Những kết nghiên cứu trình bày luận văn hoàn toàn trung thực, tôi, không vi phạm điều luật sở hữu trí tuệ pháp luật Việt Nam Nếu sai, hoàn toàn chịu trách nhiệm trước pháp luật TÁC GIẢ LUẬN VĂN Nguyễn Thị Yên MỤC LỤC Trang LỜI CAM ĐOAN MỤC LỤC DANH MỤC CÁC KÝ HIỆU VIẾT TẮT DANH MỤC CÁC HÌNH DANH MỤC CÁC BẢNG MỞ ĐẦU Chương 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ KIỂM THỬ TĨNH 1.1 Khái quát Kiểm thử phần mềm 1.1.1 Định nghĩa Kiểm thử phần mềm 1.1.2 Qui trình phát triển phần mềm RUP 10 1.1.3 Các mức kiểm thử phần mềm 11 1.1.4 Ca kiểm thử phương pháp thiết kế ca kiểm thử 13 1.1.5 Các ý tưởng không kiểm thử 14 1.1.6 Các hạn chế việc kiểm thử 14 1.2 Khái quát Kiểm thử tĩnh 15 1.2.1 Định nghĩa Kiểm thử tĩnh 15 1.2.2 Phân loại kỹ thuật kiểm thử tĩnh 15 1.2.3 Sơ lược kỹ thuật kiểm thử tĩnh 16 1.3 Kết luận 17 Chương 2: PHƯƠNG PHÁP KIỂM THỬ DÒNG DỮ LIỆU TĨNH TRONG KIỂM THỬ PHẦN MỀM 18 2.1 Phương pháp kiểm thử dòng liệu tĩnh 18 2.1.1 Ý tưởng phương pháp 18 2.1.2 Các vấn đề bất thường dòng liệu 19 2.1.3 Phương pháp kiểm thử dòng liệu tĩnh 22 2.2 Kết luận 34 Chương 3: ỨNG DỤNG LOGIC HOARE TRONG KIỂM THỬ PHẦN MỀM 35 3.1 Đặt vấn đề 35 3.2 Tổng quan Logic Hoare 35 3.3 Ứng dụng Logic Hoare kiểm thử phần mềm 40 3.3.1 Sơ lược kỹ thuật kiểm thử dựa kịch dòng liệu 41 3.3.2 Ký hiệu sử dụng Logic Hoare 44 3.3.3 Kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch dòng liệu - Phương pháp TBFV 45 3.4 Áp dụng phương pháp TBFV 46 3.4.1 Áp dụng cho đoạn chương trình 46 3.4.2 Áp dụng cho việc gọi phương thức 48 3.4.3 Các nghiên cứu liên quan 50 3.5 Kết luận 50 KẾT LUẬN VÀ KIẾN NGHỊ 52 Kết luận 52 Kiến nghị 52 TÀI LIỆU THAM KHẢO 53 DANH MỤC CÁC KÝ HIỆU VIẾT TẮT TT Viết tắt Đầy đủ Diễn giải Kỹ thuật chứng minh hình thức dựa kiểm thử TBFV Testing - Based Formal Verification RUP Rational Unified Process Qui trình phát triển phần mềm DU-path Definition Use path Đường dẫn định nghĩa sử dụng FSF Functional Scenario Form Hình thức kịch chức SOFL Structured ObjectOriented Formal Language Ngôn ngữ hình thức hướng đối tượng cấu trúc 5 DANH MỤC CÁC HÌNH Trang Hình 1.1: Qui trình phát triển phần mềm RUP 10 Hình 1.2: Các mức kiểm thử phần mềm 12 Hình 1.3: Minh họa Kiểm thử hộp trắng hộp đen 14 Hình 1.4: Phân loại kỹ thuật kiểm thử tĩnh 16 Hình 2.1: Tuần tự câu lệnh có vấn đề thuộc loại 19 Hình 2.2: Tuần tự câu lệnh có vấn đề thuộc loại 20 Hình 2.3: Sơ đồ chuyển trạng thái biến 21 Hình 2.4: Đồ thị dòng liệu cho chương trình Example 25 Hình 2.5: Ví dụ đường DU (DU-path) 28 Hình 2.6: Ví dụ đường dẫn – du mà đường dẫn – dc 28 Hình 2.7: Các độ đo Rapps-Weyuker 30 Hình 2.8: Đồ thị hàm Example sau phân mảnh 33 Hình 2.9: Program slice lưới 33 DANH MỤC CÁC BẢNG Trang Bảng 1.1: Tổng hợp kiểm thử hộp đen hộp trắng sử dụng mức kiểm thử 14 Bảng 2.1: Nút sử dụng nút định nghĩa cho biến totalPrice 28 Bảng 2.2: Nút sử dụng nút định nghĩa cho biến price 28 Bảng 3.1: Ví dụ kiểm thử 43 MỞ ĐẦU Chúng ta chứng kiến tăng trưởng đáng kinh ngạc ngành công nghiệp phần mềm vài thập kỷ qua Nếu trước phần mềm máy tính sử dụng để tính toán khoa học kỹ thuật xử lý liệu ngày ứng dụng vào mặt đời sống hàng ngày người, từ ứng dụng nhỏ để điều khiển thiết bị dùng gia đình thiết bị nghe nhìn, điện thoại, máy giặt, lò vi sóng, nồi cơm điện, đến ứng dụng lớn trợ giúp điều khiển phương tiện hệ thống giao thông, trả tiền cho hóa đơn, quản lý toán tài chính, Vì người ngày phụ thuộc chặt chẽ vào sản phẩm phần mềm đòi hỏi chất lượng sản phẩm phần mềm tăng, giá thành hạ, sử dụng dễ dàng, an toàn tin cậy Kiểm thử có phương pháp hoạt động thiếu quy trình sản xuất phần mềm để đảm bảo yếu tố chất lượng nêu sản phẩm phần mềm Theo thống kê việc kiểm thử tiêu tốn khoảng 50% thời gian 50% giá thành dự án phát triển phần mềm Tăng suất kiểm thử nhu cầu thiết yếu để tăng chất lượng phần mềm Từ lý nên em chọn đề tài: “Các kỹ thuật kiểm thử dòng liệu tĩnh” Mục tiêu đề tài: Nghiên cứu Tổng quan kiểm thử phần mềm để nắm kiến thức phục vụ cho nghiên cứu Sau nghiên cứu Tổng quan phương pháp kiểm thử phần mềm kiểm thử dòng liệu tĩnh Tiếp theo nghiên cứu ứng dụng Logic Hoare kiểm thử phần mềm, cụ thể: nghiên cứu kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch dòng liệu áp dụng kỹ thuật kết hợp vào kiểm thử đoạn chương trình Cấu trúc luận văn chia thành chương cụ thể sau: Chương 1: Tổng quan Kiểm thử phần mềm kiểm thử phần mềm tĩnh Trình bày khái niệm liên quan đến lĩnh vực Kiểm thử phần mềm khái niệm kiểm thử phần mềm, vai trò Kiểm thử phần mềm, mức độ kiểm thử phần mềm Đồng thời trình bày khái quát kiểm thử phần mềm tĩnh Chương 2: Phương pháp kiểm thử dòng liệu tĩnh kiểm thử phần mềm Trình bày cách phân loại kiểm thử dòng liệu tĩnh trình bày sơ lược số kỹ thuật kiểm thử dòng liệu tĩnh Chương 3: Ứng dụng Logic Hoare kiểm thử phần mềm Trình bày tổng quan Logic Hoare kỹ thuật kiểm thử dựa kịch dòng liệu Sau trình bày kỹ thuật kiểm thử phần mềm kết hợp Logic Hoare kỹ thuật kiểm thử dựa kịch dòng liệu để nâng cao hiệu cho kỹ thuật kiểm thử phần mềm dựa kịch dòng liệu Cuối ứng dụng phương pháp kết hợp vào kiểm thử đoạn chương trình Để hoàn thành luận văn, em xin gửi lời cảm ơn tới thầy cô Khoa Công nghệ thông tin - Trường Đại học Công nghệ tận tình giảng dạy, cung cấp nguồn kiến thức quý giá suốt trình học tập Đặc biệt em xin chân thành cảm ơn thầy giáo TS Đặng Văn Hưng tận tình hướng dẫn, góp ý, tạo điều kiện cho em hoàn thành luận văn 40  m – (i+1) < V Dễ dàng chứng minh: giả thiết m - i -1 < V m - (i+1) < V giả thiết định nghĩa < luật số học Cuối cần chứng minh hậu điều kiện không thay đổi thoát khỏi lặp không biến đổi Chúng ta có gợi ý điều chọn lặp không biến đổi Tuy nhiên, cần miêu tả nhiệm vụ chứng minh cách hình thức:  r = nm Chúng ta cần chứng minh sau: r = nm giả thiết thay i m theo giả thiết 3.3 Ứng dụng Logic Hoare kiểm thử phần mềm Chúng ta biết Logic Hoare sử dụng để chứng minh xác chương trình kiểm thử cách sử dụng thực tế để phát lỗi chương trình Tuy nhiên việc sử dụng Logic Hoare áp dụng thực tế kiểm thử khó phát tất lỗi xuất chương trình Do vậy, phần luận văn trình bày kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch dòng liệu để nâng cao khả phát lỗi cho kỹ thuật kiểm thử dựa kịch dòng liệu Ý tưởng kết hợp sau: sử dụng kỹ thuật kiểm thử dựa kịch dòng liệu để tìm tất đường dẫn chương trình sau sử dụng Logic Hoare để chứng minh xác tất đường dẫn chương trình Trong trình chứng minh, tất lỗi đường dẫn chương trình phát Để thuận tiện cho việc trình bày, dây luận văn trình bày dạng ký hiệu tóm tắt kỹ thuật kiểm thử dựa kịch dòng liệu Logic Hoare để làm tảng cho việc trình bày kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch dòng liệu 41 3.3.1 Sơ lược kỹ thuật kiểm thử dựa kịch dòng liệu Kỹ thuật kiểm thử dựa kịch dòng liệu phương pháp kiểm thử dựa đặc tả, sử dụng tiền điều kiện hậu điều kiện việc tạo ca kiểm thử [16] Áp dụng nguyên lý “chia trị” kỹ thuật kiểm thử dựa kịch dòng liệu coi đặc tả kịch dòng liệu tách biệt tạo tập kiểm thử phân tích kết kiểm thử dựa kịch dòng liệu Một kịch dòng liệu dạng đặc tả kiểu pre-post biểu thức logic mà thể cách rõ ràng điều kiện sử dụng để ràng buộc đầu đầu vào thỏa mãn điều kiện Cụ thể, cho S(Siv, Sov)[Spre, Spost] ký hiệu đặc tả toán tử S, Siv tập tất biến đầu vào, giá trị không thay đổi toán tử S, Sov tập tất biến đầu ra, giá trị sinh cập nhật toán tử S, Spre Spost tương ứng tiền điều kiện hậu điều kiện Đặc điểm kiểu đặc tả hậu điều kiện Spost sử dụng để miêu tả mối quan hệ trạng thái khởi tạo trạng thái cuối Chúng ta giả thiết hậu điều kiện biến ~x sử dụng để biểu thị giá trị khởi tạo biến x trước áp dụng toán tử, tức x sử dụng biểu diễn giá trị cuối x sau áp dụng toán tử Do vậy, Tất nhiên, Siv chứa tất biến đầu vào khai báo tham số đầu vào Sov gồm tất biến đầu khác khai báo tham số đầu Một chiến lược thực tế cho tạo ca kiểm thử để thực thi hành vi mong muốn tất kịch dòng liệu dẫn từ đặc tả thiết lập dựa khái niệm kịch dòng liệu Để miêu tả xác chiến lược này, cần giới thiệu kịch dòng liệu Định nghĩa 1: Cho Spost  C1  D1   C2  D2     Cn  Dn , Ci i  1,, n tiên đề, gọi “guard condition”, không chứa biến đầu Sov; Di “defining condition” mà chứa biến đầu Sov Khi đó, kịch dòng liệu fs S kết nối ~Spre  Ci  Di biểu thức (~Spre  C1  D1 )  )(~Spre  C2  D2 )    (~Spre  Cn  Dn ) ) gọi kịch dòng liệu S Tiền điều kiện ~Spre = Spre(~   ) ký hiệu kết dự đoán từ việc thay trạng thái khởi tạo ~  thành trạng thái cuối  tiền điều kiện Spre Chúng ta coi kết nối ~Spre  Ci  Di kịch dòng liệu 42 định nghĩa hành vi độc lập: ~Spre  Ci thỏa mãn trạng thái khởi tạo, trạng thái cuối (hoặc biến đầu ra) định nghĩa defining condition Di Sự kết nối ~Spre  Ci biết điều kiện kiểm thử kịch ~Spre  Ci  Di , phục vụ hệ số cho việc tạo ca kiểm thử từ kịch dòng liệu Để hỗ trợ việc tạo ca kiểm thử cách tự động từ kịch dòng liệu, bước quan trọng lấy FSF từ đặc tả có sẵn Một thủ tục chuyển có tính hệ thống, thuật toán, công cụ phần mềm hỗ trợ cho việc dẫn FSF từ đặc tả kiểu pre-post phát triển nghiên cứu [17] Tạo ca kiểm thử dựa đặc tả sử dụng phương pháp sinh ca kiểm thử dựa kịch dòng liệu thực việc tạo ca kiểm thử dựa đặc tả từ tất kịch dòng liệu phương pháp sinh ca kiểm thử dựa kịch dòng liệu Việc tạo ca kiểm thử từ kịch dòng liệu thực việc tạo ca kiểm thử từ điều kiện kiểm thử kịch dòng liệu Trong nghiên cứu [16] tập tiêu chuẩn cho việc sinh ca kiểm thử định nghĩa chi tiết Để áp dụng KỸ THUẬT DỰA VÀO KỊCH BẢN DÒNG DỮ LIỆU cách hiệu quả, FSF đặc tả phải thỏa mãn điều kiện well-formed định nghĩa Định nghĩa 2: Cho FSF đặc tả S (~Spre  C1  D1 )  (~Spre  C2  D2 )    (~Spre  Cn  Dn ) Nếu S i, j1,,n  i  j  Ci  C j  false  ( S ~ thỏa pre  mãn điều kiện C1  C2    Cn  true  ), S gọi well-formed Well-formed đặc tả S đảm bảo kịch dòng liệu định nghĩa hàm độc lập guard condition bao hoàn toàn lĩnh vực giới hạn cách đầy đủ Do vậy, đầu vào thỏa mãn tiền điều kiện, S đảm bảo để định nghĩa đầu thỏa mãn defining condition kịch dòng liệu Với giả thiết S well-formed, tập trung vào sinh ca kiểm thử từ kích chức đơn, ~Spre  Ci  Di , thời điểm sử dụng phương pháp Khi ca kiểm thử sử dụng để chạy chương trình Chúng ta sử dụng toán tử ChildFareDiscount Chức ChildFareDiscount sử dụng ngôn ngữ đặc tả SOFL [15] tương tự VDM-SL cho đặc tả toán tử Process ChildFareDiscount(a: int, n_f: int) a_f: int Pre a > and n_f > 43 Post (a > 12 => a_f == n_f) and (a  12 => a_f == n_f – n_f * 0.5) End_process Đặc tả miêu tả đầu vào a (đại diện cho age) phải lớn n_f (normal_fare) phải lớn Khi a lớn 12, đầu a_f (actual_fare) n_f; ngược lại, a_f giảm bớt 50% n_f Theo thuật toán báo cáo nghiên cứu [4], có ba kịch dòng liệu dẫn từ đặc tả này: (1) a > and n_f > and a > 12 and a_f = n_f (2) a > and n_f > and a  12 and a_f = n_f – n_f*0.5 (3) a  or n_f  and anything Bảng 3.1: Ví dụ kiểm thử Ca kiểm thử: a = 5, n_f = Điều kiện kiểm thử: a > and n_f > and a  12 Kịch dòng liệu: a > and n_f > and a  12 and a_f = n_f – n_f * 0.5 Ở anything nghĩa điều xảy tiền điều kiện bị vi phạm Giả thiết đặc tả viết lại theo chương trình (giống Java): (1) (2) (3) (4) (5) (6) (7) int ChildFareDiscount (int a, int n_f) { If (a > && n_f > 1) { if (a > 12 a_f:= n_f; else a_f:= n_f **2 – n_f – n_f *0.5; return a_f;} else System.out.println(“precondition bị vi phạm”); } Ở ký tự “:=” sử dụng toán tử gán để phân biệt từ ký tự “=” sử dụng đặc tả Hiển nhiên, dẫn đường dẫn đây: [(1)(2)(3)(5)], [(1)(2)’(4)(5)], [(1)’(6)] Trong đường dẫn [(1)(2)’(4)(5)], (2)’ nghĩa thỏa hiệp điều kiện a > 12 (tức a  12), tương tự cách hiểu áp dụng tới (1)’ đường dẫn [(1)’(6)] Chúng ta chèn thêm số khuyết phép gán a_f = n_f **2 – n_f – n_f * 0.5 (chính xác a_f = n_f – n_f * 0.5), n_f **2 nghĩa n_f mũ (tức n_f ) 44 Điểm yếu phương pháp kiểm thử tìm thấy có mặt lỗi không tìm thấy vắng mặt lỗi Ví dụ, sinh ca kiểm thử, {(a, 5), (n_f, 2)}, từ điều kiện kiểm thử a > and n_f > and a  12 kịch dòng liệu (2), minh họa Bảng 3.1 Thực thi chương trình với ca kiểm thử này, đường dẫn [(1)(2)’(4)(5)] qua Kết thực thi a_f = 2**2 – – 2*0.5 = Kết không có sẵn lỗi điều kiện kiểm thử a > and a_f > and a  12 thỏa mãn ca kiểm thử, defining condition a_f = n_f – n_f * 0.5 thỏa mãn đầu a_f = (vì = – 2*0.5  true), mà chứng minh mà ca này, chương trình thực kịch dòng liệu cách xác Nhưng đường dẫn lạ chứa lỗi Một giải pháp cho vấn đề thực thi chứng minh dựa Logic Hoare để kiểm tra đường dẫn xác với kịch dòng liệu Chứng minh xác mong muốn tự động cách hoàn toàn phép tích hợp kỹ thuật vào kỹ thuật kiểm thử dựa kịch dòng liệu Để hiểu hơn, cần giới thiệu vắn tắt tiên đề gán Logic Hoare 3.3.2 Ký hiệu sử dụng Logic Hoare Chúng ta biết, Logic Hoare xây dựng dựa logic tiên đề cung cấp tập tiên đề để định nghĩa ngữ nghĩa ngôn ngữ lập trình Với cấu trúc chương trình, hệ quả, lựa chọn lặp tiên đề cho việc định nghĩa, ngữ nghĩa định nghĩa Các tiên đề sử dụng để lý giải xác chương trình viết ngôn ngữ lập trình Cho x:= E phép gán: gán kết đánh giá biểu thức E tới biến x Tiên đề cho phép gán là: QE xx : EQ Biểu thức thể phép gán x:=E xác với post-assertion Q dẫn từ pre-assertion QE x  , kết dự đoán từ việc thay E cho tất xảy x Q Post-assertion Q biểu diễn điều kiện mà phải thỏa mãn biến x sau thực thi phép gán (phép gán coi toán tử cập nhật biến x) Để tạo post-condition Q true sau thực thi, biểu thức E phải thỏa mãn Q trước thực thi, là, QE x  true, x biểu diễn E sau thực thi 45 3.3.3 Kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch dòng liệu - Phương pháp TBFV Kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch gọi kỹ thuật chứng minh hình thức dựa kiểm thử (Testing - Based Formal Verification, viết tắt là: TBFV) Kỹ thuật TBFV kỹ thuật sử dụng để chứng minh xác đường dẫn chương trình mà đường dẫn xác định kỹ thuật dựa vào kịch dòng liệu Nguyên lý kỹ thuật TBFV gồm có ba điểm sau: - Sử dụng kỹ thuật dựa kịch dòng liệu sinh ca kiểm thử thích hợp để xác định tất đường dẫn xuất (representative paths) chương trình kiểm thử; đường dẫn sử dụng ca kiểm thử Repesentative path hình thành cách thực lặp cấu trúc if-then-else để đảm bảo phần thân lặp thực lần lặp kết thúc, cách thực tất cấu trúc khác giống hình thức gốc chúng - Cho ~Spre  Ci  Di (i = 1, …, n) ký hiệu kịch chức ca kiểm thử t sinh từ điều kiện kiểm thử ~Spre  Ci Cho p  sc1 , sc ,, sc m  đường dẫn chương trình, scj (j = 1,…, m) gọi đoạn chương trình, định (tức dự đoán), phép gán, lệnh “return”, lệnh in Giả thiết đường dẫn p sử dụng ca kiểm thử t Để chứng minh xác p với kịch dòng liệu, hình thành ba đường dẫn (path triple) {~Spre}p{Ci  Di} Bộ ba đường dẫn giống như cấu trúc ba Hoare, thay đổi thành đường dẫn đơn chương trình Điều có nghĩa tiền điều kiện ~Spre chương trình true trước đường dẫn p thực thi, hậu điều kiện Ci  Di đường dẫn p true kết thúc p - Áp dụng lặp lặp lại tiên đề phép gán (hoặc tiền đề) cung cấp cho câu lệnh liên quan khác, dẫn pre-assertion, kí hiệu ppre, để hình thành biểu thức đây: {~Spre(~x/x)} {ppre(~x/x)} p {Ci  Di(~x/x)} Ở ~Spre(~x/x), ppre(~x/x) Ci  Di(~x/x) tương ứng kết dự đoán tương ứng từ việc thay biến đầu vào ~x tương ứng cho biến đầu 46 vào x dự đoán Các thay cần thiết để loại bỏ xung đột biến đầu vào biến cập nhật bên Cuối cùng, ~Spre(~x/x)  ppre(~x/x) chứng minh có nghĩa lỗi xuất đường dẫn; ngược lại xuất lỗi đường dẫn Tiên đề cho lệnh liên quan khác định liên quan khác đưa sau: QS Q Ở S ba loại phân đoạn chương trình: lệnh định, lệnh “return” lệnh in Tiên đề miêu tả tiền điều kiện hậu điều kiện cho ba loại phân đoạn chương trình không phân đoạn chương trình thay đổi trạng thái Chúng ta gọi tiên đề tiên đề cho phân đoạn không thay đổi Chúng ta thấy ứng dụng tiên đề phép gán phân đoạn không thay đổi gồm có thao tác tay theo cú pháp, dẫn từ pre-assertion ppre(~x/x) thực cách tự động, ẩn ý chứng minh cách hình thức ~Spre(~x/x)  ppre(~x/x), viết đơn giản sau ~ Spre  ppre báo cáo này, thực cách tự động, chí với hỗ trợ chứng minh lý thuyết, phụ thuộc vào độ phức tạp ~ Spre ppre Nếu thu cách tự động đầy đủ theo ưu tiên cao nhất, chứng minh hình thức ẩn ý “thay thế” ca kiểm thử Đó là, sinh giá trị mẫu cho biến ~Spre ppre, đánh giá chúng xem ppre false ~Spre true Nếu điều true, nói đường dẫn chứng minh chứa lỗi Do kỹ thuật kiểm thử có sẵn báo [16, 19] nên không cần trình bày lại chi tiết luận văn 3.4 Áp dụng phương pháp TBFV 3.4.1 Áp dụng cho đoạn chương trình Để thử nghiệm phương pháp TBFV, đoạn tác giả luận văn trình bày nghiên cứu áp dụng phương pháp TBFV để kiểm thử chứng minh đoạn chương trình IC card system (hệ thống thẻ IC) cho JR commute train service (dịch vụ tàu điện chuyển mạch JR) Tokyo Qua thử nghiệm thấy phương pháp TBFV sử dụng hiệu phương pháp đối diện vài thách thức vài giới hạn mà cần giải nghiên cứu 47 Hệ thống thẻ IC thiết kế để cung cấp dịch vụ chức sau: (1) Điều khiển truy cập đến thoát từ trạng thái đường ray, (2) Mua vé sử dụng thẻ IC, (3) Nạp thẻ IC tiền mặt thông qua tài khoản ngân hàng, (4) Mua vé lại khoảng thời gian (thời gian tháng ba tháng) Do giới hạn thời gian, tác giả trình bày chi tiết tất cả, tác giả lấy hoạt động bên sử dụng hệ thống thẻ IC, gọi ChildFareDiscount trình bày trên, làm ví dụ để minh họa cách phương pháp TBFV áp dụng Chương trình ChildFareDiscount chứa ba đường dẫn, cần chứng minh hình thức ba đường dẫn Do trình chứng minh cho ba đường dẫn giống nên tác giả cần chứng minh đường dẫn [(1)(2)’(4)(5)], đường dẫn sử dụng ca kiểm thử {(a, 5), (n_f, 2)} Đầu tiên xây dựng ba đường dẫn: {˜a > and ˜n_f > 1} [ a > && n_f > a 12, a_f := n_f − n_f − n_f 0.5, return a_f ] { ˜a 12 and a_f = ˜n_f − ˜n_f 0.5 Ở kết thay cho biến đầu vào a n_f tương ứng pre-condition chương trình, kết hoàn thành thay post-condition Thứ hai, áp dụng lặp lặp lại tiên đề phép gán tiền đề phép gán với lệnh không thay đổi cho ba đường dẫn [(1)(2)’(4)(5)], post-condition Kết xây dựng đường dẫn đây, gọi asserted path (đường dẫn chứa thêm khẳng định), với khẳng định bên dẫn từ hai đoạn chương trình: { ˜a > and ˜n_f > 1} { ˜a 12 and ˜n_f − ˜n_f − ˜n_f 0.5 = ˜n_f − ˜n_f 0.5} a > && n_f > { ˜a 12 and n_f − n_f − n_f 0.5 = ˜n_f − ˜n_f 0.5} a 12 {˜a 12 and n_f − n_f − n_f 0.5 = ˜n_f − ˜n_f 0.5} 48 a_f := n_f − n_f − n_f 0.5 { ˜a 12 and a_f = ˜n_f − ˜n_f 0.5} return a_f {˜a 12 and a_f = ˜n_f − ˜n_f 0.5} Ở đường dẫn định 12 0.5 0.5, dòng thứ hai từ xuống, kết thay cho a cho n_f định 12 0.5 0.5 Như trình bày trên, điều cần thiết để tin cậy biến đầu vào a n_f pre-condition gốc (biểu thị ) pre-assertion Thứ ba, cần đánh giá tính hợp lý ẩn ý 12 0.5 0.5 Sử dụng ca kiểm thử , dễ dàng chứng minh ẩn ý sai (đánh giá chi tiết không đề cập giới hạn thời gian) Từ ví dụ trên, thấy kiểm thử chí hiệu chứng minh hình thức việc đánh giá tính hợp lý ẩn ý lỗi có sẵn đường dẫn, đường dẫn không chứa lỗi, kiểm thử phát để đưa kết luận Trong trường hợp này, đánh giá kỹ thuật phải tạo cho việc đánh giá tính hợp lý Điểm mạnh kiểm thử thực tự động, điều vô có ích thời đại công nghiệp 3.4.2 Áp dụng cho việc gọi phương thức Nếu gọi phương thức (method invocation) sử dụng câu lệnh, thay đổi trạng thái chương trình ChildFareDiscount Do vậy, đường dẫn bên phương thức gọi phải xem xét pre-assertion chương trình dạng kiểm thử Chúng ta thay đổi chương trình ChildFareDiscount tổ chức hoàn thiện chương trình thành lớp (class) gọi FareDiscount (1) (2) (3) (4) (5) class FareDiscount{ int tem; //instance variable int ChildFareDiscount1(int a, int n_f){ Discount(n_f); if (a > && n_f > 1){ if (a > 12) a_f := n_f else a_f := n_f **2 – n_f – tem; 49 (6) (7) return a_f; } else System.out.println(“the precondition is violated ”); } void Discount(int x){ int r; (1.1) r := x*0.5; (1.2) tem := r; } } Khi chạy phương thức ChildFareDiscount1 phương thức Discount(n_f) gọi, lấy ba đường dẫn: [(1)(2)(3)(4)(6)], [(1)(2)(3)’(5)(6)] [(1)(2)’(7)], đoạn (1) đường dẫn (subpath) [(1.1)(1.2)](n_f/x), biểu thị đường dẫn kết từ việc thay tham số thực tế n_f cho tham số hình thức x đường dẫn [(1.1)(1.2)] Do đường dẫn [(1)(2)(3)’(5)(6)] thực tế sau chèn thêm đường dẫn Discount vào đường dẫn ChildFareDiscount1 biểu diễn sau [(1.1)(1.2)(2)(3)’(5)(6)] Lựa chọn ca kiểm thử giống {(a, 5), (n_f, 2)} trước chạy chương trình, tạo đường dẫn [(1.1)(1.2)(2)(3)’(5)(6) Khi xây dựng đường dẫn asserted path sau: { ˜a > and ˜n_f > 1} { ˜a 12 and ˜n_f − ˜n_f − ˜n_f 0.5 = ˜n_f − ˜n_f 0.5} r := n_f * 0.5 {˜a 12 n_f − n_f − r = ˜n_f − ˜n_f 0.5} tem := r { ˜a 12 and n_f − n_f − tem = ˜n_f − ˜n_f 0.5} a > && n_f > { ˜a 12 and n_f − n_f − tem = ˜n_f − ˜n_f 0.5} a 12 {˜a 12 and n_f − n_f − tem = ˜n_f − ˜n_f 0.5} a_ f := n_f − n_f – tem { ˜a 12 and a_f = ˜n_f − ˜n_f 0.5} return a_ f 50 { ˜a 12 and a_ f = ˜n_f − ˜n_f 0.5} Ở đường dẫn [r:= n_f *0.5, tem:= r] kết thay tham số thực tế n_f sử dụng lời gọi phương thức Discount(n_f) cho tham số hình thức x sử dụng định nghĩa phương thức đường dẫn gốc [r:= x*0.5, tem:= r] Tương tự, dễ dàng sử dụng kiểm thử để chứng minh ẩn ý 12 0.5 0.5 sai, lỗi tìm thấy đường dẫn 3.4.3 Các nghiên cứu liên quan Qua nghiên cứu thấy nghiên cứu dựa việc tích hợp Logic Hoare kiểm thử dường tập trung chủ yếu vào sử dụng pre-assertion postassertion ba Hoare cho việc sinh ca kiểm thử phân tích kết kiểm thử nghiên cứu giống phương pháp TBFV cho việc giải toán kiểm thử dựa đặc tả Một kết đạt trình bày Design By Contract (DBC) Meyer ứng dụng ngôn ngữ lập trình Eiffel [7, 8] Thành công Eiffel kiểm tra pre-condition post-condition khuyến khích môn học DBC lập trình để phát triển nghiên cứu tương tự cho ngôn ngữ khác hệ thống kiểm thử Sunit cho Smalltalk [13] Cheon Leavens miêu tả phương pháp kiểm thử đơn vị (unit testing) mà sử dụng kiểm tra assertion thời gian chạy ngôn ngữ đặc tả hình thức để định phương thức làm việc xác theo đặc tả hình thức sử dụng pre-condition post-condition, cài đặt thành công ý tưởng sử dụng ngôn ngữ mô hình Java (Java Modeling Language – JML) tảng làm việc kiểm thử Junit [20] Gray Mycroft miêu tả phương pháp khác để kiểm thử chương trình Java sử dụng đặc tả kiểu Hoare [18] Họ trình bày cách đặc tả kiểm thử logic với post-condition nhúng vào Java cách ngôn ngữ đặc tả kiểm thử biên dịch vào Java cho việc thực thi chương trình Ngoài có nhiều kết tương tự báo nhiên thời gian có hạn nên tác giả luận văn trình bày kết tiêu biểu 3.5 Kết luận Trong chương này, tác giả luận văn trình bày phương pháp chứng minh hình thức dựa kiểm thử (TBFV) cho việc phát lỗi chương trình cách tích hợp kiểm thử dựa đặc tả Logic Hoare Nguyên tắc TBFV trước tiên sử dụng kiểm thử dựa kịch 51 dòng liệu để đưa đường dẫn chương trình hình thức kiểm thử, áp dụng phương pháp dựa Logic Hoare để chứng minh hình thức xác đường dẫn Do kỹ thuật cho kỹ thuật dựa kịch dòng liệu kỹ thuật cho chứng minh xác thực tự động nên phương pháp TBFV có ưu điểm so với chứng minh xác hình thức dựa Logic Hoare thực tự động cách xây dựng hệ thống chương trình thực tế Phương pháp có ưu điểm bật việc giảm số lượng ca kiểm thử cần thiết so với kiểm thử dựa đặc tả có sẵn Trong tập trung vào trình bày ý tưởng phương pháp TBFV ví dụ để trình bày tính hiệu bật tiện lợi báo cáo này, thử nghiệm cần xây dựng để đánh giá hiệu có tính hệ thống để so sánh với kiểm thử liên quan phương pháp chứng minh hình thức Nghiên cứu tương lai cần giải đưa công cụ hỗ trợ 52 KẾT LUẬN VÀ KIẾN NGHỊ Kết luận Từ việc nghiên cứu Tổng quan kiểm thử phần mềm kiểm thử tĩnh để nắm kiến thức sở kiểm thử phần mềm nói chung kiểm thử tĩnh nói riêng phục vụ nghiên cứu Sau đó, tác giả luận văn tiến hành nghiên cứu khái quát phương pháp kiểm thử dòng liệu tĩnh kiểm thử phần mềm Cuối tác giả nghiên cứu Logic Hoare ứng dụng Logic Hoare kiểm thử phần mềm, cụ thể tác giả trình bày phương pháp kiểm thử kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch dòng liệu để nâng cao hiệu kiểm thử kỹ thuật dựa kịch dòng liệu áp dụng phương pháp kết hợp vào kiểm thử chương trình cụ thể Như với trình nghiên cứu mặt em hoàn thành mục tiêu đề tài đưa Một số kết đạt sau: - Nắm kiến thức liên quan đến Kiểm thử phần mềm kiểm thử tĩnh; - Nắm kỹ thuật kiểm thử tĩnh phương pháp kiểm thử dòng liệu tĩnh kiểm thử phần mềm; - Hiểu Logic Hoare việc chứng minh xác chương trình nghiên cứu kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa kịch dòng liệu để nâng cao hiệu cho kỹ thuật kiểm thử dựa kịch dòng liệu - Báo cáo làm tài liệu tham khảo lĩnh vực Kiểm thử phần mềm, Kiểm thử tĩnh đặc biệt kiểm thử dòng liệu tĩnh; - Kết nghiên cứu làm tiền đề cho nghiên cứu liên quan khác Kiến nghị Với thời gian nghiên cứu ngắn lĩnh vực tiếp cận nên báo cáo số phần chưa hoàn thiện Do thời gian tới em tiếp tục nghiên cứu chuyên sâu cố gắng xây dựng chương trình kiểm thử tự động dựa vào kỹ thuật kết hợp Logic Hoare với kỹ thuật kiểm thử dựa vào kịch dòng liệu Trong trình làm luận văn, em cố gắng nhiều, nhiên không tránh khỏi thiếu sót, em mong nhận ý kiến đóng góp Thầy giáo, Cô giáo, bạn bè, đồng nghiệp để luận văn ngày hoàn thiện 53 TÀI LIỆU THAM KHẢO Tiếng Việt: [1] Phạm Ngọc Hùng, Trương Anh Hoàng Đặng Văn Hưng (2014), Giáo trình kiểm thử phần mềm Tiếng Anh: [2] Bath, G., McKay, J.: Praxiswissen Softwaretest - Test Analystund Technical Test Analyst Dpunkt, Heidelberg (2010) [3] Beck (2002), Test driven development: By example, Addison Wesley Longman Publishing Co., Inc., Boston, MA, USA [4] Fosdick Lloyd D and Osterweil Leon J (1976), Data flow analysis in software reliability, ACM Comput Surv 8, no 3, 305–330 [5] Huang J C (1979), Detection of data flow anomaly through program instrumentation, IEEE Trans Softw Eng 5, no 3, 226–236 [6] K B Gallagher and J R Lyle, “Using program slicing in software mainte-nance.,” IEEE Trans Software Eng , vol 17, no 8, pp 751–761, 1991 [7] Liggesmeyer (2009), P.: Software-Qualität: Testen, Analysieren und Ve rifizieren von Softwa re, 2nd edn Spektrum-Akademischer Verlag, Berlin [8] M Weiser, “Program slicing.,” IEEE Trans Software Eng., vol 10, no 4, pp 352–357, 1984 [9] M Weiser, “Program slicing.,” in IC SE , pp 439–449, 1981 [10] Majchrzak, T.A., Kuchen, H.: IHK-Projekt Softwaretests: Auswertung In: Working Pa pers, Vol Förderkreis der Angewa ndten Informatik an der Westfälischen Wilhelms-Universität, Münster e V (2010) [11]Michael Kart (2012), Behavior-driven development: conference tutorial, J Comput Sci.Coll 27, no 4, 75–75 [12] P C Jorgensen, Software Testing: A Craftsman’s Approach CRC Press, 2nd ed., 2002 [13] Pezze, M., Young, M.: Software Testing and Analysis: Process, Principles and Techniques Wiley, New York (2007) 54 [14] Roitzsch, E H.P.: Analytische Softwarequalitätssicherung in Theorie und Praxis: Der Wegzur Software mit hoher Qualität durch statisches Prüfen, dynamisches Testen, formales Beweisen Monsensteinund Vannerdat (2005) [15] S.Liu (2004), Formal Engineering for Industrial Software Development Using the SOFL Method Springer-Verlag, ISBN 3-540-20602-7 [16] S Liu and S Nakajima (2010), A Decompositional Approach to Automatic Test Case Generation Based on Formal Specifications In 4th IEEE International Conference on Secure Software Integration and Reliability Improvement (SSIRI 2010), pages 147 {155, Singapore, June 9-11 2010 IEEE CS Press} [17] S Liu, T Hayashi, K Takahashi, K Kimura, T Nakayama, and S Nakajima (2010), Automatic Trans-formation from Formal Specifications to Functional Scenario Forms for Automatic Test Case Genneration In 9th International Conference on Software Methodologies, Tools and Techniques (SoMet 2010), page to appear, Yokohama city, Japan, Sept 29- Oct 2010 IOS International Publisher [18] S Rapps and E J Weyuker, “Selecting software test data using data flow information.,” IEEE Trans Software Eng , vol 11, no 4, pp 367–375, 1985 [19] S.Liu and S.Nakajima (2011), A "Vibration" method for Automatically Generating Test Cases Based on Formal Specifications In 18th Asia-Pacific Software Engineering Conference (APSEC 2011), pages 73{80, HCM City, Vietnam, Dec 5-8 2011 IEEE CS Press [20] Shaoying Liu, “Utilizing Hoare Logic to Strengthen Testing for Error Detection in Programs” [21] Sneed, H.M., Winter, M.: Testen Objektorientierter Software Hanser, München (2002) [22] Zeller, A.: Why Programs Fail: A Guide to Systematic Debugging Morgan Kaufmann, San Francisco (2006) ... trình cho phép người kiểm thử sử dụng kỹ thuật kiểm thử dòng liệu tĩnh Các kỹ thuật kiểm thử dòng liệu tĩnh trình bày đoạn  Kiểm thử định nghĩa/sử dụng (Define/Use Testing) Kiểm thử Define/Use sử... yếu kiểm tra tính đắn code (mã lệnh), thuật toán hay tài liệu 1.2.2 Phân loại kỹ thuật kiểm thử tĩnh Các kỹ thuật kiểm thử tĩnh không tạo ca kiểm thử không chạy chương trình kiểm thử [17] Các kỹ. .. tác giả luận văn trình bày sơ lược số kỹ thuật kiểm thử phần mềm thuộc nhóm kỹ thuật kiểm thử tĩnh 1.2.3 Sơ lược kỹ thuật kiểm thử tĩnh Các kỹ thuật kiểm thử tĩnh xem xét chương trình thời điểm