Kiểm thử hướng mô hình và ứng dụng trong phát triển ứng dụng cho điện thoại di động thông minh

Luận văn thạc sỹ

1

MỤC LỤC
LỜI CAM ĐOAN .......................................................................................................... 3
Danh mục các từ viết tắt và thuật ngữ ........................................................................ 4
Danh mục các bảng ....................................................................................................... 5
Danh mục các hình vẽ ................................................................................................... 6

MỞ ĐẦU ............................................................................................................... 7
Chương 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ KIỂM THỬ
HƯỚNG MÔ HÌNH ............................................................................................. 9
1.1

Tổng quan về kiểm thử ...................................................................................... 9
1.1.1 Các khái niệm liên quan trong kiểm thử ...................................................... 9
1.1.2 Quy trình kiểm thử (Test Process) ............................................................. 12
1.2
Tổng quan về kiểm thử hướng mô hình ......................................................... 15
1.2.1 Khái niệm về kiểm thử hướng mô hình ...................................................... 15
1.2.2 Cách thức làm việc của kiểm thử hướng mô hình ...................................... 16
1.2.3 Ưu thế của kiểm thử hướng mô hình .......................................................... 17
1.2.4 So sánh kiểm thử hướng mô hình và kiểm thử thông thường. .................... 17
1.2.5 Khả năng ứng dụng kiểm thử hướng mô hình trong phát triển ứng dụng
cho điện thoại di động thông minh......................................................................... 18
1.2.6 Giới thiệu một số công cụ miễn phí hỗ trợ kiểm thử hướng mô hình ........ 20
1.3
Kết chương ........................................................................................................ 21

Chương 2. SỬ DỤNG CÔNG CỤ SPEC EXPLORER ĐỂ SINH CÁC CA

KIỂM THỬ TỰ ĐỘNG ..................................................................................... 23
Đặt vấn đề ......................................................................................................... 23
Cơ sở lý thuyết áp dụng trong spec explorer ................................................. 23
2.2.1 Trạng thái (state)........................................................................................ 23
2.2.2 Máy tạo mô hình tự động (model automata).............................................. 24
2.2.3 Chương trình mô hình (model program) ................................................... 25
2.2.4 Duyệt trạng thái (State exploration) .......................................................... 26
2.3
Các bước xây dựng chương trình mô hình và sinh các ca kiểm thử tự động
bằng spec explorer....................................................................................................... 27
2.3.1 Tóm lược yêu cầu của ứng dụng ví dụ mẫu ............................................... 29
2.3.2 Các bước tạo ra chương trình mô hình...................................................... 30
2.3.3 Cấu hình kiểm thử để sinh ca kiểm thử ...................................................... 34
2.4
Kết luận ............................................................................................................. 38
2.1
2.2

Chương 3. THỬ NGHIỆM ỨNG DỤNG THỰC TẾ ..................................... 39
3.1

Đặt vấn đề ......................................................................................................... 39

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

2

3.1.1 Thông tin chung về dự án ........................................................................... 39
3.1.2 Mô tả về ứng dụng (đặc tả hệ thống) ......................................................... 39
3.1.3 Xây dựng các Ca kiểm thử (viết ra bằng cách thủ công) ........................... 41
3.2
Ứng dụng kỹ thuật sinh kiểm thử tự động hướng mô hình vào dự án ....... 42
3.2.1 Phân tích ban đầu ...................................................................................... 42
3.2.2 Xây dựng chương trình mô hình cho Tutle Run ......................................... 43
3.2.3 Đánh giá kết quả ........................................................................................ 52
3.3
Kết chương ........................................................................................................ 53
3.3.1 Ưu điểm của kiểm thử hướng mô hình với Spec Explorer ......................... 53
3.3.2 Nhược điểm của kiểm thử hướng mô hình với Spec Explorer ................... 53

KẾT LUẬN VÀ KIẾN NGHỊ ........................................................................... 54
A. Kết luận ................................................................................................................... 54
Các kết quả chính đạt được trong đề tài: .............................................................. 54
Những khó khăn và hướng giải quyết .................................................................... 55
B. Kiến nghị ................................................................................................................. 56
C. Hướng phát triển của đề tài. ................................................................................. 57

Tài liệu tham khảo ............................................................................................. 58

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

3

LỜI CAM ĐOAN
Tôi xin cam đoan: Luận văn "Kiểm thử hướng mô hình và ứng ụng trong phát
triển ứng dụng cho điện thoại di động thông minh" là do bản thân tôi tự thực hiện dưới
sự hướng dẫn của PGS.TS. Huỳnh Quyết Thắng - Viện Công nghệ thông tin và Truyền
thông - Đại học Bách khoa Hà Nội; các thông tin số liệu và kết quả trong Luận văn có
nguồn gốc rõ ràng, nội dung của Luận văn chưa từng được công bố trong bất kỳ một
công trình nghiên cứu nào ở trong nước.

Hà Nội, tháng 9 năm 2015
Tác giả Luận văn

Ngô Hoàng Thành

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

4

Danh mục các từ viết tắt và thuật ngữ
Từ viết tắt,
thuật ngữ

Từ viết đầy đủ

AAL

Adapter Action Language

IUT
MBT
OTC

Impementation Under Test
Model Based Testing
Intel Open Source
Technology Center
System Under Test

SUT

Ngô Hoàng Thành

Ý nghĩa
Ngôn ngữ mô hình hóa được sử dụng
trong fMBT
Bộ phần thực thi cần kiểm thử
Kiểm thử hướng mô hình
Trung tâm công nghệ mã nguồn mở
của Intel
Hệ thống cần kiểm thử

Lớp 12BCNTT2 – Khóa 2012B

Luận văn thạc sỹ

5

Danh mục các bảng
Bảng 1: Ca kiểm thử của Turtle Run ............................................................................. 42
Bảng 2: Ca kiểm thử đã dùng với HowTo Scene của Turtle Run.................................. 48

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

6

Danh mục các hình vẽ
Hình 1-1: Mối liên hệ giữa sai sót, lỗi và thất bại ............................................................ 9
Hình 1-2: Mô hình chữ V ............................................................................................... 13
Hình 1-3: Ba phương pháp cơ bản tích hợp kiểm thử vào kỹ nghệ hệ thống ................ 14
Hình 1-4: Cách thức vận hành của kiểm thử hướng mô hình ........................................ 16
Hình 2-1: Quy trình sử dụng spec explorer .................................................................... 28
Hình 2-2: Normal Trace Sample .................................................................................... 32
Hình 2-3: LoadAndSave Trace Sample ......................................................................... 32
Hình 2-4: ShowOldMap Trace Sample .......................................................................... 33
Hình 2-5: Hỉnh ảnh về model program .......................................................................... 35
Hình 2-6: Hình ảnh ví dụ về ca kiểm thử ....................................................................... 36
Hình 2-7: Hình ảnh minh họa state trong ca kiểm thử (S32) ......................................... 37

Hình 2-8: Hình ảnh minh họa state trong ca kiểm thử (S65) ......................................... 38
Hình 3-1: Scene Flow của Turtle Run ........................................................................... 40
Hình 3-2: Mô hình SceneFlow của Turtle Run .............................................................. 44
Hình 3-3: Ca kiểm thử SceneFlow của Turtle Rune ...................................................... 44
Hình 3-4: Mô hình và ca kiểm thử TopScene của Turtle Run ....................................... 45
Hình 3-5: Mô hình và ca kiểm thử rankingScene của Turtle Run ................................. 46
Hình 3-6: Mô hình và ca kiểm thử HowTo Scene của Turtle Run ................................ 47
Hình 3-7: Mô hình và ca kiểm thử GameOver Scene của Turtle Run ........................... 48
Hình 3-8: Mô hình vào ca kiểm thử GameScene - Story của Turtle Run ...................... 50
Hình 3-9: Mô hình và ca kiểm thử GameScene - gameplay của Turtle Run ................. 51

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

