DSpace at VNU: 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

ĐẠ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


MỤC LỤC
LỜI CẢM ƠN..................................................................... Error! Bookmark not defined.
TÓM TẮT .......................................................................... Error! Bookmark not defined.
ABSTRACT ....................................................................... Error! Bookmark not defined.
LỜI CAM ĐOAN ............................................................... Error! Bookmark not defined.
MỤC LỤC ............................................................................................................................ ii
DANH SÁCH BẢNG BIỂU ............................................................................................... iv
DANH SÁCH HÌNH VẼ...................................................................................................... v
BẢNG THUẬT NGỮ VIẾT TẮT ..................................................................................... vii
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 ........................................... Error! Bookmark not defined.

2.4

Các độ đo kiểm thử ................................................. Error! Bookmark not defined.

Chƣơng 3: PHƢƠNG PHÁP SINH ĐỒ THỊ DÕNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN
TỰ....................................................................................... Error! Bookmark not defined.
3.1

Điều kiện ràng buộc trong thiết kế ......................... Error! Bookmark not defined.

3.2
Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển Error! Bookmark
not defined.
3.2.1.

Thuật toán sinh đồ thị dòng điều khiển .............. Error! Bookmark not defined.

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


3.3

Kỹ thuật sinh kịch bản kiểm thử............................. Error! Bookmark not defined.

3.3.1.
Kịch bản kiểm thử cho các toán từ thông thƣờng .............Error! Bookmark not
defined.
3.3.2.
Kịch bản kiểm thử cho các phân đoạn song song (Par, Seq) .. Error! Bookmark
not defined.
3.4

Xây dựng hệ ràng buộc ........................................... Error! Bookmark not defined.

3.5

Giải hệ sử dụng SMT-Solver .................................. Error! Bookmark not defined.

3.6

Các nghiên cứu liên quan ....................................... Error! Bookmark not defined.

Chƣơng 4: CÔNG CỤ VÀ THỰC NGHIỆM .................... Error! Bookmark not defined.
4.1

Giới thiệu công cụ và môi trƣờng thực nghiệm ..... Error! Bookmark not defined.

4.2

Thực nghiệm ........................................................... Error! Bookmark not defined.

4.3

Ý nghĩa thực nghiệm .............................................. Error! Bookmark not defined.

Chƣơng 5:

KẾT LUẬN ................................................ Error! Bookmark not defined.

TÀI LIỆU THAM KHẢO .................................................................................................. 14


DANH SÁCH BẢNG BIỂU
Bảng 2.1 Ca kiểm thử độ bao phủ yếu ............................... Error! Bookmark not defined.
Bảng 2.2 Ca kiểm thử độ bao phủ trung bình..................... Error! Bookmark not defined.
Bảng 2.3 Ca kiểm thử độ bao phủ mạnh ............................ Error! Bookmark not defined.
Bảng 3.1 Các khóa cơ bản và ý nghĩa trong tệp xmi .......... Error! Bookmark not defined.
Bảng 3.2 Dữ liệu thu thập tƣơng ứng theo các nốt đƣợc nối với nhau ... Error! Bookmark
not defined.
Bảng 4.1 Môi trƣờng thử nghiệm công cụ sinh ca kiểm thử từ thiết kế.. Error! Bookmark
not defined.


DANH SÁCH HÌNH VẼ
Hình 2.1 Qui trình kiểm thử dựa trên mô hình. .................................................................... 6
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. ...................................................................................... 10
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. ................................................................................................. 12
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. .................................................. Error! Bookmark not defined.
Hình 2.14 Phân đoạn Assert. .............................................. Error! Bookmark not defined.
Hình 2.15 Phân đoạn Critical. ............................................ Error! Bookmark not defined.
Hình 2.16 Đồ thị dòng điều khiển tƣơng ứng của phân đoạn Par. ....Error! Bookmark not
defined.
Hình 3.1 Thiết kế tên thông điệp. ....................................... Error! Bookmark not defined.
Hình 3.2 Thiết kế ràng buộc. .............................................. Error! Bookmark not defined.
Hình 3.3 Khai báo biến trong ràng buộc tƣơng ứng cho các lớp. .....Error! Bookmark not
defined.
Hình 3.4 Xóa triệt để các đối tƣợng không dùng nữa. ....... Error! Bookmark not defined.
Hình 3.5 Đồ thị CFG tƣơng ứng cho phân đoạn Alt. ......... Error! Bookmark not defined.
Hình 3.6 Đồ thị CFG tƣơng ứng cho phân đoạn Opt. ........ Error! Bookmark not defined.
Hình 3.7 Đồ thị CFG tƣơng ứng cho phân đoạn Loop. ...... Error! Bookmark not defined.
Hình 3.8 Đồ thị CFG tƣơng ứng cho phân đoạn Break. ..... Error! Bookmark not defined.
Hình 3.9 Đồ thị CFG tƣơng ứng cho phân đoạn Par. ......... Error! Bookmark not defined.


Hình 3.10 Đồ thị CFG tƣơng ứng cho phân đoạn Seq. ...... Error! Bookmark not defined.
Hình 3.11 Đồ thị CFG tƣơng ứng cho phân đoạn Ignore. .. Error! Bookmark not defined.
Hình 3.12 Đồ thị CFG tƣơng ứng cho phân đoạn Consider. .............Error! Bookmark not
defined.
Hình 3.13 Đồ thị CFG tƣơng ứng cho phân đoạn Neg....... Error! Bookmark not defined.
Hình 3.14 Đồ thị CFG tƣơng ứng cho phân đoạn Assert. .. Error! Bookmark not defined.
Hình 3.15 Đồ thị CFG tƣơng ứng cho phân đoạn Strict..... Error! Bookmark not defined.
Hình 3.16 Ví dụ cây đồ thị cần duyệt. ................................ Error! Bookmark not defined.
Hình 3.17 Đồ thị dòng điều khiển. ..................................... Error! Bookmark not defined.

