test-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<objective> Create actionable test plans for sprints and releases. A test plan answers four questions: what to test, how deeply, who does it, and when it must be done. The output is a living document that tracks progress, not a bureaucratic artifact filed and forgotten. A plan that schedules 100% of available time fails the moment the first bug is found — buffer and prioritization are what make it survive contact with reality. </objective>

<objective> 制定可执行的Sprint和Release测试计划。一份测试计划需要回答四个问题：测试什么、测试深度如何、由谁执行、必须何时完成。输出的是一份用于跟踪进度的动态文档，而非归档后被遗忘的官僚式文件。如果计划将所有可用时间排满，那么一旦发现第一个bug就会失效——缓冲时间和优先级设置才是让计划能够应对实际情况的关键。 </objective>

Quick Route

快速指引

Situation	Go to
Plan a single sprint	Steps 1-6 below, then the 1-page sprint template in `references/plan-documents.md`
Plan a release	Release template in `references/plan-documents.md` ; the go/no-go decision itself belongs to `release-readiness`
Track an in-flight plan / feed results back	`references/tracking-formats.md` (daily status + retrospective)
Decide what to cut when over capacity	Step 4 prioritization matrix

场景	对应操作
制定单个Sprint测试计划	完成以下步骤1-6，然后使用 `references/plan-documents.md` 中的单页Sprint模板
制定Release测试计划	使用 `references/plan-documents.md` 中的Release模板；发布与否的决策本身属于 `release-readiness` 的范畴
跟踪执行中的计划 / 反馈结果	`references/tracking-formats.md` （每日状态+回顾）
工作量超容时决定裁剪内容	步骤4的优先级矩阵

Discovery Questions

调研问题

Before writing a test plan, gather context. Check

.agents/qa-project-context.md

first -- if it exists, use it as the foundation and skip questions already answered there.

在编写测试计划前，先收集上下文信息。首先查看

.agents/qa-project-context.md

——如果该文件存在，以此为基础并跳过已解答的问题。

Scope

范围

What is the scope? (single sprint, release, hotfix, feature)
Which features are new vs. changed vs. unchanged?
Which features are being released for the first time?
Are there infrastructure or dependency changes (database migrations, API version bumps, third-party provider switches)?
Is there a requirements document, PRD, or set of user stories to map against?

测试范围是什么？（单个Sprint、Release、热修复、功能模块）
哪些功能是新增的、修改的、未变更的？
哪些功能是首次发布？
是否存在基础设施或依赖变更（数据库迁移、API版本升级、第三方供应商切换）？
是否有需求文档、PRD或用户故事集可用于映射？

Time and Resources

时间与资源

What is the testing window? (days, hours available)
Who is available for testing? (SDETs, manual testers, developers)
Are there shared resources that could bottleneck? (staging environments, test accounts, devices)
Is there a hard deadline that cannot move, or is the release date flexible?

测试窗口期是多久？（可用天数、小时数）
哪些人员可参与测试？（SDET、手动测试人员、开发人员）
是否存在可能造成瓶颈的共享资源？（预发布环境、测试账号、设备）
是否有不可变动的硬性截止日期，还是发布日期可灵活调整？

Risk Context

风险背景

Which areas changed the most in this cycle?
What broke in the last release or sprint?
Are there known fragile areas or tech debt that increase risk?
For risk-based prioritization methodology, see
```
risk-based-testing
```
.

本次周期中哪些区域变更最大？
上一次Release或Sprint中哪些部分出现过问题？
是否存在已知的脆弱区域或技术债务会增加风险？
如需基于风险的优先级划分方法，请查看
```
risk-based-testing
```
。

Existing Coverage

现有覆盖情况

What automated tests already exist for the in-scope features?
What is the current pass rate of the automated suite?
Are there known gaps in automation that require manual testing?
When was the last exploratory testing session on these features?

针对范围内的功能，已存在哪些自动化测试？
当前自动化测试套件的通过率是多少？
是否存在已知的自动化覆盖缺口需要手动测试补充？
最后一次对这些功能进行探索性测试是什么时候？

Core Principles

核心原则

1. Coverage-Driven: Map Every Requirement to at Least One Test

1. 覆盖驱动：每项需求至少对应一个测试用例

