Phương pháp sinh dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML, biểu đồ lớp và ràng buộc OCL

Chương trình kiểm thử biến đổi tệp xmi bằng cách bóc tách các thông điệp, toán tử và các ràng buộc được đưa vào trong thiết kế, từ đó vẽ đồ thị dòng điều khiển tươngứng.. gian bắt đầu ki

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN HÒA

PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP

VÀ RÀNG BUỘC OCL

LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM

HÀ NỘI – 2016

NGUYỄN VĂN HÒA

PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP

NGUYEN VAN HOA

A METHOD AND TOOL SUPPORTING FOR AUTOMATED TESTING FROM UML SEQUENCE DIAGRAMS, CLASS

DIAGRAMS AND OCL CONSTRAINS

THE MS THESIS INFORMATION TECHNOLOGY Supervisor: Assoc Prof., PHAM NGOC HUNG, PhD

HÀ NỘI – 2016

LỜI CẢM ƠN

Đầu tiên, tôi xin gửi lời cảm ơn chân thành và sâu sắc tới thầy Phạm Ngọc Hùng –Người đã trực tiếp hướng dẫn nhiệt tình, giúp đỡ và động viên tôi rất nhiều, cho tôi có cơhội được tiếp xúc với các tài liệu tham khảo quý giá, góp ý cho tôi những lời khuyên chânthành trong quá trình nghiên cứu để hoàn thành đề tài này

Tiếp theo tôi xin gửi lời cảm ơn đến các thầy cô giảng viên Trường Đại học CôngNghệ - Đại học Quốc Gia Hà Nội – những người đã tận tâm truyền đạt những kiến thứcquý báu làm nền tảng cho tôi suốt 2 năm học

Cuối cùng, tôi xin gửi lời biết ơn sâu sắc tới gia đình vì đã luôn ở bên cạnh tôi,mang lại cho tôi nguồn động viên tinh thần to lớn và tạo mọi điều kiện thuận lợi cho tôitrong quá trình học tập và hoàn thành luận văn này

Với luận văn này tôi rất mong nhận được ý kiến đóng góp từ Thầy, Cô giáo và cácbạn quan tâm để hoàn thiện và phát triển nhiều hơn về các phương pháp mới trong kiểmthử phần mềm

Xin trân trọng cảm ơn!

Hà Nội, ngày 10 tháng 10 năm 2016

Học viên

Nguyễn Văn Hòa

TÓM TẮT

Luận văn này trình bày một phương pháp nghiên cứu tự động hóa quá trình kiểmthử dự án phần mềm từ biểu đồ tuần tự UML 2.0 Hướng nghiên cứu dựa trên lý thuyếtkiểm thử dựa trên mô hình Mục tiêu đề ra là tự động hóa quá trình kiểm thử, nâng caohiệu quả kiểm thử, tiết kiệm chi phí và thời gian phát triển dự án Phương pháp được đềxuất với nội dung chính như sau Đầu vào là biểu đồ tuần tự UML 2.0 lưu giữ dưới dạngtệp xmi Chương trình kiểm thử biến đổi tệp xmi bằng cách bóc tách các thông điệp, toán

tử và các ràng buộc được đưa vào trong thiết kế, từ đó vẽ đồ thị dòng điều khiển tươngứng Từ đồ thị dòng điều khiển sử dụng thuật toán dò tìm, thuật toán sinh ca kiểm thử chocác toán tử song song có các điểm chia sẻ dữ liệu tìm ra các đường đi từ điểm bắt đầu chotới điểm kết thúc gọi là các đường kiểm thử Tập các đường kiểm thử được chia tươngứng thành 3 cấp độ kiểm thử khác nhau Các ràng buộc trên mỗi đường đi được thu thập

và giải lấy kết quả dựa trên công cụ SMT solver kết hợp phương pháp sinh ngẫu nhiên.Kết quả thu được sau khi giải hệ chính là đầu vào cho các ca kiểm thử tương ứng Cuốicùng trích xuất ra tệp excel là các ca kiểm thử theo từng độ bao phủ dùng cho kiểm thửthiết kế Để kiểm nghiệm mức độ khả thi của phương pháp, một công cụ hỗ trợ đã đượccài đặt và thử nghiệm với một số ví dụ đơn giản nhằm minh chứng cho tính đúng đắn vàhiệu quả của phương pháp trên Kết quả thực nghiệm cho thấy hiệu quả của các ca kiểmthử cũng là khả quan để áp dụng cho các công ty phát triển phần mềm

Từ khóa: Kiểm thử dựa trên mô hình, kiểm thử tự động, biểu đồ tuần tự, đồ thị

dòng điều khiển, kiểm thử luồng song song, kiểm thử có chia sẻ dữ liệu luồng song song

The content of this thesis is research and propose a method to generate a set of testcases from the UML 2.0 Sequence diagrams Based on model-based testing in order toautomate the testing process, increase effectiveness, reduce cost and time of testing Themethod follows the following steps At first, in order to have the input model for testing, itanalyzes and divides the input diagram into fragments These fragments can be Sequential

or nested based on their relationship After that, it generates the corresponding controlflow graph for the input Sequence diagram The final control flow graph is analyzed togenerate a set of testing paths Symbolic Execution (SE) technique is used to createreStrictions associated with that set of testing paths Finally, the method uses SMT solver

to solve the set of reStrictions to find solution and then to generate a set of test cases Atool is also implemented and tested with some simple examples in order to show thecorrectness and effectiveness of the method The experimental results give us the potentialapplication of the tool in automation testing in companies

Keywords: Model base testing, automated testing, Sequence diagram, control flow

testing, Parallel threading testing, threading testing with data shared

LỜI CAM ĐOAN

Tôi xin cam đoan rằng những nghiên cứu về sinh tự động bộ kiểm thử từ biểu đồtuần tự được trình bày trong luận văn này dưới sự hướng dẫn của thầy Phạm Ngọc Hùng

là của tôi Những gì tôi viết ra không sao chép từ các tài liệu, không sử dụng các kết quảcủa người khác mà không trích dẫn cụ thể

Tôi xin cam đoan công cụ kiểm thử tự động tôi trình bày trong luận văn là do tôi tựphát triển, không sao chép mã nguồn của người khác Nếu sai tôi hoàn toàn chịu tráchnhiệm theo quy định của Trường Đại học Công Nghệ - Đại học Quốc Gia Hà Nội

Hà nội, ngày 10 tháng 10 năm 2016

Học viên:

Nguyễn Văn Hòa

MỤC LỤC

LỜI CẢM ƠN i

TÓM TẮT ii

ABSTRACT iii

LỜI CAM ĐOAN iv

MỤC LỤC v

DANH SÁCH BẢNG BIỂU vii

DANH SÁCH HÌNH VẼ viii

BẢNG THUẬT NGỮ VIẾT TẮT x

Chương 1: GIỚI THIỆU 1

Chương 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ HÌNH 3 2.1 Tổng quan kiểm thử dựa trên mô hình 3

2.1.1 Khái niệm kiểm thử dựa trên mô hình 3

2.1.2 Quy trình chung của kiểm thử dựa trên mô hình 5

2.1.3 Phương pháp đặc tả mô hình bằng máy trạng thái UML 6

2.1.4 Thuận lợi và khó khăn của kiểm thử tự động dựa trên mô hình 6

2.2 Biểu đồ tuần tự và các khối phân đoạn trong UML 8

2.2.1 Biểu đồ tuần tự 8

2.2.2 Các phân đoạn sử dụng trong biểu đồ tuần tự 8

2.3 Đồ thị dòng điều khiển 16

2.4 Các độ đo kiểm thử 17

Chương 3: PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN TỰ 20

3.1 Điều kiện ràng buộc trong thiết kế 20

3.2 Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển 24

3.2.1 Thuật toán sinh đồ thị dòng điều khiển 24

3.2.2 Đồ thị dòng điều khiển tương ứng với các phân đoạn 29

3.3 Kỹ thuật sinh kịch bản kiểm thử 37

3.3.1 Kịch bản kiểm thử cho các toán từ thông thường 37

3.3.2 Kịch bản kiểm thử cho các phân đoạn song song (Par, Seq) 42

3.4 Xây dựng hệ ràng buộc 44

3.5 Giải hệ sử dụng SMT-Solver 45

3.6 Các nghiên cứu liên quan 46

Chương 4: CÔNG CỤ VÀ THỰC NGHIỆM 48

4.1 Giới thiệu công cụ và môi trường thực nghiệm 48

4.2 Thực nghiệm 50

4.3 Ý nghĩa thực nghiệm 57

Chương 5: KẾT LUẬN 59

TÀI LIỆU THAM KHẢO 61

DANH SÁCH BẢNG BIỂU

ảng 2.1 Ca kiểm thử độ bao phủ yếu 18

ảng 2.2 Ca kiểm thử độ bao phủ trung bình 18

ảng 2.3 Ca kiểm thử độ bao phủ mạnh 19

ảng 3.1 Các khóa cơ bản và ý nghĩa trong tệp xmi 24

ảng 3.2 Dữ liệu thu thập tương ứng theo các nốt được nối với nhau 39

ảng 4.1 Môi trường thử nghiệm công cụ sinh ca kiểm thử từ thiết kế 49

DANH SÁCH HÌNH VẼ

Hình 2.1 Qui trình kiểm thử dựa trên mô hình 5

Hình 2.2 Phân đoạn Alt 9

Hình 2.3 Phân đoạn Opt 9

Hình 2.4 Phân đoạn Loop vô hạn 9

Hình 2.5 Phân đoạn Loop với cận trên bằng cận dưới bằng 10 10

Hình 2.6 Phân đoạn Loop với cận trên bằng 5, cận dưới bằng 10 10

Hình 2.7 Phân đoạn Break 11

Hình 2.8 Phân đoạn Par 12

Hình 2.9 Phân đoạn Seq 12

Hình 2.10 Phân đoạn Strict 13

Hình 2.11 Phân đoạn Ignore 13

Hình 2.12 Phân đoạn Consider 14

Hình 2.13 Phân đoạn Neg 15

Hình 2.14 Phân đoạn Assert 15

Hình 2.15 Phân đoạn Critical 16

Hình 2.16 Đồ thị dòng điều khiển tương ứng của phân đoạn Par 18

Hình 3.1 Thiết kế tên thông điệp 21

Hình 3.2 Thiết kế ràng buộc 22

Hình 3.3 Khai báo biến trong ràng buộc tương ứng cho các lớp 23

Hình 3.4 Xóa triệt để các đối tượng không dùng nữa 23

Hình 3.5 Đồ thị CFG tương ứng cho phân đoạn Alt 31

Hình 3.6 Đồ thị CFG tương ứng cho phân đoạn Opt 31

Hình 3.7 Đồ thị CFG tương ứng cho phân đoạn Loop 32

Hình 3.8 Đồ thị CFG tương ứng cho phân đoạn Break 32

Hình 3.9 Đồ thị CFG tương ứng cho phân đoạn Par 32

Hình 3.10 Đồ thị CFG tương ứng cho phân đoạn Seq 33

Hình 3.11 Đồ thị CFG tương ứng cho phân đoạn Ignore 34

Hình 3.12 Đồ thị CFG tương ứng cho phân đoạn Consider 34

Hình 3.13 Đồ thị CFG tương ứng cho phân đoạn Neg 35

Hình 3.14 Đồ thị CFG tương ứng cho phân đoạn Assert 36

Hình 3.15 Đồ thị CFG tương ứng cho phân đoạn Strict 36

Hình 3.16 Ví dụ cây đồ thị cần duyệt 38

Hình 3.17 Đồ thị dòng điều khiển 39

Hình 3.18 Ví dụ về ràng buộc OCL được khai báo trong thiết kế 45

Hình 3.19 Mô tả công cụ SMT Solver 46

Hình 4.1 Cấu trúc công cụ thực nghiệm 48

Hình 4.2 Đầu vào công cụ của ví dụ 1 50

Hình 4.3 Đầu ra - đồ thị CFG của ví dụ 1 51

Hình 4.4 Đồ thị CFG và ca kiểm thử độ bao phủ yếu cho ví dụ 1 52

Hình 4.5 Ca kiểm thử độ bao phủ yếu cho ví dụ 1 52

Hình 4.6 Ca kiểm thử độ bao phủ trung bình cho ví dụ 1 52

Hình 4.7 Dữ liệu kiểm thử sau khi xuất ra tệp MS Excel 53

Hình 4.8 Đầu vào của ví dụ 2 54

Hình 4.9 Đầu ra đồ thị CFG cho ví dụ 2 55

Hình 4.10 Ca kiểm thử độ bao phủ yếu cho ví dụ 2 55

Hình 4.11 Ca kiểm thử độ bao phủ trung bình cho ví dụ 2 56

Hình 4.12 Ca kiểm thử độ bao phủ mạnh cho ví dụ 2 56

Hình 4.13 Đường đi tương ứng của một ca kiểm thử độ bao phủ mạnh của ví dụ 2 57

BẢNG THUẬT NGỮ VIẾT TẮT

Chương 1: GIỚI THIỆU

Công nghệ phần mềm đang ngày càng phát triển và chi phối cuộc sống của conngười Ngược lại, con người luôn không ngừng sáng tạo để tạo ra những công nghệ mới,phần mềm và dịch vụ mới Trong quá trình phát triển đó, cần phải có một qui trình songsong để phát hiện và kiểm soát những sai lầm mà con người có thể vô tình hoặc cố tìnhtạo ra, đó chính là kiểm thử Theo ước tính, quá trình kiểm thử chiếm khoảng 50% thờigian và 40% - 60% tổng chi phí trong toàn bộ quá trình phát triển phần mềm [1] Quátrình kiểm thử cũng quyết định sự thành công, mức độ đảm bảo của dự án phần mềm đặcbiệt là trong các lĩnh vực đòi hỏi độ chính xác cao như hàng không, quân sự, khoa học, vũtrụ Vì vậy, để rút ngắn thời gian phát triển và nâng cao chất lượng dự án phần mềm, quátrình sinh ca kiểm thử tự động và nâng cao chất lượng ca kiểm thử trở nên thực sự cầnthiết, nhất là đối với những phần mềm lớn và phức tạp Kiểm thử tự động đang được xem

là giải pháp chính nhằm giảm chi phí và thời gian mà vẫn đảm bảo chất lượng trong quátrình phát triển phần mềm Để giải quyết vấn đề này, nhiều công trình nghiên cứu đã được

