PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP VÀ RÀNG BUỘC OCL

Tìm hiểu phương pháp sinh dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML, biểu đồ lớp và ràng buộc OCL. Tối ưu hóa quy trình kiểm thử phần mềm.

• Tác giả: Nguyễn Văn Hòa
• Người hướng dẫn: PGS. Phạm Ngọc Hùng
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Phương Pháp Sinh Dữ Liệu Kiểm Thử Tự Động Từ UML và OCL
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2016
• Địa điểm: Hà Nội

Tóm tắt

I. Tổng Quan Về Sinh Dữ Liệu Kiểm Thử Tự Động Từ UML OCL

Công nghệ phần mềm ngày càng phát triển, đi kèm với đó là nhu cầu kiểm thử để đảm bảo chất lượng. Ước tính, kiểm thử chiếm phần lớn thời gian và chi phí phát triển phần mềm. Vì vậy, việc sinh dữ liệu kiểm thử tự động trở nên quan trọng để rút ngắn thời gian và nâng cao chất lượng. Kiểm thử tự động giúp giảm chi phí và thời gian, đồng thời đảm bảo chất lượng. Nhiều nghiên cứu đã được đề xuất để giải quyết vấn đề này, mỗi nghiên cứu mang lại kết quả khác nhau. Bài nghiên cứu này trình bày một phương pháp cải tiến sinh ca kiểm thử tự động để nâng cao chất lượng. Phương pháp này đòi hỏi các mô hình toán học đặc tả chính xác hành vi của hệ thống. Phân tích và thiết kế dựa trên các biểu đồ tuần tự UML là một công việc dễ dàng và phổ biến hơn. Do đó, việc kiểm thử tính đúng đắn cho thiết kế dựa trên mô hình đang được nghiên cứu và áp dụng thực tế. Giai đoạn kiểm thử thiết kế tập trung vào các ca kiểm thử được sinh ra từ các đường kiểm thử dựa trên đồ thị hoạt động và sinh ra dữ liệu kiểm thử từ dữ liệu đầu vào là các bản thiết kế từ đặc tả chương trình. Mục tiêu là nâng cao chất lượng kiểm thử và khả năng phát hiện lỗi của các kịch bản kiểm thử.

1.1. Giới Thiệu Chung Về Phương Pháp Kiểm Thử Tự Động

Phương pháp kiểm thử tự động đang ngày càng được sử dụng rộng rãi trong quy trình phát triển phần mềm hiện đại. Nó giúp giảm thiểu công sức và thời gian cần thiết cho việc kiểm thử, đồng thời nâng cao độ tin cậy và chất lượng của sản phẩm phần mềm cuối cùng. Việc áp dụng các công cụ và kỹ thuật tự động hóa vào quy trình kiểm thử cho phép các nhà phát triển tập trung vào các khía cạnh phức tạp hơn của dự án.

1.2. Tầm Quan Trọng Của UML và OCL Trong Kiểm Thử Phần Mềm

UML (Unified Modeling Language) và OCL (Object Constraint Language) đóng vai trò quan trọng trong việc mô tả và đặc tả hệ thống phần mềm. UML cung cấp một ngôn ngữ trực quan để mô hình hóa các thành phần và mối quan hệ trong hệ thống, trong khi OCL cho phép định nghĩa các ràng buộc và điều kiện một cách chính xác. Việc sử dụng UML và OCL giúp tăng cường khả năng hiểu và kiểm soát hệ thống, từ đó cải thiện hiệu quả của quá trình kiểm thử. Ví dụ UML và OCL giúp kiểm thử phần mềm hiệu quả hơn.

II. Thách Thức Trong Sinh Dữ Liệu Kiểm Thử Tự Động Từ UML OCL

