Nghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúng (Luận văn thạc sĩ)

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
---------------------------------------

PHẠM THỊ NGỌC

NGHIÊN CỨU KỸ THUẬT KIỂM THỬ TỰ ĐỘNG DỰA TRÊN
MÔ HÌNH, ÁP DỤNG TRONG HỆ THỐNG NHÚNG

LUẬN VĂN THẠC SĨ KỸ THUẬT
(Theo định hướng ứng dụng)

HÀ NỘI - 2018


HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
---------------------------------------

PHẠM THỊ NGỌC

NGHIÊN CỨU KỸ THUẬT KIỂM THỬ TỰ ĐỘNG
DỰA TRÊN MÔ HÌNH, ÁP DỤNG TRONG HỆ THỐNG NHÚNG

Chuyên ngành: Hệ thống thông tin
Mã số: 8.48.01.04

NGƯỜI HƯỚNG DẪN KHOA HỌC : TS. ĐỖ THỊ BÍCH NGỌC

HÀ NỘI - 2019


i

LỜI CAM ĐOAN
Tôi cam đoan luận văn thạc sĩ “Nghiên cứu kỹ thuật kiểm thử tự động dựa
trên mô hình, áp dụng trong hệ thống nhúng” là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai
công bố trong bất kỳ công trình nào khác. Tất cả những tham khảo và kế thừa đều
được trích dẫn và tham chiếu đầy đủ.
Tác giả luận văn


ii

MỤC LỤC
LỜI CAM ĐOAN…………………………………………………………………………..i
MỤC LỤC ............................................................................................................................ 1
DANH MỤC HÌNH VẼ ...................................................................................................... iii
MỞ ĐẦU ............................................................................................................................... 1
Chương 1 – TỔNG QUAN VỀ HỆ THỐNG NHÚNG ..................................................... 3
VÀ KIỂM THỬ TRONG HỆ THỐNG NHÚNG. ........................................................... 3
1.1. Hệ thống nhúng ....................................................................................................... 3
1.2. Đặc điểm của hệ thống nhúng ................................................................................. 4
1.2.1. Giao diện .......................................................................................................... 4
1.2.2. Thiết bị ngoại vi ............................................................................................... 5
1.2.3. Công cụ phát triển ............................................................................................ 5
1.2.4. Độ tin cậy ......................................................................................................... 6
1.2.5. Xu hướng phát triển của các hệ thống nhúng .................................................. 6
1.2.6. Những thách thức và vấn đề còn tồn tại với hệ thống nhúng .......................... 7
1.3. Lý thuyết kiểm thử .................................................................................................. 8
1.3.1. Mục tiêu kiểm thử ............................................................................................ 8
1.3.2. Nguyên tắc kiểm thử ........................................................................................ 9

1.3.3. Nội dung các nhiệm vụ trong quá trình kiểm thử .......................................... 10
1.4. Kiểm thử tự động .................................................................................................. 12
Kiểm thử tự động ........................................................................................... 12
Ưu điểm và nhược điểm................................................................................. 12
Tầm quan trọng của kiểm thử tự động. .......................................................... 13
Chương 2-PHƯƠNG PHÁP KIỂM THỬ DỰA TRÊN MÔ HÌNH.............................. 15
2.1. Kiểm thử dựa trên mô hình ................................................................................... 15
2.1.1. Kiểm thử dựa trên mô hình ............................................................................ 15
2.1.2. Quy trình kiểm thử dựa trên mô hình ............................................................ 16
2.1.3. Thuận lợi và khó khăn của kiểm thử dựa trên mô hình ................................. 19
2.2. Các vấn đề của quá trình kiểm thử dựa trên mô hình ........................................... 20
2.3. Lập mô hình cho hệ thống ..................................................................................... 31
2.3.1. Mô hình kiểm thử trong Simulink ................................................................. 32
2.3.2. Yêu cầu/ đặc tả của mô hình .......................................................................... 33
2.3.3. Tạo ca kiểm thử từ mô hình ........................................................................... 35
2.3.4. Đánh giá mức phủ của test case ..................................................................... 35
Chương 3 - THỬ NGHIỆM VÀ ĐÁNH GIÁ .................................................................. 39
3.1. Cài đặt Matlab & Simulink toolbox ...................................................................... 39
3.2. Áp dụng kiểm thử dựa trên mô hình vào bài toán kiểm thử mô hình điều khiển
hành trình ......................................................................................................................... 40
3.2.1. Xây dựng mô hình trong Matlab.................................................................... 40
3.2.2. Sinh ca kiểm thử và thực thi và kết quả kiểm thử ......................................... 45
Chương 4 – KẾT LUẬN.................................................................................................... 51
TÀI LIỆU THAM KHẢO ................................................................................................. 52


iii

DANH MỤC HÌNH VẼ
Hình 1.1:

Bản kế hoạch chính và bản kế hoạch chi tiết ........................................ 11

Hình 2.1:

Phân loại quá trình kiểm thử dựa trên mô hình .................................... 21

Hình 2.2: Ví dụ một mô hình cơ bản bao gồm các khối thử nghiệm tuần tự, kiểm
tra dữ liệu và kiểm tra quản lý. ................................................................................. 33
Hình 2.3:

Ví dụ sơ đồ khối hệ thống truyền lực ................................................... 34

Hình 2.4:

Sơ đồ mô hình hóa và kết quả mô phỏng động cơ truyền động ........... 34

Hình 3.1:

Sơ đồ khối của hệ thống điều khiển hành trình cho hệ thống ô tô. ...... 41

Hình 3.2:

Mô hình lực cân bằng xe ô tô ............................................................... 42

Hình 3.3:

Chi tiết khối Cruise control................................................................... 45

Hình 3.4:

Cơ sở dữ liệu kiểm thử ......................................................................... 46

Hình 3.5:

Nhập file dữ liệu đầu vào ...................................................................... 47

Hình 3.6:

Tạo file dữ liệu cơ sở từ 1 ca kiểm thử ................................................. 48

Hình 3.7:

So sánh kết quả với đường cơ sở baseline ............................................ 48

Hình 3.8:

Độ dốc của đường tăng giảm với biên độ nhỏ ...................................... 49

Hình 3.9:

Vận tốc của xe khi độ dốc thay đổi với biên độ nhỏ ............................ 49

Hình 3.10:

Độ dốc của đường tăng giảm với biên độ lớn ................................... 50

Hình 3.11:

Vận tốc của xe khi độ dốc đường lớn................................................ 50

1

MỞ ĐẦU
Xuất hiện từ những năm đầu thập niên 1960, hệ thống nhúng đang dần trở
thành một ngành phát triển mạnh mẽ trong lĩnh vực công nghệ thông tin (CNTT),
với những ứng dụng rộng rãi trong công nghiệp và đời sống.
Sự tăng trưởng của hệ thống nhúng trong ngành công nghiệp dẫn tới một quá
trình phát triển công nghệ dựa trên mô hình (model based), mang lại nhiều thuận lợi
cho sự phát triển của công nghệ tự động. Các kỹ thuật dựa trên mô hình như
MATLAB/ Simulink, Statemate, MatrixX hoặc LabView là những công cụ cụ thể
và có cơ chế mạnh mẽ nhằm hỗ trợ xử lý các tín hiệu liên tục và các loại dữ liệu
quan trọng nhất trong lĩnh vực điều khiển tự động. Những công nghệ dựa trên mô
hình này cho phép phát triển các mô hình một cách chi tiết và có thể được sử dụng
để mô phỏng các giai đoạn phát triển.
Sự phát triển của hệ thống nhúng kéo theo những yêu cầu phát triển của hoạt
động kiểm thử. Thông thường, cách phổ biến để kiểm thử cho hệ thống nhúng nói
chung là chạy giả lập phần cứng trên phần mềm mô phỏng. Kiểm thử tự động là
một giải pháp hữu hiệu nhằm nâng cao tính chính xác và hiệu quả, cũng như giảm
kinh phí và rút ngắn thời gian trong quá trình kiểm thử các sản phẩm phần mềm nói
chung và các hệ thống nhúng nói riêng. Kiểm thử dựa trên mô hình đang được xem
là một phương pháp kiểm thử có khả năng tự động hóa cao.
Kiểm thử dựa trên mô hình là một phương pháp kiểm thử, trong đó 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ử.
Ngoài ra,việc đảm bảo chất lượng dựa trên phát triển mô hình, đặc biệt là thử
nghiệm, vẫn còn ít được hỗ trợ. Trong luận văn này, chúng ta thảo luận các đặc tính
của quy trình phát triển dựa trên mô hình cho hệ thống nhúng, đánh giá sự cần thiết
và hiệu quả của việc kiểm thử trong thực tế.
Đặc biệt hệ thống nhúng yêu cầu cao về chất lượng, cần kiểm thử ngay từ mô

hình, việc mô hình hóa & mô phỏng hệ thống nhúng được sử dụng khi hệ vật lý
không tồn tại, tốn thời gian hoặc chi phí để xây dựng, cho phép quan sát quá trình,
đáp ứng động của hệ thống trước khi thực nghiệm trên thiết bị thực, đây chính là


2

công cụ hữu hiệu cho việc thiết kế, nghiên cứu, với chi phí thấp, có thể dễ dàng thay
đổi.
Các công cụ mô hình hoá (như Simulink) hay được dùng để thiết kế các hệ
thống nhúng. Simulink được tích hợp vào Matlab như một công cụ để mô phòng hệ
thông, giúp người sử dụng phân tích và tổng hợp hệ thống một cách trực quan.
Trong Simulink, hệ thống được mô tả dưới dạng sơ đồ khối. Với dạng sơ đồ khối
này, ta có thể quan sát các đáp ứng thời gian của hệ thống với nhiều tín hiệu vào
khác nhau như: tín hiệu bậc thang, tín hiệu sinus, xung chữ nhật, tín hiệu ngẫu
nhiên,.. bằng cách thực hiện mô phỏng. Kết quả mô phỏng có thể được xem theo
thời gian thực trong môi trường Simulink hoặc Matlab. Tất cả các hàm trong Matlab
đều cố thể truy cập từ Simulink, và ngược lại, các kết quả tìm được trong Simulink
đều có thể sử dụng và khái thác trong mô trường Matlab.
Với mục đích tìm hiểu những kỹ thuật kiểm thử mới áp dụng vào hệ thống
nhúng, tôi nhận thấy việc nghiên cứu các phương pháp kiểm thử tự động dựa trên
mô hình trong hệ thống nhúng là một vấn đề rất cần thiết hiện nay.
Luận văn sẽ được cấu trúc với các chương như sau:
Chương 1 : Tổng quan về hệ thống nhúng và kiểm thử trong hệ thống nhúng.
Chương 2 : Phương pháp kiểm thử dựa trên mô hình hệ thống nhúng
Chương 3: Thử nghiệm và đánh giá
Luận văn sẽ khảo sát bài toán kiểm thử dựa trên mô hình áp dụng trong hệ
thống nhúng, đề xuất một phương pháp, một mô hình kiểm thử phù hợp với quy
trình hiện tại. Đồng thời phương pháp đề xuất sẽ được phân tích và đánh giá bằng
một số phương pháp đánh giá thông dụng trên tập dữ liệu đã có sẵn.

3

Chương 1 – TỔNG QUAN VỀ HỆ THỐNG NHÚNG
VÀ KIỂM THỬ TRONG HỆ THỐNG NHÚNG.
1.1. Hệ thống nhúng
Xuất hiện từ những năm đầu thập niên 1960, hệ thống nhúng đang dần trở
thành một ngành phát triển mạnh mẽ trong lĩnh vực công nghệ thông tin (CNTT),
với những ứng dụng rộng rãi trong công nghiệp và đời sống.
Hệ thống nhúng (embedded system) được định nghĩa là một hệ thống chuyên
dụng, thường có khả năng tự hành và được thiết kế tích hợp vào một hệ thống lớn
hơn để thực hiện một chức năng chuyên biệt nào đó.
Hệ thống nhúng là một thuật ngữ để chỉ một hệ thống có khả năng tự trị được
nhúng vào trong một môi trường hay một hệ thống mẹ. Đó là các hệ thống tích hợp
cả phần cứng và phần mềm phục vụ các bài toán chuyên dụng trong nhiều lĩnh vực
công nghiệp, tự động hoá điều khiển, quan trắc và truyền tin. Đặc điểm của các hệ
thống nhúng là hoạt động ổn định và có tính năng tự động hoá cao.
Hệ thống nhúng thường được thiết kế để thực hiện một chức năng chuyên
biệt. Khác với các máy tính đa chức năng, chẳng hạn như máy tính cá nhân, một hệ
thống nhúng chỉ thực hiện một hoặc một vài chức năng nhất định, thường đi kèm
với những yêu cầu cụ thể và bao gồm một số thiết bị máy móc và phần cứng chuyên
dụng mà ta không tìm thấy trong một máy tính đa năng nói chung. Vì hệ thống chỉ
được xây dựng cho một số nhiệm vụ nhất định nên các nhà thiết kế có thể tối ưu hóa
nó nhằm giảm thiểu kích thước và chi phí sản xuất. Các hệ thống nhúng thường
được sản xuất hàng loạt với số lượng lớn. Hệ thống nhúng rất đa dạng, phong phú
về chủng loại. Đó có thể là những thiết bị cầm tay nhỏ gọn như đồng hồ kĩ thuật số
và máy chơi nhạc MP3, hoặc những sản phẩm lớn như đèn giao thông, bộ kiểm soát
trong nhà máy hoặc hệ thống kiểm soát các máy năng lượng hạt nhân. Xét về độ
phức tạp, hệ thống nhúng có thể rất đơn giản với một vi điều khiển hoặc rất phức

tạp với nhiều đơn vị, các thiết bị ngoại vi và mạng lưới được nằm gọn trong một lớp
vỏ máy lớn.
Các thiết bị PDA hoặc máy tính cầm tay cũng có một số đặc điểm tương tự


4

với hệ thống nhúng như các hệ điều hành hoặc vi xử lý điều khiển chúng nhưng các
thiết bị này không phải là hệ thống nhúng thật sự bởi chúng là các thiết bị đa năng,
cho phép sử dụng nhiều ứng dụng và kết nối đến nhiều thiết bị ngoại vi.
1.2. Đặc điểm của hệ thống nhúng
Hệ thống nhúng thường có một số đặc điểm chung như sau:


Các hệ thống nhúng được thiết kế để thực hiện một số nhiệm vụ chuyên

dụng chứ không phải đóng vai trò là các hệ thống máy tính đa chức năng. Một số hệ
thống đòi hỏi ràng buộc về tính hoạt động thời gian thực để đảm bảo độ an toàn và
tính ứng dụng; một số hệ thống không đòi hỏi hoặc ràng buộc chặt chẽ, cho phép
đơn giản hóa hệ thống phần cứng để giảm thiểu chi phí sản xuất.


Một hệ thống nhúng thường không phải là một khối riêng biệt mà là một

hệ thống phức tạp nằm trong thiết bị mà nó điều khiển.


Phần mềm được viết cho các hệ thống nhúng được gọi là firmware và

được lưu trữ trong các chip bộ nhớ ROM hoặc bộ nhớ flash chứ không phải là trong

một ổ đĩa. Phần mềm thường chạy với số tài nguyên phần cứng hạn chế: không có
bàn phím, màn hình hoặc có nhưng với kích thước nhỏ, dung lượng bộ nhớ thấp.
Với những đặc điểm như trên, việc thử nghiệm, xác định lỗi trong hệ thống
nhúng gặp nhiều khó khăn. Số lượng trường hợp thử nghiệm lớn, đòi hỏi phải có
phương pháp và mô hình kiểm thử phù hợp.
1.2.1.

Giao diện

Các hệ thống nhúng có thể không có giao diện (đối với những hệ thống đơn
nhiệm) hoặc có đầy đủ giao diện giao tiếp với người dùng tương tự như các hệ điều
hành trong các thiết bị để bàn. Đối với các hệ thống đơn giản, thiết bị nhúng sử
dụng nút bấm, đèn LED và hiển thị chữ cỡ nhỏ hoặc chỉ hiển thị số, thường đi kèm
với một hệ thống menu đơn giản.
Còn trong một hệ thống phức tạp hơn, một màn hình đồ họa, cảm ứng hoặc
có các nút bấm ở lề màn hình cho phép thực hiện các thao tác phức tạp mà tối thiểu
hóa được khoảng không gian cần sử dụng. Ý nghĩa của các nút bấm có thể thay đổi
theo màn hình và các lựa chọn. Các hệ thống nhúng thường có một màn hình với


5

một nút bấm dạng cần điểu khiển (joystick button). Sự phát triển mạnh mẽ của
mạng toàn cầu đã mang đến cho những nhà thiết kế hệ nhúng một lựa chọn mới là
sử dụng một giao diện web thông qua việc kết nối mạng. Điều này có thể giúp tránh
được chi phí cho những màn hình phức tạp nhưng đồng thời vẫn cung cấp khả năng
hiển thị và nhập liệu phức tạp khi cần đến, thông qua một máy tính khác. Điều này
là hết sức hữu dụng đối với các thiết bị điều khiển từ xa, cài đặt vĩnh viễn. Ví dụ,
các router là các thiết bị đã ứng dụng tiện ích này.
1.2.2.

Thiết bị ngoại vi

Hệ thống nhúng giao tiếp với bên ngoài thông qua các thiết bị ngoại vi, ví dụ
như:
• Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485.
• Universal Serial Bus (USB).
• Networks: Controller Area Network, LonWorks.
• Bộ định thời: PLL(s), Capture/Compare và Time Processing Units.
• Discrete IO: General Purpose Input/Output (GPIO).
1.2.3.

Công cụ phát triển

Tương tự như các sản phẩm phần mềm khác, phần mềm hệ thống nhúng
cũng được phát triển nhờ việc sử dụng các trình biên dịch (compilers), chương trình
dịch hợp ngữ (assembler) hoặc các công cụ gỡ rối (debuggers). Tuy nhiên, các nhà
thiết kế hệ thống nhúng có thể sử dụng một số công cụ chuyên dụng như:
• Bộ gỡ rối mạch hoặc các chương trình mô phỏng (emulator).
• Tiện ích để thêm các giá trị checksum hoặc CRC vào chương trình, giúp hệ
thống nhúng có thể kiểm tra tính hợp lệ của chương trình đó.
• Đối với các hệ thống xử lý tín hiệu số, người phát triển hệ thống có thể sử
dụng phần mềm workbench như MathCad/ Mathematica để mô phỏng phép toán.
• Các trình biên dịch và trình liên kết (linker) chuyên dụng được sử dụng để
tối ưu hóa một thiết bị phần cứng.
• Một hệ thống nhúng có thể có ngôn ngữ lập trình và công cụ thiết kế riêng
của nó hoặc sử dụng và cải tiến từ một ngôn ngữ đã có sẵn.


6

