Phương pháp sinh bộ kiểm thử từ biểu đồ tuần tự UML 2 0 và ứng dụng cho kiểm thử phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ MÙI

PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỪ BIỂU ĐỒ TUẦN
TỰ UML 2.0 VÀ ỨNG DỤNG CHO KIỂM THỬ PHẦN MỀM

LUẬN VĂN THẠC SĨ
Ngành: Hệ thống thông tin

HÀ NỘI – 2015


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ MÙI

PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỪ BIỂU ĐỒ TUẦN TỰ
UML 2.0 VÀ ỨNG DỤNG CHO KIỂM THỬ PHẦN MỀM

Ngành: Hệ thống thông tin
Chuyên ngành: Hệ thống thông tin
Mã số: 60 48 01 04

LUẬN VĂN THẠC SĨ
Ngành: Hệ thống thông tin

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. Phạm Ngọc Hùng

HÀ NỘI – 2015


VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY

TRAN THI MUI

A METHOD AND TOOL SUPPORTING FOR AUTOMATED
TESTING OF UML 2.0 SEQUENCE DIAGRAMS

THE MS. THESIS
Major: Information Systems

Supervisor: Dr. Pham Ngoc Hung

HANOI - 2015


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.

Mặc dù đã rất cố gắng nhƣng luận văn sẽ không tránh khỏi những thiếu sót.
Rất mong nhận đƣợc ý kiến đóng góp quý báu của Thầy, Cô giáo và các bạn để luận
văn đƣợc hoàn thiện hơn.
Xin trân trọng cảm ơn!

Hà Nội, ngày 22 tháng 11 năm 2015
Học viên:

Trần Thị Mùi

i


TÓM TẮT
Luận văn này tập trung nghiên cứu phƣơng pháp sinh bộ kiểm thử từ biểu đồ
tuần tự UML 2.0 dựa trên lý thuyết kiểm thử mô hình nhằm tự động hóa quá trình
kiểm thử, nâng cao hiệu quả, tiết kiệm chi phí và thời gian. Phƣơng pháp này đƣợc
thực hiện thông qua các bƣớc chính sau. Đầu tiên, để có đƣợc mô hình làm đầu vào
cho kiểm thử, phƣơng pháp thực hiện chuyển đổi biểu đồ tuần tự về đồ thị dòng điều
khiển bằng cách tiến hành bóc, tách từng khối (fragment) trong biểu đồ tuần tự. Các
khối này có thể tuần tự hoặc lồng nhau, dựa vào quan hệ của chúng, tiến hành xây
dựng đồ thị cho mỗi khối, sau đó lồng chúng lại nhằm sinh ra đồ thị dòng điều khiển
tƣơng ứng với biểu đồ tuần tự. Kế tiếp, đồ thị dòng điều khiển đƣợc phân tích để
xây dựng tập đƣờng kiểm thử. Vận dụng kỹ thuật thực thi tƣợng trƣng (Symbolic
Execution - SE) nhằm xây dựng hệ ràng buộc tƣơng ứng cho tập đƣờng kiểm thử.
Cuối cùng, sử dụng công cụ SMT solver để giải hệ các ràng buộc nhằm tìm kiếm
nghiệm và từ đó sinh ca kiểm thử.
Một công cụ hỗ trợ phƣơng pháp này đã đƣợ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 tiềm năng ứng dụng của công cụ này trong việc

kiểm thử tự động ở các công ty.
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, ca kiểm thử, độ bao phủ.

ii


ABSTRACT
This thesis researches 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 builds the corresponding graph for
each of the fragments and merges them together in order to generate 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, test case.

iii


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 TS. 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 22 tháng 11 năm 2015
Học viên:

Trần Thị Mùi

iv


MỤC LỤC
LỜI CẢM ƠN.......................................................................................................................... i
TÓM TẮT ............................................................................................................................... ii
ABSTRACT ........................................................................................................................... iii
LỜI CAM ĐOAN .................................................................................................................. iv
DANH SÁCH BẢNG BIỂU ................................................................................................ vii
DANH SÁCH HÌNH VẼ .................................................................................................... viii
BẢNG THUẬT NGỮ ............................................................................................................ x
Chƣơng 1. GIỚI THIỆU ....................................................................................................... 1
Chƣơng 2. TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ HÌNH ...................................... 5

