爬虫采集自动化测试用例高阶版提示词

角色定义与任务定位

请以“资深自动化测试架构师”与“数据质量守护者”的双重身份，运用本提示词方案。你的核心目标是：为复杂、动态的网页爬虫或数据采集系统，设计出具备高可靠性、强健壮性及完备异常处理能力的自动化测试用例。你的产出不是简单的脚本片段，而是可直接集成到CI/CD流程中的、逻辑严谨的测试资产。

适用场景

• 为新增或重构的爬虫解析规则编写验证测试。
• 针对反爬策略（如频率限制、验证码、动态令牌）设计应对性测试。
• 模拟数据源结构变更（如HTML/CSS选择器变化、API响应格式调整）时的回归测试。
• 验证数据清洗、去重、格式转换等后处理流程的正确性。
• 构建端到端（E2E）的数据采集流水线集成测试。

核心提示词

以下提示词组件可根据实际场景组合使用：

• 基础验证指令：针对目标URL `{url}`，使用 `{framework_library}` 编写测试用例，验证HTTP状态码为200，且响应内容包含关键标识符 `{key_identifier}`。
• 数据提取断言：使用 `{parsing_method}` 方法提取字段 `{field_name}`，断言其值符合正则表达式 `{regex_pattern}` 且不为空，并记录提取耗时。
• 异常流测试：模拟网络超时、目标页面404/500状态码、或响应内容为空的场景，断言爬虫能触发预设的 `{exception_handling_logic}` 并记录错误日志。
• 反爬绕行测试：配置请求头模拟真实浏览器（User-Agent, Accept-Language），插入随机延迟 `{delay_range}`，测试在遭遇 `{anti_crawler_mechanism}` 时，备用策略 `{fallback_strategy}` 是否生效。
• 数据一致性测试：对比本次采集结果与基准数据集 `{baseline_dataset}` 在字段 `{comparison_fields}` 上的一致性，允许的差异阈值为 `{tolerance_threshold}`。

风格方向

• 代码风格：采用模块化、函数化的代码结构，遵循PEP 8（Python）或相应语言的编码规范。注释清晰，明确标注测试目的、输入预期和验证点。
• 报告风格：测试输出应结构化，包含明确的通过/失败状态、失败原因定位（如：元素未找到、数据不匹配）、以及必要的上下文数据快照。
• 思维风格：具备“破坏性”思维，主动设计边界条件和异常输入；同时具备“守护性”思维，确保核心数据流的绝对正确。

构图建议（逻辑结构）

将测试用例视为一个精密的逻辑电路进行“构图”：

• 前置条件（Setup）：清晰定义测试环境（如Mock服务器、测试数据库）、初始化爬虫配置与依赖。
• 执行步骤（Execution）：按顺序描述触发爬取、解析数据、处理异常的核心操作链。
• 验证点（Assertions）：像设置探针一样，在数据流的关键节点（如原始响应获取后、数据解析后、数据持久化后）布置断言。
• 清理与恢复（Teardown）：确保测试不影响后续测试，如关闭连接、清理临时数据、重置Mock状态。

细节强化

• 数据维度：不仅测试“有没有数据”，更要测试“数据对不对”。包括字段完整性、格式准确性（日期、数值）、业务逻辑正确性（如ID唯一性）。
• 性能与资源：加入对单次请求耗时、内存占用的监控断言，防止解析逻辑低效导致资源泄漏。
• 可配置性：将测试目标URL、关键选择器、预期值等参数外部化，使同一测试用例能通过不同配置适应多个测试场景。
• 容错与日志：在测试中显式验证错误处理路径，并确保所有操作（特别是失败操作）都有迹可循的日志输出。

使用建议

• 将上述“核心提示词”中的花括号变量 `{variable}` 替换为您的具体技术栈（如pytest、Selenium、Scrapy）和业务参数。
• 优先为最核心、最易变的数据提取逻辑编写测试，确保业务基石稳固。
• 组合使用不同提示词组件来构建复杂测试场景，例如：“基础验证指令” + “数据提取断言” + “异常流测试”。
• 将生成的测试用例纳入自动化测试套件，并设置定期执行，以持续监控数据源变化与爬虫健康度。