A test plan without traceability to requirements is a guess. Every user story, acceptance criterion, or requirement must map to at least one test case. Gaps in this mapping are untested requirements -- the most dangerous kind of risk.

无法追溯到需求的测试计划只是猜测。每个用户故事、验收标准或需求都必须对应至少一个测试用例。这种映射中的缺口意味着需求未被测试——这是最危险的风险类型。

2. Time-Boxed: Plan Fits the Available Window

2. 时间盒限制：计划需适配可用窗口期

Testing expands to fill available time if unbounded. Set a time box for each activity and stick to it. When the window is too short, the prioritization matrix determines what gets cut -- not gut feeling.

如果不设限，测试工作会自动填满所有可用时间。为每项活动设置时间盒并严格遵守。当窗口期过短时，由优先级矩阵决定裁剪内容——而非凭直觉判断。

3. Prioritized: Not Everything Gets Equal Depth

3. 优先级划分：并非所有内容都需同等深度测试

A payment flow change and a tooltip fix do not deserve equal effort. Use the risk x effort matrix to allocate depth: some features get full regression, others a smoke test, some nothing if low-risk and unchanged.

支付流程变更与提示框修复不值得投入同等精力。使用风险×工作量矩阵分配测试深度：部分功能需完整回归测试，部分只需冒烟测试，低风险且未变更的功能可无需测试。

4. Buffered: Leave Room for the Unexpected

4. 预留缓冲：为意外情况留出空间

Plans that schedule 100% of available time fail when bugs are found. Allocate only 70-80% of the testing window to planned work and explicitly reserve the remaining 20-30% for bug verification, re-testing, and unplanned investigation. If buffer is not a named line in the plan, you do not have one.

将所有可用时间排满的计划在发现bug时会立即失效。仅将测试窗口期的70-80%分配给计划内工作，明确预留剩余20-30%用于bug验证、重测和未计划的调查。如果计划中没有明确标注缓冲项，就等于没有缓冲。

5. Visible: The Plan Is a Communication Tool

5. 可视化：计划是沟通工具

Developers need to know what gets tested to write testable code. Product managers need coverage visibility to make release decisions. Publish the plan where the team can see it.

开发人员需要了解测试内容以编写可测试代码。产品经理需要覆盖可见性来做出发布决策。将计划发布到团队可查看的位置。

6. Entry and Exit Criteria Are First-Class

6. 准入与准出标准为核心内容

The most-reused part of any plan is its gate. Make it explicit, not buried: entry = code-complete on staging + existing suite green + test data seeded; exit = every HIGH-risk area covered + no open P0/P1 + zero unexplained GAP rows in the coverage matrix. Everything else is detail around these two checkpoints.

任何计划中最常被复用的部分是其关卡。需明确标注，而非隐藏：准入标准 = 预发布环境代码完成+现有测试套件全部通过+测试数据已准备；准出标准 = 所有高风险区域已覆盖+无未解决的P0/P1级bug+覆盖矩阵中无未解释的GAP行。其他内容都是围绕这两个检查点的细节。

Workflow

工作流程

The six workflow steps each have a fill-in-the-blank scaffold. The decision prose stays here; the copy-paste templates (decomposition, coverage matrix, estimation worksheet, prioritization matrix, allocation table, schedule) live in

references/workflow-templates.md

六个工作流程步骤各有填空模板。决策说明保留在此处；可复制粘贴的模板（拆解、覆盖矩阵、估算工作表、优先级矩阵、分配表、进度安排）位于

references/workflow-templates.md

中。

Step 1: Feature Analysis and Decomposition

步骤1：功能分析与拆解

Break each in-scope feature into testable units. A "testable unit" is a specific behavior that can be verified with a clear pass/fail outcome. Walk every feature against these scenario categories so none gets skipped:

Happy path — the primary success flow.
Validation — required fields empty, format violations, boundary values.
Error conditions — server 5xx, network timeout, rejected input.
Edge cases — unicode, oversized payloads, unsupported formats.
Concurrency / race conditions — two users edit the same record simultaneously, double-submit, retry-after-timeout. These hide the worst data-corruption bugs and are the category most often missed.
Integration points — behavior across each boundary the feature crosses.

See

references/workflow-templates.md

for the decomposition template and a worked "User Profile Edit" example that exercises all six categories.