Việc sinh dữ liệu kiểm thử tự động từ UML và OCL đối mặt với nhiều thách thức. Biểu đồ tuần tự biểu diễn thiết kế theo trình tự thời gian và bao gồm nhiều thành phần, cấu trúc biểu diễn một hoạt động khác nhau trong ca sử dụng. Biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển là một công việc khó khăn vì chúng không tuân theo một qui luật nào cả. Cần liệt kê tất cả các thành phần, khối toán tử bên trong biểu đồ tuần tự và dùng thuật toán tương ứng biến đổi cho từng toán tử và thành phần đó. Thuật toán này không những phải hoạt động đúng mà còn phải đảm bảo tính đúng đắn khi các thành phần và toán tử lồng nhau. Việc tự động hóa hoàn toàn quá trình này đòi hỏi các thuật toán phức tạp và khả năng xử lý các trường hợp biên. Ràng buộc OCL có thể rất phức tạp và khó giải quyết, đòi hỏi các công cụ mạnh mẽ và hiệu quả.

2.1. Độ Phức Tạp Của Mô Hình UML và Ràng Buộc OCL

Mô hình UML và ràng buộc OCL có thể trở nên rất phức tạp, đặc biệt đối với các hệ thống phần mềm lớn và phức tạp. Việc xử lý và phân tích các mô hình này đòi hỏi các công cụ và kỹ thuật tiên tiến. Độ phức tạp của mô hình và ràng buộc có thể làm chậm quá trình sinh dữ liệu kiểm thử và tăng khả năng xảy ra lỗi. Vì vậy, cần có các phương pháp tiếp cận hiệu quả để đơn giản hóa và quản lý độ phức tạp của mô hình.

2.2. Vấn Đề Về Tính Khả Thi Của Các Ca Kiểm Thử Được Sinh Ra

Không phải tất cả các ca kiểm thử được sinh ra từ mô hình UML và ràng buộc OCL đều có tính khả thi. Một số ca kiểm thử có thể vi phạm các ràng buộc hoặc không thể thực hiện được trong thực tế. Việc xác định và loại bỏ các ca kiểm thử không khả thi là một thách thức quan trọng. Cần có các kỹ thuật để đánh giá tính khả thi của ca kiểm thử trước khi thực hiện kiểm thử thực tế, từ đó tiết kiệm thời gian và tài nguyên.

2.3. Khó Khăn Trong Việc Tự Động Hóa Quá Trình Giải Ràng Buộc OCL

Việc tự động hóa quá trình giải ràng buộc OCL là một thách thức lớn do tính biểu cảm cao và độ phức tạp của ngôn ngữ này. Các ràng buộc OCL có thể bao gồm các biểu thức logic, toán học, và truy vấn dữ liệu phức tạp. Việc giải các ràng buộc này đòi hỏi các công cụ và thuật toán mạnh mẽ, chẳng hạn như SMT solver, và có thể tốn nhiều thời gian và tài nguyên tính toán.

III. Phương Pháp Sinh Đồ Thị Dòng Điều Khiển Từ Biểu Đồ Tuần Tự UML

Phương pháp sinh dữ liệu kiểm thử tự động từ UML và OCL hiệu quả. Để làm được điều này chúng ta phải liệt kê tất cả các thành phần, khối toán tử bên trong biểu đồ tuần tự và dùng thuật toán tương ứng biến đổi cho từng toán tử và thành phần đó. Thuật toán này không những phải hoạt động đúng mà còn phải đảm bảo tính đúng đắn khi các thành phần và toán tử lồng nhau. Đồ thị dòng điều khiển là một đồ thị biểu diễn trực tiếp của biểu đồ tuần tự và được tạo nên từ bảy loại nốt nối với nhau bởi các đường. Bảy loại nốt đó là nốt bắt đầu, nốt đơn vị, nốt quyết định, nốt rẽ nhánh, nốt kết hợp, nốt kết thúc.

3.1. Thuật Toán Biến Đổi Biểu Đồ Tuần Tự Sang Đồ Thị Dòng Điều Khiển

Cần một thuật toán hiệu quả để biến đổi biểu đồ tuần tự thành đồ thị dòng điều khiển. Thuật toán này cần xác định và xử lý các thành phần khác nhau của biểu đồ tuần tự, bao gồm các thông điệp, các toán tử điều khiển, và các phân đoạn. Thuật toán cần đảm bảo tính chính xác và đầy đủ của quá trình biến đổi, sao cho đồ thị dòng điều khiển phản ánh đúng hành vi của hệ thống.

