监控测试用例 · Test Case Monitor

它解决什么问题

测试用例写成后没人维护:需求改了用例不更新、核心路径没覆盖、失败的用例一直红灯没人管,上线后才发现漏测。直接让 AI 写用例,常只给列表,不说怎么持续监控。

这个技能做什么

先盘点现有用例与需求变更,按「覆盖度 → 有效性 → 执行频率」检查:找出核心路径盲区、标注失效用例与原因,输出监控清单:哪些用例必须每次跑、哪些按周跑、失败后谁来修。

为什么比裸提示词强

• 查盲区:对照需求找漏测点。
• 查失效:过期用例标记原因与处理方式。
• 定频率:核心/常规/低频用例分级执行。

典型用例

• 需求变更后同步更新用例。
• 上线前检查用例覆盖是否足够。
• 把散乱的用例整理成监控清单。

局限

不执行测试,只做结构与覆盖检查;需要你提供需求与用例文本。

English · 英文介绍

The problem

After the test cases were written, no one maintained them: the test cases were not updated when the requirements were changed, the core paths were not covered, and the failed test cases kept the red light and no one took care of them. The missing tests were discovered only after going online. Directly asking AI to write use cases is often only given a list, without mentioning how to continuously monitor it.

What it does

First, take inventory of existing use cases and demand changes, and check according to "Coverage → Effectiveness → Execution Frequency": find out the core path blind spots, mark failed use cases and reasons, and output a monitoring list: which use cases must be run every time, which ones are run every week, and who will fix them after failure.

Why is it better than naked prompt words?

• Check blind spots: Find missing test points based on requirements.
• Check for expiration: reasons and processing methods for expired use case marking.
• Fixed frequency: core/regular/low-frequency use cases are executed hierarchically.

Typical use cases

• Use cases are updated synchronously after requirements change.
• Check whether the use case coverage is sufficient before going online.
• Organize scattered use cases into a monitoring list.

Limitations

No tests are executed, only structure and coverage checks are performed; you are required to provide requirements and use case texts.