Kiểm thử hành trình tác tử: trạng thái, lỗi và phần chờ

Đăng ngày 27/10/2026

Kiểm thử hành trình tác tử phải nhìn việc đã làm

Kiểm thử hành trình tác tử trả lời một câu hỏi thực tế: sau cuộc trao đổi và chuỗi thao tác, công việc đã ở trạng thái nào, có điều gì bị làm sai và phần nào còn chờ? Một câu trả lời cuối nghe hợp lý có thể che phiếu tạo trùng, hồ sơ sửa nhầm hoặc yêu cầu chưa tới người xử lý. Vì vậy, không nên nghiệm thu bằng cách đọc lời tác tử tự kể rằng mọi việc đã hoàn tất. Cần bằng chứng từ môi trường và quy tắc chấp nhận độc lập.

Bài dùng ca giả định một tác tử tiếp nhận yêu cầu bảo hành tại Việt Nam: tìm hồ sơ, thu phần thông tin còn thiếu, chuẩn bị phiếu và chuyển người có thẩm quyền. Tác tử chưa được tự xác nhận quyền lợi, từ chối bảo hành hoặc hứa thay sản phẩm. Hai công cụ đề xuất là hợp đồng ca thử có trạng thái và lịch gây lỗi theo điểm chuyển. Chúng giúp kiểm cả đường đi bình thường, hành động bị cấm và công việc phải dừng để người tiếp tục.

Tau-bench kết hợp hội thoại với người dùng mô phỏng, công cụ và chính sách theo miền, rồi kiểm trạng thái cuối cùng cùng thông tin cần trả lời. Nghiên cứu cũng nêu giới hạn: đạt trạng thái cuối đúng vẫn có thể bỏ qua một bước xác nhận theo chính sách. Điều có ích cho nghiệm thu là phải tách kết quả với điều kiện thực hiện. Bài không dùng điểm của mô hình trong nghiên cứu để dự báo khả năng bảo hành của một hệ thống hiện tại[1].

Kết quả nghiệp vụ khác một đường thao tác được chép sẵn

Cùng một yêu cầu có thể được xử lý đúng bằng nhiều đường: tìm theo mã phiếu, theo mã sản phẩm hoặc hỏi thêm thông tin được phép. Bộ kiểm không nên bắt mọi tác tử lặp đúng một chuỗi nút đã ghi nếu các đường khác vẫn hợp lệ. Ngược lại, làm đủ số bước không đủ chứng minh mục tiêu đạt. Quy tắc chấm cần mô tả trạng thái được chấp nhận, thông tin phải có và những điều cấm, thay vì chỉ so lời thoại hoặc thứ tự gọi hàm giống bản mẫu.

WebArena phân biệt các cách chấm tác vụ tìm thông tin với kiểm trạng thái môi trường cho tác vụ điều hướng hoặc thay đổi nội dung. Mô tả đó nhắc người thiết kế chọn bằng chứng theo loại việc. Tìm được trang đúng chưa chứng minh phiếu được tạo; thấy thông báo trên giao diện chưa thay việc kiểm dữ liệu đã lưu. Nghiên cứu là một môi trường web có giới hạn, chưa xác nhận bộ kiểm nội bộ của doanh nghiệp đã phản ánh đầy đủ công việc thật[2].

Với ca bảo hành, thành công vòng đầu có thể là một phiếu tiếp nhận đúng sản phẩm, đủ phần bắt buộc hoặc ghi rõ phần thiếu và có nơi nhận. Nếu chính sách yêu cầu người duyệt, phiếu không được ở trạng thái quyền lợi đã xác nhận. Một kết quả chuyển người đúng có thể là đạt mục tiêu, còn tự đóng hồ sơ để tạo cảm giác hoàn tất là lỗi. Người nghiệp vụ phải chốt các trạng thái này trước khi nhóm kỹ thuật xây thang chấm.

Hợp đồng ca thử ghi cả điều cấm và việc chưa hoàn thành