3.2. Các Loại Nốt Trong Đồ Thị Dòng Điều Khiển và Ý Nghĩa

Đồ thị dòng điều khiển bao gồm nhiều loại nốt khác nhau, mỗi loại có một ý nghĩa riêng. Nốt bắt đầu đánh dấu điểm khởi đầu của quá trình thực thi. Nốt đơn vị biểu diễn một hành động hoặc một khối lệnh. Nốt quyết định biểu diễn một điều kiện hoặc một lựa chọn. Nốt rẽ nhánh và kết hợp được sử dụng để biểu diễn các luồng song song. Nốt kết thúc đánh dấu điểm kết thúc của quá trình thực thi. Hiểu rõ ý nghĩa của từng loại nốt giúp chúng ta phân tích và kiểm thử hệ thống một cách hiệu quả hơn.

IV. Kỹ Thuật Sinh Kịch Bản Kiểm Thử Từ Đồ Thị Dòng Điều Khiển

Sau khi có đồ thị dòng điều khiển, cần có kỹ thuật sinh kịch bản kiểm thử. Chia ra 2 kịch bản kiểm thử. Một cho các phân đoạn thông thường (các phân đoạn không chứa luồng song song) và một kịch bản kiểm thử cho các phân đoạn chứa luồng song song (Par, Seq).

4.1. Kịch Bản Kiểm Thử Cho Các Toán Tử Thông Thường

Kịch bản kiểm thử cho các toán tử thông thường tập trung vào việc kiểm tra các luồng điều khiển tuần tự và các lựa chọn điều kiện. Cần đảm bảo rằng tất cả các nhánh và đường dẫn trong đồ thị dòng điều khiển đều được kiểm tra ít nhất một lần. Các ca kiểm thử cần bao gồm các giá trị đầu vào khác nhau để đảm bảo độ bao phủ cao của quá trình kiểm thử.

4.2. Kịch Bản Kiểm Thử Cho Các Phân Đoạn Song Song Par Seq

Kịch bản kiểm thử cho các phân đoạn song song (Par, Seq) phức tạp hơn do sự xuất hiện của các luồng thực thi song song. Cần kiểm tra tất cả các khả năng tương tác giữa các luồng song song, bao gồm cả các trường hợp chia sẻ dữ liệu và đồng bộ hóa. Các ca kiểm thử cần bao gồm các tình huống khác nhau về thời gian và thứ tự thực thi của các luồng song song.

4.3. Đánh Giá Độ Bao Phủ Kiểm Thử Độ Bao Phủ Yếu Trung Bình Mạnh

Độ bao phủ kiểm thử là một thước đo quan trọng để đánh giá hiệu quả của quá trình kiểm thử. Có nhiều loại độ bao phủ khác nhau, bao gồm độ bao phủ yếu, trung bình, và mạnh. Độ bao phủ yếu chỉ yêu cầu kiểm tra tất cả các nốt hoặc cạnh trong đồ thị dòng điều khiển. Độ bao phủ trung bình yêu cầu kiểm tra tất cả các nhánh và đường dẫn trong đồ thị. Độ bao phủ mạnh yêu cầu kiểm tra tất cả các khả năng tương tác giữa các luồng song song. Lựa chọn loại độ bao phủ phù hợp phụ thuộc vào yêu cầu cụ thể của dự án.

V. Ứng Dụng SMT Solver Trong Giải Hệ Ràng Buộc OCL và Sinh Dữ Liệu

Sau khi xây dựng đồ thị dòng điều khiển, ràng buộc OCL, cần giải hệ bằng công cụ SMT-Solver.

5.1. Giới Thiệu Về SMT Solver và Khả Năng Giải Quyết Bài Toán Ràng Buộc

SMT-Solver (Satisfiability Modulo Theories) là một công cụ mạnh mẽ để giải quyết các bài toán ràng buộc. SMT-Solver có khả năng xử lý các ràng buộc phức tạp, bao gồm các ràng buộc logic, toán học, và truy vấn dữ liệu. SMT-Solver được sử dụng rộng rãi trong nhiều lĩnh vực, bao gồm kiểm thử phần mềm, xác minh phần cứng, và trí tuệ nhân tạo.