7

MỞ ĐẦU
1. Lý do chọn đề tài
Kiểm thử phần mềm luôn là một khâu rất quan trọng trong việc phát triển phần
mềm. Tuy nhiên trong thực tế tại Việt Nam rất ít công ty chú trọng đúng mức vào công
đoạn kiểm thử này (do tiết kiệm chi phí, do trình độ nhân công hoặc lý do khác) trong
khi đây là điều then chốt ảnh hưởng tới chất lượng sản phẩm đầu ra.
Khi làm việc tại một công ty phát triển phần mềm ở Việt Nam, tôi nhận thấy
chất lượng của các sản phẩm luôn ở một mức mà có một từ thường được sử dụng là
“chấp nhận được”, do đó sản phẩm công ty nói riêng và có lẽ là cả ngành gia công
phần mềm Việt Nam nói chung đều chưa có tiếng nói, chưa thể sánh ngang với các

nước khác trên thế giới. Ngoài ra, chất lượng của việc kiểm thử cũng là một vấn đề nan
giải.
Do đó tôi chọn đề tài này như một hướng đi hứa hẹn giải quyết các vấn đề về
chất lượng phần mềm nói chung và chất lượng ứng dụng trên điện thoại thông minh
(lĩnh vực mà tôi đang phát triển) được cải thiện trong khi vẫn đảm bảo chi phí sản xuất
trong khoảng cạnh tranh.
2. Tính cấp thiết của đề tài
Như đã nói ở trên, tại Việt Nam chất lượng trong việc kiểm thử trong lĩnh vực
phát triển phần mềm nói chung và phát triển ứng dụng cho điện thoại thông minh nói
riêng đang là một vấn đề nan giải. Qua quả trình tìm hiểu của tác giả, vấn đề kiểm thử
phần mềm cho ứng dụng trên điện thoại di động thông minh có những nguyên nhân
chính sau:
 Quy trình kiểm thử mang nhiều tính chất chủ quan và lệ thuộc vào từng kiểm
thử viên. Tại các công ty phần mềm vừa và nhỏ, việc kiểm thử chưa có quy chuẩn rõ
ràng dẫn đến việc xây dựng các ca kiểm thử cũng như việc tiến hành kiểm thử phụ
thuộc rất nhiều vào cách nhìn nhận vấn đề của kiểm thử viên.
 Do tiết kiệm chi phí nên bỏ qua nhiều công đoạn kiểm thử. Các công ty phần
mềm ở Việt Nam phần lớn đều dựa trên lĩnh vực “outsource” (làm cho khách hàng)
nước ngoài. Để tăng lợi nhuận, giảm giá thành (tăng tính cạnh tranh), chi phí cho việc
kiểm thử thường bị cắt giảm và xem nhẹ nhất là với các dự án nhỏ, chi phí thấp. Rất
nhiều dự án phát triển ứng dụng cho điện thoại di động thông minh rơi vào trường hợp
này.
 Kỹ thuật kiểm thử còn nhiều hạn chế. Các kỹ thuật kiểm thử chủ yếu là kiểm
thử thủ công và phụ thuộc vào trình độ của kiểm thử viên, trong khi các kiểm thử viên
thường không được đào tạo bài bàn dẫn đến việc kiểm thử còn hạn chế về mặt kỹ thuật.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B

Luận văn thạc sỹ

8

Từ đó đòi hỏi cần phải có một phương pháp, một kỹ thuật cùng với công cụ để
hỗ trợ quy trình kiểm thử, giúp cho khâu này cải thiện được chất lượng mà vẫn đảm
bảo hợp lý về mặt chi phí. Kiểm thử tự động – kiểm thử hướng mô hình chính là một
hướng tiếp cận hứa hẹn đáp ứng được các điều kiện đã đề ra.
3. Nhiệm vụ trong luận văn
Với mục đích ứng dụng được kỹ thuật kiểm thử hướng mô hình vào phát triển
ứng dụng cho điện thoại di động thông minh (smart phone), luận văn tập trung nghiên
cứu các nội dung chính sau :



minh


Tìm hiểu về các kỹ thuật kiểm thử và tập trung vào kiểm thử hướng mô hình
Tìm hiểu các công cụ, lựa chọn công cụ thích hợp.
Áp dụng công cụ vào quá trình phát triển ứng dụng cho điện thoại di động thông
Đánh giá hiệu quả và đưa ra các hướng phát triển tiếp theo.

4. Bố cục của luận văn
Chương 1: Giới thiệu tổng quan về kiểm thử phần mềm và kiểm thử hướng mô
hình. Chương này trình bày về các khái niệm cơ bản trong kiểm thử, tiếp đó sẽ trình
bày về các khái niệm cũng như đặc điểm chung của kiểm thử hướng mô hình.
Chương 2: Phương pháp sử dụng công cụ kiểm thử hướng mô hình. Chương
này tập trung vào việc mô tả quy trình, cách thức thực hiện kiểm thử hướng mô hình

bằng cách sử dụng công cụ Spec Explorer.
Chương 3: Thực nghiệm và đánh giá kết quả. Chương cuối cùng này sẽ trình
bày nội dung của một dự án thực tế về phát triển ứng dụng trên smart phone (phát triển
game Turtle Run), đưa các kết quả khi chưa áp dụng kiểm thử hướng mô hình và sau
khi áp dụng kỹ thuật này. Từ đó đánh giá ưu, nhược điểm của kỹ thuật đối với việc
phát triển ứng dụng trên điện thoại di động thông minh.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

9

Chương 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ
KIỂM THỬ HƯỚNG MÔ HÌNH
1.1 Tổng quan về kiểm thử
1.1.1 Các khái niệm liên quan trong kiểm thử
Ta sẽ đi tìm hiểu một vài thuật ngữ cơ bản trong kiểm thử. Trong đề tài này ta sẽ
sử dụng thuật ngữ IUT (Implementation Under Test) hoặc SUT (System Under Test)
đều mang ý nghĩa là phần thực thi hoặc hệ thống đang cần được kiểm thử. Ta có thể
hiểu đơn giản đấy là đối tượng ta đang muốn kiểm thử nó.
1.1.1.1 Sai sót, Lỗi, Hỏng hóc
Đây là ba thuật ngữ cơ bản của việc kiểm thử mà ta cần phải làm rõ.
Định nghĩa 1 – Sai sót(Fault): Là một sai sót “tĩnh” trong hệ thống [9].
Định nghĩa 2 – Lỗi (Error): Là một trạng thái nội bộ của hệ thống xảy ra sai sót
khi hệ thống đang được vận hành [9].
Định nghĩa 3 – Thất bại (Failure): Là sự sai khác có thể thấy được trong thực

tế của hệ thống so với dự kiến [9].
Sơ đồ sau thể hiện mối quan hệ giữa sai sót, lỗi và thất bại.
Đối chiếu

Kích hoạt
Sai sót

Lỗi

Thất bại

Hình 1-1: Mối liên hệ giữa sai sót, lỗi và thất bại
Sơ đồ trên biểu thị quá trình phát sinh thất bại của hệ thống bắt đầu từ những sai
sót, những sai sót này trong quá trình hệ thống được thực thi sẽ tạo ra lỗi làm cho kết
quả của hệ thống không đúng như chúng ta mong muốn và tạo ra thất bại.
Vậy đâu là nguồn gốc của những sai sót? Ta có thể quy nguyên nhân của những
sai sót về ba nguyên nhân chính sau:
Thứ nhất, cần phải kể đến là những sai lầm, thiếu sót trong yêu cầu của hệ
thống. Trong trường hợp này, kỹ sư hệ thống đã thiếu mất một số trường hợp sử dụng
của hệ thống hoặc thiếu định nghĩa những hành động mà ta mong muốn hệ thống thực
hiện. Những sai sót thuộc loại này có thể được phát hiện bằng việc phân tích yêu cầu
hệ thống.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