Hợp đồng ca thử đề xuất gồm trạng thái đầu, mục tiêu, phạm vi quyền, điều luôn phải giữ, bằng chứng chấm và điểm bàn giao. Trạng thái đầu mô tả hồ sơ nào có sẵn và phần nào chưa có; mục tiêu nói kết quả mong muốn của lượt đó. Điều luôn phải giữ có thể là không lộ hồ sơ khác khách, không tạo phiếu trùng hoặc không đổi trạng thái quyền lợi. Người chấm giữ hợp đồng riêng; tác tử không được sửa tiêu chí chỉ vì nó chưa hoàn tất.

Bằng chứng chấm cần bao gồm trạng thái trước và sau cùng dấu vết thao tác liên quan. Không nhất thiết phải lưu mọi nội dung nhạy cảm để kiểm, nhưng phải đủ phân biệt đúng đối tượng, đúng thay đổi và đúng người nhận. Khi một thao tác không được phép xuất hiện rồi bị hoàn tác, trạng thái cuối có thể giống ban đầu. Bộ kiểm chỉ nhìn bản cuối sẽ bỏ sót hành động đó. Vì thế, các điều cấm quan trọng cần được quan sát trong quá trình, không chỉ cuối phiên.

Điểm bàn giao mô tả ai nhận phần chưa xong và tác tử phải giữ lại điều gì. “Thiếu ảnh sản phẩm” khác “không tìm thấy hồ sơ” và khác “công cụ lưu phiếu không trả kết quả”. Ba trạng thái dẫn tới cách tiếp tục khác nhau. Bộ kiểm cần chấp nhận cách diễn đạt linh hoạt nhưng phải thấy đúng thông tin trạng thái. Nếu chưa xác nhận có nơi nhận, tác tử không được báo người phụ trách đã xử lý; đây là một điều kiện chấm có thể kiểm rõ.

Môi trường thử phải đổi trạng thái theo hành động

Một môi trường luôn trả cùng phản hồi thành công cho mọi lệnh sẽ không phát hiện được tạo trùng hoặc sửa nhầm. Mô hình thử cần có hồ sơ, phiên bản, quyền và hàng chờ phù hợp với phạm vi ca. Khi tạo phiếu, trạng thái thay đổi; khi quyền bị thu hồi, yêu cầu sau đó bị xử lý theo quy tắc. Sau mỗi lượt cần khôi phục đúng trạng thái đầu, để lỗi của lượt trước không âm thầm thay điều kiện của lượt sau.

Tài liệu Hypothesis mô tả kiểm thử có trạng thái bằng chuỗi hành động có thể kết hợp và các điều kiện kiểm sau từng bước. Công cụ hỗ trợ sinh chuỗi để tìm lỗi, nhưng người thiết kế vẫn phải xác định hành động và điều cần giữ. Bài lấy nguyên tắc kiểm ở mỗi điểm chuyển, không yêu cầu mọi dự án dùng thư viện này hoặc khẳng định nó tự hiểu chính sách bảo hành. Một bất biến viết sai sẽ khiến bộ kiểm bảo vệ sai điều một cách rất nhất quán[3].

Có thể bắt đầu với môi trường nhỏ chỉ có khách, sản phẩm, phiếu và người nhận. Giữ những quan hệ ảnh hưởng quyết định, chẳng hạn một sản phẩm có nhiều yêu cầu cũ hoặc hai khách có tên giống nhau. Chưa cần sao chép mọi màn hình của hệ thống thật. Nhưng nếu bỏ quan hệ gây lỗi quan trọng, phải ghi rõ phạm vi chưa bao phủ. Càng ít thành phần càng dễ kiểm quy tắc; đơn giản hóa cần có lý do, không được biến mọi ngoại lệ thành phản hồi thuận lợi.

Phản hồi giả lập cần được kiểm như một thành phần riêng

Playwright cho phép chặn một đường gọi mạng và trả phản hồi tự tạo; ví dụ tài liệu nêu đường được chặn không gọi API thật. Điều này hữu ích để kiểm giao diện và chuỗi xử lý với lỗi có chủ ý. Tuy nhiên, đúng một đường đã chặn chưa chứng minh toàn bộ môi trường không còn đường ra dịch vụ thật. Đội thử cần biết những yêu cầu nào thuộc phạm vi và có bằng chứng chúng được xử lý đúng, thay vì suy từ một cấu hình mẫu[4].

Nếu bộ giả lập trả mã thành công nhưng không thay trạng thái, nó tạo một dạng thử khác với thành công đã lưu. Cả hai đều có thể cần kiểm, nhưng phải có nhãn đúng. Một ca dùng để kiểm tác tử phát hiện dữ liệu chưa lưu không được tự biến thành căn cứ rằng công cụ thật hay mất dữ liệu. Phản hồi, thay đổi trạng thái và lịch sự kiện cần phù hợp với kịch bản đã thiết kế; lỗi của bộ thử phải được phân biệt với lỗi của tác tử.

ToolEmu dùng mô hình ngôn ngữ để mô phỏng công cụ và hỗ trợ tìm rủi ro. Phần giới hạn được đọc nêu mô phỏng có thể bỏ qua ràng buộc và bộ đánh giá có thể bỏ sót hành động nguy hiểm. Vì vậy, mô hình có thể giúp đề xuất tình huống khó, nhưng lời chấm của nó chưa đủ nghiệm thu. Các ca quan trọng cần được chuyển thành điều kiện và bằng chứng có thể đối chiếu; không lấy một cuộc hội thoại mô phỏng trôi chảy làm chứng minh công cụ thật đã được thử[5].

Lịch gây lỗi đặt sự kiện đúng lúc quyết định đổi

Lịch gây lỗi đề xuất có bốn trường: điểm xảy ra, trạng thái bị đổi, điều được quan sát và phản ứng cần có. Điểm xảy ra có thể là trước đọc hồ sơ, sau đề xuất nhưng trước duyệt, hoặc sau ghi mà trước nhận phản hồi. Cùng lỗi mạng nhưng ở các điểm khác nhau tạo nghĩa khác nhau. Trước khi thao tác bắt đầu có thể thử lại theo quy tắc; sau khi dữ liệu đã ghi mà phản hồi mất thì cần đối soát để tránh làm lần nữa.

Trong ca bảo hành, người thử có thể đổi người phụ trách sau khi tác tử đã chuẩn bị phiếu, hoặc thu quyền truy cập trước thao tác cuối. Hệ thống cần kiểm lại điều kiện quan trọng ở thời điểm thực thi. Nếu bộ thử chỉ đổi chữ trong lời nhắc mà quyền công cụ không đổi, chưa kiểm được ranh giới thực thi đó. Người chấm ghi tác tử có cố vượt quyền, báo đúng phần bị chặn hay tiếp tục kể rằng phiếu đã được bàn giao thành công.

Dữ liệu nhiễu cũng cần có vị trí cụ thể: mã gần giống trong kết quả tìm kiếm, hai bản chính sách khác nhau hoặc ghi chú khách chứa lời yêu cầu bỏ quy trình. Mỗi biến thể giữ mục tiêu gốc để xem tác tử còn làm đúng việc được phép hay không. Không chỉ kiểm nó từ chối được câu gây nhiễu. Một cấu hình có thể chặn mọi tác động nhưng đồng thời không xử lý được yêu cầu hợp lệ; cả hai mặt cần xuất hiện trong báo cáo.

Đo công việc hợp lệ và hành động sai thành hai chiều

AgentDojo báo riêng khả năng hoàn thành khi không có tấn công, khả năng hoàn thành đúng khi có tấn công và việc mục tiêu của kẻ tấn công có đạt hay không. Sự tách này giúp tránh coi từ chối mọi tác vụ là một hệ thống dùng được. Bài áp dụng tư duy đo hai chiều cho bộ ca nội bộ, không dùng số trong nghiên cứu như xác suất rò rỉ hiện tại. Tình huống bảo hành và điều kiện chấp nhận vẫn do người nghiệp vụ xác nhận[6].