Các công cụ phần mềm có thể được tạo ra bởi các công ty phần mềm chuyên
dụng về hệ thống nhúng hoặc chuyển đổi từ các công cụ phát triển phần mềm GNU.
Đôi khi, các công cụ phát triển dành cho máy tính cá nhân cũng được sử dụng nếu
bộ xử lý của hệ thống nhúng đó gần giống với bộ xử lý của một máy PC thông
dụng.
1.2.4.

Độ tin cậy

Các hệ thống nhúng thường nằm trong các cỗ máy được kỳ vọng là sẽ chạy
hàng năm trời liên tục mà không bị lỗi hoặc có thể khôi phục hệ thống khi gặp lỗi.
Vì thế, các phần mềm hệ thống nhúng được phát triển và kiểm thử một cách cẩn
thận hơn là phần mềm cho máy tính cá nhân. Ngoài ra, các thiết bị rời không đáng
tin cậy như ổ đĩa, công tắc hoặc nút bấm thường bị hạn chế sử dụng. Việc khôi phục
hệ thống khi gặp lỗi có thể được thực hiện bằng cách sử dụng các kỹ thuật như
watchdog timer – nếu phần mềm không đều đặn nhận được các tín hiệu watchdog
định kì thì hệ thống sẽ bị khởi động lại.
Một số vấn đề cụ thể về độ tin cậy như:
• Hệ thống không thể ngừng để sửa chữa một cách an toàn, ví dụ như ở các
hệ thống không gian, hệ thống dây cáp dưới đáy biển, các đèn hiệu dẫn đường…
Giải pháp đưa ra là chuyển sang sử dụng các hệ thống con dự trữ hoặc các
phần mềm cung cấp một phần chức năng.
• Hệ thống phải được chạy liên tục vì tính an toàn, ví dụ như các thiết bị dẫn
đường máy bay, thiết bị kiểm soát độ an toàn trong các nhà máy hóa chất…
Giải pháp đưa ra là lựa chọn backup hệ thống, nếu hệ thống ngừng hoạt động
sẽ gây tổn thất rất nhiều tiền của ví dụ như các dịch vụ buôn bán tự động, hệ thống
chuyển tiền, hệ thống kiểm soát trong các nhà máy …
1.2.5.

Xu hướng phát triển của các hệ thống nhúng

Sau máy tính lớn (mainframe), PC và Internet thì hệ thống nhúng đang là làn
sóng đổi mới thứ 3 trong công nghệ thông tin và truyền thông.
Xu hướng phát triển của các hệ thống nhúng hiện nay là:


7

Phần mềm ngày càng chiếm tỷ trọng cao và đã trở thành một thành phần cấu
tạo nên thiết bị bình đẳng như các phần cơ khí, linh kiện điện tử, linh kiện quang
học…
• Các hệ nhúng ngày càng phức tạp hơn đáp ứng các yêu cầu khắt khe về thời
gian thực, tiêu ít năng lượng và hoạt động tin cậy ổn định hơn.
• Các hệ nhúng ngày càng có độ mềm dẻo cao đáp ứng các yêu cầu nhanh
chóng đưa sản phẩm ra thương trường, có khả năng bảo trì từ xa, có tính cá nhân
cao.
• Các hệ nhúng ngày càng có tính thích nghi, tự tổ chức cao có khả năng tái
cấu hình như một thực thể, một tác nhân.
• Các hệ nhúng ngày càng có khả năng tiếp nhận năng lượng từ nhiều nguồn
khác nhau (ánh sáng, rung động, điện từ trường, sinh học….) để tạo nên các hệ
thống tự tiếp nhận năng lượng trong quá trình hoạt động.
1.2.6.

Những thách thức và vấn đề còn tồn tại với hệ thống nhúng

Hệ thống nhúng hiện nay còn phải đối mặt với các vấn đề sau:
• Độ phức tạp của sự liên kết đa ngành phối hợp cứng - mềm. Độ phức tạp
của hệ thống tăng cao do nó kết hợp nhiều lĩnh vực đa ngành, kết hợp phần cứng mềm, trong khi các phương pháp thiết kế và kiểm tra chưa chín muồi. Khoảng cách
giữa lý thuyết và thực hành lớn và còn thiếu các phương pháp và lý thuyết hoàn

chỉnh cho khảo sát phân tích toàn cục các hệ nhúng.
• Thiếu phương pháp tích hợp tối ưu giữa các thành phần tạo nên hệ nhúng
bao gồm lý thuyết điều khiển tự động, thiết kế máy, công nghệ phần mềm, điện tử,
vi xử lý, các công nghệ hỗ trợ khác.
• Thách thức đối với độ tin cậy và tính mở của hệ thống: Do hệ thống nhúng
thường phải hội thoại với môi trường xung quanh nên nhiều khi gặp những tình
huống không được thiết kế trước dễ dẫn đến hệ thống bị loạn. Trong quá trình hoạt
động một số phần mềm thường phải chỉnh lại và thay đổi nên hệ thống phần mềm
có thể không kiểm soát được.


8

Đối với hệ thống mở, các hãng thứ 3 đưa các module mới, thành phần mới
vào cũng có thể gây nên sự hoạt động thiếu tin cậy.
1.3. Lý thuyết kiểm thử
1.3.1.

Mục tiêu kiểm thử

Kiểm thử nhằm xác định sự khác biệt giữa các hành vi dự kiến và hành vi
thực sự của một hệ thống. Mục đích của kiểm thử là phát hiện lỗi, nhằm tìm ra các
sự khác biệt có thể nhận diện giữa hành vi của hệ thống được cài đặt và hành vi dự
định của hệ thống thử nghiệm. Mục tiêu của quá trình kiểm thử được xác định
nhằm:


Tìm và ngăn ngừa các lỗi



Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng.



Đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu kinh doanh và người