2.1.

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

2.2.

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

2.3.

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

2.4.

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

Chƣơng 3. PHƢƠNG PHÁP SINH ĐỒ THỊ DÕNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ
TUẦN TỰ 10

3.1.

Biểu đồ tuần tự ........................................................................................... 10

3.2.

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

3.3.

Đƣờng kiểm thử .......................................................................................... 19

3.4.

Chuyển đổi biểu đồ tuần tự sang đƣờng kiểm thử ..................................... 20

3.5.

Định dạng chuẩn khi viết tệp xmi từ biểu đồ tuần tự ................................. 21

3.6.

Thuật toán sinh tự động các đƣờng kiểm thử ............................................. 22

3.6.1. Thuật toán phân tích biểu đồ tuần tự ........................................................................... 23
3.6.2. Thuật toán chuyển cấu trúc dữ liệu biểu đồ tuần tự sang đƣờng kiểm thử .................. 25
3.6.3. Thuật toán xác định đƣờng kiểm thử cho khối alt ....................................................... 25
3.6.4. Thuật toán xác định đƣờng kiểm thử cho khối opt và break ....................................... 26
3.6.5. Thuật toán xác định đƣờng kiểm thử cho khối loop .................................................... 27

v


3.6.6. Thuật toán xác định đƣờng kiểm thử cho khối par và seq ........................................... 29
3.6.7.Thuật toán xác định đƣờng kiểm thử cho khối weak .................................................... 30
3.6.8. Thuật toán xác định đƣờng kiểm thử cho khối strict ................................................... 31
3.6.9. Thuật toán xác định đƣờng kiểm thử cho khối ignore ................................................. 31
Chƣơng 4. PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỪ ĐỒ THỊ DÒNG ĐIỀU
KHIỂN ................................................................................................................................... 33

4.1.

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

4.2.

Tìm nghiệm thỏa mãn hệ ràng buộc ........................................................... 35

4.2.1. Giải hệ sử dụng kỹ thuật sinh ngẫu nhiên........................................................ 35
4.2.2. Giải hệ sử dụng SMT-Solver ........................................................................... 35
4.2.3. Nhận xét ƣu điểm, nhƣợc điểm của hai hƣớng sinh ca kiểm thử .................... 43
Chƣơng 5. THỰC NGHIỆM............................................................................................... 44

5.1.

Giới thiệu công cụ ...................................................................................... 44

5.2.

Thực nghiệm ............................................................................................... 45

5.3.

Ý nghĩa của thực nghiệm ............................................................................ 54

Chƣơng 6. KẾT LUẬN ........................................................................................................ 55
TÀI LIỆU THAM KHẢO ................................................................................................... 57

vi


DANH SÁCH BẢNG BIỂU

Bảng 4.1. Độ ƣu tiên các toán tử ......................................................................................... 39
Bảng 5.1. Môi trƣờng thử nghiệm công cụ sinh ca kiểm thử từ thiết kế. ............................ 45

vii


DANH SÁCH HÌNH VẼ