đề xuất nhằm giải quyết, tối ưu và tự động hóa quá trình kiểm thử Mỗi công trình nghiêncứu mang lại một kết quả khác nhau và áp dụng cho từng mục đích kiểm thử khác nhau.Một số nghiên cứu có thể kể đến như: phương pháp sinh ca kiểm thử tự động từ biểu đồtuần tự trong UML bởi A.V.K Shanthi và G Mohan Kumar [6] Sinh dữ liệu kiểm thử tựđộng từ biểu đồ tuần tự UML và ràng buộc OCL bởi Ashalatha Nayak và DebasisSamanta [4] Sinh ca kiểm thử từ biểu đồ tuần tự và hệ thống chuyển đổi được gắn nhãnbởi Emanuela G Cartaxo [9] Sinh ca kiểm thử tự động từ biểu đồ tuần tự UML và ràngbuộc OCL bởi Li Bao-Lin, Li Zhi-shu, Li Qing và Chen Yan Hong [10], v.v Trong đómột số nghiên cứu mới chỉ dừng lại ở dạng đề xuất, nhiều nghiên cứu khác chưa giảiquyết trọn vẹn bài toán kiểm thử trực tiếp từ biểu đồ tuần tự từ một phần mềm cụ thể Mỗiphương pháp hướng tới một mục đích kiểm thử khác nhau Để hiểu rõ hơn một vàinghiên cứu trên sẽ được trình bày chi tiết hơn ở chương ba của luận văn

Bài nghiên cứu này tôi sẽ trình bày một phương pháp khác sinh ca kiểm thử tựđộng và cải tiến một công đoạn sinh ca kiểm thử tự động để nâng cao chất lượng kiểmthử Cũng như các phương pháp kiểm thử dựa trên mô hình khác, phương pháp này đòihỏi phải có các mô hình toán học đặc tả chính xác hành vi của hệ thống và có sẵn trongthực tế Các mô hình này thường được biểu diễn bằng các máy hữu hạn trạng thái đơnđịnh Tuy nhiên, xây dựng mô hình cho các phần mềm là một công việc khó khăn và tiềm

ẩn nhiều lỗi đối với các công ty Thay vào đó việc phân tích và thiết kế dựa trên các biểu

đồ tuần tự UML là một công việc dễ dàng và trở nên phổ biến hơn Do đó việc kiểm thửtính đúng đắn cho thiết kế dựa trên mô hình đang được nghiên cứu và áp dụng thực tế chokiểm thử dự án phần mềm Không những tự động hóa được qui trình kiểm thử mà thời

gian bắt đầu kiểm thử cũng được tiến hành sớm hơn giúp rút ngắn thời gian phát triểnphần mềm.

Giai đoạn kiểm thử thiết kế (kiểm thử dựa trên mô hình) chủ yếu tập trung vào các

ca kiểm thử được sinh ra từ các đường kiểm thử dựa trên đồ thị hoạt động và sinh ra dữliệu kiểm thử từ dữ liệu đầu vào là các bản thiết kế từ đặc tả chương trình Với mục tiêukiểm thử phần mềm dựa trên thiết kế của biểu đồ tuần tự, mục tiêu nâng cao chất lượngkiểm thử cũng như khả năng phát hiện lỗi của các kịch bản kiểm thử trong thiết kế và khichương trình được thực thi Nội dung bài nghiên cứu này được trình bày trong 4 chương

Chương 3 nghiên cứu đề xuất cách biến đổi từ biểu đồ tuần tự sang đồ thị dòngđiều khiển và các thuật toán biến đổi Phương pháp sinh ca kiểm thử sau khi hoàn thành

độ thị dòng điều khiển trong đó chia ra 2 kịch bản kiểm thử Một cho các phân đoạn thôngthường (các phân đoạn không chứa luồng song song) và một kịch bản kiểm thử cho cácphân đoạn chứa luồng song song (Par, Seq) Phần cuối chương 3 trình bày phương phápsinh dữ liệu kiểm thử từ đồ thị dòng điều khiển, một số nghiên cứu liên quan để thấyđược ưu nhược điểm của bài nghiên cứu so với các phương pháp khác

Chương 4 giới thiệu công cụ thực nghiệm, các ví dụ thể hiện tính đúng đắn và khảthi của phương pháp đề xuất Kết quả thu được thực tế từ chương trình và rút ra ý nghĩacủa phương pháp đề xuất

Cuối cùng là kết luận, định hướng mở rộng và tài liệu tham khảo

Chương 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ

HÌNH 2.1 Tổng quan kiểm thử dựa trên mô hình

Ngày nay, các công ty phần mềm lớn thường sử dụng ngôn ngữ UML (UnifiedModeling Language) để phân tích, thiết kế phần mềm trước khi đi vào triển khai Sảnphẩm tạo ra là các mô hình thiết kế bởi UML Trong UML có nhiều mô hình phục vụ chothiết kế, việc lựa chọn những mô hình nào để thiết kế phụ vào mục đích sử dụng và địnhhướng phát triển phần mềm của công ty đó Quá trình kiểm thử trong giai đoạn thiết kếnày được gọi là kiểm thử dựa trên mô hình Các mô hình thiết kế có thể là biểu đồ lớp,biểu đồ tuần tự, biểu đồ hoạt động, v.v là đầu vào cho kiểm thử dựa trên mô hình, đầu ra

là các ca kiểm thử để đánh giá, phát hiện lỗi Mục đích của kiểm thử dựa trên mô hình làtìm ra được lỗi từ khâu thiết kế, không triển khai những thiết kế lỗi, hạn chế và rút ngắnđược thời gian kiểm thử cũng như triển khai dự án sau này

Việc kiểm thử và phát hiện sớm các lỗi, các khiếm khuyết trong thiết kế làm giảmthiểu đến mức thấp nhất các lỗi phát sinh khi đưa vào ứng dụng thực tế, đồng thời làmgiảm đáng kể thời gian cũng như chi phí phát triển, bảo trì Do vậy, việc phát triển mộtphương pháp kiểm thử dựa trên mô hình mang lại hiệu quả cao là rất cần thiết Trongchương này, tôi sẽ trình bày lý thuyết về phương pháp kiểm thử dựa trên mô hình và ứngdụng cho kiểm thử phần mềm

2.1.1 Khái niệm kiểm thử dựa trên mô hình

Kiểm thử dựa trên mô hình là một kỹ thuật kiểm thử hộp đen, dựa trên phươngpháp ứng dụng các mô hình thiết kế vào kiểm thử phần mềm Mô hình thiết kế là đại diệncho các hành vi mong muốn của một hệ thống cần kiểm thử, kiểm thử dựa trên mô hìnhđại diện cho một chiến lược thử nghiệm hay một môi trường kiểm thử

Một mô hình đặc tả hệ thống thường là một bản tóm tắt, trình bày một phần hành

vi mong muốn của hệ thống Chúng được biểu diễn bằng máy hữu hạn trạng thái, ôtômat,đặc tả đại số, biểu đồ trạng thái bằng UML, v.v Các ca kiểm thử có thể được sinh ra từ môhình theo nhiều cách khác nhau Trường hợp kiểm thử dựa trên một mô hình gọi là kiểm thửchức năng có cùng mức độ trừu tượng như mô hình Những trường hợp kiểm thử này đượcgọi là một bộ kiểm thử trừu tượng Một bộ kiểm thử trừu tượng không thể khẳng định hoàntoàn được tính đúng đắn của hệ thống Vì hệ thống trên thiết kế cũng có một mức sai trừutượng Một bộ kiểm thử thực thi cần phải được bắt nguồn từ một bộ thử nghiệm trừu tượngtương ứng Các bộ kiểm thử thực thi có thể liên lạc trực tiếp với hệ thống kiểm thử Điềunày đạt được bằng cách ánh xạ các ca kiểm thử trừu tượng với các

các ca kiểm thử cụ thể phù hợp để thực thi Trong một số môi trường kiểm thử dựa trên

mô hình, mô hình có đủ thông tin để tạo ra dãy ca kiểm thử thực thi trực tiếp Trong cáctrường hợp khác, các yếu tố trong bộ phần mềm kiểm thử cần phải được ánh xạ tới bộkiểm thử cụ thể

