1. Trang chủ
  2. » Luận Văn - Báo Cáo

Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm

79 3 0
Tài liệu được quét OCR, nội dung có thể không chính xác
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
Tác giả Hà Thị Nga
Người hướng dẫn TS. Bàng Văn Hưng
Trường học Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội
Chuyên ngành Kỹ thuật phần mềm
Thể loại Luận văn thạc sĩ
Năm xuất bản 2014
Thành phố Hà Nội
Định dạng
Số trang 79
Dung lượng 2,6 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Vĩ các kỹ thuật nảy dược thực hiện trên các mã lệnh của chương trình va tim ra các lỗi phân tích, lỗi thiết kế và lỗi về đâm bảo tính để dùng của chương trình Kiểm chứng mô hình Model

Trang 1

TRUONG BAT HOC CONG NGHE

NGO THINGA

KET HỢP PIƯƠNG PHÁP KIÊM CITỮNG MÔ HÌNTI VÀ

CAC KY THUAT KIEM THU PHAN MEM LAM TANG BO

TIN CAY CUA ITE THONG PTAN MEM

LUAN VAN TIIAC Si CONG NGI THONG TIN

Hà Nội - 2014

Trang 2

ĐẠI HỌC QUỐC GIA HÀ NÓI

TRUONG DAI HỌC CÔNG NGHI

NGÔ TIH NGA

KET HỢP PHƯƠNG PIHÁP KIỂM CIIỨNG MÔ HÌNH VÀ CAC K¥ THUAT KIEM THU PHAN MEM LAM TANG DO

TIN CAY CUA TIE THONG PITAN MEM

Ngành: Công nghệ thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã số: 60480103

LUAN VAN THAC Si CONG NGHE THONG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS BANG VAN HUNG

Trang 3

Loi cam doan

‘T@i xin cam đoan rằng luận văn cao học nảy do chính tôi thực hiện Những kết

quả được tổng hợp vả nghiên cứu từ các tài liệu tham kháo sứ dụng trong luận văn này

được thu thập từ các nguồn thông tin được công bổ trên các sách báo, tạp chỉ khoa học

chuyên ngành đáng tn cậy và kiến thức, kmh nghiệm cửa bản thân Tôi hoàn Loàn chịu

trách nhiệm Irước nhà lrường vé su cam doan nay

Hà Nội, ngày 11 tháng 06 năm 2014

Học viên

Ngõ Thị Nga

Trang 4

lim xin gũi lời cám ơn chân thành tới các thầy cô giảng viên trong bộ môn Kỹ thuật phần mềm, khoa Công nghệ thông tin, trường Dại học Công nghệ đã giáng dạy

và truyền đạt những kiến thức, kinh nghiệm che em trong thời gian qua

Tim xin được gửi lời cảm ơn sâu sắc nhất tới thấy giáo TS Dang Van Ilung, thay

đã giúp dé, hưởng dẫn va chí bảo cho em trong suốt quả trinh học tập và thực hiện

Tuận vẫn

Tiên cạnh những kết quả mà em đạt được, em cũng không tránh khỏi những thiểu sot trong, quá trình thực hiện luận văn, em kinh mong các thầy cô thông cắm cho em

Sự góp ý, giúp đỡ của thấy cô sẽ là những kinh nghiệm quý báu cho quá trình học tập

và lắm việc của em sau này

1Öm kinh chúc thầy cô luôn mạnh khỏe, công tác tốt và đạt đuạc nhiều thành công, trong cuộc sống cũng nÏư trong sự nghiệp trồng người của minh

Hà Nội, ngày 11 tháng 06 năm 2014

Học viên

Ngo Thi Nga

Trang 5

Trời cam đoạn

Trời cầm ơn

Mục lục

Danh mục bâng biểu TH H1 HH T712 cty

Chương 1 Giới thiệu

lội dụng nghiên cứu

3.1.6 Các mức độ kiểm thử coi cước

2.1.7 Các giới hạn của kiếm thử 2.2 Cac kỹ thuật kiểm thử phan mém

1 Kỹ thuật phân lớp tương đương,

3.1 Khái niệm kiểm chứng mê hình

3.2 Quy trình kiểm chứng mô hình

3.3 Ưu và nhược điểm của kiếm chứng mô hình

3.3.1 Ưu điểm của kiếm chứng mô hình 3.3.2 Nhược điểm của kiểm chứng mỗ hình

3.4 Logie thời gian tuyển tỉnh (Linear Temporal Logie - 1.11.)

3.4.1 Trang thai thai giant tuydu tink (Linear-Titne Behavior)

3.4.2 Thude tính thời gian tuyến Lính

3.4.3 Các thuộc tính sn loàn (safety propertics)

3.5 Các công cụ kiểm chứng mô hình

Trang 6

4.1.3, Dữ liệu và cầu trúc chương trình

4.1.3 Cầu trúc kiểu kènh thông điệp và tiên trình

Chương 5 Kết hợp kiểm chứng mô hình và các kỹ thuật kiểm thử phẫn miễm

5.1 Ý nghĩa SH 0012001101001 TT m1 cTn.Tne ru,

5.2 Mô hinh đề xuất se ireererree

5.3 Tỉnh đứng đẫn của cách tiếp cận

5.1 Ưu điểm và nhược điểm của cách tiếp cận

Chương 6 Thục nghiệm

6.1 Mô tả bài toán thực nghiệm — bài toán ATM

62 Xây đựng mô hinh và kiếm chứng,

6.2.1 Máy trạng thái hữu hạn mở rộng EI'SM

6.2.2 Mô hình hóa hệ thẳng bằng ngôn ngữ Pramela

6.2.3 Hình thức hóa va kiếm chứng các yên cầu hệ thông,

63 Biển đối hệ thẳng bằng kỹ thuật kiếm thử đột biến

6.3.1 Biến đổi mô hình hệ thống 6.3.2 Biến đổi yêu câu đặc tả của hệ thông

6.4 Kết luận

1 Kết quả của luận văn

2 Hướng nghiên cửu tiếp theo

Tài liệu tham khảo

Trang 7

Danh mục hình vẽ

Tình 21 Mô hình chữ V trong phát triển phần mềm - 13

Hình 3.1 Môi liên hệ giữa kiểm chứng hình thức, kiểm chứng mô hình và khái niêm

Tình 4.4 Sơ đỗ gửi nhận thông điệp trên kênh gặp - 40

Hình 4.5 Sơ đề gửi nhân thông diệp trong kênh đệm eeoeeeeseo.4T

Hình 410, Ví đụ về mmội chương trình có lỗi cceeeeoeesoreeoeo.đĐ

Tĩnh 4.12 Giả lập có hướng dẫn với Trial được tạo ra ở hình 4.9 sees SO

Tình 5.2 Cách tiễn cận kiêm chứng mỏ hình kết hợp với kiếm thử đội biên 33

Hinh 6.2 Lược dẻ truyền thông điệp trong máy ATM sec vỐT

Tinh 6.3 Các thông điệp trong máy ATM oi cecer ¬ THình 6.4 Cáo kênh thông điệp trong máy ATAM 62

Tình 6.5 Hàm rút khỏi tạo các liễn trình - - - 62

Tình 6.6 Mã lệnh Promela cũa Hến trink Customer đ

Hinh 6.7 Kết quả kiểm chứng với yêu cầu đặc tả thứ nhật ER) Binh 6.8 Két qua kiém chứng với yêu cầu đặc tá thử hai —-¬

Tinh 6.9 Két quả kiểm chứng mö hình với đặc tà sai Mutant 6 68 Tinh 6.10 Két quả kiểm chúng mê hình với đặc tá sai Mutant 7 - 69

Trang 8

táng 3.1 Các toán tử trong LỮL is ceeeteirreerree

Tảng 3 2 Các toán tử thời gian trong LTL

Bang 33 Bang chan gid wi

Bang 41 Kiểu dữ liệu số của Promela

Bang 5.1 Cúc toán tử đội biển trong trgôn ngữ Pruruela

Bang 5.2 Méi quan hệ giữa đặc tÄ và mỏ hình hệ thông

Trang 9

1.1 Dat van dé

Hang ngay méi chung ta déu tiếp xúc với hảng trắm thiết bị điện tổ, dỗ gia đụng, máy vị tính ản chứa trong dỏ là những hệ thống máy tính và các chương trình

ứng đụng phẫn mềm Máy vi lính và các hệ thông thông lim đã đi sâu vào đt

mỗi người Bắt cứ một sai sót nảo của các thiết bị này đều khó mà chấp nhận được, những sai lâm này đều phải trã giá bằng sinh mạng con người, bằng vật chất Theo [3],

ngày 04/06/1996, tàu vũ trụ Ariane-5 đã nỗ tung ngay sau khi khỏi động được 36 giây

đo lỗi chuyển đổi một số đạng dâu phẩy động 64-bit thành giá trị nguyên dương 16-bit

‘Theo [13], tháng 2-2014 Toyota đã phải thu hỏi 1,9 triệu xe 6té Prius trén toan cau vi

lập trình hệ thống lai phối hợp hai hệ thông xăng và diện Vì vậy dộ tin cậy của các

hệ thông, xảy tỉnh là điểu quan trọng nhất trong quả trình phát triển phần mềm

ông cửa

huật kiểm tuử chơ chủng ta các chủng cứ về dộ tin cậy của hệ thông Vĩ

các kỹ thuật nảy dược thực hiện trên các mã lệnh của chương trình va tim ra các lỗi

phân tích, lỗi thiết kế và lỗi về đâm bảo tính để dùng của chương trình

Kiểm chứng mô hình (Model checking) là một kỹ thuật tự động kiểm tra tính

ding cha métmé hinh dirge sinh ra tr hu nỏ hình thoả riấn được các đặc 18 của hệ thông thì la nói mổ hình đỏ đứng đắn Nếu mô hình không thoả rnấn gác

đặc tả của hệ thống thì la nói mô hình đỏ sai, và các phân vỉ dụ sẽ được lao ra để

chứng mình mô hình sai Kiểm chứng mê hình được thực hiện tự động bởi các công cụ

kiểm chứng (Model cheoker), và một treng những công cụ hiệu quả nhật là SPIN,

Kiểm chứng mô hình la thực hiện kiêm tra bằng cách vét cạn cáo khả năng có thể xây

ra của mô hình trừu tượng Nhung trong quá trình kiểm chứng mô hình để cho việc

kiểm chứng là thực hiện được, thì một số các tính chất, đặc tã chỉ tiết của cluương trình

đã bị loại bỏ Vì vậy, đã một mô hình hệ thống đáp ứng dược đặc lâ của hộ thống, thì

các thuộc tính Hới gian; luận văn cũng nghiên cửa về ngôn ngữ Promels và

sử dụng công cụ SPTN để kiểm chứng mô hình Từ hiểu biết về kiểm thử phần tiêm và

Trang 10

kiểm chứng mô hình, luận văn dua ra phương pháp kết hợp hai kỹ thuật này Để tài thực hiệu việc kiểm chứng trên mô hình bởi công cụ SPTN và sau đó tiến hành thâm định chương trình bằng gác kỹ thuật kiểm thữ để làm tăng tính tín cây của hệ thống

1.3 Cấu trúc luận văn