AI decomposition cross-check. When an agent decomposes features, have it immediately map its own scenarios back against the Step 2 coverage matrix. Any requirement with no scenario, or any scenario category above with no entry, is a decomposition gap the agent must surface before estimation — this is how you catch the agent's blind spots, not after CI does.

将每个范围内的功能拆解为可测试单元。“可测试单元”是指可通过明确的通过/失败结果验证的特定行为。对照以下场景类别梳理每个功能，确保无遗漏：

正常流程 —— 主要成功路径。
校验场景 —— 必填字段为空、格式违规、边界值。
错误场景 —— 服务器5xx错误、网络超时、输入被拒绝。
边缘场景 —— Unicode字符、超大负载、不支持的格式。
并发/竞态条件 —— 两名用户同时编辑同一条记录、重复提交、超时后重试。这些场景隐藏着最严重的数据损坏bug，也是最常被遗漏的类别。
集成点 —— 功能跨越的每个边界的行为。

请查看

references/workflow-templates.md

中的拆解模板及涵盖所有六个类别的“用户资料编辑”示例。

AI拆解交叉校验。当Agent拆解功能时，需立即将其生成的场景映射到步骤2的覆盖矩阵中。任何没有对应场景的需求，或上述任何场景类别中无条目，均为拆解缺口，Agent必须在估算前指出——这是在CI发现问题前捕捉Agent盲区的方法。

Step 2: Requirements-to-Test Coverage Mapping

步骤2：需求到测试的覆盖映射

Create a traceability matrix that maps every requirement to its test cases. See

references/workflow-templates.md

for the coverage matrix template.

Rules for the coverage matrix:

Every requirement must appear in the matrix (target: 100% mapping)
"GAP" status triggers a decision: write a test, accept the risk, or defer
Automated tests get test IDs that link to the actual test file/function
Manual tests reference the test case document or charter

创建可追溯矩阵，将每个需求映射到对应的测试用例。请查看

references/workflow-templates.md

中的覆盖矩阵模板。

覆盖矩阵规则：

每个需求都必须出现在矩阵中（目标：100%映射）
“GAP”状态需触发决策：编写测试用例、接受风险或延迟测试
自动化测试需分配测试ID，链接到实际测试文件/函数
手动测试需引用测试用例文档或测试大纲

Step 3: Effort Estimation

步骤3：工作量估算

Estimate effort for each test type using historical data. If no historical data exists, use the reference estimates below and calibrate after the first sprint.

Estimation reference (per test case):

Test Type	Write Time	Execute Time	Maintenance (per quarter)
Unit test	0.5 hr	< 1 sec	5 min
Integration test	1 hr	5-30 sec	15 min
E2E test (Playwright/Cypress)	2-3 hours	30s-2 min	30 min
Manual test case (write)	0.25 hr	5-15 min per execution	10 min
Exploratory session (charter)	15 min	1.5 hrs per session	N/A
Accessibility review (manual)	0.5-1 hr per area	included in write	15 min
Visual regression test	30-60 min	10-30 sec	20 min (baseline updates)
Performance test (k6 script)	2-4 hours	5-30 min per run	30 min
Prompt regression / LLM eval	30-60 min per case	30 sec - 2 min (with API cost)	20 min
Setup & test data (per feature)	0.5-2 hrs	one-time	re-seed per env

Write Time is authoring only. The "Setup & test data" row is the line planners most often omit — environment, fixtures, and mock configuration routinely run 20-40% of total effort, so budget it as a real line rather than discovering it mid-sprint.

AI authoring trade-off. Using an agent to author tests cuts Write Time by roughly 40-60%, but add a Review Time line of similar size per case — Bolton's "AI productivity paradox" (2026) is that the speed-up evaporates when an agent ships plausible-but-broken tests that pass a casual review and fail in CI. See
ai-test-generation
Step 7 for the review checklist and
ai-qa-review
for the smell taxonomy.

Test-smells review. ISTQB's CTAL-AT v2.0 (May 2026) names test smells as a planning concern. Budget a recurring 30-min "test-smells review" per sprint against the taxonomy in
ai-qa-review
— cheap, and it finds maintenance debt before it compounds.

Use the sprint estimation worksheet in

references/workflow-templates.md

to roll per-case estimates up to a capacity-utilization figure (target: 70-80%, leaving 20-30% buffer).

