报告
bug报告mcp labelbox python
假设错误报告验证 你要做什么
您将评估由AI系统生成的错误报告，该系统使用基于属性的测试来查找Python包中的错误。你的工作是确定每份报告是否描述了应该向维护人员报告的真正错误。 开始之前
请仔细阅读这些说明。
您必须具有网络访问权限才能浏览错误报告所涉及的代码库。
可选：如果你想运行复制代码，包括克隆代码库，请设置一个Python环境。 任务
对于每个bug报告，您将回答三个是/否问题：
这是一个真正的bug吗？属性测试失败指向代码行为中的合法问题。 维护人员会欢迎这个bug报告吗？报告是准确的，这个bug值得他们花时间解决。 这是安全问题吗？错误报告标记了可能导致恶意利用的行为。
对于每个问题，您还将提供一个信心评级（1-5），以表明您的确定性。
时机 平均处理时间（AHT）：每次评估45分钟。 战略性地使用时间预算：从文档和代码搜索开始，必要时运行代码，并在答案明确时完成。
循序渐进的过程
仔细阅读Bug报告。 审查摘要和索赔问题 检查失败的基于属性的测试 查看复制代码和失败的输入 了解建议的修复方法（如果提供） 调查索赔。 搜索功能/模块文档 查找任何关于观察到的行为的提及 检查是否存在已知的限制或边缘情况 验证声称的“正确”行为是否与文档相符 探索源代码。 在GitHub或包存储库上查找实现 检查有意设计决策的意见 查看最近影响此代码的提交 审查建议的修复方案的可行性 搜索现有问题。 检查是否已报告此错误 查找相关讨论或PR 查看维护人员是否对类似问题发表了评论 如果找到，请保存链接以包含在您的回复中 运行复制代码。（可选，但有帮助） 如果你有一个Python环境，试试最小的例子 验证错误是否如所声称的那样再现 测试失败输入周围的边缘情况 进行评估
对于每个问题，请提供是/否答案以及置信度评分（1-5）： 5：对决策充满信心 4：有信心，有轻微的不确定性 3：信心适中，有些模糊 2：信心低，不确定性大 1：非常不确定，主要是猜测 这是一个真正的Bug吗？
是：违反记录的行为、数学属性或合理预期 否：这是预期行为、用户错误或误解。
请仔细考虑以下几点： 它是否违反了明确的文件？ 一个理性的开发人员会期望这种行为吗？ 当前行为是否有合法的用例？
有些虫子很无聊，不有趣。例如，一个位于某个库内部且用户不可见的函数，它说它应该为错误代码返回-1，但有时为不同的错误代码返回-2，这可能不是一个需要提交问题的关键错误。相比之下，一个用户可见的函数表示它正在计算某个函数，但行为不同（甚至微妙），可能值得报告 一般来说，运用你的判断力。如果你想在这里提交一个bug，如果你看到了这份报告，你应该提交这个bug。 维护人员会欢迎这个bug报告吗？
是的：清晰、可操作的错误，具有良好的再现性，值得修复。 否：琐碎、写得不好、已经为人所知或不值得付出努力。
您会注意到，每个错误报告都有一个日期。这是最近的事情，但也有可能在那时到现在之间添加了错误修复。回答时，要像报告错误报告的当天一样。
请仔细考虑以下几点： 这会影响多少用户？ 报告的明确性和可操作性如何？ 繁殖是最小和可靠的吗？ 它是否包括合理的修复建议？ 是否已经报道或已知？ 这是安全问题吗？
是：可能被利用造成伤害（数据丢失、DoS、注入等） 否：没有可利用的安全隐患
请仔细考虑以下几点： 这会导致数据损坏或丢失吗？ 它可以用于拒绝服务吗？ 它是否绕过了安全边界？ 它会泄露敏感信息吗？ 记录你的推理
对于每次评估，请提供： 你的信心水平（1-5分） 解释你的决定的理由（每个理由4句以上） 你检查了哪些资源。提供指向任何相关问题、github讨论、文档、git历史提交、错误报告、相关CVE（等）的确切链接，这些链接通知了您的评级决定。 任何影响你决定的额外背景。这可能是检查现有的测试用例，并检查是否已经间接捕获了属性测试违规。您可以使用git blast来扫描随着时间的推移对发生属性测试违规的范围内的代码所做的更改，以查看属性违规是由于最近的更改还是始终存在。 质量要求
✓ 在将其标记为“真正的bug”之前，请检查官方文档。 ✓ 为每个决定提供明确的理由 ✓ 你的理由与给出正确的答案同样重要。请对你的理由给予同等的努力和考虑。这是您展示专业知识和专业背景价值的机会。 ✓ 链接到任何现有的错误报告或讨论 ✓ 指定您咨询了哪些资源 ✓ 保持评估标准的一致性 ✓ 在安全评估中保持客观——不要过度 要避免的常见错误 ❌ 假设所有测试失败都是错误（有些可能测试不正确的假设） ❌ 仅仅因为问题是边缘情况，就将其标记为“不真实” ❌ 过度标记安全问题（它们很少见——要客观） ❌ 不检查问题是否已知/已报告 ❌ 查找现有报告但忘记包含链接 ❌ 在明确的案件上花费太多时间 ❌ 当您不熟悉软件包域时，使用高置信度 成功秘诀
💡 从文档开始——这是识别预期行为的最快方法 💡 使用GitHub的搜索功能快速找到相关讨论 💡 把时间集中在模棱两可的案件上；清除bug/非bug应该很快 💡 在评估安全影响时要客观——这种情况很少见 💡 使用信心评分来表达不确定性——这就是它们的用途 💡 对于不熟悉的包裹，进行基础研究，但要反映信心评分的不确定性 💡 如果找到现有报告，请始终链接到它们-避免重复工作 例子 示例1：清除Bug-仅正分布的负值
Bug报告摘要： numpy.random.wald 产生具有较大平均参数的负值，违反了数学定义。
调查结果：
- 文档表明Wald分布只产生正值
- 数学定义确认x>0要求
- 复制确认产生负值
- 没有迹象表明这是预期行为
评估：
- 这是一个真正的bug吗？是（置信度：5）
- 理由：明显违反数学属性和文档
- 维护人员会欢迎吗？是（置信度：4）
- 理由：记录良好，影响统计计算的正确性
- 安全问题？否（置信度：4）
- 理由：可能导致计算错误，但不会直接利用安全漏洞 示例2：边缘案例-性能下降
Bug报告摘要：在特定的输入模式下，函数会变得非常慢。
调查结果：
- 文件没有规定性能保证
- 算法已知O（n²）最坏情况
- 问题跟踪器有类似的报告，标记为“wontfix-记录的限制”
- 发现存在问题：https://github.com/example/repo/issues/456
评估：
- 这是一个真正的bug吗？是（置信度：2）
- 理由：技术上正确，但性能令人惊讶；然而，这似乎是已知的局限性
- 维护人员会欢迎吗？否（置信度：4）
- 理由：已经讨论过并决定不进行修复（见第456期）
- 安全问题？否（置信度：3）
- 理由：虽然可能用于DoS，但维护人员意识到并接受风险
- 现有报告：\[https://github.com/example/repo/issues/456\]
示例3：非Bug记录行为
Bug报告摘要：函数对空输入引发异常。
调查结果：
- 文档明确指出“无输入时引发ValueError”
- 多个测试验证了此行为
- 设计讨论表明这是有意的
评估：
- 这是一个真正的bug吗？否（置信度：5）
- 理由：明确记录的行为
- 维护人员会欢迎吗？否（置信度：5）
- 理由：报告误解了预期API
- 安全问题？否（置信度：5）
- 理由：标准输入验证 常见问题请务必阅读
Q： 如果我无法运行复制代码怎么办？ A： 专注于文档和源代码分析。大多数决定可以在不执行的情况下做出。
Q： 如果我对包裹不熟悉怎么办？ A： 进行基础研究（文档、README、包描述）以了解其目的。你不需要深厚的专业知识——维护者是最终的仲裁者。反映你的信心分数中的任何不确定性。
Q： 我应该考虑向后兼容性吗？ A： 是的，如果修复错误会破坏现有代码，请在评估维护人员是否会欢迎它时注意这一点。
Q： 如果bug已经被报告了怎么办？ A： 如果它是一个真正的bug，请将其标记为一个bug，但请在“维护人员会欢迎吗”中注意，它是已知的，并提供现有报告的链接。这有助于避免重复工作。
Q： 我应该调查多深？ A： 把更多的时间花在模棱两可的案件上。明确的错误或非错误应该是快速的决定。以合理的谨慎为目标，真诚地做出贡献。
Q： 什么是安全问题？ A： 任何可能被利用的漏洞：崩溃系统、损坏数据、绕过访问控制、泄露信息或消耗过多资源。 其他资源
- Python文档：https://docs.python.org/3/
- PyPI包搜索：https://pypi.org/
- GitHub代码搜索：https://github.com/search
- 常见漏洞类型：https://owasp.org/www-community/vulnerabilities/
关于不熟悉的包的说明：你不熟悉的研究包，但你不需要深厚的专业知识。注重合理关怀，为诚信贡献力量。当你对包的域不太熟悉时，使用较低的置信度分数。