Luận văn có câu trúc như sau: Chương 2 trình bây kiến thức tống quan về kiếm thử phần mềm, vả các kỹ thuật kiếm thử phân mẻm Chương 3 giới thiệu các khái niệm về kiểm chủng mỏ hinh, ưu nhược điểm của kiểm chứng mô hình, logie thời gian, các thuộc tính thời gian, và logic thời gian tuyến tỉnh Chương 4 giới thiệu về ngôn ngữ Promela, cáo kiểu dữ liệu, các quy tắc trong lập trình, cách biểu điễn các thuộc tính thời gian tuyến tỉnh và công cụ kiểm chứng SPIN Chương 5 dé xuất mô hình kết hợp kiểm chứng mô hình và các kỹ thuật kiếm thử phân mêm Việc ứng dụng công cn kiếm chứng SPTN và các kỹ thuật kiếm thử để tăng tính tin cậy của hệ thống, phân mềm sẽ được trình bảy trong chương 6 Cuối cửng là kết luận về quá trình nghiên cứu, đưa ra các kết quả đạt được và hướng nghiên cứu tiếp theo

Trang 11

Chương 2 Tổng quan về kiểm thử phần mềm

Chương 2 trình bảy tổng quan về kiểm thử phần mém va các phương pháp kiểm thử phần mềm

2.1 Tang quan vé kiểm thử phan mém

2.1.1 Chất lượng phần mềm

Trước khi nói vẻ kiếm thử phân mềm, chúng ta cần hiếu rõ khái niệm “chat lượng phản mềm.” Thee [9], chất lượng phần mềm được đánh giá theo năm góc nhìn

khác nhau như sau:

«Góc nhìn tiên nhiệm (Transcendental View): Chất lượng lá một thứ gì đỏ để dang Uuữa nhận nhưng khó dễ định nghữa Góc nhìn tiên nhiệm không đặc tâ

riêng rẽ được chất lượng phần meém nhưng có thể ứng dụng vào những phần phức tạp khác nhau trong cuộc sống hàng ngày

«Góc nhìn người đùng (User View): Chất lượng được cho là phải phủ hợp với

mụe dích Theo góc nhìn này thì khi dánh giá chất lượng của một sản phẩm, chúng ta phải đặt ra và trả lời cho một câu hỏi quan trọng là “Liêu sản phẩm có thỏa mãn yêu cầu và mong muốn của rigwời đùng hay khong?”

« Góc nhìn sản xuất (Manufacturing View}: Ở dây, chất lượng dược hiểu là sự

dap ứng được đặc lã Chải lượng ở mức độ sản phảm được xác định bởi việc là sân phẩm có gặp được đấu tä của nó hay không

œ Góc nhìn san phẩm (Product View): Trong trường hợp này, chất lượng được xem như là một đặc lính vốn có của sản phẩm

«- Góc nhìn đựa vào giá tri (Value-Based View): Chất lượng, theo khía cạnh này

phụ thuộc vào tổng giá trị mà khách hàng vui lòng trả cho nó

Khai niệm về chất lượng phân mềm và các nỗ lực để hiểu được nó theo một cách

có thể định lượng được đã bắt đầu được nghiên cứu từ những năm 1970 Trang tài liệu

về tiêu chuẩn I8O 9126 thì chất lượng, phần mềm dược dịnh nghĩa trên sảu thuộc tính

lá: tỉnh năng, tỉnh đáp ứng, tỉnh dễ dùng, tính hiệu quả, tinh cỏ thể bảo trí được và tính

khả chuyển Một rảng buộc vẻ chất lượng là một thuộc tỉnh của một yếu tổ chất lượng liên quan đến quá trinh phái triển phan mềm

2.1.2 Kiểm thử và vai trẻ của kiểm thứ

Kiểm thứ phần mềm đóng một vai trò quan trọng trong việc hoàn thành vả đánh giá chất lượng cửa một sản phẩm phản mềm 'Theo [9], chủng ta cãi tiển chất lượng của sâu phẩm bằng việc lắp dị lặp lại quá trình kiểm dui - tim lỗi — sửa lỗi trong suốt quá

trình phát triển Mặt khác, chúng ta đánh giá cách hệ thống có thể hoạt dộng đúng khi

chúng ta thưc hiện kiểm thử ở mức hệ thống tước khi bàn giáo sản phẩm Theo Triedman và Voas đã mô tâ thì kiếm thử phân mẻm 14 một quá trình thấm định cho việc đánh giá và cải thiện chất lượng phan mềm

Trang 12

