所有收藏
入门
新手
争议解决 - 好与坏的示例
争议解决 - 好与坏的示例

快速了解好坏争议之间的区别

Nikola Jonic avatar
作者:Nikola Jonic
一周前更新

"争议解决是一个特性,旨在为您提供机会,如果您认为您的漏洞被不合理地认为是合法或降级,可以向我们的争议经理提交请求。"

动机

收到漏洞拒绝通知从来都不容易接受,但我们经验丰富的测试员知道如何处理。他们知道何时以及如何提交成功的漏洞争议,以便让争议经理对其漏洞报告进行最终审核。漏洞争议是一个旨在为您提供机会,如果您认为您的漏洞是合法的或被不合理地降级,可以向我们的争议经理提交请求的功能。关于漏洞争议功能的更多信息可以在这里找到

何时提交漏洞争议

为了防止自己被封锁一个月,您需要确保只针对您百分之百确定的漏洞提交漏洞争议。这可能听起来像是我们在试图吓唬你,但这不是我们的目标。我们希望你开始思考你提交的漏洞以及TL评论中提供的拒绝/降级原因。

请自己问:“我有没有忽略什么?我是否上传了控制台日志以支持我关于漏洞的声明?我是否忘记在漏洞报告中分享某些东西?我是否正确理解了产品?”一旦你回答了这些问题,你就会知道是否应该提交漏洞争议。

一个好的漏洞争议包含什么

你是否曾经考虑过在法庭上提出投诉?这与提交漏洞争议并没有太大不同。它们都需要包括:

  • 评审员的正式问候

  • 为什么您联系他们的解释

  • 为什么您认为您的权益受到损害的原因

  • 附加证据,如附件、链接和日志

  • 问题的建议解决方案

  • 结尾的正式问候

争议解决:争议经理的角色

争议经理的目标是确保在团队领导和测试员之间解决争议时公平性。

如果双方提出了有效的论点,且其权重相等,优势将给予测试员,争议经理将对测试员有利的决策。在这种情况下,测试员的关切将被优先考虑。

但是,如果争议被拒绝,这意味着拒绝的原因是合理的,测试员应从中吸取经验。

争议经理努力维护公平性的平衡,始终考虑规则、漏洞报告的质量以及在审查漏洞争议时应用的广泛经验。他们的目标是在决策过程中尽可能公平。

漏洞争议的积极示例

在上面,您了解了如何使您的漏洞争议成功所需的内容。现在,让我们看看在实践中它是什么样子。下面的示例涵盖了一个真实场景。有时,测试员不需要使用上面提到的所有元素来证明问题是合法的。在下面的积极示例中,您可以看到测试员只使用了4个元素:

  • 问候语"你好,争议团队"

  • 为什么测试员认为该问题是漏洞

  • 如果不修复漏洞,可能的影响和受影响的受众

  • 结尾的正式问候是"请重新检查一下!谢谢!"

考虑到测试员尽可能简洁但又详细,我们可以得出结论,找到正确的平衡是成功的关键。使争议成功的机会增加的另一种方法是提供一些未包含在初始漏洞报告中的附加信息。例如,将第二个屏幕录像或控制台日志上传到Google Drive并在争议中共享为链接。

漏洞争议的负面示例

怀着愤怒或严厉的态度参与争议从来都不是一个好主意。你可以试试,但最终会被拒绝、警告,甚至在我们的平台上被封禁。所以,请计算一下粗鲁、不专业或暴力的可能情景。听起来糟糕吗?

另一方面,一些测试员不阅读或忘记了我们的规则,这导致了漏洞报告的拒绝和漏洞争议的拒绝。在下面的情况中,测试员写道:

  • 标题和实际结果应该是相似的。

    标题旨在提供关于何时、何地和发生了什么的简短描述。它应该尽可能简短,但又足够详细。另一方面,实际结果中,测试员应该详细解释问题是什么,指出问题的范围,受影响的其他页面(如果有的话)等。在漏洞报告标题中分享所有这些细节是不可能的。

  • 视频准确显示了所有步骤的顺序并展示了描述的问题。

    屏幕录像不应显示重现漏洞所需的所有步骤。视频中只应显示最后一两个步骤。

漏洞争议中缺少什么

  • 开头的官方问候语

  • 我们规则的了解

  • 我们漏洞报告质量标准的了解

  • 用于支持漏洞严重性声明的附加信息

更多测试员在提交漏洞争议时犯的错误示例包括:

  • 在漏洞争议中只写"请审查!"

  • 写"谢谢TL,我明白了!",以为他们是通过漏洞报告的评论做出回应

  • 将争议经理称为TL

  • 谎称未回答的请求等

请记住,我们看到每个漏洞报告的历史。诚实和辛勤工作之路是唯一的保证,我们将考虑您是否有可能在未来晋升。如果您想在我们公司开展职业生涯,请确保您朝着正确的方向迈出正确的步伐。

这是否解答了您的问题?