10

Thứ hai, là các sai sót liên quan đến chức năng của hệ thống, ví dụ như việc sai
khác giữa đặc tả kiểm thử với kết quả của thực thi của hệ thống trong khi kiểm thử. Sai
sót này thường xảy ra do thiếu sót trong quá trình phát triển, cài đặt của phần mềm
hoặc do phần cứng. Sai sót loại này có thể được phát hiện bằng kiểm thử chức năng.
Thứ ba, là các sai sót phi chức năng. Những sai sót này gắn liền với những đặc
tả phi chức năng của hệ thống như hiệu năng, tính bảo mật, tính mở rộng, tính tương
thích… của hệ thống. Để có thể phát hiện các sai sót loại này ta cần có những phương
pháp tương ứng với từng đặc điểm phi chức năng cụ thể. Ngoài ra ta cũng có thể phát
hiện các sai sót loại này trong quá trình thực thi hệ thống để kiểm thử.
Trên đây là ba khái niệm cơ bản trong kiểm thử, sau đây ta sẽ đưa ra khái niệm
về kiểm thử.
1.1.1.2 Kiểm thử (testing) là gì?
Trong phần này ta sẽ làm rõ các khái niệm liên quan, từ đó đưa ra khái niệm đâu
là kiểm thử và đâu không phải là kiểm thử.
Kiểm thử (testing) trong thực tế có thể vừa là thẩm định (Validation) vừa là kiểm
chứng (Verification) [9]. Trước hết ta cần hiểu thẩm định và kiểm chứng là gì.
Định nghĩa 4 – Thẩm định (validation): Thẩm định là quá trình đánh giá một
hệ thống để đảm bảo rằng nó phù hợp với đặc tả hoặc mục đích sử dụng [9].
Định nghĩa 5 – Kiểm chứng (verification): Kiểm chứng là quá trình xác minh
kết quả của một giai đoạn phát triển hệ thống có thực hiện đúng và đầy đủ yêu cầu
được đưa ra ở giai đoạn trước đó hay không [9].
Ta có thể hiểu một cách đơn giản hơn là kiểm chứng sẽ phát hiện ra lỗi lập trình,
tức là tìm ra sai khác giữa hệ thống ta tạo ra với những yêu cầu đã được đề ra. Còn
thẩm định sẽ phát hiện ra hệ thống có đáp ứng đúng nhu cầu thực tế hay không, do đó
ta có thể phát hiện ra lỗi thiết kế ở mức cao hơn kiểm chứng.
Định nghĩa 6 – Kiểm thử (Testing): Kiểm thử là quá trình đánh giá một cách có
hệ thống (systematically) một hệ thống bằng việc quan sát hoạt động của nó [9].
Định nghĩa 7 – Gỡ lỗi (Debugging): Gỡ lỗi là quá trình tìm ra sai sót dẫn đến

thất bại của hệ thống [9].
Định nghĩa 6 cho ta thấy rõ rằng kiểm thử vừa có thể là thẩm định, vừa có thể là
kiểm chứng. Thông thường kiểm thử viên sẽ tạo ra các ca kiểm thử từ đặc tả yêu cầu
của hệ thống một cách thủ công, khi đó việc kiểm thử chính là kỹ thuật thẩm định hệ
thống. Đối với kiểm thử hướng mô hình, ca kiểm thử thường được sinh tự động từ mô
tả của hệ thống thì khi đó kiểm thử là việc ta xác minh lại kết quả thực thi của hệ thống
đối với các ca kiểm thử này, lúc đó kiểm thử chính là kỹ thuật kiểm chứng.
Ở đây ta cần phân biệt kiểm thử và gỡ lỗi. Có thể hiểu rằng kiểm thử là quá
trình tìm ra thất bại trong khi gỡ lỗi là quá trình xác định sai sót tạo ra các thất bại đó.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

11

1.1.1.3 Một số định nghĩa thuật ngữ liên quan khác.
Định nghĩa 8 – Ca kiểm thử: Một ca kiểm thử là một bộ các giá trị đầu vào và
hành vi mong muốn tương ứng của hệ thống. Trong đề tài này ta sẽ sử dụng từ “ca
kiểm thử” ứng với khái niệm này.[11]
Định nghĩa 9 – Ca kiểm thử trừu tượng: ca kiểm thử trừu tượng là ca kiểm thử
bao gồm những thông tin trừu tượng về đầu vào cũng như đầu ra. Ca kiểm thử loại này
thường không chứa các giá trị của tham số cụ thể hoặc là tên của các chức năng.[11]
Ca kiểm thử trừu tượng thường là bước đầu tiên trong việc tạo ra ca kiểm thử.
Chúng thường được sử dụng để đưa ra ý tưởng về cấu trúc của ca kiểm thử hoặc thông
tin về việc thỏa mãn các tiêu chí. Các thông tin còn thiếu sẽ được thêm vào ca kiểm thử
cụ thể.

Định nghĩa 10 – Ca kiểm thử cụ thể: Một ca kiểm thử cụ thể là một ca kiểm
thử trừu tượng cộng thêm toàn bộ thông tin cụ thể bị thiếu để thực hiện ca kiểm
thử.[11]
Ca kiểm thử cụ thể bao gồm thông tin hoàn chỉnh và có thể được thực hiện trong
quá trình kiểm thử toàn bộ hệ thống. Do đó với một ca kiểm thử đơn giản thường
không đủ để tạo ra quá trình kiểm thử cho kết quả cao.
Định nghĩa 11 – Bộ kiểm thử (test suite): Một bộ kiểm thử là một tập hợp các
ca kiểm thử. Trong đề tài này ta sẽ sử dụng “bộ kiểm thử” ứng với khái niệm này.
Các khái niệm về bộ kiểm thử trừu tượng và cụ thể có thể được định nghĩa
tương tự như định nghĩa về ca kiểm thử.[11]
Định nghĩa 12 – Tiêu chuẩn kiểm thử (test oracle): Một tiêu chuẩn kiểm thử là
một bộ bao gồm các hiểu biết về hành vi mong muốn của SUT.[11]
Mỗi một ca kiểm thử bắt buộc phải có một vài thông tin tiêu chuẩn để ta có thể
so sánh được kết quả quan sát thực tế với hành vi mong muốn của SUT. Nếu ta không
có những tiêu chuẩn này thì việc kiểm thử sẽ không thể tìm ra được thất bại. Các tiêu
chuẩn thường gặp là mong muốn của người dùng, các sản phẩm khác để so sánh, phiên
bản trước đây của chính hệ thống, những suy đoán về mục đích sử dụng, các tiêu chuẩn
liên quan đến luật pháp hoặc thông số đặc tả kiểm thử…
Định nghĩa 13 – Đặc tả kiểm thử (test specification): Một đặc tả kiểm thử là
một mô tả về môi trường của hệ thống hoặc các hành vi mong muốn của hệ thống.
Những đặc tả này được sử dụng để tạo ra các bộ kiểm thử đồng thời cũng được dùng
để so sánh giữa hành vi mong muốn và hành vị quan sát được của hệ thống [11].
Đặc tả kiểm thử được dùng để tạo ra các bộ kiểm thử. Hai đặc tả có thể khác
nhau ở một số khía cạnh như khía cạnh trừu tượng hoặc hình thức. Đặc tả kiểm thử
thường là kết quả của sự thỏa thuận giữa bên cung cấp hệ thống và khách hàng, trong
đó phần quan trọng thường được mô tả một cách kỹ càng, phần ít quan trọng hơn sẽ
được mô tả sơ sài hơn. Thông thường tiêu chí để đánh giá đâu là phần quan trọng sẽ

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

