sinh CA KIỂM THỬ CHO CÁC HỆ THỐNG PHẢN ỨNG sỬ DỤNG CÔNG CỤ KIỂM

CHỨNG MÔ HÌNH NUSMV

Trịnh Công Duy1*, Võ Đức Lân2, Nguyễn Thanh Bình1

1
Trường Đại học Bách khoa, Đại học Đà Nẵng;
2
Trường Đại học Phạm Văn Đồng
*Email: 1tcduy@dut.udn.vn

TÓM TẮT

Kiểm thử phần mềm là một trong những hoạt động đóng vai trò quan trọng nhằm nâng cao
chất lượng phần mềm, đặc biệt các hệ thống phản ứng. Trong các kỹ thuật kiểm thử, kiểm
chứng mô hình là một kỹ thuật hữu hiệu nhằm tìm lỗi trên mô hình đó. Hiện nay, có nhiều
nghiên cứu về các kỹ thuật và công cụ kiểm chứng mô hình. Trong bài báo này, chúng tôi
nghiên cứu việc ứng dụng công cụ kiểm chứng mô hình NuSMV để tạo các ca kiểm thử cho
các hệ thống phản ứng. NuSMV đưa ra các phản ví dụ, thông thường các phản ví dụ này có
ý nghĩa là hướng dẫn, phân tích, tìm kiếm nguồn gốc nguyên nhân gây ra lỗi. Đối với các
hệ thống phản ứng, các phản ví dụ được xem là các ca kiểm thử nhằm phát hiện lỗi. Chúng
tôi dùng ngôn ngữ SMV để mô hình hóa yêu cầu và các điều kiện bao phủ, và sử dụng logic
thời gian LTL hoặc CLT để định nghĩa các thuộc tính bẫy. Từ các mô hình SMV và các
thuộc tính bẫy, công cụ kiểm chứng mô hình NuSMV được sử dụng để sinh ra ca kiểm thử.
Giải pháp được thử nghiệm cho một hệ thống phản ứng thực tế.

Từ khóa: Hệ thống phản ứng; Kiểm chứng mô hình; Công cụ NuSMV; Thuộc tính bẫy; Tiêu chí
bao phủ.

1. GIỚI THIỆU
Việc phát hiện và khắc phục các lỗi cho các phần mềm là một công việc đòi hỏi nhiều
nỗ lực và chi phí trong phát triển phần mềm. Hiện nay, phần mềm đang được ứng dụng
ngày càng rộng rãi trong nhiều lĩnh vực, do đó chất lượng phần mềm ngày càng được quan tâm.
Trong công nghệ phần mềm, kiểm thử là hoạt động cơ bản nhằm phát hiện các lỗi của phần
mềm. Trong đó, kiểm thử tự động nhằm xử lý một cách tự động quy trình kiểm thử, sinh ca
kiểm thử, thực thi kiểm thử và đánh giá kết quả kiểm thử.

Hệ thống phản ứng (reactive system) khi hoạt động đáp ứng (phản ứng) với các sự kiện
bên ngoài [2]. Chẳng hạn, các hệ thống sinh học là những hệ thống phản ứng, bởi vì nó phản
ứng với các sự kiện nhất định. Tuy nhiên, trong tin học và điều khiển, thuật ngữ này được sử
dụng chủ yếu để mô tả các hệ thống nhân tạo. Hệ thống phản ứng liên tục tương tác với môi
trường và thực thi theo yếu tố tác động bởi môi trường.

1
 Hình 1. Mô hình hệ thống phản ứng.