sử dụng.
Kiểm thử sẽ giúp hoàn thiện các ứng dụng phần mềm hoặc sản phẩm so với
yêu cầu kinh doanh và người sử dụng. Đây là giai đoạn rất quan trọng để đảm bảo
hệ thống hoạt động tốt và theo các thông số kỹ thuật.
Việc xác định phạm vi kiểm tra các trường hợp kiểm thử nên được thiết kế
tốt với khả năng tối đa của việc tìm kiếm các lỗi hiệu quả và được tính toán là số
bug báo cáo cho mỗi trường hợp kiểm thử.
Kiểm thử để chắc chắn hệ thống đang thực hiện đúng cách và đã sẵn sàng để
sử dụng. Kiểm thử bao phủ các lĩnh vực khác nhau như: chức năng của các ứng
dụng, khả năng tương thích của các ứng dụng với các hệ điều hành, phần cứng và
các loại khác nhau của các trình duyệt, thực hiện kiểm thử để kiểm tra hiệu năng
của các ứng dụng để đảm bảo rằng hệ thống đáng tin cậy và không có trục trặc hay
không nên có bất kỳ vấn đề cản trở. Xác định rằng các ứng dụng có thể được triển
khai một cách dễ dàng với máy tính và không có bất kỳ sự cố. Do đó các ứng dụng
rất dễ dàng để cài đặt, tìm hiểu và sử dụng.
Kiểm thử cho phép tạo ra những đánh giá khách quan về mức độ phù hợp
của hệ thống các yêu cầu đã nêu và thông số kỹ thuật.


9

Kiểm tra xác nhận rằng hệ thống đáp ứng các yêu cầu khác nhau bao gồm:
chức năng, hiệu suất, độ tin cậy, an toàn, khả năng sử dụng và như vậy. Việc xác

nhận này được thực hiện để đảm bảo rằng đội ngũ kỹ sư đang xây dựng hệ thống
phù hợp. Ngoài việc giúp đưa ra quyết định, các thông tin từ các quá trình kiểm thử
sẽ giúp quản lý rủi ro.
1.3.2.

Nguyên tắc kiểm thử

Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử hệ thống cần phải tuân
thủ một số nguyên tắc sau:
 Nguyên tắc 1: Kiểm thử chỉ ra sự hiện diện của lỗi.
Kiểm thử có thể chỉ ra có mặt của lỗi, nhưng không thể chứng minh rằng hệ
thống không có lỗi. Việc kiểm thử làm giảm xác suất các khuyết tật chưa được tìm
thấy còn lại trong hệ thống hoặc phần mềm.
 Nguyên tắc 2: Kiểm thử toàn bộ, đầy đủ là không thể.
Kiểm thử toàn bộ (kết hợp tất cả các yếu tố đầu vào và điều kiện tiên quyết)
là không khả thi trừ những trường hợp nhỏ và đơn giản. Thay vì kiểm thử đầy đủ,
nên sử dụng những đánh giá rủi ro và nỗ lực để ưu tiên tập trung kiểm thử từng
trường hợp.
 Nguyên tắc 3: Cần bắt đầu giai đoạn kiểm thử càng sớm càng tốt.
Hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong chu trình phát triển
hệ thống và cần được tập trung vào các mục tiêu xác định.
 Nguyên tắc 4: Phân nhóm lỗi để xác định một số module tập trung lỗi
nhiều nhất.
 Nguyên tắc 5: Kịch bản kiểm thử cần được cập nhật
Các bộ kịch bản kiểm thử phải được thường xuyên xem xét và cập nhật, phù
hợp với từng thành phần khác nhau của hệ thống, mang lại khả năng tìm thấy lỗi lớn
nhất.
 Nguyên tắc 6: Kiểm thử được thực hiện khác nhau trong những bối
cảnh khác nhau.

10

1.3.3.

Nội dung các nhiệm vụ trong quá trình kiểm thử

 Lập kế hoạch kiểm thử:
Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ
được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng
được dùng để xác định nhu cầu nhân lực.
Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá
trình cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra
viên quá yếu, không hiểu rõ yêu cầu.
Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện
việc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ
định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện để
xác định thời gian kiểm tra.
Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần
cứng, phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra.
Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định
chitiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá
trình kiểm tra.
Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch
chi tiết.


11

Hình 1.1: Bản kế hoạch chính và bản kế hoạch chi tiết

Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người
có liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc xem xét nhằm bảo
đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai sót
trong các bản kế hoạch.
 Chuẩn bị môi trường kiểm thử
Thiết kế hệ thống kiểm thử: Có những trường hợp máy được dùng cho các
vận hành nghiệp vụ phải được dùngcho chạy chương trình để kiểm thử. Tuy nhiên
nếu máy này lưu giữ các tệp hay cơ sở dữ liệu vẫn được truy nhập tới trong vận
hành hàng ngày, hay 1 tải lượng lớn bị áp vào máy trong khi kiểm thử, thì việc sản
xuất sẽ bị gây rối loạn. Dó đó cần phải phát triển hay thiết kế cùng hệ điều hành, tệp
và cơ sở dữ liệu nhưng sẽ là đối tượng được dùng trong việc chạy sản xuất thực.
Thiết kế chương trình kiểm thử và dữ liệu kiểm thử: Chương trình kiểm
thử phải được thiết kế, dữ liệu kiểm thử phải được chuẩn bị và các trường hợp kiểm
thử phải được thiết kế bằng nhiều phương pháp.
Thiết đặt các công cụ kiểm thử: Các công cụ kiểm thử cần phải được thiết
đặt phù hợp với hệ điều hành để làm giảm chi phí phát triển và làm tăng tính hiệu
quả, chất lượng của kiểm thử.
 Tiến hành kiểm thử:
Nhiều loại kiểm thử phải được tiến hành trong điều kiện môi trường được
chuẩn bị tốt.


12

 Kiểm tra kết quả của kiểm thử:
Kiểm thử được tiến hành tương ứng với các kế hoạch kiểm thử và đặc tả
kiểm thử, và kết quả của việc kiểm thử phải được kiểm tra lại.
 Phân tích hỏng hóc, phân tích hiệu năng:
Các lỗi và các hỏng hóc bị phát hiện phải được phân tích chặt chẽ bằng việc

dùng các công cụ và các kĩ thuật kiểm tra chất lượng đa dạng.
 Sửa chữa và cải tiến tài liệu, chương trình gốc:
Nếu lỗi hay sai sót thiết kế được tìm thấy và nếu chúng có thể được sửa chữa
ngay lập tức thì chương trình nguồn phải được sửa chữa hay cải tiến. Phần của tài
liệu thiết kế liên quan tới các lỗi hay sai sót thiết kế như vậy cũng phải được sửa
chữa đảm bảo sự nhất quán giữa chương trình nguồn và tài liệu thiết kế.
 Hoàn tất quá trình kiểm thử :