12

dựa trên mong muốn của khách hàng hoặc là hậu quả có thể có của thất bại. Để có thể
thực hiện được các bộ kiểm thử ta cần đến các công cụ kiểm thử và các bộ khung kiểm
thử.
Định nghĩa 14 – Công cụ kiểm thử (test software): Công cụ kiểm thử là một
loại phần mềm được sử dụng trong quá trình kiểm thử. Phổ biến nhất là các test
generator, các bộ khung kiểm thử, và những bộ kiểm thử được tạo ra từ chúng [11].
Định nghĩa 15 – Bộ khung kiểm thử (test framework): Bộ khung kiểm thử là
một bộ khung (framework) với mục đích tự động hóa quá trình kiểm thử, thực thi các
bộ kiểm thử và tự động sinh ra các báo cáo tương ứng [11].
Các framework thường cung cấp khả năng tự động hóa ở một mức nhất định
nào đó. Ví dụ: JUnit (Java) hoặc CppUnit (C++) là bộ khung kiểm thử cho phép định
nghĩa một cách đơn giản, tích hợp và thực thi ở mức unit test.
1.1.2 Quy trình kiểm thử (Test Process)
Có rất nhiều cấp độ trừu tượng mà việc phát triển hệ thống có thể đạt được từ
việc phân tích yêu cầu cho đến việc thực hiện các đoạn mã. Kiểm thử có thể được thực
hiện ở tất cả các cấp độ trừu tượng này. Do đó chúng ta cần xem xét các cấp độ kiểm
thử khác nhau dựa theo mô hình chữ V (V-model) rồi từ đó sẽ là quá trình tích hợp quy
trình kiểm thử vào kỹ nghệ hệ thống (system engineering).
1.1.2.1 Các cấp độ kiểm thử trong V-Model.
Có rất nhiều mô hình mô tả cho ta làm thế nào để quản lý việc phát triển hệ
thống, trong đó nổi bật nhất là mô hình chữ V (V-model). V-model là viết tắt của
Verification software development model (mô hình phát triển phần mềm xác minh).
Cũng tương tự như các mô hình khác về vòng đời phát triển của phần mềm (mô hình

thác nước, mô hình xoắn ốc, …) V-model đưa ra các giai đoạn chính trong quá trình
phát triển phần mềm. Trong V-model ứng với từng giai đoạn phát triển phần mềm khác
nhau ta có các cấp độ kiểm thử khác nhau. Hình dưới đây sẽ cho ta thấy rõ hơn về Vmodel.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

13

Kiểm thử chấp
nhận

Yêu cầu

Kiểm thử hệ
thống

Đặc tả hệ thống

Thiết kế hệ
thống

Kiểm thử tích
hợp

Thiết kế chi

tiết

Kiểm thử đơn
vị

Thực thi

Trình tự xử lý
Ảnh hưởng của kết quả
kiểm thử

Hình 1-2: Mô hình chữ V
Từ hình vẽ trên ta thấy được bốn cấp độ khác nhau của kiểm thử tương ứng với
bốn giai đoạn khác nhau trong quá trình phát triển phần mềm.
Kiểm thử đơn vị: Là cấp độ thấp nhất của kiểm thử trong V-model. Trong kiểm
thử đơn vị các đặc tả kiểm thử sẽ được xây dựng dựa trên thiết kế chi tiết của hệ thống.
Mục đích chính của kiểm thử đơn vị là tìm ra các lỗi về mặt lập trình, các lỗi dữ liệu,
lỗi xử lý logic của từng chức năng trong SUT.
Kiểm thử tích hợp: Trong kiểm thử tích hợp đặc tả kiểm thử được xây dựng dựa
trên thiết kế hệ thống. Mục đích của kiểm thử tích hợp giống như tên gọi là tìm ra các
lỗi về liên kết giữa các thành phần, các chức năng trong SUT.
Kiểm thử hệ thống: Mục đích của kiểm thử hệ thống là xem xét toàn bộ hệ
thống đã được xây dựng nên có thực hiện đúng theo đặc tả hệ thống được đưa ra từ ban
đầu hay không.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B

Luận văn thạc sỹ

14

Kiểm thử chấp nhận: Mục tiêu của kiểm thử chấp nhận là xác minh lại tính đúng
đắn của hệ thống so với nhu cầu thực tế. Ngoài ra kiểm thử chấp nhận còn đánh giá
xem hệ thống có sẵn sàng để đưa vào triển khai và sử dụng hay không.
Ta có thể nhận thấy rằng kiểm thử chấp nhận chính là quá trình thẩm định
(validation) còn kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống là quá trình
kiểm chứng (verification) ứng với định nghĩa đã nêu trên.
1.1.2.2 Tích hợp quy trình kiểm thử trong kỹ nghệ hệ thống.
Ta có ba cách thức cơ bản để tích hợp quy trình kiểm thử trong phát triển hệ
thống. Đó là: (a) Kiểm thử sau khi phát triển, (b) thực hiện kiểm thử và phát triển hệ
thống song song với nhau, và (c) bắt đầu bằng việc kiểm thử (test-driven development).
Hình sau sẽ thể hiện ba cách thức này.
Yêu cầu

Yêu cầu

Phát triển hệ
thống

Kiểm thử hệ
thống
(a) Phương pháp
kiểm thử sau
phát triển

Kiểm thử hệ
thống

Yêu cầu

Phát triển hệ
thống

Kiểm thử hệ
thống

(b) Phương pháp song
song

Phát triển hệ
thống
(c) Phương kháp
kiểm thử trước
phát triển

Hình 1-3: Ba phương pháp cơ bản tích hợp kiểm thử vào kỹ nghệ hệ thống
Kiểm thử sau phát triển hệ thống: Phương pháp này chính là công việc thường
ngày của kiểm thử viên. Người phát triển hệ thống tạo ra hoặc chỉnh sửa các thành
phần, sau đó thì kiểm thử viên sẽ thẩm định SUT. Với phương pháp này, kiểm thử
được tiến hành sau khi SUT được tạo ra và SUT phải được điều chỉnh lại nếu kiểm thử
phát hiện ra thất bại trong SUT. Những thất bại này thường do việc thiếu đầy đủ hoặc
sai khác so với yêu cầu. Đối với phương pháp này thì việc thay đổi yêu cầu sau giai
đoạn triển khai sẽ dẫn đến việc tăng cao về chi phí. [3]

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B

Luận văn thạc sỹ

15

Kiểm thử và phát triển hệ thống song song với nhau: Thực tế cho thấy thời
gian dành cho kiểm thử rất hạn chế, vì vậy ta thường mong muốn có thể bắt đầu việc
kiểm thử càng sớm càng tốt. Việc xây dựng các bộ kiểm thử và SUT đồng thời nhằm
phục vụ cho mục đích: hệ thống được kiểm thử ngay khi có thể. Với phương pháp này,
sai sót được phát hiện sớm hơn, kéo theo người quản lý dự án có thể đưa ra được xử lý
sớm hơn phương pháp (a), tuy nhiên vấn đề sai sót về yêu cầu được tìm ra sau khi triển
khai vẫn còn tồn tại nên phương pháp này vẫn đòi hỏi chi phí lớn. [3]
Phát triển hệ thống dựa trên kiểm thử (kiểm thử trước phát triển): Là phương
pháp mà các ca kiểm thử được tạo ra trước khi bắt đầu triển khai hệ thống. Do đó ca
kiểm thử sẽ thất bại trước tiên, và nhiệm vụ của việc phát triển hệ thống là làm sao có
thể vượt qua được các ca kiểm thử. Khi ta viết ra việc kiểm thử trước khi triển khai thì
số lượng thay đổi cần thiết của yêu cầu trong pha triển khai sẽ được giảm xuống. Tuy
nhiên điều này có thể kéo theo việc các SUT sẽ chỉ được triển khai với mục tiêu là
tránh việc phát hiện ra thất bại. [3]

