CRO-requirements-test-analysis

Requirements Test Analysis

Purpose

Use this skill only for analyzing requirements and producing test analysis artifacts. Do not implement product code, change requirements, or run tests unless the user separately asks for execution in Agent mode.

Workflow

1. Identify the tested module, actors, business goal, dependencies, input/output data, state transitions, permissions, and acceptance criteria.
2. List unclear or missing requirements as assumptions or questions before generating cases. Before designing any test analysis or test cases, if questions remain, always ask the user first and wait for explicit confirmation before proceeding with the test analysis. Do not start writing the XMind tree or test cases until the open questions are answered.
3. Derive test scenarios from normal flows, abnormal flows, boundary values, validation rules, state changes, permissions, data consistency, concurrency, idempotency, compatibility, usability, and observability.
4. Always consider non-routine / unconventional operations along the business chain, not just the happy path. Examples: out-of-order steps, skipping or reversing a stage, retrying/re-submitting, concurrent operations by multiple roles, editing or deleting data that is already consumed downstream, operating on expired/cancelled/migrated data, partial success and rollback, cross-module data inconsistency, and recovering after interruption. Explicitly trace the full business chain (e.g. sampling -> logistics -> sample handling -> report -> billing) and probe where an abnormal operation at one stage could break or corrupt later stages.
5. Before writing test cases, create an XMind-style test analysis tree with leaf nodes that clearly describe expected coverage or behavior.
6. Prioritize cases by business risk and failure impact.
7. Ensure every test case title contains the expected result.
8. Keep the output focused on testing requirements. Avoid implementation details unless they affect test coverage.

Domain Context

When the user's requirement belongs to the drug clinical trial information system, use this context by default.

System name: 药物临床试验信息系统。

Core business flow:

采样 -> 预约物流配送 -> 样本流转/分拣 -> 样本入库/出库 -> 生成报告单

Sample testing is outside this system and must not be included in the default test scope unless the user explicitly asks for integration or external-system validation.

Authoritative module / page / field map: the detailed module list, navigation, page fields, roles, and status definitions are maintained in the CRO System Testing skill (including its references/module-map.md). Use that skill as the single source of truth for system domain details, and update it (not this skill) when new screenshots or requirements reveal new modules/fields. Do not duplicate the module list here.

For this system, always consider cross-module data continuity: project, center, subject, sample, logistics order, storage status, report task, and billing data should remain consistent across the business flow.

Required Coverage

Always consider these categories when relevant:

• Normal path: successful user journeys and core acceptance criteria.
• Abnormal path: invalid input, missing data, service errors, timeout, network interruption, repeated submission, expired session, unauthorized access.
• Boundary values: minimum, maximum, just below minimum, just above maximum, empty, null, zero, negative, max length, special characters, date/time boundaries.
• State transitions: draft, submitted, approved, rejected, cancelled, expired, deleted, restored, retrying, completed.
• Permission and roles: unauthenticated, normal user, owner, operator, admin, cross-tenant or cross-department access.
• Data rules: uniqueness, required fields, formats, precision, rounding, sorting, filtering, pagination, duplicate data, historical data.
• Integration risks: upstream/downstream failure, partial success, callback retry, message delay, data synchronization.
• Non-functional risks: performance, compatibility, security, audit logs, accessibility, localization, error messaging.

Output Format

Use this structure by default:

## 测试分析范围

[说明被测模块、测试目标、核心业务规则、依赖条件]

## 需求疑问与假设

- [疑问/假设 1]
- [疑问/假设 2]

## XMind 式测试分析叶子结点

```text
[需求名称]
├─ 触发条件
│  ├─ 【触发】[满足条件后出现预期行为]
│  └─ 【不触发】[不满足条件后不出现该行为]
├─ 正常流程
│  └─ 【成功】[核心业务流程成功结果]
├─ 异常场景
│  └─ 【异常处理】[异常输入/接口失败/状态异常后的系统表现]
├─ 边界场景
│  └─ 【边界通过/拦截】[边界值下的系统表现]
├─ 权限与数据隔离
│  └─ 【权限控制】[不同角色/不同项目/不同中心的数据隔离结果]
└─ 体验与提示
   └─ 【正确展示】[提示文案、关闭、跳转、可操作性等表现]

测试用例

风险与补充测试建议

• [风险或补充建议]

If the user prefers non-table output, use this case format instead:

```markdown
### P0｜异常｜【拦截】必填字段为空时禁止提交并提示具体字段错误

- 前置条件：
- 测试步骤：
- 测试数据：
- 预期结果：
- 覆盖点：

Title Rules

Each case title must include the result or system behavior:

• Good: 【成功】用户输入正确账号密码后可登录系统
• Good: 【失败提示】用户输入错误密码后提示账号或密码错误
• Good: 【边界拦截】手机号少于 11 位时禁止提交并提示格式错误
• Good: 【异常处理】接口超时后页面展示重试入口且不重复创建订单
• Avoid: 登录功能测试
• Avoid: 手机号边界测试

Quality Checklist

Before finalizing, verify:

• Titles include expected results.
• P0 cases cover core business success and critical failure paths.
• XMind-style leaf-node analysis is provided before test cases.
• Abnormal and boundary scenarios are included.
• Permissions, state transitions, and data rules are considered where applicable.
• Requirement gaps are listed separately from test cases.
• Test data is specific enough for execution.
• Expected results are observable and verifiable.
• For the drug clinical trial system, sample testing is excluded unless explicitly requested.
• For the drug clinical trial system, cross-module continuity is considered from sampling through logistics, sample handling, reporting, and billing.