Có bốn phương pháp tiếp cận với kiểm thử dựa trên mô hình như sau [7]:

 Sinh ra dữ liệu đầu vào kiểm thử từ một mô hình chính: đầu vào cơ bản của

kiểm thử dựa trên mô hình là các mô hình, từ đó tạo ra các ca kiểm thử bằng cách chọn lựathông minh một tập hợp con của tập giá trị các trường hợp có khả năng để đưa ra dữ liệu

đầu vào kiểm thử Ví dụ mô hình cần kiểm thử có 3 tập đầu vào như sau, A : {red, green,

yellow}, B : {1, 2, 3, 4} và C : {car, truck, bike} Chúng ta có thể kết hợp và lựa chọn ra số

ca kiểm thử tối thiểu thỏa mãn tất cả các đường kiểm thử có thể thực thi thay vì thực thi tất

cả các ca kiểm thử Theo đó số ca kiểm thử cho ví dụ này là 12 thay vì 3 x 4 x 3 = 36 ca

kiểm thử

 Sinh ra các ca kiểm thử từ một mô hình môi trường: phương pháp này sử dụng

một loại mô hình khác, mô hình này sẽ miêu tả môi trường mong muốn của SUT Từ mô hình

mô phỏng giả lập này đưa ra các tham số gọi tới SUT Tuy nhiên, như cách tiếp cận sinh dữliệu đầu vào kiểm thử từ một mô hình chính, trình tự được tạo ra không chỉ định rõ các đầu ramong đợi của SUT, điều này là không thể dự

đoán các giá trị đầu ra, bởi vì mô hình môi trường không mô hình hóa được toàn

bộ hành vi của SUT Vì vậy nó rất khó để xác định chính xác một kiểm thử làthành công hay thất bại

 Sinh ra các ca kiểm thử với các dự đoán từ một mô hình hành vi: đưa ra các ca

kiểm thử có khả năng thực thi bao gồm các thông tin dự đoán các giá trị đầu ra mong muốn củaSUT Hoặc một vài khâu kiểm tra tự động các giá trị đầu ra thực tế

để có thể nhìn thấy nếu chúng là đúng đắn Điều này khó hơn việc sinh ra dữ liệukiểm thử đầu vào hoặc kiểm thử dựa trên trình tự gọi tới SUT mà không kiểm tratới kết quả đầu ra Để đưa ra kiểm thử với các dự đoán thì người đưa ra các cakiểm thử phải có đầy đủ thông tin về các hành vi mong đợi của SUT để có thể tiênđoán hoặc kiểm tra các dữ liệu đầu ra của SUT Một cách khác, với định nghĩakiểm thử dựa trên mô hình này, mô hình phải mô tả các hành vi mong đợi củaSUT, cũng như mối quan hệ giữa chúng, đồng thời mô tả đầu vào và đầu ra chotừng hành vi Thuận lợi của cách tiếp cận này là nó là phương pháp tiếp cận duynhất giải quyết được vấn đề kiểm thử dựa trên mô hình bằng việc chọn lựa các giátrị đầu vào và việc đưa ra các trình tự của sự vận hành, việc đưa ra các ca kiểm thử

có khả năng thực thi bao gồm thông tin quyết định sau mỗi ca kiểm thử

 Sinh ra các đoạn mã kiểm thử từ các kiểm thử trừu tượng: sinh ra các ca kiểm

thử có thể thực thi bao gồm các thông tin tiên đoán dựa trên mô hình hành vi của SUT Quátrình sinh ra các ca kiểm thử này bao gồm việc sinh ra dữ liệu kiểm thử và trình tự cácphương thức gọi tới kiểm thử tuần tự, sinh ra các dự đoán để kiểm tra kết quả đầu ra củaSUT Đây là một phương pháp tiếp cận hoàn thiện và phức tạp nhất, mang lại hiệu quả tốtnhất Nó có thể tự động hoàn thiện các tiến trình thiết kế, đưa ra một mô hình hoàn thiện, táihiện đầy đủ các tuần tự kiểm thử và chuyển đổi thành các kịch bản kiểm thử có thể thực thi

Với cách nhìn của kiểm thử dựa trên mô hình, chúng ta định nghĩa kiểm thử dựatrên mô hình như việc tự động tạo ra các ca kiểm thử hộp đen đối với bản thiết kế

2.1.2 Quy trình chung của kiểm thử dựa trên mô hình

Mô hình UML được thiết kế từ các đặc tả yêu cầu của hệ thống Mô hình có thểđược biểu diễn bằng các loại mô hình và biểu đồ khác nhau Việc xây dựng mô hình cònphải dựa trên các yếu tố dữ liệu đầu vào và đầu ra Mô hình này được sử dụng để sinhđầu vào cho các ca kiểm thử Tiếp đến, chúng ta sẽ sinh giá trị đầu ra mong muốn ứng vớimỗi bộ đầu vào Khi kết thúc bước này, chúng ta đã có các ca kiểm thử Sau khi thực thicác ca kiểm thử tương ứng theo từng giai đoạn hoặc phương pháp tiếp cận, kết quả thuđược sẽ được so sánh với kết quả mong đợi Từ đó quyết định hành động tiếp theo nhưsửa đổi mô hình hoặc dừng kiểm thử, v.v

Các bản đặc tả yêu cầuThiết kế

hình

Phản hồiTạo tự động

Theo dõi

Thực thi

Hình 2.1 mô tả về quy trình chung của kiểm thử tự động dựa trên mô hình [8].Kiểm thử tự động dựa trên mô hình gồm các giai đoạn sau:

 Sinh mô hình dựa trên các yêu cầu và chức năng của hệ thống

 Sinh các ca kiểm thử (bộ đầu vào và giá trị đầu ra mong đợi cho mỗi ca kiểm thử)

 Chạy các kịch bản kiểm thử để phát hiện các lỗi/khiếm khuyết của sản phẩm

 So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến

 Quyết định hành động tiếp theo (sửa đổi mô hình, tạo thêm ca kiểm thử, dừng kiểm thử, đánh giá chất lượng của phần mềm) [1]

2.1.3 Phương pháp đặc tả mô hình bằng máy trạng thái UML

Các phương pháp đặc tả mô hình sử dụng các công cụ toán học thường khó và ítphổ biến vì thường được thực hiện bằng các chuyên gia về đặc tả hình thức [1] Phù hợphơn cho môi trường công nghiệp, đặc tả mô hình bằng máy trạng thái UML thường đượcdùng để đặc tả các hành vi động (chuyển trạng thái) của các lớp đối tượng, các ca sửdụng (use cases), các hệ thống con và thậm chí là toàn bộ hệ thống Tuy nhiên, máy trạngthái UML thường được sử dụng cho các lớp đối tượng Trong UML, một trạng thái ứngvới một điều kiện quan trọng của một đối tượng Trạng thái này được quyết định bởi cácgiá trị hiện thời của đối tượng, các mối quan hệ với các đối tượng khác và các hành động(phương thức) mà đối tượng này thực hiện Một phép chuyển trạng thái là mối quan hệgiữa hai trạng thái Một phép chuyển trạng thái trong UML bao gồm một sự kiện đượckích hoạt, điều kiện và hành động tương ứng Các sự kiện được kích hoạt của các phépchuyển trạng thái có thể là một trong các sự kiện sau:

 Một lời gọi ứng với một phương thức

 Một tín hiệu nhận được từ các trạng thái khác trong máy trạng thái

 Một sự thay đổi giá trị của một thuộc tính nào đó của một đối tượng

 Hết thời gian (timeout)

2.1.4 Thuận lợi và khó khăn của kiểm thử tự động dựa trên mô hình

