test-data-generation

Test Data Generation (Chinese Version)

When to Use

You need to design a reusable test data set that covers business rules, boundaries, combinations, and privacy constraints.
You need to perform a risk review of an existing plan, result, or evidence, and form actionable improvement items.
The input is incomplete, but a usable initial version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required items.

First read and follow the input, execution rules, minimum coverage checklist, and output order of prompts/test-data-generation.md .
Supplement the scope, environment, version, limitations, evidence, and success criteria that truly affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and questions to be confirmed.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a limited initial version, and explain which conclusions cannot currently hold.

When calibrating domain results, correct comparisons, or evidence gaps, read the desensitized input, item-by-item expectations, and recalculation basis of references/domain-decision-example.md .
Each execution must read prompts/test-data-generation.md; it is the complete execution specification of this Skill.
When this Skill needs to be evaluated or regressed, read evals/eval.yaml and the matching evals/cases/ test cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Derive data groups from the provided schema, entity foreign keys, unique constraints, state relationships, and scenario expectations; fix the seed/generator version, keep UNKNOWN when rules are missing, and do not automatically invent fields or real users.
Separate valid happy/boundary data from targeted invalid data, and note for each group the changed constraints, expected rejection/allowance, and unaffected relationships; invalid data must not quietly enter the normal process group.
Actually deliver desensitized samples and verification: uniqueness, foreign key existence, field type/range, state association, and repeatable output; rerunning the same seed should yield the same data identity rather than only writing reproducibility recommendations.
Use isolated IDs/namespaces, retain source permissions, personal data restrictions, and clean up in reverse dependency order; without authorization, do not scrape real personal profiles, and do not treat generated samples as proof of real business representativeness.

Real sensitive personal data must not be used
Distinguish synthetic, desensitized, and production mirror data
Generated data must be repeatable and cleanable
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide verification methods.
Priority must explain the basis in terms of business impact, likelihood of occurrence, or detectability.

Covered: valid and invalid, boundaries, equivalence classes, combinations, referential integrity, state, roles, localization, privacy, cleanup.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priority, evidence, owner, or next step.
The output includes verifiable judgment criteria rather than generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without specifying input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of prioritization.
Replacing domain judgment with tool names or generic theory.
Rejecting outright when input is incomplete, or conversely pretending the conclusion is already certain.

Start with the paths most likely to cause business loss, security issues, or release blockers.
Use the smallest verifiable experiment to reduce uncertainty, and record the reproduction conditions.
Make the output directly executable and reviewable by another engineer.