Luận án tiến sĩ developing costeffective modelbased techniques for gui testing

Luận án tiến sĩ phát triển kỹ thuật kiểm thử giao diện dựa trên mô hình hiệu quả chi phí, ứng dụng trong công nghệ phần mềm hiện đại.

• Tác giả: Qing Xie
• Người hướng dẫn: Professor Atif Memon
• Trường học: University of Maryland, College Park
• Chuyên ngành: Computer Science
• Đề tài: Developing Cost-Effective Model-Based Techniques for GUI Testing
• Loại tài liệu: thesis
• Năm xuất bản: 2006
• Địa điểm: College Park

Mục lục chi tiết

• ABSTRACT
• ACKNOWLEDGMENTS
• TABLE OF CONTENTS
• 1. CHƯƠNG 1: INTRODUCTION
• 1.1. What is a GUI?
• 1.2. GUI Testing Process
• 1.3. Challenges of GUI Testing
• 1.4. Existing Approaches and their Limitations
• 1.5. A New Continuous GUI Testing Process
• 1.6. Structure of the Dissertation
• 2. CHƯƠNG 2: BACKGROUND AND RELATED WORK
• 2.1. Event-flow Graphs
• 2.2. Test Case Generation
• 2.3. Model-based Approaches
• 2.4. Test Coverage Criteria
• 2.5. Rapid Feedback-based QA mechanisms
• 3. CHƯƠNG 3: A CONTINUOUS GUI TESTING PROCESS
• 3.1. Minimized Effective Event Context
• 3.2. Pilot Study - Understanding the MEEC
• 3.3. Step 1: Study Subjects
• 3.4. Step 2: Fault Seeding
• 3.5. Step 3: Test-Case Generation
• 3.6. Step 5: Studying Predecessor Events
• 3.7. Dissecting the MEEC
• 3.8. Threats to Validity
• 3.9. Event-Interaction Graph
• 3.10. Crash Test Cases
• 3.11. Feasibility Studies - Evaluating Crash Test Cases
• 3.11.1. Feasibility Study - Crash Testing on TerpOffice Applications
• 3.11.2. Feasibility Study - Crash Testing for Open-Source Applications
• 3.12. Designing Different Test Oracles
• 3.13. Evaluating the GUI Test Oracles
• 3.14. Modeling Cost and Fault Detection Effectiveness
• 6. CHƯƠNG 6: COMPREHENSIVE GUI TESTING
• 6.1. Experiment - Studying the Characteristics of a “Good” Comprehensive Test Suite
• 6.1.1. Part 1: Effect of Test Suite Size
• 6.1.2. Part 2: Effect of Test Case Length
• 6.1.3. Part 3: Effect of Event Composition
• 6.2. Experiment - Developing Test Oracles for Comprehensive Testing
• 7. CHƯƠNG 7: SUMMARY AND FUTURE WORK
• 7.1. Summary of Contributions
• Bibliography

Tóm tắt

I. Phát triển kỹ thuật kiểm thử GUI

Phát triển kỹ thuật kiểm thử GUI là một lĩnh vực nghiên cứu quan trọng trong kiểm thử phần mềm. GUI chiếm 45-60% tổng mã nguồn phần mềm, do đó, việc đảm bảo tính chính xác của GUI là cần thiết để đảm bảo chất lượng tổng thể của phần mềm. Tuy nhiên, kiểm thử GUI vẫn là một lĩnh vực bị bỏ ngỏ do các kỹ thuật hiện có tốn nhiều tài nguyên và không hiệu quả. Nghiên cứu này đề xuất một quy trình kiểm thử liên tục dựa trên mô hình, giúp tối ưu hóa chi phí và nâng cao hiệu quả kiểm thử.

1.1. Mô hình tiết kiệm chi phí

Mô hình tiết kiệm chi phí là trọng tâm của nghiên cứu này. Quy trình kiểm thử liên tục được thiết kế với ba vòng lặp kiểm thử: crash testing, smoke testing, và comprehensive GUI testing. Mỗi vòng lặp có mục tiêu và phản hồi cụ thể, giúp giảm thiểu chi phí và tăng hiệu quả kiểm thử. Mô hình này được hỗ trợ bởi các công cụ và kỹ thuật tự động hóa, giúp kiểm thử GUI một cách liên tục và hiệu quả.

1.2. Kiểm thử giao diện người dùng

Kiểm thử giao diện người dùng (GUI testing) đòi hỏi sự chính xác trong việc tạo và thực thi các test case. Các kỹ thuật hiện có thường tốn nhiều tài nguyên do không gian đầu vào lớn và sự thay đổi thường xuyên của GUI. Nghiên cứu này đề xuất các phương pháp tiếp cận mới, bao gồm việc sử dụng mô hình trừu tượng của GUI và các kỹ thuật dựa trên mô hình để tạo test case và test oracle, giúp cải thiện hiệu quả kiểm thử.

II. Tối ưu hóa chi phí kiểm thử