Hình 3.18 Ví dụ về ràng buộc OCL đƣợc khai báo trong thiết kế. ...Error! Bookmark not
defined.
Hình 3.19 Mô tả công cụ SMT Solver ............................... Error! Bookmark not defined.
Hình 4.1 Cấu trúc công cụ thực nghiệm. ............................ Error! Bookmark not defined.
Hình 4.2 Đầu vào công cụ của ví dụ 1. .............................. Error! Bookmark not defined.
Hình 4.3 Đầu ra - đồ thị CFG của ví dụ 1. ......................... Error! Bookmark not defined.
Hình 4.4 Đồ thị CFG và ca kiểm thử độ bao phủ yếu cho ví dụ 1. ...Error! Bookmark not
defined.
Hình 4.5 Ca kiểm thử độ bao phủ yếu cho ví dụ 1. ............ Error! Bookmark not defined.
Hình 4.6 Ca kiểm thử độ bao phủ trung bình cho ví dụ 1. . Error! Bookmark not defined.
Hình 4.7 Dữ liệu kiểm thử sau khi xuất ra tệp MS Excel .. Error! Bookmark not defined.
Hình 4.8 Đầu vào của ví dụ 2. ............................................ Error! Bookmark not defined.
Hình 4.9 Đầu ra đồ thị CFG cho ví dụ 2. ........................... Error! Bookmark not defined.
Hình 4.10 Ca kiểm thử độ bao phủ yếu cho ví dụ 2. .......... Error! Bookmark not defined.
Hình 4.11 Ca kiểm thử độ bao phủ trung bình cho ví dụ 2. ..............Error! Bookmark not
defined.
Hình 4.12 Ca kiểm thử độ bao phủ mạnh cho ví dụ 2. ....... Error! Bookmark not defined.
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. Error!
Bookmark not defined.



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

STT

Từ viết tắt

Tên đầy đủ

Ý nghĩa

1

BN

Block Node

Nốt đơn

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


1
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àytô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 3trì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ốnphƣơ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ự độngcá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.

Thiết kế

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

Mô
hình

Phản hồi

Phản hồi
Tạo tự động
Các chuỗi kiểm
thử

Kiểm thử dự
đoán

Kết luận: Pass /
Fail

Theo dõi

Điều khiển

Thực thi

Phản hồi

Hình 2.1Qui 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ệcphả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 haiphầ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).

Alt
[balance > 0]

Accept()

[else]
Reject()

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

Opt
[No error]
post_coment()

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.


Loop

notify()

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

Loop(10)

notify()

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

Loop(5,10)
[size < 0]
notify()

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ạnLoop với vòng lặp vô hạn. Hình 2.5 miêu tả phân
đoạnLoop với vòng lặp với cận trên bằng cận dƣới và bằng 10, không có điều kiện cần
kiể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 Bing trƣớc khi tìm bằng Yahoo.

Loop(10)
add()

Break

[y > 0]
add()


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

Par
1a: searchGoogle()

2: readResult()
1b: searchBing()
3: readResult()

1c: searchYahoo()
4: readResult()

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

Seq
Search_google()

search_bing()

Search_yahoo()

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

Phân đoạn tƣơng tác tuần tự ngặt (StrictSequencing) 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 Bing, 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.

Strict
Search_google()

search_bing()

Search_yahoo()

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

Phân đoạn tƣơng tác từ chối (Ignore) chỉ ra rằng có một số kiểu thông điệp
không đƣợc hiển thị trong phân đoạn kết hợp này. Các kiểu thông điệp này có thể bị coi
là vô nghĩa và bị mặc nhiên bỏ qua. Hình 2.11 là ví dụ minh họa thiết kế sử dụng phân
đoạn Ignore với ràng buộc bỏ qua các thông điệp get() và set()nếu có. Các thông điệp
khác vẫn đƣợc thực thi bình thƣờng.

Ignore{get,set}
add()

remove()

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

Phân đoạn tƣơng tác lƣu ý (Consider) chỉ ra những thông điệp nên đƣợc lƣu ý
trong phân đoạn kết hợp này. Điều này tƣơng đƣơng với việc định nghĩa mọi thông điệp
khác là bị bỏ qua. Ví dụ minh họa trong Hình2.12 sử dụng phân đoạn Consider để lƣu ý
đến hai thông điệp add() và remove() nếu sảy ra, các thông điệp khác bị coi là vô nghĩa
và bị bỏ qua.

Consider {add, remove}
add()

remove()

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

Phân đoạn tƣơng tác phủ định (Negative) chỉ ra rằng phân đoạn kết hợp biểu
diễn các vết (traces) đƣợc định nghĩa là không hợp lệ. Hình 2.13 biểu diễn qui trình hoạt
động của lò vi sóng trong đó có sử dụng phân đoạn Neg trong thiết kế. Trong phân đoạn
Neg có thông điệp open() đi từ một trục thời gian Cheftừ 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.

TÀI LIỆU THAM KHẢO
Tiếng Việt
[1]. PhạmNgọcHùng, Trƣơng Anh Hoàng, Đặng Văn Hƣng (2014), “Giáotrìnhkiể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
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]. />[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 Bruno 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.
[3].