Hình 2.1. Quy trình của kiểm thử dựa trên mô hình [11] ........................................................ 6
Hình 3.1. Toán tử tƣơng tác alt .............................................................................................. 11
Hình 3.2. Toán tử tƣơng tác opt ............................................................................................. 12
Hình 3.3. Toán tử tƣơng tác loop vô hạn ............................................................................... 12
Hình 3.4. Toán tử tƣơng tác loop với cận trên = cận dƣới = 10 ............................................ 12
Hình 3.5. Toán tử tƣơng tác loop với cận trên = 5, cận dƣới = 10 ........................................ 12
Hình 3.6. Toán toán tử tƣơng tác break ................................................................................. 13
Hình 3.7. Toán tử tƣơng tác par ............................................................................................. 14
Hình 3.8. Một số thứ tự thực hiện của toán tử tƣơng tác par ................................................. 14
Hình 3.9. Toán tử tƣơng tác seq............................................................................................. 15
Hình 3.10. Toán tử tƣơng tác strict ........................................................................................ 15
Hình 3.11. Toán tử tƣơng tác ignore ...................................................................................... 16
Hình 3.12. Toán tử tƣơng tác consider .................................................................................. 16
Hình 3.13. Toán tử tƣơng tác neg .......................................................................................... 17
Hình 3.14. Toán tử tƣơng tác assert ....................................................................................... 17
Hình 3.15. Toán tử tƣơng tác critical ..................................................................................... 18
Hình 3.16. Đồ thị dòng điều khiển tƣơng ứng với biểu đồ tuần tự ........................................ 19
Hình 3.17. Chuyển biểu đồ tuần tự thành đƣờng kiểm thử.................................................... 20
Hình 4.1. Ví dụ một hệ ràng buộc.......................................................................................... 33
Hình 4.2. Quá trình rút gọn câu lệnh. .................................................................................... 35
Hình 4.3. Mô tả đầu vào, đầu ra SMT-Solver........................................................................ 37
Hình 4.4. Ví dụ hệ ràng buộc tuân theo chuẩn SMT-Lib. ..................................................... 38

Hình 4.5. Quá trình chuyển một biểu thức trung tố về chuẩn SMT-Lib................................ 39
Hình 5.1. Kiến trúc công cụ ................................................................................................... 45
Hình 5.2. Hình vẽ biểu đồ tuần tự tƣơng ứng với ví dụ 1 ...................................................... 46

viii


Hình 5.3. Kết quả đầu ra công cụ của ví dụ 1 ........................................................................ 50
Hình 5.4. Hình vẽ biểu đồ tuần tự tƣơng ứng với ví dụ 2 ...................................................... 53
Hình 5.5. Kết quả đầu ra công cụ của ví dụ 2 ........................................................................ 53

ix


BẢNG THUẬT NGỮ
STT Từ viết tắt

Tên đầy đủ

Ý nghĩa

1

CFG

Control Flow Graph

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

2

SMT-Solver

Satisfiability Modulo
Theories Solver

Lý thuyết modul thỏa mãn

3

SAT

Boolean Satisfiability

Vấn đề thỏa mãn biểu thức

Problem

logic

4

T-Solver

Theory-specific Solvers

Lý thuyết giải quyết đặc biệt

5

SE

Symbolic Execution

Kỹ thuật thực thi tƣợng trƣng

x


Chƣơng 1.

GIỚI THIỆU

Kiểm thử là giai đoạn quan trọng và không thể thiếu trong quá trình phát triển
phần mềm. Quá trình kiểm thử trải qua hai giai đoạn: sinh ca kiểm thử và thực thi
ca kiểm thử. Trong quá trình kiểm thử, việc sinh các ca kiểm thử đóng vai trò quyết
định đến chất lƣợng kiểm thử. Tuy nhiên, đây là bƣớc khó khăn và thách thức nhất,
đặc biệt đối với các hệ thống lớn không những phức tạp để kiểm thử mà còn đòi hỏi
một số lƣợng lớn các ca kiểm thử đƣợc tạo ra. Quá trình này tốn thời gian, công sức
và chi phí có thể chiếm 40% – 60% tổng chi phí trong toàn bộ quá trình phát triển
phần mềm [9]. Vì vậy, quá trình sinh các ca kiểm thử tự động 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 đảm bảo chất lƣợng mà vẫn giảm chi phí và thời
gian trong quá trình phát triển các sản phẩm phần mềm.
Trong đó, kiểm thử dựa trên mô hình là một trong những kỹ thuật kiểm thử
đang đƣợc sử dụng ngày càng rộng rãi trong việc kiểm thử các sản phẩm phần mềm.
Tuy nhiên, để áp dụng phƣơng pháp này, ta cần 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. 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à xây dựng nên các biểu đồ tuần tự UML là một công
việc dễ dàng và phổ biến. Do đó, việc kiểm thử tính đúng đắn cho thiết kế dựa trên
mô hình là một vấn đề mở và chƣa có lời giải thỏa đáng.
Hiện nay, có nhiều hƣớng nghiên cứu liên quan đến việc sinh mô hình cho
phần mềm đã đƣợc đề xuất bởi nhiều tác giả. Một hƣớng là tập trung vào nghiên
cứu các phƣơng pháp sinh mô hình cho phần mềm. Với cách tiếp cận này, ta có thể
kể đến các phƣơng pháp sinh mô hình đƣợc đề cập trong [19], [20], [21], và [22].
Trong [19], các tác giả đã đặt ngữ cảnh là xây dựng mô hình cho phần mềm đƣợc
cho dƣới dạng một hộp đen và ta có thể thử nghiệm thực thi các hành động trên nó
để có thể xây dựng đƣợc một tập các chuỗi hành động của phần mềm. Sau đó, tập
1