‘Théng thường, các hoạt déng danh giá phần mềm dược chúa làm hai loại là: phân tích tĩnh (static analysis) va phan tich dug (dynamic analysis), Phan tich (nb 14 viéc

đánh giá chương trình mà không can thyc thi trên các mã lệnh của phương hình, nó có thể là các hoại động xem xét (reviw) lại các lãi liên đặc tâ, lài liệu thiết kế, tài liệu ca

kiểm thủ, hoặc là thanh tra ma ngudn (code imspection), Phan tích động là việc đánh giá chương trình mà cần thực thì trên các mã lệnh của chương trình, trong đỏ có +kỹ thuật kiếm thủ hộp đen và hộp trắng

Bang việc thực hiện phân tích tĩnh và phân tích động thì người kiểm thử viên

mong muền tìm được nhiều lỗi nhật có thể, để các lỗi này được sửa trong các giai đoạn

sớm của quy trình phát triển phần mềm

Xác minh (Verification) va tham dinh (Validation) la nhimg céng việc xuyên

suốt trong quá trình phát triển phần mềm, chử không phải khi đã cá mã nguồn của chương trinh Xác mình là sự kiểm tra xem phẩn mềm có thỏa mãn được yêu cầu đặc

tả của hệ thông không? Nó trả lời cho câu hỏi “Hệ thông dã dược xây dựng dúng theo đặc tả chưa?”, mục tiêu của xác minh là phát hiện các lỗi lập trình Thám dịnh là sự

kiểm tra xem phan mém có thôa mãn được yêu cầu của người sử dụng không, nó chú trọng vào sân phẩm cuỗi củng khi bản giao cho khách hàng, mục tiêu là phát hiện các lỗi về thiết kế, về đặc tả Một hệ thẳng xây dựng đúng đặc tả, nhưng chưa chắc đã đáp tửng được yêu câu của khách hàng, vì đặc tả có thể sai, thiết kê có thế thiêu chỉ tiết

2.1.3 Các mục tiêu của kiểm thử

Theo tai hệu [7],

thử viên, quân trị dự án và khách hàng Mỗi đối tượng nảy đều

cô những cái nhìn khác nhau về mục tiêu của kiểm thử

+ Chương frình hoạt động được: Cáo lập trình viên thường chỉ quan tâm

đến khia cạnh là làm thé nào để chương trinh hoạt động được trong các diễu kiện thông thường,

+ Chương trình không hoạt đồng được: Lập trình viên ít khi quan tâm đến xuột khia cạnh khác của chương trình là khi nào thì chương trình không

hoạt động dược, làm thế nảo khi chương trình bị lối

«® Giảm rủi ro của lỗi Nhà quản trị phản mềm thường quan tâm đến khia cạnh là giãm rủi ro của lỗi gây ra Hầu hết các hệ thông phân mẻm phức

tạp đều chứa lỗi - la nguyên nhân hệ thống thất bại Bởi vậy nếu các lỗi được phát hiện và sửa trong khi thực hiện kiểm thứ, tý lệ hệ thống gặp rủi

To số giảm

* Giam chỉ phí của việc kiếm thử: Chỉ phí cho việc kiểm thử bao gêm chỉ phí thiết kế, bảo trì và thực thi các ca kiểm thử; chỉ phí phần tích kết quả

thực hiện của mỗi ca kiểm thử; chỉ phí tải liệu hóa các ca kiểm thử và chỉ

phí cho hệ thống hoạt động và tài liệu hóa các hoạt dộng dó Khách hàng,

Trang 13

ác bộ ca kiểm thử hiệu quả bao phủ vimg kiểm thứ tốt với số lượng ca kiểm

muốn>, Ví dụ vẻ các ca kiểm thử cho chương trình tính bình phương của một số là các

cặp giả trị là <0, 0>

Trong các hệ thống không trạng thai (stateless systems), gia wi dau ra chi phy thuộc duy nhất vào giả trị dầu vào hiện tại, các ca kiểm thứ thường rất dơn giản Ví dụ

như là chương trình tính bình phương, của một số như ở trên

‘Trong cae hệ thống hưởng trạng thải (state-orienfed systems), giả trị đầu ra của chương trinh phụ thuộc vào cả trạng thái hiện tại của hệ thống vả giá trị dẫu vào hiện tại, thì môi ca kiểm thử có thể chứa một chuỗi các cặp <giá trị đầu vào, giá trị đầu ra

lw như trong hệ thống ATM, hệ thống chuyển điện thoại, hệ thống,

Theo lài liêu 19|, dễ kiểm thử một chương trình, một kỹ sư kiểm thử phải thục

hiện một chuỗi các hoại động như saiz

ø Xác định đôi tượng cần kiểm thủ: TIoạt động đầu tiên là phải xác định được đôi

tượng kiếm thi Déi tượng được xác định là mụo đích đề thiết kẻ một hay nhiều ca kiểm thủ đảm bảo chương trình thỏa mãn đổi tượng đó Một đối

tượng 16 rang sẽ kết noi bởi một ca kiểm thử

«Lựa chọn các giá trị đâu vào: Việc lựa chọn này dựa vào đặc tả yêu cầu, mã

nguồn hoặc mong muôn của chúng †a

rị đầu ra mong muốn: Hoạt động thủ ba là tỉnh toán giá trị đầu ra

«Tỉnh toán gửi

ương muốn cửa chương trình tương ứng với giá trị đầu vào

«+ Thiết lập môi trưởng kiểm thử của chương trình: Chuản bị mỗi trường kiểm thứ của chương trình, ở bước này tất cả các giả đinh: ngoài của chương trình phải được théa mãm Ví dụ: các hệ thống mạng, các cơ sở dữ liệu cần được thiếL

lập một cách đúng đắn

® Tiền hành kiểm thử chương trình: Trong bước thủ năm, các kỹ sư kiểm thử thực

hiện chương trình với các tập giá trí dâu vào và quan sát giá trị dâu ra thực tế

của chương trình Đề thực hiện một ca kiếm thủ, các giá trị đầu vào phải được

cung cấp cho chương trình ở các thời điểm khác nhau

Trang 14

củng là đưa ra quyết đình về kết quả hoạt động của chương trình là thỏa mãn (pass), khong thoai man (fail) yêu cầu của người dùng hay không đưa ra được

quyết định

2.1.6 Các mức độ kiểm thử

Kiểm thử phan mem là một chuỗi các hoạt động tiên hình song song cùng hoạt đông phát triển phần mềm, từ lập kế hoạch va kiểm soát quá trình kiểm thử, phân tích yêu cầu vả thiết kế ca kiểm thử, viết ca kiểm thử, tiền hành kiểm thử phan mem, danh giá các kết quả kiểm thử, báo cáo va tổng hợp các hoạt động kết thúc quá trình kiểm

thứ Mô hinh chữ V ở Hình 2.1 sẽ cho chúng ta thấy mới liên hệ giữa hoạt đông phát

triển và hoạt động kiểm thử

Các hoạt động kiểm thử bao gồm: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử

hệ thống vả kiểm thử chấp nhận Mỗi hoạt động nảy tương ứng với các pha trong phát

triển phân mềm từ đặc tả yêu cầu của khách hàng đền hoạt động lập trình

Kiem thử đơn vị được các lập trình viên thực hiện độc lập trên các đơn vị chương

trình, như là các lớp vả các hảm

Kiểm thử tích hợp được thực hiện bởi các kỹ sư lập trinh vả kỹ sư kiểm thử phần mềm nhằm đảm bảo rằng chương trình cỏ thẻ hoạt động đúng khi tích hợp các đơn vị

lại với nhau Kiem thử tích hợp tương đương với việc kiêm tra thiết kế chỉ tiết, xem

chương trình cỏ thoải mãn thiết kế chỉ tiết hay không

Kiểm thử hệ thông được thực hiện bởi kỹ sư kiểm thử và sử dụng nhiều phương

pháp, kỹ thuật khác nhau đẻ tìm ra các lỗi, sửa lỗi và đảm bảo không phát sinh những lỗi mới Kiểm thử hệ thống là một pha rất quan trọng trong quy trình phát triển phan

Trang 15

hàng

Kiểm thử chấp nhận được thực hiện bởi khách hàng, những, người sẽ kiểm tra xem phân mềm có đáp mg dược yêu cầu của người dùng hay không Quá trình kiểm thử này không nhằm mục địch tìm ra lỗi mà là đo xem sản phẩm có đáp ứng được nhục cầu của người đừng hay không

2.1.7 Các giới hạn của kiểm thử

Lý tưởng nhất lả tất cả các chương trình dễu phải hoạt déng đúng, không có lỗi xảy ra trong chương trình Nhưng thực tế là dễ chứng mình được một chương trình là

hoạt dộng dúng thị khách bàng và các nhè lập trình đều phải dựa vào việc kiểm thử

phân mẻm Theo [9], la xen xét đến hai giới hạn lớn của kiếm thử:

«Kiểm thử có nghĩa là thục thí một chương trình với một tập con đúng đắn của

miễn giá trị đầu vào của chương trình Một tập cơn đúng đẫn của miễn giả trị đầu vào được chọn bởi vi các chỉ phí phin mềm không cho phép một tập con lớn hơn được chọn, ví dụ như là tập các đầu vào đầy đủ Kiểm thử với tập các

+Khi chúng ta chọn một lập con của miễn giá lrị đầu vào, chúng la sẽ phải đối phó với van để kiếm chứng tỉnh đúng đấn của các giá trị đầu ra chương trình với các giá trị đầu vào riêng biệt Cơ chế đánh giá tính đúng đắn của giá trị

đầu ra chương trình được gọi là oracle (phán xét kiểm thử) Quyết định tính

đúng đắn của một giá trị đầu ra của chương trình là một công việc không tầm thường Một chương trinh được xem xét lả không thể kiểm thứ được (noniesiable) khi nó gặp phải hai vẫn dễ sau:

© Không tổn tại một phản xét kiểm thử,

ö Quá khó để đưa ra quyét dinh đây có phải đầu ra đúng đân

Nếu không có cơ chế dễ dánh gia tinh ding dan của một dầu ra chương trình hoe 16 lồn quá nhiều thời gian để đánh giá đầu ra, thì sẽ không đại được kết quả

nong muốn của việc thực hiện kiểm thử

2.2 Các kỹ thuật kiểm thử phần mềm

Trong kiểm thử phân mềm, chúng ta thường đủng hai kỹ thuật chính là kiếm thử tĩnh (statie testing) và kiém thir déng (dynamic testing) Kiém thử động bao gồm các kỹ thuật: kiểm thử hộp den (black box testing) va kiểm thir hép trang (white box

testing)

Ky thuật thử hộp đen là một kỹ thuật quan trọng trong hoạt động kiểm thử phân mềm, khái niệm “hộp đen” ở đây là chỉ việc kiểm thứ viên không biết chương

Trang 16

trình bên trong dược cài dặt như thế nào, họ chỉ biết rằng no phải lâm gì, vá làm như

thể nào để thôa mãn các yêu cầu đặc tả - đá được cụ thể hóa thảnh các ca kiểm thử {9|

Một số phương pháp được ap dụng trong kỹ thuật kiểm thử hộp đen: kỹ thuật phân lớp

tương đương (Equtvalcnoc pariboning), kỹ thuật phân tích giá trị biên (Roundary

value analysis), kỹ thuật dùng bảng quyét dinh (Decision table), kỹ thuật đùng bảng

chuyén trang thai (State transition) va ky thoat kiém tht ca str dung (Use case testing)

Ky thuật kiểm thử hộp trắng là một kỹ thuật được áp dụng khi ta đã biết chương trình bền trong được lập trình như thé nảo, câu trúc chương trình, các déng điều khiến,

và đòng đữ liệu chạy ra sao Kỹ thuật nảy thường tên thời gian, công sức đề thực hiện,

nên thường chi ap dụng ở mức độ kiểm thủ đơn vị - kiểm tra từng lớp, từng bộ phận

mà không thực hiện ở các mức độ cao hơn Các kỹ thuật kiểm thứ hộp trắng là: kiểm thử luậng điều khiển, kiểm thử động dữ liêu và kiểm thử miễn

‘Tuy cd rat nhiều phương pháp kiểm thử phần mềm, nhưng trong nội dung của hiên văn này, chúng ta di sầu vào việc kết hợp kiểm chứng mỏ bình, kỹ thuật phân lớp tương đương vả kỹ thuật kiểm thử đột biển Vì vậy luận văn sẽ trình bày rõ hơn về hai

kỹ thuật phần lớp tương đương và kỹ thuật kiểm thử dột biến

2.2.1 Kỹ thuật nhân lớp tương đương

Kỹ thuật phân lớp tương đương dược áp dụng khi miễn dữ liệu dau vào quả lớn

để có thể kiểm tra từng giả trị dầu vào Miễn giá trị dâu vào sẽ được chia thành một số hữu hạn các miễn nhỏ hơn có tính chất giống nhau Mỗi miễn nhỏ hon nảy sẽ dược gọi

Tả muội phân lớp Lương đương, các gia bị đâu vào trong một lớp tương đương sẽ cho

cùng ruột kết quả đầu ra

Vide phan lớp tương đương sẽ làm giảm số lượng các ea kiểm thứ, gác bộ giả trị

của phương pháp phân hoạch tương dương là

cần một số lượng nhỏ ca kiểm thữ để có thể bao phủ cả một miễn giá trị

«- Khả năng tìm ra lỗi trên cỗ miễn bao phủ là cao hơn so với phương pháp

lựa chơn triển giá trị đâu vào, và ca kiểm thử ngẫu rủ

© Phuong phap nay áp dụng dược cho cả miễn giá trị đầu vào và miễn giá trị

dâu ra

2.3.2 Phương pháp kiểm thử đột biến (mutation testing)

Kiểm thử đột biến la một cách đề đánh giả và cãi tiên chất lượng của một bộ ca

kiểm thứ bằng việc kiểm tra nêu các ca kiểm thứ cúa nó có thể phát hiện ra một số lỗi

đã dược chiên vào trong chương trình Các lỗi thường dược dưa vào chương trính bằng, việc thay dối cú pháp của mä nguồn theo các mẫu của lỗi lập trình thông thưởng

cde dt bién (amdants) Cac phién

Thường thì Nhimg 46 léch (deviation) Irong mã lệnh được gợi là

Trang 17

trong toán lử Boolcan và biểu thức đại số Ở đây, ta chỉ xem xét các phép biển đổi về

cú pháp Theo |I |, số lượng và loại phép đột biển phụ thuộc vào ngồn ngữ lập trình và

đã được xác định gọi là Ioán tử d6t bién (mutation operators)

Một toàn tử đột biển là một luậi được viết lại để định nghữa cách các thuật ngít

cu thé trong ngôn ngữ lập trình được thay thế bằng các đội biến Với việc thay thể mội

toán tử đột biến vào trang chương trình gốc thì sẽ tạo ra một đột biên mới Sau khi, tập các đột biển được sinh ra, các ca kiếm thủ được chạy trên chương trình gốc và trên

mỗi biến thể Nẻu ca kiểm thữ có thể phát hiện được một đột biển trong chương trinh

gốc, ví dụ như là ca kiểm thứ vượt qua được trong chương trinh gốc nhưng trượt trong

một đột biến, thì chúng ta nói rằng ca kiêm thứ nảy đã “loại bố” (&) được một đột

lơại hồ dược tái we dé

biến Mục liêu là phát triển một bộ các ca kiểm thir cd 1

biển Theo |9], tỷ lẻ đột bién (Mutation score) cba mot tap kiểm thứ là tỷ lê phản trăm

số các đột biển bị loại bỏ bởi cá ca kiểm thứ

1 proctypa trityre (int a; int b; int c} {

This is nok a triangle\n");

a) > printf (" This is a isso

else -> printf (" This is a scatene\n"}

biển có thể viết lại là mỗi đâu “ ” sẽ dược thay thế bằng đâu “> ” Chúng la có năm

biến thể, tương đương với năm phép biển đổi rong chương trình

Ta có một tập các ca kiểm thử của chương trình là

Trang 18

* Mutant 1: biến dỗi dòng 6 thành

ja >= b && b == c) > printf (" This is a

equilateral,

* Mutant 2: bién dai dong 6 thanh

ia — b && b > ôi -> printf (" This is a

equilateral\a™) + + Mulani 3: biến đối đòng 7 thành

(a> bl -> print£ (" this is a csosceles\n");

# Mutant 4: bién déi dong 8 thanh

» cl -> printf (" This is a -sosceles\n"};

(

© Mutant 5: bién dai đòng 9 thành

G] -» printé (" This is a -sosceles\n"):

ta >

Niu ta chay lai chwong trinh sau khi đã biển đổi cùng với bộ ca kiểm thử, chứng

ta sẽ thu được kết quả sau:

Mutant | vA Mutant 2: tat cA cdc ca kiểm thứ đều thỏa mãn Nói cách khác

18 Mutant | va Mutant 2 khéng bi “kill”

Mutant 3: chương trỉnh bị lỗi ở TƠ4 và TC?

Mutant 4: chuong trinh bị lỗi õ TƠ4, TC6 và TC?

Mutant 5: chương trình bị lỗi ở TƠ4 và TỪ?

Nếu tính toán tỷ lệ đột biển, chúng ta sở thấy rằng vị

trong năm đột biến được phát hiện ra, và tỷ lệ lá 60% Vì thể ta cần thêm các ca kiểm thử dé phát hiện ra dot bién Mutant 1 va Mutant 2

# TCS: (<3, 2, 2, isosceles)

« TClO«

Lite nay thi bé ca kiém thử mới phát hiện được hết các dét bién, va ty 1é dét bién

bay gid la 100%,

'Theo [9†, kỹ thuật kiểm thứ dột biến được thực hiện qua các bước sau

© Bude 1: Bat déu với mnột chương trình P, và xuôi tập các cả kiểm thử T cho trước được cho là chính xác

* Hước 2: Lhực hiện các ca kiểm thứ trong tập T trên chương trình P Nếu

một ca kiểm thử bị lỗi, có nghĩa là dầu ra của chương trình không dúng,

năm đột biến thủ chỉ ba

3, 2>, isoscclos)

Trang 19

tiếp tục thực hiện bước 3

® Bude 3: Lạo một bộ các đột biển {Pj}, mỗi đột biến là một thay đổi nhớ

trong củ pháp của chương trình P

® Bude 4: Thực hiện các ca kiểm thử trong T trên mỗi đột biên P¡ Nếu đầu ra của đột biển P; khác với đầu ra của chương trình góc P, thì đột biến P¡ được xem là không chính xác và bị loại bỏ bởi ca kiểm thứ Nếu P; có kết quả đầu

ra chính xác nhu kết quả của chương trình gốc P khi kiêm thử trong T thì

một trong các trường, hợp sau là dúng

o PvaPj la tuong đương Có nghĩa là hành vị của chúng không khác nhau

bởi bất kỳ tập các ca kiểm thứ tảo Tu ý là rất khó để đánh giá được là

P và P; lương đương trong Tưực tê

© Pi cé thể bị loại bỏ Có nghĩa là, cáo ca kiếm thử đã không loại bỏ được

đột biến P; Trong trường hợp này, cáo ca kiểm thử mới sé duoc tao ra

œ Bước 5: Tính toán tỷ lê đột biển của lập các ca kiểm thử T Tỷ lệ đột biển

100 x D+ (N — £), trong dó D là các đột biểu dã bị loại bỏ, N là tổng số

dột biến, E là số dột biển tương đương,

«© Bước 6: Nếu tỷ lệ đột biển ở bước 5 lả không cao, thi cần phải thiết kề các

ca kiểm Thử mới phân biệt P; với P, thêm các ca kiểm thử mới vào tập T, vào

quay lại bước 2 Néu ty lệ đột biến ở rưức độ tương đương với kỷ vọng, thì chấp nhận tập T như là một dộ do tốt cho tính dùng, dẫn của chương trình P với tập các đột biển P„và ngùng thiết kế các ca kiểm thứ mới

“Theo [9], kiểm thứ đột biên đưa ra hai giá dụnh quan trọng:

* Gia thuyél cac lập trình viên có trình độ (Coơmpeleml Programmer

Hypothesis) i ng các lập trình viên đều có trình độ, họ không tạo ra

các chương trình mội cách ngầu nhiên Chỉmg ta có thé giả sử rằng rnội

lập trình viên sẽ viết ra các chương trình đứng đắn với một vài lỗi nhỏ

Các lỗi nhỏ nảy được xem như lä một sự sai lệch nhỏ so với chương trình

gốc Các lỗi này thường được gọi là các toán tử đột biến, gây ra những sai lệch nhö một cách có hệ thống trong chương trinh

« Hiệu ứng cặp dai (Coupling Effect): Gia dink nay được đưa ra vào năm

1978 béi nhả khoa học deMillo va đồng sự Giá định nay nói rằng các lỗi phức tạp là những cặp lỗi đơn giản và nêa mà một bộ kiểm thứ phát hiện

ra tất cả các lỗi đơn giản trong chương trình thì sẽ phát hiện ra các lỗi

phúc tạp

Kiểm thử đột biên giúp cho các kiểm thử viên có thể tự tin về chương trình của mình Nhưng số lượng các đột biến dược sinh ra và các ca kiểm thử dễ loại bỏ dược

nó là rất lớn Vì vậy, chúng ta cần có chiến lược dễ có thể áp dụng kỹ thuật kiểm thữ

đột biển mội cách hiệu quả.

Trang 20

Chương 3 Kiểm chứng mô hình

Chương 3 trình bảy các khái niệm vẻ kiểm chứng mô hình, quy trình thực hiện việc kiểm chứng mô hình, các ưu nhược điềm, thuộc tỉnh của mô hình vả các công cụ

để kiểm chứng

3.1 Khái niệm kiểm chứng mô hình

Trước khi nỏi vẻ kiểm chứng mô hình, thì chúng ta cần nhắc đến khải niệm vẻ

các phương pháp hình thức (/ormal methods) Theo [3], các phương pháp hình thức

được coi như lả việc áp dụng các kiến thức toán học ứng dụng vảo việc mô hỉnh hoá

vả phân tích các hệ thông thông tin Các phương pháp hình thức lả một trong những kỹ

thuật thâm định các hệ thống thông tin được đánh giá cao Ngảy nay, các phương, pháp hình thức, vả kiểm chứng hình thức đã được áp dụng trong các viện nghiên cứu vả

giảng dạy trong các trường đại học

Kỹ thuật kiểm chứng dựa vào mô hình là căn cứ vào mô hình mô tả các hành vi

có thể của hệ thông bằng các công thức toán học chính xác vả không nhập nhằng Các

mô hình hệ thống được đi kèm theo bởi các thuật toán dỏ tìm tất cả các trạng thái của

mô hình hệ thông một cách tự động Điều này cung cấp các nên tảng cho một loạt các

kỹ thuật thẩm định từ thăm dỏ vét cạn (kiểm chứng mô hỉnh) tới kiểm tra bằng thực

nghiệm trên mô hình (mô phỏng) hoặc trên thực tế (kiểm thử)

Kiểm chứng mô hình là một kỹ thuật trong kiểm chứng hình thức (Formal

Verification) No nim trong môi tương quan giữa đặc tả hình thức (Formal

Specification) va su tong hop hinh thite (Formal Synthesis)

Kiểm chứng mô hình (Model checking) la mot kỹ thuật automat dùng đề kiểm

chứng các hệ phản vệ (re-active systems) cỏ hữu hạn trạng thải, ví dụ như là các thiết

Trang 21

trong logic mệnh để thời gim (propositional temporal logie) và hệ phân về được mơ

hình hố thành ruột đồ thị chuyển tang thai (state — transition graph) Mat edch tim

kiếm hiệu quả đã được sử dụng để quyết định một cách tự động xen đặt lã cĩ được

thỗ mãn bởi đĩ thị chuyển trạng thái hay khơng Kỹ thuật nảy đã được phát triển từ năm 198] béi Clarke va Allen Emerson Trong khi dé, Quielle va Sifakis cting déc lap

phát triển một kỹ thuật kiếm ching tong tu ngay sau đỏ

Ky thuật kiếm chứng mơ hình cĩ một số tmì điểm quan trong trong việc chứng mình các lý thuyết về cơ khí họe hoặc kiếm tra việc kiểm chứng trong các mạch và

phương thủe giao tiếp Quan trọng nhất là nỏ hoạt động tự động ở mức cao Thơng

thường, người dùng cung cấp một thể hiện ở mức độ cao của mơ hình va đặc tá cần

kiểm tra Bộ kiểm chứng mơ hình sẽ chạy đến khi nĩ trả về kết quả là dùng (true), túc

là mơ hình thoả mãn duợc các đặc lễ, hoặc nổ sẽ dưa ra các phân vỉ dụ

(ooumlercxample) dễ chỉ ra rằng mơ hình khơng được thoả mãn Các phan vi du nay rat quan trong trong viée tim kiếm các điểm cĩ thế gây lãi trong các hệ phân vệ phức tạp

Kiểm chứng mơ hình thực ra chính là quá trình khám phả tất cả cáo trạng thái

cĩ thế của hệ thơng bằng phương pháp vét cạn Nĩ tương tự như việc vét cạn tắt cã các +khã năng đặt quân hận trong bài tốn 8 — hậu, hay là tìm kiếm tất cả các nước cĩ thế thắng trong cờ vua Kiếm chứng rơ hình sẽ là một thách thức lớn khi mà khơng gian trạng thải tìm kiểm trở lên lớn hơn Kiểm chứng mổ hình cĩ thể tìm ra nhiều lỗi Hểm

an ma ching ta khơng tim được bằng phương pháp kiểm thứ hay mơ phỏng thơng

thường,

Các thuộc tính thơng thường cĩ thể được kiểm tra băng kiểm chứng mơ hình là các đặc diễm định tính tự nhiên: Kết quả sinh ra cĩ dung khơng? Hệ thơng cĩ thể trái qua một tỉnh huỗng khố chết khơng? Khi hai tiến trình tương tranh dễu chờ nhau thì

cĩ gây ra hiện tượng treo ở các phẩn cịn lại của hệ thống khơng? Các thuộc tỉnh thời

gian cũng cĩ thể được kiểm chứng: Một khoa chết cĩ thể xây ra trong 1 giờ san khi hệ thống phục hồi khơng? Hay, một phan hỗi cĩ luơn được nhận sau mỗi 8 phút khơng? Kiế ứng rnơ hình yêu cầu một phát biểu chính xác và khơng nhập nhằng của các thuộc tính được kiểm chứng,

Mơ hình hệ thơng thường được sinh ra một cách tự động từ một mơ tã mơ hình

được đặo tả trong vải ngơn ngữ lập trinh thích hợp như C, Jeva hoặc các ngơn ngữ đặc

tã phần cứng như là Verilog hay VIIDL Lum ý rằng: cáo đặc tả thuộc tính quy định hệ thơng nên lâm gì và khơng được làm ai, trong khi đỏ mơ bình định vị cách hệ thống hoạt động Bộ kiểm chủng mơ hình thực hiện chỉnh xác tất cá các trạng thải hệ thơng

để kiểm chứng xem chúng cĩ thộ mãn thuộc tỉnh mong dợi Nếu một trạng thái khơng,

Trang 22

người dùng có thể chạy lại tỉnh huồng vi phạm, nỏ chứa các thông tin hữu ích cho việc

gỡ lỗi, và đáp ứng của hệ thống,

3.2 Quy trình kiểm chứng mô hình

Các giai đoạn trong quy trình kiểm chứng mô hình (cách giai đoạn này được mô

Hình 3.2 Cách tiếp cận kiểm chứng mô hình

© Giai doan mé hinh hoa (Modeling phase):

o Méhinh hé thong dang xem xét sử dụng ngôn ngữ mô tả mô hình của bộ kiểm chứng

o Glan kiém thử tỉnh đúng đẫn (sanity check) đầu tiên và đánh giá nhanh

mô hình sẽ thực hiện vài mô phỏng;

© Hinh thie hoa thuéc tinh can kiểm chứng dùng ngôn ngữ đặc tả thuộc

tính

©- Giai đoạn thie thi (Running phase): chay bộ kiếm chứng mô hình đẻ kiểm tra

tỉnh hợp lệ của thuộc tính trong mô hình hệ thông

© Giai đoạn phân tich (Analysis phase)

o Néu thuộc tỉnh được thoả mãn? —› Tiền hành kiểm tra thuộc tính tiếp

theo (nêu có);

© Neu thuéc tinh bi vi pham? >

1, Phan tich phan vi dụ được sinh ra bởi bộ mô phỏng,

2 Lam mịn mô hình, thiết kẻ, hoặc thuộc tính;

3 Lap lai toan bộ thủ tục trên.

Trang 23

©_ Nếu bị tràn bộ nhớ? —> Cổ gắng thu gọn mô hình và thứ lại

'Thêm nữa là toàn bộ quả trình kiểm chứng nên được lập kế hoạch, quản lý và tổ chức Quả trình nảy được gọi là “Ô chức kiểm chứng

Mô hình hoá (Modcling) Diễu kiện đầu vao cần thiết cho việc kiểm thứ mô

hình là một mô hình của hệ thống đang được đánh gia và một đặc điểm hình thức của của thuộc tính cần kiểm chứng

Mô hình của các hệ thống mỏ tã hành vi của hệ thống theo một cách chỉnh xác

và không nhập nhằng Chúng thường dược biểu diễn bởi một otomat hữu hạn trang

thải (Trite-state autoraata), là một tập hữu hạn các trang thái và tập các phép chuyển

Các trang thái bao gồm thòng tì về các giá trị hiện tại của biển, biểu thức đã duợc thực thủ trước đó Các phép chuyển mô tả cách hệ thông chuyển từ một rang thai nay sang một trạng thái khác Trong các hệ thống thực tế, otomat hữu hạn trạng thái được

mô tả bằng một ngôn ngữ mẽ tả mô hình (model đescriptien language} như là các nở

rộng tương ứng của ngôn ngữ C, Java

Để việc kiểm chứng được chính xác, các thuộc tính cản được mô tả mệt cach

chính xác vả không nhập nhằng, Nó thường được mô tả bởi một ngôn ngữ đặc tả thuộc

tinh (property specification language) Ở đây chúng ta tập trung vào sử đựng logie thời

gian (femporal logic) như là một ngôn ngữ dặc tả thuộc tính, là một kiểu logic thich

hop cho việc đặc tả các thuộc tỉnh của các hệ thông thông tin Trong logic toàn học, nó kiểm tra rằng, đặc tả hệ thống là một mô hình của công thức logic thời gian Nó giúp

giải lách ý nghĩa của cưm từ “Kiểm chứng mô hình” T.ogie thời gian là một mở rộng,

cia logic ménh dé truyén théng với các toán từ liên hệ tới hành vì của các hệ thống,

No cho phép đặc 1ä cho một loạt các thuộc tỉnh của hệ thông như là tính đúng đấm cửa chitc nang (functional correctness - hé thông lảm những gì mã nó được mơng muốn là

sẽ thực hiện), khả năng có thẻ đạt tới được (reacbability - nó có thể kết thúc trạng thái khoả chết?), tình an toàn (safety - diều tôi tệ sẽ không bao giờ xáy ra7), tính hoạt dộng, được (liveness những diễu tốt dẹp sẽ xảy ra?), tình ôn định (fairness dưới các diều kiện giống nhau, một sự kiện diễn ra lặp lại?), và các thưộc tỉnh thời gian thục (hệ thống sẽ thực hiện đúng giờ?)

Chay Bé kiém chimg (Running the Model Checker) Dau tiên, Bộ kiểm

chứng khởi tao vide thi ap cac hia chon va eac chi thuc

khác nhau thích hợp đ

tiện việc kiểm chứng vét Sau đó, quả trình kiểm chứng mô hình thật sự sẽ diễn ra

Việc kiểm chứng này cơ bân là dùng một cách tiếp cận thuật loán duy nhất để

xem xét tính hợp lệ của thuộc tỉnh đang đánh giả xem nó có được kiểm tra trong tất cả

các trạng thái của mô hình hệ thông

Phân tích các kết quả (Analyzing the Results) Có ba trường hợp có thế xây

ra: thuộc tính được đặc tả thoả mãn mô hình đã cho hoặc không thoả man, hodc m6

hình trở nên quá to đối với các giới hạn vật lý của bộ nhớ máy vị tỉnh

Trang 24

Trong trưởng, hợp thuộc tính thố mãn, các thuộc tỉnh tiếp theo sẽ cỏ thể dược

kiểm tra, hoặc trường hợp tất cả các thuộc tính đã được kiểm ta, thì trõ hình sẽ được

kết luận là thộ mãn lật cả các thuộc Lính mà nĩ đời hồi

Khi một thuộc lính khơng thộ mãn, kết quả tiêu cực cĩ thể xây ra đo các nguyên nhân khác nhau Cĩ thể là do quả trình mơ hình hố bị lỗi mơ hình khơng phân ảnh đúng thiế

phép kiếm chứng này khơng cỏ giá trị với mồ hình mới Xếu lỗi phân tích chỉ ra rằng,

khơng cĩ sự sai khác một cách bất thường giữa thiết kế và mỏ hình của nĩ, sau đĩ cĩ thể là một lỗi thiết kế hoặc một thuộc tỉnh lỗi đã xáy ra Lrường hợp cĩ một lỗi thiết

kể, việc kiểu chứng sẽ bao gồm cả kết quả sai, và thiết kế (cùng với mỏ hình của nĩ)

phải dượu cải tiến Nếu là do lỗi của thuộc tính đã khơng phất ánh dùng yêu cầu phi

hình thức dễ kiểm chứng thủ thuộc tính này cân được sửa lại, và một quá trình kiểm chứng mới của mư hình sẽ được thực hiên Bởi vỉ mơ hình khơng thay đối nền ta khơng cản kiểm chứng lại các thuộc tính đã kiếm chứng trước đĩ Một thiết kê được

gọi là kiếm chứng khi và chỉ khi tắt cã các thuộc tính được kiểm tra cần thận với một

mé hinh dung

Khi mơ hình qua lớn đề cĩ thể điều khiến — khơng gian trạng thái của các hệ thơng thật cĩ thể lớn hơn rất nhiều so với khá năng lưu trữ của các bộ nhớ hiện tại — cĩ nhiều cách khác nhau để tiếp tục Một kha năng là ứng dụng các kỹ thuật để cĩ gắng khai thác các quy tắc ân trong câu trúc của mơ hình Ví dụ của những kỹ thuật này là thể hiện các khơng gian trang thái bằng các kỹ thuật ký hiểu như là các lược đỗ quyết

định nhị phân (binary đecision diagrams) hay làm giảm thứ tự riêng phân (partial order

ređuction) Một cách khác đề giải quyết các kÌ

lơng gian trạng thái quả lớn là từ bỏ tỉnh

chính xác của kết quả kiếm chứng Các cách tiếp cận kiểm chứng xác suất khám phá chỉ mệt phân của khơng gian trang thai trong khi dua ra một sự hy sinh (một cách khơng đáng kể) trong độ phủ của kiểm chứng

niên quản lý phiên bản và cầu hình của các lản kiểm chúng Các thơng tin này cần được

‘yan ban hoa va bao tri cân thận để quãn lý quá trính kiểm chứng mơ hình thực tế và cho phép thực hiện lại các quả trình dĩ

3.3 Ưu và nhược điễm cũa kiểm chứng mơ hình

3.3.1 Un điểm của kiểm chứng mơ hình

®_ Dây là một cách tiếp cận kiểm chứng phố biến mả cĩ thể áp dụng trong các ứng

dụng khác nhau như các hệ thống nhúng, kỹ nghệ phản mềm và thiết kế phần

cứng

Trang 25

3.3

* _ Hỗ trợ kiếm chứng cục bộ (partial verificatien), ví đụ như các thuộc tính có thể

được kiếm chứng độc lập, và cho phép tập trung vào các thuộc tính quan trang

trước Nẻ không đói hỏi đặc tả các yêu cầu một cách hoàn chỉnh

+ Không ảnh hưởng tới khả nắng xây ra cửa một lỗt được phát hiện; điều mày trải ngược với việc kiểm thử và mồ phỏng — vốn có mục đích lä tìm vết những lỗi

có thể xảy ra nhất

+ Cứng cấp các thông tin chuẩn đoán rong trường hợp một thuộc tính là không

giá trí; nó rất hữu ích cho mục đích gỡ rồi

* Day là một công nghề “nhân nút” (“push - button” technology) cé tiém năng, việc sử dụng kiểm chứng, mô hình yêu cầu không chỉ là mức độ tương tác cao của người đùng mâ còn cần có kinh nghiệm cao

* Phuong phap nay dược yêu thích trong quy trình phát triển phản mềm nhanh rất dược ưa thích trong cỏng nghiệp

«- Có thể dễ đảng tích hợp với vòng đời phát triển sẵn có;

® Có niên tảng đúng đần và chính xác; nó dua vào lý thuyết về các thuật toán đỗ

thị, các câu trúc đữ liệu và logie

2 Nhược điểm cửa kiểm chứng mô hình

® Phương pháp nảy chú yếu thích hợp với các ủng dụng hướng điều khiển hơn la các ứng dụng hướng dữ liệu bởi vị đữ liệu thường vượt quá các miễn võ hạn

© Khả năng 4p dụng của nó lrong lĩnh vực liên quan đến các vẫn để mang tỉnh quyết định; trong các hệ thông trạng thái võ hạn, hoặc hệ lập luận với các kiểu

đữ liệu trừu tượng (yêu câu legic không tất định hoặc ban tất định), kiểm

chứng mê hình Không mang lại nhiều hiệu quả tính toán

e Nó kiếm chứng một mô hình hệ thống, và không phải là một hệ thông thật sự

(mật sản phẩm hay bản mẫu) của nả, bắt kỷ kết quả mảo cũng chỉ tắt tương img với mô hình hệ thống Các kỹ thuật bố sung như là kiểm thử là cẩn thiết đề tim

ra lỗi sản xuất (đổi với phần cửng) và lỗi lập trinh (đổi với phần mắm),

« Nó chỉ kiếm tra các yêu cầu đã được trạng thái, nó không bảo đâm tính toàn vẹn Tỉnh hợp lý của các thuộc tính không được kiểm chứng có thể không được

dam bao

ø Nó phải đối mặt với vấn để búng nỗ không gian trạng thái, số các trang thái cẩn

cho mô hình hệ thông chính xác có thẻ dé đàng vượt quá bộ nhớ của máy vi

tính

«_ Việc đùng nó yêu cầu một vải kinh nghiệm trơng việc tìm ra các trùu tượng hoá

phủ hop dé lam cho các mô hình hệ thẳng nhô hơn vả trạng thải của các thuộc

tính trong logic hình thức dủng được

© Nó không đâm bảo cho ra các kết quả chính xác hoàn toàn: vì cũng như các

công cụ khác thủ Bộ kiểm chứng cũng là một phần mềm có thể có lỗi

Trang 26

e Nó không cho phép kiểm chứng tỉnh tổng quát: thông thường, các hệ thông kiểm chứng với một số tuỳ ý các thành phần, hoặc các hệ thông đã được tham

số hoá là không thể bị lửa đôi Các hệ thống nảy có thẻ được kiểm chứng bằng cách dùng các chứng minh

3.4 Logic thời gian tuyến tính (Linear Temporal Logic - LTL)

3.4.1 Trạng thái thời gian tuyến tính (Linear-Time Behavior)

Theo [3], để phân tich một hệ thống may tính được thể hiện bằng một hệ thống, chuyén (transition system), ca hai cach tiép can dua vao hành động (action-based) va

dựa vao trang thai (state-based) đều có thể sử dụng được Cách tiếp cận hướng trạng

thái trừu tượng hóa từ các hảnh động thay vi chỉ trừu tượng hỏa các nhãn chuối trang thái được lẫy ra để xem xét Ngược lại thì cách tiếp cân hướng hành động trim tượng

hỏa từ các trang trải vả liên hệ tới các nhãn hành đồng của các phép chuyên

a Céc hé thong chuyén (transition systems)

Theo [3], các hệ thông chuyên thường được dùng trong khoa học máy tính như

là các mô hình đề mô tả hành vi của các hệ thông Thông thưởng, chúng là những đồ

thị có hưởng với các đỉnh thẻ hiện cho các trạng thái, và các cạnh mô phỏng cho việc

chuyển trạng thải Các phép chuyên đặc tả cách hệ thông cỏ thể chuyên tử một trạng,

thải này sang một trạng thải khác

GO day ching ta dùng các hệ thống chuyển với định danh hảnh động (action

names) cho các phép chuyên vả các mệnh đẻ nguyên tử cho các trạng thái Định danh

hành động sẽ được dùng đề mô tả cơ chế giao tiếp giữa các tiền trinh Mệnh đề nguyên

tử được đủng để mô hình hóa các thuộc tỉnh thời gian, chủng thường biểu biển các sự

thật một cách đơn giản vẻ các trạng thái của hệ thông đang xem xét

Định nghĩa 3.1 Hệ thống chuyển (Transition System — TS)

Một hệ thông chuyên TS là một bộ (8, Act, —, I, AP, L), trong đó:

e_ S là một tập các trạng thái,

« - Actlà một tập các hành động kỷ hiệu là ơ, B ,

© +&S x Act x $laphep chuyên,

© TC S là một tập các trang thái bắt đâu,

© AP la một tập các mệnh đề nguyên tử, thường kỷ hiệu bằng các chữ cái a, b,

c, de, f

e L:S ¬ 2ÊP là hàm gản nhãn

TS được gọi là hữu hạn nếu 8, Act và AP là hữu hạn

Định nghĩa 3.2 Các tiền tổ và hậu tố trực tiếp (Direct Predecessors and Successors)

Trang 27

Với TS = (S, Act, —, I, AP, L) la mét hé thong chuyên Với mỗi trạng thais € $

va méi hanh déng @ € Act, tap cac hau té # trực tiếp của s được định nghĩa như sau:

Post (s,«) ={s' €S|s Š sĩ }, Post(s) = Ux cacePost (5-*) (3.1)

Céng thite (3.1) chi ra ring tap cae hau t6 Pest (s,c¢) ciia trang thai s với hành

động œ là tập các trạng thái s” thuộc 8, sao cho s” lả kết quả của phép chuyển tử trạng

s sau khi thực hiện hảnh động #; tập các hậu tô Pøst(s) của trạng thái s là tập hợp tất

cả các trang thái tiếp theo s” của s với tất cả các hành động œ của Act

TTập các tiên tô œ trực tiếp của s được định nghĩa như sau

Pre (s,«) ={s° €Sls' Š s}, Pre(s) = U„;¿„Pre(s%) — @2)

Công thức (3.1) chỉ ra rằng tập các tiên tổ Pre (s, %) của trạng thái s với hành

động œ là tập các trạng thải s” thuộc §, sao cho s” là trạng thái xuất phát của phép

chuyên đề đạt được trạng thái s sau khi thực hiện hành động ; tập các tiên tô Pre (s} của trạng thái s lả tập hợp tất cả các trạng thái xuất phát s” của s với tất cả các hành

dong @ ciia Act

Định nghĩa 3.3 Trạng thái kết thúc (Terminal States)

‘Trang thai s trong hệ thông chuyển TS được gọi là kết thúc khi vả chỉ khi tập các hậu tỏ của s rồng: Post(s) = ø

Định nghĩa 3.4 Thực thi (Execution)

Một thực thi của hệ thống chuyển TS là một đường thực thi tử ban đầu và dai nhật

Định nghĩa 3.5 Các trạng thái có thể đạt được (Reachable States)

Với T§ = (S, Aet, —, I, AP, L) là một hệ thống chuyển Một trang thai s € S

được gọi là đạt được trong hệ chuyên TS nêu có tôn tại một đường thực thi từ ban dau

và hữu hạn

«1 #2 #n

Sp PS 2 —S„ =6 Reach (TS) là ký hiệu của tập tất cả các trạng thái đạt được trong hệ thống

chuyén TS

Cỡ của hệ thông chuyền thẻ hiện sự phát trién theo ham mii trong cac thanh phan,

vi dụ như là số biến trong một đồ thị chương trình hay số thành phần trong một hệ

thống tương tranh Nó được gọi là vẫn đẻ bùng nỗ không gian trạng thái

Trang 28

b._ Các đường và đỗ thị trạng thái (Path and State graph)

Định nghĩa 3.6 Dé thi trang thai (state graph)

Đồ thi trạng thái của TS ký hiệu lả G(TS) là một bộ (V, E) với các đỉnh V = S va

các cạnh E = { (s,s” }€ § x § |s” € Post(s)} với các đỉnh s, s” thuộc tập trạng thải

§ và sˆ thuộc tập trạng thái hậu tô của trạng thái s

Định nghĩa 3.7 Đường dẫn (Path)

Một đường dân của hệ chuyên TS là một đường dẫn phân mảnh từ điểm bắt dau

và dài nhất Tức là đường dẫn sẽ đi từ trạng thái bắt đâu đền trạng thái kết thúc của đỏ

thi

Paths(TS) là kỷ hiệu cho tập tất cả các đường dẫn trong T§ Vả Pathsg„ (TS) là

tập tất cả các đường dân khởi dau, hitu han ciia TS (fin la tir viet tat của finite - hữu

hạn)

© Vét (Trace)

Dinh nghĩa 3.8 Vết và lần vết (Trace)

Với TS = (S, Act, >, I, AP, L) la mét hé thong chuyén không có trạng thái kết

thúc Một vết của đường dẫn vô hạn x = so $1 duge dinh nghia la Trace (x) = L(so)

Lí(ị) Vết của đường dẫn hữu hạn 8# = sạ s; s„ được định nghia la Trace (i) =

Lí) L(s) La)

'Vết của một đường dân cỏ thẻ là hữu hạn hoặc vỏ hạn

3.4.2 Thuộc tính thời gian tuyến tính

Các thuộc tính thời gian tuyến tính (Linear- Time properties) đặc tả các vết mà

một hệ chuyên nên thẻ hiện Nói một cách khác lả thuộc tính thời gian đặc tả hành vi

có thể chấp nhân được (được hy vọng) của hệ thông đang xem xét

Định nghĩa 3.9 Thuộc tính thời gian tuyến tính (LT Property)

Một thuộc tính thời gian tuyên tỉnh trên tập các mệnh đề nguyền tử AP là một tập

con của (22%),

Trong đó (2*?)° là ký hiệu của tập từ được tạo ra từ các kết hợp vô hạn của các

từ trong 2P Một thuộc tính thời gian tuyến tính là một ngôn ngữ (tập hợp) vô hạn các

từ trong bảng chữ cái 2®,

Định nghĩa 3.10 Mối quan hệ thỏa mãn các thuộc tính thời gian tuyến tính

(Satisfaction Relation for LT Properties)

P lả một thuộc tính thời gian tuyen tinh trén AP va TS = (S, Act, +, I, AP, L) la một hệ chuyển không cỏ trạng thái kết thie TS = (S, Act, —, I, AP, L) théa man P, ky higu la TS = P Khi vào chỉ khí vết của TS la tap con của thuộc tinh P

Traces(TS) & P Trang thais € S thoa man P, ky hiéu las © P khi Traces(s) © P

Trang 29

vét của nó đều thỏa mãn P, nếu tất cả các hành vi của nó là chấp nhận được Một trạng thái thỏa mãn P khi tất cả các vết bắt đầu từ trạng thái nảy đều thoả mãn P

3.4.3 Các thuộc tính an toàn (safety properties)

Các thuộc tính an toàn thường mô tả lả “không có gì tôi tế cỏ thể xây ra` (nothing

bad should happen) Vi du trong bài toán mutual — thuộc tỉnh luôn luôn có nhiều nhật

là 1 tiền trình trong đoạn găng — đây lả một thuộc tính an toàn cơ bản

a Bat bién (Invariants)

Trong thực tế, thuéc tinh safety 6 trén la mét trudng hop cu the ctia invariants

Bat bién la nhimg thudc tinh thoi gian tuyên tính được định nghĩa bởi 1 điều kiên ®

cho các trạng thái và yêu câu ® giữ tắt cả các trạng thái có thể đạt được

Định nghĩa 3.11 Bất biến

Một thuộc tỉnh thời gian tuyên tính Pạ„ trên AP là bắt biển nêu có một công thức

logic ménh dé ® trên AP thỏa mãn

Pạ„y =Í Áo A¡A; €(24P) |VJ >0,A,E®} 6.3)

€ được gọi lả một điều kiện bắt biến (hay là một điều kiện trạng thải) của Pạu Công thức (3.3) chỉ ra rằng Pạ„ một tập các từ trong bảng chữ cái (2ÊP ) sao cho các từ nảy thoả mãn công thức logie mệnh đề ®

Luu y rang

TS E P„„y khi và chỉ khi trace(r) € Pip, voi tat ca dudng dan x trong TS

khiva chikhiL(s) F # voi tat cả trang thải s thuộc một đường dan của TS khi và chỉ khi L(S) E_ # với tất cả trạng thái s € Reach(TS)

Khải niệm “bất biển” cỏ thê giải thích như sau: điều kiên ® được thoả mãn bởi

tắt cả các trạng thải ban dau va tinh thoả mãn của ® là bất biến đưởi mọi phép chuyên

trong đường dần có thê đạt được của hệ thông chuyên Ngoài ra, nêu œ giữ trạng thải

nguồn s của phép chuyển thì ® cũng sẽ giữ trạng thái đích s” của phép chuyền

b Thuộc tỉnh an toàn

Định nghĩa 3.12 Thuộc tính an toàn, các tiền tổ xấu (Safety properties, bad

prefixes)

Một thuộc tính thời gian tuyến tính P„„ trên AP được gọi là một thuộc tính an

toan neu tat cd cae tira € (24°)*\ Pie khi ton tại một tiền tổ hữu hạn £ của ơ thỏa mãn:

P,„r; ({ơ° 6 (2°3“ | ê là một tiền tố hữu hạn của ø”} = ö

Bất kỳ từ hữu hạn đ được gọi lả một tiên tố xấu của P„„ Một tiên tố xâu nhỏ nhật của P,„œ kỷ hiệu là một tiên tổ của P.ø khi không có tiên tổ nảo của đ là một tiên tổ xấu của P„, Nói cách khác là các tiền tố xấu tối thiểu lả các tiên tố xấu cỏ độ

Trang 30

đài tôi thiểu Tập tất cả các tiên tổ xáu của P„œ kỷ hiệu là BaảPreƒf(P;;;), tập hợp tắt cả cac tién té xau nhé nhat la MinBadPref(P./)

Định lý 3.13 Mối quan hệ thỏa mãn cho các thuộc tính an toàn (Satisfaction

Relation for Safety Properties)

Cho hệ chuyển TS không có trạng thái kết thúc vả một thuộc tỉnh an toan Pyate

TS E_ P;„;¿ khi và chỉ khi Tra£es;„„ (TS) n BadPre(P,s¿)= 0 (3.4)

Công thức (3.4) chỉ ra rằng hệ chuyên TS thoả mãn thuộc tỉnh an toàn P,„; khi

và chỉ khi không có tiền tỏ xâu nào của P;„;; trên các vét có kết thúc của hệ chuyên

TS

3.4.4 Các thuộc tính hoạt động dugc (liveness properties)

Các thuộc tính được gọi là thuộc tính “hoạt động được”, chúng tuyên bồ ring

“những điều tốt” sẽ xảy ra Trong khi các thuộc tính an toàn bị vĩ phạm trong thời gian

hữu hạn bởi một hệ thông hữu hạn, thì thuộc tính hoạt động được bi vi phạm trong thời gian vô hạn bởi một hệ thông vô hạn

« Thuộc tỉnh hoạt động được

Định nghĩa 3.14 Thuộc tính hoạt động được

“Thuộc tính thời gian tuyển tính LT Pụy trên AP lả một thuộc tính hoạt động được

khi preƒ (P„,) = (22°)ˆ

Vi vậy, một thuộc tỉnh hoạt động được (trên AP) lả một thuộc tỉnh thời gian

tuyến tỉnh P mả mỗi từ hữu hạn có thê được mở rộng thành một từ vô hạn thỏa mãn P

Với các trạng thái khác nhau, P là một thuộc tỉnh hoạt động được khi vả chỉ khi tất cả

các từ hữu hạn w £€ (2P)” cỏ tổn tại một từ vô hạn ø € (2”)” thỏa mãnwø € P

b So sảnh các thuộc tỉnh an toàn và thuộc tính hoạt động được

Phan nảy nỏi về môi quan hệ giữa thuộc tỉnh an toản vả thuộc tính hoạt động được Cụ thể là nó sẽ trả lời cho hai câu hỏi sau

e Cac thuéc tinh an toản và thuộc tính hoạt động được có tách rời nhau không?

œ Một thuộc tính thời gian tuyên tính bắt kỳ là thuộc tính an toàn hay thuộc tính

hoạt động được?

Với câu hỏi đầu tiên các thuộc tỉnh an toàn và thuộc tính hoạt động được thực sự

là tách rời nhau Nói một cách chính xác hơn thì nó chỉ ra rằng một thuộc tính có cả

hai tỉnh chất là an toàn và hoạt động duoc 1a rat han che

Câu hỏi thứ hai là kết quả trong một câu trả lời phủ định Với bắt kỳ thuộc tính

thời gian tuyên tỉnh P nảo cũng sẽ cỏ một thuộc tỉnh thời gian tuyến tỉnh P° tỏn tại một

sự kết hợp (như lả phép giao) của một thuộc tính an toàn và một thuộc tính hoạt động được

Định lý 3.15 Giao của các thuộc tính an toàn và các thuộc tính hoạt động được

Trang 31

thuộc tính hoạt động được là (25Ẻ)“

3.4.5 Sự công bằng (fairness)

Một khia cạnh quan trọng của hệ phản vệ là sự công bằng Các giả định công

bằng loại bỏ các hành vi vô hạn mả được xem xét một cách không thực tế, và thường can đề chứng minh các thuộc tỉnh hoạt động được

a_ Các ràng buộc công bing (Fairness Constraints)

Thông thường, một thực thi công bằng (hay một vết) là được mô tả bởi một thực tế là các ràng buộc công bằng phải được thỏa mãn Rảng buộc công bằng

thường được dùng đề loại bỏ các tỉnh toản được đánh giả lả vô ly voi hé thong đang xem xét Cac ràng buộc công bằng được xem xét dưới các khia cạnh sau:

© Céng bing v6 diéu kién (unconditional fairness)

© Céng bang manh (strong fairness)

© Céng bang yéu (Weak fairness)

Định nghĩa 3.16 Công bằng (A-fair ) vô điều kiện, mạnh và yêu

Với hệ chuyên TS = (§, Act, —, I, AP, L) không cỏ trạng thái kết thúc, 4 © Act

wt

và đường thực thi vỏ hạn ø = sp > s; — của TS:

1 ø là A-fair vô điều kiên khi và chỉ khi Š j,, € 4 @.5)

2 ø là A-fair mạnh khi vả chỉ khi

(Sj Act(s,) nA # 0) =(SJ.«,€A) @.6)

3 g la A-fair yéu khi vả chỉ khi

(Sj Act(s) NA + 0) >( Fx, EA4) GI

Ở đây, S5 j có nghĩa là “tồn tại j" và ' j cỏ nghĩa là “ hầu như với mọi j” trong

nghĩa “với tất cả, trừ một số trạng thái hữu hạn của j” Bien j thuộc trường số tự nhiên

Công thức (3.5) chỉ ra rằng một công bằng lả võ điều kiên khi và chỉ khi tôn tại j

và hành động ®%, trong tập hành động A là luôn luôn thực hiện được

Công thức (3.6) nói rằng một công bằng là mạnh khi vảo chỉ khi tổn tại giá trị j

trên tập hảnh động 4ct(s,) của trạng thai sj giao voi tap trang thai A thi ton tai hanh

động ® trong tập hành động A sẽ thực thi được

Công thức (3.7) nỏi rằng một công bằng là yêu khi vào chi khi hau như mọi giả trí j trên tập hành đông 4ct(s,) của trang thai s; giao voi tap trang thai A thi ton tai

hành động ®%, trong tap hành động A sẽ thực thi được.

Trang 32

Mỗi quan hệ giữa các loại công bằng là mỗi công bằng vô điêu kiện là bao ham công bằng mạnh, môi công bằng mạnh là bao ham mét công bang yeu Vi du một

đường thực thi là công bằng mạnh, nhưng nỏ không phải là một công bằng vô điều

kiên, còn một công bằng vô điều kiên thì chắc chắn lả một công bằng mạnh Chieu

ngược lại không đúng

Công bằng vô điều kiện => Công bằng mạnh => Công bang yeu

Dinh nghia 3.17 Gia dinh céng bang (Fairness Assumption)

M6ét gia dinh céng bing cho tap hanh déng Act la mét b6

F = (Fucona» FeerongFweak )

V6i FuconasFeerongs Fweak & 24% Thue thi p la F — fair néu:

© No la mot A-fair v6 dieu kién voi tat caA © Fycone +

©_ Nó là một A-fair mạnh với tất cả 4 E #;„¿n„ , và

© Nola mét A-far yeu voi tat caA © Fyean

Nếu tập # là rỗng trong trường hợp này, chúng ta dùng khái niệm công bằng

(fair) thay cho F — fair

b Tính công bằng và tính an toàn

Trong khi giả định công bằng là cần thiết để kiểm tra các thuộc tỉnh hoạt động được, chúng lại không thích hợp đề kiểm tra các thuộc tính an toàn, bởi vì chúng luôn đảm bảo rằng có một chiến lược lập lịch thích hợp Bởi vậy các giả định công bằng

được gọi là các giả định công bằng cỏ thẻ nhận thức được Một giả định công bằng,

không thể nhận thức được trong một hệ chuyển khi tồn tai mot trang thai co the dat

được tại chỗ mả đường dẫn không công bằng bắt đầu Trong trường hợp này, không

thể thiết kế một bộ lịch biểu đề giải quyết vấn đẻ không đơn định như khi chỉ có các

đường dẫn công bằng còn lại

Định nghĩa 3.18 Giả định công bằng có thể nhận thức được (Realizable

Fairness Assumption)

TS lả một hệ chuyển với một tập các hành động Act va F la mot gia dinh cong

bằng cho tập 4ef # được gọi là cỏ thể nhận thức được trong TS nếu với mỗi trạng thái

đạt được s phải khác rong ta co:

FairPath;(s) + ©

Trang 33

3.4.6 Logic thời gian tuyến tính (Linear temporal logic - LTL)

a Cú pháp của LTL

Theo [10], LTL dựa trên các phép toán mệnh đề, công thức của các phép toán

mệnh đề bao gồm các mệnh đẻ nguyên tử (ký hiệu bởi các chữ cái p, q ) và các phép

toán như trong bảng 3.1

Bang 3.1 Các toán tử trong LTL

Chúng ta cỏ thể dùng cả hai cách ký hiệu toán học vả cú pháp đẻ viết các công,

thức trong SPIN Ví dụ như: (p A ¬q) > (p V ¬q), (p && !q) ¬ (p || gq)

“Theo [10], một công thức của LTL được xây dựng từ các mệnh đẻ nguyên thủy

và từ các toán tử bao gồm các toán tử của các phép toán mệnh đề cũng như các toán tử

thời gian Các toản tử thời gian được mô tả trong bảng 3.2

Bảng 3.2 Các toán tử thời gian trong LTL

Phép toán Ky hiéu trong SPIN

Cho den khi (until) U

Toản tử luôn luôn và tồn tại là toản tử 1 ngôi, và toán tử cho đền khi là toán tử

hai ngôi Toản tử thời gian vả toán mệnh đề được kết hợp tự do Vỉ dụ như trong công

thie sau: []((p && gq) +r U (p || g)), công thức nảy được đọc là luôn luôn có p giao với q, kéo theo là r giữ cho đến khi (p hoặc q) giữ

b._ Ngữ nghĩa cña LTL

Ngữ nghĩa của một công thức đúng cú pháp được định nghĩa trong một thẻ hiện:

bảng chân giá trị với T(true - đúng) hoặc F (false - sai), với các mệnh đề nguyên tử của

nó Bảng chân giá trị của 2 mệnh đẻ nguyên tử A và B được mô tả trong bảng 3.3

Trang 34

Bang 3.3 Bang chin gia trị

Trong logic thời gian, ngữ nghĩa của một công thức được định nghĩa theo phép

tỉnh vả trạng thái của phép tính Các mệnh đề nguyên tử của logic thời gian là biểu

thức Boolean cỏ thẻ được đánh giả trong một trạng thái đơn độc lập của một tỉnh toán

Vi du critical là giá trị của một biển critical trong một chương trình về đoạn găng; biểu thức critical <= 1 là một mệnh để nguyên tử, bởi vỉ nó có thể được gan gia tri ding

trong một trạng thải s bằng việc kiểm tra giá tri ctia bien critical trong trạng thải s

3.5 Các công cụ kiểm chứng mô hình

Từ khi kiểm chứng mô hình bắt đâu được phát triển cho đến nay, có rất nhiều công cụ để kiểm chứng mô hình Theo thống kê của trang web

hittp://anna.fi: muni.cz/yahoda/ (trang được xây dựng và cập nhật bởi phỏng thí nghiệm

ParaDiSe của khoa Thông tín, đại học Masaryk University Brno, céng hoa Séc) dén

tháng 9/ 2012, khoa đã thông kê được 68 công cụ kiểm chứng trong đó có 53 công cụ kiểm chứng mô hình Trong đỏ, chúng ta có thê kẻ đên một số công cu phỏ biến như là

SPIN, NuSMV, Java Pathfinder, KRONOS

SPIN (Simple Promela Interpreter — Trinh bién dich Promela don gidn) la céng

cụ hỗ trợ cho việc kiểm chứng mô hình cho các hệ phan tan Phan mem nay được phát triển bởi phòng thí nghiệm Bell Labs trong nhóm các phương pháp hình thức vả kiểm

chứng bắt đầu từ năm 1980 SPIN cùng với ngôn ngữ Promela là một bộ công cụ mạnh

mẽ, và được áp dụng rộng rãi trong kỹ thuật kiểm chứng mô hình

NuSMV (A new symbolic model checker — bé kiém chứng mô hình biểu tượng

mới) có ngôn ngữ đâu vào được thiết kế đề cho phép mô tả các hệ thông hữu han trang

thải Mục đích cơ bản của ngôn ngữ NuSMV là mô tả (sử dụng các biêu thức trong các

phép tỉnh mệnh đẻ) phép chuyên liên quan tới cầu trúc hữu hạn Kripke

Java Pathfinder (JPF) la mét hé thông đánh giá các chương trình thực thi của

Java bytecode Java được phát triền bởi trung tâm nghiên cứu NASA và trở thành mã

nguồn mở năm 2005

KRONOS 1a mét céng cụ kiểm chứng mô hình với thời gian phân nhanh (branch tìme) và kiểm chứng tương đương dùng cho ngôn ngữ mô hình hóa Timed Automata

Trong KRONOS, các thảnh phan của hệ thống thời gian thực được mô hình hoá thành

các automat thời gian, vả các yêu cầu chính xác được biêu diễn trong logic thời gian

thực TCTL (TCTL la một mở rộng của logic thời gian CTL — Computation Tree

Trang 35

Logie_ Logie cây tỉnh toán má cho phép định lượng lý luận thời gian trên một khoảng,

thời gián liên Lục

Mỗi sông cụ kiểm chứng đều có những ưu nhược điểm khác nhau, và được áp dung trong những bài toán eụ thê Tuuận văn lựa chọn 8PTN là công cụ kiểm chứng bởi

vi SPIN được íng dụng rộng rấi trong việc kiểm chúng các hệ phân Lan cA trong

nghiên cửu và trong công nghiệp, có lính phổ quái, dễ ứng dụng, cộng đồng phát Iriển

và nghiên cứu hoạt động tích cự và ngôn ngũ mô hình hóa PROMELA gân với ngôn ngữ lập trình Œ

Trang 36

Chương 4 Ngôn ngữ Promela và công cụ kiêm

chứng mô hình SPIN

Công cụ kiểm chứng mô hình SPTN là một công cụ được áp dụng rộng rãi trong,

nghiên cứu khoa học và trong công nghiệp Ngôn ngữ Promela là ngôn ngữ để mô

hình hóa hệ thông phân mém dé céng cụ SPIN có thể hiểu và kiểm chứng mô hình cho hiệ thông

“Mục tiêu của chương này là giới thiệu về ngôn ngữ Promela, đẻ từ đó ta có thê sử đụng ngôn ngữ Promela để mô hình hoá được các hệ thông,

4.1 Ngân ngữ Promcla

SPIN là một công cụ để phân tích tỉnh logie nhất quán của các hệ phân tán, đặc biệt là các giao thức truyền nhận đữ liêu Hệ thống được mõ tá trong một ngôn ngữ mô

hinh héa goi 14 Promela (Precess or Protocol Meta Language — Ngôn ngữ Meta của

tiễn trinh hoặc giao thức) Ngôn ngữ nảy cho phép tạo một cách tự động các tiến trình tương tranh Giao tiếp thông qua các kênh thông điệp có thể được định nghĩa để đồng

bộ hoặc không đồng bộ

Mô hình SPIN có 3 loại đối tượng: các tiến trình (processes), các kênh thông điệp (message channels), và các biến (variables) Các tiên trinh là các đổi tượng toàn cục Các kênh thông diệp và các biến là cáo đổi tượng có thẻ dược khai báo toàn cục hoặc cục bộ Các tiến trình đặc tả hành vị, các kênh và biến toàn cục định nghĩa môi trường,

ma trơng đó các Liên trình chạy

4.1.1 Kiểu dữ Hiệu, toán tử và câu lệnh

¡ Kiểu đữ liệu

“Theo [10], kiến đữ liệu của ngân ngữ Promela được mô tả như trong bảng 4.1

Băng 4.1 Kiểu dữ lện số của Promela

Trang 37

Ngoài ra thi Promela cỏn cung cấp các kiểu dữ liệu khác la: chan (kiêu kênh),

mtype (kiêu tự định nghĩa)

Promela không cung cap kiéu ky tu (char), kieu chudi (string) va kieu dau phay d6ng (floating-point number) Ky tu co the gan cho bién voi kiêu byte vả được ghỉ

ra theo cau tric $c Kiểu chuỗi là không cần thiết trong Promela do cẩn tối giản hỏa

chương trình, ya từ khỏa print£ chỉ có tác dụng khi mô hình hóa chương trình, còn

khi SPIN chứng minh chương trình thì không gọi đền nó Kiểu dâu phảy động có thê được sử dụng bằng cách nhúng các mã lệnh C vào trong chương trình

b._ Toán từ và biểu thức

Theo [10], một tập các toản tử trong Promela được định nghĩa như trong Hinh 4.1 Các toán tử này được mô tả tương tự như ngôn ngữ C Có một điểm cân lưu ý là các toán tử này là vô hướng (side-effeet free), và chỉ cỏ các hậu tổ trong phép toán

++,— — chứ không có các tiên tổ Ví dụ: ta chỉ có thê biểu diễn là

a= bi+ la ding

a=++b lasai

13 ! phai Phép phủ định logic

13 x phải Phép bủ bit

12 "1% trai Nhan, chia, lấy phần nguyên

10 <<, >> trá — |Dịchbitsang trái phải

7 trái Phép toán thao tác bit AND

6 * trái Phép toán thao tắc bit XOR - phép OR có loại trừ|

5 | trái Phép toán thao tắc bit OR

2 L>:) phải Biểu diễn điều kiên

Hình 4.1 Các toán tử trong ngôn ngữ Promela

Các định danh biéu tuong (Symbolic names) duoc dùng đẻ khai bảo một biểu

tượng cho một só, một marco tiên xử lý có thể được dùng ở đầu chương trình

# define max 10 Kiểu mtype (message type — kiêu thông điệp) được dủng đề khai bảo các định

danh bộ nhớ cho các giá trị Ưu điểm của meype là các giá trị biêu tượng có thể được

Trang 38

chương trình Nhược điểm của meype là nó

cho toàn bộ chương trình, Giá trị meype có thể được ín ra bằng lệnh printm

c Cin link if

Lệnh 4£ dùng để điều khiển cac cau tric 18 nhanh sẽ được khai bảo theo cầu

có ruột lập các lên đã định nghĩa trước

Trong Promela thi cau lệnh điển kiện được định nghĩa bảng cặp từ khóa i£ và

£1, cing voi cặp đầu hai chấm (::) dink nghũa diễu kiện trong chương trình Từ khỏa

skip được dùng để thoát ra khỏi chương trình khi mã biểu thúc đánh giá hiôn có giá trị tuc hoặc (1)

Doan wi 1énh lp dug bao trong clip tir khoa đo và ođ, các lệnh ở bên trong

đoạn mã được định nghĩa bởi cặp đâu hai châm (: :), để thoát khởi vòng lặp thì ta

ding lừ khóa break

2 Céu link nhdy jump

Promela cung cấp các câu lệnh nhảy đến một phản khác trong chương trình là goto, break, skip Lénh nhay goto có thế thay thể cho lệnh break trong vòng lắp, nhưng lệnh nhãy goto cản dược chủ dịnh là sẽ nhảy đến phan nào của chương trình

‘bang mệt nhãn (label), còn lệnh break chỉ đơn giản là thoát ra khỏi vòng lặp

4.1.2 Dữ liệu và câu trúc chương frình

a Kiéu mang (array)

Trang 39

cach dich chuyén bit (shift) va ding mat na (mask)

b Dinh aghia kiéve (type definitions)

Các kiêu kết hợp được định nghĩa với typede£ va thường được dùng đề định

nghĩa cầu trúc của các thông điệp được gỗi qua các kênh:

Kiểu tụ định nghĩa này cũng được dùng đề khai bảo máng 2 chiều trong Promela

Củ pháp của kiếu tự định nghĩa này tương tự với các ngôn ngữ giống C

e_ Bộ tần xử lý (The preprocessor)

SPIN dược cải dặt bằng ngôn ngữ C, nên nó củng có những dặc tỉnh tương tự C

Nó sử dụng một sông cụ biên địch được gọi lả bộ liên xử

tiễn xử lý không có bất kỳ trí thức nao về cú pháp và ngữ nghĩa của ngân ngũ, thay

vào đó là xem mã nguiồn như là văn bản thuận

Khi SPIN chạy ở bât kỳ mode nảo, nó cũng gọi bộ tiên xử lý trước tiên, thẳng thường thi nó sẽ giống như là bộ tiên xử lý được kết hợp với bộ biên địch đùng để biên

địch các bộ kiểm chứng,

Chúng tạ có thể gặp các bộ tiển xử lý như #đefine, #inelnde, và inline

tương tự như ngôn ngữ Ở trong SPDN

tảnglude *Zor.h” // Khu báo Lhu viện

sdefine N 5 // Dinh nghia mt ky hoéu, whan

⁄/ được đùng trong các đặc tá tíma

ff đăng

Ngoài ra bộ tiễn xử lý còn được cài đặt, ứng dung trong việc biên dịch điều kiện

(eondition compilation), và các macro.

Ngày đăng: 21/05/2025, 18:49

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
1. Bemhard K. Aichemig (2013), “Model-based mutation testing of reactive system, from semantics to automated test-case generation”, Lecture Notes inComputer Science, Volume 8051, pp.23-36.Bogdanov K., Bowen J. P., Cleaveland R., Derrick J., Dick J., Gheorghe M.,Harman M., Hierons R. M., Kapoor K., Krause P., Luettgen G., Simons A. J Sách, tạp chí
Tiêu đề: Lecture Notes inComputer Science
Tác giả: Bemhard K. Aichemig
Nhà XB: Lecture Notes in Computer Science
Năm: 2013
3. Christel Baier, Joost-Pieter Katoen (2008), Principles of Model Checking, The MIT Press, Cambridge, Massachusetts, London Sách, tạp chí
Tiêu đề: Principles of Model Checking
Tác giả: Christel Baier, Joost-Pieter Katoen
Nhà XB: The MIT Press
Năm: 2008
4, Doroty Graham, Erik Van Veenendaal, Isabel Evans, Rex Black (2008) Foundations of Software Testing: ISTQB Certification, Cengage LearningEMEA, Boston Sách, tạp chí
Tiêu đề: Foundations of Software Testing: ISTQB Certification
Tác giả: Doroty Graham, Erik Van Veenendaal, Isabel Evans, Rex Black
Nhà XB: Cengage LearningEMEA
Năm: 2008
6. Gerard J. Holzmann (2003), Spin Model Checker, The: Primer and Reference Manual, Addison-Wesley, Boston Sách, tạp chí
Tiêu đề: Spin Model Checker, The: Primer and Reference Manual
Tác giả: Gerard J. Holzmann
Nhà XB: Addison-Wesley
Năm: 2003
9. Kshirasagar Naik, Priyadarshi Tripathy (2008), Sofavare Testing and Quality Assurance: Theory and Practice, John Wiley &amp; Sons, Waterloo Sách, tạp chí
Tiêu đề: Sofavare Testing and Quality Assurance: Theory and Practice
Tác giả: Kshirasagar Naik, Priyadarshi Tripathy
Nhà XB: John Wiley & Sons
Năm: 2008
10. Mordechai Ben-Ari (2008), Principles of the Spin Model Checker, Springer, Germany Sách, tạp chí
Tiêu đề: Principles of the Spin Model Checker
Tác giả: Mordechai Ben-Ari
Nhà XB: Springer
Năm: 2008
7. Gordon Fraser, Franz Wotawa, Paul E. Ammann (2009), “Testing with model checkers: A Survey”, Journal for Software Testing, Verification and Reliability,Volume 19, Issue 3, pp.215-261 Khác
8. Huiling Shi, Wenke Ma, Meihon Yang, Xinchang Zhang (2012), “4 Case Study of Model Checking Retail Banking System with SPIN”, Jounal of Computers,Volume 7, Issue 10, pp.2503-2510 Khác
11.Paul E. Ammann, Paul E. Black, William Majurski (1998), “Using Model Checking to Generate Tests from Specifications”, ICFEM '98 Proceedings ofthe Second IEEE International Conference on Formal Engineering Methods,pp.46-54 Khác
12. Yue Jia and Mark Harman (2011) “An Anlysis and Survey of the Development of Mutation Testing”, IEEE Transactions on Software Engineering, vol. 37 no Khác

HÌNH ẢNH LIÊN QUAN

Hình  2.1  Mô  hình  chữ  V  trong  phát  triển  phần  mềm - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 2.1 Mô hình chữ V trong phát triển phần mềm (Trang 14)
Hình  2.2.  Chương  trình  kiếm  tra  ba  cạnh  của  tam  giác - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 2.2. Chương trình kiếm tra ba cạnh của tam giác (Trang 17)
Hình  thức  hóa  Mô  hình  hóa - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh thức hóa Mô hình hóa (Trang 22)
Bảng  3.2.  Các  toán  tử  thời  gian  trong  LTL - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
ng 3.2. Các toán tử thời gian trong LTL (Trang 33)
Bảng  chân  giá  trị  với  T(true  -  đúng)  hoặc  F  (false  -  sai),  với  các  mệnh  đề  nguyên  tử  của - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
ng chân giá trị với T(true - đúng) hoặc F (false - sai), với các mệnh đề nguyên tử của (Trang 33)
Hình  4.1.  Các  toán  tử  trong  ngôn  ngữ  Promela - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 4.1. Các toán tử trong ngôn ngữ Promela (Trang 37)
Hình  4.3  là  ví  dụ  về  hoại  dông  của  kênh  gặp: - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 4.3 là ví dụ về hoại dông của kênh gặp: (Trang 41)
Hình  4.7.  Giao  diện  khung  làm  việc  Simulate/  Replay - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 4.7. Giao diện khung làm việc Simulate/ Replay (Trang 48)
Hình  5.1.  Kiểm  thử  đột  biến  hướng  mô  hình - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 5.1. Kiểm thử đột biến hướng mô hình (Trang 53)
Hình  thức  hóa.  Mô  hình  hóa - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh thức hóa. Mô hình hóa (Trang 54)
Hình  6.1.  EFSM  của  máy  rút  tiền  tự  động, - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 6.1. EFSM của máy rút tiền tự động, (Trang 61)
Hình  6.2.  Lược  đồ  truyền  thông  điệp  trong  máy  ATM - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 6.2. Lược đồ truyền thông điệp trong máy ATM (Trang 62)
Hình  6.6.  Mã  lệnh  Promeia  của  iên  trình  Custamer' - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 6.6. Mã lệnh Promeia của iên trình Custamer' (Trang 64)
Hình  6.7.  Kết  quả  kiểm  chứng  với  yêu  cầu  đặc  tả  thứ  nhất - Luận văn kết hợp phương pháp kiểm chứng mô hình và các kỹ thuật kiểm thử phần mềm làm tăng Độ tin cậy của hệ thống phần mềm
nh 6.7. Kết quả kiểm chứng với yêu cầu đặc tả thứ nhất (Trang 66)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm