Trên trang này
Kiểm thử màu xanh có thể giấu một quy tắc thiếu. Trong ví dụ này, tác nhân được giao kết nối cửa hàng với nền tảng email. Máy chủ thử nhận cập nhật liên hệ và trả 200 gọn gàng. Tác nhân xong việc, kiểm thử đạt.
Hệ thống đích thật có thêm quy tắc: thuộc tính tùy chỉnh phải được khai báo trước khi bản cập nhật liên hệ đặt được nó. Máy chủ thử không mô phỏng quy tắc đó. Kết quả xanh chứng minh điều gì đó về tác nhân trong thế giới thử nghiệm, không chứng minh quy tắc bị thiếu ở thế giới thật.
Đây là thỏa thuận cốt lõi của mô phỏng. Nó biến hành động nguy hiểm hoặc tốn kém thành thứ có thể lặp lại. Nó cũng tạo hệ thống thứ hai có thể lệch hành vi so với hệ thống thứ nhất.
Môi trường thay thế giúp thử hành động
Muốn kiểm thử tác nhân biết hành động, hãy cho mục tiêu, môi trường và trạng thái cuối quan sát được. Thảo luận nguồn về môi trường tác nhân mô phỏng mô tả cấu trúc này trong tác vụ trình duyệt và tri thức. Môi trường cho bộ xác minh so trạng thái tác nhân để lại với kết quả đúng đã biết.
Với tích hợp, môi trường thay thế có thể cung cấp vài thao tác đích: liệt kê trường, tạo liên hệ, cập nhật liên hệ và đọc lại. Nó có thể giữ mẫu dữ liệu có trường FNAME đã khai báo và chưa có CUSTOM_TIER. Kiểm thử yêu cầu tác nhân đề xuất ánh xạ, rồi từ chối lượt ghi dùng CUSTOM_TIER trước khi có định nghĩa.
Môi trường này hữu ích vì mỗi lượt chạy bắt đầu từ cùng trạng thái. Bạn có thể thay một điều kiện mỗi lần: trường thiếu, quyền bị từ chối, phiên bản lược đồ cũ, định danh mơ hồ. Có thể so thứ tự lệnh và trạng thái cuối của tác nhân giữa mô hình hay prompt.
Mạnh hơn câu hỏi chỉ bằng chữ về tác nhân sẽ làm gì. Nó kiểm tra tác nhân thực sự đã gọi gì trong thế giới kiểm soát.
Mẫu dữ liệu nên có trạng thái trước và sau mỗi lệnh, không chỉ phản hồi định sẵn. Nếu tác nhân tạo liên hệ hai lần, lệnh thứ hai phải bộc lộ hành vi trùng lặp muốn thử. Nếu đọc trường sau khi ghi, kết quả đọc phải phản ánh trạng thái lưu. Nếu không, tác nhân có thể đạt bằng cách gửi yêu cầu nghe hợp lý mà bài thử không phát hiện chuỗi đó có tạo bản ghi mong muốn không.
Mức giống thực tế là một phần kiểm thử
Phản biện hợp lý: “Nhà cung cấp có sandbox, sao xây cái khác?” Dùng sandbox của họ nếu hỗ trợ trường hợp cần và giữ dữ liệu an toàn. Môi trường thay thế tại chỗ đáng có khi cần đặt lại trạng thái chắc chắn, cố ý gây lỗi hoặc thử lệnh mà sandbox không dàn dựng được. Nó cũng tốn bảo trì. Mọi quy tắc mô phỏng có thể sai hoặc cũ.
API liên hệ Brevo chính thức nói thuộc tính liên hệ phải có trong tài khoản và giá trị sai kiểu đã khai báo sẽ bị bỏ qua. Môi trường thay thế từ chối mọi giá trị sai sẽ khác trường hợp trong tài liệu. Nó có thể dạy tác nhân chờ một lỗi không hề xuất hiện.
Ghi rõ môi trường thay thế bao phủ những hành vi nào. Giữ vài phép thử hợp đồng nhỏ với API thật hoặc môi trường thử được hỗ trợ. Khi phát hiện khác biệt, cập nhật mô phỏng và thêm trường hợp làm lộ nó. Mô phỏng là mô hình nhà cung cấp, không thay nhà cung cấp.
Thời gian cũng vậy. Môi trường thay thế cho mọi lượt ghi hiện ngay có thể bỏ lỡ quy trình đọc quá sớm. Cố ý trì hoãn mọi lượt ghi lại có thể bịa lỗi nhà cung cấp không tạo. Chỉ mô phỏng thời gian nơi nó ảnh hưởng quyết định đang thử, và gắn nhãn phần còn lại là ngoài phạm vi. Một lần đạt sau đó có nghĩa chính xác: tác nhân hoàn tất các hành động này theo các quy tắc đã mô hình.
Hướng dẫn bộ kết nối Brevo của Tajo nêu cùng vấn đề từ phía người bán: yêu cầu thành công nhưng trường vẫn vắng. Kiểm thử chỉ hữu ích khi kiểm tra trường, không chỉ phản hồi HTTP.
Hệ thống đích mô phỏng thử tác nhân theo quy tắc đã mô hình. Phép thử hợp đồng so chúng với hệ thống thật trước bản xem trước giới hạn.
Từ tập dượt an toàn tới bằng chứng giới hạn
Mô phỏng đạt nên dẫn tới bản xem trước thật nhỏ. Chọn vài bản ghi có trạng thái đích mong đợi rõ ràng. Gồm bản ghi bình thường, một bản không có trường tùy chọn và một bản có trạng thái đồng ý cấm dùng cho marketing. Kiểm tra đích thực sự lưu gì. Đừng suy kết quả chỉ từ dữ liệu yêu cầu.
Bản xem trước mô phỏng và bước kiểm tra đích trả lời hai câu hỏi khác nhau. Bản xem trước ánh xạ của Tajo thử quy tắc chuyển đổi mà không ghi vào đích. Giao diện đề xuất dưới đây cho thấy ranh giới tiếp theo: cập nhật đã áp dụng vẫn cần kiểm tra trạng thái tại đích. Giữ bước ấy ở trạng thái chờ để không nhầm buổi thử với bằng chứng.
Ghi xong vẫn cần bằng chứng
Đồng bộ khách hàng đã xong chưa?
Đã áp dụng lượt ghi. Còn chờ xác minh.
Chưa kiểm tra trạng thái ở đích.
Hoạt động đồng bộ
- Đã nhận yêu cầu
- Đã áp dụng cập nhật
- Chờ kiểm tra đích
Lượt chạy mẫu · 14:32 UTC
Điều đã biết
- Phản hồi từ nhà cung cấp
- Đã nhận
- Kết quả ghi
- Đã áp dụng
- Đọc lại từ đích
- Đang chờ
Lệnh gọi thành công không chứng minh trạng thái cuối.
Bố cục đề xuất dựa trên bảng hoạt động của Tajo. Hình này thêm trạng thái xác minh; không khẳng định tính năng đọc lại từ đích đã được triển khai.
Bản xem trước cần phạm vi hẹp và điều kiện dừng rõ. Thất bại phải ngăn kích hoạt rộng và chỉ ra đúng chỗ lệch: định nghĩa trường, định danh, kiểu, quyền hoặc thời gian. Đạt không chứng minh mọi bản ghi tương lai đều giống, nhưng xác nhận hợp đồng chạy với các trường hợp chọn hôm nay.
Chuỗi bước này tách hai câu hỏi. Mô phỏng hỏi “Tác nhân có theo quy tắc đã thiết kế khi thế giới do ta kiểm soát?” Bản xem trước thật hỏi “Quy tắc đó có hợp tài khoản nhà cung cấp này?” Không câu nào thay được câu kia.
Hướng dẫn reverse ETL giải thích vì sao công việc cuối lặp trên nhiều bản ghi. Sự lặp lại khuếch đại mọi khác biệt giữa hợp đồng mô phỏng và thật.
Tập dượt trong thế giới có thể đặt lại. Rồi quan sát thế giới không thể.
Câu hỏi Thường gặp
Hệ thống đích mô phỏng kiểm tra được gì?
Nó kiểm tra tác nhân có chọn lệnh mong đợi, tuân quyền, xử lý lỗi đã biết và để lại trạng thái mong đợi trong mô phỏng không.
Nó không chứng minh được gì?
Nó không xác nhận mô hình của nhà cung cấp đã đầy đủ. Hành vi chưa ghi tài liệu, thời gian và cài đặt riêng tài khoản có thể khác.
Sau khi mô phỏng đạt thì làm gì?
Chạy bản xem trước hoặc canary có giới hạn với hệ thống đích thật, rồi xem trạng thái tạo ra trước khi kích hoạt rộng.