1.2 Tổng quan về kiểm thử hướng mô hình
1.2.1 Khái niệm về kiểm thử hướng mô hình
Kiểm thử hướng mô hình thường mang nghĩa kiểm thử chức năng với các đặc tả
kiểm thử được đựa trên một mô hình kiểm thử. Mô hình kiểm thử được bắt nguồn từ
các yêu cầu của hệ thống. Chỉ có một số ít các phương pháp sử dụng kiểm thử hướng
mô hình cho việc kiểm thử phi chức năng. Trong kiểm thử hướng mô hình, các bộ
kiểm thử được đưa ra một cách tự động (hoặc bán tự động) từ các mô hình kiểm thử.
Kiểm thử hướng mô hình có thể được áp dụng tại tất cả các cấp độ kiểm thử từ kiểm
thử đơn vị đến kiểm thử hệ thống.

Kiểm thử hướng mô hình được coi là một phương pháp hình thức gọn nhẹ để
kiểm chứng các hệ thống phần mềm. [8]
Kiểm thử hướng mô hình là một phương pháp hình thức vì nó tạo ra các đặc tả
kỹ thuật (hoặc mô hình) của SUT theo một cách thức xác định (có nghĩa là máy tính có
thể đọc được). Nó gọn nhẹ bởi vì, trái với phương pháp hình thức khác, kiểm thử
hướng mô hình không chú trọng vào toán học chứng minh rằng phần thực thi phù hợp
với đặc tả trong mọi trường hợp có thể. Những gì kiểm thử hướng mô hình làm là sinh
ra một bộ kiểm thử từ mô hình một cách có hệ thống, sau đó thực thi kiểm thử trên
SUT với việc tin rằng SUT sẽ thực hiện theo những gì mà mô hình thể hiện.
Sự khác nhau giữa phương pháp hình thức “gọn nhẹ” và “nặng nhọc” dựa trên
việc tin tưởng hay đảm bảo hoàn toàn. Sự đảm bảo hoàn toàn ở đây có thể hiểu là mức
độ áp dụng phương pháp này trong phát triển hệ thống sẽ đảm bảo hệ thống khi vận
hành sẽ cho ta kết quả giống hệt kết quả kiểm thử, đảm bảo rằng tất cả trường hợp có
thể xảy ra (với một mức độ nào đó và được chứng minh bằng các lý thuyết toán học) ta
đều đã kiểm soát được. Trong thực tế chi phí cần thiết cho sự đảm bảo hoàn toàn

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

16

thường rất đắt (đôi khi là cực kỳ đắt), vì vậy kiểm thử hướng mô hình sẽ là một phương
pháp linh hoạt hơn, thích hợp áp dụng cho các dự án chi phí thấp.
1.2.2 Cách thức làm việc của kiểm thử hướng mô hình
Kiểm thử hướng mô hình là kỹ thuật kiểm thử trước khi xây dựng phần thực thi.
Do đó các đặc tả kiểm thử và các ca kiểm thử được tạo ra trước khi ta xây dựng phần

mềm. Từ những ca kiểm thử này ta có thể đánh giá lại được tính đúng đắn của mô hình
cũng như của yêu cầu đầu vào và có những điều chỉnh phù hợp trong khi xây dựng
phần thực thi. Hình sau sẽ thể hiện cách thức làm việc của kiểm thử hướng mô hình.[8]
Yêu cầu
Phản hồi

Xây dựng
Mô hình

Phản hồi

Phản hồi
Sinh ra
Các ca kiểm thử
Đầu vào

Đầu ra mong
muốn

Vấn đề

Quyết định

OK

NG

Quan sát

Điều

khiển

Phần thực thi

Phản hồi

Hình 1-4: Cách thức vận hành của kiểm thử hướng mô hình
(NG: No good – trường hợp không thỏa mãn một yêu cầu nào đó)
Trong kiểm thử hướng mô hình, đầu tiên từ yêu cầu của hệ thống ta sẽ xây dựng
lên mô hình tương ứng. Từ mô hình này ta sẽ sinh ra các ca kiểm thử. Do mô hình
được xây dựng theo những chuẩn đặc tả xác định từ trước nên việc sinh ra các ca kiểm
thử này hoàn toàn có thể tự động hóa. Việc sinh ra các ca kiểm thử ngay tại giai đoạn
này cũng thể hiện tính chất của kiểm thử hướng mô hình là một phương pháp kiểm thử
trước khi phát triển. Ngoài ra từ mô hình xây dựng được ta có thể đưa lại các phản hồi,
các điểm bất hợp lý đến các yêu cầu của hệ thống để có những điều chỉnh hợp lý.
Từ các ca kiểm thử đã được sinh ra ta có thể xác định được những vấn đề của
mô hình cũng như của hệ thông trước khi phát triển, và từ đó có thể đưa ra các phản

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

17

hồi đến cả mô hình, yêu cầu ban đầu cũng như phần thực thi (bộ phận trực tiếp phát
triển hệ thống).
1.2.3 Ưu thế của kiểm thử hướng mô hình

Kiểm thử hướng mô hình đóng một vai trò quan trọng trong việc kiểm chứng
(verification) phần mềm hướng mô hình. Có rất nhiều ưu điểm của kiểm thử hướng mô
hình như sau:
 Thứ nhất, mô hình kiểm thử được sử dụng thường xuyên thường khá nhỏ, dễ
hiểu, dễ dàng bảo trì.
 Thứ hai, việc sử dụng các mô hình kiểm thử thường cho phép ta truy xuất nguồn
gốc từ yêu cầu đến ca kiểm thử.
 Thứ ba, kiểm thử hướng mô hình có thể được sử dụng cho kiểm thử sau khi phát
triển hệ thống tốt như phương pháp test-first (test-driven). Như đã đề cập đến trong
phần 1.1.2.2, các phương pháp kiểm thử trước khi phát triển sẽ giúp ta giảm được chi
phí, hơn nữa kinh nghiệm cho thấy rằng việc tạo ra các mô hình kiểm thử chính thức
cũng giúp ta tìm ra được các sai sót và mâu thuẫn trong yêu cầu.
 Thứ tư, cũng chính là ưu điểm mà đề tài tập trung vào: có thể sinh kiểm thử tự
động (automatic test generation) từ các mô hình. Tức là mô hình kiểm thử có thể được
sử dụng để tạo ra các bộ kiểm thử từ nhỏ đến rất lớn thỏa mãn một tiêu chuẩn tương
ứng một cách tự động. Điều này cho phép ta tạo ra đồng thời các bộ kiểm thử nhỏ, thực
hiện nhanh hoặc là các bộ kiểm thử lớn với lượng sai sót có thể phát hiện được lớn
hơn.
1.2.4 So sánh kiểm thử hướng mô hình và kiểm thử thông thường.
Trước tiên, kiểm thử thông thường (conventional testing) ở đây ta ngầm hiểu là
hai phương pháp: tạo kiểm thử thủ công hoặc tạo kiểm thử tự động dựa trên mã nguồn
(code-based test generation).
Trong nhiều công ty, kiểm thử được thiết kế thủ công bởi kiểm thử viên hoặc
bởi người phát triển, cả hai cách này đều có ưu – nhược điểm của nó. Tuy nhiên một
nhược điểm chung là chúng ta cần có một lượng chi phí cao cho việc tạo ra, thực hiện
và duy trì các bộ kiểm thử. Đồng thời ta không có cách truy xuất từ yêu cầu để ra ca
kiểm thử, và hệ quả của nó là với mỗi một thay đổi yêu cầu ta đều cần kiểm tra lại các
bộ kiểm thử một cách thủ công, điều này tạo ra một lượng chi phí lớn. Đối với kiểm
thử hướng mô hình, việc tạo ra mô hình kiểm thử ban đầu cũng tiêu tốn lượng chi phí
cao, tuy nhiên ngược lại với kiểm thử thủ công, chi phí cho việc duy trì kiểm thử trong