5.2. Phương Pháp Xây Dựng Hệ Ràng Buộc Từ UML và OCL Để Đưa Vào SMT Solver

Việc xây dựng hệ ràng buộc từ UML và OCL để đưa vào SMT-Solver đòi hỏi một quy trình chặt chẽ. Cần phân tích mô hình UML và ràng buộc OCL để xác định các biến và ràng buộc liên quan. Sau đó, cần biểu diễn các ràng buộc này dưới dạng các biểu thức logic và toán học mà SMT-Solver có thể hiểu được. Quá trình này có thể được tự động hóa bằng cách sử dụng các công cụ và kỹ thuật phù hợp.

5.3. Tối Ưu Hóa Quá Trình Giải Ràng Buộc Để Tăng Hiệu Quả Sinh Dữ Liệu

Quá trình giải ràng buộc có thể tốn nhiều thời gian và tài nguyên tính toán, đặc biệt đối với các hệ ràng buộc phức tạp. Do đó, cần có các kỹ thuật để tối ưu hóa quá trình giải ràng buộc. Các kỹ thuật này có thể bao gồm việc đơn giản hóa các ràng buộc, sử dụng các thuật toán tìm kiếm hiệu quả, và tận dụng các đặc tính của bài toán ràng buộc.

VI. Kết Luận và Hướng Phát Triển Của Sinh Dữ Liệu Kiểm Thử Tự Động

Bài nghiên cứu này trình bày một phương pháp sinh ca kiểm thử tự động và cải tiến một công đoạn sinh ca kiểm thử tự động để nâng cao chất lượng. Cần tiếp tục nghiên cứu để giải quyết các thách thức còn tồn tại và phát triển các phương pháp sinh dữ liệu kiểm thử hiệu quả hơn. Việc áp dụng các phương pháp sinh dữ liệu kiểm thử tự động giúp giảm chi phí và thời gian phát triển phần mềm, đồng thời nâng cao chất lượng sản phẩm.

6.1. Tóm Tắt Kết Quả Nghiên Cứu và Đánh Giá Tính Khả Thi

Nghiên cứu đã trình bày một phương pháp sinh ca kiểm thử tự động từ biểu đồ tuần tự UML và ràng buộc OCL, sử dụng đồ thị dòng điều khiển và SMT-Solver. Kết quả nghiên cứu cho thấy phương pháp này có tính khả thi và có thể giúp giảm chi phí và thời gian kiểm thử. Tuy nhiên, vẫn còn nhiều thách thức cần giải quyết để nâng cao hiệu quả và độ tin cậy của phương pháp.

6.2. Hướng Phát Triển Tiếp Theo Để Nâng Cao Chất Lượng Kiểm Thử

Hướng phát triển tiếp theo có thể tập trung vào việc cải thiện thuật toán biến đổi biểu đồ tuần tự thành đồ thị dòng điều khiển, phát triển các kỹ thuật tối ưu hóa quá trình giải ràng buộc, và nghiên cứu các phương pháp đánh giá độ bao phủ kiểm thử hiệu quả hơn. Ngoài ra, cần nghiên cứu các phương pháp áp dụng trí tuệ nhân tạo và học máy vào quá trình sinh dữ liệu kiểm thử để tự động hóa các công đoạn phức tạp và tăng cường khả năng phát hiện lỗi.

6.3. Triển Vọng Ứng Dụng Thực Tế Của Phương Pháp Sinh Dữ Liệu Kiểm Thử Tự Động

Phương pháp sinh dữ liệu kiểm thử tự động có triển vọng ứng dụng thực tế rộng rãi trong các dự án phát triển phần mềm. Việc áp dụng phương pháp này giúp giảm chi phí và thời gian kiểm thử, đồng thời nâng cao chất lượng sản phẩm. Đặc biệt, phương pháp này có thể được áp dụng hiệu quả trong các dự án phần mềm lớn và phức tạp, nơi việc kiểm thử thủ công trở nên khó khăn và tốn kém.