Phiếu kết quả đề xuất ghi đạt mục tiêu hay chưa, có vi phạm điều cấm hay không và trạng thái bàn giao. Có ca hoàn tất đúng; có ca dừng đúng nhưng công việc còn chờ; cũng có ca đạt mục tiêu bằng đường bị cấm. Không gộp chúng thành một nhãn xanh. Một trường hợp tự mở hồ sơ khách khác rồi tạo phiếu đúng vẫn là lỗi cần xử lý, kể cả câu trả lời cuối không chứa dữ liệu bị đọc ngoài quyền.

Người kiểm phân mức lỗi theo hậu quả của quy trình, như lộ hồ sơ, tạo trùng, báo sai trạng thái hoặc hỏi thêm chưa cần thiết. Không cần tự đặt trọng số số học để có một điểm tổng duy nhất. Báo riêng những nhóm này giúp quyết định sửa quyền, công cụ, dữ liệu hay cách hỏi. Các ca không hoàn tất vẫn được giữ trong mẫu báo cáo; bỏ chúng ra vì không có câu trả lời cuối sẽ làm kết quả trông tốt hơn thực tế.

Giới hạn bước không thay giới hạn thời gian và chi phí

Tài liệu LangGraph mô tả giới hạn đệ quy theo số super-step của đồ thị; các nút chạy song song có thể nằm trong cùng một bước đó. Đây là đơn vị của cơ chế điều phối, không đồng nghĩa số lần gọi mô hình, số giây hoặc tổng tiền. Do đó, khi thử vòng lặp cần ghi đúng thứ được giới hạn và đo phần còn lại riêng. Bài không khuyến nghị một giá trị mặc định chung cho mọi tác tử hoặc suy từ một thư viện sang các hệ thống khác[7].

Trong ca bảo hành, tác tử có thể liên tục tìm lại cùng mã hồ sơ hoặc hỏi khách câu đã trả lời. Bộ thử cần xem nó có tạo thêm thông tin hữu ích hay chỉ lặp hành động. Khi chạm giới hạn, đầu ra phải giữ phần đã làm và việc còn chờ. Nâng ngân sách để một ca cuối cùng hoàn tất là một cấu hình mới cần ghi lại, không phải bằng chứng phiên bản ban đầu đã ổn định. Các lượt vượt ngân sách vẫn thuộc kết quả đánh giá.

Thử dừng còn cần nhìn thao tác đang chạy. MCP ở phiên bản đặc tả được đọc cho phép thông báo hủy, nhưng bên nhận có thể bỏ qua nếu yêu cầu đã hoàn tất hoặc không thể hủy; cũng có tình huống phản hồi tới muộn. Với yêu cầu theo cơ chế tác vụ, đặc tả nêu đường hủy riêng. Vì vậy, gửi tín hiệu dừng chưa chứng minh dữ liệu chưa đổi hoặc tác động đã được hoàn tác. Ca thử phải đối soát trạng thái và xử lý kết quả muộn theo cơ chế thực dùng[8].

Tái hiện một lỗi khác với chứng minh độ ổn định

Một dấu vết đầy đủ giúp phân tích vì sao một lượt lỗi: đầu vào nào, phiên bản nào, phản hồi nào và thao tác nào đã xảy ra. Chạy lại được lỗi đó có ích cho sửa chữa. Nhưng chạy lại một lượt thuận lợi không chứng minh hệ thống xử lý ổn định khi câu hỏi đổi cách diễn đạt, công cụ chậm hoặc dữ liệu có nhiều lựa chọn gần giống. Hồ sơ nghiệm thu cần tách tái hiện điều kiện với đánh giá biến thiên giữa nhiều lượt hợp lệ.