Hình 1 thể hiện mô hình của một hệ thống phản ứng. Ở một khía cạnh trừu tượng thì nó
được xem là một hộp đen, ta cung cấp các giá trị đầu vào thì hệ thống sẽ cho ra các giá trị đầu ra
thích hợp. Các hệ thống phản ứng có thể được xem là đang ở một trạng thái nhất định và đợi
thông tin đầu vào (input). Với mỗi đầu vào, chúng thực hiện tính toán và sinh đầu ra (output) và
chuyển sang một trạng thái mới. Thông thường, các hệ thống nhúng và các hệ thống điều khiển
cũng là các hệ thống phản ứng [1]. Với các hệ thống phản ứng, yếu tố an toàn (Safety) được
quan tâm hàng đầu.

Hệ thống phản ứng được ứng dụng trong các ngành công nghiệp như hệ thống máy bay,
hệ thống vận tải, hệ thống năng lượng, hạt nhân…, vì vậy việc hệ thống bị lỗi là rất nghiêm
trọng, cần phải được kiểm chứng để khắc phục các lỗi đó. Hơn nữa, “lỗi hệ thống” có xu hướng
được phát hiện muộn trong quá trình phát triển khi mà nó đã gây ra thiệt hại đáng kể, rất khó để
gỡ lỗi và tốn nhiều chi phí. Trong tiến trình phát triển phần mềm cho các hệ thống phản ứng,
giai đoạn kiểm thử đóng vai trò quan trọng. Phần mềm càng lớn và càng phức tạp, thủ tục kiểm
thử đòi hỏi tốn nhiều thời gian và công sức. Việc tìm lỗi càng sớm càng tốt, ngăn ngừa các
khiếm khuyết trước khi thực hiện kiểm thử ở mức cao hơn, phức tạp hơn và chi phí cao hơn.

Trong bài báo này, chúng tôi sử dụng kỹ thuật kiểm chứng mô hình (model checking)
để sinh tự động các ca kiểm thử cho hệ thống phản ứng. Chúng tôi sẽ sử dụng công cụ NuSMV
để tiến hành kiểm chứng mô hình của một ứng dụng phản ứng cụ thể, sau đó sinh ra các ca kiểm
thử dựa trên các kết quả sinh ra từ quá trình kiểm chứng này.

Nội dung của bài báo được tổ chức như sau: Phần 1 giới thiệu chung về bài báo và trình
bày tổng quan về hệ thống phản ứng. Phần 2 trình bày về việc ứng dụng kiểm chứng mô hình
trong kiểm thử phần mềm. Trong phần 3, chúng tôi đề xuất phương pháp ứng dụng công cụ
kiểm chứng mô hình NuSMV để tạo ca kiểm thử cho các hệ thống phản ứng. Phần 4 trình bày
việc ứng dụng giải pháp này cho một hệ thống cụ thể và các kết quả của việc thử nghiệm. Cuối
cùng là phần kết luận và đề xuất hướng phát triển tiếp theo.

2. KIỂM CHỨNG MÔ HÌNH

Trong phát triển phần mềm, kỹ thuật kiểm chứng mô hình được sử dụng để chứng minh
một cách tự động tính đúng đắn của phần mềm hoặc chỉ ra tại sao phần mềm không chạy đúng
thông qua phản ví dụ (counter-example). Các phản ví dụ sẽ được sử dụng để hình thành nên các
ca kiểm thử của hệ thống. Trong phần này chúng tôi trình bày kỹ thuật kiểm chứng mô hình, các

2
vấn đề về việc sử dụng logic thời gian tuyến tính (LTL - Linear Temporal Logic) trong kiểm
chứng mô hình, các công cụ kiểm chứng mô hình và đặc biệt là NuSMV – công cụ mà chúng
tôi sử dụng trong bài báo này.

2.1 Giới thiệu

Kiểm chứng mô hình là kỹ thuật phân tích hệ thống để xác định tính hợp lệ của một hay
nhiều tính chất mà người dùng quan tâm trong một mô hình cho trước. Cụ thể hơn, với mô hình
M và thuộc tính p cho trước, nó kiểm tra liệu thuộc tính p có thỏa mãn trong mô hình M hay
không: M |= p [3]. Về mặt thực thi, kiểm chứng mô hình là kỹ thuật tĩnh, nó duyệt qua tất cả các
trạng thái, các đường thực thi có thể có trong mô hình M để xác định tính phủ định của p. Kiểm
chứng mô hình bao gồm 3 bước: mô hình hóa, đặc tả và kiểm chứng.

