Luận Văn Thạc Sĩ Kỹ Thuật Viễn Thông: Nghiên Cứu Phát Triển Phần Mềm Tự Động Kiểm Định Ứng Dụng

Luận văn thạc sĩ kỹ thuật phân tích kỹ thuật viễn thông nghiên cứu phát triển phần mềm tự động kiểm định ứng dụng, đánh giá thực trạng, chỉ ra hạn chế, đề xuất giải pháp khả thi

• Tác giả: Lê Trường Anh Tiến
• Người hướng dẫn: TS. Lưu Thanh Trà
• Trường học: Đại học Bách Khoa - Đại học Quốc gia TP. Hồ Chí Minh
• Chuyên ngành: Kỹ thuật Viễn thông
• Đề tài: Nghiên cứu phát triển phần mềm tự động kiểm định ứng dụng
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2016
• Địa điểm: TP. Hồ Chí Minh

Mục lục chi tiết

• NHIỆM VỤ LUẬN VĂN THẠC SĨ
• LỜI CẢM ƠN
• TÓM TẮT LUẬN VĂN
• LỜI CAM ĐOAN
• DANH MỤC HÌNH VẼ
• DANH MỤC BẢNG BIỂU
• DANH MỤC CÁC TỪ VIẾT TẮT
• 1. Chương 1: Giới thiệu
• 1.1. Tổng quan
• 1.2. Mục đích nghiên cứu đề tài
• 1.2.1. Yêu cầu
• 1.2.2. Tính năng
• 1.2.3. Độ phức tạp
• 1.2.4. Mở rộng
• 1.2.5. Ứng dụng
• 1.3. Phạm vi nghiên cứu và phương pháp nghiên cứu
• 1.3.1. Phạm vi nghiên cứu
• 1.3.2. Phương pháp nghiên cứu
• 2. Chương 2: Lý thuyết tổng quan và tình hình nghiên cứu
• 2.1. Giới thiệu công nghệ Automation trên Windows
• 2.1.1. Động lực và mục tiêu
• 2.1.2. Kỹ thuật tổng quan
• 2.1.3. Loại điều khiển (Control Types)
• 2.1.4. Các kiểu điều khiển (Control Patterns)
• 2.1.5. UI Automation cho kiểm thử tự động
• 2.2. Giới thiệu công nghệ Automation trên Web
• 2.2.1. Tự động hóa hay không?
• 2.2.2. Giới thiệu Selenium
• 2.2.3. Bộ công cụ Selenium
• 2.2.4. Hỗ trợ trình duyệt
• 2.2.5. Ứng dụng thực tế với Selenium WebDriver
• 2.2.5.1. Cách thực hiện
• 2.2.6. Ứng dụng thực tế với Selenium IDE
• 2.2.6.1. Cách thực hiện
• 2.3. Giới thiệu và so sánh về các hệ thống testing trong nhiều lĩnh vực khác nhau trên thế giới hiện nay
• 2.3.1. HP Quick Test Professional (QTP)
• 2.3.2. So sánh giữa QTP và Selenium
• 2.4. Giới thiệu trình biên dịch (compiler)
• 2.4.1. Ngôn ngữ và cú pháp
• 2.4.2. Ứng dụng trình biên dịch vào đề tài
• 3. Chương 3: Cấu trúc giải thuật chương trình và kết quả thực hiện
• 3.1. Giới thiệu giao diện
• 3.1.1. Menu chính
• 3.1.2. Tab UI Elements
• 3.2. Cấu trúc chương trình
• 3.2.1. Phần bắt UI Element
• 3.2.2. Phần trình biên dịch
• 3.3. Kết quả thực hiện
• 3.3.1. Test ứng dụng calculator của Windows
• 3.3.2. Test ứng dụng Softphone 3CX
• 4. Chương 4: Kết luận và hướng phát triển
• 4.1. Kết quả đạt được
• 4.2. Những vấn đề còn hạn chế
• 4.3. Hướng phát triển
• PHỤ LỤC: CODE LẬP TRÌNH
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Giới thiệu

Chương 1 của Luận Văn Thạc Sĩ Kỹ Thuật Viễn Thông giới thiệu tổng quan về khái niệm tự động kiểm định (automated testing). Mục đích nghiên cứu của đề tài là xây dựng một hệ thống phần mềm tự động kiểm định ứng dụng hiệu quả, tiết kiệm thời gian và chi phí. Kiểm tra thủ công (manual testing) đòi hỏi nhiều nguồn lực và dễ gây lỗi, trong khi kiểm tra tự động (automated testing) giúp tăng tốc độ, độ chính xác và khả năng mở rộng. Đề tài tập trung vào việc phát triển một hệ thống tự động hóa đơn giản nhưng hiệu quả, với mã nguồn mở để cộng đồng có thể phát triển thêm.

1.1. Tổng quan

Kiểm tra thủ công là quá trình con người thực hiện từng bước kiểm tra ứng dụng. Kiểm tra tự động sử dụng công cụ tự động để thực hiện các bước kiểm tra, so sánh kết quả và tạo báo cáo. Tự động hóa kiểm tra giúp tiết kiệm thời gian, chi phí và nâng cao hiệu suất. Các trường hợp phù hợp cho kiểm tra tự động bao gồm các tác vụ lặp lại, phức tạp hoặc tốn thời gian. Tuy nhiên, các tác vụ mới hoặc thường xuyên thay đổi không phù hợp với kiểm tra tự động.

1.2. Mục đích nghiên cứu

Mục đích của đề tài là xây dựng một hệ thống tự động kiểm định đơn giản, hiệu quả và có mã nguồn mở. Hệ thống này đáp ứng các yêu cầu cơ bản của kiểm tra tự động, bao gồm việc xác định các thành phần giao diện (UI Element), tạo kịch bản (script) và thực thi các lệnh kiểm tra. Đề tài cũng hướng đến việc ứng dụng thực tế, như đo thời gian quay số kết nối trong hệ thống tổng đài Voice IP.

II. Lý thuyết tổng quan và tình hình nghiên cứu

Chương 2 trình bày các lý thuyết nền tảng và tình hình nghiên cứu trong lĩnh vực kiểm tra tự động. Đề tài tập trung vào hai mảng chính: kiểm tra tự động trên nền Windows và kiểm tra tự động trên nền Web. Công nghệ User Interface Automation (UIA) của Microsoft được giới thiệu chi tiết, cùng với hệ thống Selenium cho kiểm tra tự động trên web. Chương này cũng so sánh các hệ thống kiểm tra tự động nổi tiếng như HP Quick Test Pro và Selenium, đồng thời giới thiệu về trình biên dịch và cách ứng dụng vào hệ thống tự động kiểm định.

2.1. Công nghệ Automation trên Windows

Công nghệ User Interface Automation (UIA) của Microsoft kế thừa từ MS Active Accessibility (MSAA), cung cấp khả năng truy cập và tương tác với các thành phần giao diện (UI Element) trên nền Windows. UIA hỗ trợ các loại điều khiển (Control Types) và kiểu điều khiển (Control Patterns), giúp xác định và tương tác với các thành phần giao diện một cách chính xác. Đề tài sử dụng UIA để xây dựng hệ thống tự động kiểm định trên các ứng dụng Windows.

2.2. Hệ thống Automation trên Web

Hệ thống Selenium là một công cụ mã nguồn mở phổ biến cho kiểm tra tự động trên web. Selenium hỗ trợ nhiều trình duyệt và cung cấp các công cụ như Selenium WebDriver và Selenium IDE để tạo và thực thi các kịch bản kiểm tra. Đề tài so sánh Selenium với HP Quick Test Pro, một công cụ thương mại, và nhấn mạnh ưu điểm của Selenium về tính linh hoạt và chi phí thấp.

III. Cấu trúc giải thuật và kết quả thực hiện

Chương 3 trình bày cấu trúc giải thuật của hệ thống tự động kiểm định và kết quả thực hiện. Hệ thống bao gồm hai phần chính: phần bắt các thành phần giao diện (UI Element) và phần trình biên dịch để thực thi các kịch bản kiểm tra. Đề tài đã thử nghiệm hệ thống trên các ứng dụng như Calculator và Softphone 3CX, đạt được kết quả khả quan trong việc tự động hóa quy trình kiểm tra.

3.1. Cấu trúc chương trình

Hệ thống tự động kiểm định bao gồm hai phần chính: phần bắt các thành phần giao diện (UI Element) và phần trình biên dịch. Phần bắt UI Element sử dụng công nghệ UIA để xác định và tương tác với các thành phần giao diện. Phần trình biên dịch đọc và thực thi các kịch bản kiểm tra, bao gồm các lệnh cơ bản như RunApp, GetID, PushID, và lệnh điều kiện If.

3.2. Kết quả thực hiện

Hệ thống đã được thử nghiệm trên các ứng dụng Calculator và Softphone 3CX. Kết quả cho thấy hệ thống có khả năng tự động hóa quy trình kiểm tra một cách hiệu quả, tiết kiệm thời gian và nâng cao độ chính xác. Hệ thống cũng ghi nhận các bước thực hiện trong quá trình kiểm tra, giúp người dùng dễ dàng kiểm tra và xử lý lỗi.

IV. Kết luận và hướng phát triển

Chương 4 tổng kết các kết quả đạt được và đề xuất hướng phát triển cho hệ thống tự động kiểm định. Đề tài đã xây dựng thành công một hệ thống đơn giản nhưng hiệu quả, với mã nguồn mở để cộng đồng có thể phát triển thêm. Hướng phát triển trong tương lai bao gồm mở rộng hỗ trợ cho các loại điều khiển khác, bổ sung thêm các lệnh kiểm tra và xây dựng hệ thống báo cáo chuyên nghiệp hơn.

4.1. Kết quả đạt được

Đề tài đã xây dựng thành công một hệ thống tự động kiểm định trên nền Windows, với khả năng xác định và tương tác với các thành phần giao diện (UI Element) một cách chính xác. Hệ thống cũng bao gồm một trình biên dịch để thực thi các kịch bản kiểm tra, giúp tự động hóa quy trình kiểm tra ứng dụng.

4.2. Hướng phát triển

Hướng phát triển trong tương lai bao gồm mở rộng hỗ trợ cho các loại điều khiển khác, bổ sung thêm các lệnh kiểm tra và xây dựng hệ thống báo cáo chuyên nghiệp hơn. Đề tài cũng hướng đến việc ứng dụng hệ thống tự động kiểm định trong nhiều lĩnh vực khác nhau, như kiểm định sản phẩm phần mềm và tự động hóa các ứng dụng trên Windows.

Nội dung chính

Tổng quan nghiên cứu

Trong bối cảnh công nghệ thông tin phát triển mạnh mẽ, kiểm thử phần mềm thủ công ngày càng bộc lộ nhiều hạn chế về chi phí, thời gian và độ chính xác. Theo ước tính của ngành phát triển phần mềm, chi phí kiểm thử thủ công có thể chiếm từ 30–50% tổng chi phí phát triển một sản phẩm phần mềm. Thực tế này tạo ra áp lực lớn cho các doanh nghiệp, đặc biệt trong các dự án quy mô lớn đòi hỏi kiểm định liên tục và lặp lại nhiều lần.

Luận văn thạc sĩ "Nghiên cứu phát triển phần mềm tự động kiểm định ứng dụng" của tác giả Lê Trường Anh Tiến, thực hiện tại Trường Đại học Bách Khoa – ĐHQG TP. Hồ Chí Minh (năm 2016), tập trung giải quyết bài toán tự động hóa kiểm thử ứng dụng trên nền tảng Windows. Nghiên cứu hướng đến mục tiêu xây dựng một hệ thống automated testing mã nguồn mở, đủ năng lực nhận diện các thành phần giao diện người dùng (UI Element), ghi nhận tương tác và tái thực thi thông qua một trình biên dịch tự xây dựng.

Phạm vi nghiên cứu giới hạn trong các ứng dụng chạy trên môi trường Windows, hỗ trợ nền tảng WinForm, .NET và Windows Presentation Foundation (WPF). Về ứng dụng thực tế, hệ thống được triển khai để đo thời gian quay số kết nối của phần mềm softphone 3CX tới tổng đài Voice IP — một kịch bản kiểm thử mà nếu thực hiện thủ công trên hàng chục số điện thoại sẽ tiêu tốn đáng kể thời gian của kỹ sư.

Ý nghĩa của nghiên cứu thể hiện ở hai chiều: về học thuật, đây là một trong số ít công trình trong nước đề xuất tích hợp công nghệ UI Automation của Microsoft với một trình biên dịch tự phát triển; về thực tiễn, mã nguồn được công khai, tạo nền tảng để cộng đồng kỹ thuật mở rộng và phát triển thê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 xây dựng trên hai trụ cột lý thuyết chính.

Thứ nhất, công nghệ User Interface Automation (UIA) của Microsoft — được giới thiệu năm 2005 như một bản kế thừa cải tiến từ Microsoft Active Accessibility (MSAA). UIA cung cấp khả năng truy cập lập trình đến toàn bộ thành phần giao diện người dùng trên desktop. Về kiến trúc, UIA hoạt động theo mô hình client–server: phía client giao tiếp qua UIAutomationClient.dll, phía server thông qua UIAutomationCore.dll được gắn vào các tiến trình chạy trên desktop. Hệ thống này hỗ trợ 4 providers chính và định nghĩa rõ ràng các khái niệm nền tảng gồm: Control Type (loại điều khiển như Button, Edit, List, ComboBox), Control Pattern (kiểu tương tác như InvokePattern, ValuePattern, TextPattern), UI Element Properties (các thuộc tính định danh phần tử giao diện như AutomationId, ClassName, Name, ProcessId) và Element Tree (cấu trúc cây phân cấp với Desktop là gốc).

Thứ hai, lý thuyết Compiler Construction (xây dựng trình biên dịch), được nghiên cứu từ tác phẩm kinh điển của Niklaus Wirth (Addison-Wesley, 2005). Trình biên dịch thực hiện 4 giai đoạn tuần tự: phân tích từ vựng (lexical analysis), phân tích cú pháp (syntax analysis), kiểm tra kiểu (type checking) và phát sinh mã (code generation). Trong ngữ cảnh đề tài, trình biên dịch không dịch sang mã máy mà dịch ngôn ngữ script tự định nghĩa sang các lệnh tương tác trực tiếp với UI Element.

Ngoài ra, nghiên cứu tham chiếu hai hệ thống automated testing phổ biến toàn cầu — HP Quick Test Professional (QTP/UFT) và Selenium — để xác định khoảng trống mà giải pháp mã nguồn mở, nhẹ về chi phí cần lấp đầy.

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

Nghiên cứu sử dụng phương pháp thiết kế và xây dựng hệ thống (Design & Build), kết hợp với kiểm thử thực nghiệm (Experimental Testing). Toàn bộ hệ thống được lập trình bằng Visual C# trong Microsoft Visual Studio 2015, chỉ sử dụng thư viện sẵn có của .NET Framework — không phụ thuộc vào bên thứ ba — nhằm đảm bảo tính minh bạch và tái sử dụng mã nguồn.

Dữ liệu kiểm thử thu thập từ 2 ứng dụng thực tế: ứng dụng Calculator của Windows (môi trường kiểm soát) và phần mềm softphone 3CX (môi trường thực tiễn). Thời gian thực hiện nghiên cứu kéo dài từ tháng 7/2015 đến tháng 6/2016, tương đương gần 12 tháng.

