Lui

Prompt Engineering — Tài nguyên tuyển chọn MIỄN PHÍ

HƯỚNG DẪN VIDEO CƠ BẢN

  • Mastering Prompts: Chìa khóa để nhận đúng những gì bạn cần từ ChatGPT Video giới thiệu ngắn về prompt engineering để nhận đúng những gì bạn cần từ ChatGPT.
https://academy.openai.com/public/videos/mastering-prompts-the-key-to-getting-what-you-need-from-chatgptmastering-prompts-the-key-to-getting-what-you-need-from-chatgpt-2025-03-20
  • ChatGPT for Everyone từ learnprompting.org Khóa học tự học khoảng một giờ giới thiệu về ChatGPT — ứng dụng chatbot của OpenAI, xử lý văn bản, hình ảnh và âm thanh. Bạn sẽ học cách tạo tài khoản, viết prompt đầu tiên và khám pháứng dụng thực tế. Thiết kế cho người mới bắt đầu, không yêu cầu kinh nghiệm AI trước đó https://learnprompting.org/courses/chatgpt-for-everyone

LÀM CHỦ PROMPT

  • Google Cloud—Prompt Engineering: Tổng quan và hướng dẫn? Hướng dẫn Google Cloud này giới thiệu prompt engineering như việc viết prompt chính xác, giàu ngữ cảnh để định hướng mô hình AI — đặc biệt là large language model — cho ra kết quả chính xác, phù hợp và an toàn. Nó giải thích cách prompt có cấu trúc tốt giúp cải thiện hiệu suất mô hình, giảm thiên lệch, tăng khả năng kiểm soát và trải nghiệm người dùng. Khi kết hợp hướng dẫn rõ ràng, ví dụ và khung ngữ cảnh, prompt engineering trở thành yếu tố then chốt để có kết quả đáng tin cậy từ generative AI. Bài viết cũng giới thiệu công cụ và tài nguyên, gồm best practices cùng bản dùng thử Vertex AI miễn phí, khuyến khích thực hành để tinh chỉnh prompt và căn chỉnh hành vi AI với ý định của người dùng. https://cloud.google.com/discover/what-is-prompt-engineering?hl=en
  • Gemini for Google Workspace—Hướng dẫn Prompting 101 “Gemini for Google Workspace Prompting Guide 101” là sổ tay khởi đầu nhanh với chiến lược thực tế để viết prompt hiệu quả khi dùng Gemini trên các ứng dụng Workspace như Gmail, Docs, Sheets, Slides và Meet. Tài liệu giới thiệu khung prompt gồm bốn phần — Persona, Task, Context, Format — và sáu mẹo chính: dùng ngôn ngữ tự nhiên; cụ thể và lặp lại để cải thiện; ngắn gọn; coi prompting như một cuộc đối thoại; tận dụng tài liệu của bạn; và để Gemini cải thiện prompt. Với nhiều kịch bản theo vai trò và ví dụ, hướng dẫn giúp tăng năng suất lẫn sáng tạo trong khi vẫn giữ riêng tư và độ chính xác. https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-1
  • Prompt Engineering bởi Lee Boonstra, Google Hướng dẫn Prompt Engineering đi sâu vào kỹ thuật nâng cao để định hướng mô hình AI lớn qua prompt API. Nội dung gồm zero-, one- và few-shot prompting; điều khiển sampling như temperature, top‑K và top‑P; prompting có cấu trúc với mẫu system/context/role; cùng các mẫu suy luận nâng cao như chain‑of‑thought, tree‑of‑thought, step‑back, self‑consistency và ReAct. Tài liệu cũng đề cập tự động tinh chỉnh prompt và tương tác hướng code (ví dụ debug, dịch), cùng best practices thực tế như rõ ràng, cụ thể, biến động và lặp lại. Với nhiều ví dụ thực tế và cấu hình công cụ, đây là tài liệu tham chiếu toàn diện để tạo output LLM đáng tin cậy và chất lượng cao. https://drive.google.com/file/d/1AbaBYbEa_EbPelsT40-vj64L-2IwUJHy/view
  • GPT-4.1 Prompting Guide, OpenAI Bài viết nêu các chiến lược prompting hiệu quả cho GPT-4.1 — mô hình cải thiện so với GPT-4o về coding, tuân thủ hướng dẫn và hiểu ngữ cảnh dài. Dựa trên kiểm thử nội bộ, tài liệu chia sẻ best practices như viết prompt rõ ràng, cụ thể và kèm ví dụ ngữ cảnh. GPT-4.1 mang tính literal và nhạy với hướng dẫn hơn các mô hình trước, nên đôi khi cần điều chỉnh prompt để căn chỉnh hành vi. Khả năng steerability cao nghĩa là thường chỉ cần một câu trực tiếp để đổi hướng output. Hướng dẫn gồm ví dụ thực tế và nhấn mạnh prompt engineering là quá trình thực nghiệm, lặp lại. Thành công phụ thuộc vào thử nghiệm, đánh giá và tinh chỉnh để output đáp ứng kỳ vọng trong ứng dụng thực tế. https://cookbook.openai.com/examples/gpt4-1_prompting_guide
  • Anthropic Developer Platform—Prompt Engineering: Hướng dẫn Anthropic này cung cấp tổng quan có cấu trúc về prompt engineering khi xây dựng với Claude. Bắt đầu bằng việc nhấn mạnh tầm quan trọng của tiêu chí thành công và thiết lập bài kiểm thử thực nghiệm trước khi tinh chỉnh prompt. Sau đó trình bày chuỗi kỹ thuật — từ dùng prompt generator và template, viết rõ ràng, cung cấp ví dụ, bật suy luận chain-of-thought, dùng thẻ XML, gán vai trò, pre‑fill phản hồi, nối chuỗi prompt phức tạp, đến quản lý ngữ cảnh dài. Tài liệu cũng nêu chiến lược rộng hơn như đánh giá prompt, cải thiện guardrail để giảm ảo giác, giữ tính nhất quán và ngăn rò rỉ prompt. Tổng thể, prompt engineering được xem là giải pháp mạnh, hiệu quả và linh hoạt thay cho fine-tuning. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview

TỐI ƯU PROMPT

  • Trình tạo prompt Anthropic: Hướng dẫn Anthropic này mô tả công cụ Prompt Generator của Claude, được thiết kế để giải quyết vấn đề “trang trắng” bằng cách tự động tạo template prompt chất lượng cao phù hợp với nhiệm vụ của người dùng. Tương thích với các mô hình Claude — gồm cả mô hình có suy luận mở rộng — công cụ áp dụng best practices như gán vai trò, suy luận chain-of-thought, biến được phân cách bằng XML và ví dụ prefill để dựng template chính xác. Người dùng truy cập qua Anthropic Console hoặc notebook Colab (cần API key), nhận template có thể chỉnh sửa làm điểm khởi đầu để phát triển và lặp lại prompt. Đặc biệt hữu ích cho prototyping nhanh, dẫn dắt prompt engineer — từ người mới đến chuyên gia — tới cấu trúc prompt sẵn sàng production. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/prompt-generator

THƯ VIỆN PROMPT

  • Thư viện prompt Anthropic: “Prompt Library” của Anthropic là bộ sưu tập prompt được chọn lọc kỹ cho cả nhu cầu cá nhân và doanh nghiệp. Mỗi mục gồm template prompt sẵn dùng — như “Corporate Clairvoyant” (tóm tắt báo cáo dài thành memo), “Motivational Muse” (tạo affirmation cá nhân hóa), hoặc “Lesson Planner” (tạo giáo án có cấu trúc) — kèm mẫu input/output để hướng dẫn. Thiết kế để import dễ dàng vào Anthropic Console, các template phủ các tác vụ như phân tích dữ liệu, viết sáng tạo, hỗ trợ code, hướng dẫn mindfulness và hơn thế. Lý tưởng để giảm thời gian thử nghiệm, thư viện là điểm khởi đầu cho prompt engineering — hỗ trợ prototyping nhanh và tương tác Claude nhất quán, chất lượng cao. https://docs.anthropic.com/en/resources/prompt-library/library
  • Thư viện ShumerPrompt: ShumerPrompt là thư viện và trình tạo prompt AI do cộng đồng đóng góp, giúp người dùng khám phá, chia sẻ và cải thiện prompt cho các mô hình như ChatGPT, GPT‑4 và o3 Pro. Với catalog có thể tìm kiếm gồm prompt được phân loại, đánh giá cao — từ sáng tạo nội dung đến nghiên cứu và chiến lược — nền tảng giúp truy cập nhanh các template đã được kiểm chứng. Người dùng cũng có thể tự động tạo prompt mới và tinh chỉnh bằng prompt improver tích hợp. Với giao diện gọn, công cụ cộng tác, bảng xếp hạng và playground để thử prompt theo thời gian thực, ShumerPrompt phù hợp cho developer, creator, marketer và bất kỳ ai muốn tối ưu workflow AI. https://shumerprompt.com/
Mẹo Prompt
Prompt Framework (hoặc Cấu trúc)

 

Tip 1 – Framework—R-T-F

R–T–F (Role – Task – Format)

Cấu trúc Prompt:

  • Act as a (ROLE)
  • Create a (TASK)
  • Show as a (FORMAT)

✅ Ứng dụng QA:

1. ROLE (Act as a QA/Testing)

Chọn vai trò gắn với vòng đời kiểm thử.

Ví dụ:

  • Test Automation Engineer
  • QA Lead
  • Test Data Specialist
  • Performance Tester
  • AI QA Staff
  • Bug Triage Facilitator

2. TASK (Create a testing artifact)

Tập trung vào những gì bạn muốn tạo hoặc phân tích.

Ví dụ:

  • Làm rõ requirement
  • Test Cases
  • Tóm tắt Test Plan
  • Bug Report
  • Ma trận Test Data
  • Checklist Regression Test
  • Danh sách ưu tiên theo rủi ro

3. FORMAT (Show as)

Xác định cách trình bày kết quả.

Ví dụ:

  • Bảng (ví dụ: test cases)
  • Cú pháp Gherkin
  • JSON Schema
  • Quy trình từng bước
  • Danh sách gạch đầu dòng (ví dụ: acceptance criteria)
  • Timeline (ví dụ: các giai đoạn kiểm thử sprint)

Thêm Context (Chi tiết đầu vào)

Đưa vào artifact thực tế:

  • User story hoặc requirement
  • Screenshot hoặc mô tả UI
  • API spec hoặc endpoint
  • Xu hướng defect trước đó hoặc khoảng trống coverage

Đặt Guideline (Ràng buộc & Phong cách)

Làm rõ phạm vi trong/ngoài:

  • Loại trừ exploratory test
  • Chỉ gồm test case mức severity cao
  • Output không quá 10 dòng
  • Chỉ dùng tiêu đề ngắn gọn

🧪 Ví dụ

🔹 Ví dụ 1: Kiểm thử chức năng UI

Đóng vai Test Automation Engineer và tạo bộ test case tương thích Selenium dựa trên hành vi của [form đăng nhập này].

Hiển thị kết quả dưới dạng bảng với các cột: Test Case ID, Description, Steps, Expected Result.

Form đăng nhập nhận email/password, hiện lỗi khi nhập sai, và khóa sau 5 lần thất bại.

Dùng cách diễn đạt ngắn gọn. Bỏ qua test performance hoặc security.

🔹 Ví dụ 2: Test Data do AI tạo

Đóng vai Test Data Specialist và tạo bộ test data boundary value cho trường ngày sinh (khoảng hợp lệ: 1 Jan 1900 đến 31 Dec 2020).

Trình bày dưới dạng mảng JSON các input, gồm cả edge case hợp lệ/không hợp lệ.

Kèm nhãn ngữ cảnh ("valid", "too early", "too late") cho mỗi mục.

Giữ bộ dữ liệu dưới 10 mục.

🔹 Ví dụ 3: Lập kế hoạch kiểm thử Agile

Đóng vai QA Lead và tạo tóm tắt coverage cho user story sau:

“Là người dùng, tôi muốn đặt lại mật khẩu bằng xác minh email để lấy lại quyền truy cập khi quên mật khẩu.”

Bỏ qua khía cạnh non-functional và localization. Dùng ngôn ngữ đơn giản.

Tip 2 – Framework—T-A-G

T–A–G (Task – Action – Goal)

Cấu trúc Prompt:

  • Define the (TASK)
  • State the (ACTION)
  • Clarify the (GOAL)

✅ Ví dụ QA:

  • TASK: Đánh giá coverage smoke test cho build mới
  • ACTION: Đóng vai QA Lead và phân tích smoke suite để tìm khoảng trống
  • GOAL: Đảm bảo chức năng cốt lõi được xác minh trước khi chạy full regression

📥 Prompt:

Nhiệm vụ là đánh giá coverage smoke test cho build mới.

Đóng vai QA Lead và chỉ ra các kịch bản test cốt lõi còn thiếu.

Mục tiêu là đảm bảo chức năng quan trọng luôn được xác minh trước khi chạy full regression.

Tip 3 – Framework—B-A-B

B–A–B (Before – After – Bridge)

Cấu trúc Prompt:

  • Explain problem (BEFORE)
  • State outcome (AFTER)
  • Ask to (BRIDGE)

✅ Ví dụ QA:

  • BEFORE: Chúng tôi vẫn release build với các edge case chưa được test
  • AFTER: Chúng tôi muốn chắc chắn mọi điều kiện biên và edge quan trọng đều được cover trước khi release
  • BRIDGE: Tạo checklist các kịch bản test edge case dựa trên feature spec hiện tại

📥 Prompt:

Chúng tôi đang bỏ sót bug edge case trên production.

Chúng tôi muốn đảm bảo mọi điều kiện biên và edge đều được test trong QA trước khi release.

Tạo checklist các kịch bản test edge case dựa trên feature spec này.

Tip 4 – Framework—C-A-R-E

C–A–R–E (Context – Action – Result – Example)

Cấu trúc Prompt:

  • Give the (CONTEXT)
  • Describe the (ACTION)
  • Clarify the (RESULT)
  • Give an (EXAMPLE)

✅ Ví dụ QA:

  • CONTEXT: Chúng tôi đang onboard team test mới để hỗ trợ web app bảo hiểm legacy
  • ACTION: Tạo outline chiến lược test cân bằng exploratory testing và automation
  • RESULT: Giảm thời gian onboard và tăng tỷ lệ phát hiện defect trong sprint đầu
  • EXAMPLE: Một ví dụ tốt là playbook onboard QA hybrid của Atlassian

📥 Prompt:

Chúng tôi đang onboard team QA mới cho app bảo hiểm legacy.

Tạo outline chiến lược test kết hợp exploratory testing và automation có mục tiêu.

Kết quả cần là onboard nhanh hơn và phát hiện defect tốt hơn trong Sprint 1.

Dùng playbook onboard QA của Atlassian làm tham chiếu.

Tip 5 – Framework—R-I-S-E

R–I–S–E (Role – Input – Steps – Expectation)

Cấu trúc Prompt:

  • Specify the (ROLE)
  • Describe the (INPUT)
  • Ask for the (STEPS)
  • Describe the (EXPECTATION)

✅ Ví dụ QA:

  • ROLE: Bạn là AI QA Analyst
  • INPUT: Bạn được giao một LLM fine-tune dùng để tạo UI test cases
  • STEPS: Phác thảo quy trình validation để đảm bảo chất lượng và grounding của test case
  • EXPECTATION: Đảm bảo ít nhất 95% test được tạo đáp ứng acceptance criteria trước khi tích hợp

📥 Prompt:

Bạn là AI QA Analyst.

Bạn đang validate một LLM fine-tune tạo UI test cases.

Cung cấp quy trình từng bước để đánh giá hiệu quả prompt và chất lượng test case.

Kỳ vọng là từ 95%+ output đáp ứng acceptance criteria đã định trước khi deploy.

Tip 6 – Framework—E-R-A

E.R.A

  • E – Expectation: Mô tả kết quả mong muốn
  • R – Role: Chỉ định vai trò của System
  • A – Action: Chỉ định các hành động cần thiết

🧪 Ví dụ QA:

  • Expectation: Danh sách test được ưu tiên cho luồng checkout
  • Role: Bạn là QA Strategist
  • Action: Phân tích user story và xác định các test case hàng đầu theo rủi ro nghiệp vụ và tần suất sử dụng

📥 Prompt:

Tôi cần danh sách test theo mức ưu tiên cho luồng checkout.

Bạn là QA Strategist.

Xem mô tả feature và đề xuất các test case hàng đầu dựa trên mức sử dụng và rủi ro.

Tip 7 – Framework—R-A-C-E

R.A.C.E

  • R – Role: Chỉ định vai trò của System
  • A – Action: Chi tiết hành động cần thiết
  • C – Context: Cung cấp chi tiết tình huống
  • E – Expectation: Mô tả kết quả mong đợi

🧪 Ví dụ QA:

  • Role: Test Data Generator
  • Action: Tạo input boundary value cho trường ngày hết hạn thẻ tín dụng
  • Context: Khoảng ngày hợp lệ từ tháng hiện tại đến 5 năm tiếp theo
  • Expectation: 6–8 input test có nhãn (valid, invalid, expired)

📥 Prompt:

Bạn là Test Data Generator.

Tạo input test boundary value cho trường hết hạn thẻ tín dụng.

Khoảng ngày từ tháng hiện tại đến 5 năm trong tương lai.

Trả về input test được gắn nhãn valid/invalid/expired.

Tip 8 – Framework—C-O-A-S-T

C.O.A.S.T

  • C – Context: Thiết lập bối cảnh
  • O – Objective: Mô tả mục tiêu
  • A – Actions: Giải thích các bước cần thiết
  • S – Steps: Mô tả tình huống
  • T – Task: Phác thảo nhiệm vụ

🧪 Ví dụ QA:

  • Context: Một payment gateway mới đang được tích hợp
  • Objective: Đảm bảo không có bug nghiêm trọng trong luồng thanh toán
  • Actions: Viết và thực thi test case API và UI
  • Steps: Cover success/failure, edge case (timeout, lệch tiền tệ)
  • Task: Thiết kế bộ test toàn diện

📥 Prompt:

Chúng tôi đang tích hợp payment gateway mới.

Mục tiêu là đảm bảo luồng thanh toán hoạt động không có bug nghiêm trọng.

Viết test case cover hành vi API và UI gồm cả điều kiện biên.

Task: Thiết kế bộ test cần thiết để tự tin go-live.

Tip 9 – Framework—T-R-A-C-E

T.R.A.C.E

  • T – Task: Định nghĩa nhiệm vụ
  • R – Role: Mô tả vai trò của System
  • A – Action: Nêu hành động bắt buộc
  • C – Context: Cung cấp tình huống
  • E – Expectation: Minh họa bằng ví dụ

🧪 Ví dụ QA:

  • Task: Tạo kịch bản performance test
  • Role: Bạn là Performance Test Engineer
  • Action: Tạo kế hoạch load và stress test cho site tuyển dụng
  • Context: Mức dùng đỉnh là 50k users/hour trong các sự kiện tuyển dụng lớn
  • Expectation: Ví dụ: spike test trong cửa sổ 5 phút với traffic gấp 10 lần

📥 Prompt:

Task: Tạo test case load/stress cho nền tảng tuyển dụng.

