Hành trình xây dựng hệ thống kiểm thử tự động AI: Từ thử thách đến giải pháp đột phá!
Lê Lân0
Hành Trình Phát Triển Hệ Thống Tự Động Tạo và Chạy Test End-to-End Bằng AI
Mở Đầu
Trong lĩnh vực kiểm thử phần mềm, việc tự động hóa test end-to-end với độ chính xác cao và ít sự can thiệp thủ công luôn là thách thức lớn. Việc xây dựng một hệ thống có thể tạo và thực thi các test case một cách tự động chỉ từ URL mà không cần ghi lại thao tác hay ảnh chụp màn hình là mục tiêu đầy tham vọng.
Chúng tôi đã đặt ra mục tiêu phát triển một hệ thống tự động hóa test end-to-end hoạt động với kết quả dự đoán được và yêu cầu rất ít thông tin đầu vào từ người dùng. Hệ thống này không cần dựa vào các luồng ghi sẵn (recorded flows), ảnh chụp màn hình hay các thiết lập thủ công, mà chỉ cần một URL duy nhất. Qua quá trình nghiên cứu và triển khai, chúng tôi chia sẻ chi tiết những phương pháp đã thử, những điểm không thành công, và cách hệ thống ngày một hoàn thiện. Từ khởi đầu với học tăng cường (reinforcement learning), chuyển sang các mô hình dựa trên transformer, và cuối cùng kết hợp giữa các LLM tự host, API bên ngoài cùng với mô hình truy vấn kết hợp (RAG), để tạo nên một hệ thống đa tác tử (multi-agent) hiệu quả.
Nếu bạn quan tâm đến việc tích hợp AI vào tự động hóa kiểm thử hay chỉ đơn giản muốn hiểu rõ cách một hệ thống như vậy được tạo nên, hãy tiếp tục theo dõi bài viết này.
1. Các Thử Nghiệm Ban Đầu: Học Tăng Cường Trên Đầu Vào Hình Ảnh
Tiếp Cận Ban Đầu
Chúng tôi bắt đầu từ góc nhìn kiểm thử UI như một bài toán reinforcement learning (RL). Mục tiêu là huấn luyện một agent có thể "nhìn thấy" trang web đã render thông qua ảnh chụp màn hình, từ đó xác định vị trí các trường nhập liệu và các nút bấm, rồi thực hiện hành động giống như người dùng thực.
Thực Thi và Thách Thức
- Mô hình RL nhận đầu vào là ảnh chụp màn hình được feed vào mạng neural kết hợp hình ảnh và văn bản.
- Mỗi bước huấn luyện cần render lại ảnh, làm inference trên mô hình lớn.
- Kích thước mô hình lên tới hơn 15 GB, thời gian huấn luyện và chạy inference rất lâu.
- Dữ liệu đánh dấu (label) rất hạn chế, không thể tổng quát hóa tốt với các trang web đa dạng.
- Tính ổn định và khả năng ứng dụng thực tế rất thấp.
Bài học rút ra: Các mô hình RL dựa thuần trên hình ảnh cho E2E testing về cơ bản đã lỗi thời với mục tiêu của chúng tôi. Cần tìm hướng tiếp cận nhẹ nhàng, tập trung vào xử lý văn bản thay vì chỉ xử lý hình ảnh.
2. Chuyển Hướng Sang Mô Hình Text-First và Các Nhiệm Vụ NLP
Các Nhiệm Vụ Đơn Giản Ban Đầu
Sau khi từ bỏ RL hình ảnh, chúng tôi tập trung vào xử lý ngôn ngữ tự nhiên (NLP) với các tác vụ như:
- Phát hiện ngôn ngữ của trang: Chọn những mô hình phát hiện ngôn ngữ nhẹ, dung lượng dưới 100 MB, và tuân thủ giấy phép MIT hoặc Apache để tránh chi phí dịch vụ bên ngoài.
- Tóm tắt nội dung trang: Giúp nhận biết mục đích trang. Ví dụ, khi click "Liên hệ", kết quả tóm tắt là "Trang Liên hệ" sẽ chứng tỏ hành vi điều hướng thành công.
Kết Quả Thử Nghiệm
- Các mô hình tóm tắt chuyên biệt cỡ 1.5 GB trở lên nhìn chung cồng kềnh và chất lượng chưa thật sự tốt.
- Nhóm các LLM nhỏ có dung lượng 1-2 GB lại cho kết quả tóm tắt vượt trội hơn.
3. Thời Đại LLM Tự Host: Tìm Mô Hình Phù Hợp
Khảo Sát Mô Hình
Chúng tôi tìm kiếm trên nền tảng Hugging Face những mô hình transformer nhỏ, mã nguồn mở, giấy phép MIT hoặc Apache để tối ưu chi phí và linh hoạt. Một số thử nghiệm tiêu biểu:
Mô hình | Kích thước | Đánh giá chất lượng |
|---|---|---|
Microsoft PHI | 1.5 GB | Chưa đạt yêu cầu |
QWEN-tiny (1.5B) | 1.5 GB | Đạt chất lượng ổn định |
QWEN-3B | 3 GB | Chất lượng cải thiện |
QWEN-7B | 14 GB (quantized) | Được sử dụng dưới dạng lượng tử hóa |
Triển Khai
- Chạy QWEN-1.5B trong Docker trên GPU 16GB.
- Dùng DOM serializer của chúng tôi để chuyển DOM thành JSON có cấu trúc, giảm khoảng 50% token so với dùng raw HTML.
- Gửi đoạn text hiển thị (visible text) cho LLM để tóm tắt và đối chiếu với kỳ vọng.
Lý do chọn JSON thay vì HTML: JSON giữ lại các phần tử trọng yếu như thẻ, kiểu thẻ, thuộc tính quan trọng. HTML chứa nhiều dữ liệu thừa như style, class làm tăng chi phí token không cần thiết.
4. Từ Tóm Tắt Đến Tìm Kiếm Phần Tử và Tạo & Kiểm Tra Test Case
Tạo Đề Xuất Test Case
- Với mỗi URL, hệ thống tự động phân tích, nhận diện trường nhập liệu, form, và các nút bấm.
- Dựa trên các phần tử này, LLM tạo ra các kịch bản test định dạng JSON (ví dụ: đăng nhập thành công, đăng nhập sai mật khẩu, trường nhập thiếu, v.v.).
- Hệ thống thúc đẩy người dùng không cần dung ghi lại thao tác hay lưu ảnh màn hình.
Thực Thi và Xác Thực Test Case
Quy trình "ping-pong" giữa backend và LLM như sau:
Bước | Mô tả |
|---|---|
1 | Backend gửi DOM dạng JSON serialized cho LLM |
2 | LLM trả về các test case dạng JSON |
3 | Playwright thực hiện các test case trên trình duyệt |
4 | Thu thập DOM mới sau thực thi |
5 | LLM so sánh tóm tắt DOM cũ và mới để đánh giá pass/fail |
Đảm Bảo Tính Xác Định
Bằng cách cài đặt
temperature=0 trong LLM, mô hình cho ra các kết quả nhất quán và có thể dự đoán được với cùng một đầu vào.5. Những Thử Thách Kỹ Thuật và Tối Ưu Vi Nhỏ
Quá Tải Khung Ngữ Cảnh (Context Window)
- Trang web phức tạp với nhiều thành phần dẫn đến vượt giới hạn token của LLM.
- Việc thiếu kiên định trong cách viết code phía frontend khiến DOM sinh ra rất đa dạng, khó tiêu chuẩn hóa.
Giải Pháp
- Chia nhỏ DOM thành các khối như header, content, footer để tóm tắt riêng từng phần rồi gộp kết quả.
- Nén ID: Thay thế các UUID dài bằng số nguyên nhỏ trước khi gửi LLM, sau khi inference remap lại, tiết kiệm khoảng 30% token khi số lượng phần tử lớn.
- Sử dụng mô hình tự host trên cluster nội bộ để giảm chi phí.
Quản Lý Mô Hình và Tài Nguyên
Mô hình | VRAM | Lợi ích | Hạn chế |
|---|---|---|---|
QWEN-1.5B | ~3 GB | Chạy mượt, hiệu suất ổn định | Chất lượng còn giới hạn |
QWEN-3B | 8 GB | Chất lượng khá, nghiên cứu mở rộng | Giấy phép hạn chế (Research only) |
QWEN-7B (quant) | 14 GB | Độ chính xác cao, tiết kiệm VRAM | Phức tạp, cần kỹ thuật lượng tử hóa |
Chúng tôi chuyển sang dùng vLLM thay vì Python runner của Hugging Face để tận dụng caching attention, giảm đáng kể độ trễ và bộ nhớ.
Kiến Trúc Đa Tác Tử (Multi-Agent) và Kiến Trúc Hàng Đợi
- REST API không ổn định khi tải lớn, vLLM không tương thích tốt với uWSGI.
- Dùng hàng đợi Redis giúp truyền thông tin giữa các tác tử ổn định hơn.
- Tuy nhiên, thời gian tạo và xác nhận test case lên đến 50 giây trên mỗi lần—còn quá chậm với bộ test lớn.
- Để hỗ trợ multi-user và CI, nhiều instance GPU là yêu cầu bắt buộc, nhưng chi phí không khả thi.
Hướng đi tiếp theo: Tối ưu đầu vào gửi cho LLM, rà soát lại toàn bộ quy trình và nghiên cứu tích hợp API bên ngoài như OpenAI hoặc Gemini để tăng tốc.
Kết Luận
Chúng tôi đã trải qua một quá trình chuyển đổi dài từ mô hình RL dựa trên hình ảnh sang các mô hình LLM tập trung vào văn bản, kết hợp các kỹ thuật xử lý DOM tinh gọn và các chiến lược cải thiện hiệu năng để xây dựng hệ thống tự động tạo và chạy test end-to-end hiệu quả. Việc lựa chọn mô hình phù hợp cùng kiến trúc multi-agent và tối ưu hóa lưu lượng giao tiếp giữa backend và LLM là chìa khóa để duy trì tính ổn định cũng như khả năng mở rộng của hệ thống. Hành trình vẫn còn tiếp tục khi chúng tôi hướng đến tích hợp các API LLM bên ngoài và tối ưu hóa sâu hơn nhằm đáp ứng nhu cầu thực tiễn trong môi trường CI đa người dùng.
Nếu bạn muốn thử trải nghiệm hệ thống này, hãy truy cập Treegress và nhập URL bất kỳ để xem hệ thống hoạt động như thế nào.
Tham Khảo
- OpenAI GPT Documentation. https://platform.openai.com/docs
- Hugging Face Models Repository. https://huggingface.co/models
- Alibaba QWEN Models. https://www.alibabacloud.com/
- Playwright Automation Framework. https://playwright.dev/
- Reinforcement Learning for UI Automation, Medium Article, 2023.
- vLLM: An Efficient Transformer Inference Framework. https://github.com/vllm-project/vllm
- Treegress Demo Platform. https://www.treegress.com/
June 15, 2024
Loading...