kiểm thử hướng mô hình lại thấp hơn nhiều do: Mô hình kiểm thử được tạo ra một
cách thích hợp một lần và sau đó toàn bộ bộ kiểm thử sẽ được sinh ra một cách tự
động. Ngoài ra, mô hình kiểm thử thường dễ hiểu hơn là bộ kiểm thử.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

18

Trong phương pháp sinh kiểm thử tự động dựa trên mã nguồn, mã nguồn của hệ
thống được kiểm thử theo hướng chức năng. Có rất nhiều thiết bị và mô hình kiểm tra
để chạy mã nguồn, từ đó cho phép tìm ra được sự thiếu nhất quán trong luồng điều
khiển và luồng dữ liệu (thường sẽ là nguyên nhân chính gây ra những hành vi không
mong muốn của hệ thống – ví dụ như hệ thống bị treo chẳng hạn). Do các thiếu sót
hoặc dư thừa của các đặc tả kiểm thử, kiểm thử hướng mã nguồn không phát hiện được
các sai sót chức năng cũng như phát hiện ra việc thiếu sót chức năng.
Ta đều thấy rằng chi phí cho việc kiểm thử sẽ tăng dần theo mức độ hoàn thành
của SUT. Việc sinh kiểm thử theo cách thủ công sẽ tốn nhiều chi phí, trong khi sinh
kiểm thử hướng mã nguồn có một hạn chế chính là việc kiểm thử chỉ có thể thực hiện
sau khi đã phát triển xong. Ngược lại, kiểm thử hướng mô hình cho phép tìm ra các sai
sót trước khâu phát triển. Việc tạo ra các mô hình thử nghiệm chính thức và thống nhất
sẽ giúp cho việc phát hiện những mâu thuẫn trong bản thân đặc tả yêu cầu.
1.2.5 Khả năng ứng dụng kiểm thử hướng mô hình trong phát triển ứng dụng
cho điện thoại di động thông minh
1.2.5.1 Đặc trưng của việc phát triển ứng dụng trên điện thoại di động thông minh
Qua quá trình làm việc thực tế của tác giả trong lĩnh vực phát triển ứng dụng nói

chung và trò chơi nói riêng cho điện thoại di động thông minh, tác giả nhận thấy việc
phát triển ứng dụng cho điện thoại di động thông minh tại Việt Nam có những đặc
trưng sau:
 Môi trường phát triển và môi trường ứng dụng là hoàn toàn khác nhau: Đây là
đặc điểm chung của việc phát triển ứng dụng cho điện thoại di dộng thông minh, khi
mà môi trường phát triển ứng dụng là máy tính cá nhân (hệ điều hành window hoặc
OSX) trong khi ứng dụng thực tế được cài đặt và sử dụng trên điện thoại di động thông
minh (hệ điều hành phổ biến hiện nay là Android và iOS). Vì vậy việc kiểm thử thực tế
đều tập trung vào việc quan sát hành vi của ứng dụng trên thiết bị thật một cách thủ
công.
 Ngôn ngữ lập trình cố định: Đối việc phát triển ứng dụng trên điện thoại di động
