Đặc tả đúng Đặc tả sai
Mô hình hệ thống đúng Thỏa mãn (1) Vi phạm + sinh ra phản ví dụ (3)
Mô hình hệ thống sai Vi phạm + sinh ra
phản ví dụ (2) Không xét
Để đảm bảo tính đúng đắn của kết quả kiểm chứng, ta chỉ xét đến hai trường hợp (2) và (3) là mô hình hệ thống sai hoặc đặc tả sai và kết quả kiểm chứng trả về là vi phạm và sinh ra các phản ví dụ. Bởi vì mô hình hệ thống, và đặc tả ban đầu của hệ thống là đúng đắn, nên nếu một trong hai thành phần trên sai, thì kết quả kiểm chứng cũng phải trả về kết quả là mô hình vi phạm. Trường hợp mô hình hệ thống sai hoặc đặc tả sai mà kết quả kiểm chứng là thỏa mãn, thì chứng tỏ là quá trình hình thức hóa/ mô hình hóa bị sai, và ta cần phải hình thức hóa/ mô hình hóa lại đặc tả/ mô hình hệ thống.
Câu hỏi thứ hai là “Các phản ví dụ được sinh ra có thể coi là ca kiểm thử hợp lệ của chương trình hay không? ” Theo như các nghiên cứu [2], [7] và [11] thì mỗi phản ví dụ sinh ra từ công cụ kiểm chứng mô hình đều được coi là một ca kiểm thử. Bởi vì phản ví dụ mô tả cách mà chương trình gặp phải một trạng thái không mong muốn, là một đường dẫn từ trạng thái ban đầu đến trạng thái không mong muốn. Mỗi trạng thái của hệ thống đều là chứa những thông tin về hoạt động của hệ thống. Mỗi phản ví dụ sẽ có các thông tin từ trạng thái đầu ban đầu qua các trạng thái khác nhau – đây chính là giá trị đầu vào cho một ca kiểm thử, đến trạng thái vi phạm – mô tả hành vi của hệ thống hay chính là kết quả mong muốn của ca kiểm thử. Tập các phản ví dụ chính là tập các ca kiểm thử của chương trình.
5.4. Ưu điểm và nhược điểm của cách tiếp cận
Ưu điểm của cách tiếp cận này là chúng ta tiến hành kiểm thử, đánh giá sớm được chất lượng của đặc tả và mô hình hệ thống, từ đó có thể cải tiến đặc tả và mô hình của hệ thống, để làm giảm những rủi ro trong các giai đoạn sau của quy trình phát triển phần mềm.
Bên cạnh những ưu điểm, thì cách tiếp cận này cũng có một số hạn chế:
Ngôn ngữ Promela chưa có tập toán tử đột biến của riêng nó và chưa có công cụ tự động để sinh ra các mô hình đột biến. Việc sinh ra các đột biến bằng phương pháp thủ công sẽ tốn nhiều thời gian, công sức, nhất là với các hệ thống lớn.
Mô hình được đặc tả ở mức cao, nên một số thuộc tính, đặc điểm của hệ thống đã bị loại bỏ đi, để mô hình đủ nhỏ để chứng minh được, nên ngoài việc kiểm chứng hệ thống cũng cần áp dụng thêm các kỹ thuật kiểm thử hộp đen và hộp trắng trên mã nguồn của hệ thống để đảm bảo chất lượng của hệ thống.
Chương 6. Thực nghiệm
Chương 6 áp dụng các kỹ thuật đã nói đến ở chương 5 vào bài toán thực nghiệm là ATM để kiểm chứng tính đúng đắn của lý thuyết.
Quy trình thực nghiệm được thực hiện theo các bước sau: 1. Mô tả bài toán ATM
2. Xây dựng mô hình, hình thức hóa các đặc tả và chứng minh mô hình thỏa mãn đặc tả với công cụ SPIN
3. Dùng phương pháp kiểm thử đột biến để biến đổi đặc tả/ chương trình của hệ thống, kiểm chứng lại mô hình với SPIN, thu được các phản ví dụ
4. Kết luận
6.1. Mô tả bài toán thực nghiệm – bài toán ATM
Ngày nay, cùng với sự phát triển của nền kinh tế, số lượng các ngân hàng ngày càng tăng, số lượng máy rút tiền cũng tăng theo và các giao dịch qua máy ATM trở nên phổ biến. Máy ATM bản thân nó là một thiết bị phức tạp, tương tác với người dùng, và tương tác với cơ sở dữ liệu của ngân hàng và là một hệ thống đòi hỏi tính an toàn cao. Việc kiểm thử chất lượng của máy ATM để đảm bảo là máy không gặp lỗi là một việc khó khăn. Vì vậy ở đây, luận văn áp dụng phương pháp kết hợp cả kiểm chứng mô hình và kỹ thuật kiểm thử đột biến để đảm bảo tính chính xác, tính hoạt động được, và bao phủ được nhiều lỗi nhất cho chương trình.
Vì máy ATM là một thiết bị phức tạp, với nhiều tương tác, nên luận văn chỉ giới thiệu và thực hiện kiểm chứng, kiểm thử trên một thiết kế đơn giản, đã bỏ bớt đi một số tương tác phức tạp. Theo [7], máy ATM được mô tả với các chức năng chính:
Đăng nhập vào tài khoản Rút tiền (Withdraw) Gửi tiền (Deposit)
Truy vấn tài khoản (Inquiry balance)
Chức năng đăng nhập cho phép người dùng đưa thẻ vào máy vào nhập mã PIN của thẻ. Nếu người dùng nhập đúng mã PIN sau nhiều nhất là ba lần thử, thì hệ thống sẽ hiện lên một thực đơn cho phép người dùng chọn các chức năng: rút tiền, gửi tiền và kiểm tra tài khoản. Người dùng được phép nhập sai mã PIN hai lần, nếu nhập sai mã PIN đến lần thứ ba thì thẻ bị khóa.
Chức năng rút tiền được thực hiện sau khi đăng nhập thành công, người dùng được phép rút tiền, số tiền được rút không được nhiều hơn số tiền trong tài khoản của họ. Nếu số tiền trong tài khoản nhỏ hơn số tiền người dùng muốn rút, thì hệ thống báo lỗi. Nếu số tiền trong tài khoản lớn hơn số tiền người dùng muốn rút thì hệ thống cho phép người dùng rút tiền. Để cho bài toán đủ đơn giản, tác giả để mặc định là người dùng chỉ được rút 10$ hay 20$, và người dùng cũng không được rút quá năm lần trong
một giao dịch thẻ. Nếu người dùng thực hiện thao tác rút tiền lần thứ sáu thì hệ thống sẽ thông báo lỗi.
Chức năng gửi tiền được thực hiện sau khi đăng nhập thành công, người dùng được phép gửi tiền vào tài khoản. Để cho bài toán đủ đơn giản, và hệ là một hệ đóng thì người dùng chỉ được phép gửi tiền với hai mức là 10$ hoặc 20$ và khách hàng chỉ được gửi tiền năm lần trong một lần giao dịch thẻ. Nếu người dùng thực hiện thao tác gửi tiền lần thứ sáu thì hệ thống thông báo lỗi.
Chức năng truy vấn tài khoản được thực hiện sau khi đăng nhập thành công, người dùng được phép truy vấn tài khoản. Hệ thống trả lại thông báo số tiền có trong tài khoản của người dùng.
6.2. Xây dựng mô hình và kiểm chứng
Trước khi mô hình hóa hệ thống, ta cần đưa ra được máy trạng thái hữu hạn mở rộng EFSM (Extended Finite State Machine) của máy ATM. Từ máy trạng thái hữu hạn ta xây dựng lên mô hình hệ thống bằng ngôn ngữ Promela, hình thức hóa các thuộc tính LTL và kiểm chứng mô hình cùng các thuộc tính bằng máy kiểm chứng mô hình SPIN.
6.2.1. Máy trạng thái hữu hạn mở rộng EFSM
Máy trạng thái hữu hạn mở rộng là một mô hình nâng cao dựa trên máy trạng thái hữu hạn truyền thống. Một máy trạng thái hữu hạn sẽ có ba thành phần chính:
Các trạng thái
Các hàm chuyển trạng thái Các sự kiện đầu vào và đầu ra.
Theo [8], máy trạng thái hữu hạn mở rộng cung cấp thêm thành phần nữa là các tác vụ và các quyết định. EFSM thường dùng trong các vấn đề phức tạp, khi mà số lượng trạng thái là lớn.
Một máy ATM hoạt động dựa trên ba thành phần tương tác chính là: khách hàng, máy ATM, và ngân hàng (hay có thể hiểu là máy chủ của ngân hàng). Khách hàng tương tác với máy ATM thông qua các màn hình hiển thị các chức năng đăng nhập, rút tiền, gửi tiền và truy vấn tài khoản. Máy ATM có trách nhiệm nhận các yêu cầu của khách hàng, chuyển các yêu cầu đó đến ngân hàng để kiểm tra tính hợp lệ của giao dịch, nhận kết quả trả về từ ngân hàng cho các yêu cầu đó và gửi lại kết quả của yêu cầu cho khách hàng. Ngân hàng làm nhiệm vụ nhận các yêu cầu từ máy ATM, xử lý thông tin, kiểm tra tính hợp lệ của giao dịch, và trả lại thông tin cho máy ATM.
Hình 6.1 bên dưới mô tả máy trạng thái hữu hạn mở rộng của máy ATM[8]. Máy trạng thái EFSM có bốn trạng thái và mười phép chuyển trạng thái. Mỗi phép chuyển trạng thái đều có gẵn nhãn [7]. Ví dụ, “PIN/rOK[try <=2], Logon” tức là nếu khách hàng nhập mã PIN đúng với dưới ba lần đăng nhập, thì hệ thống đăng nhập thành công và hiển thị các chức năng rút tiền, gửi tiền và truy vấn tài khoản cho khách hàng lựa
chọn; “PIN/Invalid [try <2], Logon” từ trạng thái Init đến trạng thái Re-Logon thể hiện rằng nếu khách hàng nhập sai mã PIN dưới hai lần thì khách hàng có cơ hội đăng nhập lại lần thứ ba (tiếp tục được Re-Logon); hay nhãn “Withdraw Amount/ r2ManyWD[MaxTimesW >=6]” trong trạng thái Withdraw/ Deposit/ Inquiry Balance thể hiện rằng nếu khách hàng nhập số tiền cần rút tới lần thứ sáu – yêu cầu rút tiền quá sáu lần thì hệ thống sẽ trả về lỗi r2ManyWD – lỗi yêu cầu rút tiền quá sáu lần trong một phiên giao dịch.
Hình 6.1. EFSM của máy rút tiền tự động
6.2.2. Mô hình hóa hệ thống bằng ngôn ngữ Promela
Từ máy trạng thái hữu hạn mở rộng, ta xậy dựng lên mô hình của máy ATM. Hình 6.2 mô tả các thông điệp được truyền qua lại giữa ba tiến trình là khách hàng, máy ATM và ngân hàng. Nhiệm vụ chính của máy ATM là truyền thông điệp qua lại giữa khách hàng và ngân hàng. Để tránh việc bùng nổ không gian trạng thái, thì các trường Amount_Withdraw, Amount_Deposit, Amount_Balance đều được khai báo kiểu byte. Các giao tác giữa tiến trình cũng sẽ được khai báo với kiểu bool, byte, hoặc mtype.
Hình 6.2. Lược đồ truyền thông điệp trong máy ATM
Hình 6.3 thể hiện các thông điệp truyền trong hệ thống được gán kiểu mtype:
Hình 6.3. Các thông điệp trong máy ATM
Có ba tiến trình chạy trong hệ thống là tiến trình Customer, ATM và Bank. Ba tiến trình này tương tác với nhau thông qua 4 kênh là kênh CusToATM, kênh ATMToCus, kênh ATMToBank và kênh BankToATM được khai báo như trong hình 6.4. Kênh CusToATM gửi thông điệp từ khách hàng tới máy ATM, mỗi thông điệp sẽ gồm bốn trường: trường thứ nhất được khai báo với kiểu byte thể hiện rằng đây là một khách hàng, trường thứ hai có kiểu mtype thể hiện thao tác từ khách hàng với máy ATM, trường thứ ba có kiểu byte thể hiện số tiền được thực hiện giao dịch và đang được dùng trong giao dịch và trường thứ tư có kiểu mtype thể hiện thông điệp liên quan đế các giao tác trong phiên giao dịch. Tương tự, các kênh ATMToCus, kênh
mtype={PIN,NokPIN,CardLocked,okPIN,Operate_Logon, Operate_Withdraw,Operate_Deposit,Operate_BalInq, Operate_Logout,withdrawOK,depositOK,r2ManyWD, r2ManyD, WithdrawError, ShowBalance,SmbolRequest}
ATMToBank và kênh BankToATM thể hiện việc gửi thông điệp từ máy ATM đến khách hàng, từ máy ATM đến ngân hàng và từ ngân hàng đến máy ATM.
Hình 6.4. Các kênh thông điệp trong máy ATM
Các hình 6.5 là mô tả hàm init để chạy chương trình với khai báo atomic{} để các tiến trình trong ATM sẽ được thực hiện lần lượt cho đến hết mà không bị ngắt quãng và hình 6.6 là mã lệnh tóm tắt của các tiến trình Customer. (Mã lệnh đầy đủ của chương trình được đặt trong phần phụ lục). Giá trị của mỗi lần rút tiền, hay gửi tiền đã được cố dịnh là 10$ hay 20$ để đảm bảo tính đơn giản của hệ thống.
Hình 6.5. Hàm init khởi tạo các tiến trình
chan CusToATM= [0] of {byte, mtype, byte, mtype};
/*Channel message from customer to ATM*/
chan ATMToCus = [0] of {byte, mtype, byte, mtype}; /*Channel message from ATM to customer*/
chan ATMToBank = [0] of {byte, mtype, byte, mtype}; /*Channel message from ATM to bank*/
chan BankToATM = [0] of {byte, mtype, byte, mtype}; /*Channel message from bank to ATM*/
251 init{ 252 atomic{ 253 run Bank(); 254 run ATM(); 255 run Customer(); 256 } 257 }
Hình 6.6. Mã lệnh Promela của tiến trình Customer
6.2.3. Hình thức hóa và kiểm chứng các yêu cầu hệ thống
Trong phần 6.1, luận văn đã mô tả những yêu cầu của máy ATM, và trong phần 6.2.2 luận văn đã xây dựng lên mô hình máy ATM. Để chứng minh được rằng mô hình đáp ứng được đặc tả của hệ thống, thì luận văn cần hình thức hóa các yêu cầu của hệ thống. Sau đó dùng công cụ SPIN để đánh giá các thuộc tính của hệ thống mà chúng ta mong muốn, khi thuộc tính được biểu diễn bằng công thức LTL. Để đánh giá tính
31 proctype Customer()
32 {
33 byte i;
34 Cus_Logon_Request:
35 do
36 ::CusToATM!i, Operate_Logon, 0, PIN ->
37 if
38 ::ATMToCus?eval(i), Operate_Logon, 0, OkPIN ->
39 printf("You are welcome! \n");
40 goto SelectOperator
41 ::ATMToCus?eval(i), Operate_Logon, 0, NokPIN ->
42 printf("PIN is invalid! \n");
43 goto Cus_Logon_Request
44 ::ATMToCus?eval(i), Operate_Logon, 0, CardLocked ->
45 printf("Card is locked! \n");
46 goto Cus_Logon_Request
47 fi
48 od;
49 SelectOperator:
50 do
51 ::printf("Customer Select Operator: Deposit \n") ->
52 if
53 ::Amount_Deposit = 10
54 ::Amount_Deposit = 20
55 fi;
56 if
57 ::CusToATM!i, Operate_Deposit, Amount_Deposit,
SmbolRequest ->
58 if
59 ::ATMToCus?eval(i), Operate_Deposit, 0,
DepositOK ->
60 printf("Deposit is OK! \n");
61 goto SelectOperator
62 ::ATMToCus?eval(i), Operate_Deposit, 0,
đúng đắn của mô hình máy ATM thì luận văn xây dựng hình thức hóa hai yêu cầu của hệ thống.
Yêu cầu thứ nhất: Khách hàng luôn luôn thực hiện được việc gửi tiền, rút tiền và truy vấn tài khoản, sau khi đăng nhập thành công. Yêu cầu này được mô tả bằng công thức LTL như sau:
(okPIN → (Operate_Withdraw || Operate_Deposit || Operate_BalInq)
# define bankActions (Operate_Withdraw || Operate_Deposit || Operate_BalInq)
never { /* !([] (okPIN -> <> bankActions)) */ T0_init:
if
:: (! ((bankActions)) && (okPIN)) -> goto accept_S4 :: (1) -> goto T0_init
fi; accept_S4:
if
:: (! ((bankActions))) -> goto accept_S4 fi;
}
Yêu cầu thứ hai: Nếu số tiền trong tài khoản lớn hơn hoặc bằng số tiền khách hàng muốn rút, thì khách hàng sẽ rút được tiền. Công thức LTL của yêu cầu trên như sau: ((amount_Balance >= amount_Withdraw) → withdrawOK)
# define payment (amount_Balance >= amount_Withdraw) never { /* !([] (payment -> <> withdrawOK)) */ T0_init:
if
:: (! ((withdrawOK)) && (payment)) -> goto accept_S4 :: (1) -> goto T0_init
fi;
accept_S4: if
:: (! ((withdrawOK))) -> goto accept_S4 fi;
}
Luận văn dùng SPIN để kiểm chứng mô hình và các đặc tả của hệ thống để đưa ra kết luận là mô hình đã thỏa mãn đặc tả của hệ thống.
Với yêu cầu đặc tả đầu tiên, mô hình hệ thống thoả mãn được đặc tả. Kết quả kiểm chứng bằng SPIN được thể hiện trong hình 6.7.
Hình 6.7. Kết quả kiểm chứng với yêu cầu đặc tả thứ nhất
Kết quả là: mô hình thoả mãn yêu cầu đặc tả thứ hai của hệ thống như hình 6.8.
Hình 6.8. Kết quả kiểm chứng với yêu cầu đặc tả thứ hai
Ở đây, ta kết luận là mô hình thoả mãn đặc tả của hệ thống. Ta gia sử là cả mô hình và đặc tả của hệ thống đều đã đúng, nó tương ứng với trường hợp (1) ở bảng 5.1.
6.3. Biến đổi hệ thống bằng kỹ thuật kiểm thử đột biến
Từ mô hình đã thỏa mãn đặc tả ở bước hai, ta biến đổi chương trình bằng các phép biến đổi đột biến trong mã lệnh Promela.
Luận văn thực hiện việc biến đổi theo hai cách như đã đề xuất ở chương 5:
Trường hợp (2): Biến đổi mô hình của hệ thống để thu được các mô hình biến thể, còn đặc tả của chương trình vẫn giữ nguyên. Sau đó ta dùng SPIN để kiểm chứng mô hình biến thể xem có thỏa mãn đặc tả đúng của hệ thống. Kết quả trả về là mô hình biến thể không thỏa mãn đặc tả, và các phản ví dụ được sinh ra.
Trường hợp (3): Biển đổi đặc tả của hệ thống để thu được các đặc tả biến thể, ta vẫn giữ nguyên mô hình của hệ thống. Tiếp theo, ta dùng SPIN để kiếm chứng xem mô hình có thỏa mãn đặc tả đã bị biến đổi. Thực nghiệm cho thấy là mô hình đã không còn thỏa mãn đặc tả bị biến đổi. và các phản ví dụ được sinh ra.
Các phản ví dụ này chính là đầu vào cho các ca kiểm thử trong quá trình kiểm thử trên mã nguồn của chương trình sau này.
6.3.1. Biến đổi mô hình hệ thống
Ở đây, ta sử dụng kỹ thuật kiểm thử đột biến, dùng các toán tử đột biến để biến