Chƣơng 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
b. Độ bao phủ chuyển trạng thái (transition coverage)
2.9. Kỹ thuật sinh ca kiểm thử
Ca kiểm thử tốt là ca kiểm thử có thể bao phủ toàn bộ mô hình FSM. Do vậy ta chọn độ bao phủ trạng thái, nếu độ bao phủ là 100% thì có thể phát hiện được tất cả các lỗi về output và các lỗi về trạng thái.
Phương pháp sinh ca kiểm thử:
Với mỗi phần tử của tập chuyển trạng thái hay với một đường dẫn con trên cây kiểm thử sẽ sinh ra một ca kiểm thử, các ca kiểm thử này được xếp vào bộ ca kiểm thử các chuyển trạng thái của FSM. Bên cạnh đó, ta sẽ xây dựng một bộ ca kiểm thử trạng thái ban đầu của FSM và một bộ ca kiểm thử các chuyển trạng thái của FSM. Với mỗi giá trị input tương ứng thì sẽ có một chuyển trạng thái. Mỗi chuyển trạng thái trong FSM sẽ tương ứng với sự chuyển nút ở mức thứ i sang nút ở mức thứ i+1. Với đường đi từ trạng thái ban đầu có mức cao hơn sẽ bao phủ đường đi tới tất cả các trạng thái trong mô hình.
2.9.1. Sinh cây kiểm thử và tìm tập bao phủ chuyển trạng thái.
Để dễ dàng cho việc sinh ca kiểm thử thì tiến hành như sau:
Thêm thông tin output ứng với mỗi thông tin input.
Thêm thông tin trạng thái cuối cùng của một dãy chuyển trạng thái với mục đích để xác định các chuỗi kiểm chứng.
Thông tin input và output được ngăn cách bởi ký tự „/‟, với mỗi cặp input/output.
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.
Phương pháp chủ yếu khác cho sử dụng đồ thị dựa trên các thông số kỹ thuật là để xây dựng mô hình hóa hành vi trạng thái của hệ thống phần mềm bằng cách phát triển một số đặc tả hình thức của máy trạng thái hữu hạn (FSM). Trong những năm qua, nhiều đề xuất đã được thực hiện để tạo FSM và làm thế nào để kiểm tra các phần mềm dựa trên FSM. Các chủ đề làm thế nào để tạo, vẽ và giải thích một FSM đã lấp đầy toàn bộ các giáo trình, và các tác giả đã đi vào chiều sâu lớn và nỗ lực để xác định chính xác những gì đi vào một trạng thái, những gì có thể đi vào các cạnh, và những gì gây ra quá trình chuyển đổi. Thay vì sử dụng bất kỳ ngôn ngữ cụ thể, họ đã chọn để xác định một mô hình rất chung chung cho FSM có thể thích ứng với hầu hết bất kỳ ký hiệu. Những FSM cơ bản là đồ thị, và các tiêu chuẩn thử nghiệm đồ thị đã được xác định có thể được sử dụng để kiểm tra phần mềm đó là dựa trên các FSM.
Một lợi thế của cơ sở thử nghiệm dựa trên FSM là số lượng lớn các phần mềm ứng dụng thực tế được dựa trên một mô hình FSM, hoặc có thể được mô hình hóa như FSM. Hầu như tất cả các phần mềm nhúng phù hợp trong thể loại này, bao gồm cả phần mềm trong điều khiển từ xa, thiết bị gia dụng, đồng hồ, xe hơi, điện thoại di động, hướng dẫn chuyến bay máy bay, tín hiệu giao thông, hệ thống kiểm soát đường sắt, thiết bị định tuyến mạng, tự động hóa nhà máy và máy rút tiền tự động... Thật vậy, phần mềm lớn nhất có thể được mô hình hóa với FSM, để mô hình hóa các phần mềm. Xử lý văn bản, ví dụ, chứa rất nhiều lệnh và mô hình hóa của trạng thái như FSM có thể là không thực tế. Nhưng FSM thường có giá trị lớn. Nếu các kiểm thử viên tạo ra một mô hình FSM để mô tả phần mềm hiện có, họ sẽ gần như chắc chắn phát hiện lỗi trong thiết kế. Bên cạnh đó vẫn có sự tranh luận về vấn đề này; nếu các nhà thiết kế tạo ra FSMs, các thử nghiệm sẽ không cần bận tâm cho việc tạo ra chúng vì vấn đề rất tốt. Điều này có lẽ sẽ là sự thật nếu người lập trình có thể làm hoàn hảo.
FSM có thể được chú thích với các loại khác nhau của các hành động, bao gồm cả các hành động trên quá trình chuyển đổi, hành động nhập vào các nút, và hành động xuất ra trên các nút. Nhiều ngôn ngữ được sử dụng để mô tả FSM, bao gồm cả biểu đồ trạng thái UML, bảng trạng thái automata hữu hạn (SCR), và máy hữu hạn trạng thái.
Một máy trạng hữu hạn là một đồ thị có các nút đại diện cho các trạng thái trong các hành vi được thực hiện của các phần mềm và các cạnh đại diện cho quá trình chuyển đổi giữa các trạng thái. Một máy trạng thái hữu hạn đại diện cho một tình huống nhận ra rằng vẫn còn sự tồn tại trong một khoảng thời gian. Một trạng thái được xác định bởi các giá trị cụ thể cho một tập hợp các biến; miễn là các biến có những giá
trị phần mềm được coi là ở trong trạng thái đó. (Lưu ý rằng các biến được định nghĩa ở cấp mẫu thiết kế và có thể không nhất thiết phải tương ứng với các biến trong một quá trình thực hiện.) Một quá trình chuyển đổi được coi là xảy ra trong không gian và thường đại diện cho một sự thay đổi các giá trị của một hay nhiều biến. Khi các biến thay đổi, các phần mềm được coi là để lựa chọn các vị từ (predicates) và sinh các kịch bản khác nhau của quá trình chuyển đổi để sau trạng thái (successor). Nếu các vị từ được chuyển đổi thành các hàm vị từ và sau một trạng thái chuyển tiếp là như nhau, thì giá trị của các biến trạng thái sẽ không thay đổi. FSM thường xác định điều kiện tiên quyết hoặc bảo vệ vào quá trình chuyển đổi, trong đó xác định giá trị các biến cụ thể phải có cho quá trình chuyển đổi để được kích hoạt, và kích hoạt các sự kiện, đó là những thay đổi trong giá trị biến gây ra quá trình chuyển đổi được thực hiện. Ví dụ, các ngôn ngữ mô hình FSM gọi các trạng thái điều kiện và sự kiện kích hoạt. Các giá trị các sự kiện kích hoạt có trước khi chuyển đổi được gọi là giá trị trước, và các giá trị sau khi chuyển đổi được gọi là giá trị sau. Khi đồ thị được vẽ, chuyển tiếp thường được chú thích với các sự kiện và những giá trị thay đổi. Khi chuẩn bị mô hình FSM để thử nghiệm, điều quan trọng cần lưu ý là không nhất thiết phải làm FSM có các nút chính thức. Họ thường đại diện cho hành vi của một thiết bị chạy trong một thời gian dài. Nhưng một đồ thị để kiểm tra rằng sự trừu tượng của một FSM cần nút ban đầu và cuối cùng vì vậy chúng tôi có thể lấy được con đường thử nghiệm. Đôi khi nó là khá nhiều tùy ý mà các nút được thiết kế như ban đầu và cuối cùng. Với loại hình này của đồ thị, rất nhiều các tiêu chí trên có thể được định nghĩa trực tiếp. Nút bao phủ đòi hỏi mỗi trạng thái trong FSM được viếng thăm ít nhất một lần và được gọi là bao phủ trạng thái. Cạnh bao phủ được áp dụng bằng cách yêu cầu mỗi sự chuyển tiếp trong FSM được viếng thăm ít nhất một lần, được gọi là bao phủ chuyển.
Các tiêu chuẩn bao phủ dòng dữ liệu nhiều hơn một chút khó khăn cho FSM. Đó là, tất cả các hành động trên là quá trình chuyển đổi. Không giống với các đồ thị dựa trên mã, cạnh khác nhau từ cùng một nút trong một FSM không cần phải có cùng một bộ defs và sử dụng. Những tác động của sự thay đổi để các biến có liên quan có thể cảm nhận ngay lập tức bằng cách tham gia một quá trình chuyển sang trạng thái kế tiếp. Đó là, defs có gây ra các biến ngay lập tức đạt mục đích sử dụng.
Như vậy, All-Defs và All-Uses tiêu chuẩn chỉ có thể được áp dụng có ý nghĩa cho các biến tham gia sự kiện. Điều này cũng sẽ đưa ra một vấn đề thực tế hơn, đó là FSM không luôn luôn giao mô hình cho tất cả các biến. Đó là, việc sử dụng được đánh dấu rõ ràng trong FSM, nhưng defs không phải luôn luôn dễ dàng để tìm thấy. Vì những lý do này, rất ít nỗ lực đã được thực hiện để áp dụng tiêu chuẩn dòng dữ liệu để FSM. Dưới đây là một số phát sinh của kỹ thuật sinh ca kiểm thử dựa trên hành vi trạng thái của hệ thống:
Một khó khăn trong việc thực hiện kỹ thuật đồ thị là nhận được từ các mô hình FSM ở nơi đầu tiên. Các mô hình FSM của phần mềm có thể có hoặc có thể không tồn
tại. Nếu không, các thử nghiệm có thể làm tăng đáng kể sự hiểu biết của mình về các phần mềm bằng cách bắt nguồn từ FSM. Tuy nhiên, đây không phải là một hướng dẫn đầy đủ về việc sinh ca kiểm thử dựa trên hành vi hệ thống trạng thái FSM:
Kết hợp đồ thị dòng điều khiển: Đối với các lập trình viên có ít hoặc không có kiến thức về FSM, đây thường là cách tiếp cận tự nhiên nhất để bắt đầu với FSM. Phương pháp này có một số vấn đề, vấn đề đầu tiên các nút không phải là các trạng thái. Vấn đề thứ hai là việc thực hiện phải được hoàn thành trước khi những đồ thị có thể được xây dựng; tuy nhiên, loại đồ thị không quy mô với các sản phẩm phần mềm lớn. Đồ thị là đủ phức tạp với quy mô nhỏ, và sẽ tồi tệ hơn nhiều với các chương trình lớn hơn.
Sử dụng cấu trúc phần mềm: Người lập trình viên sẽ có kinh nghiệm hơn có thể xem xét những dòng điều khiển chung của các hoạt động trong phần mềm. Mặc dù một sự cải tiến trong đồ thị dòng điều khiển, phương pháp này không thực sự các trạng thái. Đây là loại nguồn gốc cũng rất chủ quan, có nghĩa là xét nghiệm khác nhau sẽ vẽ đồ thị khác nhau, giới thiệu không nhất quán trong những thử nghiệm. Nó cũng đòi hỏi kiến thức chuyên sâu của phần mềm, không thể cho đến khi thiết kế chi tiết đã sẵn sàng, và rất khó để mở rộng quy mô cho các chương trình lớn.
Mô hình hóa các biến trạng thái: Một phương pháp được bắt nguồn từ FSM, được xem như là các giá trị của các biến trạng thái trong chương trình và thường được định nghĩa rất sớm trong thiết kế. Bước đầu tiên là xác định các biến trạng thái, sau đó chọn những thông tin thực tế có liên quan đến máy trạng thái FSM (ví dụ, các biến toàn cục và lớp). Các chiến lược này sẽ rất hấp dẫn vì có thể mong đợi sự khác nhau của việc thử nghiệm để lấy được các FSM giống nhau hoặc tương tự. Chiến lược này cũng không có những nhược điểm của hai phương pháp đầu tiên. Nó chưa thể hoàn toàn đi vào tự động hóa cho các quá trình, bởi vì những khó khăn trong việc xác định quá trình chuyển đổi từ nguồn và quyết định của các biến đòi hỏi mô hình phải có sự phán xét. Các FSM có nguồn gốc bằng cách mô phỏng các biến trạng thái có thể không hoàn toàn phản ánh đến phần mềm.
Sử dụng các hàm hoặc chi tiết kỹ thuật đặc tả: Phương pháp cuối cùng cho FSM được bắt nguồn dựa vào yêu cầu thực tế hay chi tiết kỹ thuật chính thức mô tả hành vi của phần mềm. Những yêu cầu này sẽ dẫn đến một FSM dựa trên chi tiết kỹ thuật thường tốt hơn và dễ hiểu hơn. Nếu phần mềm được thiết kế tốt, thì FSM cũng chứa những thông tin tương tự như biểu đồ trạng thái UML.