Mô hình hóa và kiểm thử máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn (FSM FINITE state machines testing)

Hiện nay việc kiểm thử phần mềm đang sử dụng một đặc tả hình thức đóng vai trò như các mô hình ngữ nghĩa chẳng hạn như máy trạng thái hữu hạn, biểu đồ chuyển trạng thái.. Việc mô hình h

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

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ MINH THÚY

MÔ HÌNH HÓA VÀ KIỂM THỬ MÁY RÚT TIỀN ATM BẰNG KỸ THUẬT

SINH CA KIỂM THỬ TỪ MÁY TRẠNG THÁI HỮU HẠN

(FSM – FINITE STATE MACHINES TESTING)

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

HÀ NỘI, 2015

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

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ MINH THÚY

MÔ HÌNH HÓA VÀ KIỂM THỬ MÁY RÚT TIỀN ATM BẰNG KỸ THUẬT

SINH CA KIỂM THỬ TỪ MÁY TRẠNG THÁI HỮU HẠN

(FSM – FINITE STATE MACHINES TESTING)

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

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS ĐẶNG VĂN HƯNG

HÀ NỘI, 2015

1

LỜI CẢM ƠN

Đầu tiên tôi xin được bày tỏ sự trân trọng và lòng biết ơn sâu sắc và gửi lời cảm ơn đặc biệt nhất tới TS Đặng Văn Hưng, giảng viên Bộ môn Công nghệ phần mềm – Khoa Công nghệ thông tin – Trường Đại học Công nghệ - ĐHQGHN Trong thời gian học và nhận đề tài, thầy đã định hướng đề tài, cung cấp cho tôi những kiến thức, những tài liệu, để thực hiện đề tài luận văn cao học này, từ những ý tưởng trong

đề cương nghiên cứu, phương pháp nghiên cứu, phương pháp giải quyết vấn đề trong luận văn cao học Thầy đã dành nhiều thời gian quý giá và tận tình chỉ bảo, hướng dẫn tôi trong suốt quá trình triển khai, việc nghiên cứu cho đến những lần kiểm tra cuối cùng để hoàn thành đề tài: “Mô hình hóa và kiểm thử máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ FSM”

Tôi xin bày tỏ lòng biết ơn chân thành và sâu sắc tới Trường Đại học Công nghệ - ĐHQGHN, phòng đào tạo sau đại học đã tạo điều kiện cho tôi được học tập và hoàn thiện quá trình học tập được đào tạo tại nhà trường.

Tôi xin chân thành cảm ơn tới GS, TS là các Thầy, Cô giáo trong bộ môn Kỹ thuật phần mềm, Khoa công nghệ thông tin, những người đã trực tiếp giảng dạy và truyền đạt giúp tôi mở rộng những kiến thức khoa học về công nghệ thông tin nói chung và Kỹ thuật phần mềm nói riêng Các thầy đã giúp tôi hiểu thấu đáo hơn lĩnh vực mà tôi nghiên cứu để có thể vận dụng các kiến thức đó trong thực tế và công việc của mình Đó là những kiến thức quý báu và rất có ích với tôi trong giai đoạn hiện tại

và trong tương lai

Tôi xin gửi lời cảm ơn đến gia đình, bạn bè những người đã luôn động viên khuyến khích tôi trong suốt quá trình học tập cũng như thực hiện đề tài luận văn của mình

Tôi xin chân thành cảm ơn!

Tác giả

Nguyễn Thị Minh Thúy

2

LỜI CAM ĐOAN

Tôi xin cam đoan rằng, nội dung trình bày trong luận văn này là do tôi tự nghiên cứu tìm hiểu dựa trên các tài liệu và tôi trình bày theo ý hiểu của bản thân dưới

sự hướng dẫn trực tiếp của Thầy TS Đặng Văn Hưng Các nội dung nghiên cứu, tìm hiểu và kết quả trong đề tài này là hoàn toàn trung thực

Luận văn này của tôi chưa từng được ai công bố trong bất cứ công trình nào

Trong quá trình thực hiện luận văn này tôi đã tham khảo đến các tài liệu của một số tác giả, tôi đã ghi rõ tên tài liệu, nguồn gốc tài liệu, tên tác giả và tôi đã liệt kê trong mục “TÀI LIỆU THAM KHẢO” ở cuối luận văn

Hà nội, tháng 11 năm 2015

Tác giả

Nguyễn Thị Minh Thúy

3

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 3

BẢNG CHỮ VIẾT TẮT VÀ THUẬT NGỮ 5

DANH MỤC HÌNH VẼ 6

DANH MỤC BẢNG 6

MỞ ĐẦU 7

1 Đặt vấn đề 7

2 Mục tiêu và nhiệm vụ nghiên cứu 7

3 Đối tượng và phạm vi nghiên cứu 7

4 Phương pháp nghiên cứu 8

5 Ý nghĩa khoa học và thực tiễn của luận văn 8

6 Bố cục luận văn 9

NỘI DUNG 10

Chương 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 10

1.1 Kiểm thử phần mềm là gì? 10

1.2 Chất lượng và độ tin cậy của phần mềm 10

1.3 Vai trò của kiểm thử phần mềm 11

1.4 Các thuật ngữ trong kiểm thử phần mềm 12

1.5 Ca kiểm thử (test case) là gì? 13

1.6 Trường hợp (Use case) kiểm thử trong phần mềm là gì? 14

1.7 Các mức kiểm thử phần mềm 16

1.8 Kỹ thuật kiểm thử tĩnh và tiến trình kiểm thử 23

Chương 2 MÔ HÌNH MÁY TRẠNG THÁI HỮU HẠN VÀ KỸ THUẬT SINH CA KIỂM THỬ TỪ FSM 30

2.1 Giới thiệu về mô hình hóa 30

4

2.2 Mô hình định hướng trạng thái 32

2.3 Máy trạng thái hữu hạn 34

2.4 Một số cách biểu diễn cho FSM 37

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

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

2.7 Kiểm thử với trạng thái kiểm chứng 44

2.7.1 Chuỗi vào – ra duy nhất (Unique Input - Output sequence) 46

2.7.2 Chuỗi phân biệt (Distinguishing sequence) 48

2.7.3 Chuỗi đặc trưng (Characterizing sequence) 50

2.8 Độ bao phủ mô hình máy hữu hạn trạng thái 51

2.8.1 Một số đặc trưng của máy hữu hạn trạng thái 51

2.8.2 Độ bao phủ của máy hữu hạn trạng thái 51

a Độ bao phủ trạng thái (State coverage) 53

b Độ bao phủ chuyển trạng thái (transition coverage) 55

2.9 Kỹ thuật sinh ca kiểm thử 57

2.9.1 Sinh cây kiểm thử và tìm tập bao phủ chuyển trạng thái 57

2.9.2 Sinh ca kiểm thử dựa trên hành vi chuyển đổi trạng thái của FSM 58

Chương 3 KIỂM THỬ HỆ THỐNG ATM DỰA TRÊN MÔ HÌNH FSM 61

3.1 Mô tả hệ thống ATM 61

3.2 Đặc tả của ATM từ mô hình FSM 61

3.2.1 Đặc tả yêu cầu hệ thống 61

3.2.2 Xây dựng mô hình FSM của ATM 63

3.3 Thuận lợi và khó khăn của máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ FSM 84

KẾT LUẬN 85

TÀI LIỆU THAM KHẢO 86

5

BẢNG CHỮ VIẾT TẮT VÀ THUẬT NGỮ

6

DANH MỤC HÌNH VẼ

Hình 1.1 Qui trình phát triển và các mức kiểm thử trong mô hình chữ V 17

Hình 2.1 Hình ảnh của hệ thống phần mềm 33

Hình 2.2 Tương tác giữa hệ thống và môi trường mô hình hóa như FSM 34

Hình 2.3 Mô hình chuyển trạng thái của FSM 35

Hình 2.4 Mô hình nhận dạng mã PIN của ATM 36

Hình 2.5 FSM của ATM biểu diễn bằng đồ thị 38

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

Hình 2.7 Mô hình kiểm thử với việc kiểm chứng trạng thái 45

Hình 2.8 FSM quá trình chuyển đổi trạng thái cho ATM 53

Hình 2.9 Một đường đi bao phủ tất cả các trạng thái của FSM ATM 54

Hình 3 1 Mô hình hoạt động giao dịch hệ thống ATM 61

Hình 3 2 Mô hình FSM chuyển đổi trạng thái của ATM 66

Hình 3 3 Cây kiểm thử của máy trạng thái hữu hạn ATM 83

DANH MỤC BẢNG Bảng 1 1 Mô tả nhập mã PIN của ATM 15

Bảng 2 1 Biểu diễn FSM bằng dạng bảng 39

Bảng 3 1 Bảng biểu diễn trạng thái FSM của ATM 65

Bảng 3 2 Bảng gán nhãn cho các trạng thái 67

Bảng 3 3 Bảng gán nhãn cho kết quả đầu vào/ đầu ra cho hệ thống ATM 68

Bảng 3 4 Bảng gán nhãn cho quá trình chuyển đổi 69

Bảng 3 5 Thông tin chi tiết của quá trình chuyển đổi cho hệ thống ATM 71

Bảng 3 6 Dãy chuyển đổi bao phủ tất cả các trạng thái trong hình 3.2 72

Bảng 3 7 Dãy chuyển đổi bao phủ tất cả các trạng thái chuyển đổi trong hình 3.2 74