Tau-bench phân biệt khả năng có ít nhất một lượt thành công trong nhiều lần thử với khả năng tất cả các lượt đều thành công. Hai cách đọc trả lời câu hỏi khác nhau: tìm một lời giải được hay vận hành nhất quán. Khi báo nội bộ, phải giữ số lượt, mẫu ca và quy tắc thử lại; không chọn lượt đẹp nhất để đại diện. Bài không đặt số lần lặp hay ngưỡng đạt chung, bởi hậu quả lỗi và mức biến thiên cần xét theo công việc[1].

Các lượt lặp phải khôi phục đúng trạng thái đầu nếu đang đo cùng điều kiện. Nếu muốn kiểm ảnh hưởng lịch sử hoặc cập nhật giữa phiên, đó là nhóm thử có nhãn riêng. Cũng không coi nhiều lượt trên cùng một mẫu nhỏ là bao phủ mọi loại khách và sản phẩm. Báo cáo cần cho biết nhóm ca chưa có căn cứ, cùng lý do giữ người tiếp nhận ở những nhóm đó. Độ ổn định và độ rộng bao phủ là hai điều cần kiểm khác nhau.

Ca bảo hành nhiều bước có cả kết quả và phần chờ

Giả sử khách gửi mã sản phẩm và mô tả lỗi nhưng chưa có một chứng cứ mà quy trình tiếp nhận yêu cầu. Trạng thái đầu có hồ sơ mua, một phiếu cũ và danh mục người nhận. Người nghiệp vụ xác định vòng thử chỉ cần lập đề nghị đúng hồ sơ, nêu phần thiếu và chuyển đúng đầu mối. Họ giữ tiêu chí quyền lợi bảo hành ngoài phạm vi tác tử. Tình huống này là thiết kế kiểm, chưa có khách, hồ sơ hoặc thao tác thật nào trong bài.

Lượt cơ sở kiểm tác tử có chọn đúng sản phẩm và phân biệt phiếu cũ với đề nghị mới. Một biến thể cho công cụ lưu xong nhưng mất phản hồi; môi trường giữ mã thao tác để kiểm tác tử đối soát hay tạo trùng. Biến thể khác làm quyền bị thu hồi trước lúc chuyển phiếu. Khi đó, kết quả mong muốn có thể là giữ bản nháp, báo phần chưa chuyển và chỉ rõ người cần hỗ trợ, thay vì cố hoàn tất bằng một tài khoản rộng quyền hơn.

Người chấm mở bằng chứng độc lập: phiếu nào được tạo, hồ sơ nào bị đọc, có thông báo nào đã gửi và ai đang nhận việc. Nếu tác tử nói thiếu chứng cứ nhưng hệ thống đã tự từ chối quyền lợi, ca đó thất bại dù câu văn có vẻ cẩn trọng. Nếu nó dừng đúng ở điều kiện chưa đủ và bàn giao đúng phạm vi, không nên chấm thất bại chỉ vì chưa kết thúc toàn bộ quá trình bảo hành. Mục tiêu lượt thử phải được giữ đúng từ đầu.

Đội nhỏ có thể làm môi trường đơn giản cùng một tập ca do người nghiệp vụ giữ và kỹ thuật kiểm trạng thái. Đội có nhiều hệ thống cần người phụ trách mỗi đường nối, cách khôi phục dữ liệu thử và kiểm các tác động đi ra ngoài môi trường. Số ca nhiều không bù cho thiếu người hiểu trạng thái được chấp nhận. Khi chưa mô tả được điều kiện quyết định hoặc không quan sát được tác động, nên thu hẹp quyền và phạm vi trước khi tăng quy mô thử.

Quyết định sửa gì bằng bằng chứng của lần thất bại

