Ứng dụng Ontology trong lĩnh vực kiểm thử phần mềm

Dịch vụ web cho phép phát triển ứng dụng một cách thuận tiện cách kết hợp lại các thành phần dịch vụ hiện có. Tuy nhiên việc dựng hệ thống dựa trên dịch vụ động lại được kiểm thử một cách tự động tại thời điểm chạy mà con người không can thiệp vào. Để giải quyết những thách thức của việc tự động sinh test case cho dịch vụ web, bài báo này đề xuất 1 mô hình dựa trên ontology. Ngôn ngữ đặc tả dịch vụ web ngữ nghĩa OWLS sẽ được sử dụng để đặc tả ứng dụng logic của các tiến trình dịch vụ. Ở đây ta sẽ sử dụng mô hình PetriNet để biểu diễn mô hình OWLS một cách hình thức. PetriNet Ontology được định nghĩa để thống nhất hoạt động và ngữ nghĩa IOPE cho quá trình sinh test case. Các test step sẽ được sinh ra bằng cách duyệt các đường đi trong mạng PetriNet. Test data sẽ được sinh dựa trên ngữ nghĩa của IOPE Ontology.

ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG  BÀI TẬP LỚN WEB NGỮ NGHĨA VÀ KHAI PHÁ DỮ LIỆU Đề tài: Ứng dụng Ontology trong lĩnh vực kiểm thử phần mềm GV hướng dẫn: TS. Cao Tuấn Dũng Học viên thực hiện: Nhóm 01 Nguyễn Lương Bằng Dương Nữ Nguyệt Linh Chu Quang Phổ Phạm Trung Thành Hà Nội, 05/2014 Mục lục 2 1. Giới thiệu tổng quan Trong báo cáo này, nhóm chúng tôi trình bày các nghiên cứu về ứng dụng lý thuyết Web ngữ nghĩa, Ontology trong việc giải quyết bài toán kiểm thử phần mềm cũng như đảm bảo chất lượng cho phần mềm. Bài nghiên cứu sẽ bố cục lần lượt các phần dựa trên nghiên cứu của từng thành viên của nhóm, mỗi phần sẽ là lý thuyết cho lĩnh việc kiểm thử phần mềm bằng việc áp dụng lý thuyết Web ngữ nghĩa. Theo đó thể hiện được khả năng & phạm vi ứng dụng rộng rãi của lý thuyết Web ngữ nghĩa. Phần tiếp theo sẽ là một số demo thể hiện được việc ứng dụng thực tiễn của những lý thuyết đã trình bày. Tổng quan sẽ bao gồm: • Tổng quan vể kiểm thử phần mềm & các lĩnh vực liên quan • Ứng dụng lý thuyết Ontology trong các lĩnh vực: White box & Black box testing • Một số demo & kết luận đưa ra định hướng nghiên cứu chuyên sâu 2. Kiểm thử phần mềm Mục tiêu của công nghệ phần mềm là những sản phẩm phần mềm phải phù hợp với chất lượng và các yêu cầu chức năng. Một hoạt động cốt yếu của công nghệ phần mềm là kiểm thử phần mềm, hoạt động này kiểm tra xem phần mềm có phù hợp với các đặc tả yêu cầu. Hoạt động này có thể rất tốn kém. Chất lượng của các bộ kiểm thử liên quan trực tiếp đến số lỗi phát hiện được trong khi đó không làm ảnh hưởng đến kích cỡ của nó. Để giảm chi phí và nâng cao chất lượng của hoạt động kiểm thử, thì kiểm thử tự động đã được đề xuất đưa vào từ những năm 1970. Trong kiểm thử tự động, đưa ra cho chuyên gia kiểm cơ hội để tận dụng tri thức của họ có thể giúp cho việc tạo ra bộ kiểm thử chất lượng. Phạm vi của hoạt động test có thể được biểu diễn trong không gia 3 chiều, trên đó 3 trục thể hiện sự khác nhau của phương thức kiểm thử, và phạm vi có thể được thể hiện rõ bằng các điểm trong không gian đó. 3 Hình . Mô hình không gian của công việc kiểm thử Trục X: Mô ta những thứ được kiểm thử ( một đơn vị, tích hợp của nhiều đơn vị, hoặc cả hệ thống ). Unit test trên đồ thị cho thấy rằng hoạt động này xuyên suốt trong quá trình phát triển phần mềm, phát triển song song với quá trình phát triển phần mềm (~ Kiểm thử hộp trắng) Trục Y: Mô tả những thứ được tạo ra dựa vào đó để sinh ra các test case (Code, các yêu cầu [kiểm thử hộp đen], thiết kế [kiểm thử hộp xám]) Trục Z: Mô tả những đặc tả các tiêu chuẩn bao phủ mà tiêu chuẩn đó biểu bi cho các test được sinh ra. (GUI, Concurrency, Code Coverage, Boundary, Exceptions). Kiểm thử tự động tạo ra bộ kiểm thử, là tập các test case dựa trên các phương pháp test oracle và Coverage criteria specificaions như hình vẽ sau: Hình . Lược đồ luồng dữ liệu của một bộ sinh testcase tự động Có 3 mức để chuyên gia kiểm thử kiểm soát bộ sinh test case: Cách thứ 1: Cho phép chuyên gia kiểm thử xác định được các test case trực tiếp Cách thứ 2: Cung cấp, hỗ trợ chuyên gia kiểm thử chọn ra được những lựa chọn từ vùng 4 tiêu chuẩn nhưng cách này cũng có những hạn chế. Cách thứ 3: được cả tiến hơn, cung cấp cho chuyên gia kiểm thử ngôn ngữ để chỉ cho họ quy tắc/phạm vi trong vùng tiêu chuẩn và để mở rộng test oracles cùng với việc tăng cường tri thức mà có thể cần thiết cho vùng tiêu chuẩn. Cách này cung cấp mức kiểm soát cao nhất để chuyên gia kiểm thử có thể nâng cao chất lượng bộ test được tạo ra. Hình . Các mức kiểm soát của chuyên gia test qua việc sinh mã kiểm thử tự động 3. Ontology trong kiểm thử 3.1 Kiểm thử Web service dựa trên Ontology 3.1.1 Tổng quan Dịch vụ web cho phép phát triển ứng dụng một cách thuận tiện cách kết hợp lại các thành phần dịch vụ hiện có. Tuy nhiên việc dựng hệ thống dựa trên dịch vụ động lại được kiểm thử một cách tự động tại thời điểm chạy mà con người không can thiệp vào. Để giải quyết những thách thức của việc tự động sinh test case cho dịch vụ web, bài báo này đề xuất 1 mô hình dựa trên ontology. Ngôn ngữ đặc tả dịch vụ web ngữ nghĩa OWL-S sẽ được sử dụng để đặc tả ứng dụng logic của các tiến trình dịch vụ. Ở đây ta sẽ sử dụng mô hình Petri-Net để biểu diễn mô hình OWL-S một cách hình thức. Petri-Net Ontology được định nghĩa để thống nhất hoạt động và ngữ nghĩa IOPE cho quá trình sinh test case. Các test step sẽ được sinh ra bằng cách duyệt các đường đi trong mạng Petri-Net. Test data sẽ được sinh dựa trên ngữ nghĩa của IOPE Ontology. 3.1.2 Giới thiệu Dịch vụ web cung cấp một nền tảng mở với tập các chuẩn XML. Ta có thể dùng ngôn ngữ 5 mô phỏng cấp cao như WSFL và BPEL để mô tả ứng dụng dựa trên các dịch vụ có sẵn trên Internet. Các dịch vụ có thể cộng tác thông qua giao thức Internet chuẩn. Kiểm thử dịch vụ web là là một vấn đề đang được quan tâm. Các quá trình test offline và thủ công truyền thống không thể thỏa mãn yêu cầu của việc kiểm thử các dịch vụ web online. Ứng dụng khởi tạo động hiện nay được test runtime nhưng không có sự can thiệp của con người. Nhiều nhà nghiên cứu đã dành rất nhiều thời gian vào việc test tự động bao gồm : - Tự động sinh test data - Tự động sinh test script Trước đây thì các kĩ thuật test hầu như dựa trên phân tích chương trình như phân tích control flow hay data flow. Trong những năm gần đây, hướng tiếp cận dựa trên mô hình được giới thiệu để sinh các test case bằng cách dịch từ các mô hình UML hay Extended Finite State Machine (EFSM) hay Specification Description Language (SDL). WS testing hiện đang được rất nhiều nhà nghiên cứu quan tâm. Đặc tả XML của WS, ví dụ như WSFL và BPEL4WS, sẽ được dịch ra thành 1 mô hình và ta sẽ test dựa trên mô hình này. Có rất nhiều nhà nghiên cứu đã nghiên cứu về vấn đề này, nổi bật nhất là Srini vs Sheila áp dụng DAML-S ontology để mô tả ngữ nghĩa của dịch vụ, dịch từ DAML-S sang Petri-Net, và sẽ test WS bằng cách mô phỏng các kế hoạch thực thi của nó với nhiều dạng đầu vào khác nhau. Mục đích của bài báo này là giải quyết vấn đề sinh test case trong việc test web service. Nó sẽ sinh test case dựa trên đặc tả OWL-S của các tiến trình web logic. Bài báo này sẽ lấy OWL-S làm input cho test generator. Ứng dụng web service ( đc mô tả bằng OWL-S ) đầu tiên sẽ được dịch sang mô hình Petri-Net để biểu diễn được cấu trúc và hành vi của dịch vụ. Petri-Net ontology được định nghĩa để mô tả các ngữ nghĩa cũng như IOPE của các hàm dịch vụ. Test case được sinh ra từ 2 khía cạnh : - Sinh test step bằng cách duyệt mạng Petri-Net - Sinh test data bằng cách ngữ nghĩa của IOPE ontology. Mấu chốt của mô hình đề xuất là ontology. Ta có thể hiểu ontology là một biểu diễn ngữ nghĩa của các thành phần hệ thống. Ontology có thể mô tả được cả cấu trúc và ngữ nghĩa của môi trường thông tin. Cấu trúc của bài báo như sau : Phần 2 giới thiệu vắn tắt OWL-S, Petri-Net ( mô hình & chú thích ). Phần 3 biểu diễn hướng tiếp cận sinh test case dựa trên mạng Petri-Net & ngữ nghĩa 6 ontology. 3.1.3 Mô hình dịch vụ web dựa trên Ontology 3.1.3.1OWL-S Bài báo này dùng OWL-S để đặc tả các tiến trình của web logic. Mô hình Petri-Net được dùng để mô tả cấu trúc và hành vi của các thành phần dịch vụ trong môi trường test. Ontology được định nghĩa để mô tả mô hình Petri-Net và chú thích cho mạng. OWL-S mô hình hóa Ontology cho các dịch vụ theo 3 khía cảnh : - ServiceProfile: service làm gì, service yêu cầu người dùng cung cấp gì cho nó - ServiceGrounding: sử dụng service như nào, làm thế nào để truy cập đến nó - ServiceModel: dịch vụ hoạt động như thế nào. Hai thành phần được sử dụng để định nghĩa OWL-S process model: o Process Ontology: mô tả các thuộc tính của dịch vụ bao gồm input, output, precondition, effect. o Process Control Ontology: Mô tả trạng thái của tiến trình như khởi tạo, thực thi & hoàn thành. Mô hình dịch vụ của OWL-S được mô hình hóa như là workflow của các tiến trình. Mỗi composite process có một mô hình điều khiển là 1 trong các kiểu sau : Sequence, Split, Split-Join, Any-Order, Iterate, If-Then-Else, và Choice. Ví dụ một người muốn đặt phòng sẽ qua 3 bước sau : GetAvailableRoom, SelectRoom, BookRoom. Đầu tiên ta họ sẽ xem còn phòng nào rỗng không thông qua dịch vụ GetAvailableRoom, sau đó sẽ chọn phòng có giá cả và vị trí phù hợp thông qua dịch vụ SelectRoom và cuối cùng đặt phòng thông qua dịch vụ BookRoom. Sau đây là một đoạn đặc tả OWL-S cho dịch vụ đặt phòng nói trên với cấu trúc là Sequence. 3.1.3.2Petri-Net Petri-Net là 1 phương pháp mô phỏng cung cấp môi trường cho việc phân tích được dễ dàng hơn. Nó được dùng cho cả hệ thống xử lý thông tin đồng bộ và phân tán. Petri-Net model có khả năng mô phỏng các sự kiện và trạng thái trong hệ thống phân tán và bắt được các luồng điều khiển. Srini & Sheila đề xuất mô hình Petri-Net cho DAML-S, ngôn ngữ trước của OWL-S. Petri Net còn được gọi là Place/Transitions Networks (mạng vị trí/chuyển tiếp) và được hiển thị bằng đồ thị có hướng gồm có 2 loại node: - Transition (chuyển tiếp) có dạng hình chữ nhật hoặc hình vuông - biểu diễn các sự kiện rời rạc có thể xảy ra. 7 - Place (vị trí) có dạng hình tròn - biểu diễn trạng thái các điều kiện. Các place và transistion được nối với nhau bằng các đường nối (liên kết). Chỉ có thể nối place với transition, không thể nối giữa hai place hoặc hai transition với nhau. Khi một đường nối đi từ một place đến một transition, thì place đó được gọi là input place của transition đó. Ngược lại, khi có một đường nối đi từ transition tới một place thì place đó được gọi là output place của transition đó. Các place có thể chứa một số lượng các token (thẻ) nào đó. Token trong place được biểu diễn bằng dấu chấm. Transition của Petri Net có thể hoạt động được khi tất cả các input place của nó có ít nhất một token. Sau khi transition hoạt động (bắn), mỗi input place sẽ mất một token và mỗi output place thêm một token. Tại một thời điểm, việc phân bố các token trên các place, được gọi là đánh dấu (marking) của Petri Net. Nó biểu diễn trạng thái hiện tại của hệ thống được mô hình hóa.Mỗi tiến trình được mô tả bởi OWL-S sẽ được map vào Petri-Net bằng cách phân tích ngữ nghĩa thực thi của nó và IOPE, nó được biểu diễn bằng 1 transition. Input & precondition sẽ được ánh xạ vào các places giữ thẻ bài trỏ đến transition. Output & affect sẽ được ánh xạ vào place sẽ được trigger sau transition này. 3.1.4 Test case generation for WS Testing 3.1.4.1Test process generation Dựa trên topology của Petri-Net, quá trình test sẽ được sinh ra dựa vào các đường đi trên mạng. Giải thuật sinh test process : Input: The Petri-Net which specifies the OWL-S process. Output: Test cases for WS testing in the XML format. function TestGen (OWLOntology Petri-NetOntology) Get the transition trans from the Petri-Net; If (trans is the end of a Control Construct) return; If (trans is a Perform) { Analyze precondition, postcondition; Analyze the input, output of WS; Generate test data for the Perform; Generate one test step; fire transition; } else if (trans is the begin of a Control Construct){ Get the control type; Process the control type; Remove all nodes in the control construct; 8 } Remove the transition from the Petri-Net; end TestGen 3.1.4.2Test data generation based on Ontology Reasoning OWL-S cung cấp OWL ontology để mô tả IOPE (inputs, outputs, preconditions, and effects ) của các service. Với việc định nghĩa OWL ontology tốt, việc gen dữ liệu test sẽ “thông minh” hơn rất nhiều, đảm bảo test được nhiều trường hợp & logic. Ví dụ với Ontology “quan hệ gia đình” gồm 3 concept là Người, Bố mẹ, Con cái. Bố mẹ thì có ít nhất 1 con. Con người phải có tên. Một ràng buộc về tên được định nghĩa để đảm bảo tên người phải bao gồm ít nhất 2 phần : tên và họ. Giả sử trong CSDL đã gồm các dữ liệu sau để test cho Person: “ Linh Dương”,”chào”,”abc”,…. Giờ ta muốn sinh dữ liệu test cho Bố mẹ, reasoned sẽ phân tích quan hệ kế thừa và ràng buộc về tên vừa nêu ở trên. Tức là : - Bố mẹ là lớp con của Con người => ta có thể sử dụng bộ dữ liệu test cho con người để test cho Bố mẹ. Do đó ta có thể sử dụng bộ “ Linh Dương”,”chào”,”abc”,…. để test cho Bố mẹ. - Bố mẹ phải đảm bảo ràng buộc về tên. Từ đó => “Linh Dương” là dữ liệu đúng, còn “chào”,”abc” là sai. 3.1.4.3XML-Based Test Case Specification Việc sinh test case sẽ được viết dưới mã XML. Với ví dụ đặt phòng khách sạn nêu ở các phần trước, test case sẽ bao gồm 3 step tương ứng với 3 service Perform. Input & expected data sẽ đc mô tả ở input vs output của các Perform. 9 3.2 Kiểm thử Web service ngữ nghĩa 3.2.1 Mở đầu 3.2.1.1Định nghĩa Webservice - WSDL Theo định nghĩa của W3C (World Wide Web Consortium), dịch vụ Web là một hệ thống phần mềm được thiết kế để hỗ trợ khả năng tương tác giữa các ứng dụng trên các máy tính khác nhau thông qua mạng Internet, giao diện chung và sự gắn kết của nó được mô tả bằng XML. WS là tài nguyên phần mềm có thể xác định bằng địa chỉ URL, thực hiện các chức 10 [...]... động kiểm tra dư thừa, kiểm tra trong bộ kiểm thử ontology về sự tồn tại test case có thỏa mãn quy định trong mục tiêu kiểm thử, kiểm tra các quy tắc mẫu, (phase 2) Test Case Generation: đảm nhiệm sinh bộ kiểm thử trừu tượng Ontology và thực hiện sinh bộ kiểm thử thực thi (phase 3,4) 4 Cài đặt & thử nghiệm 4.1 Kiểm thử Web service dựa trên Ontology 4.2 Kiểm thử Web service ngữ nghĩa 4.3 Kiểm thử GUI... tiêu kiểm thử, tạo bộ kiểm thử trừu tượng ontology và các quy tắc mẫu kiểm tra dư thừa được sử dụng để lựa chọn ra mục tiêu kiểm thử không dư thừa Bước 3 – Bộ kiểm thử Ontology trừu tượng: Một trường hợp test case trừu tượng được tạo lên và thêm vào nhằm tạo ra bộ kiểm thử ontology trừu tượng, cho mỗi mục tiêu kiểm thử không dư thừa Bước 4: Thực thi bộ kiểm thử: Đặc tả kỹ thuật mô hình hành vi, bộ kiểm. .. sinh test-case sẽ được áp dụng trong tạo ra các test-case trong đó sử dụng kinh nghiệm của tester 3.3.1 Giới thiệu Kiểm thử giao diện người dùng (GUI) là một quy trình kiểm thử phần mềm – mà dựa trên giao diện người dùng đồ họa Trong kiểm thử GUI, việc kiểm thử bằng tay gây rất nhiều thiếu sót, còn kiểm thử tự động sẽ nhanh chóng gây bùng nổ qua việc phải tổ hợp các thành phần giao diện rất phức tạp... thiết)(Precondition) 13 3.3 Kiểm thử GUI dựa trên Ontology Giao diện người dùng đồ họa (GUI) đã trở thành chuẩn mực & rất phổ biến cho người dùng tương tác với hệ thống phần mềm Công việc kiểm thử GUI là một phần vô cùng quan trọng trong quá trình phát triển phần mềm Kiểm thử GUI như các công việc khác trong công tác kiểm thử đều cần thực hiện các tác vụ cơ bản là tạo ra các trường hợp test (test-case) và kiểm tra kết... của chuyên gia kiểm thử, những đặc tả cần được kiểm tra và xác định rõ những mục tiêu kiểm thử cần được tách riêng ra Thao tác tách riêng ra cho phép chuyên gia kiểm thử có thể thao tác trên các đặc tả cần được kiểm thử mà không cần sử đổi nhiều các thuật toán xác định mục tiêu kiểm thử Như vậy các chuyên gia kiểm thử có thể làm phong phú, mở rộng thêm ontology dựa trên dự đoán kiểm thử và đặc biệt... quá trình kiểm thử, mà còn tái sử dụng được các tri thức này Tuy nhiên, để nâng cao phương pháp tiếp cận đề xuất, cần phải đưa thêm vào nhiều kinh nghiệm kiểm thử GUI đưa vào áp dụng trong quá trình sinh ra các luật cụ thể & hoàn thiện hơn nữa để phủ đủ các yêu cầu kiểm thử hệ thống GUI 3.4 Thực hiện Unit-test dựa trên Ontology 3.4.1 Mở đầu 17 Ontology dựa trên phương pháp kiểm thử phần mềm được mô... thành phần & định nghĩa trong GUI ontology Căn cứ trên thiết kế của GUI ontology, các kỹ thuật phân tích ngược được sử dụng để lấy ra toàn bộ các thành phần từ mã nguồn, rồi đưa ngược lại vào trong GUI ontology 3.3.3 Các luật trong việc sinh ra các Test-case 15 Các test-case trong kiểm thử GUI được hình thành chủ yếu từ các phần tử liên quan tới người dùng như các thành phần tương tác & các thành phần. .. tiên đoán kiểm thử đến bộ kiểm thử thực thi Để chính xác hơn 1 ontology dựa trên sự biểu diễn của mô hình hành vi của hệ thống kiểm thử, một ontology tri thức chuyên gia, ontology tri thức thực thi và các quy tắt tiêu chuẩn bao phủ, được sử dụng để thực hiện các test case 3.4.2 Phương pháp Phương pháp này tạo ra một bộ kiểm thử thực thi gồm 4 bước: Bước 1: Tổng hợp các mục tiêu cần kiểm thử Sau khi... kiểm thử ontology tóm tắt, và tri thức thi hành ontology được sử dụng để tạo ra bộ kiểm thử thực thi 18 Mục đích của phương pháp này là tạo điều kiện để khai thác tri thức của các chuyên gia kiểm thử để xay dựng lên bộ kiểm thử tự động Để đạt được mục tiêu này, phương thức thúc đẩy tách biệt thành 3 vấn đề test case, cụ thể là những cái đặc biệt cần thiết được kiểm thử, xác định mục tiêu kiểm thử và... dựa trên ontology cho kiểm thử GUI, bằng cách sử dụng tri thức cung cấp bởi hệ thống GUI kết hợp với kinh nghiệm của các tester GUI ontology sử dụng để lưu trữ các thông tin tiềm năng trong một hệ thống GUI cụ thể, trong khi các luật sinh test-case trích xuất các thông tin hữu ích dựa trên kinh nghiệm của tester Có thể kết luận, kiểm thử dựa trên GUI là một mô hình kiểm thử phần mềm mới, không chỉ lấy