Luận văn Thạc sĩ Kỹ thuật phần mềm: 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

ĐẠI HỌC QUỐC GIA HÀ NỘI 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

ĐẠI HỌC QUỐC GIA HÀ NỘI 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

Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã số: 60480103

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

CÁN BỘ HƢỚNG DẪN KHOA HỌC: PGS. TS. PHẠM NGỌC HÙNG

HÀ NỘI – 2016

VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING TECHNOLOGY

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ân thà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ông Nghệ - Đạ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ức quý 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ôi trong 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ác bạ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ểm thử 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ểm thử 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ết kiể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 cao hiệ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ạng tệ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ử cho cá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 cho tớ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ối cù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ợ đã đƣợc cà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ểm thử 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.

iii

ABSTRACT

The content of this thesis is research and propose a method to generate a set of test cases from the UML 2.0 Sequence diagrams. Based on model-based testing in order to automate the testing process, increase effectiveness, reduce cost and time of testing. The method follows the following steps. At first, in order to have the input model for testing, it analyzes and divides the input diagram into fragments. These fragments can be Sequential or nested based on their relationship. After that, it generates the corresponding control flow graph for the input Sequence diagram. The final control flow graph is analyzed to generate a set of testing paths. Symbolic Execution (SE) technique is used to create reStrictions 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. A tool is also implemented and tested with some simple examples in order to show the correctness and effectiveness of the method. The experimental results give us the potential application 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ách nhiệ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

vii

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

viii

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

STT Từ viết tắt Tên đầy đủ Ý nghĩa

Block Node Nốt đơn 1 BN

2 CFG Control Flow Graph Đồ thị dòng điều khiển

3 DC Decision Node Nốt quyết định

4 FN

5 IDE

6 JN Fork Node Integrated Development Environment Join Node Nốt rẽ nhánh Môi trƣờng phát triển tích hợp Nốt nối

7 MN Merge Node

8 OCL Object Constraint Language

9 SUT Software Under Testing

10 UML Unified Modeling Language Nốt sáp nhập Ngôn ngữ ràng buộc trên đối tƣợng Phần mềm đang đƣợc kiểm thử Ngôn ngữ mô hình hóa thống nhấ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 con ngƣờ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 song song để 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ình tạo ra, đó chính là kiểm thử. Theo ƣớc tính, quá trình kiểm thử chiếm khoảng 50% thời gian 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 đặc biệ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ần thiế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ên cứ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à Debasis Samanta [4]. Sinh ca kiểm thử từ biểu đồ tuần tự và hệ thống chuyển đổi đƣợc gắn nhãn bởi Emanuela G. Cartaxo [9]. Sinh ca kiểm thử tự động từ biểu đồ tuần tự UML và ràng buộ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ải quyế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ỗi phƣơ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ài nghiê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ểm thử. 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 đòi hỏ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 trong thự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ế cho kiể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ển phầ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êu kiể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ƣợng kiể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à khi chƣơ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 và phần kết luận.

Chƣơng 1 giới thiệu đề tài, lý do chọn đề tài, trình bày tổng quan nội dung nghiên

cứu và bố cục luận văn.

Chƣơng 2 trình bày các khái niệm cơ bản phục vụ cho đề tài bao gồm các vấn đề liên quan trong kiểm thử dựa trên mô hình, phƣơng pháp đặc tả mô hình bằng máy trạng thái UML. Các khái niệm về biểu đồ tuần tự và các phân đoạn trong thiết kế. Cuối cùng là giới thiệu đồ thị dòng điều khiển và đề xuất ba độ đo kiểm thử áp dụng cho bài nghiên cứu.

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ông thƣờ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ác phâ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áp sinh 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ĩa củ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 (Unified Modeling Language) để phân tích, thiết kế phần mềm trƣớc khi đi vào triển khai. Sản phẩ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ụ cho thiế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à định hƣớ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ảm thiể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àm giả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ột phƣơ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. Trong chƣơ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à ứng dụ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ƣơng phá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ện cho 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 đƣợc gọ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àn toà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ừu tƣợ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ƣợng tƣơ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ều nà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ác trƣờ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ựa thô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 ra mong đợ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ủa SUT. 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ệu kiể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 tra tớ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 ca kiể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ĩa kiể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ủa SUT, cũng nhƣ mối quan hệ giữa chúng, đồng thời mô tả đầu vào và đầu ra cho từ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 duy nhấ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ác phƣơ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ủa SUT. Đâ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ốt nhấ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ái hiệ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ựa

trê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òn phả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ới mỗ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 thi cá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.

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

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à ít phổ 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ợp hơ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 đƣợc dù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ạng thái UML thƣờng đƣợc sử dụng cho các lớp đối tƣợng. Trong UML, một trạng thái ứng vớ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ác giá 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 đƣợc kí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ép chuyể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ểm thử 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ần mề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ỗi trong 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ảm thiể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ểm thử 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ƣời kiể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ông chỉ 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ận khoa 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ữu hiệ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ích thƣớ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ên viê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ả mong muố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ác phâ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 đối tƣợ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ó ba loạ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ều khiể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ểu thứ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ác sai. 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ì cho phé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ần giố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.2 Phân đoạn Alt.

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ột cận dƣới (minint), một cận trên (maxint) và một biểu thức đúng-sai (boolean). Sau minint lầ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ơn hoặc bằng maxint thì vòng lặp vẫn tiếp tục.

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

Hình 2.5 Phân đoạn Loop với cận trên bằng cận dƣới bằng 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.

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ạn Loop 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ểm tra. 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ệc kiể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ạn tƣơ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ác nhau 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ỗi toá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: searchYahoo phả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ự sao cho 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ình 2.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.

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

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

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 vi củ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ép xá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ên phâ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.

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ệp khác vẫn đƣợc thực thi bình thƣờng.

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ệp khá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.

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ừng lạ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ực thi 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ặc Consider. 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ạn Consider. 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ệ.

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

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ày khô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 đƣợc chồ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 khi làm bất cứ thứ gì khác. Các cuộc gọi thƣờng thì đan xen nhau thoải mái.

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 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 định

bằ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ột tậ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ực hiệ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 dung hơ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

ID Input EO RO Note

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

ID Input EO RO Note

tc1 Bi-FN1-B1-JN1-Bk

tc2 Bi-FN1-B2-JN1-Bk

C3: Độ 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.

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

Input EO RO Note ID

Bi-FN1-B1-JN1-Bk tc1

Bi-FN1-B2-JN1-Bk tc2

Bi-FN1-B1-B2-JN1-Bk tc3

Với ví dụ Hình 2.16, ngoài các ca kiểm thử thông thƣờng không xét đến trƣờng hợp các thông điệp song song có điểm chia sẻ dữ liệu ta thu đƣợc hai ca kiểm thử ct1 và ct2 nhƣ ảng 2.3. Ngoài ra, vì hai thông điệp B1 và B2 nằm trong phân đoạn Par nên chúng có thể đƣợc thực hiện song song hoặc đảo trật theo một thứ tự bất kì. Trong trƣờng hợp này ta thu đƣợc một ca kiểm thử khác là tc3 (Bi-FN1-B1-B2-JN1-Bk) nhƣ ảng 2.3. 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ực thi 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ứa hai 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ệu quả, 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ất nhiề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ích xuấ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ệu thiế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ủa

cá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.2 Thiết kế ràng buộc.

Một lƣu ý khác trong quá trình thiết kế là các đối tƣợng, thông điệp đƣợc đƣa vào trong thiết kế, khi không còn sử dụng nữa phải đƣợc xóa triệt để trong trình duyệt cây dự án. Hình 3.4 biểu diễn các trục thời gian, phân đoạn đƣợc thêm vào cây thƣ mục dự án khi thiết kế trên phần mềm Enterprise Architect. Khi các phân đoạn và các trục thời gian này đƣợc xóa bỏ trên thiết kế, một vài trƣờng hợp chúng không tự động đƣợc xóa bỏ trên cây thƣ mục (tùy thuộc vào phiên bản phần mềm Enterprise Architect). Việc này dẫn tới tệp xmi đƣợc trích xuất sai so với thiết kế thực tế thiết kế, làm ảnh hƣởng tới quá trình phân tích, bóc tách dữ liệu thiết kế từ tệp xmi. Vì vậy, các thành phần khi không đƣợc sử dụng trong thiết kế phải đƣợc xóa bỏ triệt để trong cây thƣ mục để đảm bảo tính chính xác khi chuyển đổi về định dạng xmi.

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ều thà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 động khá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ột cô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ày chú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ùng thuậ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ông nhữ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ều khiể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ệu theo 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.1 miê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

Khóa Ý nghĩa

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

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

Kết thúc một phân đoạn

Kết thúc một thông điệp

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ật toá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,