Kiểm thử tự động luôn mang lại những ưu điểm và hiệu quả vượt trội so với kiểmthử thủ công, góp phần hoàn thiện qui trình kiểm thử trong phát triển các dự án phầnmềm Sau đây là những ưu điểm và thuận lợi của kiểm thử tự động dựa trên mô hình:

 Phát hiện lỗi sớm ngay từ khâu thiết kế: Lỗi phát hiện càng sớm, nhất là các lỗitrong thiết kế sẽ giúp hạn chế được hàng loạt các lỗi phát sinh sau này theo phản

ứng dây chuyền, nếu không phát hiện được lỗi ở giai đoạn này đôi khi có thể dẫn tới việc phải xây dựng lại cả mô hình và làm lại từ khâu thiết kế

 Tiết kiệm thời gian và chi phí: Rút ngắn được thời gian sinh các ca kiểm thử vàphân tích kết quả nhờ qui trình tự động Việc phát hiện được lỗi sớm cũng giúp ích giảmthiểu thiệt hại và rủi ro cho hệ thống phần mềm, rút ngắn thời gian kiểm thử.

 Nâng cao chất lượng kiểm thử: Có thể đánh giá được mức độ hiệu quả của kiểmthử thông qua các mức độ bao phủ của mô hình và các ca kiểm thử Nếu mô hình của hệthống được xây dựng tốt thì quá trình kiểm thử dựa trên mô hình sinh ra nhiều ca kiểm thử

và phát hiện nhiều lỗi Kiểm thử mô hình cũng cho phép giảm các lỗi chủ quan do ngườikiểm thử sinh ra trong quá trình kiểm thử sản phẩm

 Phát hiện các lỗi trong đặc tả, yêu cầu: Kiểm thử dựa trên mô hình đôi khi khôngchỉ phát hiện được các lỗi trong thiết kế mà còn phát hiện được các lỗi trong tài liệu đặc tả.Các đặc tả thiếu logic sẽ dẫn tới một thiết kế sai và không thể thực thi

 Khả năng tái sử dụng cao: Mỗi khi phần mềm được nâng cấp, chúng ta dễ dàng sinh thêm các ca kiểm thử và kiểm thử lại một cách nhanh chóng và hiệu quả

 Hiểu hơn về hệ thống: Kiểm thử dựa trên mô hình giúp người phát triển hiểu hơn

về hệ thống cần kiểm thử thông qua việc xây dựng và phân tích mô hình hệ thống

 Việc sinh ca kiểm thử tự động dựa trên các thuật toán và phương pháp tiếp cậnkhoa học, có tính toán sẽ làm giảm số lượng các ca kiểm thử trùng nhau hoặc không hữuhiệu

Có rất nhiều ưu điểm và thuận lợi nhưng kiểm thử dựa trên mô hình không dễ được áp dụng trong thực tế vì một số khó khăn như sau:

 Không thể đảm bảo tìm được tất cả các lỗi vì sự sai khác trong thiết kế và thực thi

 Khó xây dựng mô hình chính xác: Kiểm thử dựa trên mô hình cần có mô hình đặc

tả chính xác hành vi của hệ thống Trong thực tế, việc xây dựng mô hình là rất khó, tốn kém

và tiềm ẩn nhiều lỗi

 Chỉ áp dụng kiểm thử chức năng: Các mô hình kiểm thử phải nhỏ so với kíchthước của hệ thống, rằng chúng ta có thể kiểm thử nó mà không mất quá nhiều chi phí,nhưng chúng phải đủ chi tiết để mô tả thực tế và các đặc điểm cần

 Không thể bao phủ hết các giai đoạn kiểm thử: Ví dụ không kiểm thử được các tiến trình cài đặt

 Tạo giá trị đầu ra mong đợi cho các ca kiểm thử là một trong những vấn đề khókhăn nhất của kiểm thử dựa trên mô hình Thông thường cần có chuyên gia hoặc chuyênviên riêng tính toán kết quả mong đợi

2.2 Biểu đồ tuần tự và các khối phân đoạn trong UML

2.2.1 Biểu đồ tuần tự

Biều đồ tuần tự là biểu đồ thể hiện các trình tự sự kiện dẫn đến các kết quả mongmuốn Biểu đồ tuần tự sẽ cho ta thấy qui trình hoạt động cũng như sự tương tác giữa cácphân đoạn trong một hệ thống Thành phần chính của biểu đồ tuần tự gồm: Đối tượng,thông điệp và phân đoạn

Đối tượng:

Được biểu diễn bằng hai phần: phần tiêu đề khai báo đối tượng và chu kỳ sống,các đối tượng tương tác với nhau thông qua các thông điệp Thời gian đối tượng tồn tạiđược biểu diễn bằng đường đứt nét, chu kỳ sống biểu diễn bằng đường nét đôi

Thông điệp:

Được biểu diễn ở dạng đường mũi tên từ chu kỳ sống của đối tượng gửi đến đốitượng nhận Các mũi tên này được sắp xếp theo trình tự thời gian từ trên xuống Có baloại thông điệp: Thông điệp đồng bộ (nét liền), thông điệp phản hồi (nét đứt), thông điệp

đệ quy (gọi tới chính đối tượng)

Phân đoạn:

Với các luồng điều khiển phức tạp, chúng ta có thể dùng các phân đoạn lồng ghép(combined fragment) Mỗi phân đoạn có một từ khóa và có một hoặc nhiều các đoạn con(gọi là các toán hạng tương tác –interaction operands) Tương ứng với cấu trúc điềukhiển trong các ngôn ngữ lập trình như lặp, rẽ nhánh, song song, chúng ta có các phânđoạn khác nhau với các nhãn tương ứng là Loop, Alt, Par, v.v

2.2.2 Các phân đoạn sử dụng trong biểu đồ tuần tự

Phân đoạn tương tác lựa chọn đầy đủ (Alternative) chỉ ra rằng phân đoạn kết

hợp (Combined Fragment) biểu diễn một sự lựa chọn hành vi Toán hạng trong phân đoạn

có biểu thức gác (guard expression), nếu biểu thức gác đúng thì toán hạng được thực thi.Nếu toán hạng không có biểu thức gác thì biểu thức được ngầm hiểu là true Nếu biểuthức gác là else, toán hạng sẽ được thực thi khi các điều kiện gác của các toán hạng khácsai Hình 2.2 là ví dụ minh họa nếu số dư (balance) trong tài khoản lớn hơn 0 thì chophép rút tiền (accept()), nếu không thì từ chối (reject())

Phân đoạn tương tác lựa chọn không đầy đủ (Option) chỉ ra rằng phân đoạn kết

hợp biểu diễn một sự lựa chọn hành vi Trong phân đoạn chỉ có một toán hạng, toán hạng này

có thể được thực thi hoặc không được thực thi tùy vào điều kiện gác Phân đoạn Opt gầngiống với phân đoạn Alt, chỉ có điều trong Opt chỉ có một toán hạng duy nhất

Hình 2.3 là ví dụ minh hoạ thực hiện đăng bình luận (post_comments()) nếu không có lỗi(no errors).

Hình 2.3 Phân đoạn Opt.

Phân đoạn tương tác lặp (Loop) chỉ ra rằng phân đoạn kết hợp biểu diễn một

vòng lặp.Toán hạng lặp sẽ được lặp đi lặp lại một số lần Điều kiện gác có thể gồm mộtcận dưới (minint), một cận trên (maxint) và một biểu thức đúng-sai (boolean) Sau minintlần lặp, biểu thức được kiểm tra, chừng nào biểu thức còn đúng và số lần lặp còn nhỏ hơnhoặc bằng maxint thì vòng lặp vẫn tiếp tục

Loop

notify()