Trích đoạn nội dung tài liệu

Chương 1 giới thiệu đề tài, lý do chọn đề tài, trình bày tổng quan nội dung nghiên cứu và bố cục luận văn. Chương 2 trình bày các khái niệm cơ bản phục vụ cho đề tài bao gồm các vấn đề liên quan trong kiểm thử dựa trên mô hình, phương pháp đặc tả mô hình bằng máy trạng thái UML. Các khái niệm về biểu đồ tuần tự và các phân đoạn trong thiết kế. Cuối cùng là giới thiệu đồ thị dòng điều khiển và đề xuất ba độ đo kiểm thử áp dụng cho bài nghiên cứu.

Chương 3 nghiên cứu đề xuất cách biến đổi từ biểu đồ tuần tự sang đồ thị dòng điều khiển và các thuật toán biến đổi. Phương pháp sinh ca kiểm thử sau khi hoàn thành độ thị dòng điều khiển trong đó chia ra 2 kịch bản kiểm thử. Một cho các phân đoạn thông thường (các phân đoạn không chứa luồng song song) và một kịch bản kiểm thử cho các phân đoạn chứa luồng song song (Par, Seq). Phần cuối chương 3 trình bày phương pháp sinh dữ liệu kiểm thử từ đồ thị dòng điều khiển, một số nghiên cứu liên quan để thấy được ưu nhược điểm của bài nghiên cứu so với các phương pháp khác.

Chương 4 giới thiệu công cụ thực nghiệm, các ví dụ thể hiện tính đúng đắn và khả thi của phương pháp đề xuất. Kết quả thu được thực tế từ chương trình và rút ra ý nghĩa của phương pháp đề xuất. Cuối cùng là kết luận, định hướng mở rộng và tài liệu tham khảo. 3 Chương 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ HÌNH 2.1 Quy trình chung của kiểm thử dựa trên mô hình Mô hình UML được thiết kế từ các đặc tả yêu cầu của hệ thống.

Mô hình có thể được biểu diễn bằng các loại mô hình và biểu đồ khác nhau. Việc xây dựng mô hình còn phải dựa trên các yếu tố dữ liệu đầu vào và đầu ra. Mô hình này được sử dụng để sinh đầu vào cho các ca kiểm thử. Tiếp đến, chúng ta sẽ sinh giá trị đầu ra mong muốn ứng với mỗi bộ đầu vào.

Khi kết thúc bước này, chúng ta đã có các ca kiểm thử. Sau khi thực thi các ca kiểm thử tương ứng theo từng giai đoạn hoặc phương pháp tiếp cận, kết quả thu được sẽ được so sánh với kết quả mong đợi. Từ đó quyết định hành động tiếp theo như sửa đổi mô hình hoặc dừng kiểm thử, v. Thiết kế Các bản đặc tả yêu cầu Mô Phản hồi hình Phản hồi Tạo tự động Các chuỗi kiểm Kiểm thử dự Kết luận: Pass / thử đoán Fail Theo dõi Điều khiển Phản hồi Thực thi Hình 2.1 Qui trình kiểm thử dựa trên mô hình.1 mô tả về quy trình chung của kiểm thử tự động dựa trên mô hình [6].

Kiểm thử tự động dựa trên mô hình gồm các giai đoạn sau:  Sinh mô hình dựa trên các yêu cầu và chức năng của hệ thống.  Sinh các ca kiểm thử (bộ đầu vào và giá trị đầu ra mong đợi cho mỗi ca kiểm thử).  Chạy các kịch bản kiểm thử để phát hiện các lỗi/khiếm khuyết của sản phẩm.  So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến.

 Quyết định hành động tiếp theo (sửa đổi mô hình, tạo thêm ca kiểm thử, dừng kiểm thử, đánh giá chất lượng của phần mềm) [1].2 Đồ thị dòng điều khiển Đồ thị dòng điều khiển (Control Flow Graph - CFG) là đồ thị được sinh ra từ biểu đồ tuần tự bởi một thuật toán hồi qui, với các ràng buộc và thông số trong thiết kế biểu đồ tuần tự thì sẽ được bóc tách, biến đổi để sinh dữ liệu kiểm thử. Đồ thị dòng điều khiển là một đồ thị biểu diễn trực tiếp của biểu đồ tuần tự và được tạo nên từ bảy loại nốt nối với nhau bởi các đường. Bảy loại nốt đó là [4]:  Nốt bắt đầu (Start node): là nốt khởi đầu của đồ thị.  Nốt đơn vị (BN – Block node): là nốt biểu thị cho một thông điệp hoặc một tuần tự của của các thông điệp.

