Đại học quốc gia hà nội
Trường đại học công nghệ
Ngô Thuỳ Linh Nghiên cứu kiểm thử bao phủ
phần Mềm và ứng dụng Ngô Thuỳ Linh Nghiên cứu kiểm thử bao phủ
phần Mềm và ứng dụng
Luận văn thạc sĩ Ngành: CÔNG NGHỆ THÔNG TIN
Chuyên ngành: CÔNG NGHỆ PHẦN MỀM
Mã số: 60 48 10
Xin cảm ơn các bạn bè, đồng nghiệp và nhất là các thành viên trong gia
đình đã tạo mọi điều kiện tốt nhất, động viên, cổ vũ tôi trong suốt quá trình
học tập và nghiên cứu để hoàn thành tốt bản luận văn tốt nghiệp này.
Tác giả Ngô Thùy Linh LỜI CAM ĐOAN
Tôi xin cam đoan rằng, đây là công trình nghiên cứu của tôi trong đó có
sự giúp đỡ rất lớn của thầy hướng dẫn và các đồng nghiệp ở cơ quan. Các nội
dung nghiên cứu và kết quả trong đề tài này là hoàn toàn trung thực.
Công nghệ thông tin
CRC
class- responsilility- collaboration
FSM
Finite state machine
MBT
Model Base Testing
OOA
Object Oriented Analysis
OOD
Object Oriente Design
OOIT
Object Oriented Integration Testing
ORD
Object Relation Diagram
SQA
Software Quality Assurance
STD
State transition diagram
SUT
System Under Test
Mô hình mô tả kiểm thử hộp đen
14
Hình 2.1
Lớp ấn phẩm và các lớp dẫn xuất của nó
24
Hình 2.2
Sơ đồ tương tác của phần mềm hướng đối tượng và truyền
thống
27
Hình 2.3
Cụm các lớp đối tượng cần để thực hiện công việc chung
31
Hình 3.1
Công thức tính phần trăm bao phủ dòng lệnh
34
Hình 3.2
Mô hình Đồ thị luồng điều khiển
34
Hình 3.3
Công thức tính phần trăm nhánh được bao phủ
35
Hình 3.4
Lược đồ chuyển trạng thái cho “ngăn xếp bị chặn”
40
Hình 4.1
Máy trạng thái hữu hạn biểu diễn bộ khóa an toàn tổ hợp
43
Hình 4.2
Bảng chuyển trạng thái đối với một máy trạng thái hữu hạn
44
và những giới hạn về thời gian, các nguồn lực, nên các hoạt động đảm bảo chất
lượng phần mềm và kiểm thử phần mềm ngày càng chặt chẽ, song vẫn không
đảm bảo rằng các sản phẩm phần mềm được tạo ra không còn lỗi. Lỗi vẫn luôn
tiềm ẩn trong mọi sản phẩm và có thể gây ra những thiệt hại khôn lường. Đặc
biệt, do nguồn lực có hạn, việc kiểm thử phần mềm có thể phải ngừng lại khi
cạn kiệt nguồn lực hay thời gian cho phép đã hết. Vấn đề đặt ra là, có thể dừng
qúa trình kiểm thử được không hay bắt buộc phải kiếm thêm nguồn lực để tiếp
tục. Ngay trong trường hợp còn nguồn lực, khi kiểm thử không phát hiện thấy
lỗi, một câu hỏi tương tự đặt ra: có cần thiết phải tiếp tục kiểm thử nữa hay
không. Để trả lời những câu hỏi trên đây, có một số cách cho phép đánh giá chất
lượng đạt được của phần mềm để đưa ra quyết định:
− Cách thứ nhất là xây dựng mô hình đo độ tin cậy để đánh giá chương trình.
Khi chương trình đạt được một mức độ tin cậy nào đó thì có thể dừng lại.
− Cách thử hai là đánh giá độ bao phủ chương trình của mục tiêu kiểm thử
đặt ra đã thực hiện được. Khi độ bao phủ đạt được số phần trăm nào đó,
đây cũng là một tiêu chí đánh giá cho phép có thể dừng quá trình kiểm thử.
Vì những lý do trên, đề tài ”nghiên cứu kiểm thử bao phủ phần mềm và
ứng dụng” được chọn làm đề tài cho luận văn cao học của tôi.
Sau khi trình bày tổng quan về kiểm thử phần mềm, luận văn đi sâu vào
quá trình kiểm thử phần mềm hướng đối tượng, đặc biệt cho trường hợp máy
trạng thái. Trên cơ sở các phương pháp kiểm thử hướng đối tượng, nghiên cứu
các phương pháp đánh giá độ bao phủ của kiểm thử nói chung, đặc biệt kiểm thử
cho phần mềm hướng đối tượng. Tiếp đó tiến hành xây dựng một chương trình
thử nghiệm về kiểm thử phủ theo các phương pháp đã biết để đánh giá mức độ
bao phủ của các ca kiểm thử được tiến hành cho một chương trình được phát
1
2
triển sử dụng phương pháp máy trạng thái – một trường hợp riêng của phát triển
phần mềm hướng đối tượng.
3
CHƢƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
Như chúng ta biết, mục tiêu của đảm bào chất lượng phần mềm (SQA) là
sản xuất ra các phần mềm có chất lượng cao, đáp ứng được nhu cầu từ phía
khách hàng, nhà sản xuất, và cả những người phát triển. Một trong các hoạt
động quan trọng của SQA là kiểm thử phần mềm (software testing). Kiểm thử
phần mềm là yếu tố quyết định của SQA và khâu điển hình của rà soát đặc tả
thiết kế và lập mã. Việc phát triển hệ thống phần mềm bao gồm hàng loạt các
hoạt động sản xuất, mà ở đó cơ hội để con người đưa vào phần mềm những sai
lầm là rất lớn. Lỗi có thế bắt đầu xuất hiện từ lúc khởi đầu xác định mục tiêu cho
phần mềm: có thể được xác định sai hay không hoàn chỉnh, cũng như các giai
đoạn thiết kế và phát triển về sau. Phần mềm được kiểm thử sẽ hạn chế chi phí
chi trả cho các thất bại do lỗi gây ra và đồng thời có kế hoạch nâng cao chất
lượng của phần mềm cho suốt quá trình phát triển.
1.1. Khái niệm về lỗi phần mềm
Có rất nhiều định nghĩa khác nhau, tựu chung, nói một cách tổng quát là: “
Lỗi phần mềm là sự không phù hợp giữa chương trình và đặc tả của nó”
[Cem&90]. Một cách định nghĩa khác về lỗi phần mềm đó là:
− Phần mềm không làm những gì đã được đặc tả cho nó.
− Phần mềm làm những thứ mà đặc tả chỉ ra không nên làm
− Phần mềm làm những thứ mà đặc tả sản phẩm không đề cập đến
− Phần mềm khó hiểu, khó sử dụng, chậm, hoặc là người dùng cuối cùng
đánh giá là không đúng điều mong muốn.
“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng
đến mức nào, thì ngay cả những lập trình viên xuất sắc nhất cũng không có thể
viết được ngay những đoạn mã không có lỗi. Tính trung bình, một lập trình viên
loại tốt thì cũng mắc từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước lượng rằng,
việc kiểm thử để tìm ra các lỗi này chiếm phần nửa khối lượng công việc phải
làm để có được một phần mềm hoạt động được” [Beiz90] .
ước tính chiếm khoảng 40% tổng chi phí của toàn bộ quá trình phát triển một
sản phẩm phần mềm lần đầu. Kiểm thử và sửa lỗi được thực hiện tại bất kỳ giai
5
đoạn nào của vòng đời phát triển. Tuy nhiên, chi phí cho việc tìm và sửa lỗi tăng
một cách đáng kể theo quá trình phát triển.
1.4. Khái niệm về kiểm thử phần mềm
Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được
phát hiện. Kiểm thử phần mềm là quá trình thực hiện một hệ thống phần mềm để
xác định xem nó có đúng với đặc tả hay yêu cầu của người dùng không trong
một môi trường mong đợi. Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa
được phát hiện một cách sớm nhất có thể và đảm bảo rằng lỗi đã được sửa;
nhưng bản thân kiểm thử không làm công việc chuẩn đoán nguyên nhân gây ra
lỗi và sửa lỗi. Để kiểm thử cần lập kế hoạch cho mỗi lần (một ca) kiểm thử
Một ca kiểm thử thường bao gồm:
tên của mô đun kiểm thử
dữ liệu vào
các bước thực hiện
dữ liệu ra mong muốn (đúng)
dữ liệu ra thực tế (khi đã tiến hành kiểm thử )
Các ca kiểm thử nên được thiết kế ngay khi tạo ra các tài liệu phân tích và
thiết kế, không phải chờ đến khi đã viết xong mã nguồn.
Một ca kiểm thử được gọi là thành công nếu nó phát hiện ra một khiếm
khuyết của phần mềm. Tuy nhiên, các ca kiểm thử chỉ chứng minh được sự tồn
tại của lỗi trong hệ thống chứ không chứng minh được hệ thống không có lỗi.
Theo Glen Mayers [Myer79], kiểm thử phần mềm là quá trình vận hành
chương trình để tìm ra lỗi. Một ca kiểm thử tốt là ca kiểm thử có xác suất cao
tìm ra một lỗi chưa được phát hiện. Một ca kiểm thử thắng lợi là ca kiểm thử
làm lộ ra được ít nhất một lỗi còn chưa được phát hiện.
Bài toán kiểm thử luôn được đặt ra là: tổ chức việc kiểm thử như thế nào để
Hình 1.1. Mô hình chữ V của quá trình kiểm thử
xác đinh
yêu cầu
đặc tả hệ
thống
thiết kế
kiến trúc
thiết kế
chi tiết
lập
trình
rà soát, phân
tích mã
test đơn
vị
test tích
hợp
test hệ
thống
test chấp
được thực hiện càng sớm càng tốt. Thông thường, kiểm thử đơn vị đòi hỏi kiểm
thử viên có kiến thức về thiết kế và hiểu được mã của chương trình. Mục đích
của kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất ra là chính xác,
trong mối tương quan với dữ liệu nhập và chức năng của đơn vị. Điều này
thường đòi hỏi tất cả các nhánh bên trong đơn vị đều phải được kiểm thử để phát
hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi
trong một đơn vị, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then else
là một nhánh. Việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét
hết đơn vị đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.
Phương pháp được sử dụng để kiểm thử đơn vị là phương pháp hộp trắng.
Ngoài ra có thể còn cấn đến các kỹ thuật bộ cuống và bộ lái
1.5.2. Kiểm thử tích hợp
Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử
như một chức năng ứng dụng đã hoàn thành. Trong khi kiểm thử đơn vị, chúng
8
được kiểm thử riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau tạo
thành một chức năng lớn hơn để kiểm thử.
Kiểm thử tích hợp có hai mục tiêu chính:
Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị .
Tích hợp các đơn vị đơn lẻ để có được các hệ thống nhỏ (subsystem)
và cuối cùng là toàn bộ hệ thống hoàn chỉnh (system) chuẩn bị cho
kiểm thử ở mức hệ thống.
Trong kiểm thử đơn vị, lập trình viên cố gắng phát hiện lỗi liên quan đến
chức năng và cấu trúc nội tại của đơn vị chương trình. Có một số phép kiểm thử
đơn giản trên giao diện giữa đơn vị với các thành phần liên quan khác được tiến
hành trong kiểm thử đơn vị; tuy nhiên mọi giao tiếp liên quan đến đơn vị thật sự
được kiểm thử đầy đủ khi các đơn vị tích hợp với nhau trong khi thực hiện kiểm
thử tích hợp.
Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thực hiện trên những đơn
c
c
h
h
ứ
ứ
c
cn
n
ă
ă
n
n
g
g1
1F
K
B
E
D
C
2
2A
F
K
B
E
D
C
Theo chiều sâu
9
Để tích hợp, người ta có thể sử dụng một số chiến lược tích hợp:
− Tích hợp đồng thời (với các chương trình nhỏ) - chiến lược Big-Bang
− Tích hợp dần từng bước (khi chương trình có nhiều mô đun). Trong chiến
lược tích hợp dần này lại có thể tiến hành tích hợp từ trên xuống hay từ
dưới lên. Khi tích hợp từ trên xuống lại có thể thực hiện chiến lược theo
chiều sâu hay theo chiều rộng (xem hình 1.2), tức là có nhiều chiến lược để
tiến hành kiểm thử tích hợp.
Hai phương pháp được sử dụng trong kiểm thử tích hợp là phương pháp
hộp trắng (để kiểm thử cấu trúc) và phương pháp hộp đen (kiểm thử chức năng).
Ngoài ra, khi tiến hành hành tích hợp cần phải sử dụng kỹ thuật bộ cuống và bộ
lái để thay thế cho những mô đun còn thiếu mà cần thiết cho phần hệ thống được
kiểm thử (xem hình 1.3)
nhau.
Kiểm thử hệ thống là kiểm tra tất cả các hành vi chức năng của phần mềm
cùng các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu
năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi
giao tiếp với phần mềm khác hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc
nghẽn" hoặc chiếm dụng bộ nhớ.
Do cần nhiều công sức, thời gian và độ chính xác cao, tính khách quan,
kiểm thử hệ thống thường được một nhóm kiểm thử viên có trình độ cao hoàn
toàn độc lập với nhóm phát triển dự án thực hiện.
Bản thân Kiểm thử hệ thống lại gồm nhiều loại kiểm thử khác nhau (xem
hình 3), phổ biến nhất gồm:
− Kiểm thử chức năng: bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu
cầu thiết kế.
− Kiểm thử khả năng vận hành: bảo đảm tối ưu việc phân bổ tài nguyên hệ
thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng
câu truy vấn
− Kiểm thử khả năng chịu tải: bảo đảm hệ thống vận hành đúng dưới áp lực
cao (ví dụ nhiều người truy xuất cùng lúc). Kiểm thử khả năng chịu tải tập
trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất
thường
− Kiểm thử cấu hình: Kiểm tra sự cấu thành của hệ thống từ các thành phần
dự kiến.
11
− Kiểm thử khả năng an toàn và bảo mật: bảo đảm tính toàn vẹn, bảo mật của
dữ liệu và chương trình của hệ thống khi có sự xâm nhập và tấn công từ
bên ngoài
− Kiểm thử khả năng phục hồi: bảo đảm hệ thống có khả năng khôi phục
trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu;
đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực
tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ.
1.5.5. Kiểm thử hồi quy
Kiểm thử hồi quy không phải là một mức kiểm thử, như các mức khác đã
nói ở trên. Nó đơn thuần là kiểm thử lại phần mềm sau khi có một sự thay đổi
xảy ra, để bảo đảm phiên bản phần mềm mới thực hiện tốt các chức năng như
phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã
làm việc tốt. Kiểm thử hồi quy có thể thực hiện tại mọi mức kiểm tra, đặc biệt
trong kiểm thử tích hợp.
Ví dụ 1.1: một phần mềm đang phát triển khi kiểm thử cho thấy nó chạy tốt
các chức năng A, B và C. Khi có thay đổi mã của chức năng C, nếu chỉ kiểm thử
chức năng C thì chưa đủ, cần phải kiểm thử lại tất cả các chức năng khác liên
quan đến chức năng C.
Mặc dù không phải là một mức kiểm thử, Kiểm thử hồi quy là một trong
những loại kiểm thử tốn nhiều thời gian và công sức nhất. Do đó việc bỏ qua
Kiểm thử hồi quy là "không được phép" vì có thể dẫn đến tình trạng phát sinh
hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó
hoặc không có hoặc đã được kiểm thử và sửa chữa.
1.6. Các chiến lƣợc kiểm thử
Một chiến lược kiểm thử phần mềm là sự tích hợp các kỹ thuật thiết kế các
phép thử tạo thành một dãy các bước để hướng dẫn quá trình kiểm thử phần
mềm thành công. Nó đưa ra một bản đồ đường đi mô tả các bước trong quá trình
kiểm thử. Vì thế chiến lược kiểm thử nào cũng phải tích hợp được việc lập kế
hoạch kiểm thử, thiết kế các ca kiểm thử, tiến hành kiểm thử, thu thập và đánh
giá các thông tin kết quả.
13
Chiến lược kiểm thử phần mềm phải đủ mềm dẻo để cổ vũ các cách tiếp
cận sáng tạo của người thực hiện. Nhưng với tư cách là một tiến trình trong dự
án, nó cũng phải vừa đủ chặt chẽ để hỗ trợ các kế hoạch và phương thức quản lý.
Một chiến lược kiểm thử phần mềm phải thích ứng với từng mức kiểm thử:
chúng.
Tương ứng với các yêu cầu đặt ra ở trên, một số kỹ thuật sau đây đã được
sử dụng khi xây dựng các ca kiểm thử theo phương pháp hộp trắng:
− Đồ thị luồng (flow graph)
− Ma trận kiểm thử (testing matrices)
− Kiểm thử vòng lặp (loop testing)
− Kiểm thử luồng dữ liệu (data flow testing).
− Kiểm thử điều kiện.
Kiểm thử hộp trắng được sử dụng ở ba loại kiểm thử là: Kiểm thử đơn vị,
kiểm thử tích hợp, kiểm thử hồi quy.
1.7.2. Kiểm thử hộp đen
Kiểm thử hộp đen (blackbox testing) xem phần mềm như một “ hộp đen”
thuần túy, người kiểm thử không cần quan tâm đến cấu trúc và hoạt động bên
trong của nó. Bằng cách nhập các dữ liệu đầu vào qua giao diện, thực thi chương
trình và xem xét kết quả đầu ra qua giao diện để nhận biết việc thực hiện chức
năng có phù hợp với sự mong đợi hay không. Kiểm thử hộp đen vì thế còn được
gọi là kiểm thử chức năng (functional testing) hay kiểm thử hành vi (behavioral
testing). Như vậy, cơ sở cho việc kiểm thử hộp đen chính là đặc tả chức năng
của phần mềm và các dữ liệu mà nó sử dụng hình 1.4:
Hình 1.4 : Mô hình mô tả kiểm thử hộp đen
Cái
mối quan hệ đối xứng, chuyển tiếp và phản xạ, một lớp tương đương được biểu
diễn. Một lớp tương đương biểu diễn một tập các trạng thái phù hợp hay không
cho các điều kiện đầu vào. Điển hình, một điều kiện đầu vào hoặc là một giá trị
số xác định, một miền giá trị, một tập các giá trị liên quan hay một điều kiện
logic. Lớp tương đương có thể được xác định dựa theo các yếu tố sau:
− Nếu điều kiện đầu vào xác định một miền, một lớp tương đương đúng và
hai lớp tương đương sai được xác định.
− Nếu một điều kiện đầu vào yêu cầu một giá trị xác định, một lớp tương
đương đúng và hai lớp tương đương sai được xác định.
16
− Nếu một điều kiện đầu vào xác định một phần tử của một tập, một lớp
tương đương đúng và một lớp tương đương sai được xác định.
− Nếu một điều kiện đầu vào là một giá trị logic, một lớp tương đương đúng
và một lớp tương đương sai được xác định.
1.7.2.2. Phân tích giá trị điểm biên
Phân tích giá trị biên là một kỹ thuật thiết kế ca kiểm thử và được sử dụng
để chỉ ra dữ liệu kiểm thử từ đó xây dựng các ca kiểm thử. Đa phần các sai về
lập trình thường xảy ra đối với các dữ liệu ở biên, những nơi diễn ra tính toán cơ
học hoặc tại các vị trí dữ liệu được thao tác phải thay đổi cho hợp lý để chương
trình xuất ra kết quả chính xác. Ý tưởng của phân tích giá trị biên là sử dụng giá
trị biến đầu vào ở các vị trí: giá trị nhỏ nhất, giá trị lớn nhất, giá trị ngay bên
trong biên, giá trị ngay bên ngoài biên, giá trị đại diện thông thường và các giá
trị có thể gây lỗi. Kết quả mong đợi là khi chương trình làm việc chính xác với
các giá trị đặc biệt này thì nó sẽ làm việc chính xác với các giá trị thông thường
bên trong miền giá trị.
Thiết lập các ca kiểm thử được chỉ ra bởi phân tích giá trị biên phụ thuộc
vào cả sự yêu cầu về tính tin cậy của phần mềm và cả những giả thuyết có thể
xảy ra trong quá trình kiểm soát lỗi.
1.7.2.3. Đồ thị nhân quả
qua cấu trúc mã nguồn. Bên cạnh đó, bảng quyết định (decision table) và sơ đồ
trạng thái (state machine) được sử dụng để mô tả các hành vi bên ngoài (còn gọi
là black box).
1.7.3.2. Lựa chọn mô hình
Chưa có một nghiên cứu lớn nào được tiến hành để đưa ra những hướng
dẫn cho việc lựa chọn một mô hình cụ thể. Tuy nhiên, có thể sử dụng đánh giá
trực quan. Ví dụ: để mô hình hoá các tệp HTML cho một trình duyệt hoặc các
biểu thức toán học cho một máy tính khoa học, ngữ pháp có thể là hướng tiếp
cận nhanh nhất và dễ nhất để mô hình hoá, bởi vì ngữ pháp được sử dụng để mô
tả những ngôn ngữ như vậy. Các hệ thống điện thoại thường mang tính trạng
thái và rất nhiều lỗi trong những hệ thống như vậy được phát hiện thông qua thử
tải trong một giai đoạn dài, các máy trạng thái chính là giải pháp lý tưởng trong
trường hợp này. Các hệ xử lý song song là các hệ có vài thành phần hoạt động
18
đồng thời. Nếu từng thành phần độc lập có thể được mô hình hoá sử dụng các
máy trạng thái thì các lược đồ trạng thái (statecharts) là giải pháp hợp lý.
Có rất nhiều ví dụ về lựa chọn mô hình. Nếu một hệ thống có ít trạng thái
nhưng việc dịch chuyển trạng thái bị chi phối bởi vài điều kiện bên ngoài kết
hợp với đầu vào, thì cần phải có một mô hình mạnh hơn máy trạng thái hữu hạn,
lược đồ trạng thái có lẽ là thích hợp. Nếu một hệ thống có thể mô hình hoá bằng
một máy trạng thái hữu hạn nhưng có yêu cầu sử dụng các phân tích thống kê
trên dữ liệu lỗi, khi đó chuỗi Markov là thích hợp hơn.
1.7.3.3. Xây dựng mô hình
Để xây dựng mô hình, các kiểm thử viên dựa vào định nghĩa các trừu tượng
trạng thái hệ thống ở mức cao, sau đó sẽ tinh chỉnh để trở thành một không gian
trạng thái thực của hệ thống. Không gian trạng thái là rất lớn nên khó liệt liệt kê
được toàn bộ, cách tốt nhất lúc này là mô hình hoá chúng đẻ có mô hình hệ
thống.
Mô hình hoa hệ thống là trừu tượng hoá trạng thái dựa trên các đầu vào,
hợp để sinh ra không gian trạng thái. Rất nhiều thuật toán đã được đưa ra để
thực hiện việc này.
Quá trình xây dựng các loại mô hình khác (chẳng hạn ngữ pháp) cũng
tương tự mặc dù có sự khác biệt trong biểu diễn cuối cùng. Mục đích cuối cùng
là cho phép sinh ra một cách tự động dãy các đầu vào và kiểm tra các hành vi
mong đợi, do đó việc nghiên cứu phạm vi của đầu vào yêu cầu đặc tả về việc khi
nào dữ liệu đầu vào được cho phép và các hành động có thể sinh ra từ đó.
1.7.3.4. Những ưu điểm của MBT
Các kĩ thuật kiểm thử dựa trên mô hình có tiềm năng rất lớn. Nhiều nghiên
cứu chỉ ra rằng, kiểm thử cho nhiều ứng dụng khác nhau sử dụng MBT đã rất
thành công, như kiểm thử giao diện người dùng của Rosaria và Robinson
(2000), kiểm thử phần mềm điều khiển hệ thống nhúng của Agrawal và
Whittaker (1993), kiểm thử hệ thống điện thoại của Larson (1993) và Dalal
(1998).
Những kinh nghiệm trên cho thấy, MBT phù hợp với kiểm thử các ứng
dụng nhỏ, các hệ thống nhúng, giao diện người dùng và hệ thống hoạt động dựa
trên trạng thái với dữ liệu có độ phức tạp vừa phải. Nếu những kết luận này
được chứng minh, chúng ta sẽ nhìn thấy MBT được áp dụng vào rất nhiều lĩnh
Copyright: Tài liệu đại học ©