Back to Details

normalize-bug-report

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Normalize Bug Report

标准化Bug报告

Goal

目标

  • Bug report structured as sections, with no initial information lost.
  • 将Bug报告整理为结构化章节，且不丢失任何原始信息。

Input

输入

  • Raw bug report: freeform description, error log, or structured text. May be a single report, or an itemized batch (each with its own 
    id
    ) - keep 
    id
    attached throughout.
  • 原始Bug报告：自由格式描述、错误日志或结构化文本。可以是单个报告，也可以是带分项的批量报告（每个报告都有自己的
    id
    ）——全程保留
    id
    。

Steps

步骤

Step 1: Structure Bug Report

步骤1：整理Bug报告结构

Structure the input as sections:
  • Title: Issue statement. Focus on the issue, not the fix - declare the current, incorrect behavior (e.g. "User cannot log in")
  • Pre-conditions: Prerequisites for reproducing the bug (e.g. system state, environment, user account, or configuration).
  • Steps to Reproduce (STR): Sequential actions triggering the bug.
  • Actual Result (AR): Incorrect behavior description (e.g. error message).
  • Expected Result (ER): Correct expected behavior (e.g. notification shown).
  • Evidence: Assets with symptoms (e.g. logs, screenshots).
  • Severity: Level of impact (e.g., critical, high, medium, low).
将输入内容整理为以下章节：
  • 标题：问题说明。聚焦于问题本身而非修复方案——明确当前的错误行为（例如：“用户无法登录”）
  • 前置条件：复现Bug所需的前提条件（例如：系统状态、环境、用户账户或配置）。
  • 复现步骤（STR）：触发Bug的连续操作步骤。
  • 实际结果（AR）：错误行为的描述（例如：错误提示信息）。
  • 预期结果（ER）：正确的预期行为（例如：显示通知）。
  • 证据：包含症状的资源（例如：日志、截图）。
  • 严重程度：影响级别（例如：严重、高、中、低）。

Output

输出

Markdown format:
  • Bug Report
    • Title
    • Pre-conditions
    • Steps to Reproduce (STR)
    • Actual Result (AR)
    • Expected Result (ER)
    • Evidence
    • Severity
输出格式为Markdown：
  • Bug报告
    • 标题
    • 前置条件
    • 复现步骤（STR）
    • 实际结果（AR）
    • 预期结果（ER）
    • 证据
    • 严重程度