Luận văn về tự động hóa và sửa lỗi cho các lỗi biến thể trong dòng sản phẩm phần mềm

Nghiên cứu này tập trung vào việc cải thiện quy trình tự động hóa trong việc phát hiện và sửa lỗi biến thể trong dòng sản phẩm phần mềm… 195 trang · 2024.

• Tác giả: Nguyen Thu Trang
• Người hướng dẫn: Dr. Vo Dinh Hieu
• Trường học: Vietnam National University, Hanoi University of Engineering and Technology
• Chuyên ngành: Software Engineering
• Đề tài: Automated Localization and Repair for Variability Faults in Software Product Lines
• Loại tài liệu: Doctor of Philosophy Dissertation
• Năm xuất bản: 2024
• Địa điểm: Hanoi

Mục lục chi tiết

• Acknowledgement
• Declaration
• Abstract
• 1. CHAPTER 1: INTRODUCTION
• 1.1. Problem Statement
• 1.2. Objective and Contributions
• 1.3. Research methodology and Scope
• 2. CHAPTER 2: BACKGROUND AND LITERATURE REVIEW
• 2.1. Software Product Line
• 2.2. Testing Software Product Lines
• 2.3. Automated Program Repair
• 2.4. Benchmarks for Software Product Lines
• 3. CHAPTER 3: FALSE-PASSING PRODUCT DETECTION
• 3.1. Suspiciousness of Product Implementation
• 3.2. Motivation and Problem Formulation
• 3.3. False-passing Product Detection
• 3.4. Detecting False-passing Products
• 3.5. Mitigation of Negative Impact of False-passing Products on Variability Fault Localization
• 3.6. Mitigating Impact of False-passing Products on Fault Localization (RQ2)
• 3.7. Threats to Validity
• 4. CHAPTER 4: VARIABILITY FAULT LOCALIZATION
• 4.1. An Example of Variability Faults in Software Product Lines
• 4.2. Feature Interaction Formulation
• 4.3. The Root Cause of Variability Failures
• 4.4. Buggy Partial Configuration Detection
• 4.5. Buggy Partial Configuration
• 4.6. Important Properties to Detect Buggy Partial Configuration
• 4.7. Buggy Partial Configuration Detection Algorithm
• 4.8. Suspicious Statement Identification
• 4.9. Suspicious Statement Ranking
• 4.10. Product-based Suspiciousness Assessment
• 4.11. Test Case-based Suspiciousness Assessment
• 4.12. Evaluation Setup, Procedure, and Metrics
• 4.13. Accuracy and Comparison (RQ1)
• 4.14. Performance in Localizing Multiple Bugs (RQ4)
• 4.15. Threats to Validity
• 5. CHAPTER 5: AUTOMATED VARIABILITY FAULT REPAIR
• 5.1. Product-based Approach (ProdBasedbasic)
• 5.2. System-based Approach (SysBasedbasic)
• 5.3. Product-based Approach vs System-based Approach
• 5.4. Heuristic Rules for Improving the Repair Performance
• 5.4.1. Heuristic Rules for Improving the Performance of Automated Program Repair Tools
• 5.4.2. Applying the Heuristic Rules in Repairing Variability Faults
• 5.5. Evaluation Procedure and Metrics
• 5.6. Threats to Validity
• 6. CHAPTER 6: CONCLUSION
• List of Publications
• References

Tóm tắt

I. Tự động hóa sửa lỗi biến thể trong dòng sản phẩm phần mềm

Nghiên cứu này tập trung vào việc cải thiện quy trình tự động hóa trong việc phát hiện và sửa lỗi biến thể trong dòng sản phẩm phần mềm (SPL). Các hệ thống SPL ngày càng trở nên phổ biến trong phát triển phần mềm công nghiệp lớn, tuy nhiên, tính biến thể của chúng tạo ra nhiều thách thức trong việc đảm bảo chất lượng. Nghiên cứu này chỉ ra rằng mặc dù có nhiều nghiên cứu về sửa lỗi phần mềm trong các hệ thống đơn lẻ, nhưng việc sửa lỗi trong SPL vẫn còn nhiều điều chưa được khám phá. Do đó, nghiên cứu này đề xuất ba nhiệm vụ chính: phát hiện sản phẩm giả mạo, định vị lỗi biến thể và sửa lỗi biến thể.

1.1. Phát hiện sản phẩm giả mạo

Nghiên cứu giới thiệu một phương pháp gọi là Clap, nhằm phát hiện các sản phẩm giả mạo trong SPL. Clap thu thập các dấu hiệu thất bại từ các sản phẩm không thành công và đánh giá khả năng sản phẩm đang được kiểm tra có phải là giả mạo hay không. Nghiên cứu cho thấy rằng độ chính xác của việc phát hiện sản phẩm giả mạo có thể đạt tới 96%. Điều này có nghĩa là trong số mười sản phẩm được dự đoán là giả mạo, hơn chín sản phẩm được phát hiện chính xác.

1.2. Định vị lỗi biến thể

Để định vị lỗi biến thể, nghiên cứu giới thiệu phương pháp VarCop, một cách tiếp cận hiệu quả trong việc phân tích mã nguồn và kết quả kiểm tra của các sản phẩm mẫu. VarCop giúp xác định các câu lệnh nghi ngờ có liên quan đến lỗi trong hệ thống SPL. Bằng cách đánh giá sự nghi ngờ của từng câu lệnh dựa trên kết quả kiểm tra tổng thể, VarCop có thể xác định chính xác vị trí của lỗi trong hệ thống, giúp tăng cường khả năng phát hiện lỗi.

1.3. Sửa lỗi biến thể