Bảng 3 8 Chuỗi vào – ra duy nhất cho mỗi trạng thái của ATM 76

Bảng 3 9 Các chuỗi kiểm thử cho mỗi trạng thái chuyển tiếp của ATM 82

Hiện nay việc kiểm thử phần mềm đang sử dụng một đặc tả hình thức đóng vai trò như các mô hình ngữ nghĩa chẳng hạn như máy trạng thái hữu hạn, biểu đồ chuyển trạng thái Các mô hình đặc tả này được sử dụng làm mục đích để chứng minh tính đúng đắn của hành vi đặc tả hệ thống phần mềm hay các đối tượng và cũng được dùng

để sinh các ca kiểm thử Việc sinh ca kiểm thử từ đặc tả máy trạng thái hữu hạn (FSM

- Finite State Machines) được áp dụng trong lĩnh vực kiểm thử các hệ thống phần mềm cho các hệ phản vệ (reactive system) Máy rút tiền ATM là một hệ phản vệ thông dụng và đòi hỏi tính đúng đắn, độ tin cậy cao Đặc tả trực quan nhất của máy ATM là máy trạng thái hữu hạn, vì thế để kiểm thử máy ATM tôi sử dụng kỹ thuật sinh

ca kiểm thử từ máy trạng thái hữu hạn, trong luận văn này tôi chọn đề tài “Mô hình hóa và kiểm thử máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn (FSM-Finite State Machines Testing)”

2 Mục tiêu và nhiệm vụ nghiên cứu

Luận văn này đề cập các vấn đề về kiểm thử máy trạng thái hữu hạn (Finite State Machines Testing) và ứng dụng kiểm thử máy rút tiền ATM Sau khi mô hình hóa máy ATM bằng một máy trạng thái hữu hạn, luận văn cũng nghiên cứu các phương pháp sinh ca kiểm thử từ máy trạng thái (FSM) đồng thời đưa ra những nhận xét, đánh giá khi áp dụng vào mô hình của máy ATM

3 Đối tƣợng và phạm vi nghiên cứu

Đối tƣợng nghiên cứu:

 Nghiên cứu cơ sở lý thuyết về kiểm thử mô hình máy trạng thái

 Nghiên cứu về kỹ thuật mô hình hóa phần mềm phản vệ bằng máy hữu hạn trạng thái hữu hạn (FSM)

Phạm vi nghiên cứu:

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

 Thử nghiệm kiểm thử mô hình cho hệ thống máy rút tiền tự động ATM

4 Phương pháp nghiên cứu

 Đọc tài liệu, lựa chọn nội dung phù hợp từ tài liệu tham khảo và nhiều bài báo khoa học có liên quan mật thiết về đề tài nghiên cứu

 Phân tích, xác định trọng tâm và xây dựng cơ sở lý luận về vấn đề nghiên cứu

và trên cơ sở đó thực hiện giải quyết vấn đề thông qua việc thiết kế bộ kiểm thử máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn

 Nghiên cứu, tìm hiểu các kỹ thuật, chiến lược kiểm thử phần mềm

 Đưa ra tài liệu kế hoạch kiểm thử và đặc tả kiểm thử, xây dựng chương trình thực thi kiểm thử

 Đánh giá và rút ra bài học kinh nghiệm thực tiễn

5 Ý nghĩa khoa học và thực tiễn của luận văn

Ý nghĩa khoa học: Đứng trước sự gia tăng mức độ phức tạp của phần mềm,

việc trực quan hoá, mô hình hóa và kiểm thử phần mềm ngày càng trở nên chính yếu trong cách tiếp cận xem xét về một hệ thống Mô hình hóa là một dạng thức trừu tượng của một hệ thống, được hình thành để hiểu hệ thống trước khi xây dựng hoặc thay đổi

hệ thống đó Mô hình hóa cung cấp một phương tiện để quan niệm hóa vấn đề và giúp chúng ta có thể trao đổi các ý tưởng trong một hình thức cụ thể, không mơ hồ Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi, còn là quá trình khảo sát hệ thống hay phần mềm dưới những điều kiện xác định, để quan sát và ghi lại kết quả, và đánh giá một khía cạnh nào đó của hệ thống Mục đích chính của đề tài là trình bày phương pháp mô hình hóa bằng FSM của ATM và sinh ca kiểm thử từ

đặc tả máy trạng thái FSM (Finite State Machines Testing) của ATM Việc mô hình

hóa bằng FSM là làm sáng tỏ vấn đề để có thể đưa ra được các lỗi hoặc các thiếu sót của hệ thống từ việc tiếp cận trực quan đồ họa hơn là các dạng trình bày như văn bản,

đoạn mã,…

Ý nghĩa thực tiễn: Luận văn trình bày phương pháp kiểm thử dựa trên mô hình

máy hữu hạn trạng thái và dùng khái niệm mô phỏng như là một tiêu chí để đánh giá

9

sự cài đặt đúng đắn của hệ thống so với đặc tả Luận văn đi sâu nghiên cứu về độ bao phủ của mô hình máy hữu hạn trạng thái, và từ đó đưa ra phương pháp sinh ca kiểm thử để kiểm thử xem hệ thống cài đặt có mô phỏng bản đặc tả phần mềm dựa trên mô hình máy hữu hạn trạng thái hay không Hướng phát triển tiếp theo của luận văn là tìm cách cải tiến phương pháp sinh ca kiểm thử sao cho số ca kiểm thử là ít nhất nhưng độ bao phủ là lớn nhất có thể Đồng thời, sẽ xây dựng một chương trình sinh ca kiểm thử dựa trên phương pháp đã được cải tiến

6 Bố cục luận văn

A MỞ ĐẦU

B NỘI DUNG

Chương 1: Trình bày kiến thức cơ bản về kiểm thử phần mềm

Chương 2: Nghiên cứu về mô hình máy trạng thái hữu hạn và trình bày các

phương pháp về kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn(FSM-Finite State Machines) Để mô tả máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn

Chương 3: Đặc tả và xây dựng mô hình kiểm thử phần mềm máy hữu hạn trạng

thái ATM Tìm hiểu và đề xuất quy trình kiểm thử máy rút tiền ATM sử dụng máy trạng thái hữu hạn, sau đó áp dụng các kỹ thuật kiểm thử này vào kiểm thử mô hình phần mềm giả lập máy rút tiền tự động ATM sử dụng trạng thái máy hữu hạn

C KẾT LUẬN

Đưa ra những nhận xét, đánh giá khi áp dụng vào mô hình của máy ATM và định hướng khóa luận trong tương lai

10

NỘI DUNG Chương 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm mà từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm Bên cạch đó các kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm Để đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế, phát triển phần mềm và thực hiện công việc đúng như kỳ vọng và đáp ứng được mọi nhu cầu của các bên liên quan Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm Và việc kiểm thử phần mềm là một quá trình

nỗ lực để đưa ra những đánh giá này Mục tiêu của kiểm thử là với lý do hoặc mục đích cho việc thiết kế và thực hiện kiểm thử Bởi vậy ở chương này, tôi xin giới thiệu

sơ lược về tổng quan của kiểm thử phần mềm và các kỹ thuật kiểm thử phần mềm

1.1 Kiểm thử phần mềm là gì?

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó1

.Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi2 Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau3

Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?

1.2 Chất lượng và độ tin cậy của phần mềm

a Chất lượng của phần mềm

11

Chất lượng của một sản phẩm phần mềm là sự đáp ứng các yêu cầu về chức năng, sự hoàn thiện và các chuẩn đã được đặc tả, cùng các đặc trưng mong chờ từ mọi sản phẩm phần mềm chuyên nghiệp Chất lượng phần mềm đặc trưng cho “độ tốt, độ tuyệt hảo” của phần mềm và dưới đây là năm quan điểm của chất lượng phần mềm:

+ Quan điểm theo cảm tính: Là chất lượng phần mềm như có thể là cái gì đó + Quan điểm người dùng về chất lượng phần mềm như: tính chính xác, tính đúng đắn (hành vi đúng như đặc tả), tính hiệu quả (tiết kiệm thời gian và tiền bạc), độ tin cậy, tính khả kiểm thử (kiểm thử được và dễ), dễ học, dễ sử dụng, dễ bảo trì

+ Quan điểm của nhà sản xuất: Là chất lượng phần mềm phải phù hợp với các đặc tả của nó

+ Quan điểm về sản phẩm: Chất lượng sản phẩm được xem như gắn liền với các đặc tính vốn có của sản phẩm Thì phương pháp xây dựng sản phẩm phải tốt

+ Quan điểm về giá trị: Chất lượng, theo quan điểm này phụ thuộc vào khách hàng đưa ra số tiền sẵn sàng trả giá cho phần mềm đó

Các yếu tố về mặt nhân tố chất lượng đó là hành vi đặc trưng của hệ thống phần mềm như tính có cấu trúc, tính đơn thể, độ tin cậy, hiệu quả và tính khả kiểm thử, Còn các yếu tố về mặt chất lượng là những yếu tố chất lượng liên quan đến chất lượng phần mềm như tính đơn thể là một thuộc tính (attributes) của chất lượng phần mềm được chia các mã code thành những đoạn riêng lẻ Tuy nhiên người kiểm thử hay nhầm lẫn giữa độ tin cậy với chất lượng của phần mềm Khi kiểm thử đạt tới mức phần mềm chạy ổn định thì người kiểm thử thường cho rằng phần mềm đã đạt được chất lượng cao