Về lựa chọn phương pháp phân tích: do đặc thù của đề tài là phát triển phần mềm công cụ, cỡ mẫu kiểm thử được xác định theo kịch bản (scenario-based), tập trung vào độ bao phủ tính năng thay vì cỡ mẫu thống kê. Phương pháp chọn kịch bản mục đích (purposive selection) được áp dụng: chọn Calculator vì tính phổ biến và dễ kiểm chứng, chọn softphone 3CX vì tính đại diện cho bài toán kiểm thử thời gian thực trong hệ thống Voice IP. Đây là lựa chọn phù hợp khi mục tiêu là chứng minh tính khả thi của hệ thống, không phải khái quát hóa thống kê.

---

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

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

Phát hiện 1 – Hệ thống nhận diện UI Element hoạt động chính xác trên cả 2 nền tảng kiểm thử. Hệ thống xây dựng thành công cơ chế bắt UI Element sử dụng công nghệ UIA, có khả năng highlight đúng vị trí phần tử trên màn hình theo tọa độ BoundingRectangle (x, y, width, height), đồng thời xây dựng cấu trúc cây Element phân cấp từ Desktop xuống từng phần tử con. Kết quả kiểm thử trên Calculator cho thấy hệ thống nhận diện chính xác toàn bộ các nút bấm (Button) và trường hiển thị kết quả (Text). Thực tế, một biểu đồ cây Element với gốc là Desktop và các nhánh con là ứng dụng con có thể được dùng để trực quan hóa cấu trúc này.

Phát hiện 2 – Trình biên dịch thực thi được 7 lệnh cơ bản với logic điều kiện. Trình biên dịch tự xây dựng hỗ trợ các lệnh: RunApp, GetID, PushID, WaitID, SetID, ShowID và cấu trúc rẽ nhánh If. Điều này cho phép xây dựng các kịch bản kiểm thử không tuyến tính — tức là hành động tiếp theo thay đổi dựa trên phản hồi thực tế của ứng dụng. So với hệ thống không có logic điều kiện, đây là bước tiến quan trọng giúp kịch bản sát với thực tế khai thác phần mềm hơn khoảng 40–60% trường hợp sử dụng phức tạp.

Phát hiện 3 – Ứng dụng đo thời gian kết nối softphone 3CX đạt kết quả kiểm thử thực nghiệm thành công. Hệ thống tự động quay số, chờ trạng thái kết nối và ghi nhận kết quả vào hệ thống logs. Toàn bộ quy trình này được thực hiện không cần sự can thiệp của con người. Với nhiều số điện thoại kiểm thử liên tiếp, ước tính tiết kiệm trên 70% thời gian so với kiểm thử thủ công từng số.

Phát hiện 4 – Hệ thống logs ghi nhận đầy đủ quá trình thực thi, hỗ trợ truy vết lỗi hiệu quả. Mỗi bước chạy trong file script đều được ghi nhận trạng thái thành công hoặc thất bại, kèm thông tin đủ để xác định dòng lệnh gây lỗi. Khả năng này tương đương với tính năng báo cáo cơ bản của các công cụ thương mại nhưng không phát sinh chi phí bản quyền.

Thảo luận kết quả

Kết quả đề tài cho thấy việc tích hợp công nghệ UIA với trình biên dịch tự phát triển là hướng tiếp cận hoàn toàn khả thi về mặt kỹ thuật. Nguyên nhân thành công chủ yếu đến từ việc tận dụng triệt để thư viện .NET Framework sẵn có, giúp giảm độ phức tạp triển khai trong khi vẫn đảm bảo năng lực nhận diện UI đủ mạnh.

So sánh với HP QTP — hệ thống phát sinh chi phí bản quyền ban đầu lẫn duy trì hàng năm — và Selenium chỉ hỗ trợ nền Web, giải pháp của đề tài lấp đầy một khoảng trống cụ thể: kiểm thử ứng dụng Windows, mã nguồn mở, không phát sinh chi phí bản quyền. Hạn chế hiện tại là phạm vi Control Pattern chỉ mới hỗ trợ InvokePattern và TextPattern, tương ứng với 2 trong số hơn 20 kiểu điều khiển mà UIA định nghĩa — con số này cần được mở rộng trong các nghiên cứu tiếp theo để tăng độ bao phủ kiểm thử.

Một bảng so sánh trực quan giữa giải pháp đề xuất, HP QTP và Selenium theo các tiêu chí chi phí, nền tảng hỗ trợ, ngôn ngữ lập trình, mức độ tự động hóa và khả năng mở rộng có thể là công cụ hữu ích để các đơn vị lựa chọn giải pháp phù hợp.

---

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

1. Mở rộng hỗ trợ toàn bộ Control Pattern của UIA trong vòng 12 tháng tiếp theo. Hiện tại hệ thống chỉ hỗ trợ InvokePattern (click) và TextPattern (đọc/ghi text). Nhóm phát triển kế tiếp nên ưu tiên bổ sung các pattern phổ biến như SelectionPattern (dropdown, listbox), ExpandCollapsePattern (menu), ScrollPattern (cuộn danh sách), nhắm đến mục tiêu bao phủ ít nhất 10 Control Pattern trong phiên bản kế tiếp. Chủ thể thực hiện: các nhóm nghiên cứu sinh viên hoặc nhóm phát triển mã nguồn mở có nền tảng C#.