Nghiên cứu đề xuất hai phương pháp sửa lỗi: phương pháp dựa trên sản phẩm và phương pháp dựa trên hệ thống. Phương pháp dựa trên sản phẩm sửa từng sản phẩm bị lỗi một cách độc lập, trong khi phương pháp dựa trên hệ thống sửa tất cả các sản phẩm cùng một lúc. Cả hai phương pháp đều sử dụng các quy tắc heuristic để cải thiện hiệu suất sửa lỗi. Kết quả cho thấy phương pháp dựa trên sản phẩm có hiệu suất sửa lỗi cao gấp 20 lần so với phương pháp dựa trên hệ thống.

Nội dung chính

Tổng quan luận án

Trong kỹ thuật phần mềm hiện đại, các hệ thống dòng sản phẩm phần mềm (Software Product Line - SPL) hay hệ thống có thể cấu hình (Configurable Systems) được ứng dụng rộng rãi trong các dự án công nghiệp quy mô lớn nhằm tối ưu hóa chi phí phát triển, nâng cao năng suất và tăng tính linh hoạt bằng cách tái sử dụng các thành phần phần mềm. Thay vì phát triển từng sản phẩm riêng lẻ từ đầu, phương pháp tiếp cận SPL cho phép tạo ra nhiều biến thể sản phẩm (products/variants) từ một cơ sở mã nguồn chung thông qua việc lựa chọn và kết hợp các tính năng (features). Tuy nhiên, đặc tính biến thể và sự phụ thuộc, tương tác phức tạp giữa các tính năng đặt ra thách thức lớn cho công tác đảm bảo chất lượng (Quality Assurance - QA), đặc biệt là quy trình kiểm thử và gỡ lỗi tự động.

Lỗi trong hệ thống SPL có thể là lỗi biến thể (variability bug), tức là loại lỗi chỉ bộc lộ hành vi sai hỏng dưới những tổ hợp kích hoạt hoặc vô hiệu hóa cụ thể của một tập hợp các tính năng. Khi kiểm thử một tập hợp sản phẩm mẫu, lỗi biến thể chỉ làm cho một số sản phẩm bị lỗi (failing products), trong khi các sản phẩm khác vẫn vượt qua toàn bộ các ca kiểm thử (passing products). Hiện nay, trong khi các kỹ thuật gỡ lỗi tự động cho hệ thống đơn lẻ (single-system) đã được nghiên cứu sâu rộng, hoạt động gỡ lỗi trong hệ thống SPL phần lớn vẫn thực hiện thủ công và mang tính tùy biến (ad-hoc).

Luận án tiến sĩ của nghiên cứu sinh Nguyễn Thu Trang, thực hiện dưới sự hướng dẫn của TS. Võ Đình Hiếu và PGS. Hồ Sĩ Đàm tại Trường Đại học Công nghệ – Đại học Quốc gia Hà Nội (năm 2024), tập trung giải quyết bài toán gỡ lỗi tự động cho hệ thống dòng sản phẩm phần mềm chịu ảnh hưởng bởi lỗi biến thể. Luận án giải quyết ba nhiệm vụ nghiên cứu cốt lõi:

1. Phát hiện sản phẩm vượt qua giả (False-passing product detection) nhằm khắc phục hiện tượng trùng hợp đúng (coincidental correctness) làm sai lệch kết quả kiểm thử.
2. Định vị lỗi biến thể (Variability fault localization) ở mức câu lệnh trên phạm vi toàn hệ thống thông qua phân tích tương tác tính năng và phổ thực thi.
3. Tự động sửa lỗi biến thể (Automated variability fault repair) ở mức mã nguồn dựa trên hai chiến lược: tiếp cận theo sản phẩm (product-based) và tiếp cận theo hệ thống (system-based), kết hợp các quy tắc suy nghiệm nhằm tối ưu hóa việc chọn vị trí sửa và thao tác sửa.

Đối tượng nghiên cứu của luận án là mã nguồn các hệ thống dòng sản phẩm phần mềm, mô hình tính năng (feature models), tập cấu hình mẫu và các bộ kiểm thử tương ứng của từng sản phẩm. Phạm vi nghiên cứu tập trung vào các lỗi biến thể mức mã nguồn trong hệ thống SPL dạng dòng lệnh và hướng đối tượng, được kiểm chứng thực nghiệm trên bộ dữ liệu chuẩn gồm 1.570 phiên bản lỗi thuộc 6 hệ thống SPL mã nguồn mở có kích thước và đặc tính cấu hình đa dạng.

Tổng quan tài liệu và vị trí của luận án

Tổng quan tài liệu trong luận án phân tích các nhánh nghiên cứu liên quan đến tương tác tính năng, kiểm thử SPL, hiện tượng trùng hợp đúng, định vị lỗi và sửa lỗi chương trình tự động:

1. Nghiên cứu về tương tác tính năng và lỗi biến thể trong SPL: Sự tương tác ngoài dự kiến giữa các tính năng khi kết hợp trong một sản phẩm có thể dẫn đến sai hỏng hệ thống. Các công trình của Abal và cộng sự (2014, 2018) đã phân tích các lỗi biến thể thực tế trong các hệ thống lớn như Linux Kernel và BusyBox, chỉ ra tính phức tạp và bản chất phụ thuộc cấu hình của chúng. Garvin và cộng sự (2011) xác lập tiêu chí hộp trắng về các câu lệnh cần thiết phải thực thi hoặc không thực thi để bộc lộ lỗi tương tác. Bên cạnh đó, các kỹ thuật phát hiện tương tác tính năng hộp đen (Siegmund và cộng sự, 2012), kiểm tra mô hình (Classen và cộng sự, 2010), phân tích luồng điều khiển và luồng dữ liệu (Nguyen và cộng sự, 2016; Reisner và cộng sự, 2010) cũng như phương pháp lặp của iGen (2013) đã được đề xuất nhằm nhận diện sự ảnh hưởng lẫn nhau giữa các tính năng.

