PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ PHẦN MỀM DỰA TRÊN KỸ THUẬT KIỂM CHỨNG MÔ HÌNH

53 1.5K 7
PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ PHẦN MỀM DỰA TRÊN KỸ THUẬT KIỂM CHỨNG MÔ HÌNH

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Trong những năm gần đây, việc phát triển phần mềm ngày càng được chuyên nghiệp hóa. Các phần mềm được phát triển ngày càng có quy mô lớn. Yêu cầu đảm bảo chất lượng phần mềm là một trong những mục tiêu quan trong nhất, đặc biệt trong một số lĩnh vực như y khoa, ngân hàng, hàng không… Việc kiểm thử, kiểm chứng phần mềm một cách thủ công chỉ đảm bảo được phần nào chất lượng của phần mềm. Vì vậy rất nhiều các tổ chức, công ty đã nghiên cứu và phát triển các lý thuyết cũng như công cụ để kiểm chứng, kiểm thử phần mềm một cách tự động.Xuất phát từ nhu cầu thực tế trên, tác giả đã nghiên cứu một số lý thuyết, công cụ trong việc kiểm chứng và kiểm thử phần mềm. Một lý thuyết nền tảng rất quan trọng đó là lý thuyết về tính thỏa được, viết tắt là SMT (Satisfiability Modulo Theories). Lý thuyết về tính thỏa được đã được ứng dụng để giải quyết nhiều bài toán trong công nghệ phần mềm như:•Kiểm chứng chương trình•Khám phá chương trình•Mô hình hóa phần mềm•Sinh các ca kiểm thử

1 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ PHAN VĂN TIẾN NGHIÊN CỨU PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ PHẦN MỀM DỰA TRÊN KỸ THUẬT KIỂM CHỨNG MÔ HÌNH LUẬN VĂN THẠC SĨ Hà Nội - 2011 2 LỜI CẢM ƠN ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ PHAN VĂN TIẾN NGHIÊN CỨU PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ PHẦN MỀM DỰA TRÊN KỸ THUẬT KIỂM CHỨNG MÔ HÌNH NGÀNH: CÔNG NGHỆ THÔNG TIN CHUYÊN NGÀNH: CÔNG NGHỆ PHẦN MỀM MÃ SỐ: 60 48 10 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. NGUYỄN TRƯỜNG THẮNG Hà Nội - 2011 3 LỜI CẢM ƠN Trước tiên tôi xin gửi lời cảm ơn chân thành và sâu sắc nhất tới TS. Nguyễn Trường Thắng - Viện công nghệ thông tin - Viện khoa học công nghệ Việt Nam. Thầy đã tận tình chỉ bảo, giúp đỡ và truyền đạt cho tôi rất nhiều kiến thức và kinh nghiệm quý báu trong thời gian qua. Tôi xin cảm ơn các thầy giáo, cô giáo trong khoa Công Nghệ Thông Tin, các thầy các cô luôn giành cho tôi những kiến thức, tình cảm và những lời khuyên quý báu. Cuối cùng tôi xin cảm ơn các bạn bè, đồng nghiệp và nhất là các thành viên trong gia đình đã tạo mọi điều kiện tốt nhất, động viên, cổ vũ tôi trong suốt quá trình học tập và nghiên cứu để hoàn thành tốt luận văn tốt nghiệp này. Tác giả 4 LỜI CAM ĐOAN Tôi xin cam đoan rằng đây là công trình nghiên cứu của tôi trong đó có sự giúp đỡ của thầy hướng dẫn. Các nội dung nghiên cứu và kết quả trong đề tài này là hoàn toàn trung thực. Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả đã được liệt kê tại phần tài liệu tham khảo ở cuối luận văn. Hà Nội, ngày……tháng……năm…… Tác giả Phan Văn Tiến 5 MỤC LỤC DANH MỤC CÁC HÌNH 6 MỞ ĐẦU Trong những năm gần đây, việc phát triển phần mềm ngày càng được chuyên nghiệp hóa. Các phần mềm được phát triển ngày càng có quy mô lớn. Yêu cầu đảm bảo chất lượng phần mềm là một trong những mục tiêu quan trong nhất, đặc biệt trong một số lĩnh vực như y khoa, ngân hàng, hàng không… Việc kiểm thử, kiểm chứng phần mềm một cách thủ công chỉ đảm bảo được phần nào chất lượng của phần mềm. Vì vậy rất nhiều các tổ chức, công ty đã nghiên cứu và phát triển các lý thuyết cũng như công cụ để kiểm chứng, kiểm thử phần mềm một cách tự động. Xuất phát từ nhu cầu thực tế trên, tác giả đã nghiên cứu một số lý thuyết, công cụ trong việc kiểm chứng và kiểm thử phần mềm. Một lý thuyết nền tảng rất quan trọng đó là lý thuyết về tính thỏa được, viết tắt là SMT (Satisfiability Modulo Theories). Lý thuyết về tính thỏa được đã được ứng dụng để giải quyết nhiều bài toán trong công nghệ phần mềm như: • Kiểm chứng chương trình • Khám phá chương trình • Mô hình hóa phần mềm • Sinh các ca kiểm thử Hiện nay Microsoft Z3 là một công cụ tìm lời giải cho SMT đang được áp dụng trong nhiều dự án của Microsoft như: Pex, Spec#, SLAM/SDV, Yogi. Z3 được đánh già là công cụ tìm lời giải mạnh nhất hiện nay. Tuy nhiên Z3 chỉ được áp dụng cho các ngôn ngữ của Microsoft. Vì vậy tác giả đặt ra vấn đề: Liệu có thể sử dụng Z3 để kiểm chứng cho các chương trình viết bằng ngôn ngữ khác như Java? Trong quá trình nghiên cứu về kiểm chứng chương trình tác giả cũng có tìm hiểu về JavaPathFinder (JPF). JPF là một dự án mã nguồn mở được phát triển trên ngôn ngữ 7 Java. Hiện nay có một mở rộng của JPF trong việc sinh tự động dữ liệu đầu vào để kiểm thử chương trình. Tuy nhiên còn rất nhiều hạn chế, vì vậy tác giả đã nghĩ đến việc làm sao để tích hợp được Z3 với JPF để có thể sinh tự động dữ liệu kiểm thử chương trình. Nếu việc tích hợp thành công thì sẽ dẫn tới việc giải quyết được lớp bài toán rộng hơn. Điều này là rất có ý nghĩa đối với thực tế. Mục tiêu đề tài: Mục tiêu của đề tài là nghiên cứu nắm bắt rõ về Z3 và JPF. Sau đó bước đầu tích hợp thành công Z3 và JPF để có thể sinh tự động dữ liệu kiểm thử chương trình Java cho các bài toán mà hiện nay JPF không thể thực hiện được. (ví dụ: sinh tự động dữ liệu cho số học phi tuyến tính). CẤU TRÚC CỦA LUẬN VĂN Luận văn bao gồm các phần sau: Mở đầu: Giới thiệu về đề tài, tính cấp thiết cũng như mục tiêu của đề tài Chương 1: Cơ sở lý luận Chương 2: JPF và Thực thi tượng trưng Nội dung: Giới thiêu JPF là gì? Kiến trúc của JPF, cách mở rộng, phát triển trên JPF. Ngoài ra còn một phần rất quan trọng đó là giới thiệu về thực thi tượng trưng để sinh dữ liệu kiểm thử cho chương trình trong JPF. Mở rộng này sẽ cho phép sinh tự động dữ liệu kiểm thử chương trình Java. Chương 3: Microsoft Z3 Nội dung: Giới thiệu về lý thuyết tính thỏa được SMT, Z3, các lý thuyết được hỗ trợ trên Z3, các API của Z3 để tích hợp với JPF, các ứng dụng của Z3. Chương 4: Tích hợp JPF với Z3 Nội dung: Nghiên cứu, đánh giá các giải pháp. Sau khi đã có giải pháp tiến hành thiết kế kiến trúc hệ thống, sau đó chi tiết hóa sang mức gói, mức lớp cuối cùng là cài đặt và đánh giá kết quả. Kết luận và hướng phát triển của luận văn Trình bày kết quả sau khi nghiên cứu, triển khai và hướng phát triển tiếp theo. 8 CHƯƠNG 1- CƠ SỞ LÝ LUẬN 1.1 Tổng quan kiểm định phần mềm Như chúng ta đã biết, việc kiểm thử phần mềm là một khâu không thể thiếu trong các bước phát triển phần mềm, đặc biệt các phần mềm lớn, nhiều module do nhiều người phát triển, dễ sinh ra các lỗi tiềm ẩn mà nhà phát triển không thể lường trước. Trong lĩnh vực kiểm định chất lượng phần mềm hiện nay trên thế giới, hiện có nhiều kỹ thuật nhưng tựu chung có thể phân theo ba nhóm chính: Phân tích mã nguồn tĩnh (static code analysis), kiểm thử dữ liệu động (dynamic data testing) và kỹ thuật hình thức dựa trên mô hình (model-based verification). Hai nhóm đầu tập trung vào việc nâng cao chất lượng phần mềm tại mức mã nguồn, trong khi nhóm cuối cùng xử lý phần mềm tại mức trừu tượng cao hơn – mô hình. 1.2 Các nhóm kiểm định phần mềm Phân tích mã nguồn tĩnh là kỹ thuật phát hiện lỗi chương trình mà không yêu cầu chạy chương trình đó. Không giống như kỹ thuật kiểm thử dữ liệu động đòi hỏi phải chạy chương trình với dữ liệu đầu vào thật, kỹ thuật phân tích mã nguồn tĩnh chỉ xem xét mã nguồn của chương trình. Kỹ thuật kiểm thử phần mềm dựa trên mô hình: khác với hai nhóm ở trên ở điểm đối tượng được kiểm thử là các mô hình được trừu tượng hóa từ hệ thống được xem xét. Quá trình trừu tượng hóa là việc lược bỏ những chi tiết của hệ thống trong khi chỉ giữ lại những thông tin/khía cạnh quan trọng cần được lưu tâm. Kỹ thuật trừu tượng hóa đơn giản hóa hệ thống được xem xét và do đó giảm không gian tìm kiếm và thời gian phân tích chương trình đi nhiều lần so với lúc thực hiện công việc phân tích đó trên mã nguồn. 9 Khi xây dựng xong phần mềm, chúng ta phải sử dụng các testcase (trường hợp kiểm thử) cho việc kiểm thử. Chất lượng của việc kiểm thử phụ thuộc rất lớn vào tập hợp các testcase mà chúng ta sử dụng. Hai tiêu chí chính của việc đánh giá chất lượng kiểm thử đó là hiệu quả cho chất lượng phần mềm được kiểm thử là độ phủ dòng chảy (control flow coverage) và độ phủ dữ liệu (data coverage). Tiêu chí thứ nhất tập trung vào việc kiểm thử tất cả các điểm điều khiển trên chương trình (ví dụ: các nhánh rẽ khả đạt trong cấu trúc chương trình – reachable control points). Trong khi tiêu chí thứ hai tập trung vào tập dữ liệu kiểm thử ứng với mỗi điểm điều khiển trong cấu trúc chương trình. Bằng kỹ thuật phân tích chương trình dựa trên mô hình sau khi trừu tượng hóa mã nguồn của chương trình được kiểm thử, việc phân tích cấu trúc logic của chương trình và tập dữ liệu ứng với mỗi điểm điều khiển trong chương trình sẽ dễ dàng hơn. Qua đó, quá trình sinh ra tập các testcase sẽ nhanh chóng và chính xác, đảm bảo các tiêu chí control flow và data coverage tốt hơn nhiều so với cách tiếp cận ở mức mã nguồn truyền thống. Hơn nữa, nếu quá trình này được thực hiện một cách tự động sẽ giảm thiểu nhiều công sức cho các chuyên gia kiểm thử chương trình. Với cách tiếp cận như vậy, phần mềm có thể được kiểm thử một cách tự động bằng máy, đem lại kết quả chuẩn hơn, xét được nhiều trường hợp hơn, đặt biệt là các lỗi logic, tiết kiệm chi phí sản xuất. Đánh giá tập dữ liệu kiểm thử: Ngoại trừ những chương trình đơn giản, sẽ là không thực tế nếu kiểm chứng phần mềm trên tập tất cả dữ liệu đầu vào có thể. Ngay cả khi chỉ tính tổ hợp của các dữ liệu đầu vào hoặc tổ hợp của các hàm, số lượng đầu vào và số lượng các trạng thái cũng là quá lớn. Khi hệ thống có bộ nhớ lớn, các dữ liệu đầu vào, đầu ra sẽ được log lại để theo dõi trạng thái. Trong khi không có một công cụ để tạo ra một thiết kế phần mềm chuẩn, hoàn chỉnh và chắc chắn thì việc kiểm thử là một khâu không thể thiếu để có thể đánh giá được chất lượng phần mềm. Vì thế người ta phải tìm cách chọn được một tập dữ liệu nhỏ mà có thể kiểm thử mang lại được độ tin cậy cao với mỗi hệ thống. Độ phủ hay mức độ đầy đủ bằng trực quan đánh giá được phạm vi hay mức độ kiểm thử. Nếu kiểm thử không đầy đủ được hết mọi khía cạnh của phần mềm đồng nghĩa với việc chúng ta bỏ sót nhiều lỗi. Các tấn suất của các trường hợp cũng không giống nhau. Khái niệm ca kiểm thử đơn giản là kiểm chứng các trạng thái đưa ra thể hiện cho hoạt động của hệ thống. Chúng ta có thể tạo ra ca kiểm thử đề đạt được trạng thái có thể bằng cách đưa vào các biến đặc biệt, trạng thái để điều khiển hệ thống. 10 CHƯƠNG 2- JAVA PATH FINDER VÀ THỰC THI TƯỢNG TRƯNG Trong chương này sẽ bao gồm hai phần chính. Phần 1 giới thiệu về JPF, một dự án mã nguồn mở được viết bằng ngôn ngữ java để kiểm chứng mô hình. Phần 2 giới thiệu một mở rộng của JPF đó là thực thi tượng trưng trong việc sinh tự động dữ liệu để kiểm thử chương trình Java. 2.1 Giới thiệu về JPF JPF là một bộ kiểm tra mô hình phần mềm trạng thái tường minh cho Java [5]. Hiểu một cách cơ bản JPF là một máy ảo thực thi chương trình Java không chỉ một lần (giống như các máy ảo thông thường), mà thực thi trong tất cả các nhánh, các đường đi có thể. JPF sẽ kiểm tra các vi phạm thuộc tính như khóa chết hoặc các ngoại lệ không thể bắt được xuyên xuốt các đường thực thi tiềm năng. Hình 2-1 mô tả mô hình hoạt động của JPF. [...]... mở rộng này, đó là tự động sinh dữ liệu kiểm thử bao phủ toàn bộ chương trình của mã nguồn Mở rộng này phối hợp thực thi tượng trưng với kiểm chứng mô hình và các ràng buộc giải quyết để sinh dữ liệu kiểm thử Trong công cụ này, các chương trình được thực thi trên đầu vào tượng trưng Các giá trị của các biến được biểu diễn như và các biểu thức số và ràng buộc, chúng được sinh từ việc phân tích cấu trúc... bằng Eclipse sẽ cho kết quả sau: 20 Hình 2.6: Đầu ra trên Eclipse cho MyClass1 Nhìn vào kết quả ở trên các PC sẽ chỉ ra các ca kiểm thử là Ca kiểm thử 1: y = -9999999, x = 10000000 Ca kiểm thử 2: y = -10000000, x = 10000000 Ca kiểm thử 1 tương ứng với z > 0 của câu lệnh if của phương thức myMethod Ca kiểm thử 2 tương ứng với nhánh z≤0 2.2.3.2 Lọc các trường hợp kiểm thử Chúng ta thay đổi MyClass1 thành... trên Eclipse Khi đó kêt quả ta sẽ được các ca kiểm thử sau: • Ca kiểm thử 1: y = -4.999992597731762E-7, x = -5000.00000025 • Ca kiểm thử 2: y = 0.0, x = 0.0 • Ca kiểm thử 3: y = -4.999992597731762E-7, x = -5000.00000025 Ở đây ta thấy nhận được 3 ca kiểm thử tuy nhiên trong trường hợp kiểu là số nguyên ta chỉ nhận được 2 ca kiểm thử Đó là bởi vì JPF thực thi trên JVM bytecode, không phải là Java source... đích phân chia hệ thống thành các thành phần con và sau đó kiểm chứng từng thành phần đó một cách riêng rẽ Mục đích chính của mở rộng này là cải tiến khả năng của JPF, nó có thể được sử dụng để sinh ra môi trường giả định cho kiểm chứng mô hình UML, để xác định các trình tự sự kiện đúng numeric - Numeric Property Verification Mở rộng này được sử dụng để kiểm chứng các thuộc tính của số học Ban đầu... điểm của phương pháp này là ta có thể thực thi tại bất kỳ điểm nào trong chương trình và có thể trộn giữa đầu vào tượng trưng với đầu vào cụ thể Phương pháp này sẽ cho ta các điều kiện đường đi của chương trình, và với việc sử dụng các công cụ tìm lời giải cho các điều kiện đường đi (coi mỗi điều kiện đường đi là một biểu thức) sẽ sinh ra dữ liệu kiểm thử cho chương trình Tuy nhiên phương pháp này... tượng trưng để sinh dữ liệu kiểm thử 2.2.1 Thực thi tượng trưng là gì? Đổi giá trị giữa 2 biến Đường đi cụ thể 17 Hình 2.5: Ví dụ về thực thi tượng trưng Kỹ thuật thực thi tượng trưng là kỹ thuật thực thi chương trình bằng cách sử dụng các giá trị tượng trưng, không phải sử dụng các giá trị cụ thể [2] Để hiểu rõ thực thi tượng trưng là gì, xét ví dụ chuyển đổi giứa 2 biến x và y: Ở ví dụ trên, nếu trong... kiểu dữ liệu đệ quy Z3 kiểm tra một tập các công thức có thỏa mãn trong lý thuyết của nó hay không Nếu tập công thức đó là thỏa mãn, khi đó tập công thức đó là tồn tại Trong thực tế Z3 là 31 một thủ tục ra quyết định: Nó luôn luôn đảm bảo rằng trả về 1 câu trả lời chính xác Khi một tập của công thức F là thỏa mãn, Z3 có thể đưa ra một mô hình cho F Mô hình này có thể sử dụng trong kiểm chứng phần mềm, ... cấu hình như sau: +vm.insn_factory.class=gov.nasa.jpf.symbc.SymbolicInstructionFactory +vm.classpath= +vm.storage.class= +symbolic.method=myMethod2(sym#sym) +search.multiple_errors=true +jpf.report.console.finished= MyClass2 21 Hình 2.7: Đầu ra của MyClass2 trên Eclipse • • • • Khi đó chúng ta sẽ nhận được 4 ca kiểm thử như sau: Ca kiểm thử 1: y = 10000000, x = -9999999 Ca kiểm thử 2: y = -4, x=5 Ca kiểm. .. ra một phương thức gọi tượng trưng như sau: MyDriver1.imposePreconditions(), không phải MyClass1.myMethod() Chú ý rằng tham số của phương thức imposePreconditions() là x và y, đây chính là tham số của myMethod() cần phải được symbolic Hình 2.9: Đầu ra của MyDriver trên Eclipse • • Kết quả sẽ cho ra các ca kiểm thử với các tham số nằm trong khoảng giới hạn Ca kiểm thử 1: y = 1, x = 0 Ca kiểm thử 2:... bytecodes nhằm sinh ra các ca kiểm thử riêng biệt Nói tóm lại nó hoạt động bằng cách sử dụng các thuộc tính/ trường của JPF để thu thập các điều kiện đường đi PC, sau đó được đưa các PC vào một hệ thống tìm lời giải theo đinh dạng của hệ thống đó để đưa ra dữ liệu kiểm thử Mở rộng này sẽ được trình bày chi tiết hơn ở phần 2.2 cv - Compositional Verification Framework Mở rộng này là một thuật toán học