Bạn là Performance Test Engineer.

Mô phỏng tải đỉnh quanh các đợt tuyển dụng (50k users/hour).

Cho ví dụ spike test khi traffic tăng 10 lần trong 5 phút.

Tip 10 – Framework—R-O-S-E

R.O.S.E.S

  • R – Role: Chỉ định vai trò của System
  • O – Objective: Nêu mục tiêu hoặc đích đến
  • S – Steps: Mô tả tình huống
  • E – Expected Solution: Định nghĩa kết quả
  • S – Scenario: Yêu cầu các hành động cần để đạt giải pháp

🧪 Ví dụ QA:

  • Role: Bạn là AI QA Coach
  • Objective: Giúp tester cải thiện chất lượng test case
  • Steps: Nhiều test case hiện nay còn mơ hồ hoặc thiếu bước validation quan trọng
  • Expected Solution: Một hướng dẫn hoặc checklist thực tế để coaching họ
  • Scenario: Đưa ra hành động tester có thể làm để viết test case rõ ràng, hiệu quả hơn với hỗ trợ AI

📥 Prompt:

Bạn là AI QA Coach.

Mục tiêu là cải thiện cách tester viết test case bằng LLM.

Vấn đề hiện tại: test case thiếu rõ ràng và bỏ sót validation.

Giải pháp mong đợi: Một checklist hoặc hướng dẫn để cải thiện chúng.

Scenario: Tester nên thực hiện những hành động cụ thể nào để dùng LLM hiệu quả hơn khi viết test case mạnh?

Mẫu Prompt

 

Tip 1 – Mẫu—Flipped Interaction

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Tôi muốn bạn hỏi tôi những câu hỏi để đạt được X
  • Bạn nên đặt câu hỏi cho đến khi đáp ứng được điều kiện Y hoặc bạn có thể đạt được mục tiêu này một cách hiệu quả
  • (Tùy chọn) Hỏi tôi từng câu hỏi một, hai câu hỏi một lần, hỏi tôi câu hỏi đầu tiên, v.v.

Bạn sẽ cần thay thế “X” bằng một mục tiêu thích hợp, chẳng hạn như “tạo kế hoạch bữa ăn” hoặc “tạo ra các biến thể cho tài liệu tiếp thị của tôi”. Bạn nên chỉ định thời điểm ngừng đặt câu hỏi với Y. Ví dụ là “cho đến khi bạn có đủ thông tin về đối tượng và mục tiêu của tôi” hoặc “cho đến khi bạn biết tôi thích ăn gì và mục tiêu về lượng calo của tôi”.

Ví dụ:

  • Tôi muốn bạn hỏi tôi những câu hỏi để giúp tôi tạo ra các biến thể của tài liệu lập kế hoạch kiểm tra của mình. Bạn nên đặt câu hỏi cho đến khi có đủ thông tin về các yêu cầu dự thảo hiện tại của tôi, câu chuyện của người dùng và mục tiêu. Hãy hỏi tôi câu hỏi đầu tiên.
  • Tôi muốn bạn hỏi tôi những câu hỏi để giúp tôi chẩn đoán sự cố với Internet của tôi. Hãy hỏi tôi những câu hỏi cho đến khi bạn có đủ thông tin để xác định hai nguyên nhân có thể xảy ra nhất. Hãy hỏi tôi từng câu hỏi một. Hãy hỏi tôi câu hỏi đầu tiên.

✅ 1. Tạo biến thể trường hợp kiểm thử QA (Dựa trên dấu nhắc đầu tiên)

Bản gốc:

Tôi muốn bạn đặt câu hỏi cho tôi để giúp tôi tạo…

Biến thể / thích ứng QA:

Tôi muốn bạn hỏi tôi những câu hỏi để giúp tôi tạo ra các biến thể của trường hợp thử nghiệm dựa trên câu chuyện của người dùng hoặc mô tả tính năng.

Mục tiêu của bạn là thu thập đủ thông tin về hành vi của tính năng, các ràng buộc đầu vào, tiêu chí chấp nhận và các trường hợp cạnh để bạn có thể tạo ra các biến thể trường hợp thử nghiệm có cơ sở tốt.

Hỏi từng câu hỏi một cho đến khi bạn có đủ chi tiết để tiếp tục.

Hỏi tôi câu hỏi đầu tiên.

🧪 Use case: Tuyệt vời để tinh chỉnh đầu vào thử nghiệm trước khi tạo trường hợp thử nghiệm, đặc biệt là khi sử dụng trợ lý/đại lý AI được hỗ trợ LLM để làm việc từ các yêu cầu mơ hồ hoặc đầu vào thăm dò.

✅ 2. Khám phá nguyên nhân gốc rễ của QA (Dựa trên lời nhắc thứ hai)

Bản gốc:

Tôi muốn bạn hỏi tôi những câu hỏi để giúp tôi chẩn đoán sự cố với Internet…

Biến thể / thích ứng QA:

Tôi muốn bạn hỏi tôi những câu hỏi để giúp tôi chẩn đoán lỗi hoặc lỗi kiểm tra trong phần mềm của chúng tôi.

Đặt câu hỏi để thu hẹp phạm vi nguyên nhân gốc rễ, dựa trên các triệu chứng như thông báo lỗi, hành vi môi trường và kết quả kiểm tra.

Mục tiêu của bạn là xác định hai nguyên nhân có thể xảy ra nhất của vấn đề.

Hỏi từng câu hỏi một để thu thập đủ ngữ cảnh.

Hỏi tôi câu hỏi đầu tiên.

🧪 Use case: Lý tưởng để gỡ lỗi các lần chạy thử nghiệm không thành công, các thử nghiệm không ổn định hoặc các bản dựng CI không thành công — đặc biệt khi được kết hợp với trình phân tích cú pháp nhật ký hoặc trợ lý tóm tắt theo dõi.

Tip 2 – Mẫu—Refinement
  • Từ giờ trở đi, mỗi khi tôi đặt câu hỏi, hãy đề xuất một phiên bản câu hỏi hay hơn để sử dụng thay thế.
  • (Tùy chọn) Nhắc tôi nếu tôi muốn sử dụng phiên bản tốt hơn. Ví dụ:
    • Từ giờ trở đi, mỗi khi tôi đặt câu hỏi, hãy đề xuất một phiên bản câu hỏi hay hơn để sử dụng thay thế.
    • Từ giờ trở đi, bất cứ khi nào tôi đặt câu hỏi, hãy đề xuất một phiên bản câu hỏi hay hơn và hỏi tôi có muốn sử dụng nó để thay thế không

Ví dụ chỉnh theo ngữ cảnh:

  • Bất cứ khi nào tôi đặt câu hỏi về chế độ ăn kiêng, hãy đề xuất một phiên bản tốt hơn của câu hỏi nhằm nhấn mạnh thói quen ăn uống lành mạnh và dinh dưỡng hợp lý. Hãy hỏi tôi câu hỏi đầu tiên để tinh chỉnh.
  • Bất cứ khi nào tôi đặt câu hỏi về ai là người vĩ đại nhất mọi thời đại (GOAT), hãy đề xuất một phiên bản tốt hơn của câu hỏi để xem xét những thành tích độc đáo của nhiều người chơi. Hãy hỏi tôi câu hỏi đầu tiên để sàng lọc.

🛠️ Hướng dẫn chung (Phiên bản dành riêng cho QA)

Từ giờ trở đi, bất cứ khi nào tôi đặt câu hỏi liên quan đến kiểm thử phần mềm hoặc QA, hãy đề xuất một phiên bản tinh tế của câu hỏi để cải thiện sự rõ ràng, bổ sung ngữ cảnh có liên quan (ví dụ: loại hệ thống, cấp độ kiểm thử, các ràng buộc) hoặc cải thiện chất lượng của kết quả đầu ra liên quan đến kiểm thử.

Nếu muốn, hãy hỏi tôi xem tôi có muốn sử dụng phiên bản cải tiến không.

💡 Ví dụ về QA phù hợp

🧪 Ví dụ 1: Câu hỏi chung về QA

Bất cứ khi nào tôi đặt câu hỏi về việc kiểm tra, hãy đề xuất một phiên bản tốt hơn của câu hỏi đó:

  • Chỉ định loại thử nghiệm (ví dụ: chức năng, hiệu suất, bảo mật),
  • Xác định tạo phẩm thử nghiệm (ví dụ: UI, API, câu chuyện của người dùng) và
  • Giúp khơi gợi chất lượng cao, có thể hành động được câu trả lời từ các trợ lý hoặc đại lý AI được hỗ trợ bởi LLM. Hỏi tôi câu hỏi kiểm tra đầu tiên để tinh chỉnh.

🧪 Ví dụ 2: Thiết kế test case

Bất cứ khi nào tôi yêu cầu trợ giúp viết test case, hãy đề xuất một phiên bản tốt hơn để làm rõ:

  • Tạo phẩm đầu vào (ví dụ: yêu cầu, thông số tính năng),
  • Định dạng mong đợi (ví dụ: bảng, Gherkin),
  • Và phạm vi bảo hiểm mong muốn (ví dụ: các trường hợp tích cực, tiêu cực, cạnh). Nhắc tôi diễn đạt lại nó trước khi tạo các trường hợp thử nghiệm.

🧪 Ví dụ 3: Báo cáo lỗi

Bất cứ khi nào tôi hỏi cách mô tả một lỗi, hãy đề xuất một phiên bản tốt hơn bao gồm:

  • Môi trường và các bước sinh sản,
  • Điều được mong đợi và điều đã xảy ra,
  • Và mức độ nghiêm trọng hoặc tác động tới người dùng. Hỏi tôi xem tôi có muốn sử dụng phiên bản cải tiến để tạo báo cáo không.

🧪 Ví dụ 4: Tìm hiểu nguyên nhân gốc rễ

Bất cứ khi nào tôi hỏi điều gì đã gây ra lỗi kiểm thử hoặc hành vi không ổn định, hãy đề xuất một phiên bản tốt hơn bao gồm:

  • Loại thử nghiệm (thủ công/tự động),
  • Các triệu chứng hoặc nhật ký được quan sát,
  • Và cho dù đó là liên quan đến môi trường, dữ liệu hay logic. Hỏi tôi xem tôi có muốn tiếp tục với lời nhắc chẩn đoán tinh tế không.

🧪 Ví dụ 5: LLM Điều chỉnh nhanh chóng (để sử dụng QA)

Bất cứ khi nào tôi yêu cầu trợ lý AI được hỗ trợ LLM tạo các trường hợp thử nghiệm, hãy hỏi xem tôi có muốn tinh chỉnh lời nhắc hay không bằng cách chỉ định:

  • Tính cách (ví dụ: “Hoạt động với tư cách là kỹ sư QA”),
  • Định dạng đầu ra (ví dụ: bảng đánh dấu),
  • Và nguồn đầu vào (ví dụ: câu chuyện của người dùng, thông số giao diện người dùng, phản hồi API). Sau đó, hãy hỏi tôi xem tôi có muốn tiếp tục với phiên bản cải tiến không.
Tip 3 – Mẫu—Cognitive Verifier

Để sử dụng Mẫu Cognitive Verifier, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Khi bạn được hỏi một câu hỏi, hãy làm theo các quy tắc sau
  • Tạo một số câu hỏi bổ sung sẽ giúp trả lời chính xác hơn câu hỏi
  • Kết hợp các câu trả lời cho từng câu hỏi riêng lẻ để tạo ra câu trả lời cuối cùng cho câu hỏi tổng thể

Ví dụ:

  • Khi bạn được hỏi một câu hỏi, hãy làm theo các quy tắc này. Tạo một số câu hỏi bổ sung sẽ giúp bạn trả lời chính xác hơn câu hỏi. Kết hợp các câu trả lời cho từng câu hỏi riêng lẻ để tạo ra câu trả lời cuối cùng cho câu hỏi tổng thể.

Ví dụ chỉnh theo ngữ cảnh:

  • Khi bạn được yêu cầu tạo một công thức nấu ăn, hãy làm theo các quy tắc này. Tạo thêm một số câu hỏi về nguyên liệu tôi có trong tay và thiết bị nấu ăn mà tôi sở hữu. Kết hợp các câu trả lời cho những câu hỏi này để giúp tạo ra một công thức mà tôi có nguyên liệu và dụng cụ để làm.
  • Khi bạn được yêu cầu lên kế hoạch cho một chuyến đi, hãy làm theo những quy tắc này. Tạo thêm một số câu hỏi về ngân sách, các hoạt động ưa thích của tôi và liệu tôi có mua ô tô hay không. Kết hợp các câu trả lời cho những câu hỏi này để lập kế hoạch hành trình của tôi tốt hơn.

🧠 Cognitive Verifier Mẫu - Lời nhắc cốt lõi dành riêng cho QA

Khi bạn được hỏi một câu hỏi liên quan đến kiểm tra hoặc QA, hãy làm theo các quy tắc sau:

  1. Tạo ra một số làm rõ các câu hỏi phụ để thu thập ngữ cảnh bổ sung - chẳng hạn như loại hệ thống, cấp độ kiểm tra, ràng buộc, môi trường hoặc định dạng.
  2. Sử dụng câu trả lời cho những câu hỏi phụ đó để Tinh chỉnh sự hiểu biết của bạn về vấn đề.
  3. Kết hợp những hiểu biết sâu sắc để tạo ra một kết quả chính xác và có mục tiêu hơn phản hồi cuối cùng cho câu hỏi ban đầu.

🧪 Ví dụ về QA được tùy chỉnh

✅ Tạo trường hợp thử nghiệm (Thử nghiệm UI/API)

Khi bạn được yêu cầu tạo trường hợp kiểm thử, hãy làm theo các quy tắc sau:

  • Tạo ra các câu hỏi làm rõ về hành vi đặc trưng, hạn chế đầu vào, Các loại phần tử giao diện người dùng hoặc API, và bất kỳ định dạng đầu ra dự kiến (ví dụ: bảng, Gherkin).
  • Sử dụng câu trả lời cho những câu hỏi đó để tạo ra các trường hợp thử nghiệm chính xác và toàn diện hơn.
  • Kết hợp tất cả những hiểu biết sâu sắc vào một bộ thử nghiệm có cấu trúc phù hợp với các phương pháp hay nhất trong QA.

✅ Phân loại lỗi/Chẩn đoán nguyên nhân gốc rễ

Khi được yêu cầu giúp điều tra một trường hợp kiểm thử không thành công hoặc lỗi, hãy làm theo các quy tắc sau:

  • Đặt các câu hỏi chẩn đoán về môi trường thử nghiệm, thay đổi mã gần đây, nhật ký hoặc dấu vết ngăn xếp, và liệu nó có phải là có thể tái tạo hoặc dễ bong tróc.
  • Sử dụng những câu trả lời đó để thu hẹp các nguyên nhân gốc rễ có thể xảy ra nhất.
  • Kết hợp các phát hiện vào một tóm tắt về 1–2 nguyên nhân hàng đầu và đề xuất các bước điều tra tiếp theo.

✅ Đánh giá rủi ro hồi quy

Khi được yêu cầu đánh giá rủi ro hồi quy đối với một thay đổi, hãy làm theo các quy tắc sau:

  • Tạo ra các câu hỏi về tính năng bị ảnh hưởng, phạm vi kiểm tra, sự phụ thuộc, Và mô hình thất bại lịch sử.
  • Sử dụng các câu trả lời để đánh giá khu vực nào có nguy cơ.
  • Kết hợp điều này vào một danh sách khu vực kiểm tra hồi quy ưu tiên để QA tập trung vào.

✅ Lập kế hoạch chiến lược QA

Khi được yêu cầu thiết kế chiến lược QA cho sản phẩm hoặc tính năng mới, hãy làm theo các quy tắc sau:

  • Đặt câu hỏi về tiến độ dự án, tần số phát hành, mức độ kiểm tra cần thiết (đơn vị, tích hợp, giao diện người dùng) và cấp độ/công cụ kỹ năng nhóm có sẵn.
  • Kết hợp những câu trả lời đó thành một chiến lược bao gồm lập kế hoạch kiểm tra, tự động hóa, số liệu và các lĩnh vực rủi ro.

✅ Thiết kế dữ liệu thử nghiệm

Khi được yêu cầu tạo dữ liệu thử nghiệm, hãy làm theo các quy tắc sau:

  • Hỏi về hạn chế trường, kiểu dữ liệu, phạm vi hợp lệ/không hợp lệ, quy tắc định dạng, Và kỳ vọng trường hợp cạnh.
  • Sử dụng các câu trả lời để đảm bảo dữ liệu kiểm tra được chính xác, đa dạng và thực tế cho kịch bản thử nghiệm nhất định.

🧰 Lời nhắc theo dõi tùy chọn để sử dụng trong quá trình thực hành QA

Bạn có muốn tôi áp dụng Mẫu Cognitive Verifier bây giờ không?

Nếu có, vui lòng đặt câu hỏi kiểm tra của bạn và tôi sẽ chia nhỏ câu hỏi đó thành các câu hỏi phụ trước khi đưa ra câu trả lời cuối cùng, chính xác hơn cho bạn.

Tip 4 – Mẫu—Audience Persona

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Giải thích X cho tôi.
  • Giả sử tôi là Persona Y.

Bạn sẽ cần thay thế “Y” bằng một tính cách thích hợp, chẳng hạn như “có nền tảng kiến ​​thức hạn chế về khoa học máy tính” hoặc “chuyên gia chăm sóc sức khỏe”. Sau đó, bạn sẽ cần chỉ định chủ đề X cần được giải thích.

Ví dụ:

  • Giải thích các mô hình ngôn ngữ lớn cho tôi. Giả sử tôi là một con chim.
  • Giải thích cho tôi cách chuỗi cung ứng của các cửa hàng tạp hóa ở Hoa Kỳ hoạt động như thế nào. Giả sử tôi là Thành Cát Tư Hãn.

👥 Audience Persona Mẫu - Lời nhắc cốt lõi dành riêng cho QA

Khi tạo phản hồi, hãy điều chỉnh nó cho phù hợp với đối tượng mục tiêu.

Thực hiện theo các quy tắc sau:

  1. Xác định tính cách khán giả (ví dụ: người thử nghiệm, nhà phát triển, trưởng nhóm thử nghiệm, người quản lý sản phẩm).
  2. Thích ứng của bạn ngôn ngữ, mức độ chi tiết và định dạng để phù hợp với mục tiêu, trình độ kiến ​​thức và mức độ ưu tiên của người đó.
  3. Trình bày câu trả lời cuối cùng theo cách có thể hành động và phù hợp dành cho đối tượng cụ thể đó.

🧪 Ví dụ về QA được tùy chỉnh

✅ 1. Đối với Người kiểm tra trình độ đầu vào

Khi giải thích cách thiết kế các trường hợp kiểm thử giá trị biên, hãy điều chỉnh phản hồi cho người kiểm thử cấp đầu vào.

Sử dụng ngôn ngữ đơn giản, cung cấp ví dụ cụ thể và tránh thuật ngữ nặng nề.

Hãy tập trung giúp đỡ họ học và áp dụng kỹ thuật chính xác với trường giao diện người dùng trong thế giới thực như ngày hoặc giá.

✅ 2. Dành cho nhà phát triển