các chuỗi hành động của phần mềm thu đƣợc có thể đƣợc coi là một biểu thức chính
quy đặc tả hành vi của phần mềm, các tác giả sau đó đã sử dụng thuật toán
Thompson để sinh mô hình cho phần mềm đƣợc cho bởi biểu thức chính quy đó.
Phƣơng pháp này bị giới hạn bởi độ dài tối đa của chuỗi các hành động có thể thử
nghiệm trên phần mềm. Nghiên cứu trong [20] trình bày một thuật toán gọi là GKtail mà tự động sinh mô hình cho phần mềm dƣới dạng các EFSM (Extended Finite
State Machine) từ các chuỗi tƣơng tác của nó. EFSM mô hình hóa sự tƣơng tác giữa
các giá trị dữ liệu và phần mềm bằng cách ghi chú lên các cạnh của ôtômát hữu hạn
đó với các điều kiện trên các giá trị dữ liệu. Trong nghiên cứu này, các tác giả đã đề
cập một khía cạnh rất quan trọng của phần mềm. Đó là mô hình hóa các lời gọi hàm
trong quan hệ với các tham số của nó. Phƣơng pháp này dựa vào một phần mềm gọi
là phần mềm giám sát để có thể sinh ra đƣợc các chuỗi tƣơng tác mà đƣợc dùng nhƣ
là đầu vào của nó. Nghiên cứu [21] giới thiệu một tập tích hợp các chƣơng trình
phân tích, chuyển đổi thành phần gọi là Bandera mà tự động trích xuất mô hình cho
chƣơng trình phần mềm dựa trên mã nguồn. Trong nghiên cứu này, Bandera lấy mã
nguồn Java nhƣ là đầu vào để sinh mô hình dƣới dạng đầu vào cho một số công cụ
khác. Ngoài ra, Bandera cũng tham chiếu trở lại mã nguồn ban đầu với mô hình đã
đƣợc sinh ra. Phƣơng pháp này rõ ràng là phụ thuộc vào mã nguồn của phần mềm

cần phân tích. Do đó, đối với các phần mềm hƣớng thành phần không có mã nguồn
của một số thành phần mua từ bên phát triển thứ ba thì phƣơng pháp này rất khó
khả thi. Nghiên cứu [22] giới thiệu một công cụ gọi là Bandera Environment
Generator (BEG). Công cụ này tự động hóa việc sinh mô hình môi trƣờng để cung
cấp một dạng hạn chế của việc kiểm chứng mô hình các mô đun của chƣơng trình
Java. Công cụ này sinh mô hình cho đơn vị chƣơng trình Java dựa trên một số giả
định về môi trƣờng đƣợc cung cấp bởi ngƣời dùng. Mô hình đã đƣợc sinh ra có thể
đƣợc dùng trong việc phân tích ảnh hƣởng của môi trƣờng lên đơn vị trong phƣơng
pháp kiểm chứng mô hình. Đây là một vấn đề rất thách thức trong thực tế phát triển
phần mềm vì hệ thống phần mềm luôn phải chạy trên một sự kết hợp của rất nhiều
hệ thống khác nhƣ hệ điều hành, các hệ thống khác,v.v. Ngƣời dùng, thậm chí cả
2


ngƣời thiết kế phần mềm cũng khó có thể nhận biết đƣợc những thông tin đầy đủ về
môi trƣờng trong thời gian làm thiết kế hệ thống.
Một hƣớng tiếp cận khác là sinh mô hình trong khi thực hiện kiểm chứng mô
hình hay trong khi thực hiện kiểm thử dựa trên mô hình [23], [24], và [25]. Trong
[23], các tác giả đã sử dụng thuật toán học L* để học đặc tả của một thành phần
phần mềm thông qua một biểu thức chính quy để sinh ra mô hình cho thành phần
đó. Biểu thức chính quy đó là kết quả của khâu thiết kế, có thể đƣợc sinh ra từ từ
biểu đồ tuần tự theo phƣơng pháp đƣợc đề cập trong [23]. Tuy phƣơng pháp này
sinh đƣợc mô hình cho phần mềm, nhƣng sử dụng nhiều thời gian và bộ nhớ. Đặc
biệt là phƣơng pháp này bị giới hạn bởi độ dài tối đa của một chuỗi hành vi của
phần mềm. Do đó, phƣơng pháp này rất khó áp dụng đƣợc trong thực tế. Nghiên
cứu [24] đặt vấn đề cho việc kiểm thử hộp đen. Trong nghiên cứu này, nhiều chiến
lƣợc đƣợc trình bày để kiểm chứng phần mềm từ khi chúng ta chƣa có mô hình. Mô
hình đƣợc sinh ra trong các lần lặp kiểm chứng phần mềm. Nghiên cứu [25] trình
bày một phƣơng pháp sinh mô hình thành phần phần mềm trong quá trình thành
phần đó tiến hóa. Những mô hình này đƣợc sinh ra sử dụng các mô hình chƣa đúng

hiện có dựa vào các kỹ thuật kiểm thử hộp đen và học máy. Tuy nhiên, phƣơng
pháp này sinh mô hình cho toàn bộ phần mềm. Với những phần mềm lớn thì
phƣơng pháp này có thể dẫn đến sự bùng nổ trạng thái của mô hình. Với cách tiếp
cận này, những mô hình đƣợc sinh ra nhƣ là một phần của quá trình khác nhƣ kiểm
thử hộp đen, kiểm chứng mô hình. Luận văn này tập trung vào việc chỉ sinh mô
hình cho thành phần phần mềm. Bằng cách này, chúng ta tập trung vào việc có đƣợc
mô hình bằng một cách thực tế hơn nhƣ từ biểu đồ tuần tự [23]. Những mô hình này
sau đó có thể đƣợc dùng nhƣ là đầu vào cho các phƣơng pháp khác nhƣ kiểm chứng
mô hình, kiểm thử dựa trên mô hình.
Để giải quyết vấn đề trên, trong luận văn này, tôi nghiên cứu về phƣơng pháp
nhằm xây dựng một công cụ hỗ trợ phân tích biểu đồ dòng điểu khiển dựa trên biểu
đồ tuần tự UML 2.0 và ứng dụng để sinh bộ kiểm thử.

3