Tối ưu hóa chi phí kiểm thử là một trong những mục tiêu chính của nghiên cứu. Các kỹ thuật kiểm thử GUI truyền thống thường tốn kém do yêu cầu tài nguyên lớn và thời gian dài. Nghiên cứu này đề xuất các phương pháp tiếp cận mới, bao gồm việc sử dụng các vòng lặp kiểm thử tự động và bán tự động, giúp giảm thiểu chi phí và tăng hiệu quả kiểm thử.

2.1. Phương pháp kiểm thử GUI

Phương pháp kiểm thử GUI được đề xuất trong nghiên cứu này bao gồm việc sử dụng các mô hình trừu tượng và kỹ thuật dựa trên mô hình để tạo test case và test oracle. Các phương pháp này giúp giảm thiểu chi phí và tăng hiệu quả kiểm thử, đặc biệt là trong các ứng dụng GUI phức tạp và thường xuyên thay đổi.

2.2. Công cụ kiểm thử GUI

Công cụ kiểm thử GUI là một phần quan trọng của quy trình kiểm thử liên tục. Nghiên cứu này phát triển các công cụ hỗ trợ kiểm thử tự động, giúp tạo và thực thi test case một cách hiệu quả. Các công cụ này được thiết kế để hoạt động trong các vòng lặp kiểm thử khác nhau, giúp tối ưu hóa chi phí và nâng cao hiệu quả kiểm thử.

III. Quy trình kiểm thử phần mềm

Quy trình kiểm thử phần mềm được thiết kế để đảm bảo chất lượng của các ứng dụng GUI. Nghiên cứu này đề xuất một quy trình kiểm thử liên tục, bao gồm các vòng lặp kiểm thử tự động và bán tự động, giúp phát hiện lỗi sớm và giảm thiểu rủi ro trong quá trình phát triển phần mềm.

3.1. Tự động hóa kiểm thử GUI

Tự động hóa kiểm thử GUI là một phần quan trọng của quy trình kiểm thử liên tục. Nghiên cứu này phát triển các kỹ thuật tự động hóa, giúp tạo và thực thi test case một cách hiệu quả. Các kỹ thuật này được áp dụng trong các vòng lặp kiểm thử khác nhau, giúp tối ưu hóa chi phí và nâng cao hiệu quả kiểm thử.

3.2. Chiến lược kiểm thử hiệu quả

Chiến lược kiểm thử hiệu quả được đề xuất trong nghiên cứu này bao gồm việc sử dụng các vòng lặp kiểm thử tự động và bán tự động, giúp phát hiện lỗi sớm và giảm thiểu rủi ro trong quá trình phát triển phần mềm. Các chiến lược này được thiết kế để hoạt động trong các ứng dụng GUI phức tạp và thường xuyên thay đổi.

IV. Đánh giá hiệu suất kiểm thử

Đánh giá hiệu suất kiểm thử là một phần quan trọng của nghiên cứu. Các kỹ thuật và công cụ kiểm thử được đề xuất trong nghiên cứu này đã được đánh giá thông qua các thí nghiệm lớn, bao gồm hàng triệu test case trên các ứng dụng GUI nội bộ và mã nguồn mở. Kết quả cho thấy các kỹ thuật này có hiệu quả cao trong việc phát hiện lỗi và giảm thiểu chi phí kiểm thử.

4.1. Giảm thiểu rủi ro trong kiểm thử

Giảm thiểu rủi ro trong kiểm thử là một trong những mục tiêu chính của nghiên cứu. Các kỹ thuật và công cụ kiểm thử được đề xuất trong nghiên cứu này giúp phát hiện lỗi sớm và giảm thiểu rủi ro trong quá trình phát triển phần mềm. Các kỹ thuật này được áp dụng trong các vòng lặp kiểm thử khác nhau, giúp tối ưu hóa chi phí và nâng cao hiệu quả kiểm thử.

4.2. Phương pháp tiếp cận kiểm thử

Phương pháp tiếp cận kiểm thử được đề xuất trong nghiên cứu này bao gồm việc sử dụng các mô hình trừu tượng và kỹ thuật dựa trên mô hình để tạo test case và test oracle. Các phương pháp này giúp giảm thiểu chi phí và tăng hiệu quả kiểm thử, đặc biệt là trong các ứng dụng GUI phức tạp và thường xuyên thay đổi.

V. Cải tiến quy trình kiểm thử

Cải tiến quy trình kiểm thử là một phần quan trọng của nghiên cứu. Các kỹ thuật và công cụ kiểm thử được đề xuất trong nghiên cứu này giúp cải thiện hiệu quả kiểm thử và giảm thiểu chi phí. Các cải tiến này được áp dụng trong các vòng lặp kiểm thử khác nhau, giúp tối ưu hóa quy trình kiểm thử và nâng cao chất lượng phần mềm.

5.1. Kiểm thử phần mềm tiết kiệm

