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

ĐẠ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
năng và đưa ra các thông tin người dùng yêu cầu. Một dịch vụ Web được tạo nên bằng cách
lấy các chức năng và đóng gói chúng sao cho các ứng dụng khác dễ dàng nhìn thấy và có
thể truy cập đến những dịch vụ mà nó thực hiện, đồng thời có thể yêu cầu thông tin từ dịch
vụ Web khác.
3.2.1.2Định nghĩa Webservice Sematic – WSDL-S
WSDL-S là một phần mở rộng của các chuẩn WSDL. Phần WSDL-S mở rộng từ bao gồm
các yếu tố ngữ nghĩa mà sẽ được cải thiện có thể dùng lại WS bằng cách tạo điều kiện cho
các thành phần của các dịch vụ, cải thiện phát hiện và tạo điều kiện cho sự phân tích kế thừa
nền tảng WS. WSDL-S được phát triển bởi IBM và Đại học Georgia
3.2.1.3Các bước thực hiện sinh test case WS tự động dựa vào WSDL-S
- Sinh dữ liệu test dựa trên sự phân tích của: thong điệp và loại dữ liệu theo cú pháp
XML.
- Luồng sinh test case dựa trên phân tích thành phần phụ thuộc: đầu vào và đầu ra.
Làm giam số test case,sinh test case dựa trên mô tả XML nó được gọi là STS- Service Test
Specification.
3.2.2 Cơ sở lý thuyết
3.2.2.1Semantic Web Rule Language (SWRL)
- SWRL là sự kết hợp của OWL DL và OWL Lite.
- SWRL là 1 sự duy diễn dựa trên quy tắc ngôn ngữ OWL
- Cung cấp khả năng suy diến tốt hơn OWL đơn lẻ.
- SWRL được xây dựng trên nền tảng giống mô tả logic như OWL
- Mạnh trong việc cung cấp các luật giống nhau khi thực hiện suy luận
- Bao gồm: tiền đề và kết quả.
- Cả Body và head bao gồm các liên từ rõ rang của các phần nhỏ

- SWRL không hỗ trợ OWL Full trực tiếp
- SWRL không hỗ trợ RDF hoặc RDFS

3.2.2.2Web service Semantic(WSS)
WSS: thêm ngữ nghĩa cho mô tả dịch vụ web bằng cachs mở rộng WSDL là tương đối đơn
11
giản nâng cấp công cụ hiện có của WSDL.Các yếu tố và thuộc tính mở rộng được cung cấp:
- ModelReference: phần mở rộng thuộc tính cùng với sự kết hợp đặc biệt giữa 1 đối
tượng và 1 khái niệm trong một vài mô hính ngữ nghĩa.
- SchemaMapping: mở rộng thuộc tính với xử lý cấu trúc khác nhau giữa sơ đồ
phần tử của WS và các khía niệm tương ứng mô hình ngữ nghĩa của chúng
- Precondition and effect: cả điều kiện và kết quả thành phần mới được thiết lập
như các thành phần nhỏ của thành phần hoạt động. Mỗi thành phần có thẻ nhiều
nhất 1 điều kiện và 1 kết quả. Một điều kiện(giả thiết, tiền đề, luật suy diễn) được
định nghĩa xác nhận trước khi thành phàn WS có thẻ được gọi ra.
- Category: thuộc tính mở rộng thành phần giao tiếp gồm có thong tin được phân
loại có thể sử dụng khi được public là 1 dịch vụ trong WS như là UDDI.
3.2.2.3Kỹ thuật test ngẫu nhiên
Đây là kỹ thuật test theo nguyên tắc test hộp đen, các tham số đầu vào độc lập và được tạo
ra ngẫu nhiên. Thường các giá trị được chọn: nhỏ nhất, nhỏ, trung bình, lớn, lớn nhát.
3.2.3 Cách tiếp cận
Việc sinh test case tự động WSDL-S và SWRL dựa trên test radom. Thực hiện cách tiếp cận
này có tool chạy thử là TAG-WS
3.2.3.1Qui trình
3.2.3.1.1 Phân tích SWRL
- Một tài liệu SWRL định nghĩa các qui tác tham chiều bỏi các thành phần
modelReference trong tài liệu SWRL
- Đinh nghĩa luật bao gômf 2 phần: giả thiết và kết quả
- Phương pháp phân tích SWRL cơ bản:
o Tìm thành phần ruleml:imple
o Tìm kiếm luật có tên là rdf:ID
o Phân tích cấu trúc cây phân cấp của ruleml:imple
o Duyệt cây, tại mỗi nút của cây:

 Nếu đó là nút ruleml:_body thì sinh ra biểu thức logic điều kiện
 Nếu là nút ruleml:_head sinh ra biểu thức logic kết quả.
o Giữ tên luật và biểu thức logic điều kiện và kết quả vào DB.
o Tìm thành phần ruleml:imp tiếp theo và quay lại bước 2. Nếu là nút cuối thì
kết thúc phân tích.
3.2.3.1.2 Phân tích WSDL-S
WSDL-S diễn tả dịch vụ web đặc biệt với sự chú thích ngữ nghĩa. Loại dữ liệu được định
nghĩa mỗi phần tử có định nghĩa dựa trên XML Schema.
Các bước phân tích:
12
B1: Phân tích cấu trúc cây phân cấp của nút phần tử.
B2: Duyệt nút của cây:
Nếu là 1 nút input thì sinh ra loại dữ liệu định nghĩa là biến input.
Nếu là 1 nút output thì sinh lại dữ liệu định nghĩa là biến output.
Nếu là 1 nút điều kiện trích chọn luật URIs của điều kiện trong từ thuộc tính
modelReference.
Nếu là 1 nút kết quả(của mênh đề) trích luật theo luật URIs của điều kiện sau từ
thuộc tính modelReference.
B3: Lưu các định nghĩa toán tử vào DB.
3.2.3.1.3 Mapping luật tới toán tử
- Đây là hành động tìm kiếm thông tin của hai phần trước trong DB. Sau đó tất cả
luật sẽ được mapped với mỗi dịnh nghĩa toán tử
- Các bước để thực hiện:
o B1: Tìm kiếm thông tin của phân tích SWRL và phân tích WSDL-S.
o B2: Phân tích danh sách luật URIs của điều kiện
o B3: Duyệt danh sách,tại mỗi điểm mapping luật từ phân tích SWRL vào tập
tin.
o B4: Phân tích danh sách luật URIs phần hậu tố và lặp lại bước 3.
3.2.3.2Sinh test case
Các bước sinh test case:

- Phân tích định nghĩa các toán tử.
- Chọn giá trị dữ liệu test ngẫu nhiên theo định nghĩa các toán tử.
- Phân tích kết quả output mong muốn.
- Sinh test case theo WTCS
- Lặp lại bước 2 nếu:
o Tất các các test case giá trị ouput không bao phủ được tất cả tình huống.
o Nếu tât cả test case không phủ được 100% điều kiện(giả 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 quả chạy kiểm thử; quá trình này rất phức tạp đòi hỏi tri thức rất chuyên sâu,
cần phải có kiến thức về giao diện người dùng hệ thống cần kiểm thử cũng như kinh nghiệm
của nhân viên kiểm thử (tester).
14
Mục này của bài viết sẽ trình bày một phương pháp tiếp cận dựa trên Ontology giúp cho quá
trình sinh ra các test-case được hiệu quả bằng cách sử dụng kiến thức & kinh nghiệm của
tester. Tiếp cận này trước tiên sẽ phân tích mã nguồn theo các kỹ thuật phân tích ngược
(reverse engineering). Tiếp theo các quy luật 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. Những vấn đề này phản ảnh đặc tính yêu cầu tri thức chuyên
sâu của công tác kiểm thử GUI, trong đó bao gồm rất nhiều các thành phần, tác vụ & mối
ràng buộc phức tạp của giao diện người dùng kết hợp với kinh nghiệm của tester. Chính vì
vậy, kiểm thử GUI sẽ cần một phương pháp tiếp cận dựa trên tri thức.

Dựa trên lợi thế của Ontology trong việc biểu diễn tri thức có ngữ nghĩa, nên sẽ khả thi nếu
tiếp cận theo phương pháp Ontology cho kiểm thử GUI. Trong đó tất cả các thành phần giao
diện sẽ được miêu tả trong GUI ontology, các luật trong việc sinh ra test-case sẽ được tạo ra
bằng cách phân tích GUI ontology & kinh nghiệm của tester. Cuối cùng các test-case sẽ
được sinh ra từ các luật này.
3.3.2 GUI Ontology
Ontology được sử dụng để xây dựng lên các mô hình tính toán cho một số miền nghiệp vụ.
Trong trường hợp này thì ontology sẽ được xây dựng dựa trên tri thức cung cấp bởi hệ
thống GUI. Bảng sau đây sẽ đưa ra tập hợp các thành phần của GUI Ontology bao gồm:
khái niệm, thể hiện, mối quan hệ và các thuộc tính; những cấu thành này sẽ được tổ chức
theo mô hình thừa kế.
THÀNH PHẦN ĐỊNH NGHĨA
KHÁI NIỆM Các thành phần cơ bản trong mã nguồn
THỂ HIỆN Sự cài đặt của các khái niệm
MỐI LIÊN HỆ Các mối quan hệ giữa các khái niệm hay thể hiện
THUỘC TÍNH Các mối quan hệ giữa các khái niệm, các thể hiện và các thành phần dữ liệu
Bảng. Các 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 dữ liệu, do đó luật của việc sinh
test-case cũng sẽ tập trung vào các yếu tố liên quan tới người dùng này. Các phần tử liên
quan tới người dùng này sẽ được định nghĩa đầu tiên trong GUI ontology và phân chia
thành các loại khác nhau, sau đó tester sẽ dùng kinh nghiệm để đưa ra các luật.
3.3.3.1Phân loại cấu thành liên quan người dùng
Đối với người dùng, ngoại trừ các thành phần tương tác như Button, TextBox và Form, tất
cả các phần tử dữ liệu trong hệ thống GUI đều quan trọng. Các phần tử liên quan tới dữ liệu
trong hệ thống GUI là cơ sở dữ liệu, tệp tin, biến số. Như trong bảng 2 dưới đây, các phần tử

liên quan tới người dùng được phân chia thành 4 nhóm chính như sau:
THÀNH PHẦN ĐỊNH NGHĨA VÍ DỤ
THÀNH PHẦN
TƯƠNG TÁC
Các khái niệm hiển thị trên màn hình mà tương tác
với người dùng cuối
Button, Text, Listbox,
CƠ SỞ DỮ LIỆU Các thành phần trong cơ sở dữ liệu Table, View, Store,
TỆP TIN Tệp tin dữ liệu (ko bao gồm CSDL) .xml, .txt,
BIẾN/THAM SỐ Các biến chương trình định nghĩa bởi người dùng
sử dụng để truyền giá trị
Nguoi_dung, Mat_khau,
Tu_ngay, Toi_ngay,
Bảng. các phần tử liên quan tới người dùng & định nghĩa
3.3.3.2Sinh luật kiểm thử
Kinh nghiệm của tester trong việc kiểm thử GUI thể hiện ở thứ tự lần lượt các thành phần
GUI được nhập bởi tester, theo đó tester khác nhau, sẽ có cách làm việc khác nhau. Như vậy
để trích xuất được tập luật sinh test-case chung thì cần một số lượng lớn các tester tham gia
cùng.
Dựa trên tri thức chứa trong GUI ontology, các luật được sinh ra thông qua việc phân tích
tập hợp các thứ tự làm việc với các thành phần GUI của các tester. Quy trình cơ bản của
việc sinh ra các luật sẽ như sau:
Bước1: kinh nghiệm của các tester sẽ được ghi nhận lại và được biểu diễn thành các hành vi
liên tiếp (tương tác với các thành phần GUI) vào trong các file XML, trong này các thành
phần GUI đã được định nghĩa sẵn trong GUI ontology.
Bước 2: tất cả các thành phần liên quan tới dữ liệu được đánh dấu trong thứ tự các tương
tác.
Bước 3: với từng phần tử dữ liệu, các trình tự thực hiện liên quan tới phần tử dữ liệu được
đưa vào cùng một tập hợp trình tự.
Bước 4: từng tập hợp trình tự sẽ được phân tích & ghi nhận mối quan hệ logic giữa các

16
thành phần, trong đó các mối quan hệ logic tham chiếu tới phụ thuộc dữ liệu hoặc mối quan
hệ gọi thành phần giữa các thành phần liên quan tới người dùng.
Bước 5: với mỗi loại của thành phần dữ liệu, các hiệu ứng với các mối quan hệ logic tương
đồng sẽ được tìm ra, và nếu tần xuất của một mối quan hệ logic xuất hiện vượt quá ngưỡng
trung bình, nó sẽ được coi là một luật cho việc sinh ra test-case.
Bốn loại chính của luật được trích xuất ra trong nghiên cứu này là: DB_Rules, File_Rules,
Var_Rules & Com_Rules. Ví dụ với DB_Rules: tham chiếu tới các luật sinh test-case liên
quan tới cơ sở dữ liệu. Điều quan trọng nhất với DB_Rules là sự kết hợp không xác định
trước của việc tìm kiếm, thêm mới, cập nhật và xóa dữ liệu được kiểm tra một cách tự động.
Ngoài ra để đảm bảo tính toàn vẹn của các test-case sinh ra, thì tester dựa vào kinh nghiệm
của bản thân có thể bổ sung thêm các luật vào bộ sinh test-case.
3.3.4 Phân tích kết quả
Trước tiên ta nhận thấy việc xây dựng GUI ontology và quá trình trích xuất các luật sinh
test-case là bán tự động. Sau đó với công nghệ phân tích ngược sử dụng trong nghiên cứu
này yêu cầu phải có mã nguồn, một hệ thống phần mềm quản lý cơ bản được phát triển cho
một công ty truyền thông được chọn được làm nghiên cứu trong bài viết này, có 48 thành
phần tương tác đã được tìm thấy & 12 luật đã được sinh ra. Theo đó các test-case sẽ được
sinh ra từ các luật sinh này. Bên cạnh đó, các tester cũng bổ sung vào một số luật sinh dựa
trên kinh nghiệm.
3.3.5 Kết luận
Phần này đã đề cập tới một cách tiếp cận 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 các đặc tính tri thức chuyên sâu đưa vào 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ô tả như một dãy các thay đổi
đặc tả từ việc 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 hoàn thành bước 1.
Bước 2, và bước 3 được thực hiện nhiêu lần để tạo ra một bộ kiểm thử tóm tắt.
Bước 4 dựa trên bộ kiểm thử trừu tượng các bộ kiểm thử thực thi được tạo ra.
Trong mỗi bước thông tin đầu vào sau đó chuyển thành đầu ra theo sơ đồ sau
Bước1 - Test Objective Generation (mục tiêu kiểm thử): Đặc tả mô hình hành vi, tri thức
chuyên gia và độ bao phủ các quy tắc tiêu chuẩn được sử dụng để tạo ra một tập hơp các
mục tiêu kiểm thử.
Bước 2 – Kiểm tra dư thừa/ rườm rà: Đặc tả mô hình hành vi, mục 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 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à sinh ra các test case. Để khai thác tri thức 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 là tiêu chuẩn bao phủ được rộng rãi.
3.4.3 Thiết kế
Mô tả thiết kế prototype tự động dịch chuyển của các đặc tả dựa trên phương pháp ontology
base đã được trình bày phần trên. Hệ thống sẽ được thiết kế có 3 phần chính (như trên sơ
đồ): Test Objective Generation, Redundancy checking và Test Case Generation
Test Objective Generation: đảm nhiệm cho việc tự động trong pha xác định mục tiêu kiểm
19
thử dựa trên Behavioral model ontology, expert Knowledge ontology và coverage criteria
(phase 1)
Test Redundancy Checking : đảm nhiệm cho việc xử lý tự độ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 dựa trên Ontology
4.3.1 Ví dụ: quá trình thực hiện GUI test
Chương trình: tính lãi xuất cho tiền gửi kỳ hạn cố định
- Đầu vào: các ô nhập bao gồm
o Lãi xuất: 2% – 3%
o Khoản tiền: $1,000 – $10,000
o Kỳ hạn: 3 – 12 tháng
- Tác vụ: nút lệnh tính toán
o Nút “tính lãi xuất”

- Đầu ra: ô nhãn kết quả
o Nhãn “tổng tiền lãi”
Lưu ý: chỉ quan tâm tới các GUI quan trọng, bỏ qua các GUI khác: menu, màu nền, bố cục,
20
- Quá trình sử dụng:
o Mở chương trình
o Nhập 3 ô dữ liệu
o Nhấn nút tính & xem KQ
o Đóng chương trình
- Sinh testcase theo:
o Lãi xuất: bước tăng 0.1
o Khoản tiền: 500, 1000, 8000
o Kỳ hạn: 6, 12, 24
- Được 99 testcases
o TC 0
o TC 1
o …
o TC 98
21
4.3.2 Demo: Kiểm thử hệ thống ERP
Đặc tính chung của các hệ thống quản lý ERP:
- Hàng nghìn bảng CSDL
- Quy mô trăm triệu/tỷ bản ghi
- Phát sinh hàng chục GB/tháng
- Hàng trăm Form nhập liệu
- Hàng nghìn báo cáo nghiệp vụ
- Quy trình phức tạp liên hoàn
- Phục vụ hàng nghìn Users 24/7
Chất lượng
- Ảnh hưởng vô cùng lớn

- Chìa khóa để đảm bảo thành công
Chất lượng/Kiểm thử:
- Tập trung vào WHITE BOX testing
Phân tích ngược mã nguồn & cấu trúc dữ liệu
- Bỏ qua PHẦN LỚN những GUI trình bày/phi nghiệp vụ
- Tìm META DATA: những GUI trên các FORM
22
- Tìm META DATA: những GUI trên các BÁO CÁO
- Tìm META DATA: những TÁC VỤ nghiệp vụ
- Các META ITEM: xác định miền giá trị
 GUI/SYSTEM Ontology
Thực hiện sinh Testcases:
- Tester & BA Bổ sung ràng buộc dữ liệu
- Dựa trên Ontology/META INFO & ràng buộc: hệ thống tự SINH các testcases
- Tester & BA chọn lựa và viết điều kiện kiểm tra
- Các Testcases này sẽ được lưu lại, chỉnh sửa & chạy liên tục mỗi khi hệ thống có
sửa đổi
Giao diện cần kiểm thử
Phân tích mã nguồn
23
Sinh, sửa & chạy Testcases
Mã nguồn Testcases
24
<?xml version="1.0"?>
<Samples
xmlns:xsd=" />xmlns:xsi=" />instance"
TestID="a821fe63-9789-47e4-8f9d-afa1282de7fb"
xmlns="Core.Framework.Tests">
<Description xsi:nil="true" />
<Sample Name="Hưu trí">

<In>
<Item Name="Lop">
<Value>KhamNgoai</Value>
</Item>
<Item Name="NhomDtBhytLD">
<Value>66576</Value>
</Item>
<Item Name="DonViID">
<Value>28</Value>
</Item>
<Item Name="Loai">
<Value>3</Value>
</Item>
<Item Name="TuNgayGio">
<Value>20140604120000</Value>
</Item>
<Item Name="ToiNgayGio">
<Value>20140605120000</Value>
</Item>
</In>
<Out>S("C20")=="Nguyễn Thị Thuần" && S("I20")
== "04/06/2014"</Out>
<Description xsi:nil="true" />
</Sample>

25