b Độ tin cậy của phần mềm

Độ tin cậy chỉ là một yếu tố để đánh giá chất lượng phầm mềm Độ tin cậy của phần mềm là xác suất để phần mềm chạy không có thất bại trong một khoảng thời gian nhất định Nó được xem là một yếu tố quan trọng của chất lượng phần mềm Ngoài ra, thời gian trung bình cho việc khắc phục một sự cố cũng là một thông số quan trọng trong việc đánh giá độ tin

1.3 Vai trò của kiểm thử phần mềm

Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá và thu được chất lượng cao của sản phẩm phần mềm trong quá trình phát triển Thông qua chu

trình “kiểm thử - tìm lỗi - sửa lỗi”, ta hy vọng chất lượng của sản phẩm phần mềm sẽ

được cải tiến Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khi cho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mức nào Vì thế, nhiều tác

12

giả đã mô tả việc kiểm thử phần mềm là một quy trình kiểm chứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm Quy trình này gồm hai công việc chính là phân tích tĩnh và phân tích động

Phân tích tĩnh: Việc phân tích tĩnh được tiến hành dựa trên việc khảo sát các

tài liệu được xây dựng trong quá trình phát triển sản phẩm như tài liệu đặc tả nhu cầu người dùng, mô hình phần mềm, hồ sơ thiết kế và mã nguồn phần mềm Các phương pháp phân tích tĩnh truyền thống bao gồm việc khảo sát đặc tả và mã nguồn cùng các tài liệu thiết kế Người ta cũng có thể dùng các kỹ thuật phân tích hình thức như kiểm chứng mô hình (model checking) và chứng minh định lý (theorem proving) để chứng minh tính đúng đắn của thiết kế và mã nguồn Vì vậy mà công việc này không kiểm tra đến việc thực thi chương trình mà chỉ duyệt, lý giải về tất cả các hành vi có thể của chương trình khi được thực thi Tối ưu hóa các chương trình dịch là các ví dụ về phân tích tĩnh

Phân tích động: Phân tích động liên quan đến việc thực thi chương trình để

phát hiện những thất bại có thể có của chương trình, hoặc quan sát các tính chất về hành vi và hiệu quả (performance) Vì gần như không thể thực thi chương trình trên tất

cả các dữ liệu đầu vào có thể, ta chỉ có thể chọn một tập con các dữ liệu đầu vào để thực thi, gọi là các “ca kiểm thử”

Bằng cách thực hiện phân tích tĩnh và động, người kiểm thử muốn phát hiện nhiều lỗi nhất, để chúng có thể được sửa ở giai đoạn sớm nhất trong quá trình phát triển phần mềm Phân tích tĩnh và động là hai kỹ thuật bổ sung cho nhau và cần được làm lặp đi lặp lại nhiều trong quá trình kiểm thử

1.4 Các thuật ngữ trong kiểm thử phần mềm

 Lỗi (Error): Là các lỗi do con người gây ra

 Sai (Fault): Sai là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai Cũng có

thể nói sai là một biểu diễn của lỗi dưới dạng một biểu thức như: Chương trình, văn bản, sơ đồ dòng dữ liệu, biểu đồ lớp,… Sai có thể khó bị phát hiện Đôi khi nhà thiết kế mắc lỗi bỏ sót trong quá trình thiết kế thì sẽ dẫn đến sai

 Thất bại (Failure): Xảy ra khi xuất hiện một lỗi được thực thi (khi thực thi

chương trình tại các nơi bị sai thì sẽ xảy ra trạng thái thất bại)

 Sự cố (Incident): Là những kết quả do thất bại đem đến Sự cố là các triệu

chứng liên kết với một thất bại và báo hiệu cho người dùng biết sự xuất hiện của thất bại

13

 Gỡ lỗi (Debugging): Quá trình tìm, phân tích và loại bỏ những nguyên nhân

gây thất bại trong phần mềm

 Yêu cầu (Requirment): Một điều kiện cần thiết để người phát triển giải quyết

một vấn đề hoặc đạt được mục tiêu phải được đáp ứng để đáp ứng một hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật

 Đánh giá (Review): Đánh giá tình trạng sản phẩm hoặc dự án để xác định sự

khác biệt từ kết quả dự định và đề nghị cải tiến Bao gồm đánh giá quản lý, đánh giá thông tin, đánh giá kỹ thuật, kiểm tra inspection và walkthrough

 Trường hợp kiểm thử (Test case): Trường hợp kiểm thử được liên kết tương

ứng với hoạt động của chương trình Một trường hợp kiểm thử bao gồm một tập các giá trị đầu vào và một danh sách các kết quả đầu ra mong muốn

 Thẩm định (Validation): Là quá trình để đảm bảo rằng sản phẩm đáp ứng

được yêu cầu của người dùng (khách hàng)

 Kiểm chứng (Verification): Kiểm chứng là quá trình để đảm bảo rằng một

sản phẩm phần mềm thỏa mãn đặc tả của nó

 Máy hữu hạn trạng thái (FSMs - Finite State Machines): Là một dạng mô

hình đa trạng thái, gồm 3 thành phần chính: các trạng thái, các cung chuyển trạng thái, các sự kiện (Event) hoặc hành động (Action)

 Máy rút tiền tự động (ATM - Automated Teller Machine): Là một thiết bị

ngân hàng giao dịch tự động với khách hàng, thực hiện việc nhận dạng khách hàng thông qua thẻ ATM ( thẻ ghi nợ, thẻ tín dụng) hay các thiết bị tương thích, và giúp khách hàng kiểm tra tài khoản, rút tiền mặt, chuyển khoản, thanh toán tiền hàng hóa dịch vụ4

1.5 Ca kiểm thử (test case) là gì?

Test case là mô tả một dữ liệu đầu vào (input), hành động (action) hoặc sự kiện (event) và một kết quả mong đợi (expected response), để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không Một test case có thể có các phần đặc thù khác nhau như mã test case, tên test case, mục tiêu test, các điều kiện test, các yêu cầu data input, các bước thực hiện và các kết quả mong đợi Do vậy, quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó đòi hỏi người kiểm thử phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng

Vì vậy, việc chuẩn bị test case sớm nhất có thể trong quy trình phát triển phần mềm là rất hữu ích Nói chung, test case là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng thỏa mãn yêu cầu đặt ra hay không và gồm 3 bước cơ bản như sau:

14

 Mô tả: Đặc tả các điều kiện cần tiến hành kiểm tra

 Nhập: Đặc tả đối tượng hoặc dữ liệu cần thiết, được sử dụng làm đầu vào

để thực hiện kiểm tra

 Kết quả mong đợi: Là kết quả trả về từ đối tượng được kiểm tra

1.6 Trường hợp (Use case) kiểm thử trong phần mềm là gì?

Sử dụng trường hợp kiểm thử là một kỹ thuật giúp chúng ta xác định được các trường hợp kiểm thử đó thực hiện toàn bộ hệ thống trên một giao dịch theo từng giao dịch từ đầu đến cuối

 Một trường hợp sử dụng là một mô tả chi tiết cụ thể của hệ thống được xác định bởi một tác nhân (một người sử dụng của hệ thống) Mỗi trường hợp sử dụng được mô tả tương tác với các tác nhân đã có trong hệ thống để đạt được một nhiệm vụ cụ thể như: sản xuất cái gì có giá trị cho người sử dụng,

 Nói chung tác nhân là người trong hệ thống nhưng cũng có thể là các hệ thống khác

 Trường hợp sử dụng là một chuỗi các bước mô tả sự tương tác giữa các tác nhân và hệ thống Sử dụng các trường hợp được quy định tại các điều kiện của tác nhân, không hệ thống, mô tả những gì các tác nhân làm và những gì các tác nhân nhìn thấy hơn là những gì đầu vào hệ thống mong muốn và những gì kết quả đầu ra của hệ thống

 Họ thường sử dụng ngôn ngữ và các điều kiện của người giao dịch chứ không phải là thuật ngữ kỹ thuật, đặc biệt là khi các tác nhân là một người giao dịch của hệ thống

 Trường hợp thử nghiệm chủ yếu là ở cấp hệ thống kiểm tra và chấp nhận

 Trường hợp sử dụng có thể khám phá các khiếm khuyết được tạo ra bởi sự tương tác không chính xác giữa các thành phần

 Trường hợp sử dụng mô tả quá trình hoạt động của một hệ thống dựa trên nhiều khả năng của nó Điều này làm cho các trường hợp kiểm thử từ trường hợp sử dụng đặc biệt tốt cho việc tìm kiếm các khiếm khuyết trong việc sử dụng thực tế của hệ thống (tức là những khuyết tật mà người sử dụng có nhiều khả năng đi qua khi lần đầu tiên sử dụng hệ thống)

 Mỗi trường hợp sử dụng thường có một xu hướng chính hoặc có thể là kịch bản và đôi khi thêm các nhánh khác bao gồm: ví dụ, trường hợp đặc biệt hoặc điều kiện ngoại lệ

Ví dụ: Về việc nhập mã PIN vào hệ thống ATM sau cho thấy kịch bản thành

công và không thành công Trong sơ đồ này, là sự tương tác giữa A (Actor –tác nhân trong trường hợp này là con người) và S (System – hệ thống) Từ bước 1 đến bước 5 là các kịch bản thành công, cho ta thấy rằng thẻ và PIN cả hai đã xác nhận và cho phép tác nhân để truy cập vào tài khoản Nhưng trong phần mở rộng (Extensions) có ba trường hợp khác nhau là 2a, 4a, 4b được thể hiện trong biểu đồ dưới đây

Main Success Scenario

2a Card not valid

S: Display message and reject card 4a PIN not valid

S: Display message and ask for retry (twice) 4b PIN invalid 3 times

S: eat card and exit

Bảng 1 1 Mô tả nhập mã PIN của ATM

Đối với trường hợp sử dụng thử nghiệm, tôi sẽ đưa ra một bài kiểm tra của các kịch bản thành công và là một thử nghiệm cho mỗi lần mở rộng Trong ví dụ này, chúng ta có thể cho phần mở rộng 4b một sự ưu tiên cao hơn 4a từ một góc nhìn Yêu cầu hệ thống cũng có thể được quy định như một tập hợp các trường hợp sử dụng Cách tiếp cận này có thể làm cho nó dễ dàng hơn để liên quan đến người sử dụng trong các yêu cầu thu thập và xác định qui trình hoạt động của hệ thống

16

1.7 Các mức kiểm thử phần mềm

Trong thực tế, kiểm thử phần mềm có nhiều mức khác nhau và có mối quan hệ chặt chẽ với các giai đoạn phát triển trong một dự án phát triển phần mềm Có bốn mức kiểm thử phần mềm cơ bản: Unit test (kiểm thử đơn vị); Integration test (kiểm thử tích hợp); System test (kiểm thử hệ thống); Acceptance test (kiểm thử chấp nhận) Trong đó chỉ có ba loại kiểm thử đầu tiên được thực hiện bởi các nhóm phát triển trong đơn vị sản xuất phần mềm, còn kiểm thử chấp nhận được thực hiện bởi khách hàng Bốn loại kiểm thử trên kết hợp với nhau tạo thành mô hình chữ V

Ƣu điểm

- Đơn giản dễ sử dụng

- Có hoạt động, kế hoạch cụ thể cho quá trình test

- Tiết kiệm được thời gian, và có cơ hội thành công cao hơn waterfall

- Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu

Nhƣợc điểm

- Độ linh hoạt ít và còn tồn tại sự cứng nhắc Nó thể hiện ở chỗ cứ sau mỗi step thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức tạp và

dễ hiểu, thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian

- Giống với waterfall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu Không đáp ứng được yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm

- Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, update lại tài liệu

Áp dụng cho những dự án nhƣ thế nào?

- Dự án có kích thước nhỏ, và trung bình, các yêu cầu dự án là rõ ràng, cố định

- Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn

có để đảm bảo được yêu cầu, đọc nhanh, test nhanh và coding nhanh

- Nếu khách hàng có sự tự tin cao trong yêu cầu thiết kế (nghĩa là ít thay đổi, ít dao động) thì mô hình chữ V (V model) là lựa chọn cần thiết

17

Hình 1.1 Qui trình phát triển và các mức kiểm thử trong mô hình chữ V

Giai đoạn phát triển:

Xác định yêu cầu và đặc tả (Requirement & Specification): Xác định yêu cầu

cần thiết mà hệ thống đòi hỏi, đưa ra bản đặc tả

Phân tích hệ thống (System Analysis): Phân tích các yêu cầu mà hệ thống cần

có và đưa ra giải pháp tích hợp các yêu cầu đó vào hệ thống

Thiết kế chi tiết (Detailed Design): Chi tiết hóa các bước thực hiện xây dựng hệ

thống về cả giao diện và nội dung

Phát triển (Development): Thực hiện việc viết code

Giai đoạn kiểm thử:

a Kiểm thử đơn vị (Unit test)

18

- Chương trình

- Chuyển đổi dữ liệu, thay đổi chương trình

- Mô hình cơ sở dữ liệu

Để hiểu rõ về kiểm thử đơn vị, thì ta phải hiểu rõ: thế nào là một đơn vị phần mềm? Một đơn vị là một thành phần, phần mềm nhỏ nhất mà ta có thể kiểm thử được như: các hàm (Function), các thủ tục (Procedure), các lớp (Class), hoặc các phương thức (Method) đề có thể được xem là đơn vị Vì đơn vị được chọn để kiểm thử thường

có kích thước nhỏ và chức năng hoạt động đơn giản, dễ tổ chức, kiểm tra, ghi nhận và phân tích kết quả nhận được Một đơn vị chương trình là một đoạn mã nguồn như hàm hoặc phương thức của một lớp, có thể được gọi từ ngoài và cũng có thể gọi đến các đơn vị chương trình khác Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục lỗi đối với một đơn vị tương đối dễ dàng Một nguyên lý đúc kết từ thực tiễn là: thời gian tốn kém cho kiểm thử đơn vị sẽ được bù đắp bằng việc tiết kệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó

Kiểm thử đơn vị là việc kiểm thử các đơn vị chương trình một cách cô lập Kiểm thử đơn vị tập trung vào việc xác minh trên đơn vị nhỏ nhất của thiết kế phần mềm Tuy nhiên, 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, với dữ liệu nhập và chức năng của đơn vị Các mức kiểm thử nhằm phát hiện các lỗi trong các phạm vi của module bao gồm: giao diện module; cấu trúc dữ liệu cục bộ; điều kiện biên; đường dẫn độc lập; đường dẫn xử lý lỗi Do đó kiểm thử đơn vị đò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ỗi nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị như: chuỗi các lệnh sau điều kiện If và nằm giữa Then… Else là một nhánh

Kiểm thử đơn vị thường được xem như một phần phụ cho các bước mã hóa sau khi mã nguồn được phát triển, được duyệt lại và được kiểm tra đúng cú pháp thì bắt đầu thiết kế các trường hợp kiểm thử đơn vị Kiểm thử đơn vị thường được làm bởi chính tác giả (lập trình viên) của chương trình và có thể tiến hành theo hai giai đoạn: kiểm thử đơn vị tĩnh (static unit testing) và kiểm thử đơn vị động (dynamic unit testing)

 Kiểm thử đơn vị tĩnh là việc kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu, được thực hiện qua các bước: chuẩn bị kịch bản, nhân lực  chuẩn bị câu hỏi; yêu cầu thay đổi kiểm tra, đánh giá; mã nguồn  tác giả

mã nguồn sửa những vấn đề thay đổi  xác minh lại  kết thúc

19

 Kiểm thử đơn vị động là việc khảo sát đơn vị dựa vào việc tiến hành, gồm các bước:

1) Đơn vị được tách ra khỏi môi trường;

2) Môi trường được làm giả bằng cách tạo ra các Test driver và Stub Test driver là chương trình được viết nhằm gọi đến đơn vị đang được thử Còn Stub là một đơn vị giả lập để đơn vị gọi đến nhằm quan sát dòng điều khiển và giao diện của đơn vị đang được thử

3) Dịch và tiến hành Quan sát để xác định hành vi có đúng không Nếu không đúng như chờ đợi thì đơn vị có lỗi

b Kiểm thử tích hợp (Integration test)

Cơ sở kiểm thử :

- Thiết kế hệ thống và phần mềm, kiến trúc

- Luồng công việc và các trường hợp sử dụng

Đối tƣợng kiểm thử:

- Các hệ thống con, cơ sở dữ liệu

- Cơ sở hạ tầng, giao diện

- Cấu hình hệ thống và cấu hình dữ liệu

Kiểm thử tích hợp nhằm đảm bảo hệ thống làm việc ổn định trong môi trường thí nghiệm để sẵn sàng cho việc đưa vào môi trường thực sự bằng cách đặt các đơn vị với nhau theo phương pháp tăng dần Kiểm thử tích hợp có 2 mục đích 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ẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là một hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra hệ thống Kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng Unit test và tất cả các lỗi mức đơn vị đã được sửa chữa Trong kiểm thử tích hợp gồm:

 Kiểm thử cấu trúc: Nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng

 Kiểm thử chức năng: Nhằm chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kĩ thuật

 Kiểm thử hiệu năng: Kiểm tra việc vận hành của hệ thống

 Kiểm thử khả năng chịu tải: Kiểm tra các giới hạn của hệ thống

20

Tóm lại, kiểm thử tích hợp kiểm tra các giao diện giữa các thành phần, tương tác với các phần khác nhau của một hệ thống như là hệ điều hành, hệ thống file, phần cứng và các giao diện giữa các hệ thống Có nhiều hơn một mức độ kiểm thử tích hợp

và nó có thể thực hiện trên các đối tượng của các quy mô khác nhau như sau:

o Kiểm thử tích hợp thành phần, kiểm tra sự tương tác giữa các thành phần phần mềm và được thực hiện sau kiểm thử thành phần

o Kiểm thử tích hợp hệ thống, kiểm tra sự tương tác giữa các hệ thống khác nhau hoặc giữa phần cứng và phần mềm Được thực hiện sau kiểm thử hệ thống

o Kiểm thử tích hợp dựa trên kiến trúc hệ thống ( như là top-down và up), các nhiệm vụ chức năng, trình tự xử lý giao dịch hoặc một vài khía cạnh của hệ thống hoặc các phần mềm Để dễ dàng sữa lỗi và phát hiện lỗi sớm phương pháp kiểm thử tích hợp thường được dùng là “big bang”

bottom-o Kiểm thử tích hợp có thể bao gồm kiểm thử phi chức năng (như kiểm thử hiệu suất)

