Tìm hiểu và xây dựng ca kiểm thử phần mềm ứng dụng ontology

Mô hình kiểm thử phần mềm dựa trên ontology Việc sinh ca kiểm thử dựa trên tri thức kiểm thử là một yếu tố quan trọng cho việc mô phỏng các hệ thống phức tạp, ví dụ như các hệ thống tự đ

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC HÌNH VẼ 5

LỜI CAM ĐOAN 7

LỜI CẢM ƠN 8

MỞ ĐẦU 9

CHƯƠNG 1 11

TỔNG QUAN VỀ ỨNG DỤNG ONTOLOGY TRONG CÔNG NGHỆ PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM 11

1 Vai trò của ontology trong công nghệ phần mềm 11

2 Phân lo ại ontology trong quy trình phát triển phần mềm 13

3 Mô hình kiểm thử phần mềm dựa trên ontology 17

3.1 Giới thiệu mô hình áp dụng ontology 17

3.1.1 Mô hình dữ liệu mô phỏng hệ thống 17

3.1.2 Sinh bộ kiểm thử 19

3.2 Đánh giá phương pháp sinh ca kiểm thử dựa trên ontology 20

4 Mô hình ontology kiểm thử phần mềm 22

4.1 Khái niệm cơ bản 22

4.2 Khái niệm phức hợp 27

CHƯƠNG 2 29

CÁC NGHIÊN CỨU ỨNG DỤNG ONTOLOGY TRONG VIỆC SINH CA KIỂM THỬ 29

1 Phương pháp sinh ca kiểm thử dựa trên ontology 29

1.1 Phương pháp sinh ca kiểm thử cho các hệ thống cố định 29

1.1.1 Qui trình thực hiện 30

1.1.2 Các giai đoạn sinh ca kiểm thử thông qua ví dụ 32

1.1.3 Kết luận 35

1.2 Phương pháp sinh ca kiểm thử cho hệ thống đa tác tử 37

1.2.1 Hệ thống kiểm thử tích hợp ontology tương tác tử 38

1.2.2 Sinh ca kiểm thử dựa trên ontology 40

1.2.2.1.Ontology tương tác tử 40

1.2.2.2.Ontology chuyên sâu và s ự liên kết giữa các ontology 42

1.2.2.3.Qui trình thực hiện 42

1.2.3.Kết luận 45

1.3 Đánh giá 46

2 Phương pháp xây dựng ontology kiểm thử bán tự động 46

2.1 Tổng quan 46

2.2 Các bước thực hiện 48

2.2.1 Liệt kê các khái niệm quan trọng của lĩnh vực 48

2.2.2 Tạo đồ thị khía cạnh 52

2.3 Kết quả 55

CHƯƠNG 3 58

XÂY DỰNG ONTOLOGY VÀ MINH HOẠ CA KIỂM THỬ PHẦN MỀM 58

1 Qui trình xây dựng ontology 58

2 Thiết kế kiến trúc phân tầng và quan hệ trong ontology 61

2.1 Khái niệm tổng quát 61

2.2 Khái niệm cơ bản 62

2.3 Khái niệm về dữ liệu kiểm thử 62

2.4 Khái niệm về kỹ thuật kiểm thử 64

2.5 Khái niệm tổng hợp 66

2.6 Một số quan hệ cụ thể trong ontology 66

3 Xây dựng ontology trên Protege 71

3.1 Danh sách các lớp 71

3.1.1 Các lớp tổng quan 71

3.1.2 Các lớp khái niệm cơ bản về kiểm thử 72

3.1.3 Các khái niệm về dữ liệu kiểm thử 73

3.1.4 Các khái niệm kết hợp 76

3.1.5 Các khái niệm về kỹ thuật trong kiểm thử phần mềm 76

3.2 Danh sách thuộc tính kiểu đối tượng 77

3.3 Danh sách thuộc tính kiểu nguyên thủy 79

4 Tạo thể hiện cho ontology 80

5 Minh hoạ ca kiểm thử phần mềm 85

5.1 Tìm kiếm thông tin cho các ca kiểm thử của một chức năng c ụ thể 85

5.2 Tìm kiếm thông tin cho các ca kiểm thử phát sinh lỗi 87

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 90

1.Kết luận 90

2.Hướng phát triển 91 TÀI LIỆU THAM KHẢO 92

DANH MỤC CÁC HÌNH VẼ

Hình 1 Vai trò của Ontology trong Công Nghệ Phần Mềm 14

Hình 2 Mô hình hệ thống SAW 18

Hình 3 Mô hình quy trình xử lý 3 pha 20

Hình 4 Hình minh hoạ chi phí c ủa quá trình mô tả ca kiểm thử 21

Hình 5 Hình minh hoạ chi phí c ủa việc thêm một lượng lớn tham số 21

Hình 6 Các khái niệm cơ bản trong kiểm thử phần mềm 23

Hình 7 Các khái niệm liên quan đến Tester 23

Hình 8 Ngữ Cảnh kiểm thử 24

Hình 9 Các hoạt động kiểm thử 25

Hình 10 Các phương pháp kiểm thử 26

Hình 11 Các cấu phần sử dụng cho kiểm thử 26

Hình 12 Môi trường kiểm thử 27

Hình 13 Tác vụ kiểm thử 28

Hình 14 Qui trình sinh ca kiểm thử cho các hệ thống tập trung 31

Hình 15 Một ví dụ sinh ca kiểm thử dựa trên máy trạng thái UML 33

Hình 16 Ca kiểm thử t1 của bộ ca kiểm thử trừu tượng thoả mãn mục tiêu kiểm thử 34

Hình 17 Một phần của ca kiểm thử trừu tượng được tạo ra cho mục tiêu kiểm thử cho trước 35

Hình 18 Một phần của bộ ca kiểm thử có thể thực thi được tạo ra từ ca kiểm thử trừu tượng 35

Hình 19 Kiến trúc của Framework kiểm thử eCat 39

Hình 20 Hình minh hoạ Ontology tương tác trao đổi sách 41

Hình 21 Qui trình sinh ca kiểm thử cho hệ thống đa tác tử 43

Hình 22 Ví dụ về cấu trúc của từ điển 49

Hình 23 Danh sách từ và trọng số 51

Hình 24 Ontology kết quả 56