1: create initial node in, node x;

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

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ác

bƣớ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.

 Khởi tạo nốt kết thúc, nối các cạnh giữa các nốt kế tiếp nhau thu đƣợc đồ thị CFG

hoàn chỉnh.

Thuật toán 2: Phân tích các phần tử trong hàng đợi queue (processElement). [3]

Đầu vào: queue: hàng đợi chứa thông tin các phân đoạn, thông điệp và ràng buộc

OCL, curNode A (nốt bắt đầu), Sequence Diagram: D

Đầu ra: exitNode A, CFG

2: x= queue.pop();

1: while (queue != empty) do

3: if (x==fragment) and (x.type=='opt' or 'alt' or 'loop') then

Create a DN ; 4:

ConnectEdge(curNode,DN); 5:

6: else if (x==message) then

7: begin

8: BN=CreateBlockNode() //BN is message or a set of message

9: for each message m

10: begin

11: get receiver class in r.className

12: msg=returnMsgStructure(D, m)

13: attr=returnAttributeStructure(D, OCL_Contraint)

14: for all variables in m

15: attachAttributeInfor(attr,m); //attach constraint c[i] to msg

17: ConnectEdge(curNode,DN);

16: end for;

18: exitNode =BN;

19: end for;

20: else if (x==operand) and (x.guard!=null) then

21: attachGuardtoEdge()

22: curNode = DN;

23: else if (x== fragment) and (x.type=='par' or 'seq') then

24: Create forkNode FN;

25: ConnectEdge(curNode,FN);

26: curNode = FN;

27: for each operand

29:

isAsynToBN() //attach isAsyn toBN with

28: Create BN to coressponding msg;

30: messages of operands having sharing data

31: else if (x== fragment) and (x.type=='ignore') then

32: if(message.attribute==x.attribute)

33: Remove BN to coressponding msg;

34: else if (x== fragment) and (x.type== 'consider') then

35: if (message.attribute!=x.attribute)

36: Remove BN to coressponding msg;

37: else if (x== fragment) and (x.type=='neg') then

38: Create forkNode FN;

39: ConnectEdge(curNode,FN);

40: curNode = FN;

41: if (message from inside linelife)

42: Create BN to the first branch;

44: Create BN to the second branch;

43: else if (message from outside linelife)

45: else if (x== fragment) and (x.type=='assert') then

46: if(message.attribute==x.attribute)

47: Create BN to coressponding msg;

48: else if (x== fragment) and (x.type=='break') then

49: if (curNode inside a fragment)

50: Exit current fragment;

51: else jump to exitNode;

52: else if (x=='EOF' and x.type=='alt' or 'opt') then //termination condition of frag alt

or opt

53: Create merge node MN

54: ConnectEdge(curNode,MN);

55: exitNode =MN;

57: Create join node JN

56: else if (x=='EOF' and x.type=='par' or 'seq' or „neg‟) then

58: ConnectEdge(curNode,JN);

59: exitNode =JN;

60: else if (x=='EOF' and x.type=='loop') then

61: attachLoopstoEdge() //attach number of loops to Edge

62: ConnectEdge(curNode,DN);

63: curNode=DN;

64: else if (x=='EOF' and x.type=='ignore' or „consider‟ or „assert‟) then

65: continue;

66: end if

67: return exitNode;

68: end while

Thuật toán 2 với đầu vào là nốt bắt đầu và hàng đợi chứa thông tin các thông điệp thu thập đƣợc từ tệp xmi thông qua thuật toán 1. Đầu ra là đồ thị CFG tƣơng ứng với thiết kế. Nguyên tắt hoạt động của thuật toán 2 nhƣ sau:

 Đọc từng phần tử trong hàng đợi, nếu gặp thông điệp thì tạo một nốt đơn N.  Nếu gặp một phân đoạn, kiểm tra xem đó là phân đoạn nào. o Nếu gặp opt, alt, loop: tạo nốt quyết định DC. o Nếu gặp par, seq: tạo nốt rẽ nhánh FN. o Nếu gặp ignore: bỏ qua các thông điệp thỏa mãn điều kiện phân đoạn

ignore.

o Nếu gặp consider: chỉ xem xét các thộng điệp thỏa mãn điều kiện phân đoạn

consider.

o Nếu gặp neg: tạo nốt rẽ nhánh FN, tiếp tục kiểm tra các thông điệp nằm trong phân đoạn neg. Nếu thông điệp nào xuất phát từ các trục thời gian bên trong phân đoạn, thêm vào nhánh thứ nhất. Nếu thông điệp nào xuất phát từ các trục thời gian bên ngoài phân đoạn, thêm vào nhánh thứ 2. Điều này thỏa mãn nếu hai thông điệp là trái ngƣợc nhau thì sẽ không bao giờ sảy ra đồng thời trong cùng một ca sử dụng.

o Nếu gặp assert: chỉ kiểm tra các thông điệp thỏa mãn điều kiện phân đoạn assert. Các thông điệp khác bỏ qua cho tới khi thoát khỏi phân đoạn hiện tại. o Nếu gặp break: thoát khỏi phân đoạn hiện tại hoặc nhảy về nốt kết thúc nếu

đang không ở trong một phân đoạn nào cả.

 Nếu gặp EOF (End Of Fragment): kiểm tra phân đoạn đang xử lý:

o Nếu là EOF của phân đoạn par, seq hoặc neg: tạo một nốt FN và liên kết tất

cả các nhánh.

o Nếu là EOF của loop: nốt kết thúc của phân đoạn là nốt quyết định của vòng

lặp.

Quá trình xử lý các phân đoạn đƣợc thực hiện đệ qui lồng vào nhau để đảm bảo tính đúng đắn khi các phân đoạn thiết kế lồng nhau. Thuật toán kết thúc khi tất cả các phần tử trong hàng đợi đƣợc duyệt xong.

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

Sau khi áp dụng thuật toán biến đổi sinh đồ thị dòng điều khiển ta thu đƣợc kết quả

tƣơng ứng đối với từng phân đoạn nhƣ sau:

Biến đổi tƣơng ứng đối với phân đoạn Alt: Phân đoạn Alt đại diện cho một toán tử lựa chọn. Trong lập trình, phân đoạn Alt đƣợc hiểu nhƣ một hàm “if-else”. Vì vậy, trên biểu đồ CFG phân đoạn Alt là một nốt rẽ nhánh DC và kết thúc bởi nốt JN. Sau nốt rẽ nhánh của phân đoạn Alt có thể bao gồm hai hay nhiều nhánh khác nhau tùy thuộc vào cấu trúc cũng nhƣ thiết kế của phân đoạn Alt trên biểu đồ tuần tự. Hình 3.5 biễu diễn mô hình biến đổi tƣơng ứng của phân đoạn Alt sang đồ thị CFG.

Biến đổi tƣơng ứng đối với phân đoạn Opt: Phân đoạn Opt đại diện cho một toán tử lựa chọn khác nhƣng chỉ nhận giá trị đúng. Trong lập trình, phân đoạn Opt đƣợc hiểu nhƣ một hàm kiểm tra hoặc hàm “if” chỉ nhận một giá trị đúng. Ngƣợc lại thì không làm gì cả và chuyển sang nốt tiếp theo. Vì vậy thiết kế của phân đoạn Opt trên đồ thị CFG là một nốt quyết định DC nhƣng chỉ có hai nhanh trong đó một nhánh đúng cho phép thực hiện các thông điệp tiếp theo, nhánh còn lại không làm gì cả (bỏ qua các thông điệp trong phân đoạn Opt). Hình 3.6 biễu diễn mô hình biến đổi tƣơng ứng của phân đoạn Opt sang đồ thị CFG.

Biến đổi tƣơng ứng đối với phân đoạn Loop: Phân đoạn Loop đại diện cho một vòng lặp và kiểm tra giá trị tại nốt điều kiện lặp. Trong lặp trình phân đoạn Loop tƣơng ứng với các vòng lặp “while, for, repeat, v.v”. Tất cả các phƣơng thức lặp đều có điều kiện lặp để giới hạn số vòng lặp. Vì vậy trong đồ thị CFG phân đoạn Loop cũng đƣợc biểu diễn bằng một nốt quyết định DC tuy nhiên không có JN ở cuối phân đoạn nhƣ Alt hay Opt. Mà nốt kết thúc phân đoạn Loop là chính nó để kiểm tra lại điều kiện lặp và chuyển sang nốt tiếp theo khi điều kiện lặp không còn thỏa mãn. Hình 3.7 biễu diễn mô hình biến đổi tƣơng ứng của phân đoạn Loop sang đồ thị CFG. Việc sinh ca kiểm thử cho điều kiện vòng lặp là rất phức tạp bởi vì trong hầu hết các trƣờng hợp điều kiện vòng lặp bị thay đổi, giá trị biến bên trong bị thay đổi sau mỗi lần thực hiện những câu lệnh trong vòng lặp.