o Tester sẽ là người thực hiện kiểm thử tích hợp Cả hai phương pháp tiếp cận chức năng ( functional) và cấu trúc (structural) sẽ được sử dụng

o Kiểm thử tích hợp được lên kế hoạch trước khi các thành phần và hệ thống được xây dựng

c Kiểm thử hệ thống (System test)

Cơ sở kiểm thử:

- Yêu cầu đặc tả của phần mềm và hệ thống, các trường hợp sử dụng

- Đặc tả chức năng, báo cáo phân tích rủi ro

Đối tƣợng kiểm thử:

- Hệ thống, người sử dụng, hướng dẫn hoạt động

- Cấu hình hệ thống và cấu hình dữ liệu

Mục đích của kiểm thử hệ thống là kiểm tra thiết kế toàn bộ hệ thống có thỏa mãn yêu cầu đặt ra hay không?

Kiểm tra hệ thống thực tế là một tập các kiểm thử khác nhau với mục đích cơ bản là thực hiện đầy đủ hệ thống dựa trên máy tính Mặc dù mỗi kiểm thử có một mục đích khác nhau, nhưng tất cả các công việc đều nhằm kiểm tra tất cả các thành phần hệ thống được tích hợp một cách hợp lý và thực hiện đúng các chức năng đã xác định

21

Kiểm thử hệ thống được bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công Kiểm thử hệ thống kiểm tra các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng cũng như độ tin cậy, tính tiện lợi khi sử dụng và thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự

án Với mục đích nhằm đảm bảo rằng việc cài đặt tuân thủ đầy đủ các yêu cầu được đặc tả của người dùng Kiểm thử hệ thống có liên quan với các hành vi của cả hệ thống/sản phẩm

Trong kiểm thử hệ thống, môi trường kiểm thử phải tưng ứng với các mục tiêu hoặc môi trường sản xuất để giảm thiểu các rủi ro của các sự cố môi trường không được tìm thấy trong kiểm thử

Kiểm thử hệ thống bao gồm các kiểm tra dựa trên các rủi ro hoặc yêu cầu đặc

tả, quy trình nghiệp vụ, các trường hợp sửa dụng, các mô hình hành vi của hệ thống, tương tác với các hệ điều hành và tài nguyên hệ thống

Kiểm thử hệ thống kiểm tra các yêu cầu chức năng và phi chức năng và các đặc tính chất lượng dữ liệu Kiểm thử chức năng sử dụng kỹ thuật kiểm thử hộp đen Kiểm thử phi chức năng sử dụng các kỹ thuật kiểm thử hộp trắng Một đội kiểm thử độc lập thường thực hiện kiểm thử hệ thống Kiểm thử hệ thống gồm có các loại sau:

 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 việc phân bố tài nguyên hệ thống…

 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

 Kiểm thử cấu hình

 Kiểm thử khả năng bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu

 Kiểm thử tính 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 của dữ liệu

d Kiểm thử chấp nhận (Acceptance test)

Kiểm thử chấp nhận được thực thi bởi chính các khách hàng nhằm đảm bảo rằng sản phẩm phần mềm làm việc đúng như họ mong đợi Mục đích của kiểm thử chấp nhận là để chứng minh phần mềm thỏa mãn tất cả các yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm

Kiểm thử chấp nhận dựa vào:

 Các yêu cầu người dùng (User requirements);

22

 Các yêu cầu hệ thống (System requirements);

 Các trường hợp sử dụng (Use cases);

 Các qui trình xử lý công việc (Business processes);

 Các báo cáo phân tích rủi ro (Risk analysis reports);

Các mục tiêu kiểm tra chung:

 Kiểm tra các qui trình xử lý công việc trên hệ thống đã được tích hợp đầy

đủ nhất;

 Các qui trình hoạt động và bảo trì;

 Các thủ tục người dùng (ví dụ: phân quyền dựa trên user login);

Tóm lại kiểm thử chấp nhận là hoạt động thẩm định (Validation) và do người sử dụng, khách hàng kiểm tra Họ xem hệ thống phần mềm có đáp ứng đúng như mong muốn của họ không, không cần tài liệu đặc tả Chúng ta cần kiểm thử chấp nhận vì đặc

tả có thể đã có khiếm khuyết hoặc người khách hàng và phát triển cùng đọc một tài liệu nhưng hiểu không hoàn toàn Quyết định này, có thể dựa vào các số đo của sản phẩm hoặc quy trình Các số đo của sản phẩm thường được suy ra từ kết quả kiểm thử thống kê Số đo quy trình thường dựa trên kinh nghiệm của người đánh giá so với sản phẩm trước đó Các số đo này đánh giá mức độ tin cậy của phần mềm để quyết định triển khai cho người dùng cuối Gắn liền với giai đoạn kiểm thử chấp nhận thường là

23

một nhóm những dịch vụ và tài liệu đi kèm, được phổ biến như hướng dẫn cài đặt, sử dụng,…Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ

1.8 Kỹ thuật kiểm thử tĩnh và tiến trình kiểm thử 5

Kỹ thuật kiểm thử tĩnh dựa trên việc kiểm tra thủ công (reviews) và phân tích tĩnh tự động ( static analysis) của mã( code) hoặc tài liệu dự án mà không thực thi mã chương trình

Đánh giá (reviews) là một cách kiểm thử sản phẩm công việc phần mềm ( bao gồm cả code) được thực hiện trước kiểm thử động Các lỗi được phát hiện trong quá trình review sớm trong chu trình vòng đời ( ví dụ các lỗi được tìm thấy trong đặc tả) rẻ hơn nhiều so với các lỗi được phát hiện bằng cách chạy kiểm thử thi hành các mã

 Một đánh giá(review) được thực hiện như thế nào :

- Đánh giá thủ công (Review manually) và dùng công cụ hỗ trợ (Automated Analysis by Tool)

 Đối tượng đánh giá (pecifications) bao gồm:

- Thiết kế thông số kỹ thuật (design specifications) và mã(Code)

- Kế hoạch kiểm thử (test plans) và kỹ thuật kiểm thử( test specifications)

- Các trường hợp kiểm thử( test cases)

- Các kịch bản kiểm thử ( test scripts)

- Hướng dẫn sử dụng( user guides) và các trang web (web pages)

 Lợi ích của đánh giá (review):

- Sớm phát hiện lỗi và điều chỉnh và cải thiện năng suất phát triển

- Giảm khoảng thời gian phát triển và giảm chi phí và thời gian kiểm thử

 Loại khiếm khuyết trong đánh giá (reviews) bao gồm:

- Độ lệch tiêu chuẩn (deviations from standards)

- Khiếm khuyết trong yêu cầu ( requirement defects) và khiếm khuyết trong thiết kế ( design defects)

- Không đủ khả năng bảo trì code (insufficient maintainability) và chi tiết

kỹ thuật giao diện không chính xác (incorrect interface specifications)

 Đánh giá có thể tìm các thiếu sót mà không có khả năng tìm thấy trong kiểm thử động Ví dụ như thiếu sót trong yêu cầu kỹ thuật

24

 Sự giống nhau và khác nhau của kiểm thử động và kiểm thử tĩnh

a Quy trình đánh giá - Review Process

- Tiêu chí đầu vào - Entry criteria: Tập hợp các điều kiện chung và cụ thể Mục

đích của tiêu chí đầu vào là ngăn cản một nhiệm vụ từ khi bắt đầu sẽ gây ra lãng phí nỗ lực, để loại bỏ các tiêu chí đầu vào lỗi

- Đánh giá chính thức - formal review : Một đặc tính đánh giá bằng tài liệu và

yêu cầu kỹ thuật

- Đánh giá không chính thức - informal review: Một đánh giá không dựa trên quy

- Người điều hành - moderator: Các trưởng nhóm (leader) và người chịu trách

nhiệm chính cho việc kiểm tra(inspection) hoặc tiến trình đánh giá khác

- Đánh giá ngang hàng - peer review: Một đánh giá của một sản phẩm phần

mềm giữa các đồng nghiệp của nhà sản xuất ra sản phẩm với mục đích xác định các lỗi và cải tiến

- Người đánh giá - reviewer: Những người tham gia vào việc đánh giá và mô tả

sự bất thường trong sản phẩm hoặc dự án được đánh giá Người đánh giá có thể được chọn để đưa ra các quan điểm khác nhau và vai trò trong quá trình review

- Người ghi chép: Người ghi lại từng khiếm khuyết được đưa ra và bất kỳ đề xuất

cải tiến quy trình trong cuộc họp review

- Đánh giá kỹ thuật - technical review: Một hoạt động thảo luận nhóm mà tập trung

vào việc đạt được sự đồng thuận về các phương pháp kỹ thuật được thực hiện

- Walkthrough : Nội dung của tài liệu được trình bày từng bước một bởi tác giả

của tài liệu để thu thập thông tin và thiết lập hiểu biết chung

b.Các hoạt động của một đánh giá chính thức

Một đánh giá chính thức điển hình có các hoạt động chính sau đây :

1) Kế hoạch – Planning

o Xác định tiêu chí đánh giá, lựa chọn nhân sự

25

o Phân bổ vai trò và xác định tiêu chí đầu vào và tiêu chí kết thúc cho nhiều loại đánh giá chính thức (ví dụ : inspections)

2) Khởi động - Kick-off

o Phân phối các tài liệu

o Giải thích mục tiêu, quy trình ,các tài liệu cho người tham gia

