Luận án TS: Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML
Luận án TS máy tính nghiên cứu kỹ thuật sinh tự động dữ liệu kiểm thử. Áp dụng biểu đồ UML để nâng cao chất lượng và hiệu quả kiểm thử phần mềm.
Công nghệ Thông tin
Luan An
Luận án
Năm xuất bản
Số trang
175
Thời gian đọc
27 phút
Lượt xem
0
Lượt tải
0
Phí lưu trữ
50 Point
Tóm tắt nội dung
I.Tối ưu hóa kiểm thử phần mềm với sinh dữ liệu tự động
Kiểm thử phần mềm là giai đoạn quan trọng, đảm bảo chất lượng hệ thống. Sinh dữ liệu kiểm thử thủ công tốn thời gian, dễ sai sót. Kỹ thuật sinh dữ liệu kiểm thử tự động giải quyết vấn đề này. Phương pháp tạo ra dữ liệu đầu vào cần thiết, mục tiêu kiểm thử các chức năng, luồng nghiệp vụ. Tự động hóa kiểm thử giúp tăng hiệu quả, giảm chi phí kiểm thử, nâng cao độ tin cậy của phần mềm. Tài liệu này khám phá các kỹ thuật đó, tập trung vào việc tạo dữ liệu kiểm thử từ biểu đồ UML. Đây là một bước tiến quan trọng trong tự động hóa kiểm thử. Giúp hệ thống đạt chất lượng cao nhất.
1.1. Giới thiệu về sinh dữ liệu kiểm thử tự động
Sinh dữ liệu kiểm thử tự động là quá trình tạo ra các bộ dữ liệu đầu vào. Chúng được sử dụng để kiểm tra phần mềm mà không cần sự can thiệp thủ công. Kỹ thuật này giúp phát hiện lỗi sớm. Đảm bảo hệ thống hoạt động đúng như yêu cầu. Việc sinh dữ liệu kiểm thử từ mô hình như biểu đồ UML đang trở nên phổ biến. Nó tận dụng thông tin thiết kế để tạo ra các kịch bản kiểm thử toàn diện. Phương pháp này đóng vai trò then chốt trong kiểm thử phần mềm hiện đại. Góp phần vào sự phát triển nhanh chóng của các dự án.
1.2. Lợi ích của tự động hóa sinh dữ liệu kiểm thử
Tự động hóa sinh dữ liệu kiểm thử mang lại nhiều lợi ích. Tăng tốc độ phát triển dự án. Cải thiện đáng kể chất lượng sản phẩm. Giúp phát hiện lỗi sớm hơn, đảm bảo các kịch bản kiểm thử được bao phủ đầy đủ. Phương pháp loại bỏ sự lặp lại, nhàm chán của công việc thủ công. Giảm thiểu lỗi do con người gây ra. Tự động hóa hỗ trợ thực hiện kiểm thử hộp đen hiệu quả. Đặc biệt hữu ích trong các hệ thống phức tạp. Công cụ sinh dữ liệu kiểm thử giảm tải công việc cho kiểm thử viên. Cho phép họ tập trung vào các vấn đề phức tạp hơn. Đảm bảo nguồn lực được tối ưu.
II.Kiểm thử dựa mô hình MBT và vai trò biểu đồ UML
Kiểm thử dựa mô hình (MBT) đang cách mạng hóa cách tiếp cận kiểm thử phần mềm. Phương pháp này sử dụng mô hình hệ thống để sinh ra các ca kiểm thử tự động. Mô hình hóa phần mềm giúp hiểu rõ hành vi hệ thống, giảm công sức thiết kế ca kiểm thử, cải thiện độ bao phủ kiểm thử. Đặc biệt hiệu quả khi hệ thống thay đổi liên tục. Mô hình thường được biểu diễn bằng biểu đồ UML, đây là ngôn ngữ mô hình hóa thống nhất. MBT tạo điều kiện cho tự động hóa kiểm thử từ giai đoạn đầu phát triển. Quá trình này bắt đầu từ việc phân tích yêu cầu một cách kỹ lưỡng. MBT tối ưu hóa quy trình kiểm thử.
2.1. Khái niệm kiểm thử dựa mô hình MBT
Kiểm thử dựa mô hình (MBT) là phương pháp tạo các ca kiểm thử từ một mô hình trừu tượng. Mô hình này mô tả hành vi mong muốn của hệ thống. Thay vì viết ca kiểm thử thủ công, MBT sinh ca kiểm thử tự động. Điều này giúp giảm đáng kể thời gian và công sức. MBT tăng cường độ bao phủ kiểm thử, đảm bảo các phần quan trọng của hệ thống được kiểm tra. Đây là một phần quan trọng của chiến lược tự động hóa kiểm thử hiện đại. MBT giúp phát hiện lỗi sớm hơn trong chu trình phát triển. Tăng cường chất lượng phần mềm tổng thể.
2.2. Biểu đồ UML và ràng buộc OCL trong MBT
Biểu đồ UML cung cấp các công cụ mạnh mẽ để mô tả cấu trúc và hành vi của hệ thống. Biểu đồ tuân tự UML đặc biệt hữu ích cho sinh dữ liệu kiểm thử tự động. Chúng mô tả luồng tương tác giữa các đối tượng. Ràng buộc OCL (Object Constraint Language) bổ sung thông tin chi tiết. OCL định nghĩa các điều kiện và bất biến cho mô hình UML. Các ràng buộc này là đầu vào quan trọng giúp tạo dữ liệu kiểm thử chính xác. Dữ liệu kiểm thử phải thỏa mãn các điều kiện này. OCL giúp kiểm thử viên xác định phạm vi kiểm thử. Đảm bảo dữ liệu tạo ra hợp lệ và có ý nghĩa.
2.3. Chuyển đổi mô hình UML thành đồ thị điều khiển
Một bước thiết yếu trong MBT là chuyển đổi mô hình. Biểu đồ UML được chuyển thành các đồ thị điều khiển (Control Flow Graph - CFG). CFG biểu diễn tất cả các đường dẫn thực thi có thể trong hệ thống. Các đường dẫn này có thể được kiểm thử một cách có hệ thống. Việc chuyển đổi này tạo cơ sở cho thuật toán sinh dữ liệu kiểm thử. Các thuật toán khám phá các đường dẫn này. Sau đó tạo ra các kịch bản kiểm thử khác nhau. Đây là nền tảng để tạo dữ liệu kiểm thử từ mô hình. Quá trình này hỗ trợ việc sinh kịch bản kiểm thử tự động và hiệu quả.
III.Kỹ thuật sinh dữ liệu kiểm thử cho các kiểu dữ liệu
Việc sinh dữ liệu kiểm thử tự động đòi hỏi xử lý nhiều kiểu dữ liệu khác nhau. Bao gồm kiểu số, kiểu cấu trúc động, kiểu chuỗi, và các cấu trúc vòng lặp. Mỗi kiểu dữ liệu đặt ra những thách thức riêng biệt. Các kỹ thuật cần được phát triển để tạo ra dữ liệu hợp lệ và có khả năng gây lỗi. Điều này đảm bảo kiểm thử phần mềm toàn diện. Phương pháp đề xuất trong tài liệu tập trung vào việc chuyển đổi biểu đồ tuân tự UML. Biểu đồ được biến đổi thành đồ thị điều khiển. Sau đó sinh dữ liệu kiểm thử dựa trên các đường dẫn. Mục tiêu là bao phủ tối đa các trường hợp kiểm thử.
3.1. Sinh dữ liệu cho kiểu số và cấu trúc động
Đối với kiểu dữ liệu số, cần tạo các giá trị biên. Bao gồm giá trị dương, âm, không, và giá trị rất lớn/nhỏ. Việc này đảm bảo kiểm thử các trường hợp đặc biệt. Các cấu trúc dữ liệu động cũng cần được xem xét. Ví dụ: danh sách, cây, đồ thị. Dữ liệu phải đảm bảo tính hợp lệ theo ràng buộc. Đồng thời tạo ra các trường hợp kiểm thử đặc biệt. Phương pháp đề xuất chuyển đổi biểu đồ tuân tự UML thành CFG. Sau đó sinh dữ liệu kiểm thử cho các đường dẫn. Điều này giúp kiểm thử hệ thống con. Đảm bảo các trường hợp dữ liệu được bao phủ tốt.
3.2. Phương pháp chuyển đổi biểu đồ tuân tự UML
Tài liệu trình bày phương pháp chuyển đổi biểu đồ tuân tự UML thành đồ thị điều khiển (CFG). CFG này chứa thông tin về luồng điều khiển và các ràng buộc dữ liệu. Quá trình này bao gồm phân tích các toán tử. Ví dụ: toán tử tuần tự yếu (Weak Sequencing Fragment - Seq) và toán tử song song (Parallel Fragment - Par). Các toán tử này ảnh hưởng đến cấu trúc của CFG. Từ CFG, các đường dẫn kiểm thử được trích xuất. Sau đó, các hàm vị từ (predicate functions) được tạo. Hàm vị từ này chứa các ràng buộc OCL. Bộ giải ràng buộc sẽ giải các hàm vị từ để sinh dữ liệu kiểm thử. Điều này là cốt lõi của việc tạo dữ liệu kiểm thử từ mô hình.
IV.Sinh dữ liệu kiểm thử chuyên sâu cho vòng lặp chuỗi
Việc sinh dữ liệu kiểm thử cho các cấu trúc phức tạp như vòng lặp và chuỗi đòi hỏi kỹ thuật chuyên sâu. Cấu trúc vòng lặp là một thách thức lớn, cần bao phủ nhiều trường hợp để đảm bảo tính đúng đắn. Dữ liệu chuỗi cũng đặt ra các yêu cầu kiểm thử riêng biệt với các ràng buộc về độ dài và định dạng. Phương pháp tiếp cận cần phải linh hoạt để giải quyết những ràng buộc này một cách hiệu quả. Mục tiêu là tạo ra dữ liệu kiểm thử đa dạng, có khả năng phát hiện lỗi trong các kịch bản đặc biệt. Điều này giúp nâng cao chất lượng kiểm thử phần mềm đáng kể.
4.1. Sinh dữ liệu kiểm thử cho cấu trúc vòng lặp
Cấu trúc vòng lặp là một thách thức lớn trong kiểm thử phần mềm. Việc sinh dữ liệu kiểm thử cho vòng lặp cần bao phủ nhiều trường hợp quan trọng. Bao gồm vòng lặp không chạy lần nào, vòng lặp chạy một lần, và vòng lặp chạy nhiều lần. Cần xét đến các điều kiện thoát của vòng lặp. Các tiêu chuẩn độ bao phủ vòng lặp là rất quan trọng để đảm bảo tính đúng đắn. Phương pháp đề xuất tập trung vào độ bao phủ tương tranh và độ bao phủ vòng lặp. Điều này giúp đảm bảo tính đúng đắn của vòng lặp. Tránh các lỗi liên quan đến lặp vô hạn hoặc xử lý sai các trường hợp biên.
4.2. Giải quyết ràng buộc chuỗi trong sinh dữ liệu
Dữ liệu chuỗi đặt ra các yêu cầu kiểm thử riêng biệt. Ràng buộc chuỗi thường phức tạp, bao gồm độ dài chuỗi, định dạng chuỗi (regex), và các giá trị cụ thể. Kỹ thuật sinh dữ liệu kiểm thử phải giải quyết các ràng buộc này một cách hiệu quả. Cần sử dụng bộ giải ràng buộc (constraint solver) chuyên biệt. Bộ giải này phân tích các biểu thức chuỗi OCL. Sau đó tạo ra các chuỗi thỏa mãn các điều kiện. Điều này đảm bảo dữ liệu kiểm thử đa dạng. Bao phủ các trường hợp lỗi tiềm ẩn. Việc tự động hóa sinh dữ liệu cho chuỗi giúp kiểm thử hiệu quả các biểu mẫu, trường nhập liệu. Giảm thiểu lỗi bảo mật liên quan đến dữ liệu đầu vào.
V.Tự động hóa kiểm thử Độ bao phủ và phân tích đột biến
Tự động hóa kiểm thử không chỉ là việc thực hiện các ca kiểm thử nhanh hơn. Còn là đảm bảo rằng các ca kiểm thử đó có chất lượng cao và hiệu quả. Độ bao phủ kiểm thử là một chỉ số quan trọng. Nó cho biết mức độ các phần của hệ thống đã được kiểm tra. Phân tích đột biến là một kỹ thuật nâng cao. Kỹ thuật này đánh giá chất lượng của chính các ca kiểm thử. Hai khái niệm này kết hợp giúp tối ưu hóa quá trình kiểm thử. Đảm bảo rằng các nỗ lực tự động hóa mang lại giá trị thực sự. Góp phần vào một quy trình kiểm thử phần mềm mạnh mẽ.
5.1. Tiêu chuẩn độ bao phủ trong kiểm thử
Độ bao phủ là một chỉ số quan trọng trong tự động hóa kiểm thử. Cho biết mức độ các phần của mã nguồn hoặc mô hình đã được kiểm thử. Các tiêu chuẩn độ bao phủ khác nhau được sử dụng để đo lường. Ví dụ: độ bao phủ câu lệnh, độ bao phủ nhánh, độ bao phủ đường dẫn. Trong kiểm thử dựa mô hình (MBT), độ bao phủ tương tranh là một trọng tâm. Độ bao phủ tương tranh giúp đánh giá các tương tác đồng thời. Đảm bảo rằng tất cả các kịch bản quan trọng đều được kiểm thử. Việc này là nền tảng của tự động hóa kiểm thử hiệu quả. Đảm bảo chất lượng hệ thống.
5.2. Phân tích đột biến Mutation Analysis
Phân tích đột biến (Mutation Analysis) là một kỹ thuật mạnh mẽ. Được sử dụng để đánh giá chất lượng của các ca kiểm thử. Kỹ thuật này tạo ra các "đột biến" nhỏ trong mã nguồn hoặc trong mô hình. Sau đó, chạy các ca kiểm thử hiện có. Mục tiêu là phát hiện xem ca kiểm thử có thể "giết chết" các đột biến này không. Nếu ca kiểm thử không phát hiện được đột biến, ca kiểm thử đó yếu hoặc thiếu sót. Phân tích đột biến giúp tăng cường chất lượng bộ ca kiểm thử. Cải thiện hiệu quả của sinh dữ liệu kiểm thử tự động. Đặc biệt hữu ích trong việc đảm bảo độ mạnh của kiểm thử phần mềm.
VI.Công cụ ứng dụng sinh dữ liệu kiểm thử từ UML
Sự phát triển của kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML đã dẫn đến nhiều công cụ hỗ trợ. Các công cụ này đóng vai trò quan trọng trong việc chuyển đổi mô hình thiết kế thành các ca kiểm thử và dữ liệu kiểm thử cụ thể. Mặc dù có những tiến bộ, vẫn tồn tại thách thức trong việc xử lý các kiểu dữ liệu và ràng buộc phức tạp. Việc tìm kiếm và áp dụng các công cụ phù hợp là chìa khóa để tối ưu hóa quy trình kiểm thử phần mềm, đặc biệt trong bối cảnh kiểm thử hộp đen. Công cụ giúp đẩy nhanh chu trình phát triển sản phẩm.
6.1. Tổng quan các công cụ sinh dữ liệu hiện có
Hiện nay có nhiều công cụ hỗ trợ sinh dữ liệu kiểm thử. Một số công cụ tích hợp với các môi trường phát triển tích hợp (IDE). Một số khác chuyên biệt cho kiểm thử dựa mô hình (MBT). Các công cụ này thường hỗ trợ biểu đồ UML. Chúng giúp tự động hóa quá trình từ mô hình đến dữ liệu kiểm thử. Tuy nhiên, nhiều công cụ vẫn còn hạn chế. Đặc biệt trong việc xử lý các kiểu dữ liệu phức tạp. Hoặc các ràng buộc OCL phức tạp. Việc đánh giá và lựa chọn công cụ phù hợp là quan trọng. Công cụ phải phù hợp với nhu cầu cụ thể của dự án. Điều này giúp tối ưu hóa quá trình kiểm thử phần mềm.
6.2. Ứng dụng thực tiễn trong kiểm thử hộp đen
Kỹ thuật sinh dữ liệu kiểm thử từ biểu đồ UML có ứng dụng rộng rãi. Đặc biệt trong kiểm thử hộp đen (Black box testing). Kiểm thử hộp đen tập trung vào kiểm tra chức năng hệ thống. Không quan tâm đến cấu trúc bên trong mã nguồn. Biểu đồ UML cung cấp một mô tả hành vi cấp cao của hệ thống. Phù hợp cho việc tạo dữ liệu kiểm thử từ góc độ người dùng và yêu cầu nghiệp vụ. Dữ liệu tạo ra giúp kiểm tra các yêu cầu hệ thống một cách hiệu quả. Đảm bảo hệ thống hoạt động đúng như mong đợi. Các kịch bản kiểm thử được sinh tự động. Giúp giảm thời gian và công sức kiểm thử thủ công đáng kể.
Tải xuống file đầy đủ để xem toàn bộ nội dung
Tải đầy đủ (175 trang)Trích đoạn nội dung luận án
Tải xuống để đọc toàn bộC C Kß THU T SINH TÜ ¸NG DÚ LI U KI MTHÛDÜATR NC CBI U ˙UML VÔ THÀ O Th¡ng 04 n«m 2018 L˝IC MÌN Lu“n ¡n ÷æc thüc hi»n t⁄i Tr÷íng ⁄i håc Cæng ngh», ⁄i håc QuŁc gia H Nºi, d÷îi sü h÷îng d¤n cıa PGS. Tæi xin gßi líi c£m ìn ch¥n th nh v s¥u s›c nh§t tîi PGS. Nguy„n Vi»t H Bº mæn Cæng ngh» phƒn m•m, Khoa Cæng ngh» thæng tin, Tr÷íng ⁄i håc Cæng ngh». Ng÷íi thƒy t¥m huy‚t ¢ t“n t…nh h÷îng d¤n, ºng vi¶n kh‰ch l», d nh nhi•u thíi gian qu‰ b¡u ” ành h÷îng cho tæi trong qu¡ tr…nh tham gia khâa håc v ho n thi»n lu“n ¡n.
Tæi xin gßi líi c£m ìn ch¥n th nh tîi l¢nh ⁄o tr÷íng ⁄i håc Cæng ngh», l¢nh ⁄o Khoa Cæng ngh» thæng tin, c£m ìn c¡c çng nghi»p ¢ t⁄o i•u ki»n thu“n læi cho tæi trong qu¡ tr…nh l m lu“n ¡n. Tæi xin gßi líi c£m ìn ch¥n th nh tîi c¡c thƒy, cæ trong Bº mæn Cæng ngh» phƒn m•m, Khoa Cæng ngh» thæng tin, Tr÷íng ⁄i håc Cæng ngh», nhœng ng÷íi luæn h÷îng d¤n, ành h÷îng, gâp þ cho tæi trong qu¡ tr…nh vi‚t lu“n ¡n. CuŁi còng, tæi xin gßi líi c£m ìn s¥u s›c tîi gia …nh v b⁄n b–, nhœng ng÷íi ¢ luæn ıng hº v hØ træ tæi v• måi m°t ” tæi y¶n t¥m håc t“p, nghi¶n cøu, v ho n th nh lu“n ¡n. i L˝I CAM OAN Tæi xin cam oan: B£n lu“n ¡n tŁt nghi»p n y l cæng tr…nh nghi¶n cøu thüc sü cıa c¡ nh¥n.
C¡c k‚t qu£ ÷æc vi‚t chung vîi c¡c t¡c gi£ kh¡c •u ÷æc sü çng þ cıa c¡c çng t¡c gi£ tr÷îc khi ÷a v o lu“n ¡n. C¡c k‚t qu£ n¶u trong lu“n ¡n l trung thüc v ch÷a tłng ÷æc cæng bŁ d÷îi b§t cø h…nh thøc n o tr÷îc khi tr…nh, b£o v» v cæng nh“n bði Hºi çng ¡nh gi¡ lu“n ¡n tŁt nghi»p Ti‚n s¾ Cæng ngh» Thæng Tin. Mºt lƒn nœa, tæi xin khflng ành v• sü trung thüc cıa líi cam k‚t tr¶n. T¡c gi£: ii MÖC LÖC L˝IC MÌN i L˝I CAM OAN ii MÖC LÖC iii DANH MÖC C C THU T NGÚ V KÞ HI U vii DANH MÖC C C B NG ix DANHMÖCC CHNHV xi T´MT TLU N N xiii Ch÷ìng 1 GI˛I THI U 1 1.2 Ph÷ìng ph¡p v nºi dung nghi¶n cøu.
6 Ch÷ìng 2 KI NTHÙCN NT NG 7 2.2 Ki”m thß düa tr¶n mæ h…nh .3 C¡c bi”u ç UML v r ng buºc OCL .1 Bi”u ç tuƒn tü UML v c¡c to¡n tß .2 C¡c r ng buºc OCL trong c¡c bi”u ç UML .3 ç thà dÆng i•u khi”n .4 C¡c º bao phı v º ph¥n t‰ch ºt bi‚n trong ki”m thß .1 º bao phı t÷ìng tranh .2 º bao phı trong ki”m thß vÆng l°p .3 º ph¥n t‰ch ºt bi‚n .5 TŒng quan v• sinh dœ li»u ki”m thß tü ºng .1 Sinh dœ li»u ki”m thß trong ki”m thß c§u tróc .2 Sinh dœ li»u ki”m thß trong ki”m thß chøc n«ng .3 Sinh dœ li»u ki”m thß tü ºng tł c¡c bi”u ç UML .6 C¡c cæng cö sinh dœ li»u ki”m thß hi»n t⁄i. 34 Ch÷ìng 3 SINH DÚ LI U KI M THÛ CHO KI U DÚ LI U S¨ V C U TRÓC ¸NG 35 3.2 Nhœng nghi¶n cøu li¶n quan .3 Ph÷ìng ph¡p sinh dœ li»u ki”m thß cho bi‚n ki”u dœ li»u sŁ v c§u tróc ºng .1 TŒng quan v• ph÷ìng ph¡p • xu§t .2 Chuy”n Œi bi”u ç tuƒn tü UML th nh CFG .3 Sinh c¡c kàch b£n ki”m thß .4 Chån c¡c và tł v chuy”n th nh c¡c h m và tł .5 H m và tł vîi c¡c r ng buºc OCL .6 Sinh dœ li»u ki”m thß tł c¡c h m và tł .2 K‚t qu£ v ¡nh gi¡. 85 Ch÷ìng 4 SINH DÚ LI U KI M THÛ CHO V`NG L P V iv C C ÙNG DÖNG T×ÌNG TRANH 87 4.2 Nhœng nghi¶n cøu li¶n quan .3 Ph÷ìng ph¡p sinh dœ li»u ki”m thß theo c¡c º bao phı t÷ìng tranh v l°p .1 TŒng quan v• ph÷ìng ph¡p • xu§t .2 Sinh c¡c kàch b£n ki”m thß .3 Sinh dœ li»u ki”m thß .2 K‚t qu£ v ¡nh gi¡. 113 Ch÷ìng 5 SINH DÚ LI U KI M THÛ CHO KI U DÚ LI U CHUÉI 115 5.2 Nhœng nghi¶n cøu li¶n quan .3 Ph÷ìng ph¡p sinh tü ºng dœ li»u ki”m thß cho c¡c r ng buºc chuØi .1 TŒng quan v• ph÷ìng ph¡p • xu§t .2 Sinh c¡c kàch b£n ki”m thß .3 Gi£i c¡c r ng buºc chuØi .2 K‚t qu£ v ¡nh gi¡ .142 Ch÷ìng 6 K T LU N 144 6.1 C¡c k‚t qu£ ⁄t ÷æc cıa lu“n ¡n .2 H÷îng nghi¶n cøu ti‚p theo.
146 DANH MÖC C C C˘NG TR NH KHOA H¯C CÕA T C GI LI NQUAN NLU N N 148 T ILI UTHAMKH O 149 vi DANH MÖC C C THU T NGÚ V KÞ HI U T¶n thu“t ngœ ƒy ı Chœ vi‚t t›t Gi£i ngh¾a Breadth-first search BFS Thu“t to¡n t…m ki‚m theo chi•u rºng Black box testing Ki”m thß hºp en Control Flow Graph CFG ç thà dÆng i•u khi”n Constraint solver Bº gi£i r ng buºc Coverage criteria Ti¶u chu'n bao phı Dynamic Domain Reduction DDR Ph÷ìng ph¡p gi£m mi•n ºng Deadlock Khâa ch‚t Depth-first search DFS Thu“t to¡n t…m ki‚m theo chi•u s¥u Extended Finite State Machine EFSM M¡y hœu h⁄n trang th¡i mð rºng Finite State Machine FSM M¡y hœu h⁄n tr⁄ng th¡i Gray box testing Ki”m thß hºp x¡m Invariant B§t bi‚n Linear Temporal Logic LTL Logic thíi gian tuy‚n t‰nh Message Thæng i»p Model Checking Ki”m chøng mæ h…nh Mutation Score MS º o ºt bi‚n Object Constraint Language OCL Ngæn ngœ r ng buºc Łi t÷æng Parallel Fragment Par To¡n tß song song Post condition H“u i•u ki»n Pre condition Ti•n i•u ki»n Predicate Và tł Safety property Thuºc t‰nh an to n Satisfiable SAT Thäa m¢n Symbolic execution SE Thüc thi t÷æng tr÷ng Weak Sequencing Fragment Seq To¡n tß tuƒn tü y‚u vii T¶n thu“t ngœ ƒy ı Chœ vi‚t t›t Gi£i ngh¾a Satisfiability Modulo Theories SMT C¡c lþ thuy‚t mæ un v• t‰nh thäa ÷æc System Under Testing SUT H» thŁng ÷æc ki”m thß Test Case Ca ki”m thß Test Data Dœ li»u ki”m thß Test Scenario Kàch b£n ki”m thß Test Script M¢ ki”m thß d⁄ng °c t£ kàch b£n dòng ” tü ºng hâa Unified Modeling Language UML Ngæn ngœ mæ h…nh hâa thŁng nh§t Unsatisfiable UNSAT Khæng thäa m¢n Variable Assignment Graph VAG ç thà tham sŁ bi‚n White box testing Ki”m thß hºp tr›ng eXtensible Markup Language XML Ngæn ngœ ¡nh d§u mð rºng Z3-Str solver Bº gi£i Z3-Str viii DANH MÖC C C B NG 2.1 C¡c bi”u ç UML v sß döng ” mæ h…nh hâa cho ki”m thß [100] 30 3.1 B£ng gi¡ trà ch¥n lþ cho c¡c to¡n tß logic [3] .2 H m và tł cho c¡c to¡n tß logic trong OCL [3] .3 H m và tł cho c¡c to¡n tß quan h» OCL cho ki”u dœ li»u sŁ [3] .4 C¡c kàch b£n ki”m thß ÷æc sinh ra cıa m¡y b¡n h ng tü ºng .5 So s¡nh k‚t qu£ • xu§t v k‚t qu£ nghi¶n cøu trong [72] .6 Thüc nghi»m ÷a ra º bao phı c¡c ÷íng d¤n cıa ç thà cıa ph÷ìng ph¡p ÷a ra v ph÷ìng ph¡p ki”m thß ng¤u nhi¶n .7 K‚t qu£ thüc nghi»m so s¡nh ph÷ìng ph¡p • xu§t vîi ph÷ìng ph¡p [30] .1 K‚t qu£ MS sß döng cho tłng kàch b£n ki”m thß ÷æc sinh ra trong c¡ch ti‚p c“n [95] v Ph÷ìng ph¡p • xu§t .2 K‚t qu£ MS cıa ph÷ìng ph¡p • xu§t v ph÷ìng ph¡p ng¤u nhi¶n112 5.1 V‰ dö gi£i c¡c to¡n tß chuØi .2 C¡ch Z3 str thüc hi»n xß lþ c¡c r ng buºc chuØi trong B£ng 5.3 Ngœ ph¡p cıa c¡c r ng buºc trong Z3 str, mð rºng cho search v replaceAll so vîi [114] .4 ành ngh¾a cho Thu“t to¡n 5.6 Quy t›c gi£m sß döng gåi » quy .7 C¡c quy t›c ti•n xß lþ cho c¡c to¡n tß chuØi .8 So s¡nh kh£ n«ng t…m lØi cıa c¡c chøc n«ng trong c¡c øng döng .9 So s¡nh xß lþ c¡c to¡n tß chuØi v hi»u n«ng cıa SeqString vîi ph÷ìng ph¡p cıa nhâm T¡c gi£ Shoichiro [39]. 141 x DANHMÖCC CHNHV 1.1 C¡c nºi dung lu“n ¡n gi£i quy‚t trong b i to¡n ki”m thß düa tr¶n mæ h…nh.1 Quy tr…nh ki”m thß düa tr¶n mæ h…nh [100].2 V‰ dö bi”u ç tuƒn tü UML câ to¡n tß alt v opt.3 V‰ dö bi”u ç tuƒn tü UML câ to¡n tß loop v break.4 V‰ dö bi”u ç tuƒn tü UML câ to¡n tß par v seq.5 V‰ dö bi”u ç tuƒn tü UML câ to¡n tß strict v critical.6 V‰ dö bi”u ç tuƒn tü UML câ to¡n tß ignore v consider.7 V‰ dö bi”u ç tuƒn tü UML câ to¡n tß negative v assert.9 C¡c lo⁄i nót cıa ç thà dÆng i•u khi”n .10 C¡c h÷îng ti‚p c“n cıa sinh dœ li»u ki”m thß tü ºng [99].11 Ph¥n lo⁄i c¡c cæng cö sinh ki”m thß tü ºng [40].1 Sinh ca ki”m thß sß döng ki”m chøng mæ h…nh theo c¡ch ti‚p c“n [17].2 C¡c b÷îc cì b£n sinh c¡c dœ li»u ki”m thß.3 V‰ dö bi”u ç tuƒn tü UML.4 File xmi sau khi chu'n hâa mæ t£ dœ li»u cıa bi”u ç tuƒn tü trong H…nh 3.5 Chuy”n tł bi”u ç tuƒn tü sang CFG (cıa to¡n tß opt v alt).6 Chuy”n tł bi”u ç tuƒn tü sang CFG (cıa to¡n tß break v loop).7 Chuy”n tł bi”u ç tuƒn tü sang CFG (cıa to¡n tß par v seq).8 Chuy”n tł bi”u ç tuƒn tü sang CFG (cıa to¡n tß strict v critical).9 Chuy”n tł bi”u ç tuƒn tü sang CFG (cıa to¡n tß ignore v consider).10 Chuy”n tł bi”u ç tuƒn tü sang CFG (cıa to¡n tß assert v negative).11 Bi”u ç tuƒn tü cıa m¡y b¡n h ng tü ºng.12 Bi”u ç lîp cıa chøc n«ng m¡y b¡n h ng tü ºng.13 ç thà dÆng i•u khi”n cıa m¡y b¡n h ng tü ºng.14 Bi”u ç tuƒn tü vîi ki”u dœ li»u bi‚n l c§u tróc ºng.15 ç thà dÆng i•u khi”n vîi ki”u dœ li»u bi‚n l c§u tróc ºng.16 ÷íng d¤n con P1 thüc thi.17 ÷íng d¤n con P2 thüc thi.18 ÷íng d¤n con P3 thüc thi.19 Ki‚n tróc thüc thi cıa SequenceTesting.1 To¡n tß l°p chuy”n sang CFG.2 To¡n tß song song chuy”n sang CFG.3 Qu¡ tr…nh sinh dœ li»u ki”m thß: ph¡t tri”n tł [75] cho vÆng l°p.4 T‰nh i”m chia split phö thuºc c¡c mi•n gi¡ trà cıa bi‚n trong [75].5 Bi”u ç tuƒn tü cıa chøc n«ng chuy”n ti•n trong h» thŁng ng¥n h ng.6 Bi”u ç lîp v r ng buºc OCL cho chøc n«ng chuy”n ti•n.7 ç thà dÆng i•u khi”n cıa chøc n«ng chuy”n ti•n.8 Ki‚n tróc ph¡t tri”n cıa cæng cö SequenceConcur.1 Ki‚n tróc cıa Bº gi£i Z3 str trong [114].2 Bi”u ç tuƒn tü cho chøc n«ng ki”m tra thæng tin cıa mºt øng döng web.3 CFG cıa chøc n«ng ki”m tra thæng tin øng döng web.4 Ki‚n tróc cıa SeqString. 139 xii T´MT TLU N N Lu“n ¡n nghi¶n cøu mºt sŁ gi£i ph¡p hØ træ sinh dœ li»u ki”m thß tü ºng tł c¡c bi”u ç UML 2.
Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ
Câu hỏi thường gặp
Luận án "Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML" nghiên cứu về vấn đề gì?
Luận án TS máy tính nghiên cứu kỹ thuật sinh tự động dữ liệu kiểm thử. Áp dụng biểu đồ UML để nâng cao chất lượng và hiệu quả kiểm thử phần mềm.
Luận án "Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML" được bảo vệ tại trường nào?
Luận án này được bảo vệ tại đại học Công nghệ, đại học Quốc gia Hà Nội. Năm bảo vệ: 2018.
Luận án "Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML" thuộc chuyên ngành gì?
Luận án "Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML" thuộc chuyên ngành Công nghệ Thông tin. Danh mục: Khoa Học Máy Tính.
Luận án "Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML" có bao nhiêu trang?
Luận án "Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML" có 175 trang. Bạn có thể xem trước một phần tài liệu ngay trên trang web trước khi tải về.
Cách tải luận án "Kỹ thuật sinh dữ liệu kiểm thử tự động từ biểu đồ UML" về máy như thế nào?
Để tải luận án về máy, bạn nhấn nút "Tải xuống ngay" trên trang này, sau đó hoàn tất thanh toán phí lưu trữ. File sẽ được tải xuống ngay sau khi thanh toán thành công. Hỗ trợ qua Zalo: 0559 297 239.