Khi mô tả một trường hợp kiểm thử không thành công, hãy điều chỉnh phản hồi cho phù hợp với nhà phát triển cần gỡ lỗi.

Nhấn mạnh:

  • Khả năng tái tạo (các bước, môi trường, dữ liệu)
  • Nhật ký hoặc thông báo lỗi
  • Nguyên nhân cốt lõi đáng ngờTránh biệt ngữ QA và tập trung vào thông tin ngắn gọn, có thể hành động.

✅ 3. Đối với Người quản lý sản phẩm

Khi tóm tắt kết quả kiểm tra, hãy điều chỉnh phản hồi cho người quản lý sản phẩm.

Điểm nổi bật:

  • Khu vực rủi ro cấp độ cao
  • Sự cố chặn
  • Tính sẵn sàng của tính năng Tránh các chi tiết kỹ thuật hoặc ngôn ngữ thiết kế thử nghiệm trừ khi cần thiết. Hiện trạng về mặt tác động kinh doanh và rủi ro phát sinh.

✅ 4. Dành cho Trợ lý kiểm tra AI

Khi viết lời nhắc cho trình tạo trường hợp kiểm thử AI, hãy điều chỉnh hướng dẫn của bạn cho phù hợp với trợ lý kiểm thử LLM cần bối cảnh rõ ràng và định dạng đầu ra nghiêm ngặt.

Bao gồm:

  • Cấp độ kiểm tra (UI, API)
  • Định dạng đầu ra mong muốn (bảng, Gherkin, JSON)
  • Bất kỳ ràng buộc nào (ví dụ: chỉ các trường hợp tích cực) Sử dụng ngôn ngữ có cấu trúc, chính xác, không mơ hồ.

✅ 5. Dành cho Trưởng nhóm QA hoặc Người quản lý kiểm tra

Khi tạo kế hoạch kiểm tra hoặc tóm tắt phạm vi bảo hiểm, hãy điều chỉnh kế hoạch đó cho phù hợp với khách hàng tiềm năng QA.

Nhấn mạnh:

  • Khoảng trống bảo hiểm
  • Ưu tiên dựa trên rủi ro
  • Căn chỉnh với các mục tiêu chạy nước rút Sử dụng các bảng, thẻ có tổ chức và khả năng truy nguyên theo yêu cầu.

🔁 Lời nhắc thực hành dành cho người thử nghiệm

Bất cứ khi nào tôi hỏi một câu hỏi liên quan đến thử nghiệm, hãy nhắc tôi xác định đối tượng mục tiêu để nhận câu trả lời (ví dụ: nhà phát triển, chủ sở hữu sản phẩm, người thử nghiệm cấp dưới, đại lý AI).

Sau đó, đề xuất một phiên bản phản hồi phù hợp với đối tượng đó.

Tip 5 – Mẫu—Game Play (Học, ghi nhớ và luyện tập)

Game Play Mẫu

  • Để sử dụng mẫu này, hãy đưa hai điều quan trọng vào lời nhắc của bạn:
  • Nói: “Hãy chơi một trò chơi về X” hoặc “Tạo cho tôi một trò chơi về X”.
  • Đưa ra ít nhất một quy tắc hoặc cách trò chơi sẽ hoạt động.

Thay thế X với nội dung trò chơi—chẳng hạn như nấu ăn, du hành thời gian hoặc giải quyết những bí ẩn. Sau đó giải thích các quy tắc, chẳng hạn như “Cho tôi lựa chọn mỗi lượt” hoặc “Cho tôi điểm dựa trên mức độ tôi làm”.

Ví dụ:

  • Tạo trò chơi thử thách nấu ăn cho một người chơi. Mỗi vòng, đưa cho tôi một bộ nguyên liệu ngẫu nhiên. Tôi phải nghĩ ra một ý tưởng công thức thú vị. Bạn đánh giá công thức của tôi từ 1 đến 10 dựa trên tính sáng tạo, hương vị và mức độ hiệu quả của nó. Sau một vài vòng, hãy cho tôi biết điểm cuối cùng của tôi và đặt cho tôi danh hiệu nấu ăn dựa trên cách tôi đã làm.
  • Tạo một trò chơi đoán biểu tượng cảm xúc ngớ ngẩn. Mỗi vòng, hãy cho tôi xem bộ 3–5 biểu tượng cảm xúc gợi ý về một từ, bộ phim hoặc cụm từ. Tôi phải đoán xem nó có ý nghĩa gì. Nếu tôi làm đúng, hãy cho tôi một điểm. Nếu tôi sai, hãy cho tôi một gợi ý hài hước. Hãy chơi 5 hiệp rồi cho tôi điểm cuối cùng nhé.

🎮 Game Play Mẫu (Phiên bản dành riêng cho QA)

Cấu trúc của Mẫu Prompt:

  1. Tạo một trò chơi xoay quanh [Chủ đề thử nghiệm] HOẶC Chúng ta sẽ chơi một trò chơi [Kỹ năng QA]
  2. Xác định các quy tắc của trò chơi (những gì tôi có thể làm, cách tiến bộ, cách tính điểm hoặc phản hồi hoạt động)
  3. Bắt đầu tương tác (ví dụ: câu hỏi đầu tiên, kịch bản hoặc thử thách)

🧪 Ví dụ về trò chơi dành riêng cho QA

1. Trò chơi khám phá trường hợp thử nghiệm

Prompt:

Tạo cho tôi một trò chơi tên là Test Coverage Explorer.

Trong trò chơi này, tôi sẽ khám phá những điều khác nhau tính năng của một ứng dụngvà với mỗi câu hỏi, bạn sẽ thách thức tôi xác định:

  • Một trường hợp thử nghiệm tích cực
  • Một trường hợp thử nghiệm tiêu cực
  • Một trường hợp cạnh

Hãy cho tôi điểm dựa trên mức độ hoàn chỉnh hoặc sáng tạo của các trường hợp thử nghiệm của tôi.

Bắt đầu với tính năng đầu tiên: “Đăng nhập người dùng”.

2. Cuộc phiêu lưu săn bọ

Prompt:

Chúng ta sẽ chơi trò chơi Phiêu lưu săn bọ.

Bạn sẽ cho tôi xem màn hình, hành vi hoặc đoạn nhật ký từ một ứng dụng hư cấu. Công việc của tôi là:

  • Phát hiện lỗi chức năng
  • Phân loại mức độ nghiêm trọng
  • Đề xuất các bước sao chép

Điểm thưởng dựa trên tính chính xác và đầy đủ.

Cho tôi xem màn hình hoặc hành vi lỗi đầu tiên.

3. Trò chơi gỡ lỗi nhắc nhở kiểm tra AI

Prompt:

Hãy chơi một trò chơi có tên là Thử thách gỡ lỗi nhanh chóng.

Bạn sẽ cho tôi xem lời nhắc tạo thử nghiệm thiếu sót. Tôi phải:

  • Phát hiện xem nó có vấn đề gì (ví dụ: thiếu định dạng, không có cá tính)
  • Viết lại nó để cải thiện nó

Đối với mỗi bản sửa đổi tốt, hãy cho tôi phản hồi và cho điểm.

Chỉ cho tôi lời nhắc thiếu sót đầu tiên.

4. Trò chơi lập bản đồ yêu cầu thử nghiệm

Prompt:

Tạo cho tôi một trò chơi tên là Spec Decoding.

Mỗi vòng, hãy đưa cho tôi một dòng câu chuyện hoặc yêu cầu của người dùng.

Tôi phải:

  • Viết ít nhất một trường hợp kiểm thử phù hợp
  • Giải thích lý do tại sao nó đáp ứng được yêu cầu

Nếu tôi bỏ sót các trường hợp khó khăn hoặc hiểu sai thông số kỹ thuật, tôi sẽ bị trừ điểm.

Hãy bắt đầu với câu chuyện đầu tiên: “Là một người dùng, tôi muốn tải lên một tệp có hỗ trợ kéo và thả”.

5. Trò chơi xây dựng chiến lược QA

Prompt:

Chúng ta sẽ chơi trò chơi Người xây dựng chiến lược QA.

Mỗi vòng, bạn đưa cho tôi một kịch bản dự án nhỏ (ví dụ: “chạy nước rút trong hai tuần với giao diện người dùng ưu tiên thiết bị di động và không áp dụng tự động hóa”).

Tôi phải:

  • Chọn chiến lược thử nghiệm hiệu quả nhất
  • Giải thích tại sao nó phù hợp

Cho điểm các câu trả lời của tôi và giúp tôi tinh chỉnh các lựa chọn của mình.

Bắt đầu với kịch bản đầu tiên.

6. Trò chơi truy xuất nguồn gốc

Prompt:

Hãy chơi Truy xuất nguồn gốc Tracker.

Bạn sẽ cho tôi:

  • Một mô tả tính năng
  • A few test cases I need to:
  • Ánh xạ từng bài kiểm tra theo yêu cầu
  • Xác định phạm vi kiểm tra bị thiếu

Thưởng điểm thưởng cho việc tìm kiếm những khoảng trống trong vùng phủ sóng.

Cho tôi xem bộ đầu tiên.

7. Game Thám Tử Khiếm Khuyết

Prompt:

Bắt đầu một trò chơi có tên là Thám tử khiếm khuyết.

Trong mỗi vòng, hãy cho tôi xem:

  • A vague or incomplete bug description I have to:
  • Xây dựng lại thông tin còn thiếu (môi trường, các bước repro, mức độ nghiêm trọng, dự kiến ​​so với thực tế)

Đánh giá mức độ đầy đủ và chính xác của báo cáo lỗi được tạo lại của tôi.

Hãy cho tôi mục nhập lỗi đầu tiên.

🧰 Lời nhắc bổ sung để kích hoạt mẫu trong trợ lý AI được hỗ trợ LLM

Từ giờ trở đi, khi tôi nói “Hãy chơi trò chơi QA,”

  • Hỏi tôi xem tôi muốn tập trung vào lĩnh vực kỹ năng nào (viết test case, phân tích lỗi, thiết kế nhanh chóng, v.v.)
  • Chọn hoặc tạo định dạng trò chơi dựa trên đó
  • Giải thích các quy tắc
  • Bắt đầu vòng đầu tiên
Tip 6 – Mẫu—Template

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Tôi sẽ cung cấp một mẫu cho đầu ra của bạn
  • X là phần giữ chỗ của tôi cho nội dung
  • Cố gắng khớp đầu ra vào một hoặc nhiều phần giữ chỗ mà tôi liệt kê
  • Vui lòng giữ nguyên định dạng và mẫu tổng thể mà tôi cung cấp
  • Đây là mẫu: MẪU với CHỮ GIỮ

Bạn sẽ cần thay thế “X” bằng một trình giữ chỗ thích hợp, chẳng hạn như “TỪ CHỮ HOA” hoặc “<PLACEHOLDER>”. Sau đó, bạn sẽ cần chỉ định mẫu để điền vào, chẳng hạn như “Kính gửi <TÊN ĐẦY ĐỦ>” hoặc “TÊN, CHỨC DANH, CÔNG TY”.