hiện nay, ngôn ngữ sử dụng phổ biến trên Android là Java, trên iOS là ObjC và Swift.
Các ngôn ngữ lập trình khác sẽ gặp nhiều hạn chế khi phát triển các ứng dụng trên điện
thoại di động thông minh. Hiện nay đã có nhiều công cụ phát triển không phụ thuộc
vào nền tảng ứng dụng (cross-platform) sử dụng các ngôn ngữ lập trình khác (phổ biển
là C# với Unity, Xamarin), tuy nhiên trong nhiều trường hợp ta vẫn cần sử dụng Java
với Android (hoặc ObjC, Swift với iOS) để có thể thực hiện được các chức năng cần
thiết và tích hợp vào trong công cụ phát triển đã nêu.
 Thời gian phát triển ngắn (2 đến 6 tháng): Trên thực tế các ứng dụng trên điện
thoại di động thông minh cũng có thể chia ra nhiều mức độ phụ thuộc vào chi phí, quy

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

19

mô, thời gian phát triển. Tuy nhiên thực tế cho thấy tại Việt Nam, số lượng các ứng
dụng phát triển trong thời gian ngắn (từ 2 đến 6 tháng) chiếm đa số. Kéo theo đó chi
phí cho việc phát triển các ứng dụng này thường hạn chế và điều này khiến công đoạn
kiểm thử thường bị coi nhẹ để đảm bảo lợi nhuận.
1.2.5.2 Khả năng áp dụng kiểm thử hướng mô hình trong phát triển ứng dụng cho
điện thoại di động thông minh
Mức độ phù hợp:
Như đã trình bày ở trên (mục 1.2.1), kiểm thử hướng mô hình là một phương
pháp kiểm thử gọn nhẹ để kiểm thử hệ thống. Ta thấy rằng kiểm thử hướng mô hình
không tập trung vào việc đảm bảo hoàn toàn ứng dụng sẽ phù hợp với đặc tả trong mọi
trường hợp có thế. Trên thực tế do đặc điểm đầu tiên của việc phát triển ứng dụng trên
điện thoại di động thông minh thì việc đảm bảo hoàn toàn gần như là không khả thi.
Trái lại, tính chất “gọn nhẹ” của kiểm thử hướng mô hình lại hoàn toàn thích hợp với
đặc điểm trên. Xét trên một khía cạnh nào đó, khi phát triển ứng dụng cho điện thoại di
động thông minh, ta tin rằng việc phát triển trên nền tảng phát triển sẽ cho ta kết quả
trên nền tảng ứng dụng là tương đồng nhau.
Kiểm thử hướng mô hình đòi hỏi việc xây dựng mô hình theo một cách thức xác
định (để máy tính có thể đọc được). Điều này rất dễ áp dụng vào phát triển ứng dụng
cho điện thoại di động thông minh khi ngôn ngữ lập trình cho các ứng dụng này là cố
định (Java, ObjC, Swift, hoặc C# đối với công cụ không phụ thuộc nền tảng).
Ngoài ra, do tính “gọn nhẹ” của kiểm thử hướng mô hình đem lại cho chúng ta
một phương pháp kiểm thử hứa hẹn tiết kiệm chi phí, điều này phù hợp với đặc điểm
đa phần các ứng dụng trên điện thoại di động thông minh là những ứng dụng phát triển
trong thời gian ngắn, chi phí thấp.
Các hạn chế:
Tuy nhiên, kiểm thử hướng mô hình khi áp dụng vào phát triển ứng dụng trên
điện thoại di động thông minh cũng có những rào cản và hạn chế nhất định.
Trước hết cũng chính do đặc điểm đầu tiên của việc phát triển ứng dụng trên
điện thoại di động thông minh mà việc tự động hóa khi áp dụng kiểm thử hướng mô
hình sẽ gặp nhiều hạn chế.

Sau đó, do hạn chế về số lượng ngôn ngữ lập trình để phát triển ứng dụng kéo
theo việc lựa chọn công cụ hỗ trợ kiểm thử hướng mô hình trong phát triển ứng dụng
trên điện thoại di động thông minh sẽ gặp nhiều khó khăn. Trên thế giới hiện nay có
nhiều công cụ hỗ trợ kiểm thử hướng mô hình, tuy nhiên không phải công cụ nào cũng
có thể áp dụng trong phát triển ứng dụng cho điện thoại di động thông minh. Ta sẽ tìm
hiểu sơ qua về các công cụ đó trong phần sau.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

20

1.2.6 Giới thiệu một số công cụ miễn phí hỗ trợ kiểm thử hướng mô hình
1.2.6.1 fMBT
Đây là công cụ do OTC (Intel Open Source Technology Center) nghiên cứu và
phát triển. Công cụ này sử dụng AAL (Adapter Action Language) kết hợp cùng với
một ngôn ngữ lập trình khác (hiện tại hỗ trợ hai ngôn ngữ lập trình chính là C++,
Python) để xây dựng mô hình cũng như phát triển ứng dụng.[11]
Ưu điểm:
 Có thể cài đặt và chạy trên cả môi trường Linux (bao gồm cả Ubuntu và Fedora)
và window.
 Do việc kết hợp AAL với một ngôn ngữ lập trình như C++, Python nên việc xây
dựng mô hình dễ tiếp cận và nắm bắt đối với lập trình viên.
 Được Intel ứng dụng thử nghiệm trên các hệ thống khác nhau nên tính tin cậy và
hiệu quả của công cụ này đã được kiểm chứng.
 Có hỗ trợ kiểm thử hướng mô hình trên Android.

Hạn chế:
 Ngôn ngữ lập trình được hỗ trợ hiện tại là C++ và Python, hai ngôn ngữ lập
trình này không thích hợp cho việc phát triển ứng dụng trên điện thoại di động thông
minh.
1.2.6.2 TorX
TorX là một công cụ do nhóm nghiên cứu về các công cụ và phương pháp hình
thức (Formal Methods and Tools) tại trường UT (University of Twente) của Hà Lan
đưa ra. Công cụ này hỗ trợ rất nhiều ngôn ngữ mô hình hóa (ngôn ngữ để mô tả mô
hình) khác nhau để xây dựng mô hình. Ngôn ngữ lập trình được hỗ trợ chính là C++ và
Java. [12]
Ưu điểm:
 Có thể cài đặt trên cả môi trường Linux (đặc biệt là có thể cài đặt trên OSX) và
window.
 Hỗ trợ nhiều ngôn ngữ mô hình hóa như: Aldebaran, GraphML, GraphViz,
Jararaca, FSP, …
 Hỗ trợ ngôn ngữ lập trình Java và kiểm thử hướng mô hình trên Android.
Nhược điểm:
 Giao diện đồ họa còn đơn giản và khó sử dụng.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

21

 Ngôn ngữ mô hình hóa độc lập với ngôn ngữ lập trình nên khó nắm bắt hơn đối
với lập trình viên.

1.2.6.3 Spec Explorer
Spec Explorer là công cụ hỗ trợ kiểm thử hướng mô hình do Microsoft phát triển
và tích hợp vào trong Visual studio. Công cụ này sử dụng Cord Scripting Language kết
hợp với C# để xây dựng mô hình. Ngôn ngữ lập trình được hỗ trợ là C#. [6]
Ưu điểm:
 Được tích hợp cùng với Visual studio (là một bộ công cụ lập trình đầy đủ do
Microsoft phát triển).
 Ngôn ngữ mô hình hóa sử dụng Cord Scripting Language kết hợp với C# nên dễ
tiếp cận với lập trình viên.
 Hỗ trợ ngôn ngữ lập trình C# nên hứa hẹn khả năng kết hợp với các công cụ
phát triển ứng dụng cho điện thoại di động thông minh không phụ thuộc nền tảng
(Unity, Xamarin).
 Giao diện đồ họa trực quan, dễ sử dụng.
Nhược điểm:
 Chỉ cài đặt được trên window và đi cùng với Visual studio.
 Ngôn ngữ lập trình hỗ trợ là C# mà đây không phải là ngôn ngữ mà bản thân các
nền tảng điện thoại di động thông minh hỗ trợ. Do đó cần phải kết hợp với các công cụ
không phụ thuộc nền tảng khác.
Do đặc điểm dễ sử dụng, dễ tiếp cận đối với lập trình viên đồng thời hứa hẹn khả
năng kết hợp cùng các công cụ phát triển không phụ thuộc nền tảng cho điện thoại di
động thông minh khác (Unity, Xamarin) nên đề tài sẽ lựa chọn spec explorer làm công
cụ để áp dụng kiểm thử hướng mô hình vào phát triển ứng dụng cho điện thoại di động
thông minh.

1.3 Kết chương
Chương 1 đã trình bày được:
 Về kiểm thử nói chung
 Các định nghĩa cơ bản về kiểm thử nói chung
 Một số quy trình kiểm thử cơ bản
 Về kiểm thử hướng mô hình

 Đưa ra khái niệm cơ bản về kiểm thử hướng mô hình
 Tìm hiểu cách thức hoạt động của kiểm thử hướng mô hình
 So sánh kiểm thử hướng mô hình với kiểm thử thông thường

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

22

 Đánh giá khả năng áp dụng kiểm thử hướng mô hình vào phát triển ứng dụng
cho điện thoại di động thông minh.
 Giới thiệu và so sánh một số công cụ miễn phí hỗ trợ kiểm thử hướng mô hình
Từ đó ta có những cái nhìn tổng quan sau:
 Kiểm thử là một quá trình quan trọng, có thể được ứng dụng trong bất kỳ khâu
nào của quá trình phát triển hệ thống.
 Có nhiều phương pháp áp dụng các kỹ thuật kiểm thử trong quá trình phát triển
hệ thống, trong đó cần kể đến phương pháp “Test-driven System Development” là
phương pháp xây dựng ca kiểm thử trước khi phát triển hệ thống thực thi.
 Kiểm thử hướng mô hình là một trong những phương pháp “Test-driven System
Development” với việc kiểm thử được sinh ra dựa trên mô hình.
 Kiểm thử hướng mô hình cho phép ta tự động hóa quá trình kiểm thử.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B

Luận văn thạc sỹ

23

Chương 2. SỬ DỤNG CÔNG CỤ SPEC EXPLORER ĐỂ SINH
CÁC CA KIỂM THỬ TỰ ĐỘNG
2.1 Đặt vấn đề
Trong phần trên ta đã tìm hiểu được tổng quan và những kiến thức chung nhất
về kiểm thử và kiếm thử hướng mô hình. Sang phần này ta sẽ đi vào tìm hiểu một công
cụ (tool) cụ thể dựa trên kiểm thử hướng mô hình để tự động sinh ra các ca kiểm thử
(và có thể là cả test code, đồng nghĩa với việc ta có thể thực thi quy trình kiểm thử
hoàn toàn tự động).
Công cụ mà đề tài lựa chọn tìm hiểu là Spec Explorer do Microsoft phát triển và
được phát hành hoàn toàn miễn phí khi đi kèm với visual studio. Bộ công cụ này được
xây dựng dựa trên ngôn ngữ lập trình C# và Cord Scripting Language giúp ta có thể
xây dựng mô hình, liên kết với phần thực thi (SUT) và sinh ra các ca kiểm thử. Ở đây
ta sẽ tập trung vào việc sinh ra các ca kiểm thử dựa trên mô hình một cách tự động.
Về mặt bản chất, kiểm thử hướng mô hình cho phép ta có thể tự động hóa quá
trình kiểm thử từ việc sinh ra ca kiểm thử cho đến việc tự động chạy ứng dụng và đưa
ra kết quả kiểm thử khi chạy ứng dụng đó. Tuy nhiên, do đặc muốn kiểm thử ứng dụng
một các tự động đòi hỏi chúng ta phải xây dựng một bộ mã tương thích (adapter) hay
mã kiểm thử và dựa vào đó để xây dựng ứng dụng. Với đặc thù của ứng dụng di động,
nền tảng của ứng dụng hoàn toàn khác với nền tảng phát triển nên việc tích hợp kiểm
thử tự động cả mã nguồn còn nhiều vấn đề nan giải. Vì vậy, ở đây chúng ta sẽ chỉ tìm
hiểu về cách sinh các ca kiểm thử tự động, một bước mà ta sẽ tiết kiệm được chi phí
sản xuất mà đạt hiệu quả cao.
Trước hết ta sẽ tìm hiểu về khái niệm cơ bản trong cơ sở lý thuyết mà spec
explorer dựa vào là chương trình mô hình (model program) và máy mô hình tự động
(model automata) cùng những khái niệm liên quan khác.

2.2 Cơ sở lý thuyết áp dụng trong spec explorer
Ta gọi tập hợp tất cả các khái niệm, các thuật ngữ được sử dụng để xây dựng
nên cơ sở lý thuyết của spec explorer là tập từ vựng . Trước hết ta sẽ đi vào khái niệm
trạng thái (state) là khái niệm đầu tiên ta cần tìm hiểu trong .
2.2.1 Trạng thái (state)
Một trạng thái s là một cấu trúc bậc một trong mà miền giá trị của nó (được ký
hiệu là U) được giả định là cố định đối với tất cả các trạng thái. Các ký hiệu từ vựng
tương ứng là các ký hiệu chức năng (funcion symbol), trong đó mỗi ký hiệu hàm đều
có một số lượng tham số (arity) và cách diễn giải trong s. Cách diễn giải của một số ký

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

24

hiệu trong đối với các trạng thái khác nhau có thể khác nhau. Những ký hiệu chức
năng mà diễn giải của chúng có thể thay đổi được gọi là các biến trạng thái (state
variables) hoặc các hàm động (dynamic fucntions). Tập hợp các biến trạng thái được
ký hiệu là V. Bất kỳ phần tử cơ sở nào thuộc
đều có diễn giải giống nhau đối với
tất cả các trạng thái.
Với một cấu trúc bậc một s trong và một bộ từ vựng
, ta ký hiệu
{
} (tập hợp tất cả s|V

biểu thị cho thể hiện của s trong V. Ta ký hiệu:
sao cho
).
Một biểu thức phụ thuộc trạng thái (state based expression) E là một phần tử
thuộc có thể (một cách logic) chứa các biến. Nếu E không chứa biến nào (một cách
logic) ta nói E suy biến về mức đơn vị (ground) hoặc E đóng. Nếu E chứa tất cả các
biến trong số các biến
, ta ký hiệu là [ ] , và các phần tử đóng
ta viết [ ] ký hiệu cho biểu tức đóng sau khi thay thế từng trong E bởi
với toàn bộ
[
]. Giá trị của biểu thức đóng phụ thuộc trạng thái E trong trạng thái
{
}.
s được ký hiệu là E(s). Ta viết
2.2.2 Máy tạo mô hình tự động (model automata)
Định nghĩa 16: Một máy tạo mô hình tự động (model automaton) M bao gồm
các thành phần sau [7]:
 Một tập hợp S các trạng thái trong , trong đó chứa một tập từ vựng hữu
hạn V của các biến trạng thái và hàm động.
 Một tập hợp con không rỗng
của S được gọi là các trạng thái khởi tạo.
 Một tập hợp con
của S được gọi là các trạng thái chấp nhận (accepting
states)
 Một tập hợp Acts của các hành động là những phần tử đơn vị trong
.
Acts được chia thành hai phần độc lập là tập hợp các hành động có thể kiểm
soát được (controllable action) Ctrl và tập hợp các hành động có thể quan sát
được (observable action) Obs.

 Một quan hệ chuyển tiếp
M được gọi là xác định nếu bất kỳ trạng thái s và hành động a có ít nhất một
trạng thái t thỏa mãn
, trong trường hợp này ta viết
. Ở đây ta
chỉ xem xét các máy tạo mô hình xác định.
Đối với một trạng thái cho trước
, ta có Acts(s) biểu thị cho tập hợp tất cả
các action
sao cho
, với ít nhất một t nào đó. Ta nói rằng a được
kích hoạt trong trạng thái s. Ta có
và
. Thông thường ta sẽ ký hiệu M bởi một bộ
.

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B


Luận văn thạc sỹ

25

Định nghĩa 17: Một máy tạo mô hình tự động M là một máy tự động con của
máy tạo mô hình tự động N (ký hiệu là
) nếu các điều kiện sau đều được thỏa
mãn [7]:
,

,
,
,
,
.
Để xác định một thành phần của một model automaton M, đôi khi ta lập chỉ số các
thành phần của M, trừ khi M đã rõ ràng về mặt ngữ cảnh. Khi điều kiện cho phép, ta
biểu diễn M bởi một bộ (Sinit, S, Sacc, Obs, Ctrl, δ).
Định nghĩa 18: Cho một máy tự động M và một tập từ vựng
, ta viết
biểu thị cho một máy tự động N, được gọi là suy biến của M trên V như sau [7]:



|
|
là tập hợp của tất cả các hành động a thuộc
phần tử thuộc V
{
}


sao cho a là một

M được gọi là mở rộng của N.
Một suy biến của một máy tự động cho một tập con của tập hợp các biến trạng
thái có thể rút gọn từ nhiều trạng thái thành một trạng thái. Vì vậy phép chiếu này
không phải lúc nào cũng đảm bảo tính xác định của máy tự động. Do đó, để đảm bảo
tính xác định của máy tự động, phép chiếu này thường ít được sử dụng.
2.2.3 Chương trình mô hình (model program)

Một chương trình mô hình P khai báo một tập hữu hạn M của các phương thức
hành động (action method) và một tập hợp các biến trạng thái V. Một trạng thái của P
được biểu thị bởi các giá trị (hoặc diễn giải) của các ký hiệu từ vựng trạng thái trong
xuất hiện trong chương trình mô hình. Giá trị của biến trạng thái trong
có thể
thay dổi do kết quả của việc thực thi chương trình. Trong đó ta có thể đưa ra các ví dụ
đại diện sau: các ký hiệu chức năng có diễn giải không đổi ứng với những phép toán có
sẵn, các cấu trúc dữ liệu; một biến trạng thái không tham số là một biến bình thường
(hoặc biến tĩnh – static) mà giá trị có thể được cập nhật; một biến trạng thái đơn tham
số (có một tham số) có thể là một tham chiếu đến một trường bên trong của một lớp
(thông qua đối tượng là thể hiện – instance của lớp đó đã được tạo ra trong quá trình
chương trình vận hành).
Trong phương thức hành động m, với các biến x được coi là tham số hình thức
đầu vào của m, được liên kết chặt chẽ với một biểu thức logic phụ thuộc vào trạng thái
[ ] (được gọi là điều kiện tiền dề của m). Việc thực thi của m trong một trạng thái
s với một bộ tham số thực tế v sẽ tạo ra một trạng thái tiếp theo nơi mà một số biến
trạng thái có thể đã được thay đổi. Thông thường việc thực thi của m có thể đồng thời
thực hiện các công việc khác (ví dụ như ghi dữ liệu vào tập tin – file, hiển thị hộp thoại
cho người dùng) nhưng theo một các trừ tượng hóa ta xem xét m như một quy tắc cập

Ngô Hoàng Thành

Lớp 12BCNTT2 – Khóa 2012B