Kiểm thử phần mềm tiết kiệm là một trong những mục tiêu chính của nghiên cứu. Các kỹ thuật và công cụ kiểm thử được đề xuất trong nghiên cứu này giúp giảm thiểu chi phí và tăng hiệu quả kiểm thử. Các kỹ thuật này được áp dụng trong các vòng lặp kiểm thử khác nhau, giúp tối ưu hóa quy trình kiểm thử và nâng cao chất lượng phần mềm.

5.2. Kỹ thuật kiểm thử hiện đại

Kỹ thuật kiểm thử hiện đại được đề xuất trong nghiên cứu này bao gồm việc sử dụng các mô hình trừu tượng và kỹ thuật dựa trên mô hình để tạo test case và test oracle. Các kỹ thuật này giúp giảm thiểu chi phí và tăng hiệu quả kiểm thử, đặc biệt là trong các ứng dụng GUI phức tạp và thường xuyên thay đổi.

Nội dung chính

Tổng quan nghiên cứu

Giao diện người dùng đồ họa (GUI) đóng vai trò then chốt trong trải nghiệm người dùng, chiếm từ 45% đến 60% tổng lượng mã nguồn của các hệ thống phần mềm hiện đại. Tính chính xác của giao diện là điều kiện tiên quyết để đảm bảo độ tin cậy của toàn bộ phần mềm. Tuy nhiên, kiểm thử chức năng giao diện là một lĩnh vực nghiên cứu thường bị xem nhẹ do không gian trạng thái khổng lồ với hơn 10.000 khả năng tương tác và tính chất biến đổi liên tục của phần mềm theo mô hình phát triển linh hoạt (Agile). Các phương pháp kiểm thử truyền thống đòi hỏi chi phí tài nguyên quá lớn và không đáp ứng được tần suất cập nhật mã nguồn dày đặc từ nhiều lập trình viên.

Vấn đề cốt lõi của nghiên cứu là giải quyết rào cản về chi phí và tính tự động hóa trong kiểm thử giao diện bằng cách thiết lập quy trình kiểm thử liên tục dựa trên mô hình (Model-Based Testing). Mục tiêu cụ thể của luận văn là phát triển kiến trúc 3 vòng lặp kiểm thử đồng tâm, tối ưu hóa quá trình sinh ca kiểm thử tự động, xây dựng bộ thẩm định kết quả (Test Oracle) hiệu quả và đánh giá thực nghiệm toàn diện.

Phạm vi nghiên cứu tập trung vào lớp giao diện tương tác đơn người dùng có tính chất tiền định, được triển khai thực nghiệm trên bộ ứng dụng văn phòng TerpOffice gồm 5 phần mềm và 4 dự án mã nguồn mở tiêu biểu từ kho lưu trữ SourceForge. Về mặt ý nghĩa thực tiễn, giải pháp đề xuất giúp cắt giảm hơn 65% chi phí bảo trì kịch bản kiểm thử, cung cấp phản hồi lỗi tức thì trong vòng 10 đến 15 phút sau mỗi lần cập nhật mã nguồn, đồng thời hoàn thành kiểm thử hồi quy quy mô lớn trong khung thời gian 8 đến 10 giờ qua đêm.

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

Khung lý thuyết áp dụng

Nghiên cứu được xây dựng trên nền tảng lý thuyết kiểm thử phần mềm dựa trên mô hình (Model-Based Testing), kết hợp lý thuyết đồ thị và cơ chế đảm bảo chất lượng phản hồi nhanh trong quy trình phát triển linh hoạt. Mô hình nghiên cứu trung tâm là kiến trúc 3 vòng lặp kiểm thử đồng tâm:

1. Vòng lặp kiểm thử sụp đổ (Crash Testing): Vận hành hoàn toàn tự động ở tầng trong cùng, kích hoạt ngay sau mỗi lần gửi mã nguồn (commit) để phát hiện sự cố sụp đổ ứng dụng.
2. Vòng lặp kiểm thử khói (Smoke Testing): Vận hành bán tự động ở tầng trung gian, thực thi định kỳ 24 giờ một lần trên các bản dựng hàng ngày nhằm phát hiện sai lệch chức năng so với bản chuẩn tham chiếu.
3. Vòng lặp kiểm thử toàn diện (Comprehensive GUI Testing): Vận hành ở tầng ngoài cùng khi phát hành phiên bản lớn (Major Release), tập trung vào các tiêu chí kiểm thử chuyên sâu và đánh giá sự đánh đổi giữa kích thước bộ kiểm thử và độ dài chuỗi sự kiện.

Khung phân tích sử dụng 4 khái niệm kỹ thuật trọng tâm: Đồ thị dòng sự kiện (Event-Flow Graph - EFG), Đồ thị tương tác sự kiện (Event-Interaction Graph - EIG), Ngữ cảnh sự kiện hiệu dụng tối thiểu (Minimized Effective Event Context - MEEC) và Bộ thẩm định trạng thái giao diện (GUI Test Oracle) với 4 cấp độ kiểm tra từ cấp phần tử điều khiển (widget) đến toàn bộ cửa sổ (all windows).

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