3) Chuẩn bị cá nhân- Individual Preparation

o Chuẩn bị cho cuộc họp đánh giá bằng cách xem xét các tài liệu

o Ghi nhận các lỗi tiềm năng, các câu hỏi và các bình luận

4) Kiểm tra/ đánh giá/ ghi kết quả ( trong cuộc họp đánh giá)

o Thảo luận hoặc ghi lại kết quả trong tài liệu được lập và ghi nhận các lỗi, kiến nghị liên quan đến việc xử lý các lỗi, đưa ra quyết định về các lỗi

o Kiểm tra/ đánh giá và ghi lại các vấn đề trong cuộc họp hoặc theo dõi bất kỳ nhóm thông tin liên lạc điện tử

5) Làm việc lại – Rework

o Sửa các lỗi tìm thấy ( thường được thực hiện bởi tác giả)

o Ghi lại trang thái đã cập nhật của lỗi

6) Bước thực hiện tiếp theo - Follow-up

o Kiểm tra lại các lỗi đã được giải quyết

o Thu thập các số liệu và kiểm tra tiêu chí kết thúc

c Vai trò và trách nhiệm - Roles and Responsibilities

Một đánh giá điển hình sẽ bao gồm các vai trò sau:

 Quản lý:

- Quyết định về việc thực hiện các đánh giá

- Phân bổ thời gian trong dự án và xác định các mục tiêu đánh giá đã được đáp ứng hoặc chưa được đáp ứng

 Người điều hành:

- Người lãnh đạo việc đánh giá các tài liệu hoặc thiết lập các tài liệu, bao gồm kế hoạch đánh giá, điều hành cuộc họp, bước thực hiện tiếp theo sau cuộc họp

- Dàn xếp giữa các quan điểm khác nhau để đánh giá thành công

 Người ghi chép:

- Ghi chép tài liệu về tất cả các vấn đề và các quan điểm mở được xác định trong cuộc họp đánh giá

d Các loại đánh giá - Types of Reviews

Một sản phẩm phần mềm hoặc sản phẩm công việc liên quan có thể là đối tượng của nhiều hoặc một đánh giá Nếu nhiều hơn một loại đánh giá được sử dụng, thứ tự có thể thay đổi

Ví dụ: Đánh giá không chính thức ( informal review) có thể được thực hiện trước đánh giá kỹ thuật(technical review) Hoặc một kiểm tra (inspection ) có thể được thực hiện trên yêu cầu đặc điểm kỹ thuật trước một walkthough với khách hàng

Các đặc điểm, lựa chọn và mục đích chính của các loại đánh giá là:

 Đánh giá không chính thức (Informal Review):

 Walkthrough:

- Quy trình đánh giá chính thức, cuộc họp bởi tác giả

- Có thể lấy mẫu(form) của các kịch bản, việc vận hành thử, nhóm tham gia

- Phiên họp mở-kết thúc ( Open-ended sessions):

 Tùy chọn trước cuộc họp sự chuẩn bị của người đánh giá

27

 Tùy chọn chuẩn bị báo cáo đánh giá bao gồm danh sách của các phát hiện

 Tùy chọn người ghi chép( người không phải là tác giả)

 Mục đích chính : Tìm hiểu; Đạt được sự hiểu biết; Tìm các lỗi

 Đánh giá kỹ thuật:

- Quy trình đánh giá chính thức, lập tài liệu, xác định quá trình phát hiện những sai sót bao gồm người điều hành, các đồng nghiệp, các chuyên gia kỹ thuật và ý tưởng được dẫn dắt bởi người điều hành( không phải tác giả)

- Tùy chọn sử dụng các danh sách kiểm tra (checklists)

- Chuẩn bị báo cáo đánh giá bao gồm danh sách các phát hiện, các quyết định xem sản phẩm phần mềm có đáp ứng được các yêu cầu, kiến nghị liên quan đến các phát hiện

- Mục đích chính:

 Thảo luận; Đưa ra các quyết định

 Đánh giá các lựa chọn thay thế

 Tìm các lỗi; Giải quyết các vấn đề kỹ thuật

 Kiểm tra sự phù hợp với các thông số kỹ thuật, kế hoạch, quy định và tiêu chuẩn

 Inspection:

- Quá trình đánh giá chính thức

- Được dẫn dắt bởi người điều hành( không phải tác giả)

- Tiến hành như một đánh giá ngang hàng ( đánh giá giữa các đồng nghiệp)

- Xác định các vai trò và thu thập các số liệu

- Quá trình đánh giá chính thức dựa trên các nguyên tắc và danh sách kiểm tra

- Quy định tiêu chí đầu vào và tiêu chí kết thúc

- Chuẩn bị cuộc họp và kiểm tra báo cáo bao gồm danh sách các phát hiện

- Quá trình các bước tiếp theo ( với việc tùy chọn tiến trình cải tiến các thành phần)

- Tùy chọn người đọc với mục đích chính là phát hiện các lỗi

28

Tóm lại, kỹ thuật phân tích tĩnh có các yếu tố thành công và mục tiêu cho việc đánh giá trong quá trình kiểm thử phần mềm dưới đây:

Các yếu tố thành công cho đánh giá bao gồm:

- Người kiểm thử là người đánh giá có giá trị đóng góp vào việc đánh giá và cũng tìm hiểu về sản phẩm để họ chuẩn bị cho các kiểm thử sớm

- Các khiếm khuyết tìm thấy được tiếp nhận và bày tỏ quan điểm

- Đánh giá được tiến hành trong không khí tin tưởng, kết quả sẽ không được

sử dụng cho việc đánh giá những người tham gia

- Danh sách kiểm tra(checklist) hoặc các vai trò được sử dụng phù hợp để tăng hiệu quả của việc xác định các khiếm khuyết

- Đào tạo được đưa ra trong kỹ thuật đánh giá, đặc biệt là các kỹ thuật chính thức như là inspection

- Hỗ trợ quản lý là một quá trình đánh giá tốt

- Tầm quan trọng trong việc học tập và cải tiến quá trình

Mục tiêu của phân tích tĩnh:

 Là tìm ra các khiếm khuyết trong mã nguồn (source code) phần mềm và trong mô hình phần mềm Phân tích tĩnh được thực hiện mà không cần chạy phần mềm, được kiểm tra bằng công cụ Công cụ phân tích tĩnh phân tích mã chương trình (ví dụ : luồng điều khiển và luồng dữ liệu)

 Lợi ích của phân tích tĩnh:

- Phát hiện sớm các lỗi trước khi thực hiện kiểm thử

- Cảnh báo sớm về những khía cạnh đáng ngờ của code hoặc thiết kế bằng cách tính toán các số liệu

- Xác định các lỗi không dễ dàng tìm được trong kiểm thử động

- Xác định phần phụ thuộc và không nhất quán trong mô hình phần mềm

- Cải thiện khả năng bảo trì của code và thiết kế

- Ngăn ngừa các lỗi, cải thiện chất lượng

 Các khiếm khuyết điển hình được phát hiện bằng công cụ phân tích tĩnh:

- Tham chiếu một biến với một giá trị không xác định

- Giao diện không đồng nhất giữa các modules và các thành phần

 Phân tích tĩnh bằng công cụ khi nào và do ai thực hiện:

- Sử dụng bởi các nhà phát triển trước và trong kiểm thử thành phần và kiểm thử tích hợp

- Khi kiểm tra trong code bằng công cụ quản lý cấu hình và thực hiện bởi người phát triển

- Trong mô hình phần mềm thực hiện bởi người thiết kế

 Phân tích tĩnh bằng công cụ có thể tạo ra một số lượng lớn các tin nhắn cảnh báo, cần quản lý tốt để sử dụng công cụ một cách hiệu quả nhất

Tóm lại, ở chương 1 là một tổng thể về kiểm thử phần mềm, chính vì việc kiểm thử này nhằm đánh giá chất lượng hoặc tính chấp nhận được của sản phẩm phần mềm đồng thời cũng nhằm phát hiện các lỗi hoặc bất cứ vấn đề gì về sản phẩm Bởi vậy mà chúng ta nên cần kiểm thử vì biết rằng con người luôn có thể mắc sai lầm Điều đó đặc biệt trong lĩnh vực phát triển phần mềm và các hệ thống điều khiển bởi phần mềm

Kể từ khi mô hình hóa bằng máy hữu hạn trạng thái được giới thiệu, nó đã trở thành một công cụ phổ biến cho các hệ thống mô hình hóa phần mềm Hiện nay máy hữu hạn trạng thái là một chuẩn trong ngành công nghiệp về việc đặc tả hành vi mô hình hóa hệ thống phần mềm Vì vậy, nó có thể thực hiện được yêu cầu cho việc thiết

kế trong qui trình kiểm thử Kiểm thử dựa trên mô hình máy hữu hạn trạng thái là sự đặc tả hình thức kiểm thử được thực hiện làm mục đích cho việc sử dụng các mô hình ngữ nghĩa như: máy trạng thái hữu hạn, biểu đồ chuyển trạng thái Các mô hình này biểu diễn các đặc tả và được sử dụng làm mục đích để chứng minh hành vi của hệ thống hoặc các đối tượng trong hệ thống phần mềm Trên thực tế, có rất nhiều hệ thống được đặc tả như: một máy trạng thái hữu hạn, hệ thống nhúng và hệ thống điều khiển Điều đó đã thúc đẩy việc nghiên cứu các phương pháp tiếp cận để kiểm thử phần mềm dựa trên mô hình máy trạng thái hữu hạn để khám phá các khía cạnh hành