Hình 2.4 Phân đoạn Loop vô hạn.

Hình 2.6 Phân đoạn Loop với cận trên bằng 5, cận dưới bằng 10.

Hình 2.4 miêu tả phân đoạn Loop với vòng lặp vô hạn Hình 2.5 miêu tả phân đoạnLoop với vòng lặp với cận trên bằng cận dưới và bằng 10, không có điều kiện cần kiểmtra Hình 2.6 miêu tả sau khi lặp hết 5 lần, nếu điều kiện size < 0 đúng thì dừng lặp, việckiểm tra này còn thực hiện chừng nào số lần lặp còn <= 10

Phân đoạn tương tác Break chỉ ra rằng khi điều kiện gác đúng thì toán hạng

trong phân đoạn kết hợp Break sẽ được thực thi thay cho phần còn lại của phân đoạntương tác (Interaction Fragment) bao gói bên ngoài Hình 2.7 là ví dụ minh họa: Nếu y >

0 thì thực hiện save() rồi thoát luôn khỏi vòng lặp

Phân đoạn tương tác song song (Parallel) chỉ ra rằng các toán hạng trong phân

đoạn kết hợp có thể được thực thi song song với nhau Các sự kiện trong các toán hạng khácnhau có thể đan xen vào nhau theo bất cứ cách nào, miễn là thứ tự của các sự kiện trong mỗitoán hạng được bảo toàn Hình 2.8 là ví dụ minh họa thứ tự thực hiện các phân đoạn Thôngđiệp 1a: searchGoogle phải được thực hiện trước thông điệp 2: readResult, thông điệp 1b:searchBing phải được thực hiện trước thông điệp 3: readResult, thông điệp 1c: searchYahoophải được thực hiện trước thông điệp 4: readResult Tuy nhiên thứ tự các thông điệp (1a, 2),(1b, 3), (1c, 4) có thể đan xen nhau theo bất cứ cách này Tìm bằng

Yahoo có thể được thực hiện và trả về kết quả trước sau đó với tìm bằng Google và Bing,v.v.

Phân đoạn tương tác tuần tự yếu (weak Sequencing) chỉ ra rằng phân đoạn kết

hợp biểu diễn một trình tự yếu giữa các hành vi của các toán hạng Trình tự yếu đượcđịnh nghĩa bởi tập các vết với các đặc tính:

 Thứ tự của các sự kiện (EventOccurences) trong mỗi một toán hạng được duy trì

 Các sự kiện trên các trục thời gian (lifeline) khác nhau ở các toán hạng khác nhau

có thể xảy ra theo thứ tự bất kỳ

 Các sự kiện trên cùng trục thời gian ở các toán hạng khác nhau được sắp thứ tự saocho một sự kiện của toán hạng thứ nhất phải xảy ra trước sự kiện của toán hạng thứ hai Hình2.9 là ví dụ minh họa: Tìm kiếm bằng Google song song với Bing và

Yahoo, tuy nhiên phải tìm bằng ing trước khi tìm bằng Yahoo

1a: searchGoogle()2: readResult()

1b: searchBing()3: readResult()

1c: searchYahoo()4: readResult()

Hình 2.8 Phân đoạn Par.

Seq

Search_google()

search_bing()

Search_yahoo()

Hình 2.9 Phân đoạn Seq.

Phân đoạn tương tác tuần tự ngặt (Strict Sequencing) chỉ ra rằng phân đoạn kết

hợp biểu diễn một trình tự ngặt giữa các hành vi của các toán hạng Hình 2.10 là ví dụminh họa: Tìm bằng Google, rồi đến tìm bằng ing, sau đó là Yahoo Thứ tự các hành vicủa các toán hạng luôn tuân theo trình tự bắt buộc theo trục thời gian và không được phépxáo trộn Điều này tuân theo qui luật của thiết kế và thực thi trong biểu đồ tuần tự nênphân đoạn Strict không có nhiều ý nghĩa khi đi một mình Chỉ có ý nghĩa biểu đạt sự tuân

thủ nghiêm ngặt trong thiết kế Phân đoạn Strict thường được dùng kết hợp với các phânđoạn khác như Critical regigon, Par, Seq.

Strict

Search_google()

search_bing()

Search_yahoo()

Hình 2.10 Phân đoạn Strict.

Phân đoạn tương tác từ chối (Ignore) chỉ ra rằng có một số kiểu thông điệp

không được hiển thị trong phân đoạn kết hợp này Các kiểu thông điệp này có thể bị coi

là vô nghĩa và bị mặc nhiên bỏ qua Hình 2.11 là ví dụ minh họa thiết kế sử dụng phânđoạn Ignore với ràng buộc bỏ qua các thông điệp get() và set() nếu có Các thông điệpkhác vẫn được thực thi bình thường

Ignore{get,set}

add()

remove()

Hình 2.11 Phân đoạn Ignore.

Phân đoạn tương tác lưu ý (Consider) chỉ ra những thông điệp nên được lưu ý

trong phân đoạn kết hợp này Điều này tương đương với việc định nghĩa mọi thông điệpkhác là bị bỏ qua Ví dụ minh họa trong Hình 2.12 sử dụng phân đoạn Consider để lưu ý

đến hai thông điệp add() và remove() nếu sảy ra, các thông điệp khác bị coi là vô nghĩa và

bị bỏ qua

Consider {add, remove}

add()

remove()

Hình 2.12 Phân đoạn Consider.

Phân đoạn tương tác phủ định (Negative) chỉ ra rằng phân đoạn kết hợp biểu

diễn các vết (traces) được định nghĩa là không hợp lệ Hình 2.13 biểu diễn qui trình hoạtđộng của lò vi sóng trong đó có sử dụng phân đoạn Neg trong thiết kế Trong phân đoạn

Neg có thông điệp open() đi từ một trục thời gian Chef từ bên ngoài vào trục thời gian

Door nằm bên trong thông điệp Vì vậy, thông điệp Open() là không được phép trong

thời gian thông điệp Neg đang thực thi Nếu thông điệp Open() được thực hiện bắt buộc

từ người sử dụng thì các thông điệp khác bên trong phân đoạn Neg sẽ bị dừng lại Điều

đó nói lên, việc mở cửa của lò vi sóng là không được phép trong khi đang nấu Hoặc, nếu

mở cửa lò vi sóng khi đang nấu, các nhiệm vụ khác bên trong phân đoạn Neg sẽ bị dừnglại Các nhiệm vụ đến từ bên ngoài và bên trong phân đoạn Neg không được phép thựcthi song song

Phân đoạn tương tác quyết định (Assertion) chỉ ra rằng phân đoạn kết hợp biểu

diễn các vết hợp lệ Phân đoạn Assert thường được sử dụng cùng với Ignore hoặcConsider Hình 2.14 minh họa phân đoạn Assert được sử dụng kết hợp với phân đoạnConsider Trong đó phân đoạn Consider cho phép các thông điệp q, v, w được phép sảy

ra Tuy nhiên trong khoảng thời gian thực thi khối Assert chỉ chấp nhận thông điệp q làhợp lệ, do đó nếu thông điệp w xảy ra thay cho q thì w không hợp lệ

Chef Control Microw- Microway Door

Panel ay Generator

open() insert_food()

Hình 2.14 Phân đoạn Assert.

Phân đoạn tương tác vùng then chốt (Critical region) chỉ ra rằng phân đoạn kết