Hình 25 Các khái niệm tổng quát 61

Hình 26 Các khái niệm cơ bản 62

Hình 27 Các khái niệm về dữ liệu kiểm thử 63

Hình 28 Các khái niệm về thông tin đặc tả ca kiểm thử 64

Hình 29 Khái niệm kỹ thuật kiểm thử 65

Hình 30 Khái niệm tổng hợp 66

Hình 31 Quan hệ giữa dữ liệu kiểm thử và tài liệu tham chiếu 67

Hình 32 Quan hệ giữa Method, Approach và Technique 67

Hình 33 Quan hệ giữa dữ liệu trích xuất với thông tin đặc tả ca kiểm thử 69

Hình 34 Quan hệ giữa một số thông tin cơ bản 70

Hình 35 Quan hệ giữa thông tin đầu vào, đầu ra, mục đích test 70

Hình 36 Các lớp tổng quan 71

Hình 37 Các khái niệm cơ bản về kiểm thử 72

Hình 38 Các khái niệm về dữ liệu kiểm thử 73

Hình 39 Các khái niệm về dữ liệu 74

Hình 40 Các khái niệm về kỹ thuật kiểm thử 76

Hình 41 Danh sách thuộc tính kiểu đối tượng 77

Hình 42 Danh sách thuộc tính kiểu nguyên thuỷ 79

Hình 43 Minh hoạ trên Protege – Một Module bao gồm nhiều Function 81

Hình 44 Minh hoạ trên Protege – Một Function bao gồm nhiều Flow 82

Hình 45 Minh hoạ trên Protege – Thông tin c ủa Flow 83

Hình 46 Sơ đồ minh hoạ quan hệ giữa các thực thể trong ontology 84

Hình 47 Minh hoạ truy vấn trên Protege 87

Hình 48 Minh hoạ truy vấn trên Protege 89

LỜI CAM ĐOAN

Tôi cam đoan đây là công trình nghiên cứu của riêng tôi Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác

Hà Nội, ngày 25 tháng 03 năm 2014

Vũ Thị Thuý Hoàn

Học viên cao học khoá 2011B

Viện Công nghệ Thông tin và Truyền thông - Đại học Bách Khoa Hà Nội

LỜI CẢM ƠN

Trước hết, em xin được chân thành gửi lời cảm ơn sâu sắc tới các thầy cô giáo trong trường Đại học Bách Khoa Hà Nội nói chung và các thầy cô trong Viện Công nghệ Thông tin và Truyền thông, bộ môn Công nghệ phần mềm nói riêng đã tận tình giảng dạy, truyền đạt cho em những kiến thức, những kinh nghiệm quý báu trong suốt thời gian học tập tại trường

Em xin được gửi lời cảm ơn đến thầy Cao Tuấn Dũng - Giảng viên bộ môn Công nghệ phần mềm, Viện Công nghệ Thông tin và Truyền thông, trường Đại học Bách Khoa Hà Nội đã hết lòng giúp đỡ, hướng dẫn và chỉ dạy tận tình trong quá trình em làm luận văn tốt nghiệp

Cuối cùng, em xin được gửi lời cảm ơn chân thành tới gia đình đã tạo điều kiện

và giúp đỡ trong quá trình học tập, nghiên cứu và hoàn thành luận văn tốt nghiệp

MỞ ĐẦU

Trong lĩnh vực công nghệ phần mềm hiện nay, kiểm thử phần mềm đóng một vai trò hết sức quan trọng Việc kiểm thử phần mềm sẽ đảm bảo sản phẩm thỏa mãn yêu cầu của người sử dụng Tùy từng hệ thống, tùy từng yêu cầu mà việc kiểm thử sẽ có những mức độ khác nhau Tuy nhiên ở các công ty phần mềm hiện nay, kiểm thử phần mềm vẫn ở mức độ thủ công, do con người đảm nhiệm Tính liên kết, tái sử dụng, tự động trong kiểm thử phần mềm chưa được xem xét một cách đầy đủ và hệ thống Nhận thức được vấn đề này, người làm luận văn muốn tìm hiểu một công nghệ mới nhằm thúc đẩy và hỗ trợ kiểm thử phần mềm hiệu quả hơn

Trong quá trình học tập, người làm luận văn đã được làm quen với công nghệ web semantic và ontology Nhận thấy khả năng lưu trữ và truy vấn thông tin hiệu quả của ontology nên người làm luận văn đã quyết định lựa chọn đề tài tìm hiểu và xây dựng ca kiểm thử phần mềm ứng dụng ontology

Cùng với thời gian được học ở trường kết hợp với thời gian làm luận văn, người làm luận văn đã tìm hiểu những nghiên cứu về ứng dụng ontology và mong muốn phát triển một ứng dụng sinh ca kiểm thử tự động dựa trên ontology Tuy nhiên vì khả năng còn nhiều hạn chế nên mục đich của đề tài sẽ nhằm vào các nội dung cơ bản sau:

- Một là tổng hợp, phân tích những kết quả của thế giới trong việc ứng dụng ontology trong kiểm thử phần mềm

- Hai là thiết kế một ontology về lĩnh vực kiểm thử phần mềm nói chung

- Ba là minh họa một số kịch bản kiểm thử đơn giản sử dụng ontology đã thiết

kế

Với mục đích như trên, nội dung luận văn phát triển bao gồm 3 chương:

- Chương 1: Tổng quan về ứng dụng ontology trong công nghệ phần mềm và kiểm thử phần mềm

- Chương 2: Các nghiên cứu ứng dụng ontology trong việc sinh ca kiểm thử

- Chương 3: Xây dựng ontology và minh hoạ ca kiểm thử phần mềm

mô hình tổng quát ứng dụng ontology trong hoạt động kiểm thử, đồng thời giới thiệu một thiết kế về ontology kiểm thử đã có sẵn nhằm đưa ra những thông tin ban đầu về việc ứng dụng ontology trong kiểm thử phần mềm

1 Vai trò của ontology trong công nghệ phần mềm

Web ngữ nghĩa là thế hệ thứ 2 của Web dùng để chia sẻ và tái sử dụng dữ liệu trong các ứng dụng, doanh nghiệp hay cộng đồng giới hạn nào đó Một thành phần quan trọng của web ngữ nghĩa đó là ontology Trong khoa học máy tính và công nghệ thông tin, ontology là dạng biểu diễn một tập các khái niệm trong một lĩnh vực nào đó