Ví dụ vòng lặp for trong thiết kế ứng với đoạn mã nguồn sau:

For (int i = 0; i < 10; i++) {

money = money + 500;

if (money > 5000) {

break;

}

Từ mã nguồn ta thấy vòng lặp cho phép lặp tối đa 10 lần, sau mỗi lần lặp giá trị money bị thay đổi. Trong một số trƣờng hợp vòng lặp có thể bị ngắt (không lặp đủ 10 lần) vì thoải mãn điều kiện bên trong. Những thay đổi này gây khó khăn trong việc xây dựng hệ và sinh dữ liệu kiểm thử sau khi đã có ca kiểm thử. Điều kiện lặp đƣợc đọc một lần và đƣa đƣa vào hệ để giải sinh dữ liệu kiểm thử, tuy nhiên nếu số lần lặp nhiều hơn một sẽ có tƣơng ứng số ràng buộc phải đƣa vào để giải hệ. Việc này là không thể thực thi khi chƣa có mã nguồn. Đây cũng là một trong những nhƣợc điểm của kiểm thử dựa trên mô hình. Để giải quyết bài toán này, tất cả các vòng lặp đƣợc qui ƣớc số vòng lặp là một (khi sinh ca kiểm thử và dữ liệu kiểm thử).

Biến đổi tƣơng ứng đối với phân đoạn Break: Phân đoạn Break cho phép thoát ra khỏi vòng lặp hay các nốt quyết định khác đang thực thi tới nó và nhảy tới bƣớc tiếp theo. Trong trƣờng hợp phân đoạn Break không nằm trong phân đoạn nào thì nó sẽ nhảy tới nốt kết thúc. Trong lặp trình, phân đoạn Break có ý nghĩa tƣơng tự với lệnh ngắt (break), tuy nhiên lệnh “break” trong lặp trình chỉ thƣờng sử dụng để thoát ra một vòng

lặp hay một hàm điều kiện chứ không sử dụng để nhảy tới cuối chƣơng trình. Hình 3.8 biễu diễn mô hình biến đổi tƣơng ứng của phân đoạn reak sang đồ thị CFG.

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

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

Biến đổi tƣơng ứng đối với phân đoạn Par: Phân đoạn Par đại diện cho toán tử lựa chọn, có thể có nhiều hơn 2 lựa chọn rẽ nhánh và các nhánh này có thể đƣợc thực hiện đồng thời. Để biểu diễn sự khác biệt này, trên đồ thị CFG phân đoạn Par sẽ đƣợc biểu diễn bởi một nốt FN và kết thúc bằng nốt JN. Các nhánh trong phân đoạn Par đƣợc qui ƣớc cho phép hoạt động song song nhau. Hình 3.9 biễu diễn mô hình biến đổi tƣơng ứng của phân đoạn Par sang đồ thị CFG.

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

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

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

Biến đổi tƣơng ứng đối với phân đoạn Seq: Về cơ bản phân đoạn Seq có cấu tạo nhƣ phân đoạn Par, tuy nhiên điểm khác biệt cần lƣu ý là, với phân đoạn Seq các thông điệp cùng nằm trên một trục thời gian (cùng truyền tới một trục thời gian) thì buộc phải thực hiện theo thứ tự (trình tự thời gian). Trong ví dụ Hình 3.10, bình thƣờng khi biến đổi sang đồ thị CFG có thể tạo thành 3 nhánh thực thi song song nhau. Tuy nhiên vì m3 và m4 cùng truyền tới I3 nên m3 chắc chắc phải đƣợc thực thi trƣớc m4. Vậy, để đảm đƣợc điều này m3 và m4 sẽ đƣợc gộp vào một nhánh và sắp xếp theo đúng trình tự. Về thiết kế biến đổi này sẽ bỏ qua một trƣờng hợp là chƣơng trình thực thi m3 và không thực thi m4. Tuy nhiên đây chỉ là một khả năng nhỏ trong rất nhiều khả năng khác. Hơn nữa việc thực thi thêm m4 cũng không gây ảnh hƣởng nhiều trong thiết kế kiểm thử nên có thể chấp nhận đƣợc.

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

Biến đổi tƣơng ứng đối với phân đoạn Ignore: Phân đoạn Ignore sẽ bỏ qua các thông điệp đƣợc khai báo trƣớc. Trong ví dụ Hình 3.11, thông điệp „set‟ sẽ bị bỏ qua trong suốt thời gian mà phân đoạn còn hiệu lực.

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

Biến đổi tƣơng ứng đối với phân đoạn Consider: Ngƣợc lại với phân đoạn Ignore, phân đoạn Consider sẽ chỉ xem xét các thông điệp đƣợc khai báo trƣớc. Các thông điệp còn lại sẽ bị bỏ qua trong suốt thời gian phân đoạn còn hiệu lực. Hình 3.12 biễu diễn mô hình biến đổi tƣơng ứng của phân đoạn Consider sang đồ thị CFG.

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

Biến đổi tƣơng ứng đối với phân đoạn Neg: Với phân đoạn Neg, trong khi các thông điệp bên trong phân đoạn đang thực thi thì bất kì một thông điệp nào trong cùng khoảng thời gian đó đi từ các trục thời gian (linelife) bên ngoài phân đoạn vào đều bị bỏ qua hoặc không cho phép thực hiện. Ngƣợc lại, nếu một thông điệp bên ngoài đi vào vào phân đoạn Neg đang đƣợc thực hiện thì các thông điệp bên trong phân đoạn Neg sẽ không đƣợc phép thực hiện hoặc bị bỏ qua. Trong ví dụ Hình 3.13, thông điệp m2 sẽ không đƣợc thực thi do đƣợc truyền từ đƣờng I1 từ bên ngoài phân đoạn Neg vào. Và ngƣợc lại, nếu nhƣ thông điệp m2 đang đƣợc thực thi thì các thông điệp khác bên trong phân đoạn Neg là m3 sẽ không đƣợc phép thực hiện hoặc bị bỏ qua.

Biến đổi tƣơng ứng đối với phân đoạn Assert: Phân đoạn Assert thƣờng sử dụng kết hợp với Ignore hoặc Consider để biểu diễn các trƣờng hợp bắt buộc hoặc ngoại lệ xảy ra bên trong. Ví dụ Hình 3.14, có 3 thông điệp q, v, w đƣợc cho phép trong Consider tuy nhiên trong khoảng thời gian phân đoạn Assert diễn ra thì chỉ cho phép thông điệp q đƣợc thực thi, các thông điệp khác nếu xảy ra sẽ bị bỏ qua. Sau khi kết thúc phân đoạn Assert thì các thông điệp khác trong Consider diễn ra bình thƣờng.

Biến đổi tƣơng ứng đối với phân đoạn Strict: Phân đoạn Strict dùng để diễn tả sự tuân thủ nghiêm ngặt theo trình tự của các thông điệp. Ý nghĩa của phân đoạn là không cho phép hoán đổi hoặc thực thi sai trình tự trong mọi tình huống. Điều này tuân thủ phƣơng pháp chung trong xây dựng đồ thị CFG từ biểu đồ tuần tự theo thời gian. Các ca kiểm thử của Strict sẽ luôn đƣợc bao phủ bởi các ca kiểm thử ở mức độ bao phủ C2. Hình 3.15 biễu diễn mô hình biến đổi tƣơng ứng của phân đoạn Strict sang đồ thị CFG.

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

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

Phân đoạn Critical region: Do đặc tính ƣu tiên vùng then chốt, phân đoạn Critical region giống nhƣ một công tắc ngắt chƣơng trình và ƣu tiên thực hiện các sự kiện trong phân đoạn khi thỏa mãn điều kiện, sau đó quay lại thực hiện tiếp công việc ở vị trí trƣớc khi xảy ra. Điều này phá vỡ qui tắc về thời gian của biểu đồ tuần tự, khi biến đổi sang đồ thị dòng điều khiển không kiểm soát đƣợc việc thực thi đƣờng kiểm thử (do khó kiểm soát khi nào thì phân đoạn ngắt quãng và chuyển xuống để thực thi). Vì vậy, để việc kiểm thử hiệu quả hơn các mô đun chứa phân đoạn critical region sẽ đƣợc thiết kế các ca kiểm thử riêng biệt và không đƣợc đề xuất trong bài nghiên cứu này.

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

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

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

Đồ thị dòng điều khiển đƣợc sinh ra từ biểu đồ tuần tự đƣa ta trở về bài toán quen thuộc trong kiểm thử hộp trắng. Có nhiều phƣơng pháp sinh luồng kiểm thử có thể đƣợc áp dụng nhƣ: thuật toán tìm theo chiều sâu, thuật toán tìm theo chiều rộng, v.v.

Xét về mặt giải thuật, cả hai thuật toán duyệt theo chiều rộng và thuật toán duyệt theo chiều sâu đều có thể đƣợc sử dụng. Tuy nhiên, với mong muốn sinh lần lƣợt các ca kiểm thử tƣơng ứng, tức duyệt lần lƣợt từng đƣờng đi từ điểm bắt đầu tới điểm kết thúc thì thuật toán duyệt theo chiều sâu là phù hợp hơn. Vì vậy, trong bài nghiên cứu này tôi sử dụng giải thuật thuật toán duyệt theo chiều sâu để duyệt đồ thị CFG và sinh ca kiểm thử.

Thuật toán duyệt theo chiều sâu là thuật toán mà quá trình tìm kiếm đƣợc phát triển từ đỉnh con đầu tiên của nút đang tìm kiếm cho tới khi gặp đƣợc đỉnh cần tìm hoặc tới một nút không có con. Khi đó giải thuật quay lui về đỉnh vừa mới tìm kiếm ở bƣớc trƣớc và tiếp tục tìm kiếm cho tới khi duyệt hết tất cả các đỉnh trong đồ thị.

Ví dụ áp dụng thuật toán duyệt theo chiều sâu cho đồ thị Hình 3.16. Tìm kiếm ƣu tiên chiều sâu bắt đầu thăm đỉnh A, đi theo cạnh trái, tiếp tục tìm kiếm xong ở cây con trái mới chuyển sang tìm kiếm ở cây con phải. Thứ tự thăm viếng các đỉnh là: A, B, D, F, E, C, G. Quá trình viếng thăm các đỉnh diễn ra nhƣ sau: Sau khi thăm đỉnh A, vì chƣa đƣợc thăm nên theo cạnh A ta thăm , tiếp tục theo cạnh BD tới viếng thăm D. Từ D không thể tiếp tục đi xa hơn, ta quay lại B. Từ , theo F đến thăm F, từ F đến thăm E. Từ E vì A đã viếng thăm nên ta quay lại F, rồi quay lại B. Tại B vì tất cả các khả năng từ đã xem xét nên ta quay lại A. Từ A, quá trình tiếp tục với các đỉnh C và G.

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

Áp dụng thực tế cho bài nghiên cứu, ví dụ cho đồ thị dòng điều khiển nhƣ Hình 3.17. Dựa vào mối liên hệ giữa các nốt trong đồ thị dòng điều khiển dùng thuật toán biến đổi đƣa dữ liệu về dạng chuẩn nhƣ miêu tả ở Bảng 3.2.

Qui trình:

 Nốt Start đƣợc đánh số 0 nối với nốt 1 thu đƣợc cặp dữ liệu 0-1.  Nốt 1 đƣợc nối với nốt 2 thu đƣợc cặp dữ liệu 1-2.  Nốt 2 nốt tới nốt 3 và nốt 4 thu đƣợc dòng dữ liệu 2-3-4.  Nốt 3 nối tới nốt 5 thu đƣợc cặp dữ liệu 3-5.  Nốt 4 nối tới nốt 5 thu đƣợc cặp dữ liệu 4-5.  Nốt 5 nối tới nốt 6 thu đƣợc cặp dữ liệu 5-6.  Nốt 6 nối với nốt kết thúc.

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

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

Nốt bắt đầu

Nốt kết thúc Dữ liệu thu thập

Start 1 0 1

1 2 1 2

2 3, 4 2 3 4

3 5 3 5

4 5 4 5

5 6 5 6

6 End |

Thuật toán 3: Sinh ca kiểm thử cho các toán tử thông thƣờng.

Đầu vào: Thông tin đƣờng nối tất cả các cạnh trong đồ thị CFG.

E = {(x, y) | x, y A F} : tập tất cả các cạnh trong đồ thị CFG

Trong đó:

sourceList{x}: tập các nốt nguồn - các đỉnh xuất phát x trong tập cạnh (x, y).

targetList{y} : tập các nốt đích - các đỉnh kết thúc y trong tập cạnh (x, y).

Đầu ra: allTestPath p: là tập tất cả các đƣờng kiểm thử

1: Create new String: danhsachke;

2: danhsachke = "-1 0\n";

3. for each element sourceList

4: danhsachke += sourceNodeId(i) + " " + targetNodeId(i);

5: if (current sourceNode == current targetNode)

6: danhsachke += " " + target.get(j).getNodeId();

7: end if

8: danhsachke += "\n";

9: end for

10: Create new String maTranKe = danhsachke; // maTranKe = "0 1\n1 2 3\n2 1\n3

4\n4 5\n5 4 6\n6 7 8\n7 9 10\n9 -1\n10 -1\n8 11\n11 8 12\n12 -1"

11: allTestPath p = new getAllPaths(maTranKe); // thuật toán duyệt theo chiều sâu

sinh ca kiểm thử

Thuật toán 3 miêu tả quá trình sinh ca kiểm thử cho các thiết kế chứa các phân đoạn thông thƣờng không có luồng song song. Đầu vào là đồ thị dòng điều khiển (ví dụ Hình 3.17) và đầu ra là chuỗi các đƣờng kiểm thử. Kết quả thu đƣợc ở Bảng 3.2 là một kết quả trung gian trong quá trình biến đổi. Các bƣớc thực hiện nhƣ sau: Từ đồ thị dòng điều khiển duyệt từng nốt và kiểm tra nốt tiếp theo thu đƣợc thông tin ma trận kề (Bảng 3.2). Kết quả ma trận kề đƣợc đƣa vào thuật toán 4 duyệt theo chiều sâu để tìm ra tất cả các đƣờng kiểm thử có thể đi từ nốt bắt đầu cho tới nốt kết thúc.

Thuật toán 4: Duyệt theo chiều sâu để sinh đƣờng kiểm thử (traverse).

Đầu vào: String maTranKe; với maTranKe là chuỗi các nốt khởi đầu và kết thúc của

các cạnh trong đồ thị CFG. Ví dụ cấu trúc một ma trận kề: maTranKe = "0 1\n1 2 3\n2

1\n3 4\n4 5\n5 4 6\n6 7 8\n7 9 10\n9 -1\n10 -1\n8 11\n11 8 12\n12 -1"

Đầu ra: String testPathString; là chuỗi tất cả các đƣờng kiểm thử

1: CreateObject Vertex (int data, int[] branchId); // tạo đối tƣợng Vertex

3: Create new ArrayList vertexPath;

2: Create new ArrayList vertexList ;

4. Create new ArrayList testPath;

5: Split maTranke line by line;

6: for each line of maTranke

7: vertexList.add(id, branchId)); // thêm tất cả các nốt nguồn và nhánh vào