Ngày đăng: 05/10/2014, 18:59

Từ khóa liên quan

Mục lục

  • MỞ ĐẦU

  • CHƯƠNG 1- CƠ SỞ LÝ LUẬN

    • 1.1 Tổng quan kiểm định phần mềm

    • 1.2 Các nhóm kiểm định phần mềm

    • CHƯƠNG 2- JAVA PATH FINDER VÀ THỰC THI TƯỢNG TRƯNG

      • 2.1 Giới thiệu về JPF

        • 2.1.1 JPF có thể kiểm tra những chương trình gì?

        • 2.1.2 Kiến trúc mức cao của JPF

        • 2.1.3 Khả năng mở rộng của JPF

        • 2.1.4 Một số mở rộng của JPF

        • 2.2 Thực thi tượng trưng để sinh dữ liệu kiểm thử

          • 2.2.1 Thực thi tượng trưng là gì?

          • 2.2.2 Thực thi tượng trưng với JPF

          • 2.2.3 Hướng dẫn thực thi tượng trưng với JPF

            • 2.2.3.1 Một ví dụ đơn giản

            • 2.2.3.2 Lọc các trường hợp kiểm thử

            • 2.2.3.3 Bổ sung tiền điều kiện

            • 2.2.3.4 Các tham số thực

            • 2.2.3.5 Các thuộc tính của đối tượng

            • 2.2.4 Hạn chế

            • CHƯƠNG 3- MICROSOFT Z3

              • 3.1 SMT là gì

              • 3.2 Z3 là gì

              • 3.3 Tại sao lại là Z3?

              • 3.4 Kiến trúc của Z3

              • 3.5 Định dạng đầu vào

Tài liệu cùng người dùng

Tài liệu liên quan