và mối quan hệ giữa các khái niệm Sự biểu diễn này là ở mức ngữ nghĩa, độc lập với cấu trúc dữ liệu và xử lý Được định nghĩa như là tri thức ở một lĩnh vực cụ thể, ontology có khả năng suy diễn về các đặc điểm của lĩnh vực đó Thêm vào đó, nó có thể tích hợp các dữ liệu không đồng nhất và gắn kết các hệ thống khác nhau Các chuẩn W3C cho web ngữ nghĩa bao gồm Web Ontology Language (OWL), Resource Description Framework (RDF), … OWL là ngôn ngữ đặc tả ontology và RDF là ngôn ngữ mô tả tài nguyên tồn tại trong web Web ngữ nghĩa đã khắc phục được hạn chế của ngôn ngữ tự nhiên trong việc mô tả các nội dung một cách chuẩn mực, chính xác, rõ ràng Ngoài ra, nó còn lưu trữ thông tin theo định dạng mà các công cụ tự động có thể

hiểu và xử lý được Nó cung cấp một nền tảng tích hợp mà thông tin được tổ chức tốt, được phân phối, chia sẻ rộng rãi, truy vấn dễ dàng và tích hợp đơn giản

Phát triển phần mềm là quy trình phức tạp, tạo ra một lượng lớn thông tin Những phương thức tiếp cận ngữ nghĩa, chặt chẽ và cụ thể đã trở nên rất cần thiết cho sự phát triển, xử lý và bảo trì các hệ thống phần mềm Và nỗ lực cải thiện quy trình phần mềm

đã phần nào đó có hiệu quả Ví dụ, ngôn ngữ mô hình hóa được đề xuất để mô tả thiết

kế hệ thống tốt hơn; các môi trường phát triển tích hợp được tạo ra để việc thực thi thuận lợi hơn; các công cụ để quản lý các loại cấu phần phần mềm khác nhau cũng được phát triển Tuy nhiên phát triển phần mềm vẫn còn nhiều khó khăn

Thứ nhất, quy trình phần mềm tốn nhiều chi phí cho việc thu thập và sản xuất thông tin Việc sử dụng lại những thông tin đã có sẽ tiết kiệm được chi phí Phạm vi tái

sử dụng được mở rộng từ tái sử dụng những đoạn mã chương trình cho tới tái sử dụng các nội dung thông tin như là tài liệu yêu cầu chức năng, quy trình dự án và tài liệu thiết kế phần mềm Tuy nhiên cách biểu diễn thông tin hiện nay làm cho việc quản lý, truy vấn và tái sử dụng trở nên khó khăn Một phương thức để việc truy vấn và tái sử dụng thông tin thuận lợi hơn trở thành một yêu cầu cấp thiết

Thứ hai, do tính toàn cầu hóa, các hệ thống phần mềm thường được phát triển bởi nhiều nhóm ở các nơi khác nhau Do đó, có nhiều quy trình khác nhau được sử dụng Các nhóm ở các vùng khác nhau có thể sử dụng khác quy trình khác nhau và cũng dẫn tới những nhận thức khác nhau Vì vậy việc chia sẻ thông tin sẽ hạn chế được sự không thống nhất

Chia sẻ và tái sử dụng thông tin mang lại những lợi ích như cải thiện hiệu suất, rút gọn vòng đời phát triển phần mềm, giảm chi phí, tăng chất lượng sản phẩm Với yêu cầu đó, web ngữ nghĩa và ontolgy sẽ cung cấp phương thức để cải thiện việc chia sẻ và tái sử dụng thông tin Ontology được sử dụng để mô hình hóa tri thức công nghệ phần

mềm bằng cách chỉ ra các cấu phần được thiết kế, được sản xuất trong suốt quy trình

kỹ thuật Web ngữ nghĩa cho phép công khai các nguồn tài nguyên tri thức công nghệ phần mềm có khả năng tái sử dụng Với sự hỗ trợ của các ontology liên quan đến công nghệ phần mềm, web ngữ nghĩa cho phép truy vấn và suy diễn trên tri thức công nghệ phần mềm một cách thông thường hoặc bằng các tác nhân phần mềm khác

2 Phân loại ontology trong quy trình phát triển phần mềm

Ontology được ứng dụng vào công nghệ phần mềm với nhiều mục đích, nhằm giải quyết nhiều vấn đề còn tồn tại của công nghệ phần mềm Những ưu điểm của ontology được coi là cơ sở quan trọng để ứng dụng vào công nghệ phần mềm:

 Tính chuẩn hoá: ontology được W3C đề xuất mô tả theo định dạng RDF

và OWL nhằm chuẩn hoá định dạng thông tin

 Tính linh hoạt: kết hợp dữ liệu từ nhiều nguồn, suy luận ra nhiều tri thức mới, dễ dàng mở rộng ontology, tái sử dụng ontology

 Tập trung vào mô hình nghiệp vụ - yếu tố quan trọng nhất của các hệ thống phần mềm : đưa ra các khái niệm thống nhất, rõ ràng về các mô hình nghiệp vụ

Có 2 hướng để phân loại ontology trong công nghệ phần mềm:

 Theo vai trò của ontology trong vòng đời phát triển phần mềm: thời điểm phát triển và thời điểm hoạt động

 Theo loại tri thức được mô tả: phần mềm và cơ sở hạ tầng

Kết hợp 2 định hướng trên, ta có 4 lĩnh vực cơ bản sau:

Hình 1 Vai trò của Ontology trong Công Nghệ Phần Mềm

 ODD – Ontology-driven Development : sử dụng ontology khi phát triển và

mô tả các vấn đề nghiệp vụ

 OED – Ontology-Enabled Development : sử dụng ontology khi phát triển,

mô tả các cơ sở hạ tầng liên quan, hỗ trợ coding

 OBA – Ontology-Based Architecture : sử dụng ontology khi hoạt động,

mô tả các logic nghiệp vụ

 OEA – Ontology-Enabled Architecture : sử dụng ontology ở thời điểm thực thi, mô tả các cơ sở hạ tầng cho việc thực thi

