A Repeatedly Postponed Task

Anyone who has led a small team has probably encountered this scenario: the feature development is done, unit tests have coverage, but the integration test scenario design document sits on the to-do list until the day before launch, when a few hasty "smoke test scenarios" are thrown together just to get by.

It's not that people don't know it's important—it's that the effort-to-value ratio of writing it is too low. Take our team as an example:

• Not enough manpower: In a three-person team, whoever writes the scenario list has to stop everything to read code and API docs, easily eating up half a day;
• Scattered knowledge: How services call each other and which boundary conditions are prone to problems—this information lives in different people's heads, and no single person can write it all;
• Reviews without evidence: Even when the list gets written, in review meetings people can only vaguely say "something seems missing" without being able to pinpoint what;
• Deferred risk: Problems not covered by the scenarios eventually become post-mortem material after production incidents.

This is fundamentally a process problem, not purely a technical one. So the approach I tried wasn't "use AI to write tests," but rather embedding AI into the "design—review—confirm" process, letting it take on the initial draft—the most time-consuming step—while humans handle judgment and final sign-off.

What Role AI Plays in the Process

I gave AI a very clear positioning: a tireless draft writer + a devil's advocate reviewer.

The adjusted process works like this:

1. Developers provide input: API docs, service call relationship diagrams (a textual description is fine), and known historical failure points. The format doesn't need to be perfect—just understandable.
2. AI generates the scenario draft: It outputs a structured scenario list organized by dimensions such as normal flows, boundary conditions, exception propagation, idempotency and retries, and data consistency. Each scenario includes preconditions, trigger actions, and expected results.
3. Team review: The AI-generated list is walked through at the standup, and each person only needs to answer two questions—"which scenarios are redundant" and "which types of risks aren't covered."
4. AI counter-challenges: Review feedback is fed back in, and AI plays the role of "someone trying to break the system," specifically attacking paths the list didn't consider.
5. Confirm and archive: The final list is archived as the basis for test cases, with clear owners and confirmation timestamps.

The key points are steps 3 and 4: AI does not hold decision-making power. It outputs candidate proposals, and every line ultimately requires a human sign-off. This way you get the efficiency gains without giving away quality control.

A Reusable Prompt Template

This is the template our team actually uses—just replace the input section with your own project information:

你是一名资深测试架构师，帮我设计集成测试场景清单。

## 项目背景
- 系统组成：[描述涉及的服务/模块，如：订单服务 + 支付网关 + 消息队列]
- 集成方式：[如：同步HTTP调用 + 异步消息 + 共享数据库]
- 关键业务流程：[如：下单 → 扣库存 → 调支付 → 发通知]

## 输入材料
[粘贴接口文档摘要、调用关系描述、历史故障记录等]

## 要求
1. 按以下维度分类输出场景：
   - 正常路径（含典型参数组合）
   - 边界条件（超时、限流、参数极值）
   - 异常传播（下游失败时上游的行为）
   - 幂等与重试（重复请求、消息重复投递）
   - 数据一致性（部分成功、中间状态残留）
2. 每个场景包含：编号、前置条件、触发动作、预期结果、优先级(P0/P1/P2)
3. 对每个P0场景，说明如果漏测可能造成的最坏后果
4. 输出后附一节「本清单的盲区」：主动指出你可能遗漏的风险类型

## 输出格式
Markdown表格，方便直接贴入评审文档。

A special note on the last item, "blind spots of this list." Having AI proactively admit its coverage gaps is far easier than having team members rack their brains over "what's still missing"—review attention naturally gets directed to the weak spots, and meeting efficiency improves noticeably.

Before and After Comparison

From a management perspective, the biggest change isn't how much time was saved, but that this task finally has a fixed process. Previously, integration test scenario design was "whoever's free writes it." Now it has become a standard step with inputs, outputs, and review sign-offs—risk shifts from "randomly blowing up after launch" to "concrete, discussable, trackable items in the review meeting."

A Few Practical Tips

• Don't treat AI output as the final document directly. We found that roughly 20-30% of scenarios in the draft are unnecessary or based on invalid premises—the review step cannot be skipped.
• Historical incident records are the best input. Feed your past production issues to the AI, and the exception scenarios it generates will be noticeably more relevant to your system's reality.
• Watch out for sensitive information. Sanitize API docs before inputting them, especially parts involving keys, internal domain names, and customer data structures.
• Keeping costs manageable is enough. Tasks like this require "structured reasoning + long-text comprehension" from a model—mainstream models can all handle it. For specific selection, refer to the official pricing page and estimate based on your team's budget and call frequency.

Final Thoughts

When it comes to integration test scenario design, the difficulty has never been in "writing"—it's in "thinking comprehensively" and "having someone willing to start." AI happens to fill both gaps: it doesn't find the work tedious and can do dimension enumeration very systematically; and it doesn't worry about offending anyone, daring to list "here's what happens if you miss this."

For independent developers and small teams, my advice is to treat AI as a fixed role within your process to manage—clarify its inputs, outputs, and permission boundaries, rather than grabbing it ad hoc to fight fires. If you're looking for a stable AI API to support this kind of workflow, check out this platform: https://api.thistoken.ai/register —register and you can start running this process right away.

---

Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.