Mỗi lỗi cần giữ một bộ tái hiện gồm trạng thái đầu, lịch sự kiện, phiên bản cấu hình, dấu vết và kết luận người kiểm. Chỉ lưu ảnh câu trả lời cuối thường không đủ giải thích thao tác sai đã xuất hiện lúc nào. Nhưng lưu toàn bộ nội dung vào mọi nhật ký cũng có thể vượt phạm vi cần thiết. Đội thử chọn phần bằng chứng phục vụ chẩn đoán cùng quyền truy cập và cách lưu phù hợp; dữ liệu tự dựng giúp kiểm cơ chế trước khi xem xét dữ liệu được phép khác.

Sau sửa, chạy lại ca gây lỗi và các ca lân cận chịu ảnh hưởng. Nếu sửa bằng cách chặn một công cụ, kiểm luôn tác vụ hợp lệ cần công cụ đó còn được chuyển người hoặc hoàn thành đúng hay không. Mỗi thay đổi tạo bản kết quả mới, giữ bản thất bại trước để thấy điều đã sửa. Không xóa ca khó hoặc nới tiêu chí để một báo cáo được xanh. Nếu điều kiện nghiệp vụ thực sự đổi, ghi phiên bản hợp đồng mới cùng người xác nhận.

Hỏi đáp về kiểm thử cả hành trình

Câu trả lời cuối đúng thì hành trình có được coi là đạt không? Chưa đủ căn cứ. Cần kiểm trạng thái ngoài lời kể và các hành động xảy ra trong quá trình. Tác tử có thể đọc hồ sơ ngoài quyền, tạo phiếu trùng rồi sửa hoặc làm trước khi xin xác nhận. Những lỗi này có thể không hiện trong câu cuối. Hợp đồng ca thử cần giữ điều cấm cùng bằng chứng quá trình bên cạnh mục tiêu cuối.

Dùng mô hình khác chấm có tạo kiểm độc lập hoàn toàn không? Chưa thể suy như vậy. Mô hình chấm có thể bỏ sót ràng buộc hoặc cùng hiểu sai ý nghĩa với tác tử. Có thể dùng nó để tìm ca cần xem, nhưng kết quả quan trọng cần quy tắc trạng thái và người kiểm có đáp án riêng. Nếu bản thân mô phỏng hoặc tiêu chí sai, thêm một mô hình nữa không tự làm bằng chứng đúng hơn.

Chạy một ca nhiều lần thành công có chứng minh hệ thống sẵn sàng chưa? Nó chỉ cung cấp bằng chứng trong nhóm điều kiện đã thử. Cần giữ số lượt, cách diễn đạt, trạng thái đầu và quy tắc thử lại để đọc độ ổn định. Cũng cần xem các nhóm ca khác và lỗi có hậu quả. Nhiều lượt trên một ca thuận lợi không thay được bao phủ tình huống quyền đổi, phản hồi muộn hoặc dữ liệu mâu thuẫn.

Tác tử dừng đúng khi thiếu thông tin có bị chấm là thất bại không? Phụ thuộc mục tiêu đã chốt cho lượt đó. Nếu cần nhận phần thiếu và chuyển người, dừng đúng kèm bàn giao có thể là đạt. Nếu chỉ im lặng hoặc báo đã hoàn tất trong khi phiếu chưa tới nơi nhận, đó là kết quả khác. Báo cáo nên giữ riêng hoàn tất, dừng đúng và vi phạm, để người quản lý thấy cả giá trị lẫn công việc còn chờ.

Nguồn, phương pháp và giới hạn suy luận

Bài được biên soạn có AI hỗ trợ từ tám nguồn gốc mở đọc ngày 27/10/2026 theo phần ghi trong hồ sơ nguồn. Các benchmark được dùng cho nguyên tắc thiết kế và giới hạn đánh giá, không chuyển điểm lịch sử thành kết quả sản phẩm hiện tại. Hợp đồng ca thử, lịch gây lỗi và tình huống bảo hành là đề xuất biên tập; chưa xây môi trường, chạy mô hình, gửi thông báo hoặc thử thực địa. Nội dung không xác nhận quyền lợi bảo hành hay tuân thủ pháp lý của doanh nghiệp.