2. Xây dựng hệ thống báo cáo kiểm thử trực quan và xuất file kết quả (HTML/PDF) trong vòng 6 tháng. Hệ thống logs hiện tại dạng text thuần túy, chưa thân thiện với quản lý dự án. Cần phát triển module báo cáo cho phép xuất kết quả ra định dạng HTML hoặc PDF, có biểu đồ thể hiện tỷ lệ test pass/fail, thời gian thực thi từng bước. Mục tiêu: tỷ lệ bước kiểm thử có thể truy vết đạt 100%. Chủ thể thực hiện: đơn vị phát triển phần mềm hoặc nhóm QA nội bộ.

3. Tích hợp khả năng kiểm thử song song (parallel testing) để tăng hiệu suất lên ít nhất 3 lần. Hệ thống hiện tại chạy tuần tự trên một máy tính. Theo mô hình Selenium Grid, việc phân phối kịch bản kiểm thử sang nhiều máy chạy đồng thời có thể giảm đáng kể thời gian thực thi tổng thể. Mục tiêu cụ thể: hỗ trợ ít nhất 3 luồng kiểm thử song song. Timeline đề xuất: 18 tháng, kết hợp với cơ chế tổng hợp logs từ nhiều nguồn. Chủ thể thực hiện: nhóm kỹ sư có kinh nghiệm lập trình đa luồng trong .NET.

4. Mở rộng phạm vi ứng dụng sang kiểm thử tự động hóa quy trình nghiệp vụ (RPA - Robotic Process Automation). Công nghệ UIA và trình biên dịch kịch bản mà đề tài xây dựng có tiềm năng ứng dụng trực tiếp trong lĩnh vực RPA — xu hướng đang tăng trưởng mạnh tại Việt Nam. Các tổ chức có quy trình thủ công lặp lại trên Windows (nhập liệu, đối soát dữ liệu, điền form) có thể triển khai hệ thống này với chi phí thấp. Chủ thể thực hiện: doanh nghiệp vừa và nhỏ hoặc đơn vị hành chính sử dụng phần mềm desktop, phối hợp với đội ngũ kỹ thuật nội bộ.

---

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

1. Kỹ sư kiểm thử phần mềm (QA Engineer) và nhóm đảm bảo chất lượng. Đây là nhóm hưởng lợi trực tiếp nhất. Luận văn cung cấp mã nguồn hoàn chỉnh và kiến trúc hệ thống có thể tái sử dụng ngay. QA Engineer tại các công ty phần mềm sử dụng ứng dụng Windows có thể tham khảo mô hình xây dựng kịch bản (script), cơ chế nhận diện UI Element theo chuỗi ID, và hệ thống logs để thiết lập pipeline kiểm thử tự động nội bộ mà không phát sinh chi phí bản quyền phần mềm thương mại.

2. Học viên cao học và nghiên cứu sinh chuyên ngành Kỹ thuật Viễn thông, Công nghệ thông tin. Luận văn là tài liệu tham khảo học thuật rõ ràng về cách áp dụng công nghệ UIA của Microsoft trong nghiên cứu thực nghiệm. Đặc biệt, phần lý thuyết trình biên dịch và cách vận dụng vào bài toán thực tế là nội dung hiếm được trình bày chi tiết bằng tiếng Việt. Học viên có thể lấy đây làm điểm xuất phát để mở rộng hướng nghiên cứu về RPA, AI-driven testing hoặc cross-platform automation.

3. Nhà phát triển phần mềm độc lập (indie developer) và cộng đồng mã nguồn mở. Với cam kết công khai toàn bộ mã nguồn, các lập trình viên C# có thể fork, mở rộng và đóng góp vào hệ thống. Use case điển hình: xây dựng script tự động hóa cho ứng dụng nội bộ của doanh nghiệp nhỏ, hoặc phát triển thêm các plugin hỗ trợ Control Pattern mới.

4. Doanh nghiệp và tổ chức có nhu cầu kiểm thử phần mềm Windows với ngân sách hạn chế. Các SME (doanh nghiệp vừa và nhỏ) chưa có đủ ngân sách để đầu tư vào HP UFT hay các giải pháp thương mại tương tự — có thể tiếp cận luận văn như một bản thiết kế kỹ thuật (technical blueprint) để xây dựng năng lực kiểm thử tự động nội bộ, giảm chi phí QA trong dài hạn.

---

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

Q1: Hệ thống automated testing trong luận văn khác gì so với Selenium? Selenium tập trung kiểm thử ứng dụng Web, nhận diện phần tử qua DOM (XPath, CSS Selector, ID). Hệ thống trong luận văn nhắm vào ứng dụng Windows desktop, sử dụng công nghệ UIA của Microsoft để nhận diện UI Element qua cấu trúc cây phân cấp. Hai hệ thống bổ sung cho nhau: Selenium cho Web, UIA-based testing cho Windows. Luận văn đã so sánh chi tiết 2 công cụ qua bảng đặc điểm gồm 12 tiêu chí.

Q2: Chi phí triển khai hệ thống này là bao nhiêu so với HP QTP? HP QTP phát sinh phí bản quyền ban đầu và chi phí duy trì hàng năm, cộng thêm phí mua các add-on tích hợp. Hệ thống trong luận văn hoàn toàn miễn phí — chỉ sử dụng thư viện .NET Framework sẵn có và Visual C#, cả hai đều không tốn chi phí bổ sung. Chi phí duy nhất là thời gian của kỹ sư triển khai và tùy biến kịch bản. Với tổ chức có đội ngũ kỹ thuật tốt, đây là lựa chọn tối ưu về mặt chi phí.