Mỗi thông điệp m(i) bao gồm thông tin của lớp gửi và lớp nhận và có cấu trúc ( m(i), ParameterList, returnValue ). Mỗi thông số của một thông điệp có thể là một thuộc tính của ràng buộc OCL.  Nốt quyết định (DC – Decision node): là nốt biểu thị cho một hàm điều kiện như điều kiện đúng (hoặc sai) cần được thỏa mãn để lựa chọn các toán hạng tương ứng trong một phân đoạn.  Nốt rẽ nhánh (FN – Fork node): là nốt biểu thị đầu vào của phân đoạn PAR hoặc SEQ.

 Nốt kết hợp (JN – Join node): là nốt đầu ra (hay kết thúc) của phân đoạn PAR hoặc SEQ.  Nốt kết thúc (End node): là nốt kết thúc của tất cả các chu trình trong đồ thị. Một đồ thị dòng điều khiển G được biểu diễn như sau: G <A, E, in, F> với: o ‘in’ là nốt khởi tạo (nốt bắt đầu). o F là tập các nốt hay trạng thái cuối cùng của đồ thị.

o A là tập các nốt bao gồm (BN CN) với BN là nốt đơn vị (Block node), CN = (DN MN FN JN) được gọi là tập các nốt điều khiển. o E là tập các cạnh nối giữa các nốt. E = {f (x; y) | x, y A F} Cấu trúc mỗi nốt A được đề xuất như sau: < nodeId, nodeType, nodeDetails, outEdge > với:  nodeId: là nhãn duy nhất được đính kèm vào mỗi nốt.  nodeType = {decision, merge, fork, join} với mỗi và nodeType = {block, initial, final} cho tất cả các nốt còn lại., | q là số của một tin nhắn trong BN}.

Mỗi nodeDetails được định nghĩa là một bộ ba < m, s, r > với mỗi bản tin xác định 5 được đối tượng gửi s, đối tượng nhận r và tên của mỗi bản tin m cho tất cả các nốt đơn vị BN. Mỗi thông điệp bao gồm các thông tin bên gửi từ biểu đồ lớp và có cấu trúc < m, ParamList, rValue >. Các thông tin này sẽ được đính kèm vào cả các bộ thông số ParamList = { } và trả về giá trị rValue. Ngoài ra, một thông số của một phương thức còn có thể được cung cấp từ các thuộc tính, ràng buộc các lớp.

Một thông số hay một giá trị trả về được tách riêng và các thông tin ràng buộc từ biểu đồ lớp và có cấu trúc < name, type, value, constraint > với name là tên của bộ thông số hoặc thuộc tính, type là dạng dữ liệu, value là giá trị được gán. Còn constraint được lấy từ ràng buộc OLC được khai báo từ các thuộc tính biểu đồ lớp hoặc đã được đính kèm vào biểu đồ tuần tự.  outEdge = { ,…, | q là số cạnh nối}. Mỗi được xác định bằng < sourceNode, targetNode > [13].3 Các độ đo kiểm thử Độ đo kiểm thử là một công cụ giúp ta đo mức độ bao phủ chương trình của một tập ca kiểm thử cho trước.