vi của hệ thống Vậy tại sao phải mô hình hóa? Để trả lời câu hỏi này, dưới đây tôi xin giới thiệu về mô hình và mô hình hóa bằng máy hữu hạn trạng thái FSM cho việc kiểm thử của hệ thống máy rút tiền ATM Việc kiểm thử dựa trên mô hình hóa bằng máy hữu hạn trạng thái FSM nhằm tăng tính hiệu quả và độ chính xác của các hoạt động kiểm thử trong hệ thống phần mềm

2.1 Giới thiệu về mô hình hóa

Hiện nay, mô hình hóa hướng đối tượng là phương pháp xây dựng mô hình dựa trên tư duy hướng đối tượng Mỗi thế giới thực đều được tạo thành bởi các đối tượng

và mối quan hệ giữa chúng Mô hình hóa hướng đối tượng giúp ta hiểu tốt hơn các yêu cầu của bài toán đặt ra, bởi cách thức tiến hành gần với tư duy con người hơn là mô

31

hình hóa hướng dữ liệu Từ đó, ta có thể đưa ra giải pháp thiết kế và thực thi phù hợp hơn cho bài toán Trong bài toán mô hình hóa máy rút tiền ATM, là một đặc tả hình thức mô hình hóa có thể biểu diễn một cách đầy đủ các khía cạnh cần quan tâm của hệ thống thực Chính vì vậy mô hình hóa, là để biểu diễn thế giới thực, song bản thân mỗi

mô hình cũng cần một ngôn ngữ để mô tả Ngôn ngữ sử dụng để mô tả một mô hình được gọi là ngôn ngữ mô hình hóa Một ngôn ngữ mô hình hóa chứa đựng các yếu tố

về cú pháp và ngữ nghĩa của một mô hình Hầu hết các ngôn ngữ mô hình hóa đều dựa trên các yếu tố thông dụng như văn bản, đồ họa, công thức toán học,…Trong mô hình hóa ta sử dụng ngôn ngữ nào? Trước hết, một ngôn ngữ mô hình hóa tốt phải đáp ứng được các yêu cầu như: Đơn giản, trực quan, dễ hiểu, dễ xây dựng; khả năng biểu diễn mạnh; khả năng thực thi cao; sự linh hoạt, nhất quán cho suốt qui trình phát triển công nghệ phần mềm

Mô hình hóa hệ thống đã trở thành một phương tiện để biểu diễn một hệ thống

sử dụng một số kí hiệu đồ họa trong máy hữu hạn trạng thái FSM Đứng trước sự gia tăng mức độ phức tạp của một hệ thống, việc trực quan hóa của mô hình và mô hình hóa ngày càng hiệu quả trong cách tiếp cận xem xét về một hệ thống Giúp cho người phân tích hiểu được chức năng của một hệ thống được sử dụng để giao tiếp với khách hàng Phương pháp mô hình hóa hệ thống được xem như là một tập hợp các khái niệm, quy tắc và thứ tự dùng để biểu diễn một hệ thống khi thực hiện công việc kiểm thử cho

hệ thống đó

Mô hình (Model) là một dạng thức trừu tượng của một hệ thống, được hình thành để hiểu hệ thống trước khi xây dựng hoặc thay đổi hệ thống đó Mô hình là một dạng trình bày đơn giản hóa của thế giới thực6 Bởi vì, hệ thống thực tế thì rất phức tạp và rộng lớn, có những mức độ phức tạp không cần thiết phải được mô tả và giải quyết Mô hình cung cấp một phương tiện để quan niệm hóa vấn đề để giúp chúng ta

có thể trao đổi các ý tưởng trong một hình thức cụ thể, không mơ hồ Tuy nhiên, một

mô hình cũng có những đặc điểm riêng như: Diễn đạt một mức độ trừu tượng hóa (mức quan niệm, mức tổ chức, mức vật lý,…); Tuân theo một quan điểm; Có một hình thức biểu diễn văn bản, đồ họa, sơ đồ, biểu đồ trạng thái…Cho nên các kỹ thuật mô hình hóa được sử dụng trong phân tích thiết kế để biểu diễn các ngôn ngữ đồ họa,

ngôn ngữ văn phạm,…các ngôn ngữ đó gồm một tập hợp các ký hiệu Mô hình có hai loại: Mô hình tĩnh ( Static model) được xem như là hình ảnh về thông số hệ thống tại một thời điểm xác định Các mô hình tĩnh được dùng để trình bày cấu trúc hoặc những khía cạnh tĩnh của hệ thống; Mô hình động (dynamic model) được xem như là một tập hợp các hành vi, thủ tục kết hợp với nhau để mô tả hành vi của hệ thống và dùng để biểu diễn sự tương tác của đối tượng để thực hiện công việc trong hệ thống

32

Mô hình hóa (Modeling) là thay thế các đối tượng gốc bằng một mô hình nhằm thu nhận các thông tin quan trọng về đối tượng bằng cách tiến hành các thực nghiệm trên mô hình Việc xây dựng mô hình và nghiên cứu mô hình với mục đích nhằm làm sáng tỏ vấn đề mà chúng ta có thể đưa ra được các lỗi hoặc các thiếu sót của hệ thống

từ việc tiếp cận trực quan đồ họa hơn là các dạng trình bày khác như văn bản, đoạn mã,… Hơn nữa, việc mô hình hóa giúp chúng ta dễ dàng hiểu được hệ thống Mô phỏng được hình ảnh tương tự của hệ thống chính là sự trình bày của mô hình có thể đưa ra được hình ảnh giả lập như hoạt động thực sự của hệ thống thực tế, điều này giúp cho người tiếp cận cảm thấy thuận tiện khi làm việc với mô hình Để gia tăng khả năng duy trì của hệ thống, nhằm thay đổi các vị trí được xác định trực quan trên mô hình sẽ giúp giảm đi được các lỗi của hệ thống Chính vì thế mô hình hóa là phương pháp nghiên cứu thực nghiệm trên mô hình của một hiện tượng (quá trình, sự vật…) thay vì nghiên cứu trực tiếp hiện tượng ấy ở dạng tự nhiên Do đó phải xây dựng mô hình sao cho những kết quả thí nghiệm trên mô hình có thể áp dụng tính toán trên thực tế

Mô hình trạng thái hữu hạn (FSM) dùng để biểu diễn trạng thái của một đối tượng và thứ tự chuyển tiếp giữa các trạng thái, chuyển đổi từ trạng thái này sang trạng thái khác Các sự kiện gây nên sự chuyển đổi trạng thái khác

2.2 Mô hình định hướng trạng thái

Hệ thống phần mềm có thể được chia thành hai nhóm cụ thể: trạng thái hệ thống không định hướng và trạng thái hệ thống có định hướng Những hành động của một hệ thống trạng thái không định hướng sẽ không phụ thuộc vào đầu vào trước đó của hệ thống Một trình biên dịch là một ví dụ về một hệ thống trạng thái không định hướng vì kết quả của việc biên soạn một chương trình không phụ thuộc vào các chương trình đã được biên soạn trước đây Các hệ phản vệ hoặc hệ thống trạng thái có định hướng thì với dữ liệu đầu vào hiện tại phụ thuộc vào các yếu tố đầu vào trong quá khứ của hệ thống trong một hệ thống

Một trạng thái hệ thống có định hướng sẽ ghi nhớ trình tự của các yếu tố đầu vào nó đã nhận được, cho đến hiện tại trong các hình thức của một trạng thái Một hệ thống rút tiền tự động ATM là một ví dụ đặc trưng nhất nói về một hệ thống trạng thái theo định hướng Các giải thích các chữ số trên bàn phím phụ thuộc vào các yếu tố đầu vào trước đó, chẳng hạn như: người sử dụng chèn thẻ ATM vào hệ thống, với các chuỗi kiểm tra về thẻ ATM, và các thao tác được thực hiện bởi người sử dụng,…Do đó một hệ thống trạng thái có định hướng có thể được xem như là một phần điều khiển và một phần dữ liệu Các phần điều khiển quy định cụ thể trình tự của các tương tác môi trường với nó, và các phần dữ liệu xác định các dữ liệu được xử lý và lưu lại Tùy thuộc vào đặc điểm của hệ thống, một hệ thống có thể chủ yếu là định hướng dữ liệu,

33

hoặc một hệ thống có thể chủ yếu là định hướng điều khiển hoặc có một kết hợp cân bằng của cả hai phần dữ liệu và phần điều khiển, như trong hình 2.1

Hình 2.1 Hình ảnh của hệ thống phần mềm 1

Trong một hệ thống dữ liệu chiếm ưu thế, hệ thống dành phần lớn thời gian xử

lý dữ liệu đó và yêu cầu người sử dụng, các trình tự tương tác với người sử dụng rất đơn giản Vì vậy, phần điều khiển là đơn giản hơn so với việc xử lý dữ liệu, đó là phức tạp hơn Do vậy, các phần điều khiển của một hệ thống phần mềm thường có thể được

mô hình hóa như một trạng thái hữu hạn (FSM), có nghĩa là sự tương tác giữa hệ thống

và người dùng hoặc môi trường