Sau khi 1 kiểm thử đã được hoàn tất và chương trình đã được sửa chữa, thì
các hành động sau phải được tiến hành:
- Quản lý tiến trình kiểm thử và báo cáo:. Sau khi kiểm thử được hoàn tất,
kiểm thử viên phải báo cáo kết quả của việc kiểm thử bằng việc dùng báo cáo hoàn
thành kiểm thử.
- Kiểm soát dữ liệu liên quan tới hỏng hóc: Dữ liệu về lỗi hay khiếm
khuyết được tìm ra trong khi kiểm thử, quá trình fix lỗi phải được tích lại phục vụ
cho quá trình hoàn thiện và phát triển hệ thống.
- Xem lại tài liệu vận hành ngược dòng: Để ngăn cản việc lặp lại các lỗi
gây ra bởi 1 sai lầm phạm phải trong quá trình sửa lỗi.
1.4. Kiểm thử tự động
Kiểm thử tự động
Sử dụng một công cụ kiểm thử tự động để thực thi các ca kiểm thử thay cho
con người được goi là kiểm thử tự động. Công cụ kiểm thử tự động có thể lấy dự
liệu từ file bên ngoài (excel, csv, …) nhập vào ứng dụng, so sánh kết quả mong đợi
với kết quả thực tế và xuất ra báo cáo kết quả kiểm thử.
Ưu điểm và nhược điểm


13



Ưu điểm:

-

Độ tin cậy cao (Reliability): Nhờ sự ổn định vượt trội của công cụ kiểm

thử tự động so với con người, đặc biệt trong trường hợp có quá nhiều test cases cần
được thực thi, nên độ tin cậy của kiểm thử tự động thường cao hơn so với kiểm thử
thủ công.
-

Khả năng lặp (Repeatability): Với độ ổn định cao, chúng ta hoàn toàn

có thể tin tưởng vào kết quả thực thi của công cụ kiểm thử tự động.
-

Khả năng tái sử dụng (Reusability): Với một bộ kiểm thử tự động,

chúng ta có thể sử dụng cho nhiều phiển bản ứng dụng khác nhau, đây được gọi là
tính tái sử dụng.
-

Nhanh (Fast): Thực thi các test case một cách tự động sẽ đáp ứng thời

gian rất nhanh.
-

Chi phí thấp (Cost Reduction): Nếu áp dụng kiểm thử tự động đúng

cách, chúng ta có thể tiết kiệm được rất nhiều chi phí, thời gian và nhân lực.



Nhược điểm :

-

Khó mở rộng, khó bảo trì (Poor scalability and maintainability):

Trong cùng một dự án, để mở rộng phạm vi cho kiểm thử tự động là khó hơn nhiều
so với kiểm thử cách thủ công. Số lượng công việc phải làm để mở rộng phạm vi
cho kiểm thử tự động là nhiều hơn và khó hơn kiểm thử thủ công.
-

Khả năng bao phủ thấp (Low coverage): Chính vì việc khó ứng dụng,

khó mở rộng, cũng như đòi hỏi quá nhiều kỹ năng lập trình nên độ bao phủ của
kiểm thử tự động khá thấp (xét trên góc nhìn toàn dự án).
-

Vấn đề công cụ và nhân lực (Technology vs. people issues): Cho đến

nay công cụ hỗ trợ kiểm thử tự động đã có những bước phát triển mạnh mẽ, chúng
ta có các công cụ rất tốt như QTP, Selenium, Test Complete, LoadTest, Jmeter,
Visual Studio, … Nhưng nhìn chung vẫn còn rất nhiều mặt hạn chế. Ngoài ra nguồn
nhân lực đạt yêu cầu cũng không nhiều.
Tầm quan trọng của kiểm thử tự động.
- Tiết kiệm tiền bạc và thời gian: Nhận định này đặc biệt đúng nếu xét trong


14

giai đoạn bảo trì của các dự án lớn. Mỗi tuần chúng ta phải thực hiện regression test
từ 1 đến 2 lần với số lượng test case rất lớn trong 1 đến 2 ngày. Gần như không thể
thực hiện cách thủ công, trong khi với kiểm thử tự động chúng ta hoàn toàn có thể
với nguồn nhân lực vô cùng khiêm tốn.
- Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các ca
kiểm thử với độ chính xác cao hơn.
- Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử tự động, chúng ta
có thể thực thi số lượng lớn các ca kiểm thử trong một thời gian ngắn. Điều này
giúp chúng ta tăng độ bao phủ trong giai đoạn kiểm thử hồi quy (một ví dụ điển
hình).
- Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta
muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất.


15

Chương 2-PHƯƠNG PHÁP KIỂM THỬ DỰA TRÊN MÔ HÌNH
2.1. Kiểm thử dựa trên mô hình
2.1.1.

Kiểm thử dựa trên mô hình

Kiểm thử dựa trên mô hình là một dạng kiểm thử dựa trên hành vi của các
mô hình, nó mã hóa các hành vi dự tính của một hệ thống thử nghiệm và/hoặc hành
vi trong môi trường của nó. Các trường hợp kiểm thử được tạo từ một trong các mô
hình hoặc là sự kết hợp của chúng và được thực hiện trên hệ thống thử nghiệm.
Theo phương pháp truyền thống, quá trình kiểm thử bắt đầu bằng việc sử dụng các
mô hình thường không có cấu trúc, không tái sử dụng, không được tài liệu hóa,
thiếu logic hợp lý cho thiết kế kiểm thử, và dựa trên kinh nghiệm, kỹ năng của các

kỹ sư. Với ý tưởng các thực thể sẽ được mã hóa tường minh vào hệ thống thử
nghiệm dự kiến và các hành vi môi trường khả dĩ có thể giúp giảm thiểu các vấn đề
trên.
Các ý tưởng về kiểm thử dựa trên mô hình được gọi là kiểm thử dựa trên đặc
tả. Trong thập kỷ vừa qua, ở lĩnh vực nghiên cứu và trong ngành công nghiệp,các
phương pháp phát triển dựa trên mô hình và kiểm thử làm trung tâm, cũng như mức
độ phát triển của công nghệ từ lĩnh vực kiểm thử đã làm tăng sự quan tâm về chủ
đề. Dias-Neto đã phân tích 271 tài liệu và xác định được 219 cách tiếp cận kiểm thử
dựa trên mô hình. Điều này cản trở việc áp dụng công nghệ kiểm thử dựa trên mô
hình trong công nghiệp và hạn chế cải tiến các phương pháp tiếp cận kiểm thử dựa
trên mô hình.
Kiểm thử dựa trên mô hình bao gồm các quá trình và các kỹ thuật nhằm: tạo
các dẫn xuất tự động của các trường hợp kiểm thử trừu tượng từ các mô hình trừu
tượng, tạo ra các bài kiểm thử cụ thể từ các kiểm thử trừu tượng,và thực thi thủ
công hoặc tự động các trường hợp kiểm thử cụ thể.
Theo Colin Campbell, kiểm thử dựa trên mô hình là một kỹ thuât kiểm thử
mà các hoạt động của hệ thống được chạy thử trong một thời gian sẽ được dự đoán
trước, nó được thực hiện bởi một đặc tả hình thức hoặc một mô hình của hệ thống.
Các mẫu thiết kế hay mô hình là mô tả đơn giản của hệ thống dựa trên yêu cầu hệ