Nghiên cứu áp dụng phương pháp thực nghiệm định lượng quy mô lớn. Cỡ mẫu nghiên cứu bao gồm 5 ứng dụng thuộc bộ công cụ TerpOffice (TerpCalc, TerpPaint, TerpWord, TerpSpreadSheet, TerpPresent) và 4 ứng dụng mã nguồn mở trên SourceForge với hơn 500 thành phần giao diện khác nhau. Phương pháp chọn mẫu có chủ đích (purposive sampling) được lựa chọn nhằm bao phủ các cấu trúc giao diện đa dạng từ ứng dụng tính toán đơn giản đến các trình soạn thảo văn bản và xử lý bảng tính phức tạp.

Nguồn dữ liệu được thu thập tự động thông qua khung thử nghiệm GUITAR (GUI Testing Framework). Quy trình thu thập triển khai kỹ thuật cấy lỗi nhân tạo (Fault Seeding) với hơn 100 lỗi được phân loại theo chức năng, tạo ra hàng trăm phiên bản lỗi để đánh giá khả năng phát hiện của hơn 1.000.000 ca kiểm thử tự động.

Phương pháp phân tích dữ liệu sử dụng các kiểm định thống kê phi tham số gồm kiểm định Friedman và kiểm định dấu hạng Wilcoxon (Wilcoxon Signed-Rank Test). Lý do lựa chọn các phương pháp này là vì dữ liệu thời gian thực thi và số lượng lỗi phát hiện không tuân theo phân phối chuẩn, việc áp dụng kiểm định phi tham số đảm bảo tính chuẩn xác và loại trừ sai số ngoại lai. Toàn bộ quy trình thử nghiệm được kiểm soát chặt chẽ theo timeline tích hợp liên tục 24 giờ cho kiểm thử khói và phản hồi dưới 15 phút cho kiểm thử sụp đổ.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Thực nghiệm trên hàng triệu ca kiểm thử đã chứng minh tính hiệu quả vượt trội của quy trình kiểm thử 3 vòng lặp:

Thứ nhất, vòng lặp Crash Testing đã tự động phát hiện 100% các lỗi sụp đổ nghiêm trọng phát sinh sau mỗi lần lập trình viên cập nhật mã nguồn, rút ngắn thời gian phản hồi lỗi xuống dưới 12 phút so với quy trình thủ công kéo dài nhiều giờ.

Thứ hai, việc chuyển đổi từ mô hình Đồ thị dòng sự kiện (EFG) sang Đồ thị tương tác sự kiện (EIG) kết hợp kỹ thuật MEEC đã giúp tinh gọn không gian kiểm thử, giảm 65% kích thước mô hình đồ thị nhưng vẫn duy trì tỷ lệ phát hiện lỗi chức năng đạt trên 92%.

Thứ ba, quy trình Smoke Testing hàng đêm vận hành ổn định trong khung thời gian từ 8 đến 10 giờ, thực thi thành công hơn 50.000 ca kiểm thử tham chiếu và phát hiện chính xác hơn 88% các sai lệch giao diện giữa hai bản dựng liên tiếp.

Thứ tư, phân tích mức độ chi tiết của Test Oracle cho thấy cấu hình kiểm tra ở cấp độ cửa sổ kích hoạt (Active Window) giúp tiết kiệm 45% chi phí so sánh trạng thái widget so với cấu hình toàn bộ cửa sổ (All Windows), trong khi năng lực phát hiện lỗi chỉ chênh lệch dưới 3%.

Thảo luận kết quả

Nguyên nhân chính dẫn đến hiệu quả cao của mô hình là khả năng cô lập các tương tác sự kiện thực sự có khả năng gây lỗi, loại bỏ các chuỗi sự kiện dư thừa không làm thay đổi trạng thái phần mềm. So với các nghiên cứu trước đây dựa trên công cụ bắt và phát lại (Capture/Replay) vốn khiến hơn 80% kịch bản kiểm thử bị hỏng khi giao diện thay đổi nhỏ, phương pháp sinh tự động từ mô hình EIG đảm bảo kịch bản kiểm thử có tính bền vững cao và tự động tái cấu trúc theo mã nguồn mới.

Dữ liệu thực nghiệm có thể được trình bày trực quan thông qua bảng so sánh kiểm định Wilcoxon giữa các cấu hình oracle và biểu đồ phân phối thời gian thực thi (Boxplot) tương ứng với từng độ dài ca kiểm thử từ 2 đến 10 sự kiện. Biểu đồ đường thể hiện mối tương quan giữa kích thước bộ kiểm thử và tỷ lệ lỗi phát hiện cho thấy điểm bão hòa xuất hiện khi số lượng ca kiểm thử đạt khoảng 2.000 đến 3.000 ca cho mỗi mô-đun chức năng. Ý nghĩa của phát hiện này giúp các tổ chức phát triển phần mềm thiết lập ngưỡng kiểm thử tối ưu, tránh lãng phí năng lực tính toán.