2. Kỹ thuật kiểm thử và lấy mẫu cấu hình trong SPL: Do không gian cấu hình bùng nổ theo hàm mũ (ví dụ: Linux Kernel có hơn 12.000 tùy chọn biên dịch tạo ra hàng tỷ biến thể), việc kiểm thử toàn bộ sản phẩm là bất khả thi. Các kỹ thuật lấy mẫu cấu hình được áp dụng phổ biến gồm kiểm thử tổ hợp tương tác $t$-wise (combinatorial interaction testing), bao phủ câu lệnh (statement-coverage), một-tính-năng-bật (one-enabled), một-tính-năng-tắt (one-disabled) và bật-tắt-nhiều-nhất (most-enabled-disabled). Các nghiên cứu của Al-Hajjaji và cộng sự (2016, 2017) và Nguyen và cộng sự (2016) tập trung vào sắp xếp thứ tự ưu tiên cấu hình kiểm thử dựa trên độ tương đồng hoặc số lượng lỗi tiềm năng.

3. Hiện tượng trùng hợp đúng và chất lượng bộ kiểm thử: Hiện tượng trùng hợp đúng (coincidental correctness) xảy ra khi một ca kiểm thử thực thi qua câu lệnh lỗi nhưng không lan truyền trạng thái sai ra ngõ ra, dẫn đến kết quả kiểm thử đạt (passed) một cách ngẫu nhiên. Hiện tượng này làm suy giảm nghiêm trọng độ chính xác của các kỹ thuật định vị lỗi (Masri và cộng sự, 2014; Wang và cộng sự, 2017). Nhiều công trình đã phát triển kỹ thuật lọc hoặc gán trọng số cho các ca kiểm thử đạt ngẫu nhiên (Bandyopadhyay và cộng sự, 2011) hoặc đánh giá chất lượng bộ kiểm thử thông qua độ đo DDU (Density-Diversity-Uniqueness) của Perez và cộng sự (2017) và kiểm thử đột biến (mutation testing).

4. Kỹ thuật định vị lỗi (Fault Localization - FL): Định vị lỗi dựa trên phổ thực thi (Spectrum-Based Fault Localization - SBFL) là nhánh kỹ thuật tiêu biểu (Tarantula, Ochiai, Op2, Barinel, Dstar). Để áp dụng cho SPL, các hướng tiếp cận trước đây thường thực hiện định vị lỗi độc lập trên từng sản phẩm bằng phương pháp lát cắt chương trình (slicing) hoặc chạy SBFL riêng lẻ, tạo ra nhiều danh sách xếp hạng rời rạc khiến lập trình viên khó xác định nguyên nhân gốc rễ. Một cách tiếp cận khác coi toàn bộ hệ thống SPL như một chương trình đơn lẻ bằng cách xem các chỉ thị tiền xử lý #ifdef như câu lệnh rẽ nhánh điều kiện (Ngo và cộng sự, 2024), hoặc áp dụng mô phỏng lỗi (Arrieta và cộng sự, 2017). Tuy nhiên, các kỹ thuật này chưa khai thác trực tiếp thông tin về tương tác tính năng và cấu hình bộ phận gây lỗi.

5. Tự động sửa lỗi chương trình (Automated Program Repair - APR): Các công cụ APR kiểm thử tiêu biểu (GenProg, RSRepair, Nopol, Cardumen, SimFix, Arja, DEAR) được thiết kế cho hệ thống đơn lẻ không có khả năng nhận biết biến thể. Khi áp dụng trực tiếp cho SPL, bản vá tạo ra có thể sửa được sản phẩm đang xét nhưng lại phá vỡ tính đúng đắn của các sản phẩm khác. Một số nghiên cứu về SPL chỉ tập trung sửa lỗi ở mức mô hình biến thể (Arcaini và cộng sự, 2015, 2017) hoặc cấu hình sai (Weiss và cộng sự, 2017; Xiong và cộng sự, 2015). Nghiên cứu thực nghiệm của Echeverría và cộng sự (2021) trên hệ thống SPL công nghiệp cho thấy việc lập trình viên sửa lỗi thủ công và lan truyền bản vá giữa các sản phẩm gặp rất nhiều khó khăn.

Khoảng trống nghiên cứu: Chưa có một quy trình gỡ lỗi tự động toàn diện cho hệ thống SPL giải quyết đồng thời việc nhận diện sản phẩm vượt qua giả, định vị lỗi biến thể mức câu lệnh dựa trên tương tác tính năng và tự động tổng hợp bản vá mã nguồn hợp lệ cho toàn bộ dòng sản phẩm.

Cơ sở lý thuyết và phương pháp nghiên cứu

Cơ sở lý thuyết và khung khái niệm

• Hệ thống dòng sản phẩm phần mềm (SPL): Được biểu diễn hình thức bằng bộ 3 thành phần $S = \langle S, F, \varphi \rangle$, trong đó:
  • $S$ là tập hợp tất cả các câu lệnh mã nguồn thực thi của hệ thống.
  • $F$ là tập hợp các tính năng của hệ thống. Mỗi tính năng $f \in F$ nhận giá trị bật (enabled/true) hoặc tắt (disabled/false).
  • $\varphi: F \to 2^S$ là hàm ánh xạ triển khai tính năng, xác định tập câu lệnh $\varphi(f) \subset S$ thuộc về tính năng $f$.
