QUAN
Đặt vấn đề
Trong quá trình phát triển phần mềm, kiểm thử đóng vai trò quan trọng trong việc đảm bảo chất lượng sản phẩm, ảnh hưởng trực tiếp đến sự tồn tại của hệ thống Khi phần mềm ngày càng phức tạp và lớn, thời gian và công sức cho kiểm thử cũng gia tăng Nhiều nghiên cứu chỉ ra rằng hơn 50% chi phí phát triển phần mềm được dành cho hoạt động kiểm thử.
Trong nghiên cứu kiểm thử phần mềm, việc sinh các ca kiểm thử là một trong những bài toán quan trọng nhất Thiết kế và thực hiện các ca kiểm thử thường tốn nhiều thời gian và công sức, đặc biệt khi thực hiện bằng phương pháp thủ công, dễ dẫn đến sai sót Do đó, nghiên cứu các kỹ thuật tự động hóa trong việc sinh kịch bản kiểm thử trở nên cần thiết và cấp bách.
Có hai hướng tiếp cận chính trong việc sinh ca kiểm thử tự động: một là thiết kế ca kiểm thử từ yêu cầu và đặc tả phần mềm, hai là sinh ca kiểm thử từ mã nguồn Thiết kế từ mã nguồn thường phức tạp và khó tự động hóa Việc sử dụng ký hiệu thiết kế làm cơ sở cho kiểm tra đầu ra có thể giảm đáng kể chi phí kiểm thử Quá trình sinh bài kiểm tra từ thiết kế giúp phát hiện vấn đề trong thiết kế sớm, từ đó tiết kiệm thời gian và nguồn lực Khi kiểm thử viên phát hiện những điểm không nhất quán trong đặc tả và thiết kế, có thể cải thiện chúng trước khi viết mã Dữ liệu kiểm tra độc lập với các cài đặt, giúp tự động hóa quá trình sinh ca kiểm thử rút ngắn thời gian và công sức Hầu hết yêu cầu và thiết kế phần mềm được tài liệu hóa bằng mô hình, có thể sử dụng cho quá trình sinh ca kiểm thử tự động.
Phát triển phần mềm hướng mô hình là một phương pháp hiệu quả trong lĩnh vực phát triển phần mềm, giúp trực quan hóa các miền ứng dụng và giải pháp Việc sử dụng mô hình thiết kế trong kiểm thử phần mềm, đặc biệt là cho các chương trình hướng đối tượng, mang lại ba lợi ích chính: đầu tiên, các kỹ thuật kiểm thử truyền thống chỉ tập trung vào trạng thái tĩnh của mã nguồn, không đủ để kiểm thử các hành vi động của phần mềm; thứ hai, việc kiểm tra phần mềm hướng đối tượng qua mã nguồn thường phức tạp và tốn thời gian, trong khi mô hình giúp kiểm thử viên hiểu hệ thống tốt hơn; và thứ ba, việc sinh ca kiểm thử dựa vào mô hình có thể được lập kế hoạch từ giai đoạn đầu của vòng đời phát triển phần mềm, cho phép lập trình và kiểm tra diễn ra song song Nhờ vào những lý do này, phương pháp sinh ca kiểm thử dựa vào mô hình trở thành lựa chọn tối ưu trong ngành công nghiệp phần mềm.
UML là công cụ quan trọng trong việc mô hình hóa hướng đối tượng trong công nghệ phần mềm, nhưng ít nghiên cứu áp dụng nó cho kiểm thử Sự gia tăng sử dụng UML trong mô hình hóa phần mềm đã thu hút sự chú ý của các nhà nghiên cứu về khả năng ứng dụng của nó trong kiểm thử Trong luận văn này, tôi sẽ nghiên cứu phương pháp sinh ca kiểm thử tự động từ biểu đồ tuần tự và biểu đồ trạng thái UML.
Tổng quan tình hình nghiên cứu
Cách tiếp cận sử dụng các biểu đồ UML để sinh ca kiểm thử tự động có thể kể đến một số nghiên cứu như sau:
Bertolino và Basanieri đề xuất một phương pháp sinh ca kiểm thử dựa trên biểu đồ UML use case và các biểu đồ tương tác, đặc biệt là biểu đồ thông điệp tuần tự Phương pháp này tập trung vào kiểm thử tích hợp nhằm xác nhận rằng các thành phần hệ thống đã được kiểm thử trước đó tương tác chính xác với nhau Họ áp dụng phương pháp phân hoạch loại và tạo ra các ca kiểm thử thủ công dựa trên luồng thông điệp giữa các thành phần trong biểu đồ tuần tự.
Briand và Labiche mô tả phương pháp kiểm thử hệ thống TOTEM, tập trung vào việc kiểm thử các hệ thống hướng đối tượng bằng UML Hệ thống yêu cầu được chiết xuất từ biểu đồ ca sử dụng, biểu đồ tuần tự và lớp tương ứng, cho thấy sự phụ thuộc tuần tự giữa các ca sử dụng thông qua một biểu đồ hoạt động Dựa trên những phụ thuộc này, họ tạo ra các chuỗi hợp lệ của ca sử dụng để phát sinh các ca kiểm thử Phương pháp này mang tính bán tự động, nhằm bao phủ kịch bản với các điều kiện khởi tạo đã được xác định trước và dự đoán kết quả.
Sharma [7] đã chuyển đổi biểu đồ ca sử dụng thành đồ thị ca sử dụng và biến biểu đồ tuần tự thành đồ thị biểu đồ tuần tự Sau đó, hai đồ thị này được tích hợp thành đồ thị kiểm thử hệ thống, từ đó tiến hành duyệt đồ thị kiểm thử hệ thống để sinh ra các ca kiểm thử.
Nội dung nghiên cứu
Nội dung nghiên cứu của luận văn tập trung vào việc tổng quan về kiểm thử phần mềm và các phương pháp kiểm thử cơ bản Bên cạnh đó, luận văn cũng nghiên cứu về UML, đặc biệt là hai loại biểu đồ quan trọng: biểu đồ tuần tự và biểu đồ trạng thái, được sử dụng để sinh ca kiểm thử.
Luận văn giới thiệu kỹ thuật sinh ca kiểm thử từ biểu đồ trạng thái và biểu đồ tuần tự, bao gồm ví dụ minh họa chi tiết và các thuật toán được áp dụng trong phần trình diễn của chương trình.
Cấu trúc khóa luận
Khóa luận được tổ chức thành bốn chương như sau:
Chương một trình bày tầm quan trọng và ý nghĩa thực tiễn của đề tài “Sinh ca kiểm thử từ các biểu đồ UML”, đặc biệt là từ biểu đồ trạng thái và biểu đồ tuần tự UML Mục tiêu của nghiên cứu này là phát triển các phương pháp hiệu quả để tạo ra các ca kiểm thử, nhằm nâng cao chất lượng phần mềm và đảm bảo tính chính xác trong quá trình kiểm thử.
KIẾN THỨC CHUNG
Kiểm thử phần mềm
2.1.1 Các khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là quá trình khảo sát thực tế sản phẩm trong môi trường triển khai dự kiến, nhằm cung cấp thông tin về chất lượng sản phẩm Hoạt động này đánh giá chất lượng và tính chấp nhận của phần mềm, với mục đích phát hiện lỗi và các vấn đề tiềm ẩn Nói một cách đơn giản, kiểm thử phần mềm là tập hợp các quy trình được thiết kế để đảm bảo mã nguồn hoạt động đúng theo yêu cầu mà nó được lập trình, không thực hiện các hành động không mong muốn.
Trong kiểm thử phần mềm, các thuật ngữ như lỗi, sai, thất bại và sự cố cần được phân biệt rõ ràng Lỗi (Error) là những vấn đề mà lập trình viên gặp phải trong quá trình phát triển phần mềm Sai (Fault) là kết quả của lỗi, có thể chia thành hai loại: sai sót do đưa ra thông tin không chính xác và sai do bỏ sót thông tin cần thiết trong mô tả yêu cầu phần mềm Thất bại (Failure) xảy ra khi một lỗi được thực thi, dẫn đến chức năng phần mềm không hoạt động như mong đợi Cuối cùng, sự cố (Incident) là những kết quả phát sinh từ sai sót, có thể hiển thị hoặc không hiển thị cho người dùng, thể hiện sự tồn tại của thất bại.
Việc kiểm thử phần mềm được thực hiện lần lượt các bước theo quy trình, hình vẽ dưới đây mô mả mô hình chung của quá trình kiểm thử
Hình 2.1: Quy trình kiểm thử phần mềm
Một quy trình kiểm thử phần mềm được bắt đầu từ bước lập kế hoạch kiểm thử
Dựa vào đặc tả phần mềm, thiết kế các ca kiểm thử và tạo dữ liệu kiểm tra từ các ca kiểm thử đã viết Chương trình sẽ được chạy theo kịch bản với dữ liệu kiểm tra, sau đó so sánh kết quả kiểm tra với đầu ra mong muốn Qua từng ca kiểm thử, kết quả sẽ được ghi nhận là pass hoặc fail, và cuối cùng, một báo cáo kết quả kiểm thử sẽ được tổng hợp.
Quá trình kiểm thử phần mềm bao gồm kiểm chứng và thẩm định chất lượng, với kiểm chứng đảm bảo phần mềm xây dựng đúng theo đặc tả ban đầu, còn thẩm định xác nhận phần mềm đáp ứng yêu cầu của khách hàng Thực tế, kiểm chứng được thực hiện trước thẩm định để đảm bảo phần mềm không chỉ tuân thủ thiết kế ban đầu mà còn thỏa mãn nhu cầu của người dùng.
Kiểm thử phần mềm được chia thành hai nhóm kỹ thuật chính: kiểm thử tĩnh và kiểm thử động Kiểm thử tĩnh không yêu cầu chạy chương trình, mà dựa vào việc khảo sát tài liệu phát triển như tài liệu đặc tả nhu cầu, mô hình phần mềm và mã nguồn để phát hiện lỗi Các kỹ thuật phân tích hình thức như kiểm chứng mô hình và chứng minh định lý cũng được áp dụng để xác minh tính đúng đắn của thiết kế và mã nguồn Ngược lại, kiểm thử động thực hiện qua việc chạy chương trình để kiểm tra các tác động của nó, nhằm đảm bảo phần mềm hoạt động đúng và đầy đủ chức năng theo yêu cầu của người dùng.
Trong quy trình phát triển phần mềm, kiểm thử được phân chia thành các mức độ khác nhau, bao gồm kiểm thử mức đơn vị, kiểm thử mức tích hợp, kiểm thử mức hệ thống và kiểm thử mức chấp nhận Mỗi mức độ kiểm thử đóng vai trò quan trọng trong việc đảm bảo chất lượng và hiệu suất của phần mềm.
Kiểm thử mức đơn vị (Unit test):
Kiểm thử đơn vị là mức độ kiểm thử thấp nhất, tập trung vào việc kiểm tra các đơn vị chương trình như phương thức, hàm và lớp một cách độc lập Mục tiêu chính của kiểm thử đơn vị là đảm bảo rằng thông tin được xử lý và xuất ra từ đơn vị là chính xác so với dữ liệu đầu vào và chức năng của nó Để đạt được điều này, tất cả các nhánh bên trong đơn vị cần được kiểm tra nhằm phát hiện lỗi Một nhánh thường là một chuỗi lệnh được thực thi, ví dụ như các lệnh trong điều kiện If và giữa then else Kiểm thử đơn vị thường do chính các lập trình viên thực hiện.
Kiểm thử đơn vị, giống như các mức kiểm thử khác, yêu cầu chuẩn bị kỹ lưỡng cho các ca kiểm thử, bao gồm dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Ưu điểm lớn nhất của kiểm thử đơn vị là khả năng xác định và sửa lỗi một cách dễ dàng nhờ vào phạm vi kiểm thử nhỏ, giúp phát hiện lỗi sớm và giảm chi phí kiểm thử so với việc phát hiện lỗi muộn ở các giai đoạn phát triển sau Tuy nhiên, kiểm thử đơn vị cũng có nhược điểm là tốn thời gian và công sức, đồng thời không phát hiện được các lỗi xảy ra khi các đơn vị được tích hợp với nhau.
Kiểm thử mức tích hợp:
Kiểm thử tích hợp là bước tiếp theo sau kiểm thử đơn vị, trong đó các thành phần của chương trình đã được kiểm tra và cần được kết nối để hình thành hệ thống hoàn chỉnh Mục tiêu của kiểm thử tích hợp là phát hiện các vấn đề có thể phát sinh khi các module hoặc thành phần của hệ thống tương tác với nhau.
Hai mục tiêu chính của kiểm thử tích hợp bao gồm việc phát hiện lỗi giao tiếp giữa các đơn vị và tích hợp các thành phần riêng lẻ thành các hệ thống nhỏ (Subsystem) cũng như hệ thống hoàn chỉnh (System) để chuẩn bị cho kiểm thử ở mức hệ thống.
Có 4 loại kiểm thử trong kiểm thử tích hợp: ã Kiểm thử cấu trỳc: 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 và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các câu lệnh và nhánh bên trong ã Kiểm thử chức năng: Kiểm thử chức năng chỳ trọng đến chức năng của chương trình và 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 thử việc vận hành của hệ thống, đỏnh giỏ hiệu năng của hệ thống ở các mức chịu tải khác nhau Kiểm thử hiệu năng được dùng để kiểm tra các thuộc tính chất lượng của hệ thống như khả năng mở rộng, độ tin cậy, mức độ sử dụng tài nguyên ã Kiểm thử khả năng chịu tải của hệ thống: Là hỡnh thức kiểm thử được sử dụng để xác định tính ổn định của một hệ thống, kiểm thử các giới hạn của hệ thống, đánh giá hiệu năng của hệ thống với một mức tải được định nghĩa trước
Trong kiểm thử tích hợp, có bốn chiến lược chính được áp dụng: Tích hợp từ trên xuống dưới (top-down), tích hợp từ dưới lên trên (bottom-up), tích hợp kẹp (sandwich) và tích hợp Big Bang Mỗi chiến lược này có những ưu điểm và nhược điểm riêng, phù hợp với từng loại dự án và yêu cầu kiểm thử cụ thể.
Kiểm thử mức hệ thống:
Kiểm thử hệ thống là quy trình đánh giá toàn diện tất cả các chức năng của phần mềm, bao gồm sự tương tác giữa các thành phần trong một môi trường mô phỏng thực tế Điều này bao gồm việc kiểm tra hệ điều hành, cơ sở dữ liệu, kết nối mạng và khả năng tương thích với các phần mềm khác.
Kiểm thử hệ thống là quá trình đánh giá cả chức năng của phần mềm và các yêu cầu chất lượng như độ tin cậy, tính tiện lợi, hiệu năng và bảo mật Mục tiêu chính của kiểm thử hệ thống là đảm bảo rằng cài đặt phần mềm đáp ứng đầy đủ các yêu cầu của người dùng Quá trình này đòi hỏi nhiều công sức do sự đa dạng trong các yêu cầu cần được kiểm tra Khác với kiểm thử tích hợp, tập trung vào sự giao tiếp giữa các thành phần, kiểm thử hệ thống chú trọng vào hành vi và lỗi trên toàn bộ hệ thống Để đảm bảo mọi đơn vị và sự tương tác giữa chúng hoạt động chính xác, cần thực hiện kiểm thử đơn vị và kiểm thử tích hợp trước khi tiến hành kiểm tra toàn hệ thống.
Trong kiểm thử hệ thống, có nhiều loại kiểm thử quan trọng để đảm bảo hiệu suất và độ tin cậy của hệ thống Kiểm thử cơ bản xác nhận hệ thống hoạt động đúng cách, trong khi kiểm thử chức năng đánh giá toàn bộ các chức năng mà chương trình cung cấp Kiểm thử khả năng chịu lỗi kiểm tra độ ổn định của hệ thống, và kiểm thử tương thích xác định khả năng hoạt động với sản phẩm bên thứ ba Kiểm thử hiệu năng đo lường khả năng đáp ứng yêu cầu về thông lượng và thời gian xử lý, trong khi kiểm thử khả năng mở rộng xác định giới hạn tài nguyên và số lượng truy cập Kiểm thử khả năng chịu tải đánh giá mức độ tối đa mà hệ thống có thể xử lý, và kiểm thử khả năng ổn định quá tải kiểm tra hoạt động trong thời gian dài dưới áp lực Kiểm thử độ tin cậy đảm bảo hệ thống hoạt động liên tục mà không gặp lỗi, trong khi kiểm thử tài liệu xác nhận tính chính xác của hướng dẫn sử dụng Kiểm thử tính pháp lý đảm bảo hệ thống tuân thủ quy định địa phương, kiểm tra khả năng bảo mật nhằm bảo vệ dữ liệu, và kiểm thử khả năng phục hồi đảm bảo hệ thống có thể khôi phục trạng thái ổn định sau sự cố, đặc biệt quan trọng cho các hệ thống giao dịch như ngân hàng trực tuyến.
Kiểm thử mức chấp nhận
PHƯƠNG PHÁP SINH CA KIỂM THỬ TỪ BIỂU ĐỒ TUẦN TỰ VÀ BIỂU ĐỒ TRẠNG THÁI
Phương pháp thực hiện
Mô hình UML mang lại nhiều thông tin quan trọng cho các bài thử nghiệm, giúp tạo ra các góc nhìn đa dạng về chương trình Chương này tập trung vào kỹ thuật xây dựng các ca kiểm thử từ sự kết hợp giữa biểu đồ tuần tự và biểu đồ trạng thái UML Thông tin được trích xuất từ biểu đồ tuần tự và được bổ sung bởi các trình tự khởi tạo cho các đối tượng tham gia từ biểu đồ trạng thái.
Một trong những thách thức lớn trong kiểm thử chương trình hướng đối tượng là lựa chọn các ca kiểm thử phù hợp Thông thường, việc thực hiện kiểm thử với toàn bộ dữ liệu đầu vào là không khả thi Một phương pháp hiệu quả là tập trung vào các trình tự thông điệp điển hình thông qua biểu đồ tuần tự Mặc dù kiểm thử dựa trên biểu đồ tuần tự mang lại sự trực quan và dễ hiểu, nhưng nó thiếu thông tin về thời gian trong vòng đời chương trình Khi các hành vi theo mô hình xảy ra, không có thông tin về trạng thái và sự chuyển trạng thái của các đối tượng Do đó, việc kết hợp giữa biểu đồ tuần tự và biểu đồ trạng thái của từng đối tượng tham gia giúp chúng tôi xác định các đường kiểm tra ca kiểm thử, bao gồm trình tự thực hiện thông điệp và sự chuyển trạng thái của đối tượng trong mỗi ca kiểm thử.
Phương pháp thực hiện được mô tả như hình vẽ sau:
Hình 3.1: Các bước cơ bản sinh ca kiểm thử
Để chuyển đổi từ biểu đồ tuần tự sang đồ thị tuần tự, chúng ta định nghĩa một ca kiểm thử bao gồm bốn phần tử: {ID, Trạng thái bắt đầu, Tập hợp thông điệp, Trạng thái kết thúc} Trong đó, ID là định danh duy nhất cho từng kịch bản kiểm thử; Trạng thái bắt đầu là trạng thái khởi đầu của đối tượng trong kịch bản; Tập hợp thông điệp là các sự kiện xảy ra trong kịch bản; và Trạng thái kết thúc là trạng thái khi kịch bản hoàn thành.
Trong kịch bản kiểm thử, chỉ có một trạng thái bắt đầu duy nhất, trong khi có thể có một hoặc nhiều trạng thái kết thúc khác nhau tùy thuộc vào các tình huống kiểm thử cụ thể.
Một sự kiện trong Set of Message được biểu diễn bởi ba phần tử: {messageName, fromObject, toObject} Trong đó, messageName là tên của thông điệp, fromObject là đối tượng gửi thông điệp, và toObject là đối tượng nhận thông điệp Khi chuyển từ biểu đồ tuần tự sang đồ thị tuần tự, mỗi đỉnh trong đồ thị tương ứng với một bộ ba trên, và sự kiện này xảy ra sau sự kiện khác, tạo ra hai đỉnh liên tiếp thành một cạnh trong đồ thị.
Bước 2: Kết hợp đồ thị tuần tự và biểu đồ trạng thái ra được đồ thị chung
Trong biểu đồ trạng thái, mỗi sự chuyển trạng thái đều gắn liền với các sự kiện diễn ra Quá trình này bao gồm việc duyệt từng thông điệp trong đồ thị tuần tự, kiểm tra xem thông điệp có dẫn đến sự chuyển trạng thái hay không Nếu có, thông tin về trạng thái mới của đối tượng sẽ được ghi lại Nếu không, quá trình sẽ tiếp tục với thông điệp tiếp theo Cuối cùng, quá trình dừng lại khi tất cả các thông điệp trong biểu đồ đã được duyệt.
Kết quả của bước này là một biểu đồ tuần tự đã được cập nhật với các trạng thái, nếu có sự chuyển đổi trạng thái, sau khi thực hiện các thông điệp Biểu đồ này được gọi là đồ thị chung.
Bước 3: Duyệt đồ thị chung và áp dụng thuật toán tìm kiếm theo chiều sâu để xác định các đường kiểm thử Mỗi đường kiểm thử sẽ bao gồm trình tự các thông điệp trong từng trường hợp kiểm thử và các chuyển trạng thái tương ứng của đối tượng Ca kiểm thử được xác định có dạng {ID, Start State, Set of Message, End State} Phương pháp này giúp sinh ra ca kiểm thử đạt được bộ bao phủ thông điệp và bao phủ trạng thái của đối tượng.
Ví dụ minh họa
Phần này sẽ nêu ví dụ minh họa cho phương pháp được nêu trên Với ví dụ là hệ thống máy rút tiền ATM
Các use case của hệ thống này từ góc nhìn của người sử dụng gồm có: Rút tiền, gửi tiền, chuyển khoản, tra số dư tài khoản
Hình 3.2: Sơ đồ use case của hệ thống máy rút tiền ATM từ góc nhìn người sử dụng
Chọn giao dịch rút tiền của máy ATM làm ví dụ minh họa Các bước rút tiền gồm có:
- Khách hàng đưa thẻ vào máy ATM
- Máy ATM kiểm tra thẻ và đưa yêu cầu thông tin mã pin
- Khách hàng nhập mã pin
- Máy ATM xác thực mã pin, đưa yêu cầu cho khách hàng chọn loại giao dịch
- Khách hàng chọn giao dịch rút tiền
- Hệ thống yêu cầu nhập số tiền cần rút
- Khách hàng nhập số tiền cần rút
- Hệ thống kiểm tra số tiền cần rút và số tiền còn lại trong tài khoản, đưa ra thông báo lỗi hoặc thực hiện giao dịch
Biểu đồ tuần tự tương ứng cho chức năng rút tiền như sau:
Hình 3.3: Biểu đồ tuần tự chức năng rút tiền
Với một giao dịch rút tiền, ta có biểu đồ trạng thái của máy ATM như sau:
Hình 3.4: Biểu đồ trạng thái máy ATM chức năng rút tiền
Bước 1: Chuyển biểu đồ tuần tự thành đồ thị tuần tự Gọi mi là các message trong biểu đồ tuần tự phía trên, i có giá trị từ 1 đến 20
Hình 3.5: Đồ thị tuần tự của chức năng rút tiền
Bước 2: Kết hợp việc duyệt đồ thị tuần tự với biểu đồ trạng thái để xác định các điểm chuyển trạng thái của đối tượng Thông tin về trạng thái của đối tượng sẽ được bổ sung trên đồ thị tuần tự, tạo thành một đồ thị chung.
Hình 3.6: Kết hợp đồ thị tuần tự và biểu đồ trạng thái
Bước 3: Duyệt qua đồ thị chung và áp dụng thuật toán tìm kiếm theo chiều sâu để xác định các ca kiểm thử Mỗi ca kiểm thử sẽ bao gồm thông tin về trình tự thực hiện các message và sự chuyển trạng thái của message trong từng ca kiểm thử.
Duyệt đồ thị hình 3.6 theo thuật toán tìm kiếm theo chiều sâu, xác định được các ca kiểm thử có dạng {ID, Start State, Set of Message, End State }
STT Test case Sự chuyển trạng thái của đối tượng
1 TC1: {1, Idle, {m1 à m2 à m3 à m19 à m20}, Eject Card} Idle à Reading Card à Eject Card
Idleà Reading Card à Requesting Pin à Reading Pin à Eject Card
TC 2: {3, Idle, {m1 à m2 à m3 à m4à m5 à m6 àm7 à m8 à m9 à m10 à m11à m12à m13 à m14 à m15 à m16 à m19 àm20}, Eject Card}
Idle à Reading Card à Requesting Pin à Reading Pin à Withdraw à Checking Account à Eject Card
Idleà Reading Cardà Requesting Pin à Reading Pin à Withdraw à Checking Account à Peporming Withdraw à Eject Card
Bảng 3.1: Kết quả danh sách các ca kiểm thử theo định nghĩa