hợp biểu diễn một vùng then chốt Một vùng then chốt nghĩa là các vết trong vùng nàykhông thể bị đan xen bởi các sự kiện (EventOccurence) khác (trên các trục thời gian bịphủ bởi vùng này) Hình 2.15 minh họa: Các cuộc gọi cho 911 phải nối tiếp, không đượcchồng lấn nhau Điều hành viên (operator) phải chuyển tiếp cuộc gọi cho số 911 trước khilàm bất cứ thứ gì khác Các cuộc gọi thường thì đan xen nhau thoải mái

:Emergency :Operator :Caller :Callee

Hình 2.15 Phân đoạn Critical.

2.3 Đồ thị dòng điều khiển

Đồ thị dòng điều khiển (Control Flow Graph - CFG) là đồ thị được sinh ra từ biểu

đồ tuần tự bởi một thuật toán hồi qui, với các ràng buộc và thông số trong thiết kế biểu đồ

tuần tự thì sẽ được bóc tách, biến đổi để sinh dữ liệu kiểm thử Đồ thị dòng điều khiển làmột đồ thị biểu diễn trực tiếp của biểu đồ tuần tự và được tạo nên từ bảy loại nốt nối với

nhau bởi các đường Bảy loại nốt đó là [4]:

 Nốt bắt đầu (Start node): là nốt khởi đầu của đồ thị.

 Nốt đơn vị (BN – Block node): là nốt biểu thị cho một thông điệp hoặc một tuần

tự của của các thông điệp Mỗi thông điệp m(i) bao gồm thông tin của lớp gửi và lớp nhận

và có cấu trúc ( m(i), ParameterList, returnValue ) Mỗi thông số của một thông điệp có thể

là một thuộc tính của ràng buộc OCL

 Nốt quyết định (DC – Decision node): là nốt biểu thị cho một hàm điều kiện như

điều kiện đúng (hoặc sai) cần được thỏa mãn để lựa chọn các toán hạng tương ứng trong

một phân đoạn

 Nốt sáp nhập (MN – Merge node): là nốt biểu thị cho sự sáp nhập các nhánh ra từ

một hành vi lựa chọn (chẳng hạn như lối ra từ một phân đoạn ALT hoặc OPT)

 Nốt rẽ nhánh (FN – Fork node): là nốt biểu thị đầu vào của phân đoạn PAR hoặc

SEQ

 Nốt kết hợp (JN – Join node): là nốt đầu ra (hay kết thúc) của phân đoạn PAR

hoặc SEQ

 Nốt kết thúc (End node): là nốt kết thúc của tất cả các chu trình trong đồ thị Một

đồ thị dòng điều khiển G được biểu diễn như sau: G <A, E, in, F> với:

o „in‟ là nốt khởi tạo (nốt bắt đầu)

o F là tập các nốt hay trạng thái cuối cùng của đồ thị

o A là tập các nốt bao gồm (BN CN) với BN là nốt đơn vị (Block node),

CN = (DN MN FN JN) được gọi là tập các nốt điều khiển

o E là tập các cạnh nối giữa các nốt E = {f (x; y) | x, y A F}

Cấu trúc mỗi nốt A được đề xuất như sau: < nodeId, nodeType, nodeDetails,

outEdge > với:

 nodeId: là nhãn duy nhất được đính kèm vào mỗi nốt.

 nodeType = {decision, merge, fork, join} với mỗi và

nodeType = {block, initial, final} cho tất cả các nốt còn lại.

 nodeDetails = { , , | q là số của một tin nhắn trong BN} Mỗi

nodeDetails được định nghĩa là một bộ ba < m, s, r > với mỗi bản tin xác định

được đối tượng gửi s, đối tượng nhận r và tên của mỗi bản tin m cho tất cả các nốtđơn vị BN Mỗi thông điệp bao gồm các thông tin bên gửi từ biểu đồ lớp

và có cấu trúc < m, ParamList, rValue > Các thông tin này sẽ được đính kèm vào

cả các bộ thông số ParamList = { } và trả về giá trị rValue Ngoài ra, một

thông sốcủa một phương thức còn có thể được cung cấp từ các thuộc tính,ràng buộc các lớp Một thông số hay một giá trị trả về được tách riêng và các thông

tin ràng buộc từ biểu đồ lớp và có cấu trúc < name, type, value, constraint > với

name là tên của bộ thông số hoặc thuộc tính, type là dạng dữ liệu, value là giá trị

được gán Còn constraint được lấy từ ràng buộc OLC được khai báo từ các thuộc

tính biểu đồ lớp hoặc đã được đính kèm vào biểu đồ tuần tự

 outEdge = { ,…, | q là số cạnh nối} Mỗi được xác địnhbằng < sourceNode, targetNode > [13]

2.4 Các độ đo kiểm thử

Độ đo kiểm thử là một công cụ giúp ta đo mức độ bao phủ chương trình của mộttập ca kiểm thử cho trước Mức độ bao phủ của một bộ kiểm thử (tập các ca kiểm thử)được đo bằng tỷ lệ các thành phần thực sự được kiểm thử so với tổng thể sau khi đã thựchiện các ca kiểm thử Bài nghiên cứu này chia ra 3 tiêu chuẩn bao phủ, để dễ hình dunghơn về 3 tiêu chuẩn bao phủ này chúng ta sẽ bám theo ví dụ về kiểm thử phân đoạn Par đãđược biến đổi sang đồ thị dòng điều khiển như Hình 2.16

Hình 2.16 Đồ thị dòng điều khiển tương ứng của phân đoạn Par.

C1: Độ bao phủ yếu: Đường kiểm thử đi qua tất cả các nốt rẽ nhánh (các nốt quyết định)

của đồ thị dòng điều khiển Đối với ví dụ Hình 2.16 ta có bảng các ca kiểm thử như sau:

ảng 2.1 Ca kiểm thử độ bao phủ yếu

tc1 Bi-FN1-B1-JN1-Bk

C2: Độ bao phủ trung bình: Đường kiểm thử đi qua tất cả các nhánh của đồ thị dòng điều

khiển Bảng các ca kiểm thử tương ứng cho ví dụ Hình 2.16 như sau:

ảng 2.2 Ca kiểm thử độ bao phủ trung bình

tc1 Bi-FN1-B1-JN1-Bktc2 Bi-FN1-B2-JN1-BkC3: Độ bao phủ mạnh: Được áp dụng cho các thiết kế có sử dụng các phân đoạn song

song có các luồng chạy song song như Par, Seq Khi đó các nốt chạy song song có chia sẻ

dữ liệu với nhau sẽ được hoán đổi vị trí để tạo ra các đường kiểm thử phủ được nhiều

trường hợp hơn

Ví dụ Hình 2.16 còn một cách đảo lộn thứ tự khác là Bi-FN1-B2-B1-JN1-Bk Thứ tự thựcthi này hoàn toàn có thể sảy ra, tuy nhiên ở phương pháp tôi đề xuất chỉ kiểm tra chia sẻ

dữ liệu một lần cho cặp hai thông điệp song song bất kì có chia sẻ dữ liệu Điều này đảm

bảo số lượng ca kiểm thử sinh ra là không quá nhiều mà vẫn đảm bảo mức độ hiệu quảkiểm thử đặc biệt cho các bài toán phức tạp Ví dụ Hình 2,16 là một ví dụ đơn giản chứahai luồng thực thi song song với hai điểm chia sẻ dữ liệu 1 và 2 Với những bài toán sửdụng nhiều phân đoạn Par lồng nhau và có nhiều nhánh thì việc kiểm tra tất cả các thông

điệp thực thi song song và có chia sẽ dữ liệu sẽ trở nên phức tạp hơn nếu muốn tìm tất cảcác đường đi có thể sảy ra Tuy nhiên, dựa trên phương pháp này chúng ta hoàn toàn cóthể phát triển nhiều hơn các đường thực thi muốn kiểm tra tùy theo mục đích kiểm thử và

