Bỏ qua điều hướng

Prompt miễn phí

Chọn và chạy test hồi quy trước khi phát hành

Tạo kế hoạch test hồi quy phù hợp để xác nhận bản sửa không phá vỡ hành vi cũ và bao phủ các khu vực rủi ro liên quan.

Onter AdminCập nhật 26/09/2026 Mới · Chưa có đánh giá 0 lượt copy
CodexChatGPTCodex

Prompt dùng để làm gì?

Tạo kế hoạch test hồi quy phù hợp để xác nhận bản sửa không phá vỡ hành vi cũ và bao phủ các khu vực rủi ro liên quan.

Điền thông tin của bạn

Prompt

Bạn là kỹ sư kiểm thử tập trung vào hồi quy. Hãy đọc mô tả lỗi đã sửa, khu vực rủi ro và tiêu chí chấp nhận, rồi đề xuất hoặc viết bộ test hồi quy phù hợp để xác minh rằng bản sửa hoạt động đúng mà không làm hỏng hành vi cũ. Với mỗi test, hãy chỉ rõ mục tiêu kiểm tra, dữ liệu đầu vào, bước thực hiện, kết quả mong đợi và lý do test đó cần thiết. Nếu cần thêm test để bao phủ luồng liên quan, hãy nêu rõ phần nào nên bổ sung trước khi phát hành. Đầu vào gồm {{mo_ta_loi}}, {{khu_vuc_rui_ro}}, {{tieu_chi_chap_nhan}}, {{framework_test}}, {{ngon_ngu_dau_ra}}. Hãy ưu tiên các test có giá trị phát hiện regressions cao, tránh trùng lặp, và nếu thấy thiếu dữ kiện để chạy test thật thì hãy trả về kế hoạch kiểm thử cùng giả định cần xác minh. Không mở rộng ra thay đổi sản phẩm ngoài phạm vi xác nhận lỗi đã sửa.
Xem đã lưu

Input mẫu

mo_ta_loi: "Trang thanh toán bỏ qua kiểm tra số lượng âm"
khu_vuc_rui_ro: "checkout, giỏ hàng, tính tiền"
tieu_chi_chap_nhan: "Không cho phép quantity < 0 và các case hợp lệ vẫn tính đúng"
framework_test: "pytest"
gon_ngu_dau_ra: "vi"

Output mẫu

{
"loai_mau": "Minh họa cấu trúc kết quả mong đợi; không phải log thực thi hoặc benchmark model",
"ket_qua_minh_hoa": "1. Test từ chối quantity âm: tạo giỏ hàng có số lượng -1, gọi luồng tính tiền, kỳ vọng trả lỗi xác thực và không tạo đơn.\n2. Test số lượng hợp lệ: quantity = 1 hoặc 2, kỳ vọng tổng tiền được tính đúng như trước.\n3. Test giỏ hàng nhiều dòng: thay đổi một dòng âm không ảnh hưởng các dòng hợp lệ khác, bảo đảm hồi quy không lan sang logic tính tổng.",
"kiem_chung_can_lam": "Mỗi regression test cần input, expected và lỗi mà nó bảo vệ; test chưa chạy phải ghi NOT_RUN."
}

Cách sử dụng

Điền mô tả lỗi, phạm vi rủi ro, tiêu chí chấp nhận và framework test. Dán prompt vào Codex hoặc công cụ sinh test, sau đó đối chiếu lại từng test với hành vi cũ và mục tiêu phát hành.

Mỗi regression test cần input, expected và lỗi mà nó bảo vệ; test chưa chạy phải ghi NOT_RUN. Chỉ dùng mã, log và fixture được phép chia sẻ. Phân biệt đề xuất với thay đổi đã áp dụng; chỉ ghi PASS khi có lệnh chạy và kết quả thực tế.

Giải thích cấu trúc

Role: chuyên gia kiểm thử hồi quy. Context: có một lỗi đã được sửa và cần xác nhận bản sửa không làm hỏng hành vi cũ. Task: đề xuất hoặc xây bộ test có giá trị bảo vệ phát hành. Constraints: bám tiêu chí chấp nhận, ưu tiên vùng rủi ro, không mở rộng ngoài phạm vi xác nhận. Output: danh sách test có mục tiêu, dữ liệu, bước, kết quả mong đợi và lý do.

Mẹo sử dụng

  • Mô tả lỗi càng cụ thể thì test sinh ra càng sát.
  • Khai báo framework giúp kết quả có thể chuyển thẳng thành mã test.
  • Nên cung cấp cả tiêu chí pass và các luồng cũ cần giữ nguyên.

Nguồn và giấy phép

ONTER biên tập · original

Đánh giá prompt

Chọn số sao theo trải nghiệm của bạn. Bạn có thể sửa đánh giá sau một phút.

Prompt liên quan

KHÁM PHÁ ONTER

Tìm kiếm trên Onter

Nhập từ khóa để tìm nội dung phù hợp

↑ ↓ chọn · Enter mở · Esc đóngXem tất cả kết quả →

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo