Phân tích must may để kiểm tra chương trình

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC BÁCH KHOA - LÊ THỊ NHẬT VĂN PHÂN TÍCH MUST-MAY ĐỂ KIỂM TRA CHƯƠNG TRÌNH Chuyên ngành: KHOA HỌC MÁY TÍNH LUẬN VĂN THẠC SĨ GVHD: TS Quản Thành Thơ TP HỒ CHÍ MINH, tháng 07 năm 2012 CƠNG TRÌNH ĐƢỢC HỒN THÀNH TẠI TRƢỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC QUỐC GIA TP HCM Cán hư ớng dẫn khoa học : TS QUẢN THÀNH THƠ Cán chấm nhận xét : Cán chấm nhận xét : Luận văn thạc sĩ bảo vệ Trường Đại học Bách Khoa, ĐHQG Tp HCM, ngày tháng năm 2012 Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm: (Ghi rõ họ, tên, học hàm, học vị Hội đồng chấm bảo vệ luận văn thạc sĩ) Xác nhận Chủ tịch Hội đồng đánh giá LV Trưởng Khoa quản lý chuyên ngành sau luận văn sửa chữa (nếu có) Chủ tịch Hội đồng đánh giá LV Phân tích MUST-MAY để kiểm tra chương trình Trƣởng Khoa ĐẠI HỌC QUỐC GIA TP.HCM TRƢỜNG ĐẠI HỌC BÁCH KHOA CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập - Tự - Hạnh phúc NHIỆM VỤ LUẬN VĂN THẠC SĨ Họ tên học viên: LÊ THỊ NHẬT VĂN MSHV: 09070477 Ngày, tháng, năm sinh: 10/06/1984 Nơi sinh: Đồng Nai Chuyên ngành: Khoa học Máy Tính Mã số : I TÊN ĐỀ TÀI: Phân tích MUST-MAY để kiểm tra chương trình II NHIỆM VỤ VÀ NỘI DUNG: Nhiệm vụ luận văn : Nghiên cứu xây dựng hệ thống sinh logic test-case dựa kỹ thuật slicing cho chương trình viết ngôn ngữ HIP Nội dung : Tìm hiểu kỹ thuật phân tích MUST MAY kết hợp phương pháp để kiểm tra chương trình Tìm hiểu separation logic cơng cụ HIP/sleek - công cụ hiệu quả.để kiểm tra chương trình dựa trỏ Tìm hiểu kỹ thuật concolic testing Xây dựng hệ thống sinh logic test-case dựa kỹ thuật concolic testing cho chương trình dựa trỏ Tìm hiểu kỹ thuật slicing áp dụng kỹ thuật slicing để hỗ trợ trình phát lỗi cải tiến trình sinh test-case hệ thống III NGÀY GIAO NHIỆM VỤ : 05/02/2011 Phân tích MUST-MAY để kiểm tra chương trình IV NGÀY HỒN THÀNH NHIỆM VỤ: 02/07/2012 V CÁN BỘ HƢỚNG DẪN: TS Quản Thành Thơ Tp HCM, ngày 02 tháng 07 năm 2012 CÁN BỘ HƢỚNG DẪN (Họ tên chữ ký) CHỦ NHIỆM BỘ MÔN ĐÀO TẠO (Họ tên chữ ký) TRƢỞNG KHOA….……… (Họ tên chữ ký) Phân tích MUST-MAY để kiểm tra chương trình LỜI CẢM ƠN Tôi xin chân thành cảm ơn TS Quản Thành Thơ, người thầy tận tình hướng dẫn tơi thực đề tài Tôi xin chân thành cảm ơn thầy kiến thức thầy truyền đạt quan tâm giúp đỡ thầy trình thực luận văn Xin chân thành cảm ơn quý thầy cô Khoa Khoa học Kỹ thuật Máy Tính trường Đại học Bách Khoa Tp HCM cung cấp cho kiến thức tảng giúp hoàn thành luận văn Xin chân thành cảm ơn tác giả tài liệu tham khảo sử dụng trình thực đề tài Mặc dù có nhiều cố gắng nhiên đề tài chắn khơng thể tránh khỏi thiếu sót Rất mong nhận đóng góp, phê bình q thầy cơ, bạn bè để đề tài hoàn chỉnh Tp HCM, ngày 02 tháng 07 năm 2012 Phân tích MUST-MAY để kiểm tra chương trình ABSTRACT Testing based on test-case is still a primary way to check software bugs today White-box testing using program flow analysis currently is attracting much attention in both industry and academic communities due to its capacity of automatic test-case generation To reduce the high cost of path exploration, the concolic testing technique is recommended, which combines symbolic execution with concrete execution during test-case generation process However, for heap-manipulation programs, where pointers are commonly used, the test-cases generated by typical concolic approach are not sufficient to cover all of necessary checking cases The reason is that the concolic approach does not take into account the specification of shared mutable data structures Moreover, for large programs, the cost for covering all the paths is very expensive Thus, slicing technique originally defined as program decomposition techniques based on extracting statements relevant to a computation in a program is useful to deal with this limitation We don’t need to explore all the paths of program but still make sure to generate the test-cases that cover all possible errors affecting a program's output In this research, taking advantage of the capacity of separation logic on describing semantics of heap-based program, we develop a framework of slicingbased test-case generation on heap-manipulation programs In doing so, we extend the concolic approach by combining data specification with control flow when symbolically executing the program Slicing technique is combined on the fly to lower the number of test-cases if could The test-cases to be generated are represented by separation formulae, thus regarded as logic test-case Phân tích MUST-MAY để kiểm tra chương trình TÓM TẮT Ngày nay, kiểm thử phần mềm dựa test-case kỹ thuật phổ biến lĩnh vực kiểm tra phần mềm (software verification) để tìm lỗi chương trình Kỹ thuật kiểm tra hộp trắng (white-box testing) dựa việc phân tích luồng thực thi chương trình cách sử dụng chủ yếu môi trường giáo dục công nghiệp Tuy nhiên, kiểm tra hộp trắng dẫn đến việc bùng nổ trạng thái dựa vào số lệnh rẽ nhánh chương trình Để khắc phục nhược điểm này, kỹ thuật concolic testing xem phương pháp hiệu việc làm giảm số lần duyệt qua đường thực thi chương trình mà đảm bảo sinh đủ test-case để phát lỗi Tuy nhiên, chương trình thao tác heap, chủ yếu sử dụng trỏ, test-case sinh kỹ thuật concolic testing không đảm bảo phủ tất trường hợp cần kiểm tra Điều phương pháp không sử dụng thông tin phần đặc tả cấu trúc liệu để kiểm tra tất trường hợp xảy cấu trúc liệu Trong trình nghiên cứu, dựa vào ngữ nghĩa separation logic áp dụng cho việc suy luận cho chương trình thao tác heap, đề tài đề xuất phương pháp xây dựng hệ thống sinh test-case hoàn chỉnh cho chương trình thao tác heap Đề tài mở rộng kỹ thuật concolic testing việc kết hợp phần đặc tả cấu trúc liệu từ chương trình nguồn với luồng thực thi (control flow) chương trình bước thực thi symbolic kỹ thuật concolic testing Hơn để cải tiến việc sinh số test-case hiệu hỗ trợ trình debug phát lỗi, hệ thống kết hợp kỹ thuật slicing đồng thời với trình sinh test-case để xây dựng hệ thống sinh test-case hồn thiện Phân tích MUST-MAY để kiểm tra chương trình LỜI CAM ĐOAN Tơi xin cam đoan luận văn tốt nghiệp cơng trình nghiên cứu thực cá nhân, thực sở nghiên cứu lý thuyết kiến thức cá nhân hướng dẫn khoa học TS Quản Thành Thơ Các số liệu kết luận văn trung thực, chưa công bố hình thức trước trình bảo vệ Hội Đồng đánh giá luận văn tốt nghiệp Thạc sĩ Một lần nữa, xin khẳng định trung thực lời cam kết Phân tích MUST-MAY để kiểm tra chương trình MỤC LỤC  NHIỆM VỤ LUẬN VĂN THẠC SĨ LỜI CẢM ƠN ABSTRACT TÓM TẮT LỜI CAM ĐOAN MỤC LỤC MỤC LỤC BẢNG 11 MỤC LỤC HÌNH 12 Chƣơng Giới thiệu 13 1.1 Tổng quan đề tài 13 1.2 Mục tiêu nghiên cứu luận văn 15 1.3 Đóng góp luận văn 16 1.4 Cấu trúc luận văn 16 Chƣơng Các kiến thức tảng 17 2.1 Separation logic 17 2.1.1 Tổng quan separation logic 17 2.1.2 Ngữ nghĩa separation logic 17 2.2 HIP 26 2.2.1 Tổng quan HIP 26 2.2.2 Kiến trúc hệ thống HIP 27 Phân tích MUST-MAY để kiểm tra chương trình 2.2.3 Ngôn ngữ đặc tả HIP 28 2.2.4 Cơ chế kiểm tra tự động HIP 29 2.2.5 Mơ tả chƣơng trình input HIP 30 2.3 Kỹ thuật concolic testing 34 2.4 Kỹ thuật slicing 36 2.4.1 Kỹ thuật static slicing 36 2.4.2 Kỹ thuật dynamic slicing 38 2.4.3 Kỹ thuật relevant slicing 40 Chƣơng Hệ thống sinh logic test-case dựa kỹ thuật slicing 45 3.1 Các tiền đề 45 3.2 Hệ thống sinh logic test-case hoàn chỉnh 48 Chƣơng Cở sở lý thuyết hệ thống sinh logic test-case dựa kỹ thuật slicing 4.1 54 Các giải pháp cho chế Slicing 54 4.1.1 Vấn đề bí danh 55 4.1.2 Vấn đề truy xuất thuộc tính cấu trúc liệu 57 4.2 Các giải pháp cho kỹ thuật sinh logic test-case 58 4.2.1 Luật mở rộng (Expansion rules) 59 4.2.2 Luật phục hồi test-case (Restoration rules) 62 Chƣơng Hiện thực hệ thống sinh logic test-case dựa slicing 64 5.1 Tổng quan hệ thống 64 5.2 Xây dựng thành phần hệ thống 64 5.2.1 Module Slicing 64 5.2.2 Module sinh test-case 66 Phân tích MUST-MAY để kiểm tra chương trình 60 sang pure logic, định nghĩa hai function Store Store0, trình bày hình 4.1 Mục đích tập luật để suy diễn thêm công thức hợp lý từ công thức ban đầu isData (c) Store( p :: c(v * )) Store0 ( p :: c(v * )) (1) is Pr edicate (c) c(v * ) Store ( p :: c(v * )) [ p / self ] Store0 ( ) isData(c) f : vf * * v r where f ( p.v f ) * r Store0 ( p :: c(v )) Store0 ( ) Store0 ( * ) vr (3) f is Pr edicate (c) Store0 (p :: c(v*r )) p :: c(v*r ) Store0 ((  )* ) (2) (4) (5) (Store0 ( )  Store0 ( ))* (6) Store0 ( )  Store0 ( ) (7) Hình 4.1: Luật lưu trữ liệu Ví dụ 4.1 Xét cơng thức = x::ll vị từ ll = (self = null * q::ll) Gọi phần thân định nghĩa vị từ ll, n = 0) (self::node = (self = null n = 0) (self::node * q::ll) Áp dụng hàm Store0 lên Store0 ( , có: ) = Store0 (self = null = (self = null n = 0) = (self = null n = 0) Store0 (self::node * q::ll) [Store0 (self::node) n = 0) [(self.val = _ Store0 (q::ll)] self.next = q) (q::ll)] [ p / self ]Store0 ( ) biểu diễn phép thay self p cơng thức Store0 ( ) Phân tích MUST-MAY để kiểm tra chương trình 61 Vì vậy, Store (x::ll) = [x/self] Store0 ( = (x = null n = 0) [(x.val = _ ) x.next = q) (q::ll)] (1) Kết (1) đạt từ bước Store có dạng đệ quy vị từ ll định nghĩa đệ quy Sau đó, tiếp tục sử dụng luật thay (substitution rule) bước để thu công thức mở rộng cuối 4.2.1.2 Luật thay (Substitution Rule-SR) Nếu kết hàm Store có dạng đệ quy, áp dụng luật thay Substitution Rule để suy diễn công thức mở rộng Luật thay Substitution Rule định nghĩa sau: p q q :: c(v*) p :: c(v*) Hình 4.2: Luật thay Giả sử xác định nơi vị từ đệ quy (tức nơi vị từ gọi lại thân vị từ) Sau áp dụng hàm Store cho công thức heap x:: c(vx*), có: Store(x:: c(vx*)) =  (  ) * với =  (q::c(vq*) )* Vì vị từ c(v*) có dạng well-founded [ ] (được định nghĩa HIP), q tiến đến từ x Bây điều cần q phải có khả truy xuất trực tiếp từ x, có nghĩa q phải thuộc tính (field) x Để suy luận điều này, áp dụng luật thay SR q truy xuất trực tiếp từ x Ví dụ 4.2 Xét ràng buộc bảng 4.7, x::ll n>0 x.next = null Như nói trước đây, ràng buộc phải bao gồm công thức x.next::ll với vị từ ll định nghĩa đệ quy Từ kết ví dụ 4.1, có Store(x::ll) = (x = null n = 0) [(x.val = _ x.next = q) (q::ll)] Ta thấy, q truy xuất trực Phân tích MUST-MAY để kiểm tra chương trình 62 tiếp từ x, áp dụng luật thay Substitution Rule SR sau x.next q q :: ll n x.next :: ll n Chúng ta có x.next::ll, lúc x.next truy xuất trực tiếp từ x, ngừng áp dụng luật thay thế, ràng buộc x::ll null n>0 x.next = x.next::ll sinh việc thêm công thức suy diễn x.next::ll vào ràng buộc ban đầu 4.2.1.3 Luật đệ quy (Recursive Rule-RR) Trong vài trường hợp phức tạp hơn, ràng buộc kết hợp tạo không đơn giản chứa công thức x.next mà chứa x.next.next, x.next.next.next, … Vì vậy, cần suy diễn x.next.next::ll, x.next.next.next::ll,…Luật đệ quy Recursive Rule RR giúp ta giải vấn đề Giả sử ta có khai báo liệu sau d(vd*) có p :: c(v * ) p.vd :: c(u * ) với vd thuộc tính (field) khai báo liệu d(vd*) Gọi gi ánh xạ từ miền giá trị vi (d(vi)) đến miền giá trị ui (d(ui)) với gi(vi) = ui, i Chúng ta phát biểu luật đệ quy RR sau: Recursive Rule RR p :: c(v * ) p.vd :: c(u * ) g i : g i (vi ) p.vd vd :: c(( g i (u i ))* ) ui , i Hình 4.3: Luật đệ quy Ví dụ 4.3: Ở ví dụ 4.2, sau áp dụng luật thay SR, có x.next::ll Mặt khác, ban đầu có x::ll Áp dụng luật đệ quy RR với ánh xạ g xác định g(x) = x-1, thu x.next.next::ll Tiếp tục áp dụng luật đệ quy RR, ta dễ dàng suy luận x.next.next.next::ll,… cần thiết 4.2.2 Luật phục hồi test-case (Restoration rules) Bước cuối trình sinh test-case khôi phục test-case từ pure logic sang separation logic Luật phục hồi Restoration Rule đề xuất dựa Phân tích MUST-MAY để kiểm tra chương trình 63 heuristic Q trình phục hồi bao gồm hai bước sau: Bƣớc 1: Gọi ràng buộc ban đầu dạng separation logic Chúng ta xác đinh vị từ separation logic = p::c(v*) Sau lưu trữ dạng c (p, p1,…, pi) với pj, (j = i ) tham số vị từ c(v*) Ví dụ 4.4 Xét ràng buộc Listing 4, = null Chúng ta xác định vị từ 1= x::ll n>0 = x::ll Vì vậy, lưu trữ x.next dạng ll(x, n) Bƣớc 2: Gọi test-case dạng pure logic sau chuyển đổi Thay biến pi cấu trúc lưu trữ bước bỏi giá trị tương ứng pi pure test-case Ví dụ 4.5 Giả sử pure test-case sinh =x=2 x.next = n = Từ ví dụ 4.4, có ll(x, n) Thay giá trị biến tương ứng vào ll(x, n) ta ll(x, n) = [2/n] ll(x, n) = ll(x, 2), từ kết khơi phục lại thành logic test-case x::ll Phân tích MUST-MAY để kiểm tra chương trình 64 Chƣơng Hiện thực hệ thống sinh logic test-case dựa slicing 5.1 Tổng quan hệ thống Chương trình bày trình thực hệ thống sinh test-case dựa kỹ thuật slicing Như đề cập chương 3, framework hồn chỉnh cho hệ thống trình bày hình 3.1 Framework bao gồm modules chính, module slicing module sinh test-case Module Slicing thực nhiệm vụ sinh tập slice test-case tương ứng, đồng thời tạo điều kiện đường dẫn (path condition) tương ứng với test-case để cung cấp cho module sinh test-case Module sinh test-case sử dụng điều kiện đường dẫn nhận từ module slicing để thực bước cần thiết để sinh testcase tương ứng 5.2 Xây dựng thành phần hệ thống 5.2.1 Module Slicing Module slicing gồm có thành phần mơ tả chương 3: Bộ tính tốn Đồ thị phụ thuộc chương trình Tập biểu diễn Defined/Used (PDG & Defined/Use Calculator): dựa source code chương trình, thành phần xây dựng đồ thị phụ thuộc dạng biểu diễn Defined/Used tương ứng với chương trình Bộ giả lập thực thi chương trình (Execution simulator): chạy giả lập chương trình với input test-case cụ thể, cho kết lịch sử thực thi (execution history) tương ứng với test-case Phân tích MUST-MAY để kiểm tra chương trình 65 Bộ thực thi giải thuật Relevant slicing (Relevant slicing algorithm): nhận PDG dạng biểu diễn Defined/Used chương trình (từ Bộ tính tốn Đồ thị phụ thuộc chương trình Tập biểu diễn Defined/Used) lịch sử thực thi chương trình ứng với test-case cho trước (từ Bộ giả lập thực thi chương trình) làm input Bộ thực thi giải thuật Relevant slicing áp dụng giải thuật relevant slicing để sinh tập slice tương ứng, đồng thời tạo điều kiện đường dẫn cung cấp cho module sinh test-case Source code AST Converter AST PDG & D/U Calculator Slice Set PDG & D/U Relevant Slicing Test-case Execution Simulator Execution History Path Condition Hình 5.1: Hiện thực chi tiết module Slicing Tuy nhiên, để xây dựng Đồ thị phụ thuộc chương trình Tập biểu diễn Defined/Used từ source code chương trình, hệ thống trước tiên thực chuyển đổi trung gian để biến đổi mã nguồn dạng ngôn ngữ HIP thành cú pháp trừu tượng-AST Cây AST dùng làm input để tạo đồ thị phụ thuộc chương trình PDG tập biểu diễn Defined/Used Cũng dựa vào AST này, mô chạy giả lập chương trình AST từ test-case input, kết thu tập dòng lệnh thực thi với input tương ứng hay gọi lịch sử thực thi chương trình Bộ chuyển đổi chương trình thành AST tạo grammar cho ngơn ngữ HIP, sau chuyển mã nguồn chương trình thành AST Phân tích MUST-MAY để kiểm tra chương trình 66 Duyệt AST thực dựa mẫu thiết kế Visitor Pattern Các thành phần PDG & Defined/Use Calculator, Execution simulator, Relevant slicing algorithm thực module chức gồm nhiều lớp chức thực nhiệm vụ mô tả Module Relevant Slicing mở rộng đồ thị PDG thành đồ thị EPDG (Extended Program Dependence Graph) cách thêm vào đồ thị PDG cạnh phụ thuộc điều kiện (conditional dependence edge) Giải thuật Relevant Slicing dựa vào đồ thị EPDG lịch sử thực thi chương trình (Execution History) để tính tốn phụ thuộc tiềm ẩn (Potential Dependence) sau tiến hành Slice chương trình Module Slicing đồng thời tạo điều kiện đường dẫn (path condition) từ lịch sử thực thi (execution history) Điều kiện đường dẫn dùng làm đầu vào cho module sinh test-case 5.2.2 Module sinh test-case Module sinh test-case bao gồm trình chủ yếu sau: Kết hợp ràng buộc (Constraint Combination): Quá trình thực kết hợp phần đặc tả (mà cụ thể tiền điều kiện hàm) với điều kiện đường dẫn (path conditions) chương trình nhận từ module slicing để tạo ràng buộc kết hợp (combined constraints) Chuyển đổi sang pure logic (Pure Logic Conversion): Phần thực chuyển ràng buộc kết hợp bước Kết hợp ràng buộc thành công thức dạng pure logic Kết bước tạo ràng buộc dạng pure logic, cịn gọi pure constraints Vì việc chuyển đổi từ công thức dạng separation logic sang pure logic đắn (sound) khơng hồn tồn (complete), đề xuất tập luật gọi Luật Mở rộng (expansion rules) Tập luật suy diễn từ phần đặc tả cấu trúc liệu sử dụng chương trình mơ tả chi tiết chương Phân tích MUST-MAY để kiểm tra chương trình 67 Sinh pure test-case (Pure Test-case Generation): Ở bước này, sử dụng prover để giải ràng buộc dạng pure logic, sinh test-case tương ứng dạng pure logic (còn gọi pure test-case) Phục hồi test-case (Test-case Restoration): Quá trình phục hồi pure test-case bước thành logic test-case dạng separation logic Quá trình sử dụng luật restoration rules trình bày chi tiết chương Hiện thực tập luật mở rộng (expansion rules) tập luật phục hồi (restoration rules) để giúp trình suy diễn qua bước sinh test-case bước sinh test-case bao gồm Kết hợp ràng buộc, Chuyển đổi sang pure logic, Sinh pure test-case, Phục hồi test-case thực gồm class chức thực nhiệm vụ mô tả Module Test-case Generation sau nhận Path Condition reindex lưu vào danh sách đường dẫn duyệt qua Sau điều kiện đường dẫn phủ định điều kiện cuối, đồng thời bỏ vào Stack phần Path Condition chưa phủ định Sau kiểm tra điều kiện duyệt qua chưa dựa vào danh sách đường dẫn duyệt qua lưu lại Nếu đường dẫn chưa duyệt qua, đưa vào Solver Z3 để sinh test-case tương ứng Ngược lại, lấy từ stack điều kiện đường dẫn tiếp tục đưa vào Z3 cho trình sinh test-case Kết xử lý để tạo test-case Nếu khơng có test-case sinh tiếp tục lấy Path Condition đỉnh Stack, phủ định đưa vào Z3 Khi stack điều kiện đường dẫn rỗng, nghĩa không đường thực thi nào, hệ thống dừng Phân tích MUST-MAY để kiểm tra chương trình 68 Chƣơng Kết thực nghiệm đánh giá Ở chương này, luận văn trình bày kết thực nghiệm hệ thống xây dựng để thấy ưu, nhược điểm hệ thống từ có hướng phát triển 6.1 Các điều kiện thử nghiệm Hệ thống chạy thử nghiệm benchmark input HIP, gồm file định nghĩa cấu trúc liệu danh sách liên kết (linked list), stack, queue, …Ngồi ra, luận văn cịn thực chuyển số benchmark tool làm việc cấu trúc liệu Smallfoot, Slayer sang dạng input hệ thống HIP để tiến hành thử nghiệm Mỗi cấu trúc liệu định nghĩa nhiều hàm (function) thao tác cấu trúc liệu đó, ví dụ cấu trúc liệu danh sách liên kết thường có hàm hàm append để nối danh sách liên kết với thành danh sách cuối cùng, hàm insert, delete để thêm hay xóa phần tử từ danh sách, hàm create_list để tạo danh sách liên kết từ node cho trước, hàm reverse thực đảo phần tử danh sách liên kết Thêm vào đó, tool Smallfoot cung cấp thêm số hàm để duyệt qua phần tử danh sách, hàm copy để copy danh sách nguồn sang danh sách đích, hàm filter để xóa phần tử, … Ngoài ra, luận văn tạo số chương trình, hàm sử dụng vịng lặp while để kiểm tra q trình sinh test-case HIP khơng thể thực verify chương trình có vịng lặp mà khơng đặc tả tiền hậu điều kiện cho vịng lặp 6.2 Kết thử nghiệm Với benchmark trên, hệ thống sinh test-case đảm bảo phủ đường thực thi chương trình để giúp phát lỗi Hệ thống trích xuất tập slice gồm tập lệnh phản ánh ảnh hưởng đến kết chương trình mà quan tâm Hệ thống sinh tập test-case cho chương Phân tích MUST-MAY để kiểm tra chương trình 69 trình có sử dụng vịng lặp while mà HIP thực verify không đặc tả tiền hậu điều kiện cho vòng lặp Tuy nhiên, hệ thống giới hạn việc suy diễn chương trình input có cấu trúc liệu đơn giản linked list, stack, queue,… Đối với cấu trúc liệu phức tạp cân avl, hay binary heap, hệ thống chưa thể suy diễn thơng tin cách xác từ phần định nghĩa vị từ cấu trúc liệu từ ngơn ngữ HIP Cần cải tiến hệ thống để suy diễn cách tổng quát chương trình input sử dụng cấu trúc liệu phức tạp Vì kỹ thuật slicing slice chương trình ban đầu thành tập dịng code nhỏ có ảnh hưởng đến kết quan tâm, giảm số lượng test case sinh Tuy nhiên, để giảm số lượng test case chương trình sau slice phải giảm số lượng control-flow (hay lệnh rẽ nhánh chương trình) Việc xảy function thực song song hay nhiều nhiệm vụ khơng liên quan Vì vậy, phần áp dụng kỹ thuật slicing chủ yếu để hỗ trợ debug, tức trích xuất tập slice gồm dịng lệnh ảnh hưởng đến kết cần quan tâm Còn vấn đề hỗ trợ để giảm số lượng test-case trình sinh test-case hệ thống thực được, nhiên chương trình thử nghiệm (benchmark) chủ yếu hàm thực nhiệm vụ đơn (tức không thực hay nhiều nhiệm vụ song song function), kết thực nghiệm chưa thấy rõ tính ứng dụng kỹ thuật slicing vào việc giảm số lượng test-case sinh Phân tích MUST-MAY để kiểm tra chương trình 70 Chƣơng 7.1 Tổng kết Tổng kết  Luận văn đặt mục tiêu sau : Tìm hiểu kỹ thuật phân tích MUST MAY kết hợp phương pháp để kiểm tra chương trình Tìm hiểu separation logic cơng cụ HIP/sleek - cơng cụ hiệu quả.để kiểm tra chương trình dựa trỏ Tìm hiểu kỹ thuật concolic testing Xây dựng hệ thống sinh logic test-case dựa kỹ thuật concolic testing cho chương trình dựa trỏ Tìm hiểu kỹ thuật slicing áp dụng kỹ thuật slicing để hỗ trợ trình phát lỗi cải tiến trình sinh test-case hệ thống  Đóng góp luận văn Luận văn hồn thành mục tiêu đề ra, tìm hiểu kỹ thuật kiểm tra chương trình, từ xây dựng hệ thống sinh logic test-case cho chương trình thao tác trỏ Đề tài tập trung nghiên cứu kỹ thuật phân tích MUST, mà điển hình kỹ thuật concolic testing, để phát lỗi xảy chương trình (nếu có) Kết hệ thống tập test-case hiệu (số lượng test-case nhỏ nhất) đảm bảo độ bao phủ đường thực thi nhằm phát lỗi chương trình Để thực điều này, luận văn kết hợp kỹ thuật slicing để hỗ trợ trình phát lỗi cải tiến trình sinh testcase hệ thống Trong trình thực hệ thống, luận văn phát triển tập luật để hỗ trợ trình sinh test-case cho chương trình input viết ngơn ngữ HIP Song song đó, áp dụng kỹ thuật concolic testing chương trình thao tác trỏ, luận văn đề xuất cách khắc phục Phân tích MUST-MAY để kiểm tra chương trình 71 số vấn đề thường xảy làm việc với chương trình có trỏ, ví dụ vấn đề bí danh vấn đề truy xuất thuộc tính cấu trúc liệu Với cải tiến này, tập slice trích xuất cho kết xác Trong q trình thực hiện, đề tài đóng góp báo nghiên cứu sau : Le Thi Nhat Van, Quan Thanh Tho, Logic test-case generation for heapmanipulation programs, In Proceedings of International Conference on Advanced Computing and Applications (ACOMP), Ho Chi Minh City, Vietnam, 2011  Những hạn chế luận văn Bên cạnh đóng góp nói trên, luận văn số hạn chế: Hệ thống giới hạn việc suy diễn chương trình input có cấu trúc liệu đơn giản linked list, stack, queue,… Đối với cấu trúc liệu phức tạp cân avl, hay binary heap, hệ thống chưa thể suy diễn thông tin cách xác từ phần định nghĩa vị từ cấu trúc liệu từ ngôn ngữ HIP Phần áp dụng kỹ thuật slicing chủ yếu để hỗ trợ debug, tức trích xuất tập slice gồm dòng lệnh ảnh hưởng đến kết cần quan tâm Còn vấn đề hỗ trợ để giảm số lượng test-case trình sinh test-case hệ thống thực được, nhiên chương trình thử nghiệm (benchmark) chủ yếu hàm thực nhiệm vụ đơn (tức không thực hay nhiều nhiệm vụ song song function), kết thực nghiệm chưa thấy rõ tính ứng dụng kỹ thuật slicing vào việc giảm số lượng test-case sinh Phân tích MUST-MAY để kiểm tra chương trình 72 7.2 Hƣớng phát triển Dựa vào đóng góp hạn chế đề tài, để cải tiến hệ thống thành framework sinh test-case hoàn chỉnh hơn, hướng nghiên cứu sau đề xuất: Cần xây dựng tập luật, hay văn phạm tổng quát hoàn chỉnh để hệ thống suy diễn cách xác chương trình input có khai báo cấu trúc liệu phức tạp Hoặc đề xuất cách tiếp cận khả quan Để hệ thống mang tính ứng dụng cao hơn, cần phát triển chức lỗi sai từ tập slice cách trực quan, thân thiện gần gũi với người dùng Phân tích MUST-MAY để kiểm tra chương trình 73 Tài liệu tham khảo [1] P Godefroid, N Klarlund, K Sen, DART: Directed Automated Random Testing, In Programming Language Design and Implementation, pp 213-223 ACM, 2005 [2] C Cadar, V Ganesh, P M Pawlowski, D L Dill, and D R Engler, EXE: Automatically generating inputs of death, In CCS’06: Computer and Communications Security Conference, pp 322-335, 2006 [3] P Godefroid, Compositional dynamic test generation, In POPL ’07: Principles of Programming Languages, pp 47-54, 2007 [4] T Ball and S K Rajamani, Automatically validating temporal safety properties of interfaces, In SPIN ’01: SPIN workshop on Model checking of Software, pp 103122, 2001 [5] T A Henzinger, R Jhala, R Majumdar, and G Sutre, Lazy abstraction, In POPL ’02: Principles of Programming Languages, pp 58-70, 2002 [6] M Das, S Lerner, and M Seigle, ESP: Path-sensitive program verification in polynomial time, In PLDI’02: Programming Language Design and Implementation, pp 57-69, 2002 [7] Heumann J., Generating Test Cases from Use Cases, Journal of Software Testing Professionals 3(2) (2002) [8] Hutcheson M L., Software Testing Fundamentals-Methods and Metrics, Wiley Publishing, 2003 [9] Williams N., Marre B., Mouy P and Roger M., PathCrawler: Automatic Generation of Path Tests by Combining Static and Dynamic Analysis, SpringerVerlag, Dependable Computing: In Proceedings of the 5th European Dependable Computing Conference, 3463, 2005, pp 281–292 [10] Sen K and Agha G., CUTE and jCUTE : Concolic Unit Testing and Explicit Path Model-Checking Tools, Springer-Verlag, Computer Aided Verification: In Proceedings of the 18th International Conference, 4144, 2006, pp 419-423 Phân tích MUST-MAY để kiểm tra chương trình 74 [11] Godefroid P., Random testing for security: blackbox vs whitebox fuzzing, ACM Publisher, In Proceedings of the 2nd international workshop on Random testing: co-located with the 22nd IEEE/ACM International Conference on Automated Software Engineering, 2007, pp 1-1 [12] Peter O'Hearn, John Reynolds, Hongseok Yang, Local Reasoning about Programs that Alter Data Structures, Invited paper, Proceedings of CSL'01, Paris, 2001, pp 1-19 [13] John Reynolds, Separation Logic: A Logic for Shared Mutable Data Structures, Proceedings of LICS, 2002, pp 55-74 [14] M Huth and M Ryanl, Logic In Computer Science: Modeling And Reasoning About Systems, Cambridge University Press, 1999 [15] Sen K., Marinov D and Agha G., CUTE: a concolic unit testing engine for C, ACM Publisher, In Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering, 30(5), 2005, pp 263-272 [16] Wei-Ngan Chin, Cristina David, Huu Hai Nguyen, Shengchao Qin, Multiple Pre/Post Specifications for Heap-Manipulating Methods, (HASE07), Nov 2007, Dallas, Texas [17] Huu Hai Nguyen and Wei-Ngan Chin, Enhancing Program Verification with Lemmas, (CAV 2008), July 2008, Princeton, New Jersey [18] Tool Z3, website: http://research.microsoft.com/en-us/um/redmond/projects/z3/ [19] Bjørner N and Moura L D., Z3^10: Applications, Enablers, Challenges and Directions, In Proceedings of Workshop on Constraints in Formal Verification, 2009 [20] Nguyễn Trung Hải, Thesis Slicing-based testing for C++, HoChiMinh City, Vietnam, 2012 [21] Tibor Gyimothy, Arpad Beszedes, and Istvan Forgacs, An Efficient Relevant Slicing Method for Debugging, 1999 [22] H Agrawal & J R Horgan, Dynamic Program Slicing, 1990 Phân tích MUST-MAY để kiểm tra chương trình ... trên, phân tích MUST khơng thể phủ tất đường thực thi chương trình lớn) Phân tích MUST- MAY để kiểm tra chương trình 14 Nhóm thứ hai công cụ kiểm tra dựa kỹ thuật overapproximate, cịn gọi phân tích. .. cho chương trình bảng 2.5 Phân tích MUST- MAY để kiểm tra chương trình 44 ij 11 52 63 74 95 106 d x b a p5 x.data o10 U RelSlice(d) a x.data, b x.data 1, 5, 6, 1, 5, 6, 7, Phân tích MUST- MAY để kiểm. .. cịn gọi phân tích MAY [4][5][6] Phân tích MAY dùng để chứng minh thuộc tính (property) chương trình ln tất đường thực thi chương trình Phân tích MAY sử dụng để chứng minh chương trình khơng có lỗi