4. Ý nghĩa lý luận và thực tiễn của đề tài
4.2.2. Kiểm thử bao phủ máy trạng thái
Để kiểm thử xem một hệ thống máy trạng thái hoạt động có đầy đủ và vững chắc không, kiểm thử cần bao phủ được các nhân tố cấu thành hệ thống trong mối quan hệ với các nhân tố khác, đó là: trạng thái, sự kiện, chuyển trạng thái, hành động, tiền định. Do một số nhân tố gắn kết với nhau trong mô hình, nên khi bao phủ được yếu tố này thì đồng thời cũng bao phủ được yếu tố kia. Nhưng không phải các yêu tố đều được gắn với nhau, trong trường hợp này cần phải kiểm thử độc lập. Chẳng hạn có thể đạt được tiêu chuẩn bao phủ tất cả các trạng thái nhưng lại không bao phủ tất cả các chuyển trạng thái (hình 4.6 - đường mờ). Tất nhiên, với các mô hình nhỏ sẽ cho phép bao phủ tất cả trạng thái và tất cả dịch chuyển bằng cách vét cạn. Như chúng ta đã thấy, biểu diễn đồ thị của máy trạng thái là một đồ thị có hướng, nên với các bài toán lớn hơn, ta phải biết lựa chọn từ rất nhiều thuật toán tìm bao phủ cạnh của đồ thị một phương pháp tốt để áp dụng cho bài toán này.
Hình 4.6: Một đường đi bao phủ tất cả các trạng thái
Một câu hỏi tự nhiên đặt ra là: với một hệ thống máy trạng thái đã cho, liệu có thể tìm được đường đi qua tất cả các trạng thái và đi qua tất cả các đường chuyển trạng thái của nó hay không? Câu trả lời cho trường hợp tổng quát là không, những với máy trạng thái hữu hạn lại là có thể.
Những nội dung sau đây được đặt ra cho việc thẩm định một máy trạng thái là đúng đắn và đầy đủ:
− Có ít nhất một trạng thái là khởi đầu với các chuyển dịch trạng thái đi ra − Có ít nhất một trạng thái là kết thúc với các chuyển dịch trạng thái đi vào − Mỗi trạng thái đều có thể đến được từ trạng thái khởi đầu.
− Có ít nhất một trạng thái là kết thúc đối từ một trạng thái bất kỳ khác − Mỗi sự kiện và hành động được xác định phải xuất hiện trong ít nhất một
chuyển dịch trạng thái (hay trạng thái)
− Mỗi trạng thái không phải là khởi đầu hay kết thúc có ít nhất một chuyển trạng thái đến và một chuyển trạng thái đi.
− Tên của trạng thái, hành đông và sự kiện phải rõ ràng, đủ nghĩa trong khung cảnh của ứng dụng.
− Và một số yêu cầu khác không nêu ra ở đây.
Bên cạnh đó, những lỗi sau đây cần được kiểm tra khi kiểm thử: − Thiếu chuyển trạng thái
− Thiếu hành động hay hành động sai
− Trạng thái thừa hay trạng thái dừng không phải là kết thúc
Những nội dung trên đây cho phép thiết kế các ca kiểm thử tốt và hiệu quả.
4.3. Chƣơng trình thử nghiệm
4.3.1. Giới thiệu bài toán
Hệ thống điều khiển thang máy là hệ thống thời gian thực. Hệ thống này gồm các thành phần vật lý tương tác thường xuyên với môi trường của nó. Thang máy trong thực tế có thể có nhiều tầng, tuy nhiên trong phạm vi đề tài chỉ nghiên cứu hệ thống thang máy có 4 tầng. Với hệ thống này vẫn đảm bảo có được các đặc trưng trạng thái tiêu biểu của một thang máy như: Khi thang máy chuyển động đi lên có thể nó sẽ lên tầng trên hoặc bỏ qua để lên tầng trên nữa. Tương tự như vậy, khi thang máy chuyển động xuống có thể nó sẽ đi xuống 1 tầng hoặc bỏ qua tầng giữa để đi xuống tầng tiếp theo. Việc cầu thang lên hay xuống phụ thuộc vào lựa chọn của người đi trong cầu thang. Nếu chọn chính tầng mà thang máy đang dừng thì sẽ không có sự chuyển trạng thái. Tại mỗi tầng sẽ có các sự kiện chọn hoặc không chọn, nếu chọn có thể đi lên hoặc đi xuống. Việc các tầng được chọn quyết định sự di chuyển tiếp tục hay dừng lại tại đó của cầu thang.
Nếu cầu thang đi lên mà nút tầng được chọn là nút lên thì nó sẽ dừng lại cho người vào, nhưng nếu nút chọn hướng xuống thì nó sẽ xóa bỏ lựa chọn và đi qua. Do đó trạng thái của cầu thang khi đến các tầng có thể sẽ bị dừng lại và chuyển trạng thái.
Khi thang máy di chuyển lên, nếu có một số các tầng được chọn thì nó sẽ dừng lại ở tầng được chọn gần nhất, hoặc khi di chuyển xuống nó sẽ dừng lại ở 1 tầng được chọn gần nhất sau đó chuyển đến một trạng thái tiếp theo.
Từ mô tả của bài toán ta có sơ đồ chuyển trạng thái của cầu thang là một đồ thị có hướng như hình 4.7
Hình 4.7 Sơ đồ chuyển trạng thái của cầu thang 4 tầng Qua sơ đồ chuyển trạng thái ta nhận thấy hệ thống gồm có:
- Tổng số trạng thái: 4
- Tổng số các chuyển trạng thái: 12 - Tổng số sự kiện: 4
Với sơ đồ trên, cần lập kế hoạch kiểm thử như thế nào để có thể bao phủ được tất cả các trạng thái, các chuyển trạng thái với số các ca kiểm thử sử dụng là ít nhất. Bên cạnh đó, khi chú ý đến các lỗi có thể gặp, ca kiểm thử cần bao hàm đủ các sự kiện có thể:
Khi thang máy dừng ở một tầng, đi đến các tầng khác có thể: − Một tầng được chọn
1 2 4
− Cả ba tầng được chọn đồng thời
Khi thang máy di chuyển từ một tầng, có thể: − Một nút tầng được nhấn
− Hai nút tầng được nhấn − Ba nút tầng được nhấn
Và có thể cùng chiều hay khác chiều để kiểm tra hành động dừng hay bỏ qua.
4.3.2. Xây dựng các ca kiểm thử cho chương trình
1. Từ sơ đồ trên, để bao phủ hết cả 4 trạng thái ta chọn tiến trình theo sơ đồ sau:
Hình 4.8. Sơ đồ tiến trình cho kiểm thử phủ trạng thái
Ca kiểm thử 1: kế hoạch sử dụng đường đi: 1-2-3-4
Dữ liệu vào Kết quả ra
Trạng thái xuất phát
Sự kiện ( chon tầng)
Trạng thái Chuyển trạng thái
Dự kiến Thực tế Dự kiến Thực tế
1 2, 3, 4 2 12
3 23
4 34
2. Để bao phủ các chuyển trạng thái, ta tìm một chu trình ơle trong đồ thị chuyển trạng thái của hệ thống có đoạn đầu tiên là 1-2-3-4. Điều này có thể thực hiện được, vì các đỉnh có số cung vào bằng số cung ra.
1 2 3 4
Hình 4.9. Sơ đồ tìm chu trình Ơle cho kiểm thử phủ chuyển trạng thái Chu trình tìm được là : 1-2-3-4-2-1-4-3-2-4-1-3-1
Theo giả thiết về sự chuyển trạng thái của cầu thang, quá trình chỉ có thể di chuyển liên tục theo môt hướng lên hay xuống (tiền định). Vì vậy ta cần chia chu trình Ơler thành các đoạn chỉ gồm các cung đi từ đỉnh nhỏ đến lớn hay ngược lại. Nếu mỗi đoạn này thiết kế một ca kiểm thử thì có thể tiến hành kiểm thử liên tục các ca kiểm thử đó vì trạng thái khởi đầu của ca kiểm thử sau chính là trạng thái kết thúc của ca kiểm thử trước. Hơn nữa, việc bắt đầu một ca kiểm thử được thực hiện bằng việc chọn các cầu thang (sự kiện) đi đến theo một hướng – là một một chức năng tiếp nhận sự kiện của chương trình mà ta có thể lựa chọn sự kiện theo dự kiến, nên thực tế các ca kiểm thử này được tiến hành một cách liên tục mà không bị ngắt quãng bởi bất cứ yếu tố gì từ ngoài hệ thống. Vì vậy có thể xem dãy các ca kiểm thử này như một ca kiểm thử. Hơn nữa, đoạn 1-2-3-4 đã được thiết kế, ta chỉ cần thiết kế cho phần còn lại của chu trình. Ca kiểm thử tổng hợp 1: sử dụng chu trình : 1-2-3-4-2-1-4-3-2-4-1-3-1 4 1 2 3 1 1 1 2 2 3 4 5 6 4 8 7
Trạng thái xuất phát
Sự kiện (chon tầng)
Trạng thái đến Chuyển trạng thái Dự kiến Thực tế Dự kiến Thực tế 1 2, 3, 4 2 12 3 23 4 34 4 2, 1 2 42 1 21 1 4 4 14 4 3, 2 3 43 2 32 2 4 4 24 4 1 1 41 1 3 3 13 3 1 1 31
3. Để kiểm thử phủ tầng, ta chọn đại điện là tầng giữa 2 và 3, ở đó tầng được chọn là tầng khởi đầu, nhưng khi đó cầu thang không nằm tại vị trí này. Để bao phủ đầy đủ hai trạng thái chọn của tầng, ta chọn “nút lên” cho tầng 3 và “nút xuống” cho tầng 2. Như vậy trạng thái cầu thang hiện thời sau kiểm thử thứ nhất sẽ được dùng để kiểm thử thứ hai.
Ca kiểm thử 3, 4: kế hoạch kiểm thử hai trạng thái tầng (lên, xuống) Trạng thái
cầu thang
Trạng thái tầng Trạng thái đến Chuyển trạng thái Dự kiến Thực tế Dự kiến Thực tế
1 T3, nút lên 3 13
3 T2, nút xuống 2 32
Trạng thái tầng không được chọn và việc chuyển trạng thái bỏ qua tầng khi nó không được chọn đã được kiểm tra ở ca kiểm thử chung.
Trong ví dụ này, các ca kiểm thử được thiết kế đã bao phủ: − Toàn bộ (4) các trạng thái (100%)
− Toàn bộ (12) các chuyển trạng thái (100%) − Toàn bộ sự kiện (1,2,3,4) (100%)
4.3.3. Xây dựng chương trình
4.3.3.1. Giới thiệu chương trình
Nhằm thể hiện rõ nét nhất các ca kiểm thử cho cầu thang máy, tôi đã xây dựng một chương trình mô phỏng hoạt động của thang máy cho các ca kiểm thử và kết thúc quá trình mô phỏng sẽ hiển thị các quá trình chuyển trạng thái. Để đạt được mục đích này, tôi đã sử dụng ngôn ngữ lập trình C# 2005 để xây dựng chương trình.
Giao diện chương trình đơn giản, thuận tiện cho người dùng thao tác, giao diện chương trình như sau:
Giao diện tách làm hai phần mô hình và kết quả. Phần mô hình nhằm mô phỏng hoạt động của thang máy ứng với các ca kiểm thử. Phần kết quả thể hiện quá trình chuyển trạng thái ứng với ca kiểm thử.
Chương trình cho phép bạn bắt đầu một ca kiểm thử theo hai chế độ: Một là, cho phép bạn chọn tầng và chiều xuất phát, tầng và chiều xuất phát sau khi chọn sẽ hiển thị cho người dùng biết. Tiếp theo sẽ chọn tầng đến, tầng đến được chọn sẽ có màu đỏ. Khi chọn tầng bắt đầu xuất phát thì thanh trượt mô phỏng thang máy sẽ tự động chuyển đến tầng đó. Khi click vào nút “Bắt đầu” thì chương trình sẽ bắt đầu mô phỏng. Bạn có thể dừng quá trình mô phỏng bằng cách click vào nút “Dừng”.
Hai là, cho phép bạn bắt đầu ca kiểm thử với trạng thái xuất phát là tại vị trí cầu thang đang dừng. Bạn chọn tầng cần đến và chiều cần đi, sau đó chọn tầng đến, click vào nút “Bắt đầu” để mô phỏng.
Cả hai chế độ, khi thang máy di chuyển đến đâu thì đều thể hiện tầng và chiều ở vị trí đó. Khi đã qua tầng nào thì tầng được chọn đó sẽ trở lại trạng thái như chưa được chọn. Trong quá trình làm việc đều có xử lý ưu tiên.
Trong quá trình mô phỏng thì quá trình chuyển trạng thái sẽ được hiển thị tự động bên bảng kết quả.
4.3.3.3. Các lớp cài đặt
Enum State : Tập hợp trạng thái.
Tên Mô tả
Property
Up Biểu thị trạng thái lên
Down Biểu thị trạng thái xuống
Class Floor: Lớp tầng.
Tên Mô tả
Property
FloorNumber Biểu thị số tầng.
FState Biểu thị trạng thái của tầng
Name Tên tầng. Sử dụng khi in kết quả
Contrucsor
Floor() Contrucsor không có tham số
Floor(int floorNumber) Contrucsor có 1 tham số là số tầng Floor(int numFloor,State state) Contrucsor có 2 tham số là số tầng
và trạng thái tầng. Floor(int numFloor,State
state,string name)
Contrucsor có 3 tham số là số tầng, trạng thái tầng và tên tầng.
Method bool Contains(Floor floor) Hàm kiểm tra 2 tầng giống nhau về tầng và trạng thái
Class Elevator: Lớp cầu thang.
Tên Mô tả
Property
LastFloor Biểu thị trạng thái tầng có bấm nút gọi đi tầng khác.
CurrentState Biểu thị trạng thái thang máy.
StateExact Biểu thị trạng thái thang máy tiếp theo khi bấm nút gọi.
CurrentFloor Biểu thị trạng thái tầng hiện thời.
ListOle Danh sách các tầng thang máy đã chạy qua.
Member
m_items Danh sách lưu các trạng thái tầng.
m_itemsUp Danh sách lưu các tầng được bấm đi lên. m_itemDown Danh sách lưu các tầng được bấm đi xuống. m_lassposition Lưu vị trí cuối cùng của trạng thái cầu
Contrucsor
Elevator() Contrucsor không có tham số Elevator(int
initialFloor,State state)
Contrucsor có 2 tham số là trạng thái tầng bắt đầu và trạng thái chiều của tầng.
Method
SetCurrentState(Fl oor floor)
Thiết lập trạng thái hiện tại cho thang máy
SetCurrentState(Fl oor a,Floor b)
So sánh 2 tầng và thiết lập trạng thái cho cầu thang.
Start(Floor) Thêm tầng đầu tiên vào danh sách. Add(Floor) Thêm các tầng vào danh sách. OpenFloor(Floor,r
ef int numFloor)
Hàm kiểm tra và thiết lập danh sách mở cầu thang.
StopTimer() Kiểm tra trạng thái dừng cầu thang.
Mô tả chung:
Nếu bấm nút gọi cầu thang gọi là trạng thái gọi cầu thang. Nếu bấm nút gọi tầng gọi là trạng thái gọi tầng.
Bài toán đặt ra là mô phỏng trạng thái cầu thang chạy và đưa ra chu trình ơle. Đầu vào ở đây được xác định đó là ấn nút trạng thái gọi cầu thang sau đó xác định trạng thái gọi tầng. Sau khi kết thúc quá trình đó mới cho cầu thang chuyển động để đánh giá độ bao phủ tầng.
4.3.3.4. Mô tả một số phương thức chính sử dụng trong chương trình
Phương thức Add(Floor a): Phương thức này kiểm tra tầng đầu vào. Nếu là trạng thái tầng được thêm vào thì thêm vào danh sách m_items và thiết lập giá trị cho LastFloor. Nếu là tầng được bấm thì kiểm tra chiều của LastFloor. Nếu là chiều lên thì thêm vào danh sách m_itemsUp và sắp xếp lại theo chiều tăng dần, ngược lại thì thêm vào danh sách m_itemsDown và sắp xếp theo chiều giảm dần.
Phương thức OpenFloor(Floor a,ref int num): Phương thức này kiểm tra tầng đầu vào a hiện tại của cầu thang đang chuyển động. Nếu tầng hiện tại xác
thái gọi cầu thang đó và thiết lập lại chiều chuyển động cho cầu thang, ngược lại thì chỉ xét đến danh sách tầng được gọi và xoá tầng a trong danh sách.
KẾT LUẬN
Kiểm thử phần mềm, một nội dung nghiên cứu được triển khai từ rất sớm và không phải là mới mẻ đối với thế giới, nhưng luôn là vấn đề cấp thiết cho việc nâng cao chất lượng phần mềm, và trong điều kiện phát triển phần mềm ở Việt Nam việc hiểu biết và vận dụng nó còn nhiều hạn chế.
Trong luận văn này, tác giả đã trình bày tổng quan về kiểm thử phần mềm: bao gồm các khái niệm cơ bản, các chiến lược kiểm thử, các phương pháp kiểm thử, và các vấn đề liên quan đến kiểm thử trong đảm bảo chất lượng phần mềm.
Luận văn cũng trình bày tổng quan về kiểm thử phủ và những nghiên cứu liên quan đến kiểm thử phủ trong các phần mềm phát triển theo phương pháp truyền thống, phần mềm phát triển theo hướng đối tượng, những kết quả đạt được, những khó khăn thuận lợi và những vấn đề đặt ra.
Cuối cùng luận văn đi sâu nghiên cứu về mô hình máy trạng thái – một mô hình phát triển phần mềm sử dụng lập trình hướng đối tượng cho một lớp bài toán mô tả hệ thống có các đối tượng di chuyển trong không gian các trạng thái khác nhau. Tại đây luận văn cũng trình bày sâu về kiểm thử phủ và vận dụng phương pháp kiểm thử để tiến hành lập trình thử nghiệm kiểm thử phủ cho bài toán cầu thang máy được phát triển theo mô hình máy trạng thái hữu hạn.
Những kết quả của luận văn chưa nhiều, nhưng nó thực sự đóng góp cho việc nghiên cứu và ứng dụng kiểm thử phủ phần mềm cho mô hình phát triển đối với một lớp bài toán hạn chế. Trong hướng tiếp tục của luận văn, tác giả hy vọng có thể mở rộng nghiên cứu kiểm thử phủ phần mềm với mô hình cho những lớp bài toán rộng rãi hơn.
TÀI LIỆU THAM KHẢO
[Beiz90] Boris Beizer. Software Testing Techniques, Second Edition, Van NostrandReinhold, 1990.
[Beiz95] Beizer, B. Black-box Testing.Wiley,1995.