16

thống và chức năng xác định, giúp chúng ta có thể hiểu và dự đoán được hành vi
của hệ thống.
2.1.2.

Quy trình kiểm thử dựa trên mô hình

Quá trình kiểm thử 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 ra các ca kiểm thử. Chúng ta có thể biết kết
quả đầu ra mong đợi từ mô hình hoặc từ quy định chuẩn. Khi chạy kich bản và kết
quả thu được sẽ 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ử,…
Các bước để thực hiện kiểm thử dựa trên mô hình:
-

Xây dựng mô hình dựa trên các yêu cầu và chức năng của hệ thống.

-

Tạo đầu ra dự kiến từ mô tả của bài toán

-

Chạy kịch bản kiểm thử

-

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 phần mềm)
Trong giới hạn luận văn, học viên sẽ giới thiệu các thuật ngữ và miêu tả
chung quá trình của kiểm thử dựa trên mô hình.

Một bộ kiểm thử (test suite) là một tập các ca kiểm thử (test case). Một ca
kiểm thử là một cấu trúc hữu hạn đầu vào và đầu ra mong muốn: một cặp đầu vào
và đầu ra của các hệ thống biến đổi xác định, một chuỗi đầu vào và đầu ra trong
trường hợp của các hệ thống phản ứng xác định, và một cây hoặc đồ thị trong
trường hợp của các hệ thống phản ứng không xác định. Đầu vào của các ca kiểm
thử gọi là đầu vào kiểm thử.
Một tiến trình chung của kiểm thử dựa trên mô hình sẽ được thực hiện như
hình đây:
Bước 1. Mô hình hệ thống kiểm thử được xây dựng từ các yêu cầu hoặc dựa
trên các tài liệu đặc tả. Mô hình này được gọi là mô hình kiểm thử do nó vẫn trừu


17

tượng và mô hình phải tập trung liên kết trực tiếp tới các đối tượng kiểm thử. Trong
vài trường hợp, mô hình kiểm thử có thể là mô hình thiết kế của hệ thống thử
nghiệm tuy nhiên vẫn có một vài sự khác nhau tương đối giữa mô hình sử dụng cho
bộ tạo kiểm thử và các mô hình phát triển, các lỗi xuất hiện trong mô hình phát triển
có thể không được đưa vào các bài thử nghiệm. Do đó, nó thường được sử dụng để
phát triển mô hình kiểm thử cụ thể từ các yêu cầu, hoặc để tái sử dụng một vài mặt
của mô hình phát triển làm cơ sở cho mô hình thử nghiệm, sau đó sẽ được đối chiếu
với các yêu cầu. Việc đối chiếu mô hình trong đó các yêu cầu được xem xét kỹ
lưỡng đáp ứng sự nhất quán và đầy đủ, và tìm thấy các lỗi.
Trong kiểm thử dựa trên mô hình, việc xác thực mô hình đòi hỏi mô hình
phải đơn giản hơn, trừu tượng hơn hệ thống thử nghiệm, hoặc ít nhất cũng dễ kiểm
tra, thay đổi và quản lý. Nếu không, việc xác thực mô hình sẽ bằng việc xác thực hệ
thống thử nghiệm. Điều này rất khó thực hiện. Trong luận văn này, khái niệm “trừu
tượng” có nghĩa sự thiếu sót có chủ ý về chi tiết trong mô hình và đóng gói của các
chi tiết bằng các cấu trúc ngôn ngữ bậc cao. Mô hình kiểm thử có thể nằm ở nhiều
mức trừu tượng khác nhau. Chuyển đổi trừu tượng chính là ánh xạ từng đầu vào với

đầu ra “không có lỗi ngoại lệ” hoặc “không có sự cố”. Nó cũng có thể trừu tượng ở
việc bỏ qua một số chức năng, hoặc bỏ qua các thuộc tính về chất lượng dịch vụ
như thời gian hoặc bảo mật.
Mặt khác, mô hình phải đủ chính xác để làm cơ sở cho việc tạo ra các ca
kiểm thử có ý nghĩa. Các kiểm thử được tạo ra từ mô hình phải đảm bảo đầy đủ các
tham số đầu vào và kết quả dự kiến để tạo ra hiệu quả thực sự. Nếu không công việc
thiết kế kiểm thử chỉ có thể thực hiện thủ công, và đem lại ít giá trị trong các kiểm
thử được tạo ra từ mô hình.
Bước 2. Lựa chọn tiêu chí kiểm thử, để việc tạo kiểm thử tự động sao cho đạt
được một bộ dữ liệu kiểm thử tốt - một bộ thỏa mãn các chính sách kiểm thử được
xây dựng cho hệ thống thử nghiệm. Việc xây dựng chính sách và các đối tượng
kiểm thử cho một hệ thống phải rõ ràng và dự án phát triển hệ thống liên quan phải
là một phần của tất cả các phương pháp kiểm thử như TMapR hoặc các hướng dẫn


18

ISTQB được sử dụng rộng rãi trong công nghiệp. Trong các phương pháp, chính
sách kiểm thử và các đối tượng kiểm thử được xây dựng từ các tài liệu kế hoạch
kiểm thử, nó xác định phạm vi kiểm thử và các chiến lược cũng như kỹ thuật kiểm
thử khác nhau sẽ được sử dụng trong dự án cho từng mức độ kiểm thử (ví dụ đối
tượng kiểm thử, kiểm thử tích hợp, hệ thống kiểm thử,..)
Các tiêu chí lựa chọn kiểm thử có thể liên quan đến một chức năng nhất định
của hệ thống (tiêu chí lựa chọn kiểm tra dựa trên yêu cầu), đến cấu trúc của mô hình
kiểm thử (vùng bao phủ, vùng chuyển tiếp…), đến các đặc tính ngẫu nhiên như
ngẫu nhiên thuần túy hoặc các hồ sơ người dùng, đến các thuộc tính của môi trường
và chúng cũng có thể liên quan đến một bộ lỗi đã được xác định rõ ràng.
Bước 3. Tiêu chí lựa chọn kiểm thử sẽ được chuyển thành các đặc tả trường
hợp kiểm thử. Các đặc tả trường hợp kiểm thử hiện thực hóa ý tưởng về tiêu chí lựa
chọn kiểm thử và đưa chúng vào hoạt động như: đưa ra mô hình và đặc tả trường