Bởi vậy, một mô hình FSM hành vi bên ngoài của hệ thống mô tả trình tự của đầu vào và đầu ra mong đợi từ hệ thống Một mô hình như là một nguồn chính cho các trường hợp kiểm thử Trong phần này, tôi xin giải thích làm thế nào để lấy được các trường hợp kiểm thử từ một mô hình FSM

1 2008 Software Testing and Quality Assurance Theory and Practice - KSHIRASAGAR NAIK - PRIYADARSHI TRIPATHY

(Chapter 10: Test Generation from FSM Models – Page 266)

Máy hữu hạn trạng thái (FSM) là một mô hình hành vi sử dụng các trạng thái và chuyển trạng thái Nó là một mô hình được sử dụng rộng rãi trong lĩnh vực công nghệ phần mềm và đặc biệt phổ biến trong thiết kế hệ thống Máy trạng thái hữu hạn tạo ra output trên chuyển trạng thái và input nhận được Máy hữu hạn trạng thái là một bộ

M = <S, I, O, s0, δ, λ> Trong đó:

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

 I: là tập thông tin đầu vào,

 O: là tập thông tin đầu ra,

 s0: là trạng thái ban đầu,

 δ: S x I → S là hàm chuyển trạng thái,

 λ: S x I → O là hàm thông tin đầu ra

2 2008 Software Testing and Quality Assurance Theory and Practice - KSHIRASAGAR NAIK - PRIYADARSHI TRIPATHY

(Chapter 10: Test Generation from FSM Models – Page 268)

35

Tuy nhiên, kiểm thử phần mềm có rất nhiều mô hình được sử dụng như UML (Unified Modeling Language), văn phạm, bảng quyết định, máy trạng thái hữu hạn FSM (Finte State Machine)… được sử dụng rộng rãi để mô hình hóa các đặc tả hành

vi của hệ thống Những mô hình này gồm các trạng thái, các chuyển tiếp, các hành động (action) bao gồm: hành động vào (Entry action) được thực hiện khi vào trạng thái tương ứng; hành động thoát (Exit action) được thực hiện khi rời trạng thái tương ứng; hành động nhập (Input action) được thực hiện theo dữ liệu nhập và trạng thái tương ứng; hành động chuyển trạng thái (Transition action) được thực hiện khi chuyển trạng thái theo cung tương ứng Nó được dựa trên các khái niệm trạng thái (States) và sự mô hình hóa máy trạng thái (FSM), cho phép các kiểm thử viên xem sự phát triển phần mềm trong một số điều kiện trạng thái của nó, mà quá trình chuyển đổi giữa các trạng thái, điều kiện nhập đầu vào và sự kiện kích hoạt thay đổi trạng thái

Hình 2.3 Mô hình chuyển trạng thái của FSM

Việc xem xét này, làm cho các Tester có thêm cơ hội phát triển các test case để phát hiện ra các lỗi mà không phát hiện được bằng điều kiện input, output bình thường cũng như việc xem đồ thị nguyên nhân – kết quả được lập ra từ lớp tương đương và vẽ

đồ thị nguyên nhân – kết quả

Về ứng dụng, máy trạng thái hữu hạn đóng vai trò quan trọng trong nhiều lĩnh vực như: công nghệ điện tử, ngôn ngữ học, khoa học máy tính, triết học, sinh học, toán học, logic học…Trong kiểm thử phần mềm, máy trạng thái hữu hạn được sử dụng rộng rãi trong việc mô hình hóa hoạt động của hệ thống phần mềm, thiết kế hệ thống phần cứng, công nghệ mạng, xử lý trong ngôn ngữ…Trạng thái là cấu hình bên trong của một hệ thống hoặc chức năng của thành phần (component) Nó được định nghĩa dựa trên điều kiện các giá trị giả định tại một thời điểm riêng biệt cụ thể cho các biến đặc trưng cho hệ thống FSM là một thiết bị để mô hình hóa các hành vi (mô hình trừu tượng hóa toán học đôi khi dùng để thiết kế ra các kỹ thuật logic hoặc các chương trình máy tính) gồm một số trạng thái có hạn, quá trình chuyển đổi qua lại giữa các trạng thái và các hành động tương tự như một đồ thị luồng xử lý (flow graph) Trong

đó, có thể kiểm tra các bước chạy logic khi các điều kiện nhất định được đáp ứng Nó

Sự kiện/ hành động

36

có bộ nhớ trong, một chức năng nhập đầu vào (input) có thể đọc được những ký hiệu liên tục trong một thời điểm mà không cần phải quay lại và một chức năng output có thể là một hình thức giao diện người dùng khi mô hình hoạt động

Cách hoạt động của mô hình máy trạng thái hữu hạn FSM được bắt đầu từ một trạng thái khởi tạo, đến các trạng thái chuyển tiếp sang các trạng thái khác nhau phụ thuộc vào điều kiện nhập và có thể kết thúc ở bất kỳ trạng thái nào hợp lệ Tuy nhiên chỉ có một tập các trạng thái được đánh dấu là luồng xử lý thành công Ví dụ dưới đây

là một mô hình nhận dạng mã PIN đơn giản của hệ thống ATM:

Hình 2.4 Mô hình nhận dạng mã PIN của ATM 3

FSM là những mô hình bao gồm:

o Những yếu tố tĩnh: gồm có trạng thái (state) và sự chuyển tiếp trạng thái (state

transition) Những sự chuyển tiếp trạng thái thường được gọi là các sự chuyển tiếp Số lượng của những trạng thái là hữu hạn Sự chuyển tiếp trực tiếp từ trạng thái A sang trạng thái B chỉ có thể theo 1 đường link duy nhất là A-B Số lượng của những chuyển tiếp là giới hạn

o Những yếu tố động: gồm đầu vào input được cung cấp cho FSM và đầu ra

output được lấy ra từ FSM ở việc thực hiện trong hệ thống Nói chung, cả hai số lượng đầu vào và đầu ra đều là hữu hạn Nếu trường hợp mà có số lượng đầu vào và đầu ra

có thể chiếm một số lượng lớn hoặc một số lượng vô hạn các giá trị, thông thường chúng ta cần phải nhóm chúng vào các phân vùng

3

http://www.softwaretestingclass.com/design-test-cases-using-state-transition-testing-technique/

37

Các mô hình FSM và các yếu tố của hệ thống cần kiểm tra được biểu diễn bằng

đồ thị gồm:

o Mỗi trạng thái được mô tả như là một nút (node) trong đồ thị

o Mỗi sự chuyển tiếp được diễn tả như một đường link được kết nối trực tiếp từ trạng thái này sang trạng thái khác

o Input và output được nối với sự chuyển tiếp và được diễn tả như sự chú thích bởi các sự chuyển tiếp

Thông thường một trạng thái thì tương ứng với vài trạng thái xử lý chương trình của một hệ thống hoặc là một khoảng thời gian cụ thể, hoặc là tương ứng với một trường hợp đặc biệt giữa những hoạt động nào đó của hệ thống

2.4 Một số cách biểu diễn cho FSM

a Biểu diễn kiểu liệt kê

Cho FSM ATM= <S, I, O, s0, δ, λ>

Trạng thái ban đầu s0

Tập trạng thái S = {s1, s2 , sn}

Tập Inputs I = {i1, i2, , in}

Tập chuyển trạng thái {δ(ii,sj) = st} với ∀ iiI và sj, stS

Tập Outputs O = {λ(si,ik) = ot} với siS; ∀ ik I; ∀otO

Ví dụ: FSM ATM = <S, I, O, s0, δ, λ),

Tập các trạng thái S={S0, S1, S2}

Tập Inputs I={<card (pin,b)/prompt for pin>,

<pin(p); [(p!=pin) & attempt<3]/ Display error>,

<withdraw(w)/ b=b-w>,<deposit(d)/ b=b+d>,

<continue transaction/print(b); Display menu>}

Tập Outputs O={<card (pin,b)/ prompt for pin>,

<pin(p);[(p!=pin)&attempt<3]/ Display error>,

<withdraw(w)/ b=b-w>,<deposit(d) / b=b+d>,

<continue transaction/ print(b); Display menu>}

38

Trạng thái ban đầu: s0=S0

Tập chuyển trạng thái: {δ(S0, pin(p); p==pin)=S1,

δ (S1, withdraw(w))=S2, δ (S1,exit)=S0, δ(S1, deposit(d))=S2, δ(S2, continue transaction)=S1 }

Tập Outputs tương ứng với sự chuyển trạng thái:

{ λ(S0, pin(p); p==pin)=Display menu, λ (S1, withdraw(w))=b=b-w,

λ(S1, exit)=Eject card, λ (S1, deposit(d))=b=b+d, λ(S2, continue transaction)=print(b);display menu}

b Biểu diễn bằng đồ thị

Các FSM và các yếu tố của chúng có thể được biểu diễn bằng đồ thị Các yếu tố chính trong đồ thị bao gồm:

o Mỗi trạng thái được mô tả như là một nút (node) trong đồ thị

o Mỗi sự chuyển tiếp được diễn tả như một đường link được kết nối trực tiếp từ trạng thái này sang trạng thái khác được coi là cạnh của đồ thị với nhãn là cặp input/output (ký hiệu „/‟ để phân biệt input và output)

Từ việc mô tả FSM ATM bằng phương pháp liệt kê như ví dụ ở trên, ta có thể biểu diễn FSM ATM bằng đồ thị như hình 2.5 dưới đây:

Hình 2.5 FSM của ATM biểu diễn bằng đồ thị