Ngoài ra có một số phương pháp khác để phân loại các ontology, ví dụ như phân loại theo các giai đoạn sản xuất phần mềm; phân loại theo loại thông tin mà chúng mô hình hoá; phân loại theo phạm vi ứng dụng của chúng Ta có thể tóm tắt phân loại các ontology như bảng thống kê dưới đây: các cột từ 3 đến 5 liệt kê sự phân loại ontology theo 3 tiêu chí đã nói ở trên

STT Ontology Giai đoạn phát triển

phần mềm

Phân loại thông tin

Phạm vi ứng dụng

3 Ontology mô hình đặc

điểm miền ứng dụng

Đặc tả yêu cầu chức năng

Lĩnh vực cụ thể /Sản phẩm

Đặc tả miền thông tin

4 Ontology hệ thống hành

5 Ontology kiến trúc hệ

6 Ontology lgic ứng dụng Thiết kế Sản phẩm Khởi tạo

7 Ontology thiết kế hướng đối tượng Thiết kế Sản phẩm

Đặc tả hệ thống hướng đối

9 Ontology cấu phần

10 Ontology mã nguồn hướng đối tượng Thực thi Sản phẩm

Đặc tả hệ thống hướng đối tượng

11 Ontology phiên bản Thực thi Quản lý và hỗ

12 Ontology cấu hình hệ

13 Ontology văn bản hoá

14 Ontology tài liệu Thực thi Quản lý và hỗ

15 Ontology chất lượng Toàn bộ Quản lý và hỗ

16 Ontology kiểm thử Kiểm thử Quản lý và hỗ

Ontology quy trình bảo

19 Ontology công nghệ Toàn bộ Công nghệ Tổng quát

3 Mô hình kiểm thử phần mềm dựa trên ontology

Việc sinh ca kiểm thử dựa trên tri thức kiểm thử là một yếu tố quan trọng cho việc mô phỏng các hệ thống phức tạp, ví dụ như các hệ thống tự động hoá sản xuất Hiện tại có hai cách tiếp cận để sinh ca kiểm thử Thứ nhất là phương pháp truyền thống, phương pháp này dựa trên việc tạo các kịch bản kiểm thử một cách thủ công, tốn nhiều chi phí để thêm các tham số Thêm vào đó, người sử dụng phải có kĩ năng lập trình như là thiết đặt, chỉnh sửa tham số Thứ hai là phương pháp dựa trên ontology, sử dụng cơ chế sinh kịch bản kiểm thử một cách tự động bằng cách sử dụng ontology như một mô hình dữ liệu Các ca kiểm thử được tạo ra phụ thuộc vào việc lựa chọn tham số của người sử dụng

So với phương pháp truyền thống, phương pháp sử dụng ontology mang lại những lợi ích cơ bản sau:

 Tính khả thi: phương pháp sử dụng ontology hướng đến mục tiêu vượt qua được những hạn chế của phương pháp truyền thống Đầu tiên là cung cấp mô

tả kiểm thử ở mức độ cao hơn, tạo ra những ca kiểm thử với chi phí thấp hơn Thứ hai là kiểm tra tính đúng đắn và tính ràng buộc của việc thiết đặt tham số nhằm giảm bớt nguy cơ có thể gây lỗi trong quá trình sinh ca kiểm thử

 Tiềm năng lợi ích về chi phí

3.1 Giới thiệu mô hình áp dụng ontology

Phần này sẽ trình bày một mô hình mô phỏng hoạt động của một hệ thống áp dụng ontology để sinh ca kiểm thử [7]

3.1.1 Mô hình dữ liệu mô phỏng hệ thống

Hệ thống mô phỏng hoạt động của một phân xưởng sản xuất giả lập - SAW (Simulation of Assembly Workshop) sử dụng kiến trúc ontology 5 tầng dưới dạng một

mô hình dữ liệu

Hình 2 Mô hình hệ thống SAW

 Tầng nghiệp vụ: tập trung vào các đơn đặt hàng đến hạn thanh toán

 Tầng ca làm việc: kiểm tra tài nguyên sử dụng cho các sản phẩm đã được đặt hàng Ngoài ra còn kiểm tra việc chuyển các đơn đặt hàng thành đơn đặt hàng sản xuất

 Tầng điều tiết: các đơn đặt hàng sản xuất được chia nhỏ theo các chiến lược sản xuất

 Tầng thực thi: thực thi công việc bằng các máy móc sẵn có một cách hiệu quả nhất

 Tầng dữ liệu chung: chứa tất cả các thông tin

Để cung cấp chức năng sinh ca kiểm thử tự động dựa trên ontology, sẽ thực hiện thêm tầng ca kiểm thử vào mô hình SAW ở trên Tầng ca kiểm thử cùng với kịch bản

sinh ca kiểm thử tương ứng sẽ cung cấp các ca kiểm thử chất lượng cao theo cách thức

hệ thống và tự động hoá Người sử dụng có thể quyết định việc muốn sinh ca kiểm thử một cách thủ công hay là sử dụng sinh ca kiểm thử tự động Trong trường hợp sử dụng sinh ca kiểm thử tự động thì phải thiết đặt tham số và giá trị tham số tương ứng Sau đó

bộ sinh ca kiểm thử sẽ tạo ca kiểm thử tương ứng với tham số đã được thiết đặt

3.1.2 Sinh bộ kiểm thử

Phương pháp dựa trên ontology trước hết cần một giao diện có thể điều chỉnh thông tin liên quan đến các tham số Phương pháp này sẽ truy xuất các tham số, các giá trị cho phép của tham số và thông tin có cấu trúc từ mô hình dữ liệu cơ bản Sau đó những thông tin chính xác sẽ được truyền vào ontology thông qua giao diện Điều này tạo ra một giao diện động tương ứng với ontology tại thời điểm thực thi

Nói cách khác, phương pháp dựa trên ontology sử dụng cấu trúc của ontology và các ràng buộc để đảm bảo tính thống nhất của các ca kiểm thử Các miền dữ liệu của các tham số được sử dụng để đảm bảo tính chính xác của các ca kiểm thử Tuy nhiên người sử dụng phải biết quản lý ontology Do đó họ cần có kĩ năng chỉnh sửa ontology bằng các công cụ phổ biến như Protege