hợp kiểm thử. Một số bộ tạo kiểm thử tự động phải có khả năng chuyển đổi bộ kiểm
thử (xem Bước 4). Ví dụ, “độ bao phủ” của một máy trạng thái hữu hạn (FSM) có
thể được chuyển đổi thành một tập hợp các đặc tả trường hợp kiểm thử như {reach
s0, reach s1, reach s2,. . .}, trong đó s0, s1, s2,. . .là tất cả các trạng thái của FSM.
Đặc tả trường hợp kiểm thử là một mô tả mức cao của một trường hợp kiểm thử
mong muốn.
Bước 4. Khi mô hình và các đặc tả của trường hợp kiểm thử đã được xác
định, một tập hợp các trường hợp kiểm thử sẽ được tạo ra, với mục đích đáp ứng
được tất cả các đặc tả của trường hợp thử nghiệm. Tập hợp các trường hợp kiểm thử
đáp ứng một đặc tả của kiểm thử liên quan tới mô hình có thể rỗng, trong trường
hợp đó đặc tả trường hợp kiểm thử được cho là không thỏa mãn. Tuy nhiên, thường
có một vài hoặc nhiều trường hợp kiểm thử thỏa mãn, và bộ tạo trường hợp kiểm
thử sẽ chỉ chọn một trong các trường hợp kiểm thử đó. Một số bộ tạo kiểm thử có
thể tối ưu hóa bộ kiểm thử, sao cho số các trường hợp kiểm thử được tạo ra ít nhất
nhưng kiểm tra được nhiều các đặc tả trường hợp kiểm thử nhất.


19

Bước 5. Khi bộ kiểm thử đã được tạo, các trường hợp kiểm thử sẽ được thực
thi. Quá trình kiểm thử có thể thực hiện thủ công bởi con người hoặc tự động bởi
môi trường thực thi kiểm thử, nó cung cấp các cơ sở để tự động hóa quá trình kiểm
thử và ghi lại quyết định kiểm tra. Đôi khi, đặc biệt với các hệ thống không xác
định, quá trình tạo và thực thi các kiểm thử được ghép lại cùng nhau, chúng sẽ được
gọi là kiểm thử trực tuyến (online testing). Thực hiện một trường hợp kiểm thử bao
gồm một vài bước. Mô hình và hệ thống thử nghiệm nằm ở các mức trừu tượng
khác nhau, và các mức khác nhau này phải được liên kết.
Một kịch bản kiểm thử là mã thực thi thực hiện một trường hợp kiểm thử, lấy
ra đầu ra của hệ thống kiểm thử, và sau đó xây dựng quyết định. Một bộ điều hợp là
khái niệm và không nhất thiết phải là một thành phần phần mềm riêng biệt - nó có

thể được tích hợp trong các kịch bản kiểm thử. Tóm lại, kiểm thử dựa trên mô hình
bao gồm các hoạt động chính sau đây: xây dựng mô hình, xác định các tiêu chí lựa
chọn kiểm tra và chuyển chúng thành các đặc tả cho trường hợp kiểm thử, tạo các
kiểm thử, nhận và thiết lập thành phần bộ điều hợp (nếu các kiểm thử được tạo ra
được thực hiện tự động , bộ điều hợp thường chiếm một tỷ trọng đáng kể trong tổng
khối lượng công việc) và thực hiện các kiểm tra trên hệ thống thử nghiệm. Mô hình
của hệ thống thử nghiệm được sử dụng làm cơ sở cho việc tạo kiểm thử, nhưng
cũng phục vụ để xác nhận các yêu cầu và kiểm tra sự nhất quán của chúng.
2.1.3.

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

 Thuận lợi
Trong quá trình phát triển hệ thống các kiểm thử viên thường thực hiện công
việc của mình bằng phương pháp truyền thống nên thường thiếu thời gian để thực
hiện kiểm thử, hoặc giá thành sản phẩm khi hoàn thành thường cao. Kiểm thử mô
hình sẽ khắc phục được một số nhược điểm đó:
-

Do quá trình sinh ca kiểm thử là tự động vì vậy mà rút ngắn thời gian

phát triển hệ thống.
-

Đặc biệt tuy chi phí cho việc xây dựng mô hình lớn nhưng điều này sẽ

được khấu trừ do chi phí bảo dưỡng thấp hơn nhiều khi hệ thống được hoạt động.


20

-

Quá trình sinh các ca kiểm thử được thực hiện một cách tự động nên sinh

ra nhiều ca kiểm thử và phát hiện nhiều lỗi.
-

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 các ca kiểm thử trùng nhau hoặc không hữu

-

Khi một yêu cầu của hệ thống thay đổi thì việc thay đôi các ca kiểm thử

hiệu.
đơn giản hơn, vì chỉ cần thay đổi mô hình của hệ thống.
 Khó khăn
Mặc dù có nhiều thuận lợi nhưng bên cạnh cũng có những trở ngại nhất
định của kiểm thử dựa trên mô hình:
-

Do phải xây dựng mô hình của hệ thống vậy nên 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.
-

Trong kiêm thử dựa trên mô hình công việc quan trọng nhất là xây dựng

mô hình. Việc xây dựng mô hình cần được đầu tư thời gian, trí óc và tiền bạc.
2.2. Các vấn đề của quá trình kiểm thử dựa trên mô hình
Các phương pháp kiểm thử dựa trên mô hình thường bao gồm 6 vấn đề. Các
vấn đề phần lớn không hoàn toàn độc lập với nhau: ví dụ, nếu kiểm thử liên quan
với hệ thống liên tục chứ không phải là một hệ thống rời rạc thì sẽ hạn chế lựa chọn
mô hình hóa mô hình, tiêu chí lựa chọn kiểm tra và công nghệ tạo trường hợp kiểm
thử.