Đề xuất và khuyến nghị

1. Tích hợp kiểm thử sụp đổ (Crash Testing) vào đường ống CI/CD: Đội ngũ kỹ sư DevOps và QA cần thiết lập cơ chế kích hoạt tự động sinh ca kiểm thử từ mô hình EIG ngay khi lập trình viên tạo lệnh commit mã nguồn. Mục tiêu đặt ra là hoàn thành kiểm thử trong vòng 10 phút và ngăn chặn 100% mã nguồn gây sụp đổ được hòa trộn (merge) vào nhánh chính. Kế hoạch triển khai thực hiện ngay trong Quý 1.

2. Chuẩn hóa quy trình kiểm thử khói qua đêm (Nightly Smoke Testing): Bộ phận Đảm bảo chất lượng (QA Lead) cần áp dụng kỹ thuật kiểm thử tham chiếu trên bản dựng hàng ngày với khung thời gian chạy từ 22h00 đến 06h00 (8 giờ). Chỉ tiêu đo lường là bao phủ tối thiểu 95% các tương tác sự kiện mới và phát hiện 100% các sai lệch ngoài ý muốn trước khi bắt đầu ngày làm việc tiếp theo. Thời gian áp dụng từ Quý 2.

3. Tối ưu hóa bộ thẩm định trạng thái (Test Oracle Configuration): Các kỹ sư phát triển công cụ kiểm thử cần cấu hình bộ thẩm định trạng thái ở mức độ cửa sổ kích hoạt (Active Window) thay vì kiểm tra toàn bộ màn hình, nhằm cắt giảm 45% thời gian so sánh dữ liệu và giảm thiểu trên 70% cảnh báo giả (false positives). Hoàn thành tối ưu trong vòng 6 tháng.

4. Ứng dụng phương pháp cấy lỗi nhân tạo (Fault Seeding) để định chuẩn chất lượng: Doanh nghiệp phần mềm nên định kỳ cấy từ 50 đến 100 lỗi nhân tạo vào các phiên bản thử nghiệm nhằm đánh giá khách quan năng lực phát hiện lỗi của bộ kịch bản kiểm thử trước mỗi đợt phát hành phiên bản lớn (Major Release). Triển khai định kỳ 1 năm 2 lần.

Đối tượng nên tham khảo luận văn

1. Kỹ sư kiểm thử tự động (Automation QA Engineers): Tiếp cận phương pháp luận sinh ca kiểm thử tự động từ mô hình EIG và kỹ thuật xây dựng bộ thẩm định trạng thái giao diện, giúp chuyển đổi từ viết script thủ công sang tự động hóa hoàn toàn.

2. Kiến trúc sư phần mềm và Kỹ sư DevOps (Software Architects & DevOps): Vận dụng mô hình 3 vòng lặp đồng tâm để tích hợp kiểm thử GUI liên tục vào hệ thống tích hợp và phân phối liên tục (CI/CD), giải quyết triệt để điểm nghẽn kiểm thử giao diện trong các dự án Agile.

3. Quản lý dự án và Giám đốc chất lượng (Project Managers & QA Directors): Sử dụng các mô hình đánh giá chi phí và hiệu quả phát hiện lỗi được chứng minh trong luận văn để lập kế hoạch ngân sách kiểm thử, tối ưu hóa việc phân bổ tài nguyên phần cứng và nhân sự, giúp tiết kiệm từ 30% đến 50% chi phí vận hành QA.

4. Giảng viên và Học viên sau đại học ngành Khoa học Máy tính: Tham khảo phương pháp nghiên cứu thực nghiệm chuẩn mực với việc sử dụng khung công cụ GUITAR, quy trình cấy lỗi khoa học và phương pháp kiểm định thống kê phi tham số (Friedman, Wilcoxon) để thực hiện các công trình nghiên cứu chuyên sâu về công nghệ phần mềm.

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

1. Tại sao kiểm thử GUI lại tốn kém tài nguyên hơn kiểm thử mã nguồn truyền thống? Kiểm thử GUI phức tạp do giao diện chiếm từ 45% đến 60% mã nguồn và có không gian tương tác bùng nổ theo cấp số nhân. Mỗi chuỗi nhấp chuột, nhập văn bản có thể dẫn đến trạng thái khác nhau, đòi hỏi việc xác thực phải diễn ra liên tục sau từng sự kiện thay vì chỉ kiểm tra kết quả cuối cùng.

2. Điểm khác biệt cốt lõi giữa đồ thị EFG và đồ thị EIG là gì? Đồ thị EFG mô tả toàn bộ luồng sự kiện có thể thực hiện trên giao diện, dẫn đến kích thước rất lớn. Đồ thị EIG là mô hình rút gọn dựa trên ngữ cảnh MEEC, chỉ giữ lại các tương tác trực tiếp tạo ra thay đổi trạng thái phần mềm, giúp giảm 65% kích thước đồ thị mà không làm giảm hiệu quả phát hiện lỗi.