Bằng cách sử dụng phương pháp dựa trên ontology, người sử dụng luôn có thể lựa chọn tất cả các tham số được hỗ trợ bởi kịch bản sinh ca kiểm thử để định nghĩa việc thiết đặt tham số Thêm vào đó phương pháp này còn đảm bảo việc thiết đặt tham

số có giá trị đúng và phù hợp Dựa trên các tham số đã được thiết đặt, kịch bản kiểm thử sẽ tạo ra các ca kiểm thử tương ứng Và sản phẩm cuối cùng của cơ chế tự động là tạo ra file XML

Mô hình tổng quan về quy trình xử lý 3 pha của phương pháp sinh ca kiểm thử dựa trên ontology:

Hình 3 Mô hình quy trình xử lý 3 pha

Ưu điểm của mô hình này là pha thứ nhất và pha thứ hai hoàn toàn độc lập với nhau Điều này đảm bảo miền thông tin là ẩn với ontology Pha đầu tiên tương tác với ontology và đưa tên thành phần, các giá trị hợp lệ cho thể hiện của thành phần và thông tin về ontology cho pha thứ hai Sau đó, pha thứ hai sẽ sử dụng những thông tin nhận được để tạo một giao diện động tại thời điểm thực thi Người sử dụng có thể thiết đặt pha thứ ba dựa trên mô hình dữ liệu một cách dễ dàng

3.2 Đánh giá phương pháp sinh ca kiểm thử dựa trên ontology

Thực hiện đánh giá dựa trên 3 tiêu chí sau:

 Chi phí để mô tả việc cấu hình tham số dùng cho việc sinh ca kiểm thử

 Chi phí triển khai tham số xác định cụ thể tương ứng với từng cấp độ

 Phí đầu tư (Return on Investment - ROI): được tính dựa trên việc sử dụng các công nghệ khác nhau

Sau đây sẽ minh hoạ chi phí của quá trình mô tả ca kiểm thử và chi phí triển khai tham số Về phí đầu tư liên quan đến công nghệ cụ thể của từng hệ thống thì không xem xét ở đây

Hình 4 Hình minh hoạ chi phí của quá trình mô tả ca kiểm thử

Hình 5 Hình minh hoạ chi phí của việc thêm một lượng lớn tham số

Dựa trên đồ thị minh hoạ ở trên, ta nhận thấy rằng, so với phương pháp thủ công thì phương pháp sinh ca kiểm thử tự động dựa trên ontology ưu thế hơn về mặt chi phí khi mô tả ca kiểm thử và khi thêm một số lượng lớn tham số

4 Mô hình ontology kiểm thử phần mềm

Ontology kiểm thử phần mềm [5] định nghĩa các khái niệm liên quan đến kiểm thử như là người kiểm thử, môi trường, ngữ cảnh, thành phần để việc kiểm thử được thực hiện, phương pháp kiểm thử và hoạt động Mỗi khái niệm được định nghĩa chi tiết bằng các khái niệm con Ví dụ các ngữ cảnh kiểm thử bao gồm kiểm thử đơn (unit testing), kiểm thử tích hợp (integration testing), kiểm thử hệ thống (system testing), … Hoạt động bao gồm lập kế hoạch, tạo ca kiểm thử, thực thi và xác nhận

Để biểu diễn ontology, XML được xem là định dạng phù hợp vì tính đơn giản, dễ định nghĩa, khả năng mở rộng và đặc biệt là phù hợp với các ứng dụng web Người sử dụng có thể định nghĩa các thẻ, các định dạng để biểu diễn các khái niệm đơn giản và các cấu trúc phức tạp Tuy nhiên biểu diễn ontology dưới dạng XML là hình thức biểu diễn ở mức độ trừu tượng thấp Để biểu diễn ontology ở mức độ trừu tượng cao thì chúng ta cần một ngôn ngữ mô hình hoá mạnh như UML Sau đây sẽ trình bày ontology kiểm thử phần mềm bằng ngôn ngữ UML

Các khái niệm trong kiểm thử phần mềm được phân thành 2 loại sau: khái niệm

cơ bản và khái niệm phức hợp

4.1 Khái niệm cơ bản

Khái niệm cơ bản trong kiểm thử phần mềm bao gồm: tester, context, activities, methods, artefacts và environement

Hình 6 Các khái niệm cơ bản trong kiểm thử phần mềm

Với mỗi khái niệm cơ bản sẽ có một vài khái niệm con tương ứng Cụ thể như sau:

 Tester: khái niệm liên quan đến các đối tượng thực thi các hoạt động kiểm

thử Tester có thể là con người hoặc là công cụ thực hiện test hoặc có thể là một nhóm bao gồm nhiều tester

Hình 7 Các khái niệm liên quan đến Tester

Ví dụ mô tả bằng định dạng XML một đối tượng tester là con người có tên là như sau:

<TESTER TESTER_TYPE="HUMAN" TESTER_NAME="Howard" />

Ví dụ mô tả bằng định dạng XML một đối tượng tester là một nhóm với trưởng nhóm là Joe, thành viên là một phần mềm hỗ trợ như sau:

<TESTER TESTER_TYPE="TEAM" TESTER_NAME="ATEAM" TESTER_LEADER="JOE">

<TESTER TESTER_TYPE="HUMAN" TESTER_NAME="JOE" />

<TESTER TESTER_TYPE="SOFTWARE" TESTER_NAME="ANAGENT" />

 Activity: bao gồm các hoạt động chính của kiểm thử phần mềm

Test Planning: lập kế hoạch kiểm thử

Testcase Generation: sinh ca kiểm thử

Test Execution: thực thi kiểm thử (chạy các ca kiểm thử)

Testresult Validation: xác nhận kết quả kiểm thử

Adequacy Measurement: đánh giá đầy đủ về chất lượng kiểm thử

Report Generation: tạo báo cáo

Hình 9 Các hoạt động kiểm thử

 Method: bao gồm các khái niệm về các phương pháp thực hiện kiểm thử

Spec Based Structural Testing: kiểm thử dựa trên tài liệu đặc tả yêu cầu

Program Based Structural Testing: kiểm thử dựa trên chương trình (design chi tiết)

Control Flow Testing: kiểm thử luồng điều khiển

Branch Coverage: bao phủ rẽ nhánh (C1)

Statement Coverage: bao phủ dòng lệnh (C0)

Data Flow Testing: kiểm thử luồng dữ liệu

 Environment: bao gồm các khái niệm về môi trường thực thi kiểm thử

Hình 12 Môi trường kiểm thử

o Bao gồm một Activity, có thể là tạo tetscase, tạo test report, …

o Có hoặc không có hoàn cảnh thực hiện cụ thể Nếu là tạo ca kiểm thử thì cần xác định hoàn cảnh là unit test hay integration test, …

o Có hoặc không có phương thức thực hiện cụ thể

o Bao gồm một hoặc nhiều dữ liệu kiểm thử

1 Phương pháp sinh ca kiểm thử dựa trên ontology

Các hệ thống phần mềm phổ biến hiện nay có thể phân thành hai nhóm cơ bản là

cố định và phân tán Đối với các hệ thống phần mềm khác nhau thì sẽ có những phương pháp khác nhau để ứng dụng ontology trong việc sinh ca kiểm thử Các hệ thống cố định thường có nghiệp vụ phức tạp, cần sử dụng linh hoạt nhiều mô hình ontology khác nhau để mô tả và sinh ca kiểm thử Phần này sẽ giới thiệu phương pháp sinh ca kiểm thử dựa trên công nghệ tri thức (knowledge engineering) hỗ trợ sinh ca kiểm thử cho các hệ thống cố định [8] So với hệ thống cố định thì hệ thống phân tán thường có nghiệp vụ đơn giản hơn nhưng có nhiều hạn chế vì các tác tử ở các địa điểm khác nhau dẫn đến việc trao đổi thông tin sẽ khó khăn Do đó đối với hệ thống phân tán thì việc yêu cầu có một ontology dùng chung giữa các tác tử khác nhau là hết sức quan trọng Phương pháp sinh ca kiểm thử sử dụng ontology tương tác tử sẽ giải quyết phần nào khó khăn cho hệ thống phân tán [2]

1.1 Phương pháp sinh ca kiểm thử cho các hệ thống cố định

Phương pháp sinh ca kiểm thử cho các hệ thống cố định [8] sử dụng công nghệ tri thức, thực hiện tách rời các thuật toán lựa chọn kiểm thử với nguồn tri thức được sử dụng để lựa chọn kiểm thử Sự phân tách này cho phép chuyên gia kiểm thử có thể tự

do điều chỉnh ontology dựa trên đặc tả của những đối tượng cần được kiểm thử mà không cần sửa thuật toán lựa chọn kiểm thử Để làm được điều này, các ontology và các luật được sử dụng để chỉ định cái gì cần được kiểm thử và các thuật toán suy diễn được sử dụng để lựa chọn các mô tả mức cao của các ca kiểm thử, được gọi là các mục tiêu kiểm thử Các mục tiêu kiểm thử được lựa chọn sẽ được dịch thành các ca kiểm thử trừu tượng Các ca kiểm thử trừu tượng này sẽ được thể hiện trong một ontology cho phép suy diễn để kiểm tra sự trùng lặp Cuối cùng, các ca kiểm thử có khả năng thực thi sẽ được sinh ra từ ontology của các ca kiểm thử trừu tượng

1.1.1 Qui trình thực hiện

Qui trình sinh ca kiểm thử bao gồm 4 giai đoạn cụ thể như sau:

Giai đoạn 2: Kiểm tra

dư thừa Các mục tiêu kiểm thử

Giai đoạn 3: Sinh ontology kiểm thử trừu tượng

Ontology tri thức thực

thi

Ontoloy chứa các ca kiểm thử trừu tượng

Giai đoạn 4: Sinh các

ca kiểm thử có khả năng thực thi

Các ca kiểm thử có khả năng thực thi

Ontology mô hinh hành

vi

Các luật kiểm tra dư

thừa

Hình 14 Qui trình sinh ca kiểm thử cho các hệ thống tập trung

Giai đoạn 1: Sinh mục tiêu kiểm thử

Những mô tả dựa trên ontology của các đối tượng cần kiểm thử bao gồm: những đặc tả mô hình hành vi, tri thức chuyên gia, và các luật bao phủ Những mô tả này được sử dụng để sinh ra một tập các mục tiêu kiểm thử Giai đoạn này được thực hiện bằng cách suy diễn trên các ontology mô tả các đặc tả

Giai đoạn 2: Kiểm tra dư thừa

Với mọi mục tiêu kiểm thử, một luật kiểm tra dư thừa được áp dụng để kiểm tra xem mục tiêu đó có thể thoả mãn bằng một ca kiểm thử đã có hay không Ca kiểm thử này nằm trong một ontology của bộ ca kiểm thử trừu tượng Giai đoạn này cũng được thực hiện bằng cách suy diễn trên các ontology

Giai đoạn 3: Sinh ontology kiểm thử trừu tượng

Với mỗi mục tiêu kiểm thử (không dư thừa), một ca kiểm thử trừu tượng được tạo

ra và được thêm vào ontology kiểm thử trừu tượng Giai đoạn này được thực hiện bằng cách sử dụng các phương pháp sinh ca kiểm thử phổ biến (Ví dụ như các thuật toán duyệt đồ thị)

Giai đoạn 4: Sinh các ca kiểm thử có khả năng thực thi

Với mọi ca kiểm thử trừu tượng trong ontology kiểm thử trừu tượng, một ca kiểm thử có khả năng thực thi được sinh ra bằng cách sử dụng ontology tri thức thực thi Giai đoạn 1 tạo ra một tập các mục tiêu kiểm thử, sau khi giai đoạn 1 kết thúc, giai đoạn 2 và 3 được thực hiện lặp lại để sinh ra một bộ ca kiểm thử trừu tượng Sau

đó ở giai đoạn 4, dựa trên bộ ca kiểm thử trừu tượng đã có, bộ ca kiểm thử có thể thực thi được tạo ra

1.1.2 Các giai đoạn sinh ca kiểm thử thông qua ví dụ

Phần này sẽ mô tả các giai đoạn của sinh ca kiểm thử từ các đặc tả bằng cách sử dụng một ví dụ đơn giản của Unit Test dựa trên máy trạng thái UML

Trong giai đoạn 1, các mục tiêu kiểm thử được tạo ra, sự lựa chọn ca kiểm thử ban đầu được thực hiện bằng cách sử dụng suy diễn và kết quả là các bộ test ở mức cao được thể hiện bằng một tập các mục tiêu kiểm thử