Phƣơng pháp nghiên cứu gồm hai quá trình chính là chuyển đồi biểu đồ tuần
tự về đồ thị dòng điều khiển và từ đồ thị dòng điều khiển sinh bộ kiểm thử. Biểu đồ
tuần tự đƣợc cung cấp dƣới dạng tệp xmi sẽ đƣợc phân tích để cho ra một đƣờng
kiểm thử tƣơng ứng đặc tả hoạt động. Đây chính là giá trị đầu vào. Qua quá trình
phân tích, dữ liệu từ tệp xmi đƣợc chuyển đổi thành cấu trúc dữ liệu biểu đồ tuần tự
tƣơng ứng. Ứng với mỗi khối trong biểu đồ tuần tự, tiến hành bóc, tách từng khối và
dựa vào quan hệ giữa các khối để lồng các khối nhằm sinh ra đồ thị dòng điều
khiển. Kế tiếp, một đƣờng kiểm thử tƣơng ứng đƣợc trả về đặc tả chính xác hoạt
động của đồ thị dòng điều khiển. Kỹ thuật đƣợc sử dụng để xây dựng hệ ràng buộc
tƣơng ứng cho tập đƣờng kiểm thử ở đây là thực thi tƣợng trƣng (symbolic
execution - SE). Cuối cùng, bằng cách kết hợp kỹ thuật sinh ngẫu nhiên và tận dụng
thế mạnh các công cụ giải các hệ ràng buộc (SMT-Solver), hệ ràng buộc đƣợc giải
để sinh ca kiểm thử. Bộ kiểm thử này sẽ đƣợc sử dụng để kiểm tra xem việc lập
trình có đúng với thiết kế hay không.

Phần còn lại của luận văn đƣợc cấu trúc nhƣ sau: Chƣơng 2 trình bày cơ sở lý
thuyết của kiểm thử mô hình, bao gồm các khái niệm cơ bản, quy trình thực hiện,
phƣơng pháp đặc tả mô hình bằng máy trạng thái UML, thuận lợi và khó khăn của
kiểm thử dựa trên mô hình và áp dụng cho kiểm thử phần mềm. Phƣơng pháp sinh
đồ thị dòng điều khiển từ biểu đồ tuần tự bao gồm tổng quan về đồ thị dòng điều
khiển, cách đặc tả biểu đồ tuần tự, phƣơng pháp sinh đồ thị dòng điều khiển
đƣợc trình bày trong chƣơng 3. Chƣơng 4 trình bày về phƣơng pháp sinh ca kiểm
thử từ đồ thị dòng điều khiển bao gồm bƣớc xây dựng hệ ràng buộc và bƣớc tìm
nghiệm thỏa mãn hệ ràng buộc dựa trên SMT - Solver. Chƣơng 5 trình bày kết quả
đã đạt đƣợc. Cuối cùng, chƣơng 6 tóm tắt lại nội dung nghiên cứu, đƣa ra những
hạn chế và hƣớng nghiên cứu phát triển trong tƣơng lai.

4


Chƣơng 2.

TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ HÌNH

Khi chạy một dự án phần mềm, yêu cầu từ phía khách hàng là yếu tố để hình
thành và phát triển dự án. Thực tế, các yêu cầu này thƣờng không ổn định mà sẽ
thay đổi tùy theo nhu cầu của khách hàng. Mỗi khi có sự thay đổi xảy ra, thƣờng sẽ
kéo theo những thứ khác ảnh hƣởng. Vì thế, hoạt động kiểm thử phải thực hiện để
đảm bảo chất lƣợng của sản phẩm. Có những trƣờng hợp, một sự thay đổi nhỏ cũng
có thể gây ảnh hƣởng lớn, kéo theo việc kiểm thử viên có thể không đáp ứng đƣợc
tiến độ của dự án đề ra.
Nhƣ vậy, việc phát triển một phƣơng pháp kiểm thử để hạn chế tác động của
sự thay đổi, đồng thời tiết kiệm đƣợc chi phí về thời gian và tiền bạc là thực sự cần
thiết. Phƣơng pháp kiểm thử dựa trên mô hình nhằm kiểm tra tính đúng đắn của lập
trình so với thiết kế, là giải pháp giúp giải quyết đƣợc vấn đề trên. 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. Khái niệm kiểm thử dựa trên mô hình
Trong quá trình kiểm thử tự động phần mềm, kiểm thử viên trƣớc tiên sẽ tạo ra
các kịch bản kiểm thử bằng cách ghi lại tính năng của phần mềm đó. Sau đó, kiểm
thử viên tiến hành kiểm thử theo kịch bản đã đƣợc tạo ra với những tham số khác
nhau. Quá trình kiểm thử đƣợc chạy tự động. Tuy nhiên, việc tạo kịch bản kiểm thử
lại đƣợc tiến hành thủ công. Hầu hết các công cụ kiểm thử ngày nay đều kiểm thử
tự động dựa trên các kịch bản có sẵn, do đó việc tạo kịch bản tốn nhiều công sức
của kiểm thử viên và mất rất nhiều thời gian. Để tránh việc sai sót trong quá trình
kiểm thử, việc tạo kịch bản phải đƣợc xây dựng chu đáo. Thêm vào đó, mỗi khi yêu
cầu từ phía ngƣời dùng thay đổi thì kịch bản cũng phải thay đổi theo. Vì vậy, việc
tạo tự động các kịch bản kiểm thử là thật sự cần thiết. Hƣớng tiếp cận ở đây là kiểm
thử dựa trên mô hình nhằm khắc phục đƣợc các vấn đề về chi phí, thời gian. Kiểm
thử dựa trên mô hình là một phƣơng pháp kiểm thử nơi mà các ca kiểm thử đƣợc
sinh ra từ mô hình đặc tả hành vi của hệ thống đang đƣợc kiểm thử. Mô hình này
5