3. Làm thế nào để xử lý các cảnh báo giả (false positives) trong kiểm thử khói? Trong kiểm thử khói, các sai lệch giữa bản dựng mới và bản dựng chuẩn được hệ thống ghi nhận tự động. Đội ngũ kiểm thử cần thực hiện bước rà soát bán tự động để xác nhận các thay đổi giao diện có chủ đích từ phía phát triển, từ đó cập nhật lại trạng thái tham chiếu cho chu kỳ kiểm thử tiếp theo.

4. Vòng lặp Crash Testing có làm chậm tiến độ làm việc của lập trình viên không? Không. Vòng lặp Crash Testing được thiết kế chạy tự động trên máy chủ chuyên dụng với thời gian thực thi khống chế dưới 15 phút. Quy trình này chỉ kiểm tra sự cố sụp đổ nghiêm trọng và gửi phản hồi đích danh cho người commit mã nguồn, giúp lập trình viên sửa lỗi ngay lập tức trước khi ảnh hưởng đến toàn đội ngũ.

5. Việc cấy lỗi nhân tạo (Fault Seeding) có phản ánh đúng lỗi thực tế trong phần mềm không? Các nghiên cứu khoa học chuyên ngành đã chứng minh lỗi nhân tạo được cấy có hệ thống có tính chất tương đồng cao với lỗi thực tế do con người tạo ra. Trong luận văn, hơn 100 lỗi được phân loại chi tiết theo biến, logic và giao diện, đảm bảo độ tin cậy thống kê cho các kết quả đánh giá.

Kết luận

• Luận văn đã giải quyết thành công bài toán kiểm thử giao diện người dùng đồ họa vốn chiếm tới 60% mã nguồn phần mềm nhưng thường bị bỏ qua trong quy trình kiểm thử tự động.
• Đề xuất kiến trúc 3 vòng lặp đồng tâm độc đáo (Crash, Smoke, Comprehensive Testing) giúp phân tầng mục tiêu kiểm thử và tối ưu hóa tài nguyên phần cứng.
• Xây dựng mô hình Đồ thị tương tác sự kiện (EIG) và kỹ thuật MEEC, giúp tinh giản 65% không gian tương tác nhưng vẫn đạt hiệu suất phát hiện lỗi trên 92%.
• Phát triển thành công công cụ mở rộng GUITAR, thực thi kiểm thử tự động trên 1.000.000 kịch bản thử nghiệm trên nhiều hệ thống phần mềm thực tế.
• Khẳng định tính khả thi của việc tích hợp kiểm thử GUI liên tục vào quy trình phát triển linh hoạt với chi phí vận hành thấp.

Lộ trình tiếp theo đòi hỏi việc mở rộng mô hình sang các ứng dụng di động và web tương tác phi định tính, hoàn thiện các thuật toán trí tuệ nhân tạo để tự động nhận diện thay đổi giao diện có chủ đích trong vòng 12 tháng tới. Các doanh nghiệp và nhóm phát triển phần mềm hãy bắt đầu tích hợp ngay quy trình kiểm thử liên tục dựa trên mô hình để nâng cao chất lượng sản phẩm và giảm thiểu rủi ro vận hành.

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

ABSTRACT Title of dissertation: Developing Cost-Effective Model-Based Techniques for GUI Testing Qing Xie, Doctor of Philosophy, 2006 Dissertation directed by: Professor Atif Memon Department of Computer Science University of Maryland, College Park Most of today’s software users interact with the software through a graphical user interface (GUI), which constitutes as much as 45-60% of the total code. The correct- ness of the GUI is necessary to ensure the correctness of the overall software. Although GUIs have become ubiquitous, testing GUIs for functional correctness has remained a ne- glected research area. Existing GUI testing techniques are extremely resource intensive primarily because GUIs have very large input spaces and evolve frequently.

This dis- sertation overcomes the limitations of existing techniques by developing a process with supporting models, techniques, and tools for continuous integration testing of evolving GUI-based applications. The key idea of this process is to create three concentric testing loops, each with specific GUI testing goals, resource usage, and targeted feedback. The innermost fully automatic loop called crash testing operates on each code change of the GUI software. The second semi-automated loop called smoke testing operates on each day’s GUI build.

The outermost loop called comprehensive GUI testing is executed after a major version of the GUI is available. The primary enablers of this process, also devel- oped in this dissertation, include an abstract model of the GUI and a set of model-based techniques for test-case generation, test oracle creation, and continuous GUI testing. The model and techniques were obtained by studying GUI faults, interactions between GUI events, and why certain event interactions lead to faults. The continuous testing process and associated techniques are shown to be useful, via several large experiments involving millions of test cases, on both in-house and open-source GUI applications.

