Lợi nhuận:
- Khả năng tạo mã kiểm tra giao diện người dùng mạnh mẽ bằng trí tuệ nhân tạo, bao gồm kiểm thử dữ liệu, chờ mở và xác nhận để xác minh kết quả thực của người dùng
- Khả năng tránh các thử nghiệm dễ vỡ (bộ chọn sai, chờ mù) và làm cho các thử nghiệm dễ dàng duy trì trong cấu trúc Mô hình Đối tượng Trang
- Khả năng kiểm tra mọi bài kiểm tra giao diện người dùng được tạo bằng cách phá mã, đồng thời phát hiện và sửa các bài kiểm tra giả mạo đã vượt qua
Mỗi lần nhấp chuột, mỗi lần điền biểu mẫu, mỗi lần chuyển đổi trang mà người dùng thực hiện trong trình duyệt đều không thể được kiểm tra lặp đi lặp lại bằng tay — đó là lý do tồn tại tính năng tự động kiểm tra giao diện người dùng (giao diện người dùng; các thử nghiệm này bắt chước hành vi của người dùng bằng cách lập trình điều khiển một trình duyệt thực). Selenium, Playwright và Cypress là những công cụ phổ biến nhất cho công việc này. Trí tuệ nhân tạo (AI) có kỹ năng cao trong việc viết mã cho các công cụ này: bạn mô tả một trường hợp thử nghiệm, AI cung cấp cho bạn bản nháp của một tập lệnh tự động hóa khả thi. Nhưng ở đây, cảnh báo trọng tâm của mô-đun này lại xuất hiện: mã kiểm tra giao diện người dùng mà AI tạo ra thường có thể là các bài kiểm tra dễ vỡ “bật đèn xanh nhưng xác minh sai” hoặc bay trong gió. Công việc của bạn không phải là chạy mã này mà là đảm bảo rằng nó thực sự xác minh một cách mạnh mẽ điều đúng đắn.
Trong đơn vị này, chúng tôi mong muốn tạo ra các thử nghiệm giao diện người dùng mạnh mẽ, có thể bảo trì và xác thực thực sự bằng AI; Bạn sẽ học cách tránh những bài kiểm tra dễ vỡ.
Ba trụ cột của thử nghiệm giao diện người dùng vững chắc
1. Định vị phần tử chính xác. Thử nghiệm sử dụng bộ chọn để tìm phần tử trên trang. AI thường tạo ra các bộ chọn dễ vỡ: đường dẫn XPath dài (địa chỉ phụ thuộc quá nhiều vào cấu trúc trang), bộ chọn dựa trên tên lớp CSS (ngắt khi thiết kế thay đổi). Cách mạnh mẽ là các thuộc tính ổn định như data-testid mà nhà phát triển đã thêm vào để thử nghiệm. Áp đặt rõ ràng điều này lên AI.
2. Chờ đợi rõ ràng. Nguồn lỗ hổng số một trong thử nghiệm giao diện người dùng là thời gian. Ngủ liên tục(3) (chờ đợi một cách mù quáng) là một thói quen không tốt: đôi khi không đủ, đôi khi lại lãng phí thời gian. Cách chính xác là sử dụng tính năng chờ rõ ràng, có nghĩa là "đợi cho đến khi phần tử này xuất hiện". Nhà viết kịch thực hiện việc này phần lớn một cách tự động; Trong Selenium bạn phải yêu cầu nó một cách rõ ràng.
3. Khẳng định có ý nghĩa. Quá trình kiểm tra sẽ xác minh kết quả mà người dùng thực sự sẽ thấy - chẳng hạn như “số đơn hàng xuất hiện trên màn hình”, chứ không chỉ “đã tải trang”. Nếu bài kiểm tra do AI tạo ra không có xác nhận hoặc không quan trọng thì bài kiểm tra đó sẽ tạo ra một giả vượt qua (đơn vị thứ 1).
Thận trọng: Khi bạn xem thử nghiệm giao diện người dùng do AI tạo lần đầu tiên, hãy kiểm tra tối đa ba điều: bộ chọn có được cam kết không (data-testid), đang chờ (không có chế độ ngủ mù) và xác nhận có xác minh kết quả thực tế của người dùng không? Nếu ba điều này đều ổn thì bài kiểm tra có thể chắc chắn.
Mô hình đối tượng trang
Khi các bài kiểm tra ngày càng lớn hơn, việc viết các bộ chọn bên trong mỗi bài kiểm tra sẽ trở thành một cơn ác mộng khi bảo trì. Mô hình đối tượng trang (POM - mẫu thiết kế thu thập các bộ chọn và hành động cho mỗi trang/màn hình vào một lớp duy nhất) giữ bộ chọn ở một nơi; Khi giao diện thay đổi, bạn cập nhật nó trong một tệp duy nhất. Yêu cầu AI thực hiện các bài kiểm tra theo cấu trúc POM, thay vì trực tiếp; Điều này làm cho việc bảo trì hoàn toàn dễ dàng hơn.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Viết bài kiểm tra Selenium cho trang đăng nhập."
Mạnh: "Viết bài kiểm tra luồng đăng nhập bằng Playwright (TypeScript). Bộ chọn chỉ sử dụng data-testid; không sử dụng quyền kiểm soát những gì người dùng nhìn thấy, không sử dụng tiêu đề trang.”
Lời nhắc mạnh mẽ; Công cụ này cung cấp ngôn ngữ, chính sách bộ chọn, chiến lược chờ, kiến trúc (POM) và kỳ vọng khẳng định mang tính biểu cảm.
Kiểm tra dữ liệu và tính độc lập của môi trường
Một bài kiểm tra giao diện người dùng vững chắc không chỉ được viết chính xác mà còn xây dựng và làm sạch dữ liệu kiểm tra của chính nó. Các bài kiểm tra do AI tạo thường liên kết với người dùng hoặc bản ghi được cho là đã tồn tại trong môi trường (“đăng nhập với tư cách người dùng quản trị viên”). Giả định này bị phá vỡ khi thử nghiệm chạy trong môi trường khác hoặc sau một thử nghiệm khác (vấn đề phụ thuộc thứ tự trong bài 9). Sự thật là mọi thử nghiệm đều tạo ra dữ liệu cần thiết khi bắt đầu thử nghiệm (hoặc chuẩn bị dữ liệu đó bằng lệnh gọi API) và xóa dữ liệu đó vào cuối. Hướng dẫn rõ ràng AI "thiết lập bất kỳ dữ liệu nào mà bài kiểm tra này phụ thuộc vào trong bài kiểm tra; không giả sử dữ liệu được tạo sẵn từ bên ngoài."
Một điểm quan trọng khác là không thực hiện kiểm tra giao diện người dùng bằng dữ liệu người dùng thực. Nếu bản sao cơ sở dữ liệu sản xuất được sử dụng trong môi trường thử nghiệm thì những bản ghi này là dữ liệu của người thật; ảnh chụp màn hình và bản ghi thử nghiệm có thể tiết lộ dữ liệu này. Sử dụng tài khoản kiểm tra tổng hợp (hư cấu); nó vừa bảo vệ tính bảo mật vừa làm cho các bài kiểm tra có thể lặp lại được. Việc thực hiện thử nghiệm "hủy đơn hàng" bằng tài khoản khách hàng thực vừa là một sai lầm về mặt đạo đức vừa là sai lầm trong hoạt động.
Mẹo: Giữ số lần kiểm tra giao diện người dùng càng ít càng tốt; Hãy để việc xác minh thực tế cho các thử nghiệm API và đơn vị, chúng nhanh và ổn định. Kiểm tra giao diện người dùng rất tốn kém và dễ vỡ - chỉ sử dụng nó để xác thực luồng người dùng thực sự từ đầu đến cuối (kiểm tra logic kim tự tháp).
So sánh xe
tính năng
selen
nhà viết kịch
cây bách
ngôn ngữ
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
chế độ chờ tự động
Không (bằng tay)
Có (mạnh)
Có
Đa trình duyệt
rộng
Crom/Firefox/WebKit
Crôm chiếm ưu thế
xu hướng giòn
Cao (chế độ chờ thủ công)
thấp
thấp
Dễ học
trung bình
dễ dàng
dễ dàng
hoạt động song song
Cần có lưới
tích hợp sẵn
Thường trú/trả phí
Khi yêu cầu mã từ AI, hãy nêu rõ đó là phương tiện nào; Nếu không, nó có thể tạo ra mã khó hiểu, không hoạt động.
Bốn mẫu có thể sao chép
1) Tạo thử nghiệm giao diện người dùng vững chắc:
Vai trò của bạn: kỹ sư tự động hóa thử nghiệm cấp cao. Viết bài kiểm tra bằng [công cụ + ngôn ngữ] cho luồng sau: [luồng]. Quy tắc:- Chỉ chọn data-testid; Sử dụng lớp XPath/CSS. - Không ngủ mù; Sử dụng chờ đợi rõ ràng/tự động. - Áp dụng mô hình đối tượng trang. - Hãy để mỗi khẳng định xác minh kết quả thực tế của người dùng. Nhận xét ở đầu mỗi bài kiểm tra tiêu chí chấp nhận mà bạn đang xác nhận.
2) Kiểm soát tính dễ vỡ:
Kiểm tra thử nghiệm độ giòn của giao diện người dùng sau: - Có bộ chọn không ổn định (dài
3) Chuyển đổi sang đối tượng trang:
Chuyển đổi mã kiểm tra đơn giản sau đây thành cấu trúc Mô hình Đối tượng Trang. Di chuyển bộ chọn và hành động tới các lớp trang; Hãy để tệp thử nghiệm chỉ đọc luồng kịch bản. [Công cụ/ngôn ngữ]. Mã: [dán mã]
4) Bằng chứng chuyển tiếp giả:
Chứng minh rằng thử nghiệm giao diện người dùng này thực sự hợp lệ: Tôi thực hiện thay đổi nào đối với mã ứng dụng sẽ biến thử nghiệm này thành ĐỎ? Nếu bạn không thể tìm ra một thay đổi có thể phá vỡ bài kiểm tra thì bài kiểm tra đó không thỏa đáng; thêm các xác nhận bị thiếu.Kiểm tra: [kiểm tra dán]
ba trường hợp nhỏ
Trường hợp 1 - Giải phóng khỏi bộ chọn mỏng manh. Trong số 40 bài kiểm tra mà một nhóm thực hiện bằng AI, 70% đã bị hỏng sau khi cập nhật giao diện; không có lỗi nào trong số đó là lỗi thực sự, chúng đều là các bộ chọn XPath dễ hỏng. Nhóm đã chuyển đổi các thử nghiệm thành cơ sở kiểm thử dữ liệu với mẫu "kiểm tra tính dễ vỡ". Trong ba lần cập nhật giao diện tiếp theo, số lần ngắt sai giảm xuống 0; thời gian bảo trì giảm từ 6 giờ xuống còn 30 phút mỗi tuần.
Trường hợp 2 - Kiểm tra giao diện người dùng giả mạo. AI đã tạo ra bài kiểm tra “thêm vào giỏ hàng”; bài kiểm tra có màu xanh lá cây. Khi mẫu "bằng chứng giả mạo" được chạy, thử nghiệm dường như chỉ kiểm tra số lần nhấp vào nút và tiêu đề trang, không bao giờ xác minh xem bộ đếm giỏ hàng có tăng hay không. Ngay cả khi logic của giỏ hàng bị hỏng hoàn toàn thì bài kiểm tra vẫn vượt qua. Đã thêm xác nhận đúng (huy hiệu giỏ hàng là "1").
Trường hợp 3 - Bẫy chờ đợi mù quáng. Trong thử nghiệm Selenium do AI tạo ra, có chế độ ngủ (2) sau mỗi bước; 60 bài kiểm tra mất 14 phút và thỉnh thoảng vẫn bị hỏng. Sau khi chuyển sang chờ mở (đợi phần tử có thể nhấp được), thời gian giảm xuống còn 5 phút và độ giòn biến mất. Sự chờ đợi mù quáng vừa chậm vừa không đáng tin cậy.
Những lỗi thường gặp
- Đồng ý với các bộ chọn mong manh. Sử dụng các XPath dài do AI tạo ra; Các thử nghiệm gặp sự cố ở lần thay đổi giao diện đầu tiên.
- Để mù `ngủ`. “Giải quyết” thời gian với thời gian chờ cố định; vừa chậm vừa thiếu quyết đoán.
- Khẳng định tầm thường. Chỉ cần xác minh rằng trang đã được tải; không kiểm tra kết quả thực tế của người dùng (fake-pass).
- Phát triển mà không cần POM. Phân phối bộ chọn cho mỗi bài kiểm tra; Cập nhật thủ công hàng chục file khi giao diện thay đổi.
- Không chỉ định công cụ. Không cho AI biết bạn muốn công cụ/ngôn ngữ nào; nhận được mã lộn xộn, không hoạt động.
- Tin tưởng khi bạn chạy mã được tạo và vượt qua. Không kiểm tra bằng cách phá mã.
Tóm lại
Tự động kiểm tra giao diện người dùng xác minh hành vi của người dùng bằng cách điều khiển trình duyệt thực tế bằng chương trình. AI tạo mã này một cách nhanh chóng, nhưng có hai cạm bẫy lớn: các bài kiểm tra dễ vỡ (bộ chọn kém, chờ đợi mù) và các bài kiểm tra vượt qua giả (xác nhận không đầy đủ/tầm thường). Ba trụ cột của thử nghiệm giao diện người dùng vững chắc là bộ chọn cam kết (data-testid), chờ đợi rõ ràng và xác nhận xác minh kết quả thực tế của người dùng. Việc có các thử nghiệm được tạo trong Mô hình Đối tượng Trang sẽ đơn giản hóa triệt để việc bảo trì. Kiểm tra từng bài kiểm tra được tạo bằng câu hỏi "thay đổi nào sẽ phá vỡ điều này?"
Nhiệm vụ ứng dụng
Chọn luồng người dùng từ dự án của riêng bạn (ví dụ: đăng nhập hoặc tìm kiếm). Yêu cầu AI viết bài kiểm tra với mẫu “tạo bài kiểm tra giao diện người dùng mạnh mẽ”. Sau đó: (1) kiểm tra và sửa các bộ chọn và chờ bằng "kiểm tra tính dễ vỡ", (2) chứng minh rằng mỗi bài kiểm tra thực sự xác thực bằng "bằng chứng giả vượt qua", (3) phá mã và quan sát rằng bài kiểm tra chuyển sang màu đỏ. Báo cáo số lượng thử nghiệm được thực hiện và sửa chữa cũng như số lượng lỗ hổng và mật khẩu giả mà bạn đã tìm thấy.
danh sách kiểm tra
- [ ] Tôi đã cung cấp cho AI công cụ, ngôn ngữ, chính sách bộ chọn và kiến trúc (POM) một cách rõ ràng.
- [ ] Tôi đã xác minh rằng bộ chọn là data-testid.
- [ ] Tôi đảm bảo sử dụng tính năng chờ rõ ràng/tự động thay vì ngủ mù.
- [ ] Tôi đã kiểm tra xem mỗi xác nhận có xác minh kết quả thực tế của người dùng hay không.
- [ ] Tôi đã kiểm tra từng bài kiểm tra bằng cách phá mã; Tôi thấy nó chuyển sang màu đỏ.
- [ ] Tôi đã thu thập các bài kiểm tra trong cấu trúc Mô hình Đối tượng Trang.