Một bài tự động ổn định cần kiểm tra điều gì ngoài nút bấm?

Một bài kiểm thử mở trang đặt lịch, chọn giờ, bấm xác nhận rồi kết thúc. Nó chạy xanh nhiều lần. Sau một thay đổi, hệ thống vẫn hiển thị thông báo thành công nhưng không còn giữ lịch. Bài kiểm thử tiếp tục xanh vì điều duy nhất nó chứng minh là nút đã được bấm.

Tự động hóa có ích khi biến một kỳ vọng rõ thành phép kiểm tra lặp lại được. Tốc độ chạy chỉ là một phần. Câu hỏi khó hơn là: khi bài chạy xanh, nhóm được quyền tin điều gì; khi nó đỏ, người nhận có biết cần điều tra ở đâu không?

Bắt đầu ở kết quả cần được bảo vệ

Với đặt lịch, kết quả có thể là khách nhìn thấy đúng giờ đã chọn trong danh sách lịch của mình sau khi quay lại. Đó là mục tiêu khác với việc một thông báo xuất hiện. Cần thống nhất tín hiệu nào đủ để xác nhận, và phần nào thuộc trách nhiệm một lớp kiểm tra khác.

Không nhất thiết dồn toàn bộ bằng chứng vào trình duyệt. Quy tắc không được giữ hai lịch trùng có thể được kiểm tra gần phần nghiệp vụ; một hành trình trên giao diện bảo vệ cách khách chọn và nhận kết quả. Nếu nhiều bài ở cùng lớp lặp lại một chi tiết, chi phí bảo trì có thể tăng mà câu hỏi được trả lời không đổi.

Dữ liệu thử cũng là thiết kế của bài

Hai bài chạy song song cùng đặt một khung giờ sẽ tranh nhau dữ liệu. Một bài đỏ có thể đang báo xung đột do chính bộ kiểm thử tạo ra, chứ không phải thay đổi sản phẩm.

Hãy cấp dữ liệu riêng, hoặc thiết lập trạng thái được chia sẻ có quy tắc. Mỗi bài cần biết tài khoản nào, khung giờ nào và quyền nào đang có. Việc chuẩn bị nên có thể lặp lại; việc dọn dẹp chỉ xóa dữ liệu thuộc lượt chạy ấy. Đặt tên dễ truy nguyên giúp tránh xóa nhầm khi một bước trước đã thất bại.

Tính độc lập còn có nghĩa bài không cần một bài khác chạy trước để đăng nhập hoặc tạo lịch. Nếu đó là cùng một hành trình dài, hãy mô tả nó như một hành trình, không giả vờ là nhiều phép kiểm tra riêng.

Chờ một trạng thái, đừng chờ theo thói quen

Một khoảng nghỉ cố định có thể quá ngắn trên môi trường chậm, nhưng lại làm mất thời gian ở mọi lượt nhanh. Tốt hơn là xác định dấu hiệu ứng dụng đã sẵn sàng: danh sách giờ tải xong, nút được phép thao tác, hoặc lịch mới đã xuất hiện.

Định vị phần tử nên diễn đạt ý nghĩa của nó với người dùng, chẳng hạn vai trò và tên rõ ràng. Khi cần mã định danh dành cho test, hãy thống nhất nó như một giao diện hỗ trợ kiểm thử. Tránh để một thay đổi bố cục vô hại làm mọi đường dẫn tới phần tử bị gãy.

Đây là các nguyên tắc thiết kế; cách viết cụ thể phụ thuộc công cụ và phiên bản đang dùng, cần đọc tài liệu tương ứng trước khi triển khai.

Trừu tượng vừa đủ để còn đọc ra hành trình

Gom thao tác chọn lịch hoặc đăng nhập có thể giảm lặp. Nhưng một hàm tên “hoàn tất mọi thứ” giấu nhiều bước sẽ khiến người đọc không biết bài đang kiểm tra điều gì. Lớp hỗ trợ cần có tên theo ý định và giữ các điều kiện quan trọng dễ nhìn.

Nếu dùng mô tả Given–When–Then, hãy để nó kể về trạng thái, hành động và kết quả nghiệp vụ. Việc chép từng cú bấm sang một ngôn ngữ khác chỉ tạo thêm một lớp phải sửa khi giao diện đổi.

Giữ lại lý do báo đỏ

Khi thất bại, cần có bước đang chạy, kết quả thực tế, dấu vết phù hợp và dữ liệu nhận diện lượt thử. Ảnh chụp giúp thấy trạng thái cuối; dấu vết yêu cầu có thể giải thích vì sao nó xuất hiện. Không đưa mật khẩu hay dữ liệu khách hàng vào tệp báo cáo.

Chạy lại có thể giúp nhận diện tính thất thường, nhưng đổi đỏ thành xanh sau vài lần chưa giải thích được lỗi. Theo dõi nguyên nhân, phạm vi và người xử lý trước khi coi bài đã đáng tin trở lại.

Một điểm xuất phát tốt là tự động hóa một hành trình quan trọng có dữ liệu kiểm soát được, kết quả rõ và chẩn đoán đủ dùng. Khi nhóm tin được báo cáo của hành trình ấy, hãy mở rộng sang rủi ro tiếp theo thay vì chỉ tăng số bài.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.