使用历史数据估算每种测试类型的工作量。如果没有历史数据，请使用以下参考估算值，并在第一个Sprint后进行校准。

估算参考（每个测试用例）：

测试类型	编写时间	执行时间	维护成本（每季度）
Unit test	0.5小时	<1秒	5分钟
Integration test	1小时	5-30秒	15分钟
E2E test (Playwright/Cypress)	2-3小时	30秒-2分钟	30分钟
手动测试用例（编写）	0.25小时	每次执行5-15分钟	10分钟
探索性测试（大纲）	15分钟	每次会话1.5小时	N/A
无障碍测试（手动）	每个区域0.5-1小时	包含在编写时间内	15分钟
Visual regression test	30-60分钟	10-30秒	20分钟（基线更新）
Performance test (k6 script)	2-4小时	每次运行5-30分钟	30分钟
Prompt regression / LLM eval	每个用例30-60分钟	30秒-2分钟（含API成本）	20分钟
环境搭建与测试数据（每个功能）	0.5-2小时	一次性	每个环境需重新准备

编写时间仅指创作时间。“环境搭建与测试数据”项是计划人员最常遗漏的部分——环境、测试夹具和模拟配置通常占总工作量的20-40%，因此需将其作为明确项纳入预算，而非在Sprint中期才发现问题。

AI编写权衡。使用Agent编写测试可减少约40-60%的「编写时间」，但需为每个测试用例添加同等时长的「审核时间」——Bolton在2026年提出的“AI生产力悖论”指出，当Agent生成看似合理但存在问题的测试用例，通过初步审核却在CI中失败时，效率提升就会消失。请查看
ai-test-generation
步骤7的审核清单和
ai-qa-review
中的问题分类。

测试问题审核。ISTQB的CTAL-AT v2.0（2026年5月）将测试问题列为计划关注点。每个Sprint预留30分钟的“测试问题审核”时间，对照
ai-qa-review
中的分类进行检查——成本低，且能在维护债务累积前发现问题。

使用

references/workflow-templates.md

中的Sprint估算工作表，将单个用例的估算汇总为容量利用率数值（目标：70-80%，预留20-30%缓冲）。

Step 4: Prioritization Matrix (Risk x Effort)

步骤4：优先级矩阵（风险×工作量）

When the estimated effort exceeds available capacity (it usually does), use the risk x effort matrix to decide what to cut. See

references/workflow-templates.md

for the full matrix grid.

For each test case, plot it on the matrix using the risk score from

risk-based-testing

and the effort estimate from Step 3, then consume capacity in priority order: DO FIRST → DO SECOND → DO THIRD → DEFER → SKIP.

Tie-break rule: within HIGH risk, low-effort beats high-effort — a HIGH-risk / low-effort test (DO FIRST) outranks a HIGH-risk / high-effort test (DO THIRD), because it buys the most risk reduction per hour. Medium-risk items defer before you cut any HIGH-risk coverage; low-risk items defer or skip entirely. Never cut buffer to fit more planned work.

当估算工作量超过可用容量时（通常会出现这种情况），使用风险×工作量矩阵决定裁剪内容。请查看

references/workflow-templates.md

中的完整矩阵网格。

将每个测试用例根据

risk-based-testing

中的风险评分和步骤3的工作量估算绘制到矩阵中，然后按优先级顺序消耗容量：优先执行 → 次要执行 → 延后执行 → 延迟 → 跳过。

平局规则：在高风险类别中，低工作量测试优于高工作量测试——高风险/低工作量测试（优先执行）排名高于高风险/高工作量测试（次要执行），因为每小时投入能获得最大的风险降低效果。中风险项在裁剪任何高风险覆盖前延迟；低风险项直接延迟或跳过。绝不能通过裁剪缓冲来容纳更多计划内工作。

Step 5: Resource Allocation

步骤5：资源分配

Assign testing work based on skill match and availability.

Allocation principles:

Automated test writing goes to SDETs or developers with framework experience
Exploratory testing goes to the person who understands the feature best (often the developer or product manager, not just QA)
New feature testing benefits from fresh eyes -- assign someone who did not build it
Critical path testing should not have a single point of failure -- two people should be able to cover it
Each person's load stays at 70-80% utilization, not 100% — the rest is their buffer
Buffer is distributed per person, not lumped into one tester's block: every assignee carries their own buffer line so a blocker on one person does not consume everyone's slack