Bước mô hình hóa, đầu vào của bước này có thể là bản thiết kế phần mềm hoặc là các
dòng mã lập trình.

Bước tiếp theo, định nghĩa các thuộc tính mà mô hình cần thỏa mãn được đặc tả. Các
thuộc tính này thường được diễn đạt bằng các biểu thức logic. Trong nghiên cứu này, chúng tôi
sử dụng các biểu thức Logic thời gian tuyến tính (LTL- linear-time-temporal logic) để biểu diễn
các thuộc tính này. Kết quả của hai bước mô hình hóa và đặc tả là đầu vào của kiểm chứng mô
hình.

Trong bước cuối cùng, công cụ kiểm chứng sẽ tự động thực hiện và trả về kết quả là
thỏa mãn nếu mô hình thỏa mãn các thuộc tính, hoặc đưa ra một phản ví dụ nếu mô hình không
thỏa mãn.

Hình 2. Sơ đồ tổng quát của kiểm chứng mô hình.

2.2 Logic thời gian

Logic thời gian [4] dùng để mô tả các kí hiệu và hệ thống luật về giá trị đúng sai của
các vị từ có tính đến yếu tố thời gian. Khác với logic mệnh đề trong đó mỗi mệnh đề có tính
chất đúng sai rõ ràng mà không quan tâm đến thời điểm đang xem xét, logic thời gian cho phép

3
biểu diễn các mệnh đề mà giá trị chân lý của nó phụ thuộc vào thời gian. Chúng tôi sẽ trình bày
các toán tử logic thời gian trong các mục dưới đây.

- Toán tử globally (toàn thể)

Toán tử globally kí hiệu là ð . Giả sử ð là một biểu thức logic vị từ, khi đó biểu thức ð
có giá trị đúng nếu  đúng trong mọi thời điểm. Người ta cũng thường kí hiệu toán tử này là G.

- Toán tử next (tiếp theo)

Toán tử next kí hiệu là . Giả sử  là một biểu thức logic. Có thể coi  như một dãy trạng
thái và trạng thái hiện tại đang xét đến là trạng thái thứ n. Khi đó biểu thức  có giá trị đúng
khi và chỉ khi phần tử ngay sau phần tử hiện tại trong dãy trạng thái  (phần tử thứ n+1) có giá
trị đúng. (bằng 1).
Toán tử next thường được kí hiệu bằng chữ cái X.

- Toán tử eventually (cuối cùng sẽ xảy ra)

Toán tử eventually kí hiệu là ◊. Giả sử  là một biểu thức logic và  được coi như một dãy
trạng thái mà mỗi phần tử chỉ có giá trị bằng 0 hoặc 1. Khi đó giá trị biểu thức ◊  bằng 1 khi và
chỉ khi  có ít nhất một phần tử có giá trị bằng 1. Toán tử ◊ được định nghĩa thông qua toán tử □
như sau:
◊ ≡ □ φ
Toán tử eventually thường được kí hiệu bằng chữ cái F. Có hai loại logic thời gian được
sử dụng phổ biến:
- LTL (linear-time-temporal logic): Logic thời gian tuyến tính. Thời gian có cấu trúc
tuyến tính, mỗi trạng thái chỉ có một trạng thái ngay tiếp sau nó.
- CTL (branching-time-temporal logic): Logic thời gian rẽ nhánh. Thời gian có cấu trúc
tuyến tính, mỗi trạng thái có nhiều trạng thái ngay tiếp sau nó.
Trong nghiên cứu này, chúng tôi sử dụng các biểu thức Logic thời gian tuyến tính LTL để
biểu diễn các thuộc bẫy trong quá trình kiểm chứng mô hình.

2.3 Ngôn ngữ SMV

Ngôn ngữ SMV (Symbolic Model Verifier) [8] được sử dụng để mô tả các hệ thống hữu
hạn trạng thái. Các kiểu dữ liệu mà ngôn ngữ này cung cấp bao gồm: kiểu logic (boolean), kiểu
số nguyên (bounded interger subrange) và các kiểu dữ liệu liệt kê (symbolic enum). Các mô tả
của một hệ thống phức tạp có thể được chia nhỏ thành các mô-đun và mỗi một mo-đun này có
thể được thực thi nhiều lần. Cấu trúc của một chương trình được viết bằng SMV như sau:
MODULE tên_mô-đun
VAR
Khai báo các biến.
ASSIGN
Mô tả các bước chuyển trạng thái.

4
 Kết thúc câu lệnh là một dấu chấm phẩy (;). Chi tiết về ngô ngữ SMV được trình bày
trong [8].

2.4 Công cụ kiểm chứng NuSMV

NuSMV [4] là một công cụ kiểm chứng mô hình được phát triển bởi trường đại học
Carnegie Mellon University (CMU) và viện per la Ricerca Scientifica Tecnolgica (IRST).
NuSMV được thiết kế với kiến trúc mở, mềm dẻo và được mô tả đầy đủ để phục vụ cho việc
kiểm chứng mô hình phần mềm.
NuSMV có thể xử lý đặc tả bằng ngôn ngữ SMV. Đặc tả này chứa hệ thống đã được mô
hình hóa và các thuộc tính mà hệ thống cần kiểm chứng. Sau khi xử lý, NuSMV sẽ đưa ra thông
báo hệ thống có thỏa mãn các thuộc tính đó hay không, nếu hệ thống không thỏa mãn, NuSMV
sẽ đưa ra phản ví dụ. NuSMV hỗ trợ cả đặc tả thuộc tính bằng LTL và CTL.

3. ỨNG DỤNG CÔNG CỤ KIỂM CHỨNG MÔ HÌNH NUSMV TẠO CA KIỂM

THỬ CHO CÁC HỆ THỐNG PHẢN ỨNG

3.1 Quy trình tạo ca kiểm thử

Để sinh ca kiểm thử bằng kiểm chúng mô hình, chúng ta sử dụng logic thời gian để định
nghĩa những thuộc tính bẫy. Sau đó thực hiện quá trình kiểm chứng mô hình sẽ sinh ra các phản
ví dụ. Ý tưởng của hướng tiếp cận này là đầu tiên ta mô hình hóa bài toán của hệ thống phản
ứng bằng ngôn ngữ SMV, bước thứ hai ta biểu diễn các thuộc tính bẫy bằng logic thời gian LTL
hoặc CLT. Các bước thực hiện như sau:
- Mô tả các chức năng của hệ thống phản ứng bằng ngôn ngữ SMV.
- Xác định các hành vi của hệ thống cần được kiểm tra bởi các thuộc tính bẫy.
- Kiểm chứng các thuộc tính với NuSMV, chỉnh sửa các đặc tả đến khi thuộc tính đó
ổn định.
- Thực thi lại các thuộc tính bẫy bằng NuSMV. NuSMV sinh ra các phản ví dụ.
- Ánh xạ các phản ví dụ thành các ca kiểm thử bằng cách thêm vào biến State. Biến
State này được khởi gán bằng 0.
Các phản ví dụ này được xem là các ca kiểm thử, được minh họa trong Hình 3.

Hình 3. Quy trình tạo ca kiểm thử bằng kiểm chứng mô hình.

5
3.2 Tiêu chí bao phủ trong sinh ca kiểm thử
Mẫu công thức LTL có thể sử dụng để xác định một thuộc tính phù hợp như sau:
G (<Mô hình trạng thái hệ thống phản ứng>  <Giá trị đầu ra mong muốn>)
Trong đó:
<Mô hình trạng thái hệ thống phản ứng>: Chứa giá trị hiện tại của hệ thống hoặc tín
hiệu đầu ra của hệ thống hiện tại và các hành động tác động tới hệ thống như là các giá trị đầu
vào.
<Giá trị ra mong muốn>: Chứa các kết quả của tín hiệu đầu ra.
Việc sinh ra các ca kiểm thử chính xác, bao phủ được tất cả các trường hợp lỗi có thể
xảy ra là rất quan trọng. Do đó, việc kiểm đặc tả các thuộc bẫy phải thõa mãn các tiêu chí bao
phủ. Trong nghiên cứu này, chúng tôi sử dụng các tiêu chí sau đây:

3.2.1 Phủ tất cả các trạng thái của mô hình

Là đảm bảo tất cả các trạng thái phải kích hoạt ít nhất một lần. Một thuộc tính bẫy
tương ứng với một trạng thái.
Công thức chung: G (!” trạng thái”)
Phản ví dụ cho tính an toàn đơn: F (“trạng thái”)
Ví dụ: Trong mô hình điều khiển tốc độ xe, một chiếc xe có tất cả ba trạng thái dừng
(stop), chạy chậm (slow) và chạy nhanh (fast):
G(!velocity = stop)
G(!velocity = slow)
G(!velocity = fast)

3.2.2 Phủ tất cả các chuyển tiếp

Là đảm bảo phủ tất cả các cạnh ít nhất một lần, phủ tất cả giá trị đúng sai của biểu thức
logic. Ta có thể biểu diễn thuộc tính này bằng LTL như sau:


G ( & X !)

Phản ví dụ về tính an toàn: F(α & ϕ & X β )

Ví dụ: Trong hệ thống phanh xe, khi xe đang dừng và thực hiện tăng tốc (đạp ga) thì xe
sẽ chuyển sang chạy chậm.
G(velocity=stop& accelerate  X velocity=slow)

3.2.3 Phủ các điều kiện

Với mỗi chuyển tiếp, và với mỗi biến bảo vệ v thuộc kiểu Boolean thì tồn tại 2 ca kiểm
6
thử cho bước chuyển đổi.
G ! (α & v) -> X(!β) v

G ! (α & !v) -> X(!β)

4. THỬ NGHIỆM

Xét bài toán thiết kế một chương trình mô phỏng sự hoạt động của hệ thống điều khiển
tốc độ xe (Car Controller) [5]. Hệ thống này có hai giá trị đầu vào thuộc kiểu Boolean thể hiện
cho quyết định của người sử dụng. Giá trị thứ nhất là accelerate (Tăng tốc), giá trị thứ hai là
brake (Phanh).
- Bất cứ khi nào phanh được kích hoạt, chuyển động sẽ dừng lại.
- Khi tăng tốc và không phanh, vận tốc tăng dần cho đến khi vận tốc nhanh.
- Khi không tăng tốc và không phanh thì vận tốc giảm dần cho đến khi xe dừng.

Hình 4. Mô hình hệ thống điều kiển phanh xe.

Từ mô hình trong hình 4 chúng ta có thể xây dựng được mô hình bằng ngôn ngữ SMV như sau:

7
 Hình 5. Biểu diễn mô hình bằng ngôn ngữ SMV.

Để mô tả các thuộc tính bẫy khi thực thi ca kiểm thử bằng công cụ NuSMV chúng ta sử
dụng các độ bao phủ để sinh ra các thuộc tính bẫy, từ đó ta sẽ có được các ca kiểm thử [2].

4.

4.1 Phủ tất cả các trạng thái