vertexList là giá trị trung gian dùng để duyệt.

8: traverse(firstNode, new ArrayList() vertexPath) // duyệt ma trận kề

bắt đầu tại nốt đầu tiên

9: vertex v = vertexList.get(0);

10: if (v == null or v.getid() == -1) // kết thúc

11. testPath.add( vertexPath.clone()); // lƣu đƣờng đi thành đƣờng kiểm thử

12: else if (check(vertexPath, v.getId())) // duyệt tiếp nếu chƣa kết thúc

13: vertexPath.add(v);

14: int temp = v.getBranchLengh();

16: Vertex u = getVertex(v.getBranchId(i));

15: for (int i = 1; i < temp; i++)

17: traverse(u, vertexPath); // duyệt đệ qui

18: vertexPath.remove(vertexPath.size() - 1);

19: end for

20: end if

21: end for

22: return String testPathString = testPath.toString();

Thuật toán 4 có đầu vào là ma trận kề, đầu ra là các ca kiểm thử. Các bƣớc thực

hiện nhƣ sau:

 Khởi tạo một đối tƣợng vertex có cấu trúc Vertex (int data, int[] branchId) trong đó int data để chứa giá trị đang duyệt, int[] branched là mảng chứa các đƣờng kiểm thử trong quá trình duyệt ma trận.

 Khởi tạo mảng vertexList là biến đổi của ma trận sẽ duyệt.  Khởi tạo mảng vertexPath chứa đƣờng kiểm thử đang đƣợc duyệt.  Bắt đầu duyệt từng phần tử trong vertexList (bắt đầu từ nốt bắt đầu), nếu là nốt

không có rẽ nhánh lần lƣợt thêm vào vertexPath.

 Nếu gặp nốt rẽ nhánh (là nốt đi tới nhiều hơn 1 nốt tiếp theo), tiến hành duyệt đệ qui theo từng nhánh cho tới khi gặp nốt kết thúc thu đƣợc một đƣờng kiểm thử.  Sau khi hoàn thành nhánh thứ nhất, quay lại đệ qui tiêp quá trình duyệt với các