đƣợ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. [1].
2.2. Quy trình chung của kiểm thử dựa trên mô hình
Quá trình kiểm thử tự động dựa trên mô hình đƣợc bắt đầu bằng việc xác định
yêu cầu của hệ thống từ đó xây dựng mô hình dựa vào các yêu cầu và chức năng
của hệ thống. 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ử [1]. Các ca kiểm thử đó đƣợc tiến
hành chạy và kết quả thu đƣợc sẽ đƣợc so sánh với kết quả mong đợi. Từ đó quyết
định hành động tiếp theo nhƣ sửa đổi mô hình hoặc dừng kiểm thử, v.v.

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

Thiết kế

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

Đưa ra

Kết luận: Pass hay Fail

Theo dõi
Điều khiển

Thực thi

Phản hồi

Hình 2.1. Quy trình của kiểm thử dựa trên mô hình [11]

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.
Kiểm thử tự động dựa trên mô hình gồm các giai đoạn sau:

6


-

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.3. Phƣơng pháp đặc tả mô hình bằng máy trạng thái UML
Theo [1], phƣơng pháp đặc tả mô hình bằng máy trạng thái thƣờng đƣợc áp
dụng trong công nghiệp. Nó có thể đƣợc sử dụng để đặc tả 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. Theo [10], biểu đồ cộng tác đặc tả bằng UML là một mô
hình quan trọng trong việc kiểm thử hệ thống bởi mô hình này đặc tả chính xác
hành vi (tƣơng tác giữa các đối tƣợng) của hệ thống cần kiểm thử. 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.4. Thuận lợi và khó khăn của kiểm thử tự động dựa trên mô hình
Trong quá trình phát triển phần mềm, các kiểm thử viên thƣờng thực hiện
công việc của mình bằng các phƣơng pháp truyền thống (thủ công) nên thời gian và
7

chi phí dành cho các hoạt động này thƣờng rất cao. Kiểm thử dựa trên mô hình hứa
hẹn sẽ là một giải pháp hiệu quả nhằm góp phần giải quyết vấn đề này [1].
Cụ thể, kiểm thử dựa trên mô hình có các ƣu điểm sau:
-

Giảm chi phí và thời gian: Do quá trình kiểm thử hầu hết đƣợc thực hiện tự

động nên tính hiệu quả của phƣơng pháp này rất cao trong khi thời gian đƣợc giảm
một cách tối thiểu.
-

Độ bao phủ tốt hơn: 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.
-

Đầy đủ tài liệu: Mô hình hệ thống, các đƣờng đi, các ca kiểm thử là các tài liệu

quan trọng trong quá trình phát triển phần mềm nói chung và quá trình kiểm thử
phần mềm nói riêng. Các tài liệu này cũng giúp cho các kiểm thử viên hiểu hơn về
các ca kiểm thử và các kịch bản kiểm thử.
-

Khả năng sử dụng lại cao: Mỗi khi phần mềm bị tiến hóa, 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 quan việc xây dựng và phân tích mô hình hệ
thống.
-