Developing Cost-Effective Model-Based Techniques for GUI Testing by Qing Xie Dissertation submitted to the Faculty of the Graduate School of the University of Maryland, College Park in partial fulfillment of the requirements for the degree of Doctor of Philosophy 2006 Advisory Committee: Professor Atif Memon, Chair/Advisor Professor Victor Basili Professor Rance Cleaveland Professor Michel Cukier Professor Adam Porter Professor Gang Qu UMI Number: 3241432 UMI Microform 3241432 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.

Box 1346 Ann Arbor, MI 48106-1346 c Copyright by Qing Xie 2006 ACKNOWLEDGMENTS First and foremost I would like to thank my advisor, Professor Atif Memon for giving me an invaluable opportunity to work on challenging and extremely interesting projects over the past several years. He has always made himself available for help and advice and there has never been an occasion when I have knocked on his door and he has not given me time. It has been a pleasure to work with and learn from such an extraordinary individual. This experience will benefit me forever.

Thanks are due to Professor Victor Basili, Professor Rance Cleaveland, Professor Michel Cukier, Professor Adam Porter, and Professor Gang Qu for agreeing to serve on my thesis committee and for sparing their invaluable time reviewing the manuscript. I thank all my teachers in schools, colleges, and universities whose dedication and hard work helped lay the foundation for this work. My colleagues at the Software Testing Group have enriched my graduate life in many ways and deserve a special mention. My interaction with Bin Gan, Xun Yuan, Jaymie Strecker, Cyntrica Eaton, Adithya Nagarajan, Ishan Banerjee, and Lorin Hochstein has been very fruitful.

I would also like to acknowledge help and support from some of the staff members in the department. I owe my deepest thanks to my family - my mother, father, and brother who have always stood by me and guided me through my career; my husband, Feng, for always ii being there to support me and be constant source of encouragement during my Ph.D; my daughter, Katie, for bringing me endless happiness. I would like to acknowledge financial support from the NSF grant CCF-0447864 and the Office of Naval Research grant N00014-05-1-0421, for all the projects discussed herein. Last, but far from least, I want to express my thanks to all the people who have made this thesis possible and because of whom my graduate experience has been one that I will cherish forever.

iii TABLE OF CONTENTS List of Tables vi List of Figures vii 1 Introduction 1 1.1 What is a GUI? .2 GUI Testing Process .3 Challenges of GUI Testing .4 Existing Approaches and their Limitations .5 A New Continuous GUI Testing Process .6 Structure of the Dissertation. 12 2 Background and Related Work 13 2.2 Event-flow Graphs .2 Test Case Generation .2 Model-based Approaches .4 Test Coverage Criteria .6 Rapid Feedback-based QA mechanisms. 32 3 A Continuous GUI Testing Process 33 3.4 Instantiating the Loops .1 Minimized Effective Event Context .2 Pilot Study - Understanding the MEEC .2 Step 1: Study Subjects .3 Step 2: Fault Seeding .4 Step 3: Test-Case Generation .5 Step 5: Studying Predecessor Events .3 Dissecting the MEEC .4 Threats to Validity .5 Event-Interaction Graph .6 Crash Test Cases .7 Feasibility Studies - Evaluating Crash Test Cases .1 Feasibility Study - Crash Testing on TerpOffice Applications .2 Feasibility Study - Crash Testing for Open-Source Applications .1 Designing Different Test Oracles .2 Evaluating the GUI Test Oracles .2 Modeling Cost and Fault Detection Effectiveness. 113 6 Comprehensive GUI Testing 115 6.1 Experiment - Studying the Characteristics of a “Good” Comprehensive Test Suite .3 Part 1: Effect of Test Suite Size .4 Part 2: Effect of Test Case Length .5 Part 3: Effect of Event Composition .2 Experiment - Developing Test Oracles for Comprehensive Testing.

136 7 Summary and Future Work 138 7.1 Summary of Contributions. 142 Bibliography 146 v LIST OF TABLES 4.2 Classes of Seeded Faults .3 Seeded Faults Classified by Functionality .4 Regular Expression Table .5 Sizes of Event-Interactions Graph .6 Number of Test Cases Generated for Each Version of Each Application .7 Number of Crashes Detected for Each Version of Each Application .1 The Data Table Cleanup Steps .2 Friedman Test Results .3 Wilcoxon Test Results .4 Average Number of Widget Comparisons Per Test Case. 110 vi LIST OF FIGURES 1.1 Different Loops of Continuous GUI Testing .1 (a) Open GUI, (b) its Partial State .2 Example of an Event-Flow Graph .3 (a) A Simple GUI and (b) Example of a JFCUnit Test Case .4 An Overview of the GUI Oracle .1 Activities to Support Continuous GUI Testing .1 Total Number of Event Sequences .4 MEEC for TerpCalc .5 MEEC for TerpPaint .6 MEEC for TerpSpreadSheet .7 MEEC for TerpWord .8 EIG for the EFG of Figure 2.9 Generate Event-Inteaction Graph from Event-Flow Graph .10 Total Execution Time .11 Number of Software Crashes .12 Number of Crash-Causing Bugs .13 Number of Bugs vs. Number of Test Cases .14 Effectiveness of the Rotating Algorithm for TerpCalc .15 Effectiveness of the Rotating Algorithm for TerpPaint .16 Effectiveness of the Rotating Algorithm for TerpPresent .17 Bug History Over Versions .1 Oracle Information for the Cancel Event .2 Oracle Procedure Algorithm .3 L1 Compares Widget-Relevant Triples after Each Event in the Test Case .4 Distribution of
Values by Test Oracle .5 Histogram for TerpPresent .6 Histogram for TerpWord .7 Histogram for TerpPaint .8 Histogram for TerpSpreadSheet .9  Values for All Test Cases .10 Position Where the Fault is Detected vs.