nhánh tiếp theo thu đƣợc các đƣờng kiểm thử còn lại.

 Mỗi đƣờng kiểm thử hoàn thành đƣợc thêm vào mảng testPath để có thể khôi phục

mảng vertexPath về vị trí ban đầu hoặc vị trí bắt đầu đệ qui trƣớc đó.

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

Đối với phân đoạn song song, ngoài việc tìm ra tất cả các đƣờng đi trong đồ thị dòng điều khiển, chúng ta còn phải tìm hiểu các thông số, các biến ở mỗi nốt. Nếu 2 nốt có sử dụng chung một biến thì đƣợc gọi là có chia sẻ dữ liệu. Khi đó kết quả thực thi và tính toán của đƣờng kiểm thử đơn (đƣờng kiểm thử chỉ chứa một trong các nốt có chia sẻ dữ liệu) có thể sẽ bị ảnh hƣởng vì sẽ có hai hành động có khả năng thực hiện cùng lúc, trƣớc hoặc sau lúc đó làm biến đổi giá trị của biến đang thực thi trong đƣờng kiểm thử dẫn tới sai lệch trong kết quả chƣơng trình hoặc kết quả kiểm thử. Để khắc phục điều này cần phải thực hiện chung các nốt có chia sẻ dữ liệu trong cùng một test case mà chƣơng trình có thể thực hiện.

Ví dụ nốt 3 và nốt 4 trong đồ thị Hình 3.16 là hai nốt có chia sẻ dữ liệu (và là hai nốt song song vì thuộc phân đoạn par: phân đoạn par khi biến đổi sang CFG sẽ bắt đầu từ một nốt FN và kết thúc bằng nốt JN). Khi đó ngoài 2 đƣờng kiểm thử thông thƣờng: 0-1- 2-3-5-6-End và 0-1-2-4-5-6 End sẽ có thêm 2 đƣờng đi có thể đƣợc hình thành nhƣ là: 0- 1-2-3-4-5-6-End và 0-1-2-4-3-5-6-End.

Kỹ thuật áp dụng trong việc sinh các ca kiểm thử song song là đánh dấu các điểm có chia sẻ dữ liệu: Nốt (data.shared = true) nếu phát hiện ra hai nốt có chung một biến bên trong. Sau đó sắp xếp hai nốt này đi chung với nhau (có hoán đổi vị trí) trong một ca kiểm

thử tạo ra các ca kiểm thử mới. Trong trƣờng hợp trƣớc và sau hai nốt này còn có các nốt khác thì thứ tự các nốt trƣớc nó phải đƣợc giữ nguyên.

Thuật toán sinh ca kiểm thử chứa các nốt có chia sẻ dữ liệu nhƣ sau:

Thuật toán 5: Sinh ca kiểm thử cho các toán tử song song.

Đầu vào: sourceList{x}; targetList{y} : là tập các đỉnh đầu và đỉnh cuối của tất cả các

cạnh trong CFG: E = {(x, y) | x, y A F}.

các phân đoạn song song.

Đầu ra: allTestPath p: là tập tất cả các đƣờng kiểm thử bao gồm đƣờng kiểm thử cho

1: Create new String: danhsachke;

2: danhsachke = "-1 0\n";

3: for each element sourceList

4: if (current sourceNode == par or seq)

5: if (current sourceNode is shared data with forwardNode branch(x))

6: danhsachke += sourceNodeId(i) + targetNodeId(i) + startNode in branch(x);

7: else if (current sourceNode is shared data with backwardNode branch(x))

8: danhsachke += sourceNodeId(i) + targetNodeId(i) +

targetNodeId(backwardNodeId());

9: else if

10: danhsachke += sourceNodeId(i) + " " + targetNodeId(i);

else 11:

danhsachke += sourceNodeId(i) + " " + targetNodeId(i); 12:

14:

danhsachke += "\n";

13: end if

15: end for

16: Create new String maTranKe = danhsachke; // maTranKe = "0 1\n1 2 3\n2 1\n3

4\n4 5\n5 4 6\n6 7 8\n7 9 10\n9 -1\n10 -1\n8 11\n11 8 12\n12 -1"

17: allTestPath p = new getAllPaths(maTranKe); // thuật toán 4 - duyệt theo chiều sâu

sinh ca kiểm thử

Thuật toán 5 trình bày qui trình sinh ca kiểm thử cho các toán tử song song chứa điểm chia sẻ dữ liệu. Mục đích của thuật toán 5 là sinh ra một ma trận kề tƣơng tự nhƣ thuật toán 3, sau đó sử dụng thuật toán 4 để tìm ra tất cả các đƣờng đi thỏa mãn là các ca kiểm thử tƣơng ứng. Thuật toán 5 kiểm tra trong quá trình duyệt nếu gặp các phân đoạn par hoặc seq sẽ kiểm tra tất cả các nốt bên trong. Nếu 2 nốt thuộc hai nhánh khác nhau của đồ thị CFG cùng tác động tới một biến dữ liệu chung thì hai nốt đó đƣợc gọi là hai nốt có điểm chia sẻ dữ liệu. Thuật toán 5 sẽ chuyển đổi giữa hai ca kiểm thử có chứa điểm chia sẻ dữ liệu đó để tìm ra đƣờng đi có đi qua cả hai điểm.

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

Để thực thi đƣợc các ca kiểm thử sinh từ đồ thị dòng điều khiển thì cần có dữ liệu đầu vào cho các ca kiểm thử. Dữ liệu đầu vào đó sẽ đƣợc lấy từ kết quả giải các hệ ràng buộc tƣơng ứng trên từng đƣờng đi của ca kiểm thử. Dữ liệu đƣa vào giải hệ đƣợc thu thập từ ràng buộc OCL và các dữ liệu đƣợc khai báo trên thiết kế theo yêu cầu ở mục 3.1.2. Tất cả đều đƣợc bóc tách từ tệp xmi và lƣu giữ trong các nốt (các thông điệp) tƣơng ứng.

Giữ liệu kiểm thử sẽ đƣợc giải tƣơng ứng cho từng ca kiểm thử. Duyệt từ nốt khởi đầu tới nốt kết thúc để thu thập các thông điệp và ràng buộc. Các ràng buộc và các biến sẽ lƣu trữ trong hai mang tƣơng ứng nhƣ sau:

ArrayList testConstraint

ArrayList DefineList

Trong đó mảng ArrayList DefineList sẽ lƣu giữ các biến, mảng đƣợc khai báo trong dữ liệu test. Trong thiết kế mô hình, các biến này thƣờng cũng sẽ đƣợc khai báo trong các biểu đồ lớp tƣơng ứng trong ULM 2.0.

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

Ví dụ về một mảng DefineList đã đƣợc điền dữ liệu nhƣ sau:

defineList = {int max, int money, double time, float transfer};

Mảng ArrayList testConstraint lƣu giữ các ràng buộc, dữ kiện chƣơng trình cần thực thi. Ví dụ số tiền tối thiểu có trong tài khoản: money >=50, thời gian đƣợc lƣu giữ dƣới dạng số thực: time > 0.

Ví dụ về một mảng testConstraint đã đƣợc fill dữ liệu nhƣ sau:

testConstraint = {max <=10, max >0, money >=50, time > 0, transfer = money/max};

Hai mảng testConstraint, defineList đƣợc dùng làm dữ liệu đầu vào cho công cụ

giải hệ SMT-Solver.

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

SMT-Solver là một chƣơng trình đƣợc phát triển để giải các hệ ràng buộc dựa trên nền tảng Z3. Đƣợc phát triển bởi một nhóm sinh viên trƣờng Đại học Công Nghệ - Đại học Quốc Gia Hà Nội [2]. Đầu vào của SMT-Solver là 2 mảng nhƣ mục 3.4. Đầu ra sẽ là giá trị ngẫu nhiên thỏa mãn các điều kiện trong hệ ràng buộc. SMT-Solve hỗ trợ các loại dữ liệu về số. Mã nguồn SMT solver sẽ đƣợc nhúng vào chƣơng trình để giải các ràng buộc trong các đƣờng kiểm thử và đƣa ra dữ liệu kiểm thử cho các ca kiểm thử tƣơng ứng.

Với đặc thù không đòi hỏi giải ra tất cả các kết quả thỏa mãn đƣờng đi mà chỉ lấy một kết quả thỏa mãn dùng làm dữ liệu kiểm thử. Kỹ thuật sinh ngẫu nhiên đƣợc xem nhƣ

