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
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.14 MB, 53 trang )
<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">
<b>TRƯỜNG ĐẠI HỌC CÔNG NGHỆ </b>
<b>NGUYỄN VĂN HÒA </b>
<b>PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP </b>
<b>VÀ RÀNG BUỘC OCL </b>
<b>LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM </b>
<b>HÀ NỘI – 2016 </b>
</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2"><b>TRƯỜNG ĐẠI HỌC CƠNG NGHỆ </b>
<b>NGUYỄN VĂN HỊA </b>
<b>PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP </b>
</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3"><b>UNIVERSITY OF ENGINEERING TECHNOLOGY </b>
<b>NGUYEN VAN HOA </b>
<b>A METHOD AND TOOL SUPPORTING FOR AUTOMATED TESTING FROM UML SEQUENCE DIAGRAMS, CLASS </b>
<b>DIAGRAMS AND OCL CONSTRAINS </b>
<b>THE MS. THESIS INFORMATION TECHNOLOGY Supervisor: Assoc. Prof., PHAM NGOC HUNG, PhD </b>
<b>HÀ NỘI – 2016 </b>
</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4"><b>LỜI CẢM ƠN </b>
Đầu tiên, tôi xin gửi lời cảm ơn chân thành và sâu sắc tới thầy Phạm Ngọc Hùng – Người đã trực tiếp hướng dẫn nhiệt tình, giúp đỡ và động viên tơi rất nhiều, cho tơi có cơ hội được tiếp xúc với các tài liệu tham khảo q giá, góp ý cho tơi những lời khun chân thành trong q trình nghiên cứu để hồn thành đề tài này.
Tiếp theo tôi xin gửi lời cảm ơn đến các thầy cô giảng viên Trường Đại học Công Nghệ - Đại học Quốc Gia Hà Nội – những người đã tận tâm truyền đạt những kiến thức quý báu làm nền tảng cho tôi suốt 2 năm học.
Cuối cùng, tôi xin gửi lời biết ơn sâu sắc tới gia đình vì đã luôn ở bên cạnh tôi, mang lại cho tôi nguồn động viên tinh thần to lớn và tạo mọi điều kiện thuận lợi cho tơi trong q trình học tập và hồn thành luận văn này.
Với luận văn này tơi rất mong nhận được ý kiến đóng góp từ Thầy, Cơ giáo và các bạn quan tâm để hồn thiện và phát triển nhiều hơn về các phương pháp mới trong kiểm
</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5"><b>TÓM TẮT </b>
Luận văn này trình bày một phương pháp nghiên cứu tự động hóa q trình kiểm thử dự án phần mềm từ biểu đồ tuần tự UML 2.0. Hướng nghiên cứu dựa trên lý thuyết kiểm thử dựa trên mơ hình. Mục tiêu đề ra là tự động hóa quá trình kiểm thử, nâng cao hiệu quả kiểm thử, tiết kiệm chi phí và thời gian phát triển dự án. Phương pháp được đề xuất với nội dung chính như sau. Đầu vào là biểu đồ tuần tự UML 2.0 lưu giữ dưới dạng tệp xmi. Chương trình kiểm thử biến đổi tệp xmi bằng cách bóc tách các thơng điệp, tốn tử và các ràng buộc được đưa vào trong thiết kế, từ đó vẽ đồ thị dòng điều khiển tương ứng. Từ đồ thị dịng điều khiển sử dụng thuật tốn dị tìm, thuật tốn sinh ca kiểm thử cho các tốn tử song song có các điểm chia sẻ dữ liệu tìm ra các đường đi từ điểm bắt đầu cho tới điểm kết thúc gọi là các đường kiểm thử. Tập các đường kiểm thử được chia tương ứng thành 3 cấp độ kiểm thử khác nhau. Các ràng buộc trên mỗi đường đi được thu thập và giải lấy kết quả dựa trên công cụ SMT solver kết hợp phương pháp sinh ngẫu nhiên. Kết quả thu được sau khi giải hệ chính là đầu vào cho các ca kiểm thử tương ứng. Cuối cùng trích xuất ra tệp excel là các ca kiểm thử theo từng độ bao phủ dùng cho kiểm thử thiết kế. Để kiểm nghiệm mức độ khả thi của phương pháp, một công cụ hỗ trợ đã được cài đặt và thử nghiệm với một số ví dụ đơn giản nhằm minh chứng cho tính đúng đắn và hiệu quả của phương pháp trên. Kết quả thực nghiệm cho thấy hiệu quả của các ca kiểm thử cũng là khả quan để áp dụng cho các công ty phát triển phần mềm.
<b>Từ khóa: Kiểm thử dựa trên mơ hình, kiểm thử tự động, biểu đồ tuần tự, đồ thị </b>
dòng điều khiển, kiểm thử luồng song song, kiểm thử có chia sẻ dữ liệu luồng song song.
</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6"><b>ABSTRACT </b>
The content of this thesis is research and propose a method to generate a set of test cases from the UML 2.0 Sequence diagrams. Based on model-based testing in order to automate the testing process, increase effectiveness, reduce cost and time of testing. The method follows the following steps. At first, in order to have the input model for testing, it analyzes and divides the input diagram into fragments. These fragments can be Sequential or nested based on their relationship. After that, it generates the corresponding control flow graph for the input Sequence diagram. The final control flow graph is analyzed to generate a set of testing paths. Symbolic Execution (SE) technique is used to create reStrictions associated with that set of testing paths. Finally, the method uses SMT solver to solve the set of reStrictions to find solution and then to generate a set of test cases. A tool is also implemented and tested with some simple examples in order to show the correctness and effectiveness of the method. The experimental results give us the potential application of the tool in automation testing in companies.
<b>Keywords: Model base testing, automated testing, Sequence diagram, control flow </b>
testing, Parallel threading testing, threading testing with data shared.
</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7"><b>LỜI CAM ĐOAN </b>
Tôi xin cam đoan rằng những nghiên cứu về sinh tự động bộ kiểm thử từ biểu đồ tuần tự được trình bày trong luận văn này dưới sự hướng dẫn của thầy Phạm Ngọc Hùng là của tơi. Những gì tôi viết ra không sao chép từ các tài liệu, không sử dụng các kết quả của người khác mà khơng trích dẫn cụ thể.
Tôi xin cam đoan công cụ kiểm thử tự động tơi trình bày trong luận văn là do tơi tự phát triển, không sao chép mã nguồn của người khác. Nếu sai tơi hồn tồn chịu trách nhiệm theo quy định của Trường Đại học Công Nghệ - Đại học Quốc Gia Hà Nội.
</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">Chương 1: GIỚI THIỆU ... 1
Chương 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MƠ HÌNH . 3 2.1 Quy trình chung của kiểm thử dựa trên mơ hình ... 3
2.2 Đồ thị dòng điều khiển ... 4
2.3 Các độ đo kiểm thử ... 5
Chương 3: PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN TỰ ... 7
3.1 Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dịng điều khiển ... 7
3.1.1. Thuật tốn sinh đồ thị dòng điều khiển ... 7
3.1.2. Đồ thị dòng điều khiển tương ứng với các phân đoạn ... 13
3.2 Kỹ thuật sinh kịch bản kiểm thử ... 21
3.2.1. Kịch bản kiểm thử cho các tốn từ thơng thường ... 21
3.2.2. Kịch bản kiểm thử cho các phân đoạn song song (Par, Seq) ... 26
3.3 Xây dựng hệ ràng buộc ... 28
3.4 Giải hệ sử dụng SMT-Solver ... 29
Chương 4: CÔNG CỤ VÀ THỰC NGHIỆM ... 31
4.1 Giới thiệu công cụ và môi trường thực nghiệm ... 31
4.2 Thực nghiệm ... 33
</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">4.3 Ý nghĩa thực nghiệm ... 37 Chương 5: KẾT LUẬN ... 39 TÀI LIỆU THAM KHẢO ... 41
</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10"><b>DANH SÁCH BẢNG BIỂU </b>
ảng 2.1 Ca kiểm thử độ bao phủ yếu ... 6
ảng 2.2 Ca kiểm thử độ bao phủ trung bình... 6
ảng 2.3 Ca kiểm thử độ bao phủ mạnh ... 6
ảng 3.1 Các khóa cơ bản và ý nghĩa trong tệp xmi ... 7
ảng 3.2 Dữ liệu thu thập tương ứng theo các nốt được nối với nhau ... 23
ảng 4.1 Môi trường thử nghiệm công cụ sinh ca kiểm thử từ thiết kế ... 32
</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11"><b>DANH SÁCH HÌNH VẼ </b>
Hình 2.1 Qui trình kiểm thử dựa trên mơ hình. ... 3
Hình 2.2 Đồ thị dịng điều khiển tương ứng của phân đoạn Par. ... 5
Hình 3.1 Đồ thị CFG tương ứng cho phân đoạn Alt. ... 15
Hình 3.2 Đồ thị CFG tương ứng cho phân đoạn Opt. ... 15
Hình 3.3 Đồ thị CFG tương ứng cho phân đoạn Loop. ... 16
Hình 3.4 Đồ thị CFG tương ứng cho phân đoạn Break. ... 16
Hình 3.5 Đồ thị CFG tương ứng cho phân đoạn Par. ... 16
Hình 3.6 Đồ thị CFG tương ứng cho phân đoạn Seq. ... 17
Hình 3.7 Đồ thị CFG tương ứng cho phân đoạn Ignore. ... 18
Hình 3.8 Đồ thị CFG tương ứng cho phân đoạn Consider. ... 18
Hình 3.9 Đồ thị CFG tương ứng cho phân đoạn Neg. ... 19
Hình 3.10 Đồ thị CFG tương ứng cho phân đoạn Assert. ... 20
Hình 3.11 Đồ thị CFG tương ứng cho phân đoạn Strict. ... 20
Hình 3.12 Ví dụ cây đồ thị cần duyệt. ... 22
Hình 3.13 Đồ thị dịng điều khiển. ... 23
Hình 3.14 Ví dụ về ràng buộc OCL được khai báo trong thiết kế. ... 29
Hình 3.15 Mơ tả cơng cụ SMT Solver ... 30
Hình 4.1 Cấu trúc cơng cụ thực nghiệm. ... 31
Hình 4.2 Đầu vào của ví dụ 1. ... 34
Hình 4.3 Đầu ra đồ thị CFG cho ví dụ 1. ... 35
Hình 4.4 Ca kiểm thử độ bao phủ yếu cho ví dụ 1. ... 35
Hình 4.5 Ca kiểm thử độ bao phủ trung bình cho ví dụ 1. ... 36
Hình 4.6 Ca kiểm thử độ bao phủ mạnh cho ví dụ 1. ... 36
Hình 4.7 Đường đi tương ứng của một ca kiểm thử độ bao phủ mạnh của ví dụ 1. ... 37
</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12"><b>BẢNG THUẬT NGỮ VIẾT TẮT </b>
2 CFG Control Flow Graph Đồ thị dòng điều khiển
</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13"><b>Chương 1: GIỚI THIỆU </b>
Công nghệ phần mềm đang ngày càng phát triển và chi phối cuộc sống của con người. Ngược lại, con người luôn không ngừng sáng tạo để tạo ra những công nghệ mới, phần mềm và dịch vụ mới. Trong q trình phát triển đó, cần phải có một qui trình song song để phát hiện và kiểm sốt những sai lầm mà con người có thể vơ tình hoặc cố tình tạo ra, đó chính là kiểm thử. Theo ước tính, q trình kiểm thử chiếm khoảng 50% thời gian và 40% - 60% tổng chi phí trong tồn bộ q trình phát triển phần mềm [1]. Quá trình kiểm thử cũng quyết định sự thành công, mức độ đảm bảo của dự án phần mềm đặc biệt là trong các lĩnh vực đòi hỏi độ chính xác cao như hàng khơng, qn sự, khoa học, vũ trụ.. Vì vậy, để rút ngắn thời gian phát triển và nâng cao chất lượng dự án phần mềm, quá trình sinh ca kiểm thử tự động và nâng cao chất lượng ca kiểm thử trở nên thực sự cần thiết, nhất là đối với những phần mềm lớn và phức tạp. Kiểm thử tự động đang được xem là giải pháp chính nhằm giảm chi phí và thời gian mà vẫn đảm bảo chất lượng trong quá trình phát triển phần mềm. Để giải quyết vấn đề này, nhiều cơng trình nghiên cứu đã được đề xuất nhằm giải quyết, tối ưu và tự động hóa q trình kiểm thử. Mỗi cơng trình nghiên cứu mang lại một kết quả khác nhau và áp dụng cho từng mục đích kiểm thử khác nhau. Một số nghiên cứu có thể kể đến như: phương pháp sinh ca kiểm thử tự động từ biểu đồ tuần tự trong UML bởi A.V.K. Shanthi và G. Mohan Kumar [5]. Sinh dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML và ràng buộc OCL bởi Ashalatha Nayak và Debasis Samanta [4]. Sinh ca kiểm thử từ biểu đồ tuần tự và hệ thống chuyển đổi được gắn nhãn bởi Emanuela G. Cartaxo [7]. Sinh ca kiểm thử tự động từ biểu đồ tuần tự UML và ràng buộc OCL bởi Li Bao-Lin, Li Zhi-shu, Li Qing và Chen Yan Hong [10], v.v. Trong đó một số nghiên cứu mới chỉ dừng lại ở dạng đề xuất, nhiều nghiên cứu khác chưa giải quyết trọn vẹn bài toán kiểm thử trực tiếp từ biểu đồ tuần tự từ một phần mềm cụ thể. Mỗi phương pháp hướng tới một mục đích kiểm thử khác nhau. Để hiểu rõ hơn một vài nghiên cứu trên sẽ được trình bày chi tiết hơn ở chương ba của luận văn.
Bài nghiên cứu này tôi sẽ trình bày một phương pháp khác 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 kiểm thử. Cũng như các phương pháp kiểm thử dựa trên mơ hình khác, phương pháp này địi hỏi phải có các mơ hình tốn học đặc tả chính xác hành vi của hệ thống và có sẵn trong thực tế. Các mơ hình này thường được biểu diễn bằng các máy hữu hạn trạng thái đơn định. Tuy nhiên, xây dựng mơ hình cho các phần mềm là một cơng việc khó khăn và tiềm ẩn nhiều lỗi đối với các công ty. Thay vào đó việc 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à trở nên 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ế cho kiểm thử dự án phần mềm. Không những tự động hóa được qui trình kiểm thử mà thời
</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">gian bắt đầu kiểm thử cũng được tiến hành sớm hơn giúp rút ngắn thời gian phát triển phần mềm.
Giai đoạn kiểm thử thiết kế (kiểm thử dựa trên mơ hình) chủ yếu 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. Với mục tiêu kiểm thử phần mềm dựa trên thiết kế của biểu đồ tuần tự, mục tiêu nâng cao chất lượng kiểm thử cũng như khả năng phát hiện lỗi của các kịch bản kiểm thử trong thiết kế và khi chương trình được thực thi. Nội dung bài nghiên cứu này được trình bày trong 4 chương và phần kết luận.
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 tố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.
</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15"><b>Chương 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MƠ HÌNH </b>
<b>2.1 Quy trình chung của kiểm thử dựa trên mơ hình </b>
Mơ hình UML được thiết kế từ các đặc tả 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.v.
Hình 2.1 Qui trình kiểm thử dựa trên mơ hình.
Hình 2.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].
</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16"><b>2.2 Đồ thị dòng điều khiển </b>
Đồ 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]:
<b> Nốt bắt đầu (Start node): là nốt khởi đầu của đồ thị. </b>
<b> 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 </b>
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.
<b> Nốt quyết định (DC – Decision node): là nốt biểu thị cho một hàm điều kiện như </b>
đ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.
<b> Nốt sáp nhập (MN – Merge node): là nốt biểu thị cho sự sáp nhập các nhánh ra từ </b>
một hành vi lựa chọn (chẳng hạn như lối ra từ một phân đoạn ALT hoặc OPT).
<b> 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 </b>
SEQ.
<b> 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 </b>
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 <sub> </sub> <i> A được đề xuất như sau: < nodeId, nodeType, nodeDetails, </i>
<i>outEdge > với: </i>
<i> nodeId: là nhãn duy nhất được đính kèm vào mỗi nốt. </i>
<i> nodeType = {decision, merge, fork, join} với mỗi </i> và
<i>nodeType = {block, initial, final} cho tất cả các nốt còn lại. </i>
<i> nodeDetails = { </i> ,..., | q là số của một tin nhắn trong BN}. Mỗi
<i>nodeDetails được định nghĩa là một bộ ba < m, s, r > với mỗi bản tin xác định </i>
</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">đượ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
<i>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. Ngồi ra, một </i>
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
<i>tin ràng buộc từ biểu đồ lớp và có cấu trúc < name, type, value, constraint > với </i>
<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ị </i>
<i>được gán. Còn constraint được lấy từ ràng buộc OLC được khai báo từ các thuộc </i>
tính biểu đồ lớp hoặc đã được đính kèm vào biểu đồ tuần tự.
<i> outEdge = { ,…, </i> | q là số cạnh nối}. Mỗi được xác định bằng < sourceNode, targetNode > [13].
<b>2.3 Các độ đo kiểm thử </b>
Độ đ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.16.
</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">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:
<b> ng 2.1 Ca kiểm thử độ bao phủ yếu </b>
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:
<b> ng 2.2 Ca kiểm thử độ bao phủ trung bình </b>
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 hốn đổi vị trí để tạo ra các đường kiểm thử phủ được nhiều
Với ví dụ Hình 2.16, ngồ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.3. Ngồ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.3.
</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19"><b>Chương 3: PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN TỰ </b>
<b>3.1 Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển </b>
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 tn 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 tốn tử và thành phần đó. Thuật tố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ế.
<b>3.1.1. Thuật toán sinh đồ thị dòng điều khiển </b>
Đầu vào của thuật tố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 tố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ự. Bảng 3.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.
ảng 3.1 Các khóa cơ bản và ý nghĩa trong tệp xmi
<constraints> ắt đầu khai báo các ràng buộc (OCL) trong biểu đồ </constraints> Kết thúc khai báo các ràng buộc trong biểu đồ
<fragment ắt đầu một phân đoạn </fragment> Kết thúc một phân đoạn <lifeline ắt đầu trục thời gian <message ắt đầu một thông điệp </message> Kết thúc một thông điệp
<operand ắt đầu khai báo các toán tử bên trong phân đoạn </operand> Kết thúc khai báo các toán tử bên trong phân đoạn
Cấu trúc dữ liệu của biểu đồ tuần tự là một mảng các phần tử bao gồm thơng điệp, phân đoạn và tốn hạng và tất cả các phần tử này được sắp xếp theo trình tự thời gian.
</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">Thuật tốn phân tích lần lượt từng phần tử trong hàng đợi và trả về các nốt khác nhau. Bắt
<i>đầu từ nốt khởi đầu in – được xem là nốt hiện tại (curNode), mỗi phần tử của hàng đợi sẽ được đọc bởi câu lệnh (queue.pop()). Tùy thuộc vào số lượng phần tử trong hàng đợi, </i>
thuật toán này sẽ được gọi trả về là BN, DN, MN, FN và JN.
Thuật toán 1 biểu diễn các bước sinh đồ thị CFG từ biểu đồ tuần tự là tệp xmi. Các bước thực hiện như sau:
Tạo nốt bắt đầu, đặt nốt bắt đầu là nốt bắt đầu duyệt là curPos.
Khởi tạo hàng đợi (rỗng).
Đọc từng phần tử từ tệp xmi và thêm vào hàng đợi rồi chuyển sang phần tử tiếp theo. Quá trình đọc tệp xmi được lặp lại cho tới khi kết thúc.
<b>Thuật toán 1: Sinh đồ thị CFG </b>
<b>Đầu vào: Biểu đồ tuần tự D (tệp xmi trích xuất từ phần mềm Enterprise Architect) Đầu ra: Đồ thị G: (A, E, in, F) với: A là tập các nốt (BN, DN, MN, FN, JN); </b>
<i>in là nốt khởi tạo, F là nốt kết thúc; E là tập các cạnh trong đồ thị CFG, </i>
E ={(x, y) | x, y A F}.
<i>1: create initial node in, node x; 2: create empty queue; </i>
<i>3: create curPos point at start element of sequence diagram D in xmi; </i>
<b>4: repeat </b>
5: <i>curPos read each element of D to add to queue </i>
6: <i>curPos move to next Element; </i>
<i><b>7: until curPos meets end element of xmi file </b></i>
<i>8: x = processElement(queue, in); // thuật toán 2 </i>
<i><b>9: if x ≠ finalNode then </b></i>
10: <i>create final Node fn F; </i>
11: <i>Connect edge from x to fn; </i>
<b>12: end if 13: return G; </b>
</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21"> Hàng đợi thu thập được và nốt bắt đầu được đưa vào thuật toán 2 để sinh các nốt tương ứng theo thiết kế và lý thuyết chuyển đổi.
Khởi tạo nốt kết thúc, nối các cạnh giữa các nốt kế tiếp nhau thu được đồ thị CFG hoàn chỉnh.
</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22"><b>Thuật tốn 2: Phân tích các phần tử trong hàng đợi queue (processElement). [3] Đầu vào: queue: hàng đợi chứa thông tin các phân đoạn, thông điệp và ràng buộc </b>
OCL, curNode A (nốt bắt đầu), Sequence Diagram: D
<i><b>Đầu ra: exitNode A, CFG </b></i>
<b>1: while (queue != empty) do </b>
8: BN=CreateBlockNode() //BN is message or a set of message 9: <b>for each message m </b>
<b>10: begin </b>
11: get receiver class in r.className 12: msg=returnMsgStructure(D, m)
13: attr=returnAttributeStructure(D, OCL_Contraint) 14: <b>for all variables in m </b>
15: <b>attachAttributeInfor(attr,m); //attach constraint c[i] to msg </b>
</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">29: isAsynToBN() //attach isAsyn toBN with 30: messages of operands having sharing data
<b>31: else if (x== fragment) and (x.type=='ignore') then </b>
41: <b>if (message from inside linelife) </b>
42: Create BN to the first branch;
43: <b>else if (message from outside linelife) </b>
44: Create BN to the second branch;
<b>45: else if (x== fragment) and (x.type=='assert') then 46: if(message.attribute==x.attribute) </b>
<b>47: </b> Create BN to coressponding msg;
<b>48: else if (x== fragment) and (x.type=='break') then 49: if (curNode inside a fragment) </b>
<b>50: </b> Exit current fragment;
</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">Thuật toán 2 với đầu vào là nốt bắt đầu và hàng đợi chứa thông tin các thông điệp thu thập được từ tệp xmi thông qua thuật toán 1. Đầu ra là đồ thị CFG tương ứng với thiết kế. Nguyên tắt hoạt động của thuật toán 2 như sau:
Đọc từng phần tử trong hàng đợi, nếu gặp thơng điệp thì tạo một nốt đơn N.
Nếu gặp một phân đoạn, kiểm tra xem đó là phân đoạn nào. o Nếu gặp opt, alt, loop: tạo nốt quyết định DC.
o Nếu gặp par, seq: tạo nốt rẽ nhánh FN.
o Nếu gặp ignore: bỏ qua các thông điệp thỏa mãn điều kiện phân đoạn ignore.
o Nếu gặp consider: chỉ xem xét các thộng điệp thỏa mãn điều kiện phân đoạn consider.
51: <b>else jump to exitNode; </b>
<b>52: else if (x=='EOF' and x.type=='alt' or 'opt') then //termination condition of frag alt </b>
or opt
53: Create merge node MN 54: ConnectEdge(curNode,MN); 55: exitNode =MN;
<b>56: else if (x=='EOF' and x.type=='par' or 'seq' or ‘neg’) then </b>
57: <b>Create join node JN </b>
58: ConnectEdge(curNode,JN); 59: exitNode =JN;
<b>60: else if (x=='EOF' and x.type=='loop') then </b>
61: attachLoopstoEdge() //attach number of loops to Edge
</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">o Nếu gặp neg: tạo nốt rẽ nhánh FN, tiếp tục kiểm tra các thông điệp nằm trong phân đoạn neg. Nếu thông điệp nào xuất phát từ các trục thời gian bên trong phân đoạn, thêm vào nhánh thứ nhất. Nếu thông điệp nào xuất phát từ các trục thời gian bên ngoài phân đoạn, thêm vào nhánh thứ 2. Điều này thỏa mãn nếu hai thơng điệp là trái ngược nhau thì sẽ khơng bao giờ sảy ra đồng thời trong cùng một ca sử dụng.
o Nếu gặp assert: chỉ kiểm tra các thông điệp thỏa mãn điều kiện phân đoạn assert. Các thông điệp khác bỏ qua cho tới khi thoát khỏi phân đoạn hiện tại. o Nếu gặp break: thoát khỏi phân đoạn hiện tại hoặc nhảy về nốt kết thúc nếu
đang không ở trong một phân đoạn nào cả.
Nếu gặp EOF (End Of Fragment): kiểm tra phân đoạn đang xử lý:
o Nếu là EOF của phân đoạn par, seq hoặc neg: tạo một nốt FN và liên kết tất cả các nhánh.
o Nếu là EOF của loop: nốt kết thúc của phân đoạn là nốt quyết định của vịng lặp.
Q trình xử lý các phân đoạn được thực hiện đệ qui lồng vào nhau để đảm bảo tính đúng đắn khi các phân đoạn thiết kế lồng nhau. Thuật toán kết thúc khi tất cả các phần tử trong hàng đợi được duyệt xong.
<b>3.1.2. Đồ thị dòng điều khiển tương ứng với các phân đoạn </b>
Sau khi áp dụng thuật toán biến đổi sinh đồ thị dòng điều khiển ta thu được kết quả tương ứng đối với từng phân đoạn như sau:
<b>Biến đổi tương ứng đối với phân đoạn Alt: Phân đoạn Alt đại diện cho một toán </b>
tử lựa chọn. Trong lập trình, phân đoạn Alt được hiểu như một hàm “if-else”. Vì vậy, trên biểu đồ CFG phân đoạn Alt là một nốt rẽ nhánh DC và kết thúc bởi nốt JN. Sau nốt rẽ nhánh của phân đoạn Alt có thể bao gồm hai hay nhiều nhánh khác nhau tùy thuộc vào cấu trúc cũng như thiết kế của phân đoạn Alt trên biểu đồ tuần tự. Hình 3.1 biễu diễn mơ hình biến đổi tương ứng của phân đoạn Alt sang đồ thị CFG.
<b>Biến đổi tương ứng đối với phân đoạn Opt: Phân đoạn Opt đại diện cho một </b>
toán tử lựa chọn khác nhưng chỉ nhận giá trị đúng. Trong lập trình, phân đoạn Opt được hiểu như một hàm kiểm tra hoặc hàm “if” chỉ nhận một giá trị đúng. Ngược lại thì khơng làm gì cả và chuyển sang nốt tiếp theo. Vì vậy thiết kế của phân đoạn Opt trên đồ thị CFG là một nốt quyết định DC nhưng chỉ có hai nhanh trong đó một nhánh đúng cho phép thực hiện các thông điệp tiếp theo, nhánh cịn lại khơng làm gì cả (bỏ qua các thơng điệp trong phân đoạn Opt). Hình 3.2 biễu diễn mơ hình biến đổi tương ứng của phân đoạn Opt sang đồ thị CFG.
</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26"><b>Biến đổi tương ứng đối với phân đoạn Loop: Phân đoạn Loop đại diện cho một </b>
vòng lặp và kiểm tra giá trị tại nốt điều kiện lặp. Trong lặp trình phân đoạn Loop tương ứng với các vòng lặp “while, for, repeat, v.v”. Tất cả các phương thức lặp đều có điều kiện lặp để giới hạn số vòng lặp. Vì vậy trong đồ thị CFG phân đoạn Loop cũng được biểu diễn bằng một nốt quyết định DC tuy nhiên khơng có JN ở cuối phân đoạn như Alt hay Opt. Mà nốt kết thúc phân đoạn Loop là chính nó để kiểm tra lại điều kiện lặp và chuyển sang nốt tiếp theo khi điều kiện lặp khơng cịn thỏa mãn. Hình 3.3 biễu diễn mơ hình biến đổi tương ứng của phân đoạn Loop sang đồ thị CFG. Việc sinh ca kiểm thử cho điều kiện vòng lặp là rất phức tạp bởi vì trong hầu hết các trường hợp điều kiện vòng lặp bị thay đổi, giá trị biến bên trong bị thay đổi sau mỗi lần thực hiện những câu lệnh trong vịng lặp.
Ví dụ vòng lặp for trong thiết kế ứng với đoạn mã nguồn sau: For (int i = 0; i < 10; i++) {
Từ mã nguồn ta thấy vòng lặp cho phép lặp tối đa 10 lần, sau mỗi lần lặp giá trị
<i>money bị thay đổi. Trong một số trường hợp vịng lặp có thể bị ngắt (khơng lặp đủ 10 lần) </i>
vì thoải mãn điều kiện bên trong. Những thay đổi này gây khó khăn trong việc xây dựng hệ và sinh dữ liệu kiểm thử sau khi đã có ca kiểm thử. Điều kiện lặp được đọc một lần và đưa đưa vào hệ để giải sinh dữ liệu kiểm thử, tuy nhiên nếu số lần lặp nhiều hơn một sẽ có tương ứng số ràng buộc phải đưa vào để giải hệ. Việc này là không thể thực thi khi chưa có mã nguồn. Đây cũng là một trong những nhược điểm của kiểm thử dựa trên mơ hình. Để giải quyết bài tốn này, tất cả các vịng lặp được qui ước số vòng lặp là một (khi sinh ca kiểm thử và dữ liệu kiểm thử).
<b>Biến đổi tương ứng đối với phân đoạn Break: Phân đoạn Break cho phép thốt </b>
ra khỏi vịng lặp hay các nốt quyết định khác đang thực thi tới nó và nhảy tới bước tiếp theo. Trong trường hợp phân đoạn Break khơng nằm trong phân đoạn nào thì nó sẽ nhảy tới nốt kết thúc. Trong lặp trình, phân đoạn reak có ý nghĩa tương tự với lệnh ngắt (break), tuy nhiên lệnh “break” trong lặp trình chỉ thường sử dụng để thốt ra một vịng
</div>