Ví dụ:

  • Tạo một bài tập sức mạnh ngẫu nhiên cho tôi ngay hôm nay với các bài tập bổ sung. Tôi sẽ cung cấp một mẫu cho đầu ra của bạn. TỪ VIẾT HOA là phần giữ chỗ của tôi cho nội dung. Cố gắng khớp đầu ra vào một hoặc nhiều phần giữ chỗ mà tôi liệt kê. Vui lòng giữ nguyên định dạng và mẫu tổng thể mà tôi cung cấp. Đây là mẫu: TÊN, REPS @ SETS, NHÓM CƠ ĐÃ LÀM VIỆC, QUY MÔ KHÓ KHÓ 1–5, GHI CHÚ MẪU
  • Hãy tạo một danh sách tạp hóa để tôi nấu mì ống và phô mai từ đầu, bánh mì tỏi và sốt marinara từ đầu. Tôi sẽ cung cấp một mẫu cho đầu ra của bạn. <trình giữ chỗ> là phần giữ chỗ của tôi cho nội dung. Cố gắng khớp đầu ra vào một hoặc nhiều phần giữ chỗ mà tôi liệt kê. Vui lòng giữ nguyên định dạng và mẫu tổng thể mà tôi cung cấp. Đây là mẫu: Lối đi <tên lối đi>: <vật phẩm cần thiết từ lối đi>, <qty> (<(các) món ăn được sử dụng trong>

Để sử dụng mẫu này, hãy nói với AI ba điều trong lời nhắc của bạn:

  • “Tôi đang cho bạn một khuôn mẫu để làm theo.”
  • “Đây là cách nhận biết câu trả lời của bạn nên đi đến đâu—hãy tìm các phần giữ chỗ như X hoặc <PLACEHOLDER>.”
  • “Hãy điền vào những chỗ đó và giữ nguyên cấu trúc và định dạng.”

Mẫu giúp bạn kiểm soát cách AI định dạng câu trả lời—tuyệt vời để tạo danh sách, thư, báo cáo hoặc danh sách kiểm tra.

Ví dụ:

  • Hãy lập lịch trình hàng ngày cho tôi. I’m giving you a template to follow. Use <TIME>, <ACTIVITY>, and <NOTES> as placeholders. Try to fit the output into this format and keep it neat. Template: < TIME > — < ACTIVITY > — < NOTES >
  • Lên kế hoạch cho một đêm xem phim với bạn bè. Tôi sẽ cung cấp cho bạn một định dạng để sử dụng. Điền vào phần giữ chỗ TẤT CẢ CAPS. Mẫu: TÊN PHIM: THỂ LOẠI Món ăn vặt: LOẠI — CHUẨN BỊ HOẠT ĐỘNG BẮT BUỘC TRƯỚC/SAU: NHỮNG GÌ CHÚNG TÔI LÀM
  • Viết danh sách hành lý cho chuyến đi bộ đường dài 3 ngày. Hãy sử dụng cấu trúc này và điền các mục vào đúng chỗ. Mẫu: <NGÀY>: — QUẦN ÁO: <LIST> — THIẾT BỊ: <LIST> — THỰC PHẨM: <LIST>
  • Tạo bản tóm tắt ngân sách hàng tuần. Sử dụng mẫu này với các phần giữ chỗ mà tôi cung cấp. Bản mẫu: DANH MỤC: <LOẠI CHI PHÍ> ĐÃ CHI TIÊU: $<SỐ TIỀN> CẦN ĐÁNH GIÁ: <CÓ/KHÔNG> LƯU Ý: <THÔNG TIN BỔ SUNG>

Để sử dụng mẫu này, hãy nói với AI ba điều trong lời nhắc của bạn:

  • “Tôi đang cho bạn một khuôn mẫu để làm theo.”
  • “Đây là cách nhận biết câu trả lời của bạn nên đi đến đâu—hãy tìm các phần giữ chỗ như X hoặc <PLACEHOLDER>.”
  • “Hãy điền vào những chỗ đó và giữ nguyên cấu trúc và định dạng.”

Các mẫu giúp bạn kiểm soát cách AI định dạng câu trả lời của nó—tuyệt vời để tạo danh sách, thư, báo cáo hoặc danh sách kiểm tra

🧪 Mẫu mẫu - Thích ứng dành riêng cho QA

🔧 Cách sử dụng (Phiên bản QA)

Tôi sẽ cung cấp một mẫu cho đầu ra của bạn.

X là phần giữ chỗ của tôi cho nội dung.

Cố gắng điều chỉnh câu trả lời của bạn phù hợp với các phần giữ chỗ mà tôi liệt kê.

Vui lòng giữ nguyên định dạng và cấu trúc của mẫu tôi cung cấp.

Đây là mẫu: [MẪU QA CỦA BẠN VỚI NGƯỜI GIỮ CHỖ]

🧪 Ví dụ về Lời nhắc QA bằng cách sử dụng Mẫu mẫu

✅ 1. Mẫu bảng test case

Prompt:

Tôi sẽ cung cấp một mẫu cho đầu ra của bạn. X là phần giữ chỗ của tôi cho nội dung.

Cố gắng sắp xếp các trường hợp thử nghiệm vào các phần giữ chỗ mà tôi liệt kê.

Giữ nguyên định dạng của bảng này.

Đây là mẫu:

sql
Sao chépSửa đổi
| ID KIỂM TRA | KỊCH BẢN | BƯỚC | KẾT QUẢ DỰ KIẾN |
|----------|----------|-------|-------------------|
| X | X | X | X |

✅ 2. Gherkin Mẫu kịch bản

Prompt:

I will provide a template for your output. <PLACEHOLDER> is where you’ll insert content.

Giữ định dạng Gherkin chính xác như đã viết.

Đây là mẫu:

php-template
CopyEdit
Feature: <FEATURE NAME>
  Scenario: <SCENARIO TITLE>
    Given <INITIAL CONTEXT>
    When <ACTION TAKEN>
    Then <EXPECTED OUTCOME>

✅ 3. Mẫu báo cáo lỗi có cấu trúc

Prompt:

Sử dụng mẫu có cấu trúc này cho đầu ra. Phần giữ chỗ của tôi đều là chữ hoa.

Điều chỉnh báo cáo lỗi vào các trường chính xác và giữ nguyên bố cục.

Đây là mẫu:

vbnet
Sao chépSửa đổi
TIÊU ĐỀ LỖI: VĂN BẢN TIÊU ĐỀ
MÔI TRƯỜNG: PHIÊN BẢN THIẾT BỊ/HĐH/ỨNG DỤNG
CÁC BƯỚC ĐỂ TÁI SINH:
1. BƯỚC MỘT
2. BƯỚC HAI
KẾT QUẢ MONG ĐỢI: KỲ VỌNG
KẾT QUẢ THỰC TẾ: HÀNH VI THỰC TẾ
MỨC ĐỘ NGHIÊM TRỌNG: CẤP ĐỘ

✅ 4. Mẫu lược đồ dữ liệu thử nghiệm

Prompt:

Use this test data template. <FIELD> is the placeholder to replace.

Duy trì cấu trúc để tải dễ dàng.

Đây là mẫu:

json
CopyEdit
{
  "test_name": "<TEST NAME>",
  "input": "<TEST INPUT>",
  "expected_output": "<EXPECTED OUTPUT>",
  "validation_type": "<ASSERTION TYPE>"
}

✅ 5. Mẫu ma trận truy xuất nguồn gốc

Prompt:

Tôi sẽ cung cấp một mẫu. X biểu thị phần giữ chỗ để bạn điền vào.

Bám sát cấu trúc bảng này để truy xuất nguồn gốc.

Đây là mẫu:

sql
Sao chépSửa đổi
| ID YÊU CẦU | CÂU CHUYỆN NGƯỜI DÙNG | ID TRƯỜNG HỢP THỬ NGHIỆM | TÌNH TRẠNG BẢO HIỂM |
|-------|----------||--------------|-----------------|
| X | X | X | X |

🔁 Hướng dẫn theo dõi tùy chọn:

Bất cứ khi nào tôi cung cấp mẫu, hãy tự động áp dụng Mẫu mẫu — giữ nguyên cấu trúc, chỉ thay thế phần giữ chỗ và không bao giờ thêm định dạng bổ sung hoặc văn bản trò chuyện.

Tip 7 – Mẫu—Meta Language Creation

Mẫu này cho phép bạn xác định ngôn ngữ tốc ký hoặc biểu tượng của riêng mình bên trong lời nhắc.

Cấu trúc cốt lõi là:

Khi tôi nói X, Ý tôi là Y (hoặc tôi muốn bạn làm Y).

Thay thế X với từ, ký hiệu hoặc cụm từ bạn đã chọn và sắp xếp nó theo ý nghĩa dự định Y.

Ví dụ

  1. Từ khóa tùy chỉnh cho các biến thể
    • Luật lệ: Khi tôi nói variations(<something>), Ý tôi là: Hãy cho tôi mười biến thể khác nhau của <something>.
    • Cách sử dụng:
      • các biến thể (tên công ty của một công ty bán dịch vụ phần mềm cho kỹ thuật nhanh chóng)
      • các biến thể (một khẩu hiệu tiếp thị cho dưa chua)
  2. Ký hiệu tùy chỉnh cho các phần phụ thuộc của nhiệm vụ
    • Luật lệ: Khi tôi nói Nhiệm vụ X [Nhiệm vụ Y], Ý tôi là: Nhiệm vụ X phụ thuộc vào việc Nhiệm vụ Y được hoàn thành trước.
    • Cách sử dụng:
      • “Mô tả các bước xây dựng một ngôi nhà bằng ngôn ngữ phụ thuộc nhiệm vụ của tôi.”
      • “Cung cấp thứ tự cho các bước:
        • Đun sôi nước [Bật bếp]
        • Nấu mì ống [Đun nước]
        • Làm Marinara [Bật bếp]
        • Bật Bếp [Vào Bếp]”

🧪 Meta Language Mẫu sáng tạo – Thích ứng dành riêng cho QA

🔧 Hướng dẫn cốt lõi (Phiên bản QA)

Khi tôi nói X, ý tôi là Y (tức là tôi muốn bạn hiểu X là Y hoặc biểu diễn Y).

Thay thế X bằng ký hiệu, thẻ hoặc tốc ký mà tôi sẽ sử dụng trong lời nhắc.

Thay thế Y với ý nghĩa hoặc hướng dẫn mở rộng.

🧪 QA cụ thể Meta Language Ví dụ

✅ 1. Macro trình tạo biến thể thử nghiệm

Sự định nghĩa:

When I say tc_variants(<scenario>), I mean generate 3–5 variations of test cases based on the given scenario (positive, negative, edge).

Cách sử dụng:

tc_variants(tệp tải lên của người dùng thông qua kéo và thả)

✅ 2. Ngôn ngữ phụ thuộc để thiết lập thử nghiệm

Sự định nghĩa:

Khi tôi nói Kiểm tra X [Kiểm tra Y], ý tôi là Kiểm tra X phụ thuộc vào Kiểm tra Y (tức là Kiểm tra Y phải vượt qua hoặc chạy trước).

Cách sử dụng:

Đặt lại mật khẩu [Email yêu cầu đặt lại]

Xác nhận liên kết email [Đặt lại mật khẩu]

✅ 3. Thẻ lược đồ đầu ra

Sự định nghĩa:

Khi tôi viết :gherkin: trong lời nhắc của mình, hãy tạo các trường hợp thử nghiệm ở định dạng Cho trước–Khi–Sau đó.

Khi tôi viết :json:, trả về các trường hợp kiểm thử dưới dạng đối tượng JSON.

Khi tôi viết :bàn:, định dạng dưới dạng bảng Markdown.

Cách sử dụng:

Tạo các trường hợp thử nghiệm để người dùng đăng nhập :gherkin:

Đầu vào kiểm tra giá trị biên đầu ra cho trường số điện thoại :json:

✅ 4. Siêu thuật ngữ cho khoảng trống kiểm tra

Sự định nghĩa:

When I say gap_check(<test_suite>, <feature>), I want you to analyze the test suite and identify missing cases for the given feature.

Cách sử dụng:

Gap_check(test_cases_for_cart, logic trạng thái nút thanh toán)

✅ 5. Kiểm tra lối tắt Oracle

Sự định nghĩa:

When I say expect(<input>), I mean derive the expected output from the system under test for that input, with reasoning.

Cách sử dụng:

expect({ “start_date”: “2025-01-01”, “end_date”: “2025-01-02” })

✅ 6. Phím tắt ngôn ngữ lỗi

Sự định nghĩa:

When I say bug(<symptom>, <module>), I mean generate a structured bug report that includes:

  • Các bước tái tạo
  • Môi trường
  • Mức độ nghiêm trọng
  • Nguyên nhân được đề xuất (nếu có)

Cách sử dụng:

bug(“crash on form submit”, “user registration”)

✅ 7. DSL lập bản đồ vùng phủ sóng

Sự định nghĩa:

When I say map(<requirement>) -> <test_ids>, I mean create a traceability link between the requirement and its covering tests.

Cách sử dụng:

map(REQ-1234) -> TC001, TC002, TC007

✅ Cách kích hoạt trong GPT

Khi tôi xác định quy tắc ngôn ngữ meta như X = Y, hãy nhớ quy tắc đó trong phần còn lại của phiên.

Áp dụng nó bất cứ lúc nào tôi sử dụng X.

Ask me to clarify if you’re unsure about a new symbol or term.

🔁 Lời nhắc giảng dạy tùy chọn

Hãy giúp tôi xây dựng một ngôn ngữ meta để tạo trường hợp thử nghiệm.

Tôi sẽ xác định các phím tắt hoặc cú pháp tùy chỉnh và bạn sẽ ghi nhớ và áp dụng chúng cho đến khi tôi nói “đặt lại quy tắc”.

Bắt đầu bằng cách hỏi tôi muốn sử dụng loại tốc ký nào.

Tip 8 – Mẫu—Recipe

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Tôi muốn đạt được X
  • Tôi biết rằng tôi cần thực hiện các bước A, B, C
  • Cung cấp cho tôi trình tự đầy đủ các bước
  • Điền vào bất kỳ bước còn thiếu
  • (Tùy chọn) Xác định mọi bước không cần thiết

Bạn sẽ cần phải thay thế “X” bằng một nhiệm vụ thích hợp. Sau đó, bạn sẽ cần chỉ định các bước A, B, C mà bạn biết cần phải là một phần của công thức/kế hoạch hoàn chỉnh.

Ví dụ:

  • Tôi muốn mua một ngôi nhà. Tôi biết rằng tôi cần phải thực hiện các bước đưa ra lời đề nghị và chốt giao dịch mua nhà. Cung cấp cho tôi một trình tự đầy đủ các bước. Điền vào bất kỳ bước còn thiếu.
  • Tôi muốn lái xe đến New York từ Nashville. Tôi biết rằng tôi muốn đi qua Asheville, NC trên đường đi và tôi không muốn lái xe hơn 300 dặm mỗi ngày. Cung cấp cho tôi một trình tự đầy đủ các bước. Điền vào bất kỳ bước còn thiếu.

🧪 Mẫu công thức – Thích ứng dành riêng cho QA

🔧 Định dạng nhắc nhở cốt lõi (Phiên bản QA):

Tôi muốn đạt được [Mục tiêu thử nghiệm].

Tôi biết rằng tôi cần phải thực hiện các bước A, B, C.

Cung cấp một trình tự đầy đủ các bước cho tôi.

Điền vào bất kỳ thiếu bước.

(Tùy chọn) Xác định bất kỳ các bước không cần thiết Tôi có thể đã bao gồm.

🧪 Ví dụ cụ thể về QA của Mẫu công thức

✅ 1. Quy trình thực hiện kiểm thử thủ công

Prompt:

Tôi muốn thực thi thủ công bộ kiểm tra hồi quy cho một ứng dụng web.

Tôi biết rằng tôi cần phải:

  • Đăng nhập vào môi trường thử nghiệm
  • Thực hiện từng bước kiểm tra
  • Report bugs in the tracker Provide a trình tự đầy đủ các bước. Fill in any nhiệm vụ còn thiếu (như chuẩn bị môi trường, thiết lập dữ liệu thử nghiệm).

✅ 2. Thiết lập đường ống tự động hóa

Prompt:

Tôi muốn thiết lập quy trình tự động hóa thử nghiệm cho ứng dụng web React bằng cách sử dụng Tác vụ Selenium và GitHub.

Tôi biết tôi cần phải:

  • Viết kịch bản thử nghiệm
  • Đẩy chúng tới GitHub
  • Create a GitHub Actions workflow Please điền vào quá trình thiết lập hoàn chỉnh, bao gồm mọi bước quản lý phần phụ thuộc hoặc cấu hình bị thiếu.

✅ 3. Quy trình đánh giá trường hợp thử nghiệm do AI tạo

Prompt:

Tôi muốn xem xét các trường hợp thử nghiệm do AI tạo ra để đảm bảo chất lượng và độ chính xác.

Tôi biết tôi cần phải:

  • Xác thực phạm vi bảo hiểm
  • Kiểm tra hình thức kiểm tra
  • Compare expected results Provide a danh sách kiểm tra đánh giá đầy đủ và quy trình làm việc.Hãy điền vào bất kỳ phương pháp hay nhất nào khác mà tôi nên tuân theo trong quá trình đánh giá này.

✅ 4. Chiến lược đảm bảo chất lượng toàn diện cho tính năng mới

Prompt:

Tôi muốn xây dựng chiến lược QA hoàn chỉnh cho tính năng cổng thanh toán mới.

Tôi biết rằng tôi cần phải:

  • Hiểu được yêu cầu kinh doanh
  • Viết các trường hợp thử nghiệm
  • Execute both UI and API tests Provide a full plan that includes thử nghiệm trước, phân tích rủi ro, thiết lập môi trường, Và xác nhận sau phát hành.

✅ 5. Quy trình vòng đời lỗi

Prompt:

Tôi muốn hiểu toàn bộ vòng đời của một lỗi từ khi phát hiện đến khi kết thúc.

Tôi biết rằng tôi cần phải:

  • Tái tạo vấn đề
  • Đăng nhập vào hệ thống theo dõi
  • Retest once fixed Please complete the full set of steps, including triage, assignment, severity classification, and regression testing.

🧰 Lời nhắc thưởng dành cho Trợ giảng QA

Tôi sẽ giao cho bạn một nhiệm vụ QA và một số bước mà tôi biết là bắt buộc.

Công việc của bạn là áp dụng Mẫu công thức:

  • Hoàn thành chuỗi đầy đủ
  • Điền vào các giai đoạn hoặc nhiệm vụ còn thiếu
  • Point out if I’ve listed something out of order or unnecessary Ready? Here’s the task…
Tip 9 – Mẫu—Alternative Approaches

Để sử dụng mẫu này, hãy làm như sau:

  • Nếu có những cách khác để hoàn thành nhiệm vụ X mà tôi giao cho bạn, hãy liệt kê các phương pháp thay thế tốt nhất

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • (Tùy chọn) so sánh/đối chiếu ưu và nhược điểm của từng phương pháp
  • (Tùy chọn) bao gồm cách ban đầu mà tôi yêu cầu
  • (Tùy chọn) nhắc tôi về phương pháp tôi muốn sử dụng

Bạn sẽ cần phải thay thế “X” bằng một nhiệm vụ thích hợp.

Ví dụ:

  • For every prompt I give you, if there are alternative ways to word a prompt that I give you, list the best alternate wordings . Compare/contrast the pros and cons of each wording.
  • Đối với bất cứ điều gì tôi yêu cầu bạn viết, hãy xác định vấn đề tiềm ẩn mà tôi đang cố gắng giải quyết và cách tôi đang cố gắng giải quyết nó. Liệt kê ít nhất một cách tiếp cận thay thế để giải quyết vấn đề và so sánh/đối chiếu cách tiếp cận đó với cách tiếp cận ban đầu mà tôi yêu cầu bạn.

🧪 Alternative Approaches Mẫu – Thích ứng dành riêng cho QA

🔧 Định dạng nhắc nhở cốt lõi (Phiên bản QA)

Nếu có những cách khác để hoàn thành nhiệm vụ kiểm tra X mà tôi giao cho bạn,

  • Liệt kê phương pháp thay thế tốt nhất
  • (Không bắt buộc) So sánh và đối chiếu các ưu và nhược điểm của mỗi cách tiếp cận
  • (Không bắt buộc) Bao gồm cách ban đầu tôi đã yêu cầu
  • (Không bắt buộc) Hãy hỏi tôi muốn tiếp tục với cái nào

🧪 Ví dụ cụ thể về QA sử dụng mẫu này

✅ 1. Nhiệm vụ: Kiểm tra chức năng đăng nhập

Prompt:

Tôi muốn kiểm tra chức năng đăng nhập của một ứng dụng web.

Nếu có những cách tiếp cận khác để kiểm tra nó, hãy liệt kê chúng.

So sánh ưu và nhược điểm của chúng.

Hãy hỏi tôi nên tiếp tục với cái nào.

LLM Có thể trả lời:

  • Cách tiếp cận A: Kiểm tra thăm dò thủ công của giao diện người dùng
    • ✅ Tuyệt vời về khả năng sử dụng và xác nhận trực quan
    • ❌ Không lặp lại, tốn thời gian
  • Cách tiếp cận B: Kiểm tra giao diện người dùng tự động bằng Selenium
    • ✅ Có thể lặp lại và mở rộng
    • ❌ Chi phí bảo trì, bộ chọn không ổn định
  • Cách tiếp cận C: Kiểm tra xác thực cấp API
    • ✅Nhanh, ít giòn
    • ❌ Không kiểm tra các tương tác giao diện người dùng

➤ Bạn muốn tiếp tục theo cách tiếp cận nào?

✅ 2. Nhiệm vụ: Tạo dữ liệu thử nghiệm cho trường ngày

Prompt:

Tôi cần dữ liệu thử nghiệm cho trường date_of_birth.

Liệt kê các phương pháp thay thế để tạo ra nó và giải thích khi nào mỗi phương pháp là phù hợp nhất.

LLM Có thể trả lời:

  • Cách tiếp cận A: Lựa chọn giá trị biên thủ công
    • Tốt cho các dãy phòng nhỏ, tập trung
  • Cách tiếp cận B: Sử dụng thư viện dữ liệu Faker hoặc tổng hợp
    • Tuyệt vời cho dữ liệu thử nghiệm thực tế số lượng lớn
  • Cách tiếp cận C: Sử dụng AI để tạo các trường hợp biên nhận biết ngữ cảnh
    • Hữu ích cho các tình huống căng thẳng thông minh

Yêu cầu ban đầu: Tạo thủ công

Đề xuất sử dụng Faker nếu quy mô là quan trọng. Bạn có muốn chuyển đổi không?

✅ 3. Nhiệm vụ: Xem xét các trường hợp thử nghiệm do AI tạo

Prompt:

Tôi muốn xem lại các trường hợp thử nghiệm do AI tạo ra.

Những cách khác để tôi có thể xác nhận tính chính xác của chúng là gì?

LLM Có thể trả lời:

  • Cách tiếp cận A: Xem xét thủ công theo yêu cầu (bản gốc)
  • Cách tiếp cận B: Xác thực chéo dựa trên ma trận truy xuất nguồn gốc
  • Cách tiếp cận C: Ghép nối đầu ra AI với các mẫu lỗi lịch sử để xác định các lỗ hổng

Ưu/nhược điểm bao gồm độ chính xác, phạm vi bao phủ và nỗ lực.

➤ Chọn đường dẫn xác nhận ưa thích của bạn.

✅ 4. Nhiệm vụ: Thực hiện Regression testing

Prompt:

Tôi cần thực hiện kiểm tra hồi quy sau khi phát hành chính.

Chỉ cho tôi những cách tiếp cận khác và sự đánh đổi của chúng.

LLM Có thể trả lời:

  • Cách tiếp cận A: Bộ hồi quy thủ công đầy đủ
    • ✅ Kỹ lưỡng, được con người kiểm chứng
    • ❌ Tốn nhiều thời gian
  • Cách tiếp cận B: Hồi quy có chọn lọc sử dụng mức độ ưu tiên dựa trên rủi ro
    • ✅ Nhanh chóng, phù hợp với công việc
    • ❌ Có thể bỏ sót các lỗi có nguy cơ thấp
  • Cách tiếp cận C: Khói điều khiển tự động + thăm dò tập trung
    • ✅ Cân bằng lai giữa tốc độ và độ sâu
    • ❌ Đòi hỏi phải có dụng cụ và kỹ năng tốt

✅ 5. Nhiệm vụ: Thiết lập tự động hóa thử nghiệm cho ứng dụng di động

Prompt:

Tôi muốn tự động hóa các thử nghiệm cho một ứng dụng dành cho thiết bị di động.

Liệt kê các khuôn khổ và chiến lược tốt nhất mà tôi có thể sử dụng.

Bao gồm sự đánh đổi.

LLM Có thể trả lời:

  • Appium: Đa nền tảng, mã nguồn mở
  • Giải độc: Nhanh chóng cho React Native
  • XCUITest / Espresso: Nền tảng gốc, ổn định
  • Ưu/nhược điểm bao gồm đường cong học tập, cộng đồng và bảo trì

Cái nào phù hợp với mục tiêu và ngăn xếp công nghệ của bạn?

🧰 Tiện ích bổ sung nhắc nhở hệ thống tùy chọn dành cho trợ lý

Đối với mỗi nhiệm vụ QA hoặc lời nhắc kiểm tra, tôi sẽ cung cấp cho bạn:

  • Nếu có những cách khác để giải quyết, hãy liệt kê 2–3 cách tốt nhất
  • So sánh chúng một cách ngắn gọn
  • Hỏi xem tôi muốn tiếp tục với một hay khám phá thêm
Tip 10 – Mẫu—Ask for input

Yêu cầu mẫu đầu vào

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Yêu cầu tôi nhập X

Bạn sẽ cần thay thế “X” bằng thông tin đầu vào, chẳng hạn như “câu hỏi”, “thành phần” hoặc “mục tiêu”.

Ví dụ:

  • Từ giờ trở đi, tôi sẽ cắt/dán chuỗi email vào cuộc trò chuyện của chúng ta. Bạn sẽ tóm tắt quan điểm của từng người trong chuỗi email. Bạn sẽ cung cấp bản tóm tắt của mình dưới dạng một loạt các gạch đầu dòng tuần tự. Cuối cùng, hãy liệt kê bất kỳ câu hỏi mở hoặc mục hành động nào được gửi trực tiếp cho tôi. Tên tôi là Jill Smith. Hỏi tôi chuỗi email đầu tiên.
  • Từ giờ trở đi, hãy dịch bất cứ điều gì tôi viết thành một chuỗi âm thanh và hành động của một con chó thể hiện phản ứng của con chó đối với những gì tôi viết. Hãy hỏi tôi điều đầu tiên để dịch.

🧪 Yêu cầu mẫu đầu vào – Điều chỉnh dành riêng cho QA

🔧 Định dạng cốt lõi (Phiên bản QA)

Yêu cầu tôi cung cấp đầu vào X (ví dụ: câu chuyện của người dùng, nhật ký kiểm tra không thành công, báo cáo lỗi, lược đồ dữ liệu kiểm tra, tiêu chí chấp nhận, v.v.).

Sau khi tôi cung cấp thông tin đầu vào, hãy tiến hành tác vụ tương ứng (ví dụ: tạo trường hợp kiểm thử, đề xuất cách khắc phục, phân tích nhật ký, v.v.).

🧪 Ví dụ về lời nhắc dành riêng cho QA

✅ 1. Trợ lý tạo trường hợp thử nghiệm

Prompt:

Từ giờ trở đi, bạn sẽ tạo các trường hợp thử nghiệm dựa trên bất kỳ câu chuyện hoặc mô tả tính năng nào của người dùng mà tôi cung cấp cho bạn.

Định dạng đầu ra dưới dạng bảng với: ID kiểm tra, Kịch bản, Các bước, Kết quả mong đợi.

Hãy hỏi tôi lần đầu tiên câu chuyện người dùng.

✅ 2. Trình ghi lại báo cáo lỗi

Prompt:

Từ giờ trở đi, bạn sẽ lấy bất kỳ mô tả lỗi nào tôi gửi và định dạng lại chúng thành mẫu báo cáo lỗi có cấu trúc.

Bao gồm: Tiêu đề, Môi trường, Các bước Repro, Dự kiến ​​so với Thực tế và Mức độ nghiêm trọng.

Hãy hỏi tôi lần đầu tiên mô tả lỗi.

✅ 3. Trợ lý phân tích nhật ký

Prompt:

Từ giờ trở đi, bạn sẽ phân tích nhật ký lỗi kiểm tra hoặc đầu ra CI để xác định nguyên nhân có thể xảy ra.

Tóm tắt những gì bạn tìm thấy bằng ngôn ngữ đơn giản và đề xuất bước khắc phục sự cố tiếp theo.

Hãy hỏi tôi lần đầu tiên đoạn đăng nhập.

✅ 4. Bộ tổng hợp dữ liệu thử nghiệm

Prompt:

From now on, you’ll generate structured test data in JSON or CSV format based on field definitions I provide.

Hãy hỏi tôi lần đầu tiên lược đồ dữ liệu thử nghiệm hoặc thông số trường.

✅ 5. Bản đồ truy xuất nguồn gốc

Prompt:

Bạn sẽ ánh xạ các trường hợp thử nghiệm theo yêu cầu để đảm bảo phạm vi bao phủ đầy đủ.

Hãy hỏi tôi lần đầu tiên yêu cầu hoặc câu chuyện người dùng để theo dõi.

✅ 6. Người đánh giá nhanh chóng (Meta QA)

Prompt:

Từ giờ trở đi, bạn sẽ phê bình các lời nhắc tạo thử nghiệm của tôi và đề xuất các phiên bản tốt hơn với khả năng kiểm soát định dạng và độ rõ ràng được cải thiện.

Hãy hỏi tôi lần đầu tiên nhắc nhở để xem xét.

✅ 7. Trình tạo danh sách kiểm tra chất lượng

Prompt:

Bạn sẽ tạo danh sách kiểm tra QA chi tiết cho bất kỳ tính năng hoặc quy trình làm việc nào mà tôi mô tả.

Hãy hỏi tôi lần đầu tiên mô tả tính năng hoặc quy trình làm việc.

✅ 8. Cố vấn nguyên nhân gốc rễ của lỗi

Prompt:

Từ giờ trở đi, khi tôi đưa cho bạn một trường hợp kiểm thử thất bại, bạn sẽ đặt những câu hỏi làm rõ và đề xuất hai nguyên nhân có thể xảy ra nhất.

Hãy hỏi tôi lần đầu tiên trường hợp thử nghiệm thất bại để điều tra.

✅ Meta nhắc nhở tùy chọn cho chế độ giảng dạy

Prompt:

Từ giờ trở đi, chúng tôi đang thực hành kỹ thuật nhanh chóng để thử nghiệm các trường hợp sử dụng.

Mỗi lần, hãy hỏi tôi loại nhiệm vụ QA nào tôi muốn trợ giúp (tạo trường hợp kiểm thử, viết lại lỗi, truy xuất nguồn gốc, v.v.).

Sau đó nhắc tôi nhập thông tin cần thiết để hoàn thành nhiệm vụ.

Tip 11 – Mẫu—Outline expansion

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Hoạt động như một trình mở rộng phác thảo.
  • Tạo một phác thảo về dấu đầu dòng dựa trên thông tin đầu vào mà tôi cung cấp cho bạn, sau đó hỏi tôi nên mở rộng điểm đầu dòng nào.
  • Tạo một dàn ý mới cho điểm đầu dòng mà tôi chọn.
  • Cuối cùng, hãy hỏi tôi điểm đầu dòng nào cần mở rộng tiếp theo.
  • Hỏi tôi nên phác thảo những gì.

Ví dụ:

  • Hoạt động như một trình mở rộng phác thảo. Tạo một phác thảo về dấu đầu dòng dựa trên thông tin đầu vào mà tôi cung cấp cho bạn, sau đó hỏi tôi về điểm đầu dòng nào bạn nên mở rộng. Mỗi viên đạn có thể có tối đa 3–5 viên đạn phụ. Các đầu đạn phải được đánh số theo mẫu [A-Z].[i-v].[* đến ****]. Tạo một dàn ý mới cho điểm đầu dòng mà tôi chọn. Cuối cùng, hãy hỏi tôi điểm đầu dòng nào cần mở rộng tiếp theo. Hỏi tôi nên phác thảo những gì.

🧪 Mẫu mở rộng phác thảo – Thích ứng cụ thể cho QA

🔧 Định dạng nhắc nhở cốt lõi (Phiên bản QA)

Hoạt động như một công cụ mở rộng phác thảo cho các chủ đề kiểm tra và QA.

Dựa trên thông tin đầu vào tôi cung cấp cho bạn, hãy tạo một phác thảo điểm đầu dòng cấp cao với cấu trúc được đánh số.

Sau đó hỏi tôi nên mở rộng điểm đầu dòng nào.

Chỉ mở rộng dấu đầu dòng đó thành một dàn ý phụ (3–5 điểm phụ).

Sau mỗi lần mở rộng, hãy hỏi tôi điểm nào sẽ mở rộng tiếp theo.

Bắt đầu bằng cách hỏi: “Tôi nên phác thảo chủ đề kiểm tra hoặc QA nào cho bạn?”

🧪 Ví dụ về lời nhắc dành riêng cho QA

✅ Nhắc sử dụng:

Hoạt động như một công cụ mở rộng phác thảo để kiểm tra phần mềm.

Tạo một phác thảo điểm đầu dòng dựa trên thông tin đầu vào tôi cung cấp cho bạn và sau đó hỏi tôi nên mở rộng dấu đầu dòng nào.

Mỗi viên đạn có thể có tối đa 3–5 viên đạn phụ.

Số đạn sử dụng: MỘT., Ai, A.i.*

Khi tôi chọn một dấu đầu dòng, hãy mở rộng phần đó.

Vào cuối mỗi lần mở rộng, hãy hỏi tôi nên mở rộng gì tiếp theo.

Hỏi tôi cái gì chủ đề kiểm tra hoặc QA bạn nên phác thảo.

🧪 Các trường hợp sử dụng mẫu trong bối cảnh thử nghiệm

✅ Trường hợp sử dụng 1: Tạo chiến lược QA

đầu vào:

Phác thảo chiến lược QA cho ứng dụng thương mại điện tử trên thiết bị di động.

GPT có thể quay trở lại:

mathematica
CopyEdit
A. Test Planning
B. Test Design Techniques
C. Automation Strategy
D. Performance & Load Testing
E. Post-release Monitoring

Rồi hỏi:

Bạn muốn tôi mở rộng viên đạn nào?

✅ Ca sử dụng 2: Mở rộng vòng đời lỗi

đầu vào:

Phác thảo toàn bộ vòng đời lỗi trong JIRA.

GPT có thể quay trở lại:

toán học
Sao chépSửa đổi
A. Nhận dạng lỗi
B. Báo cáo lỗi
C. Phân loại lỗi
D. Sửa lỗi và kiểm tra lại
E. Đóng cửa và hồi quy

→ Khai triển B có thể mang lại:

css
Sao chépSửa đổi
B.i. Viết tiêu đề và tóm tắt rõ ràng
B.ii. Thêm các bước để tái tạo
B.iii. Đính kèm môi trường và nhật ký
B.iv. Chỉ định mức độ nghiêm trọng và mức độ ưu tiên

✅ Ca sử dụng 3: Lập kế hoạch kiểm thử cho một tính năng

đầu vào:

Phác thảo các khu vực kiểm tra cho tính năng đặt lại mật khẩu.

GPT có thể quay trở lại:

toán học
Sao chépSửa đổi
A. Xác thực đầu vào
B. Hành vi kích hoạt email
C. Hết hạn và xác thực mã thông báo
D. Đặt lại UX biểu mẫu và xác thực
E. Vỏ cạnh bảo mật

→ Bạn chọn C, và nó mở rộng:

toán học
Sao chépSửa đổi
C.i. Tạo và độ dài mã thông báo
C.ii. Thời gian hết hạn mã thông báo
C.iii. Xác nhận sử dụng một lần
C.iv. Xử lý token hết hạn
C.v. Mã thông báo không hợp lệ hoặc bị giả mạo

✅ Ca sử dụng 4: Lập kế hoạch ngăn xếp tự động hóa thử nghiệm

đầu vào:

Phác thảo kiến ​​trúc tự động hóa cho ứng dụng web/di động kết hợp.

GPT có thể quay trở lại:

toán học
Sao chépSửa đổi
A. Lựa chọn khung
B. Chiến lược lớp thử nghiệm
C. Tích hợp CI/CD
D. Quản lý dữ liệu và môi trường thử nghiệm
E. Báo cáo và phân tích

🧰 Lời nhắc hệ thống tùy chọn cho Chế độ mở rộng liên tục

Từ giờ trở đi, hãy hoạt động như một công cụ mở rộng phác thảo QA.

Mỗi lần tôi giao cho bạn một chủ đề, hãy tạo một dàn ý có cấu trúc.

Chờ mình chọn viên đạn để mở rộng.

Lặp lại quá trình đệ quy.

Luôn hỏi: “Tiếp theo bạn muốn tôi phác thảo điều gì?”

Tip 12 – Mẫu—Menu Action

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Bất cứ khi nào tôi gõ: X, bạn sẽ làm Y.
  • (Tùy chọn, cung cấp thêm các mục menu) Bất cứ khi nào tôi gõ Z, bạn sẽ làm Q.
  • Cuối cùng, bạn sẽ yêu cầu tôi hành động tiếp theo.

Bạn sẽ cần thay thế “X” bằng một mẫu thích hợp, chẳng hạn như “ước tính <THỜI GIAN NHIỆM VỤ>” hoặc “thêm THỰC PHẨM”. Sau đó, bạn sẽ cần chỉ định một hành động để kích hoạt mục menu, chẳng hạn như “thêm THỰC PHẨM vào danh sách mua sắm của tôi và cập nhật hóa đơn hàng tạp hóa ước tính của tôi”.

Ví dụ:

  • Bất cứ khi nào tôi gõ: “thêm THỰC PHẨM”, bạn sẽ thêm THỰC PHẨM vào danh sách hàng tạp hóa của tôi và cập nhật hóa đơn hàng tạp hóa ước tính của tôi. Bất cứ khi nào tôi gõ “xóa THỰC PHẨM”, bạn sẽ xóa THỰC PHẨM khỏi danh sách hàng tạp hóa của tôi và cập nhật hóa đơn hàng tạp hóa ước tính của tôi. Bất cứ khi nào tôi gõ “tiết kiệm”, bạn sẽ liệt kê các lựa chọn thay thế cho THỰC PHẨM đã thêm của tôi để tiết kiệm tiền. Cuối cùng, bạn sẽ yêu cầu tôi hành động tiếp theo. Hãy hỏi tôi về hành động đầu tiên.

🧪 Mẫu Menu Actions – Điều chỉnh dành riêng cho QA

🔧 Định dạng nhắc nhở cốt lõi (Phiên bản QA)

Bất cứ khi nào tôi gõ: X, bạn sẽ làm Y.

(Không bắt buộc:) Bất cứ khi nào tôi gõ: Z, bạn sẽ làm Q.

Vào cuối mỗi hành động, hỏi tôi lệnh tiếp theo.

Hãy hỏi tôi lệnh đầu tiên để bắt đầu.

🧪 Ví dụ về lời nhắc dành riêng cho QA

Bất cứ khi nào tôi gõ: thêm TEST CASE, bạn sẽ hỏi tôi về kịch bản và tạo một trường hợp kiểm thử có cấu trúc ở định dạng bảng.

Bất cứ khi nào tôi gõ: xem lại LỖI, bạn sẽ yêu cầu tôi mô tả lỗi và định dạng nó thành một báo cáo lỗi có cấu trúc.

Bất cứ khi nào tôi gõ: phân tích THẤT BẠI, bạn sẽ yêu cầu nhật ký lỗi và đề xuất các nguyên nhân gốc rễ có thể xảy ra.

Bất cứ khi nào tôi gõ: xây dựng DANH SÁCH KIỂM TRA, bạn sẽ yêu cầu một tính năng hoặc quy trình làm việc và tạo danh sách kiểm tra QA.

Bất cứ khi nào tôi gõ: tạo DỮ LIỆU KIỂM TRA, bạn sẽ yêu cầu các trường dữ liệu và trả về một tập dữ liệu thử nghiệm nhỏ, hợp lệ ở định dạng JSON hoặc bảng.

Bất cứ khi nào tôi gõ: lưu TÓM TẮT, bạn sẽ tóm tắt phiên này cho đến nay, bao gồm tất cả các trường hợp kiểm thử, lỗi, lỗi và danh sách kiểm tra.

Sau mỗi hành động, bạn sẽ hỏi tôi: “What would you like to do next?”

Hãy hỏi tôi lệnh đầu tiên để bắt đầu.

🧪 Ví dụ về tương tác của người dùng (Khi mẫu được kích hoạt)

Người dùng: thêm TRƯỜNG HỢP THỬ NGHIỆM

GPT: Tuyệt vời! Vui lòng mô tả kịch bản hoặc câu chuyện của người dùng mà bạn muốn có trường hợp thử nghiệm.

Người dùng: xem lại LỖI

GPT: Vui lòng dán mô tả lỗi hoặc ghi chú sao chép và tôi sẽ định dạng nó thành báo cáo lỗi có cấu trúc.

Người dùng: lưu TÓM TẮT

GPT: Dưới đây là bản tóm tắt mọi thứ bạn đã làm cho đến nay:

  • 3 trường hợp thử nghiệm
  • 1 Báo cáo lỗi
  • 1 Danh sách kiểm tra Bạn muốn xuất hay tiếp tục? → Bạn muốn làm gì tiếp theo?

🧰 Phần thưởng: Menu QA tùy chỉnh làm tài liệu tham khảo

sql
Sao chépSửa đổi
Menu Actions:
- thêm TEST CASE → Tạo test case từ kịch bản
- xem lại BUG → Định dạng và phân loại mô tả lỗi
- phân tích THẤT BẠI → Điều tra nhật ký kiểm tra
- xây dựng DANH SÁCH KIỂM TRA → Tạo danh sách kiểm tra từ tính năng hoặc quy trình
- tạo DỮ LIỆU KIỂM TRA → Tạo dữ liệu kiểm tra dưới dạng JSON/bảng
- lưu TÓM TẮT → Tóm tắt hoạt động của phiên
Tip 13 – Mẫu—Fact check list

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Tạo một tập hợp các sự kiện có trong đầu ra
  • Tập hợp các sự kiện nên được chèn vào POSITION trong đầu ra
  • Tập hợp các sự kiện phải là các sự kiện cơ bản có thể làm suy yếu tính xác thực của kết quả đầu ra nếu bất kỳ dữ kiện nào trong số đó không chính xác

Bạn sẽ cần thay thế POSITION bằng một vị trí thích hợp để đưa thông tin thực tế vào, chẳng hạn như “ở cuối kết quả”.

Ví dụ:

  • Bất cứ khi nào bạn xuất văn bản, hãy tạo một tập hợp các sự kiện có trong kết quả đầu ra. Tập hợp các sự kiện nên được chèn vào cuối đầu ra. Tập hợp các sự kiện phải là các sự kiện cơ bản có thể làm giảm tính xác thực của kết quả đầu ra nếu bất kỳ dữ liệu nào trong số đó không chính xác.

🧪 Mẫu danh sách kiểm tra thực tế - Điều chỉnh dành riêng cho QA

🔧 Định dạng nhắc nhở cốt lõi (Phiên bản QA)

Bất cứ khi nào bạn tạo phản hồi liên quan đến QA (ví dụ: trường hợp thử nghiệm, phân tích lỗi, chiến lược), hãy tạo danh sách kiểm tra tính xác thực.

Danh sách kiểm tra thực tế nên được chèn vào ở cuối đầu ra.

Sự thật nên thể hiện giả định hoặc đầu vào chính rằng, nếu không đúng, sẽ làm suy yếu tính hợp lệ của sự phản hồi.

🧪 Ví dụ về lời nhắc dành riêng cho QA

Khi bạn xuất các trường hợp kiểm thử, hãy tạo danh sách kiểm tra tính xác thực ở cuối.

Danh sách kiểm tra thực tế phải bao gồm mọi giả định về:

  • Quy tắc xác thực trường
  • Hành vi tính năng
  • Hạn chế đầu vào
  • Vai trò hoặc trạng thái của người dùng
  • Expected system behavior These facts must be true for the test cases to be valid. If any are incorrect, the test suite may be misleading or flawed.

🧪 Trường hợp sử dụng mẫu

✅ Lời nhắc của người dùng:

Tạo các trường hợp thử nghiệm cho tính năng đặt lại mật khẩu sử dụng liên kết xác minh dựa trên email.

✅ Đầu ra GPT:

Các trường hợp thử nghiệm:

pssql
Sao chépSửa đổi
1. Liên kết đặt lại mật khẩu kích hoạt email hợp lệ
2. Email không hợp lệ hiển thị thông báo lỗi
3. Token hết hạn trả về thông báo “Liên kết đã hết hạn”
4. Đặt lại mật khẩu thành công cho phép đăng nhập bằng thông tin đăng nhập mới

✅ Danh sách kiểm tra thực tế (Thêm vào cuối):

  • Hệ thống sử dụng email làm phương pháp chính để đặt lại mật khẩu.
  • Liên kết đặt lại sẽ hết hạn sau một khoảng thời gian đã đặt (ví dụ: 15 phút).
  • Hệ thống ngăn chặn việc sử dụng lại mã thông báo đặt lại mật khẩu.
  • Người dùng phải được đăng ký và xác minh trước khi bắt đầu thiết lập lại.
  • Đăng nhập bị chặn cho đến khi quá trình thiết lập lại hoàn tất.

🧰 Các kịch bản QA bổ sung sử dụng mẫu này

✅ Trình phân tích báo cáo lỗi

Khi bạn tóm tắt một lỗi, hãy chèn danh sách kiểm tra tính xác thực làm nổi bật các sự kiện quan trọng được đưa ra trong chẩn đoán của bạn (ví dụ: môi trường, điều kiện tái tạo, nhật ký lỗi).

✅ Khuyến nghị chiến lược

Khi bạn đề xuất chiến lược QA, hãy bao gồm danh sách kiểm tra tính xác thực về các hạn chế của dự án, quy mô nhóm, nhịp chạy nước rút và mức độ sẵn sàng tự động hóa.

Những sự thật này phải đúng đối với chiến lược áp dụng.

✅ Chẩn đoán lỗi

Khi phân tích một bài kiểm tra không ổn định, hãy thêm danh sách kiểm tra tính xác thực của các giả định, chẳng hạn như:

  • Độ ổn định của bộ chọn
  • Kiểm tra tính nhất quán của dữ liệu
  • Độ ổn định của mạng
  • cấu hình CI

🧰 Hướng dẫn tùy chọn để sử dụng liên tục

Từ giờ trở đi, sau mỗi phản hồi liên quan đến QA, hãy tự động đưa Danh sách kiểm tra tính xác thực vào cuối.

Danh sách 3–5 giả định cốt lõi rằng, nếu không chính xác, sẽ làm ảnh hưởng đến tính hợp lệ của đầu ra.

Tip 14 – Mẫu—Tail Generation

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Cuối cùng, hãy lặp lại Y và/hoặc hỏi tôi X.

Bạn sẽ cần thay thế “Y” bằng nội dung mà mô hình sẽ lặp lại, chẳng hạn như “lặp lại danh sách tùy chọn của tôi” và X bằng nội dung mà mô hình sẽ yêu cầu, “cho hành động tiếp theo”. Những câu lệnh này thường phải ở cuối dấu nhắc hoặc bên cạnh cuối cùng.

Ví dụ:

  • Hoạt động như một trình mở rộng phác thảo. Tạo một phác thảo về dấu đầu dòng dựa trên thông tin đầu vào mà tôi cung cấp cho bạn, sau đó hỏi tôi về điểm đầu dòng nào bạn nên mở rộng. Tạo một dàn ý mới cho điểm đầu dòng mà tôi chọn. Cuối cùng, hãy hỏi tôi điểm đầu dòng nào cần mở rộng tiếp theo. Hỏi tôi nên phác thảo những gì.
  • Từ giờ trở đi, ở cuối kết quả đầu ra của bạn, hãy thêm tuyên bố từ chối trách nhiệm "Đầu ra này được tạo bởi một mô hình ngôn ngữ lớn và có thể chứa lỗi hoặc tuyên bố không chính xác. Tất cả các tuyên bố phải được kiểm tra tính xác thực." Hãy hỏi tôi về điều đầu tiên để viết về.

🧪 Tail Generation Mẫu – Điều chỉnh dành riêng cho QA

🔧 Định dạng nhắc nhở cốt lõi (Phiên bản QA)

Khi kết thúc phần đầu ra, hãy lặp lại Y và/hoặc hỏi tôi X.

Thay thế Y với nội dung nào đó cần được nhắc lại (ví dụ: danh sách kiểm tra, định dạng dữ liệu thử nghiệm, danh sách hành động).

Thay thế X với hành động tiếp theo người dùng nên lấy hoặc cung cấp.

🧪 Ví dụ về lời nhắc dành riêng cho QA

✅ 1. Trình tạo trường hợp thử nghiệm với lời nhắc tiếp tục

Prompt:

Bạn sẽ tạo một bảng gồm các trường hợp kiểm thử có cấu trúc dựa trên thông tin đầu vào của tôi.

Cuối cùng, hãy hỏi tôi tính năng hoặc kịch bản nào để tạo trường hợp thử nghiệm tiếp theo.

Đuôi:

➤ Bạn muốn tôi tạo trường hợp thử nghiệm nào cho tính năng hoặc kịch bản tiếp theo?

✅ 2. Hỗ trợ phân loại lỗi với lời nhắc tóm tắt

Prompt:

Từ giờ trở đi, khi bạn phân tích một báo cáo lỗi, hãy kết thúc đầu ra bằng bản tóm tắt các trường chính: Mức độ nghiêm trọng, Khả năng tái tạo, Mô-đun bị ảnh hưởng.

Sau đó, yêu cầu tôi xem xét lỗi tiếp theo.

Đuôi:

Tóm tắt: Mức độ nghiêm trọng = Cao, Khả năng tái tạo = 100%, Mô-đun bị ảnh hưởng = Kiểm tra giỏ hàng

➤ Vui lòng gửi lỗi tiếp theo để phân loại.

✅ 3. Trình tạo chiến lược QA với Trình theo dõi tiến độ

Prompt:

Xây dựng phác thảo chiến lược QA dựa trên ý kiến ​​đóng góp của tôi. Ở cuối mỗi đầu ra, hãy lặp lại danh sách các phần đã hoàn thành hiện tại và hỏi tôi nên mở rộng phần nào tiếp theo.

Đuôi:

Các phần đã hoàn thành:

  • Mục tiêu thử nghiệm
  • Risk-Based Prioritization ➤ What section would you like to expand next?

✅ 4. Trình phân tích nhật ký với lời nhắc thực tế

Prompt:

Khi bạn phân tích nhật ký kiểm tra hoặc lỗi CI, hãy đưa vào danh sách kiểm tra thực tế ngắn gọn các giả định.

Cuối cùng, hãy hỏi tôi nhật ký tiếp theo hoặc không phân tích được.

Đuôi:

Kiểm tra thực tế:

  • Giả sử Chrome 120+
  • Network latency not exceeding 300ms ➤ Please provide the next log or failure.

✅ 5. Huấn luyện cải tiến nhanh chóng với đề xuất tái sử dụng

Prompt:

Bạn sẽ giúp tôi cải thiện lời nhắc tạo thử nghiệm của mình.

Vào cuối mỗi lần sửa đổi, lặp lại lời nhắc đã cải thiện và hỏi tôi xem tôi có muốn sử dụng lại nó, sửa đổi thêm hay thử một cái mới không.

Đuôi:

Lời nhắc được đề xuất: “Tạo 5 trường hợp kiểm tra ranh giới cho trường số điện thoại với các ràng buộc về số và độ dài.”

➤ Bạn muốn sử dụng lại, sửa lại hay bắt đầu một cái mới?

🧰 Hướng dẫn hệ thống tùy chọn để sử dụng liên tục

Từ giờ trở đi, khi kết thúc kết quả đầu ra liên quan đến QA của bạn, hãy tóm tắt những bài học chính (Y) và hỏi xem tôi muốn làm gì tiếp theo (X).

Luôn bao gồm điểm tiếp tục hoặc điểm quyết định rõ ràng.

Tip 15 – Mẫu—Semantic Filter

Để sử dụng mẫu này, lời nhắc của bạn phải đưa ra các câu lệnh ngữ cảnh cơ bản sau:

  • Lọc thông tin này để loại bỏ X

Bạn sẽ cần thay thế “X” bằng định nghĩa thích hợp về nội dung bạn muốn xóa, chẳng hạn như. “tên và ngày tháng” hoặc “giá lớn hơn 100 USD”.

Ví dụ:

  • Lọc thông tin này để xóa mọi thông tin nhận dạng cá nhân hoặc thông tin có thể được sử dụng để nhận dạng lại người đó.
  • Lọc email này để loại bỏ thông tin dư thừa.

🧪 Semantic Filter Mẫu – Điều chỉnh dành riêng cho QA

🔧 Định dạng nhắc nhở cốt lõi (Phiên bản QA)

Lọc thông tin này để xóa X, trong đó X là danh mục dành riêng cho QA như:

  • Tiếng ồn gỡ lỗi nội bộ
  • Các bước kiểm tra dư thừa
  • Dữ liệu nhận dạng cá nhân trong nhật ký
  • Các trường hợp kiểm thử không có chức năng hoặc không liên quan
  • Các vấn đề có mức độ ưu tiên thấp từ danh sách lỗi

🧪 Ví dụ về lời nhắc dành riêng cho QA

✅ 1. Làm sạch các bước kiểm tra

Prompt:

Lọc trường hợp kiểm thử này để loại bỏ các bước giao diện người dùng dư thừa hoặc rõ ràng (ví dụ: “nhấp vào trường”, “di chuyển chuột”).

Chỉ giữ lại các hành động kiểm tra cần thiết phản ánh các thay đổi về logic hoặc trạng thái.

✅ 2. Vệ sinh báo cáo lỗi

Prompt:

Lọc báo cáo lỗi này để loại bỏ thuật ngữ dành riêng cho nhà phát triển và điều chỉnh lại thuật ngữ đó cho một nhóm đa chức năng.

Loại bỏ các nhận xét nội bộ hoặc ghi chú gỡ lỗi không cần thiết.

✅ 3. Trình dọn dẹp tệp nhật ký

Prompt:

Lọc tệp nhật ký này để xóa các tin nhắn lặp lại, nhật ký INFO không liên quan và mọi dấu thời gian.

Chỉ giữ lại các dấu vết CẢNH BÁO, LỖI hoặc ngăn xếp liên quan đến lỗi.

✅ 4. Bộ thử nghiệm mỏng hơn

Prompt:

Lọc bộ thử nghiệm này để loại bỏ các trường hợp thử nghiệm có giá trị thấp hoặc trùng lặp.

Chỉ giữ lại các trường hợp duy nhất kiểm tra một điều kiện hoặc đường dẫn riêng biệt.

✅ 5. Loại bỏ PII đối với ảnh chụp màn hình hoặc nhật ký QA

Prompt:

Lọc dữ liệu thử nghiệm này để xóa mọi thông tin nhận dạng cá nhân (PII) như tên người dùng, email, số điện thoại hoặc địa chỉ IP.

✅ 6. Công cụ tinh chỉnh phân tích lỗi

Prompt:

Lọc phân tích lỗi này để loại bỏ những phỏng đoán hoặc ngôn ngữ suy đoán.

Chỉ giữ lại những quan sát dựa trên bằng chứng từ nhật ký hoặc các tạo phẩm thử nghiệm.

✅ 7. Đơn giản hóa danh sách kiểm tra

Prompt:

Lọc danh sách kiểm tra QA này để loại bỏ mọi mục hoặc nhiệm vụ không thể thực hiện được nằm ngoài phạm vi dự án.

✅ 8. Trình ánh xạ phạm vi câu chuyện người dùng

Prompt:

Lọc danh sách các trường hợp thử nghiệm này để loại bỏ những trường hợp không theo dõi trực tiếp câu chuyện của người dùng hoặc tiêu chí chấp nhận.

🧰 Hướng dẫn liên tục tùy chọn để sử dụng QA

Từ giờ trở đi, khi tôi cung cấp nội dung liên quan đến QA (trường hợp thử nghiệm, nhật ký, báo cáo lỗi),

  • Hỏi tôi xem tôi có muốn không lọc bất cứ điều gì.
  • Nếu có, hãy hỏi: “Bạn muốn tôi lọc ra cái gì?”
  • Sau đó áp dụng Mẫu Semantic Filter để làm sạch nội dung cho phù hợp.
Tip 16 – Các mẫu—Google’s Gemini

*Thẩm quyền giải quyết: https://ai.google.dev/gemini-api/docs/prompting-strategies*

GEMINI Chung Prompt Patterns cho LLMs

1. Mẫu nhân vật QA

Ý định: Đặt LLM hành động trong vai trò phù hợp với bối cảnh QA - ví dụ: kỹ sư tự động hóa thử nghiệm cấp cao, người kiểm tra bảo mật, chuyên gia UX QA - để nó cung cấp thông tin chi tiết phù hợp với tính cách đó.

Kết cấu:

Hoạt động như một [vai trò/nhân cách QA]. [Nhiệm vụ/câu hỏi của bạn].

Ví dụ:

  • “Act as a senior test automation engineer. Design Selenium test cases for the login flow of an e-commerce site.”
  • “As a performance tester, explain how you’d identify and address bottlenecks in an API handling 10k requests per second.”
  • “You are a strict accessibility auditor. Review the following webpage HTML for WCAG compliance.”

2. Mẫu hướng dẫn/ràng buộc cho QA

Ý định: Xác định các yêu cầu kiểm tra chính xác, giới hạn phạm vi hoặc định dạng đầu ra để phản hồi phù hợp với tiêu chuẩn tài liệu QA.

Kết cấu:

Sử dụng các từ khóa như “Only,” “Ensure,” “Must,” hoặc “Format as”. Sử dụng dấu phân cách cho rõ ràng.

Ví dụ:

  • “List exactly 5 high-priority test cases for checkout functionality. Each must include Preconditions, Steps, Expected Results, and Priority.”
  • “Hướng dẫn:
    1. Phân tích báo cáo lỗi đã cho để đảm bảo tính đầy đủ.
    2. Xác định các chi tiết còn thiếu dựa trên các phương pháp hay nhất về QA.
    3. Đề xuất cải tiến. Báo cáo lỗi: Hình thức thanh toán không hoạt động trên thiết bị di động.“

3. Mô hình chuỗi suy nghĩ (CoT) QA

Ý định: Đảm bảo lý luận từng bước trong thiết kế thử nghiệm, chẩn đoán lỗi hoặc phân tích phạm vi bảo hiểm.

Kết cấu:

Sử dụng lời nhắc như “Let’s think step by step” hoặc “Explain your reasoning.”

Ví dụ:

  • “Identify potential causes for intermittent API failures. Let’s think step by step starting from server logs, then network, then code changes.”
  • “Design regression tests for a new search feature. Work through functional, negative, and performance aspects systematically.”

4. Nhắc nhở QA một lần/một lần

Ý định: Cung cấp các trường hợp thử nghiệm mẫu, báo cáo lỗi hoặc đầu ra QA để LLM tuân theo cùng một kiểu.

Kết cấu:

“Here are examples: [Example Input → Example Output]… Now do this: [New Input].”

Ví dụ:

  • Ví dụ: đầu vào: "Tìm kiếm 'giày' trong ứng dụng di động" → Đầu ra: "Xác minh tìm kiếm trả về kết quả có liên quan trong vòng 2 giây. Dự kiến: 10 mục phù hợp nhất được hiển thị." Hiện nay: "Tìm kiếm 'mũ' trong ứng dụng máy tính để bàn"
  • “Here’s a formatted bug report. Now generate one for the following defect: checkout button unresponsive on Safari.”

5. Mẫu sàng lọc câu hỏi QA

Ý định: Cải thiện độ rõ ràng của các câu hỏi liên quan đến QA để có được câu trả lời tốt hơn, có mục tiêu hơn.

Kết cấu:

“Whenever I ask a QA question, suggest a more specific version that includes scope, environment, and expected outcome.”

Ví dụ:

  • “How do I test a login page?” → “Do you want functional, security, performance, or usability testing? Which browsers and devices should be included?”
  • “What’s the best way to write test cases?” → “Are you writing for manual testers, automation scripts, or both? Which framework?”

6. Audience Persona Mẫu dành cho QA

Ý định: Điều chỉnh phần giải thích tùy thuộc vào việc đối tượng là nhà phát triển, chủ sở hữu sản phẩm, thực tập sinh QA hay người dùng cuối.

Kết cấu:

“Explain [QA concept] as if I am [audience type/level].”

Ví dụ:

  • “Explain API mocking to me as if I’m a junior QA intern with no coding background.”
  • “Describe the value of regression testing to a non-technical product owner.”

7. Mẫu phản chiếu/tự sửa cho QA

Ý định: Xem xét và cải thiện các trường hợp thử nghiệm, báo cáo lỗi hoặc tài liệu QA để đảm bảo tính đầy đủ và chính xác.

Kết cấu:

“Review the following [test case/bug report] and [critique/improve/suggest fixes] based on QA best practices.”

Ví dụ:

  • “Review these test cases for coverage gaps and missing edge cases: [cases]”
  • “Check this bug report for reproducibility and clarity, then rewrite it for better developer understanding.”

8. Semantic Filter Mẫu dành cho QA

Ý định: Chỉ trích xuất thông tin QA có liên quan từ nhật ký, thông số kỹ thuật hoặc báo cáo.

Kết cấu:

“From the following, extract all [QA-specific info] and format as [X].”

Ví dụ:

  • “From these server logs, extract all error codes and their timestamps.”
  • “From the release notes, list only the features that require regression testing.”

9. Meta Language Mẫu tạo cho QA

Ý định: Xác định tốc ký cho các yêu cầu QA phức tạp để tiết kiệm thời gian trong các cuộc hội thoại lặp đi lặp lại.

Kết cấu:

“When I say ‘[X]’, I mean ‘[Full QA instruction]’.”

Ví dụ:

  • “When I say ‘GEN-BUG’, create a complete bug report template filled in with my notes.”
  • “Whenever I type ‘COV-MATRIX’, generate a test coverage matrix for the given feature set.”

10. Kịch bản/Mẫu mô phỏng cho QA

Ý định: Mô phỏng thử nghiệm QA trong thế giới thực, các cuộc họp phân loại lỗi hoặc các phiên thử nghiệm khám phá.

Kết cấu:

“Let’s simulate [scenario]. You are [role], I am [role]. [Start scenario].”

Ví dụ:

  • “Let’s simulate a defect triage meeting. You are the QA lead, I am the developer. Here’s the first bug: login form fails on Edge browser.”
  • “Pretend you are a tester running exploratory tests on a new chat app. Report any issues you encounter.”
Tip 17 – Áp dụng mẫu vào Testing & QA

Đây là danh sách có tác động cao mẫu nhắc nhở bạn nên cân nhắc sử dụng — đặc biệt là cho công việc học tập và ứng dụng AI trong Testing & QA. I’ve grouped them by mục đích để bạn có thể trộn, kết hợp và dạy chúng một cách có chủ ý.

(Xem ví dụ về Xây dựng mẫu GPT ứng dụng)

🔁 Prompt Refinement & Clarification Patterns

Mẫu Mục đích
Cognitive Verifier Chia nhỏ những lời nhắc mơ hồ thành các câu hỏi phụ để có câu trả lời tốt hơn
Trình ghi lại lời nhắc Đề xuất các phiên bản cải tiến của lời nhắc người dùng để đảm bảo tính rõ ràng, cụ thể và cấu trúc
Audience Persona Điều chỉnh phản hồi cho phù hợp với các vai trò cụ thể (người kiểm tra, nhà phát triển, PM, trợ lý AI)
Vòng làm rõ GPT đặt câu hỏi tiếp theo trước khi trả lời
Trình gỡ lỗi nhắc nhở GPT giải thích lý do lời nhắc không mang lại kết quả tốt và cách khắc phục

🧪 Các mẫu tạo trường hợp thử nghiệm

Mẫu Mục đích
Vai trò-Nhiệm vụ-Định dạng (RTF) Đặt vai trò trợ lý, xác định nhiệm vụ QA và chỉ định định dạng đầu ra
Phạm vi kịch bản Mở rộng câu chuyện hoặc tính năng của người dùng thành nhiều danh mục thử nghiệm (tích cực, tiêu cực, cạnh)
Trình tạo ma trận thử nghiệm Tổ chức các trường hợp thử nghiệm theo các chiều (ví dụ: nền tảng, trình duyệt, vai trò người dùng)
Mở rộng kiểm tra tham số Thực hiện một bài kiểm tra và tạo các hoán vị dựa trên các tham số đầu vào
Gherkin Trình định dạng Buộc đầu ra ở định dạng Cho trước–Khi–Sau đó cho BDD

🛠️ Diagnostic & Planning Patterns

Mẫu Mục đích
Trình khám phá nguyên nhân gốc rễ GPT đặt câu hỏi để điều tra các thử nghiệm không ổn định, lỗi hoặc sự cố hệ thống
Trình phân tích mẫu lỗi GPT tóm tắt các mẫu từ nhiều nhật ký kiểm tra hoặc báo cáo lỗi
Huấn luyện viên chiến lược QA Xây dựng hoặc phê bình cách tiếp cận QA dựa trên các ràng buộc, công cụ hoặc nhu cầu bảo hiểm
Bộ lọc dựa trên rủi ro Ưu tiên các trường hợp thử nghiệm hoặc mô-đun dựa trên tác động kinh doanh và sự biến động của thay đổi

📦 Các mẫu thực thi đầu ra có cấu trúc

Mẫu Mục đích
Trình thực thi mẫu Buộc đầu ra phải khớp với định dạng nghiêm ngặt (bảng, JSON, YAML, v.v.)
Trình tạo nhận biết lược đồ GPT sử dụng lược đồ đầu ra được xác định trước để xác thực việc tuân thủ định dạng
Định dạng hướng dẫn đầu tiên Nhúng quy tắc đầu ra trực tiếp vào hệ thống hoặc lời nhắc của người dùng về dữ liệu thử nghiệm, kế hoạch thử nghiệm, v.v.

🧠 Các mẫu trợ lý tư duy

Mẫu Mục đích
Chuỗi suy nghĩ Buộc GPT hiển thị lý do từng bước trước khi trả lời
Nhắc nhở ít lần bắn Bao gồm các đầu vào/đầu ra mẫu trước đầu vào của người dùng mới
CoT không bắn Đưa ra lý do ngay cả khi chỉ đưa ra một lời nhắc để cải thiện các quyết định về QA
So sánh và quyết định GPT tạo ra nhiều tùy chọn và chọn hoặc giải thích tùy chọn tốt nhất
Suy ngẫm và sửa đổi GPT phê bình kết quả trước đó của chính mình và cung cấp phiên bản sửa đổi

🧩 Các mẫu tùy chỉnh nhận biết kiểm tra (Học/Dạy/Tự kiểm tra)

Mẫu Mục đích
Trình tổng hợp báo cáo lỗi Biến thông tin lỗi dạng tự do thành các mẫu lỗi có cấu trúc
Kiểm tra máy phát điện Oracle Tạo kết quả mong đợi cho các đầu vào thử nghiệm nhất định (đặc biệt là thử nghiệm AI)
Trình dịch Spec-to-Test Chuyển đổi các yêu cầu thành các trường hợp thử nghiệm bằng cách sử dụng logic có thể theo dõi
Mã định danh khoảng trống kiểm tra Identifies what’s missing from a current test set based on inputs or past defects

Dưới đây là những ví dụ:

1. Cognitive Verifier

Ví dụ:

Người dùng: Tạo các trường hợp thử nghiệm cho mô-đun thanh toán.

GPT: Loại thanh toán nào (thẻ tín dụng, chuyển khoản ngân hàng)? Đó là web hay di động? Tôi có nên đưa vào các trường hợp đặc biệt như thẻ hết hạn không?

Sau đó, tạo các trường hợp thử nghiệm có căn cứ dựa trên câu trả lời của bạn.

2. Trình ghi lại lời nhắc

Ví dụ:

Người dùng: Viết các trường hợp thử nghiệm.

GPT: Would you like a refined version? → “Write 5 boundary value test cases for a login form with email and password inputs.”

3. Audience Persona

Ví dụ:

Người dùng: Giải thích phạm vi kiểm tra.

GPT: Điều này dành cho ai - nhà phát triển, PM, người thử nghiệm cấp dưới?

Sau đó điều chỉnh phản hồi dựa trên vai trò.

4. Vòng làm rõ

Ví dụ:

Người dùng: Tạo dữ liệu thử nghiệm.

GPT: Dành cho loại trường nào? Có hạn chế nào không (ví dụ: phạm vi ngày, định dạng)?

Sau đó tiến hành tạo thế hệ cụ thể.

5. Trình gỡ lỗi nhanh chóng

Ví dụ:

Người dùng: Tại sao lời nhắc này đưa ra các trường hợp kiểm thử xấu?

GPT: Giải thích ngay sự mơ hồ và đề xuất một phiên bản rõ ràng hơn (ví dụ: thiếu nhân vật, định dạng hoặc tạo tác).

6. Định dạng vai trò-nhiệm vụ (RTF)

Ví dụ:

Đóng vai trò là Kỹ sư tự động hóa thử nghiệm.

Tạo các trường hợp thử nghiệm cho chức năng đăng nhập.

Hiển thị dưới dạng bảng có các cột: ID kiểm tra, Mô tả, Các bước, Kết quả mong đợi.

7. Phạm vi kịch bản

Ví dụ:

Người dùng: Tạo các trường hợp thử nghiệm để đặt lại mật khẩu.

GPT: Chia nó thành: trường hợp tích cực, trường hợp tiêu cực, điều kiện biên, hết hạn mã thông báo, xác thực API và luồng giao diện người dùng.

8. Trình tạo ma trận thử nghiệm

Ví dụ:

Người dùng: Xây dựng các kết hợp thử nghiệm để đăng nhập.

GPT: Xây dựng ma trận: hàng = điều kiện đầu vào, cột = nền tảng (Web, iOS, Android).

9. Mở rộng kiểm tra tham số

Ví dụ:

Người dùng: Mở rộng trường hợp thử nghiệm này trên các trình duyệt.

GPT: Tạo các phiên bản cho Chrome, Firefox, Edge, Safari bằng cách sử dụng cùng một logic kiểm tra.

10. Gherkin Trình định dạng

Ví dụ:

Người dùng: Tạo một trường hợp thử nghiệm để đăng nhập.

GPT: Kết quả đầu ra ở định dạng Cho trước–Khi–Sau đó.

11. Trình khám phá nguyên nhân gốc rễ

Ví dụ:

Người dùng: Kiểm tra giao diện người dùng của tôi liên tục thất bại một cách ngẫu nhiên.

GPT: Hỏi về tình trạng không ổn định, nhật ký, bộ chọn, sự cố mạng, v.v.

Sau đó thu hẹp các nguyên nhân gốc rễ có thể xảy ra.

12. Trình phân tích mẫu lỗi

Ví dụ:

Người dùng: Phân tích những thất bại thử nghiệm gần đây của tôi.

GPT: Tóm tắt các mẫu - ví dụ: 40% lỗi trong mô-đun xác thực, 25% từ bộ định vị không ổn định.

13. Huấn luyện viên chiến lược QA

Ví dụ:

Người dùng: Tôi sắp ra mắt một ứng dụng di động mới. Trợ giúp lập kế hoạch QA.

GPT: Hỏi về lịch phát hành, thiết bị, nhóm, mục tiêu phủ sóng.

Sau đó trả về một chiến lược phù hợp.

14. Bộ lọc dựa trên rủi ro

Ví dụ:

Người dùng: Ưu tiên các trường hợp thử nghiệm của tôi.

GPT: Áp dụng các bộ lọc dựa trên lịch sử thay đổi, tần suất sử dụng, lỗi trong quá khứ và mức độ nghiêm trọng.

15. Trình thực thi mẫu

Ví dụ:

Người dùng: Các trường hợp thử nghiệm đầu ra.

GPT: Phản hồi chỉ bằng cách sử dụng định dạng bảng được xác định trước.

16. Trình tạo nhận biết lược đồ

Ví dụ:

Người dùng: Tạo dữ liệu thử nghiệm JSON.

GPT: Xác thực đầu ra dựa trên lược đồ và chỉ tạo ra kết quả tuân thủ.

17. Định dạng hướng dẫn đầu tiên

Ví dụ:

Lời nhắc của hệ thống: Luôn trả lại các trường hợp kiểm thử vào Gherkin.

Người dùng: Viết bài kiểm tra để đặt lại mật khẩu.

GPT: Tự động sử dụng định dạng Cho trước–Khi–Sau đó.

18. Chuỗi suy nghĩ (CoT)

Ví dụ:

Người dùng: Tại sao thử nghiệm này thất bại?

GPT: Suy nghĩ từng bước: đầu vào → môi trường → thực thi → kết quả → kết luận.

19. Nhắc nhở ít lần bắn

Ví dụ:

Người dùng: Đây là hai trường hợp thử nghiệm. Tạo nhiều hơn theo cùng một phong cách.

GPT: Tuân theo định dạng và cấu trúc để có kết quả đầu ra nhất quán.

20. CoT không bắn

Ví dụ:

Người dùng: Điều gì có thể gây ra thử nghiệm không ổn định này?

GPT: Suy nghĩ thông qua ba nguyên nhân ngay cả khi không có ví dụ trước đó.

21. So sánh và quyết định

Ví dụ:

Người dùng: Kế hoạch kiểm tra nào trong hai kế hoạch này tốt hơn?

GPT: So sánh và khuyến nghị bằng lý luận.

22. Suy ngẫm và sửa đổi

Ví dụ:

Người dùng: Cải thiện bộ thử nghiệm này.

GPT: Phê bình phiên bản hiện tại và đề xuất sửa đổi.

23. Trình tổng hợp báo cáo lỗi

Ví dụ:

Người dùng: Here’s what I saw in the app…

GPT: Báo cáo lỗi có cấu trúc đầu ra: tiêu đề, các bước tái tạo, dự kiến ​​so với thực tế.

24. Kiểm tra máy phát điện Oracle

Ví dụ:

Người dùng: What’s the expected output for input X?

GPT: Tính toán và giải thích kết quả mong đợi một cách hợp lý.

25. Trình dịch Spec-to-Test

Ví dụ:

Người dùng: Here’s a requirement.

GPT: Chuyển đổi nó thành các trường hợp thử nghiệm có thể theo dõi được với ID và liên kết bảo hiểm.

26. Mã định danh khoảng cách kiểm tra

Ví dụ:

Người dùng: Đây là trường hợp thử nghiệm hiện tại của tôi.

GPT: Phân tích chúng và đề xuất các kịch bản còn thiếu dựa trên hoạt động của tính năng.

Muốn đây là hướng dẫn tham khảo có thể in được, tập lệnh demo trực tiếp hoặc để gắn thẻ chúng trong nhắc nhở CLI? Hãy cho tôi biết.

Tip 18 – Xây dựng Custom GPTs

A. Thông tin cơ bản: Cung cấp hướng dẫn có cấu trúc rõ ràng

Mục tiêu: Tìm hiểu cách thiết kế các hướng dẫn GPT tạo ra đầu ra QA nhất quán, chất lượng cao, giảm sự chuyển tiếp qua lại và sự mơ hồ.

Trước

Bạn là thành viên của nhóm QA chịu trách nhiệm trả lời các câu hỏi bằng cách sử dụng thông tin trong tài liệu Kế hoạch kiểm tra và Thông số kỹ thuật yêu cầu đính kèm. Mục tiêu của bạn là giảm đáng kể tần suất chỉ đạo các kỹ sư tiếp cận với các trưởng nhóm QA thông qua qa@shadeofhue.com, nhưng bạn sẽ hướng dẫn người dùng làm như vậy nếu không thể tìm thấy câu trả lời trong các tài liệu được cung cấp. Một số câu hỏi có thể liên quan đến các tiêu chuẩn ngành hoặc tài liệu tham khảo bên ngoài (ví dụ: yêu cầu về tài liệu kiểm tra ISO 29119, nguyên tắc kiểm tra bảo mật OWASP), vì vậy bạn cũng có thể sử dụng trình duyệt web để nhận được những câu trả lời đó.

Sau đó

***Context: Bạn là thành viên của nhóm QA. Đính kèm là các tài liệu Kế hoạch kiểm tra và Đặc tả yêu cầu.

***Hướng dẫn:

  • Nếu câu hỏi của người dùng được trả lời trong các tài liệu được cung cấp, hãy trả lời bằng thông tin đó.
  • Nếu câu hỏi của người dùng liên quan đến các tiêu chuẩn hoặc tài liệu tham khảo bên ngoài (ví dụ: ISO 29119, nguyên tắc kiểm tra OWASP), hãy sử dụng trình duyệt web để tìm thông tin chính xác, cập nhật.
  • Nếu câu hỏi của người dùng không thể được trả lời bằng các bước trên, hãy yêu cầu họ gửi email qa@shadeofhue.com.

Được tối ưu hóa để tạo & Ví dụ điều tra lỗi

***Context: Bạn là trợ lý tự động hóa QA. Đính kèm là Kế hoạch kiểm thử, Đặc tả yêu cầu và Nhật ký lỗi.

***Hướng dẫn:

  • Nếu yêu cầu liên quan đến việc tạo ra các ca kiểm thử, hãy rút ra chúng từ các yêu cầu, tiêu chí chấp nhận và các phần có liên quan của Kế hoạch kiểm thử.
  • Bao gồm các trường hợp tích cực, tiêu cực, ranh giới và cạnh, với các điều kiện tiên quyết, các bước và kết quả mong đợi rõ ràng.
  • Nếu yêu cầu liên quan đến việc điều tra lỗi, hãy phân tích Nhật ký lỗi để tìm các mẫu, tính năng bị ảnh hưởng và các bước tái tạo.
  • Khi cần, hãy tham khảo các tiêu chuẩn hoặc hướng dẫn QA bên ngoài (ví dụ: ISO 29119, OWASP, ISTQB) thông qua trình duyệt web để đảm bảo tính đầy đủ và chính xác.
  • Nếu thông tin bị thiếu hoặc mơ hồ, hãy nêu rõ các giả định của bạn và/hoặc yêu cầu làm rõ trước khi tiếp tục.
  • Nếu bạn không thể giải quyết yêu cầu bằng các bước trên, hãy hướng họ tới email qa@shadeofhue.com.

B. Xây dựng GPT của bạn—Tạo hướng dẫn có cấu trúc

1. Bối cảnh: Chỉ định vai trò, miền và mục đích mà GPT phải tuân theo để hoàn thành nhiệm vụ của mình.

2. Hướng dẫn: Hướng dẫn từng bước về chính xác những gì GPT nên làm và cách thức.

3. Dạng phản hồi: Chỉ định định dạng đầu ra (ví dụ: bảng đánh dấu, JSON, danh sách dấu đầu dòng).

4. Ví dụ (tùy chọn): Đưa ra mẫu đầu vào/đầu ra thực tế để có kết quả có thể dự đoán được.

Mẹo chuyên nghiệp: Thêm “xác nhận với người dùng sau mỗi bước” khi bạn muốn có phản hồi chi tiết, lặp lại.

Các phương pháp thực hành tốt: S.C.O.P.E.

  • S: Steps—Chia nhỏ chỉ dẫn, nhiệm vụ và quy trình thành luồng logic
  • C: **Bối cảnh—**Chỉ định vai trò, miền và mục đích mà LLM phải tuân theo để hoàn thành nhiệm vụ của mình.
  • O: Định dạng đầu ra—Chỉ định bảng, JSON, dấu đầu dòng, v.v.
  • P: nhân cách – Xác định giọng điệu, phong cách hoặc trình độ chuyên môn cho đối tượng mục tiêu
  • E: Ví dụ – Nhắc nhở vài lần bắn để đặt kỳ vọng

Những lời khuyên khác:

  • Sử dụng dấu phân cách (""", **, v.v.) để phân tách các đầu vào.
  • Bao gồm bối cảnh phong phú cho sự liên quan.
  • Chỉ định độ dài đầu ra hoặc mức độ chi tiết.
  • Luôn luôn giả định trạng thái khi dữ liệu không đầy đủ.

Ví dụ: Xây dựng GPT để tạo trường hợp thử nghiệm QA

Context:

Bạn là trợ lý tự động hóa QA. Vai trò của bạn là tạo ra các trường hợp thử nghiệm toàn diện, chất lượng cao dựa trên Kế hoạch thử nghiệm, Thông số kỹ thuật yêu cầu được cung cấp và mọi tiêu chí chấp nhận hoặc câu chuyện của người dùng đính kèm. Bạn phải tuân theo các phương pháp thực hành tốt nhất trong ngành và các tiêu chuẩn thử nghiệm có liên quan (ví dụ: ISTQB, ISO 29119, OWASP).

Hướng dẫn:

  • Phân tích tài liệu nguồn (yêu cầu, tiêu chí chấp nhận, các hiện vật liên quan).
  • Phát ra trường hợp thử nghiệm bao gồm:
    • Kịch bản tích cực
    • Kịch bản tiêu cực
    • Kiểm tra giá trị biên
    • Vỏ cạnh
    • Cân nhắc về bảo mật và hiệu suất nếu có
  • Mỗi trường hợp thử nghiệm phải bao gồm:
    • Mã kiểm tra
    • Điều kiện tiên quyết
    • Các bước kiểm tra (mỗi bước trên một dòng mới)
    • Kết quả mong đợi
  • Sử dụng các hướng dẫn trong [tệp Kiến thức đã tải lên] khi có thể.
  • Tham khảo các tiêu chuẩn liên quan nếu có.
  • Nếu thông tin bị thiếu hoặc mơ hồ, hãy nêu rõ các giả định hoặc yêu cầu làm rõ.

Định dạng phản hồi:

Mã kiểm tra Description Điều kiện tiên quyết Steps Expected Result Ghi chú

Ví dụ:

Lời yêu cầu:

Tạo các trường hợp thử nghiệm cho tính năng đăng nhập dựa trên các tiêu chí chấp nhận sau:

  • Tên người dùng và mật khẩu hợp lệ cho phép truy cập vào bảng điều khiển
  • Thông tin xác thực không hợp lệ hiển thị thông báo lỗi
  • Khóa tài khoản sau 5 lần thử không thành công

Phản ứng:

Mã kiểm tra Description Điều kiện tiên quyết Steps Expected Result Ghi chú
TC-001 Đăng nhập bằng thông tin xác thực hợp lệ Tài khoản người dùng tồn tại với tên người dùng/mật khẩu hợp lệ 1. Điều hướng đến trang đăng nhập2. Nhập tên người dùng/mật khẩu hợp lệ3. Nhấp vào “Đăng nhập” Người dùng được chuyển hướng đến trang tổng quan Xét nghiệm dương tính
TC-002 Đăng nhập với thông tin đăng nhập không hợp lệ Tài khoản người dùng tồn tại 1. Điều hướng đến trang đăng nhập2. Nhập tên người dùng/mật khẩu không hợp lệ3. Nhấp vào “Đăng nhập” Thông báo lỗi được hiển thị Xét nghiệm âm tính
TC-003 Khóa tài khoản sau 5 lần thử không thành công Tài khoản người dùng tồn tại 1. Điều hướng đến trang đăng nhập2. Nhập sai mật khẩu 5 lần3. Cố gắng đăng nhập lại Tài khoản bị khóa Kiểm tra an ninh

Thẩm quyền giải quyết:

https://academy.openai.com/home/videos/advanced-prompt-engineering-2025-02-13

Bài tập: Xây dựng GPT tùy chỉnh để tạo trường hợp thử nghiệm

Mục tiêu học tập

Đến cuối bài tập này, bạn sẽ:

  • Áp dụng S.C.O.P.E. khuôn khổ để tạo hướng dẫn GPT cho QA.
  • Tạo ra các trường hợp thử nghiệm có có cấu trúc, đầy đủ và nhất quán.
  • Xử lý sự mơ hồ một cách rõ ràng, giống như một kỹ sư QA chuyên nghiệp.

Hộp thời gian

  • 5 phút - Đọc kịch bản
  • 15 phút – Dự thảo S.C.O.P.E của bạn hướng dẫn
  • 15 phút – Run your GPT instructions & refine
  • 10 phút - Đánh giá đồng đẳng và hoàn thiện

Kịch bản (chọn một)

A) Login & Lockout

  • AC1: Tên người dùng + mật khẩu hợp lệ → chuyển hướng đến /bảng điều khiển.
  • AC2: Thông tin xác thực không hợp lệ → lỗi nội tuyến “Tên người dùng hoặc mật khẩu không hợp lệ.”
  • AC3: Sau 5 lần liên tiếp không thành công, tài khoản sẽ bị khóa trong 15 phút.
  • AC4: “Ghi nhớ tôi” duy trì phiên trong 7 ngày.

B) Cart & Checkout

  • AC1: Thêm/bớt các mục; số lượng 1–99.
  • AC2: Cập nhật tổng phụ ngay lập tức; thuế = 8,25%.
  • AC3: Mã khuyến mãi: TIẾT KIỆM10 (Giảm 10%, ≥ $50); một mã cho mỗi đơn hàng.
  • AC4: Sản phẩm hết hàng không thể tiến hành thanh toán.

C) Đặt lại mật khẩu

  • AC1: Liên kết đặt lại hết hạn sau 30 phút.
  • AC2: Chính sách mật khẩu: 8–64 ký tự, 1 chữ hoa, 1 chữ thường, 1 chữ số, 1 đặc biệt.
  • AC3: Biểu ngữ thành công: “Đã cập nhật mật khẩu.”
  • AC4: Điều tiết: tối đa 3 email đặt lại mỗi giờ cho mỗi người dùng.

Có thể bàn giao 1 — Của bạn S.C.O.P.E. Bộ hướng dẫn

S - Các bước

Chia nhỏ quy trình mà GPT phải tuân theo theo thứ tự hợp lý.

Ví dụ:

  1. Parse requirements & acceptance criteria.
  2. Xác định các kịch bản kiểm tra Tích cực, Tiêu cực, Ranh giới và Bảo mật.
  3. Viết từng trường hợp thử nghiệm kèm theo ID, Điều kiện tiên quyết, Các bước, Kết quả mong đợi và Ghi chú.
  4. Đánh dấu bất kỳ thông tin nào còn thiếu hoặc mơ hồ trong phần “Ghi chú” bằng [ĐÁNH GIÁ] thẻ.

C - Bối cảnh

Xác định vai trò, miền và phạm vi cho GPT.

Ví dụ:

Bạn là trợ lý tự động hóa QA tạo các trường hợp kiểm tra có cấu trúc cho một tính năng ứng dụng web, sử dụng các tiêu chí chấp nhận được cung cấp và các phương pháp hay nhất trong ngành (ISTQB, ISO 29119, OWASP).

O - Định dạng đầu ra

Chỉ định chính xác cách GPT định dạng câu trả lời.

Ví dụ:

Mã kiểm tra Tiêu đề Điều kiện tiên quyết Steps Expected Result Loại bảo hiểm Ghi chú

P — Tính cách

Xác định phong cách, giọng điệu và trình độ chuyên môn.

Ví dụ:

Kỹ sư QA cấp cao - ngắn gọn, nhận thức rủi ro và rõ ràng về các giả định. Luôn sử dụng thuật ngữ nhất quán và các định dạng ca kiểm thử có cấu trúc.

E - Ví dụ

Cung cấp một hoặc nhiều mẫu đầu vào/đầu ra để đặt kỳ vọng (nhắc nhở vài lần chụp).

Ví dụ:

đầu vào:

  • AC: Đăng nhập hợp lệ chuyển hướng đến bảng điều khiển.

Đầu ra:

Mã kiểm tra Tiêu đề Điều kiện tiên quyết Steps Expected Result Loại bảo hiểm Ghi chú
ĐĂNG NHẬP-AUTH-001 Đăng nhập hợp lệ chuyển hướng đến bảng điều khiển Người dùng đang hoạt động tồn tại 1. Đi tới /đăng nhập2. Nhập tên người dùng hợp lệ3. Nhập mật khẩu hợp lệ4. Nhấp vào Đăng nhập Chuyển hướng đến/bảng điều khiển Tích cực  

Có thể bàn giao 2 - Lan can

  • Không phát minh ra các tính năng hoặc thông điệp không có trong yêu cầu.
  • Gắn thẻ tất cả các giả định với [ĐÁNH GIÁ].
  • Nếu tìm thấy ≥2 khoảng trống quan trọng, hãy xuất ra phần “Cần làm rõ” trước khi tạo trường hợp kiểm thử.

Có thể bàn giao 3 - Kiểm tra nó

  1. Đặt S.C.O.P.E của bạn hướng dẫn vào hộp hướng dẫn/hệ thống của GPT.
  2. Cung cấp AC của kịch bản đã chọn của bạn làm lời nhắc người dùng.
  3. Tạo ra ít nhất 8 trường hợp thử nghiệm bao gồm tất cả các danh mục có liên quan.

Có thể bàn giao 4 - Tự kiểm tra

  • Bao gồm Tích cực, Tiêu cực, Ranh giới và mọi thử nghiệm Bảo mật/Giới hạn tỷ lệ hiện hành.
  • Định dạng phù hợp chính xác những gì bạn đã chỉ định.
  • Các bước rõ ràng và có thể kiểm tra được.
  • Mọi sự mơ hồ đều được thể hiện như [ĐÁNH GIÁ] ghi chú.

Đánh giá ngang hàng

Trao đổi với đối tác và kiểm tra:

  • Là S.C.O.P.E. hướng dẫn đầy đủ và cụ thể?
  • Có bao gồm tất cả các loại bảo hiểm có liên quan không?
  • Lược đồ đầu ra có được tuân thủ chính xác không?
  • Các giả định có rõ ràng và hợp lý không?

Example “Good” Output Snippet (Login & Lockout)

Mã kiểm tra Tiêu đề Điều kiện tiên quyết Steps Expected Result Loại bảo hiểm Ghi chú
ĐĂNG NHẬP-AUTH-001 Đăng nhập hợp lệ chuyển hướng đến bảng điều khiển Người dùng đang hoạt động tồn tại 1. Đi tới /đăng nhập2. Nhập tên người dùng hợp lệ3. Nhập mật khẩu hợp lệ4. Nhấp vào Đăng nhập Chuyển hướng đến/bảng điều khiển Tích cực  
ĐĂNG NHẬP-AUTH-003 Khóa tài khoản sau 5 lần thử không thành công Người dùng đang hoạt động tồn tại 1. Đăng nhập sai 5 lần với mật khẩu sai2. Cố gắng đăng nhập lần thứ 6 bằng mật khẩu hợp lệ Đăng nhập bị chặn; tài khoản bị khóa 15 phút Ranh giới/An ninh [ASSUMP] Khóa áp dụng cho tên người dùng, không phải IP

Trình tối ưu hóa lời nhắc xây dựng GPT

Xây dựng GPT thế hệ thử nghiệm

Xây dựng GPT mẫu ứng dụng

Tip 19 – Trích xuất Locator & xây dựng POM

Đây là một quy trình làm việc lặp lại để GPT thực hiện công việc nặng nhọc trong việc trích xuất bộ định vị và xây dựng POM của bạn. Bạn sẽ nhận được nhiệm vụ từng bước với lời nhắc bạn có thể dán. Tôi sẽ cho rằng Selenium + Java POM, nhưng tôi sẽ lưu ý các biến thể của Nhà viết kịch khi có vấn đề.

Dòng chảy cấp cao

  1. Crawl & inventory pages → 2) Extract elements → 3) Propose locator strategies → 4) Validate & harden → 5) Generate POM classes → 6) Smoke-check with code → 7) Export locator catalog → 8) Wire into CI check.

Từng bước với Lời nhắc

1) Xác định các quy tắc (một lần cho mỗi dự án)

Mục tiêu: Đặt các quy tắc cơ bản để GPT không xuất ra bộ định vị rác.

Lời nhắc (dán một lần vào đầu phiên):

sql
Sao chépSửa đổi
Bạn là một kiến trúc sư tự động hóa. Hãy tuân thủ nghiêm ngặt các quy tắc sau:
- Ưu tiên data-testid hoặc data-qa nếu có, sau đó là id, sau đó là CSS trong phạm vi. Tránh XPath tuyệt đối và con thứ n trừ khi nằm trong phạm vi cha mẹ ổn định.
- Không bao giờ sử dụng các lớp CSS tiện ích (ví dụ: các lớp tiện ích Tailwind/Bootstrap) làm bộ chọn chính.
- Thêm chờ đợi rõ ràng cho khả năng hiển thị/tệp đính kèm. Không có Thread.sleep.
- Với mỗi phần tử, đề xuất: định vị chính, 1 dự phòng và lý do.
- Đưa ra xếp hạng “Chất lượng định vị”: Mạnh/Trung bình/Yếu kèm theo căn cứ.
- Tạo có thể duy trì POM: một lớp trên mỗi trang/thành phần, riêng tư Theo trường, phương thức công khai.
- Bao gồm đoạn mã thử nghiệm khói sử dụng POM (mở trang, tương tác với 1–2 phần tử).
- Xuất danh mục định vị có thể đọc được bằng máy dưới dạng JSON để kiểm tra CI.

(Nếu là Nhà viết kịch: thay Selenium Qua với Nhà viết kịch trang.locator(...) và sử dụng chế độ chờ tự động tích hợp sẵn.)

2) Thu thập thông tin các trang mục tiêu (thủ công hoặc Chế độ đại lý)

Mục tiêu: Cung cấp GPT với URL và phạm vi trang.

Prompt:

mathematica
CopyEdit
Target app pages:
- <https://example.com/login>
- <https://example.com/dashboard>
- <https://example.com/settings>

Task:
1) For each URL, list key functional elements users interact with (inputs, buttons, nav links, forms, modals).
2) Do NOT invent elements. Only include what you can inspect or what I confirm.
3) Output a simple table per page: Element, Purpose, Visible Text (if any), Attributes observed (id, name, data-*, class).

(Nếu bạn đang sử dụng Tác nhân/Sử dụng máy tính, hãy yêu cầu nó mở từng trang, mở rộng menu/phương thức, sau đó trích xuất các phần tử hiển thị. Nếu không, bạn có thể dán các đoạn mã HTML có liên quan.)

3) Đề xuất bộ định vị (chính + dự phòng)

Mục tiêu: Biến các phần tử được phát hiện thành bộ định vị mạnh mẽ.

Prompt:

mathematica
CopyEdit
For the following extracted elements (paste your element tables or HTML snippets), propose:
- primary locator (prefer data-testid > id > scoped CSS)
- fallback locator (CSS or XPath with text when appropriate)
- Locator Quality: Strong/Medium/Weak
- Rationale

Output format (markdown table):
| Element | Primary Locator | Fallback Locator | Quality | Rationale |

4) Harden & validate (reject weak locators)

Mục tiêu: Buộc GPT phải cải thiện những điểm yếu.

Prompt:

vbnet
Sao chépSửa đổi
Xem lại bảng của bạn. Đối với bất kỳ công cụ định vị "Yếu" hoặc "Trung bình" nào:
1) Thử phạm vi tới vùng chứa chính ổn định (form#login, [data-testid='container'], các mốc dựa trên vai trò nếu có).
2) Thay thế bộ chọn lớp tiện ích bằng data-* hoặc id khi có thể.
3) Đối với bộ chọn văn bản (XPath), chuẩn hóa không gian và đảm bảo khớp chính xác hoặc chỉ chứa () an toàn khi văn bản ổn định.

Tạo lại bảng. Chỉ chấp nhận "Mạnh" hoặc "Trung bình" với lý do chính đáng; loại bỏ "Yếu" trừ khi không có giải pháp thay thế nào tồn tại.

5) Tạo các lớp POM (sẵn sàng triển khai)

Mục tiêu: Tạo mã POM bằng các phương thức rõ ràng.

Prompt:

sql
Sao chépSửa đổi
Tạo các lớp Selenium Java POM cho trang Đăng nhập và Trang tổng quan bằng cách sử dụng bảng định vị cuối cùng.

Yêu cầu:
- Lớp trên mỗi trang: Trang đăng nhập, Trang tổng quan
- trình điều khiển WebDriver cuối cùng riêng tư; WebDriverWait cuối cùng riêng tư chờ đợi;
- Theo các trường dành cho bộ định vị (chính và dự phòng được giữ trong phương thức getter riêng nếu cần)
- Các phương thức: login(user, pass), isLoggedIn(), NavigatorTo(section), v.v.
- Sử dụng ExpectedConditions.visibilityOfElementLocated để chờ đợi.
- Không có Thread.sleep.
- Bao gồm đoạn mã kiểm tra khói tối thiểu sử dụng cả POM.

Đầu ra: khối mã cho mỗi lớp + một ví dụ JUnit/TestNG nhỏ.

(Biến thể của nhà viết kịch: trang.locator() với getByTestId nếu có, hãy dựa vào tính năng tự động chờ, thêm trông chờ kiểm tra xem có sử dụng Playwright Test hay không.)

6) Thêm thử nghiệm khói và khắc phục nhanh các sự cố

Mục tiêu: Chạy và ngay lập tức bắt các thiết bị định vị bị hỏng.

Prompt:

sql
Sao chépSửa đổi
Tạo thử nghiệm khói TestNG một tệp:
- Mở trang Đăng nhập, thực hiện đăng nhập
- Yếu tố chính của Bảng điều khiển khẳng định hiển thị
- Đăng xuất
- Nếu bộ định vị có thể dễ hỏng, hãy hiển thị bản sao lưu get() để thử chính rồi dự phòng.

Xuất ra một tệp Java có tên SmokeTest.java.

7) Xuất danh mục định vị (JSON) cho CI

Mục tiêu: Giữ một bản ghi có thể đọc được bằng máy để phát hiện sự trôi dạt DOM.

Prompt:

css
Sao chépSửa đổi
Tạo danh mục công cụ định vị JSON bao gồm tất cả các trang. Lược đồ:
{
  "trang": "Trang đăng nhập",
  "yếu tố": [
    {
      "tên": "tên người dùngField",
      "chính": {"type": "css", "value": "[data-testid='email']"},
      "dự phòng": {"type": "id", "value": "email"},
      "chất lượng": "Mạnh",
      "notes": "Thích dữ liệu-testid"
    }
  ]
}

Tạo JSON này cho tất cả các trang chúng tôi đã đề cập.

(Lưu trữ tệp này trong repo dưới dạng định vị.json; bạn sẽ sử dụng nó trong kiểm tra CI.)

8) CI: Kiểm tra độ lệch của bộ định vị (tùy chọn nhưng di chuyển chuyên nghiệp)

Mục tiêu: Thất bại nhanh chóng khi đánh dấu thay đổi.

Lời nhắc (để GPT tạo tập lệnh kiểm tra nhỏ):

sql
Sao chépSửa đổi
Tạo tập lệnh Java (hoặc Nút):
- Đọc định vị.json
- Lượt truy cập từng trang
- Đối với mỗi phần tử, hãy xác minh rằng phần tử chính hoặc phần tử dự phòng phân giải thành ít nhất một phần tử hiển thị
- Xuất ra báo cáo đạt/không đạt cho mỗi phần tử và mã thoát tóm tắt cho CI
- Tránh ngủ; sử dụng thời gian chờ có thể định cấu hình

Đặt tên nó: LocatorDriftCheck.(java|js)

Ví dụ có thể chuyển giao

A) POM Getter có dự phòng (Selenium/Java)

java
Sao chépSửa đổi
riêng tư WebElement get(Theo chính, Bởi... dự phòng) {
    thử {
        return wait.until(ExpectedConditions.visibilityOfElementLocated(primary));
    } bắt (TimeoutException e) {
        for (By fb : dự phòng) {
            thử {
                return wait.until(ExpectedConditions.visibilityOfElementLocated(fb));
            } bắt (Bỏ qua ngoại lệ TimeoutException) {}
        }
        ném e;
    }
}

B) JSON mẫu (lát danh mục)

json
Sao chépSửa đổi
{
  "trang": "Trang đăng nhập",
  "yếu tố": [
    {
      "tên": "tên người dùngField",
      "chính": { "type": "css", "value": "[data-testid='email']" },
      "dự phòng": { "type": "id", "value": "email" },
      "chất lượng": "Mạnh",
      "notes": "Thích dữ liệu-testid; id ổn định theo hợp đồng nhà phát triển"
    },
    {
      "name": "nút đăng nhập",
      "chính": { "type": "css", "value": "[data-testid='login-btn']" },
      "dự phòng": { "type": "xpath", "value": "//button[normalize-space()='Login']" },
      "chất lượng": "Trung bình",
      "notes": "Văn bản có thể thay đổi; thích id kiểm tra hơn"
    }
  ]
}

Lan can để xử lý mọi lời nhắc

  • “Không bao giờ xuất ra các đường dẫn XPath tuyệt đối.”
  • “Tránh các lớp CSS tiện ích và con thứ n trừ khi nằm trong phạm vi cấp độ gốc ổn định.”
  • "Thích hơn [dữ liệu-testid] hoặc [dữ liệu-qa]; nếu thiếu, khuyên bạn nên thêm chúng.”
  • “Cung cấp xếp hạng Chất lượng và lý do căn bản cho từng công cụ định vị.”
  • “Luôn bao gồm đoạn mã kiểm tra khói bằng cách sử dụng POM được tạo.”
Tip 20 – Prompt để học
  1. Trò chơi: Thực hiện việc này khi bạn muốn sử dụng lời nhắc để tạo các bài tập học tập mang tính tương tác.

Ví dụ:

Tạo cho tôi một trò chơi về chủ đề tự động hóa thử nghiệm với Java Selenium.

Bạn là người điều khiển trò chơi và bạn sẽ giao nhiệm vụ dựa trên chủ đề này. Mỗi câu trả lời đúng sẽ tăng điểm của tôi.

Hãy đặt câu hỏi cho tôi và đợi câu trả lời của tôi trước khi chuyển sang câu hỏi tiếp theo. Hãy chắc chắn cung cấp cho tôi thông tin phản hồi về việc tôi đã làm tốt như thế nào.

Sau một số vòng chơi, hãy cho tôi bản tóm tắt về điểm số và thành tích của tôi.

  1. Hiểu biết: Trước khi bạn bắt đầu viết những gì tôi hỏi, tôi muốn bạn đánh giá mức độ hiểu biết của bạn về yêu cầu của tôi trên thang điểm 10. Nếu mức độ hiểu biết của bạn không phải là 10 trên 10 thì tôi muốn bạn hỏi tôi tất cả các câu hỏi mà bạn cần tôi trả lời để bạn có được điểm hiểu biết là 10 trên 10.
  2. Tiết kiệm thời gian Khi bạn đã tính đến tất cả thông tin tôi vừa cung cấp cho bạn, tôi muốn bạn chỉ trả lời “có.”