See

references/workflow-templates.md

for the allocation table format.

根据技能匹配度和可用性分配测试工作。

分配原则：

自动化测试编写分配给SDET或具备框架经验的开发人员
探索性测试分配给最了解该功能的人员（通常是开发人员或产品经理，而非仅QA）
新功能测试适合由未参与开发的人员执行，以获得全新视角
关键路径测试不应存在单点故障——需至少两名人员可覆盖
每个人的工作量保持在70-80%的利用率，而非100%——剩余时间为个人缓冲
缓冲时间分配给每个人员，而非集中分配给某一名测试人员：每个负责人都有自己的缓冲项，这样一名人员遇到阻塞不会消耗所有人的空闲时间

请查看

references/workflow-templates.md

中的分配表格式。

Step 6: Schedule with Buffers

步骤6：带缓冲的进度安排

Map testing activities to the sprint timeline. Testing should not be back-loaded to the last two days. See

references/workflow-templates.md

for the 2-week sprint schedule template.

Key scheduling rules:

Testing starts as soon as features are code-complete, not at sprint end
Environment setup and test data preparation happen on Day 1, not Day 3
Bug verification is continuous, not batched
The last day is for confirmation, not for starting new testing

将测试活动映射到Sprint时间线。测试不应集中在最后两天进行。请查看

references/workflow-templates.md

中的两周Sprint进度模板。

关键进度规则：

功能代码完成后立即开始测试，而非等到Sprint结束
环境搭建和测试数据准备在第1天完成，而非第3天
bug验证持续进行，而非批量处理
最后一天用于确认测试，而非开始新的测试工作

Plan Documents

计划文档

Full copy-paste plan documents live in

references/plan-documents.md

Sprint Test Plan (1-Page) — scope, coverage summary, effort budget, entry/exit criteria, plan risks. Keep a sprint plan to one page.
Release Test Plan — aggregates sprint plans and adds release-specific concerns (full regression, cross-browser, perf benchmark, security scan, smoke test) plus go/no-go criteria. The go/no-go decision itself belongs to
```
release-readiness
```
.
Feature Coverage Matrix — per-feature scenario list with priority, test type, location, and status.
Test Estimation Worksheet — new-test development, existing-suite execution, manual testing, and a summary delta vs. available capacity.

完整的可复制粘贴计划文档位于

references/plan-documents.md

中：

单页Sprint测试计划 —— 范围、覆盖摘要、工作量预算、准入/准出标准、计划风险。Sprint计划需控制在一页内。
Release测试计划 —— 汇总Sprint计划并添加Release特有关注点（完整回归、跨浏览器、性能基准、安全扫描、冒烟测试）以及发布与否的标准。发布与否的决策本身属于
```
release-readiness
```
的范畴。
功能覆盖矩阵 —— 每个功能的场景列表，包含优先级、测试类型、位置和状态。
测试估算工作表 —— 新测试开发、现有套件执行、手动测试，以及与可用容量的差异汇总。

Tracking Progress During the Sprint

Sprint期间跟踪进度

A test plan is useless if nobody checks it after Day 1. Track progress daily, and feed the results back into future planning at sprint end.

Daily test status — completed, blocked, bugs found, tomorrow's plan, coverage percentage, and buffer consumed. See the format in
```
references/tracking-formats.md
```
.
Sprint retrospective inputs — estimation accuracy broken out by test type, coverage delta, bug counts by severity, and lessons. See the format in
```
references/tracking-formats.md
```
; feed these data points into the next sprint's estimates.

如果在第1天后无人查看，测试计划就毫无用处。每日跟踪进度，并在Sprint结束时将结果反馈到未来的计划中。

每日测试状态 —— 已完成、阻塞、发现的bug、明日计划、覆盖百分比、缓冲消耗情况。格式请查看
```
references/tracking-formats.md
```
。
Sprint回顾输入 —— 按测试类型划分的估算准确性、覆盖差异、按严重程度划分的bug数量、经验教训。格式请查看
```
references/tracking-formats.md
```
；将这些数据点纳入下一个Sprint的估算中。

Anti-Patterns

反模式

Planning Without Risk Assessment

无风险评估的计划