sử dụng

Chương 3: PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ

TUẦN TỰ 3.1 Điều kiện ràng buộc trong thiết kế

Trên thực tế, hầu hết các công ty phần mềm đều có những qui ước thiết kế riêng đểđảm bảo tính đồng nhất trong suốt dự án Điều này giúp các kỹ sư thiết kế làm việc hiệuquả, giảm thời gian giao tiếp, trao đổi Ngoài ra, nó còn giúp phần mềm có thể tận dụngđược các mô đun có sẵn, các chương trình kiểm thử đã được định sẵn Hiện nay có rấtnhiều phần mềm hỗ trợ thiết kế mô hình, vẽ biểu đồ tuần tự như: Enterprise Architect,

Astah, Rational Rose, v.v Trong đó phần mềm Enterprise Architect với nhiều ưu điểm và

được sử dụng rộng rãi trong các công ty phần mềm Enterprise Architect cũng hỗ trợ tríchxuất tệp xmi phù hợp với mục tiêu nghiên cứu Bài nghiên cứu này tôi sử dụng đầu vào làtệp xmi được trích xuất từ phần mềm thiết kế Enterprise Architect Để đảm bảo dữ liệuthiết kế được đưa vào là phù hợp với chương trình kiểm thử tôi có một vài qui ước thiết

kế như sau

Các phân đoạn, thông điệp có thể được thiết kế song song hoặc lồng nhau Tên củacác thông điệp sẽ được đặt theo cấu trúc định sẵn

Ví dụ: Một thông điệp được đặt tên WithDrawMoney() như Hình 3.1.

 WithDrawMoney() : tên thông điệp (đặt tùy chọn)

 Balance = Balance – MoneyWithdraw : công việc được thực thi – sẽ nằm trong

chi tiết của đường kiểm thử.

 Balance, MoneyWithdraw : các biến giá trị, dữ liệu sẽ bị thay đổi hoặc tác động bởi

thông điệp này

 Tên thông điệp hiển thị trong thẻ Message.

 Nhiệm vụ thực thi của toán tử được đặt trong thẻ Parameter.

 Các biến giá trị bị thay đổi sau khi thông điệp thực thi được đặt trong thẻ

Argument(s).

Ràng buộc về dữ liệu đầu vào sẽ được khai báo trên các trục thời gian tương ứng với từng lớp đối tượng trong thiết kế Loại ràng buộc là ràng buộc OCL Hình 3.2 là ví

dụ về khai báo ràng buộc cho các biến:

 x > 0: biến x luôn nhận giá trị dương.

 accCurrent > 50: Số dư trong tài khoản phải luôn lớn hơn 50.

Hình 3.3 biểu diễn ví dụ khai báo ràng buộc OCL sử dụng trong thiết kế (kiểu biến,loại dàng buộc)

 int a: khai báo biến a đƣợc sử dụng trong thiết kế thuộc kiểu dữ liệu số nguyên

(Integer), loại ràng buộc là OCL

 int accCurrent: khai báo số dƣ tài khoản là số nguyên (Integer), loại ràng buộc

là OCL.

Hình 3.1 Thiết kế tên thông điệp.

Hình 3.3 Khai báo biến trong ràng buộc tương ứng cho các lớp.

Hình 3.4 Xóa triệt để các đối tượng không dùng nữa.

3.2 Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển

Biểu đồ tuần tự biểu diễn thiết kế theo trình tự thời gian Bên trong bao gồm nhiềuthành phần và các thông tin đính kèm Mỗi thành phần, cấu trúc biểu diễn một hoạt độngkhác nhau trong ca sử dụng Biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển là mộtcông việc khó khăn vì chúng không tuân theo một qui luật nào cả Để làm được điều nàychúng ta phải liệt kê tất cả các thành phần, khối toán tử bên trong biểu đồ tuần tự và dùngthuật toán tương ứng biến đổi cho từng toán tử và thành phần đó Thuật toán này khôngnhững phải hoạt động đúng mà còn phải đảm bảo tính đúng đắn khi các thành phần vàtoán tử lồng ghép vào nhau trong thiết kế

3.2.1 Thuật toán sinh đồ thị dòng điều khiển

Đầu vào của thuật toán 1 sinh đồ thị dòng điều khiển là tệp xmi là lưu trữ dạng kí

tự của biểu đồ tuần tự Vì vậy, để biến đổi được từ biểu đồ tuần tự sang đồ thị dòng điềukhiển thì bên trong thuật toán 1 sử dụng các thư viện đọc tệp xmi, từ đó bóc tách dữ liệutheo các từ khóa tương ứng với từng phần tử thiết kế trong biểu đồ tuần tự Bảng 3.1miêu tả một số từ khóa cơ bản dùng để nhận biết và đọc dữ liệu trong tệp xmi

ảng 3.1 Các khóa cơ bản và ý nghĩa trong tệp xmi

<constraints> ắt đầu khai báo các ràng buộc (OCL) trong biểu đồ

</constraints> Kết thúc khai báo các ràng buộc trong biểu đồ

<fragment ắt đầu một phân đoạn

</fragment> Kết thúc một phân đoạn

<lifeline ắt đầu trục thời gian

<message ắt đầu một thông điệp

</message> Kết thúc một thông điệp

<operand ắt đầu khai báo các toán tử bên trong phân đoạn

</operand> Kết thúc khai báo các toán tử bên trong phân đoạn

Cấu trúc dữ liệu của biểu đồ tuần tự là một mảng các phần tử bao gồm thông điệp,phân đoạn và toán hạng và tất cả các phần tử này được sắp xếp theo trình tự thời gian Thuậttoán phân tích lần lượt từng phần tử trong hàng đợi và trả về các nốt khác nhau Bắt đầu từ

nốt khởi đầu in – được xem là nốt hiện tại (curNode), mỗi phần tử của hàng đợi sẽ

được đọc bởi câu lệnh (queue.pop()) Tùy thuộc vào số lượng phần tử trong hàng đợi,

thuật toán này sẽ được gọi trả về là BN, DN, MN, FN và JN

Thuật toán 1: Sinh đồ thị CFG

Đầu vào: Biểu đồ tuần tự D (tệp xmi trích xuất từ phần mềm Enterprise Architect) Đầu ra: Đồ thị G: (A, E, in, F) với: A là tập các nốt (BN, DN, MN, FN, JN);

in là nốt khởi tạo, F là nốt kết thúc; E là tập các cạnh trong đồ thị CFG,

E ={(x, y) | x, y A F}

1: create initial node in, node x;

2: create empty queue;

3: create curPos point at start element of sequence diagram D in xmi;

4: repeat

5: curPos read each element of D to add to queue

6: curPos move to next Element;

7: until curPos meets end element of xmi file

8: x = processElement(queue, in); // thuật toán 2

9: if x ≠ finalNode then

10: create final Node fn F;

11: Connect edge from x to fn;

12: end if

13: return G;

Thuật toán 1 biểu diễn các bước sinh đồ thị CFG từ biểu đồ tuần tự là tệp xmi Cácbước thực hiện như sau:

 Tạo nốt bắt đầu, đặt nốt bắt đầu là nốt bắt đầu duyệt là curPos

 Khởi tạo hàng đợi (rỗng)

 Đọc từng phần tử từ tệp xmi và thêm vào hàng đợi rồi chuyển sang phần tử tiếp theo Quá trình đọc tệp xmi được lặp lại cho tới khi kết thúc

 Hàng đợi thu thập được và nốt bắt đầu được đưa vào thuật toán 2 để sinh các nốt tương ứng theo thiết kế và lý thuyết chuyển đổi