Để tạo ra một bộ kiểm thử bao phủ tất cả các biến trạng thái của hệ thống. Một thuộc
tính bẫy cho mỗi trạng thái a của mỗi biến x với giá trị không được thực hiện:  ¬ (x = a). Một
phản ví dụ như là một thuộc tính bẫy với bất kỳ dấu vết nào có chứa một trạng thái khi x=a.
Trong hệ thống điều khiển tốc độ xe thì trạng thái bao phủ đối với mỗi biến có thể đạt được với
cách thiết lập các thuộc tính bẫy như sau:
G (!accelerate =FALSE)
G (!accelerate =TRUE)
G (!brake =FALSE)
G (!brake =TRUE)
G (!velocity =stop)
G (!velocity =slow)
G (!velocity =fast)

4.2 Phủ tất cả các chuyển tiếp và điều kiện dựa trên đặc tả SCR
Đặc tả SCR (Software Cost Reducation) [10] xây dựng các bảng để xác định các yêu
cầu hành vi cho các hệ thông phần mềm được gắn vào thời gian thực tế. Một lợi ích của phương
pháp SCR đó là cấu trúc được xác định tốt cho phép các phân tích cấu trúc được sử dụng để
kiểm tra sự đồng nhất, tính hoàn chỉnh của đặc tả. Bên cạnh đó, các ứng dụng SCR cung cấp
khả năng phát hiện dấu vết từ các yêu cầu phần mềm tới mã nguồn. Nhiều loại của các phân tích
đã được áp dụng tới các đặc tả SCR. Mô hình SCR được định nghĩa là bộ bốn (S,S 0, Em,T )
trong đó S là tập các trạng thái, S 0 Ì S trạng thái ban đầu, E m tập các sự kiện đầu vào, T là bộ
chuyển đổi, cho phép chuyển đổi các trạng thái. T được mô tả bởi một bảng sự kiện.
Bảng 1. Phương thức chuyển đổi trạng thái SCR.

Trạng thái hiện tại Sự kiện Trạng thái mới

Stop accelerate =1 AND brake =0 slow

Slow accelerate =1 AND brake =0 fast

Fast accelerate =0 AND brake =0 slow

Slow accelerate =0 AND brake =0 stop

8
 Fast brake stop

Việc tạo ra các thuộc tính bẫy thỏa mãn điều kiện phủ đặc tả SCR, đồng nghĩa với tiêu
chí phủ tất cả các trạng thái và tất cả các chuyển tiếp của các trạng thái được mô tả ở phần 4.1.
Chúng ta có thể chuyển bảng SCR thành một SMV. Ý tưởng cơ bản là tạo ra các thuộc
tính bẫy dựa trên bảng SCR. Mỗi một thuộc tính bẫy xây dựng trên nguyên tắc giả sử rằng sự
kiện là không bao giờ được kích hoạt.
Ví dụ, biến CaseVar đại diện cho các trường hợp được lựa chọn cho biến Var. Kết quả
thuộc tính bẫy trong LTL được biểu diễn như sau:
G ¬ (CaseVar = 1),
G ¬ (CaseVar = 2),
…
Trong bảng 1, chúng ta có 5 trường hợp có thể thực hiện, do đó sẽ có 6 thuộc tính bẫy,
bởi vì trường hợp “không thay đổi” được xem là một sự kiện.
Thuộc tính bẫy được biễu diễn bằng LTL như sau:
{G￢(Case_velocity = i) | 0 ≤ i ≤ 6}

4.3 Sinh ca kiểm thử bằng kiểm chứng mô hình với NuSMV
Chúng sẽ sử dụng một số thuộc tính bẫy sau đây để sinh ca kiểm thử cho hệ thống nhờ
vào kỹ thuật kiểm chứng mô hình. Các thuộc tính bẫy được biễu diễn trong SMV như sau:
-- Thuộc tính bẫy điều kiện bao phủ các đỉnh
LTLSPEC
G(! (velocity = stop))
LTLSPEC
G(! (velocity = slow))
LTLSPEC
G(! (velocity = fast))
-- Thuộc tính bẫy điều kiện bao phủ chuyển tiếp
LTLSPEC
G(velocity=stop & !accelerate -> X velocity=slow)
Sau khi tiến hành kiểm chứng mô hình với các thuộc bẫy chúng ta có các ca kiểm thử
được sinh ra dựa trên các phản ví dụ. Hình 6 minh họa một trường hợp ca kiểm thử được tạo ra
từ thuộc tính bẫy trong NuSMV:

9
 Testcase

Hình 6. Sinh ca kiểm thử với kiểm chứng mô hình.

Từ kết quả ở hình 6, chúng ta thấy việc kiểm chứng sẽ kiểm tra thuộc tính bẫy G
((velocity =stop & !(accelerate & !brake)) -> X velocity = slow) đưa đến kết quả là false. Từ
đo sinh ra phản ví dụ cũng chính là ca kiểm thử.
Trên cơ sở phản ví dụ được sinh ra trong hình 6, chung ta có được ca kiểm thử tương
ứng. Ca kiểm thử này được mô tả như sau:
Đầu vào là dữ liệu thử tăng tốc (accelerate = TRUE) và thắng xe (brake =TRUE) thì
vận tốc ở trạng thái 1.1 là dừng (velocity =stop). Đến trạng thái 1.3 thì vận tốc chậm (velocity
=slow) lúc này được thắng xe (brake =TRUE) thì trong trạng thái cuối cùng vận tốc dùng
(velocity =stop).
Như vậy, tương ứng với các phản ví dụ khác nhau, quá trình kiểm chứng mô hình sẽ
giúp sinh ra các ca kiểm thử tương ứng với các phản ví dụ được tạo ra.
Hệ thống điều khiển tốc độ của ô-tô là một ví dụ điển hình cho các hệ thống phản ứng.
Sau khi ứng dụng kỹ thuật kiểm chứng mô hình với các thuộc tính bẫy, dựa vào các phản ví dụ
được sinh ra, chúng ta sẽ có được các ca kiểm thử cần thiết. Với những hệ thống lớn và phức tạp
hơn, việc sinh ca kiểm thử tự động sẽ giúp tiết kiệm được rất nhiều chi phí cho quá trình kiểm
thử.

4.4 Thực thi kiểm thử với kiểm chứng mô hình

Trong phần trình bày ở trên, chúng tôi sử dụng kiểm chứng mô hình để sinh ca kiểm thử
tự động. Tuy nhiên, chúng ta còn có thể dùng kỹ thuật này để đánh giá chất lượng phần mềm. Ta
có thể thực thi ca kiểm thử với kiểm chứng mô hình dựa trên ý tưởng cơ bản của kiểm chứng
mô hình các ca kiểm thử.

10
 Trong phần này, chúng tôi giới thiệu sơ lược về việc thực thi kiểm thử bằng kiểm chứng
mô hình. Đây là bước tiếp theo của quá trình kiểm thử phần mềm nói chung. Việc thực thi kiểm
thử sử dụng dụng kiểm chứng mô hình dựa trên ý tưởng: Các ca kiểm thử được biểu diễn như
một máy hữu hạn trạng thái, với các biến được thêm vào, ví dụ như biến State. Biến State này
được khởi gán bằng 0 và được tăng lên đến trạng thái cuối cùng của ca kiểm thử. Giá trị của các
biến được thiết lập theo giá trị của biến State.

Hình 7. Thực thi ca kiểm thử trong NuSMV.

Để mô phỏng thực hiện ca kiểm thử trên mô hình thì các ca kiểm thử kết hợp với mô
hình bằng cách di chuyển mô-đun chính của chương trình đến mô-đun phụ của ca kiểm thử và
thay đổi tất cả các biến, các tham số của mô-đun đó Mô-đun phụ này được khởi tạo trong mô
hình ca kiểm thử và các biến đầu vào được sử dụng như là các tham số.