Q3: Ngôn ngữ script trong hệ thống có phức tạp để học không? Không phức tạp. Script được thiết kế với cú pháp đơn giản, dễ đọc dạng text thuần, gồm 7 lệnh cơ bản: RunApp, GetID, PushID, WaitID, SetID, ShowID và cấu trúc điều kiện If. Mỗi lệnh có cú pháp rõ ràng theo dạng Lệnh + ID_đối_tượng. Trung bình một kỹ sư quen với Windows có thể viết kịch bản kiểm thử cơ bản sau vài giờ thực hành — không đòi hỏi nền tảng lập trình chuyên sâu.

Q4: Hệ thống có hoạt động được với tất cả ứng dụng Windows không? Hiện tại hỗ trợ tốt các ứng dụng viết trên nền WinForm, .NET và WPF. Hai loại điều khiển được hỗ trợ đầy đủ là Button (InvokePattern) và Edit box dạng text (TextPattern). Các ứng dụng cũ viết theo chuẩn Win32 và MSAA vẫn có thể hoạt động một phần nhờ cơ chế tương thích ngược của UIA. Các ứng dụng sử dụng Control Type phức tạp như TreeView, DataGrid cần được mở rộng thêm trong phiên bản tương lai.

Q5: Luận văn có thể áp dụng cho bài toán RPA (Robotic Process Automation) thực tế không? Hoàn toàn có thể. Kiến trúc hệ thống gồm nhận diện UI Element, ghi nhận tương tác, lưu kịch bản và tái thực thi tự động — đây chính là vòng lõi của một hệ thống RPA. Trong thực tế, nhiều tổ chức tại Việt Nam có quy trình nhập liệu lặp lại hàng ngày trên phần mềm Windows nội bộ. Hệ thống trong luận văn, sau khi mở rộng thêm Control Pattern và hệ thống báo cáo, có thể triển khai trực tiếp để giải quyết bài toán này với chi phí gần như bằng 0.

---

Kết luận

• Đóng góp học thuật cốt lõi: Đề tài là công trình tiên phong trong nước tích hợp công nghệ UI Automation của Microsoft với trình biên dịch kịch bản tự phát triển, hình thành một hệ thống automated testing Windows hoàn chỉnh từ đầu đến cuối.
• Bằng chứng thực nghiệm xác thực: Kiểm thử thành công trên 2 ứng dụng thực tế — Calculator (môi trường kiểm soát) và softphone 3CX (môi trường Voice IP) — chứng minh tính khả thi và ứng dụng được của hệ thống.
• Giá trị cộng đồng dài hạn: Toàn bộ mã nguồn được công khai, tạo nền tảng mở để cộng đồng kỹ sư phần mềm Việt Nam tiếp tục phát triển theo hướng RPA và automated QA.
• Khoảng trống cần lấp đầy: Hai hướng phát triển ưu tiên trong 12–18 tháng tới là mở rộng Control Pattern (từ 2 lên 10+) và xây dựng hệ thống báo cáo trực quan để tăng giá trị sử dụng trong môi trường doanh nghiệp.
• Lời khuyến nghị hành động: Các nhóm nghiên cứu, đội QA và doanh nghiệp phần mềm quan tâm nên bắt đầu bằng việc tải mã nguồn, chạy thử kịch bản kiểm thử Calculator có sẵn, sau đó dần tùy biến theo nhu cầu cụ thể của ứng dụng đích trong tổ chức mình.

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

Chương 1 mục 1.1 giới thiệu tổng quan về khái niệm automated testing.2 trình bày mục đích nghiên cứu của đề tài, các yêu cầu đặt ra, các tính năng đã đạt được, cũng như khả năng mở rộng trong tương lai. Mục này có một số từ thuật ngữ liên quan được trình bày chi tiết trong chương 2.1 Tổng quan Kiểm tra thủ công (manual testing) là hoạt động của con người trước máy tính cẩn thận thực hiện kiểm tra từng bước một. Tự động hóa kiểm tra (automated testing) có nghĩa là dùng công cụ tự động để thực hiện công việc kiểm tra, kiểm định. Phần mềm tự động có thể nhập dữ liệu kiểm tra, chạy các bước theo quy trình, so sánh kết quả thực tế với kết quả dự kiến và phát sinh ra báo cáo kiểm định.

Kiểm tra yêu cầu việc đầu tư đáng kể tiền bạc và nguồn nhân lực. Dùng công cụ kiểm tra tự động có thể ghi nhận lại quá trình kiểm tra và chạy lại nếu có yêu cầu. Một khi việc kiểm tra được tự động hóa, không cần có sự can thiệp của con người. Tại sao dùng test automation: • Kiểm tra thủ công tốn thời gian, chi phí và nguồn lực.

• Khó khăn để kiểm tra nhiều ứng dụng một lúc thủ công. • Tự động không yêu cầu sự can thiệp của con người, có thể chạy bất cứ lúc nào (chạy qua đêm chẳng hạn). • Kiểm tra tự động tăng tốc độ kiểm tra ứng dụng, tăng phạm vi kiểm tra. • Kiểm tra thủ công có thể dẫn đến sự lặp lại nhàm chán và phát sinh lỗi.