Hình dưới đây mô tả một ví dụ sinh ca kiểm thử dựa trên máy trạng thái UML Trong ví dụ này, những mục tiêu kiểm thử mà xác định kiểm thử phải qua transition t1

và t2 của máy trạng thái, sẽ được tạo ra

Hình 15 Một ví dụ sinh ca kiểm thử dựa trên máy trạng thái UML

Trong giai đoạn 2, kiểm tra trùng lặp được thực hiện, với mỗi mục tiêu kiểm thử, suy diễn được sử dụng trên một phần ontology của bộ test trừu tượng được tạo ra ở trên, để kiểm tra sự tồn tại của một ca kiểm thử thoả mã mục tiêu kiểm thử

Hình dưới mô tả một ví dụ, trong đó ca kiểm thử test1 của bộ ca kiểm thử trừu tượng thoả mãn mục tiêu kiểm thử : ca kiểm thử phải qua giao dịch transition t1 Vì vậy mục tiêu kiểm thử này bị bỏ qua Tiếp theo, một luật kiểm tra trùng lặp khác được tạo ra để kiểm tra mục tiêu kiểm thử khác Mục tiêu kiểm thử: ca kiểm thử phải qua giao dịch t2 của máy trạng thái – mục tiêu này không được thoả mãn bởi một ca kiểm thử đã có vì vậy nó được cho qua giai đoạn 3 của phương pháp sinh ca kiểm thử

Hình 16 Ca kiểm thử t1 của bộ ca kiểm thử trừu tượng thoả mãn mục tiêu kiểm

thử

Trong giai đoạn 3, việc sinh ca kiểm thử trừu tượng sử dụng các phương pháp sinh ca kiểm thử từ các tài liệu của cấu phần phần mềm (ví dụ như duyệt cây đồ thị đối với máy trạng thái UML) Các ca kiểm thử trừu tượng được tạo ra với mục tiêu kiểm thử cho trước và được thêm vào ontology ca kiểm thử trừu tượng

Hình dưới mô tả một phần của ca kiểm thử trừu tượng được tạo ra cho mục tiêu kiểm thử cho trước và được thêm vào ontology

Hình 17 Một phần của ca kiểm thử trừu tượng được tạo ra cho mục tiêu kiểm thử

cho trước

Trong giai đoạn 4, để tạo ra các bộ ca kiểm thử thực thi được thì ontology tri thức thực thi được sử dụng nhằm tạo ra bộ ca kiểm thử có thể thực thi từ ontology bộ ca kiểm thử trừu tượng

Hình dưới mô tả một phần của bộ ca kiểm thử có thể thực thi được tạo ra từ ca kiểm thử trừu tượng

Hình 18 Một phần của bộ ca kiểm thử có thể thực thi được tạo ra từ ca kiểm thử

trừu tượng

1.1.3 Kết luận

Mục tiêu của phương pháp này là cung cấp một nền tảng có thể mở rộng bằng các đặc tả cho các luật tiêu chí bao phủ tuỳ biến Để có thể mở rộng hệ thống thì có thể chỉ định các luật tiêu chí bao phủ tương ứng trong logic của ngôn ngữ lập trình và tạo ra

các tri thức tham chiếu đến các ontology tri thức chuyên gia Vì vậy, phương pháp này phụ thuộc vào các luật và các ontology được mô tả trong nó

Thêm vào đó, phương pháp này có thể được áp dụng vào nhiều lĩnh vực, như kiểm thử giao điện, kiểm thử song song, mạng, Để áp dụng phương pháp vào các lĩnh vực khác nhau, tri thức về các khía cạnh dễ bị lỗi của lĩnh vực cần được bổ sung vào ontology tri thức chuyên gia của lĩnh vực Các tiêu chí bao phủ mới được định nghĩa dựa trên vốn từ được định nghĩa trong ontology mô hình hành vi và tri thức chuyên gia Tương tự, các ca kiểm thử có thể được chỉ định thủ công bằng việc chỉ định các mục tiêu kiểm thử thủ công Thêm nữa, các luật có thể được định nghĩa để hỗ trợ các luật bao phủ tiêu chuẩn

Tuy nhiên phương pháp này có một số giới hạn nhất định, cụ thể như sau:

- Kiểm tra trùng lặp không tối ưu: Việc kiểm tra trùng lặp này chỉ kiểm tra xem mục tiêu kiểm thử có được thoả mãn bởi bộ ca kiểm thử có sẵn hay không chứ không kiểm tra được là mục tiêu có được thoả mãn bởi một bộ ca kiểm thử sẽ được tạo ra Do đó thứ tự của mục tiêu kiểm thử ảnh hưởng đến kích thước của bộ ca kiểm thử sinh ra

- Thời gian hiệu quả: Càng nhiều thứ cần kiểm thử, thì thời gian để sinh ca kiểm thử càng lâu do việc sử dụng bộ suy diễn Với các hệ thống lớn, sử dụng phương pháp này sẽ không tối ưu

- Mô hình hoá phức tạp: Độ phức tạp của các mô hình là một thử thách, tuy nhiên có thể khắc phục thông qua các công cụ tự động sinh mô hình từ các tài nguyên có sẵn: mã nguồn, tài liệu,

- Giới hạn về logic lập trình: Viết các luật có thể sẽ rất phức tạp và khả năng biểu diễn của các luật bị giới hạn bởi các thuật toán suy diễn Ràng buộc của khả năng biểu diễn các luật sẽ giới hạn các luật tiêu chí bao phủ và luật kiểm tra trùng lặp có thể được hỗ trợ bởi hệ thống

1.2 Phương pháp sinh ca kiểm thử cho hệ thống đa tác tử

Việc kiểm thử cho hệ thống đa tác tử (MAS – Multi Agent System) hiện nay đang gặp nhiều thách thức xuất phát từ chính những đặc điểm của hệ thống Hệ thống đa tác

tử là các hệ thống phân tán, độc lập, hoạt động trong thế giới mở, yêu cầu phải có nhận thức về ngữ cảnh xung quanh, chúng có thể giao tiếp bằng cách sử dụng các giao thức tương tác ở cấp độ cao và có thể phải đối diện với những vấn đề về khả năng tương tác ngữ nghĩa Những đặc điểm này được xem là khó để thiết kế và lập trình nhưng vẫn có thể kiểm thử được