Treating every feature with equal depth wastes effort on low-risk areas and under-tests critical paths. Always run the prioritization matrix (Step 4) before allocating effort. For the full risk methodology, see

risk-based-testing

对所有功能投入同等测试深度会浪费精力在低风险区域，同时对关键路径测试不足。在分配工作量前，务必运行步骤4的优先级矩阵。如需完整的风险方法，请查看

risk-based-testing

。

No Buffer for Bug Discovery

未预留bug发现缓冲

Scheduling 100% of available hours for planned activities leaves no time for verification when bugs are found. Reserve 20-30% as buffer and track consumption daily.

将所有可用时间排满计划内活动，会导致发现bug时无时间进行验证。预留20-30%的缓冲时间，并每日跟踪消耗情况。

Back-Loading Testing to Sprint End

测试集中在Sprint末期

Leaving all testing for the last two days rushes coverage and surfaces bugs too late to fix. Start testing as features become available; continuous testing beats batch testing at sprint end.

将所有测试留到最后两天会导致覆盖仓促，且发现bug时已来不及修复。功能可用后立即开始测试；持续测试优于Sprint末期的批量测试。

Test Plan as Compliance Artifact

测试计划作为合规文件

A 30-page plan filed and forgotten helps nobody. The plan should be one page for a sprint, actively tracked, and updated daily. If the plan is not changing, nobody is using it.

一份30页的计划归档后被遗忘对任何人都没有帮助。Sprint计划应控制在一页，主动跟踪并每日更新。如果计划没有变化，说明无人使用它。

Estimating Without Historical Data

无历史数据的估算

Effort estimates pulled from thin air are unreliable. Track actual time spent — broken out by test type — and use that data for future estimates. After 2-3 sprints, estimates become reliable.

凭空得出的工作量估算不可靠。跟踪实际花费的时间——按测试类型划分——并将这些数据用于未来的估算。经过2-3个Sprint后，估算会变得可靠。

Ignoring Environment and Data Setup

忽略环境与数据搭建

Environment setup, test data creation, and mock configuration can consume 20-40% of testing effort. Include the "Setup & test data" row from Step 3 in the estimate or the plan will always run over.

环境搭建、测试数据创建和模拟配置可能消耗20-40%的测试工作量。将步骤3中的“环境搭建与测试数据”项纳入估算，否则计划总会超时。

Single-Person Coverage on Critical Path

关键路径仅由单人覆盖

A single tester covering all critical-path work is a failure point. Ensure at least two people can cover critical-path testing.

仅由一名测试人员覆盖所有关键路径工作是故障点。确保至少两名人员可覆盖关键路径测试。

Verification

验证环节

Open the produced plan and confirm: every in-scope ticket ID from the sprint board appears in the Scope table; the coverage matrix has zero unexplained GAP rows (each GAP carries an accept/defer note); allocated capacity sums to 70-80% with a named buffer line; and the entry/exit criteria checklists are filled, not placeholder. If any of these fails, the plan is not done.

打开生成的计划并确认：Sprint看板中所有范围内的工单ID都出现在范围表中；覆盖矩阵中无未解释的GAP行（每个GAP都有接受风险或延迟测试的说明）；分配的容量总和为70-80%，且有明确标注的缓冲项；准入/准出标准清单已填写，而非占位符。如果任何一项不满足，计划未完成。

Done When

完成标准

Reference Files (in

references/

)

参考文件（位于

references/

）

workflow-templates.md — Fill-in scaffolds for the six workflow steps: decomposition template + example, coverage matrix, sprint estimation worksheet, risk×effort matrix grid, allocation table, and 2-week schedule.
plan-documents.md — Full copy-paste documents: 1-page sprint test plan, release test plan, feature coverage matrix, and estimation worksheet.
tracking-formats.md — Daily test status format and sprint retrospective inputs format (with per-test-type variance).

workflow-templates.md —— 六个工作流程步骤的填空模板：拆解模板+示例、覆盖矩阵、Sprint估算工作表、风险×工作量矩阵网格、分配表、两周进度安排。
plan-documents.md —— 完整的可复制粘贴文档：单页Sprint测试计划、Release测试计划、功能覆盖矩阵、估算工作表。
tracking-formats.md —— 每日测试状态格式和Sprint回顾输入格式（按测试类型划分差异）。