Mức độ bao phủ của một bộ kiểm thử (tập các ca kiểm thử) được đo bằng tỷ lệ các thành phần thực sự được kiểm thử so với tổng thể sau khi đã thực hiện các ca kiểm thử. Bài nghiên cứu này chia ra 3 tiêu chuẩn bao phủ, để dễ hình dung hơn về 3 tiêu chuẩn bao phủ này chúng ta sẽ bám theo ví dụ về kiểm thử phân đoạn Par đã được biến đổi sang đồ thị dòng điều khiển như Hình 2. I1 I2 I3 Bi FN1 m1 Bi par m2 m3 B1 B1 B2 m4 B2 JN1 m5 Bk Bk Hình 2.2 Đồ thị dòng điều khiển tương ứng của phân đoạn Par. 6 C1: Độ bao phủ yếu: Đường kiểm thử đi qua tất cả các nốt rẽ nhánh (các nốt quyết định) của đồ thị dòng điều khiển.

Đối với ví dụ Hình 2.16 ta có bảng các ca kiểm thử như sau: ng 2.1 Ca kiểm thử độ bao phủ yếu ID Input EO RO Note tc1 Bi-FN1-B1-JN1-Bk C2: Độ bao phủ trung bình: Đường kiểm thử đi qua tất cả các nhánh của đồ thị dòng điều khiển. Bảng các ca kiểm thử tương ứng cho ví dụ Hình 2.16 như sau: ng 2.2 Ca kiểm thử độ bao phủ trung bình ID Input EO RO Note tc1 Bi-FN1-B1-JN1-Bk tc2 Bi-FN1-B2-JN1-Bk C3: Độ bao phủ mạnh: Được áp dụng cho các thiết kế có sử dụng các phân đoạn song song có các luồng chạy song song như Par, Seq. Khi đó các nốt chạy song song có chia sẻ dữ liệu với nhau sẽ được hoán đổi vị trí để tạo ra các đường kiểm thử phủ được nhiều trường hợp hơn.3 Ca kiểm thử độ bao phủ mạnh ID Input EO RO Note tc1 Bi-FN1-B1-JN1-Bk tc2 Bi-FN1-B2-JN1-Bk tc3 Bi-FN1-B1-B2-JN1-Bk Với ví dụ Hình 2.16, ngoài các ca kiểm thử thông thường không xét đến trường hợp các thông điệp song song có điểm chia sẻ dữ liệu ta thu được hai ca kiểm thử ct1 và ct2 như ảng 2. Ngoài ra, vì hai thông điệp B1 và B2 nằm trong phân đoạn Par nên chúng có thể được thực hiện song song hoặc đảo trật theo một thứ tự bất kì.

Trong trường hợp này ta thu được một ca kiểm thử khác là tc3 (Bi-FN1-B1-B2-JN1-Bk) như ảng 2. 7 Chương 3: PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN TỰ 3.1 Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển Biểu đồ tuần tự biểu diễn thiết kế theo trình tự thời gian. Bên trong bao gồm nhiều thành phần và các thông tin đính kèm. Mỗi thành phần, cấu trúc biểu diễn một hoạt động khác nhau trong ca sử dụng.

Biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển là một công việc khó khăn vì chúng không tuân theo một qui luật nào cả. Để làm được điều này chúng ta phải liệt kê tất cả các thành phần, khối toán tử bên trong biểu đồ tuần tự và dùng thuật toán tương ứng biến đổi cho từng toán tử và thành phần đó. Thuật toán này không những phải hoạt động đúng mà còn phải đảm bảo tính đúng đắn khi các thành phần và toán tử lồng ghép vào nhau trong thiết kế. Thuật toán sinh đồ thị dòng điều khiển Đầu vào của thuật toán 1 sinh đồ thị dòng điều khiển là tệp xmi là lưu trữ dạng kí tự của biểu đồ tuần tự.

Vì vậy, để biến đổi được từ biểu đồ tuần tự sang đồ thị dòng điều khiển thì bên trong thuật toán 1 sử dụng các thư viện đọc tệp xmi, từ đó bóc tách dữ liệu theo các từ khóa tương ứng với từng phần tử thiết kế trong biểu đồ tuần tự.1 miêu tả một số từ khóa cơ bản dùng để nhận biết và đọc dữ liệu trong tệp xmi.