Kiểm thử chuyển đổi trạng thái (State transition testing) được sử dụng khi một số khía cạnh của hệ thống có thể được mô tả trong cái được gọi là “máy trạng thái hữu hạn”. Điều này đơn giản có nghĩa là hệ thống có thể ở một số trạng thái (hữu hạn) khác nhau và sự chuyển đổi từ trạng thái này sang trạng thái khác được xác định bởi các quy tắc của “máy”. Đây là mô hình mà hệ thống và các bài kiểm thử dựa vào. Bất kỳ hệ thống nào mà bạn nhận được một đầu ra khác cho cùng một đầu vào, tùy thuộc vào những gì đã xảy ra trước đó, là một hệ thống trạng thái hữu hạn. Một hệ thống trạng thái hữu hạn thường được hiển thị dưới dạng sơ đồ trạng thái (state diagram) (xem Hình 4.2).
Ví dụ: nếu bạn yêu cầu rút $100 từ máy ATM của Ngân hàng, bạn có thể sẽ nhận được tiền mặt. Sau đó, bạn lại thực hiện chính xác yêu cầu tương tự nhưng bị từ chối nhận tiền (vì số dư không đủ). Việc từ chối sau này là do trạng thái tài khoản ngân hàng của bạn đã thay đổi từ có đủ tiền để chi trả cho việc rút tiền sang không có đủ tiền. Giao dịch khiến tài khoản của bạn thay đổi trạng thái từ lần rút tiền trước đó. Sơ đồ trạng thái có thể đại diện cho một mô hình từ quan điểm của hệ thống, tài khoản hoặc khách hàng.
Một ví dụ khác là một trình xử lý văn bản. Nếu một tài liệu đang mở, bạn có thể đóng nó. Nếu không có tài liệu nào được mở, thì “Đóng” không khả dụng. Sau khi bạn chọn “Đóng” một lần, bạn không thể chọn lại nó cho cùng một tài liệu trừ khi bạn mở lại tài liệu đó. Do đó, một tài liệu có hai trạng thái: mở và đóng.
Một mô hình chuyển đổi trạng thái có bốn phần cơ bản:
- Trạng thái mà phần mềm có thể sử dụng (mở/đóng hoặc được tài trợ/không đủ tiền)
- Sự chuyển đổi từ trạng thái này sang trạng thái khác (không phải tất cả các chuyển đổi đều được phép)
- Các sự kiện gây ra chuyển đổi (đóng tệp hoặc rút tiền)
- Các hành động phát sinh từ quá trình chuyển đổi (thông báo lỗi hoặc nhận tiền mặt của bạn).
Lưu ý rằng trong bất kỳ trạng thái cụ thể nào, một sự kiện chỉ có thể gây ra một hành động, nhưng cùng một sự kiện (từ một trạng thái khác) có thể gây ra một hành động khác và trạng thái kết thúc khác. Đầu tiên chúng ta sẽ xem xét các trường hợp kiểm thử thực hiện các chuyển đổi trạng thái hợp lệ.
Hình 4.2 cho thấy một ví dụ về việc nhập mã số nhận dạng cá nhân (PIN) vào tài khoản ngân hàng. Các trạng thái được hiển thị dưới dạng các vòng tròn, các chuyển tiếp dưới dạng các đường có mũi tên và các sự kiện dưới dạng văn bản gần các chuyển tiếp. (Chúng ta chưa thể hiện rõ ràng các hành động trên sơ đồ này, nhưng chúng sẽ là một thông báo cho khách hàng nói những điều như “Vui lòng nhập mã PIN của bạn”)
Sơ đồ trạng thái hiển thị bảy trạng thái nhưng chỉ có bốn sự kiện có thể xảy ra (Thẻ được lắp vào, Nhập mã PIN, Mã PIN OK và Mã PIN không ổn). Chúng ta chưa chỉ định tất cả các chuyển đổi có thể có ở đây, cũng sẽ có thời gian chờ từ “chờ mã PIN” và từ ba lần thử sẽ quay lại trạng thái bắt đầu sau khi hết thời gian và có thể sẽ đẩy thẻ ra. Cũng sẽ có sự chuyển đổi từ trạng thái “ăn thẻ” trở lại trạng thái “bắt đầu”. Chúng ta cũng chưa chỉ định tất cả các sự kiện có thể xảy ra, sẽ có tùy chọn “hủy” từ “chờ mã PIN” và từ ba lần thử, cũng sẽ quay lại trạng thái bắt đầu và đẩy thẻ ra. Trạng thái “tài khoản truy cập” sẽ là điểm bắt đầu của một sơ đồ trạng thái khác hiển thị các giao dịch hợp lệ hiện có thể được thực hiện trên tài khoản.
Tuy nhiên, biểu đồ trạng thái này (mặc dù không đầy đủ) vẫn cung cấp cho chúng ta thông tin để thiết kế một số bài kiểm thử hữu ích và giải thích kỹ thuật chuyển đổi trạng thái. Trong việc tạo ra các trường hợp kiểm thử, chúng ta có thể bắt đầu với một kịch bản điển hình. Trường hợp kiểm thử hợp lý đầu tiên ở đây sẽ là tình huống thông thường, trong đó mã PIN chính xác được nhập lần đầu tiên. Để kỹ lưỡng hơn, chúng ta có thể muốn đảm bảo rằng mọi trạng thái (tức là ít nhất một bài kiểm thử đi qua từng trạng thái) hoặc có thể muốn mọi quá trình chuyển đổi. Bài kiểm thử thứ hai (để truy cập mọi trạng thái) sẽ là nhập mã PIN không chính xác mỗi lần để hệ thống nuốt thẻ. Chúng ta vẫn chưa kiểm thử mọi chuyển đổi. Để làm điều đó, chúng ta muốn có một bài kiểm thử trong đó mã PIN không chính xác ở lần đầu tiên nhưng OK ở lần thứ hai và một bài kiểm thử trong đó mã PIN chính xác ở lần thử thứ ba. Những bài kiểm thử này có lẽ ít quan trọng hơn hai bài kiểm thử đầu tiên.
Lưu ý rằng một quá trình chuyển đổi không cần phải thay đổi sang một trạng thái khác (mặc dù tất cả các quá trình chuyển đổi được hiển thị ở trên đều chuyển sang một trạng thái khác). Vì vậy, có thể có một quá trình chuyển đổi từ “tài khoản truy cập”, vốn chỉ quay trở lại “tài khoản truy cập” cho một hành động chẳng hạn như “yêu cầu số dư”.
Các điều kiện kiểm thử có thể được suy ra từ biểu đồ trạng thái theo nhiều cách khác nhau. Mỗi trạng thái có thể được ghi chú như một điều kiện kiểm thử, cũng như mỗi lần chuyển đổi. Trong bản tóm lược (Syllabus), chúng ta cần xác định được mức độ bao phủ của một tập hợp các bài kiểm thử dưới dạng chuyển tiếp.
Ngoài mức độ mong đợi trong Syllabus, ta cũng có thể xem xét các cặp chuyển vị và bộ ba…. Phạm vi bao phủ của tất cả các chuyển đổi riêng lẻ còn được gọi là phạm vi bao phủ 0-chuyển đổi (0-switch), phạm vi bao phủ của các cặp chuyển tiếp là bao phủ l-switch, phạm vi của bộ ba chuyển tiếp là bao phủ 2-switch…. Xuất phát các trường hợp kiểm thử từ mô hình chuyển đổi trạng thái là một cách tiếp cận hộp đen . Việc đo lường mức độ đã kiểm thử (được bao phủ) đang tiến gần đến góc độ hộp trắng. Tuy nhiên, trạng thái kiểm thử chuyển đổi được coi là một kỹ thuật hộp đen.
Một trong những ưu điểm của kỹ thuật chuyển đổi trạng thái là mô hình có thể chi tiết hoặc trừu tượng như bạn cần. Khi một phần của hệ thống quan trọng hơn (nghĩa là cần kiểm thử nhiều hơn) thì độ chi tiết cao hơn có thể được mô hình hóa. Khi hệ thống ít quan trọng hơn (yêu cầu ít bài kiểm thử hơn), mô hình có thể sử dụng một trạng thái duy nhất để biểu thị những gì sẽ là một loạt các trạng thái khác nhau.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