• Cấu hình (Configuration) và Sản phẩm (Product): Một cấu hình $c$ là một phép gán giá trị cho toàn bộ các tính năng trong $F$. Một cấu hình thỏa mãn toàn bộ ràng buộc của mô hình tính năng (Feature Model) là một cấu hình hợp lệ. Cấu hình bộ phận (Partial Configuration - PC) là một tập con khác rỗng của cấu hình $c$. Sản phẩm $p$ tương ứng với cấu hình $c$ là sự kết hợp mã nguồn của tất cả các tính năng được bật trong $c$.
• Lỗi biến thể (Variability Bug): Là câu lệnh mã nguồn sai trong $S$ gây ra lỗi (failure) trên một tập con thực sự khác rỗng $P_F$ của tập sản phẩm mẫu $P$, trong khi tập con còn lại $P_P$ vượt qua toàn bộ các ca kiểm thử ($P_P \cup P_F = P$).
• Phổ kiểm thử chương trình (Program Spectrum): Được biểu diễn dưới dạng ma trận thực thi $A$ kích thước $n \times m$ (với $n$ phần tử mã nguồn và $m$ ca kiểm thử) cùng vector kết quả $r$ ($r_j = 0$ nếu ca kiểm thử đạt, $r_j = 1$ nếu thất bại). Các độ đo tương tự thống kê (Tarantula, Ochiai, Op2, Barinel, Dstar) sử dụng các tham số $e_f, e_p, n_f, n_p$ (số ca kiểm thử hỏng/đạt có hoặc không thực thi qua câu lệnh) để tính điểm nghi ngờ (suspiciousness score).
• Khung hình thức cho APR:
  • Điểm sửa đổi (Modification Point): $mp = (pos, c_o)$ với $pos$ là vị trí trong chương trình và $c_o$ là mã nguồn gốc.
  • Toán tử sửa đổi (Modification Operator): $op \in {rem, rep, ins_bef, ins_aft}$ tương ứng với các thao tác xóa, thay thế, chèn trước và chèn sau.
  • Thao tác sửa đổi (Modification Operation): $d = op(mp, c_n)$ chuyển đổi mã gốc $c_o$ thành mã mới $c_n$.
  • Bản vá ứng viên (Candidate Patch): Là kết quả áp dụng một danh sách gồm một hoặc nhiều thao tác sửa đổi. Bản vá hợp lệ (Valid/Plausible Patch) là bản vá giúp sản phẩm vượt qua tất cả các ca kiểm thử hiện có.

Phương pháp nghiên cứu

Luận án kết hợp phương pháp nghiên cứu định tính và định lượng:

• Phương pháp định tính: Phân tích lý thuyết và mô hình hóa toán học đối với bài toán tương tác tính năng, cơ chế gây lỗi biến thể và các nguyên nhân dẫn đến hiện tượng trùng hợp đúng trong kiểm thử SPL; phân tích các hạn chế của các công cụ SBFL và APR truyền thống khi áp dụng trên hệ thống có cấu hình biến đổi.
• Phương pháp định lượng:
  • Xây dựng và thực thi các thuật toán thực nghiệm trên tập dữ liệu chuẩn.
  • Sử dụng các độ đo đánh giá định lượng: Độ chính xác (Accuracy), Độ chuẩn xác (Precision), Độ thu hồi (Recall) trong phát hiện sản phẩm vượt qua giả; Xếp hạng vị trí lỗi (Rank, Hit@1, Hit@3, Hit@5) trong định vị lỗi; Số lượng bản vá đúng (#Correct fixes) và số lượng thao tác sửa đổi thực hiện trong tự động sửa lỗi.

Nguồn tư liệu và dữ liệu thực nghiệm

Luận án sử dụng bộ dữ liệu chuẩn về lỗi biến thể trong SPL do Ngo và cộng sự (2024) công bố, gồm 1.570 phiên bản lỗi của 6 hệ thống SPL mã nguồn mở viết bằng Java. Các hệ thống được lấy mẫu cấu hình theo chiến lược bao phủ 4-wise.

Hệ thống SPL	Số dòng mã (#LOC)	Số tính năng (#F)	Số sản phẩm mẫu (#SP)	Số ca kiểm thử TB (#Tests)	Độ bao phủ câu lệnh (Cov %)	Phiên bản 1 lỗi (Single-Bug)	Phiên bản 2 lỗi (2-Bug)	Phiên bản 3 lỗi (3-Bug)
ZipMe	3.460	13	25	255,4	42,7%	105	190	77
Elevator-FH-JML	854	6	18	166,5	99,8%	49	126	88
Email-FH-JML	439	9	27	86,9	98,8%	73	238	72
ExamDB	338	6	8	114,3	92,6%	34	143	91
BankAccountTP	164	6	34	40,2	99,5%	38	91	82
GPL	669	16	40	120,5	94,1%	39	95	86

Nội dung chính theo từng chương

Chương 1: Giới thiệu (Introduction)

Chương này trình bày bối cảnh thực tiễn của kỹ thuật dòng sản phẩm phần mềm, nhấn mạnh sự gia tăng ứng dụng trong công nghiệp và những rào cản kỹ thuật trong kiểm thử và gỡ lỗi do không gian cấu hình lớn. Tác giả xác định tính cấp thiết của việc tự động hóa gỡ lỗi SPL, chỉ ra các nguyên nhân dẫn đến tính không hiệu quả của các công cụ gỡ lỗi đơn lẻ khi áp dụng cho hệ thống biến thể. Chương 1 xác lập mục tiêu nghiên cứu, phạm vi, phương pháp luận và tóm tắt cấu trúc của toàn bộ luận án.

Chương 2: Kiến thức nền tảng và tổng quan tài liệu (Background and Literature Review)

Chương 2 cung cấp các định nghĩa hình thức về SPL, mô hình tính năng, cấu hình, lỗi biến thể và minh họa chi tiết qua ví dụ hệ thống Thang máy (Elevator System). Tác giả hệ thống hóa các chiến lược lấy mẫu cấu hình phổ biến ($t$-wise, statement-coverage, one-disabled, most-enabled-disabled), quy trình kiểm thử miền (domain engineering) và kiểm thử ứng dụng (application engineering). Đồng thời, chương này tổng quan nguyên lý của SBFL, các bước chuẩn trong quy trình APR dựa trên kiểm thử, và phân tích các công trình nghiên cứu liên quan về tương tác tính năng, hiện tượng trùng hợp đúng cũng như các bộ dữ liệu chuẩn hiện có trong lĩnh vực SPL.

Chương 3: Phát hiện sản phẩm vượt qua giả (False-passing Product Detection)

Chương 3 đề xuất phương pháp Clap nhằm phát hiện các sản phẩm vượt qua giả (false-passing products) – là các sản phẩm chứa mã nguồn lỗi nhưng vẫn vượt qua toàn bộ ca kiểm thử do bộ kiểm thử không bao phủ được câu lệnh lỗi hoặc không lan truyền được trạng thái lỗi ra đầu ra.

Phương pháp Clap đánh giá khả năng một sản phẩm vượt qua là giả mạo thông qua hai nhóm thuộc tính đo lường được:

1. Đặc tính triển khai sản phẩm (Product Implementation): Đo lường mức độ nghi ngờ của các câu lệnh có mặt trong sản phẩm vượt qua dựa trên mức độ xuất hiện của chúng trong các sản phẩm bị hỏng. Nếu sản phẩm vượt qua chứa nhiều câu lệnh có độ nghi ngờ cao ở các sản phẩm hỏng, khả năng sản phẩm đó chứa lỗi là rất lớn.
2. Chất lượng bộ kiểm thử (Test Quality): Đánh giá độ đầy đủ (adequacy - độ bao phủ câu lệnh, nhánh) và hiệu quả kiểm thử (effectiveness - khả năng kiểm tra sâu hành vi dựa trên độ đo DDU và tính phản ánh đúng đắn/sai hỏng). Bộ kiểm thử có độ bao phủ thấp hoặc độ phân biệt trạng thái kém sẽ làm tăng xác suất sản phẩm là vượt qua giả.

Chương này cũng phân tích tác động tiêu cực của sản phẩm vượt qua giả lên các công thức SBFL mức sản phẩm và mức ca kiểm thử, đồng thời đề xuất các chiến lược giảm thiểu tác động bằng cách loại bỏ các kết quả kiểm thử không đáng tin cậy hoặc tăng cường kiểm thử bổ sung.

Chương 4: Định vị lỗi biến thể (Variability Fault Localization)

Chương 4 giới thiệu công cụ và phương pháp VarCop chuyên dụng cho định vị lỗi biến thể trong SPL. VarCop hoạt động dựa trên hai nguyên lý chính:

1. Phát hiện cấu hình bộ phận lỗi (Buggy Partial Configuration - Buggy PC): VarCop phân tích kết quả kiểm thử tổng thể của các sản phẩm mẫu để xác định tập hợp các tính năng cần được bật/tắt đồng thời để bộc lộ lỗi. Các câu lệnh liên quan đến sự tương tác giữa các tính năng trong Buggy PC được cô lập thành tập câu lệnh nghi ngờ.
2. Đánh giá và xếp hạng độ nghi ngờ đa mức (Suspicious Statement Ranking):
   • Đánh giá mức sản phẩm (Product-based): Câu lệnh xuất hiện trong càng nhiều sản phẩm hỏng và càng ít sản phẩm đạt thì điểm nghi ngờ càng cao.
   • Đánh giá mức ca kiểm thử (Test case-based): Trong từng sản phẩm hỏng chứa câu lệnh, độ nghi ngờ của câu lệnh được tính toán chi tiết dựa trên các ca kiểm thử đạt và hỏng đã thực thi qua câu lệnh đó.

Kết quả thực nghiệm trên bộ dữ liệu chuẩn cho thấy VarCop nâng cao vị trí xếp hạng của câu lệnh lỗi so với các kỹ thuật SBFL chuẩn, S-SBFL (kết hợp lát cắt và SBFL) và phương pháp của Arrieta và cộng sự.

Chương 5: Tự động sửa lỗi biến thể (Automated Variability Fault Repair)

Chương 5 trình bày hai hướng tiếp cận tự động sửa lỗi mã nguồn biến thể:

1. Tiếp cận dựa trên sản phẩm ($ProdBased_{basic}$): Sửa từng sản phẩm hỏng một cách độc lập, sau đó lan truyền bản vá tìm được sang các sản phẩm khác và kiểm chứng lại trên toàn bộ tập sản phẩm mẫu.
2. Tiếp cận dựa trên hệ thống ($SysBased_{basic}$): Toàn bộ các sản phẩm được xem xét đồng thời trong mỗi vòng lặp sửa lỗi; bản vá ứng viên được sinh ra và kiểm chứng ngay lập tức trên toàn bộ các sản phẩm mẫu.

Để khắc phục chi phí kiểm thử động lớn và nâng cao tỷ lệ sinh bản vá đúng, tác giả đề xuất hai quy tắc suy nghiệm:

• Định hướng điểm sửa đổi dựa trên điểm sửa chữa (Fixing Score): Cập nhật động điểm sửa chữa cho các vị trí mã nguồn dựa trên phản hồi từ kết quả kiểm chứng trung gian của các bản vá trước đó (nếu sửa đổi tại vị trí $mp$ làm giảm số lượng ca kiểm thử hỏng, vị trí đó được tăng mức độ ưu tiên).
• Đo lường độ phù hợp của thao tác sửa đổi (Modification Suitability): Đánh giá nhanh độ tương đồng cú pháp và ngữ nghĩa của thao tác sửa đổi mới với mã nguồn gốc và với các thao tác sửa đổi thành công/thất bại trước đó trước khi thực thi kiểm thử tốn kém, loại bỏ sớm các thao tác không phù hợp.

Hai phiên bản nâng cao tích hợp các quy tắc suy nghiệm được ký hiệu là $ProdBased_{enhanced}$ và $SysBased_{enhanced}$.

Chương 6: Kết luận (Conclusion)

Chương 6 tổng kết toàn bộ các kết quả đạt được của luận án, khẳng định tính khả thi và hiệu quả của các giải pháp tự động hóa gỡ lỗi trong SPL từ khâu phát hiện kiểm thử sai lệch, định vị lỗi đến sửa lỗi tự động, đồng thời nêu rõ các định hướng phát triển tiếp theo.

Kết quả và những đóng góp mới

Những đóng góp mới về mặt khoa học và kỹ thuật

1. Định hình bài toán và đề xuất phương pháp Clap: Lần đầu tiên bài toán phát hiện sản phẩm vượt qua giả do trùng hợp đúng trong hệ thống SPL được định hình rõ ràng; thiết lập tập thuộc tính kết hợp giữa mã nguồn và chất lượng kiểm thử để nhận diện sản phẩm vượt qua giả với độ chính xác cao.
2. Khái niệm Cấu hình bộ phận lỗi và phương pháp VarCop: Đề xuất mô hình Buggy Partial Configuration (Buggy PC) đại diện cho nguyên nhân gốc rễ của lỗi biến thể; xây dựng thuật toán định vị lỗi VarCop kết hợp phân tích tương tác tính năng với đánh giá phổ kiểm thử đa mức (sản phẩm và ca kiểm thử).
3. Hai giải pháp sửa lỗi biến thể và các quy tắc suy nghiệm: Thiết kế hai mô hình sửa lỗi $ProdBased$ và $SysBased$ cho mã nguồn SPL; xây dựng các quy tắc suy nghiệm sử dụng điểm sửa chữa động (Fixing Score) và độ phù hợp sửa đổi (Modification Suitability) giúp giảm không gian tìm kiếm và chi phí kiểm thử.
4. Bộ công cụ thực nghiệm mã nguồn mở: Phát triển và công bố công khai các công cụ hỗ trợ nghiên cứu gồm Clap, VarCop và SPLRepair.

Kết quả định lượng từ thực nghiệm

Công cụ / Phương pháp	Chỉ số đánh giá chính	Kết quả đạt được	So sánh với phương pháp cơ sở / đối chứng
Clap (Phát hiện sản phẩm vượt qua giả)	Độ chính xác trung bình (Accuracy) Độ chuẩn xác (Precision)	> 90% Lên đến 96%	Trong 10 sản phẩm dự đoán là vượt qua giả, có hơn 9 sản phẩm được xác định chính xác.
VarCop (Định vị lỗi đơn - Single bug)	Cải thiện xếp hạng câu lệnh lỗi Tỷ lệ lỗi ở Top-3 (Hit@3)	Tăng 33% và 50% Chiếm ~2/3 trường hợp	Vượt trội so với 2 kỹ thuật tiên tiến (SBFL chuẩn và S-SBFL).
VarCop (Định vị đa lỗi - Multiple bugs)	Tỷ lệ lỗi định vị ở Top-1 (Hit@1)	Đạt kết quả cao	Tốt hơn 2 lần so với S-SBFL và 10 lần so với SBFL chuẩn.
Sửa lỗi biến thể ($ProdBased$ vs $SysBased$)	Số lượng bản vá đúng (#Correct fixes)	$ProdBased$ vượt trội	$ProdBased$ tạo ra số bản vá đúng gấp khoảng 20 lần so với $SysBased$.
Quy tắc suy nghiệm (Heuristic Rules trong APR)	Tăng số bản vá đúng Giảm số phép thử sửa đổi	Tăng 30% - 150% Giảm 30% - 50%	Cải thiện rõ rệt hiệu năng của cả 2 mô hình tiếp cận $ProdBased$ và $SysBased$.

Hạn chế và hướng nghiên cứu tiếp

Dựa trên nội dung luận án, các hạn chế và hướng phát triển được xác định như sau:

• Hạn chế về bộ dữ liệu kiểm chứng: Các thực nghiệm được tiến hành trên tập dữ liệu đột biến nhân tạo (mutation-based variability faults) trên 6 hệ thống Java mẫu; chưa đánh giá trên các hệ thống ngôn ngữ hỗn hợp hoặc các lỗi biến thể đa câu lệnh có độ phức tạp cao trong các dự án công nghiệp thực tế quy mô siêu lớn.
• Không gian toán tử sửa lỗi: Các toán tử sửa đổi trong phần APR chủ yếu tập trung vào các phép biến đổi câu lệnh cơ bản (xóa, thay thế, chèn), chưa mở rộng đầy đủ cho việc tổng hợp các cấu trúc điều khiển phức tạp hoặc sửa lỗi đồng thời trên nhiều phương thức/lớp.
• Hướng nghiên cứu tiếp theo:
  1. Mở rộng phương pháp phát hiện sản phẩm vượt qua giả và định vị lỗi cho các hệ thống SPL sử dụng cơ chế liên kết động (dynamic binding) và cấu hình tại thời gian chạy (runtime variability).
  2. Kết hợp các mô hình học sâu và mô hình ngôn ngữ lớn (LLMs) vào việc sinh mã cho các thao tác sửa đổi trong APR cho SPL nhằm mở rộng không gian tìm kiếm bản vá ngữ nghĩa.
  3. Đánh giá tính mở rộng của VarCop và Clap trên các kho phần mềm công nghiệp lớn như Linux Kernel và hệ sinh thái tiện ích mở rộng của WordPress.

Giá trị tham khảo

Luận án là tài liệu học thuật có giá trị tham khảo chuyên sâu cho các đối tượng:

• Nghiên cứu sinh và học viên cao học ngành Kỹ thuật phần mềm: Tham khảo phương pháp nghiên cứu kết hợp giữa mô hình hóa hình thức và thực nghiệm định lượng; cách tiếp cận giải quyết bài toán kiểm thử và gỡ lỗi trên các hệ thống có không gian tham số lớn.
• Giảng viên và nhà nghiên cứu trong lĩnh vực Đảm bảo chất lượng phần mềm (SQA): Sử dụng các chương 2, 3, 4, 5 làm tài liệu tham khảo chuyên đề về kiểm thử dòng sản phẩm phần mềm, phân tích phổ thực thi và sửa lỗi chương trình tự động.
• Kỹ sư phát triển phần mềm và chuyên viên kiểm thử: Ứng dụng các nguyên lý của Clap và VarCop để xây dựng các công cụ phân tích chất lượng bộ kiểm thử nội bộ và tối ưu hóa quy trình khoanh vùng lỗi trên các hệ thống phần mềm có nhiều biến thể cấu hình.

Câu hỏi thường gặp

1. Lỗi biến thể (variability fault) trong dòng sản phẩm phần mềm khác gì so với lỗi phần mềm truyền thống?

Lỗi phần mềm truyền thống trong hệ thống đơn lẻ thường bộc lộ sai hỏng khi có dữ liệu đầu vào kích hoạt câu lệnh lỗi. Ngược lại, lỗi biến thể trong SPL phụ thuộc vào sự tương tác giữa các tính năng cấu hình. Lỗi này chỉ xuất hiện khi một tập hợp tính năng cụ thể được bật hoặc tắt đồng thời (Buggy Partial Configuration). Do đó, cùng một câu lệnh lỗi nhưng chỉ làm một số sản phẩm bị lỗi trong khi các sản phẩm khác vẫn chạy đúng và vượt qua toàn bộ ca kiểm thử.

2. Hiện tượng sản phẩm vượt qua giả (false-passing product) gây ảnh hưởng như thế nào đến việc định vị lỗi bằng SBFL?

Sản phẩm vượt qua giả là sản phẩm thực tế chứa mã nguồn lỗi nhưng lại vượt qua toàn bộ ca kiểm thử do bộ kiểm thử có độ bao phủ thấp hoặc do các ca kiểm thử đạt ngẫu nhiên (trùng hợp đúng). Hiện tượng này làm sai lệch thống kê của SBFL:

• Ở mức sản phẩm: Làm giảm số lượng sản phẩm lỗi ($e_f$) và tăng số lượng sản phẩm đạt ($e_p$) chứa câu lệnh lỗi, khiến điểm nghi ngờ của câu lệnh lỗi bị đánh giá thấp hơn thực tế.
• Ở mức ca kiểm thử: Làm thiếu hụt số ca kiểm thử hỏng và gia tăng số ca kiểm thử đạt thực thi qua câu lệnh lỗi, khiến công cụ định vị lỗi xếp hạng sai vị trí của câu lệnh lỗi trong danh sách ưu tiên kiểm tra.

3. Nguyên lý hoạt động của công cụ VarCop trong định vị lỗi biến thể là gì?

VarCop thực hiện qua hai bước chính:

1. Phân tích kết quả kiểm thử của các sản phẩm mẫu để nhận diện Cấu hình bộ phận lỗi (Buggy PC) – tập hợp các lựa chọn tính năng gây ra sai hỏng. Từ đó, cô lập các câu lệnh liên quan đến tương tác giữa các tính năng này thành tập câu lệnh nghi ngờ.
2. Đánh giá và xếp hạng độ nghi ngờ của từng câu lệnh dựa trên hai tiêu chí: (i) Phổ kiểm thử mức sản phẩm (số lượng sản phẩm đạt/hỏng chứa câu lệnh) và (ii) Phổ kiểm thử mức ca kiểm thử trong chính các sản phẩm hỏng chứa câu lệnh đó.

4. Tại sao phương pháp sửa lỗi dựa trên sản phẩm ($ProdBased$) lại đạt hiệu quả cao hơn phương pháp dựa trên hệ thống ($SysBased$)?

Trong $SysBased$, mỗi bản vá ứng viên phải được kiểm chứng đồng thời trên toàn bộ các sản phẩm mẫu trong từng vòng lặp, dẫn đến không gian tìm kiếm bị ràng buộc quá chặt và chi phí kiểm thử rất lớn, làm quá trình tìm kiếm dễ rơi vào bế tắc hoặc hết thời gian. Trong khi đó, $ProdBased$ tập trung sửa chữa trên từng sản phẩm hỏng đơn lẻ để tìm bản vá cục bộ hợp lệ, sau đó mới lan truyền và kiểm chứng bản vá đó trên các sản phẩm còn lại. Kết hợp với các quy tắc suy nghiệm (điểm sửa chữa và độ phù hợp thao tác), $ProdBased$ đạt số lượng bản vá đúng cao hơn gấp khoảng 20 lần.

5. Hai quy tắc suy nghiệm được đề xuất trong luận án có vai trò gì trong việc cải thiện hiệu năng APR?

Hai quy tắc suy nghiệm gồm:

• Quy tắc định hướng điểm sửa đổi (Fixing Score): Sử dụng phản hồi từ kết quả kiểm thử trung gian để cập nhật động mức độ ưu tiên của vị trí sửa đổi trong mỗi vòng lặp, thay vì chỉ dựa vào điểm SBFL tĩnh ban đầu.
• Quy tắc đo lường độ phù hợp sửa đổi (Modification Suitability): Đánh giá độ tương đồng của thao tác sửa đổi với mã gốc và với các thao tác thành công/thất bại trước đó để loại bỏ sớm các thao tác không phù hợp trước khi chạy kiểm thử, giúp giảm 30% - 50% số phép thử vô ích và tăng 30% - 150% số bản vá đúng.

Kết luận

Luận án tiến sĩ của tác giả Nguyễn Thu Trang đã giải quyết một cách có hệ thống bài toán gỡ lỗi tự động cho hệ thống dòng sản phẩm phần mềm chịu ảnh hưởng bởi lỗi biến thể. Thông qua việc đề xuất phương pháp Clap để loại bỏ sai lệch từ sản phẩm vượt qua giả, công cụ VarCop để định vị chính xác câu lệnh lỗi dựa trên tương tác tính năng, cùng các giải pháp sửa lỗi tự động kết hợp quy tắc suy nghiệm $ProdBased_{enhanced}$ và $SysBased_{enhanced}$, luận án đã đóng góp những giải pháp kỹ thuật hoàn chỉnh và hiệu quả. Các kết quả thực nghiệm trên 1.570 phiên bản lỗi chứng minh tính đúng đắn và khả năng ứng dụng thực tiễn của các phương pháp đề xuất trong việc nâng cao chất lượng và độ tin cậy của các hệ thống phần mềm có khả năng cấu hình cao.

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

VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING AND TECHNOLOGY NGUYEN THU TRANG AUTOMATED LOCALIZATION AND REPAIR FOR VARIABILITY FAULTS IN SOFTWARE PRODUCT LINES DOCTOR OF PHILOSOPHY DISSERTATION Major: Software Engineering Hanoi - 2024 VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING AND TECHNOLOGY NGUYEN THU TRANG AUTOMATED LOCALIZATION AND REPAIR FOR VARIABILITY FAULTS IN SOFTWARE PRODUCT LINES DOCTOR OF PHILOSOPHY DISSERTATION Major: Software Engineering Code: 9480103 Supervisor: Dr. Vo Dinh Hieu Co-Supervisor: Assoc. Ho Si Dam Hanoi - 2024 VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING AND TECHNOLOGY NGUYEN THU TRANG Automated Localization and Repair for Variability Faults in Software Product Lines DOCTOR OF PHILOSOPHY DISSERTATION Major: Software Engineering Code: 9480103 Supervisor: Dr. Vo Dinh Hieu Co-Supervisor: Assoc.

Ho Si Dam PhD Candidate Supervisors VNU University of Engineering and Technology Hanoi - 2024 Acknowledgement I am deeply grateful to the following individuals and organizations for their invaluable support and encouragement throughout the journey of completing my doctoral disserta- tion. I would like to express my great appreciation to my supervisor, Dr. Vo Dinh Hieu, who is always willing to give me advice and comments on my problems. His constant support, guidance, and encouragement have been invaluable throughout the entire process.

I feel very fortunate to be a student under the supervision of Dr. Vo Dinh Hieu. I also would like to extend my sincere appreciation to my co-supervisor, Assoc. Ho Si Dam who gives me many valuable comments to improve my research and complete my dissertation.

I am grateful to Dr. Nguyen Van Son, who teaches me not only research skills but also presentation and writing skills. Without his expertise and encouragement, the completion of this dissertation would not have been possible. I would like to thank MSc.

Ngo Kien Tuan who is always willing to discuss with me and helps me a lot in conducting experiments. My gratitude also extends to my teachers at the Department of Software Engineering, Assoc. Pham Ngoc Hung, Assoc. Dang Duc Hanh, Dr.

Vu Thi Hong Nhan, my colleagues, and friends at UET-VNU. Without their knowledge and support, this dissertation would not have been successful. I am thankful to Vingroup Innovation Foundation (VINIF) and The Development Foun- dation of Vietnam National University, Hanoi for providing financial support for this research. Their investment in my academic pursuits has been crucial in enabling the successful completion of this dissertation.

Lastly, I want to express my deepest gratitude to my family, who stand by me with unwavering support, patience, and understanding. Their encouragement, love, and belief in my abilities sustained me through the challenges of this doctoral journey. Declaration I hereby declare that this Doctoral Dissertation was carried out by me for the degree of Doctor of Philosophy under the guidance and supervision of my supervisors. This dissertation is my own work and includes nothing, which is the outcome of work done in collaboration except as specified in the text.

It is not substantially the same as any I have submitted for a degree, diploma or other qualification at any other university; and no part has already been, or is currently being submitted for any degree, diploma or other qualification. Hanoi, August 2024 Author Nguyen Thu Trang i Abstract Software Product Line (SPL) systems are becoming popular and widely employed to de- velop large industrial projects. However, their inherent variability characteristics pose extreme challenges for assuring the quality of these systems. Although automated de- bugging in single-system engineering has been studied in-depth, debugging SPL systems remains mostly unexplored.

In practice, debugging activities in SPL systems are often performed manually in an ad-hoc manner. This dissertation sheds light on the automated debugging SPL systems by focusing on three fundamental tasks, including false-passing product detection, variability fault localization, and variability fault repair. First, this dissertation aims to improve the reliability of the test results by detecting false- passing products in SPL systems failed by variability bugs. Given a set of tested products of an SPL system, the proposed approach, Clap, collects failure indications in failing products based on their implementation and test quality.

For a passing product, Clap evaluates these indications, and the stronger the indications, the more likely the product is false-passing.