Mở thư mục dự án
Khởi động FlowLatch, chọn thư mục chứa các bài kiểm thử làm thư mục làm việc, và chọn Ask first để mọi hành động thay đổi nội dung đều chờ sự đồng ý của bạn. Kết nối mô hình nếu bạn chưa làm, và dùng nút Test để kiểm tra điểm cuối.
Quy trình
Kiểm thử web tự động: mở, chạy, đọc và sửa một luồng
03
Kiểm tra luồng thanh toán trên ứng dụng staging của bạn
Bạn có một bản sao staging của cửa hàng, một tài khoản kiểm thử và một thư mục chứa các bài kiểm thử, và muốn biết liệu đăng nhập, thêm vào giỏ hàng và thanh toán vẫn hoạt động sau thay đổi hôm nay. Đây là kiểm thử web tự động ở dạng nhỏ nhất: một luồng, một lệnh kiểm thử, một kết quả bạn có thể đọc. FlowLatch mở thư mục, chạy lệnh qua Shell và hiển thị mã thoát thực tế trên một thẻ. Nếu luồng thất bại, nó chỉ ra dòng lỗi và đề xuất một bản sửa dưới dạng diff, bạn quyết định có chấp nhận hay không. Các bước dưới đây thực hiện 4 hành động từ thư mục đến kết quả. Chỉ làm việc trên ứng dụng bạn xây dựng hoặc được ủy quyền kiểm thử, dùng tài khoản kiểm thử và dữ liệu giả, và dùng chế độ kiểm thử của thiết lập thanh toán riêng cho bước thanh toán, không dùng thẻ thật. Kiểm tra email gửi đến một hộp thư kiểm thử đã thiết lập cho mục đích này.
Liệt kê các tệp kiểm thử
Hãy hỏi về cấu trúc của các bài kiểm tra. Các lệnh list_dir và glob sẽ hiển thị danh sách tệp, còn read_file sẽ mở quy trình thanh toán để bạn và agent bắt đầu từ cùng một nội dung trước khi bất kỳ hành động nào được thực hiện hoặc thay đổi. Mỗi hành động sẽ xuất hiện trong cuộc trò chuyện dưới dạng một thẻ kèm theo kết quả.
Chạy lệnh kiểm thử của bạn
Cho agent biết lệnh kiểm thử mà dự án của bạn sử dụng. Shell chạy nó trên Windows hoặc trong WSL, và thẻ hiển thị đầu ra đầy đủ và mã thoát thực tế, không phải bản tóm tắt. Mở rộng thẻ nếu bạn muốn xem mọi dòng, và dùng grep trên đầu ra để nhảy đến bước thất bại.
Đọc kết quả và sửa lỗi
Khi có lỗi, hãy hỏi đầu ra nói gì. Agent đề xuất một chỉnh sửa dưới dạng diff, và không có gì được ghi cho đến khi bạn chấp nhận nó. Từ chối những gì có vẻ sai, sau đó chạy lại lệnh để xem mã thoát mới. Lặp lại cho đến khi luồng thành công hoặc bạn biết cần thay đổi gì trong ứng dụng.
Dàn ý luồng kiểm thử bạn có thể sao chép
Chạy luồng thanh toán trên bản sao staging của tôi và cho tôi biết những gì đã thất bại.
- list_dir
tests/đã liệt kê - read_file
tests/checkout-flow-test.txtđã tải - Shell
your test commandexit 0 - grep
FAIL reports/0 khớp
chờ bạn xác nhận trước khi thực hiện bước tiếp theoTừ chốiChấp nhận
checkout-flow-test.txt
# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textDàn ý này là văn bản thuần và nằm trong kho lưu trữ bên cạnh các bài kiểm thử của bạn. Framework kiểm thử của bạn chuyển đổi từng bước thành mã, và FlowLatch dùng tệp làm đặc tả khi nó viết mã đó, chạy nó và so sánh kết quả với ba dòng expect. Thay đổi tên sản phẩm và các trang để phù hợp với ứng dụng staging của riêng bạn.
Hướng dẫn từng bước cho kiểm thử trình duyệt tự động
Tìm và đọc các bài kiểm thử hiện có
Bắt đầu bằng cách hỏi vị trí của các bài kiểm thử. list_dir hiển thị các thư mục, glob liệt kê mọi tệp khớp với một mẫu như các bài kiểm tra thanh toán, và read_file mở những tệp bạn quan tâm để bạn có thể xem cách một luồng được xây dựng hiện nay. grep sau đó tìm kiếm các bộ chọn và các điều kiện chờ mà chúng sử dụng. Tất cả những điều này chỉ đọc, vì vậy đây là bước đầu tiên hợp lý trong chế độ Plan only, tạo ra một kế hoạch và không chạy gì. Kế hoạch tồn tại sau khi khởi động lại, vì vậy bạn có thể quay lại nó vào ngày mai. Khi bạn sẵn sàng cho các lần chạy thực sự, hãy chuyển sang Ask first và đọc lại kế hoạch một lần nữa. Ghi lại các luồng đã được bao phủ, để bạn biết những luồng nào còn thiếu bài kiểm thử.
Chạy bộ kiểm thử và đọc mã thoát
Sau khi nâng cấp thời gian chạy, các lỗi trong bộ kiểm thử e2e thường đến từ môi trường hơn là từ ứng dụng của bạn, vì vậy hãy đọc lỗi đầu tiên trước khi chạm vào bài kiểm thử. Shell chạy lệnh kiểm thử của bạn và thẻ giữ nguyên đầu ra đầy đủ và mã thoát thực tế, đây là kết quả thành công hoặc thất bại trung thực nhất. grep có thể trích xuất bước thất bại khỏi một nhật ký dài. Yêu cầu một giải thích đơn giản về lỗi trong cuộc trò chuyện, so sánh nó với đầu ra, và chỉ sau đó quyết định xem một tệp kiểm thử có cần chỉnh sửa hay không. Nếu lỗi đề cập đến một gói bị thiếu hoặc một cài đặt đã thay đổi, hãy sửa môi trường trước và chạy lại cùng lệnh đó. Thường thì bộ kiểm thử sẽ thành công mà không cần chỉnh sửa nào, và mã thoát trên thẻ chứng minh điều đó.
Sửa bộ chọn và chạy lại
Bảo trì bộ chọn trong tự động hóa kiểm thử giao diện người dùng là công việc phổ biến nhất, vì thay đổi bố cục sẽ làm hỏng các bộ chọn được gắn liền với nó. grep tìm bộ chọn cũ trong mọi tệp, read_file hiển thị các bước xung quanh nó và edit_file đề xuất một nhãn ổn định hoặc id kiểm thử thay thế. Trong Ask first, agent tạm dừng và hiển thị diff. Chấp nhận các dòng có vẻ đúng, sau đó để Shell chạy lại lệnh. Mã thoát màu xanh lá cây sau khi chỉnh sửa là kết quả bạn muốn, và diff vẫn tồn tại trong lịch sử kho lưu trữ của bạn cho người xem tiếp theo. Nếu lệnh vẫn thất bại, hãy đọc đầu ra mới trước khi yêu cầu thêm thay đổi, vì một chỉnh sửa thứ hai dựa trên một phỏng đoán sai sẽ khiến nguyên nhân khó nhận ra hơn. Hãy giữ mỗi diff đủ nhỏ để đọc trong một lần ngồi.
Lặp lại một bài kiểm thử thất bại để kiểm tra tính không ổn định
Khi một bài kiểm thử e2e giao diện người dùng bị lỗi, nguyên nhân thực sự thường là một điều kiện chờ cố định, dữ liệu kiểm thử dùng chung hoặc thứ tự của các bài kiểm thử, không phải ứng dụng. Hãy yêu cầu FlowLatch chạy bài kiểm thử thất bại nhiều lần bằng cùng một lệnh và báo cáo từng mã thoát. Kết quả hỗn hợp có nghĩa là bài kiểm thử không ổn định. Nếu framework của bạn đã lưu ảnh chụp màn hình, ocr sẽ đọc văn bản trong đó, và văn bản trang từ lần chạy thất bại thêm một manh mối thứ hai. Sửa điều kiện chờ hoặc dữ liệu trong một diff, xem xét nó, và chạy lại bài kiểm thử. Cấp cho mỗi bài kiểm thử dữ liệu riêng và đặt lại nó, chờ một điều kiện hiển thị thay vì một khoảng thời gian cố định, và giữ các bài kiểm thử độc lập với thứ tự của nhau. Lặp lại lần chạy một lần nữa sau khi sửa; một lần chạy thành công chứng minh rất ít.