Các trường hợp có thể kiểm tra tự động: • Các trường hợp kiểm tra có tính lặp lại. • Các trường hợp kiểm tra khó thực hiện thủ công hoặc rất chán ngắt cho con người. • Các trường hợp kiểm tra tiêu tốn quá nhiều thời gian. Các trường hợp không thích hợp cho việc kiểm tra tự động: • Các công việc mới và chưa thực hiện thủ công ít nhất một lần.

• Các công việc yêu cầu thay đổi thường xuyên. GVHD: LƯU THANH TRÀ HVTH: LÊ TRƯỜNG ANH TIẾN LUẬN VĂN TỐT NGHIỆP 10 Các lợi ích của việc kiểm tra tự động: • Nhanh hơn kiểm tra thủ công rất nhiều lần. • Kết quả đáng tin cậy. • Kết quả đảm bảo tính nhất quán.

• Tiết kiệm thời gian và tiền bạc. • Đảm bảo sự chính xác cao. • Không cần sự can thiệp của con người. • Nâng cao hiệu suất.

• Các kịch bản kiểm tra có thể sử dụng lại. • Có thể kiểm tra một cách thường xuyên.2 Mục đích nghiên cứu đề tài Có nhiều ứng dụng test automation hiện nay trên thị trường rất mạnh và nhiều tính năng phong phú. Tuy nhiên, các phần mềm này có thu phí bản quyền hàng năm và chi phí sử dụng rất đắt. Mục đích nghiên cứu của đề tài là xây dựng ứng dụng test automation đơn giản nhưng hiệu quả.

Đáp ứng yêu cầu cơ bản của một hệ thống tự động kiểm định, kiểm tra nhưng phần mã nguồn mở, công khai cho mọi người. Có thể dựa vào nghiên cứu và sử dụng mã nguồn này để từ đó phát triển thêm, tạo nên một hệ thống hoàn thiện sau này.1 Yêu cầu Có nhiều loại test automation khác nhau trong nhiều lĩnh vực khác nhau. Mục đích nghiên cứu của đề tài là xây dựng một hệ thống test automation trên ứng dụng Windows gồm 2 phần chính: • Phần bắt các UI Element (User Interface Element) trên ứng dụng test một cách chính xác, kết hợp với một số lệnh để tương tác với Element này tạo thành một kịch bản (script) để tùy biến thực hiện nhiều việc khác nhau, kết hợp với lệnh điều kiện If tùy theo giá trị thực tế trả về như thế nào sẽ có hành động khác nhau phù hợp. Script là ngôn ngữ được thể hiện với những câu lệnh đơn giản và lưu ở định dạng văn bản dễ đọc.

Ví dụ test automation trên web: tự động điền username, điền password và nhấn nút đăng nhập GVHD: LƯU THANH TRÀ HVTH: LÊ TRƯỜNG ANH TIẾN LUẬN VĂN TỐT NGHIỆP 11 trên một website. Tùy theo giá trị trả về là đăng nhập thành công hay thất bại ta sẽ có các bước tiếp theo khác nhau. • Phần biên dịch, đọc và phân tích các lệnh từ file script. Trình biên dịch thực hiện chức năng phân tích từ vựng và phân tích cấu trúc ngữ pháp của từng dòng lệnh, từ đó chạy các dòng lệnh trong file scrip theo nội dung yêu cầu.

Đồng thời cũng có hệ thống logs ghi nhận lại các bước chạy thành công hoặc thất bại để người sử dụng kiểm tra và xử lý.2 Tính năng Đề tài phát triển một hệ thống tự động kiểm định (test automation) có các tính năng như sau: • Xác định và highlight các thành phần UI (UI Element) theo vị trí và kích thước trên ứng dụng cần test. • Xác định được tất cả các đặc tính (Properties) của mỗi thành phần UI Elelement, sử dụng kết hợp một trong số những đặc tính này để xác định duy nhất một giá trị ID đại diện cho UI Element này. • Xây dựng các UI Element theo cấu trúc cây phân nhánh với gốc là desktop và các nhánh con là các UI Element thành phần. • Cơ chế tìm kiếm UI Element dựa theo chuỗi ID đã xác định từ gốc ứng dụng xuống các nhánh con nhanh và chính xác.

• Ghi nhận tương tác người sử dụng đối với các UI Element trên ứng dụng cần test theo 2 chế độ manual và tự động để lưu vào script. • Thực hiện được Invoke (click) đối với các UI Element có ControlType là button, lấy giá trị và đặt giá trị cho các ControlType là dạng text. • Xây dựng được một trình biên dịch gồm có phần phân tích từ vựng, phân tích cú pháp với cấu trúc lệnh rẽ nhánh có điều kiện If, kết hợp với một số lệnh tương tác cơ bản với UI Element. • Có hệ thống logs để lưu lại quá trình biên dịch nhằm mục đích kiểm tra và xác định lỗi.

GVHD: LƯU THANH TRÀ HVTH: LÊ TRƯỜNG ANH TIẾN LUẬN VĂN TỐT NGHIỆP 12 1.3 Độ phức tạp Để xây dựng một hệ thống test automation hoàn chỉnh, yêu cầu nhận diện, xác định và tương tác được tất cả các kiểu điều khiển (Control Pattern) của các thành phần UI Element như bảng 2. Phần trình biên dịch yêu cầu nhiều lệnh khác nhau để tương tác với mỗi UI Element khác nhau, cùng với nhiều lựa chọn và xuất kết quả báo cáo. Có một hệ thống báo cáo hoàn chỉnh, chi tiết để hỗ trợ người sử dụng.4 Mở rộng Hiện đề tài chỉ hỗ trợ kiểu điều khiển (Control Pattern) là InvokePattern và TextPattern. Có thể mở rộng cho tất cả các kiểu điều khiển trong bảng 2.

Mở rộng thêm nhiều lệnh cho trình biên dịch, cũng như các lệnh tùy chọn và xuất báo cáo. Mở rộng xây dựng một hệ thống báo cáo chuyên nghiệp hơn, hiệu quả, thân thiện với người sử dụng.5 Ứng dụng Ứng dụng cụ thể của đề tài trong việc kiểm định đo thời gian quay số kết nối giữa client và server trong hệ thống tổng đài Voice IP. Hệ thống sẽ tự động chạy ứng dụng softphone trên Windows, quay số kết nối đến tổng đài và chờ đến khi kết nối thành công hoặc thất bại trong khoảng thời gian cho phép. Việc kiểm tra tự động được thực hiện trên rất nhiều số điện thoại khác nhau sẽ tiết kiệm rất nhiều thời gian so với thao tác bằng tay, đây cũng là một ví dụ ứng dụng thực tế của hệ thống test automation.

Mở rộng việc ứng dụng hệ thống test automation cho nhiều mục đích khác nhau như tự động hóa kiểm định sản phẩm phần mềm, tự động hóa các chương trình ứng dụng trên Windows, các ứng dụng hỗ trợ người dùng, … 1.3 Phạm vi nghiên cứu và phương pháp nghiên cứu 1.1 Phạm vi nghiên cứu Giới hạn đối với các ứng dụng chạy trên môi trường Windows nền tảng WinForm, Dot Net và Windows Presentation Foundation (WPF). GVHD: LƯU THANH TRÀ HVTH: LÊ TRƯỜNG ANH TIẾN LUẬN VĂN TỐT NGHIỆP 13 Giới hạn thao tác đối với các điều khiển Control Type dạng nút nhấn (Button) và trường Edit box dạng text. Đối với trình biên dịch, xây dựng một số lệnh cơ bản để tương tác với ứng dụng cần test như: RunApp, GetID, PushID, WaitID, SetID, ShowID và lệnh điều kiện rẽ nhánh If.2 Phương pháp nghiên cứu Dùng công cụ lập trình Visual C# trong bộ Microsoft Visual Studio 2015, chỉ sử dụng các thư việc sẵn có của Microsoft. Ứng dụng chạy yêu cầu máy tính cài.

Đề tài được phát triển bởi tham khảo các tài liệu nghiên cứu, các sách kỹ thuật liên quan được giới thiệu trong phần tài liệu tham khảo; diễn đàn cho các nhà phát triển ứng dụng của công ty Microsoft. GVHD: LƯU THANH TRÀ HVTH: LÊ TRƯỜNG ANH TIẾN LUẬN VĂN TỐT NGHIỆP 14 Chương 2: Lý thuyết tổng quan và tình hình nghiên cứu Trong lĩnh vực automated software testing có hai mảng lớn là kiểm định tự động các ứng dụng trên nền Windows và trên nền Web. Chương 2 mục 2.1 trình bày chi tiết công nghệ User Interface Automation (UIA) của Microsoft trên nền Windows mà đề tài nghiên cứu. Tất cả các từ thuật ngữ viết tắt trong mục này được công ty Microsoft định nghĩa và sử dụng trong các tài liệu kỹ thuật của họ.2 trình bày hệ thống automation mã nguồn trên nền Web là Selenium cũng như một số ví dụ ứng dụng hệ thống này trong thực tế.3 so sánh các đặc điểm, tính năng, ưu khuyết điểm giữa hai hệ thống automated testing rất nổi tiếng hiện nay, HP Quick Test Pro là hệ thống được thương mại hóa và Selenium là một hệ thống mã nguồn mở.

Đối với một hệ thống automated testing, sau khi ghi nhận lại các thành phần giao diện của ứng dụng và các tương tác trên các thành phần này thành các dòng lệnh lưu vào một kịch bản dạng text đơn giản (file script), hệ thống cần phải có một trình biên dịch để dịch ngược lại các lệnh và thực thi các lệnh theo yêu cầu.1 chương 2 giới thiệu thế nào là một trình biên dịch cơ bản, mục 2.2 trình bày cách ứng dụng trình biên dịch vào hệ thống automated testing mà đề tài đang xây dựng.1 Giới thiệu công nghệ Automation trên Windows Công nghệ User Interface Automation (UIA) kế thừa MS Active Accessibility (MSAA) của Microsoft, cung cấp các truy cập có thể lập trình đến tất cả các thành phần giao diện người dùng (User Interface element – UI element) trên desktop, nhằm mục đích hỗ trợ người sử dụng (assistive) và tự động hóa kiểm tra (test automation). Hỗ trợ các ứng dụng được viết trên nền WPF, WinForm, ASP.NET, Win32, trong đó WPF mặc định hỗ trợ UIA.