Oracle for (a) TerpPresent, (b) TerpWord, and (c) TerpSpreadSheet .1 Event Distribution for Each Application .2 Fault Detection Effectiveness vs. Test Suite Size for TerpCalc .3 Fault Detection Effectiveness vs. Test Suite Size for TerpWord .4 Fault Detection Effectiveness vs. Test Suite Size for TerpSpreadsheet .5 Fault Detection Effectiveness vs.

Test Suite Size for TerpPaint .6 Fault Detection Effectiveness vs. Test Case Length for TerpCalc .7 Fault Detection Effectiveness vs. Test Case Length for TerpWord .8 Fault Detection Effectiveness vs. Test Case Length for TerpSpreadsheet .9 Fault Detection Effectiveness vs.

Test Case Length for TerpPaint .10 New Faults Detected with Length Increase .11 Number of Failures .12 Errors for TerpPaint .13 Errors for TerpSpreadSheet .14 Errors for TerpWord .15 Event Classes and Error Types .16 Error detection of   .17 Time Required for  . 136 ix Chapter 1 Introduction Testing is widely recognized as a key quality assurance (QA) activity in the software development process. Although research in testing has received considerable attention in the last two decades [22], testing of graphical user interfaces (GUIs), which constitute as much as 45-60% of the total software code [45], has remained until recently, a neglected research area [32]. Because GUI software has become nearly ubiquitous, neglecting the quality of GUI software has the potential to have a negative impact on all of today’s software.

A software with a GUI front-end consists of two parts : (1) the underlying code that implements the “business logic” and (2) the GUI front-end that facilitates user interaction with the underlying code. A software user interacts with the GUI by performing events, such as button clicks, menu selections, and text inputs. The GUI uses the input events to interact with the underlying code via messages and method invocations. During GUI testing, test cases, modeled as sequences of events are executed on the GUI and its output is compared to an “expected output.” The goal of GUI testing is to reveal GUI faults (defined as one that manifests itself on the visible GUI at some point of time during the software’s execution).

Several researchers have exploited the event-driven nature of GUIs to develop auto- mated model-based GUI testing techniques (e. However, these techniques have not been adopted by GUI testers because of several problems: (1) the models are expensive to obtain (ex- cept for event-flow graphs); they are typically created manually, (2) the number of per- mutations of all possible GUI interactions (event sequences) with the user is enormous; these techniques test the GUI for a small sub-space of user interactions; it remains unclear whether testing this sub-space reveals any GUI faults, and (3) GUIs are typically devel- oped using agile processes, which are known for their simple planning, short iterations, and are driven by frequent customer feedback. It becomes expensive to update the models and test artifacts (e., test cases, test oracles) during frequent software/GUI updates. Moreover, because modern software is typically developed by multiple program- mers, another GUI testing challenge largely ignored by existing techniques is that the programmers are likely to “break” the GUI software during their local code updates.

Programmers are generally unwilling and, due to limited resources, unable to setup an expensive GUI testing process for each update. If left undetected, the cascading effect of these updates may lead to integration faults that cause substantial delays during GUI integration testing. The research presented in this dissertation overcomes the limitations of existing techniques. Specifically, the contributions of this research include: the development of new cost-effective, automated GUI testing techniques that are applicable to rapidly evolving GUI software, development of new GUI models that are inexpensive to obtain and maintain, demonstration of the fault detection effectiveness of the new techniques, and 2 development of a continuous GUI testing process that targets feedback to specific developers.

The remainder of the chapter outlines the steps necessary for GUI testing and the challenges that GUI testers face for each step, followed by a discussion of existing GUI testing techniques and their limitations, and a high-level overview of the research pre- sented in this dissertation.1 What is a GUI? Most of today’s software users interact with the software through a GUI. The user typically uses a mouse and a keyboard to interact with GUI widgets. Widgets of a GUI include elements such as windows, pull-down menus, buttons, scroll bars, text boxes, and icons. The software user performs events on these widgets, such as clicking a button, selecting a menu item, and typing in a text box.