AI 測試案例生成指南：用免費提示詞將需求轉為 TestRail 可匯入案例

A new spec lands as a PDF on Monday. By Wednesday you have to hand over test cases in your team's TestRail format: their column names, their priority values, their ID scheme. You spend two days copying requirement text into rows, and the import fails anyway because one header reads Expected Result instead of Expected result.

So you paste the spec into ChatGPT or Claude and ask for test cases. You get rows of happy path, each with "Verify the feature works correctly" as the expected result, in columns nobody on your team uses.

Your prompt skipped the work a QA lead does before writing a single case. This guide gives you that work as five prompts you can paste into any AI chat today. No tool to install.

Step 1. Give the AI your format, not just the spec

Attach two files: the requirements, and a file with two or three test cases your team already wrote. The example teaches the AI more than any description of your format.

I'm attaching (1) the requirements for the Payments module and (2) three test
cases in my team's format.

Before anything else, describe the format of file 2: the exact column names in
order, the allowed values for Priority and Type, the ID scheme and the last ID
used, and the writing style of steps and expected results. Don't write any test
cases yet.

Check the answer. If it lists High / Medium / Low and your team uses Blocker / Critical / Major / Minor, correct it now. Every case inherits this.

Step 2. Ask for a plan and the gaps, not the cases

This step decides what gets tested at all.

Read the requirements for the refund flow. Don't write test cases yet.

Give me:
1. A coverage plan: the areas you'll cover, the test design technique for each,
   and an estimated number of cases.
2. A list of gaps in the spec, each with the section number and one concrete
   question for the analyst. Look for: requirements with no measurable outcome,
   sections that contradict each other or a worked example, error paths that are
   never described, terms used as conditions but never defined, and external
   services whose failure is not specified.

End by asking me to approve or change the plan.

A spec that says "refunds should be processed quickly" has no testable outcome. A limit of $50,000 in one section and a worked example of a successful $75,000 refund in another is a contradiction someone has to resolve before you can write the boundary cases. "Silent on the error path" is the most common gap: the success flow fills a page, and nobody wrote what happens when the payment provider times out.

Approve the plan, or cut it down. Then move on.

Step 3. Make the AI use real test design techniques

Without explicit techniques, generated suites drift to whatever the spec mentions first: ten variations of the happy path. Name the techniques in the prompt:

Plan approved. Write the test cases using:

- Equivalence partitioning: one case per group of inputs that behave the same.
- Boundary values on both sides of every edge. For a limit of 50,000 that means
  49,999, 50,000 and 50,001, not just the rejected value.
- A decision table wherever an outcome depends on several conditions: one case
  where all conditions pass, plus one case per condition failing on its own.
- State transitions: the allowed ones, and a case proving each forbidden one is
  rejected.
- Error guessing: empty and max-length input, double submit, session expiry
  mid-flow, network failure between request and response.

Use exactly the columns, values and ID scheme from step 1, continuing from the
last ID.

The "both sides of every edge" line matters. A suite with 50,000 and 50,001 but no 49,999 proves the limit rejects. It never proves the system accepts everything up to the limit, so an off-by-one that moved the limit down would pass.

Step 4. Review the cases against a quality bar

Ask the AI to grade its own output before you read it:

Review every case against these rules and fix the ones that fail:

1. Atomic: one behaviour per case. If the title needs "and", split it.
2. Independent: it sets up its own preconditions.
3. One deterministic expected result with values, e.g. "Balance decreases by
   $500 and the history shows a refund with status Completed". No "works
   correctly", no "either X or Y".
4. Concrete data in the steps: "Amount: 50,001", not "an amount over the limit".
5. Steps are actions; checks go in the expected result.
6. No two cases test the same partition.
7. Every requirement in scope has at least one case. List any that have none.

Rule 3 protects the tester who runs the case. A case whose expected result reads "the operation ends in created or pending" can't be marked pass or fail. A real fork in behaviour means two cases. An undecided spec is a gap for the list.

Step 5. Export a file TestRail can import

Ask for a CSV with your exact headers:

Export all cases as CSV. Use the headers from step 1, exactly as spelled, in the
same order. One row per case. Put each step on its own line inside the cell, not
as "<br>" or "\n" text. Quote every field.

Two things break imports: a header that differs by one character from your field mapping, and multi-line steps that arrive as literal <br> tags. Open the file in a spreadsheet and check both before you import it into TestRail, Qase, Zephyr or Xray.

Where the prompts start to hurt

The five prompts work. After a few sprints, these four things get old:

• You re-describe your format every new chat, and the model forgets a column halfway through a long suite.
• It writes cases before you approve the plan unless you stop it every time.
• The gap list depends on how carefully you phrased step 2 that day.
• The CSV still needs a manual pass for headers and line breaks.

That's why I packaged the workflow as Casely, a free, open-source skill for Claude Code, claude.ai, the Claude desktop app and Codex. You attach the spec and one example file and say what you need:

"Here are the requirements for the Payments module and two example test cases my team writes. Give me test cases for the refund flow."

Casely runs the five steps above in one conversation and stops once, at the plan, for your OK. It copies your columns, priority values and ID scheme from the example file. It writes the cases with the techniques from step 3, then exports one .xlsx with your headers that TestRail imports in one pass, plus one Markdown file per case. When the spec describes an API, it also builds a Postman collection with every base URL, token and ID pulled out into variables, and no credentials in the file. When the spec names no endpoints, it asks for the API docs instead of inventing paths.

How do you know it finds the gaps?

The repo ships a benchmark: a fintech wallet spec with five planted defects (a vague "processed quickly", a $50,000 limit that contradicts a successful $75,000 example, a fee that is withheld but never sized, an undefined "verified status", and no behaviour for a payment provider outage), plus boundary rules, a state machine and a five-condition decision table. A 100-point rubric scores the run.

The first full run scored 85/100. It produced 33 cases continuing the team's ID scheme, matched all nine columns in order, and exported one workbook with no rejected case. It missed two of the five planted gaps. The rules that catch those two are now part of the skill. The spec, the example file and the rubric are in benchmark/, so you can score a run yourself.

Pick Opus for the plan phase if you can. Smaller models write acceptable cases from a plan they're handed, and miss the holes in the spec.

FAQ

Is there a free AI test case generator?
The prompts in this article are free with any AI chat. Casely is free and open-source under the MIT license; you pay only for the Claude or Codex plan you already use.

Can I import AI-generated test cases into TestRail?
Yes. Match the headers to your TestRail field mapping exactly and keep multi-line steps as real line breaks. Casely exports a file that already does both.

Does it work with requirements in other languages?
Casely writes the cases in the language of your example cases.

What about scanned PDFs?
Text-based PDFs, DOCX and XLSX work well. An image-only scan may not extract cleanly, so export a text version when you can.

Install Casely in Claude Code with two commands:

claude plugin marketplace add JohnWayneeee/casely-qa-skill
claude plugin install casely@casely

Setup for claude.ai, the desktop app and Codex is in the README.

More on how Casely came about: Your QA team was hired to find bugs. It spends two days a sprint formatting spreadsheets and Stop manually writing test cases.

If it saved you a day of formatting test cases, a ⭐ on the repo helps other QA engineers find it, and a coffee pays for the next release.