một phƣơng pháp truyền thống để giải hệ ràng buộc. Với những bài toán phức tạp với những biểu thức logic phức tạp thƣờng kỹ thuật sinh ngẫu nhiên sẽ bộc lộ nhƣợc điểm về thời gian giải ra kết quả. Tuy nhiên trong bài toán này, các thiết kế thƣờng chia làm các mô hình nhỏ, các ca kiểm thử không quá phức tạp (kiểm thử đơn vị) nhƣ trong toán học nên kỹ thuật sinh ngẫu nhiên là hoàn toàn phù hợp.

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

Hiện nay, công cụ SMT-Solver đã giải quyết đƣợc với rất nhiều dạng dữ liệu bao gồm cả dữ liệu tuyến tính và phi tuyến tính trong đó dữ liệu phi tuyến tính bao gồm các biểu thức số học, mảng, ma trận, v.v. biểu thức phi tuyến tính nhƣ các hàm lƣợng giác. Hình 3.19 mô tả qui trình giải hệ sử dụng trong bài nghiên cứu, đầu vào là hai mảng:

defineList: chứa thông tin khai báo kiểu dữ liệu đầu vào của các biến. testConstraint: chứa thông tin hệ ràng bucc cần giải.

Công cụ SMT solver đƣợc thiết kế để giải ra kết quả từ hai mảng đầu vào, nếu có nghiệm thỏa mãn hệ ràng buộc ta thu đƣợc kết quả đầu ra (SAT). Ngƣợc lại, nếu hệ vô nghiệm sẽ không có kết quả trả về (UNSAT). Nhƣợc điểm duy nhất và cũng là vấn đề phức tạp nhất với tất cả các phƣơng pháp giải hệ đó là dữ liệu dạng ký tự, chuỗi kí tự (String, ArrayString..). Đây là hạn chế chung của các phƣơng pháp giải hệ tại thời điểm hiện tại. Đối với dữ liệu này để thực hiện đƣợc cần phải biến đổi, mã hóa các kí tự về các dạng dữ liệu quen thuộc trƣớc khi đi vào giải.

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

Để hiểu rõ hơn về ƣu và nhƣợc điểm của phƣơng pháp đƣợc đề xuất trong bài nghiên cứu này. Tôi xin trình bày một về một số nghiên cứu liên quan để thấy đƣợc các vấn đề mà phƣơng pháp cải tiến và tối ƣu đƣợc trong qui trình kiểm thử.

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]. Phƣơng pháp sử dụng đầu vào là biểu đồ tuần tự, sau đó biến đổi về bảng phụ thuộc tuần tự (Sequence Dependency Table) và sử dụng thuật toán di truyền để sinh ca kiểm thử. Thuật toán di truyền sẽ duyệt hết các đƣờng đi trong bảng phụ thuộc tuần tự cho tới khi gặp đƣợc điểm cuối cùng. Tuy nhiên, mục tiêu cuối cùng của bài

nghiên cứu này là tìm ra đƣờng kiểm thử tốt nhất tức 1 đƣờng kiểm thử có thể bao phủ đƣợc nhiều nhất các tình huống có thể xảy ra trƣớc khi kết thúc ca kiểm thử. Vì vây, dữ liệu kiểm thử đƣợc đƣa vào ban đầu là ngẫu nhiên, sau đó sẽ biến đổi tƣơng ứng (thực hiện chéo hoặc thực hiện đột biến) và lặp lại cho tới khi tất cả các đƣờng dẫn tin nhắn đƣợc bao phủ. Phƣơng pháp chỉ đề xuất cách thực hiện cho các thông điệp trong biểu đồ tuần tự. Chƣa đề cập, nghiên cứu cũng nhƣ thực hiện biến đổi với các phân đoạn trong biểu đồ tuần tự.

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à Debasis Samanta [4]. Phƣơng pháp đề xuất cách sinh dữ liệu kiểm thử từ các thông tin, ràng buộc đƣợc đính kèm trong thiết kế biểu đồ lớp, biểu đồ tuần tự và ràng buộc OCL. Cũng với đầu vào là biểu đồ tuần tự sinh đồ thị dòng điều khiển, sinh ca kiểm thử và cuối cùng là dữ liệu kiểm thử. Vì tập trung vào phƣơng pháp sinh dữ liệu kiểm thử nên phƣơng pháp chƣa giải quyết triệt để bài toán biến đổi từ biểu đồ tuần tự sang đồ thị dòng điều khiển (mới chỉ đề xuất phƣơng pháp cho 5/12 phân đoạn trong biểu đồ tuần tự). Phƣơng pháp sinh dữ liệu kiểm thử hạn chế ở dữ liệu số đơn giản, không có khả năng mở rộng sang các loại dữ liệu khác. Ngoài ra, tác giả bài nghiên cứu này cũng mới dừng lại ở nghiên cứu lý thuyết mà chƣa tiến hành thực nghiệm để chứng minh tính khả thi của đề xuất.

Dựa vào vấn đề mà các bài nghiên cứu khác chƣa làm đƣợc, bài nghiên cứu này sẽ đề xuất phƣơng pháp sinh ca kiểm thử và dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML với các ƣu điểm:

 Đề xuất có thực nghiệm phƣơng pháp sinh ca kiểm thử và dữ liệu kiểm thử từ biểu đồ tuần tự. Phƣơng pháp có khả năng áp dụng thực tế cao với 11/12 phân đoạn trong thiết kế biểu đồ tuần tự có thể thực hiện.

 Đề xuất phƣơng pháp sinh ca kiểm thử theo ba mức độ với hiệu quả kiểm thử cao nhất ở độ đo kiểm thử bao phủ mạnh. Bao gồm việc sinh ca kiểm thử cho các toán tử song song có chứa điểm chia sẻ dữ liệu.

 Sinh đồ thị dòng điều khiển thực quan giúp dễ dàng kiểm tra và thao tác trong quá

trình kiểm thử.

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

Để kiểm tra tính đúng đắn, tính khả thi của nghiên cứu, khả năng áp dụng thực tế và hiệu quả của lập trình so với thiết kế. Chƣơng này tôi sẽ giới thiệu công cụ sinh bộ kiểm thử dựa trên mô hình, phần mềm đƣợc gọi là Automation Test Data Synthesis (gọi tắt là ATDS) nhằm mục đích kiểm tra lập trình có đúng với thiết kế hay không. Công cụ đƣợc phát triển bằng Eclipse, ngôn ngữ sử dụng là java, chạy trên nền hệ điều hành Windows 7/8/10. Kiến trúc và nguyên lý hoạt động và hƣớng phát triển của công cụ sẽ đƣợc trình bày ở các phần từ 4.1 đến 4.4.

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

Hình 4.1 biểu diễn cấu trúc công cụ thực nghiệm của luận văn. iểu đồ tuần tự đƣợc thiết kế trên phần mềm Enterprise Architect là phần mềm chuyên dụng đƣợc dùng phổ biến trong các công ty ngày nay. Phần mềm có hỗ trợ tính năng xuất tệp xmi sau khi thiết kế. Tệp xmi là dữ liệu đầu vào dùng để nghiên cứu trong suốt quá trình kiểm thử. Qua quá trình phân tích, dữ liệu từ tệp xmi đƣợc chuyển đổi để sinh ra đồ thị dòng điều khiển. Từ đồ thị dòng điều khiển áp dụng kỹ thuật quét theo chiều sâu để sinh ra đƣờng kiểm thử và các ca kiểm thử tƣơng ứng.

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

Đƣờng kiểm thử là đặc tả chính xác hoạt động của đồ thị dòng điều khiển cũng nhƣ biểu đồ tuần tự đƣợc thiết kế trên UML. Chúng ta cũng bóc tách đƣợc dữ liệu từ tệp xmi và biến đổi sinh ra hệ ràng buộc là đầu vào của công cụ SMT-Solver. Hệ ràng buộc đƣợc giải để sinh ra các bộ dữ liệu kiểm thử cho các ca kiểm thử tƣơng ứng. Bộ kiểm thử này đƣợc dùng để kiểm tra xem việc lập trình có đúng với thiết kế hay không đồng thời kiểm tra tính đúng đắn của thiết kế. Nếu một hệ ràng buộc đƣợc giải ra cho kết quả là vô nghiệm thì khi đó hoặc là đặc tả hay thiết kế sai, hoặc là các ràng buộc có mâu thuẫn dẫn tới ca kiểm thử không thể tồn tại. Điều đó nói lên chƣơng trình (ca sử dụng) sẽ không bao giờ đƣợc thực thi nếu nhƣ mã nguồn đƣợc tạo ra là đúng với thiết kế. Trong trƣờng hợp thu đƣợc kết quả từ việc giải hệ ràng buộc trên đƣờng kiểm thử, kết quả đó sẽ đƣợc dùng làm dữ liệu đầu vào trong ca kiểm thử và thực thi. Kết quả đầu ra đƣợc so sánh với kết quả mong đợi. Nếu kết quả đầu ra khác với kết quả mong đợi cho thấy thiết kế là sai và có lỗi. Nếu kết quả đầu ra đúng với kết quả mong đợi cho thấy thiết kế đã đảm bảo tính đúng đắn so với đặc tả hệ thống.