Những nghiên cứu gần đây về kiểm thử trên hệ thống đa tác tử cho thấy các cách tiếp cận đều thực hiện bằng cách gửi thông điệp đến tác tử cần kiểm thử và tạo ra một giao thức tương tác Sau đó sẽ đánh giá thông điệp phản hồi trở lại có đúng với kết quả mong đợi hay không Tuy nhiên những vấn đề liên quan đến việc sinh ca kiểm thử, trong đó bao gồm việc làm thế nào để tạo những dữ liệu đầu vào hợp lệ và không hợp

lệ một cách hiệu quả để kiểm tra triệt để các hành vi của hệ thống đa tác tử thì phần lớn vẫn chưa được khai phá

Hành vi của tác tử thường phụ thuộc vào thông điệp nhận được Do đó nội dung cốt lõi của việc sinh ca kiểm thử đó là xây dựng chuỗi các thông điệp để kiểm thử cũng như bao phủ hầu hết các điều kiện có thể để thực thi Thông thường lỗi chỉ xuất hiện sau một chuỗi dài các hoạt động kiểm tra và trong điều kiện, môi trường cụ thể Vấn đề chính của kiểm thử tác tử là khả năng thực hiện những tương tác trong thời gian dài với

hệ thống cần kiểm thử Điều này đòi hỏi phương pháp tự động sinh ca kiểm thử để có thể vượt qua được giới hạn về số lượng trường hợp cần được xem xét trong phương pháp kiểm thử thủ công

Việc sinh ca kiểm thử tự động cần khả năng điền thông tin vào các mẫu thông điệp với dữ liệu đầu vào có nghĩa, đa dạng và đủ để kích hoạt các phản ứng của hệ tác

tử cần kiểm thử Các phương pháp sinh thủ công và ngẫu nhiên chỉ bao phủ thông tin một cách giới hạn, nguyên nhân là do: dữ liệu nhập vào thủ công thường là một tập hợp nhỏ, dữ liệu nhập vào ngẫu nhiên không đảm bảo được ngữ nghĩa của thông điệp

Để giải quyết vấn đề tạo thông tin đầu vào có ý nghĩa, phần trình bày này sẽ nói

về việc sử dụng ưu điểm của ontology tương tác tử Phương pháp dựa trên ontology tương tác tử [2] cho phép sinh tự động cả giá trị đầu vào hợp lệ và không hợp lệ, hướng dẫn việc khai thác thông tin đầu vào và xác nhận kết quả kiểm thử

1.2.1 Hệ thống kiểm thử tích hợp ontology tương tác tử

Phần này giới thiệu về hệ thống kiểm thử eCat – hệ thống tích hợp công nghệ ontology, hỗ trợ việc sinh ca kiểm thử và thực hiện kiểm thử liên tiếp Framework này

có 2 đặc điểm chính:

- Sinh ca kiểm thử và thực thi chúng một cách liên tục

- Kiến trúc gồm 2 thành phần chính: Tác tử Tester và Tác Tử Điều khiển

Hình 19 Kiến trúc của Framework kiểm thử eCat

Trong khi các tác tử giao tiếp với nhau thông qua việc gửi nhận các thông điệp, thì tác tử Tester có thể gửi các thông điệp đến các tác tử khác để kích hoạt một hành vi

có thể giúp cho việc phát hiện ra lỗi Đến lượt mình, tác tử Điều Khiển theo dõi các phản ứng với các thông điệp gửi bởi tác tử Tester và trong trường hợp có sự không phù hợp với các hành vi được mong đợi, ví dụ các điều kiện bị vi phạm hoặc có sự thất bại

nó sẽ thông báo đến cho đội phát triển về lỗi xảy ra Việc sử dụng tác tử Tester tự động cho phép mở rộng tuỳ ý cho việc kiểm thử mà có thể thực hiện độc lập với các hoạt động khác hướng tới con người Đây là chức năng phù hợp, khi mà hoạt động của hệ

đa tác tử có thể thay đổi theo thời gian và do mối liên hệ phụ thuộc giữa các tác tử và khả năng học tập của chúng, và việc thực thi riêng một ca kiểm thử có thể sẽ không phát hiện ra được lỗi

Kiểm thử liên tục của hệ thống đa tác tử yêu cầu các tác tử Tester có khả năng phát triển các ca kiểm thử hiện tại và sinh những ca kiểm thử mới, với mục đích thử và kiểm tra ứng dụng càng nhiều càng tốt, mục tiêu cuối cùng là khả năng phát hiện ra những lỗi chưa biết

Hai kỹ thuật sinh ca kiểm thử tự động được cung cấp từ đầu với các tác tử tester,

là sinh ngẫu nhiên và sinh tiến hoá đột biến

Các tác tử tester sử dụng các bộ sinh ca kiểm thử để sinh ca kiểm thử liên tục trong khi tác tử điều khiển theo dõi hoạt động của chúng và thông báo cho tác tử tester

về lỗi xảy ra nếu có

Thêm vào đó, tác tử tester xác nhận các thông điệp nhận được từ các tác tử có phù hợp với ontology hay không Nếu không thì tác tử tester sẽ thông báo cho đội phát triển

về lỗi đã được tìm ra

1.2.2 Sinh ca kiểm thử dựa trên ontology

1.2.2.1 Ontology tương tác tử

Để một cặp tác tử có thể hiểu nhau, yêu cầu đầu tiên là chúng phải sử dụng chung ngôn ngữ và nói về cùng một thứ Điều này được thực hiện bằng một ontology gọi là onlogty tương tác tử

Cấu trúc của ontology tương tác gồm 2 khái niệm chính: Concept và AgentAction Các lớp con của AgentAction định nghĩa các hành động có thể được thực hiện bởi các tác tử, trong khi đó các lớp con của Concept định nghĩa các khái niệm chung có thể được hiểu bởi tất cả các tác tử Các lớp con có thể có nhiều thuộc tính khác nhau Với mỗi lớp, người dùng có thể định nghĩa một vài các thực thể Ví dụ lớp Book có thể có thuộc tính là Tên và thực thể là một cuốn sách tên là Testing Agents