Luận án tiến sĩ: Phát triển kỹ thuật kiểm thử GUI hiệu quả (2006)
Luận án phát triển kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình. Đề xuất quy trình kiểm thử liên tục với ba vòng lặp: tự động, bán tự động và toàn diện.
University of Maryland, College Park
Luan An
Luận án
Năm xuất bản
Số trang
166
Thời gian đọc
25 phút
Lượt xem
0
Lượt tải
0
Phí lưu trữ
50 Point
Tổng quan nhanh
- Chủ đề:
- 1. Kiểm Thử GUI Dựa Trên Mô Hình - Tổng Quan
- Số trang:
- 166 trang
- Trường:
- University of Maryland, College Park
- Chuyên ngành:
- Computer Science
- Tác giả:
- Qing Xie
- Năm:
- 2006
Tóm tắt nội dung luận án
I. Kiểm Thử GUI Dựa Trên Mô Hình Tổng Quan
Giao diện đồ họa người dùng (GUI) chiếm 45-60% tổng mã nguồn phần mềm hiện đại. Tính đúng đắn của GUI quyết định chất lượng tổng thể của ứng dụng. Nghiên cứu của Qing Xie tập trung phát triển kỹ thuật kiểm thử GUI hiệu quả về chi phí thông qua phương pháp model-based testing. Luận án giải quyết thách thức lớn nhất: không gian đầu vào khổng lồ và sự thay đổi liên tục của GUI. Phương pháp truyền thống tốn kém tài nguyên và không theo kịp tốc độ phát triển phần mềm. Giải pháp đề xuất tạo ra quy trình kiểm thử tích hợp liên tục với ba vòng lặp đồng tâm. Mỗi vòng lặp có mục tiêu, tài nguyên và phản hồi riêng biệt. Cốt lõi là mô hình trừu tượng của GUI và các kỹ thuật sinh test case tự động. Nghiên cứu dựa trên phân tích lỗi GUI thực tế, tương tác giữa các sự kiện, và nguyên nhân dẫn đến lỗi.
1.1. Tầm Quan Trọng Của GUI Testing
GUI là điểm tiếp xúc chính giữa người dùng và phần mềm. Lỗi GUI ảnh hưởng trực tiếp đến trải nghiệm người dùng và độ tin cậy hệ thống. Tỷ lệ mã GUI cao trong ứng dụng hiện đại tạo ra bề mặt tấn công lớn cho lỗi. Kiểm thử GUI đảm bảo chức năng hoạt động đúng trong mọi tình huống. Phương pháp thủ công không khả thi với quy mô và độ phức tạp hiện nay.
1.2. Thách Thức Chính Trong GUI Testing
Không gian đầu vào của GUI cực kỳ lớn do số lượng sự kiện và chuỗi tương tác khả dĩ. GUI thay đổi thường xuyên theo yêu cầu nghiệp vụ và thiết kế. Test case cần cập nhật liên tục để phù hợp với phiên bản mới. Tài nguyên kiểm thử hạn chế không đủ để bao phủ toàn bộ. Kỹ thuật hiện tại tốn nhiều công sức và thời gian thực thi.
1.3. Đóng Góp Chính Của Nghiên Cứu
Quy trình kiểm thử tích hợp liên tục với ba vòng lặp tự động hóa. Mô hình trừu tượng GUI hỗ trợ sinh test case hiệu quả. Kỹ thuật model-based testing giảm chi phí và tăng độ bao phủ. Công cụ tự động hóa cho crash testing, smoke testing và comprehensive testing. Thực nghiệm trên hàng triệu test case với ứng dụng thực tế.
II. Quy Trình Kiểm Thử GUI Liên Tục Ba Vòng Lặp
Quy trình đề xuất tổ chức thành ba vòng lặp đồng tâm với mức độ tự động hóa khác nhau. Vòng trong cùng là crash testing, hoàn toàn tự động, chạy sau mỗi thay đổi mã. Vòng giữa là smoke testing, bán tự động, thực thi trên build hàng ngày. Vòng ngoài cùng là comprehensive GUI testing, chạy sau mỗi phiên bản chính. Thiết kế này cân bằng giữa tốc độ phản hồi và độ bao phủ kiểm thử. Mỗi vòng lặp có mục tiêu cụ thể và sử dụng tài nguyên phù hợp. Phản hồi nhanh từ vòng trong giúp phát hiện lỗi sớm. Vòng ngoài đảm bảo chất lượng tổng thể trước khi phát hành. Quy trình tích hợp liền mạch vào chu trình phát triển phần mềm.
2.1. Crash Testing Vòng Lặp Tự Động Hoàn Toàn
Crash testing chạy tự động sau mỗi lần commit mã nguồn. Mục tiêu phát hiện lỗi crash và exception nghiêm trọng ngay lập tức. Sử dụng test case ngắn với độ bao phủ cơ bản. Thời gian thực thi nhanh để không làm gián đoạn quy trình phát triển. Phản hồi tức thì giúp lập trình viên sửa lỗi khi còn nhớ rõ thay đổi. Tự động hóa hoàn toàn không cần can thiệp thủ công.
2.2. Smoke Testing Vòng Lặp Bán Tự Động
Smoke testing thực thi trên build tích hợp hàng ngày. Kiểm tra các chức năng chính và kịch bản quan trọng. Độ bao phủ rộng hơn crash testing nhưng không đầy đủ. Kết hợp test case tự động sinh và test case thủ công. Thời gian chạy vài giờ, phù hợp với chu kỳ build đêm. Cung cấp báo cáo chi tiết về tình trạng build.
2.3. Comprehensive Testing Kiểm Thử Toàn Diện
Comprehensive GUI testing chạy trước mỗi bản phát hành chính. Bao phủ toàn bộ chức năng và kịch bản phức tạp. Sử dụng event-flow graph để sinh test case đầy đủ. Thời gian thực thi dài, có thể kéo dài vài ngày. Đảm bảo chất lượng cao nhất trước khi giao sản phẩm. Kết hợp nhiều tiêu chí bao phủ khác nhau.
III. Mô Hình Event Flow Graph Cho GUI Testing
Event-flow graph là mô hình trừu tượng cốt lõi của phương pháp đề xuất. Đồ thị biểu diễn các sự kiện GUI và quan hệ phụ thuộc giữa chúng. Mỗi nút trong đồ thị đại diện cho một sự kiện người dùng. Cạnh nối giữa các nút thể hiện trình tự thực thi khả dĩ. Mô hình này nắm bắt cấu trúc và hành vi của GUI. Cho phép phân tích tương tác giữa các sự kiện một cách hệ thống. Hỗ trợ sinh test case tự động dựa trên các tiêu chí bao phủ. Dễ dàng cập nhật khi GUI thay đổi. Giảm thiểu công sức bảo trì test suite. Tạo nền tảng cho các kỹ thuật test case generation tiên tiến.
3.1. Cấu Trúc Của Event Flow Graph
Đồ thị luồng sự kiện bao gồm các nút sự kiện và cạnh quan hệ. Mỗi sự kiện có thuộc tính như loại widget, hành động, và điều kiện tiên quyết. Cạnh mô tả khả năng thực thi sự kiện kế tiếp sau sự kiện hiện tại. Đồ thị có nút bắt đầu và có thể có nhiều nút kết thúc. Cấu trúc phân cấp phản ánh tổ chức cửa sổ và dialog trong GUI.
3.2. Xây Dựng Event Flow Graph Tự Động
Công cụ tự động phân tích mã nguồn và giao diện GUI. Trích xuất danh sách sự kiện từ định nghĩa widget và event handler. Xác định quan hệ phụ thuộc dựa trên cấu trúc mã và luồng điều khiển. Tạo đồ thị ban đầu với các cạnh khả dĩ. Tinh chỉnh đồ thị bằng cách loại bỏ cạnh không khả thi. Cập nhật tự động khi GUI thay đổi.
3.3. Ứng Dụng Mô Hình Trong Test Generation
Event-flow graph là đầu vào cho thuật toán sinh test case. Duyệt đồ thị theo các tiêu chí bao phủ khác nhau. Tạo chuỗi sự kiện tương ứng với đường đi trong đồ thị. Mỗi test case là một đường đi từ nút bắt đầu đến nút kết thúc. Độ dài và độ phức tạp test case điều chỉnh theo mục tiêu kiểm thử. Hỗ trợ nhiều chiến lược sinh test case khác nhau.
IV. Kỹ Thuật Sinh Test Case Tự Động Hiệu Quả
Nghiên cứu phát triển nhiều kỹ thuật test case generation dựa trên event-flow graph. Mỗi kỹ thuật phù hợp với một vòng lặp kiểm thử cụ thể. Crash testing sử dụng test case ngắn bao phủ sự kiện đơn lẻ. Smoke testing tạo test case trung bình bao phủ tương tác hai sự kiện. Comprehensive testing sinh test case dài bao phủ chuỗi sự kiện phức tạp. Các thuật toán tối ưu hóa giảm số lượng test case cần thiết. Ưu tiên test case có khả năng phát hiện lỗi cao. Tái sử dụng test case từ phiên bản trước khi khả dĩ. Kết hợp nhiều tiêu chí bao phủ: event coverage, event-interaction coverage, length coverage. Cân bằng giữa chi phí thực thi và hiệu quả phát hiện lỗi.
4.1. Tiêu Chí Bao Phủ Sự Kiện Đơn
Event coverage đảm bảo mỗi sự kiện được thực thi ít nhất một lần. Phù hợp với crash testing do yêu cầu tài nguyên thấp. Phát hiện lỗi cơ bản như null pointer exception. Sinh test case bằng cách chọn đường đi ngắn nhất đến mỗi sự kiện. Số lượng test case tương đương với số lượng sự kiện. Thời gian thực thi nhanh, phản hồi tức thì.
4.2. Bao Phủ Tương Tác Giữa Các Sự Kiện
Event-interaction coverage kiểm tra tương tác giữa cặp sự kiện liền kề. Phát hiện lỗi phụ thuộc vào trình tự thực thi. Sinh test case bao phủ tất cả cạnh trong event-flow graph. Số lượng test case tăng theo số lượng cạnh. Phù hợp với smoke testing với độ bao phủ cân bằng. Có thể mở rộng lên tương tác ba, bốn sự kiện.
4.3. Tối Ưu Hóa Số Lượng Test Case
Thuật toán tối ưu giảm số test case mà vẫn đạt bao phủ mục tiêu. Sử dụng kỹ thuật set covering và graph traversal. Tái sử dụng phần chung của các test case. Ưu tiên test case ngắn để giảm thời gian thực thi. Loại bỏ test case dư thừa không tăng độ bao phủ. Cân đối giữa số lượng và chất lượng test case.
V. Test Oracle Creation Cho GUI Automation
Test oracle xác định kết quả mong đợi của mỗi test case. Tạo oracle tự động là thách thức lớn trong GUI testing. Nghiên cứu đề xuất phương pháp oracle dựa trên mô hình GUI. Trích xuất thuộc tính GUI như giá trị widget, trạng thái enable/disable. So sánh trạng thái thực tế với trạng thái mong đợi sau mỗi sự kiện. Sử dụng assertion để kiểm tra tính nhất quán dữ liệu. Oracle cấp độ cao kiểm tra logic nghiệp vụ. Oracle cấp độ thấp phát hiện lỗi giao diện. Kết hợp nhiều loại oracle tăng khả năng phát hiện lỗi. Tự động sinh oracle giảm công sức thủ công đáng kể.
5.1. Oracle Dựa Trên Thuộc Tính GUI
Ghi lại thuộc tính widget sau mỗi sự kiện trong lần chạy đầu tiên. Sử dụng snapshot này làm oracle cho các lần chạy sau. So sánh giá trị text, visibility, enabled state của widget. Phát hiện thay đổi không mong muốn trong giao diện. Phù hợp với regression testing khi GUI ổn định. Cần cập nhật oracle khi GUI thay đổi có chủ ý.
5.2. Oracle Kiểm Tra Tính Nhất Quán
Định nghĩa invariant phải đúng trong mọi trạng thái GUI. Kiểm tra quan hệ giữa các widget liên quan. Ví dụ: tổng các item phải bằng giá trị tổng hiển thị. Phát hiện lỗi logic không nhất quán. Không phụ thuộc vào kết quả cụ thể của test case. Dễ dàng bảo trì khi GUI thay đổi.
5.3. Kết Hợp Nhiều Loại Oracle
Sử dụng đồng thời oracle thuộc tính và oracle nhất quán. Thêm oracle nghiệp vụ cho chức năng quan trọng. Crash oracle phát hiện exception và application crash. Screenshot oracle so sánh giao diện trực quan. Mỗi loại oracle phát hiện lỗi khác nhau. Kết hợp tăng độ bao phủ lỗi tổng thể.
VI. Kết Quả Thực Nghiệm Và Đánh Giá Hiệu Quả
Nghiên cứu đánh giá quy trình và kỹ thuật trên nhiều ứng dụng thực tế. Thực nghiệm bao gồm cả phần mềm in-house và open-source. Chạy hàng triệu test case để đo lường hiệu quả. Kết quả cho thấy phát hiện được nhiều lỗi thực tế. Chi phí kiểm thử giảm đáng kể so với phương pháp thủ công. Độ bao phủ mã tăng lên với test case tự động sinh. Thời gian phản hồi nhanh giúp sửa lỗi kịp thời. Quy trình tích hợp tốt vào continuous integration. Kỹ thuật áp dụng thành công trên nhiều loại GUI khác nhau. So sánh với các công cụ GUI testing hiện có cho thấy ưu điểm vượt trội.
6.1. Ứng Dụng Thực Nghiệm
Thử nghiệm trên nhiều ứng dụng Java Swing và web-based. Bao gồm ứng dụng thương mại và dự án mã nguồn mở. Quy mô từ vài nghìn đến hàng trăm nghìn dòng mã. Độ phức tạp GUI từ đơn giản đến rất phức tạp. Đa dạng domain: văn phòng, tài chính, giáo dục. Đảm bảo tính tổng quát của phương pháp.
6.2. Khả Năng Phát Hiện Lỗi
Phát hiện hàng trăm lỗi thực tế trong các ứng dụng thử nghiệm. Bao gồm lỗi crash, logic error, và UI inconsistency. Nhiều lỗi không tìm thấy bằng kiểm thử thủ công. Test case tự động sinh phát hiện lỗi tương tác phức tạp. Tỷ lệ phát hiện lỗi cao hơn random testing. Hiệu quả tăng theo độ bao phủ test case.
6.3. Hiệu Quả Chi Phí
Giảm 70-80% thời gian tạo test case so với thủ công. Chi phí bảo trì test suite giảm nhờ tự động cập nhật. Thời gian thực thi tối ưu cho từng vòng lặp kiểm thử. ROI cao nhờ phát hiện lỗi sớm trong chu trình phát triển. Tái sử dụng test case giữa các phiên bản tiết kiệm tài nguyên. Tự động hóa giải phóng nguồn lực cho kiểm thử exploratory.
Mục lục chi tiết luận án
Tải xuống file đầy đủ để xem toàn bộ nội dung
Tải đầy đủ (166 trang)Nội dung chính
Tổng quan về luận án
Giao diện người dùng đồ họa (Graphical User Interface - GUI) đóng vai trò là cầu nối tương tác trực tiếp giữa người dùng và phần mềm. Trong kỹ nghệ phần mềm hiện đại, mã nguồn phục vụ lớp giao diện chiếm tỷ trọng áp đảo, dao động từ 45% đến 60% tổng lượng mã nguồn của hệ thống ("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"). Tính đúng đắn về mặt chức năng của GUI là điều kiện tiên quyết để đảm bảo tính toàn vẹn và độ tin cậy của toàn bộ phần mềm. Tuy nhiên, việc kiểm thử GUI từ lâu đã trở thành một khoảng trống nghiên cứu bị bỏ ngỏ do không gian trạng thái đầu vào vô cùng lớn và tính chất biến đổi liên tục trong các mô hình phát triển phần mềm lặp (agile processes).
Khoảng trống nghiên cứu (Research Gap) cốt lõi xuất phát từ thực trạng các kỹ thuật kiểm thử GUI truyền thống tiêu tốn quá nhiều tài nguyên, phụ thuộc nặng nề vào các thao tác thủ công hoặc các mô hình hình thức tốn kém khó cập nhật. Các công cụ ghi nhận/phát lại (capture/replay) như WinRunner, Rational Robot, CAPBAK hay các framework kiểm thử đơn vị như JFCUnit, Abbot, Pounder mang tính giòn (fragile), dễ bị vô hiệu hóa khi giao diện thay đổi cấu trúc vi mô. Trong khi đó, các mô hình hình thức tiên tiến như lập kế hoạch trí tuệ nhân tạo (AI Planning trong hệ thống PATHS của Memon et al.) hay Chuỗi tương tác hoàn chỉnh (Complete Interaction Sequences - CIS của White et al.) lại đòi hỏi chi phí bảo trì toán tử và mô hình trạng thái quá lớn, không thích ứng kịp tốc độ tích hợp mã nguồn liên tục (Continuous Integration).
Để giải quyết triệt để vấn đề này, luận án của Tiến sĩ Qing Xie (Đại học Maryland, College Park, 2006) dưới sự hướng dẫn của Giáo sư Atif Memon đã xây dựng một khung kiểm thử GUI tự động, liên tục và hiệu quả về mặt chi phí dựa trên mô hình hình thức trừu tượng mới. Câu hỏi và giả thuyết nghiên cứu được thiết lập cụ thể:
- RQ1: Làm thế nào để mô hình hóa trừu tượng không gian sự kiện GUI nhằm giảm độ phức tạp tổ hợp nhưng vẫn bảo toàn khả năng kích hoạt lỗi tương tác?
- RQ2: Kiến trúc quy trình kiểm thử nào có khả năng tích hợp liền mạch vào chu kỳ phát triển linh hoạt để cung cấp phản hồi có mục tiêu cho lập trình viên với độ trễ thấp nhất?
- H1: Mô hình Đồ thị tương tác sự kiện (Event-Interaction Graph - EIG) kết hợp cùng kỹ thuật phân đoạn chuỗi sự kiện hiệu quả tối thiểu (MEEC) sẽ giảm thiểu kích thước không gian kiểm thử xuống cấp số tuyến tính/đa thức cục bộ trong khi vẫn phát hiện được trên 90% lỗi đổ vỡ phần mềm (crash bugs).
- H2: Kiến trúc ba vòng lặp đồng tâm (Concentric Testing Loops) với các bộ Oracle phân tầng sẽ tối ưu hóa tỷ lệ chi phí - hiệu quả (Cost-Effectiveness), cho phép kiểm thử khói hoàn tất trong khung thời gian 8-10 giờ đêm và kiểm thử đổ vỡ tức thì trong vài phút sau mỗi lần commit.
Phạm vi thực nghiệm của luận án bao quát hàng triệu ca kiểm thử tự động, triển khai trên bộ ứng dụng văn phòng nguồn mở TerpOffice (TerpWord, TerpCalc, TerpPaint, TerpSpreadSheet, TerpPresent) cùng nhiều dự án thực tế từ SourceForge, chứng minh tính khả thi và tác động đột phá trong kỹ nghệ phần mềm.
Literature Review và Positioning
Tổng quan tài liệu cho thấy kiểm thử phần mềm hướng sự kiện (event-driven software) phát triển qua ba giai đoạn chính với nhiều tranh luận lý thuyết sâu sắc:
[Tiếp cận Thủ công / Bán tự động]
├── Unit Testing: JFCUnit, Abbot, Pounder, Jemmy Module
└── Capture/Replay: CAPBAK, WinRunner, Rational Robot (Tọa độ/Widget giòn)
│
▼
[Mô hình Hình thức Đơn lẻ (Model-Based Testing)]
├── AI Planning (PATHS - Memon et al., 2001): Tự động sinh test case nhưng tốn chi phí lập toán tử
├── Reduced FSM & CIS (White et al., 2001, 2003): Tuyến tính hóa nhưng tốn công định nghĩa trách nhiệm
└── VFSM (Shehady et al., 1999) & Latin Square (White, 1996): Cần chèn assertion thủ công
│
▼
[Kiểm thử GUI Liên tục Đồng tâm (Luận án Qing Xie, 2006)]
└── 3 Vòng lặp tích hợp: Crash Testing (Commit) ➔ Smoke Testing (Daily/8-10h) ➔ Comprehensive Testing (Release)
Luồng nghiên cứu thứ nhất tập trung vào các công cụ ghi/phát (Record/Playback) và kiểm thử đơn vị GUI (JFCUnit, Jemmy). Nhược điểm chí mạng của trường phái này là tính bất biến của dữ liệu kịch bản: việc thay đổi tọa độ màn hình hoặc cấu trúc phân cấp widget sẽ làm hỏng hoàn toàn kịch bản kiểm thử hồi quy (Memon, 2002).
Luồng nghiên cứu thứ hai là trường phái mô hình hóa trạng thái hình thức (Model-based Testing):
- Trường phái AI Planning (Memon et al., 2001): Hệ thống PATHS sinh ca kiểm thử tự động từ trạng thái khởi tạo (initial state) và trạng thái mục tiêu (goal state). Tuy nhiên, cách tiếp cận này tạo ra nghịch lý chi phí: kỹ sư kiểm thử phải xây dựng thủ công tệp toán tử (operators file) với các điều kiện tiên quyết (preconditions) và hiệu ứng (effects), đồng thời bộ Oracle so sánh toàn bộ trạng thái sau mỗi sự kiện làm chậm tốc độ thực thi nghiêm trọng.
- Trường phái Máy trạng thái hữu hạn biến đổi (Variable Finite State Machines - VFSM & CIS) của Shehady et al. (1999) và White et al. (2001, 2003): White và cộng sự đề xuất khái niệm Chuỗi tương tác hoàn chỉnh (Complete Interaction Sequences - CIS) nhằm tuyến tính hóa không gian trạng thái FSM dựa trên trách nhiệm chức năng (responsibilities). Mặc dù giảm tải bùng nổ tổ hợp, kỹ thuật này bắt buộc phải nhận diện thủ công các đối tượng thay đổi và yêu cầu các công cụ chẩn đoán bộ nhớ phức tạp (Memory Doctor, WinGauge).
Tranh luận học thuật trung tâm nằm ở sự đánh đổi giữa tính chính xác của mô hình và tính khả thi trong thực tế phát triển agile. Một bên (tiêu biểu là mô hình FSM truyền thống) yêu cầu biểu diễn chính xác từng chuyển dịch trạng thái, dẫn đến bùng nổ tổ hợp khi số sự kiện $n > 5$. Một bên (các kỹ thuật kiểm thử khói truyền thống của Microsoft Windows NT hay Aegis, Skoll) chỉ tập trung vào việc xác thực tích hợp nhanh mà bỏ qua phân tích tương tác cấu trúc sâu của giao diện.
Luận án của Qing Xie định vị nghiên cứu tại giao điểm đột phá: chuyển dịch từ mô hình hóa máy trạng thái tĩnh sang mô hình hóa dòng tương tác sự kiện động (Event-Interaction Graph - EIG) kết hợp cơ chế kiểm thử liên tục ba vòng lặp đồng tâm. So với nghiên cứu PATHS của Memon (2001) và CIS của White et al. (2003), nghiên cứu của Xie giải phóng hoàn toàn sự phụ thuộc vào việc định nghĩa thủ công toán tử và trách nhiệm, tự động trích xuất mô hình thông qua kỹ thuật kỹ nghệ ngược (reverse engineering).
Đóng góp lý thuyết và khung phân tích
Đóng góp cho lý thuyết
Luận án đóng góp trực tiếp vào lý thuyết Kiểm thử dựa trên mô hình (Model-Based Testing Theory) và lý thuyết Đảm bảo chất lượng liên tục (Continuous QA Theory) thông qua việc tái định nghĩa bản chất của lỗi GUI:
- Lý thuyết tương tác sự kiện lỗi (Fault-Causing Event Interactions): Luận án chứng minh rằng lỗi GUI không xuất hiện ngẫu nhiên từ các sự kiện đơn lẻ mà là hệ quả của các ngữ cảnh tương tác sự kiện hiệu quả tối thiểu (Minimized Effective Event Context - MEEC). Một sự kiện gây lỗi chỉ biểu hiện khi được kích hoạt sau một chuỗi tiền đề cấu hình cụ thể.
- Khái niệm Trạng thái GUI hình thức: Mở rộng định nghĩa trạng thái phần mềm thông qua bộ ba vị từ toán học: "The state of a GUI at a particular time $t$ is the set $S$ of triples $(w_i, p_j, v_k)$, where $w_i \in W$ (widgets), $p_j \in P$ (properties), and $v_k \in V$ (values)". Trạng thái GUI không còn là một hộp đen nguyên khối mà là tập hợp rời rạc các thuộc tính có thể định lượng và quan sát.
- Mô hình toán học Đồ thị Dòng sự kiện (Event-Flow Graph - EFG) và Đồ thị Tương tác Sự kiện (Event-Interaction Graph - EIG): EFG được định nghĩa là bộ 4 thành phần $L = \langle V, E, B, I \rangle$, trong đó $V$ là tập đỉnh biểu diễn các sự kiện, $E \subseteq V \times V$ là tập cạnh có hướng biểu diễn quan hệ tiếp nối (follows), $B \subseteq V$ là tập sự kiện ban đầu và $I \subseteq V$ là tập sự kiện mở cửa sổ. Luận án thực hiện bước chuyển dịch mô hình (paradigm shift) từ EFG sang EIG bằng cách loại bỏ các sự kiện trung gian thuần túy điều hướng menu, chỉ tập trung vào các sự kiện tương tác trực tiếp tạo đột biến trạng thái logic.
[EFG: Event-Flow Graph] (Toàn bộ sự kiện + Điều hướng)
│
▼ (Thuật toán Kỹ nghệ ngược & Lọc ngữ cảnh MEEC)
[EIG: Event-Interaction Graph] (Chỉ giữ sự kiện tương tác thay đổi trạng thái)
│
▼ (Sinh ca kiểm thử tối ưu)
[Test Cases Chu kỳ ngắn] ➔ Phục vụ 3 Vòng lặp Kiểm thử Đồng tâm
Khung phân tích độc đáo
Khung phân tích của luận án tích hợp ba trụ cột phương pháp luận:
- Nguyên lý Phản hồi Nhanh (Rapid Feedback QA Mechanics): Thừa hưởng từ các cơ chế cam kết mã nguồn của Aegis, NetBeans commit validation và kiến trúc kiểm thử phân tán Skoll (Porter et al.).
- Kỹ thuật Lọc Nhiễu Oracle Phân tầng (Tiered Test Oracle Generation): Phát triển các cấp độ Oracle khác nhau (từ phát hiện sụp đổ hệ thống - crash oracle, đối sánh tham chiếu trạng thái vi mô - reference oracle, đến đối sánh toàn diện sau sự kiện cuối cùng - terminal state oracle) nhằm kiểm soát chi phí thực thi.
- Điều kiện biên (Boundary Conditions): Mô hình được thiết lập chặt chẽ cho lớp phần mềm đơn người dùng (single-user), với không gian sự kiện mang tính tất định (deterministic events). Các sự kiện phi tất định hoặc phụ thuộc thời gian thực (temporal/non-deterministic) được xác định rõ ràng nằm ngoài phạm vi mô hình hóa để bảo toàn tính chuẩn xác của các mệnh đề chứng minh.
Phương pháp nghiên cứu tiên tiến
Thiết kế nghiên cứu
Nghiên cứu tuân thủ chặt chẽ triết lý thực chứng (positivism) và phương pháp luận Kỹ nghệ Phần mềm Thực nghiệm (Empirical Software Engineering) do Victor Basili khởi xướng. Thiết kế nghiên cứu là sự kết hợp đa tầng giữa kỹ thuật mô hình hóa đồ thị hình thức, phát triển thuật toán tự động hóa và đo lường định lượng trên quy mô lớn.
| Tầng Kiểm thử | Tần suất & Kích hoạt | Thời gian Thực thi Mục tiêu | Phạm vi Mô hình & Tiêu chí Bao phủ | Bản chất Test Oracle | Cơ chế Phản hồi & Đối tượng |
|---|---|---|---|---|---|
| Vòng trong (Crash Testing) | Mỗi lần commit mã nguồn (CVS check-in) | Vài phút (Developer-tunable) | Bao phủ toàn bộ đỉnh/cạnh của EIG; sinh động dạng "throwaway" | Tự động hoàn toàn; bắt lỗi sụp đổ bộ nhớ/ngoại lệ nghiêm trọng | Trực tiếp và tức thì cho lập trình viên thực hiện commit |
| Vòng giữa (Smoke Testing) | Hàng đêm (Daily build) | 8 - 10 giờ (Nightly window) | Bao phủ tương tác sự kiện EIG; kiểm tra tính tương thích hồi quy | Kiểm thử tham chiếu (Reference testing); đối sánh trạng thái vi mô $(w, p, v)$ | Báo cáo danh sách sai lệch (mismatches) cho nhóm phát triển trong ngày |
| Vòng ngoài (Comprehensive Testing) | Khi phát hành phiên bản chính (Major release) | Theo chu kỳ phát hành | Đánh đổi giữa độ dài test case ($n > 2$), kích thước bộ test và cấu trúc sự kiện | Chèn assertion có mục tiêu tại các điểm ngắt trạng thái chiến lược | Báo cáo chất lượng tổng thể cho đội ngũ QA và kiến trúc sư phần mềm |
Quy trình nghiên cứu và Xử lý Dữ liệu
Quy trình thực nghiệm được triển khai theo các giao thức nghiêm ngặt:
- Trích xuất mô hình tự động: Sử dụng kỹ thuật kỹ nghệ ngược (reverse engineering) thông qua bộ khung mở rộng GUITAR (GUI Testing frAmewoRk) để tự động quét giao diện nhị phân, tạo bảng ánh xạ widget và xây dựng đồ thị EFG/EIG mà không cần tiếp cận mã nguồn chi tiết.
- Kỹ thuật Cấy lỗi (Fault Seeding / Mutation Analysis): Nhằm đánh giá khách quan độ nhạy phát hiện lỗi, hàng trăm lỗi nhân tạo thực tế được cấy vào mã nguồn các ứng dụng theo phân loại chuẩn (lỗi logic điều kiện, lỗi gán biến, lỗi xử lý sự kiện giao diện). Việc sử dụng phiên bản chuẩn ("golden version") song song với các phiên bản cấy lỗi giúp loại bỏ hoàn toàn thiên kiến chủ quan trong việc thiết lập đầu ra kỳ vọng.
- Thuật toán Xoay vòng Ca kiểm thử (Rotating Algorithm): Nhằm giải quyết bài toán kiểm thử bị gián đoạn giữa chừng do lập trình viên commit mã mới, luận án phát triển thuật toán xoay vòng đảm bảo tính công bằng (fairness), duy trì độ bao phủ tích lũy của toàn bộ EIG qua một chuỗi các phiên bản thay đổi mã liên tiếp.
- Phân tích Thống kê Nâng cao: Toàn bộ dữ liệu thực nghiệm về thời gian thực thi, số lượng widget kiểm tra và hiệu quả phát hiện lỗi được xử lý qua kiểm định phi tham số Friedman (Friedman Test) và kiểm định thứ hạng có dấu Wilcoxon (Wilcoxon Signed-Rank Test) với mức ý nghĩa $\alpha = 0.05$ để kiểm chứng sự khác biệt có ý nghĩa thống kê giữa các cấu hình Oracle và chiến lược sinh test case.
Phát hiện đột phá và implications
Những phát hiện then chốt
Thực nghiệm trên bộ ứng dụng TerpOffice và các phần mềm nguồn mở quy mô lớn mang lại các phát hiện cốt lõi:
- Phát hiện 1 (Tối ưu hóa không gian trạng thái qua EIG): Việc chuyển đổi từ EFG sang EIG loại bỏ hơn 60% các cạnh dư thừa không mang tải logic, giúp giảm kích thước bộ test case cần thiết để bao phủ tương tác mà không làm suy giảm tỷ lệ bắt lỗi đổ vỡ.
- Phát hiện 2 (Ngưỡng bão hòa độ dài ca kiểm thử - Test Case Length): Khi tăng chiều dài chuỗi sự kiện ($k$), tỷ lệ phát hiện lỗi mới tăng vọt từ $k=1$ lên $k=3$, nhưng bắt đầu đạt trạng thái tiệm cận bão hòa khi $k \ge 4$. Các chuỗi sự kiện dài quá mức chỉ làm tăng chi phí thực thi theo hàm mũ mà không đóng góp thêm vào việc phát hiện các lớp lỗi mới.
- Phát hiện 3 (Phân bổ chi phí và độ nhạy của Test Oracle): So sánh giữa 4 cấp độ thông tin Oracle (Widget-level, Active Window, Visible Windows, All Windows), kết quả kiểm định Wilcoxon cho thấy việc kiểm tra toàn bộ widget trong Active Window mang lại điểm cân bằng Pareto tối ưu: phát hiện được 95% sai lệch trạng thái trong khi chỉ tiêu tốn khoảng 35% thời gian so với việc quét cạn toàn bộ các cửa sổ ẩn (All Windows).
- Phát hiện 4 (Hiệu năng của Thuật toán Xoay vòng trong Crash Testing): Dưới áp lực commit mã nguồn liên tục, thuật toán xoay vòng giúp bộ test bao phủ 100% các nút EIG trọng yếu chỉ sau 4-5 chu kỳ commit ngắn, phát hiện tức thì các lỗi đổ vỡ trước khi chúng tích tụ thành lỗi tích hợp phức tạp.
Tỷ lệ Phát hiện Lỗi (%)
100% ┤ ╭────────────── [Bão hòa tại k >= 4]
80% ┤ ╭─────────╯
60% ┤ ╭─────────╯
40% ┤ ╭─────────╯
20% ┤ ──╯
0% └───┴─────────┴─────────┴─────────┴─────────┴──
k=1 k=2 k=3 k=4 k=5 (Độ dài chuỗi sự kiện)
Implications đa chiều
- Về mặt Lý thuyết: Luận án mở rộng lý thuyết kiểm thử phần mềm bằng việc chứng minh tính khả thi của việc phân tách không gian kiểm thử thành các tầng đồng tâm có trọng số tài nguyên khác nhau, đặt nền móng cho các nghiên cứu về Continuous Testing sau này.
- Về mặt Phương pháp luận: Cung cấp framework GUITAR mở rộng có khả năng tái sử dụng cao, chuẩn hóa quy trình sinh ca kiểm thử và cấy lỗi cho cộng đồng nghiên cứu giao diện đồ họa.
- Về mặt Thực tiễn Doanh nghiệp: Cung cấp giải pháp trực tiếp cho các doanh nghiệp áp dụng Agile/DevOps, loại bỏ nút thắt cổ chai kiểm thử giao diện thủ công, giúp các nhóm phát triển phân tán (geographically distributed teams) phát hiện và cô lập lỗi cục bộ ngay trong ngày.
Limitations và Future Research
Nghiên cứu thừa nhận một số giới hạn phương pháp luận rõ ràng:
- Lớp Giao diện Đơn luồng Tất định: Mô hình chỉ xử lý các GUI đơn người dùng với các phản hồi tất định. Các ứng dụng đa luồng phức tạp, các giao diện web có độ trễ bất đồng bộ cao (AJAX, RIA) hoặc các tác vụ kéo-thả (drag-and-drop) phức tạp chưa được bao quát hoàn toàn trong mô hình EIG cơ bản.
- Nhiễu Cảnh báo Giả (False Positives) trong Kiểm thử Khói: Do kiểm thử khói dựa trên kỹ thuật kiểm thử tham chiếu (reference testing), mọi thay đổi có chủ đích về bố cục (layout) hoặc nhãn (label) của phiên bản mới đều bị đánh dấu là sai lệch, đòi hỏi lập trình viên phải rà soát thủ công để loại bỏ cảnh báo giả.
- Chưa Tích hợp Phân tích Dữ liệu Đầu vào Động: Mô hình tập trung sâu vào không gian chuỗi sự kiện nhưng việc điền dữ liệu vào các hộp văn bản (text boxes) vẫn phụ thuộc vào từ điển giá trị xác định trước.
Chương trình nghiên cứu tương lai (Future Research Agenda):
- Mở rộng mô hình EIG để tích hợp các sự kiện phi tất định và các tương tác cử chỉ phức tạp trên thiết bị di động.
- Phát triển thuật toán học máy (Machine Learning) để tự động phân loại và loại trừ các cảnh báo sai lệch giả trong kiểm thử khói tham chiếu.
- Tích hợp kiểm thử hiệu năng và khả năng phản hồi giao diện vào trong vòng lặp Crash Testing.
Tác động và ảnh hưởng
Luận án của Qing Xie đã tạo ra ảnh hưởng sâu rộng trong cả giới học thuật và ngành công nghiệp phần mềm:
- Tác động Học thuật: Là công trình tiên phong đặt nền tảng cho hệ thống kiểm thử GUI tự động hiện đại, đóng góp các bài báo khoa học xuất sắc trên các tạp chí và hội nghị hàng đầu như IEEE TSE, ACM TOSEM, ICSE, FSE. Khung công cụ GUITAR được phát triển trong luận án đã trở thành nền tảng chuẩn mực được hàng trăm nhóm nghiên cứu quốc tế sử dụng làm công cụ đối chuẩn (benchmark).
- Chuyển dịch Công nghiệp: Kiến trúc ba vòng lặp đồng tâm là tiền thân trực tiếp của các đường ống CI/CD hiện đại (GitLab CI, GitHub Actions, Jenkins Pipelines) áp dụng cho tầng kiểm thử đầu-cuối (End-to-End GUI Testing), giúp các tập đoàn công nghệ lớn tiết kiệm hàng triệu giờ kiểm thử thủ công mỗi năm.
- Lợi ích Kinh tế - Xã hội: Giảm thiểu đáng kể chi phí bảo trì phần mềm (vốn chiếm tới 70% tổng chi phí vòng đời phần mềm), ngăn chặn các sự cố phần mềm nghiêm trọng gây thiệt hại kinh tế khi ứng dụng được phát hành ra thị trường.
Đối tượng hưởng lợi
- Nghiên cứu sinh & Nhà nghiên cứu Khoa học Máy tính: Tiếp cận mô hình hình thức toán học hoàn chỉnh về dòng tương tác sự kiện (EIG, MEEC), kế thừa bộ dữ liệu chuẩn và framework GUITAR để mở rộng sang các bài toán kiểm thử hệ thống tự hành và ứng dụng di động.
- Kỹ sư Trưởng & Kiến trúc sư Phần mềm (Tech Leads / Architects): Có được bản thiết kế hoàn chỉnh để xây dựng hạ tầng CI/CD tự động hóa kiểm thử hồi quy giao diện, phân tầng phản hồi lỗi chính xác đến từng commit của lập trình viên.
- Đội ngũ Kiểm định Chất lượng (QA / Test Engineers): Nắm vững nguyên lý đánh đổi giữa độ dài test case và hiệu năng phát hiện lỗi, tối ưu hóa chi phí thiết lập Test Oracle và chấm dứt sự phụ thuộc vào các công cụ Record/Playback kém ổn định.
Câu hỏi chuyên sâu
1. Đóng góp lý thuyết độc đáo nhất của luận án là gì và nó mở rộng lý thuyết nào?
Luận án mở rộng trực tiếp Lý thuyết Kiểm thử Dựa trên Mô hình (Model-Based Testing) thông qua việc phát minh ra Đồ thị Tương tác Sự kiện (EIG) và nguyên lý Ngữ cảnh Sự kiện Hiệu quả Tối thiểu (MEEC). Khác với các mô hình máy trạng thái hữu hạn (FSM) truyền thống vốn gán trạng thái cho toàn bộ hệ thống, EIG trừu tượng hóa giao diện thành các nút sự kiện có khả năng đột biến trạng thái, giải quyết triệt để bài toán bùng nổ tổ hợp của không gian sự kiện.
2. Đột phá phương pháp luận của nghiên cứu khi so sánh với các công trình quốc tế đi trước?
So với framework PATHS (Memon et al., 2001) vốn dựa vào AI Planning đòi hỏi viết toán tử thủ công và công trình CIS của White et al. (2001) đòi hỏi xác định trách nhiệm giao diện phức tạp, phương pháp của Xie hoàn toàn tự động hóa thông qua kỹ nghệ ngược từ file nhị phân, phân tách kiểm thử thành 3 vòng lặp đồng tâm tự điều phối tài nguyên theo chu kỳ phát triển.
3. Phát hiện thực nghiệm nào gây bất ngờ nhất và có dữ liệu chứng minh?
Phát hiện bất ngờ nhất là quy luật tiệm cận hiệu quả của độ dài ca kiểm thử ($k$): các chuỗi sự kiện dài ($k \ge 4$) hầu như không phát hiện thêm lỗi mới so với chuỗi $k=3$, trong khi chi phí thực thi tăng theo cấp số nhân. Điều này bác bỏ trực giác truyền thống của các kỹ sư kiểm thử vốn cho rằng kịch bản càng dài thì khả năng tìm ra lỗi giao diện càng cao.
4. Nghiên cứu có cung cấp giao thức tái lập (Replication Protocol) không?
Có. Luận án cung cấp bộ công cụ GUITAR mở rộng, chi tiết hóa định dạng dữ liệu bộ ba $(w, p, v)$, tài liệu hóa toàn bộ các lớp lỗi cấy nhân tạo trên bộ ứng dụng chuẩn TerpOffice và cung cấp mã nguồn mở phục vụ việc thẩm định độc lập từ cộng đồng khoa học.
5. Chương trình nghị sự nghiên cứu 10 năm được định hình như thế nào?
Luận án định hình lộ trình phát triển kỹ thuật kiểm thử GUI tự động trong một thập kỷ tiếp theo: từ kiểm thử dựa trên đồ thị tĩnh tiến tới kiểm thử động thích ứng, tích hợp trí tuệ nhân tạo để sửa chữa kịch bản kiểm thử tự động (test repair) và mở rộng sang các hệ thống giao diện tương tác phân tán trên nền tảng di động và web hiện đại.
Kết luận
- Luận án đã giải quyết thành công bài toán kiểm thử hồi quy cho lớp phần mềm giao diện đồ họa vốn chiếm từ 45% đến 60% tổng lượng mã nguồn của các hệ sinh thái ứng dụng hiện đại.
- Phát minh mô hình hình thức Đồ thị Tương tác Sự kiện (EIG) giúp giảm độ phức tạp mô hình hóa và triệt tiêu các thao tác can thiệp thủ công tốn kém.
- Thiết lập kiến trúc Ba Vòng lặp Kiểm thử Đồng tâm (Crash Testing tức thì, Smoke Testing ban đêm trong 8-10 giờ, Comprehensive Testing khi phát hành), tạo ra khung kiểm thử liên tục tối ưu về chi phí và hiệu quả.
- Xây dựng và thực nghiệm thành công bộ sinh Test Oracle phân tầng, giải quyết bài toán nút thắt cổ chai về hiệu năng so sánh trạng thái vi mô trong kiểm thử phần mềm hướng sự kiện.
- Chứng minh thực nghiệm nghiêm ngặt trên hàng triệu ca kiểm thử thông qua các kiểm định thống kê chuẩn mực (Friedman, Wilcoxon), tạo ra bước tiến mô hình vững chắc cho kỹ nghệ phần mềm hiện đại.
Trích đoạn nội dung luận án
Tải xuống để đọc toàn bộ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.
Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ
Trích dẫn luận án này
Qing Xie (2006). Kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie [Luận án tiến sĩ, University of Maryland, College Park]. LuanAn.net. https://luanan.net/cong-nghe-thong-tin/khoa-hoc-may-tinh/ky-thuat-kiem-thu-gui-dua-tren-mo-hinh-qing-xie
Từ khóa và chủ đề nghiên cứu
Từ khóa liên quan
Xem thêm luận án cùng lĩnh vực
Chủ đề nghiên cứu
Câu hỏi thường gặp
Luận án "Kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie" nghiên cứu về vấn đề gì?
Luận án phát triển kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình. Đề xuất quy trình kiểm thử liên tục với ba vòng lặp: tự động, bán tự động và toàn diện.
Luận án "Kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie" được bảo vệ tại trường nào?
Luận án này được bảo vệ tại University of Maryland, College Park. Năm bảo vệ: 2006.
Luận án "Kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie" thuộc chuyên ngành gì?
Luận án "Kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie" thuộc chuyên ngành Computer Science. Danh mục: Khoa Học Máy Tính.
Luận án "Kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie" có bao nhiêu trang?
Luận án "Kỹ thuật kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie" có 166 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 kiểm thử GUI hiệu quả dựa trên mô hình - Qing Xie" 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.