Dƣới đây là các công đoạn hoạt động của công cụ:

1. Sinh đồ thị dòng điều khiển là chuyển đổi tƣơng ứng của biểu đồ tuần

tự.

2. Sinh kịch bản kiểm thử từ đồ thị dòng điều khiển.

3. Sinh các bộ dữ liệu kiểm thử tƣơng ứng cho các ca kiểm thử.

4. Lƣu giữ kịch bản ra tệp excel phục vụ cho quá trình kiểm thử.

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

Vi xử lý Intel(R) Core(TM) i3/i7-2120 CPU @ 3.30GHz, 3300 Mhz, 2 Core(s), 4 Logical Processor(s)

ộ nhớ vật lý (RAM) 4GB

Hệ điều hành Microsoft Windows 10 Professional

Phiên bản IDE Eclipse Java EE IDE Version 4.5.1

Phiên bản Java Platform 1.8 _ Product 1.8.0_56

Công cụ ATDS đƣợc phát triển trên nền tảng Java và đƣợc thiết kế để hoạt động trên môi trƣờng window. Công cụ sử dụng đầu vào là biểu đồ tuần tự lƣu trữ dƣới định dạng xmi. Với giao diện trực quan, công cụ cho phép vẽ đồ thị dòng điều khiển và hiển thị ra màn hình. Đồ thị dòng điều khiển là dẫn xuất biến đổi tƣơng ứng từ biểu đồ tuần tự theo các qui luật biến đổi đƣợc đề xuất trong chƣơng 3. Sau khi vẽ đồ thị dòng điều khiển,

công cụ tìm kiếm và thực thi tất cả các đƣờng kiểm thử có thể đi qua để sinh các ca kiểm thử và dữ liệu kiểm thử tƣơng ứng cho từng ca kiểm thử. Các ca kiểm thử đƣợc sinh ra theo 3 cấp độ kiểm thử đã trình bày ở chƣơng 2 phần 2.4. Ngƣời dùng có thể chọn vào từng ca kiểm thử để kiểm tra đƣờng đi. Đƣờng đi của ca kiểm thử đƣợc hiển thị trực tiếp trên đồ thị dòng điều khiển tƣơng ứng với ca kiểm thử đang đƣợc chọn. Cuối cùng, sau khi hoàn thành tất cả các khâu, ngƣời dùng có thể thực hiện xuất ra tệp excel để phục vụ cho mục đích kiểm thử. Bảng 4.1 trình bày các thông số về môi trƣờng thực nghiệm công cụ.

4.2 Thực nghiệm

Ví dụ 1:

Bài toán: Phân loại học sinh theo thang điểm.

ƣớc 1: Truy cập điểm của học sinh.

ƣớc 2: Kiểm tra điểm của học sinh và phân loại (Yếu, Trung Bình, Tốt).

ƣớc 3: Trả về phân hạng của học sinh.

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

Đầu ra:

 Đồ thị dòng điều khiển - Hình 4.3: nốt DN là nốt biến đổi tƣơng ứng của phân đoạn alt (bắt đầu phân đoạn). Nốt JN là nốt kết thúc phân đoạn alt. Các nốt còn lại (BN) là biến đổi tƣơng ứng của các thông điệp thông thƣờng.

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

 Ca kiểm thử độ bao phủ yếu – Hình 4.4: chỉ bao gồm một ca kiểm thử duy nhất vì trong đồ thị dòng điều khiển chỉ chứa một nốt quyết định. Sau khi duyệt đƣờng đi thứ nhất thỏa mãn điều kiện đi qua tất cả các nốt quyết định và rẽ nhánh trong đồ thị thuật toán dừng lại và cho kết quả các ca kiểm thử độ bao phủ yếu.

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

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

 Ca kiểm thử mức độ bao phủ trung bình – Hình 4.6: gồm ba ca kiểm thử tƣơng ứng

với ba nhánh của nốt quyết định cần phải đi qua.

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

Ghi chú: Vì bài toán không dùng tới các toán tử song song nên không có ca kiểm thử ở mức độ mạnh (mức độ trung bình đƣợc xem là mạnh cho ví dụ này).

 Các ca kiểm thử đƣợc xuất ra file excel dùng cho kiểm thử.

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

Ví dụ 2: Bài toán chuyển khoản - quản lý tài khoản ngân hàng.

Đầu vào của công cụ - Hình 4.8: miêu tả quá trình quản lý tài khoản ngân hàng, thực hiện nhiều thao tác khác nhau tới cùng một tài khoản trong đó cho phép thực hiện đồng thời việc gửi tiền, rút tiền, kiểm tra tài khoản, chuyển tiền từ tài khoản chính sang tài khoản tiết kiệm và ngƣợc lại. Các bƣớc công việc cụ thể đƣợc mô tả nhƣ sau:

Khởi tạo hai luồng song song cùng truy cập vào một tài khoản.

Luồng 1:

- Truy nhập tài khoản luồng 1. - Chuyển tiền từ tài khoản chính sang tài khoản tiết kiệm. - Kiểm tra số dƣ tài khoản chính. - Kiểm tra số dƣ tài khoản tiết kiệm.

Luồng 2:

- Truy nhập tài khoản luồng 2. - Tất toán tiền từ tài khoản tiết kiệm sang tài khoản chính. - Chuyển tiền sang tài khoản tiết kiệm (lặp). - Kiểm tra số dƣ tài khoản chính.

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

Đầu ra:

 Đồ thị CFG - Hình 4.9: Ứng với phân đoạn Par trong biểu đồ tuần tự là nốt FN chia hai nhánh hoạt động song song. Vòng lặp phân đoạn Loop trong biểu đồ tuần tự tƣơng ứng với nốt DN trong đồ thị CFG. Thoát ra khỏi phân đoạn Par cũng là kết thúc chu trình hoạt động tƣơng ứng với nốt JN đồ thị Hình 4.9.

 Ca kiểm thử tƣơng ứng theo 3 độ đo kiểm thử (Hình 4.10, 4.11 và 4.12). Trong đó Hình 4.10 hiển thị tất cả các ca kiểm thử ở độ đo kiểm thử yếu. Tất cả các nốt quyết định, các nốt rẽ nhánh trong đồ thị dòng điều khiển đƣợc đi qua ít nhất 1 lần.

Các ca kiểm thử độ bao phủ yếu (2 ca kiểm thử):

TC1: Start-DC-M1-M2-M3-M4-JN

TC2: Start-DC-M5-M6-DC-M7-DC-M8-JN

Vì thuật toán duyệt lần lƣợt từng đƣờng đi của đồ thị CFG, điều kiện độ bao phủ yếu đƣợc thỏa mãn sau 2 lần duyệt.

Các ca kiểm thử độ bao phủ trung bình (3 ca kiểm thử):

TC1: Start-DC-M1-M2-M3-M4-JN

TC2: Start-DC-M5-M6-DC-M7-DC-M8-JN

TC3: Start-DC-M5-M6-DC-M8-JN

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

 Ca kiểm thử độ bao phủ yếu – Hình 4.10:

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

 Ca kiểm thử độ bao phủ trung bình – Hình 4.11:

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

 Ca kiểm thử độ bao phủ mạnh – Hình 4.12:

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

Ngoài các ca kiểm thử độ bao phủ yếu và ca kiểm thử độ bao phủ trung bình, ca

kiểm thử độ bao phủ mạnh dành riêng cho các trƣờng hợp đồ thị có chứa các nốt có điểm chia sẻ dữ liệu. Cụ thể các ca kiểm thử độ bao phủ mạnh trong ví dụ 2 nhƣ sau:

TC1: M2 và M5 có chia sẻ dữ liệu.

Start-DC-M1-M2-M5-M3-M4-M6-DC-M7-DC-M8-JN

TC2: M3 và M5 có chia sẻ dữ liệu.

Start-DC-M1-M2-M3-M5-M4-M6-DC-M7-DC-M8-JN

TC3: M4 và M5 có chia sẻ dữ liệu.

Start-DC-M1-M2-M3-M4-M5-M6-DC-M7-DC-M8-JN

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.

Hình 4.13 biểu diễn đƣờng đi tƣơng ứng của một ca kiểm thử mạnh. Ca kiểm thử này không tuân theo qui luật đƣờng đi trong đồ thị CFG mà có sự chuyển đổi giữa các nốt có sự trao đổi dữ liệu trong các nhánh khác nhau. Theo đó, đƣờng đi đƣợc miêu tả trong Hình 4.13 theo thứ tự các nốt nhƣ sau:

Start – FN – M1 – M2 – M3 – M5 – M4 – M6 – DN – M7 – DN – M8 – JN – End.

4.3 Ý nghĩa thực nghiệm

Thực thi thành công công cụ kiểm thử tự động từ biểu đồ thiết kế là bằng chứng chứng minh tính khả dụng và khả năng áp dụng thực tế cho các phƣơng pháp kiểm thử dựa trên mô hình. Hiện nay kiểm thử dựa trên mô hình vẫn là xu hƣớng chính trong nghiên cứu cải tiến thúc đẩy qui trình kiểm thử phần mềm nói chung và kiểm thử tự động nói riêng. Bằng phƣơng pháp này, các công ty phần mềm có thể tiến hành kiểm thử ngay từ khâu thiết kế, sinh ca kiểm thử tự động với độ bao phủ theo tùy ý theo các mức độ mong muốn. Hiệu quả kiểm thử cũng đã đƣợc chứng minh vƣợt trội hơn so với các phƣơng pháp khác nhƣ kiểm thử ngẫu nhiên. Giúp tiết kiệm thời gian phát triển dự án phần mềm, tiết kiệm nhân lực.

So với các nghiên cứu khác, chƣơng trình thực nghiệm sử dụng đầu vào là các biểu đồ thiết kế thực tế mà các công ty phần mềm luôn phải thực hiện. Từ đó có thể tiến hành ngay các bƣớc kiểm thử với ba độ đo kiểm thử khác nhau tùy thuộc thời gian phát triển dự án. Ở độ đo kiểm thử độ bao phủ mạnh, công cụ mang lại hiệu quả cao khi xét tới các trƣờng hợp luồn song song có chứa điểm chia sẻ dữ liệu. Việc biểu diễn trực quan đồ thị dòng điều khiển cùng với các đƣờng kiểm thử giúp kiểm thử viên có thể quan sát trực tiếp các kịch bản mà phần mềm sẽ thực thi. Dữ liệu kiểm thử đƣợc sinh tự động. Dù còn một số hạn chế về kiểu dữ liệu đầu vào nhƣng bài nghiên cứu này sẽ là tiền đề để mở rộng, áp dụng các phƣơng pháp giải khác cho các kiểu dữ liệu mảng, chuẫn kí tự, v.v. và hoàn thành một chu trình kiểm thử kín ở khâu thiết kế.

Chƣơng 5: KẾT LUẬN

Kiểm thử là một công đoạn quan trọng trong quá trình phát triển phần mềm và phƣơng pháp kiểm thử là yếu tố quyết định đến hiệu quả của việc kiểm thử. Rút ngắn thời gian hoàn thành dự án, tăng hiệu quả và khả năng phát hiện lỗi luôn là những yêu cầu hàng đầu trong kiểm thử. Hƣớng tới mô hình phát triển phần mềm trong môi trƣờng công nghiệp với đầy đủ các khâu trong thiết kế và phát triển phần mềm một cách bài bản, bài nghiên cứu này đã đƣa ra một phƣơng án hoàn thiện hơn về kiểm thử dựa trên mô hình.

Sử dụng đầu vào sẵn có là biểu đồ tuần tự lƣu trữ dƣới dạng tệp xmi. Bài nghiên cứu đã đề xuất một phƣơng pháp sinh ca kiểm thử tự động với hiệu quả kiểm thử tƣơng đƣơng với kiểm thử hộp trắng dựa trên biểu đồ CFG. Tuy nhiên, lỗi đƣợc phát hiện ở giai đoạn này là sớm hơn nên mang lại hiệu quả cao hơn xét cả về kinh tế và thời gian phát triển dự án. Một lần nữa, nội dung của bài nghiên cứu đã trình bày những nét cơ bản về kiểm thử dựa trên mô hình. Vận dụng và đề xuất phƣơng pháp sinh ca kiểm thử tự động từ biểu đồ tuần tự và ràng buộc OCL. Đầu ra của bài toán là đồ thị trực quan CFG và các ca kiểm thử đƣợc chia làm 3 mức độ. Trong đó mức độ kiểm thử tối ƣu nhất cho phép phát hiện lỗi với những thiết kế có nhiều luồng chạy song song và có điểm chia sẻ dữ liệu. Đây là một ƣu điểm lớn vì lỗi thƣờng phát sinh ở những trƣờng hợp sử lí song song này (khi có nhiều tác tử cùng tƣơng tác tới một đối tƣợng hay một biến trong chƣơng trình). Công cụ thực nghiệm cũng đã cho thấy tính khả thi và khả năng áp dụng thực tế của phƣơng pháp.

Hƣớng phát triển

Phần trình bày của phƣơng pháp mới chỉ dừng lại ở việc sinh ca kiểm thử tự động. Tối ƣu hiệu quả của các ca kiểm thử. Việc tính toán kết quả mong muốn của ca kiểm thử vẫn cần có sự can thiệp của chuyên gia. Để tự động hóa toàn bộ qui trình cần có sự kết hợp của nhiều giai đoạn kiểm thử để so sánh và đối chiếu kết quả trong và sau mỗi ca kiểm thử. Ví dụ, với các ca kiểm thử dựa trên mã nguồn, mã nguồn đƣợc xây dựng từ các thiết kế đã đƣợc kiểm duyệt. Việc tính toán ra kết quả mong đợi cũng cần có sự can thiệp của các chuyên gia để đảm bảo tính khách quan trong tính toán. Dựa trên yếu tố này, chúng ta có thể xây dựng một qui trình kiểm thử mới là kết hợp giữa kiểm thử trên mô hình và kiểm thử trên mã nguồn để so sánh và đối chiếu kết quả với cùng dữ liệu đầu vào. Cả hai quá trình đều đƣợc thực hiện tự động và tách biệt nên đảm bảo tính khách quan mà kết quả mang lại. Chỉ những ca kiểm thử cho kết quả khác nhau mới cần kiểm tra lại và tìm ra kết quả đúng đắn.

Hƣớng nghiên cứu tiếp theo của tôi là kết hợp phƣơng pháp hiện tại với các giai đoạn kiểm thử khác để tối ƣu hóa hiệu quả kiểm thử. Đề xuất kết hợp với giai đoạn kiểm

thử sau khi đã có mã nguồn để so sánh kết quả kiểm thử. Tự động hóa qui trình sinh kết quả mong muốn từ sự kết hợp giữa hai phƣơng pháp. Phát triển hoặc thay thế công cụ giải hệ để giải đƣợc với tất cả các loại dữ liệu đầu vào nhƣ kí tự, chuỗi kí tự.

TÀI LIỆU THAM KHẢO

Tiếng Việt

[1]. Phạm Ngọc Hùng, Trƣơng Anh Hoàng, Đặng Văn Hƣng (2014), “Giáo trình kiểm

thử phần mềm”, Nhà xuất bản ĐH Quốc Gia HN.

[2]. Nguyễn Đức Anh (2015), “Phƣơng pháp và công cụ hỗ trợ kiểm thử tự động các đơn vị chƣơng trình C”, Khóa luận tốt nghiệp Đại học, Trƣờng Đại học Công nghệ, Đại học Quốc Gia Hà Nội.

Tiếng Anh

[3]. Vũ Thị Đào, Phạm Ngọc Hùng, Vũ Việt Hà, Automated Test Data Generation

From Sequence_OCL

[4]. Ashalatha Nayak, Debasis Samanta (2010), “Automatic Test Data Synthesis using UML Sequence Diagrams”, in Journal of Object Technology , vol. 09, no. 2, March 2010, pp. 75-104.

[5]. http://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html [6]. A.V.K. Shanthi and G. Mohan Kumar (2012), “Automated Test Cases Generation from UML Sequence Diagram”, IPCSIT vol. 41 © (2012) IACSIT Press, Singapore

[7]. Mark Utting and runo Legeard, “Practical Model-Based Testing: A Tools

Approach” Morgan Kaufmann, 2006, pp 6-10.

[8]. El-Far I. K. and Whittaker J.A (2002), “Model-based software testing”,

Encyclopedia of Software Engineering, pp. 825-837.

[9]. Emanuela G. Cartaxo, Francisco G. O. Neto and Patr´ıcia D. L. Machado, "Test Case Generation by means of UML Sequence Diagrams and Labeled Transition Systems", IEEE 2007.

[10]. Li Bao-Lin, Li Zhi-shu, Li Qing, Chen Yan Hong , “Test Case automate Generation from UML Sequence diagram and OCL Expression”, International Conference on Computational Intelligence and Security 2007, pp 1048-1052.