5. KẾT LUẬN
Trong bài báo này, chúng tôi đã áp dụng lý thuyết về đặc tả LTL và CLT định nghĩa các
thuộc tính bẫy. Dùng thuộc tính bẫy và mô hình hóa bài toán là hai giá trị đầu vào của kiểm
chứng mô hình để sinh ra các ca kiểm thử tự động cho ví dụ về hệ thống điều khiển tốc độ xe ô
tô. Kết quả thực nghiệm thu được là các ca kiểm thử, thực thi ca kiểm thử với kiểm chứng mô
hình bằng cách ánh xạ các phản ví dụ thành các ca kiểm thử. Sau đó kết hợp với mô hình ban
đầu để thực thi ca kiểm thử, nếu như mô hình kiểm chứng sinh ra các phản ví dụ thì ca kiểm thử
đó phát hiện được lỗi (hệ thống có lỗi) ngược lại thì hệ thống không có lỗi. Kết quả đó cho thấy,
phương pháp sử dụng kiểm chứng mô hình để sinh ca kiểm thử trong kiểm thử phần mềm cho
hệ thống phản ứng là khả thi, có thể sử dụng các ca kiểm thử đó để xác minh tính đúng đắn của
phần mềm với thiết kế ban đầu của hệ thống.

TÀI LIỆU THAM KHẢO

11
[1] Trinh Cong Duy, Nguyen Thanh Binh, Ioannis Parissis. Automatic Generation of Test Cases in
Regression Testing for Lustre/SCADE. Journal of Software Engineering and Applications, Vol. 6,
2013.
[2]  Albert Benveniste, Gerard Berry. The Synchronous Approach to Reactive and Real-Time Systems.
Proceedings of the IEEE, 1991.
[3] Angelo Gargantini, Constance Heitmeyer. Using Model Checking to Generate Tests from
Requirements Specications, Berlin Heidelberg, 1999.
[4] Cimatti, E. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri, R. Sebastiani, A. Tacchella.
NuSMV 2: An OpenSource Tool for Symbolic.
[5] Gordon Fraser, FranzWotawa, Paul E. Ammann. Testing with model checkers: A survey, Competence
Network Softnet Austria, Austria, 2007.
[6] Jussi Lahtinen. Simplification of NuSMV Model Checking Counter Examples, February 14, 2008.
[7] Karolina Zurowska and Juergen Di. Model-based generation of test cases for reactive systems.
Applied Formal Methods Group School of Computing Queen’s University Kingston, Ontario,
Canada, June 2010.
[8] K. L. McMillan. The SMV language, Cadence Berkeley Lbs 2001.
[9] Luca Aceto Kim G. Larsen Anna. Reactive Systems: Modelling, Specification and Verification, May
11, 2005.
[10] C. L. Heitmeyer. Encyclopedia of Software Engineering, chapter Software Cost Reduction.Jpưohn
Wiley & Sons, 2002.

GENERATING TEST CASES FOR REACTIVE SYSTEMS

USING THE NUSMV MODEL CHECKING TOOL

Trinh Công Duy1*, Vo Đuc Lan2, Nguyen Thanh Binh1

1
Danang University of Science and Technology, The University of Da Nang;
2
Pham Van Dong University
*Email: 1tcduy@dut.udn.vn

ABSTRACT

Software testing is one of the important activities playing an important role in improve
software quality. Among testing techniques, model checking is an effective technique to find
errors. In this paper, we study the NuSMV model checking tool to generate test cases for
reactive systems. NuSMV usually gives the meaning of counter-examples which show,
analyse and search for errors. For the reactive systems, the counter-examples are used as
test cases for reactive systems. We use the SMV language to model systems and coverage
criteria, then use temporal logics LTL or CLT for define trap properties. The SMV tool
generates test cases by basing on SMV models and trap properties. A case study is also
presented.

Keywords: Reactive system; Model checking; NuSMV tool; Trap property; Coverage
criteria.

12
13