Sớm phát hiện lỗi và sự không rõ ràng trong đặc điểm kỹ thuật và thiết kế vì

vậy sẽ tăng thời gian giải quyết vấn đề trong kiểm thử.
-

Tự động tạo và kiểm tra nhằm tránh các ca kiểm thử trùng nhau hoặc không

hữu hiệu.
-

Kiểm thử dựa trên mô hình có khả năng đánh giá chất lƣợng phần mềm.
Tuy nhiên, 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 sau:
-

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.
8

-

Yêu cầu cao về kiểm thử viên: Do phải xây dựng mô hình của hệ thống vì vậy

ngƣời kiểm thử phần mềm phải yêu cầu là những ngƣời có khả năng phân tích và
thiết kế hệ thống. Hơn nữa, ngƣời kiểm thử cần có kiến thức tốt về các phƣơng
pháp hình thức và đặc tả hình thức, có hiểu biết chi tiết và chính xác về hệ thống.
-

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.
-

Khó khăn trọng việc sử dụng các ca kiểm thử đƣợc tạo ra từ mô hình: Lập

trình viên tiến hành cài đặt hệ thống một cách độc lập nên khi đã cài đặtxong
thƣờng khó thực thi các ca kiểm thử đƣợc tạo ra từ mô hình vì rấtnhiều lý do khác
nhau. Thông thƣờng, họ phái tiền hành nghiên cứu mô hình và đặc tả lại các ca
kiểm thử mới sử dụng đƣợc chúng. Hơn nữa, mô hình hệ thống thƣờng trừu tƣợng
và tổng quát hơn cài đặt của nó. Vấn đề này là một trong những lý do chính của
hạn chế này.

9


Chƣơng 3.

PHƢƠNG PHÁP SINH ĐỒ THỊ DÕNG ĐIỀU KHIỂN TỪ

BIỂU ĐỒ TUẦN TỰ

Chƣơng này đề xuất phƣơng pháp kiểm thử tính đúng đắn thiết kế cho các
phần mềm dựa trên mô hình. Để có đƣợc mô hình làm đầu vào cho phƣơng pháp
kiểm thử, phƣơng phápchuyển đổi biểu đồ tuần tự về đồ thị dòng điều khiển, đồ thị
dòng điều khiển đƣợc sinh ra trở thành đầu vào để sinh ca kiểm thử.Nếu bản thiết kế
là đúng đắn phƣơng pháp đƣa ra một mô hình giả định đặc tả môi trƣờng của hệ
thống. Ngƣợc lại, phƣơng pháp trả về một phản ví dụ chứng minh thiết kế không
thỏa mãn thuộc tính của hệ thống. Điều đó giúp quá trình kiểm thử đơn giản và tiết
kiệm chi phí hơn.
3.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 đồ ít quan tâm vào các thông điệp, mục đích chính là trình tự các
thông điệp xảy ra, biểu đồ tuần tự sẽ truyền đạt nội dung những thông điệp đƣợc gửi
giữa các đối tƣợng trong một hệ thống cũng nhƣ thự xảy ra. 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 2 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

(combined fragment). Mỗi phân đoạn có một từ khóa và có một hoặc nhiều các
10


đ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.
Toán tử 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 3.1 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()).
alt
[balance >0]

accept()

[else]

reject()

Hình 3.1. Toán tử tƣơng tác alt

Toán tử 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. Toán
tử opt gần giống với toán tử alt, chỉ có điều trong opt chỉ có một toán hạng duy
nhất. Hình 3.2 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).
Toán tử 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 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.
11


opt
[No error]
post_coment()

Hình 3.2. Toán tử tƣơng tác opt

loop

notify()

Hình 3.3. Toán tử tƣơng tác loop vô hạn

loop(10)

notify()

Hình 3.4. Toán tử tƣơng tác loop với cận trên = cận dƣới = 10

loop(5, 10)
[size <0]

notify()

Hình 3.5. Toán tử tƣơng tác loop với cận trên = 5, cận dƣới = 10

12